Display does not revive from suspend w/ kernel 6.1.119-1, but 5.15.177-1 does?

Support Graphics & Display
1

Folks:

Looks like a problem I filed about here in September has again returned in my Manjaro install . . . the “non-revival of display from suspend” problem . . . . Have to shut down with the power button on my '12 desktop Mac Pro w/ i7 cpu and Nvidia 780 gpu.

As in the other thread, the problem seems to happen in the newest kernel 6.1.119-1, but rolling back to the previous kernel 5.15.177-1 works properly as it has for awhile.

One other thing I noticed today, after a larger 472 package upgrade to Manjaro 25.0.0 is that grub menu showed the kernel as “5.15.173” but uname -r shows it as the “177” edition.

I checked lsmod and “nouveau” is showing up, as it should be, as previously the problem involved nvidia taking over . . . but that doesn’t seem to be the issue this time . . . .

It’s just easier to go to the latest kernel listing for Manjaro in grub, than to have to pick “advanced options” and then scroll down to the 5.15 line . . . .

Any other thoughts to test out?

2

Nvidia drivers are kernel-specific. If you don’t want to manually install the drivers, then you can install nvidia-dkms, which will automatically recompile the driver for the kernel in use.

Also note that there are far more graceful ways of rebooting the machine blindly.

  • The first method is to switch over to a character-mode virtual console — also known as a tty — by pressing CtrlAltF4 and then pressing CtrlAltDel.

  • The second method is a little more complicated and involves the Magic SysRq keys. Press and hold Alt and PrtSc/SysRq together, and while holding them down, press R,S, E, I, S, U and B, in this order.

The newer kernel will only be loaded after a reboot. You cannot replace the running kernel on-the-fly.

You can edit /etc/default/grub and tell it to always boot a certain entry by default. See GNU GRUB Manual 2.12: Simple configuration.

After editing and saving the file, you’ll need to run… :point_down:

sudo update-grub
1 Like
3

Thanks for the reply . . . so, as mentioned, I am using nouveau for the video driver, not proprietary.

Appreciate the details on the keystroke options, I’ll have to check it, one problem is the display is black . . . making any TTY entries, “blind.”

I do know that the new kernel is not running until reboot, OR in my case on that machine grub is handled by another system, so I have to reboot to that system and “update grub” there and then reboot back to Manjaro, which is what I did.

Of possible interest or relevance, I am now in a new-ish to me '12 Mac Mini, on which I more recently installed Manjaro as the linux system of choice, and it is running 6.12.11-1-manjaro kernel, and it revives the display just fine from suspend . . . . Not sure if it went through the 472 packages recently or not, but when I get back to the macPro might try to move the kernel way up, see if that works.

4

If you already knew this, I don’t understand the relevance of mentioning it in the first place. When booting with Grub from another Linux instance, it should be obvious that updating Manjaro will not update that Grub instance, so the (current booted) version will remain unchanged.

As you eventually pointed out yourself, you needed to update the other Linux system for that version to also change; and if the other system is another distribution (not Manjaro) it’s possible the version will still differ.

Did you mean the other Grub (or rather, it’s instance of os-prober) didn’t yet detect the Manjaro Grub change until you had updated the other Linux? That might be more understandable.

Regards.

1 Like
5

Yes, but the drive activity LED on the computer housing will provide you with feedback on what the machine is doing.

1 Like
6

Alrighty, I’ll give it a try at some point.

The saga continues, based upon seeing that my Mini is running 6.12.11-1 I tried to use the GUI >settings >kernel to install that same kernel in my desktop, as the Mini suspends and revives fine.

I ran it through, watching the pprocess there were some “no modules” error, but it declared the install as successful. I rebooted over to my grub handler OS and ran “update-bootloader” and shut down. On cold boot went to manjaro adv opptions in grub and no “6.12” line item, I clicked the toop line and it went to where it was the 6.1 that doesn’t revive.

Thinking that I now had “too many kernels installed” I removed a 5.4 kernel and again ran the update-bootloader. Again, no 6.12. Checking in the GUI Settings app it shows as “installed.” I then went to the next click up on “LTS/recommended” of 6.6.74 and installed that one, and just for good measure I removed another older one, say 5.5. Then I went to grub handler and ran the “grub2-mkconfig xxxxxx” && the update-bootloader & shut down.

BTW the grub handler OS is running 6.13 kernel. On cold boot, neither the 6.6 nor the 6.12 kernels are showing in grub menu, booting the top line still goes to 6.1.126-1-manjaro . . . .

Having a hard time deciding what to try next to get the kernel clicked up, showing as “installed” but not appearing in the grub advanced options or as “running” from top line . . . ???

