Depuis la version 8 de Windows, M$ permet des installations dites « mobiles » de ces Windows, installables sur support USB, afin de permettre à un dépanneur PC  de transporter à la fois son système et des programmes en un seul support. Voir ici pour des explications.

I. Avantages et Inconvénients de WinToGo

Avantages de WintoGo

• On lance un vrai Windows, complet et fonctionnel depuis l’USB. Les programmes insérés fonctionnent comme sur sa propre machine.
• La version de W10 s’active automatiquement sur le PC à dépanner, dès lors que la version utilisée est identique à celle installée (Home /Pro).
• Un dépanneur « amateur » peut réussir à dépanner un PC HS, sans connaître à fond les techniques de dépannage.

Inconvénients de WintoGo :

• C’est lourd, et il faut un support d’une vingtaine de Gib pour espérer avoir un outil fonctionnel.
• Le débit USB 3 n’est pas suffisant pour une utilisation souple. En USB 2, c’est quasi rédhibitoire.

Pour ceux qui sont malgré tout intéressés par cette possibilité, je les invite à consulter ce sujet où un outil graphique a été expérimenté. Sachons que Rufus permet aussi ce genre d’installation.

II. Objectifs de cette démo

L’idée est ici d’adapter les techniques de création utilisées par ces logiciels (qui se limite à l’USB) à l’installation sur disque dur. L’exercice est plus « intellectuel » que pratique, mais il a tout de même quelques intérêts :

• Permettre à un même W10 sur disque mbr de booter tant en UEFI qu’in Legacy.
• Permettre de faire redémarrer un W10 converti par erreur de GPT à mbr sans perdre l’UEFI.
• Permettre de redonner vie à un disque dur mbr contenant un W10, voire un W8, alors que le PC sur lequel il était installé est mort depuis des lustres.
• Permettre d’utiliser un W10 installé sur mbr, même si le bios est de classe 3.
• De montrer qu’on peut tout faire en invite de commandes, ce qui est selon moi toujours préférable aux outils « clé en main », dont on ignore ce qu’ils font.

III. Le but à atteindre.

Dans le sujet pc-astuces, on peut voir le résultat de la création logicielle d’un WinToGo de Windows 10.

Deux partitions sont créées. L’une, en format FAT32 est active, et donc bootable. L’autre, en NTFS, contient WinToGo.  Nous allons simplement reproduire cette situation sur le disque vierge d’un PC virtuel sous VMware, en inversant l’ordre des partitions (c’est un choix personnel, rien de plus).

 II) Installation de Windows nomade sur disque dur.

Attention : pour ceux qui veulent un WinToGo USB, mieux vaut suivre le sujet PC-Astuces. Mais j’expliquerai au fur et à mesure les variations entre méthode manuelle et logicielle.

1. Démarrage du PC.

Le plus simple est de faire booter le PC sur son W10 installé, car certaines commandes peuvent être remplacées par des actions graphiques.

Si comme moi, on part de zéro, on doit démarrer sur un support USB / DVD d’installation. Dans ce cas, mieux vaut exécuter l’installation en mode Legacy, pour des raisons que j’expliquerai un peu plus loin.

On démarre classiquement sur le disque d’installation :

Là, je choisis de réparer mon ordinateur :

Je vais suivre choisir les « options avancées » pour aboutir à l’invite de commande.

2. État des lieux et préparation du disque.

Comme je démarre en mode avancé, je vais devoir passer par l’invite de commandes. Si on fait la manipulation depuis Windows, on peut faire tout ce point depuis le gestionnaire de disques, bien évidemment. Donc, je me limiterai à des images que je commenterai.

Depuis diskpart, j’ai identifié mon disque à traiter (ici, c’est le disque 0 puisqu’il est unique). J’efface tout et je le convertis au format mbr (pour la forme, car il était déjà dans ce format).

• Maintenant, je crée mes partitions (toujours faisable en mode graphique depuis W10). Je crée une partition active fat32 de 300 Mo que j’appelle « system » avec la lettre S, et une partition NTFS sur le reste du disque et que j’appelle « OS » avec la lettre C.

REM . Le choix des lettres S et C n’est pas obligatoire, et il dépend de la situation qu’on rencontre. On choisit nécessairement des lettres inutilisées au moment de la création des partitions. Sous Windows 10, la lettre C étant occupée par le système, on peut prendre une lettre telle que W, Y ou Z, généralement libres.

•  Une petite vérification du résultat : les principales informations sont là. Il ne reste plus qu’à identifier l’image de Windows à installer et à envoyer les commandes.

3. Identification de l’image et déploiement via dism.

