Convertir partición de GPT a MBR
Resuelto
lenainjaune Mensajes publicados 726 Fecha de registro Estado Contributeur Última intervención -
Hola a to.dos :D,
¿Cuál es el método correcto para convertir una partición Debian al formato Ext4 desde un soporte con una tabla de partición GPT en una máquina con EFI con el fin de integrarla en un disco MBR para ser utilizada en una máquina con BIOS?
He probado muchos métodos diferentes sin éxito.
Finalmente, lo logré elaborando mi propio método (ver abajo) :D, pero tengo una latencia inexplicable del núcleo al arrancar y no estoy convencido de que no haya otros efectos secundarios...
---
Para implementarlo con éxito, sincronice en espejo los archivos de la partición Debian del soporte con rsync hacia una partición Ext4 en un disco que utiliza una tabla de partición MBR. Una vez hecho esto, intenté instalar el cargador GRUB con grub-install... sin éxito. Como al arrancar, el sistema se atascaba en grub rescue>, intenté la herramienta boot-repair-disk que reparó globalmente (puedo proporcionar el registro) y lo hizo funcional.
Añadido: en realidad, mi primer intento resultó en un sistema de solo lectura, que pude corregir actualizando en /etc/fstab el identificador de la partición a montar al arrancar, que se determina con blkid; también desde este mismo archivo, tuve que desactivar el archivo de intercambio SWAP que apuntaba a una partición inexistente ya que no fue clonada, para rehacerlo posteriormente.
Nota: He reducido intencionadamente las explicaciones al mínimo, pero puedo detallar cualquier punto sin problema.
---
No sé si soy lo suficientemente claro...
Por otro lado, tengo otras preguntas sobre la diferencia entre GPT y MBR.
Si alguien puede dedicarme un poco de su tiempo para ayudarme, ¡sería realmente genial :D!
Con fraternidad,
lnj
Tengo preguntas sobre todas sus respuestas. (Woody Allen)
¡Los conocimientos y las ideas pertenecen a todo el mundo (noosfera)!
4 réponses
Por otro lado, no estoy seguro de que hayas leído mi pregunta justo antes, que estaba dirigida a ti :D
Entonces supongo que la pregunta a la que te refieres es "¿Incluso para la carpeta /boot y grub?" #12
Respuesta corta
De hecho, hay que distinguir dos cosas:
- lo que configuramos nosotros mismos (y donde no nos preocupamos por MBR o GPT)
- lo que GRUB hace solo en segundo plano y que impactará en el archivo final /boot/grub/grub.cfg y en el que podemos ver matices según se use GPT o MBR.
La consideración de GPT o MBR es propia de la tabla de particiones (definidas al inicio del disco, y encargadas de definir cada partición alojada en el disco - tamaño, posición, sistema de archivos). Así, esta información reside en el encabezado del disco duro y fuera de sus particiones de datos.
Respuesta detallada
Si abrimos /boot/grub/grub.cfg, vemos que cuando usamos GPT hay líneas "insmod part_gpt" que cargan el módulo GRUB (nada que ver con un módulo del núcleo, estamos antes de cargar el núcleo cuando estamos en grub). Este módulo permite a GRUB leer particiones GPT.
Por lo tanto, la pregunta que podemos hacernos es cómo lo hizo GRUB. Como se indica al principio de /boot/grub/grub.cfg, este archivo se genera mediante el comando:
sudo update-grub
Este comando se llama implícitamente cada vez que instalas o desinstalas un nuevo núcleo (y, por tanto, en particular, cuando has instalado Linux o durante algunas actualizaciones).
Si miramos el contenido de /usr/sbin/update-grub (encontramos la ruta del ejecutable con sudo which update-grub), vemos que este script llama a grub-mkconfig. Este último se basa en:
- esqueletos de archivos de configuración de GRUB (ver /etc/grub.d/);
- el archivo de configuración /etc/default/grub (el único lugar donde se supone que debemos intervenir);
- posibles extensiones /etc/default/grub.d definidas en /etc/default/grub.d/.
En este caso, /boot/grub/grub.cfg estipula claramente que muchos de los "insmod part_gpt" se deben a los esqueletos definidos en /etc/grub.d/. Así que ahí es donde vamos a profundizar. Abrimos uno arbitrario y al principio la instrucción:
# Include the GRUB helper library for grub-mkconfig. . /usr/share/grub/grub-mkconfig_lib
Es este script auxiliar el que genera las instrucciones insmod part_gpt que aparecen finalmente en /boot/grub/grub.cfg. De hecho, si abrimos /usr/share/grub/grub-mkconfig_lib, vemos:
partmap="`"${grub_probe}" --device $@ --target=partmap`" for module in ${partmap} ; do case "${module}" in netbsd | openbsd) echo "insmod part_bsd";; *) echo "insmod part_${module}";; esac done Este fragmento de código muestra que grub-probe (es decir, /usr/sbin/grub-probe) determina qué módulos son necesarios para el correcto funcionamiento de GRUB (en particular, part_gpt para discos GPT) son necesarios.
Si la pregunta ahora es, ¿cómo hace GRUB la distinción?, es simplemente, de la misma manera que lo hace fdisk & co, mirando la forma en que está definida la tabla de particiones de tus discos duros.
Si quieres profundizar más y ver cómo está implementado, tendrías que mirar el código que generó el ejecutable /usr/sbin/grub-probe y como se trata de un binario, hay que revisar su código fuente (o el de una herramienta de particionamiento de discos) o las especificaciones pertinentes, que se presentan en la página de wikipedia sobre GPT. Se ve en particular que la información que dice "¿GPT o no?" está fuera de las particiones (lo cual es bastante normal, ya que estas consideraciones son propias de la tabla de particiones encargada de definir las particiones.)
Buena suerte
Bueno, he logrado convertir una partición de un disco con una tabla de particiones GPT a MBR
=> ¡resuelto! Celebración :D !
¿Con qué propósito? Poder aislar en p2v un sistema Debian problemático en una máquina física para probarlo en una máquina virtual (aquí con Qemu/KVM/libvirt).
Les propongo aquí mi método nativo, que no utiliza la herramienta boot-repair-disk y que seguramente no es la vía académica o deseable, pero que funciona en mi caso.
Por lo tanto, no puedo dar ninguna garantía de que funcione en otro caso y/o en otra máquina y/o con otro sistema operativo y/o otra arquitectura de virtualización.
---
Condiciones de mi prueba:
- soporte NVM Express tabla de particiones GPT 120GB en máquina EFI
- sistema a aislar Debian 12, 12/20GB libre
- Qemu/KVM v5.2.0 y libvirtd v7.0.0
Para el problema de latencia mencionado al principio, ver el hilo resuelto: Latencia del núcleo al inicio
SUPPORT_SOURCE_GPT=/dev/nvme0n1 SUPPORT_VIRTUEL_SOURCE_GPT=/dev/nbd0 SUPPORT_VIRTUEL_FINALE_MBR=/dev/nbd1 IMAGE_SOURCE_GPT=image_source_gpt.qcow2 IMAGE_FINALE_MBR=image_final_mbr.qcow2 PARTITION_ISOLEE_VIRTUELLE_SOURCE_GPT=\ $( echo ${SUPPORT_VIRTUEL_SOURCE_GPT}p5 ) # Nota: para conocer el número de partición ver detalles # de las imágenes # Atención: los soportes NVME y NBD son identificados por # números que no son números de partición # (ej: /dev/sda5 correspondería a /dev/nbd0p5) # Clonar el soporte NVME en un archivo de imagen (p2v) dd if=$SUPPORT_SOURCE_GPT of=$IMAGE_SOURCE_GPT \ bs=64K conv=noerror,sync status=progress #> 128019136512 bytes (128 GB, 119 GiB) copiados, 1123 s, 114 MB/s #> 1953669+1 registros leídos #> 1953670+0 registros escritos #> 128035717120 bytes (128 GB, 119 GiB) copiados, 1124,81 s, 114 MB/s # Probar si el módulo NBD está activo lsmod | grep -c nbd #> 1 # => activo # Activar módulo NBD si no está activo modprobe nbd max_part=8 # Cargar la imagen fuente en un soporte virtual qemu-nbd -f raw \ -c $SUPPORT_VIRTUEL_SOURCE_GPT $IMAGE_SOURCE_GPT # Crear la imagen final (>= tamaño archivos partición aislada) qemu-img create -f qcow2 $IMAGE_FINALE_MBR 15G #> Formateando 'image_source_gpt.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib #> size=16106127360 lazy_refcounts=off refcount_bits=16 # Cargar la imagen final en un soporte virtual qemu-nbd -c $SUPPORT_VIRTUEL_FINALE_MBR $IMAGE_FINALE_MBR # Formatear la imagen final parted -a cylinder $SUPPORT_VIRTUEL_FINALE_MBR \ -s "mklabel msdos" parted $SUPPORT_VIRTUEL_FINALE_MBR \ -s "mkpart primary ext4 1 100%" lsblk -lpf \ --output NAME,TYPE,FSTYPE,SIZE \ $SUPPORT_VIRTUEL_FINALE_MBR \ | grep " part " #> /dev/nbd1p1 part 15G partition_virtuelle_finale_mbr=$( lsblk -lp $SUPPORT_VIRTUEL_FINALE_MBR \ | awk '/ part / { print $1 }' ) mkfs.ext4 -F $partition_virtuelle_finale_mbr #> mke2fs 1.46.2 (28-Feb-2021) #> Rechazo de bloques de dispositivo: completado #> ... #> Superbloques de reserva almacenados en los bloques: #> 32768, 98304, ... #> ... # Detalle de las imágenes lsblk -f \ --output NAME,TYPE,FSTYPE,SIZE,PARTLABEL \ $SUPPORT_VIRTUEL_SOURCE_GPT $SUPPORT_VIRTUEL_FINALE_MBR #> NAME TYPE FSTYPE SIZE PARTLABEL #> nbd0 disk 119,2G #> ├─nbd0p1 part vfat 100M EFI system partition #> ├─nbd0p2 part 16M Microsoft reserved partition #> ├─nbd0p3 part ntfs 69,8G Basic data partition #> ├─nbd0p4 part ntfs 536M #> ├─nbd0p5 part ext4 18,6G DEBIAN #> ├─nbd0p6 part swap 977M #> └─nbd0p7 part ext4 29,3G BACKUP #> nbd1 disk 15G #> └─nbd1p1 part ext4 15G # Sincronizar archivos soporte fuente -> soporte final mkdir -p mnt/{gpt,mbr} mount $PARTITION_ISOLEE_VIRTUELLE_SOURCE_GPT mnt/gpt/ mount $partition_virtuelle_finale_mbr mnt/mbr/ rsync -aP mnt/gpt/ mnt/mbr/ # => aquí la sincronización se realizó en 8 minutos # Referencias a UUID del disco fuente y al archivo SWAP ? # Nota: UUID = Identificador Único Universal uuid_gpt=$( blkid -s UUID -o value \ $PARTITION_ISOLEE_VIRTUELLE_SOURCE_GPT ) uuid_mbr=$( blkid -s UUID -o value $partition_virtuelle_finale_mbr ) uuid_swap=$( awk \ ' BEGIN { FS = "(=| +)" } ; '\ ' /^[^#].+ swap / { print $2 } '\ mnt/mbr/etc/fstab ) grep -rlE "$uuid_gpt|$uuid_swap" mnt/mbr/ \ | grep -Ev "/var/|\.log" #> mnt/mbr/etc/initramfs-tools/conf.d/resume #> mnt/mbr/etc/fstab #> mnt/mbr/boot/grub/x86_64-efi/grub.efi #> mnt/mbr/boot/grub/x86_64-efi/load.cfg #> mnt/mbr/boot/grub/x86_64-efi/core.efi #> mnt/mbr/boot/grub/grub.cfg # => resume (suspensión), fstab (montajes automáticos), GRUB (arranque) # Desactivar el archivo de suspensión sed -i 's/^\( *[^#]\)/# \1/' \ mnt/mbr/etc/initramfs-tools/conf.d/resume # Actualizar el archivo de montajes automáticos fstab_gpt=$( sed -e 's/^\( *[^#]\)/# \1/' mnt/mbr/etc/fstab ) fstab_mbr=$( grep "$uuid_gpt" mnt/mbr/etc/fstab \ | sed "s/$uuid_gpt/$uuid_mbr/g" ) echo -e "$fstab_gpt\n\n# Disco MBR\n$fstab_mbr" \ > mnt/mbr/etc/fstab # Hacer que el soporte MBR sea arrancable grub-install --boot-directory mnt/mbr/boot \ $SUPPORT_VIRTUEL_FINALE_MBR #> Instalación para la plataforma i386-pc. #> Instalación completada, sin errores. # Actualizar el archivo de resoluciones de nombres hosts_avant=$( sed -e 's/^\( *[^#]\)/# \1/' mnt/mbr/etc/hosts ) hostname_mbr=$( cat mnt/mbr/etc/hostname ) echo -e "$hosts_avant\n\n127.0.1.1\t$hostname_mbr" \ > mnt/mbr/etc/hosts # Modificar el sistema final for f in /proc /sys ; do mount -B $f mnt/mbr$f ; done mount --rbind /dev mnt/mbr/dev/ chroot mnt/mbr/ # # Entrada en el entorno chroot # # Desactivar la carga del SWAP al inicio # (ver hilo CCM "Latencia del núcleo al inicio") # update-initramfs -u #> update-initramfs: Generando /boot/initrd.img-6.1.0-23-amd64 # # Actualizar GRUB ... # ... sin los otros dispositivos locales # https://unix.stackexchange.com/questions/634150/hide-devices-in-chrooted-environment/634655#634655 # chmod a-x /usr/bin/os-prober update-grub chmod a+x /usr/bin/os-prober exit # # Salida del entorno chroot # for f in /proc /sys /dev ; do umount -lf mnt/mbr$f ; done # # Al iniciar mi VM, tuve un error: # "unable to allocate pty: No such device" # https://askubuntu.com/questions/1449413/sudo-unable-to-allocate-pty-no-such-device/1503585#1503585 mount none -t devpts /dev/pts # Desmontar y descargar los soportes umount -l mnt/mbr umount -l mnt/gpt rmdir -p mnt/{gpt,mbr} qemu-nbd -d $SUPPORT_VIRTUEL_SOURCE_GPT #> /dev/nbd0 desconectado qemu-nbd -d $SUPPORT_VIRTUEL_FINALE_MBR #> /dev/nbd1 desconectado # Desactivar módulo NBD si no se activó automáticamente rmmod nbd Esperando que esto pueda ser útil para otros :D
Con hermandad,
lnj
Tengo preguntas sobre todas sus respuestas. (Woody Allen)
¡El conocimiento y las ideas pertenecen a todos (noosfera)!
Hola,
Por otro lado, tengo otras preguntas sobre la diferencia entre GPT y MBR.
El modelo GPT resuelve varias limitaciones propias del modelo MBR, como se explica aquí. Por lo tanto, cuando tienes la opción, GPT siempre es una mejor elección. GPT es compatible con Windows >= 7 y todo Linux razonablemente reciente.
El único caso en el que no se puede utilizar GPT (y por lo tanto, en el que se impone MBR) es para sistemas operativos tan antiguos que no soportan GPT (Windows <= XP). Más detalles aquí.
Aunque en mi opinión no es una buena idea, en Linux, puedes usar gdisk de GPT a MBR, como se explica aquí. Asegúrate de redeplegar grub una vez realizada la conversión, como se explica aquí.
Buena suerte
Hola Mamiemando :D
De hecho, si necesito convertir a MBR es porque tengo que hacer un p2v desde una máquina en EFI en un soporte que permite un arranque dual Windows/Debian, siendo Windows el que impone GPT, me parece (en todo caso está así en el estado actual). En particular, necesito virtualizar Debian.
Además, hasta hace poco la virtualización libvirt no gestionaba los instantáneos en GPT y lo necesito (eso ha cambiado desde libvirt v10.1.0 y Virtual Machine Manager v4.1.0, pero en la urgencia no voy a dedicarme a rehacer una instalación por eso).
bajo Linux, puedes utilizar gdisk de GPT a MBR, como se explica aquí. Asegúrate de volver a desplegar grub una vez que se haya realizado la conversión, como se explica aquí.
Ya he probado este método que se ejecuta sin errores PERO obtengo un disco con una única partición que ocupa todo el espacio. Bueno, técnicamente sé que los datos siguen allí, pero no son accesibles, las tablas MBR/EBR han roto su acceso.
Además, el soporte de arranque dual en GPT está particionado en 7 particiones (4 para Windows 10, 1 para Debian, 1 para copias de seguridad locales y la última para el SWAP de Linux) => como MBR limita a 4 particiones principales, gdisk debe saber por sí mismo qué particiones convertir en primarias y cuáles en extendidas. También he leído que algunos sistemas (¿solo Windows?), no pueden arrancar desde una partición extendida.
También
Hola,
Por otro lado, tengo otras preguntas sobre la diferencia entre GPT y MBR.
Una de las preguntas que me hago y a la que no consigo encontrar respuesta es la diferencia a nivel de sistema (por lo tanto, de archivos), ¿qué diferencia una instalación de Debian en una máquina con EFI de una con MBR?
Pienso que si entiendo la diferencia, me evitaría tener que recurrir a boot-repair-disk y, eventualmente, no tener esos efectos secundarios.
[...] es la diferencia a nivel de sistema (es decir, de los archivos), ¿qué es lo que diferencia una instalación de Debian en una máquina con EFI de una con MBR?
No hay ninguna, es a nivel de la tabla de particiones donde se juega, ni a nivel de los sistemas de archivos en sí, ni a nivel de su contenido. Como se explicó anteriormente, esto tendrá un impacto en lo que puedes hacer (por ejemplo, el tamaño máximo de una partición). Para un sistema instalado, verás pequeñas diferencias en los resultados devueltos por herramientas como fdisk o gdisk y en la forma en que se indexan tus dispositivos, pero por lo demás, no verás ninguna.
eso me evitaría tener que usar boot-repair-disk y posiblemente no tener los dichos efectos secundarios.
En cuanto a boot-repair, este solo es útil para instalar o reinstalar grub y se limita a este rol. Por lo tanto, es una consideración independiente de GPT o MBR. No hay efectos secundarios. O grub está bien instalado, o está mal instalado :-)
Hola
es la diferencia a nivel de sistema (por lo tanto de archivos),
Sí, solo hay que decir eso, ya que el sistema de archivos está "debajo" de EFI o de MBR, que están escritos encima o dentro de este sistema de archivos que es una "capa" sobre el hardware antes de la organización en MBR o EFI de los archivos y su localización en discos a través de tablas.
Entre EFI y MBR incluso el tamaño máximo que la organización puede gestionar difiere, por lo que la tabla de localización de EFI difiere de la de MBR.
EFI también se exonera de esta limitación de las 4 particiones principales.
Windows fue creado al principio, basándose en la existencia de la partición principal MBR, (la utiliza a veces para prohibir el acceso a los discos en los que está instalado, pero esa es otra historia, quizás por eso a veces se niega a instalarse; Microsoft podría perder un poco de control sobre sus licencias, y su control es lo que a veces asegura la seguridad prometida).
Nota:
-Windows y Linux no colocan el sistema de arranque en el mismo lugar, uno puede tener los 2 en un solo disco en doble arranque: la herramienta de reparación de arranque de grub actúa en su partición; la herramienta de reparación de arranque de Windows en la suya.
-Parece que grub sabe repararse y permite modificar una línea después para llamar a Windows, lo que es un plus para el gestor para modificar sus instalaciones posteriormente en el disco que ha iniciado el sistema y sin detener el ordenador bajo Linux, más fácilmente.
-El total de 64 bits (desaparición del 32 bits) está relacionado, o se impone EFI cuando está presente.
-obtengo un disco con una única partición,
EFI virtualiza las particiones o los discos, gestiona la totalidad del disco y es capaz de mover particiones e incluso crear varias pequeñas piezas en diferentes lugares. Por lo tanto, se ve todo, es un solo gran espacio para él.
En una VM, es peor, todo es virtual y tratado como un gran espacio entero. [Pensemos en el raid, que es algo similar. Hay lo que se ve, y hay lo físico, y no se ve lo físico].
¡Jaja, gracias :-) pero no tengo mérito, solo leí el código :D
De todos modos, por la ayuda que me brindas a mí y a los demás... ;D
---
Así que avancé bastante y estoy a punto de hacer un retorno sobre mi método.
Logré convertir una partición desde un disco GPT a MBR sin pasar por una herramienta de reparación :D
Sin embargo, sigo teniendo el efecto de borde mencionado anteriormente, es decir, aproximadamente 30 segundos en los que no sucede nada. El cursor blanco parpadea sobre un fondo negro. Justo después vienen todas las escrituras ininterrumpidas antes de llegar a la pantalla de bienvenida (= greeter)
[grito_de_enojo=inicio]Desde hace poco, decidí usar más palabras en francés, no por identidad nacional (me siento terráqueo, simplemente), sino por el fastidio del uso masivo del inglés americano para todo y cualquier cosa ;D[grito_de_enojo=fin]
Así que hice una auditoría sobre la actividad después del arranque (boot) y constaté que lo que toma tiempo es el núcleo (kernel). Pero no sé cómo profundizar más.
$ sudo systemd-analyze plot > analyse.svg
Sin hacer zoom, se ve una larga barra gris en la parte superior de 33s ...
... que está relacionado con el núcleo:
¿Sabrías ayudarme a saber qué sucede durante esos 33s?
Tengo preguntas para todas vuestras respuestas. (Woody Allen)
¡Los conocimientos y las ideas pertenecen a todo el mundo (noosfera)!
Dificil de decir. Además, creo que sería conveniente abrir una nueva discusión ya que se aleja de la pregunta inicial. Intento responder rápidamente, pero si necesitas más elementos, gracias por abrir una nueva discusión.
- Si el núcleo es anormalmente lento (en comparación con lo habitual, en esta máquina), es probable que alguna de sus funcionalidades tenga un problema y termine por abandonar (timeout).
- Intenta ver si los logs (/var/log) revelan algo, en particular /var/log/boot.log o /var/log/kern.log si existen. Los posibles errores permitirán determinar no solo la causa, sino también encontrar cómo las personas que se han enfrentado a este problema lo han resuelto.
- Puede que esto se deba a un bug. A veces, algunas personas encuentran problemas con versiones específicas (ver esta discusión). Probar con otros núcleos (incluso más antiguos) permitiría ver si eso es lo que está ocurriendo aquí.
- Si el problema persiste, sería necesario "perfilar" el núcleo (ver por ejemplo esta discusión). Desafortunadamente, es complicado de implementar, porque sea cual sea el método, se necesita recompilar el núcleo (por lo que en lugar de solo desplegar uno precompilado con un paquete linux-image, sería necesario recompilarlo como se explica aquí).
Buena suerte
De hecho, aunque el problema está completamente relacionado con este hilo, tiene su lugar en un nuevo espacio.
Así que he creado este nuevo hilo: Latencia del núcleo al inicio ... para decir que el problema está resuelto y presentar mi enfoque :D !
Por otro lado, no sé cómo marcarlo como "resuelto" ya que fui yo quien lo resolvió !
Mi método para convertir la partición GPT en MBR seguirá ... en este hilo ;D
¡Gracias mamiemando! Siempre me sorprenderás con tus conocimientos :D !
Sí, así que como sincronizo tal cual el contenido de mi partición GPT en una partición MBR, grub.cfg está dedicado a GPT, al arrancar en MBR el comando se ejecutará y por lo tanto no permitirá el arranque ... sin duda la "razón" por la que el sistema no arranca y me obliga a reparar con una herramienta como boot-repair-disk.
Empieza a aclararse ...
Si el problema se debe únicamente a este comando, me voy a reír mucho de haber perdido todo este tiempo ...
Haré pruebas y daré un regreso :D
¡Jaja, gracias :-) pero no tengo mérito, solo he leído el código :D
En efecto, en tu caso, es necesario redeplegar GRUB. Para ello, ejecuta desde el Linux instalado en tu disco duro :
Si tu Linux no es arrancable, puedes resolverlo con una herramienta boot-repair o un live CD que te permitirá hacer un chroot (para simular que se ha iniciado normalmente), y desde ahí, redeplegar GRUB. Si no estás familiarizado con este tipo de manipulaciones, te recomiendo usar boot-repair que te guiará. Y si no puedes resolverlo, no dudes en pedir más precisiones ;-)
Buena suerte