[EDIT] After I posted that last post I suspended the machine, and then a little while later I clicked go and the machine & display revived. At that time I wasn’t realizing that the thread started with 6.1.119 . . . and then, in all of the adding and removing of kernels somehow the top grub option became 6.1.126-1. Apparently .119 didn’t revive, but .126 does?? I’ve tried it a couple of times. The main purpose of the thread was to get “revival” of the display back, so that possibly has been accomplished. Now my question is, why does the GUI kernel installer show kernels to install, that when “successfully” installed, do not appear for service to the OS??? [/EDIT]

7

If you boot with Manjaro’s instance of Grub, you should find that these kernels mentioned are indeed available; but, you are not booting with Manjaro’s Grub…

For os-prober of your “Grub handler OS” to detect a change in Manjaro’s Grub, a reboot into the “Grub handler OS” is needed.

Even so, your “Grub handler OS” will only register the currently active (default) kernel in Manjaro (a foreign OS from the perspective of your “Grub handler OS”) as detected by os-prober.

1 Like
8

… should be Manjaro.

When using another distribution’s grub as the boot loader, this is the sort of problems you will encounter. Therefore, when multi-booting with other distros, Manjaro’s grub should be the primary one.

2 Likes
11

OK, well previously to the attempt to add the newer kernels, grub menu showed 4 or 5 Manjaro kernels, not just running . . . and, as mentioned I did reboot in and out of the OS handler to update the bootloader options . . . .

But the newer kernels did not make the list . . . . Perhaps it might be interesting to add the older kernels back in and then see if the os-prober would find them.

So, I can understand how ideally Manjaro would want to be in charge of grub, as many systems seem to want to do these days. I did have grub + osprober installed on my Manjaro system, but had it on the other system as well, and that also “causes problems” . . . .

Overall Manjaro’s upgrading has gone very smoothly in comparo to other rolling installs that I have . . . right now grub is being handled by one OS . . . . Might switch it back to Manjaro at some point. But is not os-prober the same by any name? The package does what it does in whatever system it is in??

12

Manjaro uses a customized version of grub. That’s why Manjaro’s grub needs to be the primary boot loader.

1 Like
13

After an change of kernels in manjaro, You need to start “grub handler OS”, then from there recreate grub.cfg.

And I definitely agree with @Aragorn that it is best to use manjaro as grub handler.
:footprints:

1 Like
14

Yes it does – os-prober does what it does.

What os-prober does not do is detect any bootable kernel in another OS that is not the default for that OS.

In your case, os-prober (in your “Grub handler OS”) will only detect the current default kernel in Manjaro.

This has been explained several times.

Using Manjaro as your “Grub handler OS” has also been recommended several times; and I also suggest this is the better strategy.

Aside:-

Another possibility (assuming each OS is UEFI booting) is to use rEFInd 1 as the dominant bootloader, and effectively chainload each Linux OS; however, this is outside the scope of this topic.

(1. Even so, rEFInd will only detect kernels that are currently discovered.)

1 Like
15

Sir, I read your previous posts, but, it is not my finding, as I also previously posted. My os-prober is showing a number of Manjaro kernels, not just running, but it is not, as has been suggested here, picking up the two newer kernels that I installed via the GUI Manjaro settings manager . . . .

It is somewhat “moot” in that as of yesterday the newer 6.1 xxx kernel was/is reviving from suspend . . . . But as in this machine, Manjaro isn’t the primary OS, for now I’ll be leaving os-prober in the OS that is the primary, newest kernel available distro.

to the person that said “You need to recreate grub.cfg” . . . that was mentioned as being done previously . . . did not pull in the newer kernels.

I am back in Manjaro as we speak, what I do notice in the foreign os-prober is that newer variations of say 6.1. don’t get recognized. In a minute I will add the older kernels back in and do the reboot update to see if they show up, or not.

And, then, on the Mini, where Manjaro is the sole/primary OS I can test to see how adding the bleeding edge kernel is handled. For the kicks.

[EDIT] So, just reporting that I did re-install the 5.10.233-1 LTS option, went over to the foreign os-prober, updated; back into grub advanced options for Manjaro and it showed “5.10.230-1” back in the list, I selected that one and uname -r shows what was in the kernel app . . . 5.10.233-1 . . . . So that grub seems to list the larger “5.10” part, but misses the subtle “.233” aspect. So, it is showing non-running options, but apparently not the newer than running options.

It is understood that that could be improved via changing over to Manjaro as the handler, but for now, “against medical advice” leaving it. Marking this thread as solved as the 6.1.126-1 kernel does appear to revive the display. [/EDIT]

16

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.