Installing UC20 in Virtuabox triggers invalid signature after ubuntu-boot not found

The issue here is probably that your VM is setup to boot in BIOS mode, but UC20 requires booting in UEFI mode. I’m not familiar with VirtualBox, but I assume there is some checkbox or something where you can enable UEFI mode for your VM this way.

You are absolutely right. I though about everything else but not that specific point.

Just for the record, Setings > System > Enable EFI (Special OSes only).

At least now it boots although it pops an error about the partition table, but that’s another thing.

Thank you very much.

Can you share what the error about the partition table is?

Sure. Reading more carefully could be something about the secure boot…

So here you say that you are flashing the uc20 image to /dev/sdb, but the error message below references /dev/sda, are you sure that:

  1. there is only one disk attached to the VM when UC20 is booted
  2. there are no other partitions on the disk that UC20 is installed to other than the BIOS Boot and the EFI System partitions

If so, can you boot the live Ubuntu CD back up with this disk attached and run this command:

sudo sfdisk --dump /dev/sda

(or sdb, whatever it shows up as in the live CD environment)


I got that thing sorted out. Instead, I have a question about UC20 itself.

I mounted a custom image manually to check which partitions has (never booted that image), but for my surprise, it only mounts two partitons, and there is no sign of /writtable.

After that, I booted the image in a Virtual Machine and after the configuration and successful ssh, it does have /writtable. Does that mean that unless you configure a user with a SSO, the image does not create the /writtable partition? I want to skip the console-conf, so I tried to create a file just as it says here. Isn’t that possible anymore (–disable console-conf is deprecated in uc20) and I’m forced to create a custum gadget to skip console-conf?


With UC20 everything changed :wink:

In 16 and 18 the /writable partition was pre-created and just grown to full size of the disk during first boot. With the introduction of full disk encryption this has changed and the partition is actually freshly created (and encrypted if possible) during first boot instead.

To skip console-conf in UC20 you need to set service.console-conf.disable from a defaults: entry in your gadget.yaml now (since you can not randomly tinker with the (non-existing) filesystem anymore which the ubuntu-image option did) …

1 Like

Thanks for your explanation, ogra.

I’m going to play a bit with the gadget.yaml. If i’m successful, I will add some steps for other ppl to follow in case they have the same issues.

Thank you again.

So, as far as I understand from here, the idea for me is to modify the gadget.yaml and append this:

        disable: true

then using my model (which is this one) and adding the extra snaps the one i’ve just created, generate the image, right? Should I remove from my own model the pc-gadget, as i’m modifying the one that i’ve got from git? Also, should I change the grade of the model?


you should just point to your locally built gadget snap with the --snap argument in ubuntu-image, for UC20 i think you also need to make your model “dangerous” but keep the pc-gadget entry …

Hi again, ogra.

I’m struggling a bit with an error that I get when building the pc-amd64-gadget. Even without modifying any file, it fails to build grub, here is the error.

Any ideas? Haven’t touched any file at all. (I’m doing this step from a laptop, form the vm i can not make it work, it gets frozen every single time, could it be that it does not have secure boot enabled and it tries to copy a file that does not exist?)

i think with UC20 some special setup is required to build the pc gadget:

1 Like

Due to the issue @ogra described in that post, I would recommend for folks trying our gadget snaps to just unpack the upstream gadget snap and modify the files from that snap and repack it with snap pack rather than try to build natively with snapcraft. So something like this:

$ snap download pc --channel=20/stable --basename=pc-gadget
$ unsquashfs -d pc-gadget pc-gadget.snap
$ # edit ./pc-gadget/meta/gadget.yaml to your desire
$ snap pack pc-gadget --filename new-pc-gadget.snap
$ ubuntu-image snap --snap pc-gadget.snap model.assertion

Thanks for the advice ijohnson.

I’ll try that too. At least I got it running, but I had to include the wget package and override-stage section of shim-signed_1.43+uc20.4+15+1552672080.a4a1fbe-0ubuntu2_amd64.deb, since it was impossible to me to get it working without it, unable to find the shim-dualsigned , just like the issue in the link ogra provided, using the pc-amd64-gadget snap, (i’m building it from a ubuntu desktop 20.04 os, maybe that’s what is wrong here?).

