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 <noelamac@gmail.com> escribió:
> >
> > El Mon, 10 Nov 2014 10:42:30 +0100, ZorroPlateado escribió:
> >
> >>> El 7/11/2014, a las 16:28, Camaleón <noelamac@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-REQUEST@lists.debian.org
> > with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> > Archive: [🔎] pan.2014.11.10.14.38.38@gmail.com">https://lists.debian.org/[🔎] pan.2014.11.10.14.38.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/UID con u número largísimo
cuando hacía fdisk -l
Haz esto a ver fdisk -l
Reply to: