LMDE 6 non-revival from suspend?? && how to edit sources?

[este.el.paz]

Folks:

Posting over here in this sub-forum for a new issue with my LMDE install . . . having had problems with Faye not being able to find itself to boot up, today, after second attempt to boot . . . Faye failed to wake up after suspend . . . . I have had this issue in my openSUSE installs over the last year, lately that has related to nvidia proprietary drivers over-writing something that removes nouveau from the lsmod . . . resulting in failure to revive from suspend.

Sort of coming to the end of my tether for LMDE . . . but hoping for some insight into how to get it straight for basic function. Lately it has taken 4 cold boots to get it booted, and now, failure to revive from suspend . . . reducing its utility for my daily driving needs.

If there are no comments on how to get revival from suspend going, then question two, is there a newer version of LMDE than "faye" yet available, such that the /etc/default/sources.list file could be edited such that what might be alpha for LMDE 7 might be installed?? I am recalling from past exploits in Mint that it uses some other file to hold the sources.list data . . . ???

Or, on this same machine I have a Sid and a Trixie install . . . what would happen if I changed "bookworm" to "trixie"?? Would that blow up an already flawed LMDE6 install?? Faye seems to keep getting a foot on the banana peel . . . and apt is not getting the system past its present condition . . . .

[xenopeek]

If you want help with your suspend issue from others here more knowledgeable about that, include your system information (open System Reports app, go to System Information on the left then click Copy button on bottom right and paste the copied information in a reply here).

If you hadn't mentioned Nvidia I would have suggested to try to install the newer Linux kernel from bookworm-backports. If your PC has very new hardware that can be a solution for hardware issues. But as I understand it installing a newer Linux kernel can be a headache with Nvidia so don't proceed on that without more info. If your CPU generation is from 2020 or before it likely won't help anyway.

What do you mean with "Lately it has taken 4 cold boots to get it booted" -- what happens the first 3 cold boots?

When next this happens and you finally are able to boot successfully I would run journalctl -b -1 -p warning -e in a maximized terminal to show the warning & error messages from your system log from the previous -- unsuccessful -- boot. It will jump you to the end of the log which is likely the most relevant but scroll up from there for any clues what's happened the previous boot. Mind the timestamp at the start of the lines -- messages older than the minute surrounding when the unsuccessful boot got hung aren't likely to be relevant at all.

If there are no comments on how to get revival from suspend going, then question two, is there a newer version of LMDE than "faye" yet available, such that the /etc/default/sources.list file could be edited such that what might be alpha for LMDE 7 might be installed?? I am recalling from past exploits in Mint that it uses some other file to hold the sources.list data . . . ???

If there were a LMDE 7 it would be on the website. If it were in development it would be on the blog. LMDE 7 will be based on Debian 13, which maybe can be expected to be released mid next year and any development for LMDE 7 won't start before that. This isn't an option.

There's nothing special about how Software Sources manages your sources -- it uses the standard way which is .list files in the /etc/apt/sources.list.d/ directory. You can also use /etc/apt/sources.list but that would be a huge clutter if all repositories would be put in that one file, so Linux Mint doesn't do that.

Or, on this same machine I have a Sid and a Trixie install . . . what would happen if I changed "bookworm" to "trixie"?? Would that blow up an already flawed LMDE6 install?? Faye seems to keep getting a foot on the banana peel . . . and apt is not getting the system past its present condition . . . .

What will happen is dependency hell and broken software.

[este.el.paz]

@xenopeek:

Alrighty, thanks kindly for the thorough reply . . . . The details of what is happening is posted over on this thread: viewtopic.php?p=2441597#p2441597

The system report data from a few weeks back is posted there at the top of the thread.

What happens is from grub menu usually the first boot goes to "initramfs ER shell" . . . "can't find init" then on subsequent cold boots selecting Faye, which is in sdb8, seems to boot my Leap 15.6 system, which is in either sda8, or sdc8 and that goes to another ER type shell that does not load the Leap GUI . . . have to "systemctl reboot" out of that or use power button.

I see in my notes that this problem with non-revival from suspend has gone back to at least 2/9/24 . . . which might have been fixed by the 6.1.0-17 kernel, but then yesterday, after booting to LMDE using an ext flash drive with Super Grub2 on it . . . got into the LMDE GUI and ran an apt dist-upgrade, and it removed the xx-17 kernel leaving it again with the xx-12 kernel . . . ???

I use my TW install to handle os-prober, so after that I ran "update-bootloader" . . . this morning it took two boots, one it "initramfs ER shell" and the second got me to LMDE GUI . . . but, now, having looked back in my notes I can figure that the xx-12 kernel had this non-revival issue . . . that possibly the -17 took care of??

From that other thread the admin/mod there said that 6.1.0-18 is available for LMDE . . . perhaps when I get a minute to get back to LMDE I could try to find where -18 kernel is located and try to upgrade to it?????

[edit] ran the journalctl command, seems like more or less the same data repeated:

Code: Select all

