Bug 690510

Summary:	Boot process hangs when swap partition is missing
Product:	[Fedora] Fedora	Reporter:	bsfmig <bigslowfat>
Component:	systemd	Assignee:	Lennart Poettering <lpoetter>
Status:	CLOSED WONTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	15	CC:	johannbg, lpoetter, metherid, mschmidt, notting, plautrba
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-03-29 22:27:41 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description bsfmig 2011-03-24 14:25:42 UTC

Description of problem:
Boot process hangs when swap partition is missing

Version-Release number of selected component (if applicable):
systemd-20-1.fc15.x86_64

How reproducible:
Each time before fstab got corrected

Steps to Reproduce:
I attempted to set up a Hackintosh today (yeah, that's indeed NOT the point) and thus needed a primary partition large enough so I resized my swap partition and installed Mac on it. When I tried to boot Fedora afterwards, the boot process sits still at "Random Seed" step (sorry but the dmesg was washed up by a bug...) instead of continuing to boot.

Expected results:
Ignore the error and continue to boot without manual editing of /etc/fstab, like my side-by-side Ubuntu installation does.

Comment 1 Michal Schmidt 2011-03-24 18:41:56 UTC

How do you reference the swap partition in /etc/fstab? By name? By UUID?
Does it timeout and continue after 3 minutes?

Comment 2 bsfmig 2011-03-25 04:19:18 UTC

by UUID.
I will try but it should have been bypassed without any trouble.

ps.It seems that China(PR) is attempting to hinder all SSL connections to the United States by randomly intendedly dropping packets on port 443 so I have trouble connecting to RHBZ.

Comment 3 Michal Schmidt 2011-03-27 00:25:40 UTC

Since you mentioned that Ubuntu does not wait in this case, I tried it in a VM. It turns out that in Ubuntu the swapon operation is fully asynchronous. It is running in a special hack "mountall" process and nothing ever waits on the swapons to finish. And when the swap given by the UUID cannot be found, the "mountall" process simply hangs around forever. The rest of the system simply does not care. I do not think that is the desired behaviour.
Though in most cases it is fine to boot the system without waiting for the swap to come up, it is conceivable that in some configurations starting the services before that swap is ready could trigger an OOM situation.

Comment 4 Lennart Poettering 2011-03-29 22:27:41 UTC

We generally try to avoid using tmpfs too much before the swap is on. That means we need to wait for swap at boot, since quite a number of tmpfs are nowadays used in our system by default. We definitely should not change this.

Normally systemd should timeout after 3min and go on booting without the swap.

Also, there is "nofail" in fstab option to activate a swap only if its backing device happens to be around.

Hence I think I can close this bug, right? If there's something left to fix, please reopen.