Discussion :

[JP.NUAGE]

Bonjour à tous et meilleurs vœux pour la nouvelle année !
Un problème certainement tout simple (ce sont ceux qui sont les plus casse-pieds) : je viens de récupérer un ordi avec Windows 11 . J'ai installé Ubuntu en bi-partition. l'installation se déroule sans aucun message d'erreur, donc je pense que tout va pour le mieux dans le meilleur des mondes. Je retire la clé qui m'a servi à installer, je redémarre l'ordi et .... j'arrive sur Windows ! Horreur et damnation ! Je n'ai pas trouvé comment activer en priorité la partition Linux !
Bête n'est-il pas ?
Un petit coup de pousse serait le bien venu !
d'avance

[N_BaH]

Bonjour,

tu as GrUB, ou c'est le bootloader de W$ qui prend la main ?
si ce n'est pas GrUB, redémarre sur un liveUSB et réinstalle GrUB, au début du disque, pas sur une partition.

[JP.NUAGE]

Bonjour N_BaH

Tu as mis le doigt sur le problème. j'ai effectivement remarqué que je n'avais pas Grub. d'ailleurs, bien que l'installation me prévienne que je pourrai choisir la partition contenant le programme d'amorçage, je n'ai rien vu.
J'ai donc relancé l'installation en option essai, puis dans un terminal la commande sudo os-prober qui m'a affiché ceci

sudo os-prober
/dev/sda1@/Micrsoft/Boot/bootmgfw.efi:Windows Boot Manager:Windows:efi
/dev/sda5/Ubuntu 20.04.6 LTS (20.04=:Ubuntu:linux)

Je suis loin d'être un as des commandes Linux, tout au plus une reste de bougie. Donc là je suis planté.
Ce que je crois comprendre est qu'il n'y a pas de GRUB installé.
Mais que faire, malgré une recherche sur l'aide en ligne d'Ubuntu je patoge
Une aide serait la bien venue
d'avance

[N_BaH]

pourtant, le wiki ubuntu donne des instructions très simples :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
sudo os-prober
sudo update-grub
sudo grub-install /dev/sd_

bien sûr, tu dois adapter /dev/sd_ à ta configuration matérielle.

nb: je ne suis pas sûr de l'utilité des deux premières comandes dans ton cas.

[JP.NUAGE]

C'est exact : j'avais trouvé cette séquence de ligne de commande, mais elle plante. Je lance sudo update-grub et je reçois :

user/sbin/grub-prober : error: failed to get canonical path of /cow

plutôt "vache" comme message !
j'ai essayé d'ignorer cet ordre et de lancer le suivant. Je suis parti dans un flot d'erreurs me disant que plein de répertoires n'existaient pas !
J'ai bien essayé de créer ces répertoires, mais au final, je retombe sur le premier message et je ne peux pas aller plus loin. Impossible de créer /cow (il doit manquer un taureau )

[N_BaH]

bien sûr. je n'ai pas pensé qu'il faut exécuter ces commandes sur le système "en panne", pas sur le système du liveUSB.

cherche « ubuntu chroot to fix GrUB », tu vas trouver une recette pour monter un chroot et réparer/installer GrUB

[Christophe]

Essayes grub-repair. Ca devrait t'éviter de devoir te chrooter dans le système KO.

[gabriel21]

En partant du principe que la partition root est monté dans /mnt. Sinon, il faut adapter les commandes au point de montage.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
sudo su -
mount --bind /dev /mnt/dev
mount --bind /dev/pts /mnt/dev/pts
mount --bind /sys /mnt/sys
mount -t proc /proc /mnt/proc
chroot /mnt /bin/bash
 
os-prober
update-grub
grub-install /dev/sda // en fonction du nom du disque
 
umount /mnt/{dev/pts,dev,sys,proc}
 umount /mnt
 reboot now

En dual boot, je conseille toujours d'utiliser os-prober avant un update-grub. J'ai déjà eu le coup que grub oublie les autres OS. La commande n'est pas très longue.

Si cela ne fonctionne pas, il faudra aller voir les options de boot EUFI qui peuvent forcer le démarrage sur OS précis ( en fonction des modèles)

[Christophe]

