# [TIP] Passer son noyau en libata "intégral"

## El_Goretto

Bonsoir tout le monde  :Smile: 

J'ai lu à droite et à gauche des trucs plus ou moins vrais pour passer un noyau 2.6.18 ou supérieur en full libata, c'est à dire en se passant des "vieux" drivers IDE. Voici une petite synthèse de ce que j'ai fait ce soir.

Rappelez vous, tout vous périphériques IDE ne seront plus en hdX, mais en sdX (disques durs)  ou srX (lecteurs optiques).

L'idéal serait de pouvoir continuer à booter tantôt un "ancien" kernel" et tantôt un kernel "libata only" sans modifier quoi que ce soit.

Bien préparer sa migration, c'est:

Pour les disques durs, utiliser les labels pour marquer les partitions et établir un fstab qui les prend en compte (LABEL=XXX à la place de /dev/hdX). 

pour le ext2/3 tune2fs est notre ami

pour le reiserfs, reiserfstune. 

pour XFS, xfs_admin

et n'oubliez pas la swap: mkswap -L label

[Si vous l'avez fait sur un autre FS, merci de préciser comment, que j'ajoute].

Pour les disques optiques, passer par hal+dbus, ou bien amusez vous avec les règles udev....  :Smile: 

Supprimer le support IDE (ATA/ATAPI/MFM/RLL support)

Trouver les drivers les remplaçant dans Serial ATA (prod) and Parallel ATA (experimental) drivers

Dans SCSI device support:

Normalement SCSI disk support doit déjà être selectionné, ne serait-ce que pour les périphériques de stockage USB.

Ne pas oublier ([/me sifflote]  :Smile: ) d'ajouter SCSI CDROM support

Idem avec SCSI generic support si vous voulez graver... Sélection recommandée, car cela permet d'activer les périphériques RAW en /dev/sgX (utile par exemple pour l'extraction de CD via cdparanoia)

Ajouter root=/dev/sdXY aux paramètres du noyau. C'est le point perfectible, mais au moins à ne faire qu'une seule fois.

Note:

Ajouter en paramètre du noyau libata.atapi_enabled=1 n'est plus nécessaire.

Effet de bords:

revoyez la conf de lvm si vous avez restreint le filtre des périphériques à scanner par défaut.

revoyez la conf de hdparm.

A compléter:

Je crois que c'est un problème universel: trouver un équivalent des labels pour GRUB ou lilo (paramètre root=...) Cette méthode semble nécessiter un ramdisk. Ami gentooiste, si tu sais comment t'y prendre, n'hésite pas à en faire profiter les "camarades"  :Wink: 

----------

## yoyo

 *El_Goretto wrote:*   

> Utiliser les labels pour marquer les partitions et établir un fstab qui les prend en compte (LABEL=XXX à la place de /dev/hdX). Pour le ext2/3 tune2fs est notre ami, pour le reiserfs çà existe aussi il me semble. [Si vous l'avez fait sur un autre FS, merci de préciser comment, que j'ajoute].

 Et pourquoi ne pas utiliser les règles udev pour fixer le nom des devices ? Ou mieux, générer un lien symboique de /dev/sdX vers /dev/hdX au cas où certains softs fassent appellent à cette dénomination ? Ainsi, les /dev/hdX seraient toujours présents : plus de problème de fstab etc.

Mes 0.02 cents

EDIT : et une question subsidiaire : quel est l'intérêt de passer en full-libata ??

----------

## truc

Bon, et bien ce psot est le bienvenu, j'me disais bien que j'avais du louper quelque chose... j'avais bien touché à quelques options dans la config du kernel, mais finalement, je n'ai rien vu de différents, ça doit ête parce que j'ai laisser "l'ancien support IDE" dans le noyau? :/

Sinon, euh... Mon disque dur principal est un sata, mon secondaire est ide, je suppose que mon actual /dev/sda peut donc devenir /dev/sdb (par exemple.) ? ( oui d'où l'utilité des label, mais je n'en suis pas encore là)

Sinon, yoyo, je n'en ai aucune idée, de l'interet de passer en full libata, sinon celui de faire kewl;) , Mais je me dis comme ça, que les anciens pilotes IDE, seront sans doutes retirés du noyau, et que c'est sans doute ça l'interet?

----------

## ghoti

 *yoyo wrote:*   

> Ou mieux, générer un lien symboique de /dev/sdX vers /dev/hdX au cas où certains softs fassent appellent à cette dénomination ? Ainsi, les /dev/hdX seraient toujours présents : plus de problème de fstab etc.

 

Heu, amha, ce serait la solution idéale pour ne plus rien y comprendre   :Confused: 

On a défini une structure pour la dénomination des périphs dans le but de clarifier les choses au niveau de nos petits neurones, alors pourquoi vouloir introduire le chao ? 

Tant qu'on y est, on pourrait faire pointer lp0 sur rtc et fb0 sur dvd0 : tu imagines tu imagines ta tête si le n00b te dis qu'il a introduit un dvd dans son lecteur mais que le mount /dev/fb0, ça marche pas ?  :Laughing: 

Non, non : surtout ne pas mélanger les notations hdx et sdx !

Par contre, des règles udev, pourquoi pas?

Mais j'aime bien tout de même la solution des labels. Quoique, j'avais essayé il y a plusieurs années mais j'avais laissé tomber je ne sais plus pourquoi.

----------

## ghoti

 *truc wrote:*   

> Mais je me dis comme ça, que les anciens pilotes IDE, seront sans doutes retirés du noyau, et que c'est sans doute ça l'interet?

 

+1

Les drivers IDE sont clairement marqués comme obsolètes ! 

On peut aussi imaginer que les drivers libata étant plus récents, il y a une petite chance qu'ils soient mieux dessinés et plus efficaces ...

----------

## _droop_

 *ghoti wrote:*   

> Il y a une petite chance qu'ils soient mieux dessinés et plus efficaces ...

 

Subjectivement, c'est le cas chez moi   :Laughing:  (pas eu le courage de faire un bench)

Sinon, il faut aussi modifier le paramêtre "root" du noyau pour le démarrage. De façon simple, on ne peut pas utiliser les LABEL (root=LABEL=/ ne fonctionne pas de base). Il y a des distributions (Fedora par exemple) qui boot en utilisant le label, mais il faudrait faire un initrd qui cherche la partition et fait le "pivot root"...

Pour les labels :

 - sur reiserfs : reiserfstune -l lelabel /dev/...

 - sur xfs : xfs_admin -L lelabel /dev/...

Les 2 sur des partitions non montées.

Pour les lecteurs optiques : 

 - on utilise hal+dbus (kde, gnome) et on n'a pas besoin d'entrée dans fstab...

 - pas de problème de gravure à reporter (je le précise car je m'étais posé la question avant la migration).

En tout cas, je remettrais jamais un noyau < 2.6.19 sur mon athlon (d'où l'utilité d'avoir mis des label partout   :Embarassed:  )...

----------

## truc

 *_droop_ wrote:*   

> En tout cas, je remettrais jamais un noyau < 2.6.19 sur mon athlon (d'où l'utilité d'avoir mis des label partout   )...

 

Par pour profiter des tes label, tu peux faire joujou avec openvz, y'a un howto dans cette même section. Pour l'instant, on en est toujours au 2.6.18, donc dépèche toi!  :Laughing: 

----------

## d2_racing

Ça va ressembler à ceci en gros :

J'ai une carte mère ASUS P4P800.[/quote]

```

# 

# ATA/ATAPI/MFM/RLL support 

# 

# CONFIG_IDE is not set 

# 

# SCSI device support 

# 

# CONFIG_RAID_ATTRS is not set 

CONFIG_SCSI=y 

# CONFIG_SCSI_NETLINK is not set 

# CONFIG_SCSI_PROC_FS is not set 

# 

# SCSI support type (disk, tape, CD-ROM) 

# 

CONFIG_BLK_DEV_SD=y 

# CONFIG_CHR_DEV_ST is not set 

# CONFIG_CHR_DEV_OSST is not set 

CONFIG_BLK_DEV_SR=y 

# CONFIG_BLK_DEV_SR_VENDOR is not set 

CONFIG_CHR_DEV_SG=y 

# CONFIG_CHR_DEV_SCH is not set 

# 

# Some SCSI devices (e.g. CD jukebox) support multiple LUNs 

# 

# CONFIG_SCSI_MULTI_LUN is not set 

# CONFIG_SCSI_CONSTANTS is not set 

# CONFIG_SCSI_LOGGING is not set 

# 

# SCSI Transports 

# 

# CONFIG_SCSI_SPI_ATTRS is not set 

# CONFIG_SCSI_FC_ATTRS is not set 

# CONFIG_SCSI_ISCSI_ATTRS is not set 

# CONFIG_SCSI_SAS_ATTRS is not set 

# CONFIG_SCSI_SAS_LIBSAS is not set 

# 

# SCSI low-level drivers 

# 

# CONFIG_ISCSI_TCP is not set 

# CONFIG_BLK_DEV_3W_XXXX_RAID is not set 

# CONFIG_SCSI_3W_9XXX is not set 

# CONFIG_SCSI_ACARD is not set 

# CONFIG_SCSI_AACRAID is not set 

# CONFIG_SCSI_AIC7XXX is not set 

# CONFIG_SCSI_AIC7XXX_OLD is not set 

# CONFIG_SCSI_AIC79XX is not set 

# CONFIG_SCSI_AIC94XX is not set 

# CONFIG_SCSI_DPT_I2O is not set 

# CONFIG_SCSI_ADVANSYS is not set 

# CONFIG_SCSI_ARCMSR is not set 

# CONFIG_MEGARAID_NEWGEN is not set 

# CONFIG_MEGARAID_LEGACY is not set 

# CONFIG_MEGARAID_SAS is not set 

# CONFIG_SCSI_HPTIOP is not set 

# CONFIG_SCSI_BUSLOGIC is not set 

# CONFIG_SCSI_DMX3191D is not set 

# CONFIG_SCSI_EATA is not set 

# CONFIG_SCSI_FUTURE_DOMAIN is not set 

# CONFIG_SCSI_GDTH is not set 

# CONFIG_SCSI_IPS is not set 

# CONFIG_SCSI_INITIO is not set 

# CONFIG_SCSI_INIA100 is not set 

# CONFIG_SCSI_PPA is not set 

# CONFIG_SCSI_IMM is not set 

# CONFIG_SCSI_STEX is not set 

# CONFIG_SCSI_SYM53C8XX_2 is not set 

# CONFIG_SCSI_IPR is not set 

# CONFIG_SCSI_QLOGIC_1280 is not set 

# CONFIG_SCSI_QLA_FC is not set 

# CONFIG_SCSI_QLA_ISCSI is not set 

# CONFIG_SCSI_LPFC is not set 

# CONFIG_SCSI_DC395x is not set 

# CONFIG_SCSI_DC390T is not set 

# CONFIG_SCSI_NSP32 is not set 

# CONFIG_SCSI_DEBUG is not set 

# 

# Serial ATA (prod) and Parallel ATA (experimental) drivers 

# 

CONFIG_ATA=y 

# CONFIG_SATA_AHCI is not set 

# CONFIG_SATA_SVW is not set 

CONFIG_ATA_PIIX=y 

# CONFIG_SATA_MV is not set 

# CONFIG_SATA_NV is not set 

# CONFIG_PDC_ADMA is not set 

# CONFIG_SATA_QSTOR is not set 

# CONFIG_SATA_PROMISE is not set 

# CONFIG_SATA_SX4 is not set 

# CONFIG_SATA_SIL is not set 

# CONFIG_SATA_SIL24 is not set 

# CONFIG_SATA_SIS is not set 

# CONFIG_SATA_ULI is not set 

# CONFIG_SATA_VIA is not set 

# CONFIG_SATA_VITESSE is not set 

# CONFIG_PATA_ALI is not set 

# CONFIG_PATA_AMD is not set 

# CONFIG_PATA_ARTOP is not set 

# CONFIG_PATA_ATIIXP is not set 

# CONFIG_PATA_CMD64X is not set 

# CONFIG_PATA_CS5520 is not set 

# CONFIG_PATA_CS5530 is not set 

# CONFIG_PATA_CS5535 is not set 

# CONFIG_PATA_CYPRESS is not set 

# CONFIG_PATA_EFAR is not set 

# CONFIG_ATA_GENERIC is not set 

# CONFIG_PATA_HPT366 is not set 

# CONFIG_PATA_HPT37X is not set 

# CONFIG_PATA_HPT3X2N is not set 

# CONFIG_PATA_HPT3X3 is not set 

# CONFIG_PATA_IT821X is not set 

# CONFIG_PATA_JMICRON is not set 

# CONFIG_PATA_TRIFLEX is not set 

CONFIG_PATA_MPIIX=y 

# CONFIG_PATA_OLDPIIX is not set 

# CONFIG_PATA_NETCELL is not set 

# CONFIG_PATA_NS87410 is not set 

# CONFIG_PATA_OPTI is not set 

# CONFIG_PATA_OPTIDMA is not set 

# CONFIG_PATA_PDC_OLD is not set 

# CONFIG_PATA_RADISYS is not set 

# CONFIG_PATA_RZ1000 is not set 

# CONFIG_PATA_SC1200 is not set 

# CONFIG_PATA_SERVERWORKS is not set 

# CONFIG_PATA_PDC2027X is not set 

# CONFIG_PATA_SIL680 is not set 

# CONFIG_PATA_SIS is not set 

# CONFIG_PATA_VIA is not set 

# CONFIG_PATA_WINBOND is not set 

```

----------

## El_Goretto

Merci pour vos commentaires, j'ai complété.

Par contre, je vais refaire des tests, mais j'ai une gravure qui a merdé hier soir (la gravure n'avançait plus, avec erreur libata au final après annulation de k3b). La seule véritable que j'ai lancée en configuration full-libata, et ce au bout d'à peine 2h d'utilisation de cette configuration...

Je vais refaire des tests grandeur nature avec un RW cette fois, et plus uniquement avec des tests de formatage de RW.

J'y suis passé surtout parce que je trouve que ma config PC (cf signature) est naze au niveau E/S disques. J'ai un phénomène pénible pendant des emerges, comme si ça swapait, alors que ce n'est pas du tout le cas... Screugneux.   :Evil or Very Mad: 

----------

## Mickael

 *Quote:*   

> Ajouter en paramètre du noyau libata.atapi_enabled=1 ne sert à rien à priori (testé avec et sans chez moi). 

 

Cela était le cas avant, avec les vieux drivers ide, mais cela n'est plus nécessaire.

----------

## geekounet

 *MickTux wrote:*   

>  *Quote:*   Ajouter en paramètre du noyau libata.atapi_enabled=1 ne sert à rien à priori (testé avec et sans chez moi).  
> 
> Cela était le cas avant, avec les vieux drivers ide, mais cela n'est plus nécessaire.

 

Oui, l'option est activée par défaut depuis le 2.6.14

----------

## Mickael

Juste pour enfoncer le clou, mais on pouvait encore avoir des problèmes d'activation, j'avais fait un post la dessus avec mon nouveau portable et mon lecteur/graveur. Mais avec les nouveaux drivers, normalement plus aucun problème.

----------

## El_Goretto

Bon, béh retour arrière pour moi, aucune gravure effectuée n'est lisible (donc la vérification échoue). Les CD/DVDs gravés auparavant passent. Dans tous les cas, c'est la fête aux erreurs côté logs:

Extrait:

```
sr 3:0:0:0: SCSI error: return code = 0x08000002

sr0: Current: sense key=0x3

    ASC=0x2 ASCQ=0x0

Info fld=0x0

end_request: I/O error, dev sr0, sector 0

Buffer I/O error on device sr0, logical block 0

Buffer I/O error on device sr0, logical block 1

Buffer I/O error on device sr0, logical block 2

Buffer I/O error on device sr0, logical block 3

Buffer I/O error on device sr0, logical block 4

Buffer I/O error on device sr0, logical block 5

Buffer I/O error on device sr0, logical block 6

Buffer I/O error on device sr0, logical block 7

Buffer I/O error on device sr0, logical block 8

Buffer I/O error on device sr0, logical block 9

sr 3:0:0:0: SCSI error: return code = 0x08000002

sr0: Current: sense key=0x3

    ASC=0x11 ASCQ=0x0

Info fld=0x0

end_request: I/O error, dev sr0, sector 0

printk: 22 messages suppressed.

Buffer I/O error on device sr0, logical block 0

sr 3:0:0:0: SCSI error: return code = 0x08000002

sr0: Current: sense key=0x3

    ASC=0x2 ASCQ=0x0

Info fld=0x0

end_request: I/O error, dev sr0, sector 1239552

Buffer I/O error on device sr0, logical block 154944

sr 3:0:0:0: SCSI error: return code = 0x08000002

sr0: Current: sense key=0x3

    ASC=0x2 ASCQ=0x0

Info fld=0x0

```

Bref, on verra la 2.6.21 ou la 22  :Smile: 

----------

## d2_racing

Il ne faut pas oublier d'activer SCSI disk support dans SCSI Section, car ça prend ça pour pouvoir mounter les clé USB.

C'est même écrit dans le make menuconfig.

----------

## blasserre

 *yoyo wrote:*   

> EDIT : et une question subsidiaire : quel est l'intérêt de passer en full-libata ??

 

ici l'intérêt est d'avoir fait passer le hdparm -t /dev/hda de 45MB/s à plus de 55MB/s

ce qui le met à égalité de perfs (voire un poil plus) avec ses deux petits frères en sata

j'ai pu faire une grossière erreur dans mes anciens noyaux, 

mais je n'avais jamais réussi à lui faire cracher autant de données avant.

enjoy   :Wink: 

----------

## yoyo

Bonjour @ tous,

Tant qu'à changer de fs (cf thread sur le stage5) je me dis que je vais aussi tenter le full-libata.

Mais j'ai une question subsidiaire : est-il possible via un argument passé au noyau de choisir le type de support des disques ? C'est-à-dire d'inclure dans le noyau les supports ide et ata et de sélectionner au boot celui que l'on souhaite ?

Enfin ça n'est pas indispensable mais j'en profite pour faire du nettoyage de sources kernel et de menu grub ...   :Rolling Eyes: 

----------

## ghoti

 *yoyo wrote:*   

> est-il possible via un argument passé au noyau de choisir le type de support des disques ? C'est-à-dire d'inclure dans le noyau les supports ide et ata et de sélectionner au boot celui que l'on souhaite ?

 

Je me demande si l'argument "combined_mode" ne servirait justement pas à ça ? (voir /usr/src/linux/Documentation/kernel-parameters.txt)

Jamais creusé cependant.

Sinon, il y a toujours la solution de créer 2 noyaux différents.

Ou aussi, en utilisant des modules séparés, il devrait théoriquement y avoir moyen de démarrer en ramdisk pour permettre le choix du driver (méthode "LiveCD", quoi!)

Mais bon, ces solutions ne brillent pas spécialement par leur simplicité ...

----------

## titoucha

L'un d'entre vous a-t-il réussi à être complètement en libata avec le chipset Nvidia 5, j'y suis pas arrivé.   :Embarassed: 

----------

## Poischack

Y a pas mal d'infos aussi sur cette page (anglais): https://forums.gentoo.org/viewtopic-p-3835164.html?sid=73a8bd77348d8d1b39670cd3d31de851

----------

## Nah

 *El_Goretto wrote:*   

> Bonsoir tout le monde 
> 
> Bien préparer sa migration, c'est:
> 
> [list][*]Pour les disques durs, utiliser les labels pour marquer les partitions et établir un fstab qui les prend en compte (LABEL=XXX à la place de /dev/hdX). 

 

On peux aussi utiliser l'UUID (Universal Unique IDentifier) des paritions, que l'on peu connaitre comme ceci:  :Wink: 

```
ls -lh /dev/disk/by-uuid/
```

après dans le fstab:

```
UUID=0c84a396-e3f5-49d4-9480-f0d81f6b07ce      /var/portage      reiser4     ...
```

----------

## Poischack

Quelqu'un a réussi à monter une partition ntfs par son label dans fstab ?

Ca marche tres bien pour le swap et mon root ext3, mais il me dit qu'il ne trouve pas le label correspondant à ma partition en ntfs.

----------

## Mickael

Avant le fstab, il te faut sélectionner les deux modules ntfs du noyau.

```
zgrep -i "ntfs" /proc/config.gz 

CONFIG_NTFS_FS=y

# CONFIG_NTFS_DEBUG is not set

CONFIG_NTFS_RW=y

```

----------

## Poischack

Ils sont en durs dans mon noyau.

# ntfslabel  /dev/sda1

vista-root

#mount LABEL=vista-root /media/sda1 -t ntfs

mount: périphérique spécial LABEL=vista-root n'existe pas

----------

## lejim

Bonsoir tout le monde, j'ai suivi la doc pour passer en full libata. Voilà ça c'est fait  :Smile:  Mais alors impossible de graver quoi que ce soit... non pas que ça foire les cd... juste que dès que je lance une gravure pouf la barre de progress passe à 100% et hop succès éjection ( et bien sur rien de gravé hein ).

J'utilise brasero. avec le créateur de cd de gnome c'est kifkif modulo un message d'erreur que l'autre ne me renvoi pas.

J'ai bien mis le generic scsi support...

J'ai raté une étape???

EDIT :

Ouai en effet... mon utilisateur n'avait pas le droit de tripatouiller aux lecteurs de cdrom....

bon première gravure sur cd effectuée et ok ( pourtant médium de mer... et graveur lg tout pourri )

----------

## xaviermiller

 *El_Goretto wrote:*   

> Bonsoir tout le monde 
> 
> Jant dans Serial ATA (prod) and Parallel ATA (experimental) drivers
> 
> [*]Dans SCSI device support:
> ...

 

sous-entendu "en dur"  :Laughing: 

passé en full libata, et après avoir mis le support SCSI en dur, ça marche  :Wink: 

----------

## Temet

Verdict:

```
gentoo ~ # hdparm -tT /dev/hda

/dev/hda:

Timing cached reads:   644 MB in  2.00 seconds = 321.30 MB/sec

Timing buffered disk reads:  174 MB in  3.02 seconds =  57.62 MB/sec
```

```
gentoo ~ # hdparm -tT /dev/sda

/dev/sda:

Timing cached reads:   610 MB in  2.00 seconds = 304.67 MB/sec

Timing buffered disk reads:  174 MB in  3.02 seconds =  57.59 MB/sec
```

Ne sert donc à rien pour moi.

----------

## titoucha

Si à utiliser des pilotes tournés vers le futur.

----------

## Bapt

 *El_Goretto wrote:*   

> Ajouter root=/dev/sdXY aux paramètres du noyau. C'est le point perfectible, mais au moins à ne faire qu'une seule fois.
> 
> 

 

Moi je fait un root=/dev/disk/by-label/monlabel où monlabel correspond au label de ma partition / et depuis mes disques peuvent changer de nom comme ils veulent : sdX, je n'ai plus de problème  :Smile: .

----------

## El_Goretto

@Bapt:

Mmmmm, yabon!  :Smile: 

Je teste, et si ça marche chez moi et que le vent est dans le bon sens, je mets à jour le post principal  :Smile: 

----------

## El_Goretto

Non, ça ne fonctionne pas, et c'est presque logique.

Voyons: pour les labels, soit c'est le noyau, soit c'est udev qui les gère (merci de me corriger). Donc quand l'OS est booté, ok, les liens sont bons, par exemple en full libata chez moi:

```
# ll /dev/disk/by-label/

total 0

lrwxrwxrwx 1 root root 10 jui 10  2007 BOOT -> ../../sdb6

lrwxrwxrwx 1 root root 10 jui 10  2007 DATA -> ../../sda5

lrwxrwxrwx 1 root root 10 jui 10  2007 PTITEBOOT -> ../../sdb1

lrwxrwxrwx 1 root root 10 jui 10  2007 ROOT -> ../../sdb8

lrwxrwxrwx 1 root root 10 jui 10  2007 SWAP -> ../../sdb7
```

Oui, sauf que grub, au mieux, je suppose qu'il lit ces liens, mais comme ceux-ci sont correctement positonnés qu'une fois que l'OS a booté... Ben on boote jamais correctement "la première fois". En particuliers si on était en hdX au précédent boot, et qu'on veut booter un noyau full libata, les liens pointeront sûrement sur du sdX:

```
lrwxrwxrwx 1 root root 10 jui 10  2007 ROOT -> ../../hdb8
```

Donc grub merdoit à chaque "switch" libata/palibata.

Bapt, si tu as le temps de vérifier mon hypothèse...  :Smile: 

----------

## Bapt

Je ne sais pas, je ne me suis pas plus poser la question que ça, mais en ce qui me concerne j'ai ça dans mon grub.conf

title Gentoo

root   (hd0,0)

kernel /boot/vmlinuz26 root=/dev/disk/by-label/root ro vga=773

initrd /boot/kernel26.img

J'avais trouver ça dans une doc arch, et ça marchait bien sous arch, je l'ai reporté sous gentoo et c'est ok. il me semble que c'est l'initrd (klibc-udev plus précisément) qui crée les liens pour que pour le kernel les trouvent bien par le suite. Donc il faut un kernel avec initrd.

Si quelqu'un parle le russe, le wiki russe de gentoo propose la même solution : http://ru.gentoo-wiki.com/Fstab

Pour le wiki archlinux en question : http://wiki.archlinux.org/index.php/Persistent_block_device_naming

----------

## yoyo

 *El_Goretto wrote:*   

> Oui, sauf que grub, au mieux, je suppose qu'il lit ces liens, mais comme ceux-ci sont correctement positonnés qu'une fois que l'OS a booté... Ben on boote jamais correctement "la première fois". En particuliers si on était en hdX au précédent boot, et qu'on veut booter un noyau full libata, les liens pointeront sûrement sur du sdX:
> 
> ```
> lrwxrwxrwx 1 root root 10 jui 10  2007 ROOT -> ../../hdb8
> ```
> ...

 Amha grub n'a rien à voir la dedans. Il ne lit aucun label ni aucun fichier dans "/dev" ou autre. Il donne la main au noyau et ne la reprend plus.

En fait grub utilise son propre système de nommage de périphériques : hd0 pour le premier disque dur qu'il trouve, qu'il soit en sata ou en pata.

Grub se contente de passer les paramètres donnés au noyau indiqué : il passera "runlevel=toto" si tu mets ça dans ta config. Après, que le noyau ne sache pas l'interpréter ça n'est pas (plus) le problème de grub.

C'est donc soit le paramètre rajouté au noyau qui est incorrect, soit le noyau lui-même qui est incomplet (option "en dur" manquante ou initrd).

D'ailleurs tu sembles dire que c'est le switch "libata/palibata" qui pose problème; cela sous-entend que ton système démarre lorsque tu ne switches pas et que par conséquent ton grub fonctionne parfaitement.

Enjoy !

----------

## El_Goretto

Oui oui, manque de lucidité de ma part.

Reste qu'il faut donc obligatoirement un ramdisk en complément du noyau pour que la methode des labels puisse fonctionner avec grub. MAJ du post initial + tard, pas le temps là.

----------

## yoyo

 *El_Goretto wrote:*   

> Reste qu'il faut donc obligatoirement un ramdisk en complément du noyau pour que la methode des labels puisse fonctionner avec grub.

 Pas obligatoirement un ramdisk. Si ma mémoire ne me fait pas défaut, le ramdisk permet au noyau de charger des modules avant qu'il n'ait accès à "/lib/modules". Par exemple le support du système de fichier sur lequel se trouve "/", le splashscreen (puisqu'il est chargé avant que le système ne soit monté) etc..

A priori si ton noyau est "complet" le ramdisk ne devrait pas être nécessaire.

Et j'insiste : "pour que la méthode des labels puisse fonctionner avec grub". Grub n'a rien à voir dans l'histoire : ça serait lilo ou un autre bootloader ça serait pareil !

Enfin là je fais des "plans sur la gourmette" (Fatals Picards Inside) parce que je ne sais même pas quelle est ton erreur : tu as une série de "grubgrubgrub" qui s'affiche à l'écran ? Si c'est le cas, le problème vient bien de grub et je ne comprends pas pourquoi. Sinon, le problème (et sa solution) est ailleurs, vraisemblablement du côté du noyau et/ou d'udev (puisque c'est lui qui génère les entrées dans "/dev" il me semble).

Enjoy !

----------

## El_Goretto

Bon, alors je persiste et signe: grub ignore tous des labels, ok, n'empeche que c'est bien un grub.conf que je vais configurer pour qu'il passe les paramètres kivonbien au noïau. Ouf  :Smile: 

"Mon erreur" est un kernel panic, du genre de celui qu'on a quand le paramètre "root=..." n'est pas bon. Et si un ramdisk n'est pas nécessaire, j'en perd mon latin: comment le noyau serait capable de comprendre une variable: "root=/dev/truc" sinon? 

Ou alors c'est pas la poule qui a pondu le 1er oeuf, mais ce farceur de castor... (oui, je vais prendre mes gouttes ^^).

----------

## yoyo

 *El_Goretto wrote:*   

> Bon, alors je persiste et signe: grub ignore tous des labels, ok, n'empeche que c'est bien un grub.conf que je vais configurer pour qu'il passe les paramètres kivonbien au noïau. Ouf 

 Oui mais si j'utilise lilo, ça reste une erreur grub ??   :Mr. Green: 

 *El_Goretto wrote:*   

> "Mon erreur" est un kernel panic, du genre de celui qu'on a quand le paramètre "root=..." n'est pas bon. Et si un ramdisk n'est pas nécessaire, j'en perd mon latin: comment le noyau serait capable de comprendre une variable: "root=/dev/truc" sinon? 

 De la même façon qu'il comprend un "root=/dev/hdxy" ou un "root=/dev/sdxy" non ?? Ce que je veux dire c'est que je démarre sans problème sur un noyau sans "initrd" avec les paramètres "root=/dev/hdaxy".

Je pense qu'il faudrait qu'on éclaircisse le processus de démarrage pour voir à quel moment sont créées les entrées dans /dev, par qui et comment. De là on devrait trouver le "responsable" des "kernel panic" et comment y remédier.

Mes 0.02 cents.

----------

## El_Goretto

Un petit ajout "culture G" grâce à guilc, à propos des périphériques RAW SCSI et cdparanoia.

----------

## Bob_Le_Mou

Avec beaucoup de retard, merci pour cette excellente doc.

Juste un petit ajout cependant pour ceux qui comme moi utilisent LVM :

Ne pas oublier de modifier /etc/lvm/lvm.conf pour le (re-)mettre d'aplomb (je ne me souviens plus de ce qu'il y a par défaut).

par exemple : 

```
filter = [ "a|/dev/[sh]d[abef]|", "r/.*/" ]
```

----------

## Biloute

C'est facile, rapide et ça peut rapporter gros!  :Shocked: 

La modif a duré 5min a tout casser : un yes et un no dans le .config et dans /etc/fstab des "s" à la place des "h".

 :Question:  Par contre il y a aussi /etc/mtab qui contient du hdXY  :Question: 

Comme Temet, hdparm donne toujours les mêmes résultats mais j'ai un boot qui passe de 24sec à 22sec (merci openrc) et firefox se lance un peu plus vite.

Sinon pour ceux qui utilisent un label pourquoi ne pas mettre root="LABEL=ROOT" dans le grub.conf (remplacer ROOT par votre label.

----------

## netfab

Salut,

Je vous explique ce qu'il m'est arrivé en passant en full libata aujourd'hui.

Sur ce système j'ai :

* 2 disques IDE : hdb et hdd

* un disque sata sda

Une fois n'est pas coutume, je décide d'upgrader mon kernel (gentoo-sources) de 2.6.23-r9 à 2.6.25-r8, en partant d'une configuration kernel d'origine, et j'en profite pour passer en même temps en full libata. Je prend donc mon temps pour configurer tout çà comme il faut, je prépare le nouveau fstab basé sur les UUID, make && make modules_install etc... etc.. et reboot.

Ma partition root est sda3 (donc dans le grub.conf je passais au kernel l'option root=/dev/sda3).

Après plusieurs kernel panic de ce style :

```

VFS : mounted root (reiserfs filesystem) readonly

freeing unused kernel memory 276k freed

Warning : unable to open an initial console

Kernel panic - not syncing : no init found. Try passing init= option to kernel.

```

Je réalise (enfin) que si les disques IDE changent de nom, alors mon sda ne doit plus s'appeler sda mais sdc.

Je reboot une fois de plus, j'édite la ligne de commande directement depuis grub : je passe l'option root=/dev/sdc3 au kernel, et là miracle, plus de kernel panic, çà boot, mais.... plein d'erreurs durant l'init, des trucs rouges de partout, des warning et j'en passe : le système s'etait complètement emmêlé les pinceaux avec les partitions.

Et là je remarque une chose : une erreur qui me dit en gros que la swap sur /dev/hdbX n'est pas activable.

Alors que j'utilise bien un UUID pour designer la swap :

```

$ grep swap /etc/fstab

UUID=656f9ccf-6be6-4d62-843c-f82dac1f3afb none swap   sw   0 0

```

Là je fais un grep hdb /etc/*, et je finis par trouver le fichier /etc/blkid.tab, qui d'après ce que j'ai compris est un fichier de cache, généré par je ne sais qui je ne sais quand, et qui visiblement est utilisé au boot. Ce fichier contenait toujours les anciennes dénominations. Je l'ai donc déplacé, j'ai redémarré : aucune erreur, et ce fichier a été recréé automatiquement avec les dénominations correctes.

----------

## El_Goretto

Bien vu.

J'aurais cru que ce genre de chose était dynamique, je ne connaissais pas ce fichier.

blkid toujours pertinent

manpage blkid

Je n'ai pas trouvé quel script lors du boot appelle ce truc. Par contre des bugs existent sur ce sujet (https://bugs.gentoo.org/show_bug.cgi?id=225669).

----------

