Auteur Sujet: Ubuntu server 18.04: Bug aprés mise à jour de "grub-efi-amd64-signed"  (Lu 13713 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 47 079
    • Twitter LaFibre.info
Ubuntu server 18.04: Bug aprés mise à jour de "grub-efi-amd64-signed"
« Réponse #36 le: 06 janvier 2020 à 21:55:07 »
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 +++

hwti

  • Abonné Orange Fibre
  • *
  • Messages: 2 237
  • Chambly (60)
Ubuntu server 18.04: Bug aprés mise à jour de "grub-efi-amd64-signed"
« Réponse #37 le: 06 janvier 2020 à 22:02:15 »
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 ..."

vivien

  • Administrateur
  • *
  • Messages: 47 079
    • Twitter LaFibre.info
Ubuntu server 18.04: Bug aprés mise à jour de "grub-efi-amd64-signed"
« Réponse #38 le: 06 janvier 2020 à 22:07:50 »
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 +++

Thornhill

  • Abonné SFR fibre FttH
  • *
  • Messages: 3 976
  • Saint-Médard-en-Jalles (33)
Ubuntu server 18.04: Bug aprés mise à jour de "grub-efi-amd64-signed"
« Réponse #39 le: 06 janvier 2020 à 23:08:04 »
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

hwti

  • Abonné Orange Fibre
  • *
  • Messages: 2 237
  • Chambly (60)
Ubuntu server 18.04: Bug aprés mise à jour de "grub-efi-amd64-signed"
« Réponse #40 le: 07 janvier 2020 à 01:48:21 »
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
Citer
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
Citer
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

vivien

  • Administrateur
  • *
  • Messages: 47 079
    • Twitter LaFibre.info
Ubuntu server 18.04: Bug aprés mise à jour de "grub-efi-amd64-signed"
« Réponse #41 le: 07 janvier 2020 à 09:16:45 »
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, un serveur de la même génération)

hwti

  • Abonné Orange Fibre
  • *
  • Messages: 2 237
  • Chambly (60)
Ubuntu server 18.04: Bug aprés mise à jour de "grub-efi-amd64-signed"
« Réponse #42 le: 07 janvier 2020 à 10:15:32 »
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.

vivien

  • Administrateur
  • *
  • Messages: 47 079
    • Twitter LaFibre.info
Ubuntu server 18.04: Bug aprés mise à jour de "grub-efi-amd64-signed"
« Réponse #43 le: 07 janvier 2020 à 10:48:23 »
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

hwti

  • Abonné Orange Fibre
  • *
  • Messages: 2 237
  • Chambly (60)
Ubuntu server 18.04: Bug aprés mise à jour de "grub-efi-amd64-signed"
« Réponse #44 le: 07 janvier 2020 à 13:03:46 »
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.

vivien

  • Administrateur
  • *
  • Messages: 47 079
    • Twitter LaFibre.info
Ubuntu server 18.04: Bug aprés mise à jour de "grub-efi-amd64-signed"
« Réponse #45 le: 07 janvier 2020 à 15:01:03 »
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 ?

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 345
Ubuntu server 18.04: Bug aprés mise à jour de "grub-efi-amd64-signed"
« Réponse #46 le: 07 janvier 2020 à 16:37:35 »
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.

Citer
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

Taboin

  • Abonné Free fibre
  • *
  • Messages: 164
  • Technicien informatique | AS207536 | Aube (10)
    • mon site o/
Ubuntu server 18.04: Bug aprés mise à jour de "grub-efi-amd64-signed"
« Réponse #47 le: 07 janvier 2020 à 16:40:29 »
Windows Server 2018 n’existe pas, c’est 2016 et 2019