Linux Mint Spontaneous Reboot At Desktop.

Topic

New Reply

My computer has an odd problem since I upgraded from Linux Mint 19.3 to LM20. A few times a month the computer will spontaneously reboot and nothing shows up in the Cinnamon crash report and Logs are vague. People have suggested it may be a power issue but couldn’t offer advice.

The reboot usually happens just after I enter my credentials in the login screen and press enter but before I reach the desktop. Once I made it to the desktop and just as I opened Firefox the system rebooted.

Today I had another spontaneous reboot. I logged in and just after the desktop loaded the system rebooted and then loaded normally. The “connected to a network” notification showed up in the upper corner like it some times does. Of course there was no notice in the crash reporter but the logs got me thinking.

In the security logs I found reference to bluez just before the reboot:

17:21:51 systemd: Reached target Exit the Session.
17:21:48 pulseaudio: GetManagedObjects() failed: org.freedesktop.DBus.Error.TimedOut: Failed to activate service ‘org.bluez’: timed out (service_start_timeout=25000ms)
17:21:45 systemd: Startup finished in 4.471s.
17:21:45 dbus-daemon: [session uid=1000 pid=1325] Successfully activated service ‘org.gtk.vfs.GoaVolumeMonitor’
17:21:45 goa-daemon: goa-daemon version 3.36.0 starting
17:21:43 systemd: Reached target Main User Target.

I have a wired network and no wifi and never have. This bluez error pops up fairly often and I have seen reference to it online. The last three entries make me wonder if it is causing the reboots. What do you think? If it is a bluez problem will removing bluez fix it? Thanks.

Reply | Quote

Replies

I was just reading your other post on Charlie’s thread when I saw this new post come in. You’ve had some kind of disk issue:

I tried a Timeshift restore the first time and it didn’t work and eventually used Fsck on my harddrive (dev/sda2) and got back to my desktop.

…

When i tried Firefox again it wouldn’t load so I rebooted the computer and ended up in Busybox and it mentioned inodes (?) and orphan files. I hadn’t updated or deleted anything around that time so don’t know what got corrupted.

…

On boot the next day I got stuck in Busybox again but Fsck fixed things and I got to my desktop.

It looks like you may have a failing hard drive/SSD. Fsck is the Linux equivalent of Windows’ chkdisk, and the bit about Timeshift not working but fsck getting you back in clearly shows a disk issue. Then you’re talking about inodes and orphaned files, which again points to disk issues.

A computer file (as we perceive it) consists of an inode (a pointer within the given directory that indicates where the data stream is located on the disk) and that data stream itself. When you delete a file, as you probably know, it doesn’t actually wipe the data, but instead removes the link to the data, leaving the data in place (until it is overwritten) but having no reference to it. That link that is removed is the inode.

When you get a list of files in a given subdirectory, you’re looking at the inodes. Each of them points to the data stream on the disk. If you move a file to another directory within the same file system, it is nearly instantaneous, since all it needs to do is remove the inode from the old directory and add the inode to the new one, with no need to actually mess with the file itself at all. If you move it to another filesystem (partition, more or less), it has to copy it, then remove the inode from the old location and add a new one to its new location. The old copy is still there, but with nothing pointing to it, it’s considered free disk space, and is likely to be partly or wholly overwritten soon enough.

The fact that fsck worked to get Mint started, but then it failed again, and worked again, points to a problem that is recurring, and that’s worrisome. It could be a failing hard disk, which means your data could be at risk if it is not backed up. If you’d used some kind of disk utility before it failed the second time, that would be suspect, but you specifically said you hadn’t. If it was an OS issue, the Timeshift should have fixed it.

It could also be a faulty connector, cable, or a failing SATA adapter on the motherboard (or on a plugin card). It wouldn’t hurt to use ClamAV to scan for malware, though in Linux malware is not very common. Be sure to copy or otherwise back up anything you’d be upset to lose, because it might be happening!

Bluez is the Bluetooth stack in Linux, and it really shouldn’t cause a spontaneous reboot if it is failing. Does the PC have a Bluetooth adapter? If not, you could try removing it, but I can’t see how that would be causing recurring disk errors.

Interestingly, in the other thread I referenced also refers to a Mint issue that may be storage related. There was some kind of error with LVM on Charlie’s computer, and that’s when it went beyond my knowledge range, as I’ve never used LVM.

 

Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)

Reply | Quote

I use Clamtk to scan my snap folders and /home folder (due to a game in .Wine that updates frequently) but a lot of the files are locked off as i don’t run it in sudo. Viruses may be a long shot.

I just checked the syslog and looked closely at temperatures and they were all well below the shown criticals at the time of the reboot.

The last info before the reboot looks fairly mundane. These are the last bits before the big red line of zeros that syslog likes to separate boots (at least in Mint).

