> 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/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-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
