Created attachment 14804 [details]
files list

Created attachment 14807 [details]
files list

Updated files list

Attachment 14804 is obsolete: 0 => 1

RH x86_64

uname -r
6.6.65-1.mga9

Both
systemctl status shorewall.service
systemctl status shorewall6.service

Looks good

Ethernet OK
Graphic Card use radeon OK
Audio/Video OK
Webcam OK
Mount ISOs with dkms-vhba+cdemu-client OK

mga9-64 linus flavour OK on my workstation svarten: AMD GPU, Plasma X11.

__Filesystems
boot: ext4
in LVM on a LUKS encrypted partition: / ext4, /home ext4, swap, swap2
big rust drive: plain ext4

__Clean update
using drakrpm, filtered on updates, testing repo enabled as updates

vt switching: OK
suspend-resume: OK
hibernate-restore: OK on second try, see *) below.

Running, various desktop apps, flatpak, syncthing, nextcloud client, dropbox, libreoffice, thunderbird, firefox...

VirtualBox 7.0.20 host with Guest Windows 7, using locally dkms built kmod
Tested dynamic window resizing, USB 2 flash disk, host folder sharing write protected and not, bidirectional clipboard, drag file from Dolphin to Explorer, Internet video in Firefox.

[morgan@svarten ~]$ dkms status | grep 65-1
virtualbox, 7.0.20-1.mga9, 6.6.65-1.mga9, x86_64: installed 

[morgan@svarten ~]$ inxi -SMCG
System:
  Host: svarten.tribun Kernel: 6.6.65-1.mga9 arch: x86_64 bits: 64
  Desktop: KDE Plasma v: 5.27.10 Distro: Mageia 9
Machine:
  Type: Desktop Mobo: ASRock model: P55 Pro serial: <superuser required>
    BIOS: American Megatrends v: P2.60 date: 08/20/2010
CPU:
  Info: dual core model: Intel Core i7 870 bits: 64 type: MT MCP cache:
    L2: 512 KiB
  Speed (MHz): avg: 1291 min/max: 1200/2934 cores: 1: 1291 2: 1291 3: 1291
    4: 1291
Graphics:
  Device-1: Advanced Micro Devices [AMD/ATI] Navi 24 [Radeon RX 6400/6500
    XT/6500M] driver: amdgpu v: kernel
  Display: x11 server: X.org v: 1.21.1.8 with: Xwayland v: 22.1.9 driver: X:
    loaded: amdgpu,v4l dri: radeonsi gpu: amdgpu resolution: 3840x2160~60Hz
  API: EGL v: 1.5 drivers: kms_swrast,radeonsi,swrast
    platforms: gbm,x11,surfaceless,device
  API: OpenGL v: 4.6 vendor: amd mesa v: 24.2.8 renderer: AMD Radeon RX
    6400 (radeonsi navi24 LLVM 15.0.6 DRM 3.54 6.6.65-1.mga9)


---

* Strange hibernate fail:
On first attempt it did not shut off but returned to login.

Here are contiguous lines from system journal:

dec 13 11:21:23 svarten.tribun kernel: PM: Image saving progress:  90%
dec 13 11:21:23 svarten.tribun kernel: PM: hibernation: Wrote 6326008 kbytes in 44.41 seconds (142.44 MB/s)
dec 13 11:21:23 svarten.tribun kernel: PM: hibernation: Basic memory bitmaps freed
dec 13 11:21:23 svarten.tribun kernel: OOM killer enabled.
dec 13 11:21:23 svarten.tribun kernel: Restarting tasks ... done.
dec 13 11:21:23 svarten.tribun kernel: PM: hibernation: hibernation exit
dec 13 11:21:23 svarten.tribun kernel: RTL8211B Gigabit Ethernet r8169-0-200:00: attached PHY driver (mii_bus:phy_addr=r8169-0-200:00, irq=MAC)
dec 13 11:21:23 svarten.tribun rtkit-daemon[1320]: The canary thread is apparently starving. Taking action.
dec 13 11:21:23 svarten.tribun systemd-sleep[467068]: Failed to put system to sleep. System resumed again: No space left on device

I would think that "hibernation: Wrote 6326008 kbytes in 44.41 seconds (142.44 MB/s)" means it did succeed writing it all.  - But still a few lines after: "No space left on device"

Back at desktop "to try something" i closed VirtualBox GIU (i did shut down guest already before hibernating), launced it again and run guest, and closed it. According to gkrellm at this moment: about 5 of 16 GB ram was used, and about 23 of 26 GB swap available.
And this time it succeeded to hibernate.
I regret not checking before previous attempt, but i closed no other app and there are 20+ GB more space then needed, plus it do compression... How did it think "No space left on device"?  And why OK the second try?

CC: (none) => fri

(In reply to Morgan Leijström from comment #4)
> hibernate-restore: OK on second try, see *) below.

It is OK. I forgot this system because historical debacle with diskdrake quirks have two swap partitions, and resume apparently is supported using only one, which happened to be the smaller one.  So an Operator/tool failure.

[morgan@svarten ~]$ swapon
NAME      TYPE       SIZE USED PRIO
/dev/dm-2 partition 19,5G 1,6G   -2
/dev/dm-3 partition  5,9G   0B   -3

(In reply to Morgan Leijström from comment #4)

> mga9-64 linus flavour OK on my workstation svarten: AMD GPU, Plasma X11.
>
> __Filesystems
> boot: ext4
> in LVM on a LUKS encrypted partition: / ext4, /home ext4, swap, swap2
> big rust drive: plain ext4
>
> __Clean update
> using drakrpm, filtered on updates, testing repo enabled as updates
>
> vt switching: OK
> suspend-resume: OK
> hibernate-restore: OK on second try, see *) below.
>
> Running, various desktop apps, flatpak, syncthing, nextcloud client,
> dropbox, libreoffice, thunderbird, firefox...
>
> VirtualBox 7.0.20 host with Guest Windows 7, using locally dkms built kmod
> Tested dynamic window resizing, USB 2 flash disk, host folder sharing write
> protected and not, bidirectional clipboard, drag file from Dolphin to
> Explorer, Internet video in Firefox.
>
> [morgan@svarten ~]$ dkms status | grep 65-1
> virtualbox, 7.0.20-1.mga9, 6.6.65-1.mga9, x86_64: installed
>
> [morgan@svarten ~]$ inxi -SMCG
> System:
>   Host: svarten.tribun Kernel: 6.6.65-1.mga9 arch: x86_64 bits: 64
>   Desktop: KDE Plasma v: 5.27.10 Distro: Mageia 9
> Machine:
>   Type: Desktop Mobo: ASRock model: P55 Pro serial: <superuser required>
>     BIOS: American Megatrends v: P2.60 date: 08/20/2010
> CPU:
>   Info: dual core model: Intel Core i7 870 bits: 64 type: MT MCP cache:
>     L2: 512 KiB
>   Speed (MHz): avg: 1291 min/max: 1200/2934 cores: 1: 1291 2: 1291 3: 1291
>     4: 1291
> Graphics:
>   Device-1: Advanced Micro Devices [AMD/ATI] Navi 24 [Radeon RX 6400/6500
>     XT/6500M] driver: amdgpu v: kernel
>   Display: x11 server: X.org v: 1.21.1.8 with: Xwayland v: 22.1.9 driver: X:
>     loaded: amdgpu,v4l dri: radeonsi gpu: amdgpu resolution: 3840x2160~60Hz
>   API: EGL v: 1.5 drivers: kms_swrast,radeonsi,swrast
>     platforms: gbm,x11,surfaceless,device
>   API: OpenGL v: 4.6 vendor: amd mesa v: 24.2.8 renderer: AMD Radeon RX
>     6400 (radeonsi navi24 LLVM 15.0.6 DRM 3.54 6.6.65-1.mga9)
>
>
> ---
>
> * Strange hibernate fail:
> On first attempt it did not shut off but returned to login.
>
> Here are contiguous lines from system journal:
>
> dec 13 11:21:23 svarten.tribun kernel: PM: Image saving progress:  90%
> dec 13 11:21:23 svarten.tribun kernel: PM: hibernation: Wrote 6326008 kbytes
> in 44.41 seconds (142.44 MB/s)
> dec 13 11:21:23 svarten.tribun kernel: PM: hibernation: Basic memory bitmaps
> freed
> dec 13 11:21:23 svarten.tribun kernel: OOM killer enabled.
> dec 13 11:21:23 svarten.tribun kernel: Restarting tasks ... done.
> dec 13 11:21:23 svarten.tribun kernel: PM: hibernation: hibernation exit
> dec 13 11:21:23 svarten.tribun kernel: RTL8211B Gigabit Ethernet
> r8169-0-200:00: attached PHY driver (mii_bus:phy_addr=r8169-0-200:00,
> irq=MAC)

> dec 13 11:21:23 svarten.tribun rtkit-daemon[1320]: The canary thread is
> apparently starving. Taking action.

^^^^^ for this try with the rtkit from updates_testing, maybe could help.

> dec 13 11:21:23 svarten.tribun systemd-sleep[467068]: Failed to put system
> to sleep. System resumed again: No space left on device
>
> I would think that "hibernation: Wrote 6326008 kbytes in 44.41 seconds
> (142.44 MB/s)" means it did succeed writing it all.  - But still a few lines
> after: "No space left on device"

how did you get the hibernation? From:

1) echo disk > /sys/power/state ?
2) systemctl hibernate ?
3) from Plasma Menu -> Power Session -> Hibernate ?

Does change if you change the way how you get the hibernation?

>
> Back at desktop "to try something" i closed VirtualBox GIU (i did shut down
> guest already before hibernating), launced it again and run guest, and
> closed it. According to gkrellm at this moment: about 5 of 16 GB ram was
> used, and about 23 of 26 GB swap available.
> And this time it succeeded to hibernate.
> I regret not checking before previous attempt, but i closed no other app and
> there are 20+ GB more space then needed, plus it do compression... How did
> it think "No space left on device"?  And why OK the second try?

Hibernation uses swap space, so apparently if swap space is already used or busy for something, then there won't remain for hibernation.

A tip is usually to keep a huge swap space (apart) of big size, e.g. of 1.5-2 times the amount of memory, to be enabled with swapon on demand, and use as hibernation (i.e. resume) partition, just before doing the hiberation (of course such extra swap partition should match the "resume=..." in boot cmdline or the entry in /sys/power/resume). E.g. if you have 32 GB of RAM and a few swap, then get 40GB extra (reserved) swap. The data in the other smaller swap partition would remain there, while the RAM will be moved to the bigger resume/hibernation partition.

