You are not logged in.
I have recently got a Dell XPS 15 laptop with a new installation of Arch on it.
I'm having a problem when rebooting (I just run 'reboot' in a terminal), where the desktop (XFCE in my case) is shut down but then the process stops at a black screen with only a blinking underscore cursor.
I've been googling around a bit to find a solution, so far what I've tried is to
- Disable lvm2-monitor.service (though this seemed to get automatically re-enabled somehow)
- Install and enable rngd
What can I do to further investigate what's halting the reboot?
Can I grab logs from some part of journalctl that would be useful?
Last edited by 7thSon (2021-06-30 08:21:31)
Offline
Check the end of the journal. If you can't switch TTY during the "pausing" look at the journal of a previous boot via
journalctl -b-1Offline
edited: sorry, wrong thread
Last edited by andrea89g (2021-06-19 13:38:45)
Offline
Here is my journal from a session until rebooting:
https://hastebin.com/raw/jihuxaquli
The end of the log doesn't seem to contain any errors, but regardless the shutdown never finishes completely.
I'm looking specifically at these lines at the very end:
Jun 19 16:21:00 arch systemd[1]: Finished Reboot.
Jun 19 16:21:00 arch systemd[1]: Reached target Reboot.
Jun 19 16:21:00 arch systemd[1]: Shutting down.
Jun 19 16:21:00 arch audit: BPF prog-id=16 op=UNLOAD
Jun 19 16:21:00 arch audit: BPF prog-id=15 op=UNLOAD
Jun 19 16:21:00 arch audit: BPF prog-id=14 op=UNLOAD
Jun 19 16:21:00 arch audit: BPF prog-id=13 op=UNLOAD
Jun 19 16:21:00 arch audit: BPF prog-id=12 op=UNLOAD
Jun 19 16:21:00 arch audit: BPF prog-id=11 op=UNLOAD
Jun 19 16:21:01 arch systemd-shutdown[1]: Syncing filesystems and block devices.
Jun 19 16:21:01 arch systemd-journald[360]: Journal stoppedOffline
Same problem w/ the regular (non -lts) kernel?
Also https://bbs.archlinux.org/viewtopic.php … 2#p1977242
Offline
Same problem w/ the regular (non -lts) kernel?
Also https://bbs.archlinux.org/viewtopic.php … 2#p1977242
Yes, I get the same behavior with both kernels.
Not sure which parts are relevant from the link you posted, I don't get a message saying "Reached system power off" in the journal for starters.
I also tried logging out before rebooting from the DM, the reboot hangs with this method as well.
I now noticed that the reboot doesn't seem to hang indefinitely. I tried switching to other tty's when stuck with the blinking cursor, but all the other tty's also only show the cursor. One of the tty's accepts input, but there is no shell, so its just dead input it seems. After a minute or two of switching back and forth between the tty's and inputting some gibberish into the responsive tty the system finally restarted.
Last edited by 7thSon (2021-06-20 11:20:10)
Offline
Some stop job is hanging but you can't see that for I assume some silent boot messages.
Post the system journal for the reboot that ultimately took place after the delay (ie. "sudo journalctl -b -1" if it was the previous one)
Offline
Some stop job is hanging but you can't see that for I assume some silent boot messages.
Post the system journal for the reboot that ultimately took place after the delay (ie. "sudo journalctl -b -1" if it was the previous one)
Here are two logs from two separate hanging reboot sessions (both booting up after hangs as well):
https://hastebin.com/raw/bogedofeqi
https://hastebin.com/raw/abigoluvil
Offline
Both reboots take ~3 seconds from issuing the command to systemd being done w/ the process.
See https://bbs.archlinux.org/viewtopic.php … 2#p1977242 again, if you have a parallel windows make sure that fast boot is (still) disabled.
Read the links in the wiki, it's important to really shut windows down at least once after the change.
Otherwise/then lie to the ACPI about the OS.
Offline
Both reboots take ~3 seconds from issuing the command to systemd being done w/ the process.
See https://bbs.archlinux.org/viewtopic.php … 2#p1977242 again, if you have a parallel windows make sure that fast boot is (still) disabled.
Read the links in the wiki, it's important to really shut windows down at least once after the change.Otherwise/then lie to the ACPI about the OS.
I now set the FastBoot to "Thorough" according to the wiki pages for Dell XPS laptops. I then switched the storage mode back to RAID to that I could boot back into Windows.
After that I booted back up into Arch, and right after logging in I went into a terminal and ran 'reboot', and I'm still getting the hang.
I'm not sure which links in the wiki you're referring to here?
After trying the above, do I still have any options left to try other than faking the OS to the ACPI?
Last edited by 7thSon (2021-06-20 12:43:44)
Offline
https://www.eightforums.com/tutorials/6 … s-8-a.html or https://www.tenforums.com/tutorials/418 … -10-a.html
Not sure what you mean by "Thorough" but this is not about the "fast boot" option you can find in many BIOS' and that "just" skips some hardware self-checks.
Offline
https://www.eightforums.com/tutorials/6 … s-8-a.html or https://www.tenforums.com/tutorials/418 … -10-a.html
Not sure what you mean by "Thorough" but this is not about the "fast boot" option you can find in many BIOS' and that "just" skips some hardware self-checks.
Yeah I completely mistook the BIOS setting for its namesake in Windows, though it was recommended to set the BIOS option to "Thorough" in the arch wiki, so good to get that done as well.
So here's what I've done now:
- Switch the storage mode to RAID in BIOS
- Boot into W10, disable FastBoot in the Power Settings
- Shutdown W10
- Boot back into W10 one more time, shut it down again (just for good measure)
- Switch storage mode to AHCI in BIOS
- Boot back into Arch
- Execute 'reboot' immediately after login - reboot hangs
- Boot back into Arch again, edit /etc/default/grub to contain:
GRUB_CMDLINE_LINUX_DEFAULT="quiet cryptdevice=UUID=bf44a380-701c-4a53-9dbe-1c6f044f5248:luks-bf44a380-701c-4a53-9dbe-1c6f044f5248 root=/dev/mapper/luks-bf44a380-701c-4a53-9dbe-1c6f044f5248 loglevel=3 nowatchdog acpi_osi=! acpi_osi=\"Windows 2012\""- Run
grub-mkconfig -o /boot/grub/grub.cfg- Execute 'reboot' - reboot hangs
- Boot back into Arch again to allow the grub changes to take effect
- Execute 'reboot' immediately after login - reboot hangs
Did I do anything wrong in the above attempts, or am I missing something else?
Offline
Did I do anything wrong in the above attempts
No :-(
Did you add "nowatchdog" before or after you encountered those hanging reboots?
Offline
Did I do anything wrong in the above attempts
No :-(
Did you add "nowatchdog" before or after you encountered those hanging reboots?
I added it because I had the same kind of hanging reboot, only it previously also stated that "watchdog did not stop", so I thought it might have been it causing the hang.
So I would say that it's been the same with and without the 'nowatchdog' setting, though perhaps it would be worth trying to remove it again at this point.
Offline
I tried removing 'nowatchdog' again, but it didn't make any difference, reboot still hangs.
So... what to try next? ![]()
Offline
Remove "quiet" and "loglevel=3" and add "debug ignore_loglevel" to the kernel parameters.
It's hard to say what to do because it remains unclear what is actually delaying the reboot.
Also please time the delay (with a stopwatch) - the default systemd timeout is 90 seconds…
You can adjust that in /etc/systemd/system.conf, see
man systemd-system.confOffline
Remove "quiet" and "loglevel=3" and add "debug ignore_loglevel" to the kernel parameters.
It's hard to say what to do because it remains unclear what is actually delaying the reboot.Also please time the delay (with a stopwatch) - the default systemd timeout is 90 seconds…
You can adjust that in /etc/systemd/system.conf, seeman systemd-system.conf
Here's a debug log (too big to haste/pastebin):
https://drive.google.com/file/d/1b_kQlq … sp=sharing
I timed the reboot, without the debug kernel parameters it was 90 seconds, but with debug it was more like 2m15s.
I also saw now that there is a message printed after "Reached target Reboot", see below.
On one reboot:
mhi0: Device failed to exit MHI reset stateOn another reboot:
mhi0: Device Ready timeout
mhi0: MHI did not enter READY stateLast edited by 7thSon (2021-06-24 15:06:53)
Offline
So after a kernel update to 5.12.13 the reboot seems to work fine!
I guess I'll mark this solved for now.
Offline