Description of problem:
Systemd waits with NO LIMIT for filesystem that's unavailable


Version-Release number of selected component (if applicable):



How reproducible:
Perfectly


Steps to Reproduce:
1. See below
2.
3.

Actual results:
Frozen boot


Expected results:
Successful boot


Additional info:

Oh what a joy to discover yet another screwup in that Tower of Babel
we know as systemd.  This one has rendered my IBM T30 laptop
unbootable.

The screen shows the boot process waiting for an anonymous filesystem
to become available.  It is waiting with "no limit"; thus far over 15
hours with no end in sight.

This is an attempt to boot to single-user mode - I appended an "s" to
the grub kernel line - because the same infinite wait occurred on a
normal boot.  In olden days, single user mode guaranteed an emergency
shell prompt, whence repairs could be made.  No more.

The critical missing filesystem is the swap partition, which is
encrypted.  How I got to this impasse involves several other defects
in the installer, grub2, and encryption, but let me be clear that this
bugzilla is to report the stupid choice to wait with NO LIMIT for
something - anything - to become available during boot.
I note that the time waited and the time to wait are now reported.
That's one small step for logic.

1 - systemd should NEVER wait forever during boot.
2 - systemd must NEVER prevent single user mode from arriving at an
emergency shell.


Because it's relevant I will describe the comedy of screwups that led
to this situation.

Prior to installing F21, this laptop was configured with standard
partitions of
  /dev/sda1      /boot
  /dev/sda5      /f19          encrypted
  /dev/sda6      /     (F20)   encrypted
  /dev/sda7      /home         encrypted
  /dev/sda8      swap          encrypted
The /boot partition contained a mishmash of kernels for both F19 and
F20 and the grub.cfg contained paragraphs for all of them.
This scheme worked fine in the days of grub, but grub2 makes a
terrible mess of it, as reported in earlier BZs (837430).
So in the sequence of annoying bugs, here's #3:

3 - grub2 can't sort out multiple systems in /boot.

I determined to segregate F21 from F20, putting their respective boot
files into their own /boot subdirectories in the separate root
filesystems.  The /boot partition would be repurposed as /mainboot
and would contain a handcrafted grub.cfg that would switch to grub.cfg
in one or the other root filesystem.

This required the root filesystems to be de-encrypted.  What better
way to accomplish this than to freshly install F21 into a newly
formatted and unencrypted /dev/sda5, while retaining the existing
encryption of /home and swap.

I soon discovered that the installer cannot cope with formatting a
previously encrypted partition.  I reverted to a properly competent
partition manager - gparted-live - which handily reformatted
/dev/sda5.  So here's #4:

4 - installer cannot reformat an encrypted partition

Despite the unwieldy user interface, I was able to attach the (still
encrypted) /home partition to the new F21 configuration without
reformatting it or otherwise disturbing its contents.  Likewise for
the encrypted /dev/sda6 /f20 mountpoint.
But nothing would allow me to similarly attach the swap partition.
So I went ahead without a swap partition.

5 - installer has no means to attach an existing swap partition.

The new F21 installation booted up nicely, except it lacked swap
space.  So, I added an entry to /etc/fstab, copying the one that
worked from /f20/etc/fstab for the encrypted swap partition.
Since the encryption passphrase is the same for all three encrypted
partitions, I thought this would surely be OK.  It wasn't.

6 - the installer, grub2, systemd, whatever, can't deal competently
with encrypted partitions.

I suspect that I was expected to add something to /etc/crypttab when I
added swap to /etc/fstab.  If I can find a way to regain access to the
machine, I'll try that.  Otherwise, I'll have to trash the installation
and start over.

LATER ---
System is recovered.  I booted from Live Xfce4 USB stick, mounted the
new /f20 filesystem, edited /etc/fstab to remove the swap line, and
rebooted.
Then with the new F20 system running (without swap), I edited
/etc/crypttab, adding the swap partition entry copied from the F19
filesystem, and reedited /etc/fstab to also restore the swap line.

Rebooted.  All is well.  The old encrypted swap partition is in use.

It shouldn't be this hard...