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 98 lignes Francois Lafont a écrit dans news:56047a46$0$3324$ le vendredi, 25 septembre 2015 à 00:33:42 :
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.
Autant que je me souvienne, sur un laptop tout neuf ( sans avoir booté aucun OS) je suis allé directement dans le bios, (UEFI) je l'ai mis en mode-legacy ET j'ai enlevé le secure-boot, je ne dis pas que ça ferait fonctionner un multiboot mais le linux ensuite s'installa puis démarra et depuis je n'ai plus entendu parler....
dyrmak -- mientras tanto ++++ --- ++++ Linux operating system ++++ --- ++++
En 98 lignes Francois Lafont a écrit
dans news:56047a46$0$3324$426a74cc@news.free.fr
le vendredi, 25 septembre 2015 à 00:33:42 :
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.
Autant que je me souvienne, sur un laptop tout neuf ( sans avoir booté
aucun OS) je suis allé directement dans le bios, (UEFI) je l'ai mis
en mode-legacy ET j'ai enlevé le secure-boot, je ne dis pas que ça
ferait fonctionner un multiboot mais le linux ensuite s'installa puis
démarra et depuis je n'ai plus entendu parler....
dyrmak
--
mientras tanto
++++ --- ++++
Linux operating system
++++ --- ++++
En 98 lignes Francois Lafont a écrit dans news:56047a46$0$3324$ le vendredi, 25 septembre 2015 à 00:33:42 :
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.
Autant que je me souvienne, sur un laptop tout neuf ( sans avoir booté aucun OS) je suis allé directement dans le bios, (UEFI) je l'ai mis en mode-legacy ET j'ai enlevé le secure-boot, je ne dis pas que ça ferait fonctionner un multiboot mais le linux ensuite s'installa puis démarra et depuis je n'ai plus entendu parler....
dyrmak -- mientras tanto ++++ --- ++++ Linux operating system ++++ --- ++++
Tonton Th
On 2015-09-24, Francois Lafont wrote:
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" ? ;)
Vieux souvenir : un module noyau à charger au boot qui "capturait" une zone de mémoire physique et empéchait le noyau de s'en servir par la suite.
Mais c'est un souvenir un peu flou...
-- ====== http://la.buvette.org/photos/myrys/20ans/fx/colorcube.avi ===== I'm <tth> on freenode. Film at 11, take your popcorn.
On 2015-09-24, Francois Lafont <francois.lafont@nospam.invalid> wrote:
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" ? ;)
Vieux souvenir : un module noyau à charger au boot qui
"capturait" une zone de mémoire physique et empéchait
le noyau de s'en servir par la suite.
Mais c'est un souvenir un peu flou...
--
====== http://la.buvette.org/photos/myrys/20ans/fx/colorcube.avi =====
I'm <tth> on freenode. Film at 11, take your popcorn.
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" ? ;)
Vieux souvenir : un module noyau à charger au boot qui "capturait" une zone de mémoire physique et empéchait le noyau de s'en servir par la suite.
Mais c'est un souvenir un peu flou...
-- ====== http://la.buvette.org/photos/myrys/20ans/fx/colorcube.avi ===== I'm <tth> on freenode. Film at 11, take your popcorn.
Francois Lafont
On 25/09/2015 09:32, dyrmak wrote:
En 98 lignes Francois Lafont a écrit
Désolé si c'est trop long. Je ne sais pas pourquoi, j'ai toujours peur de ne pas bien me faire comprendre, d'oublier un élément important etc. Alors c'est vrai que je suis un peu trop bavard du coup. ;)
Autant que je me souvienne, sur un laptop tout neuf ( sans avoir booté aucun OS) je suis allé directement dans le bios, (UEFI) je l'ai mis en mode-legacy ET j'ai enlevé le secure-boot, je ne dis pas que ça ferait fonctionner un multiboot mais le linux ensuite s'installa puis démarra et depuis je n'ai plus entendu parler....
Et bien, oui, tu as raison. C'est ce qui s'est passé pour moi. Mais pourtant, comme je l'ai indiqué dans mon message précédent, j'avais *déjà* tenté de faire cela... sans succès. J'avais une clé USB bootable via une iso d'un installateur Ubuntu 14.04 et peut-être que cette image iso était un peu ancienne ou je ne sais quoi (ça faisait bien au moins 1 an que j'avais cette clé USB). Toujours est-il que j'ai recommencé la procédure que tu indiques en passant cette fois via un boot par le réseau avec un netboot.tar.gz téléchargé de la semaine dernière et là c'est passé comme une lettre à la poste.
Donc merci de m'avoir incité à retenter la manip. ;)
Ceci étant, je ne considère pas mon problème comme résolu car je ne comprends toujours pas pourquoi diable je ne peux pas modifier à la main un menu de boot Grub en UEFI alors que tout ce qui concerne le "secure boot" est désactivé. Je dirais même d'ailleurs je payerais cher pour avoir le fin mot de l'histoire. ;)
S'il y a des experts UEFI dans la salle, je serais vraiment très curieux d'avoir vos lumières.
Merci.
-- François Lafont
On 25/09/2015 09:32, dyrmak wrote:
En 98 lignes Francois Lafont a écrit
Désolé si c'est trop long. Je ne sais pas pourquoi, j'ai
toujours peur de ne pas bien me faire comprendre, d'oublier
un élément important etc. Alors c'est vrai que je suis un peu
trop bavard du coup. ;)
Autant que je me souvienne, sur un laptop tout neuf ( sans avoir booté
aucun OS) je suis allé directement dans le bios, (UEFI) je l'ai mis
en mode-legacy ET j'ai enlevé le secure-boot, je ne dis pas que ça
ferait fonctionner un multiboot mais le linux ensuite s'installa puis
démarra et depuis je n'ai plus entendu parler....
Et bien, oui, tu as raison. C'est ce qui s'est passé pour moi. Mais pourtant,
comme je l'ai indiqué dans mon message précédent, j'avais *déjà* tenté de faire
cela... sans succès. J'avais une clé USB bootable via une iso d'un installateur
Ubuntu 14.04 et peut-être que cette image iso était un peu ancienne ou je ne
sais quoi (ça faisait bien au moins 1 an que j'avais cette clé USB). Toujours
est-il que j'ai recommencé la procédure que tu indiques en passant cette fois
via un boot par le réseau avec un netboot.tar.gz téléchargé de la semaine
dernière et là c'est passé comme une lettre à la poste.
Donc merci de m'avoir incité à retenter la manip. ;)
Ceci étant, je ne considère pas mon problème comme résolu car je ne comprends
toujours pas pourquoi diable je ne peux pas modifier à la main un menu de boot
Grub en UEFI alors que tout ce qui concerne le "secure boot" est désactivé. Je
dirais même d'ailleurs je payerais cher pour avoir le fin mot de l'histoire. ;)
S'il y a des experts UEFI dans la salle, je serais vraiment très curieux d'avoir
vos lumières.
Désolé si c'est trop long. Je ne sais pas pourquoi, j'ai toujours peur de ne pas bien me faire comprendre, d'oublier un élément important etc. Alors c'est vrai que je suis un peu trop bavard du coup. ;)
Autant que je me souvienne, sur un laptop tout neuf ( sans avoir booté aucun OS) je suis allé directement dans le bios, (UEFI) je l'ai mis en mode-legacy ET j'ai enlevé le secure-boot, je ne dis pas que ça ferait fonctionner un multiboot mais le linux ensuite s'installa puis démarra et depuis je n'ai plus entendu parler....
Et bien, oui, tu as raison. C'est ce qui s'est passé pour moi. Mais pourtant, comme je l'ai indiqué dans mon message précédent, j'avais *déjà* tenté de faire cela... sans succès. J'avais une clé USB bootable via une iso d'un installateur Ubuntu 14.04 et peut-être que cette image iso était un peu ancienne ou je ne sais quoi (ça faisait bien au moins 1 an que j'avais cette clé USB). Toujours est-il que j'ai recommencé la procédure que tu indiques en passant cette fois via un boot par le réseau avec un netboot.tar.gz téléchargé de la semaine dernière et là c'est passé comme une lettre à la poste.
Donc merci de m'avoir incité à retenter la manip. ;)
Ceci étant, je ne considère pas mon problème comme résolu car je ne comprends toujours pas pourquoi diable je ne peux pas modifier à la main un menu de boot Grub en UEFI alors que tout ce qui concerne le "secure boot" est désactivé. Je dirais même d'ailleurs je payerais cher pour avoir le fin mot de l'histoire. ;)
S'il y a des experts UEFI dans la salle, je serais vraiment très curieux d'avoir vos lumières.
Merci.
-- François Lafont
dyrmak
En 38 lignes Francois Lafont a écrit dans news:5609b3fa$0$21235$ le lundi, 28 septembre 2015 à 23:41:14 :
Désolé si c'est trop long. Je ne sais pas pourquoi, j'ai toujours peur de ne pas bien me faire comprendre, d'oublier un élément important etc. Alors c'est vrai que je suis un peu trop bavard du coup. ;)
Bonjour,
Bientôt INN va faire disparaître ce HEADER, à moins de compter les lignes à la main, j'aurai des soucis pour mon script, ;]
Et bien, oui, tu as raison. C'est ce qui s'est passé pour moi. Mais pourtant, comme je l'ai indiqué dans mon message précédent, j'avais *déjà* tenté de faire cela... sans succès. J'avais une clé USB bootable via une iso d'un installateur Ubuntu 14.04 et peut-être que cette image iso était un peu ancienne ou je ne sais quoi (ça faisait bien au moins 1 an que j'avais cette clé USB). Toujours est-il que j'ai recommencé la procédure que tu indiques en passant cette fois via un boot par le réseau avec un netboot.tar.gz téléchargé de la semaine dernière et là c'est passé comme une lettre à la poste.
Donc merci de m'avoir incité à retenter la manip. ;)
De rien, je n'y suis pour rien en fait, je n'ai fait que suggérer une piste. Dans le domaine UEFI/BIOS rien n'est encore définitif, j'en ai lu et relu pas mal de documentation, mais je ne peux pas dire que j'ai tout compris, loin s'en faut.
Ceci étant, je ne considère pas mon problème comme résolu car je ne comprends toujours pas pourquoi diable je ne peux pas modifier à la main un menu de boot Grub en UEFI alors que tout ce qui concerne le "secure boot" est désactivé. Je dirais même d'ailleurs je payerais cher pour avoir le fin mot de l'histoire. ;)
S'il y a des experts UEFI dans la salle, je serais vraiment très curieux d'avoir vos lumières.
Merci.
Si je comprends ta situation, tu es capable d'installer une distribution soit en mode legacy (ancien BIOS) ou en mode UEFI et tu veux ajouter une option pour qu'au boot la mémoire RAM soit limitée ?
Pour faire court, voici ce que me sort ma wheezy quand j'ai ajouté des options pour indiquer la taille de mon disque RAM pendant le boot:
La ramdisk que j'ai ajouté m'avait fait réfléchir si par accident elle n'allait pas contredire le fait que l'arborescence initiale qui est chargée (l'initrd) ne verrait pas la totalité de la RAM d'avant la déclaration de l'option.
Je ne me suis pas contenté de faire un update-grub ( en mode legacy ) mais j'ai fait aussi carrément un grub-install /dev/sda, ceinture et....
Autre chose que je crois comprendre, c'est que si une installation a été faite en UEFI, la distribution ne peut être bootée que sous ce mode, on peut le savoir en voyant la fstab, la partition boot EFI dans la GPT doit y apparaître, ou en faisant un cat /proc/<quelque chose>
Ce qui fait que le update-grub ou le grub-install ont une rallonge EFI et le "/dev/sda" doit probablement être plutôt une partition GPT à préciser.
Si la distribution est en mode legacy, dans ce cas là rien ne change et rien n'empêche de faire un grub-install classique après le update-grub, bien sûr, tout ceci à prendre avec des pincettes.
dyrmak -- Las experiencias engañan. ++++ --- ++++ Linux operating system ++++ --- ++++
En 38 lignes Francois Lafont a écrit
dans news:5609b3fa$0$21235$426a74cc@news.free.fr
le lundi, 28 septembre 2015 à 23:41:14 :
Désolé si c'est trop long. Je ne sais pas pourquoi, j'ai
toujours peur de ne pas bien me faire comprendre, d'oublier
un élément important etc. Alors c'est vrai que je suis un peu
trop bavard du coup. ;)
Bonjour,
Bientôt INN va faire disparaître ce HEADER, à moins de compter
les lignes à la main, j'aurai des soucis pour mon script, ;]
Et bien, oui, tu as raison. C'est ce qui s'est passé pour moi. Mais pourtant,
comme je l'ai indiqué dans mon message précédent, j'avais *déjà* tenté de faire
cela... sans succès. J'avais une clé USB bootable via une iso d'un installateur
Ubuntu 14.04 et peut-être que cette image iso était un peu ancienne ou je ne
sais quoi (ça faisait bien au moins 1 an que j'avais cette clé USB). Toujours
est-il que j'ai recommencé la procédure que tu indiques en passant cette fois
via un boot par le réseau avec un netboot.tar.gz téléchargé de la semaine
dernière et là c'est passé comme une lettre à la poste.
Donc merci de m'avoir incité à retenter la manip. ;)
De rien, je n'y suis pour rien en fait, je n'ai fait que suggérer une
piste.
Dans le domaine UEFI/BIOS rien n'est encore définitif, j'en ai lu et
relu pas mal de documentation, mais je ne peux pas dire que j'ai tout
compris, loin s'en faut.
Ceci étant, je ne considère pas mon problème comme résolu car je ne comprends
toujours pas pourquoi diable je ne peux pas modifier à la main un menu de boot
Grub en UEFI alors que tout ce qui concerne le "secure boot" est désactivé. Je
dirais même d'ailleurs je payerais cher pour avoir le fin mot de l'histoire. ;)
S'il y a des experts UEFI dans la salle, je serais vraiment très curieux d'avoir
vos lumières.
Merci.
Si je comprends ta situation, tu es capable d'installer une distribution
soit en mode legacy (ancien BIOS) ou en mode UEFI et tu veux ajouter
une option pour qu'au boot la mémoire RAM soit limitée ?
Pour faire court, voici ce que me sort ma wheezy quand j'ai ajouté
des options pour indiquer la taille de mon disque RAM pendant le boot:
La ramdisk que j'ai ajouté m'avait fait réfléchir si par accident elle
n'allait pas contredire le fait que l'arborescence initiale qui est
chargée (l'initrd) ne verrait pas la totalité de la RAM d'avant la
déclaration de l'option.
Je ne me suis pas contenté de faire un update-grub ( en mode legacy )
mais j'ai fait aussi carrément un grub-install /dev/sda, ceinture
et....
Autre chose que je crois comprendre, c'est que si une installation
a été faite en UEFI, la distribution ne peut être bootée que sous
ce mode, on peut le savoir en voyant la fstab, la partition boot EFI
dans la GPT doit y apparaître, ou en faisant un cat /proc/<quelque
chose>
Ce qui fait que le update-grub ou le grub-install ont une
rallonge EFI et le "/dev/sda" doit probablement être plutôt une
partition GPT à préciser.
Si la distribution est en mode legacy, dans ce cas là rien ne change
et rien n'empêche de faire un grub-install classique après le
update-grub, bien sûr, tout ceci à prendre avec des pincettes.
dyrmak
--
Las experiencias engañan.
++++ --- ++++
Linux operating system
++++ --- ++++
En 38 lignes Francois Lafont a écrit dans news:5609b3fa$0$21235$ le lundi, 28 septembre 2015 à 23:41:14 :
Désolé si c'est trop long. Je ne sais pas pourquoi, j'ai toujours peur de ne pas bien me faire comprendre, d'oublier un élément important etc. Alors c'est vrai que je suis un peu trop bavard du coup. ;)
Bonjour,
Bientôt INN va faire disparaître ce HEADER, à moins de compter les lignes à la main, j'aurai des soucis pour mon script, ;]
Et bien, oui, tu as raison. C'est ce qui s'est passé pour moi. Mais pourtant, comme je l'ai indiqué dans mon message précédent, j'avais *déjà* tenté de faire cela... sans succès. J'avais une clé USB bootable via une iso d'un installateur Ubuntu 14.04 et peut-être que cette image iso était un peu ancienne ou je ne sais quoi (ça faisait bien au moins 1 an que j'avais cette clé USB). Toujours est-il que j'ai recommencé la procédure que tu indiques en passant cette fois via un boot par le réseau avec un netboot.tar.gz téléchargé de la semaine dernière et là c'est passé comme une lettre à la poste.
Donc merci de m'avoir incité à retenter la manip. ;)
De rien, je n'y suis pour rien en fait, je n'ai fait que suggérer une piste. Dans le domaine UEFI/BIOS rien n'est encore définitif, j'en ai lu et relu pas mal de documentation, mais je ne peux pas dire que j'ai tout compris, loin s'en faut.
Ceci étant, je ne considère pas mon problème comme résolu car je ne comprends toujours pas pourquoi diable je ne peux pas modifier à la main un menu de boot Grub en UEFI alors que tout ce qui concerne le "secure boot" est désactivé. Je dirais même d'ailleurs je payerais cher pour avoir le fin mot de l'histoire. ;)
S'il y a des experts UEFI dans la salle, je serais vraiment très curieux d'avoir vos lumières.
Merci.
Si je comprends ta situation, tu es capable d'installer une distribution soit en mode legacy (ancien BIOS) ou en mode UEFI et tu veux ajouter une option pour qu'au boot la mémoire RAM soit limitée ?
Pour faire court, voici ce que me sort ma wheezy quand j'ai ajouté des options pour indiquer la taille de mon disque RAM pendant le boot:
La ramdisk que j'ai ajouté m'avait fait réfléchir si par accident elle n'allait pas contredire le fait que l'arborescence initiale qui est chargée (l'initrd) ne verrait pas la totalité de la RAM d'avant la déclaration de l'option.
Je ne me suis pas contenté de faire un update-grub ( en mode legacy ) mais j'ai fait aussi carrément un grub-install /dev/sda, ceinture et....
Autre chose que je crois comprendre, c'est que si une installation a été faite en UEFI, la distribution ne peut être bootée que sous ce mode, on peut le savoir en voyant la fstab, la partition boot EFI dans la GPT doit y apparaître, ou en faisant un cat /proc/<quelque chose>
Ce qui fait que le update-grub ou le grub-install ont une rallonge EFI et le "/dev/sda" doit probablement être plutôt une partition GPT à préciser.
Si la distribution est en mode legacy, dans ce cas là rien ne change et rien n'empêche de faire un grub-install classique après le update-grub, bien sûr, tout ceci à prendre avec des pincettes.
dyrmak -- Las experiencias engañan. ++++ --- ++++ Linux operating system ++++ --- ++++
Francois Lafont
Bonjour,
J'ai un petit peu avancé sur mon problème.
On 01/10/2015 15:07, dyrmak wrote:
Bientôt INN va faire disparaître ce HEADER, à moins de compter les lignes à la main, j'aurai des soucis pour mon script, ;]
Ah ok. ;)
Si je comprends ta situation, tu es capable d'installer une distribution soit en mode legacy (ancien BIOS) ou en mode UEFI
Oui, tout à fait. Dans les deux cas, installation sans aucun souci, reboot sans souci, bref tout fonctionne.
Seul problème : si je veux modifier les options kernel du boot dans grub. Dans ce cas là, freeze complet avec UEFI alors que tout est OK en mode legacy.
et tu veux ajouter une option pour qu'au boot la mémoire RAM soit limitée ?
Oui, mais c'est juste temporaire, hein. ;)
C'est pour faire un bench des IO des disques. Dans ce cas là, je préfère limiter la RAM (momentanément donc juste le temps de faire les benchs) car sinon les benchs peuvent être faussés car le cache de l'OS joue son rôle et au final tu ne benches pas tes disques mais seulement le cache en RAM de ton OS ce qui n'est pas le but.
C'est une procédure toute simple que j'ai fait des dizaines de fois sans problème. Soit tu rebootes et au niveau de menu grub tu édites le menu de boot par défaut et tu bootes dessus, soit tu édites le fichier /etc/default/grub correctement puis update-grub. Avec les deux méthodes, freeze complet de la machine avec UEFI, rien à signaler en mode bios-legacy. Évidemment, en pratique mon problème est résolu : ce sera bios-legacy et basta.
Mais j'aime bien comprendre quand même. Et, de plus, j'ai été un peu déçu par la réponse du support HP (car le serveur dispose d'un support HP sur 5 ans). Leur réponse en gros c'est :
« d'après le rapport machin généré par le serveur, au niveau Hardware tout est OK. Le souci est au niveau de la configuration du système d'exploitation, veuillez contacter le support Ubuntu. »
Évidemment, je n'ai pas de support Ubuntu. Et puis, passez-moi l'expression mais erreur de configuration de l'OS mon c.. ! En fait, pour moi, mon intime conviction est qu'il y a un bug au niveau du firmware UEFI de ce serveur (mais c'est juste une conviction). En effet, je me suis dit ok, je teste avec une Redhat enterprise 7.1 (je me suis procuré une version d'évaluation). Et bien, j'ai *exactement* le même problème ! Alors, comme ça y'aurait une erreur, un bug sur Ubuntu *et* sur Redhat.... Mouaiiiis.....
Apparemment, il existe (ou a existé) des bugs sur ce firmware UEFI. Par exemple ici une personne indique que le boot met 1 heure (!) à se faire quand le serveur est connecté à une baie de stockage. Ben moi je dis que mon problème est aussi un bug (en plus moi j'ai toujours eu un super bon fluide pour tomber sur des bugs ;)).
Pour faire court, voici ce que me sort ma wheezy quand j'ai ajouté des options pour indiquer la taille de mon disque RAM pendant le boot:
La ramdisk que j'ai ajouté m'avait fait réfléchir si par accident elle n'allait pas contredire le fait que l'arborescence initiale qui est chargée (l'initrd) ne verrait pas la totalité de la RAM d'avant la déclaration de l'option.
Je ne me suis pas contenté de faire un update-grub ( en mode legacy ) mais j'ai fait aussi carrément un grub-install /dev/sda, ceinture et....
Heu... pas sûr d'avoir compris ce que tu as fait exactement.
Autre chose que je crois comprendre, c'est que si une installation a été faite en UEFI, la distribution ne peut être bootée que sous ce mode, on peut le savoir en voyant la fstab, la partition boot EFI dans la GPT doit y apparaître, ou en faisant un cat /proc/<quelque chose>
Oui tout à fait. Une fois le mode choisi (UEFI/bios-legacy), tu ne peux pas en changer comme ça. L'installateur fait une installation adaptée au mode dans lequel tu te trouves.
À+
-- François Lafont
Bonjour,
J'ai un petit peu avancé sur mon problème.
On 01/10/2015 15:07, dyrmak wrote:
Bientôt INN va faire disparaître ce HEADER, à moins de compter
les lignes à la main, j'aurai des soucis pour mon script, ;]
Ah ok. ;)
Si je comprends ta situation, tu es capable d'installer une distribution
soit en mode legacy (ancien BIOS) ou en mode UEFI
Oui, tout à fait. Dans les deux cas, installation sans aucun souci, reboot
sans souci, bref tout fonctionne.
Seul problème : si je veux modifier les options kernel du boot dans grub. Dans
ce cas là, freeze complet avec UEFI alors que tout est OK en mode legacy.
et tu veux ajouter
une option pour qu'au boot la mémoire RAM soit limitée ?
Oui, mais c'est juste temporaire, hein. ;)
C'est pour faire un bench des IO des disques. Dans ce cas là, je préfère
limiter la RAM (momentanément donc juste le temps de faire les benchs) car
sinon les benchs peuvent être faussés car le cache de l'OS joue son rôle
et au final tu ne benches pas tes disques mais seulement le cache en RAM
de ton OS ce qui n'est pas le but.
C'est une procédure toute simple que j'ai fait des dizaines de fois sans
problème. Soit tu rebootes et au niveau de menu grub tu édites le menu de
boot par défaut et tu bootes dessus, soit tu édites le fichier
/etc/default/grub correctement puis update-grub. Avec les deux méthodes,
freeze complet de la machine avec UEFI, rien à signaler en mode bios-legacy.
Évidemment, en pratique mon problème est résolu : ce sera bios-legacy et
basta.
Mais j'aime bien comprendre quand même. Et, de plus, j'ai été un peu déçu
par la réponse du support HP (car le serveur dispose d'un support HP sur
5 ans). Leur réponse en gros c'est :
« d'après le rapport machin généré par le serveur, au niveau Hardware tout
est OK. Le souci est au niveau de la configuration du système d'exploitation,
veuillez contacter le support Ubuntu. »
Évidemment, je n'ai pas de support Ubuntu. Et puis, passez-moi l'expression
mais erreur de configuration de l'OS mon c.. ! En fait, pour moi, mon intime
conviction est qu'il y a un bug au niveau du firmware UEFI de ce serveur
(mais c'est juste une conviction). En effet, je me suis dit ok, je teste avec
une Redhat enterprise 7.1 (je me suis procuré une version d'évaluation). Et
bien, j'ai *exactement* le même problème ! Alors, comme ça y'aurait une erreur,
un bug sur Ubuntu *et* sur Redhat.... Mouaiiiis.....
Apparemment, il existe (ou a existé) des bugs sur ce firmware UEFI. Par exemple
ici une personne indique que le boot met 1 heure (!) à se faire quand le serveur
est connecté à une baie de stockage. Ben moi je dis que mon problème est aussi
un bug (en plus moi j'ai toujours eu un super bon fluide pour tomber sur des bugs ;)).
Pour faire court, voici ce que me sort ma wheezy quand j'ai ajouté
des options pour indiquer la taille de mon disque RAM pendant le boot:
La ramdisk que j'ai ajouté m'avait fait réfléchir si par accident elle
n'allait pas contredire le fait que l'arborescence initiale qui est
chargée (l'initrd) ne verrait pas la totalité de la RAM d'avant la
déclaration de l'option.
Je ne me suis pas contenté de faire un update-grub ( en mode legacy )
mais j'ai fait aussi carrément un grub-install /dev/sda, ceinture
et....
Heu... pas sûr d'avoir compris ce que tu as fait exactement.
Autre chose que je crois comprendre, c'est que si une installation
a été faite en UEFI, la distribution ne peut être bootée que sous
ce mode, on peut le savoir en voyant la fstab, la partition boot EFI
dans la GPT doit y apparaître, ou en faisant un cat /proc/<quelque
chose>
Oui tout à fait. Une fois le mode choisi (UEFI/bios-legacy), tu ne
peux pas en changer comme ça. L'installateur fait une installation
adaptée au mode dans lequel tu te trouves.
Bientôt INN va faire disparaître ce HEADER, à moins de compter les lignes à la main, j'aurai des soucis pour mon script, ;]
Ah ok. ;)
Si je comprends ta situation, tu es capable d'installer une distribution soit en mode legacy (ancien BIOS) ou en mode UEFI
Oui, tout à fait. Dans les deux cas, installation sans aucun souci, reboot sans souci, bref tout fonctionne.
Seul problème : si je veux modifier les options kernel du boot dans grub. Dans ce cas là, freeze complet avec UEFI alors que tout est OK en mode legacy.
et tu veux ajouter une option pour qu'au boot la mémoire RAM soit limitée ?
Oui, mais c'est juste temporaire, hein. ;)
C'est pour faire un bench des IO des disques. Dans ce cas là, je préfère limiter la RAM (momentanément donc juste le temps de faire les benchs) car sinon les benchs peuvent être faussés car le cache de l'OS joue son rôle et au final tu ne benches pas tes disques mais seulement le cache en RAM de ton OS ce qui n'est pas le but.
C'est une procédure toute simple que j'ai fait des dizaines de fois sans problème. Soit tu rebootes et au niveau de menu grub tu édites le menu de boot par défaut et tu bootes dessus, soit tu édites le fichier /etc/default/grub correctement puis update-grub. Avec les deux méthodes, freeze complet de la machine avec UEFI, rien à signaler en mode bios-legacy. Évidemment, en pratique mon problème est résolu : ce sera bios-legacy et basta.
Mais j'aime bien comprendre quand même. Et, de plus, j'ai été un peu déçu par la réponse du support HP (car le serveur dispose d'un support HP sur 5 ans). Leur réponse en gros c'est :
« d'après le rapport machin généré par le serveur, au niveau Hardware tout est OK. Le souci est au niveau de la configuration du système d'exploitation, veuillez contacter le support Ubuntu. »
Évidemment, je n'ai pas de support Ubuntu. Et puis, passez-moi l'expression mais erreur de configuration de l'OS mon c.. ! En fait, pour moi, mon intime conviction est qu'il y a un bug au niveau du firmware UEFI de ce serveur (mais c'est juste une conviction). En effet, je me suis dit ok, je teste avec une Redhat enterprise 7.1 (je me suis procuré une version d'évaluation). Et bien, j'ai *exactement* le même problème ! Alors, comme ça y'aurait une erreur, un bug sur Ubuntu *et* sur Redhat.... Mouaiiiis.....
Apparemment, il existe (ou a existé) des bugs sur ce firmware UEFI. Par exemple ici une personne indique que le boot met 1 heure (!) à se faire quand le serveur est connecté à une baie de stockage. Ben moi je dis que mon problème est aussi un bug (en plus moi j'ai toujours eu un super bon fluide pour tomber sur des bugs ;)).
Pour faire court, voici ce que me sort ma wheezy quand j'ai ajouté des options pour indiquer la taille de mon disque RAM pendant le boot:
La ramdisk que j'ai ajouté m'avait fait réfléchir si par accident elle n'allait pas contredire le fait que l'arborescence initiale qui est chargée (l'initrd) ne verrait pas la totalité de la RAM d'avant la déclaration de l'option.
Je ne me suis pas contenté de faire un update-grub ( en mode legacy ) mais j'ai fait aussi carrément un grub-install /dev/sda, ceinture et....
Heu... pas sûr d'avoir compris ce que tu as fait exactement.
Autre chose que je crois comprendre, c'est que si une installation a été faite en UEFI, la distribution ne peut être bootée que sous ce mode, on peut le savoir en voyant la fstab, la partition boot EFI dans la GPT doit y apparaître, ou en faisant un cat /proc/<quelque chose>
Oui tout à fait. Une fois le mode choisi (UEFI/bios-legacy), tu ne peux pas en changer comme ça. L'installateur fait une installation adaptée au mode dans lequel tu te trouves.
À+
-- François Lafont
Francois Lafont
On 01/10/2015 16:04, Francois Lafont wrote:
Apparemment, il existe (ou a existé) des bugs sur ce firmware UEFI. Par exemple ici une personne indique que le boot met 1 heure (!) à se faire quand le serveur est connecté à une baie de stockage.
Oups, j'ai oublié d'indiqué le lien, au temps pour moi : http://h20566.www2.hpe.com/hpsc/doc/public/display?sp4ts.oidr52836&docId=emr_na-c04502114&docLocale=en_US
Voilà. ;)
-- François Lafont
On 01/10/2015 16:04, Francois Lafont wrote:
Apparemment, il existe (ou a existé) des bugs sur ce firmware UEFI. Par exemple
ici une personne indique que le boot met 1 heure (!) à se faire quand le serveur
est connecté à une baie de stockage.
Oups, j'ai oublié d'indiqué le lien, au temps pour moi :
http://h20566.www2.hpe.com/hpsc/doc/public/display?sp4ts.oidr52836&docId=emr_na-c04502114&docLocale=en_US
Apparemment, il existe (ou a existé) des bugs sur ce firmware UEFI. Par exemple ici une personne indique que le boot met 1 heure (!) à se faire quand le serveur est connecté à une baie de stockage.
Oups, j'ai oublié d'indiqué le lien, au temps pour moi : http://h20566.www2.hpe.com/hpsc/doc/public/display?sp4ts.oidr52836&docId=emr_na-c04502114&docLocale=en_US
Voilà. ;)
-- François Lafont
Kevin Denis
Le 25-09-2015, Tonton Th a écrit :
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" ? ;)
Vieux souvenir : un module noyau à charger au boot qui "capturait" une zone de mémoire physique et empéchait le noyau de s'en servir par la suite.
Mais c'est un souvenir un peu flou...
C'était pas badram? http://rick.vanrein.org/linux/badram/ -- Kevin
Le 25-09-2015, Tonton Th <tTh@nowhere.invalid> a écrit :
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" ? ;)
Vieux souvenir : un module noyau à charger au boot qui
"capturait" une zone de mémoire physique et empéchait
le noyau de s'en servir par la suite.
Mais c'est un souvenir un peu flou...
C'était pas badram?
http://rick.vanrein.org/linux/badram/
--
Kevin
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" ? ;)
Vieux souvenir : un module noyau à charger au boot qui "capturait" une zone de mémoire physique et empéchait le noyau de s'en servir par la suite.
Mais c'est un souvenir un peu flou...
C'était pas badram? http://rick.vanrein.org/linux/badram/ -- Kevin
Pascal Hambourg
dyrmak a écrit :
Si je comprends ta situation, tu es capable d'installer une distribution soit en mode legacy (ancien BIOS) ou en mode UEFI et tu veux ajouter une option pour qu'au boot la mémoire RAM soit limitée ?
Pour faire court, voici ce que me sort ma wheezy quand j'ai ajouté des options pour indiquer la taille de mon disque RAM pendant le boot:
Le paramètre ramdisk_size n'a pas grand-chose à voir avec la taille de la RAM. Il fixe la taille des périphériques de type ramdisk éventuellement créés.
La ramdisk que j'ai ajouté m'avait fait réfléchir si par accident elle n'allait pas contredire le fait que l'arborescence initiale qui est chargée (l'initrd) ne verrait pas la totalité de la RAM d'avant la déclaration de l'option.
La racine initiale n'est plus un initrd sur un ramdisk depuis longtemps mais un initramfs sur un rootfs, variante simplifiée de tmpfs non swappable, non désactivable et non limitée en occupation mémoire. Elle n'est donc pas affectée par le paramètre ramdisk_size.
Autre chose que je crois comprendre, c'est que si une installation a été faite en UEFI, la distribution ne peut être bootée que sous ce mode,
Rien n'empêche d'installer un chargeur d'amorçage en mode BIOS/legacy (grub-pc, lilo...) ultérieurement. Ainsi la distribution pourra être amorcé dans les deux modes.
dyrmak a écrit :
Si je comprends ta situation, tu es capable d'installer une distribution
soit en mode legacy (ancien BIOS) ou en mode UEFI et tu veux ajouter
une option pour qu'au boot la mémoire RAM soit limitée ?
Pour faire court, voici ce que me sort ma wheezy quand j'ai ajouté
des options pour indiquer la taille de mon disque RAM pendant le boot:
Le paramètre ramdisk_size n'a pas grand-chose à voir avec la taille de
la RAM. Il fixe la taille des périphériques de type ramdisk
éventuellement créés.
La ramdisk que j'ai ajouté m'avait fait réfléchir si par accident elle
n'allait pas contredire le fait que l'arborescence initiale qui est
chargée (l'initrd) ne verrait pas la totalité de la RAM d'avant la
déclaration de l'option.
La racine initiale n'est plus un initrd sur un ramdisk depuis longtemps
mais un initramfs sur un rootfs, variante simplifiée de tmpfs non
swappable, non désactivable et non limitée en occupation mémoire. Elle
n'est donc pas affectée par le paramètre ramdisk_size.
Autre chose que je crois comprendre, c'est que si une installation
a été faite en UEFI, la distribution ne peut être bootée que sous
ce mode,
Rien n'empêche d'installer un chargeur d'amorçage en mode BIOS/legacy
(grub-pc, lilo...) ultérieurement. Ainsi la distribution pourra être
amorcé dans les deux modes.
Si je comprends ta situation, tu es capable d'installer une distribution soit en mode legacy (ancien BIOS) ou en mode UEFI et tu veux ajouter une option pour qu'au boot la mémoire RAM soit limitée ?
Pour faire court, voici ce que me sort ma wheezy quand j'ai ajouté des options pour indiquer la taille de mon disque RAM pendant le boot:
Le paramètre ramdisk_size n'a pas grand-chose à voir avec la taille de la RAM. Il fixe la taille des périphériques de type ramdisk éventuellement créés.
La ramdisk que j'ai ajouté m'avait fait réfléchir si par accident elle n'allait pas contredire le fait que l'arborescence initiale qui est chargée (l'initrd) ne verrait pas la totalité de la RAM d'avant la déclaration de l'option.
La racine initiale n'est plus un initrd sur un ramdisk depuis longtemps mais un initramfs sur un rootfs, variante simplifiée de tmpfs non swappable, non désactivable et non limitée en occupation mémoire. Elle n'est donc pas affectée par le paramètre ramdisk_size.
Autre chose que je crois comprendre, c'est que si une installation a été faite en UEFI, la distribution ne peut être bootée que sous ce mode,
Rien n'empêche d'installer un chargeur d'amorçage en mode BIOS/legacy (grub-pc, lilo...) ultérieurement. Ainsi la distribution pourra être amorcé dans les deux modes.
dyrmak
En 37 lignes Pascal Hambourg a écrit dans news:mv7r60$s1s$ le vendredi, 09 octobre 2015 à 09:42:56 :
Le paramètre ramdisk_size n'a pas grand-chose à voir avec la taille de la RAM. Il fixe la taille des périphériques de type ramdisk éventuellement créés.
Moi qui voulais faire simple, et voilà que ça semble compliqué, c'était bien mon intention de me donner après le boot la possibilité de créer des périphériques de cette taille, mais dans le cas présent je le citais comme exemple, que si une option est enregistrée par grub on n'a plus besoin de la donner au moment du boot. Et si aucun plantage n'était constaté alors ce serait la relation homme-machine en UEFI qui aurait comme un problème....
Mais bon, on nous a dit déjà que l'option codée en dur "n'est pas une option" .....
La ramdisk que j'ai ajouté m'avait fait réfléchir si par accident elle n'allait pas contredire le fait que l'arborescence initiale qui est chargée (l'initrd) ne verrait pas la totalité de la RAM d'avant la déclaration de l'option.
La racine initiale n'est plus un initrd sur un ramdisk depuis longtemps mais un initramfs sur un rootfs, variante simplifiée de tmpfs non swappable, non désactivable et non limitée en occupation mémoire. Elle n'est donc pas affectée par le paramètre ramdisk_size.
Disons que quand ça plante je me retrouve très souvent dans initramfs: à se demander pourquoi il y a toujours un /boot/initrd quelque part. L'initramfs est enfoui dans le kernel lui-même (je suppose dans vmlinuz ? ) Il est bien malin ce grub de l'extraire de là, à moins que ce ne soit le kernel lui même qui demande au secours!
Autre chose que je crois comprendre, c'est que si une installation a été faite en UEFI, la distribution ne peut être bootée que sous ce mode,
Rien n'empêche d'installer un chargeur d'amorçage en mode BIOS/legacy (grub-pc, lilo...) ultérieurement. Ainsi la distribution pourra être amorcé dans les deux modes.
Ça c'est nouveau pour moi, j'imagine alors que les deux versions de grub (grub et grub-efi) coexistent:
J'ai en effet toute une liste de grub-efi GRand Unified Bootloader, version 2 .
dyrmak -- El día tras la noche ++++ --- ++++ Linux operating system ++++ --- ++++
En 37 lignes Pascal Hambourg a écrit
dans news:mv7r60$s1s$1@saria.nerim.net
le vendredi, 09 octobre 2015 à 09:42:56 :
Le paramètre ramdisk_size n'a pas grand-chose à voir avec la taille de
la RAM. Il fixe la taille des périphériques de type ramdisk
éventuellement créés.
Moi qui voulais faire simple, et voilà que ça semble compliqué,
c'était bien mon intention de me donner après le boot la possibilité
de créer des périphériques de cette taille, mais dans le cas présent
je le citais comme exemple, que si une option est enregistrée par grub
on n'a plus besoin de la donner au moment du boot.
Et si aucun plantage n'était constaté alors ce serait
la relation homme-machine en UEFI qui aurait comme un problème....
Mais bon, on nous a dit déjà que l'option codée en dur "n'est pas une
option" .....
La ramdisk que j'ai ajouté m'avait fait réfléchir si par accident elle
n'allait pas contredire le fait que l'arborescence initiale qui est
chargée (l'initrd) ne verrait pas la totalité de la RAM d'avant la
déclaration de l'option.
La racine initiale n'est plus un initrd sur un ramdisk depuis longtemps
mais un initramfs sur un rootfs, variante simplifiée de tmpfs non
swappable, non désactivable et non limitée en occupation mémoire. Elle
n'est donc pas affectée par le paramètre ramdisk_size.
Disons que quand ça plante je me retrouve très souvent dans initramfs:
à se demander pourquoi il y a toujours un /boot/initrd quelque part.
L'initramfs est enfoui dans le kernel lui-même (je suppose dans
vmlinuz ? ) Il est bien malin ce grub de l'extraire de là, à moins
que ce ne soit le kernel lui même qui demande au secours!
Autre chose que je crois comprendre, c'est que si une installation
a été faite en UEFI, la distribution ne peut être bootée que sous
ce mode,
Rien n'empêche d'installer un chargeur d'amorçage en mode BIOS/legacy
(grub-pc, lilo...) ultérieurement. Ainsi la distribution pourra être
amorcé dans les deux modes.
Ça c'est nouveau pour moi, j'imagine alors que les deux versions
de grub (grub et grub-efi) coexistent:
J'ai en effet toute une liste de grub-efi GRand Unified Bootloader,
version 2 .
dyrmak
--
El día tras la noche
++++ --- ++++
Linux operating system
++++ --- ++++
En 37 lignes Pascal Hambourg a écrit dans news:mv7r60$s1s$ le vendredi, 09 octobre 2015 à 09:42:56 :
Le paramètre ramdisk_size n'a pas grand-chose à voir avec la taille de la RAM. Il fixe la taille des périphériques de type ramdisk éventuellement créés.
Moi qui voulais faire simple, et voilà que ça semble compliqué, c'était bien mon intention de me donner après le boot la possibilité de créer des périphériques de cette taille, mais dans le cas présent je le citais comme exemple, que si une option est enregistrée par grub on n'a plus besoin de la donner au moment du boot. Et si aucun plantage n'était constaté alors ce serait la relation homme-machine en UEFI qui aurait comme un problème....
Mais bon, on nous a dit déjà que l'option codée en dur "n'est pas une option" .....
La ramdisk que j'ai ajouté m'avait fait réfléchir si par accident elle n'allait pas contredire le fait que l'arborescence initiale qui est chargée (l'initrd) ne verrait pas la totalité de la RAM d'avant la déclaration de l'option.
La racine initiale n'est plus un initrd sur un ramdisk depuis longtemps mais un initramfs sur un rootfs, variante simplifiée de tmpfs non swappable, non désactivable et non limitée en occupation mémoire. Elle n'est donc pas affectée par le paramètre ramdisk_size.
Disons que quand ça plante je me retrouve très souvent dans initramfs: à se demander pourquoi il y a toujours un /boot/initrd quelque part. L'initramfs est enfoui dans le kernel lui-même (je suppose dans vmlinuz ? ) Il est bien malin ce grub de l'extraire de là, à moins que ce ne soit le kernel lui même qui demande au secours!
Autre chose que je crois comprendre, c'est que si une installation a été faite en UEFI, la distribution ne peut être bootée que sous ce mode,
Rien n'empêche d'installer un chargeur d'amorçage en mode BIOS/legacy (grub-pc, lilo...) ultérieurement. Ainsi la distribution pourra être amorcé dans les deux modes.
Ça c'est nouveau pour moi, j'imagine alors que les deux versions de grub (grub et grub-efi) coexistent:
J'ai en effet toute une liste de grub-efi GRand Unified Bootloader, version 2 .
dyrmak -- El día tras la noche ++++ --- ++++ Linux operating system ++++ --- ++++
Pascal Hambourg
dyrmak a écrit :
En 37 lignes Pascal Hambourg a écrit
Le paramètre ramdisk_size n'a pas grand-chose à voir avec la taille de la RAM. Il fixe la taille des périphériques de type ramdisk éventuellement créés.
je le citais comme exemple, que si une option est enregistrée par grub on n'a plus besoin de la donner au moment du boot.
Je n'avais pas compris que ce n'était qu'un exemple.
La racine initiale n'est plus un initrd sur un ramdisk depuis longtemps mais un initramfs sur un rootfs, variante simplifiée de tmpfs non swappable, non désactivable et non limitée en occupation mémoire. Elle n'est donc pas affectée par le paramètre ramdisk_size.
Disons que quand ça plante je me retrouve très souvent dans initramfs: à se demander pourquoi il y a toujours un /boot/initrd quelque part.
Bien que le nom du fichier soit resté "initrd", le contenu est techniquement un initramfs (archive cpio compressée).
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.
Rien n'empêche d'installer un chargeur d'amorçage en mode BIOS/legacy (grub-pc, lilo...) ultérieurement. Ainsi la distribution pourra être amorcé dans les deux modes.
Ça c'est nouveau pour moi, j'imagine alors que les deux versions de grub (grub et grub-efi) coexistent:
J'ai en effet toute une liste de grub-efi GRand Unified Bootloader, version 2 .
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.
dyrmak a écrit :
En 37 lignes Pascal Hambourg a écrit
Le paramètre ramdisk_size n'a pas grand-chose à voir avec la taille de
la RAM. Il fixe la taille des périphériques de type ramdisk
éventuellement créés.
je le citais comme exemple, que si une option est enregistrée par grub
on n'a plus besoin de la donner au moment du boot.
Je n'avais pas compris que ce n'était qu'un exemple.
La racine initiale n'est plus un initrd sur un ramdisk depuis longtemps
mais un initramfs sur un rootfs, variante simplifiée de tmpfs non
swappable, non désactivable et non limitée en occupation mémoire. Elle
n'est donc pas affectée par le paramètre ramdisk_size.
Disons que quand ça plante je me retrouve très souvent dans initramfs:
à se demander pourquoi il y a toujours un /boot/initrd quelque part.
Bien que le nom du fichier soit resté "initrd", le contenu est
techniquement un initramfs (archive cpio compressée).
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.
Rien n'empêche d'installer un chargeur d'amorçage en mode BIOS/legacy
(grub-pc, lilo...) ultérieurement. Ainsi la distribution pourra être
amorcé dans les deux modes.
Ça c'est nouveau pour moi, j'imagine alors que les deux versions
de grub (grub et grub-efi) coexistent:
J'ai en effet toute une liste de grub-efi GRand Unified Bootloader,
version 2 .
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.
Le paramètre ramdisk_size n'a pas grand-chose à voir avec la taille de la RAM. Il fixe la taille des périphériques de type ramdisk éventuellement créés.
je le citais comme exemple, que si une option est enregistrée par grub on n'a plus besoin de la donner au moment du boot.
Je n'avais pas compris que ce n'était qu'un exemple.
La racine initiale n'est plus un initrd sur un ramdisk depuis longtemps mais un initramfs sur un rootfs, variante simplifiée de tmpfs non swappable, non désactivable et non limitée en occupation mémoire. Elle n'est donc pas affectée par le paramètre ramdisk_size.
Disons que quand ça plante je me retrouve très souvent dans initramfs: à se demander pourquoi il y a toujours un /boot/initrd quelque part.
Bien que le nom du fichier soit resté "initrd", le contenu est techniquement un initramfs (archive cpio compressée).
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.
Rien n'empêche d'installer un chargeur d'amorçage en mode BIOS/legacy (grub-pc, lilo...) ultérieurement. Ainsi la distribution pourra être amorcé dans les deux modes.
Ça c'est nouveau pour moi, j'imagine alors que les deux versions de grub (grub et grub-efi) coexistent:
J'ai en effet toute une liste de grub-efi GRand Unified Bootloader, version 2 .
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.
