Clé USB corrompue et indémontable...

samprzyswa · Le 12/02/2023, à 17:10

Bonjour,

Suite à une coupure de courant je me retrouve avec une clé USB corrompue qui se monte automatiquement quand je la plug et qui devient indémontable même avec la commande "umount --force /media/repertoire" donc impossible de la reformater, le système me dit que le répertoire est utilisé.

Comment éviter qu'elle se monte automatiquement ou comment vraiment forcer le umount ?

Merci d'avance de votre aide.

Sam.

Dernière modification par samprzyswa (Le 12/02/2023, à 19:02)

matrix-bx · Le 12/02/2023, à 17:25

Salut,
après avoir testé avec une clef, j'obtiens le résultat attendu (la clef n'est pas montée automatiquement) en ajoutant cette ligne dans /etc/fsab

/dev/sda1 none vfat errors=remount-ro 0 2

À adapter en fonction du nom de ton périphérique et du type de système de fichier.
Ne pas oublier d'enlever la ligne une fois terminé.

Dernière modification par matrix-bx (Le 12/02/2023, à 17:48)

samprzyswa · Le 12/02/2023, à 17:34

matrix-bx a écrit :

Salut,
après avoir testé avec une clef, j'obtiens le résultat attendu (la clef n'est pas montée automatiquement) en ajoutant cette ligne dans /etc/fsab
/dev/sda1 none vfat errors=remount-ro 0 2
À adapter en fonction du nom de ton périphérique et du type de système de fichier.

Bingo !!!

Super merci.

Sam.

samprzyswa · Le 12/02/2023, à 19:16

...mon problème maintenant est de récupérer ma clé USB corrompue un lsblk affiche la clé avec les 5 partitions:

sdc           8:32   1  57,3G  0 disk  
├─sdc1        8:33   1   1,4M  0 part  
├─sdc2        8:34   1   977K  0 part  
├─sdc3        8:35   1 244,1M  0 part  
├─sdc4        8:36   1   2,6G  0 part  
└─sdc5        8:37   1  54,5G  0 part  
samp@jupiter:~$

Alors que j'ai supprimé ces partitions !?

Lorsque j'essaie de formater la clé USB avec Disques la clé apparaît bien SANS partitions mais n'affiche pas la taille du disque, j'ai pareil avec "fdisk /dev/sdc" qui ne voit carrément plus le device...

Comment récupérer cette clé ?

Merci de votre aide.

Sam.

Nasman · Le 13/02/2023, à 10:00

Que donne :

lsusb

sans que la clé soit branchée
puis

lsusb

une fois que la clé a été branchée.

sudo fdisk -l

sudo dd if=/dev/sdc bs=512 count=4 | hexdump -C

