Solution de contournement pour GMO VPS (CentOS8.1) ne pouvant pas démarrer après la mise à jour de yum

J'ai eu la chance de ne pas pouvoir redémarrer si j'exécutais yum update lors de la construction d'un serveur (CentOS8.1) avec GMO VPS. Des modifications ont été apportées à /boot/grub2/grub.cfg lors de la mise à jour de yum, ce qui semble être l'effet. Pour éviter cela, enregistrez /boot/grub2/grub.cfg au début de la construction du serveur et restaurez-le après la mise à jour de yum.

Quel genre de symptôme

Démarrez le serveur (CentOS8.1) disponible pour GMO VPS à partir du portail VPS en mode normal, et lorsqu'il est à l'état "ON", connectez-vous à TeraTerm et connectez-vous en tant que root. La même chose est vraie si vous vous connectez à partir de la console du portail VPS. Exécutez ensuite yum update et redémarrez le serveur.


login: root
Password: ***
$ yum update -y
$ reboot

Ensuite, vous ne pouvez pas vous connecter depuis TeraTerm, et l'écran de sélection GRUB s'ouvre depuis la console du portail VPS, et vous ne pouvez pas continuer.

Pourquoi ça arrive

GRUB est un chargeur de démarrage pour sélectionner l'emplacement de chargement et de démarrage de l'image du système d'exploitation. Il existe un ancien GRUB (GRUB Legacy) et un nouveau GRUB2. GRUB2 provient de CentOS7 ou version ultérieure. Sélectionnez s'il faut utiliser GRUB Legacy ou GRUB2, quelle image du système d'exploitation utiliser, charger l'image du système d'exploitation et démarrer le système d'exploitation. Normalement, l'image du système d'exploitation à utiliser mémorise les paramètres par défaut et celui sélectionné par l'utilisateur pour la première fois, et effectue automatiquement une série d'opérations. Cependant, il semble que l'image du système d'exploitation ne puisse pas être sélectionnée automatiquement en exécutant la mise à jour yum. Par conséquent, à partir de TeraTerm, il expire lors de la connexion, et à partir de la console du portail VPS, il s'arrête à l'écran de sélection de GRUB Legacy et GRUB2.

Sur la console du portail VPS, il peut être possible de traiter les commandes GRUB à partir de l'écran de sélection GRUB. J'ai abandonné tôt car la liaison des touches était différente de celle du PC Windows, je ne pouvais pas copier et coller et je n'avais aucune connaissance de la commande GRUB.

Dans CentOS8.1, GRUB2 est utilisé. Le contrôle au démarrage peut être spécifié dans le fichier / etc / default / grub. Spécifiez les secondes d'expiration avec GRUB_TIMEOUT et l'image du système d'exploitation avec GRUB_DEFAULT. L'image du système d'exploitation spécifiée est automatiquement démarrée une fois le délai d'attente écoulé. Pour être précis, exécutez la commande grub2-mkconfig à l'avance pour créer le fichier / boot / grub2 / grub.cfg en fonction de la description du fichier grub et des fichiers sous/ etc / grub.d /. Il est généré. Le fichier grub.cfg est exécuté au démarrage, pas le fichier grub n'est interprété au démarrage. Pour plus de détails sur GRUB2, reportez-vous à https://documentation.suse.com/ja-jp/sles/12-SP4/html/SLES-all/cha-grub2.html.

En d'autres termes, en raison de la mise à jour de yum, le fichier grub.cfg a été réécrit ou la situation ne peut pas être exécutée comme décrit dans le fichier grub.cfg (par exemple, le fichier requis est manquant).

Il fait également référence à / boot / grub2 / grubenv au démarrage. Cela enregistre les paramètres du démarrage précédent et est référencé au démarrage suivant. Utilisé lorsque GRUB_DEFAULT = saved est spécifié. Vous pouvez contrôler le prochain démarrage en modifiant le fichier grubenv après le démarrage. Par exemple, vous pouvez modifier directement Saved_entry sans passer par / etc / default / grub en exécutant la commande grub2-set-default.

Les étapes à éviter

Si vous enregistrez le fichier grub.cfg après la première connexion et que vous le restaurez après la mise à jour de yum, cela semble tout à fait le cas. La procédure sera décrite ci-dessous.

(1) Démarrez le serveur en mode normal depuis le portail VPS et connectez-vous en tant que root depuis TeraTerm. Ensuite, vérifiez la version dans l'état initial. CentOS 8.1.


