Bug 242294

*** Bug 244118 has been marked as a duplicate of this bug. ***

Unable to reproduce this on a ppc kickstart install, and various things are
preventing me from testing i386 installs (can't get an address via dhcp on F-7,
stage2.img isn't being produced on rawhide).  I'll look at this more once we can
sort those issues out.

Created attachment 157973 [details]
Test for fsset sorting problem.

I think I see what's going on here.  FileSystemSet.add attempts to keep entries
sorted, taking correct mount order into account.  However, the "comesAfter"
function incorrectly reports that A comes after B if B has no mountpoint or
device.  Entries with no mountpoint are added always added at the end of the
list, so once such an entry is added, all further entries will be added after it
rather than as early as possible, which is what is required for the sorting to work.

This is particularly tricky to analyze after the fact because entries with no
mount points correspond to things like PVs and volume groups, which don't show
up in /etc/fstab or in the log output quoted.

I have attached a self-contained test case based on a stripped-down copy of
fsset.py, which can be run outside of anaconda.  This illustrates the problem
based on an actual set of partition requests originally produced by a call to
autopart.autoCreateLVMPartitionRequests.  It's unclear to me how they ended up
getting sorted in the order shown, but it does illustrate the problem.  Output
looks something like this:

Bad:
/dev/VolGroup00/LogVol00 /                       ext3    defaults        1 1
/dev/VolGroup00/LogVol03 /var/cache/openafs      ext2    defaults        1 2
/dev/sda1               /boot                   ext3    defaults        1 2
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
/dev/VolGroup00/LogVol04 swap                    swap    defaults        0 0
/dev/VolGroup00/LogVol02 /var                    ext3    defaults        1 2
/dev/VolGroup00/LogVol01 /usr0                   ext3    defaults        1 2

Good:
/dev/VolGroup00/LogVol00 /                       ext3    defaults        1 1
/dev/VolGroup00/LogVol02 /var                    ext3    defaults        1 2
/dev/VolGroup00/LogVol01 /usr0                   ext3    defaults        1 2
/dev/VolGroup00/LogVol03 /var/cache/openafs      ext2    defaults        1 2
/dev/sda1               /boot                   ext3    defaults        1 2
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
/dev/VolGroup00/LogVol04 swap                    swap    defaults        0 0


Also attached is a patch against anaconda 11.2.0.66 which appears to correct the
problem.

Created attachment 157974 [details]
patch for fsset sorting problem

Actually, one of the lines in your "Good" set is incorrect. Viz. the following:

/dev/VolGroup00/LogVol03 /var/cache/openafs      ext2    defaults        1 3

No; '2' is correct.  That number has nothing to do with the order in which
things are mounted; it controls which filesystems are processed in which fsck
pass.  An administrator with knowledge of the size and tuning parameters of each
filesystem, disk types and speed, system I/O bandwidth, etc. might choose to run
additional passes in an attempt to optimize, but that's a fairly advanced
technique not heavily used in the last decade or two.  Anaconda currently puts
all filesystems except the root in pass 2.

The one thing I was worried about here was bind mounts, but I think your patch
preserves those too.  Thanks for the debugging and development work.  This will
be fixed in the next build of anaconda.