El mar, 11-11-2014 a las 09:44 +0100, ZorroPlateado escribió: > > El 10/11/2014, a las 15:38, Camaleón <[email protected]> escribió: > > > > El Mon, 10 Nov 2014 10:42:30 +0100, ZorroPlateado escribió: > > > >>> El 7/11/2014, a las 16:28, Camaleón <[email protected]> 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 [email protected] > > with a subject of "unsubscribe". Trouble? Contact > > [email protected] > > Archive: https://lists.debian.org/[email protected] > > > > 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/UID con u número largísimo cuando hacía fdisk -l Haz esto a ver fdisk -l -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
