Unable to boot after recent update

On a MicroOS KVM VM I am having problem booting after a recent snapshot. The last known working update was done on June 16th (kernel 5.18.2). The next time an updated was attempted was 23rd June with kernel 5.18.4 and again the week after with 5.18.6. Both of those snapshots fails to boot (except in recovery mode), and I’ve had to restore the earlier snapshot.

When booting the only message I get is the following, waiting up to five minutes, and nothing happens.


dracut-initqueue: Warning: File locking is disabled

I get that on the older snapshot also, however boot works fine.

When sending a reset message to the VM I do however get a bunch of messages similar to the below:


dracut-pre-pivot: /sbin/restorecon: Could not set context for /var/lib/docker/btrfs/subvolumes/.../usr/share/doc/libuniversal-isa-perl/copyright: No such file or directory

This happens on lot of different files, with no specific pattern - although it’s hard for me to extract the full log.

After a failed boot, I’ve attempted to get the logs for the failed boot system i.e:


journalctl -b -1

However, there are no entries at all for the failed boot attempt.

Given it’s hard to extract the logs, I’m finding it hard to debug the issue, and hoping someone could give me some pointers.

Thanks!

Does /var/log/journal exist? If not, there will be no journal except for the current boot. Presumably things work the same on MicroOS the same as in Leap and TW. If it doesn’t exist: create it, or edit /etc/systemd/journal.conf to make the journal persistent.

@jacobbaungard

Is selinux enabled? Sounds like the docker part is not well? I use MicroOS here, but use podman.

@jacobbaungard

Is selinux enabled? Sounds like the docker part is not well? I use MicroOS here, but use podman (integrated with Cockpit).

Thank you, yes selinux was the issue here, thanks. Disabling it completely in the grub config file (and doing transactional-update grub.cfg), then doing an update from the older snapshot, worked. Interestingly, it also failed in permissive mode, had to disable selinux fully.

I noticed there was some new updates to selinux packages, so perhaps something in those updates caused the issues.

Hi
Might be worth a bug report? openSUSE:Submitting bug reports - openSUSE