Arch Linux

Executor252

Member

Registered: 2026-01-25

Posts: 9

[SOLVED] Arch SSD no longer bootable after physical removal/reinstall

Hi guys-- I am having a strange problem with my Arch installation in that it seems to have vanished from an SSD while that drive was removed and sitting on a shelf.

I was happily running a dual-boot system using two physical M2 nvme SSDs-- one with Windows 10, the other with Arch / GRUB. It was working fine for a month or two (plenty of reboots, everything working fine).

Late last year after running Arch for a month or two I decided to boot into Windows to grab the last Windows 10 updates before EOL and to play some Battlefield 6. Out of an abundance of caution (after reading stories of Windows updates breaking bootloaders on dual-boot setups that share a physical drive) I removed the SSD containing Arch from the motherboard before booting Windows. I ran Windows update (I don't think there even were any updates for me IIRC, not that it should matter) and ran off to play BF6 and Arc Raiders on Windows for a few months.

Last night I decided that I would go back to Arch, since Arc Raiders runs fine on Linux and I'm not playing Battlefield anymore, so I:

• Shut down the machine

• Disconnected a/c power

• Reinstalled the second SSD into the #2 M2 slot

• Reconnected power, powered on, entered UEFI setup to adjust boot priority

• Set Secure Boot from "Enabled" to "Other OS"

• Went to set drive #2 to the first boot device, but found it was not listed as a bootable device at all

I also tried a few troubleshooting steps:

• Checked the list of devices in the UEFI: the SSD is listed

• Booted Windows 10, ran disk utility: SSD is listed, shows online, utility shows all the correct partitions present and healthy (the drive is not bricked or wiped)

• Rebooted again, enabled "Compatibility Support Module" for legacy boot devices (the Arch SSD still does not show as bootable)

• Using the "Boot Override" function in the UEFI, attempt to boot from the Arch SSD manually (the lovely "no operating system" screen appears that says something along the lines of "insert bootable media or reboot")

Do I conclude that my bootloader is fucked / gone? How does this happen to a drive that's sitting on a shelf?

System specifications:
Asus TUF Gaming X570-PLUS (WI-FI)
SSD1 (Windows): Samsung 990 Pro 2TB
SSD2 (Arch): Samsung 990 EVO 2TB

The Arch install was up-to-date and working with no issues when it was last booted, but obviously I can't boot Arch to get any details. Configuration wise I was using GRUB and everything was configured per the official install guide-- if the guide doesn't recommend it, I didn't do it.

I searched and found some people talking about re-installing GRUB with a "--removable" flag? https://bbs.archlinux.org/viewtopic.php?id=250619

I also found people dealing with "No bootable media" problems on ubuntu / derivatives that looked like it involved enabling secure boot and configuring it to allow use of GRUB, but I thought the default position for Arch is to just not use secure boot, no? And with it set to "Other OS" there should be no problems?

Thought I would see if anyone thinks I missed something basic before messing around with these fairly complicated-sounding fixes or god forbid just starting over with a new install.

EDIT: Solved

Per the suggestions, I did the following and it worked:

• Boot Mint live media (I wanted to see if I could do it graphically, because I'm lazy)

• Manually mount the efi partition

• Copy /efi/grub/grubx64.efi

• Create directory /efi/boot

• Copy grubx64.efi to /efi/boot

• Rename grubx64.efi → bootx64.efi

The --removable flag in grub should not be used to fix a missing boot entry.

The most correct solution sounds like:

you just have to get a new entry in your uefi to point to it by using tools like efibootmgr or efishell - or anything other that either the uefi can boot itself or can access the uefi nvram boot entries

Recommendation: don't remove your SSD unnecessarily

Last edited by Executor252 (2026-01-25 15:37:38)

frostschutz

Member

Registered: 2013-11-15

Posts: 1,595

Re: [SOLVED] Arch SSD no longer bootable after physical removal/reinstall

it was not listed as a bootable device at all

Quite normal.

That only works if that drive has its own EFI partition and you used grub-install --removable (in addition to regular grub-install).

So it has efi/boot/bootx64.efi (which is what uefi bios runs on removable devices).

If you only have, e.g. efi/grub/... or efi/arch/... or whatever, then it won't run that until you reinstate that boot entry.

You can try to just copy / rename your file to efi/boot/bootx64.efi, or boot a live / rescue, chroot and reinstall your bootloader from there.

Likewise legacy boot only works if you also installed a legacy bootloader (hybrid mode or whatever). Basically with Grub you'd have to install it three times then, uefi regular, uefi removable, and legacy. Otherwise it won't work (when removing devices or changing boot modes or whatever).

And for legacy some bios expect bootable flag, others reject it... you can't have both at the same time, so there is no one for all solution anymore.

Last edited by frostschutz (2026-01-25 10:47:44)

Executor252

Member

Registered: 2026-01-25

Posts: 9

Re: [SOLVED] Arch SSD no longer bootable after physical removal/reinstall

it was not listed as a bootable device at all

Quite normal.

That only works if that drive has its own EFI partition and you used grub-install --removable (in addition to regular grub-install).

So it has efi/boot/bootx64.efi (which is what uefi bios runs on removable devices).

If you only have, e.g. efi/grub/... or efi/arch/... or whatever, then it won't run that until you reinstate that boot entry.

Thank you for replying! I do have questions, though

Can you explain in five-year-old terms what's happened here, and why I was able to reboot / power off before without issues? I would understand if I were trying to move a drive to a different PC or something how there might be issues, but how can there be confusion with the same board / same drive / same M2 slot even? I just don't understand what has changed since the motherboard UEFI hasn't been reset or anything (all my BIOS settings persisted through the A/C power cut, so the battery on the board is fine, and even the wiki articles about GRUB here suggest that the boot entries are stored in NVRAM, with the "NV" standing for non-volatile, right? I just don't get it

I guess we can add Asus boards to the list of boards that require that "--removable" flag to be set when installing GRUB? (The wiki said it's a common problem with MSI boards)

You can try to just copy / rename your file to efi/boot/bootx64.efi, or boot a live / rescue, chroot and reinstall your bootloader from there.

Likewise legacy boot only works if you also installed a legacy bootloader (hybrid mode or whatever). Basically with Grub you'd have to install it three times then, uefi regular, uefi removable, and legacy. Otherwise it won't work (when removing devices or changing boot modes or whatever).

And for legacy some bios expect bootable flag, others reject it... you can't have both at the same time, so there is no one for all solution anymore.

Ok, this is good to know. I really just followed the wiki for the initial installation, so I don't think I did any kind of hybrid mode or anything extra: just the suggested 3 partitions on the drive (boot (1GB), swap (4GB), root) and GRUB for UEFI.

So I should boot live media and try to duplicate the .efi file to another location? (Can't do it from Windows, since it can't read or write to those partitions due to filesystem) Could I do it from any Linux live environment that can read the filesystem (EG could I boot Mint from USB and do this graphically?) Or is it best to reinstall GRUB? (And if I do that, will it automatically see the Arch install and create a bootable entry for it?

Thanks in advance

Scimmia

Fellow

Registered: 2012-09-01

Posts: 13,513

Re: [SOLVED] Arch SSD no longer bootable after physical removal/reinstall

the motherboard UEFI hasn't been reset or anything (all my BIOS settings persisted through the A/C power cut, so the battery on the board is fine, and even the wiki articles about GRUB here suggest that the boot entries are stored in NVRAM, with the "NV" standing for non-volatile, right? I just don't get it

Because many, even most, UEFI implementations will remove entries that don't exist.

Executor252

Member

Registered: 2026-01-25

Posts: 9

Re: [SOLVED] Arch SSD no longer bootable after physical removal/reinstall

the motherboard UEFI hasn't been reset or anything (all my BIOS settings persisted through the A/C power cut, so the battery on the board is fine, and even the wiki articles about GRUB here suggest that the boot entries are stored in NVRAM, with the "NV" standing for non-volatile, right? I just don't get it

Because many, even most, UEFI implementations will remove entries that don't exist.

Oh. I guess that makes sense, sort of

You guys are lifesavers-- I did the following and it worked:

• Boot Mint live media (I wanted to see if I could do it graphically, because I'm lazy)

• Manually amount the efi partition

• Copy /efi/grub/grubx64.efi

• Create directory /efi/boot

• Copy grubx64.efi to /efi/boot

• Rename grubx64.efi → bootx64.efi

Rebooted, Arch SSD shows up, put to boot #1 and it boots right into grub. Had a weird issue where the first time I went to log in my plasma session didn't seem to start (black screen), but rebooted one more time and it just works now. Thank you, guys!

It might be worth editing the Arch install guide to reflect that installing grub with that --removable flag should be the default procedure (right now it basically says, "do this if you have an MSI motherboard").

Is there any reason what I have done would cause problems in the future? Should I just leave it be now that it's working?

Last edited by Executor252 (2026-01-25 13:35:08)

frostschutz

Member

Registered: 2013-11-15

Posts: 1,595

Re: [SOLVED] Arch SSD no longer bootable after physical removal/reinstall

before uefi, bootable or not depended on the disk contents alone

with uefi, the bios has its own brain / memory / storage that makes its own decisions. you remove a drive, it decides for you to remove your boot entries as well, and those entries don't come back until you reinstall your bootloader (or use some other means to reconfigure boot behavior)

there is (usually) no file browser or selection screen in the bios screen itself, with the exception of the "removable" boot entry meant for usb sticks and the like.

installing grub with that --removable flag should be the default procedure

that's the problem with removable, there can be only one (for each efi partition), so it does not work, for multi boot and the like (removable already used by mickeysoft or other linux distro)

Is there any reason what I have done would cause problems in the future?

some other bootloader (or windows itself if you still use it) could decide to replace the removable entry with their own bootloader

just reinstall grub, have to do that anyway when grub gets updated, provided you want to boot using the new version ...

cryptearth

Member

Registered: 2024-02-03

Posts: 1,923

Re: [SOLVED] Arch SSD no longer bootable after physical removal/reinstall

@OP
to go the "5-year-old" route:

during POST most uefi implementations check if the existing boot entries are stil valid

so - what you did: you removed a fixed drive from the system
what happened: the next time the uefi checked "is the arch entry still valid?" and got a "nope, it isn't" -> so it was thrown out of the list and the uefi forgot about that specific drive

what you then did (I cut out all the nonesense): re-add the drive to the system
what happened: the system got a new unknown drive it know nothin about - and as its a fixed disk following the spec just doesn't do anything with it

why you were no longer able to boot? because the uefi is missing the required boot entry pointing to the bootloader on the arch drive

how to resolve this issue: write a new entry - for this there'Re a couple of options - but what NOT to do: use the "--removable" flag!
the flag itself is named accordingly: it is meant for removable media only - not for fixed drives!
in fact: the uefi spec explicit state that one should not rely upon installing a removable bootloader on a fixed drive - but it states it explicit as "removable" - it is NOT(!) a fallback! a system to spec not booting a fixed media via the removable path is correctly working according to the uefi spec - it's not meant to

reality: I don't know where it came from - but unfortunately many in fact do see the removable path as "fallback" - even for fixed disks - so, yes, commonly most modern uefi are able to boot from and actively scan for the removable path even on fixed disks - but: one should not rely on that behaviour - it's not in the spec but common practice on consumer grade hardware only

so - do you have to reinstall grub? likely no because it not got removed - you just have to get a new entry in your uefi to point to it by using tools like efibootmgr or efishell - or anything other that either the uefi can boot itself or can access the uefi nvram boot entries

to answer the question: you did not "reinstalled" the same drive - the moment you booted the system after removing the nvme the system forgot about it - hence when you put it back in for the uefi it was just learning about a new unknown drive like about any other

Scimmia

Fellow

Registered: 2012-09-01

Posts: 13,513

Re: [SOLVED] Arch SSD no longer bootable after physical removal/reinstall

It might be worth editing the Arch install guide to reflect that installing grub with that --removable flag should be the default procedure (right now it basically says, "do this if you have an MSI motherboard").

No, because removing the drive to boot to Windows isn't normal, and that's what caused the issue.

Executor252

Member

Registered: 2026-01-25

Posts: 9

Re: [SOLVED] Arch SSD no longer bootable after physical removal/reinstall

Thank you for the replies, guys! If this happens again maybe I will try the efibootmgr tool, but for now manually copying / renaming the .efi file seems to have worked. Now it's on to solving whole new problems

I will edit the original post / mark solved if there's enough characters left in the title field.