Pour l'UEFI, grub-install suffit mais il faut monter la partion ESP dans /boot/efi.

grub-repair se débrouille pour tout ça.

[gabriel21]

Pas toujours, notamment si l'UEFI est protégé par mot de passe.
J'ai eu des cas, où cela ne fonctionnait pas. Et j'ai même un PC (ASUS de plus de 10 ans) qui nécessite la manœuvre dans l'UEFI à chaque mise à jour de grub : par contre, l'UEFI me demande automatiquement de confirmer que je veux bien démarrer sur cette partition et que le système a été altéré depuis le dernier démarrage.

[fred1599]

Hello,

En partant du principe que la partition root est monté dans /mnt.

Vous pouvez être plus précis, je pense que le PO ne sait pas faire, et sur les infos qu'il vous donne, vous avez ce qu'il faut...

Il est impératif de monter la partition EFI au bon endroit dans l'arborescence montée comme mentionné par @Christophe, mais là aussi on a les données nécessaires pour être plus précis

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

grub-install /dev/sda // en fonction du nom du disque

Le commentaire est inutile, relisez les informations du PO... ce qui nous intéresse c'est l'emplacement du disque principal, /dev/sda suffit.

je conseille toujours d'utiliser os-prober avant un update-grub.

Pourquoi ? update-grub va le faire, non ?

Essayes grub-repair. Ca devrait t'éviter de devoir te chrooter dans le système KO.

Non absolument pas, la méthode Chroot est supérieure aux outils automatisés car elle utilise les paquets et configurations exacts du système installé, garantissant une compatibilité totale.

@JP.NUAGE

Êtes vous bloqué ? Je ne serai pas étonné, vous avez des difficultés avec les commandes (comme vous le précisez si bien plus haut) et n'avez pas les commandes exactes pour résoudre votre problème.
Il n'y a pas de questions bêtes...

[Christophe]

Essayes grub-repair. Ca devrait t'éviter de devoir te chrooter dans le système KO.
Non absolument pas, la méthode Chroot est supérieure aux outils automatisés car elle utilise les paquets et configurations exacts du système installé, garantissant une compatibilité totale.

J'ai bien dit devrait pas va.

Effectivement, ça ne marchera pas dans 100% des cas, mais je pense que c'est la 1ère étape à réaliser par un néophyte car plus simple, avec de fortes chances de réussite.

Le commentaire est inutile, relisez les informations du PO... ce qui nous intéresse c'est l'emplacement du disque principal, /dev/sda suffit.

le paramètre /dev/sda, c'est pour GRUB en mode non UEFI. Mais il a de forte chance qu'il n'en tienne tout simplement pas compte en mode UEFI plutôt que mettre une erreur (pas sûr, faudrait que je teste).

[gabriel21]

Le commentaire est inutile, relisez les informations du PO... ce qui nous intéresse c'est l'emplacement du disque principal, /dev/sda suffit.

Si ce que tu dis est vrai, la communauté ne serait pas embêter avec les UUID. Avec les Livecd, on peut avoir des surprises dans la détection. Si tu n'en as jamais eu, tant mieux pour toi.

@Christophe : tu as parfaitement raison, mais je n'ai jamais eu d'erreur avec le mode UEFI et j'ai laissé mes documentations personnelles avec.

Pourquoi ? update-grub va le faire, non ?

Pas garanti, même si pour un certain nombre de distribution, cela va être de base. Mais, je ne vais pas y mettre ma main au feu. Surtout que je n'ai jamais eu le problème qu'il signale et j'ai plus d'une 50ene d'installation de dualboot W10/11 avec Kubuntu. La détection de la configuration matériel et l'installation du grub a toujours fonctionné. A moins qu'il n'ait pas validé l'installation de grub lors de la demande de configuration du boot.

De plus, si le problème vient de la détection, et que la commande renvoie un retour sans le W11 et le linux (déjà vu, mais pas avec Ubuntu), il n'aura pas la surprise d'avoir un grub vide s'il y a un problème avec le Linux. Bien sûr dans ce cas là, réinstaller le Linux est probablement la meilleur chose à faire.

