Forum Linux.général Grub à la main... j'y suis presque !

Posté par  (Mastodon) . Licence CC By‑SA.
Étiquettes :
4
13
fév.
2023

Bonjour à toutes zé à tous,

Je suis en train de mettre une Debian sur l'ordinateur portable LORDI offert par la région à mon fils (il a quitté le lycée, on peut maintenant en faire ce qu'on veut). C'est un HP, avec UEFI.

Je n'ai pas eu de soucis à désactiver le secure boot, et à lancer un CD d'install. La procédure se passe bien, mais à la fin patatras, erreur de Grub. J'ai eu la même erreur avec Ubuntu et Debian : Grub ne peut pas ajouter une entrée dans UEFI en NVRAM.

Bon, un peu de recherche sur Internet, et je vois que je peux finir manuellement l'installation : je bascule dans une console, je fais un chroot, puis je fais un grub-install --no-nvram et je finis l'installateur.

L'ordi reboote mais reste sous Grub, pas de lancement automatique de ma Debian. Je suis sous l'invite de commande Grub.

Si je lance à la main les commandes :

set root (hd0,gtp2)
linux /boot/vmlinuz-xxx root=/dev/sda2
initrd /boot/initrd-xxx
boot

j'ai bien mon système qui boote.

Une fois booté, j'ai beau faire des update-grub et grub-install --no-nvram /dev/sda rien n'y fait, je finis toujours sur mon Grub en invite de commande.

Je ne sais pas comment debugger, notamment on dirait que au boot Grub me donne un message d'erreur mais ça va bcp bcp trop vite pour que je le lise.

Une idée ?

Merci !

  • # Probablement à côté de la plaque, mais on sait jamais

    Posté par  . Évalué à 3.

    Je ne suis pas spécialiste EFI, loin de là. Mais on finit par être obliger de "tricoter" dans ces/ses configs …
    Quand j'ai basculé mon BIOS de legacy en UEFI (cohabitation Zindoz/Linux), j'ai eu quelques problèmes liés à Grub.
    Essentiellement, la version installée par défaut (par une Debian ou Devuan) ne gère pas l'UEFI.
    Après quelques recherches, j'ai découvert l'existence de grub-efi-amd64. J'ai pu remplacer le package installé par défaut par le bon, en utilisant une "distrib live".

    Avec montage de la partition EFI, la réinstallation de grub s'est bien passée.

    Au passage, je balade un script pour ces occasions-là, que j'utilise avant le chroot /point/de/montage/de/la/partition/root/du/linux/a/rendre/bootable, les grub-install ... et update-grub2 :

    #!/bin/bash

mount -t sysfs sysfs sys
mount -t proc proc proc
mount -t devtmpfs udev dev
mount -t devpts devpts dev/pts
mount -t tmpfs tmpfs run

    C'est vraiment pas grand chose, mais ça soulage tellement de ne plus avoir à taper ça à la main …

    • [^] # Re: Probablement à côté de la plaque, mais on sait jamais

      Posté par  (Mastodon) . Évalué à 3. Dernière modification le 13 février 2023 à 13:43.

      Si, le Grub que j'ai supporte parfaitement UEFI, la preuve il gueule car il n'arrive pas à mettre à jour les variables UEFI en NVRAM :)

      Non là c'est que dans mes différents essais je pense que le Grub qui boote n'est pas forcément celui qu'on croit…

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Probablement à côté de la plaque, mais on sait jamais

      Posté par  (site web personnel) . Évalué à 4.

      Pas du tout d'accord avec le constat initial.

      La version installée par Debian est la version cohérente avec la façon dont la machine a été démarrée pendant l'installation, donc grub-pc en mode BIOS (Legacy, CSM, etc.) et grub-efi-$arch en mode EFI (avec en bonus shim pour Secure Boot).

      Debian Consultant @ DEBAMAX

      • [^] # Re: Probablement à côté de la plaque, mais on sait jamais

        Posté par  . Évalué à 1.

        C'est un vieux problème dont je ne me rappelle plus trop le contexte.
        Donc soit il existait réellement à l'époque où je l'ai rencontré, ou, et c'est peut-être plus probable, j'ai basculé la config du BIOS après l'installation de cette Debian ou Devuan, d'où le mismatch de grub/mode du BIOS.

  • # Firmware UEFI bogué ?

    Posté par  (site web personnel) . Évalué à 5.

    Il existe un contournement classique pour les firmwares bogués.

    Tu peux jouer avec efibootmgr -v pour vérifier la configuration courante, voire ajouter une entrée à la main.

    Au passage, pourquoi désactiver Secure Boot ?

    Debian Consultant @ DEBAMAX

    • [^] # Re: Firmware UEFI bogué ?

      Posté par  (Mastodon) . Évalué à 4. Dernière modification le 13 février 2023 à 14:26.

      Tu peux jouer avec efibootmgr -v pour vérifier la configuration courante

      Ah !

      Boot0000 * EFI network 0 for IPv4