(en supposant que la clé corresponde toujours à sdc

samprzyswa · Le 13/02/2023, à 12:34

Nasman a écrit :

Que donne :
lsusb
sans que la clé soit branchée
puis
lsusb
une fois que la clé a été branchée.
sudo fdisk -l
sudo dd if=/dev/sdc bs=512 count=4 | hexdump -C
(en supposant que la clé corresponde toujours à sdc

root@jupiter:/home/samp# lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 003: ID 046d:c534 Logitech, Inc. Unifying Receiver
Bus 001 Device 005: ID 1462:7d18 Micro Star International MYSTIC LIGHT 
Bus 001 Device 002: ID 050d:2103 Belkin Components F7D2102 802.11n N300 Micro Wireless Adapter v3000 [Realtek RTL8192CU]
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@jupiter:/home/samp# lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 006: ID 0781:5591 SanDisk Corp. Ultra Flair
Bus 001 Device 003: ID 046d:c534 Logitech, Inc. Unifying Receiver
Bus 001 Device 005: ID 1462:7d18 Micro Star International MYSTIC LIGHT 
Bus 001 Device 002: ID 050d:2103 Belkin Components F7D2102 802.11n N300 Micro Wireless Adapter v3000 [Realtek RTL8192CU]
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@jupiter:/home/samp# exit

par contre la commande "sudo dd if=/dev/sdc bs=512 count=4 | hexdump -C" bloque et je suis obligé d'enlever la clé pour reprandre la main...

Sam.

Nasman · Le 13/02/2023, à 12:53

Que donnait le

sudo fdisk -l

?

samprzyswa · Le 13/02/2023, à 15:03

Nasman a écrit :

Que donnait le
sudo fdisk -l
?

Ça bloque et je dois débrancher la clé pour récupérer la main en fait la clé n'est pas reconnue comme un /dev/sdx alors que lsusb la voit:

samp@jupiter:~$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 010: ID 0781:5591 SanDisk Corp. Ultra Flair
Bus 001 Device 003: ID 046d:c534 Logitech, Inc. Unifying Receiver
Bus 001 Device 005: ID 1462:7d18 Micro Star International MYSTIC LIGHT 
Bus 001 Device 002: ID 050d:2103 Belkin Components F7D2102 802.11n N300 Micro Wireless Adapter v3000 [Realtek RTL8192CU]
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
samp@jupiter:~$

Et le pire c'est que Ubuntu 20.04 me fait apparaître la partition FAT32 dans le doc mais impossible de l'ouvrir ca bloque le navigateur de fichiers !?

Comment nettoyer la clé pour la remettre à zéro ?

Sam.

erresse · Le 13/02/2023, à 16:12

Bonjour,
À mon avis, tu as juste réussi à démonter ta clé avec l'astuce du message#2, mais pour autant elle n'a pas été réinitialisée...
Tu la vois dans la commande "lsusb" comme périphérique, mais rien n'est monté, sans doute le contenu est endommagé.
Si, et je crois avoir compris que c'est le cas,tu n'as rien à récupérer sur cette clé, tu peux essayer de l'écraser avec une commande :

sudo dd if=/dev/zero of=/dev/sdc count=1024

Si la commande passe, tu débranche et rebranche la clé et tu vas dans Gparted lui créer une nouvelle table de partition au format MSDOS et une ou plusieurs partitions (de préférence FAT32) pour la partitionner.
Avec un peu chance, tu dois pouvoir récupérer ta clé.

Dernière modification par erresse (Le 13/02/2023, à 16:13)

samprzyswa · Le 13/02/2023, à 17:58

erresse a écrit :

Bonjour,
À mon avis, tu as juste réussi à démonter ta clé avec l'astuce du message#2, mais pour autant elle n'a pas été réinitialisée...
Tu la vois dans la commande "lsusb" comme périphérique, mais rien n'est monté, sans doute le contenu est endommagé.

Oui c'est ça suite à une coupure de courant...

Si, et je crois avoir compris que c'est le cas,tu n'as rien à récupérer sur cette clé, tu peux essayer de l'écraser avec une commande :
sudo dd if=/dev/zero of=/dev/sdc count=1024
Si la commande passe, tu débranche et rebranche la clé et tu vas dans Gparted lui créer une nouvelle table de partition au format MSDOS et une ou plusieurs partitions (de préférence FAT32) pour la partitionner.
Avec un peu chance, tu dois pouvoir récupérer ta clé.

Oui mais la commande ne passe pas à cause de /dev/sdc introuvable qui bloque tout accès au device je dois à chaque fois le débrancher et la rebrancher pour intervenir mais actuellement tout accès sur /dev/sdc coince...

Sam.

Coeur Noir · Le 14/02/2023, à 01:57

Clé branchée, que répond :

lsblk -fe7,11 -o +size,pttype,ro    # bien agrandir la fenêtre du terminal AVANT de lancer cette commande, son retour est un tableau assez large.

Et cela depuis un terminal en mode utilisateur normal, pas en mode administrateur.

Les supports amovibles~nomades sont montés via udisksctl dans /media/$USER/label_ou_uuid_support ; quand on les démonte ( retirer en toute sécurité ) depuis une interface graphique, en fait ça joue la commande :

udisksctl unmount -b /dev/chemin/bloc/périphérique

soit probablement :

udisksctl unmount -b /dev/sdc

Cet « automatisme » peut foirer si certains fichiers cachés de ton répertoire personnel ne t'appartiennent plus OU si certains droits ont été modifiés dans /media donc à tout hasard :

find ~ ! -user $USER

et

ls -la /media/$USER

Quand tout va bien, la première ne répond rien. Sinon elle liste les éléments ne t'appartenant plus, à montrer le cas échéant pour déterminer lesquels sont à te réapproprier impérativement ( sachant qu'en théorie tout est censé t'appartenir dans /home/$USER/ puisque c'est ton répertoire personnel. )
La seconde doit montrer des ACL sur le dossier $USER ; des droits rwxr-xr-x sur le dossier media ( accessible en lecture par tout le monde ) et root:root comme propriétaires pour les 2 dossiers.

→ ça c'est juste pour éliminer un pépin logiciel~système dans la gestion du montage « automatique » de supports amovibles. Si tout va bien par là, on pourra se dire que le problème est uniquement « dans » la clé.
→ clé qui est peut-être passée en mode read-only suite au problème électrique ? ? ? D'où l'option ro dans la commande lsblk au début de ce message.

Dernière modification par Coeur Noir (Le 14/02/2023, à 01:58)

Coeur Noir · Le 14/02/2023, à 02:26

J'ajoute :

une clé USB ( peut-être ) corrompue qui se monte automatiquement quand je la plug

…le montage automatique est un comportement normal en cas de support amovible~nomade hotpluggable et

la commande "umount --force /media/repertoire"

on est d'accord que la « vraie » commande ressemblait plutôt à

sudo umount /media/samp/uuid_ou_label_de_la_clé

? Sinon c'est normal que le système te dise que /media/samp tout court ( soit /media/$USER ) est déjà utilisé car il y a probablement d'autres montages dedans, pour d'autres partitions d'autres périphériques dont les données sont en cours d'utilisation.

Éventuellement ( car rien ne dit que c'est ce que tu as fait ) c'est une mauvaise idée de créer manuellement des points de montage sous /media/$USER/ il vaut mieux laisser au système la pleine jouissance de cet emplacement, qui s'en sert pour le montage automatique de supports amovibles.
Dans le cas de montages créés manuellement préférer les placer directement sous /media/ tout court en donnant aux dossiers~points~de~montage des noms qui ne risquent pas d'être confondus avec des noms d'$USER potentiels du système → utiliser des majuscules dans ces noms de dossiers ;-)

samprzyswa · Le 14/02/2023, à 03:10

La commande "udisksctl unmount -b /dev/sdc" me renvoie:

samp@jupiter:~$ udisksctl unmount -b /dev/sdc
Object /org/freedesktop/UDisks2/block_devices/sdc is not a mountable filesystem.
samp@jupiter:~$

et en mode superutilisateur:

samp@jupiter:~$ sudo udisksctl unmount -b /dev/sdc
[sudo] Mot de passe de samp : 
Error looking up object for device /dev/sdc
samp@jupiter:~$

Mais en fait mon problème c'est que la clé n'est plus visible en tant que /dev/sdc lorsque je fais un "fdisk /dev/sdc" se bloque, d'ailleurs un lsblk ne fait plus apparaître /dev/sdc seulement mes disques /dev/sda et /dev/sdb alors que seul l'appli Disques me les fait apparaître mais impossible d'agir dessus :

Sam.

Coeur Noir · Le 14/02/2023, à 03:49

En visant la partition ?

udisksctl unmount -b /dev/sdc2

Tu as vérifié les autres points du #11 ?

lsblk -fe7,11 -o +size,pttype,ro    # bien agrandir la fenêtre du terminal AVANT de lancer cette commande, son retour est un tableau assez large.

find ~ ! -user $USER

ls -la /media/$USER

auxquels j'ajoute

grep /dev/sd* /etc/mtab

car si je comprends bien ce qu'affiche disques, tu as 2 partitions de sdc actuellement montées ( celles marquées d'une étoile, les partitions 4 et 5 et pas à priori celle qui est sélectionnée, la 2. )