$ cat /etc/redhat-release	
CentOS Linux release 8.1.1911 (Core) 

(2) Enregistrez les fichiers suivants à l'avance car vous ne pourrez pas démarrer après la mise à jour de yum. En fait, le fichier grub.cfg seul convient, mais il est également bon d'enregistrer d'autres fichiers.


$ cp /etc/default/grub /etc/default/grub.original
$ cp /boot/grub2/grub.cfg /boot/grub2/grub.cfg.original
$ cp /boot/grub2/grubenv /boot/grub2/grubenv.original

En fait, le fichier grub a déjà été sauvegardé en tant que «grub.rpmsave», et le fichier grub.cfg a également été sauvegardé en tant que «grub.cfg.rpmsave». Ces fichiers peuvent suffire, mais dans la procédure ci-dessus, je l'ai rendu explicite. Au fait, / etc / default / grub est comme suit.


$ cat /etc/default/grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="crashkernel=auto biosdevname=0 net.ifnames=0 rhgb quiet"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true
GRUB_DISABLE_UUID=true
GRUB_DISABLE_LINUX_UUID=true

GRUB_TIMEOUT et GRUB_DEFAULT indiquent de démarrer la dernière image du système d'exploitation utilisée après avoir attendu 5 secondes. GRUB_DEFAULT est spécifié par un nombre tel que 0,1,2, ..., par le nom de l'image du système d'exploitation, ou par «" sauvé "». Dans le cas de "saved", la valeur "saved_entry" dans le fichier / boot / grub2 / grubenv identifie l'image du système d'exploitation utilisée la dernière fois.


$ cat /boot/grub2/grubenv
saved_entry=20db05bac820110f5800ebe2e7262b58-4.18.0-193.28.1.el8_2.x86_64
kernelopts=root=/dev/vda1 ro crashkernel=auto biosdevname=0 net.ifnames=0 rhgb quiet
boot_success=1

(3) Exécutez la mise à jour de yum. Exécution de la mise à jour yum en question. Environ 200 modules seront mis à jour.


$ yum update -y

(4) Vérifiez la version après la mise à jour de yum. Il a été mis à niveau vers CentOS 8.2.


$ cat /etc/redhat-release
CentOS Linux release 8.2.2004 (Core)

(5) Défini de sorte que le noyau ne soit pas mis à jour par yum update à l'avenir.


$ vi /etc/yum.conf
exclude=kernel*

(6) Restaurez le fichier grub.cfg enregistré. / etc / default / grub est inchangé, donc aucune restauration n'est requise. grubenv est mis à jour au démarrage, mais généralement le contenu est le même que la dernière fois. Si vous utilisez la commande grub2-set-default, grubenv sera réécrit. Dans ce cas, récupérez.


$ cp /boot/grub2/grub.cfg.original /boot/grub2/grub.cfg
$ cp /boot/grub2/grubenv.original /boot/grub2/grubenv

$ awk -F\' '$1=="menuentry " {print $2}' /boot/grub2/grub.cfg
CentOS Linux (4.18.0-147.5.1.el8_1.x86_64) 8 (Core)

(7) À ce stade, redémarrez et confirmez que vous pouvez vous connecter depuis TeraTerm.

(8) Modifiez le fichier grub et reflétez-le avec la commande grub2-mkconfig. Dans le fichier grub, seul GRUB_CMDLINE_LINUX est modifié. Ensuite, vérifiez si celui identifié par saved_entry dans le fichier grubenv se trouve dans le message " Found linux ". Vous pouvez également vérifier le résultat de awk. On peut voir que le début (0e) est applicable.


#Modifier le fichier grub
$ vi /etc/default/grub
GRUB_TIMEOUT=3
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="rd.lvm.lv=centos/root rd.lvm.lv=centos/swap 
 vconsole.font=latarcyrheb-sun16 vconsole.keymap=jp106 
 biosdevname=0 net.ifnames=0 rhgb quiet "
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true
GRUB_DISABLE_UUID=true
GRUB_DISABLE_LINUX_UUID=true

# grub.Refléter dans un fichier cfg
$ grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.18.0-193.28.1.el8_2.x86_64
Found initrd image: /boot/initramfs-4.18.0-193.28.1.el8_2.x86_64.img
Found linux image: /boot/vmlinuz-4.18.0-147.5.1.el8_1.x86_64
Found initrd image: /boot/initramfs-4.18.0-147.5.1.el8_1.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-20db05bac820110f5800ebe2e7262b58
Found initrd image: /boot/initramfs-0-rescue-20db05bac820110f5800ebe2e7262b58.img
done

$ awk -F\' '$1=="menuentry " {print $2}' /boot/grub2/grub.cfg
CentOS Linux (4.18.0-193.28.1.el8_2.x86_64) 8 (Core)
CentOS Linux (4.18.0-147.5.1.el8_1.x86_64) 8 (Core)
CentOS Linux (0-rescue-20db05bac820110f5800ebe2e7262b58) 8 (Core)

#Vérifiez le fichier grubenv
$ cat /boot/grub2/grubenv
saved_entry=20db05bac820110f5800ebe2e7262b58-4.18.0-193.28.1.el8_2.x86_64
kernelopts=root=/dev/vda1 ro crashkernel=auto biosdevname=0 net.ifnames=0 rhgb quiet
boot_success=1

(9) Il n'y a aucun problème si vous pouvez redémarrer et vous connecter à partir de TeraTerm.

Supplément 1: commande grub2-mkconfig

J'ai essayé de générer grub.cfg en exécutant la commande grub2-mkconfig immédiatement après la mise à jour de yum dans la procédure ci-dessus. Le résultat était NG. Je ne peux plus me connecter depuis TeraTerm, et je dois m'arrêter sur l'écran GRUB2 depuis la console du portail VPS. La description de menuentry dans grub.cfg est manquante. Je ne connais pas la cause. Cela semble fonctionner si vous exécutez grub2-mkconfig après le redémarrage comme dans les étapes (8) et (9) ci-dessus.

Supplément 2: commande grub2-set-default

En regardant / boot / grub2 / grubenv, saved_entry contient le nom 20db05bac820110f5800ebe2e7262b58-4.18.0-193.28.1.el8_2.x86_64 au lieu du nombre (0,1,2, ...). Il semble correspondre dans la dernière partie "4.18.0-193.28.1.el8_2.x86_64".


$ cat /boot/grub2/grubenv
saved_entry=20db05bac820110f5800ebe2e7262b58-4.18.0-193.28.1.el8_2.x86_64
kernelopts=root=/dev/vda1 ro crashkernel=auto biosdevname=0 net.ifnames=0 rhgb quiet
boot_success=1

En passant, en exécutant grub2-set-default, saved_entry peut être modifié directement sans passer par / etc / default / grub.


$ grub2-set-default 0
$ cat /boot/grub2/grubenv
saved_entry=0
kernelopts=root=/dev/vda1 ro crashkernel=auto biosdevname=0 net.ifnames=0 rhgb quiet
boot_success=1

Supplément 3: Réparation à partir du mode de récupération

Si vous ne pouvez pas le démarrer, démarrez le serveur en mode de récupération à partir du portail VPS, connectez-vous en tant que root depuis TeraTerm et suivez les étapes ci-dessous pour le réparer. Le mot de passe est le mot de passe initial, pas la «récupération». Le message sur le portail VPS semble être faux. La procédure consiste à identifier et à monter le disque principal avant de l'utiliser.


$ fdisk -l | more
  /dev/vda1
$ mount /dev/vda1 /mnt
$ cp /mnt/boot/grub2/grub.cfg.original /mnt/boot/grub2/grub.cfg

Je ne l'ai pas essayé, mais comme grub.cfg.rpmsave existait déjà, j'aurais peut-être pu récupérer avec ce fichier. Si vous le copiez comme suit et redémarrez le serveur, vous avez peut-être pu récupérer en suivant les étapes (8) et (9) ci-dessus.


$ cp /mnt/boot/grub2/grub.cfg.rpmsave /mnt/boot/grub2/grub.cfg

c'est tout

Recommended Posts

Solution de contournement pour GMO VPS (CentOS8.1) ne pouvant pas démarrer après la mise à jour de yum
Solution pour l'impossibilité de mettre à jour CentOS 8 (mise à jour yum / mise à jour dnf) en raison des clés centos-gpg-keys existantes
Solution pour Apache Tomcat 8 ne démarre pas après le passage à OpenJDK 11
[Explication approximative] Causes et remèdes pour ne pas pouvoir obtenir le nom du modèle ActiveHash