Bug 242294 - mount-points in /etc/fstab are created out of order in ks install
Summary: mount-points in /etc/fstab are created out of order in ks install
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 7
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Chris Lumens
QA Contact:
URL:
Whiteboard:
: 244118 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-06-03 01:15 UTC by Alexandre Oliva
Modified: 2007-11-30 22:12 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2007-06-29 18:58:20 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Test for fsset sorting problem. (12.98 KB, text/plain)
2007-06-27 00:52 UTC, Jeffrey Hutzelman
no flags Details
patch for fsset sorting problem (915 bytes, patch)
2007-06-27 00:54 UTC, Jeffrey Hutzelman
no flags Details | Diff

Description Alexandre Oliva 2007-06-03 01:15:06 UTC
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.

Comment 1 Chris Lumens 2007-06-14 13:45:58 UTC
*** Bug 244118 has been marked as a duplicate of this bug. ***

Comment 2 Chris Lumens 2007-06-14 18:53:57 UTC
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.

Comment 3 Jeffrey Hutzelman 2007-06-27 00:52:40 UTC
Created attachment 157973 [details]
Test for fsset sorting problem.

Comment 4 Jeffrey Hutzelman 2007-06-27 00:53:25 UTC
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.

Comment 5 Jeffrey Hutzelman 2007-06-27 00:54:00 UTC
Created attachment 157974 [details]
patch for fsset sorting problem

Comment 6 Ignacio Vazquez-Abrams 2007-06-27 00:56:24 UTC
Actually, one of the lines in your "Good" set is incorrect. Viz. the following:

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

Comment 7 Jeffrey Hutzelman 2007-06-27 01:46:58 UTC
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.


Comment 8 Chris Lumens 2007-06-29 18:57:20 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.