Hide Forgot
Description of problem: Here's what I have in my kickstart install of F7 x86_64: clearpart --none volgroup all --noformat logvol swap --useexisting --fstype swap --name=swap --vgname=all part swap --onpart sda2 logvol / --useexisting --fstype ext3 --name=test --vgname=all --fsoptions="noatime" logvol /l --noformat --fstype ext3 --name=l --vgname=all --fsoptions="noatime" logvol /l/root --noformat --fstype ext3 --name=stable --vgname=all --fsoptions="noatime" part /boot --fstype ext3 --onpart sda6 --fsoptions="noatime" part /l/root/boot --noformat --fstype ext3 --onpart sda5 --fsoptions="noatime" After installation, /l/root and /l/root/boot are listed before /l in /etc/fstab. And the kickstart %post script is run with /l mounted on top of /l/root and /l/root/boot, hiding the precious info that the %post script relied on in /l/root/boot. Oops. I *think* I had the same problem testing F7T4, but I fixed /etc/fstab and moved on, failing to report it. Sorry.
*** 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.