Eu tenho alguns discos no meu servidor (para RAID) e algumas partições de inicialização para testar várias distros. Em algum momento eu tinha um Debian de 32 bits recente (10 buster) e um Debian de 64 bits recente (10 buster) e, por alguns motivos, decidi mover o Debian de 64 bits para uma partição inferior (com dd, configurando um novo UUID e atualizando-o no /etc/fstab dessa partição), e então instalei um Linux Mint Cinnamon recente (20.1 Ulyssa) na partição para onde o Debian eu mudei estava antes. Eu não esperava que isso causasse problemas, pois a instalação do Linux Mint executaria o update-grub e levaria minha nova partição mas para o Debian 64, porém, naquele momento, meu Debian 64 bits parou de funcionar. Indicando que não foi possível encontrar a partição raiz.
Existem alguns comentários a fazer sobre isso: o processo de instalação do Debian é muito bom em me avisar que pode haver partições não UEFI que podem não funcionar mais se eu tentar instalar o grub no modo UEFI (e propõe iniciar no BIOS modo de compatibilidade) -) com o qual o Mint não parece se importar muito. e então o mint configurou meu grub no modo UEFI. No entanto, o estranho é que isso impediu que meu Debian 64 funcionasse, mas não meu Debian 32.
Devo admitir que o processo do grub nunca ficou claro para mim, mas o que não entendo é que tentar reinstalar e atualizar o grub do meu Debian 32 não resolveu o problema, e tentar encontrar um arquivo com o UUID com falha, em /etc e /boot (incluindo subdiretórios), em ambas as partições (Debian 32 e 64). Finalmente resolvi o problema editando a linha de comando do grub do meu Debian 64 na inicialização e, em seguida, reinstalando e atualizando o grub do meu Debian 64.
No entanto, o que eu realmente gostaria de entender é onde esse UUID foi armazenado (por que não consegui encontrá-lo) e por que não consegui resolver esse problema na minha partição Debian 32.
EDIT: Para ficar claro: consegui inicializar substituindo root=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx por root=/dev/sdxx editando os parâmetros do kernel durante o menu grub durante a inicialização e o initrd foi NÃO modificado no processo subsequente de restauração do grub. No entanto, não consegui encontrar esse valor UUID (nem xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx nem xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx), em qualquer arquivo descompactado em/etc e/boot.
EDIT2: Ok... O que eu procurava estava em /boot/grub/grub.cfg (graças ao Archemar), mas não encontrei porque me atrapalhei com minha expressão regular na busca em
find /boot /etc -type f -print0 |
xargs -0 grep -li 'a9c85b02-?751e-?48b5-?b85e-?df60d20b5d3e'
grep regexps não reconhece? Eu deveria ter usado {0,1} em vez disso... :'(
find /boot /etc -type f -print0 |
xargs -0 grep -li 'a9c85b02-\{0,1\}751e-\{0,1\}48b5-\{0,1\}b85e-\{0,1\}df60d20b5d3e'
No entanto, isso não explica por que não funcionou quando reinstalei e reconfigurei o grub da minha partição debian 32. por acaso o reconhecimento de outras partições Linux seria baseado na análise dessas /boot/grub/grub.cfgpartições ??? :-o
Responder1
Encontrei um problema semelhante no VMware movendo o disco de inicialização + sistema de um disco de 800 Gb para 16 Gb, simplesmente copiando a partição e o arquivo (do disco de 800 Gb para 16 Gb) e descartar o disco de 800 Gb seria insuficiente (inicialização do kernel OK, mas falha ao localizar /o UUID) . (e, infelizmente, neste caso, o snapshot do VMware não foi útil como proteção contra reversão)
- pontos de montagem estão presentes
/etc/fstab, mas existem2fstab - planície
fstabestá em/etc - O segredo
/etc/fstabestáinitrd.gz(ou algo semelhante) na/bootpartição do disco de inicialização, este fstab mantém o UUID apontando para/(FS raiz) do sistema operacional.
Reconstrua initrdse você inicializou a partir deste sistema operacional.
Ou se você inicializou a partir de outro sistema operacional, initrd.gzé um cpio gzipado, "simplesmente" extrair fstabo arquivo, editá-lo e colocá-lo novamente no formato initrd.gz.