Bug 836130 - after entering luks password on boot, the boot process sometime stops
after entering luks password on boot, the boot process sometime stops
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-06-28 03:35 EDT by matmenu8
Modified: 2012-11-16 09:02 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-11-16 09:02:05 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description matmenu8 2012-06-28 03:35:22 EDT
Description of problem:after entering passphrase, sometime the boot process will stop. Ctrl+alt+del works. But escape to see log doesn't work and ctrl+alt+Fx doesn't give any login possibility.

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

How reproducible: doesn't do it every time, rebooting 2 to 5 times works... Because of it's randomness, can't be sure of that, but looks like pressing escape to see boot log, prevent the boot process to hang/stop.

Steps to Reproduce:
2.Enter passphrase
Actual results: hang/stop booting

Expected results: boot and start login screen

Additional info: Didn't noticed that bug on the first days (3 weeks ago I think), may be due to a new update, but the bug is too random to be sue of that. Sometime it will successfully boot 3 days long.
My computer works perfectly, i did a memtest 4 hours long, prime95 too, all components are new and really good quality. That bug doesn't appear in Ubuntu or Windows, a reason more to think it's not a hardware problem.
Comment 1 matmenu8 2012-06-30 15:38:19 EDT
i booted more than 10 times since 2 days, without any problem. I'll keep you informed, but it was maybe due to another module, which was updated, not systmed.
Comment 2 matmenu8 2012-07-05 02:59:44 EDT
No problems anymore since last week. Maybe we can close the bug report. I don't know if it's normal that a module can make the whole boot process to hang without log report, that could be a bug to correct. Make systemd more error resiliant and more verbose in such cases to ease problem identification. But at least, seems like what caused the problem is not there anymore. We can wait another week if you want to be sure.
Comment 3 matmenu8 2012-07-12 03:50:50 EDT
The problem didn't show up anymore. You may close that bug report. Sorry I couldn't be more specific, but booting without graphical animation never made the boot freeze, so i couldn't see what was causing the problem. The graphic driver was not changed, so it wasn't the origin of that bug. Maybe an xorg update solved it.
Comment 4 matmenu8 2012-07-17 09:50:13 EDT
happened today again, i couldn't see the log (pressing escape), but pressing ctrl alt del did work to restart.
Comment 5 matmenu8 2012-07-27 07:42:47 EDT
again today... i think it happens when we take too much time before entering passphrase. So the steps would be :

2.When asked for passphrase, wait 30-60 sec
3.Enter passphrase
4.Boot stops and you must restart the computer.

Awaited : Boots further to login screen.
Comment 6 Michal Sekletar 2012-10-16 06:49:25 EDT
Ping? Is this still an issue on up-to-date Fedora installation? If so, please consider turning off plymouth boot screen (remove rhgb and quiet parameters from kernel command line) and provide some boot logs as described in [1].

[1] http://freedesktop.org/wiki/Software/systemd/Debugging
Comment 7 matmenu8 2012-11-05 03:24:56 EST
I tried a week long with rhgb and quiet disabled, I didn't had any issue with latest updates.
I'll try booting with quiet and rhgb a week again to see if the problem comes from those options.
Comment 8 matmenu8 2012-11-14 02:53:19 EST
Problem seems to be solved :)
Thanks a lot

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