kagerato
March 12th, 2011, 11:41 PM
The 'Lubi' project (see http://lubi.sourceforge.net/lubi.html ) performs essentially the task I seek, but it seems to be outdated (last updated in 2007).
In general, the idea is to install Ubuntu (or some other distribution) inside a file that resides on an existing partition. That file itself contains a complete filesystem.
Though I made many a google search attempting to research the exact mechanism by which both Wubi and Lubi accomplish that goal, I was only able to ascertain a few things:
(1) No version of Grub has support for booting a filesystem-in-filesystem. It can extract a few key files out of certain kinds of filesystems in order to start the kernel, but that's about the extent of its capacity.
(2) Therefore, the kernel to be booted itself needs to have the capacity to load a file as the root filesystem.
(3) The loop block device provides the essential capability to load a file as though it were a filesystem, and the abstraction is mostly to entirely transparent to the rest of the system.
(4) Almost the same effect can be achieved by loading a special kernel and initramfs that switches out the root filesystem with the desired one. However, in this case the boot sequence is Grub -> Linux Minimal Subsystem -> Full Userspace . It would be much more convenient to be able to control the system to be booted directly from grub, and not having any special init scripts to select and/or swap the root filesystem.
I imagine there must be someone out there who has done this and understands the underlying mechanisms very well. The closest I've come to a concrete example of it, however, are sample grub configurations for Wubi. Those look like this:
menuentry "Ubuntu, Linux 2.6.31-14-generic"
{
insmod ntfs
set root='(hd0,1)'
search --no-floppy --fs-uuid --set be4c68fe4c68b337
loopback loop0 /ubuntu/disks/root.disk
set root=(loop0)
linux /boot/vmlinuz-2.6.31-14-generic root=/dev/sda1 loop=/ubuntu/disks/root.disk ro quiet splash
initrd /boot/initrd.img-2.6.31-14-generic
}
My key questions are these:
(1) Does this mechanism require a special kernel? It doesn't look like it, but I can't be sure. Some of the Lubi packages seem to ship a precompiled kernel, but that might only be for convenience rather than necessity.
(2) Where is this loop= kernel option documented? I can't seem to find official kernel documentation on this. Several documents record a "max_loop" parameter, but no loop. My sneaking suspicion is that this may not be an offical core parameter, but something used by the initial ramdisk.
(3) Does this mechanism require a full disk or full partition in the disk image, or will it work loading just a straight filesystem? This is really only of concern for simplicity reasons, since I see no reason to complicate matters unnecessarily.
If anyone wonders why I would want to use this mechanism, it has certain advantages for backups and testing/experimentation. One, it's much faster than virtualization, since the only performance overhead is passing through the top-level filesystem. Two, maintaining many separate partitions is a hassle, especially when one realizes the sizes are wrong or there are not enough entries in the existing partition table. Creating and deleting filesystem images is simpler and more self-contained, by comparison.
Oh, and I'm aware that btrfs provides essentially exactly the capability I'm looking for as "subvolumes". I have concerns about the stability/reliability of that filesystem, though, since it still seems to be under heavy development.
In general, the idea is to install Ubuntu (or some other distribution) inside a file that resides on an existing partition. That file itself contains a complete filesystem.
Though I made many a google search attempting to research the exact mechanism by which both Wubi and Lubi accomplish that goal, I was only able to ascertain a few things:
(1) No version of Grub has support for booting a filesystem-in-filesystem. It can extract a few key files out of certain kinds of filesystems in order to start the kernel, but that's about the extent of its capacity.
(2) Therefore, the kernel to be booted itself needs to have the capacity to load a file as the root filesystem.
(3) The loop block device provides the essential capability to load a file as though it were a filesystem, and the abstraction is mostly to entirely transparent to the rest of the system.
(4) Almost the same effect can be achieved by loading a special kernel and initramfs that switches out the root filesystem with the desired one. However, in this case the boot sequence is Grub -> Linux Minimal Subsystem -> Full Userspace . It would be much more convenient to be able to control the system to be booted directly from grub, and not having any special init scripts to select and/or swap the root filesystem.
I imagine there must be someone out there who has done this and understands the underlying mechanisms very well. The closest I've come to a concrete example of it, however, are sample grub configurations for Wubi. Those look like this:
menuentry "Ubuntu, Linux 2.6.31-14-generic"
{
insmod ntfs
set root='(hd0,1)'
search --no-floppy --fs-uuid --set be4c68fe4c68b337
loopback loop0 /ubuntu/disks/root.disk
set root=(loop0)
linux /boot/vmlinuz-2.6.31-14-generic root=/dev/sda1 loop=/ubuntu/disks/root.disk ro quiet splash
initrd /boot/initrd.img-2.6.31-14-generic
}
My key questions are these:
(1) Does this mechanism require a special kernel? It doesn't look like it, but I can't be sure. Some of the Lubi packages seem to ship a precompiled kernel, but that might only be for convenience rather than necessity.
(2) Where is this loop= kernel option documented? I can't seem to find official kernel documentation on this. Several documents record a "max_loop" parameter, but no loop. My sneaking suspicion is that this may not be an offical core parameter, but something used by the initial ramdisk.
(3) Does this mechanism require a full disk or full partition in the disk image, or will it work loading just a straight filesystem? This is really only of concern for simplicity reasons, since I see no reason to complicate matters unnecessarily.
If anyone wonders why I would want to use this mechanism, it has certain advantages for backups and testing/experimentation. One, it's much faster than virtualization, since the only performance overhead is passing through the top-level filesystem. Two, maintaining many separate partitions is a hassle, especially when one realizes the sizes are wrong or there are not enough entries in the existing partition table. Creating and deleting filesystem images is simpler and more self-contained, by comparison.
Oh, and I'm aware that btrfs provides essentially exactly the capability I'm looking for as "subvolumes". I have concerns about the stability/reliability of that filesystem, though, since it still seems to be under heavy development.