Currently we are using Ubuntu Server 19.04 for our Brix devices in conjunction with Mender. My colleague wants to update our rootfs to version 20.04 because that is a LTS version while 19.04 isn’t (we had to switch to 19.04 from 18.04 because of incompatibility of a tool that we needed to run).
The question that we have is this: will upgrading the Linux OS on a Mender Client through Ubuntu’s upgrade process mess anything up with regards to the Mender Client install? Does it for instance mess up the boot partition modifications?
I guess we could find out by simply doing the upgrade, but my colleague is on a course this week and if we could have a indication one way or another before he is back, that would make our next steps a lot clearer (also for any future update should we feel the need to switch to the next LTS version).
@PJK it’s hard to say exactly what the Ubuntu upgrade will do and it may indeed cause issues for Mender. Our normal use case is to do the upgrade in the pre-mender-convert golden master and then run mender-convert on that to ensure that you don’t have such issues.
Well, we bit the bullet and did the Ubuntu update on RootfsA of our Menderized system.
After this was done we saw that the device was again booting via the /EFI/UBUNTU (or /boot/efi/EFI/UBUNTU directory after the rootfs has booted). In the past it was enough to remove the UBUNTU directory to get a Menderized image to boot correctly, but in this case that just led to a bootloop with the message “System BootOrder not found. Initializing defaults. Reset System” being shown briefly (I had to video the screen in order to be able to read that message.
Is there anyway we can restore whatever is wrong with the bootloader? I’ve been looking through the mender-convert scripts, but as a non-Go software developer I’m getting quite lost in the specific syntax.
Any help is appreciated, otherwise we’ll have to start all over again with creating a new device installation.
Can you try using efibootmgr to set a new BootOrder? You can see the list of candidates with no arguments, and should be able to activate and deactivate candidates with -a and -A.
Hi, I did that, but somehow the boot order change doesn’t stick. I do see a message being flashed on the screen after reboot stating that Secure Boot has been enabled.
It could be that this is something the Ubuntu install did, as I’m certain that we didn’t turn this option on. Also I noticed that the Ubuntu install had also replaced de .efi files in the /EFI/BOOT directory, so I got those back from a previous image. This however did not change the booting behavior.
I’ve tried switching off Secure Boot in the UEFI setup screen (what used to be the BIOS screen) after changing the boot order, but before it boots, but that didn’t help either. I’m thinking about removing the bootorder entry for UBUNTU entirely using efibootmgr, just to see if that changes things.
My colleague in the mean time has created a new basic installation of Ubuntu server 20.04 and configured it for normal use. So if nothing helps I’ll Menderize that one, though it might lead me to the same position I’m now in if it keeps turning Secure Boot on from the rootfs.