• La première chose, c’est de trouver le fichier install.wim ou install.esd qui doit se trouver sur mon DVD appelé D. La commande dir d:\sources\inst* devrait me renseigner (toujours faisable graphiquement sous W10).
• Mon fichier étant nommé « install.esd« , je vais inspecter son contenu pour savoir quelle version choisir grâce à la commande dism /get-wiminfo . Cette fois, l’invite de commande est nécessaire.

Le résultat est que j’ai deux index. Celui qui m’intéresse est le premier, car il contient la version PRO, précisément celle que je veux installer. On notera que j’utilise une vieille version de W10 pour cette démo.

• Il ne reste qu’à déployer l’image vers le support que j’ai choisi. Je rappelle que j’ai trouvé install.esd sur D et que je veux déployer vers C, ma partition NTFS.

La commande dism /apply-image va chercher la source sur D, et déploie l’index 1 sur la cible C. C’est parti pour 10 minutes de décompte, de 0 à 100 %. Au terme de ce décompte, je vérifie le résultat par un dir c (faisable graphiquement depuis W10). Mon W10 est déployé.

 4. Création des fichiers de démarrage.

Pour ce faire, on va utiliser la commande très connue bcdboot. Mais, pour le coup, il me semble que quelques précisions méritent d’être apportées avant de l’exécuter. Peu de gens savent qu’elle se comporte différemment depuis un Windows installé et depuis la console de réparation Winre (mon cas).

• Sur un Windows 10 installé, elle se contente de créer les fichiers de démarrage sur la partition système ou sur la cible qu’on lui aura indiquée.
• Sur la console Winre, elle fait la même chose, mais elle ajoute également une entrée {bootmgr} en tête de liste dans la NVRam (en UEFI), et enfin, elle scanne les partitions pour créer un éventuel dual boot. Autant dire que pour créer un support externe bootable, ce n’est pas ce qu’on veut. On risque de se retrouver avec une entrée inutile et une NVram déteriorée.

Bref, pour faire simple, si on crée un support externe, mieux vaut agir depuis Windows (et de préférence en Legacy), mais si on veut un support interne à demeure, on aura plus intérêt à lancer la commande depuis la console Winre, et en UEFI.  Ce qui est mon cas.

• Exécution de bcdboot. On notera trois options importantes. L’option /l fr-fr qui indique qu’on veut la version française, l’option /s s: qui précise à la commande la cible de l’écriture des fichiers, et enfin, l’option /f ALL qui force bcdboot à créer une base BCD pour le Bios, et une autre pour l’UEFI (tous ceux qui proposent  sur les forums cette option all par défaut sur disque gpt en uefi n’ont visiblement pas compris son usage).

C’est équivalent à ce qui est proposé ici lors de la création via un logiciel dédié:

5. Ultimes vérifications

• On peut vérifier que l’écriture s’est bien faite sur la partition S en fat32 par un dir /a (Cf. précédente image).

• On peut vérifier que notre boot fonctionnera en uefi.

• Idem en mode bios

6. Tests de démarrage.

• En UEFI

• En Bios- Legacy (Mon W10 n’a visiblement pas apprécié que j’arrête l’installation en cours de route… Mais je n’avais pas l’intention de la finaliser).

 III. Conclusion

Un PC UEFI avec W10  n’a pas besoin de partition efi . Une partition fat32 « basique » lui suffit pour booter. Il suffit que bootmgr pointe vers les fichiers adéquats. Un disque mbr doté d’une partition fat32 active suffit à permettre de mettre en place un démarrage.

Un PC Legacy W10 peut booter sur un disque mbr doté d’une partition fat32 active et contenant les fichiers de démarrage. C’est une grande différence avec W7 qui demandait obligatoirement une partition NTFS active.

Voir ce tuto de Le Fêlé qui propose la même chose en mode graphique.

 

Le format de disque virtuel LVM (Logical Virtual Manager) est proposé par défaut à l’installation d’Ubuntu et de ses dérivées. On le néglige souvent pour lui préférer le partitionnement traditionnel. Néanmoins, il offre des avantages non négligeables, tant en termes d’extensibilité et de manipulation des volumes.

I. Quelques rappels théoriques.

Le format LVM repose sur des « volumes logiques« , répartition souple et dynamique qui offre à l’utilisateur la possibilité de ne pas se préoccuper des limitations de taille de telle ou telle partition, car il peut l’augmenter quasi à l’infini en ajoutant des disques secondaires. Un exemple par l’image :

 

On distingue trois « niveaux » :

