Bug 798328

Description of problem:
This problem is already reported in bug 748920, but because the discussion there speaks about multiple issues, let's solve one specific problem here separately.

In certain scenarios when fsck reports inconsistent filesystem and manual execution fsck is required, the user is not given a maintenance shell. Therefore the boot can't continue and the system is stuck. The full description is in bug 748920 comment 53, copying here:

> 1. This problem still exists in Fedora 17. Both of them: a) Fedora does not
> boot if you set back time, and b) you don't get maintenance shell in specific
> scenarios
> 
> Reproducer:
> a) Use the default partitioning
> /dev/sda1 1MB GPT
> /dev/sda2 500MB /boot
> /dev/sda3 rest lvm
> lvm contains:
> lv_root, lv_home, lv_swap
> 
> b) If you set back time more than 1 day and reboot, you'll encounter dracut
> shell for vg-lv_root (see f17_virt_problem1.png). Fixing the problem and
> continuing boot will print out errors about /dev/sda2 (see
> f17_virt_problem2.png). You can't fix it, no maintenance shell provided. After
> reboot you'll skip vg-lv_root problem (that is already fixed), but you'll again
> encounter /dev/sda2 problem. If you are using plymouth, the boot will appear as
> "stuck" indefinitely (see f17_virt_splash.png, but you can use Esc to switch to
> text mode). You can fix this only by reverting system time in BIOS, using a
> rescue CD or some higher magic (like forcing dracut shell from grub).
> 
> c) If you use a different partitioning setup without lv_home, you'll be given a
> maintenance shell for /dev/sda2 problem, so you can fix it. The boot will hang
> after that, but next reboot is fine.
> 
> 2. I was able to reproduce this consistently with a bare metal machine and with
> a VM. But be aware that when working with VM it can be tricky to change the
> system time, read
> http://kparal.wordpress.com/2012/02/28/changing-system-time-in-a-virtual-machine/

The problem is likely to be in systemd which is in charge at that moment and should be spawning the maintenance shell. But it isn't and that makes the recovery very hard.

Version-Release number of selected component (if applicable):
Fedora 17 Alpha
systemd-43-1.fc17.i686
dracut-017-1.fc17.noarch

How reproducible:
always

Steps to Reproduce:
see quoted text in description  

Actual results:
maintenance shell is not spawned

Expected results:
maintenance shell is spawned