J'ai deux supports de donnée amovibles, ma clé USB et mon APN,
connectable lui aussi par un port USB.
Si je branche et monte en premier ma clé USB, elle est vue comme sda1
par Tux, si je branche ensuite mon APN, il est vu comme sdb1.
J'ai donc les deux lignes suivantes dans /etc/fstab
# pour ma clé USB
/dev/sda1 /mnt/CléUSB vfat noauto,noatime,rw,user,noexec,umask=000 0 0
# pour mon APN
/dev/sdb1 /mnt/APN auto noauto,noatime,rw,user,noexec,umask=000 0 0
Le problème est que si je reboote et que je branche mon APN sans que la
clé USB soit branchée, alors Tux le voit comme sda1 donc la ligne du
fstab ne sert plus à rien (elle est devenue fausse) et je suis obligé de
me connecter en root pour lire les photos de l'APN avec
# mount -t auto /dev/sda1 /mnt/APN
Je me rappelle que lorsque j'avais mon lecteur Zip, il lui était
toujours attribué le device sda4. N'y aurait-il donc pas un moyen que
Tux attribue toujours le même device à un périphérique amovible ?
Ou alors une petite ruse à l'aide lien symbolique ou bien un script qui
serait capable de détecter par quel device on accède à un périphérique
physique ?
Merci de votre aide.
--
Vire [] (com2 usb) [] probleme [] xpertplay [] resserve les adresse
memoire [] reboot [] bios [] active [] windoz [] parametrage []
reservation de ressource [] reboot [] bios [] reset [] disable [] prie.
-+- MK in Guide du linuxien pervers - "Solution à un problème Windows"
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Nicolas George
Hugolino wrote in message :
Si je branche et monte en premier ma clé USB, elle est vue comme sda1
Non, sda tout court. Et sur cette clef USB, il y a une partition, qui est désignée par sda1.
par Tux, si je branche ensuite mon APN, il est vu comme sdb1.
Même chose, l'appareil est sdb, et sa mémoire comporte une partition sdb1.
Je me rappelle que lorsque j'avais mon lecteur Zip, il lui était toujours attribué le device sda4.
Encore pareil : sda avec une partition (les Zip utilisaient la partition 4 pour je ne sais quelle obscure raison). Et c'était « toujours » sda parce que tu n'avais pas d'autre périphériques du même genre.
Dans les trois cas, il est possible de changer la table des partitions, d'en créer de différentes tailles, ou même d'utiliser le disque sans partition. Cependant, faire ça risque de causer des incompatibilités avec des OS moins souples que Linux ; c'est particulièrement vrai dans le cas de l'appareil photo.
N'y aurait-il donc pas un moyen que Tux attribue toujours le même device à un périphérique amovible ?
Non. Les périphériques qui se présentent comme un disque dur SCSI sont tous numérotés dans l'ordre où ils sont détectés : sda, sdb, sdc, etc.
Ou alors une petite ruse à l'aide lien symbolique ou bien un script qui serait capable de détecter par quel device on accède à un périphérique physique ?
Ça, c'est tout à fait faisable. Si tu utilises devfs, une règle de ce genre peut être utile :
où register_scsi est un script qui va aller chercher dans /proc/scsi/scsi ou dans /sys/bus/scsi/devices/*/ pour trouver quel périphérique c'est, et faire les liens qui vont bien.
Un exemple minimal et non testé, qu'il faudrait rendre plus robuste :
read -r -- model < /sys/bus/scsi/devices/$host:$bus:$target:$lun/model
target="" case $model in ("flash disk") model=usbkey;; ("APN machin") model=apn;; esac
if [[ $target == "" ]]; then print -u2 "Unknown SCSI disc: $model" exit 1 fi
case $action in (add) ln -s ${device:h} /dev/$target;; (remove) rm /dev/$target;; fi
----
(je mets ce bout de code dans le domaine public)
Ensuite, la clef USB est accessible par /dev/usbkey (c'est un répertoire, avec disc pour le disque entier, part1 pour la première partition, etc. ; donc c'est /dev/usbkey/part1 qu'il faut mettre dans fstab), l'appareil photo par /dev/apn, etc.
Il doit exister ce genre de scripts tout faits, peut-être du côté de hotplug, en fait. En particulier, il me semble qu'udev est censé faire quelque chose du genre.
Hugolino wrote in message
<slrncgd184.qt.hugolino@Deborah.RocknRoll.org>:
Si je branche et monte en premier ma clé USB, elle est vue comme sda1
Non, sda tout court. Et sur cette clef USB, il y a une partition, qui
est désignée par sda1.
par Tux, si je branche ensuite mon APN, il est vu comme sdb1.
Même chose, l'appareil est sdb, et sa mémoire comporte une partition
sdb1.
Je me rappelle que lorsque j'avais mon lecteur Zip, il lui était
toujours attribué le device sda4.
Encore pareil : sda avec une partition (les Zip utilisaient la partition
4 pour je ne sais quelle obscure raison). Et c'était « toujours » sda
parce que tu n'avais pas d'autre périphériques du même genre.
Dans les trois cas, il est possible de changer la table des partitions,
d'en créer de différentes tailles, ou même d'utiliser le disque sans
partition. Cependant, faire ça risque de causer des incompatibilités
avec des OS moins souples que Linux ; c'est particulièrement vrai dans
le cas de l'appareil photo.
N'y aurait-il donc pas un moyen que
Tux attribue toujours le même device à un périphérique amovible ?
Non. Les périphériques qui se présentent comme un disque dur SCSI sont
tous numérotés dans l'ordre où ils sont détectés : sda, sdb, sdc, etc.
Ou alors une petite ruse à l'aide lien symbolique ou bien un script qui
serait capable de détecter par quel device on accède à un périphérique
physique ?
Ça, c'est tout à fait faisable. Si tu utilises devfs, une règle de ce
genre peut être utile :
où register_scsi est un script qui va aller chercher dans
/proc/scsi/scsi ou dans /sys/bus/scsi/devices/*/ pour trouver quel
périphérique c'est, et faire les liens qui vont bien.
Un exemple minimal et non testé, qu'il faudrait rendre plus robuste :
read -r -- model < /sys/bus/scsi/devices/$host:$bus:$target:$lun/model
target=""
case $model in
("flash disk") model=usbkey;;
("APN machin") model=apn;;
esac
if [[ $target == "" ]]; then
print -u2 "Unknown SCSI disc: $model"
exit 1
fi
case $action in
(add) ln -s ${device:h} /dev/$target;;
(remove) rm /dev/$target;;
fi
----
(je mets ce bout de code dans le domaine public)
Ensuite, la clef USB est accessible par /dev/usbkey (c'est un
répertoire, avec disc pour le disque entier, part1 pour la première
partition, etc. ; donc c'est /dev/usbkey/part1 qu'il faut mettre dans
fstab), l'appareil photo par /dev/apn, etc.
Il doit exister ce genre de scripts tout faits, peut-être du côté de
hotplug, en fait. En particulier, il me semble qu'udev est censé faire
quelque chose du genre.
Si je branche et monte en premier ma clé USB, elle est vue comme sda1
Non, sda tout court. Et sur cette clef USB, il y a une partition, qui est désignée par sda1.
par Tux, si je branche ensuite mon APN, il est vu comme sdb1.
Même chose, l'appareil est sdb, et sa mémoire comporte une partition sdb1.
Je me rappelle que lorsque j'avais mon lecteur Zip, il lui était toujours attribué le device sda4.
Encore pareil : sda avec une partition (les Zip utilisaient la partition 4 pour je ne sais quelle obscure raison). Et c'était « toujours » sda parce que tu n'avais pas d'autre périphériques du même genre.
Dans les trois cas, il est possible de changer la table des partitions, d'en créer de différentes tailles, ou même d'utiliser le disque sans partition. Cependant, faire ça risque de causer des incompatibilités avec des OS moins souples que Linux ; c'est particulièrement vrai dans le cas de l'appareil photo.
N'y aurait-il donc pas un moyen que Tux attribue toujours le même device à un périphérique amovible ?
Non. Les périphériques qui se présentent comme un disque dur SCSI sont tous numérotés dans l'ordre où ils sont détectés : sda, sdb, sdc, etc.
Ou alors une petite ruse à l'aide lien symbolique ou bien un script qui serait capable de détecter par quel device on accède à un périphérique physique ?
Ça, c'est tout à fait faisable. Si tu utilises devfs, une règle de ce genre peut être utile :
où register_scsi est un script qui va aller chercher dans /proc/scsi/scsi ou dans /sys/bus/scsi/devices/*/ pour trouver quel périphérique c'est, et faire les liens qui vont bien.
Un exemple minimal et non testé, qu'il faudrait rendre plus robuste :
read -r -- model < /sys/bus/scsi/devices/$host:$bus:$target:$lun/model
target="" case $model in ("flash disk") model=usbkey;; ("APN machin") model=apn;; esac
if [[ $target == "" ]]; then print -u2 "Unknown SCSI disc: $model" exit 1 fi
case $action in (add) ln -s ${device:h} /dev/$target;; (remove) rm /dev/$target;; fi
----
(je mets ce bout de code dans le domaine public)
Ensuite, la clef USB est accessible par /dev/usbkey (c'est un répertoire, avec disc pour le disque entier, part1 pour la première partition, etc. ; donc c'est /dev/usbkey/part1 qu'il faut mettre dans fstab), l'appareil photo par /dev/apn, etc.
Il doit exister ce genre de scripts tout faits, peut-être du côté de hotplug, en fait. En particulier, il me semble qu'udev est censé faire quelque chose du genre.
no_spam
On Tue, 27 Jul 2004 17:32:50 +0000, Nicolas George wrote:
Hugolino wrote in message :
Si je branche et monte en premier ma clé USB, elle est vue comme sda1
Non, sda tout court. Et sur cette clef USB, il y a une partition, qui est désignée par sda1.
par Tux, si je branche ensuite mon APN, il est vu comme sdb1.
Même chose, l'appareil est sdb, et sa mémoire comporte une partition sdb1.
Je me rappelle que lorsque j'avais mon lecteur Zip, il lui était toujours attribué le device sda4.
Encore pareil : sda avec une partition (les Zip utilisaient la partition 4 pour je ne sais quelle obscure raison).
La partition 4 était utilisée pour la compatibilité avec MacOS: sur Mac, la table de partition est la première partition et la première partition de data est la partition 4 car il y a souvent une partition qui contient des drivers pour booter et une pour d'éventuelles mises à jour de l'OS.
Et c'était « toujours » sda parce que tu n'avais pas d'autre périphériques du même genre.
Presque: parce qu'il n'y avait pas d'autre périphérique avec un ID plus petit sur le bus SCSI en question. [...]
On Tue, 27 Jul 2004 17:32:50 +0000, Nicolas George wrote:
Hugolino wrote in message
<slrncgd184.qt.hugolino@Deborah.RocknRoll.org>:
Si je branche et monte en premier ma clé USB, elle est vue comme sda1
Non, sda tout court. Et sur cette clef USB, il y a une partition, qui
est désignée par sda1.
par Tux, si je branche ensuite mon APN, il est vu comme sdb1.
Même chose, l'appareil est sdb, et sa mémoire comporte une partition
sdb1.
Je me rappelle que lorsque j'avais mon lecteur Zip, il lui était
toujours attribué le device sda4.
Encore pareil : sda avec une partition (les Zip utilisaient la partition
4 pour je ne sais quelle obscure raison).
La partition 4 était utilisée pour la compatibilité avec MacOS:
sur Mac, la table de partition est la première partition et la première
partition de data est la partition 4 car il y a souvent une partition
qui contient des drivers pour booter et une pour d'éventuelles mises
à jour de l'OS.
Et c'était « toujours » sda
parce que tu n'avais pas d'autre périphériques du même genre.
Presque: parce qu'il n'y avait pas d'autre périphérique avec un ID
plus petit sur le bus SCSI en question.
[...]
On Tue, 27 Jul 2004 17:32:50 +0000, Nicolas George wrote:
Hugolino wrote in message :
Si je branche et monte en premier ma clé USB, elle est vue comme sda1
Non, sda tout court. Et sur cette clef USB, il y a une partition, qui est désignée par sda1.
par Tux, si je branche ensuite mon APN, il est vu comme sdb1.
Même chose, l'appareil est sdb, et sa mémoire comporte une partition sdb1.
Je me rappelle que lorsque j'avais mon lecteur Zip, il lui était toujours attribué le device sda4.
Encore pareil : sda avec une partition (les Zip utilisaient la partition 4 pour je ne sais quelle obscure raison).
La partition 4 était utilisée pour la compatibilité avec MacOS: sur Mac, la table de partition est la première partition et la première partition de data est la partition 4 car il y a souvent une partition qui contient des drivers pour booter et une pour d'éventuelles mises à jour de l'OS.
Et c'était « toujours » sda parce que tu n'avais pas d'autre périphériques du même genre.
Presque: parce qu'il n'y avait pas d'autre périphérique avec un ID plus petit sur le bus SCSI en question. [...]
