LVPM

Summary

Following the installation of Ubuntu onto a loopmounted partition, utilities to manage the loopmounted partitions to accomplish tasks such as resizing and transferring them to dedicated partitions should be provided or be easily accessible to users. LVPM provides some of these features for installations generated by Wubi.

Rationale

The loopmounted-install approach generated by Wubi is clearly not a viable long-term solution. It has problems, including, but not limited to:

  • Reduced hard drive performance, due to the overhead of using 2 filesystems; a loopmounted ext3 partition is used within an NTFS filesystem.
  • Increased risks of filesystem corruption and data loss if the host filesystem is not unmounted properly.
  • Lack of support for hibernation and suspend due to the usage of FUSE and file-based swap.
  • Potential conflicts with various boot scripts and mechanisms that are not compatible with loopmounted root filesystems.

  • Potentially vulnerable to Windows malware, since the bootloader mechanism GRUB4DOS and the disk images reside as normal files on the Windows filesystem, and are thus easier for malware to target than seperate partitions. [An attacker gaining admin rights in Windows might just as well erase separate partitions altogether, as far as security goes, the main difference is that swapping kernel/initrd in a Wubi installation does not require ext2 drivers, but that would make little difference if an attacker was to aim specifically at Linux installations via Windows. Hence I do not think that loopinstallations are inherently less secure than standard dual boot installations - Ago]

    • - All modern antivirus, antispyware, and security software, and even newer Windows versions' built-in security features protect against any partition-deletion based attacks or anything else that changes the partition table or MBR. Partition or MBR-based attacks haven't succeeded in spreading on a major scale in much of the last decade. Simple file-deletion or modification, however, is not protected against nearly as well, and thus, file are much more vulnerable to deletion or modification than partitions.
  • Keeps the Ubuntu install dependent on both the Windows bootloader and NTFS partition; should the Windows bootloader fail, Ubuntu will be unable to boot even if the install is intact, and the user will also be unable to remove their Windows partition without deleting their loopmounted install, thus preventing full migration to Ubuntu.
  • More issues that haven't yet been discovered, but will likely be exposed as future technology and more widespread usage of loopmounted-installs emerge throughout the 3 years of the Ubuntu 8.04 LTS release support cycle.

However, should users be unable, for some reason, to migrate their loopmounted install to a dedicated partition, it should also be possible for them to resize/expand their loopmounted partitions using the tool.

Use Cases

Anna is satisfied with running Ubuntu after using it on a loopmounted installation, and wants to switch to using entirely Ubuntu, but wouldn't like to backup and reinstall her existing Ubuntu install just to be able to remove Windows. She instead uses LVPM to transfer her install to a dedicated partition, and is then able to remove Windows and run Ubuntu exclusively afterwards.

Ben has run out of hard drive space on his loopmounted Ubuntu install. However, he is already using all 4 primary partitions on his hard drive, so he can't switch to a dedicated-partition install. Instead, he uses LVPM to expand the size of his disk image, and is able to use the additional space afterwards.

Implementation

Installation

The LVPM (Loopmounted Virtual Partition Manager) tool should be installed when the installer detects that a loopmounted-installation approach is being used. Since the total size is relatively small (a few hundred KB at max), it should be bundled in, and be available in the official repositories (in case of critical updates).

Alternativety, LVPM functionality might be integrated within Ubiquity which already accomplishes several of the tasks now taken care of by LVPM -- Ago.

Visibility

The tool should be clearly visible and accessible to the user, but not to the level of being "nagware". It should be available as an entry in the System -> Administration submenu.

For further visibility, LVPM may perhaps also be included as an icon on the desktop or periodically appear as a reminder in the notification area, triggered by certain conditions such as going below the 5% threshold on free disk space.

Running

Currently, LVPM runs from within the loopmounted install, and uses rsync to duplicate the contents of the loopmounted partitions.

Perhaps it would be safer to copy the necessary files from the existing system into a temporary initrd, and reboot into that environment, run entirely from the RAM, so that there's less chances of data corruption/loss or other failures due to changes within the mounted, running filesystem.

Transferring installs to a dedicated partition

Currently, installations are transferred by formatting the pre-allocated space that had been created earlier, copying the files over using rsync, and removing the loopmouted-booting specific patches and configuration files, to match a standard installation.

Ideally, if the initrd-ramdisk-based approach described in "Running" is used, the resizing can be done by the tool on the spot, by bundling in GParted or a similar partitioning tool into the initrd to be loaded into the ramdisk; thus, no prior action will have to be taken before running the LVPM utility; the partition resizing portion can be handled by LVPM.

The following loopmounted-booting specific patches will have to be changed/removed in the migration to a dedicated partition:

  • Patches contained in the "lupin-support" package will have to be removed.
  • /etc/fstab will have to be updated with the new partitions, UUIDs, and mountpoints.
  • GRUB will have to be installed to the MBR, and /boot/grub/menu.lst will have to be updated to use the standard disk /partition notation.
  • Kernel filesystem sync mount options will have to be reset to their defaults.

Resizing

Currently, LVPM "resizes" loopmounted partitions by creating a new disk image using dd, formatting it, and copying over the contents of the old loopmounted partition using rsync.

Ideally, the resize2fs command (or its equivalent for other filesystems) can be used to resize the loopmounted partition. This would require keeping the filesystem unmounted while undergoing the resize operation to safely commence, which is described in the "Running" section.

Another, more convenient and automated approach, could be done by using LVM pools to form the loopmounted root filesystem, and creating and adding new pools (semi)-automatically when required. However, due to (current) difficulties and obstacles in implementing this solution via d-i, this dynamically-resizing approach is unlikely to be used.

Outstanding Issues

With the emergence of new technologies that provide the same advantages, is there even a need anymore for officially supporting loopmounted-installs?

See InstallerForWindows

CategorySpec

LVPM (last edited 2008-08-06 17:01:10 by localhost)