Concernant les lib je crois qu'il faut voir au cas par cas les chip supportés par tel ou tel lib, dans mon cas pas l'ombre d'intel dans la machine (voir lspci plus haut) mais du SIS.
Et il y a bien eu une différence entre le 2.6.18 (tout en hdx) et le 2.6.21 (tout en sdx), d'ailleurs je ne peut plus booter sur le .18 sans switcher sur l'ancien fstab et menu.lst.
Je suis en train de compiler des .22 avec différentes conbinaisons pour voir, je vous tiendrai au courant...
Je vais aussi installer d'autres distrib sur la même box pour voir comment leurs noyaux se comportent... Mais vu le faible inconvénient ça ne m'empêche pas de dormir !
Pour info la carte mère est une EliteGroup K7S5A assez courante en oem il y a quelques années, les machines viennent de récup de parc d'entreprise. ;-)
EDIT : J'écris ce complément depuis Sidux Gaïa (whoaa), le thème très clair ne me plaît pas, en revanche pour le reste !!
Sidux utilise les UUID par défaut comme identifiants de disques dans grub et le fstab... à la bonne heure !
J'ai compilé un 2.6.22-2 vanilla et même sauce sur ma Debian, donc c'est bien définitif. Du coup j'ai modifié les options par défaut du menu.lst (pour éviter les problèmes à chaque "update-grub") et j'utiliserai les UUID à l'avenir...
Sidux est très rapide sur ma vieille box, et sur un amd récent en 64bits c'est le bonheur !
]>Pas totalement, avec les noyaux récents (je pense que c'est dû à udev, mais à confirmer) la dénomination des disques est fluctuante (la preuve...)
Il y a eu de grosses modification dans la libata du kernel sur la version 2.6.19, ce qui cause le renomage hdx->sdx sur des contrôleurs disques Intel.
Udev n'a rien à voir là dedans, même si il est possible de l'utiliser pour renommer les devices.
Edit: Je viens de voir que tu es en AMD il n'y a donc pas de raisons pour qu'il y ai changement. Peut-être est-ce un patch kernel ou une règle de renomage kernel pour avoir une uniformité (je n'ai pas de debian pour regarder ça ).
]>En attendant je change mes menu.lst avec root=UUID=l'UUID_trouvée_avec_blkid
Est ce a dire que via l'UUID on s'affranchie des notions de /dev/XdaN au boot ?
]>En attendant je change mes menu.lst avec root=UUID=l'UUID_trouvée_avec_blkid
C'est bon à savoir.
Merci !
Un petit article sur le sujet :
]>pata est géré par libsata...
Est ce a dire que désormais la nomenclature HD finira par être du type "/dev/sdX" que le contrôleur soit PATA ou SATA ?
Plus simple certes, mais avec l'ancienne méthode on savait a quel type de matériel on avait affaire rien qu'en voyant le /dev associé
Suis passé au 2.6.21-2 K7 la semaine dernière avec un amd 3800+ et disque IDE sans soucis.
Sans doute ai-je eu de la chance
thveillon@debian:~$ lspci
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 735 Host (rev 01)
00:01.0 PCI bridge: Silicon Integrated Systems [SiS] Virtual PCI-to-PCI bridge (AGP)
00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS85C503/5513 (LPC Bridge)
00:02.1 SMBus: Silicon Integrated Systems [SiS] SiS961/2 SMBus Controller
00:02.2 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 07)
00:02.3 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 07)
00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0)
00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] AC'97 Sound Controller (rev a0)
00:03.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet (rev 90)
00:0b.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 61)
00:0b.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 61)
00:0b.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 63)
00:0d.0 FireWire (IEEE 1394): NEC Corporation IEEE 1394 Host Controller (rev 01)
00:0f.0 Network controller: RaLink RT2500 802.11g Cardbus/mini-PCI (rev 01)
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE]
Je pense que cela s'adressait à moi.
Depuis j'ai eu une idée : suivre ce conseil http://www.debian-administration.org/articles/522
reste à savoir comment le prochain kernel update retrouvera ses petits...
ps : depuis j'ai trouvé d'autres victimes, dans un sens ça me rassure !
]>et tu peux nous coller ici un lspci stp ?
]>