Disques USB qui disparaissent tout seuls

Support Debian
#1

Pour situer, j’ai un SheevaPlug (un mini système sans écran, sans clavier) qui tourne avec squeeze.

Dans cette petite boite il n’y a qu’un port SATA, un port USB et un port RJ45.

Squeeze est installée sur un 160Go de portable branché sur le port SATA et j’ai 3 disques USB (grosse capacité) qui sont branchés via un hub sur le port USB.

Quand je démarre le monstre, les disques sont répartis comme suit :

SATA 160Go sda1 /boot (ext2) sda2 / (ext4) sda5 swap usb1 320Go sdb4 /media/usb2 (ext3) usb2 320Go sdc1 /media/usb1 (ext3) usb3 1To sdd1 /media/usb3 (ext3) sdd2 /media/usb4 (ext3)

Dans /etc/rc.local, j’appele un scripte qui vérifie les disques et qui les monte au bon endroit et mount réponds ça:

root@sheeva:~# mount /dev/sda2 on / type ext4 (rw,errors=remount-ro) tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) udev on /dev type tmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) /dev/sda1 on /boot type ext2 (rw) fusectl on /sys/fs/fuse/connections type fusectl (rw) /dev/sdb4 on /media/usb2 type ext3 (rw) /dev/sdc1 on /media/usb1 type ext3 (rw) /dev/sdd1 on /media/usb3 type ext3 (rw) /dev/sdd2 on /media/usb4 type ext3 (rw)

Maintenant, au bout de quelques heures, on ne peut plus accèder aux disques !
Mount les voit toujours montés, mais fdisk les voit raccordés à un autre device que celui du début:

root@sheeva:~# fdisk -l | grep /dev Disk /dev/sda: 160.0 GB, 160041885696 bytes /dev/sda1 1 122 975872 83 Linux /dev/sda2 122 7295 57617408 83 Linux /dev/sda3 7295 7417 975873 5 Extended /dev/sda5 7295 7417 975872 82 Linux swap / Solaris Disk /dev/sde: 320.1 GB, 320072933376 bytes /dev/sde1 * 1 64 514048+ 83 Linux /dev/sde2 65 3723 29390917+ 83 Linux /dev/sde3 3724 3852 1036192+ 82 Linux swap / Solaris /dev/sde4 3853 38913 281627482+ 83 Linux Disk /dev/sdf: 320.1 GB, 320072933376 bytes /dev/sdf1 1 38914 312570848+ 83 Linux Disk /dev/sdg: 1000.2 GB, 1000204886016 bytes /dev/sdg1 1 60800 488375968+ 83 Linux /dev/sdg2 60801 121601 488384032+ 83 Linux

Pour info, sur le premier 320Go il y a un Lenny (/boot, /, swap) de secours au cas ou le SATA ne démarre pas.

Donc je me retrouve avec des devices sdb, sdc, sdd qui son montés mais inaccessibles et des devices sde, sdf, sdg qui sont les mêmes mais non montés.

J’ai essayé de créer un chien de garde qui remonte automatiquent les devices quand ils changent de lettre, mais arrivé à ‘z’ on est bloqué.
Pour le moment le seul paliatif est de redémmarrer…

#2

Salut,

N’as tu point pensé aux UUID dans ton script ? :083

#3

J’ai trouvé une piste là : lesswatts.org/projects/devic … nt/usb.php

Sur mon plug tous les devices USB ont:

/sys/bus/usb/devices/usbx/power/wakeup = enabled /sys/bus/usb/devices/usbx/power/autosuspend = 2 /sys/bus/usb/devices/usbx/power/level = auto

Est ce que j’ai le droit de les forcer avec :

/sys/bus/usb/devices/usbx/power/wakeup = enabled /sys/bus/usb/devices/usbx/power/autosuspend = -1 /sys/bus/usb/devices/usbx/power/level = on
Any idea ???

#4

[quote=“loreleil”]Salut,

N’as tu point pensé aux UUID dans ton script ? :083

ben oui, mais la limite du ‘z’ ne dépend pas de moi …

Au bout de quelques remontages, il n’y aura plus de lettres de libre dans /dev/sdxx

#5

[quote=“Maisondouf”][quote=“loreleil”]Salut,

N’as tu point pensé aux UUID dans ton script ? :083

# blkid

ben oui, mais la limite du ‘z’ ne dépend pas de moi …

Au bout de quelques remontages, il n’y aura plus de lettres de libre dans /dev/sdxx[/quote]

??? je ne te suit pas trop là …

les UUID sont invariables et immuables … :033 Via fstab!

[quote]:~# cat /etc/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).

proc /proc proc defaults 0 0

/ was on /dev/sda1 during installation

UUID=d128857f-859e-490e-a9bf-3e7afb2741d8 / ext3 errors=remount-ro 0 1

/home was on /dev/sda6 during installation

UUID=28d14850-47ec-40c3-bf96-ffebfa75dfe7 /home ext3 defaults 0 2

swap was on /dev/sda5 during installation

UUID=795c9836-7500-4444-9332-fb6ff1289cad none swap sw 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0
/dev/scd1 /media/cdrom1 udf,iso9660 user,noauto 0 0
:~#
[/quote]

#6

