Quick and dirty is this:

Running a new dual boot system. Windows boots fine and fast. Grub bootloader grinds and grunts to startup. Systemd checks point to Fedora waiting on the Win10 disk to boot (+45s!!!). Obviously, I don’t need that drive to run, but Fedora/Bootloader thinks it should.

Disconnected the Win10 drive, Fedora booted in 3.6s.

So… Windows bootloader knows to ignore the Fedora OS drive and launches fine. Fedora Bootloader insists it try everything to get that Win10 drive running to my own detriment.

Is there a way to just ignore the Win10 drive the way Win10 ignores Fedora?

Been scratching my head on this one for a bit to be honest.

EDIT: Seems the issue was caused by RAID incompatibility from my internal backups for Win10. The RAID drives wrongly pointed the finger at the boot disk because the only thing I could really make sense of in diagnostics was the Win10 boot stalling for 45+ seconds. Once I disconnected all the drives and incrementally reconnected them I quickly realised it was the backup drives and not a boot disk conflict as I wrongly assumed.

  • Adm_Drummer@lemmy.worldOP
    2·
    12 hours ago

    how are you booting windows from systemd?

    I’m not. I ran some Systemd-analyze, blame etc once Fedora started up and saw that most of my startup lag was caused by a specific drive on boot.

    systemd is not part of the bootloader.

    Yes, and so I used the systemd tools to figure out what was causing my issues on boot.

    As I explained in a reply in this thread it seems my issue is mostly resolved for now. The bootloader was stalling on initializing a pair of drives I have in RAID for system backups on the M$ side.

    This is turn, when running -analyze or other tools showed the drive that contained my Win10 machine stalling out and waiting 45+ seconds to initialise. Because /it/ was actually waiting for the RAID drives to sort it the hell out. So, it looked like there was a conflict between both boot disks when in reality the stall was a symptom of Linux not playing nice with RAID.

    I wrongly assumed it was a boot disk conflict similar to some Windows dual boots where the two disks may be fighting with each other for boot priority and causing a fight until one timed out.