2015-12-26 12 views
6

Durante il tentativo di compilare/compilare e avviare il kernel personalizzato nella workstation vmware, durante l'avvio del nuovo kernel, fallisce e cade nella shell con errore "Impossibile trovare il disco con uuid". Ho provato questo con Ubuntu e CentOS.errore di compilazione del kernel Linux personalizzato nella workstation vmware


cose che ho provato, ma non ha aiutato


  1. mappatura controllo da uuid in voce di avvio e l'esistenza nella directory.
  2. initramfs-update
  3. sostituiti root = uuid = <> con/dev/disk/sda3

enter image description here

è emesso con workstation vmware? come può essere rettificato .. ??

+0

Puoi vedere/dev/disk/sda3 o/dev/sda3 nella shell di dracut ? Prova a guardare attraverso il dmesg per vedere se ci sono errori. – Matt

+0

Il comando 'ls -fa' non mostra l'uuid che sta cercando? Sembra meno un errore di compilazione del kernel e più come un problema di avvio, potresti voler indirizzare il tuo disco in termini di '/ dev/sd [a-z] [1-4]' nel tuo bootloader. – u8sand

+0

@Matt Li posso vedere nella shell di dracut, anche se li ho modificati in commandline, ma non mi è stato d'aiuto. dmesg dà lo stesso errore di menzione nella domanda stessa. –

risposta

0

il problema è con la creazione di initramfs, dopo aver fatto un make

oldconfig

e scegliendo di default per le nuove opzioni, assicurarsi che lo spazio su disco sia sufficiente per l'immagine da creare. nel mio caso l'immagine creata non era corretta e quindi non riusciva a montare l'immagine al momento dell'avvio.


se confrontato; la dimensione dell'immagine era piuttosto inferiore dell'immagine esistente versione inferiore, quindi aggiunto un altro disco con più di dimensione sufficiente e quindi

make bzImage

fanno moduli

make modules_install

make install

inizia a funzionare come un fascino. Mi chiedo perché la creazione dell'immagine è stata completata in precedenza e ha provocato un'immagine corrotta (con meno dimensioni) senza generare alcun errore [ogni volta]

2

Ho avuto un errore simile con i miei tentativi di avviare Fedora 22 su una partizione vuota utilizzando un'installazione di Centos su un'altra partizione. Non l'ho mai risolto completamente, ma ho scoperto che il problema era nel mio initrd piuttosto che nel kernel.

Il problema è che l'initrd non sta avviando LVM perché dracut non ha detto al initrd che ha bisogno di LVM. Quindi se avvii manualmente LVM dovresti essere in grado di avviarsi nel tuo sistema per risolverlo.

Credo che questa sia la sequenza di comandi ho eseguito dalla shell di emergenza per avviare LVM:

vgscan 
vgchange -ay 
lvs 

this link helped me remember

Seguito da exit per riprendere avvio normale.

Potrebbe essere necessario montare manualmente le voci LVM/etc/fstab, non ricordo se l'ho fatto o no.

+0

comando vgscan non vengono riconosciuti. come si entra esplicitamente nel guscio di emergenza ..? quando non riesce ad avviarsi automaticamente scende al guscio di emergenza giusto ..? –

+0

Sì, è giusto, è quello nel tuo secondo screenshot. –

+0

perché vgscan non viene riconosciuto allora ..? cosa dovrebbe essere fatto per farlo funzionare in caso di emergenza ..? –

0

Prova questo:

sudo update-grub 

Poi:

mkinitcpio -p linux 

Non farà male a controllare il vostro file di fstab. Lì, dovresti trovare l'UUID del tuo disco. Assicurati di avere i flag corretti impostati nel fstab.

Inoltre, c'è un'impostazione nello grub.cfg che ha lo GRUB uso del vecchio stile di UUID esadecimali. Controlla anche tu!

+0

Il comando mkinitcpio non è riconosciuto. Ho ubuntu e centos ma non archlinux nelle macchine guest –

+0

Ah. Hai controllato l'opzione 'GRUB' che ho menzionato? Potrebbe non riuscire ad avviarsi perché si aspetta un formato diverso. – Ray

+0

sì @Ray l'avevo già aggiornato, l'ho eseguito parecchie volte ma non ha aiutato :( –

Problemi correlati