Score:0

Ubuntu 20.04 won't boot following package install (Snap problem?)

co flag

Towards the end of last year I replaced the SSD on my Lenovo Thinkpad L380. I installed Ubuntu 20.04 from live USB with separate /boot and /boot/efi partitions and a single LUKS-encrypted partition for /

Device          Start       End Sectors  Size Type
/dev/nvme0n1p1  2048    1050623 1048576  512M EFI System
/dev/nvme0n1p2 1050624  2549759 1499136  732M Linux filesystem
/dev/nvme0n1p3 2549760 3907028991 3904479232  1.8T Linux filesystem

There is no Windows partition.

The system rebooted fine. I then installed the 20.04 versions of packages from my previous 18.04 installation and restored my home directory from backup.

After a software update last week I restarted the system and it failed to boot. No GRUB menu appeared, I was not prompted for the encryption passphrase and the last line of the log said something about snap. After a long wait, the system restarted by itself. This time the snap messages had gone but still no boot.

I tried suggestions online to get the GRUB menu to appear:

Holding down the SHIFT key from the BIOS screen didn't work.

I booted from live USB, mounted the partitions and edited /etc/default/grub:

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=10
GRUB_TERMINAL=console
GRUB_INIT_TUNE="480 440 1"

and ran update-grub. On restarting I could hear a beep (so the changes must have taken effect) but no menu appeared.

I tried removing the latest kernel, running update-grub and restarting. No change.

I then backed up the package list and home directory and did another clean reinstall. The system restarted fine. However on restoring the packages and my home directory, I had exactly the same problem: Errors from snap and no boot. :

This time I took a screenshot of the log

There are five messages all quite similar. The first one is something like:

systemd-udevd[206]: card0: Process '/usr/lib/snapd/snap-device-helper change snap_snap-store_snap-store /devices/pci0000:00/0000:00:02.0/drm/card failed with exit code 1.

On subsequent restarts, the snap messages had disappeared but still no boot.

I ran boot-repair and saved the log. This restored the GRUB menu so I could then boot into recovery mode.

Now I see the following messages. It takes a long time before they all appear:

Begin: Running /scripts/local-top … Volume group “vgubuntu” not found
  Cannot process volume group vgubuntu
  Volume group “vgubuntu” not found
  Cannot process volume group vgubuntu
Cryptsetup: Waiting for encrypted source device
    UUID=xxxx
Done.
Begin: Running /scripts/local-premount … findfs: unable to resolve ‘LABEL=writable’
Begin: Waiting for suspend/resume device … Begin: Running /scripts/local-block … Cryptsetup: Waiting for encrypted source device
    UUID=xxxx
  Volume group “vgubuntu” not found
  Cannot process volume group vgubuntu
Done.
Cryptsetup: Waiting for encrypted source device
    UUID=xxxx
Done.
Gave up Waiting for suspend/resume device
Done
The required kernel commandline snap_core is not set

Then I'm dumped at the initramfs prompt.

Any suggestions as to what to do next? It's not clear to me which of the above messages is the cause of the problem. The snap_core one seems critical.

vanadium avatar
cn flag
Spearate boot partition? A full boot partition could be the cause of issues.
Martin Burchell avatar
co flag
@vanadium /boot says 51% full. /boot/efi says 2% full
Score:0
co flag

Somehow I had managed to install the package initramfs-tools-ubuntu-core, which is for embedded systems only. Maybe I used a wildcard at some point. Removing this package and re-running the boot-repair at least got rid of the snap errors.

I still had to reinstall from scratch but omitting this package on this attempt had led to a bootable system.

mickmackusa avatar
ve flag
Welcome to Ask Ubuntu and thank you for seeing your question through to a resolution. Please take the [tour].
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.