10.12 Sierra DD en RAID 1 et icônes

[guytoon48]

Bonjour,

Je viens de faire l'acquisition d'un boitier ICY BOX IB-RD3621U3. Je l'ai chargé de 2 disques dur de 3To chacun. J'ai configuré le boitier en RAID 1 et me retrouve avec 2 icônes distinctes sur le bureau : étrange non? J'ai formaté chaque disque en mac osX étendu, schéma de partition GUID.
Comment les unifier? car je devrais avoir qu'un volume visible, non?

 

[guytoon48]

Suis une buse; j'avais pas vu que dans l'utilitaire de disque Sierra, le gestionnaire RAID était caché dans les menus.
Désolé pour le bruit!!

 

[Membre supprimé 1060554]

Salut guytoon

Une Matrice RAID 1 (= miroir) n'exporte par définition qu'un seul volume monté > égal en taille grosso modo à un seul des 2 disques associés : près de 3 To pour toi.

Si tu veux une inspection du dispositif actuel de tes disques et de la matrice RAID > tu n'as qu'à aller à : Applications > Utilitaires > lancer le «Terminal». Dans la fenêtre ouverte > passe (l'une après l'autre) les 2 commandes (simplement informatives) :

diskutil list
diskutil ar list

et ↩︎ (presse la touche "Entrée" du clavier après chaque commande pour l'activer) -->

• la première va te retourner le tableau des disques attachés à ton Mac (en interne / externe) > avec leurs tables de partition > et leurs partitions décrites en format > nom > taille > appareil ;
• la seconde > le tableau spécifique de la Matrice RAID 1.

=> tu n'as qu'à poster ici ces 2 tableaux en copier-coller (sans prendre de capture d'écran). Juste histoire de contempler le tableau d'ensemble > même s'il n'y a rien à modifier...

 

[guytoon48]

Voilà 1ere commande :

/dev/disk0 (internal, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *500.1 GB disk0

1: EFI EFI 209.7 MB disk0s1

2: Apple_HFS Macintosh SSD 499.1 GB disk0s2

3: Apple_Boot Recovery HD 650.0 MB disk0s3


/dev/disk1 (external, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *3.0 TB disk1

1: EFI EFI 209.7 MB disk1s1

2: Apple_RAID 3.0 TB disk1s2

3: Apple_Boot Boot OS X 134.2 MB disk1s3


/dev/disk2 (external, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *3.0 TB disk2

1: EFI EFI 209.7 MB disk2s1

2: Apple_RAID 3.0 TB disk2s2

3: Apple_Boot Boot OS X 134.2 MB disk2s3


/dev/disk3 (external, virtual):

#: TYPE NAME SIZE IDENTIFIER

0: Apple_HFS Stock +3.0 TB disk3


/dev/disk4 (external, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *999.5 GB disk4

1: EFI EFI 209.7 MB disk4s1

2: Apple_HFS Time Machine MBP 150.0 GB disk4s2

3: Apple_HFS Stockage 849.0 GB disk4s3


Seconde commande :

iMac-de-Guy-Vinet:~ guyvinet$ diskutil ar list

AppleRAID sets (1 found)

===============================================================================

Name: Sans titre

Unique ID: FEE59D95-508D-44B8-860F-10FC24FECD04

Type: Mirror

Status: Online

Size: 3.0 TB (3000248991744 Bytes)

Rebuild: automatic

Device Node: disk3

-------------------------------------------------------------------------------

# DevNode UUID Status Size

-------------------------------------------------------------------------------

0 disk1s2 742C6762-E384-4C99-9C30-4F87324CD382 Online 3000248991744

1 disk2s2 6C9509C6-5D19-4EF4-9F6C-082048588488 Online 3000248991744

===============================================================================

Merci.

 

[Membre supprimé 1060554]

Tes 2 disques supports de 3 To (disk1 & disk2) ont chacun une distribution de partitions conforme aux attentes : de type --> EFI > bande_RAID > booter_RAID.

La Matrice RAID a bien enregistré les bandes RAID (disk1s2 & disk2s2) > avec une taille exactement égale pour chacune.

Elle exporte un Volume Virtuel unique égal à la taille d'une seule des bandes_RAID (3 To) > avec comme device node (nœud d'appareil logique) : disk3.

Le device (appareil) correspondant à ce device node > tu le retrouves bien listé dans le tableau de la commande diskutil list -->

/dev/disk3 (external, virtual):
#:      TYPE NAME      SIZE     IDENTIFIER
0: Apple_HFS Stock    +3.0 TB   disk3

Si le nom du volume monté (Stock) diffère du nom identitaire de la Matrice RAID (Sans titre) > c'est parce que tu peux avoir renommé le premier : aucun problème intrinsèque.

=> je n'aperçois pas d'anomalie. Est-ce que tu vois toujours 2 icônes de volumes montés affichées sur le Bureau ?

 

[guytoon48]

Non, après être passé ( comme il se devait) par le gestionnaire RAID de l'utilitaire de disque, j'ai bien un volume unique sur le bureau;
D'après mes recherches, il est impossible de partitionner un volume déclaré en RAID 1;
Confirmation?...
Bonne soirée.

 

[Membre supprimé 1060554]

D'après mes recherches, il est impossible de partitionner un volume déclaré en RAID 1;
Confirmation?...

En effet : c'est un volume virtuel exporté par la Matrice RAID 1 avec une taille fixe.​

 

[guytoon48]

Question subsidiaire : si je dépose une image disque vierge sur ce disque, je devrais pouvoir y faire un clone de mon système?...

 

[Membre supprimé 1060554]

Bien sûr : tu peux très bien avoir une image-disque résidente de ton volume RAID : Stock > monter son volume (appelons-le par exemple : CLONE) > et cloner le volume de ton OS dans le volume CLONE.

Il n'y a aucun obstacle logique à avoir ainsi un dispositif où un volume monte à partir d'un disque virtuel résident lui-même d'un volume. C'est ce qui se passe avec la partition de secours Recovery HD. Lors d'un démarrage sur le Recovery OS > le volume Recovery HD se trouve monté > et dans ce volume une image-disque BaseSystem.dmg de 450 Mo se trouve à son tour montée en décompression en un volume OS X Base System de 1,2 Go qui recèle le Recovery OS à démarrer. [Configurer un dispositif de lancement capable de faire monter le volume de l'image-disque secondaire > avant d'activer son Système - bref avoir un Système résident d'une image-disque qui soit démarrable : ça, par contre, c'est une tout autre affaire].

Le volume Macintosh HD de ton OS ayant une taille de 500 Go > tu peux de créer une image-disque DMG à taille fixe de 500 Go également > ou tu peux créer une image-disque SPARSEBUNDLE à taille extensible (dont la propriété est de ne pas prendre à vide un espace-disque correspondant à sa taille théorique maximum > mais seulement une tare d'environ 500 Mo > sa taille réelle en consommation d'espace-disque évoluant avec le poids des données recelées dans son volume. Ainsi : il serait possible de créer un image-disque SPARSEBUNDLE de 700 To (théoriques) dans le volume Stock de 3 To > l'image SPARSEBUNDLE ne prendrait qu'environ 500 Mo à vide. Exemple absurde dans son exagération > mais illustrant la propriété des images dites de "faible densité" = extensibles).

 

[guytoon48]

Bonjour,

Apparemment, CCC me dit que je ne pourrai pas démarrer osX à partir de ce clone...

 

[Membre supprimé 1060554]

Si ton clone est contenu dans le volume d'une image-disque > image-disque résidente du volume Stock de ta matrice RAID > il faudrait pour que le clone en question soit démarrable que des boot_files (fichiers de démarrage) existent dans l'espace primaire du volume Stock > comportant :

• un boot_loader : boot.efi (fichier démarreur) adressable et exécutable par l'EFI ;
• un cache de démarrage prelinkedkernel ;
• un fichier com.apple.Boot.plist contenant les 2 clés :
  • Kernel Cache (associée à une chaîne mentionnant l'adresse du cache de démarrage prelinkedkernel) ;
  • Kernel Flags (associée à une chaîne mentionnant l'adresse de l'image-disque à monter en volume par le kernel pour adresser les composants du Système à démarrer).
  dont le boot_loader boot.efi passerait les instructions au kernel du prelinkedkernel.

=> «Carbon Copy Cloner» ne gère pas ce type de distribution de démarrage "au second degré". Par contre > tu pourrais utiliser le volume RAID Stock comme destination directe du clonage de ton volume-Système > et alors le volume Stock serait classiquement démarrable («CCC» gère ce dispositif "au premier degré").

Mais la disproportion des tailles des volumes (source = 500 Go vs destination = 3 To) rend ce choix plutôt "improductif". Il serait plus simple que tu aies un DDE classique de 500 Go dont le volume contiendrait le clone démarrable de ton volume-Système.

Tu pourrais alternativement créer une image-disque sparsebundle dans ton volume Stock > dans le volume de laquelle tu copierais des documents. Ce serait alors un volume de stockage non démarrable > son support-disque virtuel résidant dans le volume Stock démarrable. Ou utiliser un dossier standard spécifiquement créé à la racine de Stock pour y copier toutes sortes de données.

Mais attention : ces types de distributions sont la porte ouverte à des complications --> utiliser un même volume comme à la fois de démarrage et de stockage.

Il serait encore possible de supprimer ton actuelle Matrice RAID > pour re-séparer tes 2 disques de 3 To > et alors repartitionner chacun en 2 partitions (par exemple) : une partition majeure de 2,5 To (par exemple) et une partition mineure de 500 Go (par exemple). Tu aurais donc : disk1s2 = 2,5 To + disk2s3 = 500 Go pour le disk1 et disk2s2 = 2,5 To + disk2s3 = 500 Go pour le disk2.

Tu pourrais alors recréer une matrice RAID 1 en association des 2 partitions majeures disk1s2 et disk2s2 devenant des bandes RAID > ce qui exporterait un volume Stock unique de 2,5 To (avec backup invisible). Il te resterait 2 volumes de 500 Go chacun montant indépendamment sur les 2 partitions mineures indépendantes : disk1s3 et disk2s3. Tu pourrais avoir un clone démarrable du volume de ton OS dans le premier volume > et éventuellement un clone miroir dans le second volume.

Le procédé logiciel AppleRAID préfère intrinsèquement gérer des disques entiers > plutôt que des partitions de disque > mais si les partitions pointées ont des tailles identiques (ce qui serait le cas pour des partitions majeures créées avant les partitions mineures dont la taille peut connaître, elle, de petites fluctuations) > alors le procédé AppleRAID honore ce choix.

=> sois conscient (en résumé) > qu'il y a quand même ici encore une "fuite en avant" dans la complication...

 

[guytoon48]

Merci pour ces explications. J'ai depuis copié pas mal de fichiers sur ce nouveau disque, donc je ne vais pas réinitialiser même si la solution décrite dans l'avant dernier paragraphe est engageante.
J'ai résolu le petit souci avec CCC; dans sa fenêtre principale, rubrique "destination" j'ai opté pour une nouvelle image disque "faible densité" qui génère un fichier .sparseimage (extensible) et ma foi, çà fonctionne parfaitement. Le clonage est en cours, j'espère ne pas avoir de mauvaise surprise au moment du test de démarrage sur la cible. En tout état de cause, aucun avertissement préalable de la part de CCC lors de l'établissement de la tâche!

 

[Membre supprimé 1060554]

Tu vas bien voir > à complétion de la tâche de clonage > en re-démarrant ton Mac la touche "alt" tenue pressée à partir du gong ! --> si un volume Clone_iMac est affiché par le boot_manager > càd. choisissable comme volume de démarrage.

Je présume que ce ne sera pas le cas. Mais avec Mike Bombich - "sait-on jamais" ? - Si jamais le volume qui monte à partir de l'image-disque Clone_iMac.sparseimage (résidente du volume RAID Stockage) était démarrable > c'est que Bombich aurait implémenté «Carbon Copy Cloner» d'une capacité à créer les boot_files de démarrage du Système recelé dans le volume d'une image-disque. Ce serait une première !

Dans ce cas-là > ne t'étonne pas si je te passais une commande (informative) destinée à lister les boot_files en question dans le volume Stockage. Par curiosité intellectuelle à l'égard de cet exploit.

[À franchement parler : je n'y crois pas. Car si Bombich était capable de faire créer une telle distribution de démarrage à «CCC» > je ne vois pas pourquoi il continuerait de ne pas gérer la création et la maintenance d'une partition de récupération «Recovery HD» > lorsque le format de la partition-Système est CoreStorage : un cas de figure nettement plus facile à assumer que celui de la création des boot_files de démarrage du volume d'une image-disque...]

 

[Membre supprimé 1060554]

Retour d'expérimentation.

J'ai créé dans un volume expérimental de 120 Go Untitled > une image-disque DMG de 100 Go BOOT.dmg > monté son volume CAPITAN > cloné avec «CCC» le contenu de mon volume-Système (OS «El Capitan») dans le volume CAPITAN de l'image-disque. «CCC» affiche d'entrée un panneau d'avertissement annonçant que le clone ne sera pas démarrable > car résidant dans une image-disque. Bien entendu : aucun volume correspondant n'est affiché par le boot_manager (touche "alt").

J'ai esquissé alors une parade : j'ai inscrit dans l'espace du volume Untitled > à côté donc de l'image-disque BOOT.dmg > un boot_loader boot.efi ad-hoc > un cache de démarrage prelinkedkernel ad-hoc > un fichier SystemVersion.plist (annonçant la couleur : OS = El Capitan 10.11.6) > un fichier PlatformSupport.plist (listant les Macs supportés) > un fichier de préférences de démarrage com.apple.Boot.plist (associant à une clé Kernel Cache l'adresse du prelinkedkernel > et à une clé Kernel Flags l'adresse de l'image-disque BOOT.dmg). Cela fait > j'ai procédé à la bénédiction du volume Untitled par une commande :

sudo bless --folder /Volumes/Untitled --file /Volumes/Untitled/boot.efi

Le volume Untitled est par suite affiché à l'écran du boot_manager et choisissable comme disque de démarrage. La  s'affiche (signe que l'EFI a exécuté le boot_loader : boot.efi) > la barre de progression s'affiche sous la  (signe que le boot_loader : boot.efi a démarré le kernel du prelinkedkernel) > la jauge de progression commence à se charger (signe que le kernel a bien reçu le flag de montage du volume CAPITAN de l'image-disque BOOT.dmg > pris en compte la liste des extensions associées dans le cache adressant le répertoire-Système Extensions correspondant > et initié l'injection des kexts) > et pfuittt ! l'opération du kernel part en rideau sur un kernel_panic.

Je présume qu'avec un peu de contention d'esprit il doit être possible d'amender ce démarrage. Mais voici qui est avéré : il faut absolument qu'une distribution de boot_files existe en-dehors de l'image-disque recelant dans son volume le clone d'un macOS démarrable > de manière à ce qu'un mécanisme logique de démarrage puisse s'effectuer : EFI > boot.efi > com.apple.Boot.plist > prelinkedkernel > image-disque.dmg > volume monté du dmg > injection des extensions > INIT du Système.

Parce qu'une image-disque ne se monte jamais toute seule en volume : c'est un kernel démarré qui peut, si de telles instructions lui sont passées, monter en volume l'image-disque pour aller charger les extensions de son Système. Manifestement > «Carbon Copy Cloner», si on lui fixe comme tâche de cloner un OS dans le volume d'une image-disque, n'est pas équipé pour générer dans l'espace-parent du volume de résidence de l'image-disque les boot_files permettant le démarrage de l'OS cloné.

Bombich pourrait, sans doute, implémenter en fin de clonage une tâche de génération de ces boot_files (comme le Programme d'installation Apple de la Recovery HD sait générer les boot_files de démarrage de l'image-disque BaseSystem.dmg recelant le Recovery OS). Mais il faut bien envisager ce que cela implique : cela implique une appropriation logique intégrale du volume de résidence de l'image-disque à la finalité exclusive d'être un volume dédié au démarrage du Système de cette image-disque. Comme l'est le volume Recovery HD pour le démarrage du Recovery OS de l'image-disque BaseSystem.dmg.

Mais supposons à présent que l'image-disque d'accueil d'un clone réside dans un volume abritant déjà un OS démarrable : il faudrait alors déposséder ce volume de sa vocation de volume de démarrage de l'OS déjà en place > pour le dédier à la vocation de volume de démarrage du Système de l'image-disque clonée => jamais un développeur responsable > diffusant un utilitaire de clonage d'usage général > ne peut envisager ce type d'appropriation du volume d'accueil d'une image-disque démarrable au démarrage exclusif du Système de cette image-disque...