Impossible de démonter disque dur

Bonjour à tous,

Je suis sur Jessie et j’ai un probleme avec le démontage d’un disque dur, je m’explique:
j’ai un disque dur défectueux et dois le retirer physiquement du serveur.
Le disque était partitionné ainsi /dev/sdb1 500go ext4 et /dev/sdb2 500go ext4, le point de montage était sur /mnt/…
j’ai démonté les partition avec umount /mnt/… et /dev/sdb… , j’ai modifié le fstab pour supprimer le point de montage.
lorsque je reboot en ayant retiré physiquement le DD, debian ne se lance pas et reste en erreur, alors que si je reboot en rebranchant le DD, j’ai aucun soucis.

Je ne comprends pas pourquoi cette erreur, ai-je oublié de faire quelque chose pour le démontage du DD?

merci de votre aide.

Quelle erreur exactement ?

lorsque je reboot, je passe en mode emergency

lorsque j’ouvre les log, j’ai “failed at step EXEC spawning /bin/plymouth: No such file or directory”

le processus /bin/plymouth n’a pas pu démarrer et a donc echoué…

je veux pas dire de bêtises mais si grub était sur sdb alors debian ne pourra plus se lancer, il faut un grub sur sda.

Quels logs ?
Il n’y a pas de message d’erreur affiché lorsque Debian ne démarre pas ?
Qu’appelles-tu “mode emergency” ?
/bin est sur la racine, donc si plymouth est censé s’y trouver mais n’y est pas, ce n’est pas la bonne racine.

Je ne comprends pas pourquoi grub se trouverait sur sdb, le système lui se trouve sur sda… comment localiser grub? comment le déplacer?

Débian démarre partiellement, il s’arrête à la phase de démarrage des services, il y est inscrit Welcome to emergency mode, il propose de se loguer en root et de consulter journalctl.
le système debian ainsi que le swap se trouve sur sda, je ne comprends pas pourquoi /bin se trouverait sur un autre disque, je n’ai pas fais ce type de configuration lors de l’installation ni même depuis

Spontanément lors du démarrage en mode normal, ou lors du démarrage en mode dépannage ?

lors d’un demarrage en mode normal mais uniquement quand de dd est déconecté

Quels sont les message d’erreur affichés avant (et cause de) l’entrée en mode emergency ?

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'

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

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

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.

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

Remplace /dev/sdc par son UUID.

1 J'aime

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” :

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

É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

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