.png)
Tengo una instalación de proxmox (v5.4, creo) encima de ZFS en un servidor con 6 discos. Hay 2 grupos: rpool en un espejo de dos SSD que tiene el sistema de archivos raíz proxmox y algunos contenedores y zvols. Y los otros 4 discos están en otro grupo (HDD) en raidz-1.
Hace dos meses estuve haciendo un trabajo de optimización en los parámetros de ZFS y lo activé dnodesize = autoen todos los grupos, incluido el grupo rpool y los grupos infantiles. Ahora reinicié el servidor y el siguiente mensaje decía hola:
error: no such device: 40d7d14f38cc...
error: unknown filesystem
Entering rescue mode...
grub rescue>
Con la investigación que he hecho creo que está relacionado con el dnodesizeparámetro (veraquí,aquíyaquí). Citando directamente del primer enlace:
Algún archivo debe haber activado un tamaño de nodo no heredado (512 bytes) en el conjunto de datos, lo que significaba que GRUB ya no podía leer la unidad.
Ahora tengo algunas ideas sobre por dónde empezar pero también muchas dudas (soy un administrador no muy experimentado), así que quería preguntarte a ti primero, antes de llegar a un callejón sin salida y/o romper algo definitivamente.
En primer lugar, podría crear un USB en vivo con un sistema operativo compatible con ZFS. Probablemente la mejor opción sería utilizar el mismo ISO 5.4 proxmox. Una vez allí, ¿podría ser posible cargar y manipular los antiguos grupos de proxmox desde el USB en vivo? ¿Cómo?
El problema es que no es suficiente configurarlo dnodesize = legacyya que los cambios no se aplican retroactivamente. Entonces no sé exactamente cómo proceder aquí. Sin embargo, las opciones que tengo son las siguientes:
- Si hay una manera de detectar qué archivos superan el límite estándar de dnode de 512 bytes. Luego córtelos/muévalos a otra ubicación y péguelos/muévalos nuevamente. El problema aquí, ¿cómo detectar esos archivos?
- Corte todo el contenido del rpool en un disco externo y péguelo nuevamente en el rpool. El problema aquí es que no me siento seguro moviendo el sistema de archivos raíz proxmox hacia adelante y hacia atrás y espero que vuelva a funcionar. ¿Quizás con
cp -a? - Parece que el único contenido que grub debe poder leer es el contenido dentro de /boot. Pero la carpeta /boot está dentro del grupo rpool y los grupos zfs no se pueden reducir. Por lo tanto, no puedo reducir ninguno de los grupos actuales para crear uno nuevo para el arranque y no puedo agregar ningún disco adicional al servidor. La única opción sería mover /boot a un pendrive y decirle a grub que busque allí. Pero no parece una solución muy sólida ni definitiva.
¿Algún consejo?
EDITAR: ¿Qué tal si reemplazamos grub2 por un gestor de arranque más compatible con zfs? De la wiki de proxmox:
systemd-boot es un gestor de arranque EFI ligero. Lee las imágenes del kernel y del initrd directamente desde la partición de servicio EFI (ESP) donde está instalado. La principal ventaja de cargar directamente el kernel desde el ESP es que no es necesario volver a implementar los controladores para acceder al almacenamiento. En el contexto de ZFS como sistema de archivos raíz, esto significa que puede usar todas las funciones opcionales en su grupo raíz en lugar del subconjunto que también está presente en la implementación de ZFS en grub o tener que crear un pequeño grupo de arranque separado.
De hecho parece que:
Proxmox VE actualmente utiliza uno de los dos cargadores de arranque según la configuración del disco seleccionada en el instalador. Para sistemas EFI instalados con ZFS como sistema de archivos raíz, se utiliza systemd-boot. Todas las demás implementaciones utilizan el gestor de arranque grub estándar.
Entonces no sé por qué se instaló con grub en lugar de systemd-boot. ¿Es factible reemplazar el gestor de arranque sin romper nada?
Gracias por tu ayuda.