Hi,
on several machines, I am observing that
# shutdown now
doesn't shutdown and halt/power off.
Instead, these machines shutdown and immediately reboot.
Any ideas?
Ralf
PS.: I am only observing this issue on UEFI machines. My BIOS-machines all shutdown/halt/poweroff.
On Wednesday 04 February 2015 13:11:26 Ralf Corsepius wrote:
Hi,
on several machines, I am observing that
# shutdown now
doesn't shutdown and halt/power off.
Instead, these machines shutdown and immediately reboot.
Any ideas?
Ralf
PS.: I am only observing this issue on UEFI machines. My BIOS-machines all shutdown/halt/poweroff.
Try
shutdown -h now
The -h means halt
look at
man shutdown
On Wed, Feb 04, 2015 at 01:35:13PM +0000, Gary Stainburn wrote:
doesn't shutdown and halt/power off. Instead, these machines shutdown and immediately reboot.
Try shutdown -h now The -h means halt look at
[...]
man shutdown
Right.... --poweroff should be the default. --halt should bring it to a halted state but leave the power on (not so useful these days), which is I guess why -h is now equivalent to --poweroff and you need to use -H or --halt if you want that. But it shouldn't _reboot_ unless you use the -r or --reboot flag.
On Wednesday 04 February 2015 13:47:46 Matthew Miller wrote:
man shutdown
Right.... --poweroff should be the default. --halt should bring it to a halted state but leave the power on (not so useful these days), which is I guess why -h is now equivalent to --poweroff and you need to use -H or --halt if you want that. But it shouldn't _reboot_ unless you use the -r or --reboot flag.
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader
Maybe I should have followed my own advice. I can't remember the last time I actually looked at the man page, but I always use '-h' and always have.
Ever since the power supplies changed from a physical toggle switch, -h has always turned off the PC in my experience, which does actually contradict the man page
On 02/04/2015 02:47 PM, Matthew Miller wrote:
On Wed, Feb 04, 2015 at 01:35:13PM +0000, Gary Stainburn wrote:
doesn't shutdown and halt/power off. Instead, these machines shutdown and immediately reboot.
Try shutdown -h now The -h means halt look at
[...]
man shutdown
Right.... --poweroff should be the default.
This matches with my understanding and has worked (for me) this way for a long time. However, I am observing "shutdown now" to exhibit the behavior as I would expect it for "shutdown -r now" on 2 of my machines.
One of these is a new Fedora installation on a pretty new machine. The other one had exhibited the "shutdown -r"-behavior for a longer period when it was equipped with fc20, until the issue somehow "automagically" went away. Now (presumably since some recent update), it's back again.
Ralf
On Wed, Feb 04, 2015 at 03:23:57PM +0100, Ralf Corsepius wrote:
One of these is a new Fedora installation on a pretty new machine. The other one had exhibited the "shutdown -r"-behavior for a longer period when it was equipped with fc20, until the issue somehow "automagically" went away. Now (presumably since some recent update), it's back again.
I just confirmed that it works with my F21 laptop. I can try other machines later. Just out of curiousity, does the 'poweroff' command do the right thing? (I doubt it's any different....)
What's your hardware? Possibly this is relevant: http://mjg59.dreamwidth.org/3561.html
On 02/04/2015 03:38 PM, Matthew Miller wrote:
On Wed, Feb 04, 2015 at 03:23:57PM +0100, Ralf Corsepius wrote:
One of these is a new Fedora installation on a pretty new machine. The other one had exhibited the "shutdown -r"-behavior for a longer period when it was equipped with fc20, until the issue somehow "automagically" went away. Now (presumably since some recent update), it's back again.
I just confirmed that it works with my F21 laptop.
It works on all but 2 machines I have ;)
I can try other machines later. Just out of curiousity, does the 'poweroff' command do the right thing? (I doubt it's any different....)
I gave
# poweroff # systemctl poweroff # shutdown now # shutdown --poweroff now # shutdown -r now a try on my notebook.
No visible difference. All cause a "shutdown and reboot".
Also cf. https://bugzilla.redhat.com/show_bug.cgi?id=1189107
What's your hardware?
The notebook a Lenovo Flex 2-14, the other one is a self-built desktop, based on an Intel DH87RL Mobo.
Possibly this is relevant: http://mjg59.dreamwidth.org/3561.html
;)
Ralf
On Wed, Feb 04, 2015 at 08:47:46AM -0500, Matthew Miller wrote:
On Wed, Feb 04, 2015 at 01:35:13PM +0000, Gary Stainburn wrote:
doesn't shutdown and halt/power off. Instead, these machines shutdown and immediately reboot.
Try shutdown -h now The -h means halt look at
[...]
man shutdown
Right.... --poweroff should be the default. --halt should bring it to a halted state but leave the power on (not so useful these days), which
I've used "shutdown -h now" ever since I started using LInux (1995), and it always shuts down the machine, leaving it powered OFF. My current motherboard supports UEFI, but I've disabled it in the BIOS/SETUP screens,... perhaps if I hadn't done that, shutdown -h would work differently, but as I said it always has done that.
is I guess why -h is now equivalent to --poweroff and you need to use -H or --halt if you want that. But it shouldn't _reboot_ unless you use the -r or --reboot flag.
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
On Wed, Feb 4, 2015 at 8:34 AM, Fred Smith fredex@fcshome.stoneham.ma.us wrote:
On Wed, Feb 04, 2015 at 08:47:46AM -0500, Matthew Miller wrote:
On Wed, Feb 04, 2015 at 01:35:13PM +0000, Gary Stainburn wrote:
doesn't shutdown and halt/power off. Instead, these machines shutdown and immediately reboot.
Try shutdown -h now The -h means halt look at
[...]
man shutdown
Right.... --poweroff should be the default. --halt should bring it to a halted state but leave the power on (not so useful these days), which
I've used "shutdown -h now" ever since I started using LInux (1995), and it always shuts down the machine, leaving it powered OFF. My current motherboard supports UEFI, but I've disabled it in the BIOS/SETUP screens,... perhaps if I hadn't done that, shutdown -h would work differently, but as I said it always has done that.
FYI the motherboard is UEFI, so the "disable UEFI" option actually means "enable CSM/BIOS" which presents a faux-BIOS to the OS. There is no actual way to disable UEFI. It's annoying manufacturers use this vernacular as if words have no meaning.
The only way to know which produces better results is to test it. Easiest is to use live media and boot twice, once each with this UEFI setting enabled and disabled. Compare kernel messages for bugs, problems, or bonuses. For example on one of my computers, CSM/BIOS boot results in the SSD being treated as an IDE drive, and performs at best 1/4 of the performance when I boot in UEFI mode. Most of the video problems in UEFI boot that have been resolved by enabling CSM/BIOS mode are solved, but... basically you just have to test it to know for sure.
On 02/04/2015 02:35 PM, Gary Stainburn wrote:
On Wednesday 04 February 2015 13:11:26 Ralf Corsepius wrote:
Hi,
on several machines, I am observing that
# shutdown now
doesn't shutdown and halt/power off.
Instead, these machines shutdown and immediately reboot.
Any ideas?
Ralf
PS.: I am only observing this issue on UEFI machines. My BIOS-machines all shutdown/halt/poweroff.
Try
shutdown -h now
The -h means halt
Thanks for the hint, but this doesn't work either.
-h or --poweroff exhibit the same behavior: shut down and immediately reboot.
Ralf
shutdown -P now
On 02/04/2015 06:57 AM, Ralf Corsepius wrote:
On 02/04/2015 02:35 PM, Gary Stainburn wrote:
On Wednesday 04 February 2015 13:11:26 Ralf Corsepius wrote:
Hi,
on several machines, I am observing that
# shutdown now
doesn't shutdown and halt/power off.
Instead, these machines shutdown and immediately reboot.
Any ideas?
Ralf
PS.: I am only observing this issue on UEFI machines. My BIOS-machines all shutdown/halt/poweroff.
Try
shutdown -h now
The -h means halt
Thanks for the hint, but this doesn't work either.
-h or --poweroff exhibit the same behavior: shut down and immediately reboot.
Ralf
On Wed, Feb 4, 2015 at 11:04 AM, Ralf Corsepius rc040203@freenet.de wrote:
On 02/04/2015 06:19 PM, jd1008 wrote:
shutdown -P now
FYI, /usr/sbin/shutdown is a symlink to systemctl. Try
sync && poweroff -f
If that still results in a reboot, it's a kernel bug, according to http://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1
If power is shut off, then you've got some shutdown script or unit actually instigating the reboot, and this can probably be logged by following the instructions in the URL above.
On 02/04/2015 02:11 PM, Chris Murphy wrote:
On Wed, Feb 4, 2015 at 11:04 AM, Ralf Corsepius rc040203@freenet.de wrote:
On 02/04/2015 06:19 PM, jd1008 wrote:
shutdown -P now
FYI, /usr/sbin/shutdown is a symlink to systemctl. Try
sync && poweroff -f
If that still results in a reboot, it's a kernel bug, according to http://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1
If power is shut off, then you've got some shutdown script or unit actually instigating the reboot, and this can probably be logged by following the instructions in the URL above.
I am using shutdown -P now on fc21 with latest updates. No reboot.
On 02/04/2015 10:11 PM, Chris Murphy wrote:
On Wed, Feb 4, 2015 at 11:04 AM, Ralf Corsepius rc040203@freenet.de wrote:
On 02/04/2015 06:19 PM, jd1008 wrote:
shutdown -P now
FYI: On the Intel, I found changing "Wake up on LAN from S4/5" in the UEFI setup to "disabled" makes "shutdown now" working (This mobo has plenty of tuneable settings in its BIOS/UEFI setup).
I don't understand this, but ... well, kernel bug, UEFI bug?
cf. https://bugzilla.redhat.com/show_bug.cgi?id=1189107#c3
FYI, /usr/sbin/shutdown is a symlink to systemctl. Try
sync && poweroff -f
This indeed shutdowns/powers off the Lenovo - Anything else I tried, doesn't!
If that still results in a reboot, it's a kernel bug, according to http://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1
If power is shut off, then you've got some shutdown script or unit actually instigating the reboot, and this can probably be logged by following the instructions in the URL above.
What would you suggest me to do wrt Lenovo? File a another bug against systemd, this time specifically for the Lenovo?
Ralf
On Wed, Feb 4, 2015 at 9:07 PM, Ralf Corsepius rc040203@freenet.de wrote:
FYI: On the Intel, I found changing "Wake up on LAN from S4/5" in the UEFI setup to "disabled" makes "shutdown now" working (This mobo has plenty of tuneable settings in its BIOS/UEFI setup).
I don't understand this, but ... well, kernel bug, UEFI bug?
I don't know. Could be either, but if I were at a bar making a drink bet, I'd go with the firmware.
sync && poweroff -f
This indeed shutdowns/powers off the Lenovo - Anything else I tried, doesn't!
If that still results in a reboot, it's a kernel bug, according to http://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1
If power is shut off, then you've got some shutdown script or unit actually instigating the reboot, and this can probably be logged by following the instructions in the URL above.
What would you suggest me to do wrt Lenovo? File a another bug against systemd, this time specifically for the Lenovo?
You need to go through the process in the URL above, which will cause systemd to do a late remount of rootfs and write to a file everything that happens after what ought to be a shutdown. That file is what needs to get attached to a new bug and what component.
So the way to do it in the summary is basically: All these ways to shutdown actually do a reboot (examples), but poweroff -f works correctly. Following http://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1 attached is shutdown-log.txt.
Chances are you can look in that file and figure out what the problem is, what component to file the bug for. But if it's not obvious you could file it against systemd. Just that it gets attention faster if you get the right component from the get go.
On 02/05/2015 08:38 AM, Chris Murphy wrote:
On Wed, Feb 4, 2015 at 9:07 PM, Ralf Corsepius rc040203@freenet.de wrote:
So the way to do it in the summary is basically: All these ways to shutdown actually do a reboot (examples), but poweroff -f works correctly. Following http://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1 attached is shutdown-log.txt.
Chances are you can look in that file and figure out what the problem is, what component to file the bug for.
I tried to follow your advice, but without much luck so far. I can't spot anything obvious :(
But if it's not obvious you could file it against systemd. Just that it gets attention faster if you get the right component from the get go.
May-be you can spot something.
I uploaded one of the logs to https://corsepiu.fedorapeople.org/misc/shutdown-log.txt
Ralf
On Fri, Feb 6, 2015 at 6:32 AM, Ralf Corsepius rc040203@freenet.de wrote:
On 02/05/2015 08:38 AM, Chris Murphy wrote:
On Wed, Feb 4, 2015 at 9:07 PM, Ralf Corsepius rc040203@freenet.de wrote:
So the way to do it in the summary is basically: All these ways to shutdown actually do a reboot (examples), but poweroff -f works correctly. Following http://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1 attached is shutdown-log.txt.
Chances are you can look in that file and figure out what the problem is, what component to file the bug for.
I tried to follow your advice, but without much luck so far. I can't spot anything obvious :(
But if it's not obvious you could file it against systemd. Just that it gets attention faster if you get the right component from the get go.
May-be you can spot something.
I uploaded one of the logs to https://corsepiu.fedorapeople.org/misc/shutdown-log.txt
I'd file a new systemd bug and attach that log. This log is for a poweroff command that resulted in a reboot, right? Command didn't include -f and actually powered off the hardware?
On 02/06/2015 07:16 PM, Chris Murphy wrote:
On Fri, Feb 6, 2015 at 6:32 AM, Ralf Corsepius rc040203@freenet.de wrote:
On 02/05/2015 08:38 AM, Chris Murphy wrote:
On Wed, Feb 4, 2015 at 9:07 PM, Ralf Corsepius rc040203@freenet.de wrote:
So the way to do it in the summary is basically: All these ways to shutdown actually do a reboot (examples), but poweroff -f works correctly. Following http://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1 attached is shutdown-log.txt.
Chances are you can look in that file and figure out what the problem is, what component to file the bug for.
I tried to follow your advice, but without much luck so far. I can't spot anything obvious :(
But if it's not obvious you could file it against systemd. Just that it gets attention faster if you get the right component from the get go.
May-be you can spot something.
I uploaded one of the logs to https://corsepiu.fedorapeople.org/misc/shutdown-log.txt
I'd file a new systemd bug and attach that log. This log is for a poweroff command that resulted in a reboot, right?
It's "shutdown now", which resulted in a "shutdown && reboot"
Command didn't include -f and actually powered off the hardware?
It went down and immediately rebooted.
I have other log from other attempt, but sorting them out is a bit difficult.
Ralf
On Fri, Feb 6, 2015 at 11:25 AM, Ralf Corsepius rc040203@freenet.de wrote:
It went down and immediately rebooted.
I have other log from other attempt, but sorting them out is a bit difficult.
It's quite tedious yes.
The only other thing I can think of is to compare 'systemctl list-unit-files' on a live media boot, and the currently installed system, and disable everything on the current system that isn't enable or doesn't exist on the live media boot. That way you should have boot parity. If the problem goes away, then it's some unit file. Maybe enable 1/2 of them and try again...kinda like bisecting. If you can't reproduce the problem with all the unit files in parity between live media and current boots, then it's something else that maybe isn't using a native systemd unit. Maybe it's a legacy init script? Actually that might be worth checking before the systemd unit files. Clearly it's related to something either being startedup or qutting at poweroff time, and it's doing something wrong, acting almost like a watchdog. Some process dies and the watchdog does an "oh crap!" and reboots the system before systemd can actually complete the poweroff. Whereas poweroff -f skips all the normal nice quit sequence of services and goes straight to telling the kernel to power off the hardware.
On 02/06/2015 05:31 PM, Chris Murphy wrote:
On Fri, Feb 6, 2015 at 11:25 AM, Ralf Corsepius rc040203@freenet.de wrote:
It went down and immediately rebooted.
I have other log from other attempt, but sorting them out is a bit difficult.
It's quite tedious yes.
The only other thing I can think of is to compare 'systemctl list-unit-files' on a live media boot, and the currently installed system, and disable everything on the current system that isn't enable or doesn't exist on the live media boot. That way you should have boot parity. If the problem goes away, then it's some unit file. Maybe enable 1/2 of them and try again...kinda like bisecting. If you can't reproduce the problem with all the unit files in parity between live media and current boots, then it's something else that maybe isn't using a native systemd unit. Maybe it's a legacy init script? Actually that might be worth checking before the systemd unit files. Clearly it's related to something either being startedup or qutting at poweroff time, and it's doing something wrong, acting almost like a watchdog. Some process dies and the watchdog does an "oh crap!" and reboots the system before systemd can actually complete the poweroff. Whereas poweroff -f skips all the normal nice quit sequence of services and goes straight to telling the kernel to power off the hardware.
Is the original OP of this thread still not able to fully shutdown and power off using the command sudo shutdown -P now ?
On 02/07/2015 01:55 AM, jd1008 wrote:
On 02/06/2015 05:31 PM, Chris Murphy wrote:
On Fri, Feb 6, 2015 at 11:25 AM, Ralf Corsepius rc040203@freenet.de wrote:
It went down and immediately rebooted.
I have other log from other attempt, but sorting them out is a bit difficult.
It's quite tedious yes.
The only other thing I can think of is to compare 'systemctl list-unit-files' on a live media boot, and the currently installed system, and disable everything on the current system that isn't enable or doesn't exist on the live media boot. That way you should have boot parity. If the problem goes away, then it's some unit file. Maybe enable 1/2 of them and try again...kinda like bisecting. If you can't reproduce the problem with all the unit files in parity between live media and current boots, then it's something else that maybe isn't using a native systemd unit. Maybe it's a legacy init script? Actually that might be worth checking before the systemd unit files. Clearly it's related to something either being startedup or qutting at poweroff time, and it's doing something wrong, acting almost like a watchdog. Some process dies and the watchdog does an "oh crap!" and reboots the system before systemd can actually complete the poweroff. Whereas poweroff -f skips all the normal nice quit sequence of services and goes straight to telling the kernel to power off the hardware.
Is the original OP of this thread still not able to fully shutdown and power off using the command sudo shutdown -P now ?
No, I (== Original OP) am not. Just like anything else (but "poweroff -f"), "shutdown -P now", results in a "shutdown + immediate reboot".
Ralf