Installation de Fedora - Page 1

Martial Demolins (./2) :
bon, ben suffisait de pas mettre le root=LABEL=/

La bonne solution, c'est de mettre des labels uniques avec e2label et de remplacer / par les labels uniques.

Oui oui, tu peux virer grub. Tout ce que ça fera, c'est supprimer les programmes update-grub, etc.

Euh non, ça vire aussi le stage 2 et les configurations!
Mais il peut effectivement virer GRUB partout sauf pour la distribution dans laquelle il le configure.

c'est couillon ces histoires de labels
je m'en suis jamais servi sous linux

Martial, tu devrais plutot mettre root=/dev/sda4 que root=LABEL=machin

oui, c'est comme ça que boote linux en général (toutes distro)

le kernel a besoin de connaitre le point de montage initial avant de pouvoir monter tous les autres. l'option root=machin lui dit de monter machin sur /

l'initrd est un trifouillage qui permet de charger dans le noyal des modules avant que / soit monté (après on doit faire un pivot_root mais c'est une autre histoire), mais on peut s'en passer si on compile tout ce qui est nécessaire au démarrage en built-in.

après ça, le kernel cherche /sbin/init (ou d'autres) sur sa partition root et c'est parti. Lecture de /etc/inittab, exécution des scripts dans /etc/init.d/rc<i>.d, puis démarrage des instances de /bin/login sur les consoles. pour lancer X11 c'est juste un détail de plus.

PS: avec les options kivonbien tu peux même dire au kernel de booter sur un montage NFS en réseau.

squalyl (./7) :
c'est couillon ces histoires de labels
je m'en suis jamais servi sous linux

Martial, tu devrais plutot mettre root=/dev/sda4 que root=LABEL=machin

Par forcément judicieux ça : le label a l'immense avantage de ne pas être sensible aux changements de noms de device. Exemple, en passant de l'ancienne couche ide à la nouvelle utilisant libata => hop, les devices sont passés de hda à sda.
En passant de l'ancienne couche sata à la nouvelle avec libata => les devices sont passés de hde à sda
Etc, j'en passe. Utiliser les label (dans grub ET dans le fstab) permet de s'affranchir de ces variations au fil des version de kernel...et d'éviter les mauvaises surprises lors des MAJ de kernel

9> faut voir, à priori à lui ça lui a posé souci. ça identifie pas clairement un device.

pour les histoires de noms qui change pas, OK, ça peut être utile pour une clé usb ou un truc user friendly, mais quand ça concerne un périph racine dans une config système, spas très utile !

10> huhu

squalyl (./7) :
c'est couillon ces histoires de labels je m'en suis jamais servi sous linux

L'intérêt est que ces labels survivent une migration comme le passage à la libata qu'on a eu récemment. À cause de ça, Anaconda refuse maintenant de faire une mise à jour si les partitions sont codées en dur, il dit de mettre des labels, merci, au revoir.

trop pratique!

les label, c'est bien les identifiants super longs et impossibles à retenir ? (d'ailleurs, ils sont générés comment ? à partir du n° de série du disque ?)

Non, se sont les UUID, les labels sont les "noms de volumes" éditables dans le clic droit sur un disque dans le poste de travail windows.

ah ok. C'est récent ? Ça ne me dit rien du tout

heu ça dépend de ce que tu appelles récent, mais certaines distribs les utilisent par défaut depuis un an environ (deux versions d'ubuntu).

label, je sais pas.

Ubuntu utilise les UUID.

du genre, par exemple :
Pour une partition ext3 : 4ec2e4df-d523-4c2e-a775-52a636989443
Pour une partition NTFS : 108CD26D8CD24D3A
Pour une partition FAT32 : 4513-0E6A

j'imagine que c'est calculé à partir d'infos de la machine et du disque ; mais aussi des partitions et autres - ça semble être stocké dans le FS, et être dépendant du FS

pour compléter, ça a un _gros_ avantage par rapport à utiliser dans /etc/fstab (qui décrit les partitions à monter) "/dev/sda5" pour désigner une partition : dans le cas où tu changes deux disques de place, ou que tu en ajoutes un, ça peut changer les périphériques ; et "/dev/sda5" risque de ne plus être valide, ou de ne plus correspondre au même périphéque / partition
=> gros foutoir

Avec le système d'UUID, le système arrive à s'y retrouver....
(ce qui est bien pratique quand le PC présente pas toujours les périphériques dans le même ordre... complétement foireux, ça...)

et puis c'est compatible grâce aux /dev/disk/by-id, /dev/disk/by-label, /dev/disk/by-path et /dev/disk/by-uuid.

BookeldOr (./18) :
heu ça dépend de ce que tu appelles récent, mais certaines distribs les utilisent par défaut depuis un an environ (deux versions d'ubuntu).

J'ai toujours vu que des UUID alors ^^

(autant le système des LABEL me paraît pas mal, autant celui des UUID me rebute un peu :/)

Disons que les labels demandent une intervention humaine, et il y a le risque de brancher deux disques avec des labels identiques (genre chaîne vide), etc.
Alors que celui des UUID permet entièrement automatiquement de distinguer les partitions, règle les problèmes de changement de nappe, etc...
Ça permet aussi, par exemple, d'exécuter une action quand on branche un volume spécifique à chaud (genre time machine ).

y'a aussi les /dev/scsi/controller1/bus2/host3/lun4/part5 qui suxxent

Qui suxxent en quel sens ?

de droite à gauche

bah c'est plus chiant à retenir de /dev/sda1 et ça résout rien pisque ça dépend aussi de l'emplacement physique.