Problema con kernel 2.6.20 y nuevos drivers IDE (HORROR, cuidado todos)

Imagen de compiler
0 puntos

Como recordaréis, hace unos días comenté en el grupo que tenía un problema tras un upgrade de Edgy a Feisty.(*)

http://www.ubuntu-es.org/index.php?q=node/58669

Pues bien, agarraos los machos porque el problema es nada más y nada menos que del kernel 2.6.20 y
os va a ocurrir a todos o casi todos cuando actualicéis (no a los que reinstaléis desde cero).

Echadle un ojo a esta página:

http://www.thejemreport.com/mambo/content/view/309/122/1/19/

Resumiendo lo que pone en ella:

  • En el kernel 2.6.20 se ha pasado de usar los módulos IDE de toda la vida  gestionar los discos IDE a través de los drivers de SATA.
  • Eso implica que todos vuestros discos hda y hdb se convertirán en sda y sdb.
  • Tendréis que cambiar lilos, grubs, scripts de backup, etc manualmente,  menos que uséis el sistema de UUID (que yo nunca uso).

Y ahora el problema propiamente dicho:

  • Si arranco con 2.6.17 y el driver viejo, todo me va de lujo. Si arranco con 2.6.20, el sistema me va lentísimo y "se para" cuando accedo al disco. Por lo visto, a través de libata no puedo activar el UDMA de los discos IDE, cosa que sí puedo hacer con los drivers IDE viejos. En resumen, en el 2.6.20 no puedo activar el UDMA con hdparm, el sistema me va muy lento y con acceso a disco se me quedan las aplicaciones "congeladas".
  • No puedo usar grub-install /dev/XXX, ya que /dev/hda no existe, y si lo uso contra /dev/sda me dice que /dev/sda no se corresponde con ningún dispositivo de la BIOS.

¿No os ha pasado a nadie? ¿Sabéis cómo activarle el DMA a los discos
emulados como SATA?

De momento he vuelto al 2.6.17, hasta que consiga que vaya bien todo.

 

Imagen de Gabriel_M
+1
0
-1

Hola:

1) No se si por suerte o por casualidad, pero pase en tres PCs de Dapper a Feisty directamente, haciendo un cdrom upgrade sin ningún tipo de problemas.

2) Mis discos siguen siendo siendo hd# cuando hago sudo fdisk -l, ahora en el fstab tienen UUID.

3) Respecto de UUID para los que usamos linux hace tiempo acostumbrados a usar el archivo fstab que se encuentra dentro de la carpeta etc exactamente /etc/fstab, para hacer una identificación fija a nuestras particiones que más o menos tenían esta forma:

/dev/sda#       /media/sda#     ext3    defaults        0       2

Ahora deberemos acostumbrarnos a usar UUID (Universal Unique Identifier)  forma de identificación fija de particiones  con la particularidad que  no importa el bus al que estén conectados los discos duros, con lo que se evitarian problemas como los comentados.

 Ahora la forma de ingresar en el fstab sería:

UUID=7df75776-57e7-4c9d-92ce-389b8b2844667   /media/sda#  ext3  defaults   0  2

 Los que no puedan salir de lo clásico en lugar del UUID pueden seguir usando la forma clásica de la referencia ejemplo /dev/sda#.

 ¿como es que se obtiene la dirección de la referencia de las particiones del disco?.

 Esto se genera automáticamente en la instalación,  hay casos donde tendremos que cambiar los datos manualmente, para ello lo hacemos de la siguiente forma:

 
servidor@usuario:~$ sudo vol_id /dev/sda#
ID_FS_USAGE=filesystem
ID_FS_TYPE=ext3
ID_FS_VERSION=1.0
ID_FS_UUID=1721f484-4358-464e-a4ca-83dc4fec9076
ID_FS_LABEL=
ID_FS_LABEL_SAFE=
 

O también así

servidor@usuario:~$ blkid /dev/sda#
/dev/sda#: UUID="1721f484-4358-464e-a4ca-83dc4fec9076" SEC_TYPE="ext2" TYPE="ext3"

 4) Los nuevos drivers lo que hacen es dotar de similares prestaciones a los discos pata (ide) y sata, sin distinción del tipo de conexión paralela o serial que posean.

Respecto de lo que planteas realmente no he tenido conocimiento de problemas similares.

Saludos y suerte. 

Gabriel

+1
0
-1