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

Reply via email to