Re: Partición pierde UUID
> El 11/11/2014, a las 16:48, Haylem Candelario Bauzá <haylem@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 <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
>
No, no es el caso, comprobado.
>
>
> --
> To UNSUBSCRIBE, email to debian-user-spanish-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] 1415720882.4748.2.camel@debian.inor.sld.cu">https://lists.debian.org/[🔎] 1415720882.4748.2.camel@debian.inor.sld.cu
>
Reply to: