Mise à niveau vers les vidages 12.04LTS vers busybox au démarrage
Je viens de mettre à niveau mon serveur de 10.04LTS à 12.04 LTS en utilisant le processus de mise à niveau du serveur documenté ici: https://help.ubuntu.com/community/PreciseUpgrades .
Au démarrage, je suis maintenant transféré vers le shell busybox (plus à ce sujet dans un instant). Cependant, si je démarre un noyau de la version précédente, tout démarre correctement.
La seule chose étrange dans ma configuration est que mon périphérique de démarrage est un périphérique multi-disque utilisant RAID1. Quand j'arrive au shell de la boîte occupée, taper "mount/dev/md0/root" fonctionne très bien. J'ai essayé de passer rootdelay = 30 et je suis transféré vers le shell dans les 5 secondes suivant le démarrage.
Contrairement à la question marquée ici: mise à niveau de 10.04 à 12.04 et grub passe à BusyBox Prompt sans erreur Je n'ai pas démarré avec l'option splash ou quiet, et je n'ai reçu aucune plainte concernant un tableau dégradé . Néanmoins, j'ai essayé de démarrer avec l'option de noyau bootdegraded et cela n'a pas fonctionné non plus.
Des réflexions sur ce qu'il faut essayer?
(Et oui, l'alimentation est branchée :-))
Informations de configuration:
Version Grub: grub (GNU GRUB 0.97)
La plupart des options de grub menu.lst sont mises en commentaire (pour utiliser les valeurs par défaut). Noyau le plus récent qui ne fonctionne pas:
titre Ubuntu 12.04.2 LTS, noyau 3.2.0-51-generic-pae racine (hd0,1) noyau /boot/vmlinuz-3.2.0-51- racine-de-pae-générique =/dev/md0 ro initrd /boot/initrd.img-3.2.0-51-generic-pae[.____. E5Equiet
Noyau le plus récent qui fonctionne:
titre Ubuntu 12.04.2 LTS, noyau 2.6.32-46-generic-pae racine (hd0,1) noyau /boot/vmlinuz-2.6.32-46- racine générique-pae =/dev/md0 ro initrd /boot/initrd.img-2.6.32-46-generic-pae[.____.[quiet
informations mdadm:
garrett @ stargate:/boot/grub $ Sudo mdadm --detail /dev/md0[.____.[/dev/md0: Version: 0.90 Heure de création: Sat 16 déc 22:27:17 2006 Niveau de raid: raid1 Taille de la baie: 57609024 (54,94 GiB 58,99 Go) Taille de dév utilisée: 57609024 (54,94 GiB 58,99 Go) Périphériques RAID: 2 Nombre total de périphériques: 2 Mineur préféré: 0 Persistance: Le superbloc est persistant Heure de mise à jour: lun. 2 sept. 17:02:27 2013 État: nettoyer Périphériques actifs: 2 Périphériques de travail: 2 Périphériques défaillants: 0 Périphériques de rechange: 0 UUID: 5c92f0d9: 9cf5be95: 03611c5e: a540b92f Événements: 0.24172972 Nombre Majeur Mineur État du RaidDevice 0 8 18 0 synchronisation active /dev/sdb2 1 8 2 1 synchronisation active /dev/sda2
Données du périphérique MD vues par le noyau:
garrett @ stargate: ~ $ cat/proc/mdstat Personnalités: [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md0: raid1 actif sda2 [1] sdb2 [0] 57609024 bloque [2/2] [UU] périphériques inutilisés: <aucun>
Cela est dû à une configuration étrange ainsi qu'à une modification des scripts de démarrage.
Tout d'abord, le périphérique en miroir,/dev/md0 n'a pas de table de partition. Il est traité comme un périphérique bloc brut avec un système de fichiers directement dessus. En cas d'urgence, cela permet de démarrer directement le périphérique de sauvegarde (/ dev/sda2 ou/dev/sdb2). Il y avait auparavant une installation de courte durée de LVM sur cette partition, mais cela a été jugé inutile car le périphérique a été réinitialisé en tant que périphérique ext3 brut. Cependant, cela n'a pas réussi à éliminer toutes les traces de LMV. Il en résulte que l'utilitaire wait-for-root renvoie "LVM2_member" comme type de périphérique. Il l'a fait depuis le début.
Deuxièmement, les mises à jour du script de démarrage "scripts/local" ont changé la commande de montage de:
monter $ {roflag} $ {ROOTFLAGS} $ {ROOT} $ {rootmnt}à:
monter $ {roflag} $ {FSTYPE: + - t $ {FSTYPE}} $ {ROOTFLAGS} $ {ROOT} $ {rootmnt}Le montage échoue maintenant car nous forçons le type de système de fichiers dans la commande de montage. Dans ce cas, le type 'LVM2_member' ne fonctionne pas du tout - nous avons besoin d'ext3 à la place. L'ancienne version fonctionnait car mount était facilement en mesure de déterminer qu'il s'agissait d'un système de fichiers ext3.
La solution à court terme pour cela consiste à passer rootfstype = ext3 sur la ligne de démarrage du noyau. Ceci ignore le type de système de fichiers incorrectement détecté automatiquement et spécifie ext3 à monter.