Upgrade a 12.04LTS dump su busybox all'avvio

4

Ho appena aggiornato il mio server da 10.04LTS a 12.04 LTS utilizzando il processo di aggiornamento del server documentato qui: link .

Al momento del boot, ora sono scaricato nella shell busybox (di più su questo in un attimo). Tuttavia, se avvio un kernel dalla versione precedente, tutto funziona correttamente.

L'unica cosa strana riguardo alla mia configurazione è che il mio dispositivo di avvio è un dispositivo multi-disco che utilizza RAID1. Quando arrivo alla shell busybox, digitando "mount / dev / md0 / root" funziona bene. Ho provato a passare in rootdelay = 30 e sono stato scaricato nella shell entro 5 secondi dall'avvio.

Diversamente dalla domanda segnata qui: Aggiornato da Dal 10.04 al 12.04 e grub si riduce alla richiesta di BusyBox senza errori Non ho eseguito il boot con l'opzione splash o quiet e non ho ricevuto lamentele su un array degradato. Tuttavia, ho provato a fare il boot con l'opzione del kernel bootdegraded e questo non ha funzionato neanche.

Qualche idea su cosa provare?

(E sì, l'alimentatore è collegato :-))

Informazioni sulla configurazione:

Versione grub: grub (GNU GRUB 0.97)

Gran parte delle opzioni di menu.lst di grub sono commentate (per usare i valori predefiniti). Il kernel più recente che non funziona:

title           Ubuntu 12.04.2 LTS, kernel 3.2.0-51-generic-pae
root            (hd0,1)
kernel          /boot/vmlinuz-3.2.0-51-generic-pae root=/dev/md0 ro
initrd          /boot/initrd.img-3.2.0-51-generic-pae
quiet

Il kernel più recente che funziona:

title           Ubuntu 12.04.2 LTS, kernel 2.6.32-46-generic-pae
root            (hd0,1)
kernel          /boot/vmlinuz-2.6.32-46-generic-pae root=/dev/md0 ro
initrd          /boot/initrd.img-2.6.32-46-generic-pae
quiet

Informazioni mdadm:

[email protected]:/boot/grub$ sudo mdadm --detail /dev/md0
/dev/md0:
        Version : 0.90
  Creation Time : Sat Dec 16 22:27:17 2006
     Raid Level : raid1
     Array Size : 57609024 (54.94 GiB 58.99 GB)
  Used Dev Size : 57609024 (54.94 GiB 58.99 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Mon Sep  2 17:02:27 2013
          State : clean 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           UUID : 5c92f0d9:9cf5be95:03611c5e:a540b92f
         Events : 0.24172972

    Number   Major   Minor   RaidDevice State
       0       8       18        0      active sync   /dev/sdb2
       1       8        2        1      active sync   /dev/sda2

Dati del dispositivo Md visti dal kernel:

[email protected]:~$ cat /proc/mdstat 
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md0 : active raid1 sda2[1] sdb2[0]
      57609024 blocks [2/2] [UU]

unused devices: <none>
    
posta Garrett Kajmowicz 13.06.2013 - 01:07

1 risposta

1

Questo è causato da una strana configurazione e da una modifica negli script di avvio.

Innanzitutto, il dispositivo con mirroring, / dev / md0 non ha una tabella delle partizioni. Viene trattato come un dispositivo a blocchi grezzi con un filesystem direttamente su di esso. In casi di emergenza, ciò consente al dispositivo di backup (/ dev / sda2 o / dev / sdb2) di essere avviato direttamente. In precedenza su questa partizione esisteva un'installazione di LVM di breve durata, ma ciò era ritenuto non necessario, pertanto il dispositivo è stato reinizializzato come dispositivo raw ext3. Ciò tuttavia non ha rimosso con successo tutte le tracce di LMV. Ciò si traduce nell'utilità attesa per radice che restituisce "LVM2_member" come tipo di dispositivo. Ha sempre fatto questo.

In secondo luogo, gli aggiornamenti allo script di avvio 'scripts / local' hanno cambiato il comando mount da:

mount ${roflag} ${ROOTFLAGS} ${ROOT} ${rootmnt}

a:

mount ${roflag} ${FSTYPE:+-t ${FSTYPE} }${ROOTFLAGS} ${ROOT} ${rootmnt}

Mount ora fallisce perché stiamo forzando il tipo di filesystem nel comando mount. In questo caso, il tipo 'LVM2_member' non funziona affatto - abbiamo invece bisogno di ext3. La vecchia versione funzionava perché mount era facilmente in grado di determinare che si trattava di un filesystem ext3.

La soluzione a breve termine per questo è passare in rootfstype = ext3 sulla linea di avvio del kernel. Questo ignora il tipo di filesystem impropriamente rilevato automaticamente e specifica ext3 da montare.

    
risposta data Garrett Kajmowicz 08.10.2013 - 16:53

Leggi altre domande sui tag