Bug 192651

After issuing the reboot command, the output shows many of these messages:

Device mapper: ioctl on fedora root failed: Device or resource busy
...
Device mapper: ioctl on luks <id> failed: Device or resource busy
...

And this message once:
Failed to read reboot parameter file

Which seems to come from:
https://github.com/systemd/systemd/blob/master/src/core/shutdown.c#L406

It seems similar to the issue described here:
https://bugzilla.redhat.com/show_bug.cgi?id=1346225

Except that my system does not hang, it shuts down.

Force rebooting (reboot -f) exhibits the same behavior - the system displays the error "Failed to read reboot parameter file" and shuts down but does not restart.

Please try with upstream kernel,
1. gcc reboot_test.c -o reboot_test
2. boot kernel with 'init=/bin/bash' in the command line to get a minimal envirment, and then upload the reboot_test to the machine, and try
  ./reboot_test 3   or  ./reboot_test 4 to see if reboot works.
3. if you have problem to boot up with init=/bin/bash, just boot into a normal system and try ./reboot_test 3 and ./reboot_test 4 respectively.

Created attachment 251951 [details]
reboot syscall test

compile me

Ok doke under 4.10-rc3:

"reboot_test 3" crashes the system
"reboot_test 4" doesn't seem to do anything, the system remains responsive, I can type more shell commands, etc.

(In reply to davidnmfarrell from comment #4)
> Ok doke under 4.10-rc3:
> 
> "reboot_test 3" crashes the system
> "reboot_test 4" doesn't seem to do anything, the system remains responsive,
> I can type more shell commands, etc.

The same in init=/bin/bash mode? What does crash mean? is there panic trace on the monitor or  journal?

Created attachment 252021 [details]
dmesg after running reboot_test

Created attachment 252031 [details]
journalctl entries after reboot command

On upstream 4.10-rc4:

- "reboot_test 3" and "reboot_test 4" have no effect, under init=/bin/bash or run level 3 or 5. I'm sure the program runs because passing no parameters prints the message "Please provide a reboot mode"
- dmesg output is exactly the same before and after running reboot_test (attached)
- "reboot" seems to work - attached is the journalctl output when the reboot sequence begins. However the system never restarts, it seems to just hang, even though the screen turns off and the log entries appear to indicate that the reboot was successful.

Ok the reason reboot_test wasn't having an effect was the reboot() call was failing "operation not permitted".

- sudo reboot_test 3 initiates a reboot. The system appears to succeed, but the screen goes blank and appears to hang. Eventually the machine turns off (same as with "reboot"). But I'm unable to view the syslog with journalctl for this boot ("journalctl --boot=-1"): ("Journal file /var/log/journal/49ff6f156aa54317ac336f9a03169aea/user-1000@00053ba767883e15-ab5411483855c7e1.journal~ uses an unsupported feature, ignoring file.").
- sudo reboot_test 4 nothing happens - the reboot() function call returns the error "bad address"

For what it's worth, I have a Dell XPS 13 9360 (Kaby Lake i7-7500U)
BIOS version is 1.0.7 9/13/2016

This system came pre-installed with Ubuntu 16.04.1.
That distro is still installed, though I'm currently running a 9.3.0 kernel.

reboot from the GUI has always worked for me.

sometimes when I "sudo reboot" from the shell, after the GUI goes away there is text on the screen  complaining that a "stop job is running".... it it will wait there for up to 1m30s, but upon that passing, reboot succeeds.  I've never seen the reboot turn into a power-off.

FWIW, I set BIOS to defaults (except SATA is set to AHCI, rather than RAID), and so secure boot is enabled.  However, Ubuntu prints "Booting in insecure mode", so apparently it is secure up through the booter, but then allows booting any kernel...

Created attachment 252171 [details]
dmesg after pm_trace

How about typing "reboot" in your grub shell? Is it the same situation?(power off rather than reboot)

reboot in the Grub shell (init=/bin/bash) returns these errors:

"Failed to connect to bus: no such file or directory
Failed to talk to init daemon"


I think that's because systemd hasn't started. If I boot with systemd.unit=emergency, I get the same behavior as described earlier.

(In reply to davidnmfarrell from comment #13)
> reboot in the Grub shell (init=/bin/bash) returns these errors:
> 
> "Failed to connect to bus: no such file or directory
> Failed to talk to init daemon"
> 
> 
> I think that's because systemd hasn't started. If I boot with
> systemd.unit=emergency, I get the same behavior as described earlier.

I mean, type reboot in the grub, not after booting up to linux. You can enter grub's shell by typing 'Esc' once your saw the grub selecting menu.

(In reply to Chen Yu from comment #14)
> (In reply to davidnmfarrell from comment #13)
> > reboot in the Grub shell (init=/bin/bash) returns these errors:
> > 
> > "Failed to connect to bus: no such file or directory
> > Failed to talk to init daemon"
> > 
> > 
> > I think that's because systemd hasn't started. If I boot with
> > systemd.unit=emergency, I get the same behavior as described earlier.
> 
> I mean, type reboot in the grub, not after booting up to linux. You can
> enter grub's shell by typing 'Esc' once your saw the grub selecting menu.

And this is to figure out whether this is a firmware issue.

(In reply to Chen Yu from comment #14)

> I mean, type reboot in the grub, not after booting up to linux. You can
> enter grub's shell by typing 'Esc' once your saw the grub selecting menu.

Ah, gotcha :-)

Yes reboot from grub shell works fine: the machine powers off and then restarts.

(In reply to davidnmfarrell from comment #16)
> (In reply to Chen Yu from comment #14)
> 
> > I mean, type reboot in the grub, not after booting up to linux. You can
> > enter grub's shell by typing 'Esc' once your saw the grub selecting menu.
> 
> Ah, gotcha :-)
> 
> Yes reboot from grub shell works fine: the machine powers off and then
> restarts.
OK. Which grub version are you using? Besides, please appending the following different params respectively in the grub menu, and check if any of the following params make 'reboot' working in linux:

1) reboot=e
2) reboot=w
3) reboot=c
4) reboot=h
5) reboot=s
6) reboot=g
7) reboot=b
8) reboot=a
9) reboot=k
10) reboot=t
11) reboot=p
12) reboot=f

grub2-install -V
grub2-install (GRUB) 2.02~beta3

I installed the latest BIOS provided by Dell:
https://downloads.dell.com/FOLDER04127155M/1/XPS_9365_1_0_5.exe

On this drivers page:
http://www.dell.com/support/home/us/en/19/product-support/product/xps-13-9365-2-in-1-laptop/drivers?newtab=true&c=us&l=en&s=dhs

And this fixed the issue. I tested reboot in 4.9.3 and 4.10.0-rc6 and it works fine under both kernels.

If you need any further information, just let me know, otherwise I think this ticket can be closed.

Thank you for your help!

OK, thx.

BTW, I've noticed you have another two open tickets, can you please check if the problem still exists after upgrading BIOS?

(In reply to Zhang Rui from comment #21)
> BTW, I've noticed you have another two open tickets, can you please check if
> the problem still exists after upgrading BIOS?

They still exist :-(