Dual boot would be advisable.

A virtual machine can work, if you have good luck with PCI-E passthrough, otherwise, virtual machines are not for playing any serious games.

Quoting: Groganotherwise, virtual machines are not for playing any serious games.

On the contrary, I consider visual novels very serious business

Aside from visual novels, most games won't work in virtual machines without a dedicated graphics card passed through. You would need to use VFIO. Dual-booting, on the other hand, only requires you to have another storage device on your computer.

Some games, like Rainbow Six Siege, will ban you if you use a virtual machine with VFIO GPU Passthrough, so that's something to keep in mind too.

Quoting: pleasereadthemanual

Quoting: Groganotherwise, virtual machines are not for playing any serious games.

On the contrary, I consider visual novels very serious business

Aside from visual novels, most games won't work in virtual machines without a dedicated graphics card passed through. You would need to use VFIO. Dual-booting, on the other hand, only requires you to have another storage device on your computer.

Some games, like Rainbow Six Siege, will ban you if you use a virtual machine with VFIO GPU Passthrough, so that's something to keep in mind too.

Okay, thank you. I suppose I'll just stick with the dual boot solution I got. Now to figure out how to add the second Windows disk to Grub because it refuses to show up.

Quoting: BobbiWarrenThere is no other option except dual boot?

Options aren't great if you have a title that specifically refuses to support Linux:

1. Stop playing these games. Not exactly a great option, but still an option.
2. Dual boot
3. VM with GPU pass-through. I might be wrong, but I think this option also requires you to use a second, different GPU? And with GPU prices being what they are, that's not great.
4. Use a separate PC/laptop configured with Windows
5. Hope for a change of heart from these devs/publishes and that they'll support EAC/Battleye in Linux. It happens, but note that EAC-creator, Epic, have publicy refused to do so, as have Bungie for Destiny 2. I haven't heard flat out refusal regarding Rainbow 6 though.

Quoting: scaine3. VM with GPU pass-through. I might be wrong, but I think this option also requires you to use a second, different GPU?

Not strictly. If you're passing through a GPU to the VM then that GPU is no longer available to the host. So the host either needs to have its own GPU (integrated graphics are fine for that) or have no GPU (so you're doing stuff entirely from the command line for the time that the VM is running).

Quoting: SmellbringerBut I'm also a Linux noob...
Linux Distro: Nobara

It's not a great idea to use random niche distros when you're new.

Niche distros are going to have issues that you'll have to work out how to fix yourself because they're niche. And you won't know how to fix them yourself because you're new.

Something mainstream that loads of people use - so issues are found quickly, and widely solved quickly - is what you want when you're new.

Do client side anti-cheat systems even allow VM usage?

Quoting: EhvisDo client side anti-cheat systems even allow VM usage?

Pleasereadthemanual, above, notes that while they "work", VMs can sometimes be detected as bad, and apparently Rainbow Six Siege has been know to ban over this. I'm not sure the complexity and risk is worth the pay off, honestly.

Nobara is mostly Fedora smoke and mirrors, I don't think that's especially "niche". It's probably Fedora's grub configuration. These distros may have their own GUI tools, configuration changes, custom packages for some things but the guts are generally like the parent distro. Their repositories are rpm-fusion, fedora and nobara

Back in the good old days, I used to not care what distros people were using. It was easy enough to post distro-agnostic solutions. Nowadays there are too many distros that think they are cleverer than anybody else.

Smellbringer, if you want help with Grub, I need information

sudo dmesg > dmesg.txt

(sudo, because by default the kernel configuration will not allow unprivileged users to access the kernel log buffer and most distros won't change that)

/boot/grub/grub.cfg

Note: I think it might actually be /boot/grub2/grub.cfg in that clever distro.

Get me those two files (the resulting dmesg.txt and grub.cfg) for starters and I'll take a look. If you know which device (e.g. "/dev/sd??" or "/dev/nvme???") is your Windows drive that would help.

What may be happening is that grub-mkconfig (the grub autoconfiguration scripts) or whatever "update-grub" wrapper they use is not even "scanning" that hard drive. I'm assuming it's properly connected to the system and the kernel detects it.

Another alternative would be to simply go into your UEFI (assuming again) BIOS and make that drive the boot drive when you want to boot Windows. This is assuming that the Windows drive is standalone and can boot the system (has its own EFI partition if applicable etc.). For example, the computer originally had Windows on it and you took that drive out?

Last edited by Grogan on 21 August 2023 at 6:53 pm UTC

I got to thinking, maybe we're getting ahead of ourselves.

Have you actually tried updating the grub configuration? I shouldn't assume.

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

The os-prober might actually find it.

Otherwise, they still do provide /etc/grub.d/40_custom for manually adding menu entry stanzas.

Fedora (and Nobara) do things a bit differently, the actual boot entries are separate files in /boot/loader/entries with non human-friendly names. They call this the BootLoaderSpec, or "BLS". (The B should stand for Bollocks, but I digress)

There's not much point in showing grub.cfg because that's not where the boot entries are generated anymore.