UC20 boot error "Failed to make path absolute" on Fitlet2 device

[osteenbergen]

Trying to build a custom image for the Compulab Fitlet2 (just a extended pc-amd64-gadget) and kept getting this error. Using the original ubuntu-core-20-amd64.img.xz from https://cdimage.ubuntu.com/ubuntu-core/20/stable/current/ results in the same error. The device is booting of USB key.

Already have a working Core16 image, device can run regular Ubuntu 20.04 from USB. Image works on laptop and QEMU, just not on this device.

Error reads:
the-tool[237]: error: Failed to make path /dev/disk/by-partuuid/...: No such file or directory

Partition UUID matches the ubuntu-seed partition of the official image, on the custom image it points to the ubuntu-boot partition. Have tried different USB keys, but all of them report the same error.

Device specs:

• Intel Atom X7-E3950
• 4GB Memory

Just to be sure I tried booting using UEFI and legacy mode, with and without secure boot enabled (not configured), all result in the same error.

USB is "hp v195b" which is logged at 2.7 in the screenshot, after the error has occurred. However other tests show that the error occurs after the message related to the USB key.

[anonymouse64]

What channel are you using for the kernel snap? Have you tried using the edge channel of the kernel snap?

Hi, can you boot into a live 20.04 session and follow these instructions for determining what kernel module the disk drive/device that you are trying to use as the install device for UC20 needs?

https://unix.stackexchange.com/questions/97676/how-to-find-the-driver-module-associated-with-a-device-on-linux/125272#125272

I suspect that this is similar to https://bugs.launchpad.net/ubuntu-core-initramfs/+bug/1896528 but probably a different kernel module since the ones mentioned in that bug have been added.

[osteenbergen]

I'm usung 20/stable which is revision 743.

Seems to be the only version available in all channels.

  20/stable:        5.4.0-70.78.1  2021-03-24 (743) 284MB -
  20/candidate:     5.4.0-70.78.1  2021-03-24 (743) 284MB -
  20/beta:          5.4.0-70.78.1  2021-03-24 (743) 284MB -
  20/edge:          5.4.0-70.78.1  2021-03-24 (743) 284MB -

Using the latest Ubuntu 20.04 live CD image (kernel 5.8.0-43-generic) it reports:

$ ls -l /dev/sdb
brw-rw---- 1 root disk 8, 16 Mar 26 14:58 /dev/sdb
$ readlink /sys/dev/block8\:16/device/driver
../../../../../../../../../bus/scsi/drivers/sd

The script posted returns the following drivers: sd, usb-storage, usb, xhci_hcd.
There is a disk installed in the system which also uses the sd driver and as parent the ahci driver
Tried booting from a SD card (device has a microSD reader) which uses mmcblk and sdhci-pci drivers, but that resulted in the same error.

[osteenbergen]

Using the Ubuntu Live CD and flashing the image to the internal disk works.

[anonymouse64]

@osteenbergen to be clear, you ran the mentioned script against the USB device (or SD card) you are trying to boot from, not the media that the Ubuntu Live CD was running from?

[osteenbergen]

Yes I did ran them against the /dev/sdc (a internal, b was live cd) and /dev/mmcblk0. Now that UC20 boots I also ran the script from within UC20 and it returns the same information for the USB key.

[osteenbergen]

Hi, do you need more details/tests to be run before this can be solved? Thanks

[anonymouse64]

No, we just need time to test out adding those kernel modules to the initrd and then test that it fixes the issue. Unfortunately testing changes like these is rather involved since you need to add the snakeoil keys to a device's platform trusted keys, which is easy to do in QEMU, but then requires setting up QEMU to boot from a virtual USB drive which I have not yet had time to play around with very much.

[stulluk]

IMHO, this issue could be related to canonical/snapd#10861 .

Let us see if that fixes this issue as well.

[xanonid]

@stulluk With recent snapd (2.53.1+git284.g482f8c7), I can reproduce the issue on booting to ubuntu core 20 (using a usb key on a fast pc). Seems that the PR did not fix it.

[anonymouse64]

@xanonid unfortunately there is quite a lag between landing fixes to snap-bootstrap in snapd and being able to test that change in the core-initrd, since that change needs to land in the deb of snapd in the snappy-dev/image PPA, and then the ubuntu-core-initramfs debian package in the snappy-dev/image PPA needs to be rebuilt, then the kernel snaps need to be rebuilt to pick up that new version of the debian package.

Perhaps @alfonsosanchezbeato or @stulluk could trigger a rebuild/version bump of the ubuntu-core-initramfs debian package in that PPA, then the next kernel snap rebuild will get the snap-bootstrap from 2.53.1.