Broken boot

Filofel · Le 22/04/2022, à 17:59

xubu1957 a écrit :

Fournis les noyaux présents :

Bonjour xubu1957,

$ echo; dpkg -l | awk '!/^rc/ && / linux-(c|g|h|i|lo|m|si|t)/{print $1,$2,$3,$4 | "sort -k3V | column -t"}' ; echo -e "\nNoyau courant : $(uname -mr)"

ii  linux-headers-5.4.0-107                5.4.0-107.121  all
ii  linux-headers-5.4.0-107-generic        5.4.0-107.121  amd64
ii  linux-image-5.4.0-107-generic          5.4.0-107.121  amd64
ii  linux-modules-5.4.0-107-generic        5.4.0-107.121  amd64
ii  linux-modules-extra-5.4.0-107-generic  5.4.0-107.121  amd64
ii  linux-headers-5.4.0-109                5.4.0-109.123  all
ii  linux-headers-5.4.0-109-generic        5.4.0-109.123  amd64
ii  linux-image-5.4.0-109-generic          5.4.0-109.123  amd64
ii  linux-modules-5.4.0-109-generic        5.4.0-109.123  amd64
ii  linux-modules-extra-5.4.0-109-generic  5.4.0-109.123  amd64
ii  linux-generic                          5.4.0.109.113  amd64
ii  linux-generic-hwe-18.04                5.4.0.109.113  amd64
ii  linux-headers-generic                  5.4.0.109.113  amd64
ii  linux-image-generic                    5.4.0.109.113  amd64
ii  linux-image-generic-hwe-18.04          5.4.0.109.113  amd64
Noyau courant : 5.4.0-107-generic x86_64

xubu1957 · Le 22/04/2022, à 18:03

linux-image-generic-hwe-18.04

Je vois le hwe de la version 18.04.

Il faut l'avis des experts.

Filofel · Le 22/04/2022, à 18:16

xubu1957 a écrit :

Je vois le hwe de la version 18.04.

Ca m'avait échappé...
Bizarre que l'upgrade en ligne de 18.04 à 20.04 ait laissé ça trainer derrière?

Filofel · Le 24/04/2022, à 03:15

Je pense que j'ai l'explication, et des solutions - aucune totalement satisfaisante, mais... Pour l'instant, on va faire avec.
Rappel des épisodes précédents:

geole a écrit :

C'est effectivement une piste que le grub LEGACY accéde mal aux informations au delà de 2To dans la partition mais ils sont tous en deça de cette limite. (...)
Il se pourrait que cela soit le bios lui-même qui ne sache pas accéder à des données au delà de 2To dans une grande partition.

Filofel a écrit :

Peut-être, mais l'hypothèse est faible:
J'ai bien le menu de démarrage de Grub.
Donc Grub2 stage 2 s'est correctement chargé et exécuté. La commande Grub Rescue "env" m'affiche des données justes et cohérentes.
Grub sait que j'utilise un contrôleur disque ahci (c'est indiqué dans grub.cfg), et Grub2 a un driver ahci (ahci.mod). Donc Grub2 stage 2 n'a plus besoin du BIOS.
Et Grub2 stage 2 sait gérer des adresses disque sur 64 bits, puisqu'il est sait gérer un disque gpt.
Donc en principe, lorsque Grub2 affiche son menu, BIOS n'est plus utilisé...

Filofel avait tort.
En faisant à la mimine depuis Grub Rescue ce que fait grub.cfg, j'ai confirmé que je pouvais charger le kernel 107, mais pas le kernel 109.
Et que lorsque j'essayais de charger le kernel 109 avec la commande de Grub "linux", Grub émettait le fameux message

error: attemtp to read or write outside of 'hd0'

J'ai alors relu très attentivement toute la documentation Grub 2.06, et j'ai découvert la commande Grub

nativedisk

command console et script.
Et que fait-elle? L'explication est minimale, 3 lignes:
Elle fait basculer Grub de l'utilisation des drivers firmware vers les drivers natifs...
Donc par défaut, Grub utilise les drivers disque du firmware (BIOS ou UEFI, selon le contexte). Trop fort...
D'autant que Grub sait quel contrôleur disque j'utilise, puisqu'il a inséré un paramètre

