[SOLVED] Two swap entries created in fstab during install and slow boot

[parish]

Just installed Fedora 17 from scratch to a clean disk and have a couple of issues.

During boot, the system hangs for ~15-30 secs after the entry Started Recreate Volatile Files and Directories appears on the console. The system is trying to find a particular uuid:

Timed out waiting for device dev-disk-by\x2duuid-bdb620d8\x2d38d5\x2d4dd3\x2d8ee6\x2d5f4378a6ed58.d evice.
Dependency failed for /dev/disk/by-uuid/bdb620d8-38d5-4dd3-8ee6-5f4378a6ed58.

The problem is that as near as I can tell, this uuid does not exist on my system. I checked /dev/disk/by-uuid and used the command 'blkid /dev/sd<#>' on all disks listed in /dev. Next I checked fstab and found two entries for swap, neither of which corresponds to any disk on my system and one of which corresponds to the uuid that is timing out.

UUID=97fac974-4d65-4471-a01a-41544a6de796 swap swap defaults 0 0
UUID=bdb620d8-38d5-4dd3-8ee6-5f4378a6ed58 swap swap defaults 0 0

I then tried commenting out these two lines and adding the swap with the fstab line:

/dev/sda5 swap swap defaults 0 0

...and although the swap gets added via this entry okay, the system stills hangs at boot with the same message. I also rebuilt the initrd using dracut as part of the nvidia driver install, thinking this would solve the problem, but again it failed.

Where else might the reference to this uuid be hiding? Anywhere else I should look, andthing else I can try.

Thanks.

Daniel

[greyhound]

You could replace one UUID in fstab with a correct and real existing one of a swap and enable it again.
UUIDs can be seen e.g. with KDE-Partition-Manager

[stoat]

I recently went through something similar. I cloned a Fedora 17 system (a single ext4 root filesystem on one partition) from a tarball to a new partition (something I've done uncountable times). In the past, I only had to change the UUID in the GRUB config file, /etc/fstab, and schedule an SELinux relabel. But this time, similar to your story, it would not boot because of the missing partition UUID. The usual things weren't enough this time. Now there is something else that made my cloned Fedora 17 continue to want the old UUID, and I don't know what it is either. I, too, tried dracut on all kernel versions. Nope.

Here is what I ended up doing, and why I posted here... I used tune2fs to change the UUID of the new partition to the old UUID. Order in the universe was immediately restored. You might try that for your swap partition. Change it to what Fedora wants it to be. It be would going at the problem backwards, but it might work. And it's reversible, too.

I'm still interested in what it was that made my cloned system continue to look for the old UUID, and if I can edit that. If anybody knows, then say it now. It might help parish, too.

[sidebrnz]

You might be able to find it by using Search for Files. Just have it look through your entire file system for files containing that exact string. Remember, though, it's going to take a while so letting it work overnight would be a good idea.

[george_toolan]

If it wants a swap partition with a specific uuid why don't you just create one with mkswap?

       -U, --uuid UUID
              Specify the UUID to use.  The default is to generate a UUID.

Just make sure to swapoff first ;-)

[parish]

Originally Posted by greyhound

You could replace one UUID in fstab with a correct and real existing one of a swap and enable it again.
UUIDs can be seen e.g. with KDE-Partition-Manager

If only it were this simple, but the issue is not with the contents of fstab. The uuid it's searching for is not in fstab.

Originally Posted by stoat

/...snip/
Here is what I ended up doing, and why I posted here... I used tune2fs to change the UUID of the new partition to the old UUID. Order in the universe was immediately restored. You might try that for your swap partition. Change it to what Fedora wants it to be. It be would going at the problem backwards, but it might work. And it's reversible, too.

I'm still interested in what it was that made my cloned system continue to look for the old UUID, and if I can edit that. If anybody knows, then say it now. It might help parish, too.

Thanks for this suggestion. I was actually able to solve the delay on boot by using tune2fs to set the uuid to the one being looked for in the error message. I still needed to know where this reference was coming from though as I can't use uuids and must configure swap via old-style device nodes </dev/sda?>.

Fortunately for me though, after I altered the fstab entries to what I needed and yet again rebuilt the initrd using dracut (lost count at this point), the delay on boot was gone; no more searching for a nonexistant uuid. So the reference must have been in the initrd and I'm not sure what I did wrong such that it was not fixed the first time I rebuilt it.

Originally Posted by sidebrnz

You might be able to find it by using Search for Files. Just have it look through your entire file system for files containing that exact string. Remember, though, it's going to take a while so letting it work overnight would be a good idea.

At this point I'm fairly certain the reference was contained in the initrd, not in a file, although I did not verify it.

Originally Posted by george_toolan

If it wants a swap partition with a specific uuid why don't you just create one with mkswap?

       -U, --uuid UUID
              Specify the UUID to use.  The default is to generate a UUID.

Just make sure to swapoff first ;-)

Thanks for another way to accomplish what I did with tune2fs following stoat's advice.

Thanks guys!

Guess I'll never know why two entries were created during the install to begin with though...