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.
- UEFI system
- Any Linux live-boot CD/DVD/USB... with Linux kernel newer than 5.15
- Windows installer USB
- Boot up Linux and create a EFI system partition. 1GB is enough (512MB may not be)
- Boot up Windows and normally install it. You may need to choose "Custom: Install Windows only" option.
- When finished, boot up Linux install USB and mount the NTFS partition Windows created. Note you need to specify
-t ntfs3
onmount
. - Mount EFI partition and other needed ones (like swaps) and continue installing.
- Don't forget to "Add
rootfstype=ntfs3
as kernel parameter" - Done!
- ldconfig crashes for me, using Arch.
- sometimes kernel panics on poweroff.
- the pioneer says "the system will break after a few boots"
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 theset 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 withchkdsk /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 normallinux
next tolinux-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:
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...)