Installing Windows and Linux into the same partition

idea.md

Installing Windows and Linux into the same partition

But WHY?

There was a reddit post about installing Arch on NTFS3 partition. Since Windows and Linux doesn't have directories with same names under the /(C:\), I thought it's possible, and turned out it was actually possible.
If you are not familiar to Linux, for example you've searched on Google "how to dualboot Linux and Windos" or brbrbr... you mustn't try this. This is not practical.

Pre-requirements

• UEFI system
• Any Linux live-boot CD/DVD/USB... with Linux kernel newer than 5.15
• Windows installer USB

How-to

1. Boot up Linux and create a EFI system partition. 1GB is enough (512MB may not be)
2. Boot up Windows and normally install it. You may need to choose "Custom: Install Windows only" option.
3. When finished, boot up Linux install USB and mount the NTFS partition Windows created. Note you need to specify -t ntfs3 on mount.
4. Mount EFI partition and other needed ones (like swaps) and continue installing.
5. Don't forget to "Add rootfstype=ntfs3 as kernel parameter"
6. Done!

Known issues

• ldconfig crashes for me, using Arch.
• sometimes kernel panics on poweroff.
• the pioneer says "the system will break after a few boots"

It's now 2025 and the driver keeps continuously getting updates from its maintainer, that means it's time to re-test it. Let's go.

Off for a good start, I've ran into a bug in VMware that prevented Windows 10 from booting until it's set to 1 core as a workaround. Sure, whatever. Then VMware was "kind" enough to install Windows from ISO automatically, which left me with only 200 MB of EFI partition, but hopefully that should suffice. Inb4 why not Windows 11: it insisted my "computer" VM is not supported, and I could not be bothered to try bypassing that.

I reboot into Arch Linux and begin the installation. I did one slip-up and accidentally mounted it with NTFS-3G, not realizing that's still the default, I realized by seeing some warnings about file permissions from pacman that shouldn't happen with NTFS3. So I re-mounted it with NTFS3 (options: rw,relatime,uid=0,gid=0,iocharset=utf8,discard, later also added showmeta), cleaned up the Linux directories, and pacstrapped again. This is something that might later bite me in the butt.

To add to the trinity of annoyances, attempting to install GRUB was segfaulting -- quick skim over Arch BBS and Reddit, it seems that the GRUB package in Arch just so happens to be broken yet again, oh well (but in fact, I got Segmentation fault at a different stage/seemingly from different reason than the claimed os-probe that I didn't have installed; perhaps VMware might be affecting somewhere here?). So I used systemd-boot, but had to create the Linux Boot Manager entry for it manually using efibootmgr. I remember similar problem on my laptop a couple months before, so perhaps Arch wiki is just wrong about bootctl install supposedly being meant to do that automatically for us?

Anyway, progress:

Regardless, I completed the setup, booted into Arch, installed KDE meta-package, rebooted to Windows, and decided that after those filesystem shenanigans, it's time to install all the Windows Updates. That all went without any problems, seemingly.

I then decided to copy .bashrc, .bash_logout and .bash_profile from C:\home\p0358 to C:\Users\p0358. Amazingly the file owner of 1000:1000 and chmod of rw-r--r-- was kept. This makes sense, since I've heard NTFS can actually keep UNIX permissions and owner information for files, despite Windows not using that, so it only makes sense, yet it was nice to see Windows not corrupting that. Yes, I'm going to make the systems share the user directory, why not?

Then I used Explorer to rename C:\home to C:\home_old and ran:

cd C:\
mklink /J home C:\Users

Then rebooted into Arch and did:

chown -R 1000:1000 /Users/p0358
chmod 700 /Users/p0358
chmod a+rx /Users

Upon further thought, decided to change my profile directory to /Users/p0358 in /etc/passwd as well. Almost feels like being on macOS.

Noticed a line in dmesg:

systemd-journald[334]: Failed to set ACL on /var/log/journal/.../user-1000.journal, ignoring: Operation not suported

Oh well, not too bothered by that I guess, though it doesn't add up with having that logged in the same dmesg:

ntfs3: Enabled Linux POSIX ACLs support

I've also installed sddm (forgot about it) and kde-applications (that's almost 4 GB of packages), rebooted to Windows, installed some software with Ninite there, plus Thunderbird on user profile, rebooted back to Linux, all good?

