Linux Kernel 5.4 and VirtualBox Puzzle

I've been puzzling over WHY my VirtualBox doesn't work under Linux kernel 5.4 ever since 5.4-RC1 came out.  Last week, Slackware -current made 5.4 the default kernel so I hoped all was well - NOPE!  So I compiled it myself adding in the modules that have always allowed everything to work up until 5.3.x.  That didn't work either.  Bummer.

So I did a bit of research (5 seconds of googling) and it seems there was a lot going on with VirtualBox and Linux kernel 5.4.  First there was this:

Linux 5.4 kernel will no longer make interfaces available so that arbitrary kernel modules may modify page attributes to turn the executable bit on/off. Virtualbox currently is one of such kernel modules doing that.

 Then, it seems, in 5.4-RC7 they added a special "shared folder" area for Virtualbox which was later removed. 

So, at this time, it seems VirtualBox and Linux kernel 5.4 are not going to play well together until a special new VirtualBox 6.1 candidate is released (designed specifically to work with VirtualBox).  So far, I cannot find this release candidate (5 seconds of googling).

That's ok, I have my box set to always my special vanilla 5.3.x (5.3.15 at the time of this writing).  I just hope this continues to get updates so I don't have to drop back to the 4.19.x LTS kernel.

If you see a release candidate for VirtualBox 6.1 post a response.  I'll do the same (so we're racing).

Slackware 14.2 Under XenServer 7.1

I've always had a networking problem with Slackware as a guest VM under Citrix XenServer (or Citrix Hypervisor, I guess is what they call it these days).  I still prefer Slackware as a desktop and so I set about solving this again recently - this time I would not be thwarted!

I ran across this article: How do I disable 8139too network driver... because lsmod lead me to search for 8139too networking module.  This was an Ubuntu article, so, I'll transmorgify it a bit for Slackware users.   The first thing it suggested was to blacklist 8139 in the modules.  Like the author of this I did not have any luck with that.  It was suggested you use the 8139cp instead (cool!  I didn't even know of its existence before this article).

# lsmod | grep 8139


This revealed 8139too in use and bound with mii, so...

# rmmod 8139too
# rmmod mii
# modprobe 8139cp
# modprobe mii
# /etc/rc.d/rc.inet1 restart

At this point, I had, for the first time ever as a Slackware XenServer guest, a working eth0!

In order to keep it (and use less resources) I created a smaller kernel /boot/initrd.gz by running mkinitrd.

# /usr/share/mkinitrd/mkinird_command_generator.sh

I appended :8130cp to the suggested mkinitrd script:

# mkinitrd -c -k 4.4.14 -f ext4 -r /dev/sda2 -m jbd2:mbcache:ext4:8139cp -u -o /boot/initrd.gz

This seemed to work nicely so I doctored up the boot area a bit:

# cd /boot
# rm System.map
# ln -s System.map-generic-4.4.14 System.map
# rm config
# ln -s config-generic-4.4.14 config

Then I added a section to the /etc/lilo.conf:

 image = /boot/vmlinuz-generic
   label = Slackware
   initrd = /boot/initrd.gz
   root = /dev/sda2
   read-only

And I always add default = Slackware before running lilo -v.

After that, I rebooted and had a Slackware install with a nice lean kernel with a eth0 running as a guest VM under Citrix XenServer (or Hypervisor - I can't get used to that!).