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"

I am happy to be here to witness history.

I'm here to support. For history.

Next challenge: Create a bootable Linux environment entirely from within Windows. Somehow mount the EFI partition within Windows, drop the kernel there (with an embedded initramfs), set up a Linux root on your NTFS partition, reboot, choose the EFI stub, and go.

One of these operating systems is a tortured animal! (and the other one is a mildly uncomfortable penguin)

Next challenge: Create a bootable Linux environment entirely from within Windows. Somehow mount the EFI partition within Windows, drop the kernel there (with an embedded initramfs), set up a Linux root on your NTFS partition, reboot, choose the EFI stub, and go.

Windows 10/11 already setup an EFI partition on the default installation. So it would be easy to install the EFI stub in there, in fact I already installed GRUB in the same EFI partition as Windows for my current dual-boot installation.

Now you can use Windows as the fsck tool for when your Linux drive gets broken. Epic!

When you're at it and all into that - why not tweak and squeeze the little penguin a bit harder: enable "NTFS disc compression" to raise the heat at the north pole ...
https://www.windowscentral.com/how-use-ntfs-compression-windows-10

hint: another one bites the dust!

Brilliant!

Beautiful.
Now you can install wine and set wineprefix to /

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.