Je n'ai aucune prétention quant à « l'endroit » où je veux t'emmener, je cherche juste à (in)valider des hypothèses dans ce contexte :
⋅ montage automatique de supports amovibles ( la clé usb ) ;
⋅ droits et permissions nécessaires sur certains éléments dans un tel contexte ( /media et $HOME ) ;
⋅ potentiel mode read-only de la clé ;
⋅ repérer quoi monte où.

On voit aussi que cette clé a une table de partitions GPT à priori « robuste » car doublée.

Ah, au fait si pas déjà fait, le temps de cette enquête il faudrait annuler la modif' du fstab montrée au #3 histoire de revenir à une situation « par défaut » vis à vis du montage automatique.

geole · Le 14/02/2023, à 13:11

Bonjour
Débranche ta clé USB, attends 30 secondes, rebranche la clé USB, attends de nouveau 30 secondes et donne ce retour

journalctl --no-pager -n 50

samprzyswa · Le 14/02/2023, à 19:40

geole a écrit :

Bonjour
Débranche ta clé USB, attends 30 secondes, rebranche la clé USB, attends de nouveau 30 secondes et donne ce retour
journalctl --no-pager -n 50

Aucune informations concernant la clé ou /dev/sdc

Sam.

geole · Le 14/02/2023, à 19:49

