ll faut vite que je retire ma µSD du terminal !
Si ça arrive rarement, c’est que ça arrive !
Rappelez vous : désormais la µSD se « mount » n’importe où dans l’arborescence de Sailfish … Pour l’instant, elle a été rendue accessible que du « home directory » et de la « SD-Android directory » ; cela suffit bien. Surtout que ça marche sans accroc … Mais accroc il risque d’y avoir, si l’on souhaite retirer cette µSD à chaud, alors que les développeurs du système ne supposaient pas que l’on se permette de telles libertés !
En effet, les « files-systems linux » sont robustes (insensibles à la fragmentation depuis 1993, journalisés, clusterisables, rapides, etc) mais « bénéficient » des inconvénients de cette robustesse, comme par exemple « mettre à mal le système si l’on enlève un disque sans le démonter proprement » ; attention, on ne risque plus le « kernel panic » comme aux temps héroïques, mais déjà de corrompre sérieusement le disque que l’on met, retire et remet à chaud tel un cimmérien obstiné : « ce qui ne te tue plus, te colle simplement la diarrhée » ; et dans le cas qui nous préoccupe, cette diarrhée de bits risque de nous pourrir le contenu de la µSD.
Sous Unix, la méthode la plus simple pour démonter un disque est obtenue grâce à la commande « umount« , dont la syntaxe est triviale :
> umount répertoire_d'arrivée
Alors, il n’y a pas de quoi faire un tuto !
> devel-su Password: # df -h ... tmpfs 407M 0 407M 0% /mnt/obb /dev/mmcblk1p1 63G 1.5G 60G 3% /media/sdcard/77ad9de7-49c7-400d-8593-80441fa51f2e /dev/mmcblk1p1 63G 1.5G 60G 3% /home/nemo/SD64 /dev/mmcblk1p1 63G 1.5G 60G 3% /data/sdcard/SD64 # umount /media/sdcard/77ad9de7-49c7-400d-8593-80441fa51f2e # df -h ... tmpfs 407M 0 407M 0% /mnt/obb /dev/mmcblk1p1 63G 1.5G 60G 3% /home/nemo/SD64 /dev/mmcblk1p1 63G 1.5G 60G 3% /data/sdcard/SD64
Et si ! car si le chemin canonique et utilisé par sailfish est bien démonté, les autres sont restés ; or démonter un disque consiste surtout à vider les buffers, mettre les inodes à jours et tagguer OK le bit de « démontage« . Si dans cette configuration on retire physiquement la µSD sans autre précaution, on peut mettre le « file system » en péril, péril s’étalonnant de « rien-du-tout » à « carrément en vrac » … Et là je suppute que vous allez maudire la partie 1 de ces tuto sur la µSD 🙁 … Alors qu’il suffirait juste de démonter les répertoires d’accueil de la µSD dans l’ordre inverse où ils ont été monté 😉 !
démontons, démontons !
La liste des disques montés est stockée dans le fichier /etc/mtab
# grep mmcblk1p1 /etc/mtab /dev/mmcblk1p1 /home/nemo/SD64 btrfs rw,dirsync,nosuid,nodev,noexec,noatime,thread_pool=4,ssd,noacl,space_cache 0 0 /dev/mmcblk1p1 /data/sdcard/SD64 btrfs rw,dirsync,nosuid,nodev,noexec,noatime,thread_pool=4,ssd,noacl,space_cache 0 0
On voit bien qu’il reste deux instances liées au device /dev/mmcblk1p1, qu’il faudra démonter l’une après l’autre :
# umount /data/sdcard/SD64 # umount /home/nemo/SD64
Imaginons une petite séquence pour automatiser cette manip ; cette suite de commande :
# { SD=/dev/mmcblk1p1 MTList=`awk -v SDM=$SD ' BEGIN {LISTE=""} $0 ~ SDM { LISTE=($2" "LISTE) } END { print LISTE} ' /etc/mtab` echo $MTList } /data/sdcard/SD64 /home/nemo/SD64
nous remplis la variable shell MTList de la liste des répertoires liés au device mmcblk1p1 ; Il ne reste plus qu’à les démonter et vérifier que tout s’est bien passé :
# { for DIR in $MTList do umount $DIR [ $? -eq 1 ] && echo problème $DIR toujours monté done }
Si vous ne lisez pas le message « problème XXXX toujours monté« , vous pouvez désormais retirer physiquement votre µSD.
Alors, certes c’est « sécure », mais question praticité, on ne fait guers pire ! Pour améliorer le confort, il serait bon d’automatiser ces tâches :
SD=/dev/mmcblk1p1 MTList=`awk -v SDM=$SD ' BEGIN {LISTE=""} $0 ~ SDM { LISTE=($2" "LISTE) } END { print LISTE} ' /etc/mtab` for DIR in $MTList do umount $DIR [ $? -eq 1 ] && echo problème $DIR toujours monté done
par un script et d’en faire un fichier exécutable, SDUnMount :
echo '#!/bin/sh SD=/dev/mmcblk1p1 MTList=`awk -v SDM=$SD '\'' BEGIN {LISTE=""} $0 ~ SDM { LISTE=($2" "LISTE) } END { print LISTE} '\'' /etc/mtab` for DIR in $MTList do umount $DIR [ $? -eq 1 ] && echo problème $DIR toujours monté done ' >SDUnMount
# chmod +x SDUnMount # cp SDUnMount /usr/local/bin
Désormais, invoquer cette commande sous root pour démonter, où qu’ils soient, tous les répertoires liés à /dev/mmcblk1p1 sera la règle ; sous root ? seulement sous root ? Que se passe-t-il si c’est nemo ?
# exit > umount /data/sdcard/SD64 umount: /data/sdcard/SD64: umount failed: Operation not permitted
Et oui il faut être root pour monter et démonter un file_system … Mais cela se contourne par un simple :
> devel-su SDUnMount
Cadeau bonus
Précédemment SDMount avait été créé, désormais on dispose en plus de SDUnMount ; peut être devrions nous fusionner ces deux scripts pour n’en faire qu’un, que l’on invoquerait avec l’argument « mount » ou « unmount », pour préciser notre intention !
C’est l’idée de base, mais il faut rester circonspect : pour que le script monte le device, encore faut-il qu’il en ait reçu la consigne, que la µSD soit présente et que les répertoires d’arrivées le soient également : il est nécessaire de tester tout ça avant d’aller plus loin, ce que l’on testera de la sorte :
#!/bin/sh CMD=$1 SD=/dev/mmcblk1p1 set -- `/sbin/blkid -c /dev/null -o export $SD | grep UUID= | tr '=' ' '` UUID=$2 SDCARD=/media/sdcard/$UUID [ -z $UUID ] && exit [ -z $CMD ] && exit
maintenant traitons le cas de l’argument mount :
[ $CMD = "mount" ] && { [ ! -d $SDCARD ] && mkdir $SDCARD mount | grep -q mmcblk1p1 [ $? -eq 1 ] && \ mount /dev/mmcblk1p1 \ -t auto \ -o rw,dirsync,nosuid,nodev,noexec,noatime,thread_pool=4,ssd,noacl,space_cache \ $SDCARD df -h | grep -q $SDCARD [ $? -eq 0 ] && { mount -o bind $SDCARD /home/nemo/SD64 mount -o bind $SDCARD /data/sdcard/SD64 } }
ensuite traitons le cas de l’argument umount
[ $CMD = "umount" ] && { MTList=`awk -v SDM=$SD ' BEGIN {LISTE=""} $0 ~ SDM { LISTE=($2" "LISTE) } END { print LISTE} ' /etc/mtab` for DIR in $MTList do umount $DIR [ $? -eq 1 ] && echo problème $DIR toujours monté done }
ainsi
- si on ne donne pas d’argument ou un argument erronée, le script ne fait rien,
- si le device n’est pas présent, le script ne fait rien,
- si les répertoires d’arrivées n’existent pas, ils sont créés,
- si le démontage a posé problème, on est prévenu,
le script complet ressemble donc :
#!/bin/sh CMD=$1 SD=/dev/mmcblk1p1 set -- `/sbin/blkid -c /dev/null -o export $SD | grep UUID= | tr '=' ' '` UUID=$2 SDCARD=/media/sdcard/$UUID [ -z $UUID ] && exit [ -z $CMD ] && exit [ $CMD = "mount" ] && { [ ! -d $SDCARD ] && mkdir $SDCARD mount | grep -q mmcblk1p1 [ $? -eq 1 ] && \ mount /dev/mmcblk1p1 \ -t auto \ -o rw,dirsync,nosuid,nodev,noexec,noatime,thread_pool=4,ssd,noacl,space_cache \ $SDCARD df -h | grep -q $SDCARD [ $? -eq 0 ] && { mount -o bind $SDCARD /home/nemo/SD64 mount -o bind $SDCARD /data/sdcard/SD64 } } [ $CMD = "umount" ] && { MTList=`awk -v SDM=$SD ' BEGIN {LISTE=""} $0 ~ SDM { LISTE=($2" "LISTE) } END { print LISTE} ' /etc/mtab` for DIR in $MTList do umount $DIR [ $? -eq 1 ] && echo problème $DIR toujours monté done }
à écrire dans un fichier SD.sh par exemple,( avec VI ?) pour être copié dans /usr/local/bin
# chmod +x SD.sh # devel-su # password # cp SD.sh /usr/local/bin exit
que l’on utilisera de la sorte :
devel-su SD.sh mount
ou
devel-su SD.sh umount
C’est quand même plus propre, n’est-ce pas ?
J’entends déjà les plus exigeants me faire remarquer que ce serait quand même plus simple d’activer ce script par son icône présente sur la grille des applis du Jolla … Et ils ont assez raison …
Mais c’est déjà une autre histoire, racontée par un geek, pleine de hacks et de scripts … Et qui nous emmène encore plus loin ( Mc Bin, Chat qu’Expire) !
bandix400
Je suis passionné de génétique, d’informatique, de mécanique, et je m’arrête là car je manque déjà de temps pour tout faire ; autrement j’y rajouterais volontiers l’électronique, la musique, l’aquariophilie, le graphisme, le jeu Vidéo (simulation de conduite/FPS) et du ju-jitsu traditionnel.
Les derniers articles par bandix400 (tout voir)
- SonyX’2, le retour de la vengeance du fils caché … - 27 janvier 2018
- SFOS, mais en VO - 31 octobre 2017
- Sony’X, où Sailfish X sur Xperia X - 3 octobre 2017