Forum Astuces.divers broken symbolic link : impossible d'ouvrir /dev/root92: Aucun fichier

Posté par  . Licence CC By‑SA.
Étiquettes :
-5
29
mai
2022

l'objectif est de taper simplement

on copie la ferme by-label dans /dev
#for a in /dev/disk/by-label/*;do ln -f `{mathjax} a /dev/`(basename $a);done

on teste un label de la ferme

#fdisk -l /dev/root92 
fdisk: impossible d'ouvrir /dev/root92: Aucun fichier ou dossier de ce type

le label copié dans /dev n'est pas reconnu

diff /dev/root92 /dev/by-label/root92 
diff: /dev/root92: Aucun fichier ou dossier de ce type

les labels pointent vers le même fichier

ls -l /dev/root92 /dev/by-label/root92 
lrwxrwxrwx 2 root root 10 mai   29 17:45 /dev/by-label/root92 -> ../../sda3
lrwxrwxrwx 2 root root 10 mai   29 17:45 /dev/root92 -> ../../sda3

les labels ont le même inode

ls -li /dev/root92 /dev/by-label/root92 
1587977 lrwxrwxrwx 2 root root 10 mai   29 17:45 /dev/by-label/root92 -> ../../sda3
1587977 lrwxrwxrwx 2 root root 10 mai   29 17:45 /dev/root92 -> ../../sda3

le label copié dans dev est un lien cassé

file /dev/root92 /dev/by-label/root92 
/dev/root92:          broken symbolic link to ../../sda3
/dev/by-label/root92: symbolic link to ../../sda3

l'explication peut se trouver dans ce document

http://tvaira.free.fr/os/tpOS-7-SystemesDeFichiers.pdf

mais le document ne dit pas comment contourner le problème

mes réflexions :

https://www.facebook.com/patrick.trauquesegues/posts/2351599808316446?__cft__[0]=AZVnSGbF0k9kf7q25vIgsQ5bSI_JiYQpCPgk3G8MEBZWbt8lu2fzqAtUU9zSKvnEEUZAVSwsZXgT_20cpviZ0p-h7QMqamcO-KiHRXhcHYaynhSo0CJfbgE37rZ8icZUoSG2NycUlnH_fsj0FgqVOU9R&__tn__=%2CO%2CP-R

"pdf : Clavier
Erreur
Les éléments cliquables doivent pouvoir obtenir le focus et avoir une sémantique interactive. En savoir plus"
https://developer.mozilla.org/docs/Web/Accessibility/Understanding_WCAG/Keyboard?utm_source=devtools&utm_medium=a11y-panel-checks-keyboard#Focusable_elements_should_have_interactive_semantics
"Redémarrez pour continuer à utiliser Nightly

Une mise à jour de Nightly a démarré en arrière-plan. Vous devrez redémarrer pour terminer la mise à jour.

Vos fenêtres et onglets seront rapidement restaurés, sauf les privés."

LICENSES PRÉSENTES DANS LE DOCUMENT MENTIONNÉ :

<!--
Copyright 2012 Mozilla Foundation

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

Adobe CMap resources are covered by their own copyright but the same license:

Copyright 1990-2015 Adobe Systems Incorporated.
See https://github.com/adobe-type-tools/cmap-resources
-->

tpOS7SystemesDeFichiers.odt ♦ 27/08/2010 rev.11  thierry.vaira@orange.fr
2
Copyright 2010 tv thierry.vaira@orange.fr
Permission is granted to copy, distribute and/or modify this document under the
terms of the GNU Free Documentation License,
Version 1.1 or any later version published by the Free Software Foundation; with no
Invariant Sections, with no FrontCover Texts, and with no BackCover.
You can obtain a copy of the GNU General Public License : write to the Free
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 021111307
USA

