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:
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] blkid.tab file
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 <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.. :)
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.