list of related issues: https://bugs.mageia.org/show_bug.cgi?id=30180

I cannot comment on the sense or otherwise of all this. Perhaps somebody else can.
CC'ing a couple of people who might do better.

CC: (none) => lewyssmith, mageiatools, tmb

Elmar
Sorry to have left you; no-one commented...
Is this still an issue?

I do currently stay in Italy and have left the respective computer in Carinthia, so that I won´t see or test for this in the next few weeks to come.

Ping.

  To confess honestly I am somewhat discouraged to continue my testing effort and it hasn´t to do anything with the Mageia distribution. First of all the kernel worked quite well during the whole Alpha to Beta testing phase but I can´t use the release kernel 6.4.9-4. I don´t remember the bug it had, likely something with suspend to ram or so; using 6.3.9-desktop-1.mga9 as my relieve and rescue. In deed the same for all distros, whether I tested for OpenSUSE, Mageia or anything else. May the licenses be considered free (or see Redhat and GPL: may they be considered not) that isn´t the point for me. Most OSS Developers are paid either by some non-free economy or by some shadow services as mentioned in Comment 1. For years to come, testing since 2008 and sooner, the said/described experience to be the same. I´d consider kernel development to have the most freedom compared to other economy-paid projects since there are many contributors with exception to at least graphics device drivers paid by decisive companies. A patch to make a graphics card (initially offered as 4K ready) work with 4K had no chance to be integrated may there be as many people who speak for it as can. My Intel i915 graphics card here used to work well with 2560x1200 with Mageia 7 (if I remember it correctly) but was downgraded to feature no more than 1920x1080 since I test for Mg9. Honestly I have other sorrows than bisecting, I can´t even print the 1000 page C++ Standard (ISO/IEC 14882), I may have the first couple of pages printed but "fork: resource unavailable" is an error message you will get with OpenBSD and a Linux the like. I´d love to care about implementing tcc or C+ how I call it, which exists just on paper yet. It describes language constructs for to add to plain C until you get a full multiple inherent object oriented language (that is polymorphism, late binding, etc.) without even inheritance being a language construct per se - yes you had more than one choice on how to do it. Some hand written papers if anyone wants to see a scan or fax! (I power the phone on at this minute provided there is anyone who wants to see it.) Excuse me talking that much but I am not ready or in the mood to contribute as I´d regard it properly, today, yesterday and the few days before not even for tnef or wget. I´d also had some nice ideas for Index2Web, if possible at all I needed endurance and counteraction to realize, and I won´t get a cent for it.

Concerning this bug testing the installer is something that will come too late. Changing the swap partition and test it with the MCC is something that will require you to have a second partition usable as swap. If I came around to have one at disposition sure I would do one or another time. Then just look whether /etc/dracut.conf.d/51-mageia-resume.conf has changed accordingly and whether the result is right. Thanks to everyone by heart who did test and implement at the same time! Honestly for what I write on my own there was no other way than to do it like this. If you have running Mageia in a Qemu or VM as I know some people do, then there is nothing easier to be done! On my PB Dots E2 notebook I have a super long lasting battery but the hard disk (or to say the SSD) is being in use since some years, as you can guess, and without the free space needed for here. // Urps - Comment 6: Just a 200€ or more at Austrian-Standards, but printing currently forbidden; as the like what would make sense to me like printing/viewing the web page about the dos-exe file I had opened since some weeks ago.

fork: resource *currently* unavailable - you can´t do an ls, but an exec ls would do.

Façam vocês favor pelo me and excuse me having been rashly in comment 6. It doesn´t exist/have the hidden "planned obsolescency" with Linux device drivers, I would have supposed there: At least I have just proven, that with '6.3.9-desktop-1.mga9 #1 SMP PREEMPT_DYNAMIC Wed Jun 21 16:54:49 UTC 2023 i686 GNU/Linux' and xfwm you just need to swith off compositing with X and then I can have multiple screens and higher resolutions as before known from my Mageia 6 times here on the PB Dot S E2, Atombook: use xfwm --compositor=off or xfce4-system-settings/"Feineinstellungen der Fensterverwaltung ~ specific settings of the window manager"/"Komposit ~ Compositing"/"Anzeigekomposit aus ~ display compositing off". A nearby assumption as when you´d know approx. what compositing does: It uses up a lot, lot of graphics memory (as by the composition of different layers, all of which are kept in memory at the same time) and with a computer and graphics card that is not top end you may/will be restricted to smaller resolutions or less display area if you wanna use multiple screens. Something well to know, I am using three different screens also with my newest computing machine. I know from before that I had translucency without compositing on X, just by another X-extension that does it with less graphics memory, i.e. not keeping stuff in memory that doesn´t get displayed (shall have a look in my storeroom there, I have a lot of paper there including some printouts about the X(org)-Api. Concerning the radeon/ATI driver it is rather clear that they don´t want to have the feature that is not in their business interest if they directly pay the development of this driver. For some other pieces of touch like the WLan-PCMCIA card of my PIV, supported by the Orinoco kernel driver, I know its state to be currently broken but at least it keeps to compile (and is kept like this), so anyone how needs it and to be assumed he/she has the necessary kernel dev knowledge to knows him invited to fix it.

Orinoco driver is in the legacy kernel branch, so they normally won´t fix it for you; you would need to do yourself. Using x11-server-xorg-21.1.8-7.mga9.

Didn´t get to know it until I had to start my X-server by hand (excuse an add. comment, I value to say).

Let us go back to the original complaint:
(In reply to Elmar Stellnberger from comment #0)
> I have seen that there is a reference to the swap device in
> /etc/dracut.conf.d/51-mageia-resume.conf which is not updated automatically
> if you change your swap device in the mcc at "configure bootmanager":
> add_device+=" UUID=4abd338f-a6ac-423d-aa9e-b1709c5a2e13 "
> 
>   It may be quite seldom that someone changes the swap partition used for
> hibernation when changing the partition setup. Nonetheless I would suggest
> "configure bootloader" in mcc to check for changes of the resume device and
> if necessary regenerate the initrd with adapted parameters, if this is
> necessary. If not, which I do not suppose, 51-mageia-resume could be cropped
> alltogether.
This at least is something the Mageiatools packagers can seize. It may not matter.
Assigning appropriately.

Assignee: bugsquad => mageiatools
Whiteboard: (none) => MGA9TOO?
CC: lewyssmith => (none)
Summary: mcc: "configure bootmanager" does not update /etc/dracut.conf.d/51-mageia-resume.conf => mcc: "configure bootmanager" does not update /etc/dracut.conf.d/51-mageia-resume.conf if swap partition is changed
Source RPM: (none) => dracut