La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Linux (usage serveur) => Discussion démarrée par: vivien le 27 décembre 2019 à 19:46:43
-
Sur un serveur Dell PowerEdge R320 équipé d'Ubuntu 18.04 LTS (boot en UEFI, mais sans "Secure Boot"), j'ai des problèmes avec les mises à jour concernant grub-efi-amd64-signed :
Paramétrage de grub-efi-amd64-signed (1.93.15+2.02-2ubuntu8.14) ...
Installation pour la plate-forme x86_64-efi.
Could not prepare Boot variable: Invalid argument
grub-install : erreur : efibootmgr n'a pas réussi à enregistrer l'entrée de démarrage: Erreur d'entrée/sortie.
dpkg: erreur de traitement du paquet grub-efi-amd64-signed (--configure) :
installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1
J'ai été voir les log et cela date d'une installation automatique de nuit le 6 décembre :
Log started: 2019-12-06 06:43:17
(Lecture de la base de données... 116761 fichiers et répertoires déjà installés.)
Préparation du dépaquetage de .../grub-efi-amd64-signed_1.93.15+2.02-2ubuntu8.14_amd64.deb ...
Dépaquetage de grub-efi-amd64-signed (1.93.15+2.02-2ubuntu8.14) sur (1.93.14+2.02-2ubuntu8.13) ...
Préparation du dépaquetage de .../grub-efi-amd64_2.02-2ubuntu8.14_amd64.deb ...
Dépaquetage de grub-efi-amd64 (2.02-2ubuntu8.14) sur (2.02-2ubuntu8.13) ...
Préparation du dépaquetage de .../grub-efi-amd64-bin_2.02-2ubuntu8.14_amd64.deb ...
Dépaquetage de grub-efi-amd64-bin (2.02-2ubuntu8.14) sur (2.02-2ubuntu8.13) ...
Préparation du dépaquetage de .../grub2-common_2.02-2ubuntu8.14_amd64.deb ...
Dépaquetage de grub2-common (2.02-2ubuntu8.14) sur (2.02-2ubuntu8.13) ...
Préparation du dépaquetage de .../grub-common_2.02-2ubuntu8.14_amd64.deb ...
Dépaquetage de grub-common (2.02-2ubuntu8.14) sur (2.02-2ubuntu8.13) ...
Paramétrage de grub-common (2.02-2ubuntu8.14) ...
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
Paramétrage de grub-efi-amd64-bin (2.02-2ubuntu8.14) ...
Paramétrage de grub2-common (2.02-2ubuntu8.14) ...
Paramétrage de grub-efi-amd64 (2.02-2ubuntu8.14) ...
Installation pour la plate-forme x86_64-efi.
Could not prepare Boot variable: Invalid argument
grub-install : erreur : efibootmgr n'a pas réussi à enregistrer l'entrée de démarrage: Erreur d'entrée/sortie.
Failed: grub-install --target=x86_64-efi --no-extra-removable
WARNING: Bootloader is not properly installed, system may not be bootable
Sourcing file `/etc/default/grub'
Création du fichier de configuration GRUB…
Image Linux trouvée : /boot/vmlinuz-5.0.0-37-generic
Image mémoire initiale trouvée : /boot/initrd.img-5.0.0-37-generic
Image Linux trouvée : /boot/vmlinuz-5.0.0-36-generic
Image mémoire initiale trouvée : /boot/initrd.img-5.0.0-36-generic
fait
Paramétrage de grub-efi-amd64-signed (1.93.15+2.02-2ubuntu8.14) ...
Installation pour la plate-forme x86_64-efi.
Could not prepare Boot variable: Invalid argument
grub-install : erreur : efibootmgr n'a pas réussi à enregistrer l'entrée de démarrage: Erreur d'entrée/sortie.
dpkg: erreur de traitement du paquet grub-efi-amd64-signed (--configure) :
installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1
Traitement des actions différées (« triggers ») pour man-db (2.8.3-2ubuntu0.1) ...
Traitement des actions différées (« triggers ») pour ureadahead (0.100.0-21) ...
Traitement des actions différées (« triggers ») pour install-info (6.5.0.dfsg.1-2) ...
Traitement des actions différées (« triggers ») pour systemd (237-3ubuntu10.33) ...
Des erreurs ont été rencontrées pendant l'exécution :
grub-efi-amd64-signed
Log ended: 2019-12-06 06:43:26
Aujourd'hui à chaque appel de apt, il tente de configurer grub-efi-amd64-signed et c'est toujours un échec :
# apt upgrade
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Calcul de la mise à jour... Fait
0 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.
1 partiellement installés ou enlevés.
Après cette opération, 0 o d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer ? [O/n] o
Paramétrage de grub-efi-amd64-signed (1.93.15+2.02-2ubuntu8.14) ...
Installation pour la plate-forme x86_64-efi.
Could not prepare Boot variable: Invalid argument
grub-install : erreur : efibootmgr n'a pas réussi à enregistrer l'entrée de démarrage: Erreur d'entrée/sortie.
dpkg: erreur de traitement du paquet grub-efi-amd64-signed (--configure) :
installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1
dpkg: des problèmes de dépendances empêchent le traitement des actions différées pour shim-signed :
shim-signed dépend de grub-efi-amd64-signed ; cependant :
Le paquet grub-efi-amd64-signed n'est pas encore configuré.
dpkg: erreur de traitement du paquet shim-signed (--configure) :
problèmes de dépendances - actions différées non exécutées
Des erreurs ont été rencontrées pendant l'exécution :
grub-efi-amd64-signed
shim-signed
E: Sub-process /usr/bin/dpkg returned an error code (1)
Avez-vous une idée de ce qu'il faut faire, sachant que je n'ai pas de moyen simple de récupérer le serveur si il ne redémarre pas après un reboot.
-
Vu l'erreur "Erreur d'entrée/sortie." j'ai regardé mais je ne voit aucune ligne dans dmesg qui semble indiquer un pb dur les SSD.
Voici la fin de la commande dmesg. les premières lignes sont 8 secondes après le boot, elle date de 25 jours (le serveur n'a pas été redémarré depuis le problème apt)
[ 8.911409] tg3 0000:02:00.1 eno2: Link is up at 1000 Mbps, full duplex
[ 8.911418] tg3 0000:02:00.1 eno2: Flow control is on for TX and on for RX
[ 8.911419] tg3 0000:02:00.1 eno2: EEE is disabled
[ 8.911445] IPv6: ADDRCONF(NETDEV_CHANGE): eno2: link becomes ready
[21294.622474] perf: interrupt took too long (2507 > 2500), lowering kernel.perf_event_max_sample_rate to 79750
[29262.381822] perf: interrupt took too long (3143 > 3133), lowering kernel.perf_event_max_sample_rate to 63500
[43598.861000] perf: interrupt took too long (3935 > 3928), lowering kernel.perf_event_max_sample_rate to 50750
[84982.794604] SGI XFS with ACLs, security attributes, realtime, no debug enabled
[84982.804872] JFS: nTxBlock = 8192, nTxLock = 65536
[84982.818893] ntfs: driver 2.1.32 [Flags: R/O MODULE].
[84982.838293] QNX4 filesystem 0.2.3 registered.
[117438.966911] perf: interrupt took too long (4920 > 4918), lowering kernel.perf_event_max_sample_rate to 40500
-
La machine a accès a Internet ?
sinon https://askubuntu.com/a/1032156 mais sans garanti ;)
-
Oui la machine a accès à Internet.
- La partition / où est /boot n'est remplie que à 20% (partition de 28 Go, 5,1 Go utilisé)
- La partition UEFI (/boot/efi) est une partition de 511 Mo, dont 6,1 Mo seulement sont utilisés (2%)
Dans la partition UEFI, je remarque que les fichiers sont tous datés de la dernière tentative de configuration de grub-efi-amd64-signed :
# ls -l /boot/efi/EFI/ubuntu/
total 3644
-rwx------ 1 root root 108 déc. 27 19:37 BOOTX64.CSV
-rwx------ 1 root root 126 déc. 27 19:37 grub.cfg
-rwx------ 1 root root 1116024 déc. 27 19:37 grubx64.efi
-rwx------ 1 root root 1269496 déc. 27 19:37 mmx64.efi
-rwx------ 1 root root 1334816 déc. 27 19:37 shimx64.efi
# ls -l /boot/efi/EFI/BOOT/
total 2492
-rwx------ 1 root root 1334816 déc. 27 19:37 BOOTX64.EFI
-rwx------ 1 root root 1213032 déc. 27 19:37 fbx64.efi
cat /boot/efi/EFI/ubuntu/BOOTX64.CSV
shimx64.efi,ubuntu,,This is the boot entry for ubuntu
cat /boot/efi/EFI/ubuntu/grub.cfg
search.fs_uuid ba69c114-7f04-4b4f-8147-9329c5b55d4c root hd0,gpt2
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg
cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda2 during installation
UUID=ba69c114-7f04-4b4f-8147-9329c5b55d4c / ext4 errors=remount-ro 0 1
# /boot/efi was on /dev/sda1 during installation
UUID=4DBD-B92E /boot/efi vfat umask=0077 0 1
# /home was on /dev/sda4 during installation
UUID=cb0301b7-04e0-4a37-9a28-b87e358e2393 /home ext4 defaults 0 2
# /ssd was on /dev/sdb1 during installation
UUID=88b59ca4-01e0-4c61-a836-3c8ad05e5131 /ssd ext4 defaults 0 2
# swap was on /dev/sda3 during installation
UUID=78170fb1-2d89-4e4a-85a0-07c5508a691d none swap sw 0 0
# Placer /tmp sur un RamDisque
tmpfs /tmp tmpfs defaults,size=40% 0 0
# RamDisque pour les log Apache2
tmpfs /var/log/apache2 tmpfs defaults,size=40% 0 0
C'est un serveur Dell PowerEdge R320 équipé d'Ubuntu 18.04 LTS (boot en UEFI, mais sans "Secure Boot")
version UEFI : 2.4.2 (date: 29 janvier 2015)
CPU: Intel Xeon E5-1410 @2.8 GHz (Sandy Bridge EN)
-
La première erreur rencontrée lors de la mise à jour est "Could not prepare Boot variable: Invalid argument"
J'ai remarqué que le fichier /etc/default/grub a été modifié par la mise à jour automatique du 6 décembre :
# ls -l /etc/default/grub*
-rw-r--r-- 1 root root 1197 déc. 6 06:43 /etc/default/grub
-rw-r--r-- 1 root root 1225 févr. 6 2018 /etc/default/grub.ucf-dist
Ubuntu étant le seul système d'exploitation, je n'ai jamais modifié ce fichier manuellement (installation d'Ubuntu 16.04 en janvier 2017)
Voici /etc/default/grub (j'ai supprimé les nombreuses lignes commentées)
GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=0
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX=""
Et la sauvegarde qu'a fait APT :
GRUB_DEFAULT=0
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX=""
Ce qui a été rajouté :
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=0
Ce qui a été supprimé :
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
Sur d'autres serveurs avec Ubuntu 18.04, je retrouve cette même modification de fichier /etc/default/grub le 6 ou le 7 décembre 2019.
-
1/ efibootmgr du serveur en question (Ubuntu 18.04 est le seul système d'exploitation et Windows n'a jamais été installé sur ce serveur)
# efibootmgr -v
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0004,0000,0002,0003,0005
Boot0000* Windows Boot Manager HD(1,GPT,0bb8261c-af59-11e2-ad71-d829a5f6482d,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...a................
Boot0002* EFI Network 1 PcieRoot(0x0)/Pci(0x1c,0x4)/Pci(0x0,0x0)/MAC(90b11c522ca3,0)/IPv4(0.0.0.00.0.0.0,0,0)
Boot0003* EFI Network 2 PcieRoot(0x0)/Pci(0x1c,0x4)/Pci(0x0,0x1)/MAC(90b11c522ca4,0)/IPv4(0.0.0.00.0.0.0,0,0)
Boot0004* Windows Boot Manager HD(1,GPT,b221b9be-a399-11d5-a392-d4ae5290fd14,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...a................
Boot0005* EFI Fixed Disk Boot Device 1 PcieRoot(0x0)/Pci(0x1f,0x2)/Sata(0,0,0)/HD(1,GPT,c188b9a0-7588-4e8c-a27b-c87039655832,0x800,0x100000)
Il manque l'entrée Boot0001* ubuntu donc en cas de reboot je perds le serveur.
2/ Pour comparer, efibootmgr d'un autre serveur Dell sous Ubuntu 18.04 (c'est fr.archive.ubuntu.com, qui est sur un serveur plus récent, un Dell PowerEdge R330, avec une carte Raid hardware)
# efibootmgr -v
BootCurrent: 0000
BootOrder: 0000
Boot0000* ubuntu HD(1,GPT,ef7f70c3-e783-4816-b9a9-b1c51a4990ad,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
3/ efibootmgr d'un autre serveur chez Ikoula, avec Ubuntu 16.04 :
# efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0003,0002
Boot0000* ubuntu HD(1,GPT,414437d4-e240-4c0c-b19c-36934e5685a5,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
Boot0002* Hard Drive BBS(HD,,0x0)AMGOAMNO........o.K.I.N.G.S.T.O.N. .S.K.C.1.0.0.S.3.1.2.0.G....................A...........................>..Gd-.;.A..MQ..L.0.5.2.0.B.6.2.7.C.2.5.0.A.C.6.5. . . . ......AMBO
Boot0003* Network Card BBS(Network,,0x0)AMGOAMNO........k.R.e.a.l.t.e.k. .P.X.E. .B.0.2. .D.0.0.........................rN.D+..,.\...........<..Gd-.;.A..MQ..L.R.e.a.l.t.e.k. .P.X.E. .B.0.2. .D.0.0......AMBO
4/ efibootmgr d'un serveur sous Ubuntu 16.04 (Dell PowerEdge R210 II sans carte Raid hardware)
# efibootmgr -v
BootCurrent: 0001
Timeout: 2 seconds
BootOrder: 0001,0003,0002
Boot0000* Harddisk: Samsung SSD 850 PRO 512GB BBS(HD,Harddisk: Samsung SSD 850 PRO 512GB ,0x500)................-...........A..........................................
Boot0001* ubuntu HD(1,GPT,646928cf-2f89-4d13-983a-5e68a6ac153a,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
Boot0002* lafibre.info PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,0,0)/HD(1,GPT,646928cf-2f89-4d13-983a-5e68a6ac153a,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
Boot0003 Windows Boot Manager HD(2,GPT,5e4900cd-957f-438d-a111-06ac2d9d1ed8,0xe1800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................
5/ efibootmgr d'un autre serveur Dell PowerEdge R210 II sans carte Raid hardware, mais sous Ubuntu 18.04 :
# efibootmgr -v
BootCurrent: 0000
Timeout: 2 seconds
BootOrder: 0000,0003,0002
Boot0000* ubuntu HD(1,GPT,fc3270e4-c4f4-45a1-b964-1ad644a94d01,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
Boot0001* Harddisk: Samsung SSD 850 EVO 250GB BBS(HD,Harddisk: Samsung SSD 850 EVO 250GB ,0x500)................-...........A..........................................
Boot0002* EFI Fixed Disk Boot Device 1 PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,0,0)/HD(1,GPT,fc3270e4-c4f4-45a1-b964-1ad644a94d01,0x800,0x100000)
Boot0003* Windows Boot Manager HD(1,GPT,ebe27218-7b17-4fd1-a701-b76c33b9e781,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...a................
6/ Serveur de test Dell PowerEdge R210 II :
# efibootmgr -v
BootCurrent: 0002
Timeout: 2 seconds
BootOrder: 0002,0005,0004,0000
Boot0000* ubuntu PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,0,0)/HD(1,GPT,86cfd122-2e75-4209-ad84-8e077946e111,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
Boot0001* Harddisk: WDC WD5003ABYX-18WERA0 BBS(HD,Harddisk: WDC WD5003ABYX-18WERA0 ,0x500)................-...........A..........................................
Boot0002* ubuntu HD(1,GPT,86cfd122-2e75-4209-ad84-8e077946e111,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
Boot0003* BEV device: Slot 1 NIC: IBA XE Slot 0100 v2202 BBS(128,BEV device: Slot 1 NIC: IBA XE Slot 0100 v2202,0x0).......................................................................
Boot0004* EFI Fixed Disk Boot Device 1 PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,0,0)/HD(1,GPT,86cfd122-2e75-4209-ad84-8e077946e111,0x800,0x100000)
Boot0005* Windows Boot Manager HD(1,GPT,61f605be-4825-44ed-b69b-87fcf1fdee81,0x800,0x100000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...a................
7/ PC grand public avec Windows 10 et Ubuntu 18.04 en dual boot : (PC de bureau Dell Inspiron 3650 - génération Skylake - Core i3 6100 équipé d'un chipset Intel H110)
$ efibootmgr -v
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,0000,0002,0008
Boot0000* Windows Boot Manager HD(2,GPT,55c63364-ac29-42ed-92dc-c8a0bc9ab9e1,0xe1800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...,................
Boot0001* ubuntu HD(2,GPT,55c63364-ac29-42ed-92dc-c8a0bc9ab9e1,0xe1800,0x32000)/File(\EFI\ubuntu\shimx64.efi)
Boot0002* Onboard NIC (IPV4) PciRoot(0x0)/Pci(0x1c,0x0)/Pci(0x0,0x0)/MAC(484d7e994ad4,0)/IPv4(0.0.0.00.0.0.0,0,0)..BO
Boot0008* Onboard NIC (IPV6) PciRoot(0x0)/Pci(0x1c,0x0)/Pci(0x0,0x0)/MAC(484d7e994ad4,0)/IPv6([::]:<->[::]:,0,0)..BO
-
J'ai vérifié sur un serveur Dell de 2017, installé en Ubuntu 18.04, et effectivement j'ai l'entrée windows.
root@paprika:~# efibootmgr -v
BootCurrent: 0000
BootOrder: 0000,0002,0003,0004
Boot0000* ubuntu HD(1,GPT,f21de35b-6d93-4edd-b2f4-70e64bb9e9c4,0x800,0xf3800)/File(\EFI\ubuntu\shimx64.efi)
Boot0002* Integrated NIC 1 Port 1 Partition 1 VenHw(3a191845-5f86-4e78-8fce-c4cff59f9daa)
Boot0003* Windows Boot Manager HD(2,GPT,0f38a575-981d-4773-98b9-97b10a2c52ea,0x96800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...i...............
Boot0004* Windows Boot Manager HD(2,GPT,fb4b47bf-94a6-4abe-8896-d5a0d820a715,0x96800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...i...............
MirroredPercentageAbove4G: 0.00
MirrorMemoryBelow4GB: false
Mais il est possible qu'un Dell soit préconfiguré pour accueillir un système windows. Néanmoins, ce serveur n'a jamais été installé sous windows. Donc le problème ne vient pas à priori de là.
-
En fait le problème est presque que le même que celui expliqué sur Tutoriel pour corriger le boot UEFI d'un vieux serveur Dell qui a oublié Ubuntu (https://lafibre.info/serveur-linux/dell-rajouter-entree-uefi/)
La différence c'est qu'il n'y avait pas eu d'erreur et qu'au reboot, il ne démarrait plus.
Bref, j'ai bien retenu la leçon : installer les vieux serveurs en legacy et pas UEFI.
Là j’aimerais bien rajouter l'entrée Ubuntu sans me déplacer (Je n'ai pas d’accès à distance au serveur via un DRAC)
-
Oui, effectivement, je viens de revoir le sujet. Il faudrait donc un iDRAC pour rajouter l'entrée ubuntu qui manque, et tu n'en as pas. D'un autre côté, tu disais qu'il était possible parfois d'utiliser efibootmgr pour faire la même chose à partir de l'OS, mais que cela ne marchait pas dans ton cas ?
-
Tu dois déjà le savoir, mais on ajouterait une entrée de boot UEFI avec une commande du genre :
efibootmgr -c -d /dev/sda -p 7 -L <label> -l \EFI\<label>\grubx64.efi
Ici ce serait peut-être plutôt shimx64.efi ?
Voir pour les détails :
https://www.linuxbabe.com/command-line/how-to-use-linux-efibootmgr-examples
-
La commande serait
efibootmgr --disk /dev/sda --part 1 --create --gpt --label "ubuntu" --loader "\EFI\ubuntu\shmix64.efi"
--disk /dev/sda : disque avec la partition EFI
--part 1 : partition EFI => /dev/sda1, on utilisera -p 1 et /dev/sda2, on utilisera -p 2
--create : créer un nouveau numéro de boot variable et ajouter à bootorder
--gpt : mode de partitionnement GPT pour GUID Partition Table
--label "ubuntu" : le nom affiché pour le boot
--loader \EFI\ubuntu\shmix64.efi : chemin de l'image EFI pour démarrer
On retrouve le "Could not prepare Boot variable: Invalid argument" qui était visible dans les logs. On peut imaginer que apt a envoyé un peu prés la même commande suite à la mise à jour de "grub-efi-amd64-signed", avec le même résultat...
J'ai testé /EFI/ubuntu/shmix64.efi et \EFI\ubuntu\shmix64.efi : J'ai Could not prepare Boot variable: Invalid argument dans les deux cas.
-
Tu pourrais rajouter '-v' pour voir s'il te donnerait des détails sur l'invalid argument ?
-
Voila :
(https://lafibre.info/testdebit/ubuntu/201912_efibootmgr_invalid_argument_srv_dell.png)
J'ai essayé avec le -v en début de ligne et en fin de ligne sans succès.
# efibootmgr --disk /dev/sda --part 1 --create --gpt --label "ubuntu" --loader "\EFI\ubuntu\shmix64.efi" -v
Could not prepare Boot variable: Invalid argument
J'ai testé plusieurs alternatives dans la ligne de commande, mais c'est toujours la même réponse.
C'est bien ça qui bloque la configuration par APT de "grub-efi-amd64-signed"
Là si le serveur, c'est un non redémarrage assuré.
-
Oui, j'espérais que le -v le rendrait bavard et qu'il montrerait quel argument est invalide, mais non.
J'ai trouvé ce thread, où l'un des intervenants dit que vu le nombre de thread sur le forum Ubuntu avec ce genre de problème, il pourrait bien y avoir un bug dans une mise à récente de grub...
Mais pas de solution indiquée. Faudra-t-il attendre une nouvelle mise à jour de grub qui corrige le problème ?
https://ubuntuforums.org/showthread.php?t=2432759
-
Bien vu, les messages datent de 3 semaines, c'est bien mon problème.
Il y a aussi
https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1855574 (sur un PC Dell)
https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1855459
https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1854545
-
On m'a soufflé (merci Jean-christophe) que sur https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1753518 il y a une solution de contournement en #11
Cela a fonctionné en partie :
$ sudo su -
# cd /boot/efi/EFI
root@carte-fh:/boot/efi/EFI# ls -l
total 12
drwx------ 2 root root 4096 nov. 10 2018 BOOT
drwx------ 3 root root 4096 nov. 10 2018 Dell
drwx------ 2 root root 4096 nov. 10 2018 ubuntu
root@carte-fh:/boot/efi/EFI# mv ubuntu ubuntu-old
root@carte-fh:/boot/efi/EFI# apt install -f
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
0 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.
1 partiellement installés ou enlevés.
Après cette opération, 0 o d'espace disque supplémentaires seront utilisés.
Paramétrage de grub-efi-amd64-signed (1.93.15+2.02-2ubuntu8.14) ...
Traitement des actions différées (« triggers ») pour shim-signed (1.37~18.04.3+1
5+1533136590.3beb971-0ubuntu1) ...
W: APT had planned for dpkg to do more than it reported back (0 vs 4).
Affected packages: grub-efi-amd64-signed:amd64
root@carte-fh:/boot/efi/EFI# ls
BOOT Dell ubuntu-old
root@carte-fh:/boot/efi/EFI# mv ubuntu-old ubuntu
root@carte-fh:/boot/efi/EFI# update-grub2
Sourcing file `/etc/default/grub'
Création du fichier de configuration GRUB…
Image Linux trouvée : /boot/vmlinuz-5.0.0-37-generic
Image mémoire initiale trouvée : /boot/initrd.img-5.0.0-37-generic
Image Linux trouvée : /boot/vmlinuz-5.0.0-36-generic
Image mémoire initiale trouvée : /boot/initrd.img-5.0.0-36-generic
fait
root@carte-fh:/boot/efi/EFI# exit
déconnexion
$ efibootmgr -v
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0004,0000,0002,0003,0005
Boot0000* Windows Boot Manager HD(1,GPT,0bb8261c-af59-11e2-ad71-d829a5f6482d,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...a................
Boot0002* EFI Network 1 PcieRoot(0x0)/Pci(0x1c,0x4)/Pci(0x0,0x0)/MAC(90b11c522ca3,0)/IPv4(0.0.0.00.0.0.0,0,0)
Boot0003* EFI Network 2 PcieRoot(0x0)/Pci(0x1c,0x4)/Pci(0x0,0x1)/MAC(90b11c522ca4,0)/IPv4(0.0.0.00.0.0.0,0,0)
Boot0004* Windows Boot Manager HD(1,GPT,b221b9be-a399-11d5-a392-d4ae5290fd14,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...a................
Boot0005* EFI Fixed Disk Boot Device 1 PcieRoot(0x0)/Pci(0x1f,0x2)/Sata(0,0,0)/HD(1,GPT,c188b9a0-7588-4e8c-a27b-c87039655832,0x800,0x100000)
Cela permet donc de ne plus avoir le paquet grub-efi-amd64-signed en mode partiellement configuré.
Par contre pas d'entrée UEFI pour Ubuntu (il manque l'entrée N°1 qui est celle par défault) et efibootmgr me met toujours Invalid argument.
Je sais que si le serveur reboot, il ne redémarrera pas.
# efibootmgr --disk /dev/sda --part 1 --create --gpt --label "ubuntu" --loader "\EFI\ubuntu\shmix64.efi"
Could not prepare Boot variable: Invalid argument
Voici un strace de la commande : efibootmgr --disk /dev/sda --part 1 --create --gpt --label "ubuntu" --loader "\EFI\ubuntu\shmix64.efi"
# strace efibootmgr --disk /dev/sda --part 1 --create --gpt --label "ubuntu" --loader "\EFI\ubuntu\shmix64.efi"
execve("/bin/efibootmgr", ["efibootmgr", "--disk", "/dev/sda", "--part", "1", "--create", "--gpt", "--label", "ubuntu", "--loader", "\\EFI\\ubuntu\\shmix64.efi"], 0x7ffd8791ba40 /* 19 vars */) = 0
brk(NULL) = 0x560e09ce1000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=32193, ...}) = 0
mmap(NULL, 32193, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ffb05707000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libefivar.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200*\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=146504, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffb05705000
mmap(NULL, 2242368, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7ffb052c4000
mprotect(0x7ffb052de000, 2093056, PROT_NONE) = 0
mmap(0x7ffb054dd000, 45056, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19000) = 0x7ffb054dd000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libefiboot.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\36\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=51120, ...}) = 0
mmap(NULL, 2146336, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7ffb050b7000
mprotect(0x7ffb050c3000, 2093056, PROT_NONE) = 0
mmap(0x7ffb052c2000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xb000) = 0x7ffb052c2000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260\34\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=2030544, ...}) = 0
mmap(NULL, 4131552, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7ffb04cc6000
mprotect(0x7ffb04ead000, 2097152, PROT_NONE) = 0
mmap(0x7ffb050ad000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e7000) = 0x7ffb050ad000
mmap(0x7ffb050b3000, 15072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7ffb050b3000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\16\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=14560, ...}) = 0
mmap(NULL, 2109712, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7ffb04ac2000
mprotect(0x7ffb04ac5000, 2093056, PROT_NONE) = 0
mmap(0x7ffb04cc4000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7ffb04cc4000
close(3) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffb05703000
arch_prctl(ARCH_SET_FS, 0x7ffb05703b80) = 0
mprotect(0x7ffb050ad000, 16384, PROT_READ) = 0
mprotect(0x7ffb04cc4000, 4096, PROT_READ) = 0
mprotect(0x7ffb054dd000, 4096, PROT_READ) = 0
mprotect(0x7ffb052c2000, 4096, PROT_READ) = 0
mprotect(0x560e07ea5000, 4096, PROT_READ) = 0
mprotect(0x7ffb0570f000, 4096, PROT_READ) = 0
munmap(0x7ffb05707000, 32193) = 0
access("/sys/firmware/efi/efivars/", F_OK) = 0
statfs("/sys/firmware/efi/efivars/", {f_type=EFIVARFS_MAGIC, f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={val=[0, 0]}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_NOSUID|ST_NODEV|ST_NOEXEC|ST_RELATIME}) = 0
brk(NULL) = 0x560e09ce1000
brk(0x560e09d02000) = 0x560e09d02000
openat(AT_FDCWD, "/sys/firmware/efi/efivars/", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
fstat(3, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
fcntl(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
getdents(3, /* 42 entries */, 32768) = 2920
getdents(3, /* 0 entries */, 32768) = 0
close(3) = 0
openat(AT_FDCWD, "/sys/firmware/efi/efivars/Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c", O_RDONLY) = 3
read(3, "\7\0\0\0", 4) = 4
read(3, "\1\0\0\0t\0W\0i\0n\0d\0o\0w\0s\0 \0B\0o\0o\0t\0 \0"..., 4096) = 300
read(3, "", 3796) = 0
close(3) = 0
openat(AT_FDCWD, "/sys/firmware/efi/efivars/Boot0002-8be4df61-93ca-11d2-aa0d-00e098032b8c", O_RDONLY) = 3
read(3, "\7\0\0\0", 4) = 4
read(3, "\1\0\0\200\\\0E\0F\0I\0 \0N\0e\0t\0w\0o\0r\0k\0 \0001\0"..., 4096) = 126
read(3, "", 3970) = 0
close(3) = 0
openat(AT_FDCWD, "/sys/firmware/efi/efivars/Boot0003-8be4df61-93ca-11d2-aa0d-00e098032b8c", O_RDONLY) = 3
read(3, "\7\0\0\0", 4) = 4
read(3, "\1\0\0\200\\\0E\0F\0I\0 \0N\0e\0t\0w\0o\0r\0k\0 \0002\0"..., 4096) = 126
read(3, "", 3970) = 0
close(3) = 0
openat(AT_FDCWD, "/sys/firmware/efi/efivars/Boot0004-8be4df61-93ca-11d2-aa0d-00e098032b8c", O_RDONLY) = 3
read(3, "\7\0\0\0", 4) = 4
read(3, "\1\0\0\0t\0W\0i\0n\0d\0o\0w\0s\0 \0B\0o\0o\0t\0 \0"..., 4096) = 300
read(3, "", 3796) = 0
close(3) = 0
openat(AT_FDCWD, "/sys/firmware/efi/efivars/Boot0005-8be4df61-93ca-11d2-aa0d-00e098032b8c", O_RDONLY) = 3
read(3, "\7\0\0\0", 4) = 4
read(3, "\1\0\0\200J\0E\0F\0I\0 \0F\0i\0x\0e\0d\0 \0D\0i\0s\0"..., 4096) = 138
read(3, "", 3958) = 0
close(3) = 0
openat(AT_FDCWD, "/dev/sda", O_RDONLY) = 3
fstat(3, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 0), ...}) = 0
readlink("/sys/dev/block/8:0", "../../devices/pci0000:00/0000:00"..., 4096) = 78
openat(AT_FDCWD, "/dev/sda", O_RDONLY) = 4
ioctl(4, BLKSSZGET, [512]) = 0
lseek(4, 0, SEEK_SET) = 0
read(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
fstat(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 0), ...}) = 0
uname({sysname="Linux", nodename="carte-fh", ...}) = 0
ioctl(4, BLKGETSIZE64, [250059350016]) = 0
ioctl(4, BLKSSZGET, [512]) = 0
fstat(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 0), ...}) = 0
uname({sysname="Linux", nodename="carte-fh", ...}) = 0
ioctl(4, BLKGETSIZE64, [250059350016]) = 0
ioctl(4, BLKSSZGET, [512]) = 0
ioctl(4, BLKSSZGET, [512]) = 0
lseek(4, 512, SEEK_SET) = 512
read(4, "EFI PART\0\0\1\0\\\0\0\0\351\26\350\241\0\0\0\0\1\0\0\0\0\0\0\0"..., 512) = 512
ioctl(4, BLKSSZGET, [512]) = 0
lseek(4, 1024, SEEK_SET) = 1024
read(4, "(s*\301\37\370\322\21\272K\0\240\311>\311;\240\271\210\301\210u\214N\242{\310p9eX2"..., 16384) = 16384
fstat(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 0), ...}) = 0
uname({sysname="Linux", nodename="carte-fh", ...}) = 0
ioctl(4, BLKGETSIZE64, [250059350016]) = 0
ioctl(4, BLKSSZGET, [512]) = 0
ioctl(4, BLKSSZGET, [512]) = 0
lseek(4, 250059349504, SEEK_SET) = 250059349504
read(4, "EFI PART\0\0\1\0\\\0\0\0\251\344\305~\0\0\0\0oY\34\35\0\0\0\0"..., 512) = 512
ioctl(4, BLKSSZGET, [512]) = 0
lseek(4, 250059333120, SEEK_SET) = 250059333120
read(4, "(s*\301\37\370\322\21\272K\0\240\311>\311;\240\271\210\301\210u\214N\242{\310p9eX2"..., 16384) = 16384
ioctl(4, BLKSSZGET, [512]) = 0
lseek(4, 0, SEEK_SET) = 0
read(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
close(4) = 0
close(3) = 0
openat(AT_FDCWD, "/dev/sda", O_RDONLY) = 3
fstat(3, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 0), ...}) = 0
readlink("/sys/dev/block/8:0", "../../devices/pci0000:00/0000:00"..., 4096) = 78
openat(AT_FDCWD, "/dev/sda", O_RDONLY) = 4
ioctl(4, BLKSSZGET, [512]) = 0
lseek(4, 0, SEEK_SET) = 0
read(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
fstat(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 0), ...}) = 0
uname({sysname="Linux", nodename="carte-fh", ...}) = 0
ioctl(4, BLKGETSIZE64, [250059350016]) = 0
ioctl(4, BLKSSZGET, [512]) = 0
fstat(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 0), ...}) = 0
uname({sysname="Linux", nodename="carte-fh", ...}) = 0
ioctl(4, BLKGETSIZE64, [250059350016]) = 0
ioctl(4, BLKSSZGET, [512]) = 0
ioctl(4, BLKSSZGET, [512]) = 0
lseek(4, 512, SEEK_SET) = 512
read(4, "EFI PART\0\0\1\0\\\0\0\0\351\26\350\241\0\0\0\0\1\0\0\0\0\0\0\0"..., 512) = 512
ioctl(4, BLKSSZGET, [512]) = 0
lseek(4, 1024, SEEK_SET) = 1024
read(4, "(s*\301\37\370\322\21\272K\0\240\311>\311;\240\271\210\301\210u\214N\242{\310p9eX2"..., 16384) = 16384
fstat(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 0), ...}) = 0
uname({sysname="Linux", nodename="carte-fh", ...}) = 0
ioctl(4, BLKGETSIZE64, [250059350016]) = 0
ioctl(4, BLKSSZGET, [512]) = 0
ioctl(4, BLKSSZGET, [512]) = 0
lseek(4, 250059349504, SEEK_SET) = 250059349504
read(4, "EFI PART\0\0\1\0\\\0\0\0\251\344\305~\0\0\0\0oY\34\35\0\0\0\0"..., 512) = 512
ioctl(4, BLKSSZGET, [512]) = 0
lseek(4, 250059333120, SEEK_SET) = 250059333120
read(4, "(s*\301\37\370\322\21\272K\0\240\311>\311;\240\271\210\301\210u\214N\242{\310p9eX2"..., 16384) = 16384
ioctl(4, BLKSSZGET, [512]) = 0
lseek(4, 0, SEEK_SET) = 0
read(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
close(4) = 0
close(3) = 0
openat(AT_FDCWD, "/dev/sda", O_RDONLY) = 3
fstat(3, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 0), ...}) = 0
readlink("/sys/dev/block/8:0", "../../devices/pci0000:00/0000:00"..., 4096) = 78
openat(AT_FDCWD, "/dev/sda", O_RDONLY) = 4
ioctl(4, BLKSSZGET, [512]) = 0
lseek(4, 0, SEEK_SET) = 0
read(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
fstat(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 0), ...}) = 0
uname({sysname="Linux", nodename="carte-fh", ...}) = 0
ioctl(4, BLKGETSIZE64, [250059350016]) = 0
ioctl(4, BLKSSZGET, [512]) = 0
fstat(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 0), ...}) = 0
uname({sysname="Linux", nodename="carte-fh", ...}) = 0
ioctl(4, BLKGETSIZE64, [250059350016]) = 0
ioctl(4, BLKSSZGET, [512]) = 0
ioctl(4, BLKSSZGET, [512]) = 0
lseek(4, 512, SEEK_SET) = 512
read(4, "EFI PART\0\0\1\0\\\0\0\0\351\26\350\241\0\0\0\0\1\0\0\0\0\0\0\0"..., 512) = 512
ioctl(4, BLKSSZGET, [512]) = 0
lseek(4, 1024, SEEK_SET) = 1024
read(4, "(s*\301\37\370\322\21\272K\0\240\311>\311;\240\271\210\301\210u\214N\242{\310p9eX2"..., 16384) = 16384
fstat(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 0), ...}) = 0
uname({sysname="Linux", nodename="carte-fh", ...}) = 0
ioctl(4, BLKGETSIZE64, [250059350016]) = 0
ioctl(4, BLKSSZGET, [512]) = 0
ioctl(4, BLKSSZGET, [512]) = 0
lseek(4, 250059349504, SEEK_SET) = 250059349504
read(4, "EFI PART\0\0\1\0\\\0\0\0\251\344\305~\0\0\0\0oY\34\35\0\0\0\0"..., 512) = 512
ioctl(4, BLKSSZGET, [512]) = 0
brk(0x560e09d23000) = 0x560e09d23000
lseek(4, 250059333120, SEEK_SET) = 250059333120
read(4, "(s*\301\37\370\322\21\272K\0\240\311>\311;\240\271\210\301\210u\214N\242{\310p9eX2"..., 16384) = 16384
ioctl(4, BLKSSZGET, [512]) = 0
lseek(4, 0, SEEK_SET) = 0
read(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
close(4) = 0
close(3) = 0
openat(AT_FDCWD, "/sys/firmware/efi/efivars/Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c", O_WRONLY|O_CREAT|O_EXCL, 0644) = 3
ioctl(3, FS_IOC_GETFLAGS, 0x7ffe061c6604) = 0
write(3, "\7\0\0\0\1\0\0\0b\0u\0b\0u\0n\0t\0u\0\0\0\4\1*\0\1\0\0\0"..., 122) = -1 EINVAL (Invalid argument)
ioctl(3, FS_IOC_GETFLAGS, 0x7ffe061c6604) = 0
unlink("/sys/firmware/efi/efivars/Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c") = 0
close(3) = 0
write(2, "Could not prepare Boot variable", 31Could not prepare Boot variable) = 31
write(2, ": Invalid argument\n", 19: Invalid argument
) = 19
exit_group(5) = ?
+++ exited with 5 +++
-
Essaie de supprimer /sys/firmware/efi/efivars/Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c
Sinon, tu peut essayer de copier EFI\ubuntu\shmix64.efi dans EFI\BOOT\BOOTX64.EFI puis tu active le boot sur le Fixed disk Boot Device 1 avec efibootmgr -o 5
-
/sys/firmware/efi/efivars/Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c n'existe pas :
# ls -l /sys/firmware/efi/efivars/
total 0
-rw-r--r-- 1 root root 1156 déc. 3 06:29 2151678336-417acee0-6fa9-4a82-99d7-f9b1dd271e48
-rw-r--r-- 1 root root 36 déc. 3 06:29 2151678337-417acee0-6fa9-4a82-99d7-f9b1dd271e48
-rw-r--r-- 1 root root 13 déc. 3 06:29 334-71db7b7e-4165-48fa-ac9d-f9af4cefc534
-rw-r--r-- 1 root root 304 déc. 3 06:29 Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 130 déc. 3 06:29 Boot0002-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 130 déc. 3 06:29 Boot0003-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 304 déc. 3 06:29 Boot0004-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 142 déc. 3 06:29 Boot0005-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 6 déc. 3 06:29 BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 8 déc. 3 06:29 BootOptionSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 14 déc. 6 06:43 BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 53 déc. 3 06:29 ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 603 déc. 3 06:29 ConInDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 58 déc. 3 06:29 ConOut-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 642 déc. 3 06:29 ConOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 304 déc. 3 06:29 DbocBoot0000-1ba4c901-eb4a-493f-aeef-90a6136da384
-rw-r--r-- 1 root root 142 déc. 3 06:29 DbocBoot0001-1ba4c901-eb4a-493f-aeef-90a6136da384
-rw-r--r-- 1 root root 142 déc. 3 06:29 DbocBoot0002-1ba4c901-eb4a-493f-aeef-90a6136da384
-rw-r--r-- 1 root root 304 déc. 3 06:29 DbocBoot0003-1ba4c901-eb4a-493f-aeef-90a6136da384
-rw-r--r-- 1 root root 142 déc. 3 06:29 DbocBoot0004-1ba4c901-eb4a-493f-aeef-90a6136da384
-rw-r--r-- 1 root root 137 déc. 3 06:29 DbocBoot0005-1ba4c901-eb4a-493f-aeef-90a6136da384
-rw-r--r-- 1 root root 122 déc. 3 06:29 DbocBoot0006-1ba4c901-eb4a-493f-aeef-90a6136da384
-rw-r--r-- 1 root root 122 déc. 3 06:29 DbocBoot0007-1ba4c901-eb4a-493f-aeef-90a6136da384
-rw-r--r-- 1 root root 142 déc. 3 06:29 DbocBoot0008-1ba4c901-eb4a-493f-aeef-90a6136da384
-rw-r--r-- 1 root root 5 déc. 3 06:29 DefaultIplBootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 16 déc. 3 06:29 DefaultUefiBootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 150 déc. 3 06:29 ErrOut-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 642 déc. 3 06:29 ErrOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 221 déc. 3 06:29 HDDP-fab7e9e1-39dd-4f2b-8408-e20e906cb6de
-rw-r--r-- 1 root root 8 déc. 3 06:29 Lang-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 23 déc. 3 06:29 LangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 5 déc. 3 06:29 MemoryOverwriteRequestControl-e20939be-32d4-41be-a150-897f85d49829
-rw-r--r-- 1 root root 8 déc. 3 06:29 MTC-eb704011-1402-11d3-8e77-00a0c969723b
-rw-r--r-- 1 root root 222 déc. 3 06:29 NETWORK_SETTINGS_VAR-6568a5f5-1144-401c-b693-34353e9afdd5
-rw-r--r-- 1 root root 12 déc. 3 06:29 PerfDataMemAddr-76b6bdfa-2acd-4462-9e3f-cb58c969d937
-rw-r--r-- 1 root root 10 déc. 3 06:29 PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 60 déc. 3 06:29 PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 8 déc. 3 06:29 RTC-378d7b65-8da9-4773-b6e4-a47826a833e1
-rw-r--r-- 1 root root 6 déc. 3 06:29 Timeout-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 104 déc. 3 06:29 USER_SETTINGS_VAR-56f0edc4-25ae-4236-aca3-0bcd410aa2ae
-
openat(AT_FDCWD, "/sys/firmware/efi/efivars/Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c", O_WRONLY|O_CREAT|O_EXCL, 0644) = 3
ioctl(3, FS_IOC_GETFLAGS, 0x7ffe061c6604) = 0
write(3, "\7\0\0\0\1\0\0\0b\0u\0b\0u\0n\0t\0u\0\0\0\4\1*\0\1\0\0\0"..., 122) = -1 EINVAL (Invalid argument)
Il créé le fichier mais n'arrive pas à écrire dedans.
Soit problème alignement, soit filesystem efivars pas monté ou plein ou en read-only ?
EINVAL
fd is attached to an object which is unsuitable for writing; or the file was opened with the O_DIRECT flag, and either the address specified in buf, the value specified in count, or the current file offset is not suitably aligned.
Voir aussi comment faire du ménage dans efivars si plein, et option efi_no_storage_paranoia :
https://github.com/rhboot/efibootmgr/issues/83# (https://github.com/rhboot/efibootmgr/issues/83#)
https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Requirements_for_UEFI_variable_support (https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Requirements_for_UEFI_variable_support)
UEFI variables support in Linux kernel
Linux kernel exposes UEFI variables data to userspace via efivarfs (EFI VARiable FileSystem) interface (CONFIG_EFIVAR_FS) - mounted using efivarfs kernel module at /sys/firmware/efi/efivars - it has no maximum per-variable size limitation and supports UEFI Secure Boot variables. Introduced in kernel 3.8.
If any userspace tool is unable to modify UEFI variable data, check for existence of /sys/firmware/efi/efivars/dump-* files. If they exist, delete them, reboot and retry again.
If the above step does not fix the issue, try booting with efi_no_storage_paranoia kernel parameter to disable kernel UEFI variable storage space check that may prevent writing/modification of UEFI variables.
Warning: efi_no_storage_paranoia should only be used when needed and should not be left as a normal boot option. The effect of this kernel command line parameter turns off a safeguard that was put in place to help avoid the bricking of machines when the NVRAM gets too full. See FS#34641 for more information.
-
Comment savoir le problème qui affecte /sys/firmware/efi/efivars/ ?
C'est un espace de la NVRAM qui est exposé là sur /sys/firmware/efi/efivars/ ou un espace de la partition ESP ? (partition EFI System, d'une taille généralement de 500 Mo si on laisse Ubuntu la créer, qui est habituellement sur /dev/sda1)
Si c'est un espace de la partition ESP, pourquoi l'exposer aussi sur /boot/efi ?
On est donc plus sur un pb lié au serveur, que lié à l'OS (j'aurais le même bug avec un autre Linux, le fait que cela se soit produit lors de la mise à jour de début décembre n'est pas lié à la mise à jour proposée)
Je pense que /sys/firmware/efi/efivars/ est bien monté, car j'arrive à lire le contenu des fichiers présents.
Comment savoir si il est plein ? (la partition ESP elle est utilisée à 2%)
On peut l'afficher dans la commande df ?
J'ai calculé la taille des fichiers listés via ls -l mais en comparant un autre serveur Dell de même génération équipé lui aussi d'Ubuntu 18.04 LTS en OS, je vois que le serveur problématique a plutôt moins de données.
# df
Sys. de fichiers blocs de 1K Utilisé Disponible Uti% Monté sur
udev 12268452 0 12268452 0% /dev
tmpfs 2460772 1168 2459604 1% /run
/dev/sda2 28705788 5304864 21919708 20% /
tmpfs 12303848 0 12303848 0% /dev/shm
tmpfs 5120 0 5120 0% /run/lock
tmpfs 12303848 0 12303848 0% /sys/fs/cgroup
tmpfs 9843080 24 9843056 1% /tmp
tmpfs 9843080 1140 9841940 1% /var/log/apache2
/dev/sda1 523248 6164 517084 2% /boot/efi
/dev/sdb1 961301832 795888124 116559284 88% /ssd
/dev/sda4 185868260 66199284 110204352 38% /home
tmpfs 2460768 0 2460768 0% /run/user/1000
-
on peut avoir la taille des fichiers avec du -sh sinon
-
Cela fonctionne pour /sys/firmware/efi/efivars chez toi ?
Moi non : (testé sur 3 machines UEFI)
# du -sh /sys/firmware/efi/efivars
0 /sys/firmware/efi/efivars
-
Arrives-tu à créer un fichier non vide à l'intérieur ?
-
Même sur un autre système, je n'arrive pas a créer un fichier :
# echo > /sys/firmware/efi/efivars/tmp.tmp
bash: /sys/firmware/efi/efivars/tmp.tmp: Argument invalide
Tu arrives a créer un fichier dans /sys/firmware/efi/efivars/ ?
-
Que donne ceci :
grep -i efivar /proc/mounts
-
On m'a soufflé (merci Jean-christophe) que sur https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1753518 il y a une solution de contournement en #11
qu'on t'avais indiqué en #2 ici meme depuis le début de ton souci... ;D
-
Désolé, en fait ma compréhension du pb a bien évolué au cour de ce sujet...
Que donne ceci :
grep -i efivar /proc/mounts
Voila :
$ grep -i efivar /proc/mounts
efivarfs /sys/firmware/efi/efivars efivarfs rw,nosuid,nodev,noexec,relatime 0 0
-
Tout à l'air ok au niveau efivarfs.
En regardant le code du driver efivars, on ne peut pas y écrire n'importe quoi, le contenu des fichiers doit être valide (sinon il renvoie EINVAL).
https://code.woboq.org/linux/linux/drivers/firmware/efi/vars.c.html (https://code.woboq.org/linux/linux/drivers/firmware/efi/vars.c.html)
Cf validate_load_option()
Le souci est donc plus dans ce que la routine tente d'écrire à l'intérieur du fichier.
Pas simple...
-
C'est un espace de la NVRAM qui est exposé là sur /sys/firmware/efi/efivars/ ou un espace de la partition ESP ? (partition EFI System, d'une taille généralement de 500 Mo si on laisse Ubuntu la créer, qui est habituellement sur /dev/sda1)
Les variables EFI sont en NVRAM, c'est la façon dont tous les réglages UEFI sont stockés.
La taille dépend du système, et additionner la taille des variables ne suffit pas, ça peut être fragmenté (mais l'UEFI doit essayer de défragmenter si nécessaire).
On est donc plus sur un pb lié au serveur, que lié à l'OS (j'aurais le même bug avec un autre Linux, le fait que cela se soit produit lors de la mise à jour de début décembre n'est pas lié à la mise à jour proposée)
Il y a eu des vérifications ajoutées dans le kernel car certains PC portables se sont retrouvés HS quand il ne restait plus assez d'espace libre : la protection peut être désactivée avec "efi_no_storage_paranoia", mais il faut redémarrer pour ça...
Avec une autre distribution, tout dépend si elle lance efibootmgr automatiquement lors de mises à jour ou pas. La commande a peut-être supprimé l'ancienne entrée Ubuntu, avant d'échouer à en recréer une nouvelle :-\
Est-ce que tu as essayé de supprimer les entrées de boot Windows avec efibootmgr ? Elles ne servent pas, et si ça fonctionne peut-être que la place libérée sera suffisante.
Sinon, tu peut essayer de copier EFI\ubuntu\shmix64.efi dans EFI\BOOT\BOOTX64.EFI puis tu active le boot sur le Fixed disk Boot Device 1 avec efibootmgr -o 5
Sur Fedora c'est le cas par défaut, et ça rajoute automatiquement l'entrée de boot pour pointer ensuite sur shimx64.efi, je ne sais pas si c'est le cas sur Ubuntu.
Si Boot5 corresponde bien à la partition EFI, ça pourrait effectivement fonctionner.
-
Sinon, il y a d'autres problèmes en ce moment avec des machines Dell grand public et shim / grub : https://bugzilla.redhat.com/show_bug.cgi?id=1779611 sous Fedora.
Certains grubx64.efi n'arrivent pas à démarrer un kernel (écran noir ou reboot de la machine).
On voit que ce type de mise à jour présente toujours un risque.
Sous Fedora, grub n'était jamais mis à jour automatiquement sur les machine BIOS (il faillait faire un grub-install manuellement après mise à jour du paquet), mais quand ils ont eu besoin de faire des changements (https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault) ça a créé plein de problèmes.
Sur les machines UEFI, le paquet met directement à jour le grubx64.efi dans l'ESP.
-
Est-ce que tu as essayé de supprimer les entrées de boot Windows avec efibootmgr ? Elles ne servent pas, et si ça fonctionne peut-être que la place libérée sera suffisante.
Voila :
# efibootmgr -Bb 0004
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0000,0002,0003,0005
Boot0000* Windows Boot Manager
Boot0002* EFI Network 1
Boot0003* EFI Network 2
Boot0005* EFI Fixed Disk Boot Device 1
# efibootmgr -Bb 0000
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0002,0003,0005
Boot0002* EFI Network 1
Boot0003* EFI Network 2
Boot0005* EFI Fixed Disk Boot Device 1
# efibootmgr -v
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0002,0003,0005
Boot0002* EFI Network 1 PcieRoot(0x0)/Pci(0x1c,0x4)/Pci(0x0,0x0)/MAC(90b11c522ca3,0)/IPv4(0.0.0.00.0.0.0,0,0)
Boot0003* EFI Network 2 PcieRoot(0x0)/Pci(0x1c,0x4)/Pci(0x0,0x1)/MAC(90b11c522ca4,0)/IPv4(0.0.0.00.0.0.0,0,0)
Boot0005* EFI Fixed Disk Boot Device 1 PcieRoot(0x0)/Pci(0x1f,0x2)/Sata(0,0,0)/HD(1,GPT,c188b9a0-7588-4e8c-a27b-c87039655832,0x800,0x100000)
# efibootmgr --disk /dev/sda --part 1 --create --gpt --label "ubuntu" --loader "\EFI\ubuntu\shmix64.efi"
Could not prepare Boot variable: Invalid argument
-
Sur Fedora c'est le cas par défaut, et ça rajoute automatiquement l'entrée de boot pour pointer ensuite sur shimx64.efi, je ne sais pas si c'est le cas sur Ubuntu.
Si Boot5 corresponde bien à la partition EFI, ça pourrait effectivement fonctionner.
Il semblerait que non, mais les deux fichiers présents ont été mis à jour en même temps que ceux du dossier Ubuntu.
Voici les différents dossiers de ma partition /boot/efi :
# ls -l /boot/efi
total 4
drwx------ 5 root root 4096 janv. 5 14:08 EFI
# ls -l /boot/efi/EFI/
total 12
drwx------ 2 root root 4096 nov. 10 2018 BOOT
drwx------ 3 root root 4096 nov. 10 2018 Dell
drwx------ 2 root root 4096 nov. 10 2018 ubuntu
# ls -l /boot/efi/EFI/ubuntu/
total 3644
-rwx------ 1 root root 108 déc. 30 12:31 BOOTX64.CSV
-rwx------ 1 root root 126 déc. 30 12:31 grub.cfg
-rwx------ 1 root root 1116024 déc. 30 12:31 grubx64.efi
-rwx------ 1 root root 1269496 déc. 30 12:31 mmx64.efi
-rwx------ 1 root root 1334816 déc. 30 12:31 shimx64.efi
# ls -l /boot/efi/EFI/BOOT
total 2492
-rwx------ 1 root root 1334816 déc. 30 12:31 BOOTX64.EFI
-rwx------ 1 root root 1213032 déc. 30 12:31 fbx64.efi
# ls -l /boot/efi/EFI/Dell/
total 4
drwx------ 2 root root 4096 nov. 10 2018 BootOptionCache
# ls -l /boot/efi/EFI/Dell/BootOptionCache/
total 4
-rwx------ 1 root root 282 nov. 10 2018 BootOptionCache.dat
Contenu de BootOptionCache.dat :
# cat /boot/efi/EFI/Dell/BootOptionCache/BootOptionCache.dat
��l�vBoot0005bubuntu�����u�N�{�p9eX24\EFI\ubuntu\shimx64.efi�nBoot0005�.EFI Fixed Disk Boot Device 1�����u�N�{�p9eX2�
-
# efibootmgr --disk /dev/sda --part 1 --create --gpt --label "ubuntu" --loader "\EFI\ubuntu\shmix64.efi"
Could not prepare Boot variable: Invalid argument
C'est shimx64.efi, et pas shmix64.efi. Mais je n'ai pas l'impression que le kernel vérifie ça.
Sinon, attention avec les \, le résultat peut dépendre du shell utilisé pour cette ligne de commande (pour bash c'est correct).
Le code du kernel me semble plutôt remonter ENOSPC quand il n'y a pas passez de place, mais bizarrement pour certaines personnes efi_no_storage_paranoia était nécessaire pour ne pas avoir EINVAL.
Le code qui valide le contenu de ce que efibootmgr écrit est https://code.woboq.org/linux/linux/drivers/firmware/efi/vars.c.html#validate_load_option.
Tu peux utiliser l'option "--test boot0001.bin" pour écrire dans un fichier, on pourra essayer de le valider ensuite (soit avec du code, soit sur une autre machine, avec un "cp boot0001.bin /sys/firmware/efi/efivars/Boot1234-8be4df61-93ca-11d2-aa0d-00e098032b8".
-
quand je mets --test filename (Don't write to NVRAM, write to filename) j'ai systématiquement : efibootmgr: unrecognized option '--test'
j'ai essayé en mettant l'option en premier, même comportement.
Ca serait une option introduite dans une version plus récente ? (Note: J'ai le même problème avec efibootmgr version 15, version livrée avec Ubuntu 19.10)
# efibootmgr --disk /dev/sda --part 1 --create --gpt --label "ubuntu" --loader "\EFI\ubuntu\shimx64.efi" --test boot0001.bin
efibootmgr: unrecognized option '--test'
efibootmgr version 15
usage: efibootmgr [options]
-a | --active sets bootnum active
-A | --inactive sets bootnum inactive
-b | --bootnum XXXX modify BootXXXX (hex)
-B | --delete-bootnum delete bootnum
-c | --create create new variable bootnum and add to bootorder
-C | --create-only create new variable bootnum and do not add to bootorder
-D | --remove-dups remove duplicate values from BootOrder
-d | --disk disk (defaults to /dev/sda) containing loader
-r | --driver Operate on Driver variables, not Boot Variables.
-e | --edd [1|3|-1] force EDD 1.0 or 3.0 creation variables, or guess
-E | --device num EDD 1.0 device number (defaults to 0x80)
-g | --gpt force disk with invalid PMBR to be treated as GPT
-i | --iface name create a netboot entry for the named interface
-l | --loader name (defaults to "\EFI\ubuntu\grub.efi")
-L | --label label Boot manager display label (defaults to "Linux")
-m | --mirror-below-4G t|f mirror memory below 4GB
-M | --mirror-above-4G X percentage memory to mirror above 4GB
-n | --bootnext XXXX set BootNext to XXXX (hex)
-N | --delete-bootnext delete BootNext
-o | --bootorder XXXX,YYYY,ZZZZ,... explicitly set BootOrder (hex)
-O | --delete-bootorder delete BootOrder
-p | --part part (defaults to 1) containing loader
-q | --quiet be quiet
-t | --timeout seconds set boot manager timeout waiting for user input.
-T | --delete-timeout delete Timeout.
-u | --unicode | --UCS-2 handle extra args as UCS-2 (default is ASCII)
-v | --verbose print additional information
-V | --version return version and exit
-w | --write-signature write unique sig to MBR if needed
-y | --sysprep Operate on SysPrep variables, not Boot Variables.
-@ | --append-binary-args file append extra args from file (use "-" for stdin)
-h | --help show help/usage
-
J'ai bien cette option sur RHEL6/OL6/RHEL7/OL7, mais le versionnage RedHat suit une numérotation différente :
# efibootmgr -V
version 0.5.4
# efibootmgr -h 2>&1 |grep test
| --test filename don't write to NVRAM, write to filename.
Sinon avec strace tu peux avoir le contenu complet du buffer écrit sous forme ASCII/Hexa avec l'option "-e write=all".
A priori, il utilise le file descriptor 3 pour écrire, donc pour éviter que ce soit trop verbeux, "-e write=3" devrait suffire.
write(3, "\7\0\0\0\1\0\0\0b\0u\0b\0u\0n\0t\0u\0\0\0\4\1*\0\1\0\0\0"..., 122) = -1 EINVAL (Invalid argument)
la commande deviendrait donc :
strace -fe write=3 efibootmgr ....
-
quand je mets --test filename (Don't write to NVRAM, write to filename) j'ai systématiquement : efibootmgr: unrecognized option '--test'
En fait c'est une ancienne option, je n'aurais pas dû faire confiance à une page de man trouvée sur internet.
Donc pour récupérer les données que efibootmgr essaye d'écrire, soit tu fais comme Thornhill suggère, soit il y a une autre méthode gérée dans la libefivars utilisée :
mkdir /tmp/efivars
EFIVARFS_PATH=/tmp/efivars/ efibootmgr ...Avec ça, efibootmgr va créer des fichiers normaux.
Dans ce cas précis ce sera avec un point de départ vide, si on veut simuler de manière plus précise on peut faire un "cp /sys/firmware/efi/efivars/Boot* /tmp/efivars", mais ça ne devrait changer que le numéro qu'il va utiliser, donc le nom du fichier, pas le contenu.
-
Voila le retour de strace -fe write=3 efibootmgr :
# strace -fe write=3 efibootmgr --disk /dev/sda --part 1 --create --gpt --label "ubuntu" --loader "\EFI\ubuntu\shimx64.efi"
execve("/bin/efibootmgr", ["efibootmgr", "--disk", "/dev/sda", "--part", "1", "--create", "--gpt", "--label", "ubuntu", "--loader", "\\EFI\\ubuntu\\shimx64.efi"], 0x7fff440748c0 /* 19 vars */) = 0
brk(NULL) = 0x55d0aaacc000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=32193, ...}) = 0
mmap(NULL, 32193, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f2e81a69000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libefivar.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200*\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=146504, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f2e81a67000
mmap(NULL, 2242368, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f2e81626000
mprotect(0x7f2e81640000, 2093056, PROT_NONE) = 0
mmap(0x7f2e8183f000, 45056, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19000) = 0x7f2e8183f000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libefiboot.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\36\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=51120, ...}) = 0
mmap(NULL, 2146336, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f2e81419000
mprotect(0x7f2e81425000, 2093056, PROT_NONE) = 0
mmap(0x7f2e81624000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xb000) = 0x7f2e81624000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260\34\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=2030544, ...}) = 0
mmap(NULL, 4131552, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f2e81028000
mprotect(0x7f2e8120f000, 2097152, PROT_NONE) = 0
mmap(0x7f2e8140f000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e7000) = 0x7f2e8140f000
mmap(0x7f2e81415000, 15072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f2e81415000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\16\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=14560, ...}) = 0
mmap(NULL, 2109712, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f2e80e24000
mprotect(0x7f2e80e27000, 2093056, PROT_NONE) = 0
mmap(0x7f2e81026000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7f2e81026000
close(3) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f2e81a65000
arch_prctl(ARCH_SET_FS, 0x7f2e81a65b80) = 0
mprotect(0x7f2e8140f000, 16384, PROT_READ) = 0
mprotect(0x7f2e81026000, 4096, PROT_READ) = 0
mprotect(0x7f2e8183f000, 4096, PROT_READ) = 0
mprotect(0x7f2e81624000, 4096, PROT_READ) = 0
mprotect(0x55d0aa235000, 4096, PROT_READ) = 0
mprotect(0x7f2e81a71000, 4096, PROT_READ) = 0
munmap(0x7f2e81a69000, 32193) = 0
access("/sys/firmware/efi/efivars/", F_OK) = 0
statfs("/sys/firmware/efi/efivars/", {f_type=EFIVARFS_MAGIC, f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={val=[0, 0]}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_NOSUID|ST_NODEV|ST_NOEXEC|ST_RELATIME}) = 0
brk(NULL) = 0x55d0aaacc000
brk(0x55d0aaaed000) = 0x55d0aaaed000
openat(AT_FDCWD, "/sys/firmware/efi/efivars/", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
fstat(3, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
fcntl(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
getdents(3, /* 40 entries */, 32768) = 2776
getdents(3, /* 0 entries */, 32768) = 0
close(3) = 0
openat(AT_FDCWD, "/sys/firmware/efi/efivars/Boot0002-8be4df61-93ca-11d2-aa0d-00e098032b8c", O_RDONLY) = 3
read(3, "\7\0\0\0", 4) = 4
read(3, "\1\0\0\200\\\0E\0F\0I\0 \0N\0e\0t\0w\0o\0r\0k\0 \0001\0"..., 4096) = 126
read(3, "", 3970) = 0
close(3) = 0
openat(AT_FDCWD, "/sys/firmware/efi/efivars/Boot0003-8be4df61-93ca-11d2-aa0d-00e098032b8c", O_RDONLY) = 3
read(3, "\7\0\0\0", 4) = 4
read(3, "\1\0\0\200\\\0E\0F\0I\0 \0N\0e\0t\0w\0o\0r\0k\0 \0002\0"..., 4096) = 126
read(3, "", 3970) = 0
close(3) = 0
openat(AT_FDCWD, "/sys/firmware/efi/efivars/Boot0005-8be4df61-93ca-11d2-aa0d-00e098032b8c", O_RDONLY) = 3
read(3, "\7\0\0\0", 4) = 4
read(3, "\1\0\0\200J\0E\0F\0I\0 \0F\0i\0x\0e\0d\0 \0D\0i\0s\0"..., 4096) = 138
read(3, "", 3958) = 0
close(3) = 0
openat(AT_FDCWD, "/dev/sda", O_RDONLY) = 3
fstat(3, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 0), ...}) = 0
readlink("/sys/dev/block/8:0", "../../devices/pci0000:00/0000:00"..., 4096) = 78
openat(AT_FDCWD, "/dev/sda", O_RDONLY) = 4
ioctl(4, BLKSSZGET, [512]) = 0
lseek(4, 0, SEEK_SET) = 0
read(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
fstat(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 0), ...}) = 0
uname({sysname="Linux", nodename="carte-fh", ...}) = 0
ioctl(4, BLKGETSIZE64, [250059350016]) = 0
ioctl(4, BLKSSZGET, [512]) = 0
fstat(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 0), ...}) = 0
uname({sysname="Linux", nodename="carte-fh", ...}) = 0
ioctl(4, BLKGETSIZE64, [250059350016]) = 0
ioctl(4, BLKSSZGET, [512]) = 0
ioctl(4, BLKSSZGET, [512]) = 0
lseek(4, 512, SEEK_SET) = 512
read(4, "EFI PART\0\0\1\0\\\0\0\0\351\26\350\241\0\0\0\0\1\0\0\0\0\0\0\0"..., 512) = 512
ioctl(4, BLKSSZGET, [512]) = 0
lseek(4, 1024, SEEK_SET) = 1024
read(4, "(s*\301\37\370\322\21\272K\0\240\311>\311;\240\271\210\301\210u\214N\242{\310p9eX2"..., 16384) = 16384
fstat(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 0), ...}) = 0
uname({sysname="Linux", nodename="carte-fh", ...}) = 0
ioctl(4, BLKGETSIZE64, [250059350016]) = 0
ioctl(4, BLKSSZGET, [512]) = 0
ioctl(4, BLKSSZGET, [512]) = 0
lseek(4, 250059349504, SEEK_SET) = 250059349504
read(4, "EFI PART\0\0\1\0\\\0\0\0\251\344\305~\0\0\0\0oY\34\35\0\0\0\0"..., 512) = 512
ioctl(4, BLKSSZGET, [512]) = 0
lseek(4, 250059333120, SEEK_SET) = 250059333120
read(4, "(s*\301\37\370\322\21\272K\0\240\311>\311;\240\271\210\301\210u\214N\242{\310p9eX2"..., 16384) = 16384
ioctl(4, BLKSSZGET, [512]) = 0
lseek(4, 0, SEEK_SET) = 0
read(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
close(4) = 0
close(3) = 0
openat(AT_FDCWD, "/dev/sda", O_RDONLY) = 3
fstat(3, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 0), ...}) = 0
readlink("/sys/dev/block/8:0", "../../devices/pci0000:00/0000:00"..., 4096) = 78
openat(AT_FDCWD, "/dev/sda", O_RDONLY) = 4
ioctl(4, BLKSSZGET, [512]) = 0
lseek(4, 0, SEEK_SET) = 0
read(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
fstat(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 0), ...}) = 0
uname({sysname="Linux", nodename="carte-fh", ...}) = 0
ioctl(4, BLKGETSIZE64, [250059350016]) = 0
ioctl(4, BLKSSZGET, [512]) = 0
fstat(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 0), ...}) = 0
uname({sysname="Linux", nodename="carte-fh", ...}) = 0
ioctl(4, BLKGETSIZE64, [250059350016]) = 0
ioctl(4, BLKSSZGET, [512]) = 0
ioctl(4, BLKSSZGET, [512]) = 0
lseek(4, 512, SEEK_SET) = 512
read(4, "EFI PART\0\0\1\0\\\0\0\0\351\26\350\241\0\0\0\0\1\0\0\0\0\0\0\0"..., 512) = 512
ioctl(4, BLKSSZGET, [512]) = 0
lseek(4, 1024, SEEK_SET) = 1024
read(4, "(s*\301\37\370\322\21\272K\0\240\311>\311;\240\271\210\301\210u\214N\242{\310p9eX2"..., 16384) = 16384
fstat(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 0), ...}) = 0
uname({sysname="Linux", nodename="carte-fh", ...}) = 0
ioctl(4, BLKGETSIZE64, [250059350016]) = 0
ioctl(4, BLKSSZGET, [512]) = 0
ioctl(4, BLKSSZGET, [512]) = 0
lseek(4, 250059349504, SEEK_SET) = 250059349504
read(4, "EFI PART\0\0\1\0\\\0\0\0\251\344\305~\0\0\0\0oY\34\35\0\0\0\0"..., 512) = 512
ioctl(4, BLKSSZGET, [512]) = 0
lseek(4, 250059333120, SEEK_SET) = 250059333120
read(4, "(s*\301\37\370\322\21\272K\0\240\311>\311;\240\271\210\301\210u\214N\242{\310p9eX2"..., 16384) = 16384
ioctl(4, BLKSSZGET, [512]) = 0
lseek(4, 0, SEEK_SET) = 0
read(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
close(4) = 0
close(3) = 0
openat(AT_FDCWD, "/dev/sda", O_RDONLY) = 3
fstat(3, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 0), ...}) = 0
readlink("/sys/dev/block/8:0", "../../devices/pci0000:00/0000:00"..., 4096) = 78
openat(AT_FDCWD, "/dev/sda", O_RDONLY) = 4
ioctl(4, BLKSSZGET, [512]) = 0
lseek(4, 0, SEEK_SET) = 0
read(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
fstat(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 0), ...}) = 0
uname({sysname="Linux", nodename="carte-fh", ...}) = 0
ioctl(4, BLKGETSIZE64, [250059350016]) = 0
ioctl(4, BLKSSZGET, [512]) = 0
fstat(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 0), ...}) = 0
uname({sysname="Linux", nodename="carte-fh", ...}) = 0
ioctl(4, BLKGETSIZE64, [250059350016]) = 0
ioctl(4, BLKSSZGET, [512]) = 0
ioctl(4, BLKSSZGET, [512]) = 0
lseek(4, 512, SEEK_SET) = 512
read(4, "EFI PART\0\0\1\0\\\0\0\0\351\26\350\241\0\0\0\0\1\0\0\0\0\0\0\0"..., 512) = 512
ioctl(4, BLKSSZGET, [512]) = 0
lseek(4, 1024, SEEK_SET) = 1024
read(4, "(s*\301\37\370\322\21\272K\0\240\311>\311;\240\271\210\301\210u\214N\242{\310p9eX2"..., 16384) = 16384
fstat(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 0), ...}) = 0
uname({sysname="Linux", nodename="carte-fh", ...}) = 0
ioctl(4, BLKGETSIZE64, [250059350016]) = 0
ioctl(4, BLKSSZGET, [512]) = 0
ioctl(4, BLKSSZGET, [512]) = 0
lseek(4, 250059349504, SEEK_SET) = 250059349504
read(4, "EFI PART\0\0\1\0\\\0\0\0\251\344\305~\0\0\0\0oY\34\35\0\0\0\0"..., 512) = 512
ioctl(4, BLKSSZGET, [512]) = 0
brk(0x55d0aab0e000) = 0x55d0aab0e000
lseek(4, 250059333120, SEEK_SET) = 250059333120
read(4, "(s*\301\37\370\322\21\272K\0\240\311>\311;\240\271\210\301\210u\214N\242{\310p9eX2"..., 16384) = 16384
ioctl(4, BLKSSZGET, [512]) = 0
lseek(4, 0, SEEK_SET) = 0
read(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
close(4) = 0
close(3) = 0
openat(AT_FDCWD, "/sys/firmware/efi/efivars/Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c", O_WRONLY|O_CREAT|O_EXCL, 0644) = 3
ioctl(3, FS_IOC_GETFLAGS, 0x7ffe851f4b34) = 0
write(3, "\7\0\0\0\1\0\0\0b\0u\0b\0u\0n\0t\0u\0\0\0\4\1*\0\1\0\0\0"..., 122) = -1 EINVAL (Invalid argument)
ioctl(3, FS_IOC_GETFLAGS, 0x7ffe851f4b34) = 0
unlink("/sys/firmware/efi/efivars/Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c") = 0
close(3) = 0
write(2, "Could not prepare Boot variable", 31Could not prepare Boot variable) = 31
write(2, ": Invalid argument\n", 19: Invalid argument
) = 19
exit_group(5) = ?
+++ exited with 5 +++
-
Ca n'a pas fonctionné, il n'y a pas de dump, sur la ligne write la valeur est tronquée.
Sinon, "strace -f -e write -s 256 efibootmgr ..."
-
Voila :
# strace -f -e write -s 256 efibootmgr --disk /dev/sda --part 1 --create --gpt --label "ubuntu" --loader "\EFI\ubuntu\shimx64.efi"
write(3, "\7\0\0\0\1\0\0\0b\0u\0b\0u\0n\0t\0u\0\0\0\4\1*\0\1\0\0\0\0\10\0\0\0\0\0\0\0\0\20\0\0\0\0\0\240\271\210\301\210u\214N\242{\310p9eX2\2\2\4\0044\0\\\0E\0F\0I\0\\\0u\0b\0u\0n\0t\0u\0\\\0s\0h\0i\0m\0x\0006\0004\0.\0e\0f\0i\0\0\0\177\377\4\0", 122) = -1 EINVAL (Invalid argument)
write(2, "Could not prepare Boot variable", 31Could not prepare Boot variable) = 31
write(2, ": Invalid argument\n", 19: Invalid argument
) = 19
+++ exited with 5 +++
-
En remplaçant les caractères non imprimables par espace, ça donne ceci :
$ echo "\7\0\0\0\1\0\0\0b\0u\0b\0u\0n\0t\0u\0\0\0\4\1*\0\1\0\0\0\0\10\0\0\0\0\0\0\0\0\20\0\0\0\0\0\240\271\210\301\210u\214N\242{\310p9eX2\2\2\4\0044\0\\\0E\0F\0I\0\\\0u\0b\0u\0n\0t\0u\0\\\0s\0h\0i\0m\0x\0006\0004\0.\0e\0f\0i\0\0\0\177\377\4\0" | sed 's:\\[0-9]*: :g'
b u b u n t u * u N { p9eX2 E F I u b u n t u s h i m x . e f i
-
Voila :
# strace -f -e write -s 256 efibootmgr --disk /dev/sda --part 1 --create --gpt --label "ubuntu" --loader "\EFI\ubuntu\shimx64.efi"
write(3, "\7\0\0\0\1\0\0\0b\0u\0b\0u\0n\0t\0u\0\0\0\4\1*\0\1\0\0\0\0\10\0\0\0\0\0\0\0\0\20\0\0\0\0\0\240\271\210\301\210u\214N\242{\310p9eX2\2\2\4\0044\0\\\0E\0F\0I\0\\\0u\0b\0u\0n\0t\0u\0\\\0s\0h\0i\0m\0x\0006\0004\0.\0e\0f\0i\0\0\0\177\377\4\0", 122) = -1 EINVAL (Invalid argument)
write(2, "Could not prepare Boot variable", 31Could not prepare Boot variable) = 31
write(2, ": Invalid argument\n", 19: Invalid argument
) = 19
+++ exited with 5 +++
J'ai essayé d'ajouté la ces données dans une VM sur laquelle j'ai booté un liveCD Ubuntu 18.04 (kernel 5.0.0-23).
Il en veut bien, donc le efibootmgr génère les bonnes données.
J'ai pu au total ajouter 71 entrées, avant d'aboutir à EINVAL.
Mais à ce moment là, même en effaçant toutes les entrées, impossible d'en ajouter à nouveau, EINVAL systématique.
Avec une image Fedora 31 (kernel 5.3.7), j'ai pu ajouter 86 entrées, mais même problème ensuite.
Il ne semble pas être possible de libérer de l'espace sans au moins rebooter ! Ca dépend peut-être de l'UEFI, mais c'est très moche...
https://mjg59.dreamwidth.org/23554.html
UEFI implementations generally handle variable deletion by flagging the space as reclaimable rather than immediately making it available again. You need to reboot in order for the firmware to garbage collect it. Some firmware seems to require two reboot cycles to do this properly. Thanks, firmware.
https://mjg59.dreamwidth.org/25091.html
The hope was that any system that booted with only 5KB of space available in nvram would trigger a garbage collection run. Unfortunately, it turned out that that wasn't true - some systems will only trigger garbage collection if the OS actually makes an attempt to write a variable that won't otherwise fit.
Hence this patch. The new approach is to ask the firmware how much space is available. If the size of the new variable would reduce this to less than 5K, we attempt to create a variable bigger than the remaining space. This should cause the firmware to realise that it's out of room and either (depending on implementation) perform a garbage collection run at runtime or set a flag that will cause the system to perform garbage collection on the next reboot. We then call QueryVariableInfo() again to see whether a garbage collection run actually happened, and if so check whether we now have enough space. If so, we go ahead and write the variable. If not, we tell userspace that there's not enough space.
Donc il y a des UEFI pour lesquels même s'il reste peu d'espace libre, il faut d'abord tenter une écriture qui échoue puis rebooter pour pouvoir réussir à écrire quelque chose :o
-
Que pense tu de modifier une entrée existante (par exemple celle d'un boot réseau) pour devenir un boot Ubuntu ?
Si ce n'est pas possible, je pense qu'une intervention sur site sera nécessaire.
Je retiens qu'il ne faut pas mettre un vieux serveur en UEFI (c'est ce que j'avais écris sur Tutoriel pour corriger le boot UEFI d'un vieux serveur Dell qui a oublié Ubuntu (https://lafibre.info/serveur-linux/dell-rajouter-entree-uefi/), un serveur de la même génération)
-
Quand on est dans l'état où il n'y a plus de place, il est impossible de modifier la moindre valeur, ce serait-ce que le BootOrder. Je pense que c'est parce que ça ce fait via un ajout puis une suppression.
Le fait qu'Ubuntu appelle efibootmgr automatiquement sur des mises à jour, c'est risqué. En plus, vu le résultat, on dirait qu'ils font une suppression puis un ajout, alors qu'il faudrait faire l'inverse pour ne pas risquer de se retrouver bloqué au milieu.
Je ne sais pas si c'est lié à l'age du serveur : le problème est soit lié à un manque de place combiné au kernel qui est devenu beaucoup plus prudent, soit à l'accumulation des écritures sans nettoyage (qui nécessite un reboot).
Les écritures peuvent venir de :
- l'UEFI directement (logs, ...)
- efi-pstore (ce qui a révélé le bug des portables Samsung à l'époque), qui permet d'enregistrer les logs kernels en cas de crash pour les récupérer après reboot
- de multiples mises à jour de grub avec les scripts Ubuntu
- ...
Il y a toujours la possibilité qu'une des entrées de boot existantes fonctionne, par exemple "EFI Fixed Disk Boot Device 1", cad EFI\BOOT\BOOTX64.EFI de ce qui semble bien être l'ESP du serveur (même identifiant que l'entrée que efibootmgr essaye de créer). C'est en plus une valeur qui est en général recréée automatiquement si nécessaire, si aucune entrée n'est valide la logique est de rechercher les ESP des disques durs présents sur le système.
Mais effectivement il y a le risque qu'une intervention sur site soit nécessaire.
il faudrait bien vérifier le contenu de l'ESP pour se donner toutes les chances de ce côté.
Est-ce que le serveur utilise Secure Boot ? Si oui, il y a un risque que le mmx64.efi (MockManager) soit invoqué pour demander à l'utilisateur physiquement présent d'ajouter des clés, cf https://wiki.ubuntu.com/UEFI/SecureBoot.
Vu que le efibootmgr a échoué je ne sais pas s'il ne peut pas manquer des opérations derrière.
Pour le comportement du fallback : https://www.rodsbooks.com/efi-bootloaders/fallback.html, et https://github.com/rhboot/shim/blob/master/README.fallback (pas à jour dans les noms...).
Le bootx64.efi semble bien être une copie de shim, on peut vérifier ce qu'il va essayer de faire en regardant les chaînes de caractères qu'il contient : normalement il essaye de charger grubx64.efi, puis sinon fbx64.efi (mais avant c'était fallback.efi, c'est pour ça qu'il est important de vérifier).
strings -el /boot/efi/EFI/BOOT/BOOTX64.EFI | grep -i "\.efi"
Le fallback (fbx64.efi normalement) devrait trouver le /boot/efi/EFI/ubuntu/BOOTX64.CSV puisque c'est le seul boot.csv / bootx64.csv de la partition, et s'en servir pour recréer l'entrée de boot Ubuntu.
On peut en vérifier le contenu, normalement il devrait pointer vers le shimx64.efi :
# hexdump -C /boot/efi/EFI/ubuntu/BOOTX64.CSV
# iconv --from-code=ucs2 /boot/efi/EFI/ubuntu/BOOTX64.CSV
Par précaution, il faudrait aussi vérifier si le grub.cfg semble correct.
-
Le serveur ne supporte pas le secure boot, le Dell PowerEdge R320 est un serveur conçu en 2011/2012.
Il y a bien un reboot environ chaque mois, afin d’appliquer les mises à jour du kernel, mais j'imagine que le nettoyage des entrées supprimées n'a pas été fait (j'ai désactivé ces reboot automatiques de nuit quand une mise à jour le nécessite)
# strings -el /boot/efi/EFI/BOOT/BOOTX64.EFI | grep -i "\.efi"
Could not get image for bootx64.efi: %r
.EFI
\EFI\BOOT\fbx64.efi
\fbx64.efi
\mmx64.efi
\grubx64.efi
add-symbol-file /usr/lib/debug/usr/share/shim/x64-15-15/shimx64.efi.debug 0x%08x -s .data 0x%08x
\mmx64.efi
Contenu de /boot/efi/EFI/ubuntu/BOOTX64.CSV :
# hexdump -C /boot/efi/EFI/ubuntu/BOOTX64.CSV
00000000 73 00 68 00 69 00 6d 00 78 00 36 00 34 00 2e 00 |s.h.i.m.x.6.4...|
00000010 65 00 66 00 69 00 2c 00 75 00 62 00 75 00 6e 00 |e.f.i.,.u.b.u.n.|
00000020 74 00 75 00 2c 00 2c 00 54 00 68 00 69 00 73 00 |t.u.,.,.T.h.i.s.|
00000030 20 00 69 00 73 00 20 00 74 00 68 00 65 00 20 00 | .i.s. .t.h.e. .|
00000040 62 00 6f 00 6f 00 74 00 20 00 65 00 6e 00 74 00 |b.o.o.t. .e.n.t.|
00000050 72 00 79 00 20 00 66 00 6f 00 72 00 20 00 75 00 |r.y. .f.o.r. .u.|
00000060 62 00 75 00 6e 00 74 00 75 00 0a 00 |b.u.n.t.u...|
0000006c
# iconv --from-code=ucs2 /boot/efi/EFI/ubuntu/BOOTX64.CSV
shimx64.efi,ubuntu,,This is the boot entry for ubuntu
-
Pourtant Dell mentionne Windows Server 2012, il me semblait que le Secure Boot était obligatoire pour la certification Microsoft (s'il y a ce qu'il faut matériellement, le support peut avoir été ajouté via une mise à jour).
Les fichiers semblent corrects, donc on peut raisonnablement espérer que tout se passe bien au reboot.
-
Windows Server 2012 <=> Windows 7
Ce ne se serait pas Windows Server 2018 (qui tout comme Windows 8 ) qui demande le secure boot pour la certification ?
-
Server 2012 correspond à windows 8. C'est 2008 R2 pour 7.
Apparemment seul windows 8 était concerné par l'obligation du secure boot si les constructeurs voulaient la certification.
Secure Boot is required for all retail Windows 8 computers that get Microsoft’s stamp of approval.
Source : https://www.derekseaman.com/2012/08/how-to-configure-windows-8server-2012.html
-
Windows Server 2018 n’existe pas, c’est 2016 et 2019
-
Il faut que je dorme plus !