Bug#844237: Incorrect handling of device major/minor
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:bernhardu@mailbox.org]
> Sent: Friday, April 14, 2017 7:36 AM
> To: 844237@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
Reply to: