Bug 798328 - No rescue shell is offered for fsck errors
Summary: No rescue shell is offered for fsck errors
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 17
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: F17Blocker, F17FinalBlocker
TreeView+ depends on / blocked
Reported: 2012-02-28 16:26 UTC by Kamil Páral
Modified: 2013-05-04 02:56 UTC (History)
10 users (show)

Clone Of:
Last Closed: 2012-05-02 04:53:48 UTC

Attachments (Terms of Use)
f17_virt_problem1.png (27.53 KB, image/png)
2012-02-28 16:27 UTC, Kamil Páral
no flags Details
f17_virt_problem2.png (33.99 KB, image/png)
2012-02-28 16:27 UTC, Kamil Páral
no flags Details
f17_virt_splash.png (18.03 KB, image/png)
2012-02-28 16:27 UTC, Kamil Páral
no flags Details

Description Kamil Páral 2012-02-28 16:26:54 UTC
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

How reproducible:

Steps to Reproduce:
see quoted text in description  

Actual results:
maintenance shell is not spawned

Expected results:
maintenance shell is spawned

Comment 1 Kamil Páral 2012-02-28 16:27:40 UTC
Created attachment 566336 [details]

Comment 2 Kamil Páral 2012-02-28 16:27:45 UTC
Created attachment 566337 [details]

Comment 3 Kamil Páral 2012-02-28 16:27:50 UTC
Created attachment 566338 [details]

Comment 4 Kamil Páral 2012-02-28 16:30:52 UTC
Proposing as F17 Final blocker, even though we have no matching criterion for this.

Comment 5 Michal Schmidt 2012-02-28 16:58:46 UTC
f17_virt_problem2.png shows an interesting situation. I wonder why local-fs.target ("Local File Systems") was not marked as failed too.

Comment 6 Adam Williamson 2012-04-20 21:33:25 UTC
Discussed at 2012-04-20 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-04-20/fedora-bugzappers.2012-04-20-17.01.log.txt . We agreed we would like to have rather more information on the exact state of play in current F17 to evaluate this bug as a beta. Has someone checked exactly how this is affecting, say, F17 Beta? Under what circumstances do you get no console?

Comment 7 Michal Schmidt 2012-04-24 10:13:21 UTC
Yes, F17 is affected.
It is harder to hit this bug since the e2fsck.conf change for bug 748920. Actual filesystem corruption is now necessary.
It also depends on the disk layout. To reproduce it, a fsck has to fail while systemd is still waiting for a block device for another filesystem to appear. This is usually the case with the other filesystem being a LVM volume that has not been activated by dracut (such as lv_home).

Fixed upstream:

Comment 8 Fedora Update System 2012-04-26 00:31:28 UTC
systemd-44-7.fc17 has been submitted as an update for Fedora 17.

Comment 9 Fedora Update System 2012-04-26 19:28:00 UTC
Package systemd-44-7.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-44-7.fc17'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 10 Fedora Update System 2012-05-02 04:53:48 UTC
systemd-44-7.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 11 Tim Flink 2012-05-04 16:25:25 UTC
I realize that this has been closed but I was able to verify that the prompt does come up with fsck errors.

1. Did fresh install of F17, made sure that the lastest systemd, dracut and e2fsprogs (using LVM - /home is on it's own LV)
2. set back system time by 1 week - no fsck errors
3. purposely corrupted the LV containing /home and forced fsck at next reboot
4. on reboot, I was dumped into the systemd recovery shell because of fsck errors
5. fsck eventually fixed the damage I did (a little more than I had intended)

After another reboot and run through fsck, everything is working fine.

Note You need to log in before you can comment on or make changes to this bug.