From Bugzilla Helper: User-Agent: Mozilla/5.0 (compatible; Konqueror/3.2; Linux; X11; en_US, en) (KHTML, like Gecko) Description of problem: After upgrading the the new kernel and udev-030-18 and the dev and MAKEDEV 3.11, and mkinitrd-4.1.9 and reboot I get some weird things happening. When I do "df" command the size of the filesystem shows up to be some huge negative number. Both partitions / and /boot show up as being %100 and sometimes %101 percent occupied. System still functions fine. If I run fsck on the filesystems it fixed a lot of inodes and after remounting the sizes are kind of correct...I say kind of because the percent occupation seems to be not exactly what it was but close. I kept the same kernel but went back to old udev, dev, etc. and things seem to be stable for a day. I have MPT fusion U320 scsi disk. I know the new 2.6.9-rc1-bk7 also make a significant jump in the fusion driver. Version-Release number of selected component (if applicable): kernel-2.6-1.541 How reproducible: Always Steps to Reproduce: 1.update to latest rawhide 2.reboot 3.do a df Additional info:
Created attachment 103493 [details] Additional info concerning the odd /boot sizes
Is this a kernel or coreutils issue?
Please supply 'strace' output so we can be sure which package is at fault.
RE: coment #3; I'd be happy to provide one with a little coaching. I've run strace on various programs when run from the command line. What would you suggest as a test; i.e. "strace what?"
Just run 'strace df -h 2>log', for example.
Created attachment 103494 [details] Strace per request from FC1 against FC3T1 shared boot partition
Created attachment 103495 [details] Second strace of "df -h" I didn't see anything in the previous strace which concerned the /boot partition (hda1) so am including this variation.
statfs("/boot", {f_type="EXT2_SUPER_MAGIC", f_bsize=1024, f_blocks=101086, f_bfree=118793, f_bavail=113574, f_files=26104, f_ffree=26030, f_fsid={0, 0}, f_namelen=255, f_frsize=0}) = 0 f_bfree (and f_bavail) > f_blocks Ouch! That seems to conflict with what I expect should be: f_blocks >= f_bfree >= f_bavail Now is indeed the file system corrupted, or is the kernel reporting wrong figures? Could you please attach the output from "dumpe2fs /dev/hda1"?
Created attachment 103496 [details] dump2efs /dev/hda1
Arjan, I am still having these errors with 1.540 !! It is very weird because I can also boot 1.538 and that does not seem consistent either. In particular "df" seems to give radically different answers. I do an fsck on my root filesystem, whcih shows 27% occupation, which I know is close to the true amount. Then I reboot and login to find "df" showing 19%, 20% etc. I even played with coreutils, downgraded it to 5.2.1-17 and it changes the used amount from 18% to 21% but a second later it falls to 20%. Than I go back t0 5.2.1-23 and do a df to see %17. I know you removed the ext3 resize patch from 1.541 in 5.140. Is there another culprit?
If the filesystem is corrupted reversing the kernel will not fix that. All it does is avoiding that more filesystems get corrupted.
In a conversation on the Fedora-Test-List today Stephen Tweedie indicates this problem (odd "df" results) may have been introduced in the .538 kernel which is in line with my logs. http://marc.theaimsgroup.com/?l=fedora-test-list&m=109449522208471&w=2
OK...fsck does fix it temporarily. The odd thing is that I have the same setup on my DELL Inspiron notebook and I am not having any problems there. My office system is a SCSI system. Do you guys have IDE disks?
Mine is an IDE on a Sony VAIO Laptop: Probing IDE interface ide0... hda: TOSHIBA MK6026GAX, ATA DISK drive One of the folks in the conversation I mentioned earlier this evening noted that he had a problem with his /boot partition after editing his /boot/grub/grub.conf file using "vi". I don't recollect a specific instance like that in my own case but it's possible that I did something while running under the .538 kernel to change a file on the /boot partition. I don't know the nature of the bug that may have been introduced in the .538 kernel so it would be hard to tell if SCSI vs IDE is a factor.
Created attachment 103526 [details] A small test showing the .538 kernel has a problem. I posted this to the Fedora-Test-List.
O.K. I rebooted using the FC2 boot CD, ran fsck on all filesystems (many inodes fixed) and then rebooted into 1.540. "df" seems to be reporting correctly now. I removed 1.538 kernel rpm. I am keeping my fingers crossed but 1.538 may be the culprit.
Using .540 will likely cause corruption again. The issue was introduced in .538, not removed in .540. I think Arjan wrongly assumed the issue was introduced in .541, that's why he reverted the kernel in RawHide to .540. I believe you need to use .533 to be safe.
Perhaps....but so far the system is fine with .540 and my laptop that has been on 1.541 and 1.540 never had this problem. It could have been something in the -bkX series that got fixed in the meantime.
I installed 1.549 on both machines and still everything is fine. I always got /boot filesystem messed up when installing a new kernel for the bad kernels. Does this mean this issue is resolved?
Yes. This appears to be an issue with 538 *only*.