26 septembre 2019 16:40 "Matthieu GIRARD-COLIN" <mgirard2...@gmail.com> a écrit:
> Oui ce message est présent et le lien symbolique existe que le disque soit
> branché ou non,
> toutefois il est cassé
>
> # ls -l /sys/class/block/
> lrwxrwxrwx 1 root root 0 sept. 26 15:06 sda ->
> ../../devices/pci0000:00/0000:00:01.3/0000:03:00.1/ata1/host0/target0:0:0/0:0:0:0/block/sda
> lrwxrwxrwx 1 root root 0 sept. 26 15:06 sda1 ->
> ../../devices/pci0000:00/0000:00:01.3/0000:03:00.1/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda1
> lrwxrwxrwx 1 root root 0 sept. 26 15:06 sda2 ->
> ../../devices/pci0000:00/0000:00:01.3/0000:03:00.1/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda2
> lrwxrwxrwx 1 root root 0 sept. 26 15:06 sdb1 ->
> ../../devices/pci0000:00/0000:00:01.3/0000:03:00.0/usb2/2-1/2-1:1.0/host9/target9:0:0/9:0:0:0/block/
> db/sdb1
> Logiquement le problème
> viendrais donc du lien symbolique mais il s'agit d'un fichier protégé en
> écriture même pour root
> donc pas moyen de le virer..
Je ne sais pas bien comment /sys est rempli…
Il y a des unités Systemd associées :
systemctl list-units | grep sdb1
Apparemment les stopper ne nettoie pas /sys, mais tu peux essayer chez toi :
sudo systemctl stop <unite-trouvée-par-la-commande-précédente>.service
Et au reboot, le lien est présent ?
Sébastien
