Created attachment 1248076 [details] result of lsblk, kernel command line, systemd-dump, journal report, shutdown-log Description of problem: When you want to shutdown the system, screen turns black and computer won't stop untill you press the power button Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1.ask for shutdown 2. 3. Actual results: computer does not stop untill pwer button is pressed Expected results: normal shutdown Additional info: I firtly thought that it was a systemd bug and filed a bug report on github. This bug (https://github.com/systemd/systemd/issues/5244) has been immediately closed with this explanation: The logs you append indicate that systemd managed to run the binaries included in /usr/lib/systemd/system-shutdown. This happens very late during boot. After that the only thing system still does is either call reboot() or pass control back to the initrd (if one is used and set up for that). Since you are using Fedora, it appears that the latter is the case and hangs for you. Either way, systemd is not in control at that point anymore. Hence, please contact the dracut folks about this, we can't help you! So I contact the "dracut folks" as suggested!
Debugging dracut on shutdown To debug the shutdown sequence on systemd systems, you can rd.break on pre-shutdown or shutdown. To do this from an already booted system: # mkdir -p /run/initramfs/etc/cmdline.d # echo "rd.debug rd.break=pre-shutdown rd.break=shutdown" > /run/initramfs/etc/cmdline.d/debug.conf # touch /run/initramfs/.need_shutdown This will give you a dracut shell after the system pivot’ed back in the initramfs.
(In reply to Harald Hoyer from comment #1) > Debugging dracut on shutdown > > To debug the shutdown sequence on systemd systems, you can rd.break on > pre-shutdown or shutdown. > > To do this from an already booted system: > > # mkdir -p /run/initramfs/etc/cmdline.d > # echo "rd.debug rd.break=pre-shutdown rd.break=shutdown" > > /run/initramfs/etc/cmdline.d/debug.conf > # touch /run/initramfs/.need_shutdown > > This will give you a dracut shell after the system pivot’ed back in the > initramfs. I made this. When I ask for shutdown either the bug appears and I cannot see anything because the screen is immediately switched off and shtdown hangs (I have to press the power button to switch the computer off) Or a "normal" shutdown happens and I attach a photo of what I see on the screen for the first shell. Then I exit the first shell and I the message logout shutdown:/# Exiting the second shelle switch the computer off.
Created attachment 1249232 [details] photo of the first pre-shutdown shell
Created attachment 1249616 [details] photo of pre-shutdown shell Today I can confirm that when the bug occurs (ie. no shutdown untill power button is pressed), *absolutely nothing* is written in the log: the last written information is: systemd-logind: Creating /run/nologin blocking further logins... When I type the command "shutdown' (as root) After that screen is black and nothing is written in the journal. Today also, I get new messages after the first shell exit, I attach the image. System halt when I exit the second shell.
Created attachment 1255877 [details] image of the last screen after shutdown After updating to the last kernel (4.9.9-200.fc25.x86_64), I got this last screen with a kernel panic and computer did not stop. Image is not so good but, I think, readable... F.P.
No news? Does it mean good news? ie. someone can help?
(In reply to François Patte from comment #5) > Created attachment 1255877 [details] > image of the last screen after shutdown > > After updating to the last kernel (4.9.9-200.fc25.x86_64), I got this last > screen with a kernel panic and computer did not stop. > > Image is not so good but, I think, readable... > > F.P. This clearly is a kernel bug.. Reassigning. Sorry for the late reply.
Please retest on the latest kernel
(In reply to Laura Abbott from comment #8) > Please retest on the latest kernel Sorry, I cannot retest this bug: I made a new install of Fedora 25, giving up on my wished configuration: raid1+cryptsetup.... It is a pity that it takes so long to get an answer from bugzilla!