Mar 09 07:42:08 MacPro bluetoothd[793]: Failed to set mode: Failed (0x03)
Mar 09 07:42:08 MacPro udisksd[808]: Failed to load the 'mdraid' libblockdev plugin
Mar 09 07:42:13 MacPro kernel: [UFW BLOCK] IN=enp10s0 OUT= MAC=01:00:5e:00:00:01:2c:00:ab:8f:f0:80:08:00 SRC=192.168.254.254 >
Mar 09 07:42:18 MacPro pipewire[1132]: mod.rt: Can't find org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?
Mar 09 07:42:18 MacPro pipewire[1132]: mod.rt: found session bus but no portal
Mar 09 07:42:18 MacPro pipewire-pulse[1134]: mod.rt: Can't find org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?
Mar 09 07:42:18 MacPro pipewire-pulse[1134]: mod.rt: found session bus but no portal
Mar 09 07:42:18 MacPro wireplumber[1133]: Failed to set scheduler settings: Operation not permitted
Mar 09 07:42:28 MacPro lightdm[1216]: gkr-pam: unable to locate daemon control file
Mar 09 07:42:30 MacPro pipewire-pulse[1253]: mod.rt: Can't find org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?
Mar 09 07:42:30 MacPro pipewire-pulse[1253]: mod.rt: found session bus but no portal
Mar 09 07:42:30 MacPro pipewire[1251]: mod.rt: Can't find org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?
Mar 09 07:42:30 MacPro pipewire[1251]: mod.rt: found session bus but no portal
Mar 09 07:42:30 MacPro wireplumber[1252]: Failed to set scheduler settings: Operation not permitted
Mar 09 07:42:32 MacPro gnome-keyring-daemon[1468]: discover_other_daemon: 1
Mar 09 07:42:32 MacPro gnome-keyring-daemon[1470]: discover_other_daemon: 1
Mar 09 07:42:32 MacPro gnome-keyring-daemon[1469]: discover_other_daemon: 1
Mar 09 07:42:41 MacPro cinnamon-session[1272]: WARNING: t+9.00051s: Detected that screensaver has appeared on the bus
Mar 09 07:43:01 MacPro kernel: [UFW BLOCK] IN=enp10s0 OUT= MAC=01:00:5e:00:00:01:2c:00:ab:8f:f0:80:08:00 SRC=192.168.254.254 >
Mar 09 07:43:25 MacPro cinnamon-session[1272]: WARNING: t+53.39299s: Detected that screensaver has left the bus
Mar 09 07:45:06 MacPro kernel: [UFW BLOCK] IN=enp10s0 OUT= MAC=01:00:5e:00:00:01:2c:00:ab:8f:f0:80:08:00 SRC=192.168.254.254 >
Mar 09 07:47:11 MacPro kernel: [UFW BLOCK] IN=enp10s0 OUT= MAC=01:00:5e:00:00:01:2c:00:ab:8f:f0:80:08:00 SRC=192.168.254.254 >
Mar 09 07:48:26 MacPro cinnamon-session[1272]: WARNING: t+354.29773s: Detected that screensaver has appeared on the bus
~

This time I was able to boot to LMDE GUI the first time. I'll look for kernel data.

Hmm . . .

Code: Select all

$ uname -r
6.1.0-18-amd64

[xenopeek]

Ah. Then I'm not sure the journalctl output is relevant -- do the timestamps match up with the failed boot? If the initramfs hasn't mounted your root partition yet when the it fails, the system messages can't be written to disk. AFAIK once the initramfs loads the actual init system from your mounted root partition that's when system messages can be flushed from memory to disk. If it fails before that they are only in memory and lost on reboot.

Problems with the boot stage are a headache to troubleshoot

[este.el.paz]

@xenopeek:

Thanks for the follow-up . . . I **thought** I was going to be able to mark this as "solved" since grub is now booting the xx -18 kernel, because after posting the data I was able to revive from suspend. But, testing it again I was one time able to boot cleanly to LMDE, but it did not revive.

The "journalctl" data was from the approx times trying to boot LMDE from this morning, the more or less same data was repeated multiple times, I just selected the last round of it.

And then, testing again from cold boot, it went back to the initramfs shell, the shell that doesn't respond to commands, etc.

So, not out of the woods on getting LMDE to basic function . . . .

Back in straight up Trixie to post this.

[xenopeek]

Possibly the failing to resume from suspend and failed cold boot after is related. I don't know enough about Apple or Nvidia devices to take a further guess what to look at. IIRC issues with resuming from suspend can sometimes be worked around by reducing the maximum sleep state depth in the UEFI, so the system stays a little bit more awake and make works around whatever bug you've hit on.

[este.el.paz]

Possibly the failing to resume from suspend and failed cold boot after is related. I don't know enough about Apple or Nvidia devices to take a further guess what to look at. IIRC issues with resuming from suspend can sometimes be worked around by reducing the maximum sleep state depth in the UEFI, so the system stays a little bit more awake and make works around whatever bug you've hit on.

Yes. Both seem to be "problematic" vis nvidia and apple machines. Based upon what recently fixed the problem in openSUSE, where nvidia overwrites nouveau in /etc/modprobe.d . . . I navi'd over to that directory and found . . . nothing, or nothing that showed "nvidia" as it did in Leap 15.6 . . . .

So, I also am "out of ideas" on it. : - ) I guess I'll try to get to it to see if running apt dist-upgrade will find its way out of the quagmire . . . .

No worries on time, I have 6 other linux OSs to choose from on this machine . . . I just like a different OS for each day. Now I have to double up on one for a couple of days . . . boring. : - 0