From 93sam at debian.org Tue May 14 17:06:31 2019 From: 93sam at debian.org (Steve McIntyre) Date: Tue, 14 May 2019 17:06:31 +0100 Subject: This thing on? Message-ID: <20190514160631.GM4136@tack.einval.com> Checking addresses... -- Steve McIntyre, Cambridge, UK. steve at einval.com < Aardvark> I dislike C++ to start with. C++11 just seems to be handing rope-creating factories for users to hang multiple instances of themselves. From ard.biesheuvel at linaro.org Thu May 30 14:48:51 2019 From: ard.biesheuvel at linaro.org (Ard Biesheuvel) Date: Thu, 30 May 2019 15:48:51 +0200 Subject: efivar soc root parsing Message-ID: Hi all, Looking at efivar-37 sources in debian today, I noticed the following: /* * support for soc platforms * * various devices /sys/dev/block/$major:$minor start with: * maj:min -> ../../devices/platform/soc/$DEVICETREE_NODE/$BLOCKDEV_STUFF/block/$DISK/$PART * i.e.: soc/1a400000.sata/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda1 * ^ dt node ^ blockdev stuff ^ disk * I don't *think* the devicetree nodes stack. */ which assumes that the root of a DT hierarchy is always called soc/ This appears to be based on some APM platform, which happens to organize its DT hierarchy that way. However, in the general case, block devices could reside anywhere in the DT hierarchy, and so this code is highly non-portable. This seems to have broken the Debian installer for 32-bit ARM (and most likely DT based 64-bit ARM as well), since it no longer uses efibootmgr but uses efivar to manipulate boot entries directly. I am not exactly sure what this code does or how to fix it, so suggestions welcome. -- Ard. From steve at einval.com Thu May 30 15:30:46 2019 From: steve at einval.com (Steve McIntyre) Date: Thu, 30 May 2019 15:30:46 +0100 Subject: efivar soc root parsing In-Reply-To: References: Message-ID: <20190530143046.GH5974@tack.einval.com> On Thu, May 30, 2019 at 03:48:51PM +0200, Ard Biesheuvel wrote: >Hi all, > >Looking at efivar-37 sources in debian today, I noticed the following: > > >/* > * support for soc platforms > * > * various devices /sys/dev/block/$major:$minor start with: > * maj:min -> ../../devices/platform/soc/$DEVICETREE_NODE/$BLOCKDEV_STUFF/block/$DISK/$PART > * i.e.: >soc/1a400000.sata/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda1 > * ^ dt node ^ blockdev >stuff ^ disk > * I don't *think* the devicetree nodes stack. > */ > > >which assumes that the root of a DT hierarchy is always called soc/ > >This appears to be based on some APM platform, which happens to >organize its DT hierarchy that way. However, in the general case, >block devices could reside anywhere in the DT hierarchy, and so this >code is highly non-portable. Nod. I'm seeing problems using this with a virtio-based armhf VM running on arm64: root at debian:~# efibootmgr -c -d /dev/vda -p 1 -w -L debian -l \EFI\debian\grubarm.efi -v -v -v Could not prepare Boot variable: Success error trace: linux.c:462 device_get(): parsing soc_root failed: Success creator.c:194 efi_va_generate_file_device_path_from_esp(): could not get ESP disk info: Success creator.c:349 efi_generate_file_device_path_from_esp(): could not generate File DP from ESP: Success efibootmgr.c:287 make_var(): make_linux_load_option() failed: Success efibootmgr.c:336 make_var(): Could not set variable: Success And looking at the setup for the virtio disk containing the ESP: root at debian:~# ls -al /sys/block/vda/device/driver/ total 0 drwxr-xr-x 2 root root 0 May 30 12:35 . drwxr-xr-x 5 root root 0 May 30 12:35 .. --w------- 1 root root 4096 May 30 12:35 bind lrwxrwxrwx 1 root root 0 May 30 12:35 module -> ../../../../module/virtio_blk --w------- 1 root root 4096 May 30 12:35 uevent --w------- 1 root root 4096 May 30 12:35 unbind lrwxrwxrwx 1 root root 0 May 30 12:35 virtio2 -> ../../../../devices/platform/3f000000.pcie/pci0000:00/0000:00:03.0/virtio2 >This seems to have broken the Debian installer for 32-bit ARM (and >most likely DT based 64-bit ARM as well), since it no longer uses >efibootmgr but uses efivar to manipulate boot entries directly. > >I am not exactly sure what this code does or how to fix it, so >suggestions welcome. I'm thinking it *looks* like it's trying to find the right device for the ESP, but I'm struggling to follow the code here. :-/ -- Steve McIntyre, Cambridge, UK. steve at einval.com "Yes, of course duct tape works in a near-vacuum. Duct tape works anywhere. Duct tape is magic and should be worshipped." -― Andy Weir, "The Martian"