Impossible de booter après modification d'une option de boot dans grub... gros soupçons sur UEFI
14 réponses
Francois Lafont
Bonsoir à tous,
Je me suis heurté à un problème (non résolu à ce jour) qui me laisse
vraiment perplexe et, comme indiqué dans le titre, je soupçonne UEFI
mais j'avoue que je n'y connais rien là dedans, c'est plus ou moins
la première fois que je me frotte à ça (fallait bien que ça arrive un
jour ;)).
Voilà, j'ai un serveur HP DL360 Gen9 sur lequel j'ai installé une
Ubuntu 14.04. Alors au départ j'ai eu des soucis pour faire l'install
mais je pense que c'était surtout dû à mon ignorance en matière d'UEFI.
En effet, je ne savais pas qu'il fallait créer une partition de type
UEFI au début du disque de boot. Du coup, ça ne marchait, j'ai vu dans
le bios (enfin l'UEFI) qu'on pouvait basculer en mode bios-legacy, ce
que j'ai fait mais succès non plus (en mode bios-legacy, je suis arrivé
à installer l'OS sans problème mais je n'ai jamais pu faire booter
ensuite le serveur sur l'OS, j'ai toujours eu un "no boot device detected"
ou un truc dans le genre. Bref, après un petit pédalage dans la choucroute,
j'ai finalement remis l'UEFI en mode « non-legacy », j'ai installé l'OS
en faisant attention de bien créer la partition UEFI et ensuite, plus de
souci. Installation sans problème de ma Ubuntu 14.04. Ouf.
Seulement à un moment, j'ai voulu faire un petit bench au niveau des IO
sur ce serveur. Et il est en général recommandé dans ce cas là de limiter
la RAM de l'OS pour éviter de bencher le cache de l'OS. Alors je reboote
le serveur et une fois devant le menu grub, je sélectionne le démarrage
par défaut, puis avec « e » j'édite ce démarrage pour ajouter simplement
« mem=256m » dans les options de l'appel du noyau et ensuite F10 pour
dire à grub de booter sur cette version modifiée du boot.
Et là, freeze complet, écran noir. Le noyau n'est même pas chargé, rien
du tout. Je pense que le freeze arrive au tout début du lancement, je
suis quasiment sûr que le noyau linux n'est même pas encore chargé. Autre
information, lors de ce freeze avec un joli écran tout noir, même un
control+alt+suppr ne permet pas de rebooter la machine. Je suis obligé de
l'éteindre avec le bouton power à la main. J'ajoute que, très honnêtement,
une erreur de syntaxe de ma part au moment de l'édition est exclue car
c'est vraiment une opération que j'ai déjà faite une paquet de fois sans
jamais aucun souci (mais avec les ordinateurs utilisaient un bios pas
un UEFI).
J'ai entendu parlé d'options de sécurité de boot au niveau de UEFI alors
je suis aller dans le bios (enfin l'UEFI) et j'y ai trouvé des options
qui pourraient être en lien avec mon problème mais à chaque fois la valeur
de l'option correspondait à quelque chose qui allait dans le sens de
"sécurité désactivée". Par exemple, j'ai une option "Server Security" =>
"Secure boot settings" et là j'ai :
Current secure boot state => disabled
Secure boot enforcement => disabled
Donc a priori, ce n'est pas en mettant sur enabled que mon problème
risque de s'arranger. Bref, sauf erreur bien sûr, je n'ai trouvé aucune
modif dans ce machin qui pourrait aller dans mon sens. Toutefois, la
piste d'une config au niveau de l'UEFI reste pour moi la plus probable.
J'ai essayé dans le boot grub de mettre à la main diverses options pour
voir :
- mem=4g => freeze (en me disant peut-être qu'avec seulement 256m ça lui plaisait pas)
- ipv6.disable=1 => freeze (pour tester une autre option qu'un truc en rapport avec la RAM)
J'ai aussi tenté une installation (sans souci) de Debian Jessie en me disant
que, peut-être, le grub de Ubuntu était un peu trop vieux. Mais je constate
exactement le même phénomène que sous Ubuntu 14.04. La seule différence, c'est
que l'écran n'est pas tout noir au moment du freeze. J'ai juste ces 3 lignes :
------------------------------------
Booting a command list
Loading Linux 3.16.0.4-amd64 ...
Loading initial ramdisk ...
------------------------------------
Et c'est tout. Comme sous Ubuntu, un control+alt+suppr est sans effet.
J'ai aussi essayé de modifier les options de boot du noyau via les fichiers
de conf de grub, notamment en éditant le fichier /etc/default/grub et
en remplaçant :
GRUB_CMDLINE_LINUX=""
par
GRUB_CMDLINE_LINUX="mem=256m"
puis en faisant un « update-gub » en ligne de commande. Même résultat (sauf que
cette-fois j'ai un entrée de boot dans le menu grub qui freeze tout le temps ;)).
Ce problème me gène un peu car je me dis que, si ça se trouve, la moindre mise
à jour du noyau et paf mon serveur ne démarre plus. Pas glop. ;)
Voilà, si vous avez une idée sur comment résoudre ce problème, je serais
vraiment curieux d'avoir vos lumières.
Merci d'avance pour votre aide.
François Lafont
PS: question complètement accessoire : c'est possible de limiter la RAM
disponible pour l'OS sans passer par "grub + une option de boot du noyau" ? ;)
En 48 lignes Pascal Hambourg a écrit dans news:mvjrg1$1g4d$ le mardi, 13 octobre 2015 à 23:01:53 :
L'initramfs est enfoui dans le kernel lui-même (je suppose dans vmlinuz ? )
C'est une possibilité qui existe, il y a une option dans le .config pour inclure un initramfs dans l'image du noyau. Mais les distributions utilisent plutôt un initramfs séparé, plus souple car il peut être reconstruit sans devoir reconstruire l'image du noyau.
J'ai déjà vu qu'il est possible de manipuler cette configuration, si je trouve un moment je vais me compiler un noyau en vue d'inclure l'initramfs dans l'image, je vais faire cela dans une virtualbox, après je vais casser le système voir si je tombe dans l'initramfs comme auparavant.
Dans les architectures amd64 et i386 de Debian il y a les paquets grub-pc (qui sert à installer un chargeur GRUB 2 BIOS), grub-efi-amd64 (qui sert à installer un chargeur GRUB 2 EFI 64 bits), grub-efi-ia32 (qui sert à installer un chargeur GRUB 2 EFI 32 bits sur les quelques plates-formes EFI 32 bits). Ces paquets s'excluent l'un l'autre mais on peut les installer successivement pour installer les chargeurs d'amorçage correspondants.
J'ai pas eu la chance d'aller jusqu'au bout de mon installation en UEFI, cet ordinateur là ne m'appartenait pas et au moment du partitionnement, l'installateur m'annonçait que le disque dur 750 G était vide, il voulait installer linux sur tout le disque. J'ai renoncé et suis revenu sur legacy/secure-boot=off pour pouvoir l'installer. Où était l'erreur ? Malheureusement un peu tard pour le savoir....
dyrmak -- ¿ Cómo era aquello del rayo verde ? ++++ --- ++++ Linux operating system ++++ --- ++++
En 48 lignes Pascal Hambourg a écrit
dans news:mvjrg1$1g4d$1@saria.nerim.net
le mardi, 13 octobre 2015 à 23:01:53 :
L'initramfs est enfoui dans le kernel lui-même (je suppose dans
vmlinuz ? )
C'est une possibilité qui existe, il y a une option dans le .config pour
inclure un initramfs dans l'image du noyau. Mais les distributions
utilisent plutôt un initramfs séparé, plus souple car il peut être
reconstruit sans devoir reconstruire l'image du noyau.
J'ai déjà vu qu'il est possible de manipuler cette configuration,
si je trouve un moment je vais me compiler un noyau en vue d'inclure
l'initramfs dans l'image, je vais faire cela dans une virtualbox,
après je vais casser le système voir si je tombe dans l'initramfs
comme auparavant.
Dans les architectures amd64 et i386 de Debian il y a les paquets
grub-pc (qui sert à installer un chargeur GRUB 2 BIOS), grub-efi-amd64
(qui sert à installer un chargeur GRUB 2 EFI 64 bits), grub-efi-ia32
(qui sert à installer un chargeur GRUB 2 EFI 32 bits sur les quelques
plates-formes EFI 32 bits). Ces paquets s'excluent l'un l'autre mais on
peut les installer successivement pour installer les chargeurs
d'amorçage correspondants.
J'ai pas eu la chance d'aller jusqu'au bout de mon installation en UEFI,
cet ordinateur là ne m'appartenait pas et au moment du
partitionnement, l'installateur m'annonçait que le disque dur 750 G était
vide, il voulait installer linux sur tout le disque. J'ai renoncé et
suis revenu sur legacy/secure-boot=off pour pouvoir l'installer.
Où était l'erreur ? Malheureusement un peu tard pour le savoir....
dyrmak
--
¿ Cómo era aquello del rayo verde ?
++++ --- ++++
Linux operating system
++++ --- ++++
En 48 lignes Pascal Hambourg a écrit dans news:mvjrg1$1g4d$ le mardi, 13 octobre 2015 à 23:01:53 :
L'initramfs est enfoui dans le kernel lui-même (je suppose dans vmlinuz ? )
C'est une possibilité qui existe, il y a une option dans le .config pour inclure un initramfs dans l'image du noyau. Mais les distributions utilisent plutôt un initramfs séparé, plus souple car il peut être reconstruit sans devoir reconstruire l'image du noyau.
J'ai déjà vu qu'il est possible de manipuler cette configuration, si je trouve un moment je vais me compiler un noyau en vue d'inclure l'initramfs dans l'image, je vais faire cela dans une virtualbox, après je vais casser le système voir si je tombe dans l'initramfs comme auparavant.
Dans les architectures amd64 et i386 de Debian il y a les paquets grub-pc (qui sert à installer un chargeur GRUB 2 BIOS), grub-efi-amd64 (qui sert à installer un chargeur GRUB 2 EFI 64 bits), grub-efi-ia32 (qui sert à installer un chargeur GRUB 2 EFI 32 bits sur les quelques plates-formes EFI 32 bits). Ces paquets s'excluent l'un l'autre mais on peut les installer successivement pour installer les chargeurs d'amorçage correspondants.
J'ai pas eu la chance d'aller jusqu'au bout de mon installation en UEFI, cet ordinateur là ne m'appartenait pas et au moment du partitionnement, l'installateur m'annonçait que le disque dur 750 G était vide, il voulait installer linux sur tout le disque. J'ai renoncé et suis revenu sur legacy/secure-boot=off pour pouvoir l'installer. Où était l'erreur ? Malheureusement un peu tard pour le savoir....
dyrmak -- ¿ Cómo era aquello del rayo verde ? ++++ --- ++++ Linux operating system ++++ --- ++++
Pascal Hambourg
dyrmak a écrit :
si je trouve un moment je vais me compiler un noyau en vue d'inclure l'initramfs dans l'image, je vais faire cela dans une virtualbox, après je vais casser le système voir si je tombe dans l'initramfs comme auparavant.
Ça dépendra du contenu de l'initramfs. Il faut notamment que le script init lance un shell de secours si la racine finale ne peut être montée.
Une particularité de l'initramfs intégré au noyau à prendre en compte : je ne suis pas sûr qu'on puisse y inclure des modules du noyau. En effet pour cela il faudrait que l'initramfs soit construit pendant la compilation du noyau, après la compilation des modules et avant la construction de l'image du noyau. J'ignore si c'est possible.
J'ai pas eu la chance d'aller jusqu'au bout de mon installation en UEFI, cet ordinateur là ne m'appartenait pas et au moment du partitionnement, l'installateur m'annonçait que le disque dur 750 G était vide, il voulait installer linux sur tout le disque. J'ai renoncé et suis revenu sur legacy/secure-boot=off pour pouvoir l'installer. Où était l'erreur ?
Avec l'installateur de quelle distribution ? J'ai déjà vu cela plusieurs fois avec des disques qui avaient été auparavant partitionnés en GPT puis repartitionnés en MBR/MSDOS mais sur lesquels restaient des traces de GPT, notamment la signature caractéristique dans le secteur n° 2. Mais il ne devrait pas y avoir de différence entre le démarrage en mode UEFI avec ou sans secure boot ou en mode BIOS/legacy.
dyrmak a écrit :
si je trouve un moment je vais me compiler un noyau en vue d'inclure
l'initramfs dans l'image, je vais faire cela dans une virtualbox,
après je vais casser le système voir si je tombe dans l'initramfs
comme auparavant.
Ça dépendra du contenu de l'initramfs. Il faut notamment que le script
init lance un shell de secours si la racine finale ne peut être montée.
Une particularité de l'initramfs intégré au noyau à prendre en compte :
je ne suis pas sûr qu'on puisse y inclure des modules du noyau. En effet
pour cela il faudrait que l'initramfs soit construit pendant la
compilation du noyau, après la compilation des modules et avant la
construction de l'image du noyau. J'ignore si c'est possible.
J'ai pas eu la chance d'aller jusqu'au bout de mon installation en UEFI,
cet ordinateur là ne m'appartenait pas et au moment du
partitionnement, l'installateur m'annonçait que le disque dur 750 G était
vide, il voulait installer linux sur tout le disque. J'ai renoncé et
suis revenu sur legacy/secure-boot=off pour pouvoir l'installer.
Où était l'erreur ?
Avec l'installateur de quelle distribution ? J'ai déjà vu cela plusieurs
fois avec des disques qui avaient été auparavant partitionnés en GPT
puis repartitionnés en MBR/MSDOS mais sur lesquels restaient des traces
de GPT, notamment la signature caractéristique dans le secteur n° 2.
Mais il ne devrait pas y avoir de différence entre le démarrage en mode
UEFI avec ou sans secure boot ou en mode BIOS/legacy.
si je trouve un moment je vais me compiler un noyau en vue d'inclure l'initramfs dans l'image, je vais faire cela dans une virtualbox, après je vais casser le système voir si je tombe dans l'initramfs comme auparavant.
Ça dépendra du contenu de l'initramfs. Il faut notamment que le script init lance un shell de secours si la racine finale ne peut être montée.
Une particularité de l'initramfs intégré au noyau à prendre en compte : je ne suis pas sûr qu'on puisse y inclure des modules du noyau. En effet pour cela il faudrait que l'initramfs soit construit pendant la compilation du noyau, après la compilation des modules et avant la construction de l'image du noyau. J'ignore si c'est possible.
J'ai pas eu la chance d'aller jusqu'au bout de mon installation en UEFI, cet ordinateur là ne m'appartenait pas et au moment du partitionnement, l'installateur m'annonçait que le disque dur 750 G était vide, il voulait installer linux sur tout le disque. J'ai renoncé et suis revenu sur legacy/secure-boot=off pour pouvoir l'installer. Où était l'erreur ?
Avec l'installateur de quelle distribution ? J'ai déjà vu cela plusieurs fois avec des disques qui avaient été auparavant partitionnés en GPT puis repartitionnés en MBR/MSDOS mais sur lesquels restaient des traces de GPT, notamment la signature caractéristique dans le secteur n° 2. Mais il ne devrait pas y avoir de différence entre le démarrage en mode UEFI avec ou sans secure boot ou en mode BIOS/legacy.
dyrmak
En 29 lignes Pascal Hambourg a écrit dans news:mvm6du$27eb$ le mercredi, 14 octobre 2015 à 20:20:46 :
Ça dépendra du contenu de l'initramfs. Il faut notamment que le script init lance un shell de secours si la racine finale ne peut être montée.
Une particularité de l'initramfs intégré au noyau à prendre en compte : je ne suis pas sûr qu'on puisse y inclure des modules du noyau. En effet pour cela il faudrait que l'initramfs soit construit pendant la compilation du noyau, après la compilation des modules et avant la construction de l'image du noyau. J'ignore si c'est possible.
Avant de compiler ce noyau en vue d'y intégrer l'initramfs, je vais consulter un minimum de documentation et ce que j'en savais c'est que dans ce cas l'initramfs contient par défault une séquence avec un shell de secours si la racine finale ne peut pas être montée, maintenant pour les modules à charger effectivement ici c'est encore l'histoire de la poule et de l'½uf, si je n'arrive pas à mettre des modules du kernel en question, peut être je pourrais décompresser un initrd existant et essayer d'intégrer les modules qui s'y trouvent ? Il faudrait voir si c'est possible.
Avec l'installateur de quelle distribution ? J'ai déjà vu cela plusieurs fois avec des disques qui avaient été auparavant partitionnés en GPT puis repartitionnés en MBR/MSDOS mais sur lesquels restaient des traces de GPT, notamment la signature caractéristique dans le secteur n° 2. Mais il ne devrait pas y avoir de différence entre le démarrage en mode UEFI avec ou sans secure boot ou en mode BIOS/legacy.
C'était un Lenovo G.... dans sa boîte d'emballage, mois d'aôut 2014 Mint 17.0. J'avais essayé wheezy, knoppix et plusieurs autres Mint 11 13 16 mais elles avaient toutes un problème, wheezy n'avait pas de réseau, knoppix était fonctionnelle mais je ne savais pas l'installer dans sa version 64 bits, les autres Mint n'avaient pas n'ont plus le réseau.
La seule reconnaisant le réseau (wifi/ethernet) et à pouvoir être installée en mode UEFI ou Legacy était Mint17.0, mais comme je l'ai dit auparavant elle voulait s'installer sur tout le disque, ce qui m'a fait basculer en mode Legacy/secure-boot=off.
dyrmak -- La sombra del arbolito ++++ --- ++++ Linux operating system ++++ --- ++++
En 29 lignes Pascal Hambourg a écrit
dans news:mvm6du$27eb$1@saria.nerim.net
le mercredi, 14 octobre 2015 à 20:20:46 :
Ça dépendra du contenu de l'initramfs. Il faut notamment que le script
init lance un shell de secours si la racine finale ne peut être montée.
Une particularité de l'initramfs intégré au noyau à prendre en compte :
je ne suis pas sûr qu'on puisse y inclure des modules du noyau. En effet
pour cela il faudrait que l'initramfs soit construit pendant la
compilation du noyau, après la compilation des modules et avant la
construction de l'image du noyau. J'ignore si c'est possible.
Avant de compiler ce noyau en vue d'y intégrer l'initramfs, je vais
consulter un minimum de documentation et ce que j'en savais c'est que
dans ce cas l'initramfs contient par défault une séquence avec un shell
de secours si la racine finale ne peut pas être montée, maintenant pour
les modules à charger effectivement ici c'est encore l'histoire de la
poule et de l'½uf, si je n'arrive pas à mettre des modules du kernel en
question, peut être je pourrais décompresser un initrd existant et
essayer d'intégrer les modules qui s'y trouvent ? Il faudrait voir
si c'est possible.
Avec l'installateur de quelle distribution ? J'ai déjà vu cela plusieurs
fois avec des disques qui avaient été auparavant partitionnés en GPT
puis repartitionnés en MBR/MSDOS mais sur lesquels restaient des traces
de GPT, notamment la signature caractéristique dans le secteur n° 2.
Mais il ne devrait pas y avoir de différence entre le démarrage en mode
UEFI avec ou sans secure boot ou en mode BIOS/legacy.
C'était un Lenovo G.... dans sa boîte d'emballage, mois d'aôut 2014
Mint 17.0.
J'avais essayé wheezy, knoppix et plusieurs autres Mint 11 13 16 mais
elles avaient toutes un problème, wheezy n'avait pas de réseau, knoppix
était fonctionnelle mais je ne savais pas l'installer dans sa version
64 bits, les autres Mint n'avaient pas n'ont plus le réseau.
La seule reconnaisant le réseau (wifi/ethernet) et à pouvoir être installée
en mode UEFI ou Legacy était Mint17.0, mais comme je l'ai dit
auparavant elle voulait s'installer sur tout le disque, ce qui m'a
fait basculer en mode Legacy/secure-boot=off.
dyrmak
--
La sombra del arbolito
++++ --- ++++
Linux operating system
++++ --- ++++
En 29 lignes Pascal Hambourg a écrit dans news:mvm6du$27eb$ le mercredi, 14 octobre 2015 à 20:20:46 :
Ça dépendra du contenu de l'initramfs. Il faut notamment que le script init lance un shell de secours si la racine finale ne peut être montée.
Une particularité de l'initramfs intégré au noyau à prendre en compte : je ne suis pas sûr qu'on puisse y inclure des modules du noyau. En effet pour cela il faudrait que l'initramfs soit construit pendant la compilation du noyau, après la compilation des modules et avant la construction de l'image du noyau. J'ignore si c'est possible.
Avant de compiler ce noyau en vue d'y intégrer l'initramfs, je vais consulter un minimum de documentation et ce que j'en savais c'est que dans ce cas l'initramfs contient par défault une séquence avec un shell de secours si la racine finale ne peut pas être montée, maintenant pour les modules à charger effectivement ici c'est encore l'histoire de la poule et de l'½uf, si je n'arrive pas à mettre des modules du kernel en question, peut être je pourrais décompresser un initrd existant et essayer d'intégrer les modules qui s'y trouvent ? Il faudrait voir si c'est possible.
Avec l'installateur de quelle distribution ? J'ai déjà vu cela plusieurs fois avec des disques qui avaient été auparavant partitionnés en GPT puis repartitionnés en MBR/MSDOS mais sur lesquels restaient des traces de GPT, notamment la signature caractéristique dans le secteur n° 2. Mais il ne devrait pas y avoir de différence entre le démarrage en mode UEFI avec ou sans secure boot ou en mode BIOS/legacy.
C'était un Lenovo G.... dans sa boîte d'emballage, mois d'aôut 2014 Mint 17.0. J'avais essayé wheezy, knoppix et plusieurs autres Mint 11 13 16 mais elles avaient toutes un problème, wheezy n'avait pas de réseau, knoppix était fonctionnelle mais je ne savais pas l'installer dans sa version 64 bits, les autres Mint n'avaient pas n'ont plus le réseau.
La seule reconnaisant le réseau (wifi/ethernet) et à pouvoir être installée en mode UEFI ou Legacy était Mint17.0, mais comme je l'ai dit auparavant elle voulait s'installer sur tout le disque, ce qui m'a fait basculer en mode Legacy/secure-boot=off.
dyrmak -- La sombra del arbolito ++++ --- ++++ Linux operating system ++++ --- ++++
Pascal Hambourg
dyrmak a écrit :
En 29 lignes Pascal Hambourg a écrit
Une particularité de l'initramfs intégré au noyau à prendre en compte : je ne suis pas sûr qu'on puisse y inclure des modules du noyau. En effet pour cela il faudrait que l'initramfs soit construit pendant la compilation du noyau, après la compilation des modules et avant la construction de l'image du noyau. J'ignore si c'est possible.
Avant de compiler ce noyau en vue d'y intégrer l'initramfs, je vais consulter un minimum de documentation et ce que j'en savais c'est que dans ce cas l'initramfs contient par défault une séquence avec un shell de secours si la racine finale ne peut pas être montée,
Il n'existe pas de contenu par défaut de l'initramfs. Il dépend du générateur qui l'a créé, et il y en a autant que de distributions qui y mettent ce dont elles ont besoin.
maintenant pour les modules à charger effectivement ici c'est encore l'histoire de la poule et de l'½uf, si je n'arrive pas à mettre des modules du kernel en question, peut être je pourrais décompresser un initrd existant et essayer d'intégrer les modules qui s'y trouvent ? Il faudrait voir si c'est possible.
Le noyau et ses modules sont intimement liés et sont compilés ensemble. Pas sûr que les modules d'un noyau fonctionnent avec un autre noyau, même de la même version. Par contre il doit être possible de procéder en plusieurs temps : 1) Compilation classique du noyau et des modules. 2) Construction de l'initramfs. 3) Reconstruction de l'image du noyau avec le nouvel initramfs.
Note aussi que tu peux compiler "en dur" tous les modules dont tu as besoin lors de l'exécution de l'initramfs.
Avec l'installateur de quelle distribution ? J'ai déjà vu cela plusieurs fois avec des disques qui avaient été auparavant partitionnés en GPT puis repartitionnés en MBR/MSDOS mais sur lesquels restaient des traces de GPT, notamment la signature caractéristique dans le secteur n° 2.
J'ai oublié de préciser, s'il était besoin, qu'il suffisait d'effacer le secteur d'en-tête principal contenant cette signature GPT pour que l'installateur voie la table de partition MBR/MSDOS.
Mais il ne devrait pas y avoir de différence entre le démarrage en mode UEFI avec ou sans secure boot ou en mode BIOS/legacy.
C'était un Lenovo G.... dans sa boîte d'emballage, mois d'aôut 2014 Mint 17.0.
[...]
La seule reconnaisant le réseau (wifi/ethernet) et à pouvoir être installée en mode UEFI ou Legacy était Mint17.0, mais comme je l'ai dit auparavant elle voulait s'installer sur tout le disque, ce qui m'a fait basculer en mode Legacy/secure-boot=off.
Je n'ai jamais utilisé l'installateur de Mint, aussi j'ignore comment il fonctionne et la cause de cette différence entre UEFI et legacy. La seule hypothèse que me vient est une limitation du même style que celui de Windows, forçant le format GPT en UEFI et le format MSDOS en legacy, mais j'ai peine à y croire.
dyrmak a écrit :
En 29 lignes Pascal Hambourg a écrit
Une particularité de l'initramfs intégré au noyau à prendre en compte :
je ne suis pas sûr qu'on puisse y inclure des modules du noyau. En effet
pour cela il faudrait que l'initramfs soit construit pendant la
compilation du noyau, après la compilation des modules et avant la
construction de l'image du noyau. J'ignore si c'est possible.
Avant de compiler ce noyau en vue d'y intégrer l'initramfs, je vais
consulter un minimum de documentation et ce que j'en savais c'est que
dans ce cas l'initramfs contient par défault une séquence avec un shell
de secours si la racine finale ne peut pas être montée,
Il n'existe pas de contenu par défaut de l'initramfs. Il dépend du
générateur qui l'a créé, et il y en a autant que de distributions qui y
mettent ce dont elles ont besoin.
maintenant pour
les modules à charger effectivement ici c'est encore l'histoire de la
poule et de l'½uf, si je n'arrive pas à mettre des modules du kernel en
question, peut être je pourrais décompresser un initrd existant et
essayer d'intégrer les modules qui s'y trouvent ? Il faudrait voir
si c'est possible.
Le noyau et ses modules sont intimement liés et sont compilés ensemble.
Pas sûr que les modules d'un noyau fonctionnent avec un autre noyau,
même de la même version. Par contre il doit être possible de procéder en
plusieurs temps :
1) Compilation classique du noyau et des modules.
2) Construction de l'initramfs.
3) Reconstruction de l'image du noyau avec le nouvel initramfs.
Note aussi que tu peux compiler "en dur" tous les modules dont tu as
besoin lors de l'exécution de l'initramfs.
Avec l'installateur de quelle distribution ? J'ai déjà vu cela plusieurs
fois avec des disques qui avaient été auparavant partitionnés en GPT
puis repartitionnés en MBR/MSDOS mais sur lesquels restaient des traces
de GPT, notamment la signature caractéristique dans le secteur n° 2.
J'ai oublié de préciser, s'il était besoin, qu'il suffisait d'effacer le
secteur d'en-tête principal contenant cette signature GPT pour que
l'installateur voie la table de partition MBR/MSDOS.
Mais il ne devrait pas y avoir de différence entre le démarrage en mode
UEFI avec ou sans secure boot ou en mode BIOS/legacy.
C'était un Lenovo G.... dans sa boîte d'emballage, mois d'aôut 2014
Mint 17.0.
[...]
La seule reconnaisant le réseau (wifi/ethernet) et à pouvoir être installée
en mode UEFI ou Legacy était Mint17.0, mais comme je l'ai dit
auparavant elle voulait s'installer sur tout le disque, ce qui m'a
fait basculer en mode Legacy/secure-boot=off.
Je n'ai jamais utilisé l'installateur de Mint, aussi j'ignore comment il
fonctionne et la cause de cette différence entre UEFI et legacy. La
seule hypothèse que me vient est une limitation du même style que celui
de Windows, forçant le format GPT en UEFI et le format MSDOS en legacy,
mais j'ai peine à y croire.
Une particularité de l'initramfs intégré au noyau à prendre en compte : je ne suis pas sûr qu'on puisse y inclure des modules du noyau. En effet pour cela il faudrait que l'initramfs soit construit pendant la compilation du noyau, après la compilation des modules et avant la construction de l'image du noyau. J'ignore si c'est possible.
Avant de compiler ce noyau en vue d'y intégrer l'initramfs, je vais consulter un minimum de documentation et ce que j'en savais c'est que dans ce cas l'initramfs contient par défault une séquence avec un shell de secours si la racine finale ne peut pas être montée,
Il n'existe pas de contenu par défaut de l'initramfs. Il dépend du générateur qui l'a créé, et il y en a autant que de distributions qui y mettent ce dont elles ont besoin.
maintenant pour les modules à charger effectivement ici c'est encore l'histoire de la poule et de l'½uf, si je n'arrive pas à mettre des modules du kernel en question, peut être je pourrais décompresser un initrd existant et essayer d'intégrer les modules qui s'y trouvent ? Il faudrait voir si c'est possible.
Le noyau et ses modules sont intimement liés et sont compilés ensemble. Pas sûr que les modules d'un noyau fonctionnent avec un autre noyau, même de la même version. Par contre il doit être possible de procéder en plusieurs temps : 1) Compilation classique du noyau et des modules. 2) Construction de l'initramfs. 3) Reconstruction de l'image du noyau avec le nouvel initramfs.
Note aussi que tu peux compiler "en dur" tous les modules dont tu as besoin lors de l'exécution de l'initramfs.
Avec l'installateur de quelle distribution ? J'ai déjà vu cela plusieurs fois avec des disques qui avaient été auparavant partitionnés en GPT puis repartitionnés en MBR/MSDOS mais sur lesquels restaient des traces de GPT, notamment la signature caractéristique dans le secteur n° 2.
J'ai oublié de préciser, s'il était besoin, qu'il suffisait d'effacer le secteur d'en-tête principal contenant cette signature GPT pour que l'installateur voie la table de partition MBR/MSDOS.
Mais il ne devrait pas y avoir de différence entre le démarrage en mode UEFI avec ou sans secure boot ou en mode BIOS/legacy.
C'était un Lenovo G.... dans sa boîte d'emballage, mois d'aôut 2014 Mint 17.0.
[...]
La seule reconnaisant le réseau (wifi/ethernet) et à pouvoir être installée en mode UEFI ou Legacy était Mint17.0, mais comme je l'ai dit auparavant elle voulait s'installer sur tout le disque, ce qui m'a fait basculer en mode Legacy/secure-boot=off.
Je n'ai jamais utilisé l'installateur de Mint, aussi j'ignore comment il fonctionne et la cause de cette différence entre UEFI et legacy. La seule hypothèse que me vient est une limitation du même style que celui de Windows, forçant le format GPT en UEFI et le format MSDOS en legacy, mais j'ai peine à y croire.
