Impossible de démonter disque dur

Support Debian
#11

Bonjour Headstorm

Avec “le DD” rebranché, quel est le retour de la commande suivante ?

su -c 'lsblk -o TYPE,SIZE,NAME,FSTYPE,UUID,LABEL,MOUNTPOINT'
#12

Il n’y a pas de message d’erreur avant l’entrée en mode emergency ci-joint une capture d’écran

#13

Bonjour, voici le retour de commande

TYPE SIZE NAME FSTYPE UUID LABEL MOUNTPOINT
disk 698,7G sda
part 690,7G ├─sda1 ext4 a330e5b8-9bc5-4b1a-8396-25fb1109ef3a /
part 1K ├─sda2
part 8G └─sda5 swap 7a555451-603b-43c0-87ab-30cc2f7ca4c6 [SWAP]
disk 931,5G sdb
part 128M ├─sdb1
part 443,1G ├─sdb2 ext4 6f8f019b-acb3-4cec-b235-6a721ea8c7bb Drive A

part 488,3G └─sdb3 ext4 5a55f1ff-b84c-4d89-ad01-eb10204d7632 Drive B - INT 2

disk 931,5G sdc ext4 da0d50c0-758f-4371-826d-867706b6d3e3 /mnt/datac
disk 298,1G sdd
part 298,1G └─sdd1 ntfs C2C437ADC437A299
disk 465,8G sde
part 465,8G └─sde1 ext4 6d5e7ebf-c06f-454c-a1f7-455813126c46 SAVE Data -
/mnt/SAVE
rom 1024M sr0
rom 1024M sr1

#14

Même en remontant plus haut dans les messages avec Shift+PgUp ? Le système ne se met pas tout seul en mode dépannage…
Et si tu fais sysctctl default comme suggéré pour entrer en mode par défaut ?

PS : le contenu de /etc/fstab ?
/dev/sdc est-il identifié par son nom de périphérique ou son UUID ?
Quand sdb est retiré, sdc devient sdb donc il faut utiliser l’UUID.

#15

si je fait systemctl default ca revient sur le meme etat

mon fstab:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=a330e5b8-9bc5-4b1a-8396-25fb1109ef3a /               ext4    errors=remount-ro 0       1
# swap was on /dev/sda5 during installation
UUID=7a555451-603b-43c0-87ab-30cc2f7ca4c6 none            swap    sw              0       0
/dev/sr1        /media/cdrom0   udf,iso9660 user,noauto     0       0
/dev/sr0        /media/cdrom1   udf,iso9660 user,noauto     0       0
#/dev/sdb2 /mnt/Drive_CIA ext4 defaults,x-gvfs-show 0 0
/dev/disk/by-id/wwn-0x5000cca344ce232a-part1 /mnt/SAVE\040Data- auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=SAVE%20Data%20-,x-gvfs-icon=SAVE%20Data%20-,x-gvfs-symbolic-icon=SAVE%20Data%20- 0 0
/dev/sdc /mnt/datacloud ext4 defaults,x-gvfs-show,x-udisks-auth,x-gvfs-name=datacloud,x-gvfs-icon=datacloud,x-gvfs-symbolic-icon=datacloud 0 0
#16

Remplace /dev/sdc par son UUID.

1 J'aime
#17

Merci pour le retour de commande, mais ce retour de commande est difficile à lire car certaines fin de lignes ne sont pas visible

Peut-être que le retour de la commande mount (toujours avec le “DD” rebranché) nous en dira plus.

Je me suis permis de modifier la présentation du retour de commande qui a permis de lister le contenu du fichier /etc/fstab dans ton dernier message en le faisant précéder et suivre d’une ligne ne contenant qu’une suite de 3 caractères “backticks” :

#18

Je viens de remplacer /dev/sdc par son UUID et le problème est résolu, c’était donc du au nommage des disque, étant donné que b était plus la, le système ne comprnait pas pourquoi il y avait c sans b je présume…

Merci en tous cas du temps accordé :slight_smile:

1 J'aime
#19

Étant donné que le disque qui utilisait /dev/sdb a été déconnecté,
le disque qui était accessible par le fichier de périphérique /dev/sdc est maintenant accessible par /dev/sdb

2 J'aime
#20

merci, je me souviendrais de cette manipulation pour mes prochains post. merci de l’aide et du temps accordé a résoudre mon problème. :slight_smile:

1 J'aime
#21

Oui. Quand il y a plusieurs “disques” (au sens large), le nommage des périphériques /dev/sdX se fait dans l’ordre de leur découverte et n’est pas forcément persistant. C’est pourquoi il ne faut pas utiliser les noms de périphériques mais des identifiants persistants comme l’UUID.

Non. Le disque qui était anciennement nommé /dev/sdc est devenu /dev/sdb, le disque anciennement /dev/sdd est devenu /dev/sdc mais il ne contient pas directement un système de fichiers puisqu’il est partitionné, donc le montage de /dev/sdc demandé dans /etc/fstab échouait.

1 J'aime
#22

merci de ces explications, je comprends mieux l’intérêt des identifiants et surtout le mécanisme de répertoriage des lecteurs.

#23

La vitesse à laquelle les disques répondront au BIOS au moment de la détection de ce type de périphériques
détermine le nom du fichier de périphérique qui sera utilisé.

