When my system reaches the "Activating (possibly) more swap" section, swapon -a fails and reports "swapon /dev/hda2: device or rescource busy". This swapspace was previously mounted and according to the man page for swapon: -a All devices marked as ``swap'' swap devices in /etc/fstab are made available. Devices that are already running as swap are silently skipped. If this swapspace was already mounted, it should have ignored it.
I have the same problem after emerging baselayout-1.11.4
i noticed this while using devfs, but not udev ... do you guys use devfs ? if so, do you have it set to automount at boot ?
I have udev installed. sys-fs/udev Latest version available: 030 Latest version installed: 030 Size of downloaded files: 374 kB Homepage: http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ Description: Linux dynamic and persistent device naming support (aka userspace devfs) License: GPL-2 I emerged it a few months ago, I don't think anything else was required. here is my fstab: /dev/hda1 /boot ext2 noauto,noatime 1 1 /dev/hda3 / ext3 noatime 0 0 /dev/hda2 none swap sw 0 0 /dev/cdroms/cdrom0 /mnt/cdrw auto noauto,user 0 0 /dev/cdroms/cdrom1 /mnt/cdrom auto noauto,ro,user 0 0 /dev/fd0 /mnt/floppy auto noauto,user,sync,rw 0 0 none /proc proc defaults 0 0 none /dev/shm tmpfs defaults 0 0
what does `cat /proc/swaps` show on your systems ? when i have this problem, it's using the stupid extended naming convention: root@phear 0 mount # grep swap /etc/fstab /dev/hda2 none swap sw 0 0 root@phear 0 mount # cat /proc/swaps | grep ^/ /dev/ide/host0/bus0/target0/lun0/part2 partition 128512 0 -1 root@phear 0 mount # swapon -a swapon: /dev/hda2: Device or resource busy
Output of cat /proc/swaps: Filename Type Size Used Priority /dev/ide/host0/bus0/target0/lun0/part2 partition 506036 4304 -1 At first I thought the problem was only at bootup, but it happens now as well. This bug was not present in the previous 3 versions of baselayout.
hmm, actually the behavior hasnt changed, it's always been wrong when using devfs what i *did* change is that localmount doesnt pipe the error to /dev/null anymore so, the question is, should we just ignore it and continue piping the error to /dev/null, or should we perhaps patch util-linux's swapon to be a little smarter ? for example, if you boot with 1.10.4, you wont see the error, but if you login and run `swapon -a`, you'll see the error
Refer to Bug 39834 for what prompted the removal of the /dev/null piping
Well I suppose it would be better to make swapon skip drives that are already mounted. This would make it conform to what it says it will do based from the explanation of the "-a" flag from the man page, as this is far from silent. Some people on the forums set up a workaround that called swapoff -a and then swapon -a but that is not really a solution.
the 'workaround' they really should utilize is just run `swapon -a >& /dev/null` after all, that's what happened in 1.10.x and earlier :) for swapon to work correctly, we just have to have swapon follow symlinks before trying to enable the swap
I'm one of the members of the forums that is affected by this "bug". My question is this: Whether or not this "device or resource busy" message appears, is the swap file actually mounted and being used? Here is the output of 'cat /proc/swaps' which leads me to believe that the swap partion is mounted and is being used: <code> enterprise ~ # cat /proc/swaps Filename Type Size Used Priority/dev/ide/host0/bus0/target0/lun0/part4 partition 1050832 0 -1 </code> I hope this output helps you diagnose the issue. Kevin
Created attachment 42771 [details, diff] util-linux-2.12b-stat-swap-fallback.patch here's a patch for util-linux's swapon for you people who dont mind rebooting, please test this out ... seems to work fine for me
So what is the preferred solution to this? Is it to switch from devfs to udev? To downgrade to a past version of baselayout? To apply this patch? (If so, how?) I'm getting a simultaneous problem with cdrecord: "Cannot allocate memory. Cannot get SCSI I/O buffer." I can only think that this is related? Sorry to get a bit tangential, but if this is devfs or baselayout's problem, then I think this could be related.
util-linux-2.12b-r1 resolves this
This is back with util-linux-2.12p.
works fine for me: root@vapier 1 dev # cat /proc/swaps Filename Type Size Used Priority /dev/hdd2 partition 1068316 452048 -1 root@vapier 1 dev # grep swap /etc/fstab /dev/SWAP none swap sw 0 0 #/dev/hdd2 none swap sw 0 0 root@vapier 1 dev # ls -l SWAP hdd2 lrwxrwxrwx 1 root root 4 Jan 11 23:22 SWAP -> hdd2 brw-rw---- 1 root disk 22, 66 Jan 4 20:31 hdd2 root@vapier 1 dev # swapon -a root@vapier 1 dev # swapon -a root@vapier 1 dev # swapon --version swapon: mount-2.12p
# cat /proc/swaps Filename Type Size Used Priority /dev/ide/host0/bus0/target0/lun0/part5 partition 530104 0 -1 # grep swap /etc/fstab /dev/hda5 none swap sw 0 0 # ls -l SWAP hda5 ls: SWAP: No such file or directory lr-xr-xr-x 1 root root 33 Jan 11 18:24 hda5 -> ide/host0/bus0/target0/lun0/part5 # swapon -a swapon: /dev/hda5: Device or resource busy # swapon --version swapon: mount-2.12p
Same here with "util-linux-2.12p" and devfs... Marco
NOT AGAIN!!!!! I have the same problem.
For those of you how don't like to patch swapon, you can easily fix the problem by helping swapon a little bit. It currently doesn't follow simlinks, so if you just change your /etc/fstab to use the simlinked device, swapon works correctly. I've tested this, changed "/dev/hda2 none swap sw 0 0" to "/dev/ide/host0/bus0/target0/lun0/part2 none swap sw 0 0" and localmount did not return any errors. I know this is not the croeect solution, but it works until baselayout has been fixed (possibly by the submitted patch above)
you dont understand i wrote the aforementioned patch and it's part of util-linux-2.12p however, i'm not able to reproduce this with devfs or udev so someone will probably have to investigate what's going on
hmm, strange, i have util-linux-2.12p installed, but just discovered the problem. And is still think it's the same problem (swapon not following symlinks). I did not check whether you patch is in 2.12p, but this is what happens on my system (using devfs): philippe ~ # swapoff -a philippe ~ # cat /proc/swaps philippe ~ # swapon /dev/hda2 philippe ~ # cat /proc/swaps Filename Type Size Used Priority /dev/ide/host0/bus0/target0/lun0/part2 partition 1052248 0 -3 philippe ~ # swapon -a swapon: /dev/hda2: Device or resource busy [changing /etc/fstab so my swap-partion is listed as /dev/ide/host0/bus0/target0/lun0/part2 instead of /dev/hda2] philippe ~ # swapon -a philippe ~ # swapon --version swapon: mount-2.12p
I don't know about everyone else, but while I do have udev emerged, I didn't take it all the way, replacing /dev and all that. I wonder what could have changed to make this pop back up again. I didn't try the symlink solution, but it looks like it is the issue, symlinks. I noticed that with gnome-system-monitor that it displays the actual device instead of the symlink now ie ide/host0/bus0/target0/lun0/disc instead of /dev/hd), which is weird.
Re: comment #22 - if you emerged the updated util-linux when it was first added one of the patches wasn't applyed causing df and mount to report the full path. see bug #77622. That's probably the cause of the system-monitor showing the path differently. I have no traces of udev on my system.
Re: comment #23 Thank You. I remerged util-linux and it fixed up system monitor. I am glad I mentioned it. Of course, I had to reboot first..... swapon: /dev/hda2: Device or resource busy Can't we just set the start up script to send error output to /dev/null again?
Ok, I managed to fix the problem I was having. Long story short, its time to migrate to udev. http://www.gentoo.org/doc/en/udev-guide.xml It cleard up all of the miscellaneous error messages about things not unlinking. The trouble was that I had udev emerged, but I still had devfs support enabled and set to mount automatically in the kernel. I deceded to keep the gentoo optimizations, and after a reboot, all is fine again. So if you do this, swapon -a will report no errors, no workarounds needed.
swapon will not be piped into /dev/null again, dont ask for it
Heh Heh Heh. Well, its fine with me now, I don't know about anyone else. Doing what I said cleared my issue right up. Now to figure a way to get me off the notify list.
Why is this marked as "Resolved fixed"? Could anybody explain this to me?
This is because this bug was fixed once already. SpanKY already patched swapon to resolve this error. The bug is due to some other cause, and he is unable to duplicate the bug himself in order repair it. It resurfaced for me as well, but if you read comment #25, I was able to resolve the error on my computer. I have also since disabled the gentoo device tarball, and I am running 100% on udev. Besides, its the gentoo default now I believe. Don't worry, udev is far enough along that you should not see any problems. I know some people have issues with devices being identified wrong, but I haven't personally seen this. Good Luck.
This is _not fixed_ because the patch to util-linux-2.12.p is IMHO wrong. Compare the patches from 2.12i and 2.12p and you'll see that the former does the extended symlink/device match via the st_dev attribute whereas the latter (broken) p-patch uses st_rdev which will always be different for partitions (and therefore swapon -a will always fail). Changing line 27 in the p-patch to compare st_dev makes the error go away for me and does not seem to cause any regressions with either partitions or additional swapfiles.
although the patches differ in the way you say, your analysis is incorrect st_dev refers to the device the file resides *on* st_rdev refers to the device that the file *represents* the bug here is that i lstat() the symlink to see if it is a symlink, but i don't stat() the node that the symlink points to ... thus the stat buffer refers to the symlink still and the comparision will always be false the correct fix here is to stat() the file the symlink points to after we establish that the file stored in /proc/swaps is indeed a symlink this will be fixed in 2.12p-r1 and/or 2.12q