--hint-baremetal=ahci0,gpt2

dans mon grub.cfg! Je ne sais d'ailleurs pas à quoi lui sert ce hint, puisqu'il ne l'utlise pas?
Donc, toujours par défaut, Grub n'est capable de charger le vmlinuz et l'initrd que s'ils sont dans les 2TiB du bas... Aaargh.
Mais la commande nativedisk résoud se problème-là: Elle provoque les chargement des drivers natifs, ahci.mod, ata.mod, ehci.mod ou ohci.mod
Sauf que... où sont-ils les drivers natifs? Dans la partition, sous

/boot/grub/i386-pc

Et qu'est-ce qui prouve qu'ils sont dans les 2TiB du bas? Ben rien du tout... Retour à la case départ.
Sauf que... on peut les charger dans core.img, dans la micro-partition des bootblocks, il y a plein de place (plus de 2000 secteurs)!
Il suffit d'utiliser:

grub-install --disk-module=ahci /dev/sda

Et à partir de là, tout semble baigner. Mes deux images bootent normalement.
Inconvénient:
C'est fragile. Grub-pc ne mémorise pas ces paramètres-là (par exemple dans /etc/default/grub). Et je ne vois pas d'extension / script customisable de Grub du genre de

/etc/grub.d/40_custom

qui permette de configurer ça d'une façon perenne.
Donc le premier grub-install venu va venir remettre un core.img standard (sans le driver natif) à la place. Comme par exemple risque de le faire Grub-Repair à la première occasion, je crains fort.
Et je crains aussi que grub-install ne soit silencieusement appelé dans plusieurs autres circonstances, et ne vienne me re-casser mon boot.
Mais je vais être optimiste et éviter de pleurer avant d'avoir mal, surtout que maintenant, on dirait que j'ai (enfin) au moins une solution.
Sinon, ce serait une bonne idée que dans le cas où la première partion MBR est flaggée bios-grub, Grub-Repair vérifie si la partition de boot déborde des 2TiB du bas, et si c'est le cas, qu'il génère un grub-install avec le bon disk-module (ahci.mod, ata.mod, ehci.mod ou ohci.mod) pour créer le bon core.img.
Le paramètre

--disk-module=xxxx

ne fonctionne qu'avec BIOS, d'ailleurs: Il est bien fait précisément pour ça!
Ca serait bien aussi que Grub-pc soit un jour amélioré pour mémoriser tout seul ce genre de configuration, mais bon...

Si quelqu'un voit une solution plus solide, je suis preneur! ;-)

Dernière modification par Filofel (Le 24/04/2022, à 03:24)

xubu1957 · Le 24/04/2022, à 07:45

Bonjour,

Montre aussi d'éventuels paquets cassés :

dpkg -l | grep -v ^ii

Tente :

sudo apt purge linux-image-generic-hwe-18.04 linux-generic-hwe-18.04

Dernière modification par xubu1957 (Le 24/04/2022, à 07:59)

geole · Le 24/04/2022, à 10:37

Bonjour Filofel

Je vois que tu es sacrement pointu en GRUB.

Mais ton explication me dépasse un peu car je n'ai pas vu de fichier de boot au-delà de 2 To. Mais la limite n'est peut-être pas exactement 2To.
Je vois deux contournements à faire en live USB
a) Un très simple
Lancer gparted et rétrécir par son début ton énorme partition d'une valeur de 2Mo.
Créer une partition EXT4 avec ces 2 Mo.
Lancer boot-repair et dire de réinstaller le grub en utilisant cette partition de 2 Mo pour y mettre les fichiers de boot
b) Un plus compliqué qui ouvre la porte à une future utilisation Multi-OS.
Le principe est de séparer les données du logiciel.
Solution UN, si tu n'as pas de sauvegarde de données
Lancer gparted et rétrécir par sa fin ton énorme partition de 4 To
Créer une partition EXT4 avec label data de tout l'espace récupéré. Quitter gparted.
Transférer le maxima de tes données personnelles dans cette nouvelle partition.
Relancer gparted et rétrécir par sa fin ton énorme partition
Déplacer par sa gauche la partition DATA et l'agrandir de tout l'espace libéré et quitter gparted.
Transférer le maxima de tes données personnelles dans cette nouvelle partition.
Et itérer le nombre de fois nécessaires.
Solution Deux, si tu as une sauvegarde de données
Supprimer toutes tes données personnelle du /home
Lancer gparted et rétrécir par sa fin ton énorme partition de 4 To.
Créer une partition EXT4 avec label data de tout l'espace récupéré. Quitter gparted .
Restorer tes données personnelles dans la partiton data

