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 instructions. Version-Release number of selected component (if applicable): 4.1.18-2 How reproducible: 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 Actual results: Extra /sys mounted when looking in /proc/mounts Expected results: Only one /sys mounted.
Extra information can be found at: http://www.bughost.org/bugzilla/show_bug.cgi?id=464
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] Example initrd
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. Sorry.