Dec 9 17:21:23 leon1 at-spi-bus-launcher[1227]: dbus-daemon[1227]: Activating service name=’org.a11y.atspi.Registry’ requested by ‘:1.0’ (uid=112 pid=1203 comm=”/usr/sbin/slick-greeter ” label=”unconfined”)
Dec 9 17:21:23 leon1 at-spi-bus-launcher[1227]: dbus-daemon[1227]: Successfully activated service ‘org.a11y.atspi.Registry’
Dec 9 17:21:23 leon1 at-spi-bus-launcher[1276]: SpiRegistry daemon is running with well-known name – org.a11y.atspi.Registry
Dec 9 17:21:24 leon1 snapd[943]: storehelpers.go:551: cannot refresh: snap has no updates available: “core”, “core18”, “freeorion”
Dec 9 17:21:24 leon1 snapd[943]: autorefresh.go:479: auto-refresh: all snaps are up-to-date
Dec 9 17:21:26 leon1 systemd[1]: NetworkManager-dispatcher.service: Succeeded.
Dec 9 17:21:26 leon1 systemd-resolved[889]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
Dec 9 17:21:26 leon1 systemd-resolved[889]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
Dec 9 17:21:36 leon1 systemd-timesyncd[890]: Initial synchronization to time server 91.189.89.199:123 (ntp.ubuntu.com).

Then the system reboots and the process starts again.

I checked online and saw an article about checking your system’s “Last Reboot”. When I used the command on my comp I ended up with double entries all of the times the system rebooted.

For example (from tonight):

reboot system boot 5.4.0-52-generic Wed Dec 9 17:22 still running
reboot system boot 5.4.0-52-generic Wed Dec 9 17:20 still running
reboot system boot 5.4.0-52-generic Tue Dec 8 21:54 – 10:42 (12:47)
reboot system boot 5.4.0-52-generic Mon Dec 7 17:40 – 12:15 (18:35)

i don’t know if that is normal or not.

The problem could be due to the aging hardware since this machine is six years old. I want to get a new computer but have been holding off. Linux has giver new life to this old beasty. 🙂 In the short term I will get another USB stick and burn LM20 (my back up/rescue stick still has 19.3 on it) then do a format/reinstall. Upgrading was convenient but probably retained some errors and quirks from the original install.

Reply | Quote

[mn--]

Ascaris wrote:

A computer file (as we perceive it) consists of an inode (a pointer within the given directory that indicates where the data stream is located on the disk) and that data stream itself. When you delete a file, as you probably know, it doesn’t actually wipe the data, but instead removes the link to the data, leaving the data in place (until it is overwritten) but having no reference to it. That link that is removed is the inode.

Well actually, the more traditional way is that the inode isn’t directly in any one directory – file names are in directories and point to inodes. And removing a file by name only decrements the number of references to the inode, and inodes get removed when there are no references but “currently open in a process” also counts as a reference.

Therefore orphan inodes happen when a file was already “deleted” but open until the system crashed, or the cleanup didn’t get to run (or wasn’t able to write its end result) for some other reason. Yes, “cleanup wasn’t able to write” is typically a hardware failure.

But there’s more than one way to implement it all, some variants having the inode directly containing the data stream (Linux’s ext4 has that option for very small files only, for example) and some others only approximating the inode structure in the driver at runtime but having a very different on-disk implementation… the latter is what actually happens when you mount NTFS on Linux, for example.

• This reply was modified 4 years, 4 months ago by mn--.

1 user thanked author for this post.

Ascaris

Reply | Quote

I am simplifying a bit, maybe too much. The filename is not itself the inode (and doesn’t contain the filename), but the inode isn’t the actual data stream either (I wasn’t aware that of the exception you mentioned). As I understand, the filename is just a field in a directory structure, which points to an inode, and the inode points to the data stream and stores the metadata.

There are multiple levels of abstraction in a file system, and people think of the icon as being the file, and that works at some level, but isn’t technically true. Trying to get everything technically 100% right and making it understandable can be competing notions. I have a tendency to write a book for the simplest post anyway, and it’s possible my understanding of any given concept is incomplete. Thanks for the clarification… I try to provide the best information possible, and the real issue here is that it looks like some kind of disk system failure that firemind is having.

 

Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)

Reply | Quote

Whatever you do, do not remove Bluez! Bluetooth is tied into your sound device and will inevitably cause issues with your sound driver. Try disabling Bluetooth (Bluez) from the autostart in Mint (in your mint control panel) and see how you fair..re-enable should you have problems or need to use bluetooth.

Reply | Quote

oops..forgot about services 🙂

you can also disable the service if you don’t use bluetooth at all

Reply | Quote

Thanks. I was thinking about removing bluez since i only have one mouse that is wifi and it is tied to my wacom tablet. when checking bluez in the Update manager i noticed that people had replaced it with Blueman which is available.

