From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 Galeon/1.3.14 Description of problem: Sometimes on "shutdown -h now", the kernel will attempt to unmount the root file system, but the operation will not be successful. The failure will be reported as "mount: / is busy" or something similar (nothing in logs, unfortunately, only what I could see briefly on the screen). On the next boot ext3 file system finds that root is not clean and recovers the journal (BTW, ext3 is in default data mode here: ordered). Usually a few orphaned inodes get whacked in the process. I have observed this on my HP Pavillion ZE4201 notebook with ACPI turned on (this notebook doesn't support APM at all). Didn't see this kind of stuff on another desktop system that also has FC2 on it (ACPI mode too). This behaviour was in FC2T3 as well. Version-Release number of selected component (if applicable): kernel-2.6.5-1.358 How reproducible: Sometimes Steps to Reproduce: 1. Shut down the system. 2. Just before halt, kernel reports that "/ is busy" 3. Boot, ext3 will recover the journal and usually clean a few things up. Actual Results: Root file system is not cleanly unmounted. Expected Results: Root file system should unmounted cleanly. Additional info:
The same thing usually, but not always, happens to me shortly after a call trace related to stopping iptables (see my message in bug #123501). I had assumed it was triggered by the iptables problem. Maybe not. Do you get the call trace?
For comment #1 it is because of the previous oops.
I can see this on two more machines. ACPI doesn't seem to matter (one of the machines is K6 350MHz, no ACPI). Just FYI.
This bug is there since FC2-test2 and I wondered that only I have this condition of busy / when rebooting/shutdown I have not always a busy / so I try to rethink what I have done on my system (manual mounting other partitions/shares or manual modprobe modules) so this could be happen. Hope we find a solution soon, because I want to install Fedora on some friend's pc's. It's all in all a great distro
I have the same problem. This doesn't happen the first time I reboot after installation (after setting up modem, etc.) but does the time after that. The same thing happened with FC1 unless I let it run overnight the first time (presumably to finish cron jobs, finish setup, etc.) but it occurs in FC2 even if I leave the machine switched on to complete these operations. I get the same thing whether using ext3 or reiserfs. Let me know if there's something useful I can send in. Newbie so not sure what might be useful, but happy to provide more info.
I had same problem with RHEL 3 ES. I thought it's related to Intel ICH5R but eventually it was mgetty failing for some reason. There was a message like "pid 4590 (id S0) failed" but I overlooked it. So that might be a clue for solving your problems.
Even with very recent kernels (e.g. kernel-2.6.8-1.624), I'm seeing that sometimes after a clean shutdown the ext3 finds problems that need to be fixed. Usually all is fine, but on occasion a couple of inodes will be cleaned up by the journaling code. Still not sure why...
I've since repartitioned the machine to have separate /home and /var. Haven't seen one of those since, so I'll close this bug for now.