[Résolu] Problème grub avec /boot séparé puis mode UEFI/Legacy

Eric Bl · Le 16/11/2018, à 10:07

Bonjour,

En vrai, ce problème, je ne l'ai pas et l'objectif de cette discussion est précisément qu'il n'arrive pas. Car j'ai la hantise de rester bloqué sans ordinateur et sans réponse pendant 12 jours (ce qui est le cas de la première version de ce message).

J'ai une partition boot séparée. Je m'apprête à installer Kubuntu 18.04 en dual boot avec Kubuntu 16.04.
J'ai décrit ma configuration et demandé des conseils ici : projet dual boot

Je suis préoccupé par une discussion sur le forum qui laisse craindre les pires effets d'un boot partagé : Catastrophe probable si /boot partagée entre systèmes.

Est-ce que ces menaces s'appliquent à ma configuration ou pas ? Est-ce que /boot/efi diffère de /boot ? Est-ce que ma nouvelle version aura son boot propre qui me protégera de ce problème ? Comment réintégrer éventuellement le boot de ma version actuelle dans sa partition ? Voilà des exemples de questions auxquelles je suis incapable de répondre.

C'est pourquoi j'ai besoin, avant de me lancer, d'être sûr que quelqu'un s'intéresse à la question et est en mesure de m'aider.

Et si ce quelqu'un ou un autre pouvait valider la démarche envisagée pour mon installation de deux versions en parallèle, ça me rassurerait aussi.

Merci d'avance.

Dernière modification par Eric Bl (Le 22/11/2018, à 13:31)

erresse · Le 16/11/2018, à 12:30

Bonjour,
Pour que la version 18.04 soit installée sans souci, concernant le "boot", il te suffira de ne surtout RIEN faire, c'est à dire NE PAS assigner le volume "/boot" lors de l'installation, afin que ce répertoire fasse simplement partie de la racine 18.04 et non d'un volume séparé.
En revanche, pour les données personnelles, il convient de ne pas oublier d'assigner le(s) volume(s) utilisé(s) lors de l'installation pour pouvoir tout retrouver dès le démarrage de la novelle version.
Note: Personnellement, je recommande de séparer les données personnelles du reste de l'installation, mais PAS de créer un "/home" séparé. Ceci pour la bonne raison que le "/home" contient, outre les données personnelles des utilisateurs, une quantité de fichiers de paramétrage du système qui ne sont absolument pas gérés par l'utilisateur, même s'il s'agit de paramètres de personnalisation des logiciels applicatifs.
Il suffit de disposer d'un ou plusieurs volumes de données personnelles, dans lesquels on déportera les répertoire standard (Documents, Images, Musique, etc.) contenant les vraies données de l'utilisateur, ces répertoires étant alors remplacés dans $HOME par des liens symboliques vers leurs homologues du ou des volumes déportés.

Nasman · Le 16/11/2018, à 14:55

Ne pas oublier le dossier .thunderbird qui peut contenir les mail - plus critique en mode pop

erresse · Le 16/11/2018, à 15:18

Nasman a écrit :

Ne pas oublier le dossier .thunderbird qui peut contenir les mail - plus critique en mode pop

Exact !
Les profils de Firefox et Thunderbird sont aussi à déplacer vers les volumes de données personnelles, au même titre que les répertoires "standard", du fait qu'ils contiennent de vraies données personnelles (courriels, contacts, marques-pages, etc.).
En règle générale, on déportera sur ces volumes tout ce qui peut constituer des données personnelles, sans lien avec le système dans lequel elles sont enregistrées...

Dernière modification par erresse (Le 16/11/2018, à 15:19)

Eric Bl · Le 16/11/2018, à 18:19

Merci à vous.

Existe-t-il une présentation qui explique comment créer précisément des volumes de données personnelles.
Est-ce que volume = partition ?
Est-ce alors la même solution que celle que préconise eric63 dans la discussion sur mon installation à 2 versions : ici

erresse · Le 16/11/2018, à 18:42