Reply | Quote

Ascaris wrote:

and the real issue here is that it looks like some kind of disk system failure that firemind is having.

… possibly, yes.

The problem here is that there are no error messages seen – they probably exist briefly in the kernel message buffer but normally that isn’t visible anywhere directly, and if copying to the files fails or doesn’t have time to run before reboot…

If this thing was used in text-only mode (no graphics) they’d probably show up, but that’s sort of less than useful for a modern desktop.

You might get them to show up by using a console capture application, the traditional one is “xconsole” … but that again depends on the graphics subsystem having sufficient time to process it before dying, and… well. Still better than nothing, so,
sudo -H xconsole -notify -verbose -savelines 10000 -daemon …

… and then just keep the window visible.

In my experience though, spontaneous reboots without any prior freezing or such are usually power-related or something on the motherboard or main bus. Disk related crashes typically have a stutter period of at least a few seconds even in worst case.

Many motherboards are surprisingly weak to USB voltage/current issues, it seems. So a short in a keyboard or mouse might be enough to cause a hard reset without a warning.

Though I’ve also seen a shorted disk cause power-related resets due to all the extra current the disk pulled…

1 user thanked author for this post.

firemind

Reply | Quote

[firemind]

Many motherboards are surprisingly weak to USB voltage/current issues, it seems. So a short in a keyboard or mouse might be enough to cause a hard reset without a warning.

Interesting point. One issue I have had is with my Corsair mouse and keyboard set. They work great when Cinnamon is loaded and were no problem at all in Windows 7 or when using the 19.3 live USB. But since installation I have gotten error messages and the mouse sometimes doesn’t start. Once on the desktop I unplug/replug the mouse and it works.

I always get this message:

kernel: usbhid 3-7:1.2: couldn’t find an input interrupt endpoint

but my mouse usually works after. If i get the following message my mouse usually fails to start.

kernel: usb 3-7: can’t set config #1, error -110

The mouse and keyboard light up normally when the gigabyte logo is up and turn off briefly before some text which will have some of the USB messages. If things are fine the mouse light will come back on and no replugging is needed.

A while ago I plugged in my micorsoft mouse and for some reason my Corsair fails less often. If the corsair fails the microsft doesn’t.

Here is the current lsusb – no replug was needed:

Bus 002 Device 002: ID 8087:8000 Intel Corp.
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:8008 Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 004: ID 045e:00f6 Microsoft Corp. Comfort Optical Mouse 1000
Bus 003 Device 003: ID 1b1c:1b3c Corsair Corsair Gaming HARPOON RGB Mouse
Bus 003 Device 002: ID 1b1c:1b3d Corsair Corsair Gaming K55 RGB Keyboard
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

If the corsair mouse had failed I would see:

Bus 003 Device 003: ID 1b1c:1b3c Corsair

Btw the keyboard almost never fails.

I have been asking in forums about ckb-next a linux drivers for Corsair. I am trying to see if they will fix the detection problem. i haven’t tried them yet because one review I read said the person had to apply the firmware update to get the drivers to work and the update bricked his kb and mouse.

I am not sure if the mouse issue is related to the reboots yet.

• This reply was modified 4 years, 4 months ago by firemind.

Reply | Quote

[firemind]

I found a page I was going to post in the Mint forums about one of fsck episodes. I had a systemd update and then was using .wine to play a game.Back on the desktop everything was sluggish and so i rebooted and then had to fsck.

The last entry before shutdown was:

EXT4-fs error (device sda2): htree_dirblock_to_tree:997: inode #24775010: comm rsync: Directory block failed checksum

There were several references to .Wine:

gamemoded-Removing expired game [21170]…

Removing game: 21170 [/home/leon/.wine/drive_c/windows/system32/wineboot.exe]

I hadn’t updated anything related to .Wine and it was working fine afterwards.

• This reply was modified 4 years, 4 months ago by firemind.

Reply | Quote

firemind wrote:

EXT4-fs error (device sda2): htree_dirblock_to_tree:997: inode #24775010: comm rsync: Directory block failed checksum

Found a case with sort of similar errors on a nearly brand new system. I expect you aren’t the same person?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846296#37

… so yeah, this might be traceable to a motherboard / chipset / processor compatibility problem.

I’d experiment with the virtualization settings in your BIOS and maybe turning the IOMMU off in software (kernel parameter intel_iommu=off for some of those). There are known incompatibilities with virtualization technologies on some processor steppings “

VT-d on i7 3930K and i7 3960X only works on C2 stepping.

” and the like.

Reply | Quote

Thanks. I will look into IOMMU when i get a chance. That wasn’t me – I have posted here and the Mint forums about this but not on debian.org or github, etc.

Reply | Quote