Ce n'est pas tout à fait le retour attendu. Si ton diagnostic est bon, il ne reste plus qu'à la mettre au recyclage

samprzyswa · Le 14/02/2023, à 19:58

Coeur Noir a écrit :

En visant la partition ?
udisksctl unmount -b /dev/sdc2

samp@jupiter:~$ udisksctl unmount -b /dev/sdc2
Object /org/freedesktop/UDisks2/block_devices/sdc2 is not a mountable filesystem.
samp@jupiter:~$

Tu as vérifié les autres points du #11 ?

lsblk -fe7,11 -o +size,pttype,ro    # bien agrandir la fenêtre du terminal AVANT de lancer cette commande, son retour est un tableau assez large.

samp@jupiter:~$ lsblk -fe7,11 -o +size,pttype,ro
NAME        FSTYPE            LABEL           UUID                                 FSAVAIL FSUSE% MOUNTPOINT   SIZE PTTYPE RO
sda                                                                                                          931,5G gpt     0
├─sda1      vfat                              C3BF-02E9                                                        512M gpt     0
├─sda2      linux_raid_member ubuntu-server:0 e216b5ed-1578-b937-4b21-f3238c6f04c7                               1G gpt     0
│ └─md0                                                                                                       1022M gpt     0
│   └─md0p1 ext4                              bff328ad-ea77-4d8a-ac01-eba7b0ae2788  537,8M    39% /boot       1018M         0
├─sda3      linux_raid_member ubuntu-server:1 42fc0d81-7cf4-0188-ee4f-6c6aec4090b4                               8G gpt     0
│ └─md1                                                                                                          8G gpt     0
│   └─md1p1 swap                              33815c01-a8b9-47f8-a772-fe78a18d7d50                [SWAP]         8G         0
└─sda4      linux_raid_member ubuntu-server:2 e5ce6534-da84-0e1b-69d8-70eed22d58b6                             922G gpt     0
  └─md2                                                                                                      921,9G gpt     0
    └─md2p1 ext4                              dc396315-6eaa-4fdb-a404-8898f7b468ee  580,6G    31% /          921,9G         0
sdb                                                                                                          931,5G gpt     0
├─sdb1      vfat                              C462-5787                                                        512M gpt     0
├─sdb2      linux_raid_member ubuntu-server:0 e216b5ed-1578-b937-4b21-f3238c6f04c7                               1G gpt     0
│ └─md0                                                                                                       1022M gpt     0
│   └─md0p1 ext4                              bff328ad-ea77-4d8a-ac01-eba7b0ae2788  537,8M    39% /boot       1018M         0
├─sdb3      linux_raid_member ubuntu-server:1 42fc0d81-7cf4-0188-ee4f-6c6aec4090b4                               8G gpt     0
│ └─md1                                                                                                          8G gpt     0
│   └─md1p1 swap                              33815c01-a8b9-47f8-a772-fe78a18d7d50                [SWAP]         8G         0
└─sdb4      linux_raid_member ubuntu-server:2 e5ce6534-da84-0e1b-69d8-70eed22d58b6                             922G gpt     0
  └─md2                                                                                                      921,9G gpt     0
    └─md2p1 ext4                              dc396315-6eaa-4fdb-a404-8898f7b468ee  580,6G    31% /          921,9G         0
samp@jupiter:~$

find ~ ! -user $USER

samp@jupiter:~$ find ~ ! -user $USER
/home/samp/Video/output.mp4
/home/samp/Images/nature-landscape-beach-sea-wallpaper-preview.jpg
/home/samp/Images/images.jpeg
/home/samp/Images/Wallpaper/nature-landscape-beach-sea-wallpaper-preview.jpg
/home/samp/Images/Wallpaper/Ubuntu Touch DarkGreen .png
/home/samp/Images/Wallpaper/images.jpeg
/home/samp/Images/Wallpaper/Mexico-_widow_Beach_Wallpaper_1680x1050.jpg
/home/samp/Images/Wallpaper/fonds-ecran-plage-2015-2.jpg
/home/samp/Documents/Live USB/mkusb-backup-home-02.tar.gz
/home/samp/Documents/Live USB/mkusb-backup-home.tar.gz
/home/samp/Téléchargements/Ubuntu/mkusb-backup-home.tar.gz
/home/samp/Backups/webmin.tgz
samp@jupiter:~$

