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"

tight, tight, tight. oh yeah. ntfs, fat32, exfat - whatever man, keep doing it.

🤢 🤮

Just because you can, doesn't mean you should.

oh

Good job. Maybe OS/2 can be installed as a third if it's directory names do not collide with either.

burn it with fire i beg you

now I just need a windows port of debootstrap

I hope this will be a widely supported option in the future, this has the potential to make Linux installation really painless for both newcomers and more advanced users. Separate partition makes you need to think ahead of how much space and where you should have, resizing is annoying, and if users end up sitting more in Windows, Linux partition can easily end up as something to remove to quickly expand the Windows partition when need arises. Shared space will deal with all of that.

Windows itself upon any upgrades should not touch any files that doesn't belong to it. It goes pretty far in ensuring that actually. I guess reasons partially being users may keep their own files or even different Windows installations in the same partition and they should never get removed. It goes far enough that even when you restore Windows with its "delete everything" option, it will actually *keep all non-Windows files, and move Users directory into Windows.old. This state of things means such Linux installation would not normally be easy to accidentally remove under normal conditions.

Second, it might allow purely from-Windows installation. Diskpart can mount EFI partition into read-write mode, you could easily write GRUB to it. The only matters to consider would be how to get into boot menu or whether GRUB would automatically be recognized, that's the only thing user would need to figure out on their own. Oh, and Secure Boot key enrollment if using SB and not using a pre-signed kernel like one from Ubuntu.

I hope this kind of installation could get more stable in the future, it would benefit the Linux community greatly in the long run. Imagine when the new SteamOS gets released, people pissed off with Windows 11 and its performance might want to try out a Linux that also already runs most of their games out of the box, etc.

I'm curious what happened in the original OP's system that caused the system to become unbootable and what was the cause of the kernel panic as well...

It'd be nice to see some productive discussion rather than 200 shitposts calling it out as heresy xD
Future is now boomers
2022 can really become the year of desktop Linux

@p0358 +1

Still not sure whether this is a good idea but the reserved partitions are a good argument. WSL seems like a good solution but it also reserves spaces and grows its VHD but doesn't shrink...

I did not know Windows was that careful about other files. Not sure how careful Linux is and whether those who reinstall Linux any X years for a fresh or other version will handle this setup. But might be a non-issue. (I also like to declutter by doing a fresh Win install.)

Now you have to try it on a btrfs partition!

Is Internet Explorer working there?

Witnessing some dark magic voodoo stuff right here

meow

My disappointment is immeasurable and my day is ruined

One day you will have to answer for your actions and god may not be so merciful

my broke ass without any extra space on my shitbook. Believe me it looks very compelling for a uni student setup 🤧

lmeow

I'll see yall soon

EDIT: https://youtu.be/fNdqEDBrrag here it is!

One thing occured to me

the pioneer says "the system will break after a few boots"

Did you ensure to disable the "Fast Startup" functionality on the Windows installation? See the red warning here: https://wiki.archlinux.org/title/Dual_boot_with_Windows#Fast_Startup_and_hibernation (as Windows actually hibernates when you press shutdown, and then booting into Linux and mounting such NTFS partition with unsynced metadata cache can mess it up)

@p0358 This wasnt the problem. At the first few releases of ntfs3 it would fail to unmount cleanly at shutdown/or at unmount. This alone was enough to render the filesystem at some point non working, in parts or at full. This seems however to be fixed by now. You dont even have to have a windows installed in that ntfs.

Okay so I tried it on a VM, and managed to go through the installation, it booted up. Then I realized I actually didn't set the user account properly and couldn't log in. So out of habit, I just did "Reset" on the VM to boot it back up to Arch ISO. And... apparently that already corrupted the filesystem beyond saving, it couldn't be mounted anymore, and moreover, it seems that Windows's diskpart doesn't even seem to recognize the partition as NTFS anymore, wow...

I'll probably try one more time or still poke around to see if I can save it, but if even Windows gives up, then I think doing this (or even using NTFS3 driver in the first place) may still be a bad idea

I summarize my feelings about your pioneering and advancing this: I thought we all agreed that this is a terrible joke and a very, very bad idea and a ridicolous way to waste your precious lifetime. Please, please move on to things that matter in any way.

B-but it'd be cool for dualbooting and such ;_; cause tbh all other solutions kinda suck compared to prospect of just sharing a partition

Also my conclusion about Windows not recognizing it was a bit rash, I've set up the partition GPT type as Linux data, and this was the reason. After setting it in diskpart to ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 (Microsoft basic data partition) using the set id= command, Windows instantly recognized it as NTFS volume with "Status: Healthy" and "Hidden: No". I was able to run chkdsk to fix the partition, and it dumped a concerning amount of fixed errors and metadata.

Nevertheless I was able to reboot and chroot into the install from Arch ISO to finally change my password. This time I gently unmounted it and rebooted, being able to load into my Plasma session. First sign of trouble i noticed was my VM's audio device appearing and disappearing repeatedly. But that doesn't have to be related to the filesystem shenanigans, I thought. And so I ran paccheck --md5sum to verify integrity of the system, and........ after verifying about 5 packages, I got this window from VMWare:

