There's actually at least one other pretty important fix that landed in version 31 too.
https://github.com/rhinstaller/efivar/commit/c950dfce4a04b66e5efde770d82540e5d737f458 I think it's worth including at least those two and applying for a freeze exception in stretch. At least reviewing https://release.debian.org/testing/freeze_policy.html I don't think updating to 31 specifically will be accepted. > -----Original Message----- > From: Bernhard Übelacker [mailto:bernha...@mailbox.org] > Sent: Friday, April 14, 2017 7:36 AM > To: 844...@bugs.debian.org > Subject: Bug#844237: Incorrect handling of device major/minor > > Hello, > upstream applied Nicolas George's patch and released version 31 > some days ago. > I hope it is not too late for stretch? > > As I own an affected device I would like to supply some more > informations and workarounds to people with similar devices. > > Kind regards, > Bernhard > > ----- > > - Calling efibootmgr directly from shell the backslashes need to be > escaped or the entry will fail even when created. > > - Adding --verbose twice to efibootmgr, it outputs also the errors > stored by calls to efi_error function. > > - As a workaround I could still boot to grub by: > - boot into UEFI shell > - enter: fs0:\EFI\debian\grubia32.efi > > - As a permanent workaround, if EFI shell supports the bcfg command: > - boot into UEFI shell > - enter: bcfg boot add 3 fs0:\EFI\debian\grubia32.efi "debian" > - boot order can now possibly rearranged in UEFI menus. > If EFI shell does not support bcfg one could also supply a external EFI > shell e.g. > from [1]. > [1] > https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Obta > ining_UEFI_Shell > > - After I installed a version of libefivar1 with the mentioned patch > applied I got "Could not prepare Boot variable: No space left on device" > After moving some of the files /sys/firmware/efi/efivars/dump-type0* to > another disk the efibootmgr could successfully create the entry. > (These dump-type0* files seem to contain previous linux crashes when > examining them through /sys/firmware/efi/vars/dump-type0*/data ...) > > ----- > > # LANG=C grub-install --verbose --target=i386-efi > ... > grub-install: info: executing efibootmgr -c -d /dev/mmcblk1 -p 1 -w -L debian > -l > \EFI\debian\grubia32.efi. > Could not prepare Boot variable: No such file or directory > grub-install: error: efibootmgr failed to register the boot entry: > Input/output error. > > > # LANG=C efibootmgr --verbose --verbose -c -d /dev/mmcblk1 -p 1 -w -L debian > -l > \\EFI\\debian\\grubia32.efi > Could not prepare Boot variable: No such file or directory > error trace: > creator.c:243 efi_va_generate_file_device_path_from_esp(): could not set disk > and partition name: No such file or directory > creator.c:320 efi_generate_file_device_path_from_esp(): could not generate > File > DP from ESP: No such file or directory > efibootmgr.c:286 make_var(): make_linux_load_option() failed: No such file or > directory > efibootmgr.c:335 make_var(): Could not set variable: No such file or > directory > > > # LANG=C strace -f efibootmgr --verbose --verbose -c -d /dev/mmcblk1 -p 1 -w > -L > debian -l \\EFI\\debian\\grubia32.efi > ... > fstat(3, {st_mode=S_IFBLK|0660, st_rdev=makedev(179, 256), ...}) = 0 > readlink("/sys/dev/block/4275:0", 0x7fff3873b830, 4096) = -1 ENOENT (No such > file or directory) > ... > > # ls -lisah /dev/mmcblk1 /sys/dev/block/179\:256 > 1293 0 brw-rw---- 1 root disk 179, 256 Apr 13 21:17 /dev/mmcblk1 > 12373 0 lrwxrwxrwx 1 root root 0 Apr 13 23:17 /sys/dev/block/179:256 -> > ../../devices/platform/80860F14:00/mmc_host/mmc1/mmc1:0001/block/mmcblk > 1
