Sur un DD de grosse capacité, j'ai plusieurs partitions. Mais comme
elles prennent de la place sur le bureau quand elles montent, j'ai
l'habitude de les démonter et de monter uniquement celle dont j'ai
ponctuellement besoin.à l'aide d'un alias.
Une façpn de procéder est par ex.
alias ssd="diskutil mountDisk /dev/disk7"
alias s1="diskutil mountDisk /dev/disk5"
alias s2="diskutil mountDisk /dev/disk4"
alias s3="diskutil mountDisk /dev/disk6"
Bref, cela me convient car la partion désirée monte rapidement.
Mais il y a un hic. C'est que pour une raison inexplicable, le nom des
partion change après une extinction du Mac.
s1 ne monte pas disk5 mais disk6 ou autre au hasard.
Seul ssd disk7 qui est le DD interne ne change pas (pour l'instant).
Bref, y a t-il une explication à cela ? Car, du coup; les alias ne
servent plus à rien.
--
A+
--
Romer
> Je viens de le faire et le démontage de Sto 1 s'est bien effectué (en > n'omettant point les apostrophes)
Le démontage s'est bien passé car l'ordi n'a pâs éré redémarré pour faire cela.
Pardon ? Tu pourras redémarrer 100 fois l'ordi, la partition "Sto 1" portera toujours le même nom !!!
La bizarrerie cintinue. Je suis sorti, ai éteint l'ordi et le bazar a continué. En fait c'est le Physical Store (par ex. disk3s4) ,et l'Identifier (disk3) qui changent.
Oui, on l'a compris mais... la partition "Sto 1" s'appelle toujours "Sto 1", non ? Et "diskutil umount 'Sto 1'" doit continuer à être opérant sur cette partition ! Cordialement. -- Michel Vauquois - <http://michelvauquois.fr> Nouveau : <http://art-doise-4.michelvauquois.free-h.fr> et <http://art-doise-5.michelvauquois.free-h.fr>
Bernd <romer@bernd.invalid> a attiré mon attention en écrivant :
> > Je viens de le faire et le démontage de Sto 1 s'est bien effectué (en
> > n'omettant point les apostrophes)
Le démontage s'est bien passé car l'ordi n'a pâs éré redémarré pour
faire cela.
Pardon ? Tu pourras redémarrer 100 fois l'ordi, la partition "Sto 1"
portera toujours le même nom !!!
La bizarrerie cintinue. Je suis sorti, ai éteint l'ordi et le bazar a
continué.
En fait c'est le Physical Store (par ex. disk3s4) ,et l'Identifier
(disk3) qui changent.
Oui, on l'a compris mais... la partition "Sto 1" s'appelle toujours "Sto
1", non ? Et "diskutil umount 'Sto 1'" doit continuer à être opérant sur
cette partition !
Cordialement.
--
Michel Vauquois - <http://michelvauquois.fr>
Nouveau : <http://art-doise-4.michelvauquois.free-h.fr>
et <http://art-doise-5.michelvauquois.free-h.fr>
> Je viens de le faire et le démontage de Sto 1 s'est bien effectué (en > n'omettant point les apostrophes)
Le démontage s'est bien passé car l'ordi n'a pâs éré redémarré pour faire cela.
Pardon ? Tu pourras redémarrer 100 fois l'ordi, la partition "Sto 1" portera toujours le même nom !!!
La bizarrerie cintinue. Je suis sorti, ai éteint l'ordi et le bazar a continué. En fait c'est le Physical Store (par ex. disk3s4) ,et l'Identifier (disk3) qui changent.
Oui, on l'a compris mais... la partition "Sto 1" s'appelle toujours "Sto 1", non ? Et "diskutil umount 'Sto 1'" doit continuer à être opérant sur cette partition ! Cordialement. -- Michel Vauquois - <http://michelvauquois.fr> Nouveau : <http://art-doise-4.michelvauquois.free-h.fr> et <http://art-doise-5.michelvauquois.free-h.fr>
mv
Bernd a attiré mon attention en écrivant :
img 1 : https://transfer.sh/ha61b/Monte_3.jpg
C'est quoi ce volume en HFS nommé SD_32 ? Une clé USB ? Et je suis étonné de voir que le disque partitionné en 4 apparaisse avec "Kind : USB"... Cordialement. -- Michel Vauquois - <http://michelvauquois.fr> Nouveau : <http://art-doise-4.michelvauquois.free-h.fr> et <http://art-doise-5.michelvauquois.free-h.fr>
Bernd <romer@bernd.invalid> a attiré mon attention en écrivant :
img 1 : https://transfer.sh/ha61b/Monte_3.jpg
C'est quoi ce volume en HFS nommé SD_32 ? Une clé USB ?
Et je suis étonné de voir que le disque partitionné en 4 apparaisse avec
"Kind : USB"...
Cordialement.
--
Michel Vauquois - <http://michelvauquois.fr>
Nouveau : <http://art-doise-4.michelvauquois.free-h.fr>
et <http://art-doise-5.michelvauquois.free-h.fr>
C'est quoi ce volume en HFS nommé SD_32 ? Une clé USB ? Et je suis étonné de voir que le disque partitionné en 4 apparaisse avec "Kind : USB"... Cordialement. -- Michel Vauquois - <http://michelvauquois.fr> Nouveau : <http://art-doise-4.michelvauquois.free-h.fr> et <http://art-doise-5.michelvauquois.free-h.fr>
josephb
MV rappela à notre souvenir :
Je suis en train de penser aux scripts pour monter et démonter sélectivement des volumes que nous avons faits (toi surtout), et en voyant le méli-mélo en format APFS je me demande si ces cripts sont adaptables ! :-(
Donc tu te rappelles que tous les tracassins que Bernd rencontre, nous avions dû y faire face et après plusieurs déconvenues, avec quelques ruses de derrière les fagots on en était bien venu à bout. On avait en quelque sorte démontré qu'espérer monter /à coup sûr/ un volume depuis le Terminal et une unique ligne shell était illusoire. De fait, notre outil aurait pu assez facilement être réduit, adapté à la production d'une liste uniquement des "volumes montables", accessible depuis le menu Script, ce qui aurait pu convenir à l'O P, mais faute de pouvoir tester ce que ça donne avec des volumes en APFS, je n'ai même pas cherché. La voie qu'évoque Francis Chartier (les UUID) est aussi très intérressante, pas des plus souples, mais une fois dans le script on s'en fout ; cependant là encore sous réserve que la commande shell qu'il utilise (qui ne date pas d'hier) continue à accèder correctement aux infos des APFS. -- J. B.
MV <mv@orange.invalid> rappela à notre souvenir :
Je suis en train de penser aux scripts pour monter et démonter
sélectivement des volumes que nous avons faits (toi surtout), et en
voyant le méli-mélo en format APFS je me demande si ces cripts sont
adaptables ! :-(
Donc tu te rappelles que tous les tracassins que Bernd rencontre, nous
avions dû y faire face et après plusieurs déconvenues, avec quelques
ruses de derrière les fagots on en était bien venu à bout.
On avait en quelque sorte démontré qu'espérer monter /à coup sûr/ un
volume depuis le Terminal et une unique ligne shell était illusoire.
De fait, notre outil aurait pu assez facilement être réduit, adapté à la
production d'une liste uniquement des "volumes montables", accessible
depuis le menu Script, ce qui aurait pu convenir à l'O P, mais faute de
pouvoir tester ce que ça donne avec des volumes en APFS, je n'ai même
pas cherché.
La voie qu'évoque Francis Chartier (les UUID) est aussi très
intérressante, pas des plus souples, mais une fois dans le script on
s'en fout ; cependant là encore sous réserve que la commande shell qu'il
utilise (qui ne date pas d'hier) continue à accèder correctement aux
infos des APFS.
Je suis en train de penser aux scripts pour monter et démonter sélectivement des volumes que nous avons faits (toi surtout), et en voyant le méli-mélo en format APFS je me demande si ces cripts sont adaptables ! :-(
Donc tu te rappelles que tous les tracassins que Bernd rencontre, nous avions dû y faire face et après plusieurs déconvenues, avec quelques ruses de derrière les fagots on en était bien venu à bout. On avait en quelque sorte démontré qu'espérer monter /à coup sûr/ un volume depuis le Terminal et une unique ligne shell était illusoire. De fait, notre outil aurait pu assez facilement être réduit, adapté à la production d'une liste uniquement des "volumes montables", accessible depuis le menu Script, ce qui aurait pu convenir à l'O P, mais faute de pouvoir tester ce que ça donne avec des volumes en APFS, je n'ai même pas cherché. La voie qu'évoque Francis Chartier (les UUID) est aussi très intérressante, pas des plus souples, mais une fois dans le script on s'en fout ; cependant là encore sous réserve que la commande shell qu'il utilise (qui ne date pas d'hier) continue à accèder correctement aux infos des APFS. -- J. B.
josephb
MV wrote:
On voit clairement que SSD par ex a changé entre 2 démarrages.
Ah ouais... C'est quand même bigrement zarbi.
Ben non, ça ne devrait pas l'être, pas pour toi, parce que lorsqu'on a fait notre petit programme je t'ai raconté l'aventure (je la remets ci-dessous, c'était le 19 juillet 2017) mais soit tu ne m'as pas crû, soit tu as oublié cet épisode* quand même étonnant. À la suite de quoi j'ai réécrit le programme pour en tenir compte *À ta décharge, tu travaillais sur ta propre version dans ton environnement et tu n'as pas été confronté au problème, donc dans ta tête cela était resté du domaine de l'improbable, vu qu'alors j'étais encore sous Lion et toi en Sierra. écrit le 19/07/2017, extrait : " En parlant d'étonnement, j'ai eu mon lot tout à l'heure : Je benne à peu près tout ce que j'avais écrit jusque là avec l'ancienne approche pour reprendre les modules de ma 1.5. Premier test, extraire les listes des identifiers et noms depuis diskutil. Et quand je lis le résultat je blêmis : ça me renvoie les items en vrac !!. Depuis trois jours, j'ai tellement vu ces listes s'afficher que je les connais par c½ur, et là c'est dans le souk, non seulement dans l'ordre d'apparition des items, mais aussi les identifers attribués aux volumes. Je vérifie, recommence. Pareil :-(( Du coup je lance df -Hlg Et la lumière fut. Pour la première fois depuis que je tripote la commande diskutil, je vois que, aujourd'hui, le disk0 n'est pas le disque de démarrage mais celui de mon Time-Machine, le File System étant logé sur disk1 à disk1s2 qui est donc la racine POSIX "/" de tout la hiérarchie des volumes du Mac allumé ce matin (j'éteins le Mac toutes les nuits). À noter que justement ce matin le Mac, contrairement à certaines fois où il traîne les pieds, a démarré comme d'habitude en un temps record." -- J. B.
MV <mv@orange.invalid> wrote:
> On voit clairement que SSD par ex a changé entre 2 démarrages.
Ah ouais... C'est quand même bigrement zarbi.
Ben non, ça ne devrait pas l'être, pas pour toi, parce que lorsqu'on a
fait notre petit programme je t'ai raconté l'aventure (je la remets
ci-dessous, c'était le 19 juillet 2017) mais soit tu ne m'as pas crû,
soit tu as oublié cet épisode* quand même étonnant.
À la suite de quoi j'ai réécrit le programme pour en tenir compte
*À ta décharge, tu travaillais sur ta propre version dans ton
environnement et tu n'as pas été confronté au problème, donc dans ta
tête cela était resté du domaine de l'improbable, vu qu'alors j'étais
encore sous Lion et toi en Sierra.
écrit le 19/07/2017, extrait :
" En parlant d'étonnement, j'ai eu mon lot tout à l'heure :
Je benne à peu près tout ce que j'avais écrit jusque là avec l'ancienne
approche pour reprendre les modules de ma 1.5.
Premier test, extraire les listes des identifiers et noms depuis
diskutil.
Et quand je lis le résultat je blêmis : ça me renvoie les items en vrac
!!.
Depuis trois jours, j'ai tellement vu ces listes s'afficher que je les
connais par c½ur, et là c'est dans le souk, non seulement dans l'ordre
d'apparition des items, mais aussi les identifers attribués aux
volumes.
Je vérifie, recommence. Pareil :-((
Du coup je lance df -Hlg
Et la lumière fut.
Pour la première fois depuis que je tripote la commande diskutil, je
vois que, aujourd'hui, le disk0 n'est pas le disque de démarrage mais
celui de mon Time-Machine, le File System étant logé sur disk1 à disk1s2
qui est donc la racine POSIX "/" de tout la hiérarchie des volumes du
Mac allumé ce matin (j'éteins le Mac toutes les nuits).
À noter que justement ce matin le Mac, contrairement à certaines fois où
il traîne les pieds, a démarré comme d'habitude en un temps record."
On voit clairement que SSD par ex a changé entre 2 démarrages.
Ah ouais... C'est quand même bigrement zarbi.
Ben non, ça ne devrait pas l'être, pas pour toi, parce que lorsqu'on a fait notre petit programme je t'ai raconté l'aventure (je la remets ci-dessous, c'était le 19 juillet 2017) mais soit tu ne m'as pas crû, soit tu as oublié cet épisode* quand même étonnant. À la suite de quoi j'ai réécrit le programme pour en tenir compte *À ta décharge, tu travaillais sur ta propre version dans ton environnement et tu n'as pas été confronté au problème, donc dans ta tête cela était resté du domaine de l'improbable, vu qu'alors j'étais encore sous Lion et toi en Sierra. écrit le 19/07/2017, extrait : " En parlant d'étonnement, j'ai eu mon lot tout à l'heure : Je benne à peu près tout ce que j'avais écrit jusque là avec l'ancienne approche pour reprendre les modules de ma 1.5. Premier test, extraire les listes des identifiers et noms depuis diskutil. Et quand je lis le résultat je blêmis : ça me renvoie les items en vrac !!. Depuis trois jours, j'ai tellement vu ces listes s'afficher que je les connais par c½ur, et là c'est dans le souk, non seulement dans l'ordre d'apparition des items, mais aussi les identifers attribués aux volumes. Je vérifie, recommence. Pareil :-(( Du coup je lance df -Hlg Et la lumière fut. Pour la première fois depuis que je tripote la commande diskutil, je vois que, aujourd'hui, le disk0 n'est pas le disque de démarrage mais celui de mon Time-Machine, le File System étant logé sur disk1 à disk1s2 qui est donc la racine POSIX "/" de tout la hiérarchie des volumes du Mac allumé ce matin (j'éteins le Mac toutes les nuits). À noter que justement ce matin le Mac, contrairement à certaines fois où il traîne les pieds, a démarré comme d'habitude en un temps record." -- J. B.
pehache
Le 03/01/2018 à 20:09, MV a écrit :
Je mets 2 images prises avec mountnuoM sur un serveur. img 1 : https://transfer.sh/ha61b/Monte_3.jpg img 2 ; https://transfer.sh/puF1L/Montes_1.jpg On voit clairement que SSD par ex a changé entre 2 démarrages.
Ah ouais... C'est quand même bigrement zarbi. Et donc, la remarque faite par pehache aujourd'hui est nulle et non avenue.
Du tout, car ce qu'on voit sur ces captures d'écran ne contredisent pas ce que j'ai écrit précédemment : ce qui a changé c'est le nom du /container/.
Le 03/01/2018 à 20:09, MV a écrit :
Je mets 2 images prises avec mountnuoM sur un serveur.
Je mets 2 images prises avec mountnuoM sur un serveur. img 1 : https://transfer.sh/ha61b/Monte_3.jpg img 2 ; https://transfer.sh/puF1L/Montes_1.jpg On voit clairement que SSD par ex a changé entre 2 démarrages.
Ah ouais... C'est quand même bigrement zarbi. Et donc, la remarque faite par pehache aujourd'hui est nulle et non avenue.
Du tout, car ce qu'on voit sur ces captures d'écran ne contredisent pas ce que j'ai écrit précédemment : ce qui a changé c'est le nom du /container/.
pehache
Le 03/01/2018 à 19:45, Bernd a écrit :
Pour ne plus avoir de problème il faut que tu les montes en utilisant soit les références de périphérique /dev/disk3sY, soit les nom que tu as donnés "Sto Z".
Ni l'un ni l'autre fonctionnent.
???
Le 03/01/2018 à 19:45, Bernd a écrit :
Pour ne plus avoir de problème il faut que tu les montes
en utilisant soit les références de périphérique /dev/disk3sY, soit les
nom que tu as donnés "Sto Z".
Pour ne plus avoir de problème il faut que tu les montes en utilisant soit les références de périphérique /dev/disk3sY, soit les nom que tu as donnés "Sto Z".
Ni l'un ni l'autre fonctionnent.
???
JPP
In article <1ni2i6u.1oaihfklt75zN%, (MV) wrote:
Je comprends mais, en même temps, c'est intéressant et édifiant de voir le bordel dû à l'APFS ! ;-)
"Bordel" tu as bien écrit "bordel" , comme c'est bizarre :-)
In article <1ni2i6u.1oaihfklt75zN%mv@orange.invalid>,
mv@orange.invalid (MV) wrote:
Je comprends mais, en même temps, c'est intéressant et édifiant de voir
le bordel dû à l'APFS ! ;-)
"Bordel" tu as bien écrit "bordel" , comme c'est bizarre :-)
Je comprends mais, en même temps, c'est intéressant et édifiant de voir le bordel dû à l'APFS ! ;-)
"Bordel" tu as bien écrit "bordel" , comme c'est bizarre :-)
someone
MV wrote:
Oui, on l'a compris mais... la partition "Sto 1" s'appelle toujours "Sto 1", non ? Et "diskutil umount 'Sto 1'" doit continuer à être opérant sur cette partition !
Plus facile pour unmounter que pour mounter. Pour mounter, il faut passer par du awk pour récupérer l'identifiant de la partoche, mais je crois avoir vu passer cette solution dans l'enfilade. -- [SbM] "If the French were really intelligent, they'd speak English" (W. Sheed)
MV <mv@orange.invalid> wrote:
Oui, on l'a compris mais... la partition "Sto 1" s'appelle toujours "Sto
1", non ? Et "diskutil umount 'Sto 1'" doit continuer à être opérant sur
cette partition !
Plus facile pour unmounter que pour mounter. Pour mounter, il faut
passer par du awk pour récupérer l'identifiant de la partoche, mais je
crois avoir vu passer cette solution dans l'enfilade.
--
[SbM]
"If the French were really intelligent, they'd speak English" (W. Sheed)
Oui, on l'a compris mais... la partition "Sto 1" s'appelle toujours "Sto 1", non ? Et "diskutil umount 'Sto 1'" doit continuer à être opérant sur cette partition !
Plus facile pour unmounter que pour mounter. Pour mounter, il faut passer par du awk pour récupérer l'identifiant de la partoche, mais je crois avoir vu passer cette solution dans l'enfilade. -- [SbM] "If the French were really intelligent, they'd speak English" (W. Sheed)
someone
SbM wrote:
MV wrote:
Oui, on l'a compris mais... la partition "Sto 1" s'appelle toujours "Sto 1", non ? Et "diskutil umount 'Sto 1'" doit continuer à être opérant sur cette partition !
Plus facile pour unmounter que pour mounter. Pour mounter, il faut passer par du awk pour récupérer l'identifiant de la partoche, mais je crois avoir vu passer cette solution dans l'enfilade.
J'ai retrouvé la ligne que j'utilisais pour ce genre de chose, normalement ça devrait fonctionner : diskutil mount `diskutil list | awk '/Sto1/ {print $6}'` -- [SbM] "If the French were really intelligent, they'd speak English" (W. Sheed)
SbM <someone@nowhere.com> wrote:
MV <mv@orange.invalid> wrote:
> Oui, on l'a compris mais... la partition "Sto 1" s'appelle toujours "Sto
> 1", non ? Et "diskutil umount 'Sto 1'" doit continuer à être opérant sur
> cette partition !
Plus facile pour unmounter que pour mounter. Pour mounter, il faut
passer par du awk pour récupérer l'identifiant de la partoche, mais je
crois avoir vu passer cette solution dans l'enfilade.
J'ai retrouvé la ligne que j'utilisais pour ce genre de chose,
normalement ça devrait fonctionner :
diskutil mount `diskutil list | awk '/Sto1/ {print $6}'`
--
[SbM]
"If the French were really intelligent, they'd speak English" (W. Sheed)
Oui, on l'a compris mais... la partition "Sto 1" s'appelle toujours "Sto 1", non ? Et "diskutil umount 'Sto 1'" doit continuer à être opérant sur cette partition !
Plus facile pour unmounter que pour mounter. Pour mounter, il faut passer par du awk pour récupérer l'identifiant de la partoche, mais je crois avoir vu passer cette solution dans l'enfilade.
J'ai retrouvé la ligne que j'utilisais pour ce genre de chose, normalement ça devrait fonctionner : diskutil mount `diskutil list | awk '/Sto1/ {print $6}'` -- [SbM] "If the French were really intelligent, they'd speak English" (W. Sheed)
romer
Joseph-B wrote:
Donc tu te rappelles que tous les tracassins que Bernd rencontre, nous avions dû y faire face et après plusieurs déconvenues, avec quelques ruses de derrière les fagots on en était bien venu à bout. On avait en quelque sorte démontré qu'espérer monter /à coup sûr/ un volume depuis le Terminal et une unique ligne shell était illusoire. De fait, notre outil aurait pu assez facilement être réduit, adapté à la production d'une liste uniquement des "volumes montables", accessible depuis le menu Script, ce qui aurait pu convenir à l'O P, mais faute de pouvoir tester ce que ça donne avec des volumes en APFS, je n'ai même pas cherché. La voie qu'évoque Francis Chartier (les UUID) est aussi très intérressante, pas des plus souples, mais une fois dans le script on s'en fout ; cependant là encore sous réserve que la commande shell qu'il utilise (qui ne date pas d'hier) continue à accèder correctement aux infos des APFS.
J'ignorais que cette difficulté de montage par scrip shell était connue même avant high sierra. Une recherche sur le web il y a qq jours n'avait rien donné. Donc je m'était tourné vers le forum. -- A+ -- Romer
Joseph-B <josephb@nowhere.invalid> wrote:
Donc tu te rappelles que tous les tracassins que Bernd rencontre, nous
avions dû y faire face et après plusieurs déconvenues, avec quelques
ruses de derrière les fagots on en était bien venu à bout.
On avait en quelque sorte démontré qu'espérer monter /à coup sûr/ un
volume depuis le Terminal et une unique ligne shell était illusoire.
De fait, notre outil aurait pu assez facilement être réduit, adapté à la
production d'une liste uniquement des "volumes montables", accessible
depuis le menu Script, ce qui aurait pu convenir à l'O P, mais faute de
pouvoir tester ce que ça donne avec des volumes en APFS, je n'ai même
pas cherché.
La voie qu'évoque Francis Chartier (les UUID) est aussi très
intérressante, pas des plus souples, mais une fois dans le script on
s'en fout ; cependant là encore sous réserve que la commande shell qu'il
utilise (qui ne date pas d'hier) continue à accèder correctement aux
infos des APFS.
J'ignorais que cette difficulté de montage par scrip shell était connue
même avant high sierra.
Une recherche sur le web il y a qq jours n'avait rien donné. Donc je
m'était tourné vers le forum.
--
A+
--
Romer
Donc tu te rappelles que tous les tracassins que Bernd rencontre, nous avions dû y faire face et après plusieurs déconvenues, avec quelques ruses de derrière les fagots on en était bien venu à bout. On avait en quelque sorte démontré qu'espérer monter /à coup sûr/ un volume depuis le Terminal et une unique ligne shell était illusoire. De fait, notre outil aurait pu assez facilement être réduit, adapté à la production d'une liste uniquement des "volumes montables", accessible depuis le menu Script, ce qui aurait pu convenir à l'O P, mais faute de pouvoir tester ce que ça donne avec des volumes en APFS, je n'ai même pas cherché. La voie qu'évoque Francis Chartier (les UUID) est aussi très intérressante, pas des plus souples, mais une fois dans le script on s'en fout ; cependant là encore sous réserve que la commande shell qu'il utilise (qui ne date pas d'hier) continue à accèder correctement aux infos des APFS.
J'ignorais que cette difficulté de montage par scrip shell était connue même avant high sierra. Une recherche sur le web il y a qq jours n'avait rien donné. Donc je m'était tourné vers le forum. -- A+ -- Romer
