Dual boot, choisir l'OS par defaut

Tags: #<Tag:0x00007f63f4e0d210> #<Tag:0x00007f63f4e0d120>

Bonjour,

J’ai cherché un long moment une solution à mon problème et je croule sous la quantité d’informations peut-être utiles, ou peut-être pas, je suis vraiment perdu.

Ma situation :

Je viens d’installer Debian en dual boot de cette manière :

  • Windows 10 installé par défaut sur mon ssd (HD0)
  • Debian 10 fraîchement installé sur une partition de mon hdd (HD1)

Au démarrage de l’ordinateur, en appuyant sur F10 j’accède sans soucis au menu de démarrage dans lequel je peu choisir de lancer soit Windows, soit Debian. Mais si je n’appuie pas sur cette touche, je boot automatiquement sous Windows.

La version de mon Bios : ACRSYS - 1 V1.07 INSYDE Corp. - 10000001

Mon objectif :

Booter automatiquement sous Debian quand je presse le bouton power. Je veux donc changer l’OS par défaut au démarrage.

Ce que j’ai déjà essayé :

1) Dans le Bios

Les priorités de boot sont configurées comme suit :

  • boot from CD
  • boot from USB
  • boot from HD1
  • boot from HD0
  • Network

Malheureusement, cette manipulation ne change rien et je boot toujours sur Windows qui est installé sur HD0.

De plus, le menu de boot est très minimaliste et je n’ai pas la fonctionnalité Set Default OS.

2) Configurer le Grub

J’ai essayé de reconfigurer le Grub via l’utilitaire StartupManager sous Debian. Mais le système par défaut était déjà reglé sur “Debian”.

J’essaye de m’approprier l’environnement Linux depuis peu et je ne suis pas encore très à l’aise. Merci par avance pour le temps que vous voudrez bien consacrer à ce post ! :slight_smile:

Un utilisateur qui en a marre de bouriner F10.

Comment choisis-tu ? Que sélectionnes-tu dans le menu de démarrage pour lancer Windows ou Debian ?

Un peu d’info sur la configuration :

fdisk -l
efibootmgr -v
ls /boot/grub

NOTE : Mon Linux est la distribution Parrot 3.8 basé sur Debian 10, et j’ai rencontré le même problème avec toutes les distributions Linux que j’ai utilisé auparavant.

Mes partitions :

    ┌─[samus@parrot]─[~]
    └──╼ $sudo fdisk -l
    [sudo] password for samus: 
    Disk /dev/sda: 119.2 GiB, 128035676160 bytes, 250069680 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 byte / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disklabel type: gpt
    Disk identifier: 33FC7424-0DFC-433C-9DA9-D11DF5F09E1D

    Device         Start       End   Sectors  Size Type
    /dev/sda1       2048   1230847   1228800  600M Windows recovery environment
    /dev/sda2    1230848   1435647    204800  100M EFI System
    /dev/sda3    1435648   1697791    262144  128M Microsoft reserved
    /dev/sda4    1697792 249145343 247447552  118G Microsoft basic data
    /dev/sda5  249147392 250068991    921600  450M Windows recovery environment


    Disk /dev/sdb: 465.8 GiB, 500107862016 bytes, 976773168 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes
    Disklabel type: gpt
    Disk identifier: 3693BA1C-6C67-45D4-A144-F0F1FF6AFF3A

    Device         Start       End   Sectors   Size Type
    /dev/sdb1       2048 837978111 837976064 399.6G Microsoft basic data
    /dev/sdb2  837978112 838563839    585728   286M EFI System
    /dev/sdb3  942835712 976773119  33937408  16.2G Windows recovery environment
    /dev/sdb4  838563840 909438975  70875136  33.8G Linux filesystem
    /dev/sdb5  909438976 942835711  33396736  15.9G Linux swap

    Partition table entries are not in disk order.

Mon boot :

┌─[samus@parrot]─[~]
└──╼ $sudo efibootmgr -v
BootCurrent: 0009
Timeout: 0 seconds
BootOrder: 0000,0009,2001,2002,2003
Boot0000* Windows Boot Manager	HD(2,GPT,144a3368-6e88-4a1f-8039-4b3d90ce37f0,0x12c800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................
Boot0001* BRCM MBA Slot 0800 v16.2.1	BBS(128,,0x500)................b...........G..........................................
Boot0002* MATSHITADVD-RAM UJ8E2Q          	BBS(CDROM,,0x500)................-...........A......#..............................=-........A.........................
Boot0003* LITEON IT L8T-128L9G            	BBS(HD,,0x500)................-...........A......B..............................2-........A.........................
Boot0004* WDC WD5000LPVX-22V0TT0          	BBS(PCMCIA,,0x500)................-...........A......R..............................)-........A.........................
Boot0005* USB     USB Flash Disk  	BBS(Network,,0x500)............................................................................A...........................
Boot0006* WDC WD5000LPVX-22V0TT0          	BBS(PCMCIA,,0x500)................-...........A......R..............................)-........A.........................
Boot0007* Lexar   USB Flash Drive 	BBS(Network,,0x500)............................................................................A...........................
Boot0008* PKparis PK K'1          	BBS(Network,,0x500)............................................................................A...........................
Boot0009* parrot	HD(2,GPT,e390db02-32bc-4049-a49d-9decc110d59d,0x31f28800,0x8f000)/File(\EFI\parrot\grubx64.efi)
Boot2001* EFI USB Device	RC
Boot2002* EFI DVD/CDROM	RC
Boot2003* EFI Network	RC

Mon fichier /boot/grub:

┌─[samus@parrot]─[~]
└──╼ $ls /boot/grub
default  device.map  fonts  grub.cfg  grubenv  locale  menu.lst  menu.lst~  unicode.pf2  x86_64-efi

Mon menu de boot:

Donc démarrage en mode EFI pour les deux OS.
Il y a bien une entrée d’amorçage pour Parrot mais Windows est en premier dans l’ordre d’amorçage (BootOrder).

Il n’y a pas dans les options du firmware UEFI (ex-BIOS) une page où on peut modifier l’ordre de démarrage des entrées EFI Windows Boot Manager et parrot ?

Sinon, tu peux essayer de modifier l’ordre avec efibootmgr :

efibootmgr -o 0009,0000,2001,2002,2003

Non, pas ce genre d’option dans l’UEFI, très minimaliste.

A l’éxecution de la commande efibootmgr -o 0009,0000,2001,2002,2003 la console répond :
Could not set BootOrder : No space left on device

salut
dans /etc/default/grub
avec les options suivantes on affiche le menu grub avec la premiere entrée par défaut et on laisse 5 secondes à l’utilisateur pour changer de ligne

GRUB_DEFAULT=0
GRUB_TIMEOUT=5

NB commenter les lignes GRUB_HIDDEN

Après modifications faire
sudo update-grub

comme indiqué dans le fichier pour avoir la description des options

info -f grub -n 'Simple configuration'

@grandtoubab
Le problème n’est pas la priorité dans le menu de GRUB mais la priorité entre Windows Boot Manager et GRUB dans le firmware UEFI.

@samus
J’ai aussi rencontré cette erreur avec mon unique et assez ancienne carte mère UEFI. L’espace dont il est question est une mémoire non volatile (NVRAM) appartenant au firmware UEFI et lui servant à stocker des informations de configuration comme l’amorçage.
Ce problème est connu et j’ai lu tout ce que j’ai pu trouver à ce sujet, mais aucune des rares solutions proposées comme vider le contenu de /sys/fs/pstore/ n’était applicable à mon cas (déjà vide). La seule solution qui fonctionnait (pas à tous les coups et toujours temporairement), c’était de désactiver l’amorçage en mode EFI dans les options du firmware UEFI, ce qui avait aussi pour effet secondaire de supprimer des entrées d’amorçage EFI.

ok
j’ai conservé la trace de cette bidouille
https://forum.ubuntu-fr.org/viewtopic.php?pid=21468818#p21468818
Shimx64 défini précédemment, le faire remonter de la neuvième place à la première avec la touche F6

ça a l’air de correspondre
Boot0009* parrot
je n’ai jamais pratiqué mais au cas ou ça serait adaptable

D’après @samus, l’interface de configuration de son firmware UEFI ne permet hélas pas de gérer l’ordre de priorité des entrées d’amorçage.

peut être bien mais une grande partie de l’astuce consiste a définir un mot de passe pour accéder à certaines fonctions du bios

il y en a qui proposent de le faire sous Windows en mode administrateur avec la commande
bcdedit /set {bootmgr} path \le-chemin-du-boot-que-tu-veux

https://technet.microsoft.com/en-us/library/dn336950.aspx