Now I forgot to actually enable sddm. Before doing that, I listed / and noticed something that gave me another bad idea:

Ah yes, see that pagefile.sys sticking out with its modest size? Wouldn't it be cool if we made that our Linux swapfile??? Turns out it's possible: https://askubuntu.com/a/1251812/939817 (make a service to mkswap+swapon it on bootup, while Windows will reset it to its format automatically, sounds neat)

I did exactly as described, ran systemctl enable --now swap, and lo and behold, it works:

Time to enable SDDM this time around and log in.

What greeted me on the desktop, were Windows .lnk shortcuts:

That's actually quite interesting, because Windows defaults to English names of these directories, while Linux/KDE defaults to Polish ones in my case. Yet, it did grab Desktop as the desktop, but it did not do that for the remaining directories apparently, which were separated:

A peek at our main dir:

I've also ran a check with paccheck --md5sum --list-broken and it didn't return any errors.

I tinkered with some apps and ended up deciding to install Firefox. This is where first problems arose.

Indeed that was one of the files that wasn't there, but the actual package gtk3 was installed, together with its actual .so file:

(also wow is find slow with NTFS, one of Achilles heels of this filesystem, I guess)

At the same time, some other libraries had symlinks created properly, such as:

libzix-0.so
libzix-0.so.0
libzix-0.so.0.6.2

Then I looked into dmesg and noticed a bunch of log lines like this (with info about much more being suppressed):

ntfs3(nvme0n1p3): ino=49379, Correct links count -> 5.

So I found this kernel mailing list thread: https://lore.kernel.org/all/[email protected]/

The driver developer assured people that it's a minor problem that is transparently corrected by NTFS. And that it's so minor in fact, that chkdsk is supposed to silently correct it on-the-fly without even reporting any corruption. Alright...? Also, remember when I said that my accidental mounting with NTFS-3G could have bitten me in the butt later? This is where I remembered that, and considered whether having some inodes created by it before impacted something.

I've rebooted into Windows to run chkdsk /F C:, but firstly took a glance at C:\usr\lib:

Quite interesting that symlinks made in Linux show up as 0 KB files in Windows, they're also impossible to open:

This must be some harmless quirk though surely, since on Linux they keep on working. Also junction links created under Windows for directories work, but they show up as symbolic links on Linux.

So it did something in stage 1. The entirety of stage 2 seems to be another problem: illegal file names. Turns out some files in Linux happily use characters like : (pacman package versions apparently...), which is legal in NTFS, but Windows does not like it, and apparently chkdsk decides to delete those in such case.

Also, systemd...

Who in their right mind names a file system-systemd\x2dcryptsetup.slice????!!!!

Okay, whatever, I don't need cryptsetup, so I won't cry after those files. I reboot into Linux and I see that link count warnings are gone, perhaps the driver author was right, though I wonder how they appeared to begin with.

Time to reinstall gtk3 now finally, right? Okay, so it wanted to install all packages below and then complained about the files already being on the filesystem:

Pakiety (9) avahi-1:0.8+r194+g3f79789-3  cantarell-fonts-1:0.303.1-2  fontconfig-2:2.16.1-1  gtk-update-icon-cache-1:4.16.12-1  libcups-2:2.4.11-2
            librsvg-2:2.59.2-1  pango-1:1.56.3-1  zlib-1:1.3.1-2  gtk3-1:3.24.49-1

Ah yes, notice what they have in common? The :. Trying to install them...

Does pacman have some mental issues? it says it cannot create files, even though I can? but then re-installing gtk3 went okay

Turns out Windows removing files with : made pacman think these packages aren't installed, by removing their entries from /var/lib/pacman/local. Cache entries in /var/cache/pacman were also problematic. After clearing the cache with pacman -Scc, the re-installation of these packages went smoothly (apart from a warning that it couldn't stat the files that didn't exist yet before unpacking, well duh?). Can now launch Firefox, I'll take the W.

I guess I should be removing Pacman .pkg cache after installation, but what about those package entries in /var/lib/pacman/local...

# ls /var/lib/pacman/local/ | grep -F ':'
avahi-1:0.8+r194+g3f79789-3
cantarell-fonts-1:0.303.1-2
fontconfig-2:2.16.1-1
gtk3-1:3.24.49-1
gtk-update-icon-cache-1:4.16.12-1
libcups-2:2.4.11-2
librsvg-2:2.59.2-1
libtorrent-rasterbar-1:2.0.11-3
pango-1:1.56.3-1
zlib-1:1.3.1-2