Un "volume", c'est en fait un "système de fichiers" que le système peut "monter" sur un point de montage afin de donner accès à son contenu.
Un disque ou une partition d'un disque n'est qu'un conteneur dans lequel on installe un système de fichiers d'un format particulier (EXT4 ou NTFS, par exemple).
On parle souvent improprement de "monter un disque" ou "monter une partition"... C'est faux, on ne peut monter qu'un système de fichiers (aussi appelé volume, c'est plus pratique et plus court).
Un disque (périphérique) sera désigné par exemple par "/dev/sda" et une partition sur ce disque sera "/dev/sda1", mais il faudra formater ce disque ou cette partition pour en faire un volume qu'on pourra alors monter sur le point de montage de l'arborescence afin de permettre l'accès aux données contenues.

Eric Bl · Le 17/11/2018, à 17:09

Il y avait ma demande d'assistance pour une installation d'une nouvelle version en parallèle avec l'ancienne.

Il y avait ma tentative de précaution contre un problème grub.

Mais après 15 jours à ronger mon frein, je n'ai pas réussi à tenir jusqu'à avoir une réponse satisfaisante à la non-reconnaissance de la nouvelle version par grub.

Le temps d'avarie limitée est terminé : ça ne démarre carrément plus.

Eric Bl · Le 17/11/2018, à 19:13

On y est Grub planté

erresse · Le 17/11/2018, à 19:27

Mais en fin de compte, qu'as-tu fait exactement pour en arriver là ?
Donne quand même quelques informations, on ne peut pas le deviner !
Note : Il n'était pas nécessaire d'ouvrir une nouvelle discussion, celle-ci continue, inutile de s'éparpiller...

jamesbad000 · Le 17/11/2018, à 19:28

Bonjour,

Peux tu fournir un rapport boot info à l'aide d'un live cd boot repair. Et surtout ne pas faire de tentative de réparation !

cqfd93 · Le 17/11/2018, à 19:51

Modération

Bonjour,

erresse a écrit :

Note : Il n'était pas nécessaire d'ouvrir une nouvelle discussion, celle-ci continue, inutile de s'éparpiller...

C'est bien mon avis. Allez hop, on fusionne. C'était même le troisième sujet ouvert pour le même problème…

Eric Bl · Le 17/11/2018, à 20:57

J'ai fait la clé Boot-repair.
J'ai lancé et ça m'a ouvert directement un menu grub avec mes noyaux 16.04 mais sans la 18.04
Du coup, j'ai fait le nouveau boot-info depuis la 16.04 :
Boot info

Les seules opérations que j'ai faites consciemment entre
- grub fonctionne mais ne me propose que la 16.04
- et grub ne fonctionne plus
c'est
- changer les étiquettes des partitions Kubuntu 16.04 et Kubuntu 18.04
- lancer une réparation du boot.

Merci à vous

Dernière modification par Eric Bl (Le 21/11/2018, à 19:21)

jamesbad000 · Le 17/11/2018, à 22:11

Ce n'est pas clair.
Ton installation semble faite pour un bios en mode UEFI. Et ta session live cd est démarré en mode legacy, ce qui laisse supposer que tu as changé ton mode de démarrage dans le bios.

Mais il y a un boot legacy bancal, qui semble fonctionnel sur ton disque malgré l'absence de partition bios boot (Cette dernière a probablement été supprimée, mais le core.img est toujours accessible. Mais ce n'est pas viable sur le long terme)

En conséquence je soupçonne que les 2 ubuntu sont installés pour des modes différents.
Je conseille dans un premier temps de faire un coup de

sudo update-grub

