Repository navigation
UC20 boot error "Failed to make path absolute" on Fitlet2 device #16
Description
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.
Activity
anonymouse64 commentedon Mar 26, 2021
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 commentedon Mar 26, 2021
I'm usung 20/stable which is revision 743.
Seems to be the only version available in all channels.
Using the latest Ubuntu 20.04 live CD image (kernel 5.8.0-43-generic) it reports:
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
sddriver and as parent theahcidriverTried booting from a SD card (device has a microSD reader) which uses
mmcblkandsdhci-pcidrivers, but that resulted in the same error.osteenbergen commentedon Mar 26, 2021
Using the Ubuntu Live CD and flashing the image to the internal disk works.
anonymouse64 commentedon Mar 26, 2021
@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 commentedon Mar 26, 2021
Yes I did ran them against the
/dev/sdc(ainternal,bwas 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 commentedon Apr 13, 2021
Hi, do you need more details/tests to be run before this can be solved? Thanks
anonymouse64 commentedon Apr 13, 2021
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 commentedon Oct 2, 2021
IMHO, this issue could be related to canonical/snapd#10861 .
Let us see if that fixes this issue as well.
xanonid commentedon Oct 27, 2021
@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 commentedon Oct 27, 2021
@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.