Back in TW for the morning, yet another 6.13 kernel showed in zypper, 6.13.4 . . . with some “firmware” packages, ran it through with “high hopes” . . . on reboot it went to 6.13.4 and on reviving form the first suspend . . . no dice.
Back in 6.1.2.6 . . . way back in time lapse . . . weeks?? months??? Wow, say it ain’t so . . . but it is.
I saw on Fosstodon that 6.14 kernel is available from Torvalds . . . maybe that will restore basic function?? Or, not?? Stay tuned to this channel to find out . . . .
1 Like
@non_space I have my doubts, old technology… FWIW I’m running the 6.14 series on RISCV64 Tumbleweed…
I’ve tried a few moves to get the newer kernels working, adding DEs, adding display managers . . . gdm seemed to work to revive the display one time, then failed on the second with the newer 6.13.4 kernel. Thinking about adding KDE and then kdm to see if that works, might, might not.
I wanted to remove LXQT since it didn’t actually revive the display, but then after simply running “zypper in -t pattern lxqt” I tried to reverse out and it showed it would only be removing 3 of the 118 or so that it had just installed?
I ran a google on “how to remove a pattern” and AI showed me the command “deletepattern ” . . . so I tried that and the console said, “that command does not compute.”?? Then in the regular results a bunch of threads from the forum here saying, “You can’t remove a pattern, forget about it.” Or, use YaST and remove the packages one by one??
LXQT pattern didn’t use too much space, less than gdm; but KDE will add 1.2GB of packages . . . which, if that doesn’t succeed is a lot of “bloat”??
Final question, when you say, “old technology” what constitutes the “old” of it? The mobo? Or, if the cpu was upgraded would that make it again, “new”? Or, is this a GPU problem, the GPU isn’t moving up with the software, and perhaps a newer GPU would get the machine back into the cutting edge??
This machine more or less remained unchanged for 5 years?? It does what needs to be done, just now seems to be falling back behind the techno wave. Any way to get it back into the sweet spot???
@non_space Anything less than: Intel Gen 11+ for the GPU, Nvidia Turing or better, CPU v3+ is better, but v2 will suffice, UEFI, TPM 2.0 (v1.38+ tpm2_getcap properties-fixed | grep TPM2_PT_REVISION -A2)…
1 Like
Thanks for the reply . . . the machine gets v2 support. Has EFI . . . .
Still looking at “software” or “kernel” issues involved in the problem. The 6.13xxx kernels run fine, the only problem is, if suspended then the display does not come back, otherwise, if I never used suspend all would be well.
@non_space I’m assuming no secure boot is used, likewise booting the grubx64, not shim, use secure boot is unchecked in YaST Bootloader etc?
1 Like
That is correct, no “secure boot” has been selected, booting via grub, etc. ext4 format.
I’m not in TW at the moment, I’ll have tp double check in YaST to be sure, but I did not make any selection for secure boot or using shim for any purpose.
All was running well, reviving from suspend in the latest kernel, until the 2082 package upgrade, and then since then, not reviving. And, in the 4 or more kernel upgrades from what was 6.12.6 . . . each failing to consistently revive the display . . . but running fine up until suspended.
@non_space Well I have a HP Stream 11 running MicroOS and Hyprland, that suspends/hibernates fine. I just setup another Tumbleweed system with GNOME, hadn’t got around to configuring and it suspended/hibernated fine (it doesn’t now as disabled). All are up to date snapshot wise…
Some kernel changes related to suspend are likely involved?
Likewise I don’t believe users with newer hardware should be penalized from the potential security and performance improvements on the likes of Tumbleweed/MicroOS to support older hardware. Now in saying that, I only have one system that meets the requirements I indicated, a Beelink N100 MiniPC running Aeon. Sure I have lots of older hardware, mainly running Leap as servers for various tasks.
OK, so you are saying I am being selfish for wanting TW to support my ancient hardware?? : - 0
So, I did reboot back into TW and in checking YaST Bootloader in fact “secure boot support” was checked on?? Which I didn’t select, somehow the “system” must have done that w/o asking me about it??
I unchecked it. There were a number of zypper upgrades to run, including a “displaymanager-sysconfig xxxx” which I ran through. I rebooted and this time went for the 6.13.4 kernel option . . . ran it for a few minutes and then suspended the machine. A few minutes later I tried to resuscitate and the display did not respond . . . .
So, perhaps the machine is not keeping pace with the race of technology. I do wonder why it is that zypper does not “understand” the machine and provide upgrades that will maintain the system in the machine, possibly mentioning that it is compensating for the ancient machine??? Instead it adds kernels that are not providing basic function.
In part of my testing I have other OSs running and today is Trixie day, apt brought in a new kernel, 6.12.12 . . . which is newer than the 6.12.6 kernel that works in TW, but nothing since then does . . . . I’ll be suspending it in a minute . . . I anticipate that Trixie will revive the display . . . .
Certainly not the end of the world to have to run 6.12.6 for the life of the TW install. I have other options, I have now Leap 16 running on this machine. It’s not mission critical to have the newest kernel, it’s just “fun” . . . .
Perhaps switching out of the nvidia GPU to something newer that still runs on the '12 machine would get me away from the nvidia quagmires that keep showing up as having something to do with the recurring problem to not revive the display as the TW software speeds away from the pace of linux support provided by nvidia???
@non_space Not at all, just keeping it running to your requirements may not be achievable going forward and getting/expecting a fix… I would suggest creating a bug report.
That was just “humor” . . . .
Bug report was filed shortly after the thread was started against the “kernel,” but Takashi says “unrelated” . . . more or less crickets on the bug report. No suggestions about where to file it, etc.
Just for research purposes, as I thought, 6.12.12 kernel in Trixie is reviving the display properly, so newer kernel that works in TW . . . working for basic function.
Which does IMHO point to something in the TW iterations of the kernel??? Same machine, etc.
Hmm . . . well I see in there a link to one of my other threads . . . but at that time it didn’t seem to pan out, specifically in reference to getting grub to show kernel IDs, which it wasn’t doing in 15.6 . . . .
Might have been a confluence of snafu’s with “secure boot support” being enabled and then that needing a key update to get function for suspend?
I’ll have to try to read for deeper understanding in that thread to see if it will provide a result regarding revival of the display.
Looked over the other thread on hibernation, ran the grep dmesg and got:
# dmesg |grep -i hiber
[ 0.037120] [ T0] PM: hibernation: Registered nosave memory: [mem 0x00000000-0x00000fff]
[ 0.037122] [ T0] PM: hibernation: Registered nosave memory: [mem 0x0008f000-0x0008ffff]
[ 0.037124] [ T0] PM: hibernation: Registered nosave memory: [mem 0x000a0000-0x000fffff]
[ 0.037126] [ T0] PM: hibernation: Registered nosave memory: [mem 0x7592e000-0x7592efff]
[ 0.037128] [ T0] PM: hibernation: Registered nosave memory: [mem 0x7595a000-0x7595afff]
[ 0.037130] [ T0] PM: hibernation: Registered nosave memory: [mem 0x7bfa3000-0x7bfa3fff]
[ 0.037132] [ T0] PM: hibernation: Registered nosave memory: [mem 0x7bfa3000-0x7bfa3fff]
[ 0.037134] [ T0] PM: hibernation: Registered nosave memory: [mem 0x7f404000-0x7f419fff]
[ 0.037136] [ T0] PM: hibernation: Registered nosave memory: [mem 0x7f423000-0x7f55efff]
[ 0.037139] [ T0] PM: hibernation: Registered nosave memory: [mem 0x7f585000-0x7f5aefff]
[ 0.037141] [ T0] PM: hibernation: Registered nosave memory: [mem 0x7f683000-0x7f6aefff]
[ 0.037143] [ T0] PM: hibernation: Registered nosave memory: [mem 0x7f78f000-0x7f7aefff]
[ 0.037145] [ T0] PM: hibernation: Registered nosave memory: [mem 0x7f7ff000-0x7fffffff]
[ 0.037146] [ T0] PM: hibernation: Registered nosave memory: [mem 0x80000000-0xfed1bfff]
[ 0.037147] [ T0] PM: hibernation: Registered nosave memory: [mem 0xfed1c000-0xfed1ffff]
[ 0.037148] [ T0] PM: hibernation: Registered nosave memory: [mem 0xfed20000-0xffd1ffff]
[ 0.037148] [ T0] PM: hibernation: Registered nosave memory: [mem 0xffd20000-0xffd4ffff]
[ 0.037149] [ T0] PM: hibernation: Registered nosave memory: [mem 0xffd50000-0xffffffff]
[ 5.534058] [ T1] systemd[1]: Clear Stale Hibernate Storage Info was skipped because of an unmet condition check (ConditionPathExists=/sys/firmware/efi/efivars/HibernateLocation-8cf2644b-4b0b-428f-9387-6d876050dc67).
I didn’t run the “echo regen key” command, because it seems like hibernation does “exist” in my system??
I also checked the GPG keys in YaST and there were a couple of expired keys there, I deleted them. The rest were valid into '26 . . . . That was before I checked the hibernate thread to see that “regen” command . . . left undone at this point.
Page search here shows no other instance of 8cf2644b in this thread. Can you find one anywhere among your system’s entire library of UUIDs, or find a match among grub.cfg stanzas? I would expect to see one on a swap partition or associated with a swap file.
1 Like
Hmm . . . since I don’t use “hibernate” I didn’t think on that too much, but. no, that didn’t show up in lsblk -f or blkid or in /etc/fstab.
I tried to look in “cat /boot/grub2/grub.cfg” but it seemed to only show the last three installs in the machine, scrolling up to the top didn’t get me into sda to check where TW is installed. I must have the terminal set for a minimum number of lines that grub.cfg exceeds and didn’t see where I could select more . . . .
But, I would assume that that UUID does not exist to be found, it was somehow “created” as there, without being there?? Usually, from recollection of some file, or from the grub boot menu, there is a “revive from” line that will be a swap UUID for the system, but that number did not show up in the listing of blkids, etc.
Where else could I look??? Or what is learned from this information?? I usually only “suspend” I rarely “hibernate” as there was long ago in the PPC iterations problems with getting back from hibernate, as there now is with suspend.
[edit] I switched to unlimited lines from 512 in the console and that did bring in the TW info . . . as I thought that UUID was not included there. [/edit]
“There” exactly where, associated with what? Is it present in any /etc/default/grub file or in any file in an /etc/dracut.conf.d/ directory? Is it present in lsblk -f or blkid output, and if so associated with what? Can you grep it from any lsinitrd output? Dots need to be connected if a problem source is to be identified and corrected.
Latest kernel, 6.13.5 installed this AM via zypper dup, did not revive the display.
As per request:
# uname -a
Linux no-pc.home 6.12.6-1-default #1 SMP PREEMPT_DYNAMIC Thu Dec 19 17:23:25 UTC 2024 (fb072de) x86_64 x86_64 x86_64 GNU/Linux
no # inxi -S
System:
Host: no-pc.home Kernel: 6.12.6-1-default arch: x86_64 bits: 64
Desktop: MATE v: 1.28.2 Distro: openSUSE Tumbleweed 20250302
no # cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.12.6-1-default root=UUID=929e9949-2d18-424c-be4a-80166827335b quiet mitigations=auto
no # ls -gGh /sys/firmware/efi/efivars/H*
ls: cannot access '/sys/firmware/efi/efivars/H*': Invalid argument
no # lsinitrd /boot/initrd | grep -i uuid
drwxr-xr-x 2 root root 0 Mar 3 09:48 etc/systemd/system/dev-disk-by\x2duuid-E592\x2dECD3.device.d
-rw-r--r-- 1 root root 60 Mar 3 09:48 etc/systemd/system/dev-disk-by\x2duuid-E592\x2dECD3.device.d/timeout.conf
lrwxrwxrwx 1 root root 42 Mar 3 09:48 etc/systemd/system/initrd.target.wants/dev-disk-by\x2duuid-E592\x2dECD3.device -> ../dev-disk-by\x2duuid-E592\x2dECD3.device
-rwxr-xr-x 1 root root 35000 Feb 24 09:16 usr/lib64/libuuid.so.1.3.0
lrwxrwxrwx 1 root root 16 Mar 3 09:48 usr/lib64/libuuid.so.1 -> libuuid.so.1.3.0
-rw-r--r-- 1 root root 92 Mar 3 09:48 var/lib/dracut/hooks/emergency/80-\x2fdev\x2fdisk\x2fby-uuid\x2fE592-ECD3.sh
-rw-r--r-- 1 root root 37 Mar 3 09:48 var/lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-uuid\x2fE592-ECD3.sh
# cat /etc/default/grub
GRUB_DISABLE_OS_PROBER="false"
GRUB_TERMINAL="gfxterm"
GRUB_HIDDEN_TIMEOUT="0"
GRUB_TIMEOUT="8"
GRUB_ENABLE_CRYPTODISK="n"
GRUB_GFXMODE="auto"
GRUB_DISABLE_RECOVERY="true"
GRUB_DISTRIBUTOR=
GRUB_DEFAULT="saved"
SUSE_BTRFS_SNAPSHOT_BOOTING="true"
GRUB_USE_LINUXEFI="true"
GRUB_CMDLINE_LINUX_DEFAULT="quiet mitigations=auto"
GRUB_CMDLINE_XEN_DEFAULT="vga=gfx-1024x768x16"
GRUB_BACKGROUND=
GRUB_THEME=/boot/grub2/themes/openSUSE/theme.txt
cd /etc/dracut.conf.d/
no-pc:/etc/dracut.conf.d # ls
10-persistent_policy.conf 99-debug.conf
The lsblk f and blkid did not show that UUID, as mentioned above.
So, in the interest of science, I was able to boot my Sid install using 6.12.17 kernel and the display revives quickly from suspend.
So that is a newer kernel than the 6.12.6 kernel that is the last kernel in TW that will do the same basic function.
Debian doesn’t seem to offer the latest kernels in apt . . . I’d like to try to get into the 6.13.xxx iterations there to test it further.
But, this does show that the machine can revive the display in a post 6.12.6 kernel, whereas TW does not.
Are there any other tests to run in TW to check for where in the system some problem(s) are comingling to create this not waking the display problem?
1 Like