ls -la /media/$USER

Une fois la clé branchée:

samp@jupiter:~$ ls -la /media/$USER
total 14
drwxr-x---+ 4 root root 4096 févr. 14 18:27  .
drwxr-xr-x  3 root root 4096 juil. 31  2020  ..
dr-xr-xr-x  1 samp samp 2048 juil. 31  2020 'Ubuntu 20.04.1 LTS amd64'
drwx------  2 root root 4096 févr. 14 18:27  writable
samp@jupiter:~$

auxquels j'ajoute
grep /dev/sd* /etc/mtab

samp@jupiter:~$ grep /dev/sd* /etc/mtab
grep: /dev/sda1: Permission non accordée
grep: /dev/sda2: Permission non accordée
grep: /dev/sda3: Permission non accordée
grep: /dev/sda4: Permission non accordée
grep: /dev/sdb: Permission non accordée
grep: /dev/sdb1: Permission non accordée
grep: /dev/sdb2: Permission non accordée
grep: /dev/sdb3: Permission non accordée
grep: /dev/sdb4: Permission non accordée
grep: /dev/sdc: Permission non accordée
grep: /dev/sdc1: Permission non accordée
grep: /dev/sdc2: Permission non accordée
grep: /dev/sdc3: Permission non accordée
grep: /dev/sdc4: Permission non accordée
grep: /dev/sdc5: Permission non accordée
samp@jupiter:~$

car si je comprends bien ce qu'affiche disques, tu as 2 partitions de sdc actuellement montées ( celles marquées d'une étoile, les partitions 4 et 5 et pas à priori celle qui est sélectionnée, la 2. )
Je n'ai aucune prétention quant à « l'endroit » où je veux t'emmener, je cherche juste à (in)valider des hypothèses dans ce contexte :
⋅ montage automatique de supports amovibles ( la clé usb ) ;
⋅ droits et permissions nécessaires sur certains éléments dans un tel contexte ( /media et $HOME ) ;
⋅ potentiel mode read-only de la clé ;
⋅ repérer quoi monte où.
On voit aussi que cette clé a une table de partitions GPT à priori « robuste » car doublée.
Ah, au fait si pas déjà fait, le temps de cette enquête il faudrait annuler la modif' du fstab montrée au #3 histoire de revenir à une situation « par défaut » vis à vis du montage automatique.

J'ai bien sûr modifié le fstab pour qu'il permette le montage.

Voilà, merci de ton aide précieuse.

Sam.

geole · Le 14/02/2023, à 20:49

samprzyswa a écrit :

geole a écrit :
Bonjour
Débranche ta clé USB, attends 30 secondes, rebranche la clé USB, attends de nouveau 30 secondes et donne ce retour
journalctl --no-pager -n 50
Aucune informations concernant la clé ou /dev/sdc
Sam.

Un exemple de retour

