Description of problem:
There exists some sort of race condition in the initrd script
generated by mkinitrd. Sometimes umount /sys fails with error EBUSY.
udev probably doesn't close something fast enough. Adding a 'sleep 1'
just before the umount makes the problem go away.
The problem only appears in the specific case outlined in the
Version-Release number of selected component (if applicable):
Almost every time. (~9 out of 10 times)
Steps to Reproduce:
1. Power off laptop
2. Remove AC power
3. Boot up
4. Observe error -16 when trying to umount /sys
Extra /sys mounted when looking in /proc/mounts
Only one /sys mounted.
Extra information can be found at:
Can you attach one of your initrds? I can't see how this would happen
in the usual case and before slowing down bootup, I'd like to try to
figure out what in sysfs is being accessed during the initrd
Created attachment 108914 [details]
Hmmm, have you seen this with anything other than XFS root fs's?
It is only on one machine that this bug causes any kind of problem. So
I don't know if this has appeared on any other machine.
And changing the root fs isn't something I do on a daily basis so the
machine in question has not experienced anything but XFS.
Does this still happen for you in fc4t2?
The problem went away when I changed to ext3 on the machine. I'm no longer able
to replicate the problem so I cannot test if there has been a change for fc4t2.