Et dire qu’avant il y avait un super Wheezy avec kernel 3.1 d’installé et que je l’ai viré croyant que c’était lui qui buggait… :confused:

#7

Oui, pour les UUID pas de soucis, mais ça ne sert qu’à ‘mount’.

Au niveau inférieur, les disques doivent bien se ‘raccorder’ au système quelque part.

Si fdisk les trouvent en sde au lieu de sda après le 1er “décrochage”, au fur et à mesure, les disques ne seront plus accessibles du tout par manque de lettre.

Ou alors, j’ai rien compris.

#8

Je ne vois vraiment pas ce qui pourrait limiter l’attribution des UUID de tes partitions. :033

[quote]Qu’est-ce que l’UUID ?

UUID : Universal Unique IDentifier (identifiant universel unique)

Le paquet “volume_id” est désormais nécessaire au système de fichiers RAM initial (initramfs-tools) ainsi qu’aux programmes Grub et Udev. Notre Ubuntu est évidemment concerné par cette évolution (depuis Edgy).
Dans ce cadre, l’attribut le plus caractéristique est sans doute l’UUID.

Il s’agit d’une suite plus ou moins longue chaîne de caractères alpha-numériques qui permet d’identifier de façon absolument sûre toute partition ou tout type de périphérique de stockage (“device”) physique ou virtuel pouvant être raccordé au système de fichiers.

L’utilisation de l’UUID est généralisée. La plupart des systèmes de fichiers que vous rencontrerez reconnaissent les UUID. Citons notamment, ext2, ext3, reiserfs pour Linux, FAT16 ou 32 et NTFS pour Windows ainsi que les disques RAID. Vous trouverez une liste détaillée dans /usr/share/doc/libvolume-id0/README.

Le chiffre de l’UUID est calculé automatiquement au moyen d’un algorithme intégrant notamment certaines données de l’ordinateur hôte. Ce mode de calcul ne présente aucun risque de sécurité crédible.

L’utilisation de l’UUID constitue à la fois un progrès et une contrainte.

Un progrès
L’UUID vous garantit contre tout duplicata et évite ainsi tout blocage en cas de changement de désignation de périphérique.

Une contrainte
Vous devrez apprendre à tenir compte de l’UUID sous peine de risquer de rendre impossible le montage de certains volumes ou partitions.

[/quote]

doc.ubuntu-fr.org/uuid_et_label

#9

Pour ce qui est des UUID des partitions, je suis d’accord il n’y a pas de soucis.
Les UUID sont établis au formatage et ne bougent plus.

Mais, mon problème c’est pas de savoir remonter les disques, c’est de savoir pourquoi ils disparaissent ?

Alors tu penses que si au lieu de les monter avec :

il faut que je les monte avec

Je ne sais pas si ça va résoudre le problème.

#10

Oui! :033

[quote]7 Différencier deux périphériques USB

L’UUID peut vous servir aussi à différencier deux périphériques USB.

(source : Planet Ubuntu-fr - The Glu 19/03/07)

Si vous êtes l’heureux possesseur d’un DD externe et d’une clé USB, il peut arriver que ces périphériques soient identifiés aléatoirement au montage tantôt comme /dev/sda1 tantôt comme /dev/sdb1. Ceci peut occasionner quelques problèmes, par exemple dans le cas ou un script (sauvegarde, vérification etc…) doit s’exécuter sur l’un mais pas sur l’autre.

Vous pouvez forcer le système à les monter sur un point de montage précis en les différenciant tout simplement par leur UUID.

Pour les périphériques possédant un label le point de montage par défaut est /media/

7.1 Périphériques toujours présents au démarrage du système
Voici par exemple la procédure pour forcer le fstab à monter un périphérique sur /media/sos. Ajoutez cette ligne :

UUID=f0343b8c-1226-4f66-8b41-6a5c02c028dd /media/sos auto user,uid=1000,gid=1000,atime,auto,rw,nodev,exec,suid 0 0

Ainsi, ce périphérique sera TOUJOURS monté sur /media/sos au démarrage.

7.2 Périphériques branchés à chaud

…

[/quote]

[quote]10 Labels et Étiquettes, c’est mieux non ?

Les étiquettes (ou Label) sont un mode de désignation convivial qui convient plus particulièrement à une utilisation locale. Les étiquettes ne remplacent absolument pas les UUID car elles n’offrent ni leur unicité ni leur sécurité. Considérez-les comme un aide-mémoire et donc plutôt comme une valeur ajoutée qui vous permettra d’identifier une partition montée rapidement.

Les étiquettes font partie des attributs distinctifs des partitions et autres périphériques de stockage. Elles doivent être attribuées manuellement. Veillez à ne pas donner à votre étiquette un nom de plus de 16 caractères, sinon votre entrée sera tronquée.[/quote]

#11

Pratiquement, tous les périphériques usb étaient en mode économie d’énergie et ils se désactivent au bout d’un certain temps.

J’ai rajouté ça dans ‘rc.local’

ça bascule les devices du mode ‘auto’ (économie) au mode ‘on’ (marche continue)…

ça peut peut-être éviter la disparition …

NB: orion-ehci c’est l’appelation du chip controleur USB

edit : info ici
du coup, j’ai rajouté ça:

#12

Ça devait être ça…

Les disques tournent depuis presque 15 jours sans avoir disparu :wink: