I think I needed to use an internet friend as a rubber ducky to get things working.
I think I needed to use an internet friend as a rubber ducky to get things working.
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.
Here’s the thing… People who care still use Discord. I’m one of them. I have no other option for maintaining communications with a group of 20 people I have been gaming with since 2009. We’ve all hopped from Skype to Teamspeak to Ventrillo to Discord. There’s no going back for many of these people.
Like it or not, Discord offers a product that Signal, Briar, or any other Matrix chat offers and that’s accessibility. I would love for a mainstream E2EE chat program that actually can host a 15 person call, hold multiple chatrooms in one server, allow screen sharing, streaming and multimedia sharing.
We can’t just live in a vacuum and claim nobody uses these programs because they’re stupid or don’t care. For many, like me, Discord a reasonable security risk people are willing to take in order to maintain communications with people they care about.
Ahhh I see. Thank you!
I’m OOTL. What Linux thing are you talking about?
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.
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.