Comment échanger / dev / sda avec / dev / sdb?
C'est ça. une. banal. question, et pourtant personne ne semble pouvoir y répondre correctement.
Comment échanger/dev/sda avec/dev/sdb?
Quelqu'un peut suggérer d'utiliser un étiquetage permanent (par exemple./Dev/disk/by- *), mais malgré les meilleures intentions, cela ne fait [~ # ~] pas [~ # ~] répondre à la question. Oui, les étiquettes permanentes fonctionnent là où vous pouvez les utiliser, mais si un programme est codé en dur à utiliser, par exemple./dev/sda, cette question persiste.
Pour illustrer le problème plus loin de ce que j'ai trouvé sur Internet: http://ubuntuforums.org/showthread.php?t=1569238&page=2 (me rappelle "Schadenfreude")
Ce type semble avoir trouvé la solution, il ne l'a tout simplement pas partagée (boo!): http://ubuntuforums.org/showthread.php?t=944515
Et tbh, j'ai un danger similaire potentiel. J'utilise CloneZilla, et si un programme demande: Would you like to backup /dev/sda to /dev/sdb or /dev/sdb to /dev/sda ?, devinez à quel point je deviens nerveux en sachant que Linux semble assigner au hasard les commandes de disque. Je n'ai pas encore écrasé mes données avec ma propre sauvegarde, mais cela ne fait qu'attendre.
Qu'est-ce qui sous Linux affecte/dev/sd * aux disques, et comment influencez-vous ce processus? Cela a-t-il quelque chose à voir avec udev (/ etc/udev /, udevadm)? Mon système d'exploitation est CentOS, mais je dois le savoir aussi pour Ubuntu et CloneZilla ( http://clonezilla.org ), et ce problème se produit sur tous les systèmes, donc je suppose que ce problème n'est pas liés à la distribution, mais plutôt au noyau, aux modules du noyau, ou à quelque chose de très proche du noyau. Aidez-moi!
------------------ EDIT: 25 août 2013 Après avoir informé le lien que ypnos a donné, j'ai lisez tout, essayé une commande, et le noyau juste "vommitted" udev règne sur tout mon écran. Vous êtes ensuite invité à saisir le mot de passe root pour autoriser la maintenance ou à quitter pour redémarrer. C'est la preuve que ce truc n'est en effet pas pour la personne novice.
J'ai également cherché un peu plus loin. Je ne comprends pas comment ni quand le noyau Linux se charge, mais plusieurs messages sur Internet indiquent que le BIOS (!! croyez-le ou non) transmet la liste des disques de démarrage à grub, qui utilise ensuite le fichier device.map pour assigner quels appareils à quel grub (hd *, ). Notez que/dev/sd ont déjà été définis à ce stade, car vous pouvez utiliser des liens symboliques de développement permanents. Ces cartes de périphériques semblent en quelque sorte passer au système de fichiers racine réel. Alors, est-ce une chose bootloader maintenant?
Pour en revenir à l'udev comme solution potentielle, j'ai trouvé un rapport de bug sur google http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578826 , qui a abouti à une résolution où il a été déconseillé de changer le NOM udev (qui deviendra finalement/dev/sd * tel que nous le connaissons).
Pour les pages udev suggérées MAN:
| The following keys can get values assigned:
|
| NAME
| The name of the node to be created, or the name the network
| interface should be renamed to.
NOTE: changing the kernel-provided name of device nodes
(except for network devices) is not supported and can result
in unexpected behavior.
Today, the kernel defines the device nodes names, and udev
is expected to only manage the node's permissions and
additional symlinks.
... Mais je suis quand même sorti pour le faire de façon légèrement modifiée.
# vi /etc/udev/rules.d/00-corrections.rules
KERNEL=="sd?", ATTRS{model}=="SAMSUNG SP0411N", NAME="sda"
KERNEL=="sd??", ATTRS{model}=="SAMSUNG SP0411N", NAME="sda%n"
KERNEL=="sda", ATTRS{model}!="SAMSUNG SP0411N", NAME="sdb"
KERNEL=="sda?", ATTRS{model}!="SAMSUNG SP0411N", NAME="sdb%n"
Essentiellement, ce qu'il fait est "Si le modèle est samsung, attribuez-lui NAME sda *. Si le modèle n'est pas Samsung, mais a été affecté sda *, attribuez-lui NAME sdb *." Cette règle a été placée avant toutes les autres règles autant que possible. Notez que je ne suis pas sûr de cela, car il semble y avoir également des fichiers de règles `` invisibles '', ET bien que vous ayez renommé les périphériques, le noyau quelque part dans `` mémoire chargée par le noyau '', peut encore avoir des références erronées. Cela peut être évident lorsque vous regardez le fichier /var/log/boot.log, où dans mon cas, le début dit:
%G Welcome to [0;36mCentOS[0;39m
Starting udev: %G[60G[[0;32m OK [0;39m]Setting hostname UncleFloServer: [60G[[0;32m OK [0;39m]ERROR: asr: seeking device "/dev/sda" to 5999998795264
ERROR: ddf1: seeking device "/dev/sda" to 5999998795264
ERROR: ddf1: seeking device "/dev/sda" to 5999998664192
ERROR: hpt45x: seeking device "/dev/sda" to 5999998790144
ERROR: isw: seeking device "/dev/sda" to 5999998794752
ERROR: jmicron: seeking device "/dev/sda" to 5999998795264
ERROR: lsi: seeking device "/dev/sda" to 5999998795264
ERROR: nvidia: seeking device "/dev/sda" to 5999998794752
ERROR: pdc: seeking device "/dev/sda" to 137438913024
ERROR: pdc: seeking device "/dev/sda" to 137438920192
ERROR: pdc: seeking device "/dev/sda" to 137438927360
ERROR: pdc: seeking device "/dev/sda" to 137438934528
ERROR: sil: seeking device "/dev/sda" to 5999998795264
ERROR: via: seeking device "/dev/sda" to 5999998795264
Setting up Logical Volume Management: No volume groups found
[60G[[0;32m OK [0;39m]Checking filesystems
_CentOS-6.4-x86_: clean, 85517/655360 files, 662649/2621440 blocks
/dev/sda1: clean, 56/65536 files, 33367/262144 blocks
[60G[[0;32m OK [0;39m]Remounting root filesystem in read-write mode: [60G[[0;32m OK [0;39m]Mounting local filesystems: [60G[[0;32m OK [0;39m]Enabling local filesystem quotas: [60G[[0;32m OK [0;39m]Enabling /etc/fstab swaps: [60G[[0;32m OK [0;39m]
Ici, mon appareil Samsung fait 40 Go (que j'aimerais sous/dev/sda), et mon grand Areca Raid est 6 To (que j'aimerais sous/dev/sdb).
Certaines questions restent en suspens
Que signifient les erreurs?
Ces erreurs sont-elles la cause du noyau ou la cause d'un fichier de règles toujours en cours d'exécution avant mes 00-corrections.rules d'udev?
Ces erreurs indiquent-elles que quelque chose menace les données? La partition Areca n'a monté aucun problème sur l'un de mes dossiers dans fstab.
Existe-t-il une meilleure méthode d’attribution des appareils plus ancienne?
De nos jours, le noyau Linux remplit/dev/dynamiquement selon les règles UDEV.
Permettez-moi d'abord d'expliquer le fonctionnement des fichiers de périphérique. Chaque fichier de périphérique, généralement un fichier de périphérique de bloc, a un numéro majeur et un numéro mineur. Ces chiffres décrivent réellement le périphérique vers lequel pointe le fichier. Le nom n'y joue aucun rôle. Jetons un coup d'œil à notre cas spécifique de disques:
# ls -l sd*
brw-rw---- 1 root disk 8, 0 Aug 22 15:45 sda
brw-rw---- 1 root disk 8, 1 Aug 22 15:45 sda1
brw-rw---- 1 root disk 8, 2 Aug 22 15:45 sda2
brw-rw---- 1 root disk 8, 3 Aug 22 15:45 sda3
brw-rw---- 1 root disk 8, 5 Aug 22 15:45 sda5
brw-rw---- 1 root disk 8, 6 Aug 22 15:45 sda6
Ici vous voyez que mon premier disque a plusieurs partitions et que j'ai démarré le 22 août à 15h, c'est à ce moment que le noyau a créé les fichiers selon les règles. Vous pouvez également voir que le nombre majeur est 8 et que les nombres mineurs sont utilisés pour accéder aux partitions (0 pointant vers le disque entier). Le "b" au début de chaque ligne indique que chacun d'eux est un fichier spécial "périphérique de bloc".
Comme je l'ai dit, le noyau crée les fichiers dynamiquement "ces jours-ci". Ce n'était pas toujours comme ça et ce n'est pas comme ça sur d'autres systèmes Unix. Là, les fichiers seraient créés de manière statique et l'utilisateur créerait ou manipulerait ces fichiers.
Il est parfaitement possible de créer vos propres fichiers de périphérique, avec votre propre nom et des numéros majeurs/mineurs. Voir mknod (man mknod) pour ça. Cependant, après avoir redémarré, vos fichiers personnalisés disparaîtront.
La deuxième possibilité est de changer les règles UDEV. Les règles seront traitées lors du démarrage du système et vous garantissent un comportement cohérent en permanence. Un bon guide sur ces règles peut être trouvé ici: http://www.reactivated.net/writing_udev_rules.html
Vous verrez qu'il est possible de définir une règle qui crée "sda *" en fonction des informations matérielles spécifiques qui correspondent à votre appareil. Vous devrez remplacer les règles d'origine qui créeraient sda par les vôtres. Le fonctionnement dépend de votre distribution.
Comme je pense que c'est une entreprise dangereuse pour le novice, je ne vous expliquerai pas les étapes spécifiques; le document que j'ai lié ci-dessus vous donnera toutes les informations dont vous avez besoin, et vous devriez en effet les lire toutes.