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
Created attachment 566336 [details] f17_virt_problem1.png
Created attachment 566337 [details] f17_virt_problem2.png
Created attachment 566338 [details] f17_virt_splash.png
Proposing as F17 Final blocker, even though we have no matching criterion for this.
f17_virt_problem2.png shows an interesting situation. I wonder why local-fs.target ("Local File Systems") was not marked as failed too.
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?
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: http://cgit.freedesktop.org/systemd/systemd/commit/?id=5273510e9f228a300ec6207d4502f1c6253aed5e
systemd-44-7.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/systemd-44-7.fc17
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: https://admin.fedoraproject.org/updates/FEDORA-2012-6671/systemd-44-7.fc17 then log in and leave karma (feedback).
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.
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.