this post was submitted on 23 Dec 2024
9 points (84.6% liked)

Linux

48721 readers
1041 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
 

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.

top 5 comments
sorted by: hot top controversial new old
[–] [email protected] 5 points 4 days ago (2 children)

Is the Windows drive listed in your /etc/fstab?

[–] [email protected] 5 points 4 days ago

Nope!

Root, Boot, /EFI, /home

After writing this post I took the nuclear option and disconnected all drives in the PC save for the one hosting Fedora. Then I incrementally connected them all until failure.

It wasn't the Win10 drive but the RAID pair I have as a system backup causing the problem. I guess Fedora was trying to mount those disks causing the hold up. Then that made it look like it was the Win10 disk causing the holdup because it was waiting to initialise.

With the RAID drives disconnected everyone is speaking the same language now.

[–] [email protected] 2 points 4 days ago* (last edited 4 days ago)

I think I needed to use an internet friend as a rubber ducky to get things working.

[–] [email protected] 3 points 4 days ago (1 children)

Systemd checks point to Fedora waiting on the Win10 disk to boot (+45s!!!).

how are you booting windows from systemd?

Obviously, I don’t need that drive to run, but Fedora/Bootloader thinks it should.

systemd is not part of the bootloader.

[–] [email protected] 2 points 4 days 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.