Donc, si un jour tu installe un nouveau disque qui réponds plus vite que les autres …

Du coup, il vaut mieux utiliser l’UUID du système de fichiers à mounter,
comme l’indique l’en-tête du fichier /etc/fstab

…
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
…

Traduction approximative :

Utilisez la commande blkid pour afficher l’IDdentifiant Unique Universel (UUID) pour un périphérique.

Utiliser l’UUID dans le fichier /etc/fstab est une méthode plus fiable de nommer les périphériques
qui fonctionnera même si des disques sont ajoutés ou/et supprimés.

Lire la page man de fstab
avec la ligne commande suivante :

man 5 fstab
#24

il va donc se répertorier plus vite et se trouver “mieux” classé…

#25

Le BIOS n’intervient pas dans l’ordre d’énumération et de nommage des disques par le noyau Linux.

#26

Un petit peu quand même puisque c’est par une option du BIOS qu’on peut encore choisir le périphérique depuis lequel la machine va lancer le chargeur de boot,
que la liste des périphériques proposée dans le BIOS est ordonée suivant leur rapidité de réponse à la détection des périphériques accessibles,
et que c’est quand même le BIOS qui initialise et préconfigure tous les composants de la machine (contrôleurs SATA et autres compris) , même si le système d’exploitation essaye (parfois en vain) de remettre tout ça dans l’ordre qui lui va bien.

Ceci dit, je n’utilise pas l’UEFI, alors peut-être que suivant l’UEFI de la machine utilisé…

#27

Non. Le disque de boot sélectionné par le BIOS a le numéro 0 (hd0 dans GRUB), mais cela n’affecte pas la numérotation des disques par Linux. A noter que le disque sur lequel se trouve l’exécutable EFI sélectionné par un firmware UEFI n’a pas forcément le numéro 0.

Je n’ai jamais observé cela.

Non, pas forcément. Par exemple, quand on règle un périphérique ATA comme “none” dans le BIOS, généralement Linux le détecte quand même. Et les BIOS ont un réglage “PnP OS” qui sert à éviter que le BIOS initialise certains périphériques.

#28

Heureusement que ça ne fonctionne pô comme cela… Sinon ce serait un bô bazar… :slight_smile:

J’ignore comment la vitesse de détection a pu faire référence dans ce domaine. Elle n’a rien à voir. C’est lié aux différents contrôleurs, à l’ordre de ces contrôleurs dans le bios, à leur fonctionnement allumé ou éteint par configuration, et à la présence ou non d’un ou plusieurs disques branchés sur les ports gérés par ces contrôleurs, que l’on obtient l’énumération ‘de base’ sous Linux.

Mais sinon, par les UUID, on peut “shunter” cela, comme vient de le prouver PascalHambourg sur ce topic.

Si la rapidité de réponse était déterminante pour l’ordonnancement, on pourrait se retrouver avec des systèmes instables sans raisons apparentes. /dev/sdb deviendrait /dev/sda parce qu’il a répondu plus vite aujourd’hui. Mais demain /dev/sda reprendra sa place parce que /dev/sdb va avoir une quinte de toux…

Ca pourrait me faire arrêter l’informatique des trucs pareils :smile:

Et encore… J’ai utilisé /dev/sda et /dev/sdb par abus de langage. Car on parle bien d’ordonnancement du BIOS et non dans Linux.

#29

L’histoire m’était arrivé, mais je n’ai plus les disques qu’il me faut pour reproduire le problème.

EDIT: Je me souviens aussi entre temps avoir fait une mise à jour du BIOS de ma machine, et n,'ai plus jamais rencontré ce problème, qui d’ailleurs avait été vite résolu car il me semblait évident d’utiliser les UUID des systèmes de fichier à mounter, comme cela était conseillé dans les commentaires du fichier /etc/fstab

Alors j’ai cherché un peu sur la toile:

https://wiki.archlinux.org/index.php/Persistent_block_device_naming
…This may result in device names like /dev/sda and /dev/sdb switching around on each boot…


…The boot disk is now randomly called sda, sde or sdi…

http://www.linuxquestions.org/questions/slackware-14/sda-drive-to-sdb-so-new-hdd-can-become-sda-4175497287/#post5130188
…Keeping the order might be possible but that depends on many details such as interface type (IDE/SATA/SCSI), disk start up time, and the firmware of motherboard.…

https://access.redhat.com/solutions/67778
…After the system was booted up, the internal disk on the server were changed to /dev/sdb while the external disks on the fiber storage were now /dev/sda.…

http://www.linuxquestions.org/questions/linux-software-2/drive-designations-change-randomly-sda-vs-sdb-vs-sdc-4175587058/#post5590859
…My drive designations change randomly. I’m not doing anything between when they change (like moving cables, changing BIOS, update-grub, etc.) None of that. Just a simple reboot.…

Mais je n’ai pas retrouvé l’article super que j’avais lu à ce sujet.
Je reviendrais ajouter le lien ici dès que je retombe dessus.

#30

Ouf. Gros abus et grosse confusion en effet, car jusqu’à cette phrase je croyais que tu parlais de Linux, pour lequel tout ce que tu as écrit est effectivement susceptible de se produire.