Bug 428893 - forced fsck and reboot on first boot of newly-installed system
forced fsck and reboot on first boot of newly-installed system
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Eric Sandeen
Fedora Extras Quality Assurance
Depends On:
Blocks: F9Alpha
  Show dependency treegraph
Reported: 2008-01-15 16:40 EST by Will Woods
Modified: 2008-01-28 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version: e2fsprogs-1.40.4-7.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-28 17:10:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Will Woods 2008-01-15 16:40:19 EST
On the first boot of a newly-installed rawhide system (first observed 20080114
or so), when the LVM devices are first loaded, the following message is printed:

  primary superblock features different from backup, check forced.

followed by an e2fsck, which then forces a reboot.

This might be related to the LUKS encryption support - I haven't tested a
non-encrypted install yet. I'm assigning to anaconda based on that hunch. Sorry
I don't have a better one.
Comment 1 Will Woods 2008-01-15 17:08:05 EST
Installing to a non-encrypted device still shows this behavior.
Comment 2 Jeremy Katz 2008-01-16 10:35:49 EST
I noticed this too at one point.  It might be worth trying to just format an
ext3 filesystem with the options used in anaconda and then seeing if the check
is forced on it.

Or Eric might have an idea of what the cause is
Comment 3 Eric Sandeen 2008-01-16 11:47:45 EST
Did the subsequent fsck report any useful info?

Was this mke2fs from e2fsprogs-1.40.4?

Does anything in the install log show exactly which mkfs command was run?


Comment 4 Eric Sandeen 2008-01-16 12:13:13 EST
oh, and which kernel got installed....
Comment 5 Will Woods 2008-01-16 14:50:37 EST
Yes, this appears to be mke2fs 1.40.4. The mkfs command was:

  mke2fs /dev/VolGroup00/LogVol00 -j

so, nothing fancy there. Nothing interesting in its output. It says there are
superblock backups in blocks 8193, 24577, 40961, 57345, and 73729. 

VT5 also shows tune2fs output, but the logs don't show the exact command run.
The output is:

  Setting maximal mount count to -1
  Setting interval between checks to 0 seconds 

That second line seems odd.

Oh, kernel version is 2.6.24-0.155.rc7.git6.fc9.
Comment 6 Eric Sandeen 2008-01-16 17:47:49 EST
I tried, under the 0.133 kernel...

mke2fs /dev/sdb8 -j
tune2fs -c0 -i0 -Odir_index -ouser_xattr,acl /dev/sdb8
copy stuff

and it found no errors... but, that wasn't a reboot; maybe there is a flushing
or unmounting issue when the install reboots?
Comment 7 Will Woods 2008-01-16 19:30:59 EST
This also happens with *upgrades* to rawhide, so it's not mke2fs/tune2fs.

Might be something else in anaconda (maybe related to bootloader config or other
post-package-install tasks).. or it could be some package's %post script.
Comment 8 Will Woods 2008-01-17 17:34:28 EST
Seems quite similar to Debian bug 454926 - comment #10 is especially interesting.

Comment 9 Eric Sandeen 2008-01-17 18:13:28 EST
ugh, that doesn't sound too great.  Let me look into this...

Comment 10 Eric Sandeen 2008-01-18 00:09:10 EST
Ok, this really must have been 1.40.4, the message indicated in the opening
comment didn't show up 'til then (well, 1.40.3, but that was never in built for
rawhide).  But, 1.40.4 has at least the debian-referenced bug fixed (well, the
patch from the bug is in it).  So something else is going on, and I still can't
recreate it outside the installer.  Grr.  If the installer and/or upgrades can
recreate it I'll put something in there to at least say *what* mismatches....

Comment 11 Will Woods 2008-01-21 15:11:07 EST
Checked the output of dumpe2fs at the end of a rawhide install. The major
differences between the primary and backup superblock:

1) Primary superblock has ext_attr and needs_recovery set (and backup doesn't)
2) Backup superblock is marked 'not clean'.

Unfortunately I encrypted the device, so I can't use my F8 LiveCD to check and
see if the needs_recovery flag is cleared at installer shutdown. But assuming
that it is, we still have the ext_attr feature difference, which would still
force the fsck.

So the question is - what sets ext_attr, and why isn't it getting set on the
backup superblock?
Comment 12 Eric Sandeen 2008-01-21 15:36:38 EST
Great, thanks.

ext_attr is set when the first extended attribute gets written - i.e., when
selinux labels the filesystem.

This will reproduce it, with e2fsprogs-1.40.4:

 dd if=/dev/zero of=fsfile bs=1M count=100
 mkfs.ext3 -F fsfile 
 tune2fs -c0 -i0 -ouser_xattr,acl fsfile 
 mount -o loop fsfile mnt/
 touch mnt/file
 setfattr -n user.name -v value mnt/file 
 umount mnt/
 e2fsck -a fsfile 

 fsfile primary superblock features different from backup, check forced.
 fsfile: 12/25688 files (8.3% non-contiguous), 8915/102400 blocks

Comment 13 Will Woods 2008-01-21 18:24:08 EST
Interestingly, it seems that you can set the ext_attr bit by running:

  tune2fs -ouser_xattr $dev

I checked the primary and backup superblocks by doing
  dumpe2fs -h $dev 
  dumpe2fs -ob32768 -oB4096 -h $dev

and found that the only difference in the filesystem feature flags after running
tune2fs was that the primary superblock had "needs_recovery" still set. 

After rebooting, the system *did* notice a difference between the primary and
secondary superblocks and force an fsck, but e2fsck returned a different code
which did *not* force a reboot.
Comment 14 Eric Sandeen 2008-01-22 00:08:19 EST
I didn't expect that -ouser_xattr (default mount option, to allow xattrs to be
created) would set the ext_attr feature flag (which means a file actually exists
with an xattr), and I don't see it:

[root@neon tmp]# mke2fs -F -q fsfile 
[root@neon tmp]# dumpe2fs -h fsfile | grep "features\|options"
dumpe2fs 1.40.4 (31-Dec-2007)
Filesystem features:      resize_inode dir_index filetype sparse_super
Default mount options:    (none)
[root@neon tmp]# tune2fs -ouser_xattr fsfile 
tune2fs 1.40.4 (31-Dec-2007)
[root@neon tmp]# dumpe2fs -h fsfile | grep "features\|options"
dumpe2fs 1.40.4 (31-Dec-2007)
Filesystem features:      resize_inode dir_index filetype sparse_super
Default mount options:    user_xattr

the default mount option gets set, but the feature flags don't change.
Comment 15 John Poelstra 2008-01-22 13:34:25 EST
I can also confirm the same problem.
Comment 16 Will Woods 2008-01-22 13:42:58 EST
Hm. Retested a bit, and you're definitely right. I think the filesystem must
have been unmounted or otherwise synched while I was messing around the first
time, so it looked like the tune2fs set the ext_attr flag. Sorry for the confusion.
Comment 17 Eric Sandeen 2008-01-23 16:37:22 EST
e2fsprogs-1.40.4-5 should have a fix.  Can someone verify?  I'll try in a bit if
nobody beats me to it.
Comment 18 Eric Sandeen 2008-01-27 10:44:22 EST
Ted merged this upstream but without the fix which actually prevents the fsck
due to xattrs.  :(  He's right, though, I think, that the xattr flag difference
can't 100% safely be ignored.  However, forcing a full fsck on xattr flag
differences is still the wrong answer IMHO.

His "long-term" plan is to make mke2fs set the attr flags by default, but that
doesn't help existing filesystems.

Rawhide should be "ok" in terms of avoidingthe fsck, but it's not perfect w.r.t.
flag safety.  Honestly, though, I think it's ok for now, at least 'til I come up
with a palatable fix for existing filesystems.
Comment 19 Jesse Keating 2008-01-28 17:10:07 EST
Fixed in e2fsprogs-1.40.4-7.fc9

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