Archives mensuelles : novembre 2016

Installer Testdisk pour récupérer des partitions

Lorsqu’une partition est passée en raw ou lorsque la table de partitions est HS, on peut avoir besoin d’utiliser Testdisk. Son installation est en principe assez simple, et on peut utiliser des LiveCD qui l’incluent dans leurs paquets de programmes. Mais on peut aussi l’installer soi-même.

1. Depuis un LiveCD Linux (Ubuntu ou dérivée).

1.1. Méthode directe, par le terminal.

On démarre le PC directement sur le liveCD et on le connecte sur Internet ; on ouvre un terminal et on tape :

sudo apt-get update
sudo apt-get install testdisk

Il ne reste qu’à l’exécuter :

sudo testdisk

1.2. Depuis le paquet téléchargé.

Parfois, l’installation directe refuse de se finaliser et renvoie ceci :

reading package lists...done
 building dependency tree
 reading state information... done
 E: unable to locate package testdisk

On va alors utiliser la version « state » proposée sur le site officiel de Testdisk
On télécharge le fichier correspondant à sa version Linux, soit 32 ou soit 64 bits. On décompresse l’archive et on dépose le dossier Testdisk-7.0 sur le bureau du LiveCD. Il ne reste plus qu’à l’exécuter. On va le faire avec le terminal :

essai@fixe ~ $ ls -l
 drwxr-xr-x 5 4096 nov. 20 16:32 Bureau
 drwxr-xr-x 3 4096 nov. 2 15:56 Documents
 drwxr-xr-x 2 4096 sept. 1 09:43 Vidéos
 drwxr-xr-x 3 4096 oct. 19 17:06 vmware

J’ai bien un dossier Bureau (je tiens compte de la majuscule)

essai@fixe ~ $ cd Bureau/testdisk-7.0
 essai@-fixe ~/Bureau/testdisk-7.0 $

Je suis entré dans le dossier Bureau/testdisk7.0. Je n’ai plus qu’à l’exécuter.

essai@fixe ~/Bureau/testdisk-7.0 $ sudo ./testdisk_static

2. Sur une clé d’installation ou de réparation de Windows

On se rend à nouveau sur le sur le site officiel de Testdisk.
On télécharge cette fois la version Windows de Testdisk. On décompresse l’archive zip et on copie le dossier Testdisk-7.0 à la racine de la clé usb. On obtient un résultat proche de ceci :

testdisk

Le dossier Teststdisk-7.0 côtoie les dossiers de ma clé de démarrage. Il me suffit démarrer sur cette clé jusqu’à obtenir une invite de commandes qui se présentera ainsi :

x:\system32\windows>_

 

On lance l’outil diskpart.

x:\windows\system32>diskpart

Microsoft DiskPart version 10.0.10586 Copyright (C) 1999-2013 Microsoft Corporation.
Sur l’ordinateur : PC-essai
DISKPART>_

On repère la lettre associée à notre clé usb :

DISKPART> list vol

N° volume Ltr Nom Fs Type Taille Statut Info
---------- --- ----------- ----- ---------- ------- 
Volume 0 F DVD-ROM 0 o 0 média
Volume 1 C Boot NTFS Partition 1800 G Sain Démarrage
Volume 2 D Recover NTFS Partition 59 G Sain
Volume 3 E Amovible Fat32 Partition 4 G Sain Démarrage

La clé USB est identifiée par la lettre E. On a ce qu’il nous faut. On quitte diskpart

DISKPART> exit
x:\system32\windows>_

Il ne reste plus qu’à se rendre sur le volume E, entrer dans le dossier et exécuter testdisk_win :

x:\system32\windows>e:
E:\> cd testdisk-7.1
E:\testdisk-7.1>testdisk_win

Et testdisk se lance sans problème.

3. Préliminaires pour une réparation éventuelles avec Diskpart

Dans l’écran noir et blanc qui vient de s’ouvrir, on choisit les options suivantes :

- No Log
- On sélectionne le disque dur concerné.
- [Intel]

Si le disque est au format gpt, on choisit plutôt [EFI-GPT]

