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"

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.