Also, regarding hating GRUB: take a look at rEFInd. The themes are way better [0] and it can autodetect operating systems so not only is it harder to break your system with a bad config, it'll detect USB boot devices as well so you don't have to mash F11 or whatever if you need to boot from one. It also has mouse support and (in theory) also touchscreen.
As for drivers, the idea is that you're passing through as much of the devices as possible so it works on that level. For those you cannot passthrough, Windows 10 was surprisingly accomodating.
This is the guide I used for making the SSD look like an internal hard drive https://ckirbach.wordpress.com/2017/07/25/how-to-add-a-physi...
Once the first part of the installation was completed, I turned off the VM and booted the SSD from real hardware (after disabling the internal disk in the laptop's firmware to avoid anything unfortunate happening).
Apart from being a little slower, everything works fine. I haven't yet been offered the windows 11 upgrade so I can't say if that will continue working.
Is there a way to fool Windows into thinking it's a normal SATA hard-drive attached to the motherboard and not a USB one?
After the first part of the installation is done (the copying files from the ISO image/DVD/USB stick part), Windows 10 won't run a check that prevents C:\ being a USB drive.
So I don't think there's any reason to fool it after that point.
And before that point of the installation the virtual machine is there to fool it. When the drive is attached to the VM as per the linked instructions (in my comment above) Windows will see it as an internal drive.
---
I have also tried Windows 11 using these same steps, but got a message saying that my (virtual) hardware didn't meet the requirements. I suspect it was the TPM module that was incorrect in the VM. Probably as more people try to run Windows 11, virt manager's support will improve (including the downstream distributions' copies).
I used to get random blue screens of death from this however, so stopped using it. Also: WTG is no longer supported by Microsoft, so we can't use it anymore.
I like your hack of attaching an SSD to a VM. How do you do that though? Is there some procedure for doing that? I'd love to know!
https://superuser.com/questions/495025/use-physical-harddisk...
However, making it possible to boot windows without the VM required some hacks and I neither know if they work for modern windows too nor what they were exactly.
https://github.com/DualCoder/vgpu_unlock
Looks like it can enable a virtual GPU so you don't need to actually use 2 GPUs, but I haven't tried it, it looks pretty cool if you only want to run only 1 to switch.
Another interesting cross-OS trick is folks who use a shared NTFS drive to maintain a common Steam library between Windows and Linux. I did this for a while before I switched completely to Linux, but it's still fairly common.
[0]: https://askubuntu.com/a/47122/11736
[1]: https://www.sysprobs.com/access-physical-disk-virtualbox-des...
If you're sharing a library between Windows and Linux, NTFS should be your way forward, especially given the improved native R/W NTFS (NTFS3) driver that is present in newer Linux kernels (5.15+). exFAT is a marked improvement over FAT32 (no realworld filesize limit) but NTFS will probably be the least painful choice longer term (given the journaling capability).
Either way, NTFS isn’t supported by Proton and I’m still on 5.14; 5.15 was only released on Halloween 3 weeks ago and isn’t in most distributions/repositories yet or nearly as battle-tested. However I am excited to get my hands on the better NTFS support.
Moreover—the, erm, advantage of a system where you can tune the boot process in a hundred different ways is that you can do quite weird stuff. Like, have the boot ramdisk mount a network drive and then use that as the root filesystem.
The initramfs is the first root filesystem a Linux system has but it resides entirely in RAM. It's initialized using an archive stored on disk, but after that point can be modified freely without touching disk at all. Very much like /tmp in distros that store /tmp in memory.
initramfs is mostly for loading stuff required for booting the system. Usually these are storage related - maybe your root filesystem lives on a disk that's encrypted, backed by RAID, etc. and it requires a password or some modules that aren't baked into the main kernel image. If you include these modules/config/etc. in your initramfs and the initramfs's init (it has a distinct init from your main system, usually a shell script) knows about them then they can be used to bootstrap your root filesystem.
Of course, it requires that the initramfs be stored on a filesystem whose code is baked into the kernel. ex2 is/was a popular choice, as well as the UEFI system partition (basically FAT). Both simpler filesystems that don't bloat the kernel too much.
Once you've mounted a filesystem of some kind in the initramfs, you call pivot_root and the root filesystem switches from being the initramfs to being whatever filesystem the initramfs mounted. Then you can exec that filesystem's init and get the full system up.
Or you could just stop in the initramfs. Usually they just contain busybox and some other system binaries so they're not practically useful, but at one point I experimented with including a Lisp there. It never ran on real hardware but I was able to boot to an SBCL REPL via QEMU, which was pretty cool. The next step was Emacs but that didn't work out for reasons I don't remember clearly.
you can do this, but i've always found figuring out what drive to mount to be a challenge in the grub interface. at one point in time it was the best option.
these days, it's generally easier (imho) to just boot intot he livecd/usb environment, mount the volume you want to repair, and chroot into it
Had the same experience, it worked surprisingly good and was easily good enough for daily use.
Unmounted or hidden, an additional separate specialized FAT32 boot partition has been common for Windows since long before UEFI & GPT partitioning became mainstream.
Usually the first active primary partition on a Windows 7 BIOS PC, a few hundred megabytes of FAT32 were there specifically to hold the BOOTMGR file and its associated BOOT folder, (where you could build a Windows bootmenu) which would point from there to any of your main NTFS partitions that had a version of Windows installed.
That regular Windows bootmenu (in BIOS) could also be used to point to the GRUB-based bootsector from a type 83 EXTx Linux partition on the same HDD. This would boot the Linux like normal. Even though Windows would not mount nor access the Linux partition. But Linux could mount and access the Windows partition.
Alternatively, on a fresh BIOS partitioning layout, the FAT32 Boot partition can be upsized to a few GB (instead of mere MB) and then a copy of an entire live Linux fileset from the bootable Linux DVD can be placed there right next to the Windows BOOT folder. The contained live Linux squash filesystem is then booted into memory from the FAT32 volume using the Windows bootmenu, with GRUB, or even Syslinux which can boot the Isolinux-launchable DVD fileset when the fileset is stored on a FAT32 volume.
An advantage of this arrangement is so (live) Linux is avaiable bare metal when needed on an otherwise unchanged Windows PC, without having any EXTx partitions. As more distros gained access to NTFS it became possible to place the Linux live folderset right there on the NTFS volume alongside Windows, so there was another option.
In BIOS mode Windows 10 (and even Windows 11 in BIOS for extra credit) works just like Windows 7 for this.
For UEFI a FAT32 ESP is almost always in use but Windows bootloader will not boot Linux in UEFI. But the /EFI/BOOT folder in the UEFI ESP is not dedicated to Windows like the BOOT folder was under BIOS. /EFI/BOOT contains the key BOOTX64.EFI file which is basically a renamed OS-specific bootfile placed there by the most recent OS that was installed or had its bootfiles updated in common ways.
BOOTX64.EFI then points hardcodedly to one of the associated /EFI/Microsoft or /EFI/ubuntu, etc folders there on the boot partition which will contain a Windows or Linux bootmenu accordingly.
The /EFI/Microsoft folder contains the regular Windows bootmenu which accesses any of the Windows OS's that are installed on any of the NTFS[0] partitions that are unhidden at the time.
The /EFI/ubuntu folder contains the GRUB bootmenu which accesses any of the Linux OS's that are installed on any of the EXTx[0] partitions. Additionally the GRUB bootmenu can be configured to have a Windows bootentry which then chains to the regular Windows bootmenu in /EFI/Microsoft/Boot/BCD. Also in GRUB a bootentry can be added to launch a live Linux fileset stored on a sizable enough ESP FAT32 boot volume similarly to how it's done in BIOS.
Interestingly, on a Windows XP PC to begin with you could install to a different folder than the default WINDOWS (such as WINNT or WINXP). Afterward if you protectively renamed Documents and Settings & Program Files from the command line of the NT6 install DVD, you could then install NT6 into its own default WINDOWS folder alongside XP on the same partition without conflicts. The real Documents and Settings can then be unveiled and an NTLDR entry added to the NT6 bootmenu. BOOT.INI can then handle the NT5 & DOS booting as before and NT5 when booted can share the Program Files folder with NT6 as long as you are careful, since NT5 does not need to run anything in the Program Files folder when you boot. Often you can install an NT5 program into the same Program Files folder shared with NT6 this way and there is no conflict whatsoever.
[0] a wider variety of filesystems are becoming supported as years go by.
(Though I'm not so sure now that I remember it right, since VMs tend to use low-level approaches like kernel extensions, and Rosetta is probably not friendly toward those.)
Maybe I'll use my free time this weekend to try and compile that.
I'm occasionally using this to install Linux on an external drive.
I had an old Mac that for some reason couldn’t boot the Windows DVD, but installing it onto a VM that used the real HDD worked fine.
Though I don't remember how or whether it is legal.
if I recall (big "if"), all editions of Windows from Pro upwards include a license to run exactly one instance of the same edition of Windows inside a VM at a time. It does not need to be hosted by Hyper-V or be hosted on the associated licensed Windows installation.
Windows 10 Enterprise, I think, includes 10 VM licenses per purchased license, but those 10 are all meant for the same user, which is the user who is using the physically installed license and are not to be spread around and used by different users.
Windows licensing is kinda weird
VirtualBox supports fake disk images that are just pointers to a real block device, which could be an entire drive or partition.
I took advantage of that to have a dual-boot Linux & Windows 7 install (with the main bootloader still being Windows’ as I hate GRUB) and then created a VM pointing to the Linux partition.
The system was configured to be able to deal with both the real hardware and the VM emulated HW. As far as I know most stuff worked out of the box, the only change I had to make was have two network configuration entries - one for physical hardware and one for the VM.
This worked really well actually and performance was good.