Dual boot toggles partition at each reboot. GRUB UEFI (x86)

General Discussions
1

Hi, I have converted a regular debian linux with mender-convert and installed the Image at a x86 PC.
There are one boot partition, two linux partitions and a data partition.

After the installation of the image that mender-convert created it didn’t boot, I just got the grub prompt.
Then I setup grup to be able to boot:
grub> set root=(hd0,2)
grub> linux /boot/<linuxname.img> root=/dev/sda2
grub> initrd /boot/<initrd.img>
grub> boot
And finaly at linux to make the grub adaption permanent:
sudo grub-mkconfig -o /boot/efi/EFI/debian/grub.cfg

I have the strange behavior that the linux partition toggles mostly at reboot, not always but at approx. 8 of 10 reboots its toggling the linux partition. (Visible at lsblk)

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 238,5G 0 disk
├─sda1 8:1 0 518,8M 0 part /boot/efi
├─sda2 8:2 0 42,7G 0 part /
├─sda3 8:3 0 42,7G 0 part
└─sda4 8:4 0 146,5G 0 part /data

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 238,5G 0 disk
├─sda1 8:1 0 518,8M 0 part /boot/efi
├─sda2 8:2 0 42,7G 0 part
├─sda3 8:3 0 42,7G 0 part /
└─sda4 8:4 0 146,5G 0 part /data

“sudo efibootmgr --verbose” shows that the boot is from debian HD(1,GPT,c140e[…]03664)/File(\EFI\DEBIAN\GRUBX64.EFI)…BO (This stays always the same , even if the partition used is changing)

Also I have found out that I have multiple grub.cfg files at my system. The used one is most prapable /boot/efi/EFI/debian/grub.cfg

Existing grub.cfg files
/boot/grub/grub.cfg
/boot/efi/EFI/debian/grub.cfg
/boot/efi/EFI/BOOT/grub.cfg
/usr/share/doc/grub-common/examples/grub.cfg

Any suggestions to get rid of this toggling of used linux partition? I want it to toggle only if I do a mender system update, not at each reboot… Thanks :slight_smile:

2

I’m not sure grub-mkconfig is setup to work with our custom grub scripts. I suggest you find out the root cause of the initial boot failure first. One possibility is to use partuuids to specify the partitions instead of hard-coding them. @dellgreen do you have a local.conf snippet to show how to enable that?

Drew

1 Like
3

As @drewmoseley says I would be more concerned as to why your bootloader is not working properly after the mender-convert process as manual intervention shouldn’t be required. The grub config installed by mender-convert should be the following one:

/boot/efi/EFI/BOOT/grub.cfg

In my mender-convert config file i have the following to enable/activate PARTUUID’s

MENDER_PARTITION_SCHEME="gpt"
MENDER_ENABLE_PARTUUID="y"
MENDER_BOOT_PART="/dev/disk/by-partuuid/26445670-f37c-408b-be2c-3ef419866620"
MENDER_ROOTFS_PART_A="/dev/disk/by-partuuid/26445670-f37c-408b-be2c-3ef419866621"
MENDER_ROOTFS_PART_B="/dev/disk/by-partuuid/26445670-f37c-408b-be2c-3ef419866622"
MENDER_DATA_PART="/dev/disk/by-partuuid/26445670-f37c-408b-be2c-3ef419866623"
1 Like
4

Great, Thanks for your answer. I will try immediately :smiley:

5

I have rebuild everything again as proposed by @drewmoseley with mender-convert and the configuration options from @dellgreen , but unfortunately it is still resulting in a grub prompt…

6

At this point I would probably start double checking the EFI directory to ensure the conversion process hasn’t preserved something it shouldn’t from your golden master. An example of one of mine for Ubuntu can be seen below. I would also check inside the grub.cfg file to see if the partition information has correctly been set by the conversion process.

/boot/efi
├── EFI
│   └── BOOT
│       ├── BOOTX64.EFI
│       ├── grub.cfg
│       ├── mender_grubenv1
│       │   ├── env
│       │   ├── lock
│       │   └── lock.sha256sum
│       └── mender_grubenv2
│           ├── env
│           ├── lock
│           └── lock.sha256sum
└── ubuntu
    ├── initrd.img-5.8.0-50-generic
    └── vmlinuz-5.8.0-50-generic
7

Thanks for your reply. I have indeed remainings of my Golden master debian image that was used as input for mender-convert:

host@mender:/data/mountMender$ tree
    .
    └── EFI
        ├── BOOT
        │   ├── bootx64.efi
        │   ├── grub.cfg
        │   ├── mender_grubenv1
        │   │   ├── env
        │   │   ├── lock
        │   │   └── lock.sha256sum
        │   └── mender_grubenv2
        │       ├── env
        │       ├── lock
        │       └── lock.sha256sum
        ├── debian
        │   ├── BOOTX64.CSV
        │   ├── fbx64.efi
        │   ├── grub.cfg
        │   ├── grubx64.efi
        │   ├── mmx64.efi
        │   └── shimx64.efi
        └── Dell
            └── BootOptionCache
                └── BootOptionCache.dat
8

I’m not an expert on this topic and not clear on how mender bootstraps with respects to efi files, and I think the mender team can better answer this, but you have an awful lot of efi files. My initial guess would be your uefi is going around the mender booltloader and trying to start from one of the Debian efi files instead of the mender efi file. @drewmoseley is there some documentation somewhere that explains how mender bootstraps itself with UEFI as i’m strugging to find anything to link to?

9

I don’t think the internals are documented anywhere except for the code. @kacf is the expert on the Grub integration so hopefully, he can provide some input.
Drew

10

Mender doesn’t really bootstrap itself as much as it “offers” itself as a bootloader candidate to UEFI. Which one gets booted depends on what is set in the firmware. It’s common that BOOT is the one which is booted first, but in this case it looks like debian ranks higher.

The boot order can be changed inside the Boot Menu of the board, or using the efibootmgr. I think it’s the -o option, but you might want to double check the syntax in the man page.

11

so presumably if @trailsurfer deletes the contents of the debian and Dell folder then it will be forced to use the mender one?

12

Probably, but if it’s an entry that wasn’t in the list before, there is a chance it might end up at the bottom of the boot list, below things like MemCheck. I think most UEFI providers are smarter than that though.

2 Likes
13

Thanks for all the suggestions, I will try your suggestions now and hope that I get it fixed. Tanks a lot @dellgreen @kacf and @drewmoseley :slight_smile:

14

Just to close this topic, The problem was identified. The outcome was that I have used mender-convert the wrong way, and the resulting image was not able to boot “out of the box”, I tried to adjust the grub loader setup to get the image booting, which was wrong. Lesson learned: never configure around at the grub settings of a mender-convert created image, If its not working automatically, something went wrong . At the input image for mender-convert or at the mender convert process (mostly wrong user defined configurations or the boot process uses the wrong grub files) .

15

Thanks for the update!