Boot0001 * EFI network 0 for IPv6
Boot0002 * ubuntu

      Donc Ubuntu avait réussi à s'enregistrer (j'ai d'ailleurs un EFI/ubuntu bien populé), mais je ne sais pas pourquoi il n' pas fini le processus d'installation quand même…

      voire ajouter une entrée à la main.

      Et ça n'a pas l'air de marcher, je retombe sur le même message d'erreur :
      Could not prepare Boot variable: Interrupted system call

      Mais du coup je me demande si je peux pas dire à ma Debian actuelle que son Grub est dans EFI/ubuntu et pas EFI/debian ?

      Au passage, pourquoi désactiver Secure Boot ?

      Il me semblait que ça nécessite de signer son OS et de mettre les clés dans le UEFI… non ?

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: Firmware UEFI bogué ?

        Posté par  (Mastodon) . Évalué à 5.

        Bon, j'ai copié le EFI/debian/grub.cfg dans EFI/ubuntu/grub.cfg et ça boote, donc on au moins j'ai compris pourquoi mes grub-update marchaient pas.

        Mais faut que j'arrive à modifier l'entrée UEFI sinon je vais casser le boot à la prochaine mise à jour.

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: Firmware UEFI bogué ?

        Posté par  (site web personnel) . Évalué à 3.

        À en croire cet article, Debian gère Secure Boot depuis Debian Installer Buster RC 1, soit depuis bientôt 4 ans.

        Tu pourrais donner l'appel efibootmgr complet pour ta tentative d'ajout (et la sortie de -v pour comparer avec l'entrée ubuntu). Tu pourrais également vérifier s'il y a des protections activées côté firmware, qui interdiraient peut-être les modifications. (En fonction des machines, on peut avoir besoin de positionner un mot de passe administrateur au niveau du firmware pour avoir le droit d'activer/désactiver Secure Boot, ça peut avoir des effets de bord, j'imagine…)

        Debian Consultant @ DEBAMAX

        • [^] # Re: Firmware UEFI bogué ?

          Posté par  (Mastodon) . Évalué à 3. Dernière modification le 13 février 2023 à 18:20. 

          $ sudo efibootmgr -v
BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 0002,2003,2001,2002
Boot0000* EFI Network 0 for IPv4 (F8-B4-6A-E8-FA-88)    PciRoot(0x0)/Pci(0x13,0x0)/Pci(0x0,0x0)/MAC(f8b46ae8fa88,0)/IPv4(0.0.0.00.0.0.0,0,0)RC
Boot0001* EFI Network 0 for IPv6 (F8-B4-6A-E8-FA-88)    PciRoot(0x0)/Pci(0x13,0x0)/Pci(0x0,0x0)/MAC(f8b46ae8fa88,0)/IPv6([::]:<->[::]:,0,0)RC
Boot0002* ubuntu        HD(1,GPT,fef9070f-7029-4bc2-afa4-b34a5406f921,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)RC
Boot2001* EFI USB Device        RC
Boot2002* EFI DVD/CDROM RC
Boot2003* EFI Network   RC

          Et d'après la donc que t'as envoyé j'ai tenté d'ajouter une entrée :

          $ sudo efibootmgr -c -d /dev/sda -p 1 -L debian '\EFI\debian\grubx64.efi'
Could not prepare Boot variable: Interrupted system call

          À noter que ça met en vrac la gestion EFI :

          [  139.022883] ------------[ cut here ]------------
[  139.022889] [Firmware Bug]: Page fault caused by firmware at PA: 0x6605a210
[  139.022901] WARNING: CPU: 1 PID: 310 at arch/x86/platform/efi/quirks.c:713 efi_recover_from_page_fault+0x2e/0xc0
[  139.022902] Modules linked in: ctr ccm cmac algif_hash algif_skcipher af_alg bnep btusb btrtl btbcm btintel bluetooth jitterentropy_rng drbg x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass snd_sof_pci snd_sof_intel_byt aes_generic snd_sof_intel_ipc ghash_clmulni_intel snd_sof_intel_hda_common snd_sof_xtensa_dsp snd_hda_codec_hdmi snd_sof snd_sof_intel_hda snd_soc_skl snd_hda_codec_conexant iwlmvm snd_hda_codec_generic ledtrig_audio snd_soc_hdac_hda snd_hda_ext_core snd_soc_sst_ipc snd_soc_sst_dsp snd_soc_acpi_intel_match snd_soc_acpi mac80211 snd_hda_intel snd_intel_dspcfg soundwire_intel soundwire_generic_allocation mei_hdcp libarc4 snd_soc_core snd_compress intel_rapl_msr soundwire_cadence nls_ascii nls_cp437 snd_hda_codec uvcvideo snd_hda_core videobuf2_vmalloc snd_hwdep videobuf2_memops aesni_intel soundwire_bus vfat iwlwifi fat videobuf2_v4l2 crypto_simd snd_pcm wdat_wdt cryptd glue_helper videobuf2_common rapl intel_cstate watchdog hid_sensor_accel_3d
[  139.022983]  hid_sensor_rotation hid_sensor_gyro_3d joydev hid_sensor_magn_3d ansi_cprng hid_sensor_incl_3d videodev snd_timer pcspkr efi_pstore ecdh_generic wmi_bmof serio_raw mei_me ecc tpm_crb hp_wmi cfg80211 hid_multitouch hid_sensor_trigger mc hid_sensor_iio_common industrialio_triggered_buffer kfifo_buf libaes snd industrialio mei processor_thermal_device soundcore intel_rapl_common rfkill sg intel_xhci_usb_role_switch roles intel_soc_dts_iosf tpm_tis ac tpm_tis_core int3403_thermal intel_vbtn evdev int340x_thermal_zone soc_button_array sparse_keymap int3400_thermal tpm acpi_thermal_rel rng_core intel_pmc_core hp_wireless parport_pc ppdev lp parport fuse configfs efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic hid_sensor_custom hid_sensor_hub intel_ishtp_hid sd_mod t10_pi crc_t10dif crct10dif_generic xhci_pci i915 xhci_hcd i2c_algo_bit ahci rtsx_pci_sdmmc hid_generic mmc_core drm_kms_helper libahci usbcore crct10dif_pclmul crct10dif_common libata r8169
[  139.023076]  i2c_i801 intel_ish_ipc i2c_hid cec realtek intel_lpss_pci crc32_pclmul mdio_devres psmouse crc32c_intel drm libphy rtsx_pci scsi_mod intel_lpss idma64 usb_common lpc_ich i2c_smbus intel_ishtp wmi hid battery button video
[  139.023104] CPU: 1 PID: 310 Comm: kworker/u8:4 Not tainted 5.10.0-21-amd64 #1 Debian 5.10.162-1
[  139.023106] Hardware name: HP HP ProBook x360 11 G1 EE/82EE, BIOS 01.27 04/19/2019
[  139.023111] Workqueue: efi_rts_wq efi_call_rts
[  139.023115] RIP: 0010:efi_recover_from_page_fault+0x2e/0xc0
[  139.023118] Code: 00 8b 15 25 72 fb 01 85 d2 74 09 48 81 ff ff 0f 00 00 77 05 c3 cc cc cc cc 53 48 89 fe 48 c7 c7 d0 e9 8c 9a 50 e8 9c 5d 83 00 <0f> 0b 83 3d f9 71 fb 01 0a 0f 84 c5 58 83 00 48 8b 3d 74 b1 e9 01
[  139.023120] RSP: 0018:ffffaef00068bb50 EFLAGS: 00010082
[  139.023122] RAX: 0000000000000000 RBX: ffff959d52be45c0 RCX: ffff959dbbca0908
[  139.023123] RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff959dbbca0900
[  139.023125] RBP: ffffaef00068bbf8 R08: 0000000000000000 R09: ffffaef00068b970
[  139.023126] R10: ffffaef00068b968 R11: ffffffff9aecb6a8 R12: 000000006605a210
[  139.023127] R13: 0000000000000000 R14: 000000000000000b R15: 0000000000000001
[  139.023130] FS:  0000000000000000(0000) GS:ffff959dbbc80000(0000) knlGS:0000000000000000
[  139.023131] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  139.023133] CR2: 000000006605a210 CR3: 000000010019e000 CR4: 00000000003506e0
[  139.023134] Call Trace:
[  139.023143]  no_context+0x16e/0x3c0
[  139.023147]  exc_page_fault+0x78/0x160
[  139.023151]  asm_exc_page_fault+0x1e/0x30
[  139.023154] RIP: 0010:0xfffffffefb033d44
[  139.023156] Code: d1 b9 04 00 00 00 e9 b7 ff ff ff cc cc cc 48 8b 05 f9 4a 00 00 48 ff 60 30 cc 48 83 ec 28 48 8b 05 e9 4a 00 00 4c 8d 44 24 40 <ff> 50 40 48 8b 4c 24 40 33 d2 48 85 c0 48 0f 48 ca 48 8b c1 48 83
[  139.023158] RSP: 0018:ffffaef00068bca0 EFLAGS: 00010086
[  139.023160] RAX: 000000006605a1d0 RBX: 0000000000000002 RCX: 0000000000000004
[  139.023161] RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000002
[  139.023162] RBP: ffffaef00068bd70 R08: ffffaef00068bce0 R09: ffffaef00068bdd0
[  139.023163] R10: 0000000000000000 R11: 0000000000000018 R12: 0000000000000000
[  139.023165] R13: 0000000000083fb0 R14: ffffaef00068bdd0 R15: ffffaef00068bdd8
[  139.023171]  ? wake_up_q+0xa0/0xa0
[  139.023174]  ? __wake_up_common+0x80/0x190
[  139.023177]  ? __wake_up_common_lock+0x8a/0xc0
[  139.023180]  ? psi_group_change+0x41/0x220
[  139.023183]  ? __efi_call+0x28/0x30
[  139.023185]  ? efi_call_rts+0x483/0x800
[  139.023188]  ? process_one_work+0x1b6/0x350
[  139.023190]  ? worker_thread+0x53/0x3e0
[  139.023192]  ? process_one_work+0x350/0x350
[  139.023194]  ? kthread+0x11b/0x140
[  139.023196]  ? __kthread_bind_mask+0x60/0x60
[  139.023199]  ? ret_from_fork+0x22/0x30
[  139.023202] ---[ end trace 955a20e47c5a2167 ]---
[  139.023225] efi: Froze efi_rts_wq and disabled EFI Runtime Services
[  139.023349] efi: EFI Runtime Services are disabled!

          et qu'après je ne peux même plus relire les variables :

          $ sudo efibootmgr -v
