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.
Installing to a non-encrypted device still shows this behavior.
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
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? Thanks, -Eric
oh, and which kernel got installed....
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.
I tried, under the 0.133 kernel... mke2fs /dev/sdb8 -j tune2fs -c0 -i0 -Odir_index -ouser_xattr,acl /dev/sdb8 mount copy stuff unmount fsck and it found no errors... but, that wasn't a reboot; maybe there is a flushing or unmounting issue when the install reboots?
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.
Seems quite similar to Debian bug 454926 - comment #10 is especially interesting. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=454926#10
ugh, that doesn't sound too great. Let me look into this...
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....
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?
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
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.
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.
I can also confirm the same problem.
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.
e2fsprogs-1.40.4-5 should have a fix. Can someone verify? I'll try in a bit if nobody beats me to it.
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.
Fixed in e2fsprogs-1.40.4-7.fc9