USB réglé sur / dev / sda au lieu de / dev / sdb

J'ai essayé d'utiliser un file kickstart pour guider le programme d'installation de Red Hat (RHEL6.5) sans intervention de l'user. Il search correctement le file kickstart dans /dev/sdb/fs.cfg , mais comme l'USB est reconnu comme /dev/sda , il se trouve dans /dev/sda/fs.cfg . Je peux pointer manuellement le programme d'installation vers cette destination, mais le rest du file kickstart repose sur le fait que le disque dur natif est sda . Je voudrais le faire sans éditer les files kickstart, mais c'est ce qui est nécessaire, je suis prêt à le faire.

Y at-il un moyen de forcer le kernel à reconnaître l'USB comme sdb et la HD comme sda (je suppose que le kernel est responsable de la confusion, mais je ne suis pas sûr)? Il semble très étrange qu'il choisisse un lecteur externe (l'USB) comme sda et force le interne (HD) à sdb.

Note: Mon problème est très similaire à celui-ci , sauf que mon file kickstart dépend absolument de la HD en sda

Ce problème se produit uniquement pour le programme d'installation de RHEL6.5 et non pour le programme d'installation de RHEL5.X (je n'ai pas essayé de version précédente de RHEL6.X). Ce que je veux vraiment savoir, c'est pourquoi il y a des changements entre les versions.

Ok, donc voici comment fonctionne le process de démarrage:

  • firmware> bootloader peut-être > kernel ${parameters} > initramfs> userspace peut-être

Sur un disque d'installation redhat leur système de scripts dracut est ce qui construit et constitue initramfs et leur système d'installation anaconda constitue l'espace user final.

C'est udev qui gère la configuration du périphérique – comme dans, il nomme les périphériques dans /dev . Mais cela arrive presque toujours deux fois – une fois dans initramfs et à nouveau quand init a trouvé son périphérique racine cible et est prêt à monter un devfs dessus.

Donc, voici comment cela fonctionne:

  • bootloader (ou firmware) appelle le kernel avec un jeu de parameters optionnel et une image optionnelle initramfs. Ce jeu de parameters est enregistré dans /proc/cmdline et le kernel ignore tous les parameters qu'il ne comprend pas.

  • L'initramfs est un espace user linux fonctionnel. Si son contenu est décompressé à partir d'une image qui lui a été remise lors de l'invocation ou si elle est compilée, le kernel 2.6 est toujours le premier système de files racine en fonctionnement que le kernel Linux monte. A partir de là, le kernel Linux laisse tout à l'espace user.

    • Habituellement (comme c'est le cas pour le dracut de redhat), l'initramfs ne contient que ce qui est absolument nécessaire pour find un périphérique racine et le monter sur lui-même. Généralement tout ce qui est inclus est busybox et les modules du kernel requirejs pour monter votre périphérique racine cible.

    • Il a probablement besoin d' udev pour le faire cependant, donc udev est le plus souvent inclus – avec son propre petit set de règles.

    • Comme mentionné, initramfs est son propre petit système de files racine linux complet. Un exemple complet pourrait ressembler à: /bin /etc /dev /new_root /proc /sys init . Il n'y a généralement rien de très inhabituel dans le contenu de ces directorys – il y a presque toujours un /bin/sh et un /etc/fstab .

    • La plupart des init s parsingront /proc/cmdline pour tous les parameters du kernel qu'ils pourraient interpréter. Le plus courant est root=/dev/somedisk ou root=UUID=somediskUUID ou root=LABEL=somedisklabel . C'est l'initramfs init qui interprète ces parameters root=... – pas le kernel ou l' init final exécuté plus tard (bien que le dernier puisse très bien interpréter les autres) . Il accepte ce paramètre et le monte sur /new_root (ou le nom qu'il utilise pour le assembly switchroot avant sa switchroot ) . Si udev est inclus dans initramfs, c'est le rěglěne initramfs qui děcide du nom de l'entrěe /dev/... ce disque cible, mais cela peut changer.

    • Lorsque initramfs init réussit à find et à monter le périphérique /new_root , il search habituellement quelque chose à exec – habituellement /new_root/bin/init – donc tout ce programme devient pid 1. Il le fait généralement avec le programme switch_root fourni avec busybox – qui fait un exec tout en montant simultanément /new_root over / . Son process est décrit dans le kernel docs ainsi :

    Mais initramfs est rootfs: vous ne pouvez ni pivot_root root, ni le umount . Au lieu de cela, supprimez tout de rootfs pour libérer de l'espace ( find -xdev / -exec rm '{}' ';' ) , surmonter rootfs avec la nouvelle racine ( cd /newmount; mount --move . /; chroot . attachez stdin/stdout/stderr à la nouvelle /dev/console , et exec le nouvel init .

  • Le périphérique racine init juste exécuté doit maintenant remplir son propre système de files racine. Il appelle son udev et monte ses propres devfs sur /dev fonction de ses propres règles et fait tout le rest. Quand c'est fini, vous êtes prêt à utiliser votre ordinateur.

Désolé pour le niveau de détail là-bas, mais je voulais clarifier pourquoi ce qui suit est vrai:

  • n'importe quel paramètre du kernel que vous entrez depuis le bootloader comme root=/dev/sda ne doit pas nécessairement être le même /dev/sda que vous aurez éventuellement access sur /dev/sda après le début de initramfs /init .

Donc, une façon de le faire, je pense, est de définir une règle udev sur votre disque anaconda – qui est en fait une archive squashfs, probablement – qui l'instruit pour installer tous les disques USB ailleurs. Il y a un excellent exemple ici:

 KERNEL=="sd*", SUBSYSTEMS=="scsi", ATTRS{model}=="USB 2.0 Storage Device", SYMLINK+="usbhd%n" 

Et ce serait une très bonne chose si vous lisez le rest de ce lien. Vous devriez être en mesure de le faire afin que votre périphérique de disque USB soit /dev/sda pour initramfs – vous n'avez donc pas besoin de changer les configurations du bootloader – mais ensuite /dev/usba un noeud pour le même disque que /dev/usba pour l'anaconda installer le système.

aller dans le BIOS de l'hôte et réorganiser l'ordre des disques durs et des lecteurs amovibles. Cela ajustera l'ordre tel qu'il apparaît au kernel Linux.

Sur mon ordinateur portable HP G60 neuf mais ancien $ 45 HP j'ai eu le même problème. J'ai fait passer USB de /dev/sda à /dev/sdb en plaçant le nouveau SSD en premier dans l'ordre de démarrage. Ensuite, au démarrage, appuyez sur ESC comme vous allez dans le BIOS mais il y a un menu preBIOS. Donc, au lieu de bash F10 pour entrer dans le BIOS, j'ai appuyé sur F9 pour les options de démarrage. Ensuite, vous pouvez manuellement choisir de démarrer à partir de l'USB indépendamment de l'ordre de démarrage défini dans le BIOS. Évidemment, j'ai choisi l'USB et puis sur l'installation mon SSD montrait sous /dev/sda .

J'ai cherché et cherché et beaucoup de gens ont des problèmes similaires mais personne n'a suggéré cela. Beaucoup plus simple que tout ce que j'ai trouvé. J'ai découvert ça sur une intuition.

A partir de RHEL6, vous pouvez utiliser des libellés pour votre support d'installation de sorte que vous ayez access au lecteur / hd par un nom unique et non par le nommage incohérent du sdX du kernel.

Lorsque vous créez les filesystems sur votre lecteur USB, assurez-vous de les étiqueter avec quelque chose comme e2label ou les 101 autres façons d'étiqueter le système de files.

Une fois étiquetée, vous pouvez accéder à l'USB par ce nom ex: ks = hd: LABEL = votre nom: /path/vers/fs.ks

Gardez également à l'esprit que ce type de nommage peut également être utilisé pour d'autres locations. installer des médias, des repos, etc …