1. Les ou les volumes physiques. Ce sont les partitions physiques, voire les disques durs, représentés ici en bleu. On les repère par convention par le préfixe pv.
2. Le (ou les) groupe(s) de volumes : ce sont des sortes de « paquets » dans lesquels seront inscrits les volumes logiques. Ici, un seul groupe est représenté en vert. On le repère par le préfixe vg.
3. Les volumes logiques. Ce sont nos espaces utilisables, pour y placer nos fichiers (le root, notre home, ou nos autres fichiers, selon notre souhait. Le préfixe est lv.

Plus de détails ici :

• https://doc.ubuntu-fr.org/lvm
• https://linux.developpez.com/lvm/

 II. Le problème de l’installation avec LVM

Pour être plus concret, on va tenter une installation d’une Xubuntu 16.04 en utilisant l’option LVM.

1) Démarrage sur le live-cd

On choisit un démarrage en mode UEFI (mais le mode Legacy conviendrait également). On rencontre le traditionnel menu Grub en noir et blanc, qui garantit que le boot se fait en UEFI.

On va choisir « Try Ubuntu without installing« , ce qui permet de vérifier que le PC supporte bien cette version de Linux. Une fois le bureau obtenu, on passe notre Live-cd en français, soit en mode graphique, comme sur l’image suivante, soit à partir d’un terminal.

ou bien la commande setxkbmap fr, tapée en qwerty comme ceci :

setxkb,qp fr

2. Lancement de l’installation

Une fois tout vérifié, on lance l’installation, en suivant les consignes jusqu’à la fenêtre de partitionnement. On nous propose ceci :

Et là, on rencontre un problème. L’option LVM n’est accessible que si on efface intégralement le disque. Si on veut un Linux seul sur notre machine, on pourra choisir cette option, mais en cas de dual-boot avec Windows, c’est bien entendu à proscrire. On perdrait notre Windows.

A noter que l’option « autre chose » nous propose un partitionnement traditionnel, et donc, plus de LVM. Je n’ai pas mis d’image car on retrouve le partitionnement habituel d’Ubuntu. Il va donc falloir opérer autrement pour ne pas tout formater.

II. Préparer le partitionnement LVM

1. Partitionnement avec gparted.

Toujours depuis le live-cd, on va commencer à préparer notre disque dur (je n’en utilise qu’un seul pour la démo) avec gparted afin de faire comprendre à l’installateur qu’on ne veut pas formater le disque. La situation de départ est la suivante:

Le disque contient deux partitions préexistantes (encadrées en vert) qui « simulent » un Windows préinstallé.

• /dev/sda1 : c’est la partition efi (en fat32), indispensable au boot de Windows.
• /dev/sda2 : c’est la partition Windows (ici appelée Winre), en NTFS et qui contient le système.
• Un espace de 9,40 Gb est libre, et c’est ici qu’on installe notre partition LVM.

On choisit d’ajouter une partition primaire, mais on choisit un formatage en LMV2 pv  (encadrement en marron) pour faire comprendre à l’installateur que le « physical volume » va héberger des volumes logiques. On valide tout ça en appliquant les modifications.

2) Création du groupe de volumes et des volumes physiques

Il va falloir utiliser un terminal. Les outils de commandes LVM2 étant préinstallés sur Ubuntu, on n’aura pas besoin d’installer quoi que ce soit.

• On crée notre « volume physique » à partir de la partition /dev/sda3 qui vient d’être créée.

sudo pvcreate /dev/sda3
Physical volume "/dev/sda3" successfully created

• On crée un groupe de volumes appelé xubuntu-vg sur /dev/sda3

sudo vgcreate xubuntu-vg /dev/sda3
Volume group "xubuntu-vg" successfully created

• Enfin, nous créons nos volumes logiques. Pour la démo, on se limite à deux : un swap et un root.

sudo lvcreate  -n swap -L 500m xubuntu-vg
Logical volume "swap" created

sudo lvcreate  -n root -l 100%FREE xubuntu-vg
Logical volume "root" created

J’ai attribué 500 Mb au Swap, et le reste au root. Quelques précisions sur les options : -n signifie « name », -L signifie « size », et -l signifie « extents » en pourcentage. On peut connaître les commandes LVM très facilement pour chaque niveau (PV, VG ou LV) en cherchant sur Internet ou en tapant :

man -k ^pv
man -k ^vg
man -k ^lv

Ce qui donne en visuel :

3. Installation de Xubuntu.

On relance l’installation, comme on l’avait fait initialement, mais cette fois, on va choisir l’option « autre chose« . Nos volumes virtuels sont cette fois proposés dans les options de partitionnement :

Via la  touche « modifier », j’ai attribué

• le point de montage / à /dev/mapper/xubuntu-vg-root formatée en ext4.
• le statut swap à /dev/mapper/xubuntu-vg-swap non formatée.
• le statut de partition efi à /dev/sda1

Il ne reste plus qu’à passer à « installer maintenant » pour que l’installation se fasse. Le dual-boot Windows /Xubuntu en LVM sera opérationnel. Il ne restera plus qu’à gérer les volumes logiques, ce qui sera l’objet d’une autre démo.