I tried to post this to Problems & Suggestions but that forum appears to be closed to non-moderators (and there aren't any moderators )

My impression of the upgrade procedure KnoppMyth uses is that it mounts hda1 and hda4 and copies "stuff" to be saved to /myth/backup on hda4. hda1 is wiped and recreated from the CD. Then data from /myth/backup on hda4 is copied back to hda1. I hope that the copy back occurs while still booted from the CD and not after rebooting from hda1.

If this could be changed to use /cache on hda3, which should be big enough, I think it would make it much easier for those of us setting up LVM based systems. The contents of /cache can be wiped out to create the necessary space. If there are directory structure changes that the upgrade needs to make in /myth, they can be done after the system reboots (and the LVM is mounted as /myth) as a post-upgrade procedure. It should test to see whether they are required as if a slave backend (see below) has /myth mounted off a master, the changes have probably already been done.

The underlying problem relates to the limit of 4 logical partitions. In order to create the LVM space on hda, one of the 4 logical partitions has to be an LVM.

I've solved this (I hope) by moving swap from hda to hdf. This frees hda2 to be my LVM space and I leave hda4 as a small (3GB) partition set up the way KnoppMyth left it. This is not mounted in my fstab.

I'm not sure if this is an issue for slave backend systems as well or not. I suspect it isn't because /etc/fstab is probably ignored during an upgrade. For slave backend systems the issue is that they work best if the master's /myth is mounted on the slave as /myth. I have my fstab configured to mount /dev/hda4 as /localmyth. I left the structure that KnoppMyth layed down alone.