Lorsque ces actions sont faites, il reste à demander le montage automatique de cette partition data.
puis à lier les données soit par liens symboliques pour pointeurs XDG.

NOTA. Tu peux aussi faire un rapport de bug en espérant qu'il soit corrigé. Mais je n'y crois pas.

Filofel · Le 24/04/2022, à 17:17

geole a écrit :

Je vois que tu es sacrement pointu en GRUB.

Pas vraiment, je viens juste de plonger là-dedans par la force des choses.
J'ai regardé le manuel Grub pour la première fois il y a trois jours (et trois nuits :-) )
Oui, j'ai bien pensé aux deux solutions que tu proposes.
Ce qui me gêne dans la première (grub dans une partition spécifique en début de disque) c'est que je crains que certains outils ne s'attendent pas à trouver grub (où même toute la partition boot) dans une partition différente. Autrement dit, j'ai peur que le côté inusuel de la situation ne fasse apparaitre d'autres bugs dans différents outils.
L'autre solution est en effet de flanquer home et tout ce qui est en dessous dans une partition en haut, et de juste laisser Ubuntu en bas.
Mais c'est beaucoup de boulot <soupir>.

geole a écrit :

Mais la limite n'est peut-être pas exactement 2To.

Si, mais c'est pas deux 2To, c'est exactement 2Tio(TiB):
L'adresse secteur (LBA ou LSN) que connaît le BIOS est sur 32 bits.
Donc 4 giga secteurs.
Donc deux giga-K, puisque 2 secteurs = 1K.
Donc 2TiB...
BIOS ne peut accéder à aucun secteur au-delà.
Tout ça pour un bête bug dans Grub: Lors de l'install, Grub devrait s'apercevoir que la partition de boot dépasse la limite de 2Tib et dans ce cas, émettre un warning et charger automatiquement le module disk controller natif dans le core.img: Ca ne peut pas marcher de façon fiable autrement.
Le problème n'a pas encore été détecté généralement parce que les SATA 2"5 de 4TB ou plus n'existaient pas encore à un prix accessible, mais là, c'est parti, et les prix baissent à toute vitesse...

geole a écrit :

Tu peux aussi faire un rapport de bug en espérant qu'il soit corrigé. Mais je n'y crois pas.

Je vais peut-être quand même tenter de notifier le problème.
J'ai de bons copains chefs techniques à deux ou trois plumes chez Ubuntu comme chez Red Hat, ça peut les intéresser.
Je sais que c'est GNU qui gère Grub, mais ce sont bien Ubuntu (Debian) et RedHat qui vont commencer à se prendre les appels support, alors...
Quoi qu'il en soit, je suis bien d'accord que le problème ne sera pas résolu demain.
En attendant, si Boot-Repair prenait le problème en compte, ça aiderait déjà à sortir vite du problème lorsqu'il se produit.

geole · Le 24/04/2022, à 17:56

Je viens de comprendre

Boot repair dit
==================== sda2: Location of files loaded by Grub ====================
           GiB - GB             File                                 Fragment(s)
 997.610908508 = 1071.176556544 boot/grub/grub.cfg                             2
1529.142398834 = 1641.904148480 boot/grub/i386-pc/core.img                     1
1697.037143707 = 1822.179758080 boot/vmlinuz                                   1
1677.271514893 = 1800.956575744 boot/vmlinuz-5.4.0-107-generic                 1
1697.037143707 = 1822.179758080 boot/vmlinuz-5.4.0-109-generic                 1
1677.271514893 = 1800.956575744 boot/vmlinuz.old                               1
1677.271514893 = 1800.956575744 vmlinuz.old                                    1
1311.321285248 = 1408.020508672 boot/initrd.img                                7
1311.844722748 = 1408.582545408 boot/initrd.img-5.4.0-107-generic              4
1311.321285248 = 1408.020508672 boot/initrd.img-5.4.0-109-generic              7
1311.844722748 = 1408.582545408 boot/initrd.img.old                            4
1311.844722748 = 1408.582545408 initrd.img.old                                 4

J'en ai déduis bêtement que la limite n'est pas atteinte POUR LES DEBUTS des fichiers
Mais avec cette quantité d'extends, Il faudrait que boot-repair donne l'adresse du dernier bit des fichiers.
https://forum.ubuntu-fr.org/viewtopic.p … #p22555960
Dans ce contexte, il est fort probable que pour certains fichiers, on ait franchi la limite sans le voir d'où le fait que certains noyaux fonctionnent et pas d'autres car il faut être capable de lire la totalité du fichier.

Pour la partition de boot en début de disque, je te rassure tout de suite. C'est la règle pour tout ceux qui sont sérieux.
Par exemple en LEGACY : En RAIDS. Lorsqu'on décide de chiffrer les données et le logiciel. Lorsqu'on décide d'utiliser le LVM quand les données sont dans plus d'un disque.
et surtout en EFI.... où la partition de boot est obligatoire.

Dernière modification par geole (Le 24/04/2022, à 17:59)

iznobe · Le 25/04/2022, à 10:44

Bonjour , en admettant que j' ai compris le soucis ( ce qui n' est pas vraiment certain , ca meriterait une eclaircissement pour ce cas de figure , dans quel cas se reproduit ce bug ) :
Le probleme serait donc que : le GRUB ait a lire des fichiers au delà de la taille des 2 TiO de données , sur un disque uniquement SSD SATA ? Cela n' arriverait que sur un disque en mode LEGACY MBR , puisque sur une installation EFI , les fichiers serait dans la partition /boot/efi , toujours ( ? ) située en debut de disque ?

Hypothese : N ' est ce pas ( justement ?) pour cela que , meme sur une install en LEGACY , GRUB installe une partition EFI et qu ' on ne comprend pas forcement pourquoi ?

Dernière modification par iznobe (Le 25/04/2022, à 10:46)

Filofel · Le 25/04/2022, à 11:20

geole a écrit :

Dans ce contexte, il est fort probable que pour certains fichiers, on ait franchi la limite sans le voir d'où le fait que certains noyaux fonctionnent et pas d'autres car il faut être capable de lire la totalité du fichier.

Voui, c'est ça.
En fait, dès lors qu'un bout de la partition dépasse la limite des 2TiB, on a potentiellement le risque que le file system décide d'allouer tout ou partie d'un nouveau kernel ou d'initrd en dehors de la limite adressable fatale.
Quand on utilise Grub sans les drivers natifs, la totalité de la partition de boot doit se trouver en dessous de la limite des 2TiB.
Sinon, ça craint.

geole a écrit :

Pour la partition de boot en début de disque, je te rassure tout de suite. C'est la règle pour tout ceux qui sont sérieux.

Bon, alors c'est sans doute la solution la plus simple a mettre en œuvre.
N'empêche que je ne ferai sans doute pas ça avant d'avoir décidé d'acheter un autre SSD identique:
Un peu trop de risques de faire une fausse manœuvre, de massacrer mon disque, et de devoir le reconstruire à la petite cuillère...

Dernière modification par Filofel (Le 25/04/2022, à 11:57)

Filofel · Le 25/04/2022, à 11:55

iznobe a écrit :

Le probleme serait donc que : le GRUB ait a lire des fichiers au delà de la taille des 2 TiO de données

Oui.

iznobe a écrit :

sur un disque uniquement SSD SATA

Euh... Non. Le problème serait le même sur toute technologie de disque, SSD ou pas, SATA ou pas, dès lors que le disque contient plus de 2**32 secteurs et que le BIOS accède au disque en utilisant un numéro de secteur exprimé sur 32 bits.

iznobe a écrit :

Cela n' arriverait que sur un disque en mode LEGACY MBR puisque sur une installation EFI , les fichiers serait dans la partition /boot/efi , toujours ( ? ) située en debut de disque ?

En EFI, ce problème-là n'existe pas: le LBA fait 64 bits. Extrait de UEFI_Spec_2_9_2021_03_18.pdf:

EFI_LBA Logical block address: Type UINT64.

Plus exactement, en EFI, ce problème ne commencera à exister qu'avec l'arrivée d'un modèle de disque contenant plus de 2**64 secteurs.
Ca nous laisse encore quelques jours... :-D

iznobe a écrit :

N ' est ce pas ( justement ?) pour cela que , meme sur une install en LEGACY , GRUB installe une partition EFI et qu ' on ne comprend pas forcement pourquoi ?

Hmmm.. Grub n'installe pas de partition EFI?
Peut-être que le soft d'installation de Ubuntu le fait maintenant, je n'ai pas fait d'install depuis belle lurette, mais je ne crois pas que ce soit Grub.
Normalement, l'installer ne devrait créer cette partition EFI que s'il détecte un firmware UEFI dans la machine lors de l'install.
Ce qui, je suppose, doit arriver de plus en plus souvent.

Dernière modification par Filofel (Le 25/04/2022, à 12:00)

geole · Le 25/04/2022, à 12:29

iznobe a écrit :

Hypothese : N ' est ce pas ( justement ?) pour cela que , meme sur une install en LEGACY , GRUB installe une partition EFI et qu ' on ne comprend pas forcement pourquoi ?

Bonjour
Non. Cette partition est vide. A mon avis c'est en prévision du moment ou l'utilisateur changera de carte graphique et pourra booter en EFI, Il suffira d'un coup de boot-repair sans se préoccuper de rétrécir une partition afin de créer cette partition EFI

Je pense qu'il y a le même problème pour un disque dur classique

Filofel a écrit :

N'empêche que je ne ferai sans doute pas ça avant d'avoir décidé d'acheter un autre SSD identique:

Pourquoi un autre SSD? Cela pourrait être un disque dur externe pouvant être plus grand et pour un prix moindre.

Dernière modification par geole (Le 25/04/2022, à 12:35)

Filofel · Le 25/04/2022, à 15:42

geole a écrit :

Pourquoi un autre SSD? Cela pourrait être un disque dur externe pouvant être plus grand et pour un prix moindre.

Un SSD peut aussi être dans un boitier externe! ;-)
Parce qu'avec un disque classique, la copie de 2 à 4 TiB prend des siècles, et que je suis trop vieux pour attendre aussi longtemps!
D'autant que par expérience, ce genre de manip ne marche pas toujours du premier coup, et tu te retrouves à refaire la manip plusieurs fois, ce qui prend plusieurs fois des siècles:

Woody Allen a écrit :

L'éternité, c'est très long, surtout vers la fin.

Et puis, un autre SSD, j'en aurai toujours l'usage, alors que les disques qui tournent, je me suis un peu lassé.
Mais bon, je ne ferai pas ça demain non plus. :-)

geole · Le 25/04/2022, à 17:17

Filofel a écrit :

D'autant que par expérience, ce genre de manip ne marche pas toujours du premier coup, et tu te retrouves à refaire la manip plusieurs fois, ce qui prend plusieurs fois des siècles:

Je suis bien d'accord, Pour m'en protéger, je fais avec RSYNC. Comme cela ce qui a été copié n'est plus à refaire.
Un ordre de grandeur 50Go/heure donc un peu moins de deux jours pour les deux To.

Filofel · Le 25/04/2022, à 17:52

geole a écrit :

Un ordre de grandeur 50Go/heure donc un peu moins de deux jours pour les deux To.

Voilà. La réflexion de Woody Allen s'applique!
De SSD à SSD en USB 3, c'est une paire d'heures.
C'est moins pire!

Filofel · Le 25/04/2022, à 18:04

Ah, on dirait que ma première tentative à un report vient d'obtenir un début de résultat.
Pour commencer, j'ai cherché des problèmes similaires dans launchpad et rajouté une réponse expliquant ce que j'avais trouvé.
Et j'ai obtenu (sans aucun piston! ) que le premier problème que j'ai adressé revienne sur le devant de la scène:

rodsmith a écrit :

Rod Smith (rodsmith) wrote 2 hours ago:
I've reset this from "Won't Fix" to "Confirmed" because I believe
Filofel's analysis merits another look at the issue.
** Changed in: ubiquity (Ubuntu)
Status: Won't Fix => Confirmed

Le problème date initialement de 2014, mais il est suivi jusqu'en 2017, et maintenant, 2022!
https://bugs.launchpad.net/ubuntu/+sour … ug/1284196

Dernière modification par Filofel (Le 25/04/2022, à 18:05)

iznobe · Le 26/04/2022, à 10:16

Filofel a écrit :

iznobe a écrit :
sur un disque uniquement SSD SATA
Euh... Non. Le problème serait le même sur toute technologie de disque, SSD ou pas, SATA ou pas, dès lors que le disque contient plus de 2**32 secteurs et que le BIOS accède au disque en utilisant un numéro de secteur exprimé sur 32 bits.

Bonjour , dans ce cas là, meme si effectivement tu utilises des SSD , Mais que le probleme peut aussi bien arriver avec n ' importe quel disque , il vaut peut etre mieux ne pas specifier le type de disque , c ' est ce que je voulais clarifier dans ma question precedente , qui me parraissait plutot etonnant ( que ca ne soit lié qu ' a des SSD ) .
Là je comprends mieux

Dernière modification par iznobe (Le 26/04/2022, à 10:17)

YannUbuntu · Le 08/12/2023, à 01:33

Bonjour,
j'essaye de voir si Boot-Repair pourrait corriger ou du moins avertir l'utilisateur de ce problème.
Si je comprends bien, GRUB Legacy plante lorsque la partition contenant le dossier /boot se termine plus loin que 2Tio, c'est ça ?
Et le contournement ça serait de passer la paramètre --disk-module=ahci ou ata etc...

Filofel a écrit :

C'est fragile. Grub-pc ne mémorise pas ces paramètres-là (par exemple dans /etc/default/grub)

Si, il suffit d'ajouter le paramètre dans GRUB_CMDLINE_LINUX_DEFAULT , puis un petit update-grub Je viens de me rendre compte que j'ai écrit une bêtise, pardon.

Dernière modification par YannUbuntu (Le 08/12/2023, à 20:43)

Nasman · Le 08/12/2023, à 09:35

Filofel a écrit :

Bonjour,
Je boote sur un SSD de 4TB, une partition bios_grub dans les secteurs 17-34 (sda1), une partition ext4 ubuntu 20.04.4 sur le reste du disque (sda2). : not a COM32/COM32R module

Si tu as un disque de plus de 2 Tio, il faut une table des partitions GPT : c'est OK de ce point de vue.

Cependant il faut connaitre comment sont utilisés les secteurs dans ce type de partitionnement :
1er secteur (LBA=0) : mbr protector
LBA=1 : en tête GPT
LBA=2 à 33 : 32 secteurs utilisés pour décrire les 128 (4*32) partitions possibles
LBA=34 à 2047 : secteurs à priori non utilisés
LBA=2048 et suivants : première partition "classique" alignée au Mio

dernière LBA-33 à dernière LBA-1 : 32 secteurs utilisés pour la copie des secteurs 2 à 33 (backup de secours)
dernière LBA (définie par la taille du disque) : copie de l'entête GPT (copie de secours)

En utilisant les secteurs 17-34 (sans doute LBA 16 à 33) pour bios_grub tu as écrasé une partie de la table des partitions (donc les potentielles partitions sda61 à sda128). C'est sans doute la raison de ton pb.

Pour bios_grub ce sont les LBA 34-2047 que tu peux utiliser. Nota : a priori bios_grub correspond à ce qui était utilisé dans le partitionnement msdos à partir de la LBA1 et jusqu'à la LBA 62 : là partir de la LBA=63 commençait les premières partitions alignées au cylindre (premier secteur de la seconde tête du premier cylindre).

Filofel · Le 08/12/2023, à 20:55

YannUbuntu a écrit :

Si je comprends bien, GRUB Legacy plante lorsque la partition contenant le dossier /boot se termine plus loin que 2Tio, c'est ça ?

Pas toujours... C'est pire, il plante seulement lorsque le contenu de la partition boot qui est effectivement utilisé pour ce boot-là tombe au delà de 2Tio...
Si ce contenu (les fichiers utilisés, comme vmlinuz, un .mod utilisé, etc...est par chance dans un espace alloué dans les 2Tio du bas, c'est adressable par le LBA 32-bits du firmware, et ça passe. Sinon, il faut le LBA 64 bits et le donc module natif Grub.
C'est ce que j'essaie d'expliquer en détails au message #29.

Pour info, Grub s'est déjà mis à jour plusieurs fois depuis que j'ai utilisé cette solution, et ça n'a rien cassé.
Mais je n'ai pas encore fait mon upgrade vers 22.04!...

Dernière modification par Filofel (Le 08/12/2023, à 21:40)

geole · Le 09/12/2023, à 00:18

Bonsoir Filofel.
Je n'avais pas oublié mais reconnais que ton contexte est très rare. 1 cas sur 10 milliards probablement.
Le mieux serait que tu fasses comme tout le monde.
1) Rétrécis par le gauche la première partition (son début) de deux Go.
2) Fais une partition de 1 Mo non formatée en ajoutant le drapeau bios_grub.
3) Fais une partition de 510 Mo formatée en FAT32 en ajoutant le drapeau ESP.
4) Fais une partition EXT4 avec le reste de l'espace libéré (1,5 Go) avec le drapeau boot.
5) Lance un petit coup de boot repair en mode options avancées.
Choisis la partition de 512 Mo pour recevoir le boot EFI.
Choisis la partition de 1,5 Go pour recevoir le boot legacy.
6) Puis oublie tes ennuis.

Dernière modification par geole (Le 09/12/2023, à 00:24)

Filofel · Le 09/12/2023, à 17:04

geole a écrit :
Je n'avais pas oublié mais reconnais que ton contexte est très rare. 1 cas sur 10 milliards probablement.

Pas question, d'autant que ça marche correctement depuis 2 ans, que je connais maintenant la cause du problème et que je sais le corriger - même si c'est un peu pénible.
Et "un cas sur 10 milliards", sûrement pas: Il suffit d'avoir une workstation de 10 ans (EFI défectueux) avec un HD de plus de 2Tio pour que le problème puisse se produire. Je doute d'être le seul dans ce cas-là. Je ne vais pas jeter une workstation 17" portable avec 32 Go de RAM et un bon quadcore parce que son BIOS EFI est trop vieux et pas upgradable. Le plus important dans l'empreinte carbone d'une machine, c'est sa fabrication!

Il vaudrait mieux que Grub détecte un boot avec flag bios_grub et une partition bootable qui traverse la frontière des 2Tio, et que dans ce cas, il configure/charge ses drivers natifs plutôt que de laisser passer le défaut, i.e. les drivers du BIOS.
Ou que Boot-Repair puisse faire automatiquement ce que je fais manuellement (réinstaller grub avec les drivers natifs).
C'est pourquoi j'ai répondu à YannUbuntu, qui propose plus raisonnablement ;-) ce qui suit:

YannUbuntu a écrit :

de voir si Boot-Repair pourrait corriger ou du moins avertir l'utilisateur de ce problème.

Hint, YannUbuntu: Corriger, ça serait mieux! :-D

YannUbuntu · Le 10/12/2023, à 01:29

Bonsoir,
Corriger, je ne sais pas faire, car je ne sais pas quel paramètre --disk-module= utiliser de manière fiable. A moins que vous ayiez une idée?

Ce que je peux faire, c'est ajouter un message d'avertissement, de type 'Attention la partition xxx finit à plus de 100GB, il faut peut-être créer une partition /boot en début de disque.'
100GB au lieu de 2TB car c'est une valeur qui pose problème sur d'autres vieux PCs. https://ubuntuforums.org/showthread.php … st12362109

