Archives pour la catégorie Non classé

Convertir Xubuntu UEFI vers Legacy sans redémarrage

La conversion d’une version installée d’une Xubuntu UEFI sur disque GPT vers une installation Legacy sur disque DOS peut, contre toute attente, être réalisée depuis une version installée sans aucun redémarrage. Tout se fait depuis une série de commandes via un Terminal.

Attention, cette démonstration est réalisée sur un PC virtuel. Les manipulations n’étant pas sans risque, avec un vrai PC, toutes les sauvegardes nécessaires doivent être réalisées au préalable. Et rien ne garantit la réussite du processus.

1. État initial : installation uefi

Un rapport boot-info est le meilleur moyen de voir la situation de départ : rapport boot-info initial.

Le résultat témoigne d’une installation UEFI classique sur un disque au  format GPT (GUID) :

 => No boot loader is installed in the MBR of /dev/sda.

sda1: __________________________________________________________________________

    File system:       vfat
    Boot sector type:  FAT32
    Boot sector info:  No errors found in the Boot Parameter Block.
    Operating System:  
    Boot files:        /EFI/ubuntu/grub.cfg /EFI/BOOT/fbx64.efi 
                       /EFI/BOOT/mmx64.efi /EFI/ubuntu/grubx64.efi 
                       /EFI/ubuntu/mmx64.efi /EFI/ubuntu/shimx64.efi

GUID Partition Table detected.

Et le boot en UEFI sur Grub  est bien contrôlé par la NVram :

=================== efibootmgr -v
BootCurrent: 0005
BootOrder: 0005,0001,0002,0004,0000,0003
Boot0000* EFI VMware Virtual SCSI Hard Drive (0.0)	PciRoot(0x0)/Pci(0x10,0x0)/SCSI(0,0)
Boot0001* EFI VMware Virtual SATA CDROM Drive (1.0)	PciRoot(0x0)/Pci(0x11,0x0)/Pci(0x5,0x0)/Sata(1,0,0)
Boot0002* EFI Network	PciRoot(0x0)/Pci(0x11,0x0)/Pci(0x1,0x0)/MAC(000c29852ae6,1)
Boot0003* EFI Internal Shell (Unsupported option)	MemoryMapped(11,0x537cb000,0x53b55fff)/FvFile(c57ad6b7-0515-40a8-9d21-551652854e37)
Boot0004* cd-rom	PciRoot(0x0)/Pci(0x11,0x0)/Pci(0x5,0x0)/Sata(1,0,0)/CDROM(1,0xde8,0x1d40)/File(efibootbootx64.efi)
Boot0005* ubuntu	HD(2,GPT,3e6d692a-8258-4cd4-ad13-16c3a9ec9a1f,0x800,0x7b000)/File(EFIubuntushimx64.efi)

=================== UEFI/Legacy mode:
BIOS is EFI-compatible, and is setup in EFI-mode for this installed-session.
SecureBoot maybe enabled. (maybe sec-boot, Veuillez indiquer ce message à boot.repair@gmail.com)

L’idée est donc de convertir tout cela en installation en Legacy sans redémarrer le PC, et ce pour éviter de passer par un chroot.

2.  Phase de suppression

2.1  Suppression de Grub version EFI

On fait le point sur ce que l’installation en UEFI a installé en matière de fichiers Grub et Shim :

test@test-virtual-machine:~$ dpkg --get-selections | grep grub
grub-common                    install
grub-efi-amd64                    install
grub-efi-amd64-bin                install
grub-efi-amd64-signed                install
grub2-common                    install

test@test-virtual-machine:~$ dpkg --get-selections | grep shim
shim                        install
shim-signed                    install
shimmer-themes                    install
test@test-virtual-machine:~$

L’objectif est de ne conserver que  grub-common et grub2-common :

test@test-virtual-machine:~$ sudo apt purge grub-efi-amd64-signed shim-signed shim
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Le paquet suivant a été installé automatiquement et n'est plus nécessaire :
  mokutil
Veuillez utiliser « sudo apt autoremove » pour le supprimer.
Les paquets suivants seront ENLEVÉS :
  grub-efi-amd64-signed* shim* shim-signed*
0 mis à jour, 0 nouvellement installés, 3 à enlever et 219 non mis à jour.
Après cette opération, 9 037 ko d'espace disque seront libérés.
Souhaitez-vous continuer ? [O/n] o
(Lecture de la base de données... 199189 fichiers et répertoires déjà installés.)
Suppression de shim-signed (1.39+15+1533136590.3beb971-0ubuntu1) ...
Suppression de grub-efi-amd64-signed (1.115+2.02+dfsg1-12ubuntu2) ...
Suppression de shim (15+1533136590.3beb971-0ubuntu1) ...
(Lecture de la base de données... 199161 fichiers et répertoires déjà installés.)
Purge des fichiers de configuration de shim-signed (1.39+15+1533136590.3beb971-0ubuntu1) ...

La commande sudo apt autoremove étant demandée, on s’exécute :

test@test-virtual-machine:~$ sudo apt autoremove
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 :
  mokutil
0 mis à jour, 0 nouvellement installés, 1 à enlever et 219 non mis à jour.
Après cette opération, 71,7 ko d'espace disque seront libérés.
Souhaitez-vous continuer ? [O/n] o
(Lecture de la base de données... 199161 fichiers et répertoires déjà installés.)
Suppression de mokutil (0.3.0+1538710437.fb6250f-0ubuntu2) ...
Traitement des actions différées (« triggers ») pour man-db (2.8.5-2) ...
test@test-virtual-machine:~$

Un bilan de la situation montre qu’il reste encore des choses à supprimer :

test@test-virtual-machine:~$ dpkg --get-selections | grep grub
grub-common                    install
grub-efi-amd64                    install
grub-efi-amd64-bin                install
grub2-common                    install

test@test-virtual-machine:~$ dpkg --get-selections | grep shim
shimmer-themes                    install

On s’exécute à nouveau :

test@test-virtual-machine:~$ sudo apt purge grub-efi-amd64
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires :
  grub-efi-amd64-bin grub2-common
Veuillez utiliser « sudo apt autoremove » pour les supprimer.
Les paquets suivants seront ENLEVÉS :
  grub-efi-amd64*
0 mis à jour, 0 nouvellement installés, 1 à enlever et 219 non mis à jour.
Après cette opération, 187 ko d'espace disque seront libérés.
Souhaitez-vous continuer ? [O/n] o
(Lecture de la base de données... 199155 fichiers et répertoires déjà installés.)
Suppression de grub-efi-amd64 (2.02+dfsg1-12ubuntu2) ...
(Lecture de la base de données... 199151 fichiers et répertoires déjà installés.)
Purge des fichiers de configuration de grub-efi-amd64 (2.02+dfsg1-12ubuntu2) ...
test@test-virtual-machine:~$ 

test@test-virtual-machine:~$ sudo apt purge grub-efi-amd64-bin
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Le paquet suivant a été installé automatiquement et n'est plus nécessaire :
  grub2-common
Veuillez utiliser « sudo apt autoremove » pour le supprimer.
Les paquets suivants seront ENLEVÉS :
  grub-efi-amd64-bin*
0 mis à jour, 0 nouvellement installés, 1 à enlever et 219 non mis à jour.
Après cette opération, 6 548 ko d'espace disque seront libérés.
Souhaitez-vous continuer ? [O/n] o
(Lecture de la base de données... 199151 fichiers et répertoires déjà installés.)
Suppression de grub-efi-amd64-bin (2.02+dfsg1-12ubuntu2) ...
test@test-virtual-machine:~$

Ce qui conduit au résultat qui nous satisfait enfin :

test@test-virtual-machine:~$ dpkg --get-selections | grep grub
grub-common                    install
grub2-common                   install

2.1. Suppression de la partition efi

Celle-ci n’ayant plus aucune utilité, on peut la supprimer. Fdisk fait parfaitement l’affaire :

test@test-virtual-machine:~$ sudo fdisk /dev/sda

Bienvenue dans fdisk (util-linux 2.33.1).
Les modifications resteront en mémoire jusqu'à écriture.
Soyez prudent avant d'utiliser la commande d'écriture.