Hi guys, new issue. I did a system-user assertion using make-system-user using the same key as the one i used to sign the model. Apparently it does not work and since a few days ago, the documentation on how to make a system-user is gone. Only mentioning that we should use snap create-user, and using snap create-user <email> gives me access denied. Using sudo, it gives me “error while creation user: system user administration via snapd is not allowed in this system”.

Any tips on that? thanks.

looks to me like it is still there:

(but that also has a note about UC20 not supporting them yet, not sure how accurate that still is though)

Sorry we are in the process of moving our docs around, hence why you may have noticed some things moving around or appear to be missing. Please flag us if you can’t find anything you thought was there before.

This is wrong, I will look into why that note is there and remove it. Where you can put a system user assertion has changed but they are very much still supported and work for UC20. Off the top of my head, the main change is that you can no longer put them on non-removable partitions like ubuntu-seed, etc. and have to put it on a specific removable media storage like a USB drive, etc.

This is likely because you created an account with console-conf, and hence are already managing the device, and we don’t by default allow you to create another user account from the command line with snap create-user if there is already a “system user” on the account (console-conf also calls create-user internally, which creates your LP user as the “system user”)

editing can be done via discourse i think:

Apparently creating a new key and registering it fixed this error. Nonetheless, when I create a system user, it pops an error, although it creates the user assertion.

error: cannot sign assertion: cannot sign using GPG: /usr/bin/gpg --personal-digest-preferences SHA512 --default-key <mykeyID> --detach-sign failed: exit status 2 ("gpg: WARNING: unsafe ownership on homedir '/home/zap2x/.snap/gnupg'\ngpg: signing failed: No such file or directory\ngpg: signing failed: No such file or directory\n")
Done. You may copy auto-import.assert to a USB stick and insert it into an unmanaged Core system, after which you can log in using the username and password you provided.

That means that the even if the user assertion is created but does not include the one i’m trying to create, it will never be created in the device where I insert that assertion, right? Since it cannot sign with my key, it will do it with one of the cannonical?

How do I fix this? Is it just a permission issue fixable with chmod? both the /gnugp and its contents belongs to my user and the permissions are set as follows:

zap2x@LaPajareria:~/Desktop/newUC20$ ll /home/zap2x/.snap/
total 16
drwx------  3 zap2x zap2x 4096 feb 12 10:49 ./
drwxr-xr-x 33 zap2x zap2x 4096 feb 12 10:59 ../
-rw-------  1 zap2x zap2x  163 feb 12 10:49 auth.json
drwx------  4 zap2x zap2x 4096 feb 12 11:07 gnupg/
zap2x@LaPajareria:~/Desktop/newUC20$ ll /home/zap2x/.snap/gnupg/
total 32
drwx------ 4 zap2x zap2x 4096 feb 12 11:07 ./
drwx------ 3 zap2x zap2x 4096 feb 12 10:49 ../
drwx------ 2 zap2x zap2x 4096 feb 12 10:56 openpgp-revocs.d/
drwx------ 2 zap2x zap2x 4096 feb 12 10:56 private-keys-v1.d/
-rw-rw-r-- 1 zap2x zap2x 3828 feb 12 10:56 pubring.kbx
-rw-rw-r-- 1 zap2x zap2x 2562 feb 12 10:54 pubring.kbx~
srwx------ 1 root  root     0 feb 12 11:07 S.gpg-agent=
srwx------ 1 root  root     0 feb 12 10:22 S.gpg-agent.browser=
srwx------ 1 root  root     0 feb 12 10:22 S.gpg-agent.extra=
srwx------ 1 root  root     0 feb 12 10:22 S.gpg-agent.ssh=
-rw-r----- 1 zap2x zap2x  676 feb 12 10:46 sshcontrol
-rw------- 1 zap2x zap2x 1360 feb 12 10:56 trustdb.gpg

Thanks again.

your pubring.* permissions look too open, they should only be rw for the user …