Tengo algunos discos en mi servidor (para RAID) y algunas particiones de arranque para probar varias distribuciones. En algún momento tuve un Debian reciente (10 buster) de 32 bits y un Debian reciente (10 buster) de 64 bits, y por algunas razones, decidí mover el Debian de 64 bits a una partición inferior (con dd, configurando una nueva UUID y actualizándolo en /etc/fstab de esa partición), y luego instalé un Linux Mint Cinnamon reciente (20.1 Ulyssa) en la partición donde estaba Debian antes. No esperaba que planteara problemas, porque al instalar Linux Mint ejecutaría update-grub y tomaría mi nueva partición para Debian 64, sin embargo, en ese momento, mi Debian 64 bits dejó de funcionar. Indicando que no pudo encontrar la partición raíz.
Hay algunos comentarios que hacer al respecto: el proceso de instalación de Debian es bastante bueno al advertirme que puede haber particiones que no sean UEFI que podrían no funcionar más si intento instalar grub en modo UEFI (y propone comenzar en BIOS). modo de compatibilidad) -) que a Mint no parece importarle mucho. y entonces mint configuró mi grub en modo UEFI. Sin embargo, lo extraño es que detuvo el funcionamiento de mi Debian 64, pero no de mi Debian 32.
Debo admitir que el proceso de grub nunca me ha quedado claro, pero lo que no entiendo, es que intentar reinstalar y actualizar grub desde mi Debian 32 no solucionó el problema, y tratar de encontrar un archivo con el UUID defectuoso, en /etc y /boot (incluidos los subdirectorios), en ambas particiones (Debian 32 y 64). Finalmente resolví el problema editando la línea de comando de grub de mi Debian 64 en el arranque y luego reinstalando y actualizando grub desde mi Debian 64.
Sin embargo, lo que realmente me gustaría entender es dónde se almacenó este UUID (por qué no pude encontrarlo) y por qué no pude resolver este problema desde mi partición Debian 32.
EDITAR: Para que quede claro: pude arrancar reemplazando root=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx por root=/dev/sdxx editando los parámetros del kernel desde el menú de grub durante el arranque y initrd fue NO modificado en el posterior proceso de restauración del grub. Sin embargo, no pude encontrar este valor UUID (ni xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ni xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx), en ningún archivo sin comprimir en /etc & /boot.
EDIT2: Ok... Lo que estaba buscando estaba en /boot/grub/grub.cfg (gracias a Archemar), pero no lo encontré porque busqué a tientas mi expresión regular en la búsqueda en
find /boot /etc -type f -print0 |
xargs -0 grep -li 'a9c85b02-?751e-?48b5-?b85e-?df60d20b5d3e'
¿Las expresiones regulares grep no reconocen? Debería haber usado {0,1} en su lugar... :'(
find /boot /etc -type f -print0 |
xargs -0 grep -li 'a9c85b02-\{0,1\}751e-\{0,1\}48b5-\{0,1\}b85e-\{0,1\}df60d20b5d3e'
Sin embargo, no explica por qué no funcionó cuando reinstalé y reconfigure grub desde mi partición Debian 32. ¿Por casualidad el reconocimiento de otras particiones de Linux se basaría en el análisis /boot/grub/grub.cfgde esas particiones? :-s
Respuesta1
Encontré un problema similar en vmware al mover el disco de arranque+sistema de un disco de 800 Gb a 16 Gb, simplemente copiar la partición y el archivo (del disco de 800 Gb a 16 Gb) y soltar el disco de 800 Gb sería insuficiente (el arranque del kernel está bien pero no puedo ubicar /el UUID) . (y lamentablemente en este caso la instantánea de vmware no fue útil como protección de reversión)
- Los puntos de montaje están en
/etc/fstabpero hay2fstab - la llanura
fstabestá en/etc - El secreto
/etc/fstabestá eninitrd.gz(o similar) en/bootla partición del disco de arranque, este fstab contiene el UUID que apunta al/(FS raíz) del sistema operativo.
O reconstruya initrdsi ha iniciado desde este sistema operativo.
O si ha arrancado desde otro sistema operativo, initrd.gzes un cpio comprimido con gzip, "simplemente" extraiga fstabel archivo, edítelo y vuelva a colocarlo en el formato initrd.gz.