I’m currently working for a project that uses Gigabyte Brix devices (the GB-BLCE-4000C to be exact, see https://www.gigabyte.com/Mini-PcBarebone/GB-BLCE-4000C-rev-10) in combination with Ubuntu Server 19.04. We’ve equipped these systems with 4GB, a 120 GB SSD and a USB 4G dongle for connectivity. The processor is a Intel Celeron N4000.
We have these systems working for our application by setting up Ubuntu using the normal procedure. Now we are looking into ways of making them OTA updatable. After some research Mender seemed to be the most mature solution, so I’m currently investigating how to setup the Brix for that use.
I had some successes with manually converting the base image we use for use with Mender (got the demo server running in a VM and managed to get the Brix to register itself on the server). But of course this was only part of the things we needed.
Next I tried to use mender-convert to convert the base image of out Ubuntu install into something that would conform to the 4 partition layout that Mender wants to use.
After a number of starting problems with Mender-Convert (my manual changes to install mender were causing problems and I had to go back to the base Ubuntu image that we use to configure the Brix for our use) I finally managed to go through the entire processing chain of mender-convert and I was left with a SDIMG that could be placed on the Brix’s SSD using dd. It contained a 512 MB boot partition, two 16GB rootfs partition and a 87.5 GB data partition.
After placing the image file on the Brix SSD and rebooting I was confronted with a Grub 2.02 command line prompt, but not our Linux OS. Further investigation using the Grub prompt showed that there were indeed 4 partitions on the SSD, (hd0, msdos1) to (hd0, msdos4). Using the available commands I could see that msdos1 contained the boot partitioned (with base dir EFI), msdos2 and msdos3 contained our Ubuntu rootfs and msdos4 contained the data partition (with mender directory).
Using some grub commands I even managed to boot into our Ubuntu rootfs on msdos2. Looking at the contents of the EFI base directory on mdos1 I saw that there were two subdirectories there, “BOOT” and “Ubuntu”. The Mender specific stuff was located in “BOOT”, “Ubuntu” seemed to contain the original boot files from our install (verified by comparing them to the ones on the original boot partition).
Using the grub.cfg that was present on the EFI/BOOT directory with the command configfile would result in a system shutdown.
Looking at the configuration options available in the “mender_convert_config” and “mender_grub_config” files used by mender_convert tool and trying several variations of what looked like relevant settings did not change the behavior of the resulting SDIMG file: we always ended up in the Grub 2.02 prompt!
Which was strange because the latest version of mender-convert had switched to Grub 2.04!
As a final test I booted the Brix in its UEFI shell to see if that would help us out. This gave me a fs0: drive that mapped to the boot partition. Going to the EFI/BOOT directory and running the BOOTX64.EFI executable led to a successful boot of our Ubuntu rootfs on partition 2! I even saw some feedback being printed in the form of a Grub message line and two “lock” lines before the Linux boot sequence took over.
Unfortunately I had removed our USB 4G dongle (because of lack of USB ports for keyboard and other USB devices), so I couldn’t connect to the internet.
So I removed some unused USB device and plugged the 4G dongle back in and rebooted the Brix back to the UEFI prompt to repeat my actions to boot into the Ubuntu rootfs. Only this time I was greeted with a Grub 2.04 prompt. Turns out that the 4G Dongle also has some form of mass storage inside of it and Grub had assigned it to hd0, moving our SSD down to hd1. So the boot no longer worked because the rootfs was now on a different (incorrect) drive!
So I now have two problems:
- why doesn’t the mender-convert generated image boot through to the active rootfs by itself, without me having to do the trick via the UEFI shell?
- if that is fixed, how do I prevent or circumvent the boot failing because the 4G dongle occupies the hd0 device slot in Grub? Is this something that can be done with settings for Mender config files? Strangely enough this was not an issue for the original bootloader, but that used the UUID of the partition to select the rootfs to boot (which won’t work because mender uses an identical UUID for both rootfs partitions)
Any help will be greatly appreciated! If you need more information I’ll gladly supply it.