a@p:~$ 
a@p:~$ journalctl --no-pager -n 50
févr. 14 19:24:43 p rtkit-daemon[1575]: Supervising 8 threads of 5 processes of 1 users.
févr. 14 19:24:43 p rtkit-daemon[1575]: Supervising 8 threads of 5 processes of 1 users.
févr. 14 19:24:43 p rtkit-daemon[1575]: Supervising 8 threads of 5 processes of 1 users.
févr. 14 19:24:43 p rtkit-daemon[1575]: Supervising 8 threads of 5 processes of 1 users.
févr. 14 19:24:43 p rtkit-daemon[1575]: Supervising 8 threads of 5 processes of 1 users.
févr. 14 19:24:43 p rtkit-daemon[1575]: Supervising 8 threads of 5 processes of 1 users.
févr. 14 19:24:46 p rtkit-daemon[1575]: Supervising 8 threads of 5 processes of 1 users.
févr. 14 19:24:46 p rtkit-daemon[1575]: Supervising 8 threads of 5 processes of 1 users.
févr. 14 19:24:46 p rtkit-daemon[1575]: Supervising 8 threads of 5 processes of 1 users.
févr. 14 19:24:46 p rtkit-daemon[1575]: Supervising 8 threads of 5 processes of 1 users.
févr. 14 19:24:47 p rtkit-daemon[1575]: Supervising 8 threads of 5 processes of 1 users.
févr. 14 19:24:47 p rtkit-daemon[1575]: Supervising 8 threads of 5 processes of 1 users.
févr. 14 19:24:47 p rtkit-daemon[1575]: Supervising 8 threads of 5 processes of 1 users.
févr. 14 19:24:47 p rtkit-daemon[1575]: Supervising 8 threads of 5 processes of 1 users.
févr. 14 19:24:47 p rtkit-daemon[1575]: Supervising 8 threads of 5 processes of 1 users.
févr. 14 19:24:47 p rtkit-daemon[1575]: Supervising 8 threads of 5 processes of 1 users.
févr. 14 19:24:47 p rtkit-daemon[1575]: Supervising 8 threads of 5 processes of 1 users.
févr. 14 19:24:47 p rtkit-daemon[1575]: Supervising 8 threads of 5 processes of 1 users.
févr. 14 19:27:15 p rtkit-daemon[1575]: Supervising 7 threads of 4 processes of 1 users.
févr. 14 19:27:15 p rtkit-daemon[1575]: Supervising 7 threads of 4 processes of 1 users.
févr. 14 19:27:25 p systemd[1]: fwupd.service: Deactivated successfully.
févr. 14 19:27:25 p systemd[1]: fwupd.service: Consumed 2.572s CPU time.
févr. 14 19:28:30 p rtkit-daemon[1575]: Supervising 7 threads of 4 processes of 1 users.
févr. 14 19:28:30 p rtkit-daemon[1575]: Supervising 7 threads of 4 processes of 1 users.
févr. 14 19:28:39 p rtkit-daemon[1575]: Supervising 7 threads of 4 processes of 1 users.
févr. 14 19:28:39 p rtkit-daemon[1575]: Supervising 7 threads of 4 processes of 1 users.
févr. 14 19:28:42 p rtkit-daemon[1575]: Supervising 7 threads of 4 processes of 1 users.
févr. 14 19:28:42 p rtkit-daemon[1575]: Supervising 7 threads of 4 processes of 1 users.
févr. 14 19:30:01 p CRON[125053]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
févr. 14 19:30:01 p CRON[125054]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
févr. 14 19:30:01 p systemd[1]: Started Run anacron jobs.
févr. 14 19:30:01 p CRON[125053]: pam_unix(cron:session): session closed for user root
févr. 14 19:30:01 p anacron[125055]: Anacron 2.3 started on 2023-02-14
févr. 14 19:30:01 p anacron[125055]: Normal exit (0 jobs run)
févr. 14 19:30:01 p systemd[1]: anacron.service: Deactivated successfully.
févr. 14 19:31:45 p rtkit-daemon[1575]: Supervising 7 threads of 4 processes of 1 users.
févr. 14 19:31:45 p rtkit-daemon[1575]: Supervising 7 threads of 4 processes of 1 users.
févr. 14 19:32:12 p rtkit-daemon[1575]: Supervising 7 threads of 4 processes of 1 users.
févr. 14 19:32:12 p rtkit-daemon[1575]: Supervising 7 threads of 4 processes of 1 users.
févr. 14 19:32:14 p rtkit-daemon[1575]: Supervising 7 threads of 4 processes of 1 users.
févr. 14 19:32:14 p rtkit-daemon[1575]: Supervising 7 threads of 4 processes of 1 users.
févr. 14 19:37:58 p systemd[1967]: Started Application launched by gnome-shell.
févr. 14 19:38:00 p dbus-daemon[1980]: [session uid=1000 pid=1980] Activating via systemd: service name='org.gnome.Terminal' unit='gnome-terminal-server.service' requested by ':1.161' (uid=1000 pid=125203 comm="/usr/bin/gnome-terminal.real " label="unconfined")
févr. 14 19:38:00 p systemd[1967]: Starting GNOME Terminal Server...
févr. 14 19:38:00 p dbus-daemon[1980]: [session uid=1000 pid=1980] Successfully activated service 'org.gnome.Terminal'
févr. 14 19:38:00 p systemd[1967]: Started GNOME Terminal Server.
févr. 14 19:38:01 p systemd[1967]: Started VTE child process 125228 launched by gnome-terminal-server process 125210.
févr. 14 19:38:54 p wpa_supplicant[1273]: wlp8s0: WPA: Group rekeying completed with 62:fe:c5:c6:f3:b0 [GTK=CCMP]
févr. 14 19:47:56 p gnome-shell[2112]: libinput error: event5  - ETPS/2 Elantech Touchpad: kernel bug: Touch jump detected and discarded.
févr. 14 19:47:56 p gnome-shell[2112]: See https://wayland.freedesktop.org/libinput/doc/1.20.0/touchpad-jumping-cursors.html for details
a@p:~$