Vous pouvez être plus précis, je pense que le PO ne sait pas faire, et sur les infos qu'il vous donne, vous avez ce qu'il faut...

Dans ce cas, une réinstallation sera sûrement plus rapide pour lui. Mais il peut aussi nous poser directement la question. Je ne pars pas du principe qu'il ne sait rien et je serai ravi de lui donner un coup de main (mais rarement en week end). Et je maintiens que si udev décide de l'appeler sdb ou sdc, il ne sera pas plus quoi faire et pire, s'il y a un périphérique qui porte ce nom (sda), le fait de recopier sans comprendre les commandes pourra avoir des effets de bord.

Sinon,
Lister les différents disques avec les partitions et les informations utiles concernant les systèmes de fichier :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

lsblk -fs

Monter la partition une fois qu'elle a été bien identifiée ( en théorie, c''est une ext4) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

sudo mount /dev/nom_partition /mnt

vérifier le contenu de la partition montée :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

sudo ls /mnt

Si tu n'as pas un retour avec au moins les répertoires dev, proc, root, home :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

umount /mnt

Recommencer avec une autre partition ext4

Sinon suivre la procédure précédente

[disedorgue]

Depuis le 27/12, y avait largement le temps d'essayer de réinstaller le système...

[fred1599]

Si ce que tu dis est vrai, la communauté ne serait pas embêter avec les UUID. Avec les Livecd, on peut avoir des surprises dans la détection. Si tu n'en as jamais eu, tant mieux pour toi.

Ce qu'indique le PO :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

sudo os-prober /dev/sda1@/Micrsoft/Boot/bootmgfw.efi:Windows Boot Manager:Windows:efi /dev/sda5/Ubuntu 20.04.6 LTS (20.04=:Ubuntu:linux)

/dev/sda est identifié comme le disque contenant Windows (partition 1) et Ubuntu (partition 5).

Mais c'est sûr qu'après redémarrage du live CD il faudra vérifier cette information.

Pas garanti, même si pour un certain nombre de distribution, cela va être de base. Mais, je ne vais pas y mettre ma main au feu. Surtout que je n'ai jamais eu le problème qu'il signale et j'ai plus d'une 50ene d'installation de dualboot W10/11 avec Kubuntu. La détection de la configuration matériel et l'installation du grub a toujours fonctionné. A moins qu'il n'ait pas validé l'installation de grub lors de la demande de configuration du boot.

De plus, si le problème vient de la détection, et que la commande renvoie un retour sans le W11 et le linux (déjà vu, mais pas avec Ubuntu), il n'aura pas la surprise d'avoir un grub vide s'il y a un problème avec le Linux. Bien sûr dans ce cas là, réinstaller le Linux est probablement la meilleur chose à faire.

On parle ici de la version 20.04, l'écosystème s'appuyait généralement sur des versions de GRUB antérieures à la 2.06 (souvent la branche 2.04 patchée). La philosophie prédominante était celle de la facilité d'usage pour les configurations de bureau.

Dans ce contexte, le mécanisme de détection des OS tiers (os-prober) était considéré comme une fonctionnalité essentielle activée par défaut. Lorsqu'un administrateur ou un processus de mise à jour du noyau invoquait la commande de régénération de configuration, le système scannait proactivement tous les périphériques de bloc connectés. Si une signature Windows (via le gestionnaire de démarrage Windows Boot Manager dans l'ESP - EFI System Partition) ou une autre distribution Linux était détectée, une entrée de menu était automatiquement ajoutée au fichier grub.cfg.

La variable GRUB_DISABLE_OS_PROBER n'était, dans la majorité des configurations par défaut de la 20.04, ni définie ni documentée comme un mécanisme de blocage actif. Son absence impliquait une valeur false (faux), autorisant l'exécution sans entrave du script de détection.

Mais il peut aussi nous poser directement la question.

Il y a deux cas, soit il pose cette question, soit il abandonne car trop complexe pour lui, et dans ce cas, beaucoup d'énergies dépensées pour pas grand chose.
Il y a vraiment un intérêt d'exprimer une réponse coïncidant avec l'environnement du PO et prenant en compte les détails dont on a eu la chance qu'il partage afin de là rendre là plus précise possible.