[Bug] ext4 install drops to "grub rescue>" on every boot (typing exit boots normally; needs manual grub-install + update-grub)

SkillFishOS version

26.06.2

Hardware

AMD BC-250

Kernel flavor

7.0.11-skillfishos (BC-250 main)

Affected area

ISO / Calamares installer

What happened?

Summary

When SkillFishOS is installed with ext4 via the Calamares installer, the machine drops to a grub rescue> prompt on every boot. Typing exit at the prompt lets the system boot normally, so the OS itself and the on-disk GRUB config are fine — only the installed bootloader stage/entry is broken. The problem is fixed permanently only after manually reinstalling GRUB.

Environment

SkillFishOS version / ISO:
Edition: BC-250 Generic
Filesystem chosen at install: ext4
Install method: Calamares

Steps to reproduce

Boot the live ISO and run the Calamares installer.
Choose ext4 as the root filesystem
Complete the installation and reboot.

Expected behavior

The system boots straight into GRUB and then into SkillFishOS.

Actual behavior

On every boot the machine lands in a grub rescue> prompt.

Workaround (per boot)

Typing:

grub rescue> exit

lets the system continue and boot normally. This has to be repeated on every boot.

Permanent fix

Running the following after boot fixes it for good:

`sudo grub-install <target-disk> # e.g. /dev/sda or the EFI target
sudo update-grub

After this, boots are clean.

Notes / possible cause

Since exit from grub rescue boots the system and the config only needs a grub-install + update-grub to be corrected, the on-disk grub.cfg seems fine — the issue looks like the installer's bootloader step isn't correctly installing/embedding GRUB (wrong prefix, missing ext4 module in the core image, or a wrong EFI boot entry) when ext4 is selected. The default Btrfs path (with grub-btrfs) appears unaffected, so this may be specific to the non-Btrfs code path in the installer's bootloader module.

Steps to reproduce

No response

Logs / output

Thanks for the report and for the precise workaround (exit boots, then grub-install + update-grub fixes it permanently) — that pins it to a GRUB install/prefix problem: the core image ends up with a prefix that doesn't resolve grub.cfg on first boot, so it drops to the rescue shell until the config is regenerated.

The 26.06.2 "Aetherium" respin reworked the installer's bootloader step (removable EFI fallback \EFI\BOOT\BOOTX64.EFI, which the BC-250 firmware tends to boot from, plus a GRUB-safe filesystem layout). That may already cover this ext4 case, but the manual-grub-install symptom is subtly different from the Btrfs one, so I don't want to close it blind.

Could you confirm which media you installed from? If it predates 26.06.2, please retest a clean ext4 install off the current 26.06.2 media and let me know if it still drops to rescue. Leaving this open until confirmed.

boot: fallback EFI autonomo (causa comune di #12 e #20) + indice docs…

boot: la #12 non era il fallback EFI, ma il kernel scritto male su btrfs

Install from 26.06.2

build-iso: applica la correzione di GRUB a ogni produce, e fermati se…

Fixed in 26.06.3. Here is the evidence, since "it works now" is not worth much on its own.

The cause was what you described: with installEFIFallback, Calamares copies shim/grubx64 into the removable EFI path but not the grub.cfg stub that belongs beside them, so GRUB started from that path has no prefix and lands in grub rescue>. Typing exit works because the on-disk config is fine — only the stub is missing.

A clean install from the published 26.06.3 ISO, inspected from the hypervisor with the VM powered off, now has:

/EFI/boot/bootx64.efi   /EFI/boot/grubx64.efi   /EFI/boot/mmx64.efi
/EFI/boot/BOOTX64.CSV   /EFI/boot/grub.cfg      <-- this is the one that was missing

and the stub resolves the real configuration:

search.fs_uuid fea54d7d-… root hd0,gpt2
set prefix=($root)'/@/boot/grub'
configfile $prefix/grub.cfg

The system boots from disk on its own, no rescue prompt.

What I verified and what I did not, precisely. The install I inspected was btrfs, so the prefix above carries the /@ subvolume; on ext4 it is the plain /boot/grub. The step that writes the stub (shellprocess@boot_reconfigure, a second grub-install --removable plus update-grub) runs the same way regardless of filesystem, and Mattia reports ext4 installs cleanly on 26.06.3. So the mechanism is fixed for both, but the end-to-end run I can show you was on btrfs, not ext4.

Closing on that basis. If you hit it again on 26.06.3 or later, reopen and it goes straight back to the top — you found it once already.

Related: your PR #26 is merged in part (f983814) and the rest landed with the iso/ cleanup (70f215d), which is discussed on #27.

boot: standalone EFI fallback (cause of #12 and #20) + PL/UK docs index

boot: #12 wasn't the EFI fallback, but a badly written kernel on btrfs

build-iso: apply the GRUB fix on every produce, and stop if it fails

Navigation Menu

Repository navigation

[Bug] ext4 install drops to "grub rescue>" on every boot (typing `exit` boots normally; needs manual grub-install + update-grub) #20

SkillFishOS version

Hardware

Kernel flavor

Affected area

What happened?

Summary

Environment

Steps to reproduce

Expected behavior

Actual behavior

Workaround (per boot)

Permanent fix

Notes / possible cause

Steps to reproduce

Logs / output

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

[Bug] ext4 install drops to "grub rescue>" on every boot (typing exit boots normally; needs manual grub-install + update-grub) #20

Description

SkillFishOS version

Hardware

Kernel flavor

Affected area

What happened?

Summary

Environment

Steps to reproduce

Expected behavior

Actual behavior

Workaround (per boot)

Permanent fix

Notes / possible cause

Steps to reproduce

Logs / output

Activity

MTSistemi commented on Aug 9, 2026

cyryllo commented on Aug 11, 2026

MTSistemi commented on Aug 15, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

[Bug] ext4 install drops to "grub rescue>" on every boot (typing `exit` boots normally; needs manual grub-install + update-grub) #20