Getting VB (Victoria Bitter, I need) to do anything is always a 50/50
bet. Installing the latest version downloaded, I get the standard
message that the system is unable to start the kernel driver. There are
3 different kernels involved: the system on kernel-desktop-5-15-14-1, 5.17.9-server-1.mga8 to run VirtualBox, and virtualbox-kernel-5.17.9-desktop-2. They were what the system installed
by default. Surely at least two of them should match, but I have
noticed before that sometimes, when the system kernel is upgraded, there
is no update candidate for the VB kernel. On the other hand, I have
never before seen the kernel-server number so much greater than the kernel-desktop. The system kernel at the moment is
5.17.9-server-1.mga8. On one forum post, it turned out that the mirror
was behind, and AARnet is always behind, so I added a German mirror specifically with no better luck. To cover this last issue further, I
tried again after a couple of days, but nothing new came down.

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: Aioe.org NNTP Server (2:250/1@fidonet)

On Thu, 26 May 2022 18:35:04 -0400, Doug Laidlaw <laidlaws@hotkey.net.au> wrote:

Getting VB (Victoria Bitter, I need) to do anything is always a 50/50
bet. Installing the latest version downloaded, I get the standard
message that the system is unable to start the kernel driver. There are
3 different kernels involved: the system on kernel-desktop-5-15-14-1, 5.17.9-server-1.mga8 to run VirtualBox, and virtualbox-kernel-5.17.9-desktop-2. They were what the system installed
by default. Surely at least two of them should match, but I have
noticed before that sometimes, when the system kernel is upgraded, there
is no update candidate for the VB kernel. On the other hand, I have
never before seen the kernel-server number so much greater than the kernel-desktop. The system kernel at the moment is
5.17.9-server-1.mga8. On one forum post, it turned out that the mirror
was behind, and AARnet is always behind, so I added a German mirror specifically with no better luck. To cover this last issue further, I
tried again after a couple of days, but nothing new came down.

If you're seeing kernel updates without a corresponding virtualbox-kernel update
then you must be installing packages from updates testing, which should only be done by people testing updates before they are ready for the general public. Often
kernel updates are done in stages. The qa team members test kernel updates that will never be released as regular updates, as there are more fixes to be applied.
Those kernel updates don't get the kmod (which includes the virtualbox-kernel module packages) produced.

Part of the testing we do is to ensure they work with the kernel update installed
on the host, and in virtualbox guests.

For qa team members, or people using a kernel where the virtualbox-kernel packages
are not available (such as the kernel-linus packages), virtualbox can still be used by installing the dkms-virtualbox package.

Regards, Dave Hodgins

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 27/5/22 09:01, David W. Hodgins wrote:

If you're seeing kernel updates without a corresponding
virtualbox-kernel update
then you must be installing packages from updates testing, which should
only be
done by people testing updates before they are ready for the general
public. Often
kernel updates are done in stages.

Thanks, Dave. The "testing" repos are listed, but not enabled.

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: Aioe.org NNTP Server (2:250/1@fidonet)

On 27/5/22 20:53, Doug Laidlaw wrote:

On 27/5/22 09:01, David W. Hodgins wrote:

If you're seeing kernel updates without a corresponding
virtualbox-kernel update
then you must be installing packages from updates testing, which
should only be
done by people testing updates before they are ready for the general
public. Often
kernel updates are done in stages.

Thanks, Dave.  The "testing" repos are listed, but not enabled./var

I think that I now have this fixed. The problem was "cobwebs." I had already re-created a clean home directory using BitTwister's guide
(thanks again, Bits) but I hadn't cleaned up /var. When I was just
finding my feet, a howto book suggested that /var should be on its own partition, because it changes so often. Nobody else seems to bother,
but I have kept /var on a separate partition and wiped it on a fresh installation. For the last couple of times, I haven't done that. That
seems to have been the cause of a few problems. Cleaning it on a fresh install helped several niggly problems. VirtualBox installed with no
errors, and I had only the usual configuration to worry about.

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: Aioe.org NNTP Server (2:250/1@fidonet)

On 5/26/22 19:01, David W. Hodgins wrote:

On Thu, 26 May 2022 18:35:04 -0400, Doug Laidlaw
<laidlaws@hotkey.net.au> wrote:

Getting VB (Victoria Bitter, I need) to do anything is always a 50/50
bet.  Installing the latest version downloaded, I get the standard
message that the system is unable to start the kernel driver.  There are
3 different kernels involved: the system on kernel-desktop-5-15-14-1,
5.17.9-server-1.mga8 to run VirtualBox, and
virtualbox-kernel-5.17.9-desktop-2.  They were what the system installed
by default.  Surely at least two of them should match, but I have
noticed before that sometimes, when the system kernel is upgraded, there
is no update candidate for the VB kernel.  On the other hand, I have
never before seen the kernel-server number so much greater than the
kernel-desktop.  The system kernel at the moment is
5.17.9-server-1.mga8.  On one forum post, it turned out that the mirror
was behind, and AARnet is always behind, so I added a German mirror
specifically with no better luck. To cover this last issue further, I
tried again after a couple of days, but nothing new came down.

If you're seeing kernel updates without a corresponding
virtualbox-kernel update
then you must be installing packages from updates testing, which should
only be
done by people testing updates before they are ready for the general
public. Often
kernel updates are done in stages. The qa team members test kernel
updates that
will never be released as regular updates, as there are more fixes to be applied.
Those kernel updates don't get the kmod (which includes the virtualbox-kernel
module packages) produced.

Part of the testing we do is to ensure they work with the kernel update installed
on the host, and in virtualbox guests.

For qa team members, or people using a kernel where the
virtualbox-kernel packages
are not available (such as the kernel-linus packages), virtualbox can
still be
used by installing the dkms-virtualbox package.

Dave, the 5.17.x kernels are coming from the Core_Backports repo. I
think he's running into

https://bugs.mageia.org/show_bug.cgi?id=29830

where packages are installed from backports even if the backports repo
is disabled.

TJ


--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 5/28/22 17:37, Doug Laidlaw wrote:

On 27/5/22 20:53, Doug Laidlaw wrote:

On 27/5/22 09:01, David W. Hodgins wrote:

If you're seeing kernel updates without a corresponding
virtualbox-kernel update
then you must be installing packages from updates testing, which
should only be
done by people testing updates before they are ready for the general
public. Often
kernel updates are done in stages.

Thanks, Dave.  The "testing" repos are listed, but not enabled./var

 I think that I now have this fixed.  The problem was "cobwebs." I had already re-created a clean home directory using BitTwister's guide
(thanks again, Bits) but I hadn't cleaned up /var.  When I was just
finding my feet, a howto book suggested that /var should be on its own partition, because it changes so often.  Nobody else seems to bother,
but I have kept /var on a separate partition and wiped it on a fresh installation.  For the last couple of times, I haven't done that.  That seems to have been the cause of a few problems.  Cleaning it on a fresh install helped several niggly problems.  VirtualBox installed with no errors, and I had only the usual configuration to worry about.

It may be working for now, but I don't think it will continue to work
unless you remove those 5.17 kernels. They support newer hardware, and
are in backports because they haven't received the same level of testing
that the "regular" kernels get. If you don't have that bleeding edge
hardware, you likely don't need those backported kernels. And, they are
harder to manage.

A side effect of those backported kernels getting installed is that they
will prevent you from getting the latest updates to the "regular"
kernels. For example, most systems were just updated to kernel 5.15.43,
and those systems would have received the corresponding virtualbox
kernel modules at the same time.

This is all coming from
https://bugs.mageia.org/show_bug.cgi?id=29830
This bug can be worked around, and your system can be straightened out,
but the starting point depends on if you still have a 5.15.x kernel
installed, and can boot into it.

TJ

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Sat, 28 May 2022 18:54:53 -0400, TJ <TJ@noneofyour.business> wrote:

This is all coming from
https://bugs.mageia.org/show_bug.cgi?id=29830
This bug can be worked around, and your system can be straightened out,
but the starting point depends on if you still have a 5.15.x kernel installed, and can boot into it.

I'd forgotten about that bug. I rarely test backports myself, or use the debug repos. I normally run "urpmi.removemedia -y Debug Back" to remove those repos, which speed up checking for updates.

On the rare occasion I do need them I either download the individual packages using a browser, or remove/re-add the mirror, install the packages, and then remove the Debug and Backports repos again.

It also has the benefit of avoiding bug 29830.

Regards, Dave Hodgins

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)