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.

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

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.

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.

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

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

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