"Probably" (which means I ahven't completely verified) it might also be influenced if the memory is too much fragmented and there aren't enough big contiguos memory blocks. In this case nother tip if you are using emulators such as VirtualBox that uses a lot of memory blocks and might defrag the memory, is to enable the Huge Pages; "sysctl vm.nr_hugepages" would tell how much have actually of them, and with: "sysctl -w vm.nr_hugepages=<num_of_hugepages>" would alter it (this is a volatile command for the booted session and need to be consolidated in /etc/sysctl.d/*).

Another stuff which might help, is to use the zram. Of course this is adding some more complexity in the hibernation, but seems to work. The simplest way is to install the package "zram" (e.g. from updates_testing), and configure a percentage of memory to reserve for it on /etc/sysconfig/zram, through the FACTOR=..., then "systemctl enable mkzram" would make it permament to system boot. With 16 GB of RAM usually a 20% is an adequate value. Apparently this is also to be "protective" for SSD/nvme disks, because as being "compressed swap" at high priority then "should" preserve the disk life cycles against small writing caused in the conventional swap. Note that in mga10 the tool for starting zram has been joined by another alternative package called rust-zram-generator (such package is not available in mga9), which seems the new standard tool.

In the end, this is affecting only kernel-linus or also stock kernel?

(In reply to Giuseppe Ghibò from comment #6)
> (In reply to Morgan Leijström from comment #4)

Thank you for replies, you probably wrote it before you saw my Comment 3.

I always use Plasma menu when testing hibernation and suspending (unless i say other)


> dec 13 11:21:23 svarten.tribun rtkit-daemon[1320]: The canary thread is
> apparently starving. Taking action.

^^^^^ for this try with the rtkit from updates_testing, maybe could help.

This is with the rtkit update.
Looking in journal the message I see the message several times fort months since until including now.



> In the end, this is affecting only kernel-linus or also stock kernel?

I happened to hit it when testing server flavour too, but this time it aborted earlier, before starting to save the image, with the message

dec 13 12:27:18 svarten.tribun systemd-sleep[20209]: Failed to put system to sleep. System resumed again: Cannot allocate memory

I then dawned on me I should check how i had set up swap on this system...!

---

Good thing: I have thus tested that it aborts and returns nicely (although it may take a minute or so...)  when there is too little room in swap :)

/Users could wish the desktops could tell immediately, but that would be hard, the way hibernation works and use swap./

(In reply to Morgan Leijström from comment #5)
> (In reply to Morgan Leijström from comment #4)
> > hibernate-restore: OK on second try, see *) below.
> 
> It is OK. I forgot this system because historical debacle with diskdrake
> quirks have two swap partitions, and resume apparently is supported using
> only one, which happened to be the smaller one.  So an Operator/tool failure.
> 
> [morgan@svarten ~]$ swapon
> NAME      TYPE       SIZE USED PRIO
> /dev/dm-2 partition 19,5G 1,6G   -2
> /dev/dm-3 partition  5,9G   0B   -3


Yes, exacly, AFAIK, the system supports only ONE hibernation partition, and is the partition specified in the resume=... parameter at boot cmdline, or can be changed runtime at /sys/power/resume. No idea how diskdrake choose the resume partition, probably the first created.

In theory you can have also multiple resume partitions, but only one used at time. Also unless changed recently, AFAIK you can have only ONE resume=... entry in boot cmdline, and NOT multiple of them being imagined as a huge "logical resume partition" which is the sum of all them. Also in theory you can have a system where you keep 2 distinct resume partition (e.g. swap1 and swap2), once you boot with resume=swap1 and hibernate (and resume) on (from) it, and another time you boot with resume=swap2 and hibernate (and resume) on (from) it. But since the hibernation is also keeping the status of memory, and the memory keeps the status of regular partitions/cache allocated disk blocks, etc. after the boot, if you resume from a partition which wasn't the latest used for hibernating, then likely occurs filesystem corruption.

The only system where this kind of stuff might work is probably a system where disks filesystems are mounted read-only. In that case the filesystem can't get corrupted, because it's never written, because stays on RAM. And the only system where this might work is probably a LIVE system. Worthwhile to test as an *excercise* to boot with MGA live (without the persistent partition), with different resume=... partitions manually set at boot cmdline, then try to resume from different resume partitions, once from swap1 and once from swap2. E.g. on VirtualBox/qemu or a real system.

(In reply to Morgan Leijström from comment #7)

> (In reply to Giuseppe Ghibò from comment #6)
> > (In reply to Morgan Leijström from comment #4)
> 
> Thank you for replies, you probably wrote it before you saw my Comment 3.
> 

yep.

> I always use Plasma menu when testing hibernation and suspending (unless i
> say other)
> 

OK. Dunno yet why but doing manually sometimes (haven't tried recently, let's say in the past) the first time fails, and the 2nd time just after works...

> 
> > dec 13 11:21:23 svarten.tribun rtkit-daemon[1320]: The canary thread is
> > apparently starving. Taking action.
> 
> ^^^^^ for this try with the rtkit from updates_testing, maybe could help.
> 
> This is with the rtkit update.
> Looking in journal the message I see the message several times fort months
> since until including now.
> 
> 
> 
> > In the end, this is affecting only kernel-linus or also stock kernel?
> 
> I happened to hit it when testing server flavour too, but this time it
> aborted earlier, before starting to save the image, with the message
> 
> dec 13 12:27:18 svarten.tribun systemd-sleep[20209]: Failed to put system to
> sleep. System resumed again: Cannot allocate memory
> 
> I then dawned on me I should check how i had set up swap on this system...!

if not enough RAM might try if zram might help.

> 
> ---
> 
> Good thing: I have thus tested that it aborts and returns nicely (although
> it may take a minute or so...)  when there is too little room in swap :)

yes. Consider also that swap itself is not hibernated, because there is no need to, i.e. if you have swap1 regular swap (and it's used), and swap2 also set as resume swap, then swap1 is not moved to swap2 before hibernating, but remains there (because it's a disk swap, so already persistent). swap2 will cointain the amount of RAM moved there. If already used a bit, then it would hibernate on an offset of it. Probably is also related and whether the free part it's contiguos or not.

Would be fine if would be added as feature upstream to have an hibernate/resume partition with priority of never being used as regular swap space before. Because if system has high memory pressure, then even allocating the resume partition just before the hibernating, later, wouldn't be granted it's not immediately used as swap.

It is also possible the hybrid-sleep:

systemctl hybrid-sleep

it should hibernate and then sleep. It has advantage of immediate resume from sleep. But if the sleep fails (e.g. because battery exausts, sleeps consume the battery anyway a bit, and furthermore some BIOS or system might not supporting deep sleep states), then it would just resume from disk hibernation.

> 
> /Users could wish the desktops could tell immediately, but that would be
> hard, the way hibernation works and use swap./

Probably the system won't know in advance whether it would fail. The only thing happening for now, is that if you haven't the resume partition big enough the hibernate entry in plasma menu won't appear at all.

(In reply to Giuseppe Ghibò from comment #8)
> Yes, exacly, AFAIK, the system supports only ONE hibernation partition, and
> is the partition specified in the resume=... parameter at boot cmdline, or
> can be changed runtime at /sys/power/resume. 

I think one way to guarantee hibernation always work is to have a partition besides swap, used *only* for hibernation, pointed to by resume=

Does it need to be defined any other place?
Do it need to be formatted as swap partition?

It only need to be as big as RAM (plus some margin for formatting and data header?) - or even a bit smaller if some compression can be guaranteed.



> No idea how diskdrake choose
> the resume partition, probably the first created.
Bug 33787 - Diskdrake do not handle swap fully - should do, or warn and explain. (critical)


And yes you do have some ideas to tinker with if one had the time :)

(In reply to Giuseppe Ghibò from comment #9)
> 
> if not enough RAM might try if zram might help.

There was already 2/3 of 16GB RAM unused.

Or do you mean zram would make the resume image smaller?

Isn't the image well compressed already?
I note that during restore it say "decompressing" for each 10% processed. 

 
> It is also possible the hybrid-sleep:
> 
> systemctl hybrid-sleep
I know.
It is a pity only a few DE offers hybrid in the shutdown menu.

> > /Users could wish the desktops could tell immediately, but that would be
> > hard, the way hibernation works and use swap./
> 
> Probably the system won't know in advance whether it would fail. The only
> thing happening for now, is that if you haven't the resume partition big
> enough the hibernate entry in plasma menu won't appear at all.

IIRC Plasma is more stupid and offers hibernation just swap exist at all.

(In reply to Morgan Leijström from comment #10)

> (In reply to Giuseppe Ghibò from comment #8)
> > Yes, exacly, AFAIK, the system supports only ONE hibernation partition, and
> > is the partition specified in the resume=... parameter at boot cmdline, or
> > can be changed runtime at /sys/power/resume. 
> 
> I think one way to guarantee hibernation always work is to have a partition
> besides swap, used *only* for hibernation, pointed to by resume=
> 
> Does it need to be defined any other place?
> Do it need to be formatted as swap partition?

the hibernation partition is a regular swap partition and should be formatted as a swap partition. Also before being used for hibernation it needs to be in the active system swap, i.e. added to the system swap space with "swapon" just before being used, or with mount at boot. The resume=... parameter in the boot cmdline would tell that such swap partition IS the partition where to hibernate (if system is already booted) or where to resume from if the system is being booted. Also the hibernation partition might be changed on the fly changing the /sys/power/resume content (with echo <partition> /sys/power/resume if you want). E.g. you might have a system resumed from partition A, and then hibernated to a partition B. 

It won't hibernate on the biggest partition, but on the active swap partition defined for resume. Of course there is the needing of matching between hibernation partition written and hibernation partition read.

What you can have is to have more swap partitions with different priority, those with highest priority would be used first as regular swap space. The resume/hibernate swap partition should have in theory the lowest (i.e. low in rank of being used) priority. In this way the hibernation partition would be "filled" as latter as regular swap. But even if latter in list, or even to the point of being activated with "swapon" just a few instants before the hibernation call (if it's not swapon-ed then system doesn't see it and can't hibernate to it) doesn't grant 100%, IMHO, the chance of being completely free just for hibernation, but would just reduce its probability (e.g. if you have a system with high memory pressure and it's hungry of RAM, then it would fill any new swap space as soon as a new swap space it's added to the system).

> 
> It only need to be as big as RAM (plus some margin for formatting and data
> header?) - or even a bit smaller if some compression can be guaranteed.
> 

I haven't tried to detect the lowest minimal size. As a rule of thumb, I use RAM size plus some margin, e.g. 8 GB extra, just in case the regular swap partition is already filled, or there are holes/fragments and new swap space used. And yes, as you noticed, swap image it's probably compressed for faster access.

> > No idea how diskdrake choose
> > the resume partition, probably the first created.
> Bug 33787 - Diskdrake do not handle swap fully - should do, or warn and
> explain. (critical)
> 
> 
> And yes you do have some ideas to tinker with if one had the time :)
> 
> (In reply to Giuseppe Ghibò from comment #9)
> > 
> > if not enough RAM might try if zram might help.
> 
> There was already 2/3 of 16GB RAM unused.

swap space is used a bit for some tiny data even if there is plenty of RAM free. swappiness can be controlled by the vm.swappiness sysctl parameter. It can be even reduced to a lower value or even to 0 but doing so might have other side-effects.

> 
> Or do you mean zram would make the resume image smaller?
> 

zram is not related to hibernation images, but would act indirectly in this subject, at least IMHO. It acts as a compressed swap space of high priority. So for instance if you add 20% of RAM to zram, that means that 3.2GB of RAM are used for swap, but being compressed (considering an average ratio of 1:2) means it acts as if you were adding an extra of 6.4GB of RAM to the system (of course not as fast as stock RAM, but not as slow as disk swap, even if on NVMe disks). zramctl would tell how much is used. That would act in favour of hibernation because it would use that zram swap space first, leaving other regular swap partitions free of being used, unless really being necessary. That's why apparently "protective" for NVMe.

> Isn't the image well compressed already?
> I note that during restore it say "decompressing" for each 10% processed. 
> 
>  
> > It is also possible the hybrid-sleep:
> > 
> > systemctl hybrid-sleep
> I know.
> It is a pity only a few DE offers hybrid in the shutdown menu.
> 
> > > /Users could wish the desktops could tell immediately, but that would be
> > > hard, the way hibernation works and use swap./
> > 
> > Probably the system won't know in advance whether it would fail. The only
> > thing happening for now, is that if you haven't the resume partition big
> > enough the hibernate entry in plasma menu won't appear at all.
> 
> IIRC Plasma is more stupid and offers hibernation just swap exist at all.

I wonder if someone has already suggested to add that to the Plasma MLs/forums/Bugtrackers.

(In reply to Morgan Leijström from comment #10)

> Isn't the image well compressed already?
> I note that during restore it say "decompressing" for each 10% processed. 

Yes, however the hibernation image can be avoid of being compressed if specifying at boot the parameter "hibernate=nocompress".

RH i586

installing kernel-linus-6.6.65-1.mga9.i586.rpm kernel-linus-devel-6.6.65-1.mga9.i586.rpm from //home/katnatek/qa-testing/i586
Preparing...                     #######################################################################################
      1/2: kernel-linus-devel    #######################################################################################
      2/2: kernel-linus          #######################################################################################
remove-boot-splash: Format of /boot/initrd-6.6.65-1.mga9.img not recognized

vhba (20240202-1bdk_mga9): Installing module.
.............
..........
You should restart your computer for kernel-linus

Reboot

uname -r
6.6.65-1.mga9

Wifi OK
Audio/Video OK
Webcam OK
Mount ISOs with dkms-vhba+cdemu-client OK

(In reply to Giuseppe Ghibò from comment #6)

> ^^^^^ for this try with the rtkit from updates_testing, maybe could help.


BTW, it seems that rtkit from september in core updates_testing is missing a corresponding bug.

i586 OK on my Thinkpad T43; same tests and results as 
https://bugs.mageia.org/show_bug.cgi?id=33845#c41

x86_64 OK on my Thinkpad T510; same tests and results as 
https://bugs.mageia.org/show_bug.cgi?id=33845#c47

Validating.

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2024-0393.html

Resolution: (none) => FIXED
Status: NEW => RESOLVED