I have installed Ubuntu Core onto a DELL Optiplex micro PC (hoping to intend to use this as a wallboard to display a single web page).
Installation seems to have worked, and I have linked it to my Ubuntu One account.
It will (sometimes) boot OK, and when it does I can connect to it from my laptop via SSH successfully (so from this I would assume it is installed correctly, and the hardware is compatible).
However, it regularly gets stuck into a ‘reboot loop’ - it runs through the 2 screens of scrolling messages, and then shows ‘Job snapd-recovery-chooser-trigger.service’ and ‘Job emergency-reboot.service’
Sometimes when I leave it looping through these reboots, it will actually boot succesfully after a number of failures.
Sometimes using F12 to select the boot device and then selecting the UEFI drive will allow it to boot (even though it is defaulted to this device anyway)
I have reset the BIOS to defaults. UEFI is enabled and the only drive in the boot sequence is the SSD. Enable Legacy Option ROMs is off. AHCI is on. Secure Boot is off.
I have tried a Custom Boot Option pointing to \EFI\boot\grub64.efi (and also tried bootx64.efi) Neither of these seem to resolve the issue.
Because the problem seems to be intermittent, it is very hard to troubleshoot this. Could it be a rogue hardware issue? Or is this a Ubuntu issue
I have also noted that each time it does successfully boot, it seems to be issued a new IP address from the DHCP on my router. Not sure if this is relevant, but thought it might mean something to somebody?
I would be very grateful for any thoughts / suggestions on how to troubleshoot this…
To rule out that you are not in something like a “kernel snap update loop” or something similar, you should check snap changes … if there is anything interesting, you can see details with snap change <change ID>
Note that if your BIOS had secure boot enabled during initial install UbuntuCore defaults to turning on TPM backed full disk encryption alongside, that might lead to problems if you just turn off secure boot in the BIOS later (or any TPM related switches in there)…
PS: to keep old logs from former boots in journald you can enable persistent logging (don’t leave that on permanently unless you have spare diskspace) and check them on next boot with sudo journalctl -b-1 (also see the documentation for --list-boots in journalctl):
I don’t think there’s anything obviously problematic there?
It then restarted (without my intervention) and when it came back on (successfully booted on first attempt) it had completed the updates that had failed yesterday:
I can’t recall if SecureBoot was on or off when I installed - so I tried turning this back on in the BIOS and that seems to resolve the problem. Thanks very much for this suggestion!
I’ll do some more research on this to determine if I should leave the device in this configuration, or reinstall with secure boot off - but at least I understand the issue now.
Spoke too soon
Just tried a cold restart, and it is looping restarts again.
After approx. 7 to 9 restarts (it varies) it will boot successfully - very strange…
I’ve reinstalled this morning (this time with Secure Boot off), and I’m still seeing the same issue with multiple restarts before it will load succesfully.
When it did load, I check snap changes again:
As you can see, I haven’t attempted to install any of the modules yet, this is a ‘clean install’ with no apparent errors…
From reading online, it seems that Secure Boot being on shouldn’t be a problem, but the general consensus is that it is not needed.
I checked again a few reboots later, and it then shows that it has started updating the snaps, and I did find this error:
ERROR cannot finish pc-kernel installation, there was a rollback across reboot
But the boot up reboot issue was there before this happened, so I think there may be a fundamental incompatibility with this hardware and Ubuntu core…
I think I’ll try and install ‘full’ ubuntu and see how that behaves - I have since seen an article saying that you can still install the ‘frame’ tool on full ubuntu and have it auto start…
I think it must be a strange hardware quirk / bug.
Just run exactly the same install process on another device (same make / model) and its worked fine first time with no reboot issues whatsoever…
I’ll do some in depth comparisons - maybe it is a slightly different BIOS version or something like that…
I have 3 (supposedly) identical devices. 1 installed ubuntu core successfully and the other 2 both failed.
I checked BIOS versions, and the 2 failing were older, but bringing them up to the same version as the working PC (and reinstalling ubuntu-core) did not resolve the problem. I also tried downgrading to the ‘recommended’ BIOS version for ubuntu (according to the DELL support site), but still no change.
I then noticed that the working PC had 16GB RAM - I doubt that in itself is a requirement, but I wondered if it could be something weird like the motherboard responding differently with 1 DIMM installed (not 2). So I ‘upgraded’ one of the failing PCs to 16Gb, but still no change.
Really frustrating!