Des erreurs sont possibles.

  • # faut pas poster…

    Posté par  . Évalué à 5.

    … après la cueillette des champignons en forêt du dimanche: on a manifestement pas les idées claires.

  • # une solution au problème possible

    Posté par  . Évalué à -2.

    En fonction des branchements des disques durs, les noms de fichiers peuvent varier
    pour faciliter l'identification des disques, il est possible de leur fournir un identifiant unique appelé "UUID", ou une étiquette appelée "LABEL", /dev/sd?3 conduisait à "root92" pour l'exemple.

    Le problème était de simplifier l'accès au fichier par le "LABEL" sans avoir à saisir le long chemin pour y accéder, rangé dans /dev : /dev/root92, à la place de /dev/disks/by-label/root92 ou /dev/by-label/root92 .

    La commande "file" détermine le type de fichier, et fournit le nom du fichier du disque ayant le label "root92".

    file /dev/by-label/root92 
    /dev/by-label/root92: symbolic link to ../../sda3
    

    On apprend que ce fichier est sda3.
    La commande "cat" renvoie le contenu du fichier et fournit les adresses MAJEUR et MINEUR du périphérique recherché.

    cat /sys/block/sda/sda3/dev
    8:3
    

    On apprend que les MAJEUR et MINEUR de root92 (ou pour cette fois sda3) sont 8 et 3.
    La commande "mknod" cré les fichiers disques (fichier bloc dans notre cas)
    On peut donc créer un fichier appelé /dev/root92 qui pourra être appelé indifféremment du fichier /dev/sd?3.

    mknod /dev/root92 b 8 3
    file /dev/root92 
    /dev/root92: block special (8/3)
    

    Quelques tests pour vérifier le résultat obtenu.

    La commande "stat" affiche diverses informations sur un fichier (l'"état" du fichier).

    stat /dev/sda3
    Fichier : /dev/sda3
    Taille : 0 Blocs : 0 Blocs d'E/S : 4096 fichier spécial de bloc
    Périphérique : 6h/6d Inœud : 15386 Liens : 1 Type de périph. : 8,3
    Accès : (0660/brw-rw----) UID : ( 0/ root) GID : ( 6/ disk)
    Accès : 2022-05-31 02:31:22.594352811 +0200
    Modif. : 2022-05-29 17:45:00.958762697 +0200
    Changt : 2022-05-29 17:45:00.958762697 +0200
    Créé : -

    stat /dev/root92
    Fichier : /dev/root92
    Taille : 0 Blocs : 0 Blocs d'E/S : 4096 fichier spécial de bloc
    Périphérique : 6h/6d Inœud : 2964121 Liens : 1 Type de périph. : 8,3
    Accès : (0644/brw-r--r--) UID : ( 0/ root) GID : ( 0/ root)
    Accès : 2022-05-31 02:56:02.437563935 +0200
    Modif. : 2022-05-31 02:56:02.437563935 +0200
    Changt : 2022-05-31 02:56:02.437563935 +0200
    Créé : -

    Les 2 noms de fichiers renvoient bien les mêmes résultats.
    Mis à part:
    - les permissions qui n'ont pas été précisées et sont donc standard, sans tenir compte de leur fonction dans le système,
    - leur inode qui est différent
    - le contenu des inodes qui sont donc aussi différents

    La commande "ls" permet lister le contenu de répertoires et affiche diverses informations sur les fichiers à partir des inodes (les répertoires sont aussi des fichiers)

    ls -ldi /dev
    1025 drwxr-xr-x 18 root root 3820 mai 31 02:56 /dev

    ls -li /dev/sda3 /dev/root92
    2964121 brw-r--r-- 1 root root 8, 3 mai 31 02:56 /dev/root92
    15386 brw-rw---- 1 root disk 8, 3 mai 29 17:45 /dev/sda3

    ls -ld /root /mnt/7
    drwxr-xr-x 31 root root 4096 mai 29 17:36 /mnt/7
    drwx------ 14 root root 4096 mai 31 04:08 /root

    Je ne sais pas expliquer pourquoi la liste est inversée : le fichier sda3 ou root est toujours affiché en dernier.

    La commande "df" indique l'espace occupé et divers autres indications.

    Avant montage du système de fichiers root92 :

    df -hT /dev/sda3 /dev/root92 /mnt/7
    Sys. de fichiers Type     Taille Utilisé Dispo Uti% Monté sur
    /dev/sda3        xfs         84G     65G   20G  77% /
    udev             devtmpfs   7,7G       0  7,7G   0% /dev
    /dev/sda3        xfs         84G     65G   20G  77% /
    

    Après montage du système de fichiers root92 (sur /mnt/7)

    df -hT /dev/sda3 /dev/root92 /mnt/7
    Sys. de fichiers Type Taille Utilisé Dispo Uti% Monté sur
    /dev/sda3        xfs     84G     65G   20G  77% /
    /dev/root92      xfs     84G     65G   20G  77% /mnt/7
    /dev/root92      xfs     84G     65G   20G  77% /mnt/7
    

    La commande "xfs_info" fournit des informations sur les systèmes de fichiers xfs.

    xfs_info /dev/sda3 >sda3
    xfs_info /dev/root92 >root92
    diff sda3 root92
    

    Les résultats sont bien identiques.

    La commande "fdisk -l" fournit des informations sur le partitionnement des disques.

    fdisk -l /dev/sda3 >sda3
    fdisk -l /dev/root92 >root92
    diff sda3 root92
    1c1
    < Disque /dev/sda3 : 83,9 GiB, 90033881088 octets, 175847424 secteurs
    ---
    > Disque /dev/root92 : 83,9 GiB, 90033881088 octets, 175847424 secteurs
    

    Les résultats sont bien identiques, sauf le nom des fichiers.

    En conclusion,

    Il serait intéressant de pouvoir automatiser la créations fichiers nommés par leur label, à partir d'un script à lancer avant de manipuler les disques appelés par leur LABEL.
    Je n'ai pas essayé.

    L'objectif de cette recherche était de rafraîchir mes connaissances avant de réorganiser les systèmes informatiques utilisés, après plusieurs années à faire autre chose. Cette fiche de révision sera peut-être utile à d'autres.

    Merci à Pierre qui a tenté d'apporter une réponse malgré une intoxication alimentaire ce WE en chassant le champignon dans ses bois.

    Des erreurs sont possibles.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.