ah you did submit a new one.  :-)

CC: (none) => brtians1

Is this not already in progress?
 https://bugs.mageia.org/show_bug.cgi?id=32082#c51
says "kernel-6.4.16-5.mga9 now in updates testing" 2023-10-31.
Perhaps that does not include all the pkgs Giuseppe lists.

CC: (none) => lewyssmith
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=32082

Companion of this bug for kernel-linus is https://bugs.mageia.org/show_bug.cgi?id=32485.

(In reply to Lewis Smith from comment #2)

> Is this not already in progress?
>  https://bugs.mageia.org/show_bug.cgi?id=32082#c51
> says "kernel-6.4.16-5.mga9 now in updates testing" 2023-10-31.
> Perhaps that does not include all the pkgs Giuseppe lists.

the bug #32082 about suspend problems, was indeed already fixed in 6.4.16-4.mga9 (but not in 6.4.16-3 that was validated). 6.4.16-5.mga9 fixes further CVEs in the meanwhile, not yet included in 6.4.16-4.mga9, so basically 6.4.16-5.mga9 supersedes 6.4.16-4.mga9.

After this 6.4.16-5.mga9 validated, I think we can move to release 6.5.x (actually 6.5.10-2.mga9 in backports_testing).

Thanks for this useful info.
So we await the release of kernel 6.4.16-5 (I have only just picked up 6.4.16-desktop-3 after an absence).

(In reply to Lewis Smith from comment #5)

> Thanks for this useful info.
> So we await the release of kernel 6.4.16-5 (I have only just picked up
> 6.4.16-desktop-3 after an absence).

6.4.16-5.mga9 is actually in updates_testing, so you need to either enable updates_testing or just manually here:

https://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/9/x86_64/media/core/updates_testing/kernel-desktop-6.4.16-5.mga9.x86_64.rpm

https://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/9/x86_64/media/core/updates_testing/kernel-desktop-devel-6.4.16-5.mga9.x86_64.rpm

(In reply to Giuseppe Ghibò from comment #0)
> This kernel add fixes for CVE-2023-5178, CVE-5090, CVE-34324, CVE-2023-5345,
> CVE-2023-39139,CVE-2023-5633, CVE-2023-5717, CVE-2023-46813, and lockups of
> bug #32082.

Sorry, I don't manage to figure out what CVE-5090 and CVE-34324 should be.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-5090 is reserved, is it that one? 
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-34324 is reserved, too.

Do I only need to insert "2023-" in CVE-5090 and CVE-34324?

CC: (none) => marja11

And I don't understand what https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-39139 has to do with the kernel, please confirm that that CVE is correct anyway

(In reply to Marja Van Waes from comment #8)

> And I don't understand what
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-39139 has to do with
> the kernel, please confirm that that CVE is correct anyway

Thanks for double-checking, you are right, it was my typo in the list above (but the patch included was right), the correct number is 39189 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-39189). Fix and comment here:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f4f8a7803119005e87b716874bec07c751efafec

For the 2023-5090 other infos here in the fix itself:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b65235f6e102354ccafda601eaa1c5bef5284d21

For the 2023-34323, other infos here in the fix itself:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=87797fad6cce28ec9be3c13f031776ff4f104cfc

Yes, we put multiple bugs in references quite often.

You listed kernel linus in this report

(In reply to katnatek from comment #12)
> You listed kernel linus in this report

Thanks for spotting. Maybe next time files list should be provided as attach, so we can edit and fix.

(In reply to Marja Van Waes from comment #10)

> Thanks Guiseppe,

yep, you need to swap the 'u' and 'i', Giuseppe. :-)

> 
> Below is what my advisory looks like. I didn't commit it to SVN yet, I don't
> know whether putting two mageia bugs in the references is allowed. And I
> assume I should add some other references. The https:git.kernel.org that you
> gave in Comment 9?

I think it's ok to provide also the git links since the CVE urls is not completely accessible.

(In reply to Giuseppe Ghibò from comment #14)
> (In reply to katnatek from comment #12)
> > You listed kernel linus in this report
> 
> Thanks for spotting. Maybe next time files list should be provided as
> attach, so we can edit and fix.

Can give a try, It takes me many tries to get well the list of qemu, xen, libvirt

(In reply to Marja Van Waes from comment #16)

> (In reply to David Walser from comment #11)
> > Yes, we put multiple bugs in references quite often.
> 
> Thx
> 
> (In reply to Giuseppe Ghibò from comment #15)
> > (In reply to Marja Van Waes from comment #10)
> 
> > 
> > I think it's ok to provide also the git links since the CVE urls is not
> > completely accessible.
> 
> Thx, added the ones for which the CVE urls aren't fully accessible yet:
>  -
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/
> ?id=b65235f6e102354ccafda601eaa1c5bef5284d21
>  -
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/
> ?id=87797fad6cce28ec9be3c13f031776ff4f104cfc
> to the advisory that was just uploaded.
> 
> The rest of the uploaded advisory is in comment 10
> Please remove the "advisory" keyword if it needs to be changed. It also
> helps when obsolete advisories are tagged as "obsolete"
> 

I noticed that the bug has itself a field 'CVE:', but seems we never used in the past.

> I assume this bug isn't assigned to QA, yet, because the report for the
> virtualbox update still needs to be created?

I hadn't time yet to write one for virtualbox-7.0.12 (any help welcome, changelog is here: https://www.virtualbox.org/wiki/Changelog-7.0#v12).

(In reply to katnatek from comment #17)

> (In reply to Giuseppe Ghibò from comment #14)
> > (In reply to katnatek from comment #12)
> > > You listed kernel linus in this report
> > 
> > Thanks for spotting. Maybe next time files list should be provided as
> > attach, so we can edit and fix.
> 
> Can give a try, It takes me many tries to get well the list of qemu, xen,
> libvirt

Yes exactly. The problem is that bug can't be edited in bugzilla later (probably it's a feature, otherwise people would modify it later and create further mess, but maybe just allowing little modification to fix typo within 24 hours could be helpful).

Package list can be taken from the packages builds log, e.g. for 6.5.9, it's like this:

https://pkgsubmit.mageia.org/uploads/done/9/core/backports_testing/20231103121134.ghibo.duvel.1614267/kernel-6.5.10-2.mga9/packages.x86_64.0.20231103121308.log

but if you missed to do immediately, then it's no longer available in packages listed at https://pkgsubmit.mageia.org, and then writing a new one is prone to errors if you just get lists from mirrors.

Anyway kernel itself also require many attempts. For 6.5.x series it's actually took to around 100 local builds to get out 2 or 3...

I am currently working on my computer with this kernel version, as I mentioned in two other bugs (I only remember 32082), it works well for me at the moment.

I have had no sleep issues and everything works as expected, applications, audio, video, restart, sleep.

Target Milestone: --- => Mageia 10
CC: (none) => joselp
Version: 9 => Cauldron

So, if a user has our current Virtualbox installed without the dkms, and he installs these updates as they are, that virtualbox will no longer work. And if he updates virtualbox without this kernel, it won't work, either. 

It seems to me that could present a bad situation if one or the other of these bugs has issues that delay it. 

Wilcal used to warn about that from a previous experience, but the experience was from before my time with QA. TMB had developed a procedure to avoid the problem. I believe I remember what it was, but I'm not sure now. I will need to look up his old kernel/virtualbox bugs to refresh my memory accurately.

CC: (none) => andrewsfarm

Found it, I think, from the another time when virtualbox and the kernel were updated at around the same time. Bug 31405 and bug 31429.

TMB put the kmods for the new virtualbox with the new kernel, but he included the kmods for the then-current kernel with the virtualbox bug. So it looks like this one is OK as it is, but I need to put a comment like this in the virtualbox bug.

(In reply to Marja Van Waes from comment #23)
> (In reply to Thomas Andrews from comment #22)
> 
> Shouldn't this update + kernel-linus (bug 32485) + virtualbox (kernel 32490)
> be validated when all three of them are ready, so they can be pushed to
> updates together?

It depends. Sometimes there would be kernel updates that were tested before TMB switched to another because of some issue or another from upstream. Some of those issues, as I recall, were quite serious, and it could happen several times in one bug before it was finally pushed. 

Meanwhile, the new virtualbox could be updated and pushed to work with the current kernel.

Just trying to remember our history, so we don't repeat old mistakes...

(In reply to Thomas Andrews from comment #26)

> (In reply to Marja Van Waes from comment #23)
> > (In reply to Thomas Andrews from comment #22)
> > 
> > Shouldn't this update + kernel-linus (bug 32485) + virtualbox (kernel 32490)
> > be validated when all three of them are ready, so they can be pushed to
> > updates together?
> 
> It depends. Sometimes there would be kernel updates that were tested before
> TMB switched to another because of some issue or another from upstream. Some
> of those issues, as I recall, were quite serious, and it could happen
> several times in one bug before it was finally pushed. 
> 
> Meanwhile, the new virtualbox could be updated and pushed to work with the
> current kernel.
> 
> Just trying to remember our history, so we don't repeat old mistakes...

OK, then probably virtualbox first, then kernel later will be the order with less problems. Then we need to add kernel-virtualbox-kernel-6.4.16-{desktop,server}-3.mga9-7.0.12-34.mga9 to the current updates_testing, which is missed.

(In reply to Giuseppe Ghibò from comment #27)
> (In reply to Thomas Andrews from comment #26)
> 
> > (In reply to Marja Van Waes from comment #23)
> > > (In reply to Thomas Andrews from comment #22)
> > > 
> > > Shouldn't this update + kernel-linus (bug 32485) + virtualbox (kernel 32490)
> > > be validated when all three of them are ready, so they can be pushed to
> > > updates together?
> > 
> > It depends. Sometimes there would be kernel updates that were tested before
> > TMB switched to another because of some issue or another from upstream. Some
> > of those issues, as I recall, were quite serious, and it could happen
> > several times in one bug before it was finally pushed. 
> > 
> > Meanwhile, the new virtualbox could be updated and pushed to work with the
> > current kernel.
> > 
> > Just trying to remember our history, so we don't repeat old mistakes...
> 
> OK, then probably virtualbox first, then kernel later will be the order with
> less problems. Then we need to add
> kernel-virtualbox-kernel-6.4.16-{desktop,server}-3.mga9-7.0.12-34.mga9 to
> the current updates_testing, which is missed.

Or to avoid further problems with packages since -34 was already build, add two new:

virtualbox-kernel-6.4.16-{desktop,server}-3.mga9-7.0.12-35.mga9.x86_64.rpm

and

virtualbox-kernel-6.4.16-{desktop,server}-5.mga9-7.0.12-36.mga9.x86_64.rpm

so to cover both kernels.

MGA9-64 Plasma, i5-2500, Intel graphics, wired Internet. 

VirtualBox had already been updated to 7.0.12. Downloaded all packages but the vbox kmods, and updated kernel-desktop. Dkms-virtualbox was already installed, so the kmods were built locally. No installation issues.

No issues to report after the update: vlc, virtualbox, libreoffice, network manager and vpn, Firefox, Thunderbird, all OK.

MGA9 64 Mac Mini GNOME Core I5 16Go RAM, Wi-Fi provide with Broadcom non free:

broadcom-wl-common-6.30.223.271-66.mga9.nonfree
dkms-broadcom-wl-6.30.223.271-66.mga9.nonfree

Updated with QA repo and RPM :

kernel-desktop-6.4.16-5.mga9.x86_64.rpm
virtualbox-kernel-6.4.16-desktop-3.mga9-7.0.12-35.mga9.x86_64.rpm
virtualbox-kernel-desktop-latest-7.0.12-35.mga9.x86_64.rpm

No issues after reboot:

Sound Ok
Video Ok
Browsing with FF Ok
Wi-Fi Ok

Problem with VitualBox:

The VirtualBox Linux kernel driver is either not loaded or not set up correctly.

It seems that's problem with my kernel.
How can I fix it ?

CC: (none) => guillaume.royer

(In reply to Guillaume Royer from comment #31)

> MGA9 64 Mac Mini GNOME Core I5 16Go RAM, Wi-Fi provide with Broadcom non
> free:
> 
> broadcom-wl-common-6.30.223.271-66.mga9.nonfree
> dkms-broadcom-wl-6.30.223.271-66.mga9.nonfree
> 
> Updated with QA repo and RPM :
> 
> kernel-desktop-6.4.16-5.mga9.x86_64.rpm
> virtualbox-kernel-6.4.16-desktop-3.mga9-7.0.12-35.mga9.x86_64.rpm
> virtualbox-kernel-desktop-latest-7.0.12-35.mga9.x86_64.rpm
> 
> No issues after reboot:
> 
> Sound Ok
> Video Ok
> Browsing with FF Ok
> Wi-Fi Ok
> 
> Problem with VitualBox:
> 
> The VirtualBox Linux kernel driver is either not loaded or not set up
> correctly.
> 
> It seems that's problem with my kernel.
> How can I fix it ?

The virtualbox driver is the one provided for previous (6.4.16-3.mga9). We update virtualbox before to avoid the problem you are facing. After virtualbox is pushed we'll update kmod to  kmod-virtualbox-7.0.12-36.mga9 with the modules for kernel-6.4.16-5.mga9.

In the meanwhile you might install dkms-virtualbox or virtualbox-kernel-6.4.16-desktop-5.mga9-7.0.12-34.mga9.x86_64.rpm (the latter admitting it won't conflicts with *-latest* things, haven't checked).

6.4.16-desktop-5.mga9 x86_64
Intel Core i9-7900X 10-core
NVIDIA GP102 [GeForce GTX 1080 Ti] driver: nouveau
Intel Ethernet I219-V driver: e1000e

Installed everything except virtualbox packages (preferred mirror has not caught up yet).
Smooth reboot.  Mate desktop working.  NFS shares mounted.  Sound (bluetooth audio) and video work with TV card.  LO writer, firefox, falkon, ristretto, mplayer working in a ruby framework.  Looks good.

CC: (none) => tarazed25

virtualbox packages still not available on my second tier mirror.
6.4.16-desktop-5.mga9 x86_64
10-core Intel Core i9-7900X
NVIDIA GP102 [GeForce GTX 1080 Ti] driver: nouveau
Intel Ethernet I219-V driver: e1000e

Installed and rebooted OK.
NFS shares in evidence.  Bluetooth connection to portable audio speaker.  TV card working with vlc and proprietary firmware.  Common desktop applications work.
glmark2 OK with Mesa graphics.  Staying with an older version of firefox for the time being.  Played a local film (*.ts) with vlc.

Keeping this running.  No regressions on a desktop machine.

MGA9-32 Xfce on Foolishness, my Dell Inspiron 5100, P4, Radeon RV200 graphics, Atheros-based wifi.

No installation issues, and no issues to report after the reboot. Looks good on this hardware.

mga9-64 OK here

HW: Intel i7-870, P55 chipset, nvidia470-470.199.02-3 on GTX750

SW: Plasma X11, Normal desktop apps

VirtualBox: MSW7 guest OK with updated virtualbox 7.0.12 but like for others problem installing guest extensions, so no further testing.

suspend-resume: like with earlier desktop kernels, at resume monitor wakes but returns to sleep. This problem is not in linus kenel.

CC: (none) => fri

(In reply to Morgan Leijström from comment #36)
> mga9-64 OK here
> 
> HW: Intel i7-870, P55 chipset, nvidia470-470.199.02-3 on GTX750

BTW, there is also a nvidia470-470.223.02 in nonfree/updates_testing.

> 
> SW: Plasma X11, Normal desktop apps
> 
> VirtualBox: MSW7 guest OK with updated virtualbox 7.0.12 but like for others
> problem installing guest extensions, so no further testing.

That's should be an upstream bug. A further problem is that if you uninstall the older VBoxAddtions then you get no more mouse control and you can't then do anything to install the new version. There is also a discussion here:

https://forums.virtualbox.org/viewtopic.php?p=542189#p542189

interesting to note how many people are still using Win7...

> 
> suspend-resume: like with earlier desktop kernels, at resume monitor wakes
> but returns to sleep. This problem is not in linus kenel.

Oh, then probably there is some  older patch in kernel-desktop that is not in kernel-linus could be the cause. Are you able to compile a kernel locally with some patch disabled, so to detect which one?

(In reply to Giuseppe Ghibò from comment #37)
> (In reply to Morgan Leijström from comment #36)
> > VirtualBox: MSW7 guest OK with updated virtualbox 7.0.12 but like for others
> > problem installing guest extensions, so no further testing.
> 
> That's should be an upstream bug. A further problem is that if you uninstall
> the older VBoxAddtions then you get no more mouse control and you can't then
> do anything to install the new version.

Thank you for the warning :)

But if user enables autorun, then insert the iso?

> There is also a discussion here:
> 
> https://forums.virtualbox.org/viewtopic.php?p=542189#p542189

But why do 
 VBoxManage extpack install --replace VBoxGuestAdditions_7.0.12.iso
fail?
https://bugs.mageia.org/show_bug.cgi?id=32490#c17


> interesting to note how many people are still using Win7...

It is absolutely needed to run some old programs i.e to view or enhance old programs and other designs, and to service machines that still have twenty years to go...
I also have XP, but bare-bones install on a laptop with real COM and LPT.
There are hardened versions of XP and 7 still used as OS in HMI on many machines. Have never seen one based on Windows 10 or later...


> > suspend-resume: like with earlier desktop kernels, at resume monitor wakes
> > but returns to sleep. This problem is not in linus kenel.
> 
> Oh, then probably there is some  older patch in kernel-desktop that is not
> in kernel-linus could be the cause. Are you able to compile a kernel locally
> with some patch disabled, so to detect which one?

No time to learn now, sorry.

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

> (In reply to Giuseppe Ghibò from comment #37)
> > (In reply to Morgan Leijström from comment #36)
> > > VirtualBox: MSW7 guest OK with updated virtualbox 7.0.12 but like for others
> > > problem installing guest extensions, so no further testing.
> > 
> > That's should be an upstream bug. A further problem is that if you uninstall
> > the older VBoxAddtions then you get no more mouse control and you can't then
> > do anything to install the new version.
> 
> Thank you for the warning :)
> 
> But if user enables autorun, then insert the iso?

Haven't tried, but I doubt. One might try, with VBox snapshots, and then back to the previous working configuration.

> 
> > There is also a discussion here:
> > 
> > https://forums.virtualbox.org/viewtopic.php?p=542189#p542189
> 
> But why do 
>  VBoxManage extpack install --replace VBoxGuestAdditions_7.0.12.iso
> fail?
> https://bugs.mageia.org/show_bug.cgi?id=32490#c17
> 
> 
> > interesting to note how many people are still using Win7...
> 
> It is absolutely needed to run some old programs i.e to view or enhance old
> programs and other designs, and to service machines that still have twenty
> years to go...
> I also have XP, but bare-bones install on a laptop with real COM and LPT.
> There are hardened versions of XP and 7 still used as OS in HMI on many
> machines. Have never seen one based on Windows 10 or later...

It's not a blame, it's just an observation based also on the number of people answering in the forum about win7. Despite being declared "unsupported" upstream since a lot of time, it's seems it still has a wide user basis.

> 
> 
> > > suspend-resume: like with earlier desktop kernels, at resume monitor wakes
> > > but returns to sleep. This problem is not in linus kenel.
> > 
> > Oh, then probably there is some  older patch in kernel-desktop that is not
> > in kernel-linus could be the cause. Are you able to compile a kernel locally
> > with some patch disabled, so to detect which one?
> 
> No time to learn now, sorry.

Ok, anyway, it's just to follow a couple of lines of commands, then comment some patch between a set, adding a '#' and running a 'bm kernel.spec', mostly it's background compilation; that would speed up the attempts since you have the hardware where it happens. joselp resolved #32082 in this way.

I'm considering using isodumper to put the guest additions iso on a usb stick, and see if that makes a difference, just for my own information. 

I also have some need for a Windows guest, for preparing state tax forms, and for a better maintenance/diagnostic program for my Laserjet CP1215 than we have in Mageia. There is also a fun app that predicts the best time to fish based on the positions of the sun and moon, but I could probably get along without that one if I had to. 

I'm considering upgrading it to Win10 - if I can still do it for free.

I'm considering using isodumper to put the guest additions iso on a usb stick, and see if that makes a difference, just for my own information. 

I also have some need for a Windows guest, for preparing state tax forms, and for a better maintenance/diagnostic program for my Laserjet CP1215 than we have in Mageia. There is also a fun app that predicts the best time to fish based on the positions of the sun and moon, but I could probably get along without that one if I had to. 

I'm considering upgrading it to Win10 - if I can still do it for free.

I think we should keep the VirtualBox problem to
Bug 32490 - Update request: virtualbox-7.0.12-2.mga9

See you there

MGA9-32 Xfce on an HP Probook 6550b, i3 M350, Intel graphics, Broadcom wifi, using the server kernel.

No installation issues, and no new issues to report. Bug 31473 has returned in Mageia 9, but I believe that's a bug in the Network Center rather than in the kernel, as it doesn't happen with Network Manager.

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

> 
> After that we'll pushed
> virtualbox, we'll provide kmod-virtualbox-7.0.12-36.mga9 for 6.4.16-5.mga9


I have deleted the current advisory from svn because the kmod-virtualbox release wasn't correct, I'll re-add it when I know which kmod-virtualbox SRPM to put in the advisory for this bug

Keywords: advisory => (none)

(In reply to Marja Van Waes from comment #44)
> (In reply to Giuseppe Ghibò from comment #29)
> 
> > 
> > After that we'll pushed
> > virtualbox, we'll provide kmod-virtualbox-7.0.12-36.mga9 for 6.4.16-5.mga9
> 
> 
> I have deleted the current advisory from svn because the kmod-virtualbox
> release wasn't correct, I'll re-add it when I know which kmod-virtualbox
> SRPM to put in the advisory for this bug

Waiting kmod-virtualbox-7.0.12-35.mga9.src.rpm is removed from updates_testing, so we can build kmod-virtualbox-7.0.10-36.mga9 to bundle with kernel 6.4.16-5.mga9.

MGA9-64, Gnome, AMD Ryzen 2600, Nouveau graphics

Installed Kernel, plus VirtualBox updates for it.


$ uname -a
Linux localhost 6.4.16-server-5.mga9 #1 SMP PREEMPT_DYNAMIC Mon Oct 30 20:33:53 UTC 2023 x86_64 GNU/Linux

- VirtualBox is working as expected
- system is behaving

So far so good here.

Tested working with intel core i5 graphics 630 modesetting driver...
Virtualbox working too...

CC: (none) => ottoleipala1

[root@mga9-test ~]# uname -a
Linux mga9-test 6.4.16-server-5.mga9 #1 SMP PREEMPT_DYNAMIC Mon Oct 30 20:33:53 UTC 2023 x86_64 GNU/Linux

Tested kernel-server on a Sony Vaio E series notebook with intel graphics and under Virt-Manager. Host is Mga9 KDE Plasma, guest is Mga9 Gnome.

No regression found.
Note that I don't use virtualbox and didn't install those packages.

Ulrich

CC: (none) => bequimao.de

Tested all kernels on real hardware Mageia 9 i586 with lxqt ,not issues in the installation.

Just the kernel-server panic once, but after boot other kernel now boot normal

uname -a
Linux cefiro 6.4.16-server-5.mga9 #1 SMP PREEMPT_DYNAMIC Mon Oct 30 23:40:46 UTC 2023 i686 GNU/Linux

Whiteboard: (none) => MGA9-32-OK

Ok, old files seems to be cleaned. new kmod build sent.

We need to update the full files list with newer modules, which are:

x86_64:
virtualbox-kernel-6.4.16-desktop-5.mga9-7.0.10-36.mga9.x86_64.rpm
virtualbox-kernel-6.4.16-server-5.mga9-7.0.10-36.mga9.x86_64.rpm
virtualbox-kernel-desktop-latest-7.0.10-36.mga9.x86_64.rpm
virtualbox-kernel-server-latest-7.0.10-36.mga9.x86_64.rpm

SRPMS
kmod-virtualbox-7.0.10-36.mga9.src.rpm

these are for virtualbox 7.0.10 which is in core/release.

This kernel add fixes for CVE-2023-5178, CVE-2023-5090, CVE-2023-34324, CVE-2023-5345, CVE-2023-39189, CVE-2023-5633, CVE-2023-5717, CVE-2023-46813

SRPMS:
kernel-6.4.16-5.mga9.src.rpm  
kmod-virtualbox-7.0.10-36.mga9.src.rpm
kmod-xtables-addons-3.24-49.mga9.src.rpm 

x86_64:
bpftool-6.4.16-5.mga9.x86_64.rpm                                    
cpupower-6.4.16-5.mga9.x86_64.rpm                                   
cpupower-devel-6.4.16-5.mga9.x86_64.rpm                             
kernel-desktop-6.4.16-5.mga9.x86_64.rpm                             
kernel-desktop-devel-6.4.16-5.mga9.x86_64.rpm                       
kernel-desktop-devel-latest-6.4.16-5.mga9.x86_64.rpm                
kernel-desktop-latest-6.4.16-5.mga9.x86_64.rpm                      
kernel-doc-6.4.16-5.mga9.noarch.rpm                                                         
kernel-server-6.4.16-5.mga9.x86_64.rpm                              
kernel-server-devel-6.4.16-5.mga9.x86_64.rpm                        
kernel-server-devel-latest-6.4.16-5.mga9.x86_64.rpm                 
kernel-server-latest-6.4.16-5.mga9.x86_64.rpm                       
kernel-source-6.4.16-5.mga9.noarch.rpm                              
kernel-userspace-headers-6.4.16-5.mga9.x86_64.rpm                   
lib64bpf-devel-6.4.16-5.mga9.x86_64.rpm                             
lib64bpf1-6.4.16-5.mga9.x86_64.rpm                                  
perf-6.4.16-5.mga9.x86_64.rpm                                       
virtualbox-kernel-6.4.16-desktop-5.mga9-7.0.10-36.mga9.x86_64.rpm
virtualbox-kernel-6.4.16-server-5.mga9-7.0.10-36.mga9.x86_64.rpm
virtualbox-kernel-desktop-latest-7.0.10-36.mga9.x86_64.rpm
virtualbox-kernel-server-latest-7.0.10-36.mga9.x86_64.rpm         
xtables-addons-kernel-6.4.16-desktop-5.mga9-3.24-49.mga9.x86_64.rpm 
xtables-addons-kernel-6.4.16-server-5.mga9-3.24-49.mga9.x86_64.rpm  
xtables-addons-kernel-desktop-latest-3.24-49.mga9.x86_64.rpm        
xtables-addons-kernel-server-latest-3.24-49.mga9.x86_64.rpm  

i586:
bpftool-6.4.16-5.mga9.i586.rpm  				     
cpupower-6.4.16-5.mga9.i586.rpm 				     
cpupower-devel-6.4.16-5.mga9.i586.rpm				     
kernel-desktop-6.4.16-5.mga9.i586.rpm				     
kernel-desktop-devel-6.4.16-5.mga9.i586.rpm			     
kernel-desktop-devel-latest-6.4.16-5.mga9.i586.rpm		     
kernel-desktop-latest-6.4.16-5.mga9.i586.rpm			     
kernel-desktop586-6.4.16-5.mga9.i586.rpm			     
kernel-desktop586-devel-6.4.16-5.mga9.i586.rpm  		     
kernel-desktop586-devel-latest-6.4.16-5.mga9.i586.rpm		     
kernel-desktop586-latest-6.4.16-5.mga9.i586.rpm 		     
kernel-doc-6.4.16-5.mga9.noarch.rpm				     
kernel-server-6.4.16-5.mga9.i586.rpm				     
kernel-server-devel-6.4.16-5.mga9.i586.rpm			     
kernel-server-devel-latest-6.4.16-5.mga9.i586.rpm		     
kernel-server-latest-6.4.16-5.mga9.i586.rpm			     
kernel-source-6.4.16-5.mga9.noarch.rpm  			     
kernel-userspace-headers-6.4.16-5.mga9.i586.rpm 		     
libbpf-devel-6.4.16-5.mga9.i586.rpm				     
libbpf1-6.4.16-5.mga9.i586.rpm  				     
perf-6.4.16-5.mga9.i586.rpm					     
xtables-addons-kernel-6.4.16-desktop-5.mga9-3.24-49.mga9.i586.rpm    
xtables-addons-kernel-6.4.16-desktop586-5.mga9-3.24-49.mga9.i586.rpm 
xtables-addons-kernel-6.4.16-server-5.mga9-3.24-49.mga9.i586.rpm     
xtables-addons-kernel-desktop-latest-3.24-49.mga9.i586.rpm	     
xtables-addons-kernel-desktop586-latest-3.24-49.mga9.i586.rpm	     
xtables-addons-kernel-server-latest-3.24-49.mga9.i586.rpm

Status comment: Packages to test on comment#13 and comment#56 => Packages to test on comment#57

mga9-64 OK here

System same as comment 36, now retesting with 

  * nvidia470 = 470.223.02-1.mga9.nonfree

  * virtualbox back at 7.0.10, using kmod-virtualbox-7.0.10-36.mga9.src.rpm

§ All normal desktop apps OK

§ VirtualBox: MSW7 guest OK: internet videos, dynamic guest window resizing, Windows update, USB2 flashstick, host folder sharing, bidirectional clipboard, and drag file from Dolphin to Explorer

( Guest additions reverted to 7.0.10 per
https://bugs.mageia.org/show_bug.cgi?id=32490#c20 )

MGA9-64 Plasma on an HP Pavilion 15-n211dx, A8-4555, HD 7600G graphics, rtl8188ee wifi. Updating from kernel 6.4.16-3, with Virtualbox 7.0.10. Dkms-virtualbox is not installed.

No installation issues, and no issues to report after the reboot. Firefox, VLC, Libreoffice, and Virtualbox all work as they should.

MGA9-64 Plasma on an HP Probook 6550b, same hardware as comment 43, and an issue has shown up.

This hardware is non-efi, with three Mageia installs on it. The "primary" install is this MGA9-64 Plasma system. There is also an MGA8-64 Plasma system, and the MGA9-32 Xfce system from comment 43. Before doing the update on the primary install, I could boot into each one without difficulty.

The primary install kernel update appeared to go smoothly, including the building and install of the broadcom-wl module. After the reboot, everything seemed to be working as it should.

But, when I tried to boot into the 32-bit install (already updated to the i586 server kernel 6.4.16-5), I was greeted with a fast-moving screen of text that eventually stopped with a kernel panic. I had to use the power button to shut it off.

Going back to the MGA9-64 system and running update-grub didn't help. The same thing happened again. Booting the MGA9-32 install into the previous i586 kernel-server 6.4.16-3 is still successful, so the system IS accessible.

I suspect a problem with the 32-bit system initrd, but I don't know how to investigate it, or correct it, and that suspicion doesn't explain why the 32-bit install booted OK before the 64-bit install was updated.

Removing the 32-bit OK until we discover just what is going on for sure.

Whiteboard: MGA9-32-OK, => (none)

dracut --regenerate-all should regenerate the initrd for all the installed kernels.

BTW, is /boot partition still having enough free space for the initrd? One kernel after another and the initrd may exaust the available space.

(In reply to Giuseppe Ghibò from comment #61)
> dracut --regenerate-all should regenerate the initrd for all the installed
> kernels.

It needed "--force" to go with that before it would do anything.

But no joy there, the 32-bit system still had the kernel panic. To add to that, the previous kernel now wouldn't boot, either. I had to drop down two more before it would.

I finally got it working again - for now, anyway - by using MCC on the MGA9-64 install to re-setup grub2. No idea what messed it up, or how long the problem's been there.

Wait... Checking fstrim.timer... Ah! inactive, disabled. Enabling and starting... Status now is waiting for next week. Running the fstrim service now, checking status... Ah! Several Gb on the /partition, over 160 on /home!

Checking fstrim and timer on the 32-bit install, same type of thing, just not so bad.

Could it be the ssd ran out of enough "free" cells to function properly?

I doubt it exausted the free cells, but you might check with smartctl -a /dev/sdX (sdX=your disk). Or gsmartcontrol if you want a GUI. Check also for Total_LBAs_Written.

Since old kernels now broken too, it could also be it messed up adding some broken cmdline option in grub.cfg that caused the panic, so check /etc/default/grub.

And it's back. I attempted to boot into MGA9-32, and came up with a blank screen. I've seen that before, and running update-grub in the MGA9-64 install usually makes it go away. This time, it generated the kernel panic again. Last three lines are:

kernel panic - not syncing: Fatal exception in interrupt
Kernel Offset: disabled
---[ end Kernel panic - not syncing: Fatal exception in interrupt]---

The MGA8 install still boots normally, as does the MGA9-64 install.

Note that katnatek saw a "kernel-server panic" once in comment 53. This install is also using i586 kernel-server, so chances are that it's not something unique to my setup after all.

Contents of MGA9-64 /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="splash quiet noiswmd resume=UUID=324f6b1d-3aba-4e5b-8a03-1af405bb6982 audit=0 vga=791"
GRUB_DEFAULT=saved
GRUB_DISABLE_OS_PROBER=false
GRUB_DISABLE_RECOVERY=false
GRUB_DISABLE_SUBMENU=n
GRUB_DISTRIBUTOR=Mageia
GRUB_ENABLE_CRYPTODISK=y
GRUB_GFXMODE=1024x768x32
GRUB_GFXPAYLOAD_LINUX=text
GRUB_SAVEDEFAULT=true
GRUB_TERMINAL_OUTPUT=gfxterm
GRUB_THEME=/boot/grub2/themes/maggy/theme.txt
GRUB_TIMEOUT=10


Contents of MGA9-32 /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="ro splash quiet noiswmd root=UUID=75debf87-e864-4006-ac61-3b2b1bada09a audit=0 resume=UUID=324f6b1d-3aba-4e5b-8a03-1af405bb6982 vga=791"
GRUB_DEFAULT=saved
GRUB_DISABLE_OS_PROBER=false
GRUB_DISABLE_RECOVERY=false
GRUB_DISABLE_SUBMENU=n
GRUB_DISTRIBUTOR=Mageia
GRUB_ENABLE_CRYPTODISK=y
GRUB_GFXMODE=1024x768x32
GRUB_GFXPAYLOAD_LINUX=text
GRUB_SAVEDEFAULT=true
GRUB_TERMINAL_OUTPUT=gfxterm
GRUB_THEME=/boot/grub2/themes/maggy/theme.txt
GRUB_TIMEOUT=10

(In reply to Thomas Andrews from comment #65)
> 
> Note that katnatek saw a "kernel-server panic" once in comment#53. This
> install is also using i586 kernel-server, so chances are that it's not
> something unique to my setup after all.
I can't help more about that, the i586 system is a laptop with broken display, and the information is a few out of the display area, It's the second time that see a kernel panic testing kernel-server, but also can't always produce the panic.

I did try to take a picture, but the image is too blurry.

I think the combination server + i586 + mageia is almost null and the other kernels works without issue

mga9-64 OK on my laptop Dell Precision M6300;
CPU: Intel(R) Core(TM)2 Duo CPU  T7500
GPU: G84GLM [Quadro FX 1600M], using kernel modesetting
Wifi: PRO/Wireless 3945ABG [Golan]

Plasma, desktop apps, firefox internet video, suspend-resume

I did some test on 32bit on a VM.

with "virtual" penryn (i.e. coreduo 2):

- kernel-desktop-6.4.9-4.mga9: boot OK
- kernel-desktop-6.4.16-3.mga9: boot OK
- kernel-desktop586-6.4.16-5.mga9: boot OK
- kernel-desktop-6.4.16-5.mga9: boot OK
- kernel-server-6.4.16-5.mga9: boot OK
- kernel-linus-6.4.16-1.mga9: boot OK

with "virtual" coreduo:

- kernel-desktop-6.4.9-4.mga9: crashes after e1000 ethernet probing
- kernel-desktop-6.4.16-3.mga9: crashes after e1000 ethernet probing
- kernel-desktop586-6.4.16-5.mga9: boot OK
- kernel-desktop-6.4.16-5.mga9: crashes after e1000 ethernet probing
- kernel-server-6.4.16-5.mga9: crashes after e1000 ethernet probing
- kernel-linus-6.4.16-1.mga9: boot OK
- kernel-desktop-6.5.11-1.mga9 (from backports_testing): crashes on e1000 but then boots anyway (without networking).

with "virtual" pentium-v1 (with MMX):

- kernel-desktop-6.4.9-4.mga9: msg it can't boot on a non-i686 machine
- kernel-desktop-6.4.16-3.mga9: msg it can't boot on a non-i686 machine
- kernel-desktop586-6.4.16-5.mga9: boot OK
- kernel-desktop-6.4.16-5.mga9: msg it can't boot on a non-i585 machine

(In reply to Thomas Andrews from comment #66)

> Contents of MGA9-64 /etc/default/grub:
> 
> GRUB_CMDLINE_LINUX_DEFAULT="splash quiet noiswmd
> resume=UUID=324f6b1d-3aba-4e5b-8a03-1af405bb6982 audit=0 vga=791"
> GRUB_DEFAULT=saved
> GRUB_DISABLE_OS_PROBER=false
> GRUB_DISABLE_RECOVERY=false
> GRUB_DISABLE_SUBMENU=n
> GRUB_DISTRIBUTOR=Mageia
> GRUB_ENABLE_CRYPTODISK=y
> GRUB_GFXMODE=1024x768x32
> GRUB_GFXPAYLOAD_LINUX=text
> GRUB_SAVEDEFAULT=true
> GRUB_TERMINAL_OUTPUT=gfxterm
> GRUB_THEME=/boot/grub2/themes/maggy/theme.txt
> GRUB_TIMEOUT=10
> 
> 
> Contents of MGA9-32 /etc/default/grub:
> 
> GRUB_CMDLINE_LINUX_DEFAULT="ro splash quiet noiswmd
> root=UUID=75debf87-e864-4006-ac61-3b2b1bada09a audit=0
> resume=UUID=324f6b1d-3aba-4e5b-8a03-1af405bb6982 vga=791"
> GRUB_DEFAULT=saved
> GRUB_DISABLE_OS_PROBER=false
> GRUB_DISABLE_RECOVERY=false
> GRUB_DISABLE_SUBMENU=n
> GRUB_DISTRIBUTOR=Mageia
> GRUB_ENABLE_CRYPTODISK=y
> GRUB_GFXMODE=1024x768x32
> GRUB_GFXPAYLOAD_LINUX=text
> GRUB_SAVEDEFAULT=true
> GRUB_TERMINAL_OUTPUT=gfxterm
> GRUB_THEME=/boot/grub2/themes/maggy/theme.txt
> GRUB_TIMEOUT=10

Are you sure you haven't exchanged the output from 32bit with the one from 64bit? E.g. I see one of them misses the root=UUID=... parameter, so where it would get the root from?

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

> - kernel-desktop-6.4.16-5.mga9: msg it can't boot on a non-i585 machine

of course there is a typo, it msg it can't boot on a non-i686 machine, not non-i585.

(In reply to Thomas Andrews from comment #60)
> MGA9-64 Plasma on an HP Probook 6550b, same hardware as comment 43, and an
> issue has shown up.

note that core i3-350 is a 64bit CPU, with 64bit extensions and up to SSE4.2 SIMD instruction set. So you are basically testing MGA9-32 on a 64bit system in 32bit mode.

(In reply to Giuseppe Ghibò from comment #70)
> (In reply to Thomas Andrews from comment #66)
> 
> 
> Are you sure you haven't exchanged the output from 32bit with the one from
> 64bit? E.g. I see one of them misses the root=UUID=... parameter, so where
> it would get the root from?

Very sure. I'm on that machine now, and just checked again. (The partitions are labeled so that I know which is which from Dolphin.) 

Here is the output of the MGA8-64 install:

GRUB_CMDLINE_LINUX_DEFAULT="splash quiet noiswmd resume=UUID=324f6b1d-3aba-4e5b-8a03-1af405bb6982 audit=0 vga=791"
GRUB_DEFAULT=saved
GRUB_DISABLE_OS_PROBER=false
GRUB_DISABLE_RECOVERY=false
GRUB_DISABLE_SUBMENU=n
GRUB_DISTRIBUTOR=Mageia
GRUB_ENABLE_CRYPTODISK=y
GRUB_GFXMODE=1024x768x32
GRUB_GFXPAYLOAD_LINUX=text
GRUB_SAVEDEFAULT=true
GRUB_TERMINAL_OUTPUT=gfxterm
GRUB_THEME=/boot/grub2/themes/maggy/theme.txt
GRUB_TIMEOUT=10

Note that it doesn't include the root=UUID parameter either, and as of yesterday it booted every time. As for where it gets the root, I have no clue.

Question, from someone who is clueless about it: Could the 32-bit root=UUID parameter be sending it to the wrong place?

(In reply to Thomas Andrews from comment #73)
> (In reply to Giuseppe Ghibò from comment #70)
> > (In reply to Thomas Andrews from comment #66)
> > 
> > 
> > Are you sure you haven't exchanged the output from 32bit with the one from
> > 64bit? E.g. I see one of them misses the root=UUID=... parameter, so where
> > it would get the root from?
> 
> Very sure. I'm on that machine now, and just checked again. (The partitions
> are labeled so that I know which is which from Dolphin.) 
> 
> Here is the output of the MGA8-64 install:
> 
> GRUB_CMDLINE_LINUX_DEFAULT="splash quiet noiswmd
> resume=UUID=324f6b1d-3aba-4e5b-8a03-1af405bb6982 audit=0 vga=791"
> GRUB_DEFAULT=saved
> GRUB_DISABLE_OS_PROBER=false
> GRUB_DISABLE_RECOVERY=false
> GRUB_DISABLE_SUBMENU=n
> GRUB_DISTRIBUTOR=Mageia
> GRUB_ENABLE_CRYPTODISK=y
> GRUB_GFXMODE=1024x768x32
> GRUB_GFXPAYLOAD_LINUX=text
> GRUB_SAVEDEFAULT=true
> GRUB_TERMINAL_OUTPUT=gfxterm
> GRUB_THEME=/boot/grub2/themes/maggy/theme.txt
> GRUB_TIMEOUT=10
> 
> Note that it doesn't include the root=UUID parameter either, and as of
> yesterday it booted every time. As for where it gets the root, I have no
> clue.
> 
> Question, from someone who is clueless about it: Could the 32-bit root=UUID
> parameter be sending it to the wrong place?

Maybe it's hardcoded in the initrd. Try to pass it manually once, in grub (pressing 'e' to edit) and then adding: root=UUID=..., where UUID is the one corresponding to the partition you get from 'blkid' (issued from root). Or just shorter root=/dev/sdXY (or root=LABEL=...).

(In reply to Giuseppe Ghibò from comment #72)
> (In reply to Thomas Andrews from comment #60)
> > MGA9-64 Plasma on an HP Probook 6550b, same hardware as comment 43, and an
> > issue has shown up.
> 
> note that core i3-350 is a 64bit CPU, with 64bit extensions and up to SSE4.2
> SIMD instruction set. So you are basically testing MGA9-32 on a 64bit system
> in 32bit mode.

Yes, I realize that. Always have. But, I have had one working i586 Mageia install on this machine, for testing purposes, since I bought it in 2016. It has always worked before, and it should work now.

(In reply to Thomas Andrews from comment #75)

> (In reply to Giuseppe Ghibò from comment #72)
> > (In reply to Thomas Andrews from comment #60)
> > > MGA9-64 Plasma on an HP Probook 6550b, same hardware as comment 43, and an
> > > issue has shown up.
> > 
> > note that core i3-350 is a 64bit CPU, with 64bit extensions and up to SSE4.2
> > SIMD instruction set. So you are basically testing MGA9-32 on a 64bit system
> > in 32bit mode.
> 
> Yes, I realize that. Always have. But, I have had one working i586 Mageia
> install on this machine, for testing purposes, since I bought it in 2016. It
> has always worked before, and it should work now.

of course. My observation it's not related to your current problems with boot, but rather that your 32bit system is MORE than a 32bit system without 64bit extensions, which might end with just SSE2.

(In reply to Giuseppe Ghibò from comment #76)
> (In reply to Thomas Andrews from comment #75)
> 
> > (In reply to Giuseppe Ghibò from comment #72)
> > > (In reply to Thomas Andrews from comment #60)
> > > > MGA9-64 Plasma on an HP Probook 6550b, same hardware as comment 43, and an
> > > > issue has shown up.
> > > 
> > > note that core i3-350 is a 64bit CPU, with 64bit extensions and up to SSE4.2
> > > SIMD instruction set. So you are basically testing MGA9-32 on a 64bit system
> > > in 32bit mode.
> > 
> > Yes, I realize that. Always have. But, I have had one working i586 Mageia
> > install on this machine, for testing purposes, since I bought it in 2016. It
> > has always worked before, and it should work now.
> 
> of course. My observation it's not related to your current problems with
> boot, but rather that your 32bit system is MORE than a 32bit system without
> 64bit extensions, which might end with just SSE2.

Of course by definition 32bit system doesn't have 64bit extensions.

MGA9-64 Xfce on Acer Aspire 5253
No installation issues. At first tests no issues with wifi, internet, acessing NFS shares, large odp file playing.

CC: (none) => herman.viaene

I have another system with a 32-bit install using the server kernel, an AMD-based desktop with a Phenom II X4 910 and AMD HD 8490 graphics. I just upgraded that install from MGA8 to 9 using the applet. /etc/default/grub on that install does not have the root=UUID parameter, even after updating the kernel to 6.4.16-5.

Looking at the installed kernels on the problem laptop, I see a couple left over from Cauldron. I now believe there may be some baggage from Cauldron that needs to be cleared out. Rather than try to track that baggage down, I believe a clean install of MGA9-32 is the simplest and most effective way to do that.
  
Sorry for all the noise.

(In reply to Thomas Andrews from comment #79)

> Looking at the installed kernels on the problem laptop, I see a couple left
> over from Cauldron. I now believe there may be some baggage from Cauldron
> that needs to be cleared out. Rather than try to track that baggage down, I
> believe a clean install of MGA9-32 is the simplest and most effective way to
> do that.

well, I always wondered to write a small util that does that tracking automatically showing all the packages and files that do not belongs to an official version of the distro...

urpmq --not-available, will give you the packages part.  For the files, you can use rpm -qla to generate a list of package-owned files and find to generate a list of all of the files, and then sort and diff them.

Using DNF, autimatically
https://wiki.mageia.org/en/Using_DNF#Synchronize_with_repos

(In reply to David Walser from comment #81)

> urpmq --not-available, will give you the packages part.  For the files, you
> can use rpm -qla to generate a list of package-owned files and find to
> generate a list of all of the files, and then sort and diff them.

interesting. It could be the basis of a decluttering utility for installed releases (i.e. those based in a sort of "cauldron rolling" -> mga9). Maybe a ugly GUI (e.g. in zenity) could be added.

New information, and it's not good:

I did a new install of MGA9-32 Xfce on the Probook 6550b, using the netinstall iso, getting my packages from the math.princeton mirror. Everything went well, resulting in a boot to a working desktop. I installed qarepo, in preparation for attempting an update to kernel-server 6.4.16-5.

Here's where things go weird. I had expected the net installer to install the server kernel because this machine has 8GB of RAM, the same way the CI installer does - but it didn't. It had installed kernel-desktop 6.4.16-3. So, because I was trying to check out the i586 server kernel, I used MCC to install kernel-server 6.4.16-3.

Then I rebooted, and BANG - kernel panic. I tried the desktop kernel again, and that worked. So I tried more more boots, in this order:

Server from "Advanced" grub menu - OK
Server from "Mageia" in grub - panic 
Desktop from 'Advanced" - OK
Restart to Server in "Advanced" - OK
Restart to Server in "Advanced" - panic
Server from "Advanced" - OK
Shutdown, then Server in "Advanced" - OK
Restart to Server in "Advanced" - OK
Shutdown, then Server in "Advanced" - panic
Several boots to desktop initiated in different ways - all OK but one - that one stalls at a blank screen.

Sometimes it works, sometimes not. No pattern to it, except that it seems more likely with the server kernel. I've seen this sort of thing before. As I recall, there was a race condition somewhere. 

Since this hardware/software combination is uncommon, and since I'm seeing all this panicking with 32-bit 6.4.16-3 kernels it's not a new regression, so not something to hold 6.4.16-5 back. I'll see about filing another bug when I can gather more information.

Regarding Comment 84, in a new bug for that: Would be interesting to see if kernel-linus have the same problems on that system.

Regarding the 32bit memory models, AFAIK they were changed somewhat during devel cycle. So kernel-desktop586 is capable of handling up to 3-3.5GB of RAM, while both kernel-desktop and kernel-server are able to handle up to 64GB of RAM. Note that both 32bit kernel-desktop and kernel-server were no longer pure "i586" but "i686" kernels.

(In reply to Giuseppe Ghibò from comment #86)
> Regarding the 32bit memory models, AFAIK they were changed somewhat during
> devel cycle. So kernel-desktop586 is capable of handling up to 3-3.5GB of
> RAM, while both kernel-desktop and kernel-server are able to handle up to
> 64GB of RAM. Note that both 32bit kernel-desktop and kernel-server were no
> longer pure "i586" but "i686" kernels.
I don't know if the panic is just a hardware issue, my laptop have sse3, and I don't see crash with other kernels, desktop, desktop586 and linux were tested

Bug 32530. 

This discussion should be taken there, as this bug has become impossibly long.

(In reply to katnatek from comment #87)
> (In reply to Giuseppe Ghibò from comment #86)
> > Regarding the 32bit memory models, AFAIK they were changed somewhat during
> > devel cycle. So kernel-desktop586 is capable of handling up to 3-3.5GB of
> > RAM, while both kernel-desktop and kernel-server are able to handle up to
> > 64GB of RAM. Note that both 32bit kernel-desktop and kernel-server were no
> > longer pure "i586" but "i686" kernels.
> I don't know if the panic is just a hardware issue, my laptop have sse3, and
> I don't see crash with other kernels, desktop, desktop586 and linux were
> tested

What about kernel-server? See https://bugs.mageia.org/show_bug.cgi?id=32530

(In reply to Morgan Leijström from comment #85)
> Regarding Comment 84, in a new bug for that: Would be interesting to see if
> kernel-linus have the same problems on that system.

It doesn't - so far.

If my 32-bit boot failure problem is all that's holding this back now, we should go ahead and push it. Not only does this fix several CVEs, but it is holding back a VirtualBox security update, as well.

Leaving it to the kernel maintainers to make the decision, as is our custom for kernel updates, but if it were a "regular" update I would have  validated by now.

(In reply to Thomas Andrews from comment #91)

> If my 32-bit boot failure problem is all that's holding this back now, we
> should go ahead and push it. Not only does this fix several CVEs, but it is
> holding back a VirtualBox security update, as well.
> 
> Leaving it to the kernel maintainers to make the decision, as is our custom
> for kernel updates, but if it were a "regular" update I would have 
> validated by now.

Yes actually is what holding, but could be also on a reason.

What is weird is that kernel-linus-6.4.16-6 works all the times, which has the same extra patchset of the other -desktop and -server kernels.

One alternative, if we can't solve on this is to skip this one and directly jump over 6.5.11(12) which is now much more mature than one month ago.

I'll do some more tests on a 32bit VM tomorrow.

"One alternative, if we can't solve on this is to skip this one and directly jump over 6.5.11(12) which is now much more mature than one month ago."

That may be the way to go. That kernel is booting normally on my problem machine.

(In reply to Giuseppe Ghibò from comment #89)
> (In reply to katnatek from comment #87)
> > I don't know if the panic is just a hardware issue, my laptop have sse3, and
> > I don't see crash with other kernels, desktop, desktop586 and linux were
> > tested
> 
> What about kernel-server? See https://bugs.mageia.org/show_bug.cgi?id=32530

As I said before I get a panic each first try with two test with kernel-server (this report and previous kernel update), the first time I don't report because after test the other kernels and test again kernel-server I don't get the panic, but I don't do a deep test as Thomas Andrews.

If you decide to switch to kernel 6.5 series, I have some questions, Will keep or drop this report? If we drop this report, what happens with the advisory on svn?

If we keep this report, I can obsolete all the comments
'

(In reply to Giuseppe Ghibò from comment #92)
> What is weird is that kernel-linus-6.4.16-6 works all the times, which has
> the same extra patchset of the other -desktop and -server kernels.

Yet another use case that need kernel-linus: a chromebook
https://forums.mageia.org/en/viewtopic.php?f=7&t=15140&p=88720#p88717

(In reply to katnatek from comment #94)

> 
> If you decide to switch to kernel 6.5 series, I have some questions, Will
> keep or drop this report? 

In that case, please create a new report, this one already has 95 comments, even when obsoleted a lot to scroll down.

> If we drop this report, what happens with the
> advisory on svn?

In that case, I intend to delete it.

(In reply to Marja Van Waes from comment #96)
> (In reply to katnatek from comment #94)

> 
> > 
> > If you decide to switch to kernel 6.5 series, I have some questions, Will
> > keep or drop this report? 
> 
> In that case, please create a new report, this one already has 95 comments,
> even when obsoleted a lot to scroll down.
> 
> > If we drop this report, what happens with the
> > advisory on svn?
> 
> In that case, I intend to delete it.

In theory it fixes the same CVEs so it can be recycled once file list updated.

(In reply to Giuseppe Ghibò from comment #97)
> (In reply to Marja Van Waes from comment #96)
> > (In reply to katnatek from comment #94)

> > > If we drop this report, what happens with the
> > > advisory on svn?
> > 
> > In that case, I intend to delete it.
> 
> In theory it fixes the same CVEs so it can be recycled once file list
> updated.

Yes I can copy it to the new 325??.adv and change the link to this bug report to the new bug report, while updating the version/release for the SRPMs (also for kmod-virtualbox and kmod-xtables-addons, right?)

And the references need to be updated with, well, the changelog messages from the new kernel and _all_ the earlier ones here: https://cdn.kernel.org/pub/linux/kernel/v6.x/ ?? Or can I just give only that one link?

I assume the two git references at the bottom of the current advisory https://svnweb.mageia.org/advisories/32482.adv?revision=15246&view=markup can be dropped, because those patches are included in whichever 6.5 kernel that you'll package?

(In reply to Thomas Andrews from comment #93)
> "One alternative, if we can't solve on this is to skip this one and directly
> jump over 6.5.11(12) which is now much more mature than one month ago."
> 
> That may be the way to go. That kernel is booting normally on my problem
> machine.

OK, according to latest test with kernel-server i586, since ready, we'll skip 6.4.16-5 and go to 6.5.11(12).

It was announced yesterday that the 6.6.x kernel will be a lts release with support to 2026.

https://www.kernel.org/category/releases.html

CC: (none) => xerxes2

(In reply to Jens Persson from comment #100)

> It was announced yesterday that the 6.6.x kernel will be a lts release with
> support to 2026.
> 
> https://www.kernel.org/category/releases.html

Interesting. Let's see how many releases upgrade 6.5.x will keep before going EOL. Usually it takes wait 6-7 releases for a new series get stabilizing (plus all the external modules, nvidia, etc.).

Backport kernel 6.5.11-desktop-2.mga9 don't have the problem our 6.4 series -desktop kernels have on my system about returning from suspend when using Nvidia's drivers, my Comment 36 :)

Is fine if Close this as wontfix and convert bug#32530 in the bug to update to kernel 6.5?

OK with me. In fact, I was going to suggest we do that very thing.

OK, but probably better to restart another, as basically 32530 is "basically" solved with 6.5.11.

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

Advisory deleted after reusing most of it for bug 32537

Keywords: advisory => (none)