EFI bootloader identifier inconsistency between installer and package

esaner · 2026-08-04 15:38

Hello,

Following the recommendation of the Q4OS Team in ticket #254, I am posting the technical report here for discussion.

During the investigation of a real Secure Boot boot failure after a Microsoft Secure Boot dbx update, I observed an EFI bootloader maintenance behaviour that I could not fully explain.

The purpose of this post is not to report a confirmed bug, but to better understand whether the observed installer and package maintenance behaviour is intentional.

Any comments or clarification would be greatly appreciated.

---

# Report for Q4OS Developers

# Subject

Potential EFI bootloader identifier inconsistency between installer and package maintenance.

---

# Environment

**Distribution**

Q4OS 6 Andromeda (Debian 13 based)

**Architecture**

x86_64 UEFI

**Systems investigated**

- Two independent physical systems

**Secure Boot**

- Microsoft Secure Boot dbx update involved in the affected system

---

# Observed Behaviour

The investigation started after one system became unbootable following a Microsoft Secure Boot dbx update.

Analysis showed that the original Q4OS installation created the EFI bootloader under `EFI/Q4OS_Andromeda`, while subsequent package maintenance updated `EFI/q4os`.

Firmware on the affected system continued booting `EFI/Q4OS_Andromeda`. As a consequence, newly installed shim binaries located in `EFI/q4os` were never used.

A second independent Q4OS installation showed the same installer behaviour but had already migrated to `EFI/q4os`, preventing the failure.

---

# Evidence

## Evidence 1 — Installer Behaviour

The Q4OS installer invokes

`grub-install --bootloader-id=Q4OS_Andromeda`

This behaviour is documented in an installer log published on the official Q4OS forum.

---

## Evidence 2 — Package Maintenance

Current Debian shim maintenance derives the EFI bootloader identifier from

`GRUB_DISTRIBUTOR`

which becomes

`q4os`

on the investigated systems.

---

## Evidence 3 — Verified Installation Target

A verbose execution of

`grub-install --bootloader-id=q4os`

confirmed that the following files are installed into

`EFI/q4os`

- shimx64.efi
- grubx64.efi
- mmx64.efi
- fbx64.efi
- BOOTX64.CSV
- grub.cfg

---

## Evidence 4 — Real-world Confirmation

On the affected system, firmware continued booting

`EFI/Q4OS_Andromeda`

while package maintenance updated

`EFI/q4os`.

Replacing the obsolete shim located in `EFI/Q4OS_Andromeda` with the current signed shim immediately restored normal boot behaviour.

---

# Analysis

The collected observations appear to be consistently explained by differing EFI bootloader identifiers used during installation and subsequent package maintenance.

As a consequence, firmware may continue booting an EFI directory that is no longer maintained.

When Microsoft Secure Boot dbx updates invalidate an older shim, this situation may result in a boot failure.

This explanation is consistent with all observations collected during the investigation.

---

# Open Questions

- Is the installer intentionally using `Q4OS_Andromeda` as the EFI bootloader identifier?

- Is subsequent package maintenance intentionally expected to update `EFI/q4os` instead?

- Should package maintenance also update the installer-created EFI directory?

- Is there already a migration mechanism intended to update existing firmware boot entries?

---

# Purpose of this Report

The purpose of this report is not to assign responsibility.

It is intended to document a reproducible technical case supported by independently collected evidence from two physical systems.

If this information is useful, we would be happy to provide additional evidence, logs, hashes, timeline data, and the complete investigation repository.

---

If additional evidence is useful, the complete investigation repository is available on GitHub under the project name:

https://github.com/esaner-code/EFI-investigation

Thank you for your time.

Last edited by esaner (2026-08-04 15:47)

q4osteam · 2026-08-04 15:43

Welcome to the forum

Your account has been promoted, so you can now post links and attachments. You can also edit the OP to update links.We will investigate the issue and post back. It seems to be a real Q4OS bug by a preliminary evaluation. Thanks for the report.

q4osteam · 2026-08-04 16:18

Well, we can confirm Q4OS bug. The "grub-install" command creates new "q4os" EFI entry, although it shouldn't. Investigation continues, we will post back.

bin · 2026-08-05 06:50

I do not know if this is of any use at all.
Screenshot from Thinkpad E530
Secure Boot OFF.
The q4os entry was created on March 16 and then used for the shim update July 11th
March 16th saw a grub and kernel update.
Machine boots normally.

Last edited by bin (2026-08-05 06:50)

q4osteam · 2026-08-05 07:39

Thanks for that input. The issue is that the Calamares installer creates the boot entry in `/boot/efi/EFI/Q4OS_Andromeda/`, while updates install the new bootloader files to `/boot/efi/EFI/q4os/`.

As a result, once Secure Boot is enabled and the old Microsoft signing certificate is revoked, the default boot entry (`/boot/efi/EFI/Q4OS_Andromeda/`) no longer receives updated `shimx64` files and therefore fails to boot. However, you can still boot successfully using the `/boot/efi/EFI/q4os/` boot entry, which contains the updated Microsoft-signed `shimx64`.

In any case, we'll focus on providing a proper fix and will post an update here.
.

q4osteam · 2026-08-06 15:02

Thanks for the detailed report and for tracking down the exact symptom -
this helped a lot in pinning down the root cause precisely.

What's happening: our installer (Calamares) creates the real EFI boot
entry as /boot/efi/EFI/Q4OS_Andromeda/, but a separate configuration
setting was causing later, automatic bootloader refreshes (the ones that
happen when a Secure Boot shim/grub security update comes through apt) to
target a different, generic /boot/efi/EFI/q4os/ directory instead. Since
firmware keeps booting from Q4OS_Andromeda/, that directory's shim never
gets updated, and it eventually fails Microsoft's certificate revocation
check while EFI/q4os/ silently ends up with a fresh, working shim that
nothing ever boots from. This is now fixed at the source for future
installs/rebuilt media.

For systems already affected, here's how to fix it without reinstalling:

1. Open a terminal and check both directories exist:

ls -l /boot/efi/EFI/

You should see both Q4OS_Andromeda/ and q4os/ (the second one is the
stray one).

2. Re-run grub-install targeting the real one explicitly, so it picks up
the currently signed shim/grub binaries:

sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Q4OS_Andromeda --force

3. Fix /etc/default/grub so this doesn't happen again on the next
security update - open it with your preferred editor (e.g.
sudo nano /etc/default/grub) and make sure the GRUB_DISTRIBUTOR line
reads exactly:

GRUB_DISTRIBUTOR='Q4OS_Andromeda'

(i.e. no extra words/spaces after it - that's what was pointing future
updates at EFI/q4os/ instead of the real directory)

4. Regenerate the boot config:

sudo update-grub

5. Reboot and confirm it comes up normally before doing anything else.

Once you've confirmed step 5 works, the stray /boot/efi/EFI/q4os/
directory is no longer used for anything and can be left alone or removed
- it's harmless either way, so there's no rush.

If you'd rather not do this by hand, a fresh install from updated media
(once the next Andromeda point release/rebuilt ISO is out) will have this
fixed from the start.

Thanks again for the report - this was a real bug and a good catch.

esaner · 2026-08-06 15:16

Thank you very much for the quick investigation and for the detailed explanation.
I'm very happy to hear that the root cause has been identified and that a fix has already been implemented for future installations.
I also appreciate the migration instructions for existing systems.
I'm glad the report was useful.

Q4OS Forum

#1 2026-08-04 15:38

EFI bootloader identifier inconsistency between installer and package

#2 2026-08-04 15:43

Re: EFI bootloader identifier inconsistency between installer and package

#3 2026-08-04 16:18

Re: EFI bootloader identifier inconsistency between installer and package

#4 2026-08-05 06:50

Re: EFI bootloader identifier inconsistency between installer and package

#5 2026-08-05 07:39

Re: EFI bootloader identifier inconsistency between installer and package

#6 2026-08-06 15:02

Re: EFI bootloader identifier inconsistency between installer and package

#7 2026-08-06 15:16

Re: EFI bootloader identifier inconsistency between installer and package

Board footer