Red Hat Bugzilla – Bug 445786
swapon can't recognize UUID nor label of PS3 disk
Last modified: 2008-06-03 00:52:48 EDT
Description of problem: The swapon command can't recognize UUID nor label of PLAYSTATION 3 disk (/dev/ps3d*), so swap space on PS3 disk is unavailable. Version-Release number of selected component (if applicable): util-linux-ng-2.13.1-6.fc9.ppc How reproducible: Every time. Steps to Reproduce: 1. make a swap partition on PS3 disk with UUID or label. 2. try to enable the swap by using swapon with -U or -L option. Actual results: [root@localhost ~]# mkswap -L ps3-swap -U 22ea645c-4784-44a0-a954-5f2dd1e34525 /dev/ps3da2 Setting up swapspace version 1, size = 1077506 kB LABEL=ps3-swap, UUID=22ea645c-4784-44a0-a954-5f2dd1e34525 [root@localhost ~]# swapon -U 22ea645c-4784-44a0-a954-5f2dd1e34525 swapon: cannot find the device for 22ea645c-4784-44a0-a954-5f2dd1e34525 [root@localhost ~]# swapon -L ps3-swap swapon: cannot find the device for ps3-swap Expected results: The swap is enabled. Additional info: If the device name is passed to the swapon command directly, the swap is enabled. [root@localhost ~]# swapon /dev/ps3da2 [root@localhost ~]# free total used free shared buffers cached Mem: 202112 144884 57228 0 7648 73112 -/+ buffers/cache: 64124 137988 Swap: 1052248 0 1052248
Please, I'd like to see outputs from: # /sbin/blkid and # /sbin/blkid /dev/ps3da2 and # cat /proc/partitions I guess the partition is invisible for libblkid...
Agreed, please provide blkid output - attaching a dd of the first page-sized chunk of /dev/ps3da2 would also be useful I think. Thanks, -Eric
Oh perhaps an strace of "blkid -c /dev/null" too to be sure it's even scanning the device (it should be).
[root@localhost ~]# /sbin/blkid /dev/ps3da1: LABEL="/" UUID="a00e88ac-942e-4da6-84d1-a9e2de6ee0a7" SEC_TYPE="ext2" TYPE="ext3" [root@localhost ~]# /sbin/blkid /dev/ps3da2 (no output) [root@localhost ~]# cat /proc/partitions major minor #blocks name 1 0 16384 ram0 1 1 16384 ram1 1 2 16384 ram2 1 3 16384 ram3 1 4 16384 ram4 1 5 16384 ram5 1 6 16384 ram6 1 7 16384 ram7 1 8 16384 ram8 1 9 16384 ram9 1 10 16384 ram10 1 11 16384 ram11 1 12 16384 ram12 1 13 16384 ram13 1 14 16384 ram14 1 15 16384 ram15 253 0 46022204 ps3da 253 1 44965903 ps3da1 253 2 1052257 ps3da2
Created attachment 305074 [details] first page of swap partition output of "dd if=/dev/ps3da2 of=output bs=4096 count=1"
Created attachment 305075 [details] strace blkid -c /dev/null
Thanks. So, from the attachment in comment #6, blkid is opening the device: open("/dev/ps3da2", O_RDONLY) = 5 but from comment #4, blkid is not able to recognize the swap device. I'll look at the provided data from the swapfile to see why. Thanks, -Eric
I found that PS3 couldn't find swap partitions on '/dev/sd*' (USB storage), too. It looks like that this problem is not specific to '/dev/ps3d*'.
Ok, this is unfortunately due to a recent change I put in to sanity-check swapspace; it's in F9 too. :( http://git.kernel.org/?p=fs/ext2/e2fsprogs.git;a=commitdiff;h=6360d129d003f25942f62fab2cdc5e1d97cc88a6 + /* check for wrong version or zeroed pagecount, for sanity */ + if (!memcmp(id->bim_magic, "SWAPSPACE2", id->bim_len) && + (blkid_le32(sws->sws_version) != 1 || + sws->sws_lastpage == 0)) + return 1; but it looks like the sws_version is in native-host order and should not be byteswapped... I can fix this in rawhide and push it out for an F9 update but unfortunately it will be in F9-GA, I think.
(In reply to comment #9) > but it looks like the sws_version is in native-host order and should not be > byteswapped... So it is a generic problem for big-endian hosts? > I can fix this in rawhide and push it out for an F9 update but unfortunately it > will be in F9-GA, I think. I see. I'll wait for F9 update.
Yep, it's generic. I'm sorry about that, it was a fairly last-minute F9 change that obviously wasn't tested well enough.
(In reply to comment #9) I applied this fix, i.e. I changed blkid_le32(sws->sws_version) to sws->sws_version, and it worked correctly. (though 'make check' failed because the 'lib/blkid/tests/swap1.img.bz2' was a little-endian image...)
e2fsprogs-1.40.8-3.fc9 has been submitted as an update for Fedora 9
(In reply to comment #13) It works. Thanks.
e2fsprogs-1.40.8-3.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update e2fsprogs'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-3675
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
e2fsprogs-1.40.8-3.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.