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
Francis Chartier a attiré mon attention en écrivant :
Pour éviter ce genre de problème, sur les unix-like j'utilise habituellement les UUID des partitions
Question de béotien : est-ce qu'un UUID est toujours composé de 5 séquences séparées par un "-" ? Cordialement. -- Michel Vauquois - <http://michelvauquois.fr> Nouveau : <http://art-doise-4.michelvauquois.free-h.fr> et <http://art-doise-5.michelvauquois.free-h.fr>
Francis Chartier <num.0@bisounours-asocial.club> a attiré mon attention
en écrivant :
Pour éviter ce genre de problème, sur les unix-like j'utilise
habituellement les UUID des partitions
Question de béotien : est-ce qu'un UUID est toujours composé de 5
séquences séparées par un "-" ?
Cordialement.
--
Michel Vauquois - <http://michelvauquois.fr>
Nouveau : <http://art-doise-4.michelvauquois.free-h.fr>
et <http://art-doise-5.michelvauquois.free-h.fr>
Francis Chartier a attiré mon attention en écrivant :
Pour éviter ce genre de problème, sur les unix-like j'utilise habituellement les UUID des partitions
Question de béotien : est-ce qu'un UUID est toujours composé de 5 séquences séparées par un "-" ? 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
SbM wrote:
Mon hypothèse c'est que les différents disques ne démarrent peut-être pas forcément toujours aussi vite d'un boot à l'autre, ce qui fait qu'à un moment le disque A peut très bien être « vu » par l'OS juste avant le disque B, puis au boot suivant au contraire le disque B avant le disque A.
Oui, et on peut même dire sans grand risque de se tromper que c'est une procédure en Rom dans le CPU qui préside à cette détection. Notre erreur est d'être OS-X centrés dans l'observation de ces événements. Quand l'ordi démarre, il (le CPU) ne sait absolument rien de ce qui va permettre la réalisation du boot : disque réseau ou local, voire clé USB et encore moins de la nature de l'OS qui va être chargé si on pratique le "Dual-booting" Si on prend 2 DD avec des OS différents, allez, soyons fous, un DD avec deux partitions bootables, une OS X et une Linux, même le fameux UUID du disque ne sera pas le même, car attribué par une procédure Système. La chose qui ne changera jamais est le n° de série du DD gravé dans sa Rom. -- J. B.
SbM <someone@nowhere.com> wrote:
Mon hypothèse c'est que les différents disques ne démarrent peut-être
pas forcément toujours aussi vite d'un boot à l'autre, ce qui fait qu'à
un moment le disque A peut très bien être « vu » par l'OS juste avant le
disque B, puis au boot suivant au contraire le disque B avant le disque
A.
Oui, et on peut même dire sans grand risque de se tromper que c'est une
procédure en Rom dans le CPU qui préside à cette détection.
Notre erreur est d'être OS-X centrés dans l'observation de ces
événements.
Quand l'ordi démarre, il (le CPU) ne sait absolument rien de ce qui va
permettre la réalisation du boot : disque réseau ou local, voire clé USB
et encore moins de la nature de l'OS qui va être chargé si on pratique
le "Dual-booting"
Si on prend 2 DD avec des OS différents, allez, soyons fous, un DD avec
deux partitions bootables, une OS X et une Linux, même le fameux UUID du
disque ne sera pas le même, car attribué par une procédure Système. La
chose qui ne changera jamais est le n° de série du DD gravé dans sa Rom.
--
J. B.
Mon hypothèse c'est que les différents disques ne démarrent peut-être pas forcément toujours aussi vite d'un boot à l'autre, ce qui fait qu'à un moment le disque A peut très bien être « vu » par l'OS juste avant le disque B, puis au boot suivant au contraire le disque B avant le disque A.
Oui, et on peut même dire sans grand risque de se tromper que c'est une procédure en Rom dans le CPU qui préside à cette détection. Notre erreur est d'être OS-X centrés dans l'observation de ces événements. Quand l'ordi démarre, il (le CPU) ne sait absolument rien de ce qui va permettre la réalisation du boot : disque réseau ou local, voire clé USB et encore moins de la nature de l'OS qui va être chargé si on pratique le "Dual-booting" Si on prend 2 DD avec des OS différents, allez, soyons fous, un DD avec deux partitions bootables, une OS X et une Linux, même le fameux UUID du disque ne sera pas le même, car attribué par une procédure Système. La chose qui ne changera jamais est le n° de série du DD gravé dans sa Rom. -- J. B.
josephb
Francis Chartier wrote:
Ce n'est pas propre à Apple, c'est un problème connu depuis longtemps, et c'est entre autres pour cette raison (l'attribution des identifiants peut changer au démarrage en fonction des disques disponibles ou pas) que l'utilisation des UUID (identifiants uniques générés lors de la création du système de fichier) pour désigner les volumes est la méthode préconisée depuis des années parce que c'est invariable (sauf à éffacer/recréer un système de fichier ou utilisation volondiare d'une commande prévue pour changer cet UUID).
OK… je n'avais pas encore lu ta réponse quand j'ai écrit la mienne à l'instant, mais ce que tu cites confirme l'idée que je m'en faisais "intuitivement". Merci pour les liens. -- J. B.
Francis Chartier <num.0@bisounours-asocial.club> wrote:
Ce n'est pas propre à Apple, c'est un problème connu depuis longtemps,
et c'est entre autres pour cette raison (l'attribution des identifiants
peut changer au démarrage en fonction des disques disponibles ou pas)
que l'utilisation des UUID (identifiants uniques générés lors de la
création du système de fichier) pour désigner les volumes est la méthode
préconisée depuis des années parce que c'est invariable (sauf à
éffacer/recréer un système de fichier ou utilisation volondiare d'une
commande prévue pour changer cet UUID).
OK… je n'avais pas encore lu ta réponse quand j'ai écrit la mienne à
l'instant, mais ce que tu cites confirme l'idée que je m'en faisais
"intuitivement".
Ce n'est pas propre à Apple, c'est un problème connu depuis longtemps, et c'est entre autres pour cette raison (l'attribution des identifiants peut changer au démarrage en fonction des disques disponibles ou pas) que l'utilisation des UUID (identifiants uniques générés lors de la création du système de fichier) pour désigner les volumes est la méthode préconisée depuis des années parce que c'est invariable (sauf à éffacer/recréer un système de fichier ou utilisation volondiare d'une commande prévue pour changer cet UUID).
OK… je n'avais pas encore lu ta réponse quand j'ai écrit la mienne à l'instant, mais ce que tu cites confirme l'idée que je m'en faisais "intuitivement". Merci pour les liens. -- J. B.
Francis Chartier
Le Fri, 5 Jan 2018 13:54:42 +0100, (MV) écrivait :
Francis Chartier a attiré mon attention en écrivant :
Pour éviter ce genre de problème, sur les unix-like j'utilise habituellement les UUID des partitions
Question de béotien : est-ce qu'un UUID est toujours composé de 5 séquences séparées par un "-" ?
Hop'la. https://fr.wikipedia.org/wiki/Universal_Unique_Identifier Pour les partitions/volumes c'est normalement généré lors de la création du file system et ne devrait pas changer sauf à effacer/recréer un file system. Il existe des commandes permettant de le modifier de manière non destructive mais c'est suffisamment invariable pour être utilisé, en présentant de surcroit l'avantage pour les scripts d'éviter des e spaces et autres plaisanteries dans les indentifiants. -- Francis Chartier Bisounours Asocial #0
Le Fri, 5 Jan 2018 13:54:42 +0100, mv@orange.invalid (MV) écrivait :
Francis Chartier <num.0@bisounours-asocial.club> a attiré mon
attention en écrivant :
> Pour éviter ce genre de problème, sur les unix-like j'utilise
> habituellement les UUID des partitions
Question de béotien : est-ce qu'un UUID est toujours composé de 5
séquences séparées par un "-" ?
Pour les partitions/volumes c'est normalement généré lors de la
création du file system et ne devrait pas changer sauf à
effacer/recréer un file system.
Il existe des commandes permettant de le modifier de manière non
destructive mais c'est suffisamment invariable pour être utilisé, en
présentant de surcroit l'avantage pour les scripts d'éviter des e spaces
et autres plaisanteries dans les indentifiants.
Le Fri, 5 Jan 2018 13:54:42 +0100, (MV) écrivait :
Francis Chartier a attiré mon attention en écrivant :
Pour éviter ce genre de problème, sur les unix-like j'utilise habituellement les UUID des partitions
Question de béotien : est-ce qu'un UUID est toujours composé de 5 séquences séparées par un "-" ?
Hop'la. https://fr.wikipedia.org/wiki/Universal_Unique_Identifier Pour les partitions/volumes c'est normalement généré lors de la création du file system et ne devrait pas changer sauf à effacer/recréer un file system. Il existe des commandes permettant de le modifier de manière non destructive mais c'est suffisamment invariable pour être utilisé, en présentant de surcroit l'avantage pour les scripts d'éviter des e spaces et autres plaisanteries dans les indentifiants. -- Francis Chartier Bisounours Asocial #0
mv
Francis Chartier a attiré mon attention en écrivant :
Question de béotien : est-ce qu'un UUID est toujours composé de 5 séquences séparées par un "-" ?
Merci mais ce n'est pas vraiment spécifié *5* groupes de caractères (ou alors j'ai lu trop vite) même si l'exemple donné par wikipedia laisse penser que la réponse est oui... Cordialement. -- Michel Vauquois - <http://michelvauquois.fr> Nouveau : <http://art-doise-4.michelvauquois.free-h.fr> et <http://art-doise-5.michelvauquois.free-h.fr>
Francis Chartier <num.0@bisounours-asocial.club> a attiré mon attention
en écrivant :
> Question de béotien : est-ce qu'un UUID est toujours composé de 5
> séquences séparées par un "-" ?
Merci mais ce n'est pas vraiment spécifié *5* groupes de caractères (ou
alors j'ai lu trop vite) même si l'exemple donné par wikipedia laisse
penser que la réponse est oui...
Cordialement.
--
Michel Vauquois - <http://michelvauquois.fr>
Nouveau : <http://art-doise-4.michelvauquois.free-h.fr>
et <http://art-doise-5.michelvauquois.free-h.fr>
Merci mais ce n'est pas vraiment spécifié *5* groupes de caractères (ou alors j'ai lu trop vite) même si l'exemple donné par wikipedia laisse penser que la réponse est oui... Cordialement. -- Michel Vauquois - <http://michelvauquois.fr> Nouveau : <http://art-doise-4.michelvauquois.free-h.fr> et <http://art-doise-5.michelvauquois.free-h.fr>
romer
MV wrote:
Bernd a attiré mon attention en écrivant :
J'espère que ça convient comme cela.
J'ai adapté mon script d'hier à ta configuration et j'obtiens : ********** vendredi 5 janvier 2018 à 12:17:02 disk2s2 SD_32 disk4s1 Volume Sto 2 disk5s1 Volume Sto 1 disk6s1 Volume Sto 3 disk7s1 Volume SSD **********
Oui c'est propre et donc bien lisible. Après redémarrage, les diskXs1 ont encore changé (normal). Mais je constate une chose (sans en avoir la preuve, juste de mémoire) : le no do SSD ne changerait pas - toujours disk7s1 Si tel était le cas, y aurait-il une explication à cela ? -- A+ -- Romer
MV <mv@orange.invalid> wrote:
Bernd <romer@bernd.invalid> a attiré mon attention en écrivant :
> J'espère que ça convient comme cela.
J'ai adapté mon script d'hier à ta configuration et j'obtiens :
**********
vendredi 5 janvier 2018 à 12:17:02
disk2s2 SD_32
disk4s1 Volume Sto 2
disk5s1 Volume Sto 1
disk6s1 Volume Sto 3
disk7s1 Volume SSD
**********
Oui c'est propre et donc bien lisible.
Après redémarrage, les diskXs1 ont encore changé (normal).
Mais je constate une chose (sans en avoir la preuve, juste de mémoire) :
le no do SSD ne changerait pas - toujours disk7s1
Si tel était le cas, y aurait-il une explication à cela ?
--
A+
--
Romer
J'ai adapté mon script d'hier à ta configuration et j'obtiens : ********** vendredi 5 janvier 2018 à 12:17:02 disk2s2 SD_32 disk4s1 Volume Sto 2 disk5s1 Volume Sto 1 disk6s1 Volume Sto 3 disk7s1 Volume SSD **********
Oui c'est propre et donc bien lisible. Après redémarrage, les diskXs1 ont encore changé (normal). Mais je constate une chose (sans en avoir la preuve, juste de mémoire) : le no do SSD ne changerait pas - toujours disk7s1 Si tel était le cas, y aurait-il une explication à cela ? -- A+ -- Romer
pehache
Le 05/01/2018 à 14:10, Joseph-B a écrit :
SbM wrote:
Mon hypothèse c'est que les différents disques ne démarrent peut-être pas forcément toujours aussi vite d'un boot à l'autre, ce qui fait qu'à un moment le disque A peut très bien être « vu » par l'OS juste avant le disque B, puis au boot suivant au contraire le disque B avant le disque A.
Oui, et on peut même dire sans grand risque de se tromper que c'est une procédure en Rom dans le CPU qui préside à cette détection.
Je dirais plutôt dans le BIOS/EFI
Notre erreur est d'être OS-X centrés dans l'observation de ces événements. Quand l'ordi démarre, il (le CPU) ne sait absolument rien de ce qui va permettre la réalisation du boot : disque réseau ou local, voire clé USB et encore moins de la nature de l'OS qui va être chargé si on pratique le "Dual-booting" Si on prend 2 DD avec des OS différents, allez, soyons fous, un DD avec deux partitions bootables, une OS X et une Linux, même le fameux UUID du disque ne sera pas le même, car attribué par une procédure Système. La chose qui ne changera jamais est le n° de série du DD gravé dans sa Rom.
A mon avis, une fois un UUID attribué à une partition, il ne change pas, même si on boote sur un autre OS ou qu'on monte la partition sur un autre ordi. Logiquement, l'UUID est écrit sur le disque lui-même.
Le 05/01/2018 à 14:10, Joseph-B a écrit :
SbM <someone@nowhere.com> wrote:
Mon hypothèse c'est que les différents disques ne démarrent peut-être
pas forcément toujours aussi vite d'un boot à l'autre, ce qui fait qu'à
un moment le disque A peut très bien être « vu » par l'OS juste avant le
disque B, puis au boot suivant au contraire le disque B avant le disque
A.
Oui, et on peut même dire sans grand risque de se tromper que c'est une
procédure en Rom dans le CPU qui préside à cette détection.
Je dirais plutôt dans le BIOS/EFI
Notre erreur est d'être OS-X centrés dans l'observation de ces
événements.
Quand l'ordi démarre, il (le CPU) ne sait absolument rien de ce qui va
permettre la réalisation du boot : disque réseau ou local, voire clé USB
et encore moins de la nature de l'OS qui va être chargé si on pratique
le "Dual-booting"
Si on prend 2 DD avec des OS différents, allez, soyons fous, un DD avec
deux partitions bootables, une OS X et une Linux, même le fameux UUID du
disque ne sera pas le même, car attribué par une procédure Système. La
chose qui ne changera jamais est le n° de série du DD gravé dans sa Rom.
A mon avis, une fois un UUID attribué à une partition, il ne change pas,
même si on boote sur un autre OS ou qu'on monte la partition sur un
autre ordi. Logiquement, l'UUID est écrit sur le disque lui-même.
Mon hypothèse c'est que les différents disques ne démarrent peut-être pas forcément toujours aussi vite d'un boot à l'autre, ce qui fait qu'à un moment le disque A peut très bien être « vu » par l'OS juste avant le disque B, puis au boot suivant au contraire le disque B avant le disque A.
Oui, et on peut même dire sans grand risque de se tromper que c'est une procédure en Rom dans le CPU qui préside à cette détection.
Je dirais plutôt dans le BIOS/EFI
Notre erreur est d'être OS-X centrés dans l'observation de ces événements. Quand l'ordi démarre, il (le CPU) ne sait absolument rien de ce qui va permettre la réalisation du boot : disque réseau ou local, voire clé USB et encore moins de la nature de l'OS qui va être chargé si on pratique le "Dual-booting" Si on prend 2 DD avec des OS différents, allez, soyons fous, un DD avec deux partitions bootables, une OS X et une Linux, même le fameux UUID du disque ne sera pas le même, car attribué par une procédure Système. La chose qui ne changera jamais est le n° de série du DD gravé dans sa Rom.
A mon avis, une fois un UUID attribué à une partition, il ne change pas, même si on boote sur un autre OS ou qu'on monte la partition sur un autre ordi. Logiquement, l'UUID est écrit sur le disque lui-même.
mv
Bernd a attiré mon attention en écrivant :
Mais je constate une chose (sans en avoir la preuve, juste de mémoire) : le no do SSD ne changerait pas - toujours disk7s1
Ben non, pas du tout ! Sur <https://transfer.sh/puF1L/Montes_1.jpg>, le SSD est disk6s1 Et dans ton message <1ni0i7t.d3tfsendjvzbN%, il est disk5s1 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 :
Mais je constate une chose (sans en avoir la preuve, juste de mémoire) :
le no do SSD ne changerait pas - toujours disk7s1
Ben non, pas du tout !
Sur <https://transfer.sh/puF1L/Montes_1.jpg>, le SSD est disk6s1
Et dans ton message <1ni0i7t.d3tfsendjvzbN%romer@bernd.invalid>, il est
disk5s1
Cordialement.
--
Michel Vauquois - <http://michelvauquois.fr>
Nouveau : <http://art-doise-4.michelvauquois.free-h.fr>
et <http://art-doise-5.michelvauquois.free-h.fr>
Mais je constate une chose (sans en avoir la preuve, juste de mémoire) : le no do SSD ne changerait pas - toujours disk7s1
Ben non, pas du tout ! Sur <https://transfer.sh/puF1L/Montes_1.jpg>, le SSD est disk6s1 Et dans ton message <1ni0i7t.d3tfsendjvzbN%, il est disk5s1 Cordialement. -- Michel Vauquois - <http://michelvauquois.fr> Nouveau : <http://art-doise-4.michelvauquois.free-h.fr> et <http://art-doise-5.michelvauquois.free-h.fr>
g4fleurot
michel s'est exprimé en ces termes :
do shell script "diskutil mount $(diskutil list |awk '/DEUXTiO/ {print $6} ')"
et tout simplement : do shell script "diskutil mount 'DEUXTiO'" cà ne fonctionne pas ? -- Gérard FLEUROT plus un
michel s'est exprimé en ces termes :
do shell script "diskutil mount $(diskutil list |awk '/DEUXTiO/ {print
$6} ')"
et tout simplement :
do shell script "diskutil mount 'DEUXTiO'"
cà ne fonctionne pas ?
do shell script "diskutil mount $(diskutil list |awk '/DEUXTiO/ {print $6} ')"
et tout simplement : do shell script "diskutil mount 'DEUXTiO'" cà ne fonctionne pas ? -- Gérard FLEUROT plus un
mv
Francis Chartier a attiré mon attention en écrivant :
Pour éviter ce genre de problème, sur les unix-like j'utilise habituellement les UUID des partitions, qu'on obtient grâce à la commande : diskutil info <ident>
Pour mon disque de démarrage, j'obtiens entre autre : Volume UUID: 0E239BC6-F960-3107-89CF-1C97F78BB46B Disk / Partition UUID: 18DF09AD-7E8D-4E72-916E-A1AB142FF799 et "mount" ou "umount" fonctionnent avec les deux UUID. C'est la même chose avec la partition de récupération Recovery HD et avec la partition EFI. Pour une clé USB (en HFS), seule la ligne "Volume UUID" apparaît. Cordialement. -- Michel Vauquois - <http://michelvauquois.fr> Nouveau : <http://art-doise-4.michelvauquois.free-h.fr> et <http://art-doise-5.michelvauquois.free-h.fr>
Francis Chartier <num.0@bisounours-asocial.club> a attiré mon attention
en écrivant :
Pour éviter ce genre de problème, sur les unix-like j'utilise
habituellement les UUID des partitions, qu'on obtient grâce à la
commande :
diskutil info <ident>
Pour mon disque de démarrage, j'obtiens entre autre :
Volume UUID: 0E239BC6-F960-3107-89CF-1C97F78BB46B
Disk / Partition UUID: 18DF09AD-7E8D-4E72-916E-A1AB142FF799
et "mount" ou "umount" fonctionnent avec les deux UUID.
C'est la même chose avec la partition de récupération Recovery HD et
avec la partition EFI.
Pour une clé USB (en HFS), seule la ligne "Volume UUID" apparaît.
Cordialement.
--
Michel Vauquois - <http://michelvauquois.fr>
Nouveau : <http://art-doise-4.michelvauquois.free-h.fr>
et <http://art-doise-5.michelvauquois.free-h.fr>
Francis Chartier a attiré mon attention en écrivant :
Pour éviter ce genre de problème, sur les unix-like j'utilise habituellement les UUID des partitions, qu'on obtient grâce à la commande : diskutil info <ident>
Pour mon disque de démarrage, j'obtiens entre autre : Volume UUID: 0E239BC6-F960-3107-89CF-1C97F78BB46B Disk / Partition UUID: 18DF09AD-7E8D-4E72-916E-A1AB142FF799 et "mount" ou "umount" fonctionnent avec les deux UUID. C'est la même chose avec la partition de récupération Recovery HD et avec la partition EFI. Pour une clé USB (en HFS), seule la ligne "Volume UUID" apparaît. Cordialement. -- Michel Vauquois - <http://michelvauquois.fr> Nouveau : <http://art-doise-4.michelvauquois.free-h.fr> et <http://art-doise-5.michelvauquois.free-h.fr>