à partir de la 16.04 puisque tu es dedans. Afin de mettre à jour le menu grub de la 16.04 (qui va ainsi prendre en compte l'existence de la 18.04 en installation secondaire)
Et vérifier que tu accède bien à la 18.04 à partir du menu mis à jour.

Ensuite tenter de passer le bios en mode UEFI et voir si tu accède au menu grub géré par la 18.04 (Cette dernière sera donc en installation principale et la 16.04 en secondaire puisque détectée lors de l'installation de la 18.04)

Dernière modification par jamesbad000 (Le 17/11/2018, à 23:10)

Eric Bl · Le 17/11/2018, à 23:56

A moins d'autres suggestions, j'essaierai demain l'update-grub.

Mais ce que je peux dire déjà c'est que personnellement je n'ai jamais voulu changer mon mode de démarrage, que j'ignore d'ailleurs comment on fait ça, et que j'ignore également ce que peut vouloir dire "démarrer la session live cd en mode legacy".

Donc mes actions volontaires se sont limitées à :
1 démarrer une session live à partir de la clé usb de la 18.04
2 faire l'installation depuis le bureau live, en installant dans une nouvelle partition
3 constater que l'ordi ne démarrait pas en 18.04, ni ne proposait ce démarrage
4 lancer l'application système de réparation du démarrage sans effet perceptible
5 renommer mes partitions 16.04 et 18.04
6 retenter une réparation du démarrage et ne plus pouvoir démarrer (pas d'affichage du menu grub)
7 faire une clé usb de réparation afin de constituer un boot-info
8 mais, alors que j'attendais le menu boot-repair, le démarrage sur cette clé m'a donné le menu grub (toujours sans présence de la 18.04)

C'est de la session 16.04 ouverte ainsi que j'ai réalisé le dernier boot-info

Je veux bien essayer l'update-grub demain, mais cette commande n'était pas reconnue, quand je l'ai essayée à l'étape 4.

jamesbad000 · Le 18/11/2018, à 00:51

Ok, j'ai bien pris note de la liste des opérations que tu as effectué.

Le mode legacy ("hérité" en français) est l'ancienne méthode de démarrage des PC à partir du bios.
Maintenant tous les PC sont équipés d'un bios UEFI, mais héritent généralement de la capacité de démarrer selon l'ancienne méthode.

Le choix du mode se gère généralement dans les options du bios.
Il peut éventuellement se faire à la volée en faisant afficher le menu de démarrage du bios à l'aide d'une touche prédéfinie, spécifique au matériel.

Lorsque tu tentera l'update grub, il faudra donner en retour le contenu du terminal avec la commande et ce qui suit.

Dernière modification par jamesbad000 (Le 18/11/2018, à 01:01)

Babdu89 · Le 18/11/2018, à 01:01

Bonsoir.

A moins d'autres suggestions, j'essaierai demain l'update-grub.

jamesbad000 a écrit;
En conséquence je soupçonne que les 2 ubuntu sont installés pour des modes différents.

Oui, les deux systèmes sont installés dans des modes différents.

KUbuntu 16.04 en mode UEFI

sda2	: sda,	not-sepboot,	grubenv-ok	grub2,	signed grub-efi ,

KUbuntu 18.04 en mode Bios_Legacy.

sda5	: sda,	not-sepboot,	grubenv-ok	grub2,	grub-pc ,

Les deux systèmes doivent être installés dans le même mode. Mode UEFI, puisque la 16.04 est l"Os qui est démarré en UEFI, avec la partition boot-efi /dev/sda1 .

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/ubuntu/fwupx64.efi 
                       /EFI/ubuntu/grubx64.efi /EFI/ubuntu/mmx64.efi 
                       /EFI/ubuntu/shimx64.efi

Avant de réinstaller la 18.04, tu peux tenter la réparation recommandée avec Boot-repair. Pas celle proposée par Boot-Repair actuellement.

Çà doit être fait depuis une session live démarrée en mode UEFI, dans laquelle tu installes/utilises Boot-Repair.

Actuellement tu utilises Boot-Repair depuis ta session 16.04 démarrée en mode Bios_Legacy.
Tu ne pourras pas faire la réparation recommandée, correctement.
La 16.04 démarre dans les deux modes.

boot-info is executed in installed-session (Ubuntu 16.04.5 LTS, xenial, Ubuntu, x86_64)

=================== UEFI/Legacy mode:
This installed-session is not in EFI-mode.
SecureBoot disabled.

Depuis ta session installée 16.04. Si tu utilises Boot-Repair pour réinstallé grub il ne peut être réinstaller que dans la 16.04, pas dans la 18.04 , quel que soit le mode de démarrage.
C'est pour çà qu'il faut utiliser Boot-Repair en session live.

Lorsque tu seras en session live démarrée en UEFI. Que Boot-Repair sera installé, refaire un boot info, pour que l'on voit si la réparation recommandée convient bien pour réinstaller un grub-efi dans la 18.04.

@+. Babdu89 .

Dernière modification par Babdu89 (Le 18/11/2018, à 01:10)

Eric Bl · Le 18/11/2018, à 11:07

Bon dimanche et merci pour cette attention, ces explications et cette assistance,

Lancer la session live en UEFI,

k'y dit, mais kesako ? Donc je regarde activement le menu du bios et là, grosse déception, 3 options seulement (bizare d'habitude il me semblait qu'il y en avait plus ...) :
ubuntu
P0: WDC WD5000AAKX-221CA1
P1: HL-DT-ST DVDRAM GT51N

Peinant à reconnaître ma clé dans cette liste, je choisis ubuntu qui pourrait bien être le nom de ma clé ... --> Plantage Grub !

J'éteins, Je réessaye et là :
ubuntu
UEFI: Philips USB Flash Drive 0.00
P0: WDC WD5000AAKX-221CA1
Philips USB Flash Drive 0.00
P1: HL-DT-ST DVDRAM GT51N
IBA GE Slot 00C8 V1365

Cette fois, je reconnais bien ma liste habituelle. Celle où je cherchais à repérer ma clé sans m'apercevoir qu'il y avait 2 lignes pour ma clé et sans imaginer que ça déterminait le mode de lancement UEFI ou Legacy.

Je choisis donc le mode UEFI (en me demandant s'il ne suffirait pas de réinstaller en reformatant la partition ... mais surtout : ne prenons pas d'initiative risquée, donc non). J'ai 2 messages éclairs trop rapides pour les lire, mais il y a EFI dans l'un. Cependant je vérifie en ligne de commande que je suis bien en mode EFI.

J'installe donc et lance le Boot-info. Il est là.

Et j'attends aussi patiemment que possible les prochaines consignes.

jamesbad000 · Le 18/11/2018, à 13:12

Eric Bl a écrit :

je regarde activement le menu du bios et là, grosse déception, 3 options seulement (bizare d'habitude il me semblait qu'il y en avait plus ...) :

C'est visiblement la source de tout tes problèmes. Ce PC semble parfois manquer de constance dans la détection des partitions de démarrage UEFI. Mettre le PC hors tension lorsque ça se produit, est probablement la seule solution.

Bon puisque tu as pu démarrer sur le live en mode UEFI. (cf extraits du boot-info)

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

boot-repair is executed in live-session (Ubuntu 18.04.1 LTS, bionic, Ubuntu, x86_64)

On va réparer à partir de là. Mais la réparation recommandée (ci-dessous), ne convient pas car elle va s'appliquer à sda2 qui correspond à la 16.04

The default repair of the Boot-Repair utility would reinstall the grub-efi-amd64-signed of sda2, using the following options:        sda1/boot/efi,

Il faut donc que tu ailles dans les options avancées de boot-repairn pour choisir sda5 comme partition de l'os à démarrer (ne rien modifier d'autre. sda1 reste la partition UEFI)
Après application de la réparation, donner le nouveau rapport qui va être produit automatiquement qu'on puisse vérifier si ça c'est bien passé, avant de tenter un redémarrage.

Eric Bl · Le 18/11/2018, à 13:47

C'était clair au niveau des consignes.
C'était impressionnant au niveau des actions accomplies.
Voilà le résultat du boot-info

jamesbad000 · Le 18/11/2018, à 14:07

D'après le boot info c'est tout bon. Il devrait maintenant démarrer avec la 18.04 comme os principal. Ne surtout pas refaire d'installation, ou réparation de grub à partir de la 16.04.

Note que le choix correct dans le menu de démarrage UEFI doit être "ubuntu"

Eric Bl · Le 18/11/2018, à 16:31

Effectivement, ça a bien marché. Et je t'en remercie.

Autre chose, maintenant : il m'a suggéré de lancer plus de 200 mises à jour avec Discover. J'étais d'accord. Mais il n'a pas l'air de faire quoi que ce soit :
* ça dure depuis 1 heure et quelque,
* l'affichage ne change pas,
* il y a une mention "Taches 0%". Quand je clique dessus, il affiche "Mettre à jour - Installation en cours" avec une barre de défilement qui ne bouge pas.

Cependant, Discover refuse de fermer "car certaines taches sont encore en cours".
Et Kubuntu lui-meme refuse de fermer : message de l'espace de travail Plasma "la déconnexion est annulée par Discover".

jamesbad000 · Le 18/11/2018, à 17:08

Oui, discover fait ch.. sous kubuntu 18.04 J'ai le même problème, il coince une fois sur 2.

pour tuer la tache discover:

ps -C plasma-discover

puis remplacer ci-dessous "pid" par le n° de pid retourné par la commande précédent

sudo kill "pid"

Mise à jour manuelle :

sudo apt update
sudo apt -y dist-upgrade

Dernière modification par jamesbad000 (Le 18/11/2018, à 17:16)

jamesbad000 · Le 18/11/2018, à 17:30

ps si tu as un compte sur launchpad ou la patience pour en ouvrir un...

Ensuite ouvrir ce lien ajoutera un utilisateur affecté par le bug. Ce qui augment les chances de résolution
https://bugs.launchpad.net/ubuntu/+sour … fectsmetoo

Dernière modification par jamesbad000 (Le 18/11/2018, à 18:46)

Eric Bl · Le 18/11/2018, à 17:49

C'est beaucoup plus efficace, effectivement. Merci.

Je vais pouvoir à présent m'attaquer à la suite de mon installation avec partage des données entre les 2 versions.
J'aimerais bien que soit validée la suite de la démarche qui m'a été proposée par Eric63. Je suis surpris qu'il n'y ait pas du tout d'utilisation de FSTAB, alors que les notes que j'ai pu lire font presque toujours référence à ce fichier. Mais moi ...

Eric Bl · Le 18/11/2018, à 22:50

a ben v'là aut'chose : grub ne s'affiche plus.
Donc pas moyen de retourner en 16.04 !

Le boot-info est là.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 16/11/2018, à 10:07

[Résolu] Problème grub avec /boot séparé puis mode UEFI/Legacy

#2 Le 16/11/2018, à 12:30

Re : [Résolu] Problème grub avec /boot séparé puis mode UEFI/Legacy

#3 Le 16/11/2018, à 14:55

Re : [Résolu] Problème grub avec /boot séparé puis mode UEFI/Legacy

#4 Le 16/11/2018, à 15:18

Re : [Résolu] Problème grub avec /boot séparé puis mode UEFI/Legacy

#5 Le 16/11/2018, à 18:19

Re : [Résolu] Problème grub avec /boot séparé puis mode UEFI/Legacy

#6 Le 16/11/2018, à 18:42

Re : [Résolu] Problème grub avec /boot séparé puis mode UEFI/Legacy

#7 Le 17/11/2018, à 17:09

Re : [Résolu] Problème grub avec /boot séparé puis mode UEFI/Legacy

#8 Le 17/11/2018, à 19:13

Re : [Résolu] Problème grub avec /boot séparé puis mode UEFI/Legacy

#9 Le 17/11/2018, à 19:27

Re : [Résolu] Problème grub avec /boot séparé puis mode UEFI/Legacy

#10 Le 17/11/2018, à 19:28

Re : [Résolu] Problème grub avec /boot séparé puis mode UEFI/Legacy

#11 Le 17/11/2018, à 19:51

Re : [Résolu] Problème grub avec /boot séparé puis mode UEFI/Legacy

#12 Le 17/11/2018, à 20:57

Re : [Résolu] Problème grub avec /boot séparé puis mode UEFI/Legacy

#13 Le 17/11/2018, à 22:11

Re : [Résolu] Problème grub avec /boot séparé puis mode UEFI/Legacy

#14 Le 17/11/2018, à 23:56

Re : [Résolu] Problème grub avec /boot séparé puis mode UEFI/Legacy

#15 Le 18/11/2018, à 00:51

Re : [Résolu] Problème grub avec /boot séparé puis mode UEFI/Legacy

#16 Le 18/11/2018, à 01:01

Re : [Résolu] Problème grub avec /boot séparé puis mode UEFI/Legacy

#17 Le 18/11/2018, à 11:07

Re : [Résolu] Problème grub avec /boot séparé puis mode UEFI/Legacy

#18 Le 18/11/2018, à 13:12

Re : [Résolu] Problème grub avec /boot séparé puis mode UEFI/Legacy

#19 Le 18/11/2018, à 13:47

Re : [Résolu] Problème grub avec /boot séparé puis mode UEFI/Legacy

#20 Le 18/11/2018, à 14:07

Re : [Résolu] Problème grub avec /boot séparé puis mode UEFI/Legacy

#21 Le 18/11/2018, à 16:31

Re : [Résolu] Problème grub avec /boot séparé puis mode UEFI/Legacy

#22 Le 18/11/2018, à 17:08

Re : [Résolu] Problème grub avec /boot séparé puis mode UEFI/Legacy

#23 Le 18/11/2018, à 17:30

Re : [Résolu] Problème grub avec /boot séparé puis mode UEFI/Legacy

#24 Le 18/11/2018, à 17:49

Re : [Résolu] Problème grub avec /boot séparé puis mode UEFI/Legacy

#25 Le 18/11/2018, à 22:50

Re : [Résolu] Problème grub avec /boot séparé puis mode UEFI/Legacy

Pied de page des forums