Red Hat Bugzilla – Bug 139642
mount in a startup complains "already mounted or busy"
Last modified: 2007-11-30 17:10:54 EST
Description of problem: Afer recent rawhide updates I am greeted during a startup with numerous message of that sort: none already mounted or /dev/pts busy /dev/sda10 already mounted or /boot busy .... It turns out that 'mount' changed its behaviour. Before 'mount -a' was not trying to mount already mounted file systems and was just silent. Currently doing 'mount -a' results in something like that: mount: /dev/sda10 already mounted or /boot busy mount: /dev/sda14 already mounted or /home busy mount: /dev/sda13 already mounted or /opt busy mount: /dev/sda12 already mounted or /usr busy This is not really a fault of 'mount' as the current version of 'util-linux' package was installed on 2004/Oct/15, i.e. a month ago. The last series of updates includes a lot of different packages but 'glibc-2.3.3-77' seems to be the most likely candidate to cause that ruckus. Version-Release number of selected component (if applicable): util-linux-2.12a-16 How reproducible: 100%
Further checks reveal is that an actual problem is that an output of 'mount' is "loosing" some file systems. This is independent from a kernel used or from an arch. Replacing /etc/mtab with a symlink to /proc/mounts makes (apart of other potential problems :-) 'mount -a' to compain now in this way: mount: none already mounted or /sys busy mount: according to mtab, /sys is already mounted on /sys but not troubles with anything else. That is because there is the following line in /proc/mounts /sys /sys sysfs rw 0 0 After 'umount /sys; mount -a' all further 'mount -a' are quiet as "/sys" line now is replaced with: none /sys sysfs rw 0 0 OTOH with such hack every "bind" mount gets repeated on each 'mount -a', which is really expected. So the real issue is that for some reasons a content of /etc/mtab gets garbled and nothing seems to add missing entries.
Forgot to add, what should be obvious, that 'df' is also rather unhappy with the current arrangement.
might be related, if you do "cat /proc/mounts > /etc/mtab" and then proceed to mount/umount partitions, everything seems to work ok. This could mean that the problem is in the initscripts.
Created attachment 107029 [details] patch to make 'mount' and 'df' behave better The attached change in rc.sysinit makes only a small mess on my system (a bunch of inconsequential complaints on a shutdown) instead of a serious one when things misbehave while running. To filter /etc/mtab to remove duplicates of thigs like /proc or /sys, as that seem to be responsible for remaining troubles, would not be too hard while using unly tools from /bin and /sbin. 'sort -u -k 3,3 /etc/mtab' gives a crude first approximation. Why such hacks are suddenly needed?
Sounds like the source of the problems is /etc/mtab going wonky. /etc/mtab must stay separate from /proc/mounts, so we need to find the source of the /etc/mtab "corruption".
See long discussione in bug #139656. I believe that this is it.
*** This bug has been marked as a duplicate of 139656 ***