Issue with starting Windows 11 after using ReFIND PikaOS.
Issue with starting Windows 11 after using ReFIND PikaOS.
Hey there! In brief, it looks like I might have skipped a step during the installation of Debian-based PikaOS with its ReFIND bootloader. It seems this action affected my Windows partition on a separate drive, and now I can't start Windows. ReFIND isn’t showing up, and when I select the drive with Windows in the boot menu, I get a blank screen instead of an error. I’m not sure why the EXT4 filesystem shows up on the first partition, especially since my old setup was Debian 12 with GRUB. The plan was to fall back to the motherboard’s boot options if GRUB failed. Now I’m trying PikaOS and hoping for a fix. I’ve attached some info from lsblk and gnome-disk-utility that might help. It feels like a learning moment—hopefully this gives me a clearer path forward!
Your data appears to be intact. To verify, you can mount the NTFS partitions in Linux and try the available NTFS implementation there. The sde1 partition seems unusual—have you mounted it and inspected its contents? This could clarify its purpose and origin. Also, check if your Windows Boot Manager exists at the specified path on the ESP. If found, you may need to adjust rEFInd settings. It looks like you're aiming for an ESP on both drives, which might lead to boot complications with Windows.
It seems you may have altered the Windows EFI partition during installation, resulting in EXT4 being displayed instead of the correct format. You might want to: generate a Windows 10/11 USB installer, select Repair your computer, then Troubleshoot, Advanced options, Command Prompt. In the prompt, run: diskpart list disk select disk # / select the SATA SSD (your Windows drive) list partition select partition 3 / assign partition 3 to C format as NTFS Then: select partition 1 / if EXT4 is detected and not usable, delete it or use partition override create a new EFI partition with size=100 and format fat32 quick assign letter=Z. Exit Command Prompt, then execute bcdboot C:\Windows /s Z: /f UEFI Restart your PC. Try booting from the SATA SSD in your BIOS menu.
@Natural_Artichoke provided a helpful guide on fixing your Windows ESP—better than I could have—but the issue might remain. As noted in my initial message, using two ESPs isn’t allowed. You can find the official Microsoft resources here: https://learn.microsoft.com/en-us/troubl...-disk-uefi
You're correct, this could lead to issues later, particularly after Windows updates. @Gegueure, I'm hoping this is helpful—please let me know how it turns out.
If I found myself in your position, I’d likely try a different method: start with Linux on one disk, then remove it, switch to Windows on the other, and finally reconnect both. This setup ensures each operating system has its own dedicated EFI section, bootloader, and files, keeping them completely isolated. It could be a bit more complicated at first—you need to decide which OS to launch via the BIOS menu (such as pressing F12 during startup)—but you’ll get used to it soon. The biggest benefit is stability over time: no more conflicting bootloaders, fewer unexpected issues after updates, and it’s much simpler to replace or reinstall one OS without disrupting the other. Even with this split arrangement, both systems can still recognize each other if needed; Linux can read NTFS on the Windows drive (provided Windows isn’t in hibernation or using Fast Startup), and vice versa, though third-party tools are usually required for full compatibility since native support isn’t available.
This was the configuration I had before adjusting my Linux installation. I believe this approach helped ensure the Linux setup wouldn’t interfere with my Windows drive. It functioned well until I explored GRUB and added my Windows bootloader as a GRUB entry for remote switching. I used the command: efibootmgr -n 0000 && reboot. This time I was more cautious, anticipating possible issues. I plan to review the linked articles tonight. My current plan is to fix Windows boot using bcdboot as instructed, while disabling the Linux drive in BIOS to prevent conflicts. Thank you!
The article suggests two Microsoft ESPs could be an issue, but it doesn’t mention pairing one with a different bootloader. Based on my experience, this wasn’t a problem before—I was set up without issues for years using GRUB. Now I’ll check how ReFIND affects things. I’m open to possible challenges, just seeing them as growth chances. Thanks for the advice; I’ll look into it tonight.
I recently went through a similar situation, though it was entirely my own mistake (I cleared the Windows ESP because of a typo). The guide you referenced by @Natural_Artichoke appears to be effective for restoring the ESP, as I had a comparable experience. Unlike you, I didn’t use diskpart to remove the ESP; instead, I reformatted the drive from Linux and then moved straight to the bcdboot stage. As discussed before, having a dedicated ESP on each OS-containing drive is considered the best practice. It’s not advisable to modify existing conventions just to bypass design limitations in Windows. I’ve never seen two Windows installations side by side on separate drives, but it makes sense that the bootloader might struggle with this setup. Using GRUB or rEFInd should resolve the issue, as these are standard EFI solutions. From a BIOS/EMI standpoint, having distinct installations with their own boot files shouldn’t cause problems—similar to two separate Linux systems each with its own ESP and GRUB. However, it’s possible that the Windows boot loader expects certain code behaviors that aren’t suited for multiple ESPs. If both drives were connected during the Linux reinstall, this could have triggered the problem. Most installers aren’t built to handle such unconventional arrangements, especially if they default to ext4 or other formats without considering dual OS setups. If you followed manual partitioning and chose ext4, it might still have been a mismatch. Regardless, I hope this helps and please keep me updated!