Por que preciso de GRUB_DISABLE_LINUX_UUID = true

Question

Eu apenas mudei de lilo para grub2 e minha primeira tentativa falhou com kernel panic - not syncing vfs unable to mount root fs on unknown block(0 0) . Descobriu-se que o problema era que a partição raiz era especificada em termos de um UUID em vez de um nome de dispositivo. A solução foi descomentar GRUB_DISABLE_LINUX_UUID=true em /etc/default/grub .

O /boot/grub/grub.conf auto-gerado original continha algumas entradas UUID e algumas entradas / dev.

• Como o update-grub escolhe entre o UUID e / dev rootfs, ou seja, por que às vezes é um UUID e às vezes não?
• O que impede que os UUIDs funcionem? Eu não encontrei um parâmetro do kernel que pudesse ser configurado erroneamente (kernel 3.8.2)
• Preciso de UUIDs no meu fstab quando o grub usa UUIDs?

Answer 1

O valor de GRUB_DISABLE_LINUX_UUID é usado por update-grub e os scripts no diretório /etc/grub.d/ . Se você ainda tiver UUIDs no seu grub.conf , parece que um dos scripts não está verificando a configuração GRUB_DISABLE_LINUX_UUID .

A melhor coisa a fazer é tentar descobrir qual é o tipo de sistema de arquivos e verificar isso em relação aos nomes dos scripts em /etc/grub.d para ver se há um padrão.

Por que os UUIDs não estão funcionando, não tenho uma resposta definitiva, suspeito que isso dependa do tipo de sistema de arquivos, mas isso é um palpite.

Você não precisa de UUIDs em seu fstab mesmo quando o grub os usa, mas é claro que é possível ver se você está usando os UUIDs certos (mas eu prefiro procurar em /dev/disk/by-uuid para isso ).

    

Answer 2

Caso alguém tropeça neste post e esteja usando o Centos 7 / GRUB2 (como eu sou), o nome da variável parece ter mudado para GRUB_DISABLE_UUID (não GRUB_DISABLE _LINUX _UUID).

Você pode verificar o seu em / usr / share / grub / grub-mkconfig_lib. O meu tem isto:

if [ "x$GRUB_DISABLE_UUID" != "xtrue" ]

Após um grub2-mkconfig, os UUIDs foram substituídos por / dev / sda1, etc. (o que precisávamos porque clonamos esses sistemas).