- Analyse (une capture d'écran)
- Enter pour "continuer".
- Quick Search (une autre capture d'écran)

On met les photos sur un site d’hébergement d’images comme Casimages  ou Hostingpics, ou autre et on donne les liens.

La suite dépendra des situations retournées par les photos.

Désintaller proprement Ubuntu ou autre Linux en dual-boot uefi

On a parfois le besoin ou le désir de désinstaller un dual-boot Windows / Linux. En mode ms-dos (ou mbr), on réparait le mbr. En UEFI, c’est un peu plus subtil car l’installation a ajouté des informations de démarrage à deux endroits :

  • Sur la partition efi.
  • Dans la Nvram.

Ca semble compliqué et pourtant, il n’est pas trop difficile de se débarrasser d’un dual-boot. En outre, on peut tout faire sans aucun logiciel tiers, depuis Windows lui-même. La démo est faite avec un W8 /Mint, mais c’est exactement pareil avec W10 et Ubuntu.

1. Suppression des partitions Linux.

suppr-part

Mon Linux tient sur une seule partition. Il me suffira, depuis le gestionnaire de disques, de supprimer la partition en question, et d’étendre mon C pour que ma version Linux disparaisse. Première opération terminée. (dans les faits, je garde ma Mint, car j’en ai encore besoin)

2. Suppression des fichiers de démarrage sur la partition efi.

La capture d’écran a montré la présence d’une partition efi de 99 Gio. Des fichiers de démarrage de Linux s’y trouvent. On va utilise l’invite de commandes pour les supprimer. On lance l’invite de commandes en admin via les touches Windows et X.

On assigne la lettre k à la partition efi et on s’y rend.

C:\windows\system32>mountvol k: /s
C:\windows\system32>k:

On liste le contenu du dossier \efi :

K:\>dir efi
Le volume dans le lecteur K n'a pas de nom.
Le numéro de série du volume est BA2F-12CE

Répertoire de K:\efi

15/10/2016  11:22    <DIR>          .
15/10/2016  11:22    <DIR>          ..
15/10/2016  11:22    <DIR>          Microsoft
15/10/2016  11:22    <DIR>          Boot
15/10/2016  09:52    <DIR>          ubuntu
0 fichier(s)                0 octets
5 Rép(s)      69 728 256 octets libres

On supprime le dossier ubuntu et son contenu :

K:\>rd /s \efi\ubuntu
\efi\ubuntu, êtes-vous sûr (O/N) ? o

On vérifie que c’est bon :

K:\>dir efi
Le volume dans le lecteur K n'a pas de nom.
Le numéro de série du volume est BA2F-12CE

Répertoire de K:\efi

15/10/2016  11:22    <DIR>          .
15/10/2016  11:22    <DIR>          ..
15/10/2016  11:22    <DIR>          Microsoft
15/10/2016  11:22    <DIR>          Boot
0 fichier(s)                0 octets
4 Rép(s)      73 250 816 octets libres

On libère la lettre K et on revient sur C :

K:\>mountvol k: /d
K:\>c:

On en a fini avec les fichiers de la partition efi.

3. Suppression de l’entrée inutile dans la nvram :

Pour ça, on va utiliser la très puissante commande bcdedit.

Dans mon cas, on voit apparaître cette liste (displayorder montre que bootmgr n’est pas prioritaire):

C:\windows\system32>bcdedit /enum firmware

Gestionnaire de démarrage du microprogramme
-------------------------------------------
identificateur          {fwbootmgr}
displayorder            {3a8bf2b3-92c1-11e6-ac2f-fc5a2e9717ca}
                        {bootmgr}
                        {3a8bf2af-92c1-11e6-ac2f-fc5a2e9717ca}
                        {3a8bf2b0-92c1-11e6-ac2f-fc5a2e9717ca}
                        {3a8bf2b1-92c1-11e6-ac2f-fc5a2e9717ca}
timeout                 2

Gestionnaire de démarrage Windows
---------------------------------
identificateur          {bootmgr}
device                  partition=\Device\HarddiskVolume2
path                    \EFI\Microsoft\Boot\bootmgfw.efi
description             Windows Boot Manager
locale                  fr-FR
inherit                 {globalsettings}
default                 {current}
resumeobject            {3a8bf2b4-92c1-11e6-ac2f-fc5a2e9717ca}
displayorder            {current}
toolsdisplayorder       {memdiag}
timeout                 30

Application logicielle (101fffff)
--------------------------------
identificateur          {3a8bf2af-92c1-11e6-ac2f-fc5a2e9717ca}
description             EFI VMware Virtual SCSI Hard Drive (0.0)

Application logicielle (101fffff)
--------------------------------
identificateur          {3a8bf2b0-92c1-11e6-ac2f-fc5a2e9717ca}
description             EFI VMware Virtual SATA CDROM Drive (1.0)

Application logicielle (101fffff)
--------------------------------
identificateur          {3a8bf2b1-92c1-11e6-ac2f-fc5a2e9717ca}
description             EFI Network

Application logicielle (101fffff)
--------------------------------
identificateur          {3a8bf2b2-92c1-11e6-ac2f-fc5a2e9717ca}
description             EFI Internal Shell (Unsupported option)

Application logicielle (101fffff)
--------------------------------
identificateur          {3a8bf2b3-92c1-11e6-ac2f-fc5a2e9717ca}
device                  partition=\Device\HarddiskVolume2
path                    \EFI\ubuntu\shimx64.efi
description             ubuntu

L’entrée correspondant au premier firmware, à savoir Ubuntu, apparaît en dernière position dans la liste qui suit. On va tout simplement la supprimer grâce à son identificateur :

C:\windows\system32>bcdedit /delete {3a8bf2b3-92c1-11e6-ac2f-fc5a2e9717ca}
L'opération a réussi.

On peut vérifier que notre entrée Ubuntu a bien disparu de la Nvram :

C:\windows\system32>bcdedit /enum firmware

Gestionnaire de démarrage du microprogramme
-------------------------------------------
identificateur          {fwbootmgr}
displayorder            {bootmgr}
                        {3a8bf2af-92c1-11e6-ac2f-fc5a2e9717ca}
                        {3a8bf2b0-92c1-11e6-ac2f-fc5a2e9717ca}
                        {3a8bf2b1-92c1-11e6-ac2f-fc5a2e9717ca}
                        {3a8bf2b2-92c1-11e6-ac2f-fc5a2e9717ca}
timeout                 2

Gestionnaire de démarrage Windows
---------------------------------
identificateur          {bootmgr}
device                  partition=\Device\HarddiskVolume2
path                    \EFI\Microsoft\Boot\bootmgfw.efi
description             Windows Boot Manager
locale                  fr-FR
inherit                 {globalsettings}
default                 {current}
resumeobject            {3a8bf2b4-92c1-11e6-ac2f-fc5a2e9717ca}
displayorder            {current}
toolsdisplayorder       {memdiag}
timeout                 30

Application logicielle (101fffff)
--------------------------------
identificateur          {3a8bf2af-92c1-11e6-ac2f-fc5a2e9717ca}
description             EFI VMware Virtual SCSI Hard Drive (0.0)

Application logicielle (101fffff)
--------------------------------
identificateur          {3a8bf2b0-92c1-11e6-ac2f-fc5a2e9717ca}
description             EFI VMware Virtual SATA CDROM Drive (1.0)

Application logicielle (101fffff)
--------------------------------
identificateur          {3a8bf2b1-92c1-11e6-ac2f-fc5a2e9717ca}
description             EFI Network

Application logicielle (101fffff)
--------------------------------
identificateur          {3a8bf2b2-92c1-11e6-ac2f-fc5a2e9717ca}
description             EFI Internal Shell (Unsupported option)

C:\windows\system32>

Bootmgr est bien passé en première position dans la liste. Après redémarrage, une vérification avec easyuefi nous montre que c’est bien le cas.

vérif

On a bel et bien supprimé notre Ubuntu intégralement. Notre PC est revenu à sa situation « initiale » sans aucun logiciel tiers.

Remarque: sur certains PC, le bios /uefi peut être verrouillé. L’étape 3 échouera dans ce cas. Pour supprimer l’entrée Ubuntu ou pour tout autre modification sur les firmware, il faudra alors passer par le bios et supprimer l’entrée directement, parfois en passant par le mot de passe superviseur pour avoir les droits pour le faire.

Récupérer les permissions NTFS sur le disque C devenu inaccessible

Il est fréquents de rencontrer, sur certains forum des sujets de personnes expliquant qu’ils ont supprimés tous les accès sur le disque dur C en voulant limiter les droits des autres utilisateurs. Le disque C n’est plus du tout accessible, ce qui rend l’utilisation du PC très problématique.

Nous allons nous placer dans cette même situation depuis un pc sous W7, sachant que depuis XP, la procédure n’a pas changé.

1. Situation de départ : un W7 installé de manière classique.

départ

Ainsi  qu’on le voit sur cette image (accès via clic droit sur C –> propriétés —> sécurité), les permissions sont distribuées de manière différente pour utilisateurs authentifiés, administrateurs, et système, qui sont en contrôle total, et utilisateurs qui n’ont que des droits limités.

Nous allons supprimer tous les droits à tout le monde, histoire de mettre le bazar complet dans notre PC. Le bouton « modifier » permet de supprimer toutes les entrées, l’un après l’autre.

suppression

Le résultat est sans appel :

droits-supprimés

Plus rien n’est accessible… La situation est dramatique.

2. Reprise des permissions NTFS par le compte en cours d’utilisation

2. 1. Mode graphique

Pour la démonstration, nous allons utiliser un compte « essai«  qui appartient au groupe Administrateurs. On aurait pu conserver le même propriétaire, mais l’idée est de montrer qu’on peut tout faire.

Il faut bien comprendre que ce qui suit n’est pas un tutoriel, mais une démonstration de ce qu’il est possible de faire.

partition HS

Dans la plupart des cas, il suffira de passer par la touche « continuer » pour pouvoir récupérer les permissions NTFS (comme indiqué sur les flèches). Le propriétaire de C étant en principe le groupe « administrateurs », il devrait conduire à la fenêtre suivante permettant de rétablir les droits en ajoutant les groupes ou utilisateurs supprimés :
réparer
Il suffirait ici d’ajouter les groupes « utilisateurs authentifiés », « système », et le compte perso de l’utilisateur en contrôle total pour retrouver l’intégralité de son système.

Moi, je vais passer par l’option « avancé, en bas de page pour modifier complètement le propriétaire du disque C.

Nous allons sélectionner la touche « continuer », puis l’onglet propriétaire. L’option « modifier » va permettre de sélectionner le compte qui sera le nouveau propriétaire de C. Il s’agit du compte « essai » et nous propageons la modification à tous les sous-conteneurs:

changetpropriétaire

Windows va faire défiler tous les dossiers inclus dans le disque C et leur affecter cette modification radicale, qui n’est pas essentielle, je le rappelle. Quelques messages d’erreurs sur des fichiers temporaires ou swap peuvent survenir; on s’en moque  pour l’instant. Au bout de quelques minutes, le résultat s’affiche :

changetpropriétaire-résult2

L’utilisateur « essai » est devenu propriétaire de C, lequel est de nouveau lisible et accessible avec un contrôle total. Il ne reste donc qu’à rétablir les droits des autres « entités » ou « groupes ». Par exemple « système » qui est bien sûr indispensable pour que le système puisse se modifier de lui-même, lors des installations de programme, par exemple :

ajout-systeme

On choisit « Modifier« , puis « ajouter« , et on saisit « système » en vérifiant que le compte en question existe bien. On lui attribue tous les droits en contrôle total.

On répète la même opération avec les autres groupes tels que « administrateurs« , « utilisateurs authentifiés« , et avec « utilisateurs » pour qui on limite les droits à « lecture« , « lecture et exécution« , et affichage« . Le résultat est le suivant (on voit bien que j’ai fait des choix différents de l’origine, pour la démonstration) :

final

Notre Windows 7 est de nouveau opérationnel,

2.2. Et pourquoi pas l’invite de commandes ?

Windows propose deux commandes très puissantes (et bien docummmentées) pour s’approprier des dossiers ou fichiers en invite de commande. La première permet de devenir propriétaire d’un dossier, la seconde permet d’attribuer des droits complets :

takeown /f c:\dossier\sous-dossier
icacls c:\dossier\sous-dossier /grant Nom_Utilisateur:f

Ici, le compte administrateur en cours devient propriétaire de « sous-dossier » et il peut intervenir dessus avec un « contrôle total« .

Le principal problème est d’accéder à l’invite de commandes en mode admin. Le disque C étant inaccessible, on aboutit à ceci :

cmd-admin

Pour contourner le problème, on peut tenter de passer par CTRL ALT SUPPR, puis de lancer une nouvelle tâche, à savoir cmd. On obtient ceci :

cmd-admin3

Contrairement aux apparences, on n’est pas en mode administrateur dans cette invite de commande. Les commandes takeown et icacls seront donc refusées, avec un message « accès refusé ». Deux moyens pour y parvenir sont les suivants :

  •  Redémarrage de Windows en mode sans échec.
  • Démarrage sur la console de réparation via un support externe.

Le mode sans échec étant désactivé par défaut sur W8 et W10, on perd l’intérêt d’un dépannage depuis Windows lui-même. Par conséquent, ce piste ne sera pas retenue (sauf découverte ultérieure de solution pour lancer cmd en admin).

Donc, à suivre…

Remplacer un grub-signé par un grub-usb pour les PC au bios bloqué sur bootx64.efi

Dans le cas des installations en dual boot entre Windows (8 ou 10) et Linux, certaines marques imposent systématiquement le démarrage en UEFI sur « Windows Boot Manager », empêchant le lancement de Grub, et forçant par conséquent le démarrage sur Windows. Cela impose souvent de modifier la base bcd de Windows pour contourner le problème via les commandes suivantes, selon que le boot-secure est activé ou non:

bcdedit /set {bootmgr} path \efi\ubuntu\shimx64.efi
bcdedit /set {bootmgr} path \efi\ubuntu\grubx64.efi

Cette commande modifie la base bcd de et redirige le  démarrage de Windows vers  les lanceurs de Grub, shimx64.efi ou bootx64.efi, ce qui est la solution la plus facile. Mais ce n’est pas forcément l’idéal, notamment à cause des mises à jour de Windows 10 très fréquentes qui obligent à répéter l’opération régulièrement. Et il ne faut pas faire d’erreur, car sinon, on a un bel écran bleu.

On peut peut-être procéder autrement, c’est-à-dire en remplaçant le Grub signé par la version « removable » de Grub utilisée sur les clés USB d’installation, qui elle, démarre sur toutes les marques sans exception.

1. Situation de départ : un Linux installé qui ne démarre pas.

Pour info, je crée une fausse situation de panne, ce qui n’est pas réellement le cas. La première chose à faire est d’accéder à ce Linux  installé. On a deux moyens d’y parvenir.

- Soit en redémarrant via le mode avancé de W8/W10 qui va proposer Ubuntu dans les périphériques :

- aller dans paramètres ( le petit engrenage rouge )
- mise à jour et sécurité
- récupération
- démarrage avancé
- cliquer sur " redémarrer maintenant "
- choisir " utiliser un périphérique "

- Soit via le live-CD Supergrub2disk. Dans mon cas, je choisis Supergrub2disk, mon Linux étant le seul système installé. Je démarre sur Supergrub2disk, et dans le choix Everything, je choisis Mon Linux qui est détecté :

SG2D

1.1 On fait d’abord un point sur les partitions :

essai@essai-virtual-machine ~ $ sudo parted -l
 Modèle: VMware, VMware Virtual S (scsi)
 Disque /dev/sda : 10,7GB
 Taille des secteurs (logiques/physiques): 512B/512B
 Table de partitions : gpt

Numéro Début Fin Taille Système de fichiers Nom Fanions
 6 1049kB 107MB 106MB fat32 démarrage
 1 107MB 7107MB 7000MB ext4 msftdata
 2 7107MB 9107MB 2000MB ext4 msftdata
 3 9107MB 9607MB 500MB ntfs msftdata
 4 9607MB 10,1GB 500MB ntfs msftdata
 5 10,1GB 10,7GB 629MB ext4 msftdata

On a bien une partition efi en fat32 (sda6), et un Linux installé sur deux partitions ext4 (sda1 et sda2). Le reste (partitions 3, 4 et 5) étant des partitions d’essais sans intérêt, traces d’un ancien tuto.

1.2. Vérification de Grub

On vérifie que nos fichiers grub sont bien présents dans le point de montage /boot/efi (si la partition efi n’est pas montée, il faudra la monter manuellement via la commande mount):

essai@essai-virtual-machine ~ $ ls -R /boot/efi/efi/
/boot/efi/efi/: ubuntu
/boot/efi/efi/ubuntu: grub.cfg grubx64.efi MokManager.efi shimx64.efi

Pas de problème, les fichiers grubx64.efi et shimx64.efi sont bien là, tout comme le fichier grub.cfg qui ne fait rien d’autre que le lien vers celui de la partition Linux.

1.3. Contrôle de l’ordre de démarrage inscrit dans la Nvram du bios :

essai@essai-virtual-machine ~ $ sudo efibootmgr -v
 BootOrder: 0000,0001,0002,0003
 Boot0000* EFI VMware Virtual SCSI Hard Drive (0.0) ACPI(a0341d0,0)PCI(10,0)SCSI(0,0)
 Boot0001* EFI VMware Virtual SATA CDROM Drive (1.0) ACPI(a0341d0,0)PCI(11,0)PCI(5,0)03120a00010000000000
 Boot0002* EFI Network ACPI(a0341d0,0)PCI(11,0)PCI(1,0)MAC(000c2900b41b,0)
 Boot0003* EFI Internal Shell (Unsupported option) MM(b,3efcb000,3f355fff)
 Boot0004* <unknown> HD(6,800,32800,0b55b2b7-f872-4f3f-843e-9060be2416ee)File(\EFI\ubuntu\shimx64.efi)

On peut voir une erreur dans la ligne Boot0004, ce qui explique que Linux ne démarre pas tout seul. C’est l’entrée Boot0000 qui est prise par défaut.

Inutile de tenter de réparer si le bios /uefi du PC est la cause du blocage et qu’aucune option de permet d’ajouter cette entrée dans ce bios. On reviendra toujours automatiquement à cette situation.

2. Suppression de Grub signé

On va désinstaller les deux paquets qui permettent de lancer Linux avec les commandes suivantes

2.1 Suppression de grubx64.efi

essai@essai-virtual-machine ~ $ sudo apt-get autoremove grub-efi-amd64-signed
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Les paquets suivants seront ENLEVÉS :
grub-efi-amd64-signed
0 mis à jour, 0 nouvellement installés, 1 à enlever et 848 non mis à jour.
Après cette opération, 2 997 ko d'espace disque seront libérés.
Souhaitez-vous continuer ? [O/n] o
(Lecture de la base de données... 152448 fichiers et répertoires déjà installés.)
Suppression de grub-efi-amd64-signed (1.34.14+2.02~beta2-9ubuntu1.12) ...

2.2. Suppression de shimx64.efi

essai@essai-virtual-machine ~ $ sudo apt-get autoremove shim-signed
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Les paquets suivants seront ENLEVÉS :
libefivar0 mokutil shim shim-signed
0 mis à jour, 0 nouvellement installés, 4 à enlever et 848 non mis à jour.
Après cette opération, 4 270 ko d'espace disque seront libérés.
Souhaitez-vous continuer ? [O/n] o
(Lecture de la base de données... 152440 fichiers et répertoires déjà installés.)
Suppression de shim-signed (1.19~14.04.1+0.8-0ubuntu2) ...
Suppression de mokutil (0.3.0-0ubuntu3~14.04.1) ...
Suppression de libefivar0:amd64 (0.21-1~14.04.2) ...
Suppression de shim (0.8-0ubuntu2) ...
Traitement déclenché pour man-db (2.6.7.1-1) ...
Traitement déclenché pour libc-bin (2.19-0ubuntu6) ...

2.3 Suppression de l’entrée inutile dans la Nvram du bios

essai@essai-virtual-machine ~ $ sudo efibootmgr -b 0004 -B
 BootOrder: 0000,0001,0002,0003
 Boot0000* EFI VMware Virtual SCSI Hard Drive (0.0)
 Boot0001* EFI VMware Virtual SATA CDROM Drive (1.0)
 Boot0002* EFI Network
 Boot0003* EFI Internal Shell (Unsupported option)

2.4 Suppression de traces des fichiers dans la partition efi

essai@essai-virtual-machine ~ $ sudo rm -rf /boot/efi/efi/ubuntu

On vérifie le résultat : la partition efi est entièrement vide.

essai@essai-virtual-machine ~ $ ls -R /boot/efi/efi/
 /boot/efi/efi/:

3. Réparation du démarrage en vue d’un boot simulant l’USB

3.1. Installation de la version removable de Grub

essai@essai-virtual-machine ~ $ sudo grub-install --removable
 Installing for x86_64-efi platform.
 Installation terminée, sans erreur.

3.2. On vérifie qu’une nouvelle version de Grub s’est bien ajoutée à la notre partition efi

essai@essai-virtual-machine ~ $ ls -R /boot/efi/efi/
 /boot/efi/efi/: BOOT
 /boot/efi/efi/BOOT:BOOTX64.EFI

On constate que le dossier est nommé cette fois boot et le fichier bootx64.efi.

On met à jour notre grub, par acquis de conscience.

essai@essai-virtual-machine ~ $ sudo update-grub
 Création du fichier de configuration GRUB…
 Found linux image: /boot/vmlinuz-3.13.0-24-generic
 Found initrd image: /boot/initrd.img-3.13.0-24-generic
 No volume groups found
 fait

On peut en principe s’arrêter ici. Les Bios bloqués pour booter sur /efi/boot/bootx64 seront dorénavant capables de démarrer et ils lanceront notre Linux ou notre dual-boot.

Il nous reste à vérifier le démarrage de notre Linux.

 Le résultat de efibootmgr au redémarrage est le suivant :

essai@essai-virtual-machine ~ $ sudo efibootmgr -v
[sudo] password for essai: 
BootCurrent: 0000
BootOrder: 0000,0001,0002,0003
Boot0000* EFI VMware Virtual SCSI Hard Drive (0.0)	ACPI(a0341d0,0)PCI(10,0)SCSI(0,0)
Boot0001* EFI VMware Virtual SATA CDROM Drive (1.0)	ACPI(a0341d0,0)PCI(11,0)PCI(5,0)03120a00010000000000
Boot0002* EFI Network	ACPI(a0341d0,0)PCI(11,0)PCI(1,0)MAC(000c2900b41b,0)
Boot0003* EFI Internal Shell (Unsupported option)	MM(b,3efcb000,3f355fff)
essai@essai-virtual-machine ~ $ 

 

5. Remarque importante.

Rien ne garantit que cette manipulation pourra résoudre le problème du blocage de Bios sur toutes les marques et dans tous les cas. Il faudrait que de « joyeux cobayes » se risquent à tester le résultat de tout cela sur de vrais PC bloqués (comme les HP ou les Toshiba).

Quoi qu’il en soit, il est aisé de réinstaller les versions signées de grub via les commandes pour revenir à la version initiale (toujours depuis SG2D ou le démarrage avancé de W10):

sudo apt-get install -y grub-efi-amd64-signed shim-signed 
sudo update-grub

Les deux commandes recréeront automatiquement et sans intervention :

- Les entrées dans le bios/uefi et les placeront en tête.
- Le dossier /efi/ubuntu avec les fichiers grub nécessaires.
- La mise à jour de grub.cfg tant dans la partition Linux que dans la partition efi.

On pourra, si on le souhaite, supprimer comme suit les traces de notre grub removable, mais ce n’est pas indispensable :

essai@essai-virtual-machine ~ $ sudo rm -rf /boot/efi/EFI/BOOT

Voir discussion au sujet de cette démo ici.

*******************************************

5. Annexe : proposée simplement à titre informatif.

 5.1. Possibilité complémentaire :  ajout d’une entrée dans le bios

Pour information, j’explique comment on pourrait ajouter une entrée supplémentaire dans la liste de démarrage, si éventuellement on en avait un besoin particulier.

essai@essai-virtual-machine ~ $ sudo efibootmgr --create --part 6 --label "Linux removable" --loader '\efi\boot\bootx64.efi'
 BootOrder: 0004,0000,0001,0002,0003
 Boot0000* EFI VMware Virtual SCSI Hard Drive (0.0)
 Boot0001* EFI VMware Virtual SATA CDROM Drive (1.0)
 Boot0002* EFI Network
 Boot0003* EFI Internal Shell (Unsupported option)
 Boot0004* Linux removable

A noter qu’en principe, cette opération est faisable depuis le bios lui-même.

Ma partition efi étant la partition 6, je respecte ce nombre. Je fais pointer la nouvelle entrée vers le nouveau fichier grub dans \efi\boot\bootx64.efi. Notre entrée s’est ajoutée en tête de liste dans l’ordre de boot. On met à jour notre grub, par acquis de conscience.

essai@essai-virtual-machine ~ $ sudo update-grub
 Création du fichier de configuration GRUB…
 Found linux image: /boot/vmlinuz-3.13.0-24-generic
 Found initrd image: /boot/initrd.img-3.13.0-24-generic
 No volume groups found
 fait

Il nous reste à vérifier le démarrage de notre Linux.

5.2. Résultat des modifications

Notre Linux démarre sans encombre, et il ne reste plus qu’à vérifier que l’ordre de démarrage confirme ce succès.

essai@essai-virtual-machine ~ $ sudo efibootmgr -v
 BootCurrent: 0004
 BootOrder: 0004,0000,0001,0002,0003
 Boot0000* EFI VMware Virtual SCSI Hard Drive (0.0) ACPI(a0341d0,0)PCI(10,0)SCSI(0,0)
 Boot0001* EFI VMware Virtual SATA CDROM Drive (1.0) ACPI(a0341d0,0)PCI(11,0)PCI(5,0)03120a00010000000000
 Boot0002* EFI Network ACPI(a0341d0,0)PCI(11,0)PCI(1,0)MAC(000c2900b41b,0)
 Boot0003* EFI Internal Shell (Unsupported option) MM(b,3efcb000,3f355fff)
 Boot0004* Linux removable HD(6,800,32800,0b55b2b7-f872-4f3f-843e-9060be2416ee)File(\efi\boot\bootx64.efi)

Notre Linux vient bien de démarrer sur notre entrée nouvellement créée… Il utilise le fichier bootx64.efi .

Déplacer Winre.wim depuis Linux pour libérer une partition en cas de nombre insuffisant

Windows 10 crée une partition de 450 Mib qui contient le démarrage avance, ce qui peut parfois devenir gênant si on veut agrandir ou rétrécir la partition qui précède, ou si on atteint la limite des 4 partitions principale sur une disque ms-dos (mbr).

1. Depuis Linux : déplacer  les fichiers nécessaires de la partition de 450 Mib vers la partition Windows.

1.1. J’identifie ma partition de récupération et ma partition Windows : [b]sda5 [/b]et [b]sda4[/b].

test@test-virtual-machine ~ $ sudo parted -l
Modèle: VMware, VMware Virtual S (scsi)
Disque /dev/sda : 42,9GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : gpt
Numéro Début Fin Taille Système de fichiers Nom Fanions
1 1049kB 316MB 315MB ntfs Basic data partition caché, diagnostic
2 316MB 419MB 104MB fat32 EFI system partition démarrage
3 419MB 554MB 134MB Microsoft reserved partition msftres
4 554MB 19,2GB 18,6GB ntfs Basic data partition msftdata
7 19,2GB 19,2GB 30,4MB ext4 bios_grub
8 19,2GB 27,8GB 8613MB ext4
5 27,8GB 28,3GB 472MB ntfs caché, diagnostic
6 28,3GB 42,9GB 14,7GB ntfs Basic data partition msftdata

1.2. Je crée un dossier sda5 et j’y monte la partition de récupération pour vérifier qu’elle contient mes fichiers de démarrage avancé :

test@test-virtual-machine ~ $ sudo mkdir /mnt/sda5
test@test-virtual-machine ~ $ sudo mount /dev/sda5 /mnt/sda5

1.3. Je vérifie la présence des fichiers boot.sdi et winre.wim

test@test-virtual-machine ~ $ ls -ls /mnt/sda5/Recovery/WindowsRE
total 307428
3096 -rwxrwxrwx 1 root root 3170304 juil. 10 2015 boot.sdi
4 -rwxrwxrwx 1 root root 1054 août 26 2015 ReAgent.xml
304328 -rwxrwxrwx 1 root root 311629340 août 25 2015 Winre.wim

1.4. Je crée un dossier sda4 et j’y monte ma partition Windows. Je crée un dossier recuprecovery pour y copier mes fichiers.

test@test-virtual-machine ~ $ sudo mkdir /mnt/sda4
test@test-virtual-machine ~ $ sudo mount /dev/sda4 /mnt/sda4
test@test-virtual-machine ~ $ sudo mkdir /mnt/sda4/recuprecovery

1.5. Je copie les trois fichiers dans le dossier recuprecovery :

test@test-virtual-machine ~ $ sudo cp -v /mnt/sda5/Recovery/WindowsRE/* /mnt/sda4/recuprecovery
«/mnt/sda5/Recovery/WindowsRE/boot.sdi» -> «/mnt/sda4/recuprecovery/boot.sdi»
«/mnt/sda5/Recovery/WindowsRE/ReAgent.xml» -> «/mnt/sda4/recuprecovery/ReAgent.xml»
«/mnt/sda5/Recovery/WindowsRE/Winre.wim» -> «/mnt/sda4/recuprecovery/Winre.wim»

1.6. Je vérifie que tout s’est bien passé :

test@test-virtual-machine ~ $ ls /mnt/sda4/recuprecovery
boot.sdi ReAgent.xml Winre.wim
test@test-virtual-machine ~ $

Mes fichiers de démarrage ont bien été copiés à la racine de Windows, dans le dossier recuprecovery.

1.7 Je peux démonter et supprimer mes dossiers temporaires :

test@test-virtual-machine ~ $ sudo umount /mnt/sda4
test@test-virtual-machine ~ $ sudo umount /mnt/sda5
test@test-virtual-machine ~ $ sudo rm -r /mnt/sda4
test@test-virtual-machine ~ $ sudo rm -r /mnt/sda5

2. Déplacement des fichiers de démarrage sous Windows avec la commande reagentc

2.1. Je fais un état de la situation du démarrage avancé de Windows (en invite de commandes, mode admin).

C:\windows\system32>reagentc /info
Informations sur la configuration de l’Environnement de récupération
Windows (WinRE) et la réinitialisation du système :
État WinRE : Disabled
Emplacement WinRE :
Identificateur des données de configuration du démarrage (BCD) : 4a373e16-4b06-11e5-9107-f1e433c74f8e
Emplacement de l’'image de récupération :
Index de l’image de récupération : 0
Emplacement de l’'image personnalisée :
Index de l’image personnalisée : 0
REAGENTC.EXE : opération réussie.

Ici, il n’est pas activé puisqu’il est sur disabled. Sinon, je le désactive par

reagentc /disable

2.2. Déplacement des fichiers de démarrage vers le nouveau dossier créé :

C:\windows\system32>reagentc /setreimage /path c:\recuprecovery\winre.wim
Répertoire défini : \\?\GLOBALROOT\device\harddisk0\partition4\recuprecovery
REAGENTC.EXE : opération réussie.

2.3. Réactivation du démarrage avancé :

C:\windows\system32>reagentc /enable
REAGENTC.EXE : opération réussie.

2.4 Vérification du bon fonctionnement du démarrage avancé:

C:\windows\system32>reagentc /info
Informations sur la configuration de l’'Environnement de récupération
Windows (WinRE) et la réinitialisation du système :

État WinRE : Enabled
Emplacement WinRE : \\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE
Identificateur des données de configuration du démarrage (BCD) : 4a373e16-4b06-11e5-9107-f1e433c74f8e
Emplacement de l’'image de récupération :
Index de l’image de récupération : 0
Emplacement de l’'image personnalisée :
Index de l’image personnalisée : 0
REAGENTC.EXE : opération réussie.

Mon démarrage avancé pointe bien vers le nouveau dossier… Je peux supprimer ma partition sda5 sans aucun risque.