UC20 does not auto-import assertions until the third boot

Bug #1903959 reported by Alfonso Sanchez-Beato
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

I have created a UC20 image with latest snaps in stable. Then, I create a small disk image to hold a system-user assertion:

dd if=/dev/zero of=import.img bs=1024 count=100
mkfs.vfat import.img
mkdir mnt
mount import.img mnt/
cp auto-import.assert mnt/
umount mnt

I run qemu with both UC20 and import images attached as disks:

qemu-system-x86_64 -enable-kvm \
                   -bios /usr/share/OVMF/OVMF_CODE.fd \
                   -m 4096 -net nic \
                   -net user,hostfwd=tcp: \
                   -drive if=ide,format=raw,file=uc20.img \
                   -drive if=ide,format=raw,file=import.img

But, I cannot ssh into the device after waiting for a few minutes. If I stop qemu (by hard kill), then re-start it and wait again, I still cannot ssh into the VM. However, the *third time* I start qemu, I can finally ssh in the device with the user and password specified in the system-user assertion. I assume this should have been possible on first boot.

See attached tarball for the assertions.

FTR, if I simulate insertion of import.img using QEMU console 2-3 minutes after the system has started on first boot, the assertion is imported. So this is a race condition.

Tags: uc20
Revision history for this message
Alfonso Sanchez-Beato (alfonsosanchezbeato) wrote :
Revision history for this message
Alfonso Sanchez-Beato (alfonsosanchezbeato) wrote :

Looking at first boot log, auto-import is failing:

Nov 12 13:33:38 ubuntu systemd-udevd[575]: sdb: Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/sdb' failed with exit code 127.

Maybe there is a race condition, as snapd starts some time later:

Nov 12 13:33:59 ubuntu systemd[1]: Started Snap Daemon.

description: updated
Revision history for this message
Ian Johnson (anonymouse67) wrote :

I don't think this is a race condition, snap auto-import was recently updated to only consider removable devices, so in order for snap auto-import to recognize your block device as a valid auto-import target, it must have the removable bit set in sysfs, see https://github.com/snapcore/snapd/blob/master/cmd/snap/cmd_auto_import.go#L293

TBH, it seems a bug that it worked for you on the third boot...

What I do to test auto-import of assertions with QEMU is to add the following options:

     -drive "if=none,id=stick,format=raw,file=assertions.disk,cache=none" \
     -device nec-usb-xhci,id=xhci \
     -device usb-storage,bus=xhci.0,removable=true,drive=stick \
     -usb \

where assertions.disk is the disk image that you create with auto-import.assert

tags: added: uc20
Revision history for this message
Alfonso Sanchez-Beato (alfonsosanchezbeato) wrote :

@Ian I see, but even if you consider removable devices I have seen a race condition. I start qemu (this is the first UC20 boot after having created an image) with:

-device piix3-usb-uhci

Then I connect to the monitor and run:

drive_add 0 id=usb_disk,if=none,format=raw,file=$import_img
device_add usb-storage,id=usb_disk,drive=usb_disk

If I do it too early (~60 sec) the assertion is not imported. I have to wait around 3 minutes.

Changed in snapd:
importance: Undecided → High
Revision history for this message
roland wisdom (captaingreen55) wrote :

It’s perfect

Changed in snapd:
status: New → Triaged
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.