ylag · Le 14/02/2023, à 20:55

Bonsoir,

Vu au #18 :

samp@jupiter:~$ grep /dev/sd* /etc/mtab
grep: /dev/sda1: Permission non accordée
grep: /dev/sda2: Permission non accordée
grep: /dev/sda3: Permission non accordée
grep: /dev/sda4: Permission non accordée
...

Pas normal, l'utilisateur samp devrait avoir les permissions en lecture pour /etc/mtab ?
Peut-être vérifier avec :

ls -l /ect/mtab

ls -lH /etc/mtab

A+

nany · Le 14/02/2023, à 21:08

Bonjour,

Non, c’est seulement que la commande devrait ne pas renvoyer d’erreur avec des guillemets :

grep "/dev/sd*" /etc/mtab

[HS]
@geole : besoin de toi ici pour confirmer ou infirmer la mort d’un disque dur (que tu as déjà aidé à réparer).
[/HS]

samprzyswa · Le 14/02/2023, à 22:25

nany a écrit :

Bonjour,

Non, c’est seulement que la commande devrait ne pas renvoyer d’erreur avec des guillemets :
grep "/dev/sd*" /etc/mtab

Avec les guillemets:

samp@jupiter:~$ grep "/dev/sd*" /etc/mtab
tmpfs /dev/shm tmpfs rw,nosuid,nodev,inode64 0 0
/dev/sdc4 /media/samp/Ubuntu\04020.04.1\040LTS\040amd64 iso9660 ro,nosuid,nodev,relatime,nojoliet,check=s,map=n,blocksize=2048,uid=1000,gid=1000,dmode=500,fmode=400,iocharset=utf8 0 0
samp@jupiter:~$

Sam.

Coeur Noir · Le 15/02/2023, à 04:08

my bad pour la syntaxe du grep, c'est à ça que je pensais, en fait :

grep ^/dev/sd* /etc/mtab

soit uniquement les lignes qui commencent par /dev/sd

Je ne comprends pas pourquoi lsblk ne renvoie rien concernant sdc alors qu'on a

samp@jupiter:~$ grep "/dev/sd*" /etc/mtab
(…)
/dev/sdc4 /media/samp/Ubuntu\04020.04.1\040LTS\040amd64 iso9660 ro,nosuid,nodev,relatime,nojoliet,check=s,map=n,blocksize=2048,uid=1000,gid=1000,dmode=500,fmode=400,iocharset=utf8 0 0
samp@jupiter:~$

et

samp@jupiter:~$ ls -la /media/$USER
total 14
drwxr-x---+ 4 root root 4096 févr. 14 18:27  .					# ACL présents, ok
drwxr-xr-x  3 root root 4096 juil. 31  2020  ..					# proprios et droits à priori conformes
dr-xr-xr-x  1 samp samp 2048 juil. 31  2020 'Ubuntu 20.04.1 LTS amd64'		# ici c'est les données contenues dans /dev/sdc4 en lecture seule ( image .iso )
drwx------  2 root root 4096 févr. 14 18:27  writable				# là je ne sais pas pourquoi c'est seulement root:root qui peut rwx : normal ou pas ?
samp@jupiter:~$

Ailleurs, ça m'intrigue aussi :

samp@jupiter:~$ udisksctl unmount -b /dev/sdc2
Object /org/freedesktop/UDisks2/block_devices/sdc2 is not a mountable filesystem.
samp@jupiter:~$

Le système dit que le système de fichiers n'est pas « montable » → manquerait-il au système le « pilote » pour le système de fichiers visé ?
D'après l’illustration https://postimg.cc/CBgKtqRm
⋅ sdc2 est une partition BIOS boot de contenu inconnu → est-ce normal ou pas qu'une telle partition ne soit pas montable ?
⋅ sdc4 est une partition EXT4 → ne devrait-elle pas être à minima en rwxr-xr-x si on veut que tout le monde puisse en lire le contenu en considérant qu'elle appartient à root:root ? Voire ne devrait-elle pas être en rwxrwxrwt si on veut que n'importe qui puisse y écrire mais que seul le propriétaire d'un élément puisse l'effacer ?