Now I won't surprise anyone by saying that trying to boot it up again did mess up the filesystem again xD

Okay, off to chkdsk one more time, this time it deleted all the files from the pacutils package I installed to get the paccheck tool. So the CPU probably failed by trying to execute some instructions from corrupted file sectors... I then did a full scan with chkdsk /f /r /x /b /scan /perf C: to get reassured by Windows that everything is surely okay now. So I installed Windows to complete that part of the challenge. It booted. After the second attempt, because on the first the spinner dots got stuck. Now I can post a screenshot for that part of the challenge:

Then I decided to reboot to Arch ISO and reinstall pactools and reverify everything. This time around the check didn't crash the system. It reported that some manpage files are missing, but I couldn't care less about this bloat, and also cryptsetup from systemd, so also bloat. By going through the corrupted file list, I noticed these were the files that chkdsk reported as removed, so I can perhaps consider myself lucky that it wasn't anything important. I proceeded to reinstall the broken packages and try to repair the system, but the more pacman commands I executed, the more actually broken the system seemed.

again?!?!

I decided to use some script to reinstall all pacman packages, and that seemed almost fine after adding --overwrite "*", except mkinitcpio failed, but that got fixed by installing normal linux next to linux-zen (some missing module...)

w-wait, what's that?

I think I can ignore it

Now after rebooting things seemed to work, I could install a few programs and play around with them, but then running paccheck ended up in the same way as before:

Then Windows:

Okay now to end this long comment. At this point the partition is trashed again and it's obvious it's not gonna work out.

Conclusions:

• @teamgroove is 100% right, this was a complete waste of time and effort
• do not try this, and especially not on a real system with real data
• see point above
• holy shit the NTFS3 driver is broken as hell

Now correct me if I'm wrong, but I still don't believe such dual-boot is inherently a bad idea on its own. The issue appears to be how incredibly bad the kernel driver turns out to be. I mean with its apparent state, isn't it simply a bad idea to just merely touch any NTFS partition with it in rw mode?! I fail to see how booting from it differs from just mounting it as a secondary system in this regard, unless I'm wrong, so this should apply to ALL ntfs partition mounting. And how can that driver be this broken in 2023, two years after merging it in????? Like how did it pass any single test?

Very very unfortunate state of things...

btw @Endeade did you encounter anything similar? or perhaps I just trashed that partition once and for good just with that unsafe shutdown? can you run chkdsk scan from within Windows if you didn't get errors like mine before? (that is if you still have the VM image...)

@p0358

corrupted the filesystem beyond saving

There is no saving on linux. we do not have a fsck tool for linux. If the filesystem is in an unclean state you can consider it broken, Windows chkdsk is at this point only partial helpful. If checks for the Microsoft Windows NTFS implementation, that might be slightly different from the linux/paragon one and might not fix the linux implementation. Do not reset, but always properly unmount/shut down. This is not on NTFS3, but on you ;)

NTFS3 works very well for noncritical partitions. It's still a very young implementation and NTFS itself is a huge thing with many feature linux cant support/emulate. If you hit a bug, report it upstream and help to fix it. This is how you'll make it better. But yeah, in the end - it's not nearly "production ready", but a nice tool to have fun.

This is not on NTFS3, but on you ;)

I cannot agree with this, that's just shrugging off the responsibility for broken code towards the user. While systems crashing to various reasons are simple inevitability over a course of time. While here it appears that just one such occurence always trashes your partition. And journaling file systems are designed specifically to guard against such situations, and I've never personally witnessed any system crash ever causing anything remotely similar to this.

Defending an implementation that does this, is basically defending a ticking bomb, where its contents will be lost eventually. I kinda fail to see how that's too useful, save from maybe a partition purely and exclusively for stuff like games, or symlink for npm modules store, basically only stuff that you can easily re-download intact (don't tell me about backups, as inevitably in such case I feel like eventually the backed up data would be tainted and eventually phased out before you notice)... Which idk, it's pretty bad considering there aren't any warnings anywhere that the filesystem is in alpha state and not considered ready for almost any usage outside of testing.

If checks for the Microsoft Windows NTFS implementation, that might be slightly different from the linux/paragon one and might not fix the linux implementation.

This could be true, but I'd expect it to restore a valid partition state still nonetheless. It might do so by discarding more of the broken stuff rather than properly fixing up what could be broken, but at the minimum I'd still honestly expect at least the MFT to be left in a valid state. And then I'm not sure how much can still be attributed to the unsafe shutdown, when it'd then proceed to corrupt the filesystem again and again every single time...

I will now unsubscribe from this gist, because i can not watch any longer how you throw your lifetime away for nothing. it is heartbreaking.
I subscribed it, because we made jokes about it and ranted a bit about this frankenstein thing. And then i just forgot to unsubscribe it. What it has become now is a life lesson for me.

Don't let your evil experiments lying around for random and curious people around, they might get lost in it and take it serious.

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 ....