Skipping unreadable variable "Boot0000": Interrupted system call
Skipping unreadable variable "Boot0001": Interrupted system call
Skipping unreadable variable "Boot0002": Interrupted system call
Skipping unreadable variable "Boot2001": Interrupted system call
Skipping unreadable variable "Boot2002": Interrupted system call
Skipping unreadable variable "Boot2003": Interrupted system call
show_order(): Interrupted system call

          En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

          • [^] # Re: Firmware UEFI bogué ?

            Posté par  (site web personnel) . Évalué à 3.

            Tu peux regarder dans /sys/firmware/efi/efivars/ si tu as des entrées dump* ? Ça pourrait être une histoire de variables EFI saturées, et supprimer ces fichiers pourrait libérer de la place. Note : Je n'ai jamais été confronté à ce genre de souci, tu as peut-être envie de te renseigner par toi-même. ;)

            Good luck!

            Debian Consultant @ DEBAMAX

            • [^] # Re: Firmware UEFI bogué ?

              Posté par  (Mastodon) . Évalué à 3. Dernière modification le 13 février 2023 à 19:41.

              Oui j'avais vu passer ça, et non, pas de dump chez moi, c'est pas une histoire de saturation mémoire… mais bon, j'ai déjà un espoir vu que Ubuntu a réussi, donc c'est possible. Yapuka comprendre pourquoi ça a marché furtivement.

              En tous cas merci pour le coup du efibootmgr, ça m'a bien aidé !

              En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # j'ai le meme pb

    Posté par  (Mastodon) . Évalué à 2.

    avec mon lenovo 20405 : (enfin pour l'install de lmde5, sous mint18 ca marchait nickel)

    il m'est donc impératif de spammer F11 (boot devices) à chaque allumage pour avoir le menu de boot et choisir l'entrée EFI debian. Sinon il prend que windows.

    avec un lenovo g50-70 :
    https://forums.linuxmint.com/viewtopic.php?p=2261965#p2261965

    j'avais tenté de c/c cette réponse sur askubuntu, où les problemes de ce modele pullulaient par rapport à la problématique, j'ai vite été effacé :(

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.