Le fait qu'il y ait des éléments n'appartenant pas à samp dans /home/samp/ n'est pas tout à fait souhaitable non plus - même si ça n'a pas l'air d'impacter des fichiers cachés de config's / paramètres / préférences ( ce qui est presque étonnant d'ailleurs. )

Mmm… désolé, ça fait beaucoup de questions… qui me portent à croire que le pépin n'est pas forcément que matériel dans la clé mais peut-être bien aussi dans le système, soit parce qu'il manque des fonctions ou des paquets, soit parce que des droits et permissions ne sont pas adéquats sur des éléments cruciaux ( mais lesquels ? ).

Et comme tu as d'autres problèmes avec ce système là, ça ne me fait que douter davantage.
À tou-z-hasard, montre ton fstab :

cat /etc/fstab

Ton système est installé « dans » une grappe RAiD c'est peut-être contraignant ? ? ?
( Dans les serveurs que je vois au boulot, les systèmes sont installés en dehors des grappes RAiD, et les grappes RAiD ne contiennent que des données pas nécessaires au fonctionnement du système. )

geole · Le 15/02/2023, à 09:54

Bonjour.
Les partitions bios Boot sont sans aucune structure. Elles sont lisibles uniquement bit à bit
paragraphe 3.2
C'est l'équivalent de ce qui s'écrivait à partir du secteur 1 dans un disque ayant une table de partition ms-dos.
Si la partition sdc4 est en lecture seule, on pourrait en avoir une explication en consultant le retour de journalctl.

Dernière modification par geole (Le 15/02/2023, à 09:59)

samprzyswa · Le 15/02/2023, à 13:57

@Coeur Noir

Cette clé fonctionnait très bien il y avait un système live installé dessus et depuis une coupure de courant elle ne bootait plus, j'ai supprimé les partitions avec fdisk pour la reconstruire mais après ça blocage et plus visible en tant que /dev/sdc

Sam

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 12/02/2023, à 17:10

Clé USB corrompue et indémontable...

#2 Le 12/02/2023, à 17:25

Re : Clé USB corrompue et indémontable...

#3 Le 12/02/2023, à 17:34

Re : Clé USB corrompue et indémontable...

#4 Le 12/02/2023, à 19:16

Re : Clé USB corrompue et indémontable...

#5 Le 13/02/2023, à 10:00

Re : Clé USB corrompue et indémontable...

#6 Le 13/02/2023, à 12:34

Re : Clé USB corrompue et indémontable...

#7 Le 13/02/2023, à 12:53

Re : Clé USB corrompue et indémontable...

#8 Le 13/02/2023, à 15:03

Re : Clé USB corrompue et indémontable...

#9 Le 13/02/2023, à 16:12

Re : Clé USB corrompue et indémontable...

#10 Le 13/02/2023, à 17:58

Re : Clé USB corrompue et indémontable...

#11 Le 14/02/2023, à 01:57

Re : Clé USB corrompue et indémontable...

#12 Le 14/02/2023, à 02:26

Re : Clé USB corrompue et indémontable...

#13 Le 14/02/2023, à 03:10

Re : Clé USB corrompue et indémontable...

#14 Le 14/02/2023, à 03:49

Re : Clé USB corrompue et indémontable...

#15 Le 14/02/2023, à 13:11

Re : Clé USB corrompue et indémontable...

#16 Le 14/02/2023, à 19:40

Re : Clé USB corrompue et indémontable...

#17 Le 14/02/2023, à 19:49

Re : Clé USB corrompue et indémontable...

#18 Le 14/02/2023, à 19:58

Re : Clé USB corrompue et indémontable...

#19 Le 14/02/2023, à 20:49

Re : Clé USB corrompue et indémontable...

#20 Le 14/02/2023, à 20:55

Re : Clé USB corrompue et indémontable...

#21 Le 14/02/2023, à 21:08

Re : Clé USB corrompue et indémontable...

#22 Le 14/02/2023, à 22:25

Re : Clé USB corrompue et indémontable...

#23 Le 15/02/2023, à 04:08

Re : Clé USB corrompue et indémontable...

#24 Le 15/02/2023, à 09:54

Re : Clé USB corrompue et indémontable...

#25 Le 15/02/2023, à 13:57

Re : Clé USB corrompue et indémontable...

Pied de page des forums