Et si le grub était installé sur mon SSD, est-ce que ça pourrait résoudre le problème ?

Ou alors je désinstalle tout et je réinstalle windows puis debian tout les deux sur le ssd ? J’aimerais bien ne pas avoir à en arriver là.

Est-ce qu’il est envisageable de flashé un bios qui me propose de choisir l’os par défaut dans le menu de boot ? Pareil, je n’aime pas trop cette idée.

Normalement non. Contrairement à l’amorçage BIOS, la priorité des entrées d’amorçage EFI ne dépend pas du périphérique mais de leur ordre dans la variable BootOrder.

Concernant l’utilisation de bcdedit, je suis réservé car d’après ce que j’ai vu ailleurs, son mode d’action semble consister à modifier l’entrée d’amorçage EFI de Windows Boot Manager pour remplacer le chemin de l’exécutable normal \EFI\Microsoft\Boot\bootmgfw.efi par celui passé dans la commande. Je crains donc que le problème rencontré avec efibootmgrempêche toute modification des variables de boot EFI.

Tu as regardé dans /sys/fs/pstore pour voir s’il y avait du ménage à faire ?

Voilà ce qui se trouve dans mon dossier pstore :

┌─[samus@parrot]─[/sys/fs/pstore]
└──╼ $ls
dmesg-efi-148216270801001  dmesg-efi-148216271212001  dmesg-efi-148219085306001
dmesg-efi-148216271201002  dmesg-efi-148216271212002  dmesg-efi-148219085306002
dmesg-efi-148216271202001  dmesg-efi-148216271213001  dmesg-efi-148219085307001
dmesg-efi-148216271202002  dmesg-efi-148216271213002  dmesg-efi-148219085307002
dmesg-efi-148216271203001  dmesg-efi-148216271214001  dmesg-efi-148219085308001
dmesg-efi-148216271203002  dmesg-efi-148216271214002  dmesg-efi-148219085308002
dmesg-efi-148216271204001  dmesg-efi-148216271215001  dmesg-efi-148219085309001
dmesg-efi-148216271204002  dmesg-efi-148216271215002  dmesg-efi-148219085309002
dmesg-efi-148216271205001  dmesg-efi-148216271216001  dmesg-efi-148219085310001
dmesg-efi-148216271205002  dmesg-efi-148216271216002  dmesg-efi-148219085310002
dmesg-efi-148216271206001  dmesg-efi-148216271217001  dmesg-efi-148219085311001
dmesg-efi-148216271206002  dmesg-efi-148216271217002  dmesg-efi-148219085311002
dmesg-efi-148216271207001  dmesg-efi-148219085301001  dmesg-efi-148219085312001
dmesg-efi-148216271207002  dmesg-efi-148219085301002  dmesg-efi-148219085312002
dmesg-efi-148216271208001  dmesg-efi-148219085302001  dmesg-efi-148219085313001
dmesg-efi-148216271208002  dmesg-efi-148219085302002  dmesg-efi-148219085313002
dmesg-efi-148216271209001  dmesg-efi-148219085303001  dmesg-efi-148219085314001
dmesg-efi-148216271209002  dmesg-efi-148219085303002  dmesg-efi-148219085314002
dmesg-efi-148216271210001  dmesg-efi-148219085304001  dmesg-efi-148219098705001
dmesg-efi-148216271210002  dmesg-efi-148219085304002  dmesg-efi-148219113801001
dmesg-efi-148216271211001  dmesg-efi-148219085305001
dmesg-efi-148216271211002  dmesg-efi-148219085305002

Je ne sais pas à quoi correspondent exactement ces fichiers, et ce que leur suppression implique.

D’après le nom “dmesg”, ce seraient des logs du noyau comme ceux qu’affiche la commande dmesg.
Tu peux en afficher un pour voir ce qu’il contient.
A priori on peut les supprimer. D’ailleurs ils ne sont pas censés être conservés longtemps d’après la description dans la documentation du noyau :

Once the information in a file has been read, removing
the file will signal to the underlying persistent storage
device that it can reclaim the space for later re-use.

The expectation is that all files in /dev/pstore
will be saved elsewhere and erased from persistent store
soon after boot to free up space ready for the next
catastrophe.

Note : le point de montage peut être différent, /dev/pstore dans cette documentation et /sys/fs/pstore dans le système Debian.

Sur ma machine, le répertoire est toujours vide donc je n’ai pas pu tester.