Re: Partición pierde UUID
El 12/11/2014, a las 16:58, Camaleón noela...@gmail.com escribió: El Wed, 12 Nov 2014 10:27:03 +0100, ZorroPlateado escribió: El 11/11/2014, a las 16:30, Camaleón noela...@gmail.com escribió: (...) Es muy fácil o llevo diciendo desde el principio , el comando blkid /dev/sdc1 no devuelve nada de nada, ni error ni nada… Bien, pero no te fíes de una única herramienta. Si no devuelve nada puede ser por un error en la aplicación/biblioteca o que el caché desde el que hace la lectura esté vacío (con blkid -p /dev/sdc1 evitas esto último). Comprobado sin éxito. Bien, sólo te digo que no des por hecho que no tener uuid (o que lo haya perdido) sea debido a un error del disco duro :-) Lo que aún no has dicho (o se me ha pasado por alto) es el resultado del comando ls -la /dev/disk/by-*”. ls -la /dev/disk/by-id/ total 0 drwxr-xr-x 2 root root 700 nov 1 10:39 . drwxr-xr-x 5 root root 100 nov 1 10:39 .. lrwxrwxrwx 1 root root 9 nov 1 10:39 ata-ST3160021A_5JS42Q20 - ../../sda lrwxrwxrwx 1 root root 10 nov 1 10:42 ata-ST3160021A_5JS42Q20-part1 - ../../sda1 lrwxrwxrwx 1 root root 9 nov 1 10:39 ata-TSST_CD-RW_DVD-ROM_TSH492B - ../../sr0 lrwxrwxrwx 1 root root 9 nov 1 10:39 ata-WDC_WD10EADS-11M2B2_WD-WCAV5C108508 - ../../sdb lrwxrwxrwx 1 root root 10 nov 1 10:39 ata-WDC_WD10EADS-11M2B2_WD-WCAV5C108508-part1 - ../../sdb1 lrwxrwxrwx 1 root root 10 nov 1 10:39 dm-name-discousb-backup_old - ../../dm-9 lrwxrwxrwx 1 root root 11 nov 1 10:39 dm-name-discousb-tools - ../../dm-10 lrwxrwxrwx 1 root root 10 nov 1 10:39 dm-name-virtualbox-camaras - ../../dm-1 lrwxrwxrwx 1 root root 10 nov 1 10:39 dm-name-virtualbox-git - ../../dm-0 lrwxrwxrwx 1 root root 10 nov 1 10:39 dm-name-virtualbox-log - ../../dm-7 lrwxrwxrwx 1 root root 10 nov 1 10:39 dm-name-virtualbox-main - ../../dm-2 lrwxrwxrwx 1 root root 10 nov 1 10:39 dm-name-virtualbox-ntop - ../../dm-4 lrwxrwxrwx 1 root root 10 nov 1 10:39 dm-name-virtualbox-sugarcrm - ../../dm-3 lrwxrwxrwx 1 root root 10 nov 1 10:39 dm-name-virtualbox-usr - ../../dm-6 lrwxrwxrwx 1 root root 10 nov 1 10:39 dm-name-virtualbox-windowsxp - ../../dm-8 lrwxrwxrwx 1 root root 10 nov 1 10:39 dm-name-virtualbox-www - ../../dm-5 lrwxrwxrwx 1 root root 10 nov 1 10:39 dm-uuid-LVM-BHXLasa3SsfnEzpYSWUAFaxDazNE1uSt89QpZu4IxRSG42hcQ0jD6WERMw84SJpy - ../../dm-6 lrwxrwxrwx 1 root root 10 nov 1 10:39 dm-uuid-LVM-BHXLasa3SsfnEzpYSWUAFaxDazNE1uStBbVGRmIA9uEvxVAdHbUyXbDe4ZueY10g - ../../dm-7 lrwxrwxrwx 1 root root 10 nov 1 10:39 dm-uuid-LVM-BHXLasa3SsfnEzpYSWUAFaxDazNE1uStchePkl4Ltwnan4dfzAdtGxrPNTR2jfiM - ../../dm-4 lrwxrwxrwx 1 root root 10 nov 1 10:39 dm-uuid-LVM-BHXLasa3SsfnEzpYSWUAFaxDazNE1uStCXmu4bW11Q1E9Rq5FdNJrppYAct09pf3 - ../../dm-0 lrwxrwxrwx 1 root root 10 nov 1 10:39 dm-uuid-LVM-BHXLasa3SsfnEzpYSWUAFaxDazNE1uStDLgw0t0WoGuORWyPzQ1PaaWv7miDPysu - ../../dm-2 lrwxrwxrwx 1 root root 10 nov 1 10:39 dm-uuid-LVM-BHXLasa3SsfnEzpYSWUAFaxDazNE1uStE9oqcyOZ1G9wQIOTESRoG9uRIEevX43h - ../../dm-8 lrwxrwxrwx 1 root root 10 nov 1 10:39 dm-uuid-LVM-BHXLasa3SsfnEzpYSWUAFaxDazNE1uStENhscr2skRhBjCXB3M5w4vEUZ6lXhVpb - ../../dm-3 lrwxrwxrwx 1 root root 10 nov 1 10:39 dm-uuid-LVM-BHXLasa3SsfnEzpYSWUAFaxDazNE1uStIqdIdEqjKprxhVlbVppBhoe94sL2ktZn - ../../dm-1 lrwxrwxrwx 1 root root 10 nov 1 10:39 dm-uuid-LVM-BHXLasa3SsfnEzpYSWUAFaxDazNE1uStlSAEDqDU51gvQIc1RSpld7Cwn5l41Ujf - ../../dm-5 lrwxrwxrwx 1 root root 10 nov 1 10:39 dm-uuid-LVM-cYGUAtPmsYhR2ouQkpPCSBDTvUA4cSOs8KJWJkV30EjHKyOWPAfdD0lAGpZYWofs - ../../dm-9 lrwxrwxrwx 1 root root 11 nov 1 10:39 dm-uuid-LVM-cYGUAtPmsYhR2ouQkpPCSBDTvUA4cSOstWJnBopGy8A8n1BiyTfUanpkp413Q0qJ - ../../dm-10 lrwxrwxrwx 1 root root 9 nov 1 10:39 scsi-SATA_ST3160021A_5JS42Q20 - ../../sda lrwxrwxrwx 1 root root 10 nov 1 10:42 scsi-SATA_ST3160021A_5JS42Q20-part1 - ../../sda1 lrwxrwxrwx 1 root root 9 nov 1 10:39 scsi-SWD_Ext_HDD_1021_WCAV5C108508 - ../../sdb lrwxrwxrwx 1 root root 10 nov 1 10:39 scsi-SWD_Ext_HDD_1021_WCAV5C108508-part1 - ../../sdb1 lrwxrwxrwx 1 root root 9 nov 1 10:39 wwn-0x50014ee259b15a62 - ../../sdb lrwxrwxrwx 1 root root 10 nov 1 10:39 wwn-0x50014ee259b15a62-part1 - ../../sdb1 con tune2fs -U uuid y un posterior blkid seguimos sin obtener el identificador uuid. Vale, aceptamos pulpo. No hay UUID, se ha ido o simplemente no existe. Puedes: 1/ Asignarle uno nuevo o el mismo que tenía Comprobado en emails anteriores. (...) ¿Comprobado cómo, de qué manera, qué has hecho y con qué resultado? tune2fs -U uuid /dev/sdc1 blkid /dev/sdc1 = Sigue sin devolver nada El comando smart está bien pero cuando tienes una controladora RAID hardware con discos SCSI como que no, lo que hay que usar es el testing propio de la controladora o vía software si es que lo hay. Hay controladoras/drivers RAID que sí admiten los comandos smart, tienes una lista en su web: Checking disks behind RAID controllers
Re: Partición pierde UUID
El Thu, 13 Nov 2014 11:59:21 +0100, ZorroPlateado escribió: El 12/11/2014, a las 16:58, Camaleón noela...@gmail.com escribió: (...) Bien, pero no te fíes de una única herramienta. Si no devuelve nada puede ser por un error en la aplicación/biblioteca o que el caché desde el que hace la lectura esté vacío (con blkid -p /dev/sdc1 evitas esto último). Comprobado sin éxito. Bien, sólo te digo que no des por hecho que no tener uuid (o que lo haya perdido) sea debido a un error del disco duro :-) Lo que aún no has dicho (o se me ha pasado por alto) es el resultado del comando ls -la /dev/disk/by-*”. ls -la /dev/disk/by-id/ (...) No, cuidadín, yo dije ls -la /dev/disk/by-* que es distinto ;-) El resultado que mandas muestra los identificadores (ID) detectados, ninguno para una partición que apunte a /dev/sdc1. Vale, aceptamos pulpo. No hay UUID, se ha ido o simplemente no existe. Puedes: 1/ Asignarle uno nuevo o el mismo que tenía Comprobado en emails anteriores. (...) ¿Comprobado cómo, de qué manera, qué has hecho y con qué resultado? tune2fs -U uuid /dev/sdc1 blkid /dev/sdc1 = Sigue sin devolver nada Supongo que lo habrás puesto uuid como valor porque no es un formato válido, al menos según el manual de tune2fs. Para comprobar si el cambio se ha hecho correctamente, además de blkid (en este caso mejor sería blkid -p /dev/sdc1 por los motivos comentados anteriormente) además esa utilidad puedes usar udevadm info -q all -n /dev/sdc1 | grep uuidudevinfo, hwinfo, etc... Checking disks behind RAID controllers http://www.smartmontools.org/wiki/Supported_RAID-Controllers Las LSI Perc 4 no las soporta. Es raro que no las admita (el driver megaraid_* es uno de los que mejor soporte tiene en el kernel). ¿Has probado el comando de consulta del estado, qué te dice? Ufff la prudencia ante todo con este servidor en producción, si no dice explícitamente soporte de las Perc 4 ni me lo planteo probar. Bueno, no creo que pase nada salvo que en el caso de que no lo soporte, dé un error al ejecutar el comando (o simplemente no devuelva nada) y salga. De todas formas, ¿no tienen esas controladoras algún controlador o aplicación que puedas usar en línea de comandos para monitorizar el estado del SMART? Los fabricantes suelen tener aplicaciones propias que permite consultar el estado de las matrices, realizar operaciones de reconstrucción en caliente o ver el valor de SMART de los discos. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.11.14.16.05...@gmail.com
Re: Partición pierde UUID
El 11/11/2014, a las 16:48, Haylem Candelario Bauzá hay...@inor.sld.cu escribió: El mar, 11-11-2014 a las 09:44 +0100, ZorroPlateado escribió: El 10/11/2014, a las 15:38, Camaleón noela...@gmail.com escribió: El Mon, 10 Nov 2014 10:42:30 +0100, ZorroPlateado escribió: El 7/11/2014, a las 16:28, Camaleón noela...@gmail.com escribió: (...) La partición sigue siendo igualmente /dev/sdc1… por eso no hay problemas y se va a quedar así, pero es una terrible XXX que te deje un sistema de buenas a primeras sin arrancar por la perdida del UUID. (...) Pues entonces no entiendo qué es lo que te ha pasado. Si no existe el identificador UUID en alguna partición, ni el kernel ni GRUB2 te van a impedir usar cualquier otro identificador para iniciar el sistema. Creo que haberme explicado bien.. La partición boot está identificada por el UUID, así lleva muchos años. Ahora se pierde el UUID de dicha partición y tras el arranque del kernel y llega el momento de montaje del resto de particiones como la boot pues va a fallar. ¿Cómo que se pierde el UUID? Es que si no nos dices el resultado del comando que te puse no queda nada claro lo que dices ni a lo que te refieres. Pero aún así, aunque el identificador uuid de la partición de arranque esté en blanco o no exista puedes usar el identificador que prefieras, eso es indiferente. De modo que la única salida es especificar en el fstab la identificación por path y ya que el problema de volver a asignar el mismo UUID a dicha partición no corrige el asunto no puedo hacer nada más. Por ejemplo, o puedes usar ID o label. Lo que tampoco me termina de quedar claro es por qué asignando el uuid a la partición de arranque (el mismo u otro) dices que no corrige el problema. Ahora estos sintomas de disco solo me pueden avisar de que los 10 años ya pesan y que me prepare para un fallo general. Pues no sabría decirte, me parece un diagnóstico arriesgado. El estado de un disco duro lo puedes medio adivinar con la herramienta smart pero el hecho de que pierda el identificador no podría achacarlo exclusivamente a un fallo mecánico del disco duro ya que puede haber otras causas que lo generen (p. ej., el kernel con udev va demasiado rápido y no detecta el identificador de la partición¹). ¹https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#boot-timing Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.11.10.14.38...@gmail.com Es muy fácil o llevo diciendo desde el principio , el comando blkid /dev/sdc1 no devuelve nada de nada, ni error ni nada… con tune2fs -U uuid y un posterior blkid seguimos sin obtener el identificador uuid. Efectivamente el UUID ahora mismo no es un método que pueda seguir usando para identificar la partición boot, y el porqué lo desconozco excepto que el disco tras 10 años está empezando a decir basta. El comando smart está bien pero cuando tienes una controladora RAID hardware con discos SCSI como que no, lo que hay que usar es el testing propio de la controladora o vía software si es que lo hay. probablemente haya algun sistema de encriptación de datos instalado, a mí me pasó algo parecido una vez, los dispositivos en vez de aparecerme como sda1, me aparecían como /dev/UIDcon u número largísimo cuando hacía fdisk -l Haz esto a ver fdisk -l No, no es el caso, comprobado. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1415720882.4748.2.ca...@debian.inor.sld.cu -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/ae207b09-1f07-442c-aaff-f3a46dcfb...@gmail.com
Re: Partición pierde UUID
El 11/11/2014, a las 16:30, Camaleón noela...@gmail.com escribió: El Tue, 11 Nov 2014 09:44:37 +0100, ZorroPlateado escribió: El 10/11/2014, a las 15:38, Camaleón noela...@gmail.com escribió: (...) Ahora estos sintomas de disco solo me pueden avisar de que los 10 años ya pesan y que me prepare para un fallo general. Pues no sabría decirte, me parece un diagnóstico arriesgado. El estado de un disco duro lo puedes medio adivinar con la herramienta smart pero el hecho de que pierda el identificador no podría achacarlo exclusivamente a un fallo mecánico del disco duro ya que puede haber otras causas que lo generen (p. ej., el kernel con udev va demasiado rápido y no detecta el identificador de la partición¹). ¹https://www.debian.org/releases/stable/amd64/release-notes/ch- upgrading.en.html#boot-timing Es muy fácil o llevo diciendo desde el principio , el comando blkid /dev/sdc1 no devuelve nada de nada, ni error ni nada… Bien, pero no te fíes de una única herramienta. Si no devuelve nada puede ser por un error en la aplicación/biblioteca o que el caché desde el que hace la lectura esté vacío (con blkid -p /dev/sdc1 evitas esto último). Comprobado sin éxito. con tune2fs -U uuid y un posterior blkid seguimos sin obtener el identificador uuid. Vale, aceptamos pulpo. No hay UUID, se ha ido o simplemente no existe. Puedes: 1/ Asignarle uno nuevo o el mismo que tenía Comprobado en emails anteriores. 2/ Usar cualquier otro identificador Efectivamente el UUID ahora mismo no es un método que pueda seguir usando para identificar la partición boot, y el porqué lo desconozco excepto que el disco tras 10 años está empezando a decir basta. Pues sigo sin ver el motivo de por qué no puedes usar el mismo ni la relación de la edad del disco con que no haya UUID. El comando smart está bien pero cuando tienes una controladora RAID hardware con discos SCSI como que no, lo que hay que usar es el testing propio de la controladora o vía software si es que lo hay. Hay controladoras/drivers RAID que sí admiten los comandos smart, tienes una lista en su web: Checking disks behind RAID controllers http://www.smartmontools.org/wiki/Supported_RAID-Controllers Las LSI Perc 4 no las soporta. Gracias, como he dicho anteriormente, el problema afecta solo a boot y cambio la referencia por path y paso del UUID. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.11.11.15.30...@gmail.com -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/c3fc278d-411f-42cf-9574-9bce07c37...@gmail.com
Re: Partición pierde UUID
El Wed, 12 Nov 2014 10:27:03 +0100, ZorroPlateado escribió: El 11/11/2014, a las 16:30, Camaleón noela...@gmail.com escribió: (...) Es muy fácil o llevo diciendo desde el principio , el comando blkid /dev/sdc1 no devuelve nada de nada, ni error ni nada… Bien, pero no te fíes de una única herramienta. Si no devuelve nada puede ser por un error en la aplicación/biblioteca o que el caché desde el que hace la lectura esté vacío (con blkid -p /dev/sdc1 evitas esto último). Comprobado sin éxito. Bien, sólo te digo que no des por hecho que no tener uuid (o que lo haya perdido) sea debido a un error del disco duro :-) Lo que aún no has dicho (o se me ha pasado por alto) es el resultado del comando ls -la /dev/disk/by-*. con tune2fs -U uuid y un posterior blkid seguimos sin obtener el identificador uuid. Vale, aceptamos pulpo. No hay UUID, se ha ido o simplemente no existe. Puedes: 1/ Asignarle uno nuevo o el mismo que tenía Comprobado en emails anteriores. (...) ¿Comprobado cómo, de qué manera, qué has hecho y con qué resultado? El comando smart está bien pero cuando tienes una controladora RAID hardware con discos SCSI como que no, lo que hay que usar es el testing propio de la controladora o vía software si es que lo hay. Hay controladoras/drivers RAID que sí admiten los comandos smart, tienes una lista en su web: Checking disks behind RAID controllers http://www.smartmontools.org/wiki/Supported_RAID-Controllers Las LSI Perc 4 no las soporta. Es raro que no las admita (el driver megaraid_* es uno de los que mejor soporte tiene en el kernel). ¿Has probado el comando de consulta del estado, qué te dice? Gracias, como he dicho anteriormente, el problema afecta solo a boot y cambio la referencia por path y paso del UUID. Sí, sí, eso ha quedado claro. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.11.12.15.58...@gmail.com
Re: Partición pierde UUID
El 10/11/2014, a las 15:38, Camaleón noela...@gmail.com escribió: El Mon, 10 Nov 2014 10:42:30 +0100, ZorroPlateado escribió: El 7/11/2014, a las 16:28, Camaleón noela...@gmail.com escribió: (...) La partición sigue siendo igualmente /dev/sdc1… por eso no hay problemas y se va a quedar así, pero es una terrible XXX que te deje un sistema de buenas a primeras sin arrancar por la perdida del UUID. (...) Pues entonces no entiendo qué es lo que te ha pasado. Si no existe el identificador UUID en alguna partición, ni el kernel ni GRUB2 te van a impedir usar cualquier otro identificador para iniciar el sistema. Creo que haberme explicado bien.. La partición boot está identificada por el UUID, así lleva muchos años. Ahora se pierde el UUID de dicha partición y tras el arranque del kernel y llega el momento de montaje del resto de particiones como la boot pues va a fallar. ¿Cómo que se pierde el UUID? Es que si no nos dices el resultado del comando que te puse no queda nada claro lo que dices ni a lo que te refieres. Pero aún así, aunque el identificador uuid de la partición de arranque esté en blanco o no exista puedes usar el identificador que prefieras, eso es indiferente. De modo que la única salida es especificar en el fstab la identificación por path y ya que el problema de volver a asignar el mismo UUID a dicha partición no corrige el asunto no puedo hacer nada más. Por ejemplo, o puedes usar ID o label. Lo que tampoco me termina de quedar claro es por qué asignando el uuid a la partición de arranque (el mismo u otro) dices que no corrige el problema. Ahora estos sintomas de disco solo me pueden avisar de que los 10 años ya pesan y que me prepare para un fallo general. Pues no sabría decirte, me parece un diagnóstico arriesgado. El estado de un disco duro lo puedes medio adivinar con la herramienta smart pero el hecho de que pierda el identificador no podría achacarlo exclusivamente a un fallo mecánico del disco duro ya que puede haber otras causas que lo generen (p. ej., el kernel con udev va demasiado rápido y no detecta el identificador de la partición¹). ¹https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#boot-timing Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.11.10.14.38...@gmail.com Es muy fácil o llevo diciendo desde el principio , el comando blkid /dev/sdc1 no devuelve nada de nada, ni error ni nada… con tune2fs -U uuid y un posterior blkid seguimos sin obtener el identificador uuid. Efectivamente el UUID ahora mismo no es un método que pueda seguir usando para identificar la partición boot, y el porqué lo desconozco excepto que el disco tras 10 años está empezando a decir basta. El comando smart está bien pero cuando tienes una controladora RAID hardware con discos SCSI como que no, lo que hay que usar es el testing propio de la controladora o vía software si es que lo hay. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e2cbef9f-960e-4f64-afc5-c4220e0a9...@gmail.com
Re: Partición pierde UUID
El Tue, 11 Nov 2014 09:44:37 +0100, ZorroPlateado escribió: El 10/11/2014, a las 15:38, Camaleón noela...@gmail.com escribió: (...) Ahora estos sintomas de disco solo me pueden avisar de que los 10 años ya pesan y que me prepare para un fallo general. Pues no sabría decirte, me parece un diagnóstico arriesgado. El estado de un disco duro lo puedes medio adivinar con la herramienta smart pero el hecho de que pierda el identificador no podría achacarlo exclusivamente a un fallo mecánico del disco duro ya que puede haber otras causas que lo generen (p. ej., el kernel con udev va demasiado rápido y no detecta el identificador de la partición¹). ¹https://www.debian.org/releases/stable/amd64/release-notes/ch- upgrading.en.html#boot-timing Es muy fácil o llevo diciendo desde el principio , el comando blkid /dev/sdc1 no devuelve nada de nada, ni error ni nada… Bien, pero no te fíes de una única herramienta. Si no devuelve nada puede ser por un error en la aplicación/biblioteca o que el caché desde el que hace la lectura esté vacío (con blkid -p /dev/sdc1 evitas esto último). con tune2fs -U uuid y un posterior blkid seguimos sin obtener el identificador uuid. Vale, aceptamos pulpo. No hay UUID, se ha ido o simplemente no existe. Puedes: 1/ Asignarle uno nuevo o el mismo que tenía 2/ Usar cualquier otro identificador Efectivamente el UUID ahora mismo no es un método que pueda seguir usando para identificar la partición boot, y el porqué lo desconozco excepto que el disco tras 10 años está empezando a decir basta. Pues sigo sin ver el motivo de por qué no puedes usar el mismo ni la relación de la edad del disco con que no haya UUID. El comando smart está bien pero cuando tienes una controladora RAID hardware con discos SCSI como que no, lo que hay que usar es el testing propio de la controladora o vía software si es que lo hay. Hay controladoras/drivers RAID que sí admiten los comandos smart, tienes una lista en su web: Checking disks behind RAID controllers http://www.smartmontools.org/wiki/Supported_RAID-Controllers Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.11.11.15.30...@gmail.com
Re: Partición pierde UUID
El mar, 11-11-2014 a las 09:44 +0100, ZorroPlateado escribió: El 10/11/2014, a las 15:38, Camaleón noela...@gmail.com escribió: El Mon, 10 Nov 2014 10:42:30 +0100, ZorroPlateado escribió: El 7/11/2014, a las 16:28, Camaleón noela...@gmail.com escribió: (...) La partición sigue siendo igualmente /dev/sdc1… por eso no hay problemas y se va a quedar así, pero es una terrible XXX que te deje un sistema de buenas a primeras sin arrancar por la perdida del UUID. (...) Pues entonces no entiendo qué es lo que te ha pasado. Si no existe el identificador UUID en alguna partición, ni el kernel ni GRUB2 te van a impedir usar cualquier otro identificador para iniciar el sistema. Creo que haberme explicado bien.. La partición boot está identificada por el UUID, así lleva muchos años. Ahora se pierde el UUID de dicha partición y tras el arranque del kernel y llega el momento de montaje del resto de particiones como la boot pues va a fallar. ¿Cómo que se pierde el UUID? Es que si no nos dices el resultado del comando que te puse no queda nada claro lo que dices ni a lo que te refieres. Pero aún así, aunque el identificador uuid de la partición de arranque esté en blanco o no exista puedes usar el identificador que prefieras, eso es indiferente. De modo que la única salida es especificar en el fstab la identificación por path y ya que el problema de volver a asignar el mismo UUID a dicha partición no corrige el asunto no puedo hacer nada más. Por ejemplo, o puedes usar ID o label. Lo que tampoco me termina de quedar claro es por qué asignando el uuid a la partición de arranque (el mismo u otro) dices que no corrige el problema. Ahora estos sintomas de disco solo me pueden avisar de que los 10 años ya pesan y que me prepare para un fallo general. Pues no sabría decirte, me parece un diagnóstico arriesgado. El estado de un disco duro lo puedes medio adivinar con la herramienta smart pero el hecho de que pierda el identificador no podría achacarlo exclusivamente a un fallo mecánico del disco duro ya que puede haber otras causas que lo generen (p. ej., el kernel con udev va demasiado rápido y no detecta el identificador de la partición¹). ¹https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#boot-timing Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.11.10.14.38...@gmail.com Es muy fácil o llevo diciendo desde el principio , el comando blkid /dev/sdc1 no devuelve nada de nada, ni error ni nada… con tune2fs -U uuid y un posterior blkid seguimos sin obtener el identificador uuid. Efectivamente el UUID ahora mismo no es un método que pueda seguir usando para identificar la partición boot, y el porqué lo desconozco excepto que el disco tras 10 años está empezando a decir basta. El comando smart está bien pero cuando tienes una controladora RAID hardware con discos SCSI como que no, lo que hay que usar es el testing propio de la controladora o vía software si es que lo hay. probablemente haya algun sistema de encriptación de datos instalado, a mí me pasó algo parecido una vez, los dispositivos en vez de aparecerme como sda1, me aparecían como /dev/UIDcon u número largísimo cuando hacía fdisk -l Haz esto a ver fdisk -l -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1415720882.4748.2.ca...@debian.inor.sld.cu
Re: Partición pierde UUID
El 7/11/2014, a las 16:28, Camaleón noela...@gmail.com escribió: El Fri, 07 Nov 2014 12:01:12 +0100, ZorroPlateado escribió: El 6/11/2014, a las 15:29, Camaleón noela...@gmail.com escribió: (...) En el momento de crear un sistema de ficheros se le asigna el UUID, no se crea al vuelo en el arranque por udev, el comando blkid para la particion boot no devuelve nada por el motivo que sea cuando se ha tirado años sin problemas. No todas las particiones tienen un identificador específico asignado (que no tiene por qué ser el UUID, también te sirven LABEL, PATH y el ID) por lo que eso es irrelevante: usa el que tengas. Lo que te quería decir es que el directorio /dev lo genera el kernel al vuelo a través de las reglas udev, ya no es una ruta estática. Lo único que te interesa saber a efectos de que GRUB cargue el sistema y pueda iniciarlo es cómo detecta el kernel la partición que antes era /dev/sdc1 y ahora puede ser cualquier otra y tener un identificador x”. La partición sigue siendo igualmente /dev/sdc1… por eso no hay problemas y se va a quedar así, pero es una terrible XXX que te deje un sistema de buenas a primeras sin arrancar por la perdida del UUID. (...) Pues entonces no entiendo qué es lo que te ha pasado. Si no existe el identificador UUID en alguna partición, ni el kernel ni GRUB2 te van a impedir usar cualquier otro identificador para iniciar el sistema. Saludos, Creo que haberme explicado bien.. La partición boot está identificada por el UUID, así lleva muchos años. Ahora se pierde el UUID de dicha partición y tras el arranque del kernel y llega el momento de montaje del resto de particiones como la boot pues va a fallar. De modo que la única salida es especificar en el fstab la identificación por path y ya que el problema de volver a asignar el mismo UUID a dicha partición no corrige el asunto no puedo hacer nada más. Ahora estos sintomas de disco solo me pueden avisar de que los 10 años ya pesan y que me prepare para un fallo general. -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.11.07.15.28...@gmail.com -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/ecbaa232-3639-446a-a610-a0a4224a7...@gmail.com
Re: Partición pierde UUID
El Mon, 10 Nov 2014 10:42:30 +0100, ZorroPlateado escribió: El 7/11/2014, a las 16:28, Camaleón noela...@gmail.com escribió: (...) La partición sigue siendo igualmente /dev/sdc1… por eso no hay problemas y se va a quedar así, pero es una terrible XXX que te deje un sistema de buenas a primeras sin arrancar por la perdida del UUID. (...) Pues entonces no entiendo qué es lo que te ha pasado. Si no existe el identificador UUID en alguna partición, ni el kernel ni GRUB2 te van a impedir usar cualquier otro identificador para iniciar el sistema. Creo que haberme explicado bien.. La partición boot está identificada por el UUID, así lleva muchos años. Ahora se pierde el UUID de dicha partición y tras el arranque del kernel y llega el momento de montaje del resto de particiones como la boot pues va a fallar. ¿Cómo que se pierde el UUID? Es que si no nos dices el resultado del comando que te puse no queda nada claro lo que dices ni a lo que te refieres. Pero aún así, aunque el identificador uuid de la partición de arranque esté en blanco o no exista puedes usar el identificador que prefieras, eso es indiferente. De modo que la única salida es especificar en el fstab la identificación por path y ya que el problema de volver a asignar el mismo UUID a dicha partición no corrige el asunto no puedo hacer nada más. Por ejemplo, o puedes usar ID o label. Lo que tampoco me termina de quedar claro es por qué asignando el uuid a la partición de arranque (el mismo u otro) dices que no corrige el problema. Ahora estos sintomas de disco solo me pueden avisar de que los 10 años ya pesan y que me prepare para un fallo general. Pues no sabría decirte, me parece un diagnóstico arriesgado. El estado de un disco duro lo puedes medio adivinar con la herramienta smart pero el hecho de que pierda el identificador no podría achacarlo exclusivamente a un fallo mecánico del disco duro ya que puede haber otras causas que lo generen (p. ej., el kernel con udev va demasiado rápido y no detecta el identificador de la partición¹). ¹https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#boot-timing Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.11.10.14.38...@gmail.com
Re: Partición pierde UUID
El 6/11/2014, a las 15:29, Camaleón noela...@gmail.com escribió: El Thu, 06 Nov 2014 10:38:38 +0100, ZorroPlateado escribió: El 5/11/2014, a las 16:09, Camaleón noela...@gmail.com escribió: (...) Pero ya sabes que los kernels más recientes recomiendan el uso de la nueva nomenclatura (id/uuid/label/path) de lo contrario te arriesgas a que la partición cambie en cada reinicio. Claro, pero si te falla el UUID porque ni puedes extraer el asignado con blkid ni mantiene asignando con tune2fs ya me dirás tengo que volver al sistema antiguo /dev/sda1. Eso o crear una nueva partición boot que veo imposible ya que hace 10 años se planificó de una manera y ahora es imposible cambiar. (...) No se sigo. El identificador lo crea el kernel (udev más bien) al vuelo al iniciar el sistema y lo puedes consultar con un simple cat. ¿Qué es lo que te devuelve? Ya sabes que puedes iniciar el sistema manualmente desde el propio GRUB2 siempre y cuando cargues lo módulos que necesites y que sepas cuál es la partición raíz (a efectos prácticos es indiferente que sea /dev/sda1 o que sea UUID=). En el momento de crear un sistema de ficheros se le asigna el UUID, no se crea al vuelo en el arranque por udev, el comando blkid para la particion boot no devuelve nada por el motivo que sea cuando se ha tirado años sin problemas. No todas las particiones tienen un identificador específico asignado (que no tiene por qué ser el UUID, también te sirven LABEL, PATH y el ID) por lo que eso es irrelevante: usa el que tengas. Lo que te quería decir es que el directorio /dev lo genera el kernel al vuelo a través de las reglas udev, ya no es una ruta estática. Lo único que te interesa saber a efectos de que GRUB cargue el sistema y pueda iniciarlo es cómo detecta el kernel la partición que antes era /dev/sdc1 y ahora puede ser cualquier otra y tener un identificador x”. La partición sigue siendo igualmente /dev/sdc1… por eso no hay problemas y se va a quedar así, pero es una terrible XXX que te deje un sistema de buenas a primeras sin arrancar por la perdida del UUID. En otro servidor ha sido muy importante el uso por defecto de UUID que traen todas las distros porque al averiarse la controladora de disco podemos cambiar el disco a otro servidor y arrancamos con mínimos ajustes. Y en el caso de que jueggues por ejemplo con 6 discos haciendo RAID con mdadme es estupendo el poder identificar los discos por UUID independientemente de lo que detecte el kernel y del slot al que conectes. Gracias a todos. Con tune2fs podría volver a asignar el mismo UUID que tenía antes, pero se ve que sigo sin poder extraer ninguna UUID de esa partición con lo que me deja en la situación de seguir con la nomenclatura antigua /dev/sdc1. Hay vida más allá del UUID, usa cualquier otra etiqueta y carga la partición :-) La persona que tengo a 300 km ha conseguido arrancar el sistema a pesar del problema de montaje y después he podido recolectar toda esta información. Desde una LiveCD o desde el entorno de mantenimiento se tiene acceso a esos datos. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.11.06.14.29...@gmail.com -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2bbca32f-7623-4f42-a7d6-b7a47d1b0...@gmail.com
Re: Partición pierde UUID
El Fri, 07 Nov 2014 12:01:12 +0100, ZorroPlateado escribió: El 6/11/2014, a las 15:29, Camaleón noela...@gmail.com escribió: (...) En el momento de crear un sistema de ficheros se le asigna el UUID, no se crea al vuelo en el arranque por udev, el comando blkid para la particion boot no devuelve nada por el motivo que sea cuando se ha tirado años sin problemas. No todas las particiones tienen un identificador específico asignado (que no tiene por qué ser el UUID, también te sirven LABEL, PATH y el ID) por lo que eso es irrelevante: usa el que tengas. Lo que te quería decir es que el directorio /dev lo genera el kernel al vuelo a través de las reglas udev, ya no es una ruta estática. Lo único que te interesa saber a efectos de que GRUB cargue el sistema y pueda iniciarlo es cómo detecta el kernel la partición que antes era /dev/sdc1 y ahora puede ser cualquier otra y tener un identificador x”. La partición sigue siendo igualmente /dev/sdc1… por eso no hay problemas y se va a quedar así, pero es una terrible XXX que te deje un sistema de buenas a primeras sin arrancar por la perdida del UUID. (...) Pues entonces no entiendo qué es lo que te ha pasado. Si no existe el identificador UUID en alguna partición, ni el kernel ni GRUB2 te van a impedir usar cualquier otro identificador para iniciar el sistema. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.11.07.15.28...@gmail.com
Re: Partición pierde UUID
El 5/11/2014, a las 16:09, Camaleón noela...@gmail.com escribió: El Wed, 05 Nov 2014 09:50:12 +0100, ZorroPlateado escribió: El 4/11/2014, a las 16:52, Camaleón noela...@gmail.com escribió: El Tue, 04 Nov 2014 10:20:53 +0100, ZorroPlateado escribió: Tras la última actualización en Debian estable y en un servidor que comenzó hace 10 años, la partición asociada a boot /dev/sdc1 no ha variado y hasta ahora no ha presentado este problema. Pero ya sabes que los kernels más recientes recomiendan el uso de la nueva nomenclatura (id/uuid/label/path) de lo contrario te arriesgas a que la partición cambie en cada reinicio. Claro, pero si te falla el UUID porque ni puedes extraer el asignado con blkid ni mantiene asignando con tune2fs ya me dirás tengo que volver al sistema antiguo /dev/sda1. Eso o crear una nueva partición boot que veo imposible ya que hace 10 años se planificó de una manera y ahora es imposible cambiar. (...) No se sigo. El identificador lo crea el kernel (udev más bien) al vuelo al iniciar el sistema y lo puedes consultar con un simple cat. ¿Qué es lo que te devuelve? Ya sabes que puedes iniciar el sistema manualmente desde el propio GRUB2 siempre y cuando cargues lo módulos que necesites y que sepas cuál es la partición raíz (a efectos prácticos es indiferente que sea /dev/sda1 o que sea UUID=). Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.11.05.15.09...@gmail.com En el momento de crear un sistema de ficheros se le asigna el UUID, no se crea al vuelo en el arranque por udev, el comando blkid para la particion boot no devuelve nada por el motivo que sea cuando se ha tirado años sin problemas. Con tune2fs podría volver a asignar el mismo UUID que tenía antes, pero se ve que sigo sin poder extraer ninguna UUID de esa partición con lo que me deja en la situación de seguir con la nomenclatura antigua /dev/sdc1. La persona que tengo a 300 km ha conseguido arrancar el sistema a pesar del problema de montaje y después he podido recolectar toda esta información. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1a904446-bd31-48dd-98ed-ed671a67a...@gmail.com
Re: Partición pierde UUID
El Thu, 06 Nov 2014 10:38:38 +0100, ZorroPlateado escribió: El 5/11/2014, a las 16:09, Camaleón noela...@gmail.com escribió: (...) Pero ya sabes que los kernels más recientes recomiendan el uso de la nueva nomenclatura (id/uuid/label/path) de lo contrario te arriesgas a que la partición cambie en cada reinicio. Claro, pero si te falla el UUID porque ni puedes extraer el asignado con blkid ni mantiene asignando con tune2fs ya me dirás tengo que volver al sistema antiguo /dev/sda1. Eso o crear una nueva partición boot que veo imposible ya que hace 10 años se planificó de una manera y ahora es imposible cambiar. (...) No se sigo. El identificador lo crea el kernel (udev más bien) al vuelo al iniciar el sistema y lo puedes consultar con un simple cat. ¿Qué es lo que te devuelve? Ya sabes que puedes iniciar el sistema manualmente desde el propio GRUB2 siempre y cuando cargues lo módulos que necesites y que sepas cuál es la partición raíz (a efectos prácticos es indiferente que sea /dev/sda1 o que sea UUID=). En el momento de crear un sistema de ficheros se le asigna el UUID, no se crea al vuelo en el arranque por udev, el comando blkid para la particion boot no devuelve nada por el motivo que sea cuando se ha tirado años sin problemas. No todas las particiones tienen un identificador específico asignado (que no tiene por qué ser el UUID, también te sirven LABEL, PATH y el ID) por lo que eso es irrelevante: usa el que tengas. Lo que te quería decir es que el directorio /dev lo genera el kernel al vuelo a través de las reglas udev, ya no es una ruta estática. Lo único que te interesa saber a efectos de que GRUB cargue el sistema y pueda iniciarlo es cómo detecta el kernel la partición que antes era /dev/sdc1 y ahora puede ser cualquier otra y tener un identificador x. Con tune2fs podría volver a asignar el mismo UUID que tenía antes, pero se ve que sigo sin poder extraer ninguna UUID de esa partición con lo que me deja en la situación de seguir con la nomenclatura antigua /dev/sdc1. Hay vida más allá del UUID, usa cualquier otra etiqueta y carga la partición :-) La persona que tengo a 300 km ha conseguido arrancar el sistema a pesar del problema de montaje y después he podido recolectar toda esta información. Desde una LiveCD o desde el entorno de mantenimiento se tiene acceso a esos datos. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.11.06.14.29...@gmail.com
Re: Partición pierde UUID
El 4/11/2014, a las 16:52, Camaleón noela...@gmail.com escribió: El Tue, 04 Nov 2014 10:20:53 +0100, ZorroPlateado escribió: Tras la última actualización en Debian estable y en un servidor que comenzó hace 10 años, la partición asociada a boot /dev/sdc1 no ha variado y hasta ahora no ha presentado este problema. Pero ya sabes que los kernels más recientes recomiendan el uso de la nueva nomenclatura (id/uuid/label/path) de lo contrario te arriesgas a que la partición cambie en cada reinicio. Claro, pero si te falla el UUID porque ni puedes extraer el asignado con blkid ni mantiene asignando con tune2fs ya me dirás tengo que volver al sistema antiguo /dev/sda1. Eso o crear una nueva partición boot que veo imposible ya que hace 10 años se planificó de una manera y ahora es imposible cambiar. El caso es que al reinicio del servidor tras actualizar kernel y demás paquetes el sistema no arranca porque busca la partición en base a UUID, una vez arrancamos con CTRL+D intentamos extraer el id con el comando blkid sin éxito, incluso intento asignarse el mismo id con el comando tune2fs -U pero sin éxito por que de nuevo blkid no devuelve valor alguno. Ojo, que el UUID no es lo mismo que el ID, son identificadores distintos. Podrás ver todos los identificadores disponibles ejecutando: ls -la /dev/disk/by-* Estoy al tanto de la diferencia. Sospecho que tras 10 años los discos (en RAID5 por hardware) van a empezar a dar problema alguno. ¿Alguien tiene idea o ha pasado por la misma situación? Si es un RAID5 por hardware es transparente para el kernel, lo único que habrá podido pasar es que al reiniciar se haya traspapelado la partición. Eso sí, asegúrate que el error que te da al iniciar sea efectivamente un problema de identificación de la partición y no otro (módulo del kernel no cargado/encontrado, etc...) Saludos, Gracias,, se que el RAID hardware es independiente para el sistema, pero el origen de todo es que estaba hace referencia a boot por el UUID así como grub, pero desde esa ultima actualización y reinicio no se puede extraer dicho UUID de la partición boot. -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.11.04.15.52...@gmail.com -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/eb7d91ae-19f0-4c5e-9936-65316ed51...@gmail.com
Re: Partición pierde UUID
El Wed, 05 Nov 2014 09:50:12 +0100, ZorroPlateado escribió: El 4/11/2014, a las 16:52, Camaleón noela...@gmail.com escribió: El Tue, 04 Nov 2014 10:20:53 +0100, ZorroPlateado escribió: Tras la última actualización en Debian estable y en un servidor que comenzó hace 10 años, la partición asociada a boot /dev/sdc1 no ha variado y hasta ahora no ha presentado este problema. Pero ya sabes que los kernels más recientes recomiendan el uso de la nueva nomenclatura (id/uuid/label/path) de lo contrario te arriesgas a que la partición cambie en cada reinicio. Claro, pero si te falla el UUID porque ni puedes extraer el asignado con blkid ni mantiene asignando con tune2fs ya me dirás tengo que volver al sistema antiguo /dev/sda1. Eso o crear una nueva partición boot que veo imposible ya que hace 10 años se planificó de una manera y ahora es imposible cambiar. (...) No se sigo. El identificador lo crea el kernel (udev más bien) al vuelo al iniciar el sistema y lo puedes consultar con un simple cat. ¿Qué es lo que te devuelve? Ya sabes que puedes iniciar el sistema manualmente desde el propio GRUB2 siempre y cuando cargues lo módulos que necesites y que sepas cuál es la partición raíz (a efectos prácticos es indiferente que sea /dev/sda1 o que sea UUID=). Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.11.05.15.09...@gmail.com
Re: Partición pierde UUID
El miércoles, 5 nov 2014 a las 16:09 horas (UTC+1), Camaleón escribió: El Wed, 05 Nov 2014 09:50:12 +0100, ZorroPlateado escribió: El 4/11/2014, a las 16:52, Camaleón noela...@gmail.com escribió: El Tue, 04 Nov 2014 10:20:53 +0100, ZorroPlateado escribió: Tras la última actualización en Debian estable y en un servidor que comenzó hace 10 años, la partición asociada a boot /dev/sdc1 no ha variado y hasta ahora no ha presentado este problema. Pero ya sabes que los kernels más recientes recomiendan el uso de la nueva nomenclatura (id/uuid/label/path) de lo contrario te arriesgas a que la partición cambie en cada reinicio. Claro, pero si te falla el UUID porque ni puedes extraer el asignado con blkid ni mantiene asignando con tune2fs ya me dirás tengo que volver al sistema antiguo /dev/sda1. Eso o crear una nueva partición boot que veo imposible ya que hace 10 años se planificó de una manera y ahora es imposible cambiar. (...) No se sigo. El identificador lo crea el kernel (udev más bien) al vuelo al iniciar el sistema y lo puedes consultar con un simple cat. ¿Qué es lo que te devuelve? Ya sabes que puedes iniciar el sistema manualmente desde el propio GRUB2 siempre y cuando cargues lo módulos que necesites y que sepas cuál es la partición raíz (a efectos prácticos es indiferente que sea /dev/sda1 o que sea UUID=). Saludos, También yo estoy perdido: crear UUID al vuelo... UUID de la partición. Yo diría que el UUID pertenece al sistema de fichero, y dumpe2fs y mke2fs parecen opinar igual: # dumpe2fs -h /dev/sda1 | grep UUID dumpe2fs 1.42.12 (29-Aug-2014) Filesystem UUID: 228cd128-781d-410e-a191-01567dc8470a Supongo que habrás chequeado dicho sistema de ficheros. Por otro lado, ¿quién te dices que tengas que modificar el particionado del disco duro? Puedes usar otro disco para la nueva (y temporal) partición /boot. Eso sí, /dev/sda podría pasar a ser /dev/sdb. Saludos. -- Manolo Díaz -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141105175915.08fdd...@gmail.com
Re: Partición pierde UUID
On Tue, Nov 04, 2014 at 10:20:53AM +0100, ZorroPlateado wrote: Tras la última actualización en Debian estable y en un servidor que comenzó hace 10 años, la partición asociada a boot /dev/sdc1 no ha variado y hasta ahora no ha presentado este problema. El caso es que al reinicio del servidor tras actualizar kernel y demás paquetes el sistema no arranca porque busca la partición en base a UUID, una vez arrancamos con CTRL+D intentamos extraer el id con el comando blkid sin éxito, incluso intento asignarse el mismo id con el comando tune2fs -U pero sin éxito por que de nuevo blkid no devuelve valor alguno. Sospecho que tras 10 años los discos (en RAID5 por hardware) van a empezar a dar problema alguno. ¿Alguien tiene idea o ha pasado por la misma situación? Parece que algo se te ha estropeado en la partición /dev/sdc1, pero eso no te debería impedir sustituir la partición por otra. Lo que yo haría es: * Crear una nueva partición ext4 que será la nueva partición /boot. * Copiar el contenido de la antigua en la nueva con rsync. * Hacer los cambios en /etc/fstab que sean pertinentes. * Con un disco de rescate o usando GRUB en modo interactivo, arrancar con la nueva partición /boot. * Desde el sistema nuevo, reinstalar GRUB para que la partición de inicio sea la nueva. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141104094844.ga25...@cantor.unex.es
Re: Partición pierde UUID
El Tue, 04 Nov 2014 10:20:53 +0100, ZorroPlateado escribió: Tras la última actualización en Debian estable y en un servidor que comenzó hace 10 años, la partición asociada a boot /dev/sdc1 no ha variado y hasta ahora no ha presentado este problema. Pero ya sabes que los kernels más recientes recomiendan el uso de la nueva nomenclatura (id/uuid/label/path) de lo contrario te arriesgas a que la partición cambie en cada reinicio. El caso es que al reinicio del servidor tras actualizar kernel y demás paquetes el sistema no arranca porque busca la partición en base a UUID, una vez arrancamos con CTRL+D intentamos extraer el id con el comando blkid sin éxito, incluso intento asignarse el mismo id con el comando tune2fs -U pero sin éxito por que de nuevo blkid no devuelve valor alguno. Ojo, que el UUID no es lo mismo que el ID, son identificadores distintos. Podrás ver todos los identificadores disponibles ejecutando: ls -la /dev/disk/by-* Sospecho que tras 10 años los discos (en RAID5 por hardware) van a empezar a dar problema alguno. ¿Alguien tiene idea o ha pasado por la misma situación? Si es un RAID5 por hardware es transparente para el kernel, lo único que habrá podido pasar es que al reiniciar se haya traspapelado la partición. Eso sí, asegúrate que el error que te da al iniciar sea efectivamente un problema de identificación de la partición y no otro (módulo del kernel no cargado/encontrado, etc...) Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.11.04.15.52...@gmail.com
Re: Partición pierde UUID
El martes, 4 nov 2014 a las 16:52 horas (UTC+1),
Camaleón escribió:
Pero ya sabes que los kernels más recientes recomiendan el uso de la
nueva nomenclatura (id/uuid/label/path) de lo contrario te arriesgas a
que la partición cambie en cada reinicio.
¿De dónde sacas esa recomendación?, porque la página man de mount dice
otra cosa:
The recommended setup is to use tags (e.g. LABEL=label) rather
than /dev/disk/by-{label,uuid,partuuid,partlabel} udev symlinks in
the /etc/fstab file. Tags are more readable, robust and portable. The
mount(8) command internally uses udev symlinks, so the use of symlinks
in /etc/fstab has no advantage over tags. For more details see
libblkid(3).
Saludos.
--
Manolo Díaz
--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141104174130.12bad...@gmail.com
Re: Partición pierde UUID
El Tue, 04 Nov 2014 17:41:30 +0100, Manolo Díaz escribió:
El martes, 4 nov 2014 a las 16:52 horas (UTC+1),
Camaleón escribió:
Pero ya sabes que los kernels más recientes recomiendan el uso de la
nueva nomenclatura (id/uuid/label/path) de lo contrario te arriesgas a
que la partición cambie en cada reinicio.
¿De dónde sacas esa recomendación?,
Pues del mismo sitio que tú ;-)
porque la página man de mount dice otra cosa:
The recommended setup is to use tags (e.g. LABEL=label) rather than
/dev/disk/by-{label,uuid,partuuid,partlabel} udev symlinks in the
/etc/fstab file. Tags are more readable, robust and portable. The
mount(8) command internally uses udev symlinks, so the use of symlinks
in /etc/fstab has no advantage over tags. For more details see
libblkid(3).
¿Y exactamente donde ves tú la contradicción?
Saludos,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/pan.2014.11.04.17.31...@gmail.com
Re: Partición pierde UUID
El martes, 4 nov 2014 a las 18:31 horas (UTC+1),
Camaleón escribió:
El Tue, 04 Nov 2014 17:41:30 +0100, Manolo Díaz escribió:
El martes, 4 nov 2014 a las 16:52 horas (UTC+1),
Camaleón escribió:
Pero ya sabes que los kernels más recientes recomiendan el uso de la
nueva nomenclatura (id/uuid/label/path) de lo contrario te arriesgas a
que la partición cambie en cada reinicio.
¿De dónde sacas esa recomendación?,
Pues del mismo sitio que tú ;-)
porque la página man de mount dice otra cosa:
The recommended setup is to use tags (e.g. LABEL=label) rather than
/dev/disk/by-{label,uuid,partuuid,partlabel} udev symlinks in the
/etc/fstab file. Tags are more readable, robust and portable. The
mount(8) command internally uses udev symlinks, so the use of symlinks
in /etc/fstab has no advantage over tags. For more details see
libblkid(3).
¿Y exactamente donde ves tú la contradicción?
En path. Precisamente esa manera de identificar un disco y sus
particiones conviene evitarse. No hay garantías de que un disco que el
sistema ve ahora como /dev/sda (p. ej.) siga viéndose así siempre.
Saludos,
Saludos.
--
Manolo Díaz
--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141104185755.36794...@gmail.com
Re: Partición pierde UUID
El Tue, 04 Nov 2014 18:57:55 +0100, Manolo Díaz escribió:
El martes, 4 nov 2014 a las 18:31 horas (UTC+1),
Camaleón escribió:
El Tue, 04 Nov 2014 17:41:30 +0100, Manolo Díaz escribió:
El martes, 4 nov 2014 a las 16:52 horas (UTC+1),
Camaleón escribió:
Pero ya sabes que los kernels más recientes recomiendan el uso de la
nueva nomenclatura (id/uuid/label/path) de lo contrario te arriesgas a
que la partición cambie en cada reinicio.
¿De dónde sacas esa recomendación?,
Pues del mismo sitio que tú ;-)
porque la página man de mount dice otra cosa:
The recommended setup is to use tags (e.g. LABEL=label) rather than
/dev/disk/by-{label,uuid,partuuid,partlabel} udev symlinks in the
/etc/fstab file. Tags are more readable, robust and portable. The
mount(8) command internally uses udev symlinks, so the use of symlinks
in /etc/fstab has no advantage over tags. For more details see
libblkid(3).
¿Y exactamente donde ves tú la contradicción?
En path. Precisamente esa manera de identificar un disco y sus
particiones conviene evitarse. No hay garantías de que un disco que el
sistema ve ahora como /dev/sda (p. ej.) siga viéndose así siempre.
Ninguna de las 4 opciones posibles es infalible -como bien dice más
adelante la página del manual que apuntas- ya que p. ej., puede haber dos
etiquetas (label) idénticas. Vamos, que hay que asegurarse de que sea
cual sea el sistema de identificación elegido apunte al dispositivo
adecuado y no haya duplicados.
Saludos,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/pan.2014.11.04.18.36...@gmail.com