geole · Le 10/12/2023, à 11:31

Filofel a écrit :

Il suffit d'avoir une workstation de 10 ans (EFI défectueux) avec un HD de plus de 2Tio pour que le problème puisse se produire. Je doute d'être le seul ce cas-là.

Bonjour.
Tu n'es peut-être pas le seul à avoir ce matériel, Mais, si on élimine ceux qui il y a 10 ans n'avaient pas un disque de cette taille, ceux qui ont installés avec une partition home qui était fortement conseillée à cette époque, ceux qui ont installé avec une partition de boot, ceux qui ont choisi d'installer automatiquement sur tout le disque, ceux qui ont eu l'ncident et ont rectifié, actuellement il ne doit pas rester grand monde dans ce cette situation.
Remarque, Même si le boot était EFI, le problème resterait identique.

Dernière modification par geole (Le 10/12/2023, à 11:37)

Filofel · Le 10/12/2023, à 17:16

geole a écrit :

Mais, si on élimine ceux qui il y a 10 ans n'avaient pas un disque de cette taille

Ben moi non plus, je n'avais pas de HD de cette taille il y a 10 ans! :-D
En fait, je pense qu'il n'y avait alors pas de disque 2.5" approchant 2 TB.
De même qu'il y a 10 ans, ma machine n'avait pas 32 GB de RAM (même si elle était conçue pour les supporter, voire plus)
J'ai simplement upgradé le disque et la RAM pour prolonger la vie de la machine.
C'est d'ailleurs là que se situe le problème aujourd'hui: Les gens qui ont une machine dont le disque se remplit, qui achètent un SSD de grosse capacité pour se donner de l'oxygène:
Aujourd'hui, 4TB pour à peine plus de 200€ en SATA chez Samsung ou Crucial.
Un coup de GParted pour étendre la partition sur le nouveau disque, et à partir de là, le problème peut se produire...

geole a écrit :

ceux qui ont eu l'incident et ont rectifié

Ceux-là, je ne suis pas sûr qu'il y en ait eu beaucoup! Trop d'efforts pour comprendre et fixer.

geole a écrit :

Même si le boot était EFI, le problème resterait identique.

Non: Le firmware du boot EFI utilise un LBA 64 bits et toute la logique qui va avec. Ce problème n'existe plus en EFI.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 22/04/2022, à 17:59

Re : Broken boot

#27 Le 22/04/2022, à 18:03

Re : Broken boot

#28 Le 22/04/2022, à 18:16

Re : Broken boot

#29 Le 24/04/2022, à 03:15

Re : Broken boot

#30 Le 24/04/2022, à 07:45

Re : Broken boot

#31 Le 24/04/2022, à 10:37

Re : Broken boot

#32 Le 24/04/2022, à 17:17

Re : Broken boot

#33 Le 24/04/2022, à 17:56

Re : Broken boot

#34 Le 25/04/2022, à 10:44

Re : Broken boot

#35 Le 25/04/2022, à 11:20

Re : Broken boot

#36 Le 25/04/2022, à 11:55

Re : Broken boot

#37 Le 25/04/2022, à 12:29

Re : Broken boot

#38 Le 25/04/2022, à 15:42

Re : Broken boot

#39 Le 25/04/2022, à 17:17

Re : Broken boot

#40 Le 25/04/2022, à 17:52

Re : Broken boot

#41 Le 25/04/2022, à 18:04

Re : Broken boot

#42 Le 26/04/2022, à 10:16

Re : Broken boot

#43 Le 08/12/2023, à 01:33

Re : Broken boot

#44 Le 08/12/2023, à 09:35

Re : Broken boot

#45 Le 08/12/2023, à 20:55

Re : Broken boot

#46 Le 09/12/2023, à 00:18

Re : Broken boot

#47 Le 09/12/2023, à 17:04

Re : Broken boot

#48 Le 10/12/2023, à 01:29

Re : Broken boot

#49 Le 10/12/2023, à 11:31

Re : Broken boot

#50 Le 10/12/2023, à 17:16

Re : Broken boot

Pied de page des forums