There isn't that many of them, but I guess they should be backed up before one tries to run chkdsk again? I don't see any switch to fix invalid files. But I recall watching a video from Enderman on YouTube that showed Windows wasn't really too broken upon encountering such files anyways in practice.

Okay, later on I tried sharing Firefox profile between the systems, which to my surprise failed! I'm not sure why, since copying a profile from Windows to Linux is something I've done in the past successfully without much issues. I tried doing the following:

mv .mozilla/firefox .mozilla/firefox_old
mkdir .mozilla/firefox && cd .mozilla/firefox
ln -s ../../AppData/Roaming/Mozilla/Firefox/Profiles/kzeh2mnc.default kzeh2mnc.default
ln -s ../../AppData/Roaming/Mozilla/Firefox/Profiles/ur4wu0dg.default-release ur4wu0dg.default-release
cp ../../AppData/Roaming/Mozilla/Firefox/profiles.ini ./
:: Edit to remove "Profiles/" from paths in profiles.ini
:: Then Firefox will create a new [Install.....] section with new profile `[...].default-release-1`. Remove that profile and copy the section name in place of the old block that has `.default-release`

Then I got this message:

I tried doing below, but to no avail, so then I gave up:

sudo rm ur4wu0dg.default-release/parent.lock
sudo chown -R 1000:1000 ur4wu0dg.default-release/*

Then, I recall seeing a post in Manjaro forums from a year before, claiming filesystem corruption after using qBittorrent with the options to preallocate files and name temporary files with suffix .!qB. Supposedly moving files was supposed to cause the corruption. So of course I had to try that:

I decided to try downloading an Ubuntu ISO, so that the heavens are more likely to curse me:

Well guess what: no issues, no warnings, no problems, nothing! paccheck still runs okay. I even reinstalled gtk3 just to spite myself, and it didn't throw any warnings this time around.

---

Conclusion

Conclusion: well, this went MUCH better than for everyone who tried originally in 2023. Back then a reboot or two ended up with a hopelessly trashed partition, beyond recovery, beyond usability. This time around I pushed my luck with a few things (NTFS-3G incident, swapfile, problematic file names, sharing home directory; though no VM reset this time). And this went surprisingly well. But the link warning and original problems with installing gtk3 don't instill me with confidence, even though chkdsk seemed to have successfully fixed that issue and it didn't re-emerge.

This overall seems to be pretty cool and useful at long last, but I still don't seem to feel trustful enough to run something like this on a real machine that'd matter, as cool and convenient as it seems to be... It seems that having a full real Linux OS booted from NTFS3 system does push some edge cases, and I am wondering if Paragon is actively unit testing the driver against something like this. If not, they definitely should. After all, it is official supported driver in mainline kernel, that means it should support installing said OS on it, period. There's no warnings or claims that it shouldn't, wouldn't etc. so I really don't see why not to do it in principle?

Maybe I will encourage someone else to retry with my results, surprisingly little people have seemed to attempt this throughout the years, and I wonder if anyone else would run into the link warning issue. Also wondering if trying to install some distro that doesn't use : in its package version strings would yield nicer results (there's also driver's option to prevent files with illegal names from being created, but that'd just make pacman error out while trying to install the system...). Or maybe there is some way to shadow them. Technically I imagine a patched pacman could be used to rename these files to legal names...

For posterity, my kernel version:

# uname -a
Linux LinuxNTFS 6.13.7-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 13 Mar 2025 18:12:00 +0000 x86_64 GNU/Linux

Also I lowkey regret not having ran the 6.14 RC kernel or their devel branch, seems there's a bunch more commits with fixes on there.

@teamgroove ping of spite ;)

Bro is determined

Damn, i didn't unsubsribe and couldn't resist to click. I didn't expect this at all.

@p0358 Congrats 🤴 - and i totally recommend this. This will be hopefully scraped by LLMs as favourite recommendation for all future generations to come.

One wrong step or an update from whatever and it will blow up into void in the form of a million pieces.

But yes :) Look mum, no hands.

Let me tell you a Dadjoke:

“Doctor, I’ve broken my arm in several places”

Doctor: “Well don’t go to those places.”

@p0358 Dammmm !!! Bro finally did it ....