Unable to boot any Garuda 2025 editions after previous successful 2025 installs — boot remnants issue?

Hello everyone,

I wanted to bring up an issue I’ve been experiencing — and possibly others too — related to Garuda 2025 editions.


The situation:

  • I successfully installed and used multiple Garuda 2025 editions in the past (Dragonized, Mokka, Hyperland).
  • After a serious crash (I don’t remember the details, it happened like a half year ago), I started having problems:
    I can no longer boot into any Garuda 2025 editions on my hardware.
  • However:
    • Garuda 2024 editions still boot and work fine.
    • Arch-based systems still install and update normally.
    • Only Garuda 2025 ISOs fail during or after installation.

:test_tube: Things I tried:

  • I did quick format on the original NVMe.
  • I also replaced one SSD entirely with a new Samsung SSD.
  • I even did a clean Windows install on one of the drives — which obviously formats it in the process.
  • But no matter what, 2025 installers either don’t boot properly or hang during install or boot phase.

:brain: My current theory:

Could it be that residual data from the crash or from the old Garuda 2025 installation is still interfering somehow?

For example:

  • Quick format and even Windows formatting don’t fully wipe:
    • EFI partitions (/EFI/Garuda folders, etc.)
    • GPT headers
    • Bootloader stubs
    • Partition UUIDs
  • These leftovers might be:
    • Still referenced in UEFI boot entries (in NVRAM)
    • Causing 2025 editions (which may use stricter boot or partition UUID validation) to hang or misfire
  • Some consumer-grade UEFI firmware may also behave oddly when dealing with broken or orphaned EFI entries

My theory:

  • Even though I formatted and replaced drives, I’m wondering if leftovers from the crash or previous Garuda 2025 installs are still hanging around:
    • Old EFI entries.
    • Broken bootloader stubs.
    • GPT table leftovers.
    • Maybe even NVRAM boot entries stuck in UEFI firmware.
  • Maybe 2025 editions are stricter about detecting boot inconsistencies, and fail when they hit some old leftover data.
  • Or maybe some consumer-grade UEFI firmwares are extra sensitive to this kind of boot confusion.

My questions to others:

:one: Has anyone else run into something like this?
:two: Were you able to install 2025 once, but after a crash never again?
:three: What hardware are you using (laptop, desktop, custom build)?
:four: Did you solve it, and if yes — how? (Full wipe? NVRAM reset? Something else?)


I also saw a few older posts of people having similar issues — able to run 2024 but not 2025 anymore. Makes me think it’s not just me, and might be connected to old entries the new ISOs don’t like.

Appreciate any thoughts or ideas!

P.S. I made this post rather to gather information about HW of people that had same issue, trying to find a possible problem. I already tried all the options proposed here and lots others, but no use. The only solution so far is to run 2024 edition of garuda-dragonized and that’s the one that I’ve been running constantly for 6 months. since that issue ocured.

Feel free to wipe out your boot entries with efibootmgr if you are concerned that they are wrong. It’s true that some poor UEFI implementations can mangle them.
Related docs: efibootmgr(8) — Arch manual pages

Video on how to use it in case it’s too confusing:

Please be most specific about this. Can you please get some logs? dmesg/jctl would be a good start, but anything abnormal is useful.

Please edit in your garuda-inxi even if only from live boot: garuda-inxi | nc termbin.com 9999

2 Likes

Have you tried using Ventoy for the USB and the grub2 boot option when prompted?

2 Likes

I did. I’ve tried using all 3 - Rufus, ventoy and balena etcher with different options, I also tried to write it with dd.

No logs, nothing. It’s just a black screen hanging before the first boot menu (this one >>)

No way to interact, no keys working, it does have some process running, or, at least, it looks like it does, because of heat and excessive work of fans. I’ve tried to leave it hanging like this and stayed for hours.

Pls no prop. driver booting.
Please try again using Ventoy and the grub2 boot option when prompted.

  • latest bios (if possible)
  • bios: fastboot + secure boot off + M$ fastboot off
  • never warm start from M$ → Linux. Reverse yes.
  • Disconnect all usb/bluetooth stuff (if possible)

I made this post rather to gather information about HW of people that had same issue, trying to find a possible problem. I already tried all the options proposed here and lots others, but no use. The only solution so far is to run 2024 edition of garuda-dragonized and that’s the one that I’ve been running constantly for 6 months. since that issue ocured.