Bug 196179 - /etc/rc.d/rc.sysinit swapon error 'Device or resource busy'
Summary: /etc/rc.d/rc.sysinit swapon error 'Device or resource busy'
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: initscripts
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Brock Organ
URL:
Whiteboard:
: 192127 198589 199612 (view as bug list)
Depends On:
Blocks: 199612
TreeView+ depends on / blocked
 
Reported: 2006-06-21 19:35 UTC by Valdis Kletnieks
Modified: 2014-03-17 03:00 UTC (History)
10 users (show)

Fixed In Version: 8.36-1
Clone Of:
Environment:
Last Closed: 2006-07-21 18:46:08 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
blkid.tab file (2.62 KB, application/octet-stream)
2006-06-29 04:54 UTC, Valdis Kletnieks
no flags Details

Description Valdis Kletnieks 2006-06-21 19:35:00 UTC
Description of problem:
The following section of code (apparently added as part of #127378) in
rc.sysinit throws multiple errors:

# Start up swapping.
update_boot_stage RCswap
swappartitions=`blkid -t TYPE=swap -o device`
if [ x"$swappartitions" != x ]; then
        action $"Enabling local swap partitions: " swapon $swappartitions
fi
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
/dev/dm-12
/dev/rootvg/swap

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):
initscripts-8.35-1

How reproducible:
Define a swap area and reboot to replicate the second one.  Place it on an LVM
volume to replicate both....

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Robert Scheck 2006-06-26 00:34:48 UTC
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.

Comment 2 Peter Jones 2006-06-28 15:17:26 UTC
*** Bug 192127 has been marked as a duplicate of this bug. ***

Comment 3 Valdis Kletnieks 2006-06-28 15:31:29 UTC
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).

Comment 4 Bill Nottingham 2006-06-29 04:23:42 UTC
Please attach /etc/blkid/blkid.tab.

Comment 5 Valdis Kletnieks 2006-06-29 04:54:54 UTC
Created attachment 131713 [details]
blkid.tab file

Comment 6 Bill Nottingham 2006-06-29 05:06:12 UTC
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?

Comment 7 Valdis Kletnieks 2006-06-29 05:35:06 UTC
No, current blkid recreates it with just /dev/mapper entries.  Looks like I got
bit by this:

* Tue Jun 13 2006 Bill Nottingham <notting> - 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.. :)

Comment 8 Hans de Goede 2006-06-29 12:34:08 UTC
I can confirm that regenerating /etc/blkid/blkid.tab and removing the swap
entries from /etc/fstab fixes this for me.


Comment 9 Valdis Kletnieks 2006-06-29 12:46:47 UTC
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...

Comment 10 Bill Nottingham 2006-06-29 16:50:43 UTC
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*.

Comment 11 Pete Zaitcev 2006-07-07 02:29:49 UTC
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?


Comment 12 Bill Nottingham 2006-07-07 02:32:31 UTC
It's tracking both. :)

Comment 13 Hans de Goede 2006-07-07 06:06:35 UTC
(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!



Comment 14 Dave Jones 2006-07-16 01:19:47 UTC
*** Bug 198589 has been marked as a duplicate of this bug. ***

Comment 15 Jay Turner 2006-07-20 19:09:40 UTC
*** Bug 199612 has been marked as a duplicate of this bug. ***

Comment 16 Bill Nottingham 2006-07-21 18:46:08 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.