Red Hat Bugzilla – Bug 196179
/etc/rc.d/rc.sysinit swapon error 'Device or resource busy'
Last modified: 2014-03-16 23:00:16 EDT
Description of problem:
The following section of code (apparently added as part of #127378) in
rc.sysinit throws multiple errors:
# Start up swapping.
swappartitions=`blkid -t TYPE=swap -o device`
if [ x"$swappartitions" != x ]; then
action $"Enabling local swap partitions: " swapon $swappartitions
action $"Enabling /etc/fstab swaps: " swapon -a -e
Problem 1: On my machine, swap is on an LVM. As a result, the blkid command
returns the list:
# blkid -t TYPE=swap -o device
which happen to be names for the same device. So we blindly do a swapon for
both, and get a 'swapon: /dev/rootvg/swap: Device or resource busy' error (quite
rightly, because dm-12 was already swapon'ed). This one is likely going to bite
everybody who has a swap on an LVM....
Problem 2: /etc/fstab has a line:
/dev/rootvg/swap swap swap sw 0 0
which triggers *another* 'Device busy' error when we do the second swapon. This
one will bite a *lot* of people who have one swap area that's listed in fstab,
as the 'if' block will probably swapon it, and then swapon -a again. And
sysadmins will be confused by the "workaround" of listing the swap area as
'noauto' when they want it auto-swapon'ed at boot....
Version-Release number of selected component (if applicable):
Define a swap area and reboot to replicate the second one. Place it on an LVM
volume to replicate both....
Steps to Reproduce:
I'm not sure, but my bug #196377 is maybe a duplicate of this one. At least I
get the same result without using LVM.
*** Bug 192127 has been marked as a duplicate of this bug. ***
Re: Comment #1 - You'll get one complaint from swapon for the LVM case (because
blkid will list the same partition twice, so we swapon twice. You are probably
just seeing the *second* complaint from swapon, caused by the swap partition
being listed in /etc/fstab (which the vast majority of users with swap will have).
Please attach /etc/blkid/blkid.tab.
Created attachment 131713 [details]
Impressive. If you move that out of the way and recreate it with blkid from
e2fsprogs-1.38-15 or later, does it contain /dev/dm-X entries?
No, current blkid recreates it with just /dev/mapper entries. Looks like I got
bit by this:
* Tue Jun 13 2006 Bill Nottingham <firstname.lastname@example.org> - 1.38-15
- prevent libblkid returning /dev/dm-X
for the one swapon error. I'm willing to close *that* part out as "not a bug"
if the libblkid that did that never shipped in an FC release or the FC-updates
stream - if it was a -devel only thing, people can be expected to have to clean
up damage caused by buggy versions.
That still leaves the fact that a lot of people have swap listed in /etc/fstab,
which *is* going to be interesting.. :)
I can confirm that regenerating /etc/blkid/blkid.tab and removing the swap
entries from /etc/fstab fixes this for me.
On the other hand, forcing sysadmins to manually remove entries from /etc/fstab
isn't a real "fix", it's a workaround. And blindly removing entries isn't right
either - some sysadmins list every partition in /etc/fstab because it's how they
keep track of which ones aren't allocated yet. So if we nuke /dev/hda5 because
it's swap, they may look and say "Oh, not used..." and Bad Things happen...
Oh, I agree, we want to fix the conflict with /etc/fstab - I just want to make
sure the dm-X stuff in blkid.tab is fixed *first*.
Removing entries from /etc/fstab does not prevent blkid from listing them.
Obviously it reads from /proc/partitions or something. Editing
/etc/blkid/blkid.tab is ineffective, it gets regenerated every time.
If this bug tracks issues with DM vs. blkid, do I need a new bug open for
the swapping on partitions not listed in fstab?
It's tracking both. :)
(In reply to comment #8)
> I can confirm that regenerating /etc/blkid/blkid.tab and removing the swap
> entries from /etc/fstab fixes this for me.
Erm, correction fixed this for me, for some reason something regenerated
/etc/blkid/blkid.tab again and the dm-0 etc lines are back!
*** Bug 198589 has been marked as a duplicate of this bug. ***
*** Bug 199612 has been marked as a duplicate of this bug. ***
Fixed in 8.36-1. You now set AUTOSWAP=yes in /etc/sysconfig/init to do it, and
the errors on duplicate device bringup are gone.