This isn't an e2fsprogs bug. This is a bug in the Ubuntu installation scripts, in that:
(a) Ubuntu by default greedily tries to pull all partitions that are present in the system in /etc/fstab. (Maybe that isn't a good idea if you don't need a particular partition for a particular multiboot setup... i.e., if /dev/sda1 is your Tribe1 install, and /dev/sda2 is your Tribe2 install, and you are installing /dev/sda3 with Tribe 3, you DON'T want to put /dev/sda1 and /dev/sda2 in Tribe 3's /etc/fstab --- since you don't need multiple system's root filesystems mounted in Tribe3, and at some point you might overwrite your Tribe1 install in /dev/sda1 with Tribe 4, and at that point the /etc/fstab in your Tribe 3 install is totally bogus. On the other hand if /dev/sda4 is your /home directory, then obviously that should be in the Tribe 3 install.) (b) Ubuntu insists on re-running mkswap on each new install, so if you have multiple boot systems all sharing the same swap partition, you don't want to break the other ones by re-running mkswap and blowing away the UUID used for the swap partition, because then you have to update all of the other systems' /etc/fstab files. So yes, multi-boot is a great way to test multiple versions of distros --- I don't argue with that. But the problem is that fsck has no way of knowing whether or not /dev/sda1 was *really* important (i.e., it's an old Tribe1 install, it's OK if the filesystem with uuid FOO is no longer present), or whether it's some critical part of the filesystem where if it is no longer present, bringing up the system would result in a non-functional server, and so it's better to keep the system down and NOT let it to come up all the way. For example, if you have a critical e-commerce server, and you lose the filesystem containing the database, it's better to let your High Availability system let your backup servers take over, than to let a machine which is just going to answer http requests with "help I've fallen and I can't get up responses"; it's considered poor form. :-) One thing I am willing to do is to add support for an fstab mount options field, "non-essential", which will cause fsck to simply skip a filesystem which can't be found. Then on desktop systems, system administrators or Desktop distros could by default mark filesystems as "non-essential" so that systems with missing filesystems can continue coming up. Note that this could be quite confusing even on Desktop system if your /home partition is missing, since users will then log in and not have any home directories, but that transfer the responsibility to whoever is setting up the /etc/fstab file --- it definitively makes it the Distro installer's fault. Also, teaching the non-essential mount option may not be enough, since I suspect it will still cause mount -a to barf, and I believe that will cause the init scripts to bomb out, just later --- so if people really want this, they will probably also have to teach mount to understand the non-essential mount option. But, short of fixing the Ubuntu installer not do dumb things such as greadily including other root filesystems for other Linux installs in /etc/fstab by default, so that things break when you reinstall a newer version of Linux or another distro in a partition referenced by other installs' /etc/fstab, that's about the best I can do. Any comments from the Ubuntu installer folks? -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
