Re: Partición pierde UUID
> 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.
Reply to: