Bug 998094

Summary:	90sec boot time delay after replacing swap partition for a new one
Product:	[Fedora] Fedora	Reporter:	Nelson Benitez <nbenitezl>
Component:	systemd	Assignee:	systemd-maint
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	19	CC:	harald, johannbg, lnykryn, mschmidt, msekleta, plautrba, systemd-maint, vpavlin, zbyszek
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-08-20 14:39:28 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Nelson Benitez 2013-08-17 08:32:14 UTC

Hi,
I happened to increase the physical ram of my computer, so then I rebooted with a gparted live cd and deleted my old swap partition and created a new bigger one to match my RAM. Now everytime I boot my fedora the boot process is delayed waiting for a service that prints the following:

[ **] A start job is running for dev-disk-by\x2duuid-1234..(rest of old swap uuid)

[and after it times out, it prints the following]

Expecting device dev-disk-by\x2duuid-1234..(rest of old swap uuid)


The timeout interval is 90sec, so a lot of time. After have read "man systemd-fstab-generator" and "man systemd.swap" it seems this behaviour is caused by systemd reading fstab on boot and creating automatically a service file for the old swap UUID, and the same time not creating anyone for my new swap UUID.

I think this is wrong, it's legitimate for a user to want to re-organize his disk layout outside of fedora, for example replacing his swap partition for a bigger one after having expanded physical ram.

As this operation can't be carried while within Fedora, a gparted live cd must be used, and gparted won't update the fstab file.


As a side note, dracut had similar problem with new swap partitions, but that have been already fixed in bug 995843

Comment 1 Nelson Benitez 2013-08-17 08:48:18 UTC

Two quick/workaround fixes I'm thinking of right now:

As read in "man systemd.swap":

"Unless the noauto option is set for them all swap units configured in /etc/fstab are also added as requirements to swap.target, so that they are waited for and activated during boot."

So:

1) Change the /etc/fstab swap units to be 'noauto' by default, and if the user wants them to be waited and checked, he adds the 'auto' option.

2) Otherwise, if /etc/fstab listed swap uuids are still wanted to be 'auto', add them automatically the TimeoutSec option to be 2sec or so. Default is now 90sec.

Comment 2 Nelson Benitez 2013-08-17 09:34:49 UTC

Quick way to reproduce:

1) Create a gparted live cd or usb, see http://gparted.sourceforge.net/livecd.php

2) Boot gparted, then select your swap partition and in the context menu execute "Generate new uuid". Alternatively you can delete the partition and create it again.

3) Now boot again into fedora..

Comment 3 Harald Hoyer 2013-08-19 08:02:16 UTC

Well, as always, if you change your system's disk layout, you _always_ have to correct your /etc/fstab, too.

Comment 4 Michal Schmidt 2013-08-20 14:39:28 UTC

(In reply to Nelson Benitez from comment #1)
> 1) Change the /etc/fstab swap units to be 'noauto' by default, and if the
> user wants them to be waited and checked, he adds the 'auto' option.

'noauto' would prevent the swap from being automatically activated on boot entirely.
The behaviour you describe is better achieved by 'nofail' - it will cause the swap unit to lose its ordering with respect to swap.target. Such a swap will be activated asynchronously with the rest of the services during boot. It is not safe to be the default, because services may require more memory than is available before activating swaps.

> 2) Otherwise, if /etc/fstab listed swap uuids are still wanted to be 'auto',
> add them automatically the TimeoutSec option to be 2sec or so. Default is
> now 90sec.

The timeout needs to be long enough to let buses be scanned and slow devices probed.

I agree with Harald. You need to adjust your /etc/fstab after causing the change of UUID.
In the future we may get by without an /etc/fstab entirely in the simple cases ("Zero Configuration File System Discovery and Mounting", http://www.linuxplumbersconf.org/2013/ocw/sessions/1359), but we're not there yet.