Can I mount rootfs from file localed in other filesystem

Question

I want to boot Linux on my PC, but I am not allowed to create additional partitions on the disks, and booting from USB is slow. I have two disks, on the first one I installed Windows 10, and on the second one (which is formatted to NTFS filesystem) I stored files.

I tried to place the rootfs on the second disk. For this, I installed Arch Linux on the other disk and installed GRUB to the USB. I created a FAT partition on this USB and copied the kernel and ramdisk from the installed Arch Linux. Then, I created a file D:\ArchLinux\root.img, formatted it to ext4, and copied the root filesystem from the installed Arch Linux.

Then, I booted the USB, ran the GRUB command line, and wrote the following commands:

set root=(hd0,msdos1)
linux /vmlinuz-linux rootfstype=ntfs3 root=/dev/sda2 loop=ArchLinux/root.img loopfstype=ext4 rw
initrd /initramfs-linux.img
boot

(I found them in this answer: Can I make SYSLINUX load a root fs from an image file on an NTFS partition?)

During the boot process, I got an error:

mount: /new_root: unknown filesystem type 'ntfs3'.
       dmesg(1): may have more information after failed mount system call.
ERROR: Failed to mount '/dev/sda2' on real root
You are now being dropped into an emergency shell.
sh: can't access tty; job control turned off
[rootfs ~]#

Please help me solve it.

Answer 1

Technically yes (Ubuntu used to have that), but the initramfs needs to include all the drivers necessary for the underlying filesystem.

It is not syslinux that mounts the root filesystem or your image; all it ever loads is the kernel and the initramfs, and the latter does the rest. The initramfs is what actually has drivers for your root filesystem (which are automatically picked out of the main system at some point); here you also need to make the tools include NTFS drivers as well. That's MODULES+=(ntfs3) in mkinitcpio.conf.

(I would probably rather use ntfs-3g instead; it needs the "fuse" module and FUSE libraries and mount.ntfs-3g instead. Although it's slower, it is still more reliable than the new ntfs3 driver... and I think it's what Wubi used to use, anyway.)

In addition to NTFS, however, you also need to convince the initramfs to set up the actual loop mounts. But since the tools for building an initramfs (and the contents thereof) vary between distributions, so do the boot options. What works for a Dracut-based initramfs from Fedora will not necessarily work on Debian, and parameters recognized by a genkernel initramfs on Gentoo won't necessarily be recognized by a mkinitcpio initramfs on Arch.

Most of those tools are also modular, so even if the options you find are for Arch specifically, they might only be used by hooks or modules that aren't in use by default; you'll have to enable them in mkinitcpio.conf first. In this case, however, mkinitcpio does not have any hooks that would recognize loop= as an option. The functionality is literally not present.

(The thread you found was written by someone who used Mint, i.e. basically Debian – which builds an initramfs very different from Arch's.)

So to make this work, you would also need either a) a custom mkinitcpio "hook" script, or b) to switch to a different initramfs tool.

For option a), the hooks live in /usr/lib/initcpio and aren't that hard to write. In fact, the AUR has a "mkinitcpio-loop-subdir" package that presumably adds exactly this functionality, although likely with different options. (I haven't read its docs, but intuitively I would expect the image to be your root= while the underlying partition would be a separate option, like how cryptdisk= is separate.)

For option b), there's some variety; I think a systemd-based mkinitcpio initramfs (same tool but different set of hooks) would make this possible, if you were to embed an /etc/fstab into the initramfs. Arch also has Dracut and Booster available as an alternative; the former should definitely have the feature, the latter might not.