In the Windows 9x days this was quite common and there were linux distributions that were installed by unzipping few hundred MB zipfile into C:\linux\. It only worked with FAT filesystem and the required umsdos FS module was removed from kernet 2.6.11 (and was marked obsolete for a long time before that).
Having root filesystem on NTFS in any semi-sane way involves having kernel space NTFS FS implementation. Such a driver was introduced in 5.15 released on the 1st of this month.
Indeed; it has a feature dubbed namespaces. You can create files and directories in the POSIX namespace, store POSIX ACLs, etc. and this will give you “bag of bytes” filenames alongside Windows filenames. I believe this was used for SfU and WSL1.
Reminds me of the times when you could install Ubuntu via an .exe file using WUBI. This is how I started with Linux on my grandparents' computer without breaking it when I was 11.
Wow, you just threw me back to my childhood! WUBI was so cool. I haven't had the need for something similar in some time and Ventoy is my go-to tool for such things now.
From first hand experience, while it worked, several times the boot manager got nuked, and either I lost Ubuntu access, or had to repair windows to get back into the system at all.
That said this was back during win7, the cobbled together solution may be more stable..
Windows 10’s “updates” are actually full OS reinstalls in the background which includes the bootloader so it’ll nuke GRUB or whatever else you have.
The really nasty part is that even having separate drives won’t save you - I don’t know if Windows can install the bootloader to a different drive than the one holding the OS partition or if it’s some other bug but I absolutely remember a Windows install nuking the bootloader on other drives that were connected during the OS install.
It wasn’t a big deal pre-Windows 10 as you only install an OS once and disconnecting the drives is trivial, but nowadays with every update being an OS reinstall it’s a major problem if this issue still persists.
Windows will install its bootloader onto the fallback UEFI bootloader; the bootloader that should get loaded when no other option is configured in the UEFI itself. No other bootloaders should be touching that thing for a consistent boot experience.
Every normal OS registers a boot option with the UEFI and puts its bootloader into a normal directory. It also pushes its own bootloader as the default in some cases, but that's just a single boot order change away after booting into the UEFI setup (or after messing with confusing and dangerous tools from inside Windows, which I wouldn't recommend).
The dual boot problem is only really insurmountable in BIOS+MBR mode (which should be considered long deprecated) and with buggy motherboards. Some people will set their system to BIOS+MBR mode for some weird reason, but with Windows 11 this mode should finally be dead already. UEFI has been an option since at least Windows 7 but it was disabled by default for a long time, so if you've upgraded to Windows 10 from a previous version, you'll most likely still be running this old and unstable config. I think this is one of the reasons new Linux users have so much trouble dual booting.
Modern motherboards detect different UEFI bootloaders installed on EFI partitions even if you swap around SSDs. Dual booting has come a very long way!
> I think this is one of the reasons new Linux users have so much trouble dual booting.
There's another problem. Motherboards with non-compliant UEFI specs. Exact details here may be flawed, but one of the most insidious dual boot issues I had, which prevented grub from loading was that it turned out, if you had a folder or file labeled windows or Microsoft in the EFI partition, it would always preferentially boot that one no matter what order you set to actually prefer. To fix it, I had to run the Linux EFI utilities for OS detection to set everything up, then go in and manually change everything with windows to some other name. This included modifying whatever the grub configuration file is that says to never modify manually. The biggest issue I had is that it took a LONG time to figure out that noncompliant UEFI specs on the motherboard was the problem. It was maddening.
I have had windows and Linux on separate hard drives for the past 7+ years with no problems with upgrades. If they are on the same hard drive all bets are off though.
Puppy Linux has this feature and it’s pretty cool. Upon logging out you get a prompt asking if you want to save your session to a virtual disk file, and you can save it to any writable media (including the USB drive you’re booting Puppy from).
I donated the bootloader code/magic for Wubi, but I was never clear on why it was discontinued. I guess some internal numbers on usage didn’t encourage pursuing that path?
It wasn't intentionally discontinued, just the maintainer didn't update it in time and so Ubuntu 15.04 ISO media shipped a wubi.exe that only worked to install 14.10:
Without mentioning any names, yes, I had a hard time getting in touch with one of the maintainers back then. Burn out is real.
Wubi also had a dependency on grub4dos which had an idiosyncratic development and release style, to say the least. It was also the only component developed by non-English speakers, which made communication very hard. Later releases had some major regressions that were never sorted out, and I think everyone involved found it highly draining to deal with these issues without a more fundamentally correct way of tracking and preventing regressions.
"Known issues" is interesting; kernel panics and ldconfig breaking are probably bugs worth chasing down, but "it just breaks after a few boots" is straight up weird.
In terms of similar “interesting” things one I successfully did in the past that I wanted to share was to have a single Linux environment that you could either boot into or run in a VM.
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.
reddit r/vfio and the arch wiki page here https://wiki.archlinux.org/title/PCI_passthrough_via_OVMF there's also the level1tech forums which have a ton of information on it. The gist of it is this: Qemu with uefi boot, configured through virt-manager, passing in both the gpu and windows boot disk (nvme) as raw devices to the vm.
Mine would be booting into a minimal Linux installation/hypervisor that fires up a Linux and a Windows VM, both full-screen, between which you could swap with a pair of keyboard shortcuts.
I did the same and fixed the license issues by pirating windows.
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.
it's legal, but whether or not it violates the license agreement is what you mean, I think.
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.
I used to have a setup similar to this, where I had a Windows 10 install and a Linux install on different partitions, both being able to boot into the other through I think VMWare?
Had the same experience, it worked surprisingly good and was easily good enough for daily use.
Naturally that's also the regular way you can also boot into either partition bare metal when you want.
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.
I used to do this, but afaik virtual box explicitly disabled this because you risk some problem with data corruption on the partition running on the vm.
I recently did this with the free VMware Player, and it worked alright. Mostly just for "can I do this?", so I don't know how viable or stable it would be for actual use.
If you have the ability to mount the filesystem from the VM and the host, then you would almost certainly break the filesystem, although I can't immediately think how to do that with NT host and a Linux VM unless you added a third-party driver for the Linux filesystem.
IIRC Linux has a capability to specify the root partition at some time during loading. (Probably via the bootloader params—this is where Grub comes in use.) This is helpful for booting from a ‘recovery’ floppy/cd/usb drive and into the system on the HD. But can also be used with VMs.
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.
> IIRC Linux has a capability to specify the root partition at some time during loading. (Probably via the bootloader params—this is where Grub comes in use.) This is helpful for booting from a ‘recovery’ floppy/cd/usb drive and into the system on the HD. But can also be used with VMs.
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
In case anyone wants more detail on the internals:
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.
In my system (Gentoo Linux), I boot via efistub and a built-in kernel command line that points to my root partition, so you don't even need Grub technically though I think it works basically the same way. Literally just 'root=PARTUUID=$whatever' compiled into the kernel, and you can set it as any valid rootfs target as far as I know. I don't even use an initramfs or initrd. I just boot right into my root partition in a couple of seconds.
Wrong OS, but VMware Fusion could do that with a boot camp volume. Worked magnificently. One of the few things I'm disappointed about losing with the transition to arm64.
Rumor is, VMs work in Rosetta. Apparently people run Windows games that way—and are saying that performance is at least not worse than in plain Windows on x64.
(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.)
I know that WoA works in Parallels Desktop, though I haven't tried it. That would at least give you access to x86-64 emulation in Windows. I am curious about playing around with Crossover which apparently implements WINE using Rosetta.
Maybe I'll use my free time this weekend to try and compile that.
10 years ago or so, I wanted to have a windows on a portable USB HDD. Windows 7 didn't want to be installed on USB-drives, but once it was installed you could modify it (edit a text file or so), to make it work. So I used a VM with the usb-drive as the HDD. That way Windows didn't knew it was being installed onto a usb-drive and everything worked fine.
I've done the same to install Windows 10 to an external SSD (I don't want to divide my laptop's internal drive up between two different operating systems).
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 Windows To Go[0] and you could put Windows 8 on an SSD or even a USB flash drive.
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!
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.
I did this as well, and consider it to be my "weirdest" linux install as well. I documented it on AskUbuntu[0] and followed these instructions[1] - they involve creating a fake disk image using the VBoxManage cli. The reason I had to do this was also because of the "no-external-media-to-install-Linux" challenge. WUBI[2] used to be a solution for this, but it had it's own challenges (and was only Ubuntu iirc) and was discontinued (much after I used this trick)
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.
Recently I tried sharing a Steam library between Windows and Linux. Sadly, Proton does not support FAT32 so if your goal is to run those games under Proton you will be disappointed.
Honestly, given it's limitations (4GB Max Filesize & no journaling) FAT32 should not be used for anything aside from low capacity removable storage (or a purpose which is not frequently read from/written to).
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.
I did this on a Mac with my bootcamp partition with parallels desktop. I only booted into windows when I wanted to play a game. The rest was mainly done as a VM. I had some shenanigans with windows licenses and other software that insisted that these systems are two different computers ;)
I did this with VMware Workstation back in 2000-01, only the other way around if I remember it right (Linux host, dual booting / shared with a virtual Windows 2000 partition). I was honestly surprised it worked so well.
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.
You can also install VMware esxi on a thumb drive and just boot from that. esxi has excellent support for them booting physical or virtual disks including USB and GPU passthrough from there. If you want to boot your VM on bare metal then just remove the thumb drive on next boot.
I was recently doing archaeology of my ZFS disk, and it reminded me of how I started using ZFS - With three disks in a Raid, running under FreeBSD. That FreeBSD System was running as a guest via VirtualBox, with the windows machine host having it's own disk. I then mounted that via Samba/CIFS... Good times, terrible hacks.
I actually managed to get it to work both ways: I can boot each OS in a VM from the other. A handful of scripts inside each detect the VM and make some changes appropriately (like disabling certain startup apps and services that I already have in the host OS, disabling some fancy graphics that like to glitch out in VMs, etc.). And because I like to over-complicate things, I set up static IPv4s, so I can for example connect to Linux with the same IP, not matter if it's in a VM or running on bare metal.
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.
IIRC there was a way to do something like this way back, maybe during kernel 1.x days. It used some weird filename translation to load files from an old FAT (as in 8.3) filesystem.
Many moons ago, you were able to not only install Linux in a DOS directory, using probably UMSDOS or perhaps Syslinux—but also take over DOS with Loadlin and launch straight into full-blown Linux: https://en.wikipedia.org/wiki/Loadlin
Considering that Windows 95 still was a shell over DOS (until a later update?), you could conceivably just ‘quit to DOS’ and then run Linux. Alas I don't know of a reverse process.
The 'quit to DOS' option was not enough: it kept some windows bits until running, maybe in TSR mode. To use loadlin, you had to reboot and press f8 during boot and then choose to run DOS.
I don't know what linux would actually do in that situation. Actually the loader (loadlin) is what failed. The message was not that informational, somewhat cryptic or non-memorable because I really don't remember anymore. But I think you can see the problem happening again if you try to use one of those distros that booted from a fat filesystem on dosbox.
By modern standards, is DOS really an operating system, or is it more of an overgrown bootloader? I remember setting up old games, and having to tune memory settings, specify sound devices, and configure video, almost making them mini OSes.
A trick I used some times was to create a big file on NTFS and use a loop back (block) device to format and mount it as ext4 (root) filesystem. The old kernel ntfs module had already write support for this. It was noticable slower but it didn't mess up the NTFS filesystem.
Back in the days of FAT partitions, and when partitioning disks with data was somewhat risky, the first distribution I used was Phat Linux [1], which was installed in the same partition as Windows as well. The main side effect I remember was that all files appeared as executable to Linux. I don't recall how/if it handled symbolic links.
Reading these comments has me concerned about even installing Windows and Linux on different partitions of the same drive. Should I be concerned? I have an unused but relatively new Thinkpad onto which I want to install both Windows 11 and Linux.
The Windows EFI loader only loads Windows, and requires specifically rebooting into advanced startup to choose a different OS (and their mechanism for finding OS's isn't super reliable in my experience)
> Windows installers are still hostile to other OSes (I think)
This only happens in two specific cases: 1. MBR + same physical disk for both OSes; 2. Bad UEFI implementation on the mobo + same physical disk for both OSes.
Otherwise it should work flawlessly because their bootloaders are independent and it's only a matter of setting the desired boot order.
The simplest, non-breaky, reinstall-tolerant way of dual booting is to install operating system on different partitions and NOT install grub or anything to the root/EFI partition.
Install your bootloader to the SAME partition as you installed linux in. This is not the default in either windows or linux - and it will try to scare you into not doing it. But do it!
Now, use your laptop's built in bios feature - "press f12 while rebooting" to select the disk to boot into.
This will never fail. You can reinstall windows as many times as you like. You can burn your linux install and reinstall. They will never screw each other over and you will never be left unbootable.
I think that is only necessary for UEFI installations. I was able to do this earlier with extlinux[1]. This mentions a stackexchange question that suggests btrfs installations are possible in the same fashion[2].
I believe most BIOSes don't let you boot partitions, but only disk MBRs.
You can however install GRUB to USB stick and boot the USB stick from the BIOS. This also protects your Linux install against any Windows malware that doesn't change the BIOS if you are careful to remove the stick before booting Windows, put /boot on the USB stick as well and encrypt the Linux partition.
WSL 1 effectively, but WSL2 runs as VM with a virtual hard disk, with a default location of %LOCALAPPDATA%\Packages\CanonicalGroupLimited.Ubuntu20.04onWindows_79rhkp1fndgsc\LocalState\ext4.vhdx
Not the same thing, but I remember a great hack back in the day — from Byte, I believe — where a 128k Apple IIe/c could live dual boot ProDOS & DOS 3.3 using bank switching, with each OS living in its own bank. Switching was easy, being a simple command line command. That was fun (and occasionally useful).
>The term "cooperative" is used to describe two entities working in parallel. In effect Cooperative Linux turns the two different operating system kernels into two big coroutines. Each kernel has its own complete CPU context and address space, and each kernel decides when to give control back to its partner.
>However, while both kernels theoretically have full access to the real hardware, modern PC hardware is not designed to be controlled by two different operating systems at the same time. Therefore, the host kernel is left in control of the real hardware and the guest kernel contains special drivers that communicate with the host and provide various important devices to the guest OS. The host can be any OS kernel that exports basic primitives that allow the Cooperative Linux portable driver to run in CPL0 mode (ring 0) and allocate memory.
Thank you for bringing back this memory. As a child who had recently installed Linux for the first time, I saw someone presenting at Bentley Systems using CoLinux and have forever wondered what it was (I wasn’t able to speak to them directly nor was it related to the presentation they gave). I dove into virtual machines at the time thinking it was just some seamless graphical sharing and a wallpaper to show it off, but seeing the logo it was definitely this.
I used CoLinux early in my career. It was great! We had a number of projects that needed Visual Studio, but anything Ruby was just so much better using Linux. VMs were an option but having to context switch between what window I have what open in, plus is it in the VM or my main machine meant I was constantly losing track and having to search for things. CoLinux made it seamless. Really sad to see it's been abandoned. WSL looks pretty good, but not the seamless integration CoLinux had.
I don't think WSL1 was abandoned, was it? last I heard it was supported and meant to complement WSL2. I know of people who need WSL1 because WSL2 doesn't meet their needs in some specific ways. so, yeah, if you know where that's documented I'd like to be able to show that to said colleagues.
Sadly, that one seems to be on vbox. Windows exposes an API that lets a VMM like virtualbox create vCPUs on top of Hyper-V (https://docs.microsoft.com/en-us/virtualization/api/hypervis...). VMWare workstation and QEMU have added support for it and it works quite well, very close to native. I know vbox did implement it, but it seems to work not nearly as well.
WSL1 was one of the coolest things I've ever seen Windows do and I'm so disappointed that it's not being worked on anymore. WSL2 seems like such a massive step backwards by comparison. Sure, it's more performant, but it's just running a VM on a hypervisor. I could've done that with any number of other tools available. WSL1 was unique (afaik).
Cooperative multitasking actually works really well if the system is designed for it. It has many performance and reliability benefits.
It's mostly used in embedded or IOT systems, or inside a single application with async/await, but it can be used for the whole OS as well.
If the system and its built-in applications are designed to take advantage of it, and any external application is run inside a VM to make sure it doesn't misbehave, cooperative multitasking works great.
It may not be useful to you, but as someone who maintains a dual-boot Windows/Linux system, I currently have to make an upfront decision about how to allocate storage between Windows and Linux. Having everything in one partition would free me from having to either over-allocate OS-specific space, or risk having to resize partitions later if I run out. It would also eliminate the need to have duplicate copies of certain data across both operating systems.
But the OS partition being shared with Windows isn't buying you these advantages. That is, you can still do all this with installing your Linux-based OS into a fixed size, well-known in advance size (40GiB).
The things that grow over time aren't part of the OS, they are user data, which can be shared without doing anything special -- just mount it up.
> The things that grow over time aren't part of the OS, they are user data
Unfortunately, that's not entirely true, at least for Windows. OS updates and other files are regularly stored in folders that aren't always trivial to put into a different partition. Not that this is enough of a reason to make this abomination your main install, but...
Windows did have an issue where it did not clean the update directory. They've fixed it. You can put your home on another partition, or if not for Windows, you can do it most easily for Linux.
There's solutions to this that are not the OP and are probably easier, people just write them off because "ew CLI."
I'm not afraid of having to do stuff in the CLI. And of course there are a ton of ways to solve it. None of them would be as straightforward or as elegant as having one partition that just contains all my user data and both of the operating systems I need to boot.
If only there was a way using suspend-and-kexec to allow switching in 5 seconds between linux and windows, without having to reboot each time. There was a PoC for WinXP, but I doubt it works with recent Windows versions.
148 comments
[ 5.3 ms ] story [ 232 ms ] threadHaving root filesystem on NTFS in any semi-sane way involves having kernel space NTFS FS implementation. Such a driver was introduced in 5.15 released on the 1st of this month.
Also, this reminds me of UMSDOS.
https://wiki.ubuntu.com/WubiGuide
They've since dropped the idea but you can still cobble together something similar.
https://unix.stackexchange.com/questions/309900/deploy-linux...
https://github.com/hakuna-m/wubiuefi/
That said this was back during win7, the cobbled together solution may be more stable..
The really nasty part is that even having separate drives won’t save you - I don’t know if Windows can install the bootloader to a different drive than the one holding the OS partition or if it’s some other bug but I absolutely remember a Windows install nuking the bootloader on other drives that were connected during the OS install.
It wasn’t a big deal pre-Windows 10 as you only install an OS once and disconnecting the drives is trivial, but nowadays with every update being an OS reinstall it’s a major problem if this issue still persists.
Every normal OS registers a boot option with the UEFI and puts its bootloader into a normal directory. It also pushes its own bootloader as the default in some cases, but that's just a single boot order change away after booting into the UEFI setup (or after messing with confusing and dangerous tools from inside Windows, which I wouldn't recommend).
The dual boot problem is only really insurmountable in BIOS+MBR mode (which should be considered long deprecated) and with buggy motherboards. Some people will set their system to BIOS+MBR mode for some weird reason, but with Windows 11 this mode should finally be dead already. UEFI has been an option since at least Windows 7 but it was disabled by default for a long time, so if you've upgraded to Windows 10 from a previous version, you'll most likely still be running this old and unstable config. I think this is one of the reasons new Linux users have so much trouble dual booting.
Modern motherboards detect different UEFI bootloaders installed on EFI partitions even if you swap around SSDs. Dual booting has come a very long way!
There's another problem. Motherboards with non-compliant UEFI specs. Exact details here may be flawed, but one of the most insidious dual boot issues I had, which prevented grub from loading was that it turned out, if you had a folder or file labeled windows or Microsoft in the EFI partition, it would always preferentially boot that one no matter what order you set to actually prefer. To fix it, I had to run the Linux EFI utilities for OS detection to set everything up, then go in and manually change everything with windows to some other name. This included modifying whatever the grub configuration file is that says to never modify manually. The biggest issue I had is that it took a LONG time to figure out that noncompliant UEFI specs on the motherboard was the problem. It was maddening.
https://bugs.launchpad.net/wubi/+bug/1471344
Removing wubi was a quick fix instead of patching it.
Wubi also had a dependency on grub4dos which had an idiosyncratic development and release style, to say the least. It was also the only component developed by non-English speakers, which made communication very hard. Later releases had some major regressions that were never sorted out, and I think everyone involved found it highly draining to deal with these issues without a more fundamentally correct way of tracking and preventing regressions.
you can do it with a single GPU nowadays
https://www.youtube.com/watch?v=_JTEsQufSx4
windows should be considered as a spyware, nobody should have it installed on an hardware
use VM with a good firewall behind
"would it be possible to hardlink C:\Users -> С:/home, for extra awesomness?"
(Yes, this is a joke)
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.
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.
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
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 o...
I'm occasionally using this to install Linux on an external drive.
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.
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
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.
[1] https://wiki.debian.org/InitramfsDebug
(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 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.
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!
[0] https://en.wikipedia.org/wiki/Windows_To_Go
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.
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...
[2]: https://help.ubuntu.com/community/Wubi
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.
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.
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.
[0] https://github.com/bobafetthotmail/refind-theme-regular
Considering that Windows 95 still was a shell over DOS (until a later update?), you could conceivably just ‘quit to DOS’ and then run Linux. Alas I don't know of a reverse process.
https://github.com/haileys/doslinux
A 486DX2-80 paired with a much newer circa-1997 3GB IDE hard disc on a VL-Bus controller should have been CPU-bound. UMSDOS made it disk-bound.
Its most solid use case was probably "mount a shared prtition and still have some Unix filename support".
[1] https://www.linux.com/news/phat-linux/
Linux installers are usually friendly with Windows, but Windows installers are still hostile to other OSes (I think).
This only happens in two specific cases: 1. MBR + same physical disk for both OSes; 2. Bad UEFI implementation on the mobo + same physical disk for both OSes.
Otherwise it should work flawlessly because their bootloaders are independent and it's only a matter of setting the desired boot order.
Install your bootloader to the SAME partition as you installed linux in. This is not the default in either windows or linux - and it will try to scare you into not doing it. But do it!
Now, use your laptop's built in bios feature - "press f12 while rebooting" to select the disk to boot into. This will never fail. You can reinstall windows as many times as you like. You can burn your linux install and reinstall. They will never screw each other over and you will never be left unbootable.
FYI- I had a Dell XPS laptop and it would work just fine.
How does that even work? Is your motherboard able to read ext4 partitions?
[1] curl https://wiki.archlinux.org/title/Syslinux | grep partitionless
[2] https://unix.stackexchange.com/questions/103501/boot-partiot...
However, strictly speaking - modern bioses can scan bootable partitions.
You can however install GRUB to USB stick and boot the USB stick from the BIOS. This also protects your Linux install against any Windows malware that doesn't change the BIOS if you are careful to remove the stick before booting Windows, put /boot on the USB stick as well and encrypt the Linux partition.
I have generally not seen a non-UEFI bios or computer in the past 6-7 years. So you should be fine with UEFI.
Again, for some reason Linux installers scare you into using MBR mode. Its unnecessary now.
https://en.wikipedia.org/wiki/Cooperative_Linux
>The term "cooperative" is used to describe two entities working in parallel. In effect Cooperative Linux turns the two different operating system kernels into two big coroutines. Each kernel has its own complete CPU context and address space, and each kernel decides when to give control back to its partner.
>However, while both kernels theoretically have full access to the real hardware, modern PC hardware is not designed to be controlled by two different operating systems at the same time. Therefore, the host kernel is left in control of the real hardware and the guest kernel contains special drivers that communicate with the host and provide various important devices to the guest OS. The host can be any OS kernel that exports basic primitives that allow the Cooperative Linux portable driver to run in CPL0 mode (ring 0) and allocate memory.
[0] see the dozens of official Windows GUI frameworks: https://news.ycombinator.com/item?id=16736720 (and since then, it's gotten worse: https://www.google.com/search?hl=en&q=uwp%20deprecated)
QEMU might work for your usecase though.
It's mostly used in embedded or IOT systems, or inside a single application with async/await, but it can be used for the whole OS as well.
If the system and its built-in applications are designed to take advantage of it, and any external application is run inside a VM to make sure it doesn't misbehave, cooperative multitasking works great.
The things that grow over time aren't part of the OS, they are user data, which can be shared without doing anything special -- just mount it up.
Unfortunately, that's not entirely true, at least for Windows. OS updates and other files are regularly stored in folders that aren't always trivial to put into a different partition. Not that this is enough of a reason to make this abomination your main install, but...
There's solutions to this that are not the OP and are probably easier, people just write them off because "ew CLI."