Commande (m pour l'aide) : p
Disque /dev/sda : 20 GiB, 21474836480 octets, 41943040 secteurs
Disk model: VMware Virtual S
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : gpt
Identifiant de disque : 5265C1C1-D016-45AD-9443-44E588498AA9

Périphérique  Début      Fin Secteurs Taille Type
/dev/sda1      2048   505855   503808   246M Système EFI
/dev/sda2    505856 41881599 41375744  19,7G Système de fichiers Linux

Commande (m pour l'aide) : d
Numéro de partition (1,2, 2 par défaut) : 1

La partition 1 a été supprimée.

Commande (m pour l'aide) : w
La table de partitions a été altérée.
Failed to remove partition 1 from system: Périphérique ou ressource occupé

The kernel still uses the old partitions. The new table will be used at the next reboot. 
Synchronisation des disques.

test@test-virtual-machine:~$

Un message d’erreur signale l’échec de la suppression, qui est pourtant bien réelle. Le résultat d’un sudo fdisk -l confirme que les choses se sont bien passées :

test@test-virtual-machine:~$ sudo fdisk -l
Disque /dev/sda : 20 GiB, 21474836480 octets, 41943040 secteurs
Disk model: VMware Virtual S
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : gpt
Identifiant de disque : 5265C1C1-D016-45AD-9443-44E588498AA9

Périphérique  Début      Fin Secteurs Taille Type
/dev/sda2    505856 41881599 41375744  19,7G Système de fichiers Linux
test@test-virtual-machine:~$

2.3. Suppression du point de montage de la partition efi

La partition efi n’existant plus, il convient de supprimer ce qui pourrait engendrer un erreur. Pour la démonstration, j’utilise l’éditeur nano. On se contente d’ajouter un # devant le point de montage de la partition efi :

test@test-virtual-machine:~$ sudo nano /etc/fstab

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=22e895b7-f8bb-45a0-83c2-51e005a030b0 /               ext4    errors=remoun$
/swapfile                                 none            swap    sw           $
/dev/fd0        /media/floppy0  auto    rw,user,noauto,exec,utf8 0       0
# partition efi
#UUID=70C8-C8A7 /boot/efi       vfat    defaults        0       1

A ce stade, on a supprimé tout ce qui est inutile. On peut passer à la conversion du disque :

3. Conversion du disque au format dos (mbr)

L’outil gdisk est idéal pour cette étape. Rappel : les commandes sont simples, mais non sans risque. Des sauvegardes doivent avoir été effectuées au préalable.

test@test-virtual-machine:~$ sudo gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.3

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): r

Recovery/transformation command (? for help): g

MBR command (? for help): w

Converted 1 partitions. Finalize and exit? (Y/N): y
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
GPT data structures destroyed! You may now partition the disk using fdisk or
other utilities.
test@test-virtual-machine:~$

On vérifie le résultat. Le disque est bien repassé au mode dos-mbr :

test@test-virtual-machine:~$ sudo fdisk -l
Disque /dev/sda : 20 GiB, 21474836480 octets, 41943040 secteurs
Disk model: VMware Virtual S
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x00000000

Périphérique Amorçage  Début      Fin Secteurs Taille Id Type
/dev/sda2             505856 41881599 41375744  19,7G 83 Linux
test@test-virtual-machine:~$

Il ne reste plus qu’à réinstaller un grub cohérent pour notre nouvelle configuration.

4. Réinstallation de Grub-pc

4.1. Installation du paquet grub-pc

test@test-virtual-machine:~$ sudo apt install grub-pc
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Les paquets supplémentaires suivants seront installés : 
  grub-gfxpayload-lists grub-pc-bin
Paquets suggérés :
  desktop-base
Les NOUVEAUX paquets suivants seront installés :
  grub-gfxpayload-lists grub-pc grub-pc-bin
0 mis à jour, 3 nouvellement installés, 0 à enlever et 219 non mis à jour.
Il est nécessaire de prendre 1 044 ko dans les archives.
Après cette opération, 3 617 ko d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer ? [O/n] o
Réception de :1 http://fr.archive.ubuntu.com/ubuntu disco/main amd64 grub-pc-bin amd64 2.02+dfsg1-12ubuntu2 [902 kB]
Réception de :2 http://fr.archive.ubuntu.com/ubuntu disco/main amd64 grub-pc amd64 2.02+dfsg1-12ubuntu2 [138 kB]
Réception de :3 http://fr.archive.ubuntu.com/ubuntu disco/main amd64 grub-gfxpayload-lists amd64 0.7 [3 658 B]
1 044 ko réceptionnés en 2s (548 ko/s)        
Préconfiguration des paquets...
Sélection du paquet grub-pc-bin précédemment désélectionné.
(Lecture de la base de données... 198875 fichiers et répertoires déjà installés.)
Préparation du dépaquetage de .../grub-pc-bin_2.02+dfsg1-12ubuntu2_amd64.deb ...
Dépaquetage de grub-pc-bin (2.02+dfsg1-12ubuntu2) ...
Sélection du paquet grub-pc précédemment désélectionné.
Préparation du dépaquetage de .../grub-pc_2.02+dfsg1-12ubuntu2_amd64.deb ...
Dépaquetage de grub-pc (2.02+dfsg1-12ubuntu2) ...
Sélection du paquet grub-gfxpayload-lists précédemment désélectionné.
Préparation du dépaquetage de .../grub-gfxpayload-lists_0.7_amd64.deb ...
Dépaquetage de grub-gfxpayload-lists (0.7) ...
Paramétrage de grub-pc-bin (2.02+dfsg1-12ubuntu2) ...
Paramétrage de grub-gfxpayload-lists (0.7) ...
Paramétrage de grub-pc (2.02+dfsg1-12ubuntu2) ...

A mi-installation, une fenêtre s’ouvre demandant où placer grub. On choisit /dev/sda :

 ┌───────────────────────┤ Configuration de grub-pc ├────────────────────────┐
 │ Le paquet grub-pc est en cours de mise à jour. Ce menu permet de choisir  │ 
 │ pour quels périphériques vous souhaitez exécuter la commande              │ 
 │ grub-install automatiquement.                                             │ 
 │                                                                           │ 
 │ Il est en général recommandé d'exécuter grub-install automatiquement,     │ 
 │ afin d'éviter la situation où l'image de GRUB est désynchronisée avec     │ 
 │ les modules de GRUB ou le fichier grub.cfg.                               │ 
 │                                                                           │ 
 │ Si vous n'avez pas la certitude du périphérique utilisé comme             │ 
 │ périphérique d'amorçage par le BIOS, il est en général conseillé          │ 
 │ d'installer GRUB sur l'ensemble des périphériques.                        │ 
 │                                                                           │ 
 │ Veuillez noter que GRUB peut également être installé sur les secteurs     │ 
 │ d'amorçage de partitions. Certaines partitions où cela pourrait être      │ 
 │ nécessaire sont indiquées ici. Cependant, cela impose que GRUB utilise    │ 
 │ le mécanisme « blocklist », ce qui le rend moins fiable et n'est donc     │ 
 │ pas recommandé.                                                           │ 
 │                                                                           │ 
 │ Périphériques où installer GRUB :                                         │ 
 │                                                                           │ 
 │    [x] /dev/sda (21474 Mo; VMware_Virtual_S)                              │ 
 │    [ ] /dev/sda2 (21184 Mo; VMware_Virtual_S)                             │ 
 │                                                                           │ 
 │                                                                           │ 
 │                                  <Ok>                                     │ 
 │ __________________________________________________________________________

L’installation se termine ainsi :

Creating config file /etc/default/grub with new version
Installation pour la plate-forme i386-pc.
Installation terminée, sans erreur.
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/init-select.cfg'
Création du fichier de configuration GRUB…
Image Linux trouvée : /boot/vmlinuz-5.0.0-27-generic
Image mémoire initiale trouvée : /boot/initrd.img-5.0.0-27-generic
Image Linux trouvée : /boot/vmlinuz-5.0.0-13-generic
Image mémoire initiale trouvée : /boot/initrd.img-5.0.0-13-generic
fait
Traitement des actions différées (« triggers ») pour man-db (2.8.5-2) ...
test@test-virtual-machine:~$

4. 2. Installation de grub et mise à jour

test@test-virtual-machine:~$ sudo grub-install /dev/sda
Installation pour la plate-forme i386-pc.
Installation terminée, sans erreur.

test@test-virtual-machine:~$ sudo update-grub
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/init-select.cfg'
Création du fichier de configuration GRUB…
Image Linux trouvée : /boot/vmlinuz-5.0.0-27-generic
Image mémoire initiale trouvée : /boot/initrd.img-5.0.0-27-generic
Image Linux trouvée : /boot/vmlinuz-5.0.0-13-generic
Image mémoire initiale trouvée : /boot/initrd.img-5.0.0-13-generic
fait
test@test-virtual-machine:~$

5. Vérifications de l’installation

5.1. Vérifications avant un redémarrage

C’est le moment de faire un nouveau rapport boot-info avant de redémarrer le PC : boot-info avant redémarrage.

On constate que plusieurs choses ont changé :

  • Un grub a bel et bien été ajouté dans le mbr
============================= Boot Info Summary: =============================== 
=> Grub2 (v2.00) is installed in the MBR of /dev/sda and looks at sector 1 of the 
same hard drive for core.img. core.img is at this location and looks for 
(,msdos2)/boot/grub. It also embeds following components:
  • Le disque est bien reconnu comme un disque dos dans grub.cfg
set root='hd0,msdos2'

Mais, on a encore de nombreuses traces de notre démarrage en UEFI, notamment les points de montage et l’enregistrement du démarrage :

================================ Mount points: ================================= 
Device Mount_Point Type Options 
/dev/sda1 /boot/efi vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro) 
/dev/sda2 / ext4 (rw,relatime,errors=remount-ro)

=================== UEFI/Legacy mode: 
BIOS is EFI-compatible, and is setup in EFI-mode for this installed-session.

Mais Grub a compris que notre installation est passée en mode Legacy

=================== Suggested repair 
The default repair of the Boot-Repair utility would reinstall the grub2 of sda2 
into the MBR of sda. 
Grub-efi would not be selected by default because: no-win-efi

Si on souhaitait réparer, ce qui n’est pas nécessaire, la réparation serait satisfaisante. Nous nous contenterons de redémarrer.

5.2. Vérification après redémarrage

Le redémarrage se fait bien sûr en mode Legacy, après modification du bios. Un nouveau rapport boot-info nous dévoile la situation finale : boot-info final.

  •  Xubuntu est bien exécuté en mode Legacy
=================== UEFI/Legacy mode: 
This installed-session is not in EFI-mode. 
SecureBoot disabled

sda	: not-GPT,	BIOSboot-not-needed,	has-no-EFIpart, 	not-usb,	not-mmc, has-os,	2048 sectors * 512 bytes

Les traces de l’installation en uefi ont intégralement disparu.

 

Convertir une Xubuntu 19.04 de mbr à gpt

Si on a un PC récent qui supporte l’UEFI et qu’on a installé son Linux en Legacy, on peut être intéressé par une conversion d’un disque dos (mbr) vers le format gpt, mais on n’a pas forcément envie de réinstaller son OS.

Avec Windows, il existe une commande « clé en main », mais avec Ubuntu, Comment faire ?

1. Situation de départ

On part d’une installation d’Ubuntu 19.04 64 bits faite en Legacy sur un disque au format dos (autrement dit mbr). Je n’ai pas jugé nécessaire de faire un rapport boot-info, et je me suis contenté d’une capture d’écran de ce que gparted présente dans le cas d’une installation simple :

Mon image

On note que l’installation ne comporte qu’une seule partition ext4 (contenant le système et le /home), et que le disque est au format dos (mbr).

2. Les modifications depuis le liveCD

Aucune modification sérieuse n’étant possible depuis une version, installée, on va redémarrer sur le liveCD (en mode Legacy ou UEFI, c’est sans importance pour l’instant) afin de procéder aux principales modifications.

2.1. Conversion du disque au format gpt

Pour cette opération, on va utiliser le partitionneur gdisk. On lui associe le disque concerné, en l’occurrence /dev/sda :

sudo gdisk /dev/sda

Une série d’informations nous signale que nous sommes en présence d’un disque mbr. Une commande est attendue. Un simple « w » confirmé par un « y » va suffire à convertir le disque au format gpt :

Mon image

 

Et c’est tout ! Le disque est instantanément converti au format GPT par gdisk.

2.2. Ajout d’une partition EFI

2.2.1. Rétrécissement de la partition Ubuntu

Il est bien clair que la conversion n’aurait aucun intérêt sans partition EFI. Il va falloir la créer. L’option choisie ici est de la placer en tête de disque. Avec gparted, on va donc rétrécir la partition Ubuntu par la gauche.

Mon image

Les fichiers étant déplacés, l’opération dure un certain temps, comme le montre la seconde capture d’écran :

Mon image

2.2.2. Création d’une partition fat32

Sur l’espace libre du disque qui est bel et bien passé au format gpt, on va choisir de créer une partition  principale formatée en fat32.

Mon image

Elle recevra automatiquement l’identifiant /dev/sda2 de manière assez logique, ce que montre la capture d’écran qui suit.

2.2.3. Attribution du statut efi à la partition fat32

Lorsque c’est fait, on lui attribue par clic droit les drapeaux boot et esp (ils sont conjoints) :

Mon image

Notre disque est prêt sur le plan de sa structure d’ensemble. Mais pour l’instant, notre Ubuntu n’est toujours pas capable de fonctionner en UEFI.

2.3. Ajout de l’UUID de la partition efi dans le fichier fstab

Pour éviter de passer ultérieurement par un montage manuel de la partition efi dans /boot/efi, il sera judicieux de l’automatiser tout de suite. La partition efi créée ayant reçu automatiquement une UUID (une idenfication)  : autant s’en servir. La commande suivante est là pour nous renseigner :

blkid

L’UUID de la partition /dev/sda2 étant 3C87-F1BE (Cf. image suivante), il va falloir copier cette référence, et l’ajouter au fichier /etc/fstab. Pour ce faire, on va créer un nouveau dossier, monter la partition Ubuntu dans ce dossier, et ouvrir le fichier fstab avec l’éditeur de texte de sa distribution (ici, c’est « mousepad« ) en administrateur en saisissant :

sudo mkdir /mnt/sda1
sudo mount /dev/sda1 /mnt/sda1
sudo mousepad /mnt/sda1/etc/fstab

Et dans le fichier texte qui s’est ouvert, on ajoute les deux lignes suivantes :

# partition efi
UUUID=3C87-F1BE      /boot/efi      /vfat     /defaults     0      1

On indique en fait au système qu’il  doit monter automatiquement cette partition dans /boot/efi à chaque démarrage d’Ubuntu. L’ensemble donne ceci :

Mon image

A ce stade, notre disque et notre système sont prêts pour la dernière étape : la modification de grub.

3. Passage de Grub pour Legacy à Grub pour UEFI

3.1. Démarrage du système en UEFI via un outil externe

Maintenant, il faut modifier son bios pour le passer du mode Legacy au mode UEFI (ici, chaque marque étant particulière, il est impossible de donner une explication sinon que ça se joue généralement dans l’onglet « boot »).

Lorsque c’est fait, on doit pouvoir lancer son LiveCD en mode UEFI. Mais ce moyen étant fastidieux (car on devra passer par un chroot pour réécrire grub, ce qui augmentera le nombre de commandes), on peut choisir d’utiliser le CD de « REfind » ou de « SuperGrub2disk » qui sont capables de lancer notre Ubuntu installé directement en UEFI via son noyau. C’est le cas ici avec le CD REfind :

Mon image

Grâce à lui, nous allons travailler directement en UEFI sur la version installée. En choisissant l’option proposée, nous nous retrouvons sur le bureau de notre Ubuntu 19.04 en version installée.

3.2. Suppression des fichiers grub

L’installation d’Ubuntu Legacy ayant inséré des fichiers grub pour ce mode, il convient de les supprimer. La commande est la suivante :

sudo apt purge grub-pc

La commande  nous invitant à ajouter la commande suivante,  nous nous exécutons :

sudo apt autoremove

Le résultat des deux commandes est le suivant :  

Mon image

A cet instant, l’installation ne possède plus aucun Grub installé. On pourrait très bien le remplacer par Elilo, Refind ou autre lanceur capable de fonctionner en UEFI. Restons-en à Grub.

3.3. Installation des fichier efi de Grub

Cette partie est la plus délicate, car de version en version de Grub, on est confronté à des variantes, et pour trouver des informations fiables, ce n’est pas toujours simple. Cette fois, j’ai trouvé les commandes assez rapidement (dans mes propres essais précédents, en fait), pour récupérer les paquets nécessaires :

sudo apt install grub-efi-amd64-signed shim shim-signed

Mon image

Grub et Shim sont nécessaires, notamment si on utilise un PC avec le secure-boot activé. Puis, installation de grub et mise à jour :

sudo grub-install /boot/efi
sudo update-grub

L’installation de tout cela se déroule sans encombre :

Mon image

Notre Ubuntu est prêt à fonctionner. Un redémarrage confirme que tout s’est bien passé. Et de même pour le rapport boot-info récapitulatif.

A noter que l’opération inverse est également faisable, et qu’on peut le faire avec Windows, et même avec un dual-boot.

Ubuntu sur USB ou disque indépendant de Windows en UEFI

Une des demandes fréquentes sur les forums est de savoir comment installer en mode UEFI un Linux sur un support USB ou sur un disque secondaire, sans impacter  l’état et le fonctionnement de son Windows préinstallé. On pourra faire la même expérience pour une installation en Legacy.

I. Installation standard sur un disque secondaire de Xubuntu 19-04

On va partir d’un Windows 10 (pré)installé auquel on ajoute un disque secondaire destiné à recevoir une installation Linux. Le disque secondaire a été préalablement formaté et converti au format gpt depuis ce même Windows, mais c’est parfaitement faisable depuis Linux, avec le logiciel gparted.

La situation initiale est donc la suivante :

Mon image

 1. Essai échoué (!!!) d’installation directe avec l’outil Ubuntu intégré

La première chose à faire est de booter en uefi sur le LiveUSB. On peut vérifier qu’on est bien dans ce mode via la commande suivante qui doit retourner « session efi » :

[ -d /sys/firmware/efi ] && echo "Session EFI" || echo "Session non-EFI"

Si c’est bien le cas, on lance le processus d’installation, jusqu’à obtenir un choix proposant plusieurs types d’installation. Pour maîtriser au mieux la situation, on choisit « autre chose ». Dans mon cas, j’obtiens ceci :

Mon image

Le disque sdb est mon disque vide, je vais donc l’utiliser pour créer deux partitions (avec la touche +) : une partition efi de 100 Mo, et une partition ext4 avec le point de montage / avec le reste.

Ce qui donne ceci :

Mon image

Avant de lancer le processus, je précise à mon installateur de choisir sdb pour y placer grub pour être sûr de ne pas me retrouver avec un grub dans sda.

Mon image

Comme tout semble bon, on se lance. L’installation se fait de la manière habituelle et au redémarrage, on trouve un grub qui me propose de lancer tout ce que j’ai dans le PC, ce qui déjà n’est pas exactement ce que je souhaitais. Des entrées inutiles insérées dans grub vont être à supprimer.

Mon image

Ensuite, le passage par un rapport boot-info me présente d’autres surprises :

sda2: File system:       vfat
    Operating System:  
    Boot files:        /EFI/ubuntu/grubx64.efi /EFI/ubuntu/mmx64.efi 
                       /EFI/ubuntu/shimx64.efi 
                       /EFI/Microsoft/Boot/bootmgfw.efi 

sdb2: File system:       vfat
    Boot sector type:  FAT32
    Boot sector info:  No errors found in the Boot Parameter Block.
    Operating System:  
    Boot files:

Mes fichiers grub se sont logés, malgré ma demande (!!!), non pas dans la partition efi de mon disque sdb mais dans sda2 , qui est d’ailleurs montée dans fstab.

=================="blkid" output: 
/dev/sda2        6205-ABC5                              vfat       
/dev/sdb2        0EE5-E1D5                              vfat

=================== sdb3/etc/fstab: 
UUID=1c312bcb-c662-47de-913d-558d3696bc9b /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sda2 during installation
UUID=6205-ABC5  /boot/efi       vfat    umask=0077      0       1
/swapfile                                 none            swap    sw              0       0
/dev/fd0        /media/floppy0  auto    rw,user,noauto,exec,utf8 0       0

Là encore, les choses ne sont pas celles attendues. Comment réparer cela ?

2. Réparation des dysfonctionnements liés à l’installation directe

La première chose à faire, c’est de faire comprendre à Ubuntu qu’on veut utiliser la partition efi de sdb et non celle de sda. Pour ce faire, on va modifier le fichier /etc/fstab pour que soit montée au démarrage suivant la bonne partition. Le résultat de blkid dans boot-info nous donne son uuid. Il suffit donc de réaliser une simple substitution, en l’occurrence :

Mon image

Une fois la chose faite, on va redémarrer Ubuntu pour que ce montage soit appliqué. On pourra vérifier que la partition sdb2 est bien montée en allant voir le contenu de /boot/efi qui doit être vide.

Mon image

On peut donc passer à la suite : on réinstalle grub via la commande :

sudo grub-install

Puis, on désactive le fichier 30_os-prober pour ne plus exécuter les entrées non désirées.

sudo chmod -x /etc/grub.d/30_os-prober

Et enfin, on met grub à jour :

sudo update-grub

Le résultat est le suivant :

Mon image

Au redémarrage, on a bien une entrée pour Ubuntu et les entrées inutiles ont disparu. Il nous reste à nettoyer les entrées obsolètes de grub dans la partition efi de sda, en l’occurrence (selon mon rapport boot-info)  sda2. On monte la partition, et on supprime le dossier ubuntu et on vérifie le résultat. Si c’est bon, on démonte la partition.

sudo mkdir /mnt/sda2
sudo mount /dev/sda2 /mnt/sda2
sudo rm -fr /mnt/sda2/EFI/ubuntu
ls /mnt/sda2/EFI
sudo umount /mnt/sda2
sudo rm -fr /mnt/sda2

En image, on obtient ceci :

Mon image

Notre Ubuntu est bien installé de manière autonome sur la clé, ce que confirme notre nouveau rapport boot-info.

La partition sda2 est débarrassée des fichiers grub :

sda2: File system:       vfat
    Operating System:  
    Boot files:        /EFI/Boot/bootx64.efi /EFI/Boot/fbx64.efi 
                       /EFI/Boot/mmx64.efi /EFI/Microsoft/Boot/bootmgfw.efi 
                       /EFI/Microsoft/Boot/bootmgr.efi 
                       /EFI/Microsoft/Boot/memtest.efi

Ils sont bien présents sur sdb2 :

sdb2: File system:       vfat
    Operating System:  
    Boot files:        /EFI/ubuntu/grub.cfg /EFI/BOOT/fbx64.efi 
                       /EFI/BOOT/mmx64.efi /EFI/ubuntu/grubx64.efi 
                       /EFI/ubuntu/mmx64.efi /EFI/ubuntu/shimx64.efi

Et le démarrage prend bien en priorité mon installation de Linux, puis celle de Windows, chacun étant sur une partition efi différente :

=================== efibootmgr -v
BootCurrent: 0005
Timeout: 2 seconds
BootOrder: 0005,0010,000C,000D,000E,000F,0011

Boot0005* ubuntu	HD(2,GPT,dae2fbc5-e304-42f5-840c-1054ae1500f8,0x8000,0x2f800)/File(EFIubuntushimx64.efi)
Boot0010* Windows Boot Manager	HD(2,GPT,ffcaac27-7335-49f8-8028-b198618d7559,0x96800,0x31800)/File(EFIMicrosoftBootbootmgfw.efi)

Si on débranche, supprime, ou formate le disque sdb, Windows reprendra la main automatiquement comme avant l’installation d’Ubuntu, ce qui est nécessaire pour effectuer la seconde démo.

Mais n’était-il pas possible d’éviter toute cette fastidieuse manipulation ?

II. Installation d’Ubuntu sur disque externe ou usb sans réparation

La situation de départ est la même que pour le point I. A savoir, on dispose d’un disque vierge sur lequel on souhaite installer Ubuntu en uefi de manière indépendante :

Mon image

Cette fois, on va d’abord passer par gparted pour effectuer quelques modifications sur le disque sda. En cliquant droit sur la partition efi, ici sda2, et en choisissant l’option « manage flags« , on peut modifier la partition efi pour qu’elle semble n’être qu’une partition de données en fat32. Le résultat sera conforme à ceci :

Mon image

Mais attention !!!!

A cet instant, Windows n’est plus capable de booter !!! Nous devrons le réparer pour le rendre à nouveau fonctionnel !!!!

On va dès lors retenter une installation dans les mêmes conditions qu’au point 1. Type de partitionnement : « Autre chose« . Et on crée une partition efi de 100 Mo et une partition ext4 avec point de montage / sur le reste du disque. On choisit /dev/sdb pour y placer son grub.

L’installation se fait sans problème, et on n’a plus qu’à faire un rapport boot-info pour voir le résultat.

La situation est nettement meilleure. Les fichiers grub sont bien installés dans la bonne partition (sdb1) et la NVram est programmée pour démarrer sur cette installation toute fraîche. Mais il reste plusieurs choses à corriger :

  • Windows ne pouvant plus démarrer, on va réactiver les drapeaux ESP et Boot pour redonner à sda2 son statut efi avec l’option « manage flags » par clic droit sur sda2. Il sera alors possible de redémarrer pour régler le second problème :

 Mon image

  • Dans mon cas, puisque j’ai d’autres Linux déjà installés, Grub s’est paramétré pour lancer les noyaux de Fedora et Mint présents sur sda, ce que je ne souhaite pas : on va donc désactiver os-prober, comme on l’a fait dans le premier point, via la commande sudo chmod  et on met grub à jour :

Mon image

Cette situation ne se produira pas si on n’a pas d’autre Linux sur le PC. La situation finale est alors la même qu’au premier point. Notre Linux pourra booter sans nuire à Windows qui reprendra la main dès que ce disque sdb sera débranché.

Résoudre erreur de l’installateur ubuntu 19.04

L’installateur de la version 19.04 est source de nombreux problèmes lors de la création de dual-boot, si on ne prête pas attention aux choix que l’on fait. En effet, si on possède un Windows installé en mode Legacy et qu’on démarre sans le vouloir son liveUSB en mode UEFI, on risque fort de se retrouver dans une situation très problématique.

On voit ceci dans de nombreux sujets, à l’image de celui-ci : https://forum.ubuntu-fr.org/viewtopic.php?id=2040793

Le détail de l’erreur commise par l’installateur est essentiellement visible dans les lignes suivantes du rapport boot-info :

Disk /dev/sda: 223.6 GiB, 240057409536 bytes, 468862128 sectors
Disklabel type: dos

Device     Boot     Start       End   Sectors   Size Id Type
/dev/sda1            2048    206847    204800   100M  7 HPFS/NTFS/exFAT
/dev/sda2          206848 293165441 292958594 139.7G  7 HPFS/NTFS/exFAT
/dev/sda3  *    293167104 294215679   1048576   512M ef EFI (FAT-12/16/32)
/dev/sda4       294217726 468860927 174643202  83.3G  5 Extended
/dev/sda5       294217728 468860927 174643200  83.3G 83 Linux

sda3: __________________________________________________________________________
    File system:       vfat
    Boot sector type:  FAT32
    Boot files:        /EFI/ubuntu/grub.cfg /EFI/BOOT/fbx64.efi 
                       /EFI/BOOT/mmx64.efi /EFI/ubuntu/grubx64.efi 
                       /EFI/ubuntu/mmx64.efi /EFI/ubuntu/shimx64.efi

### BEGIN /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_os-prober ###

=================== PARTITIONS & DISKS:
sda5 : sda, not-sepboot, grubenv-ok grub2, signed grub-pc grub-efi , update-grub, 64, with-boot, is-os, not--efi--part, fstab-without-boot, fstab-has-goodEFI, no-nt, no-winload, no-recov-nor-hid, no-bmgr, notwinboot, apt-get, grub-install, with--usr, fstab-without-usr, not-sep-usr, standard, farbios, notbiosboot, .

On voit qu’une partition efi a été créée malgré le format « dos » de ce disque, qu’elle ne contient que des fichiers de démarrage pour Ubuntu, et que la version installée utilise un grub efi signé… Windows n’est pas détecté et ne boote plus, ce qui est démontré par os-prober. Bref, c’est une situation délicate à résoudre, si on veut faire les choses proprement.

I. Exemple d’installation ratée

On va partir d’un W8 installé en mode Legacy, et dans lequel on a tout préparé pour faire une installation « sans problème » :

Mon image

On voit dans la capture d’écran que le disque est bien au mode ms-dos, et qu’on a libéré un espace suffisant pour l’installation d’Ubuntu. On va volontairement faire une erreur pour l’installation et démarrer sur le live-cd en mode Uefi et non Legacy.

Les commandes suivantes montrent bien que notre démarrage de Xubuntu se fait en mode UEFI, et l’installation « à-côté de Windows » va pouvoir se faire.

 

Mon image

Rem : dans mon cas, l’option n’était pas proposée car j’avais déjà 3 partitions primaires. L’installateur créant au moins 2 partitions primaires, j’aurais donc dépassé la limite des 4 partitions. J’ai donc opté pour la solution des « partitions logiques » en passant par « autre chose », car ce cas a également été rencontré.  

L’installation se fait de manière tout à fait banale.

Rem. En fait, pas tant que ça dans mon cas, car j’ai dû passer par boot-repair suite à un plantage de l’installation. Mais bon, ce n’est pas ce qui m’intéresse. Le résultat est en tout cas celui -ciRapport boot-info

Plusieurs modifications ont été faites lors de l’installation (outre les réparations de boot-repair).

1. La partition de démarrage de Windows n’est plus bootable

/dev/sda2             616,448     1,081,343       464,896   7 NTFS / exFAT / HPFS

2. C’est bien un Grub efi qui est utilisé

sda6	: sda,	not-sepboot,	grubenv-ok	grub2,	signed grub-pc grub-efi ,	update-grub,	64,	with-boot,	is-os,	not--efi--part,	fstab-without-boot,

3. Rien n’a été écrit dans le mbr

 => Windows 7/8/2012 is installed in the MBR of /dev/sda.

4. Le PC boote bel et bien en UEFI malgré un disque ms-dos

=================== UEFI/Legacy mode:
BIOS is EFI-compatible, and is setup in EFI-mode for this installed-session.

5. Et Windows n’est pas détecté

### BEGIN /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_os-prober ###

Mais le plus grave, c’est que même si je supprime mon Linux tel qu’il est installé, mon Windows ne bootera pas. Il n’en est plus capable sans passer par des réparations. On confirme en forçant le redémarrage en mode Legacy :

Mon image

Sur un vrai PC, on aurait probablement un message signalant l’absence de système d’exploitation, voire une redirection vers le bios. Il est donc nécessaire de réparer tout cela. Et la première chose à faire, c’est de réparer Windows.

II. Réparation de Windows

Pour réparer Windows, on va démarrer à nouveau sur le liveUSB, en mode Legacy (de préférence) ou en mode Uefi. C’est finalement sans grande importance. Le rapport boot-info nous a montré ceci :

sda2: __________________________________________________________________________

    File system:       ntfs
    Boot sector type:  Windows 8/2012: NTFS
    Boot sector info:  No errors found in the Boot Parameter Block.
    Operating System:  
    Boot files:        /bootmgr /Boot/BCD

sda5: __________________________________________________________________________

    File system:       vfat
    Boot sector type:  FAT32
    Boot sector info:  No errors found in the Boot Parameter Block.
    Operating System:  
    Boot files:        /EFI/ubuntu/grub.cfg /EFI/BOOT/bkpbootx64.efi 
                       /EFI/BOOT/bootx64.efi /EFI/BOOT/fbx64.efi 
                       /EFI/BOOT/mmx64.efi /EFI/ubuntu/grubx64.efi 
                       /EFI/ubuntu/mmx64.efi /EFI/ubuntu/shimx64.efi

C’est donc la partition sda2 qui contient les fichiers de démarrage de Windows, et sda5 qui est la partition efi. On va commencer par supprimer cette partition efi sda5 et remettre le drapeau boot sur la partition sda2.  Le plus simple est d’utiliser gparted pour cela :

Mon image

La partition Windows, bien qu’indiquée en état d’erreur par gparted, ne pose pas de problème, et le redémarrage suivant  (en mode Legacy, puisqu’on n’a pas touché au bios) permet à nouveau de retrouver son Windows comme au départ :

Mon image

Le principal est fait. Windows refonctionne normalement.

La réparation peut maintenant prendre quatre directions si on veut un dual-boot :

1. Réparer Grub avec boot-repair depuis le Live-CD : cette solution est par exemple proposée ici dans ce sujet résolu par malbo  : https://forum.ubuntu-fr.org/viewtopic.php?id=2043692

2. Réparer Grub depuis le Live-CD via un chroot. Il faudra en premier lieu supprimer les paquets efi précédemment installés, et réinstaller grub-PC à la place. Je ferai une démo à l’occasion.

3. Faire la même manipulation depuis un démarrage avec SuperGrub2disk. Ca évite de chrooter. C’est en gros la technique que j’ai utilisée ici, à partir de « On réinstalle grub » :
https://forum.ubuntu-fr.org/viewtopic.php?pid=18967821#p18967821

4. Réinstaller Ubuntu dans le bon mode. C’est le choix que j’ai fait ici, par commodité. Je pars du principe que le problème apparaissant après une installation ratée, on n’a pas grand chose à perdre à passer par une réinstallation. .

La résultat après réinstallation correcte d’Ubuntu est le suivant : boot-info terminal.

 

 

 

Dual-boot Manjaro Mint en mbr: résoudre les problèmes de mise à jour

Dans le cadre des dual-boot ou trial-boot purement Linux, on peut être confronté à des soucis de compatibilité dans les versions de grub. Ca peut parfois se manifester dès l’installation, mais aussi parfois après une mise à jour d’une des distributions.

1. Situation de départ

On part d’une installation réalisée en mode Legacy, sur disque mbr (ms-dos) entre une Linux Mint installée en premier temps, puis une Xubuntu, et enfin une Manjaro installée à la fin. C’est donc le grub de cette dernière version qui va contrôler le triple démarrage, puisqu’il va écraser le précédent Grub.  Partons d’une situation théorique comme celle-ci :

Mon image

Le tout est installé sur le disque /dev/sda. C’est le grub de Manjaro qui dirige l’ensemble. Or, il se peut qu’une mise à jour d’une des distributions se fasse tôt ou tard, et qu’elle modifie le fonctionnement du démarrage. C’est ce qui s’est produit ici avec la version Mint. Et là, surprise : en voulant exécuter Manjaro, on obtient ceci :

Mon image

2. Explication du problème

En faisant sa mise à jour, Linux Mint a substitué son propre Grub à celui de Manjaro pour gérer le démarrage. Or, les paramétrages des deux versions sont différentes, et le Grub de Mint n’est plus capable de lancer Manjaro correctement. Plusieurs solutions sont possibles, plus ou moins compliquées.

3. Les solutions

3.1. Solution rapide (spécifique pour Manjaro)

On peut imaginer des solutions proches pour d’autres distributions, mais sans test, il est difficile de l’affirmer. On démarre sur le grub de Mint, et au lieu de choisir la version normale de Manjaro, on choisit les options avancées ce qui affichera ceci :

Mon image
Parmi les trois versions proposées, il suffira de choisir la version « fallback » pour pouvoir lancer une version encore opérationnelle de Manjaro. Une fois le bureau affiché, une simple réinstallation de grub redonnera la main à Manjaro qui refonctionnera correctement :

sudo grub-install /dev/sda
sudo update-grub

3.2. Solution plus complexe, mais plus universelle : le chroot

Il n’est pas sûr que toutes les distributions offrent une solution de secours comme c’est le cas de Manjaro. Dans ce cas, il va falloir chrooter, autrement dit réparer depuis le liveCD ou liveUSB en modifiant le répertoire racine, exactement comme si on agissait depuis un Linux installé.

  • Montage de la partition Manjaro vers /mnt
mount /dev/sda1 /mnt
  • Montage des outils pour le chroot (c’est pareil sous toutes les distributions)
mount -t proc proc /mnt/proc
mount -t sysfs sys /mnt/sys
mount -o bind /dev /mnt/dev
mount -t devpts pts /mnt/dev/pts/
  • Le chroot 
chroot /mnt
  • Activation de os-prober (pour les autres versions à détecter)
pacman -S mtools os-prober
  • Installation et mise à jour de grub
grub-install /dev/sda
update-grub (ici, il faut un peu de patience)

On redémarre et on retrouve son grub Manjaro et sa version fonctionnelle.

3.3. Anticipation et explication

Le mieux est tout de même de comprendre le souci. Et pour cela, il faut comparer les versions de grub.cfg de chacune des deux distributions. On les trouve dans /boot/grub de chaque OS respectif en cours d’exécution (nb. On ne peut ouvrir le fichier grub.cfg de Manjaro qu’en mode admin).

  • La version de Manjaro affiche ceci :
### BEGIN /etc/grub.d/10_linux ###
menuentry 'Manjaro Linux' --class manjaro --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-8eb0defb-f6cd-48cf-b8cd-2f34975c0139' {
savedefault
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-ieee1275='ieee1275//disk@0,msdos1' --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 8eb0defb-f6cd-48cf-b8cd-2f34975c0139
else
search --no-floppy --fs-uuid --set=root 8eb0defb-f6cd-48cf-b8cd-2f34975c0139
fi
linux /boot/vmlinuz-4.19-x86_64 root=UUID=8eb0defb-f6cd-48cf-b8cd-2f34975c0139 rw quiet
initrd /boot/intel-ucode.img /boot/initramfs-4.19-x86_64.img
}
  • Et celle de Mint va exécuter cela :
### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'Manjaro Linux (18.0.2) (sur /dev/sda1)' --class manjarolinux --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-44d457a9-2ba0-49ca-a90d-6da3ee74a0ac' {
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 44d457a9-2ba0-49ca-a90d-6da3ee74a0ac
else
search --no-floppy --fs-uuid --set=root 44d457a9-2ba0-49ca-a90d-6da3ee74a0ac
fi
linux /boot/vmlinuz-4.19-x86_64 root=UUID=44d457a9-2ba0-49ca-a90d-6da3ee74a0ac rw quiet
initrd /boot/intel-ucode.img
}

Outre les incohérences sur les UUID (on pourrait remettre ça en ordre), on voit que l’erreur majeure de Mint apparaît en dernière ligne, car une instruction manque :

boot/initramfs-4.19-x86_64.img

Pour éviter que le problème ne se produise, il est possible d’ajouter par avance les bonnes commandes issues du grub.cfg de  Manjaro au fichier 40_custom de la version Mint. On ouvre le fichier en admin (mousepad est à adapter à l’éditeur de texte de la distribution utilisée : gedit, xed ou autre):

sudo mousepad /etc/grub.d/40_custom

Cela donne ceci :  

Mon image
Ici, j’ai choisi d’ajouter à la fois la version normale de Manjaro et les versions avancées. Il ne reste plus qu’à redonner la main à Mint en réinstallant son grub :

sudo grub-install /dev/sda
sudo update-grub

On redémarre pour trouver ceci  :

Mon image
On voit que deux possibilités de lancer Manjaro sont offertes. La première demeure HS, mais la seconde, elle, fonctionne et lance Manjaro tout à fait normalement. Il suffirait d’avoir passé avant la réinstallation de grub sous Mint la commande suivante pour n’avoir que la version correcte de Manjaro :

sudo chmod -x /etc/grub.d/30_os-prober

Ainsi, les prochaines mises à jour ne causeraient plus le moindre souci, et Manjaro se lancerait toujours bien, même depuis Mint.

Cette démo a été conçue d’après ce sujet  sur PC-Astuces.

Réinitialiser un mot de passe utilisateur perdu sous Linux Mint

Il existe plusieurs méthodes pour contourner la perte d’un mot de passe sous Linux. On peut y parvenir de plusieurs manières, soit en utilisant un LiveCD  ou même directement en modifiant les paramètres de Grub. On trouve plusieurs liens expliquant les différentes techniques, notamment :

S’il est vrai que la méthode par LiveCD fonctionne avec toutes les dérivées d’Ubuntu, celle proposée via grub ne fonctionne pas avec Linux Mint, notamment parce qu’ un mot de passe va être demandé pour accéder au mode root :

Mon image

Il est évident que répondre à une demande de mot de passe pour obtenir ce même mot de passe est absurde. On va donc procéder autrement. On va modifier grub pour contourner cette restriction.

Au démarrage, dans le cas d’un dual boot, Grub s’affiche* pour proposer une menu de ce genre : on va sélectionner la première ligne et au lieu de faire « entrée », on sélectionne la lettre « e » (pour éditeur).

* Si on a un simple boot, on maintient shift pour forcer l’affichage de grub.

Mon image

Le contenu du script de démarrage va s’afficher. On va repérer la ligne contenant les indications de démarrage. L’instruction « quiet splash » devrait y apparaître. :

Mon image
On va faire une modification ponctuelle, elle ne sera pas enregistrée. Avec les flèches haut /bas /droite /gauche /effac (etc.), on se se déplace sur la ligne où apparaît quiet splash, et on supprime tout ce qui est après « RO » (c’est le mode graphique) et on ajoute init=/bin/bash * pour aboutir à un terminal en mode root (le clavier étant en qwerty, il faut taper init=!bin!bqsh . On lance avec la combinaison CTRL et X .

* L’option single  est inopérante sous Mint et demande un mot de passe.

Mon imageLinux Mint va se lancer en mode texte et conduire à un terminal en mode root :

Mon image

1. Méthode 1 : réinitialisation directe du MP en mode terminal

On s’assure que la partition racine (/) est montée en lecture et écriture, on identifie l’identifiant de l’utilisateur si on ne le connaît pas, et on remplace le mot de passe  avec les trois commandes suivantes.

mount -o remount,rw /  ( ou mount -o -rw remount / )
cat /etc/passwd (pour trouver le nom d’utilisateur si on l’ignore)
passwd utilisateur

Le résultat est le suivant :

Mon image
Après avoir saisi et confirmé le MP, il est immédiatement réinitialisé. Au prochain redémarrage, il sera immédiatement pris en compte.

2. Méthode 2 : réinitialisation via l’éditeur « nano ». 

On peut également supprimer le mot de passe complètement avec l’éditeur de texte « nano ». Comme on l’a fait précédemment, on va s’assurer que la partition / est accessible en écriture :

mount -o remount,rw /

Ensuite, on va ouvrir le fichier /etc/shadow pour le modifier :

Mon image

Cela va ouvrir une fenêtre de ce genre : avec les flèches haut /bas /droite /gauche /effac (etc.), on supprime la série inscrite entre les deux premiers doubles-points du compte utilisateur :

Mon image

On valide avec CTRL et O et on quitte avec CTRL et X. Enfin, on redémarre en mode normal. Linux Mint  nous conduit directement au bureau. Il ne reste plus qu’à réattribuer un mot de passe au compte utilisateur. Dans mon exemple, on est sur une Mint Xfce. Je sélectionne « Menu / Système /Utilisateurs et groupes :

Mon image

On constate qu’aucun mot de passe n’est attribué à l’utilisateur. Il ne reste plus qu’à l’ajouter.

Mon image

Il ne reste plus qu’à vérifier qu’il fonctionne. Une commande telle que sudo fdisk -l va demander un mot de passe. Il suffira de saisir celui qu’on vient d’entrer.

Source exploitée :  https://www.linuxtricks.fr/wiki/reinitialiser-son-mot-de-passe-perdu

Windows 10 1803 – Problème d’écran noir-Comment le régler

Cette page ne s’inscrit pas dans la philosophie du site, qui propose surtout des expériences, mais vu l’ampleur du phénomène, je propose la traduction d’une solution possible.

Traduction du sujet faite par Alberto_c (forum cnet)

http://www.thecomputercellar.com/windows-10-1803-upgrade-issues-the-black-desktop-of-death-and-how-to-fix-it/

Merci à Alberto_c

Rappel de la situation

De nombreux utilisateurs de Windows 10 ont eu une surprise autour du 22 mai quand l’installation de la RS4 / 1803 (également appelée « Mise à jour d’avril 2018″) a obligé Windows à redémarrer.
On l’appelle « le bureau noir de la mort », « Rollback Loop », et d’autres choses, mais ce lien (https://www.reddit.com/r/Windows10/comments/8l5vim/the_latest_update_debacle_windows_10_1803_upgrade/) explique exhaustivement les symptômes : au mieux, vous allez vous retrouver avec un bureau vide, un arrière-plan noir et des messages d’erreur si vous essayez de faire quoi que ce soit.

Ce problème semble être dû à un problème avec des applications antivirus tierces (Avast, en particulier) provoquant l’échec de la mise à niveau de Windows 10 / 1803. Initialement, le seul recours pour ce problème était une réinstallation complète de l’OS, mais grâce au commentaire d’un utilisateur, quelques tests et affinements de notre part, nous sommes maintenant en mesure de présenter le guide suivant, sur la façon de résoudre le problème. Si c’est fait correctement, aucun fichier, donnée ou programme ne devrait être perdu.

ATTENTION : LIRE AVANT DE PROCEDER

Nous avons reçu des retours d’une petite minorité de personnes, y compris un technicien de service informatique, qui, malgré cette procédure soigneusement effectuée, ont perdu les données « l’utilisateur ».

Nous avons également rencontré ce problème nous-mêmes (heureusement une seule fois jusqu’à présent !). Gardez à l’esprit que vous suivez ces instructions à vos risques et périls et que nous ne pouvons garantir la sécurité de vos données.

Les images du déroulé de l’opération sont en bas de la page. Ce dont vous aurez besoin :

  • Clé USB vierge de 8 Go ou plus,
  • Un PC Windows fonctionnel à utiliser brièvement (un autre ordinateur dans votre maison, l’ordinateur d’un ami, même un dans une bibliothèque ou une imprimerie),
  • Environ une heure ou deux de temps libre.

Déroulement :

  1. Allumez l’ordinateur à problème.
  2. Sur l’écran bleu, choisissez la langue de votre disposition de clavier. [figure. 1]
  3. Choisissez « Utiliser un autre système d’exploitation ». [figure. 2]
  4. Choisissez la deuxième option, « Windows 10 sur le volume [x] » [fig. 3]
  5. Attendez que l’ordinateur démarre sur le bureau (si nécessaire, entrez votre mot de passe pour vous connecter). Vous devrez peut-être attendre longtemps avant que le bureau apparaisse, tandis que la « mise à jour » est prête.
  6. Une fois que le bureau tente de se charger, fermez le message d’erreur qui s’affiche.
  7. Sur un ordinateur fonctionnant sous Windows, accédez à www.microsoft.com/en-us/software-download/windows10.
  8. Cliquez sur « Télécharger l’outil maintenant ». Désactivez tout antivirus sur le PC fonctionnel avant de passer à l’étape n ° 9.
  9. Exécutez l’outil que vous avez téléchargé et suivez les étapes simples pour créer une clé USB d’installation de Windows 10. Cela effacera tout le contenu existant de votre clé USB ! La seule option à vérifier est de s’assurer qu’il s’agit d’une version 64 bits ou 32 bits. r
  10. Sur l’ordinateur qui pose problème, cliquez avec le bouton droit sur une zone vide de la barre des tâches (généralement la barre en bas de l’écran contenant le bouton Démarrer, certaines icônes de programme, Cortana et l’horloge), puis cliquez sur Gestionnaire de tâches.
  11. Cliquez sur « Plus de détails » pour que vous puissiez voir la barre de menu. [figure. 4]
  12. Cliquez sur « Fichier ».
  13. Cliquez sur « Exécuter une nouvelle tâche ». [figure. 5]
  14. Dans la boîte de dialogue qui apparaît, cochez la case « Créer cette tâche avec des privilèges administratifs ».
  15. Cliquez sur « Parcourir … »
  16. Accédez à votre clé USB et sélectionnez « setup.exe ».
  17. Exécutez le fichier et suivez les étapes pour « mettre à niveau » Windows. Changer l’option de « vérifier et télécharger les mises à jour » à « pas maintenant », et décochez « aider à améliorer cette installation de Windows ». Si on vous demande ce que vous voulez garder, assurez-vous de le dire pour tout garder !
  18. Laissez le processus s’exécuter, ce qui peut prendre du temps. Une fois terminé, l’ordinateur devrait être de retour à la normale et entièrement à jour. Vous devrez peut-être vous reconnecter à votre compte Microsoft.
  19. Bien qu’il ne soit pas nécessaire de supprimer votre logiciel antivirus tiers, nous vous recommandons de le supprimer de toute façon, étant donné qu’il a probablement causé le problème. Windows Defender est intégré à Windows 10, il est gratuit et convient parfaitement à la protection des consommateurs.

A considérer comme non testé par mes soins…. Il existe d’autres solutions, notamment sur le site de Malekal. Je ne propose pas de lien pour cause de publicité trop massive.

Démarrer W10 sur disque GPT en mode Legacy

Il est en principe impossible de faire démarrer Windows installé en UEFI en mode Legacy (ancien BIOS), pour la bonne raison qu’un démarrage cherche un disque au format MBR, sur lequel se trouve une partition active. Un disque GPT ne proposera jamais ce type de partition active, et donc, démarrer en mode Legacy peut sembler impossible.

Cependant, parfois Windows peut faire des siennes et ne plus vouloir démarrer en mode uefi. On tombe alors sur ce genre de message :

Raspberry Pi 2

En général, à ce stade, il est difficile de déterminer si le problème vient de Windows ou de la partition EFI qui sert au démarrage. Pourtant, il est possible de tester son Windows en mode Legacy pour savoir si celui-ci est responsable ou non.

1. Situation de départ.

On va partir d’un disque Windows sain, pour mieux expliquer le processus. En cas de Windows HS, on pourrait agir sans problème depuis un PC W7 (ou plus) et avec une clé USB.

On voit que sur ce PC sont installés deux disques durs. L’un au format GPT pour Windows, qui fonctionne en uefi. L’autre  non alloué, ce qui pourrait être une clé USB ou un disque dur interne.

depart

Nous allons nous occuper du disque 1 pour rendre ce disque bootable en Legacy (BIOS).

2. Préparation de la clé USB (ou disque interne)

On va donc initialiser ce disque en mbr et le formater en NTFS, comme on pourrait le faire avec n’importe clé USB.  Le résultat est le suivant :

format-ntfs

Dans mon cas, j’ai un petit souci, l’option « Marquer la active » est grisée. Je vais devoir l’activer en invite de commandes. Pas de difficulté :

Microsoft Windows [version 10.0.10240]
(c) 2015 Microsoft Corporation. Tous droits réservés.

C:\windows\system32>diskpart
Microsoft DiskPart version 10.0.10240

DISKPART> sel disk 1
Le disque 1 est maintenant le disque sélectionné.

DISKPART> sel part 1
La partition 1 est maintenant la partition sélectionnée.

DISKPART> active
DiskPart a indiqué la partition actuelle comme étant active.

DISKPART> exit
Quitte DiskPart...

Le résultat est le suivant :
active

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

Pour l’exemple, je les crée depuis mon Windows opérationnel, mais je pourrais très facilement les créer depuis la console de réparation. La commande est simple :

Microsoft Windows [version 10.0.10240]
(c) 2015 Microsoft Corporation. Tous droits réservés.

C:\windows\system32>bcdboot c:\windows /l fr-fr /s d: /f BIOS
Les fichiers de démarrage ont bien été créés.

Explication. On demande à bcdboot de créer les fichiers de démarrage en français sur le  volume système d, qu’on force en mode bios.

On peut voir via la commande dir /a que les fichiers sont bien créés.

C:\windows\system32>dir /a d:
  Répertoire de D:\

07/10/2017  09:35    <DIR>          Boot
10/07/2015  13:00           395 268 bootmgr
10/07/2015  13:00                 1 BOOTNXT
               2 fichier(s)          395 269 octets
               1 Rép(s)   1 028 993 024 octets libres

Nous allons même vérifier que le démarrage est opérationnel :

C:\windows\system32>bcdedit /store d:\boot\bcd

Gestionnaire de démarrage Windows
---------------------------------
identificateur          {bootmgr}
device                  partition=D:
description             Windows Boot Manager
locale                  fr-fr
inherit                 {globalsettings}
default                 {default}
resumeobject            {0de78277-ab32-11e7-9c51-000c29a6acae}
displayorder            {default}
toolsdisplayorder       {memdiag}
timeout                 30

Chargeur de démarrage Windows
-----------------------------
identificateur          {default}
device                  partition=C:
path                    \windows\system32\winload.exe
description             Windows 10
locale                  fr-fr
inherit                 {bootloadersettings}
allowedinmemorysettings 0x15000075
osdevice                partition=C:
systemroot              \windows
resumeobject            {0de78277-ab32-11e7-9c51-000c29a6acae}
nx                      OptIn
bootmenupolicy          Standard

C:\windows\system32>

Mon démarrage est bel et bien situé sur D et il pointe bien vers le disque C, sur lequel il va exécuter le fichier winload.exe. Tout est-il opérationnel pour que ça démarre en mode Legacy?

4. Essai en mode Legacy.

Le PC est basculé en mode Legacy, et Windows démarre sans problème en bootant sur le petit disque dur (ou clé usb) une fois qu’on l’a passé en tête de liste dans le bios.

essai

On peut vérifier avec msinfo32 qu’on démarre bien en mode hérité (Legacy) alors que le disque est toujours au format gpt :

preuve

 5. Conclusion

On peut vérifier le bon fonctionnement d’un Windows qui ne démarre plus en UEFI avec une petite clé USB de 512 Mo en la faisant booter en mode Legacy, même si l’installation est faite en UEFI.

Toutes les manipulations pour créer une clé bootable en Legacy auraient pu être faites depuis Dart ou autre outil contenant la console Winre.

 

 

 

 

 

 

 

 

 

Créer une clé USB de dépannage Refind ou Supergrub2 Disk

Assez fréquemment, on voit des sujets sur différents forums évoquant des systèmes qui ne démarrent plus, notamment parce que la partition EFI a été bricolée ou endommagée, notamment lorsqu’on a essayé d’installer un dual-boot entre Windows et une distribution Linux.

On peut alors tenter de faire démarrer ses systèmes avec des outils de secours. En uefi, il en existent deux qui sont efficaces : Supergrub2disk, et Refind. L’un comme l’autre sont prévus pour fonctionner sur CD-Rom, mais on peut les installer sur une clé USB bootable.

Avertissement. Les PC fonctionnant en mode Legacy ne pourront pas exploiter cette procédure. Seuls les PC en UEFI sont concernés.

I) Création de la clé USB bootable.

C’est la première chose à faire. On peut la réaliser de plusieurs manières. La plus fiable est de  rendre la clé bootable sous Windows avec diskpart. On lance l’invite de commandes en admin et on tape :

diskpart
list disk (on repère le n° de la clé, d'après la taille affichée)
select disk n (on remplace n par le n° de la clé)
clean (ici, on supprime tout, donc pas d'erreur)
create partition primary
format fs=fat32 quick
assign
active (pour la rendre bootable)
exit

A ce stade, on a une clé usb bootable avec rien dessus, mais qui est potentiellement capable de booter au démarrage d’un PC UEFI.

A noter qu’il est probable que Gparted soit parfaitement capable de faire la même chose. On crée une partition fat32 sur une clé USB, et on lui adjoint le drapeau boot (je ferai l’essai à l’occasion).

II) Ajout des fichiers REFIND

On se rend sur le site du concepteur de Refind :

Il nous propose toute une série de versions de son logiciel. On ne choisira pas la version USB mais la version CD-Rom.

Cette version contient un fichier refind-cd.xx.xx.iso qu’on peut facilement «ouvrir » avec Winrar, 7zip ou avec n’importe quel gestionnaire d’archives qu’on a sous la main. Ici, j’utilise le gestionnaire d’archives par défaut de Mint 18. On va simplement extraire les dossiers encadrés directement sur la clé USB (on peut sans doute se limiter à EFI et Refind, mais je ne m’embarrasse pas).

Refind1

On peut voir dans l’image qui suit que le créateur de Refind a pris soin d’insérer le dossier EFI nécessaire au démarrage de la clé USB. On y trouve le fichier bootx64.efi, indispensable au démarrage de notre clé de dépannage.

Refind2

Il ne reste plus qu’à la tester  : on insère la clé avant de mettre le PC en route. On règle son bios-UEFI pour démarrer dans ce mode (ou on utilise le menu de démarrage du constructeur). On choisit de booter sur la clé en UEFI.

boot

Elle va détecter les installations bootables en UEFI. Comme je n’en ai aucune (le PC fonctionne en Legacy), je n’ai pas d’entrée qui apparaisse, ce qui est somme toute assez normal.

Refindecran

III) Ajout des fichiers Supergrub2disk

Ici, je m’inspire de cet excellent travail de malbo, puisqu’il a réfléchi à la question bien avant moi.

On se rend sur le site de téléchargement du concepteur du logiciel (trouvé bêtement via une recherche sur Duckduckgo).

Une seule version étant proposée, à savoir un fichier ,super_grub2_disk_hybrid_2.02s9.iso on la télécharge. On vérifie son contenu en « ouvrant » l’iso avec le gestionnaire d’archives.

supergrub1

On copie le contenu sur la clé USB , le dossier [boot] excepté (on peut peut-être se limiter à Boot, mais là encore, je n’ai pas vérifié). On aboutit à ceci :

supergrub2

Il nous manque le dossier EFI qui va permettre de faire démarrer cette clé.

REM. J’ai tenté (avec succès) d’extraire le dossier EFI du fichier efi.img de Supergrubdisk pour l’ajouter à la racine, mais dans ce cas, le démarrage conduit à des erreurs. Donc, inutile de suivre cette voie.

Je pense que n’importe quel OS****  possédant ce fameux dossier pourrait convenir, mais nous allons utiliser l’iso de Linux Mint 18.

**** Eh bien non. Il faut utiliser un dossier EFI issu d’un Linux, car sinon, ça ne lance pas ce que l’on souhaite.

On ouvre l’image ISO de Linux Mint 18, et on constate que le dossier EFI est bien là :

supergrub3

On copie le dossier à la racine de la clé, ce qui donne le résultat suivant :

supergrub4

On a bien tous les fichiers nécessaires pour démarrer. Il ne reste plus qu’à lancer la clé USB en mode UEFI. Le programme se lance parfaitement, mais là encore, mon PC n’a pas grand-chose à faire booter dans ce mode.

supergrubecranOn constate néanmoins que Supergrub2 se lance parfaitement, tout comme Refind s’est lancé précédemment. On pourrait lancer un noyau Linux, et peut-être même, un Windows récalcitrant.

 

Réparer Windows après modification du path bootmgr pour dual boot Linux

Sur de nombreux tutoriels, on propose de contourner un blocage de l’installation de dual-boot en UEFI en modifiant le lancement de Windows, de la manière suivante :

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

ou encore, si le secure-boot est activé :

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

Cette commande, souvent proposée sur les PC HP ou Toshiba, dont le bios-uefi est bloqué sur le lancement de Windows, permet en effet de faire croire au PC qu’il démarre sur Windows, alors qu’il va lancer en réalité le lanceur de Linux.

Mais qu’en est-il si l’on supprime les partitions Ubuntu, sans prendre de précaution ?

I. Situation initiale : suppression des partitions Linux

Une image étant préférable à un long discours, voilà une capture d’écran d’un dual-boot dont les partitions ont été modifiées :

Modif-Ws

On constate que les partitions Linux viennent d’être supprimées, mais que la modification de {bootmgr} est toujours opérationnelle. On va laisser les choses en l’état afin de voir quelles sont les conséquences. Il suffit de redémarrer le PC. Le résultat est le suivant :
gruboff

En toute logique, Grub ne trouvant plus les fichiers Linux, il renvoie un message d’erreur. Notre PC ne boote plus. Vérifions le bios-uefi :

ordre-bios

Windows boot manager est bien proposé, mais il ne fonctionne visiblement plus. Et aucune entrée Ubuntu n’apparaît pour modifier les choses.

II. Les réparations possibles

 1. La commande bcdboot

C’est la méthode « classique ». On va vérifier ce qu’elle est capable de faire dans une telle situation. On doit, dans ce premier cas, faire démarrer le PC sur le DVD d’installation (ou la console de réparation) et choisir l’option « réparer l’ordinateur ». On sélectionne les « options avancées, puis l’invite de commandes ». On tape la commande suivante :

bcdboot n:\windows /l fr-fr

La lettre N est à adapter. On voit sur l’image ci-dessous que mon démarrage pointe toujours vers Grub, et que mon Windows est sur le volume D. J’ai donc remplacé N par D.

bcdboot

On va vérifier le résultat via la commande bcdedit /v : le démarrage a bien été modifié, de même que le path de {bootmgr} :

bcdboot-result

Le PC doit redémarrer normalement, et en effet :

redemarrage

 2. La commande bcdedit

Comme dans le précédent exemple, il va falloir utilise le DVD d’installation ou la console de réparation. Mais cette fois, on va modifier directement le path de {bootmgr} :

bcdedit2

On voit le résultat. La ligne path est modifiée, et on pointe bien vers le fichier bootmgfw.efi. Le résultat est identique : redémarrage sans problème.

redemarrage

 3. Le bios-uefi.

On peut également, si le bios le permet, modifier le chemin vers lequel l’entrée « Windows Boot Manager » est dirigée. Sous VMware, c’est assez facile :

biso

L’image se suffit à elle-même. On va chercher le fichier dans son dossier pour permettre à l’entrée sélectionnée de booter correctement. Les bios étant spécifiques à chaque marque, ce dernier moyen n’est donné que pour information.