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!).
   

  

 

Ansible is so useful - Even for someone who doesn't know how to use it!

I love Ansible!  It is so useful even though my skills with it are very minimal, it is so powerful and useful.  I have about 80 or 90 playbooks that I use over and over.  They're all pretty simple but they get things done.  I forget when and where I can use ad-hoc ansible commands.  I love it when those work though.  I thought I could use ad-hoc to view /etc/resolv.conf and goofed around with -shell and had no success.  Then I found this I had written 13 months ago:

- hosts: all
  sudo: yes
  tasks:
  - name: Display /etc/resolv.conf
    shell: cat /etc/resolv.conf
    register: resolv

  - name: Debug resolv
    debug: var=resolv

  - name: Debug resolv.stdout as part of a string
    debug: msg=`{{ resolv.stdout }}`

Codename: Ubuntu Rusty

Just call me Rusty -  with regards to Ubuntu anyway.  Man!  I can't remember how to set the IP in the old Ubuntu.  Now, 18.04 has changed yet again.  I'm a RHELish* user when I'm not using Slackware for my own personal desktop.  Don't get me wrong - Ubuntu is a fine desktop.  I used it from '04 to '09 parting ways when the Unity desktop came into play.  I did enjoy Xubuntu and then later Lubuntu but found my 5+ years of 'buntu had weakened my RHELish skills much in the way the last (nearly 10) years has mu 'buntu skills SO I switched back.  Actually, I always load Ubuntu for other people (non-Unix folks) who want to salvage an old laptop or old desktop that ran Windows 7 or something.  I've had some success stories there.  But I digress.  

This is just a place to save these commands so I don't have to hunt them up YET AGAIN.  

Changing an Ubuntu 18.04 LTS server's name

This is pretty easy.  

$ sudo hostnamectl set-hostname linuxconfig

This note is not (currently) for me: Check for the existence of /etc/cloud/cloud.cfg and change preserve_hostname: false to preserve_hostname: true

Changing the static IP of an Ubuntu 18.04 LTS server

This is no longer in the /etc/network/interfaces.  Instead look in /etc/netplan (sudo -s first or it will not auto-complete leading me to believe it didn't exist).  The file is 50-cloud-init.yaml.

That is all I have to say since this note is mainly for me.  Hopefully I'll know what else to do when I need this information again. 


---
*RHELish (pronounced "relish") is the term I coined for Red Hat -like based systems such as (of course) Red Hat Enterprise Linux, CentOS, Scientific Linux and Oracle Linux. 

Slackware14.2-current, VirtualBox and new kernels

I keep blowing up my Slackbuild VirtualBox setup with every new kernel update.  Usually, I can just re-run the Slackbuilds for virtualbox-kernel and virtualbox (with a re-boot in between) and I'm fine. Not today. Tried all kinds of things. Then got weird. I was running the Slackbuild for VirtualBox 5.0.40. I decided to just skip package management and go straight to the source (hey, I'm a Slacker). So, I went to the Oracle Virtualbox site and found this link and then, from the command line ran the following:


curl -O http://download.virtualbox.org/virtualbox/5.2.2/VirtualBox-5.2.2-119230-Linux_amd64.run
sh VirtualBox-5.2.2-119230-Linux_amd64.run

Lots of things works, lots of things complained about symbolic links already existing (step 1 of this script attempted to remove my Slackbuild VirtualBox with, I'd say, partial success), and then it ended on "unable to start kernel drivers". Not a good sign I thought. Just for luck, another reboot. And then, I re-ran "rc.vboxdrv start" AND IT WORKED! So now I'm running 5.2.2!!

So, I fire up an ALL NEW Oracle VirtualBox with lotsa Oracle branding (hmmm... didn't remember all of that). I attempt to start my Windoze VM - no go. It complains about USB 2.0 support not being there and suggests I try installing extensions.

Implementation of the USB 2.0 controller not found!

Because the USB 2.0 controller state is part of the saved VM state, the VM cannot be started. To fix this problem, either install the 'Oracle VM VirtualBox Extension Pack' or disable USB 2.0 support in the VM settings

I re-run extensions. Still no go. So, I retro my VM's USB support from 2.0 to 1.1 (trying to think how often I use USB with a VM anyways?) AND IT WORKED! 


Ok, not the slickest solution in the world. The installer did something with Python bindings, from what I could tell, installed some things, fixed some things, possibly broke my USB 2.0 support but otherwise bailed me out.

So, if you're desperate - you're welcome.

The Rare un-iSCSI Commands

I often add iSCSI volumes to Linux servers but, until now, rarely take them away.  That strikes me as odd too.  But, I guess when I get to the point of not using storage, the server is usually going away too.  -Not in this case. 

So, here's the steps for removing all traces of an iSCSI volume.

Step 1: Find the iSCSI Session

[root@localhost]# iscsiadm -m session
tcp: [1] 192.168.0.100:3260,1 iqn.2001-05.com.emc:0-af1ff6-c57ac0bd5-712a2878fd0
533c6-backuppc (non-flash)

Step 2: Disable (logout) current iSCSI session

[root@localhost]# iscsiadm --m node -T iqn.2001-05.com.emc:0-af1ff6-c57ac0bd5-71
2a2878fd0533c6-backuppc --portal 192.168.0.100:3260 -u
Logging out of session [sid: 1, target: iqn.2001-05.com.emc:0-af1ff6-c57ac0bd5-7
12a2878fd0533c6-backuppc, portal: 192.168.0.100,3260]
Logout of [sid: 1, target: iqn.2001-05.com.emc:0-af1ff6-c57ac0bd5-712a2878fd0533
c6-backuppc, portal: 192.168.0.100,3260] successful.

Step 3: Double check that session is logged out

[root@localhost]# iscsiadm -m session                                   iscsiadm
: No active sessions.

Step 4: Permanently delete iSCSI session

[root@localhost]# iscsiadm -m node -o delete -T iqn.2001-05.com.emc:0-af1ff6-c57
ac0bd5-712a2878fd0533c6-backuppc --portal 192.168.0.100:3260

Step 5: Stop iSCSI from running (since targets are gone)

[root@localhost]# service iscsi stop
Stopping iscsi:                                            [  OK  ]            
[root@localhost]# chkconfig iscsi off

Step 6: Remove references to iSCSI in /etc/fstab

[root@localhost]# vi /etc/fstab ...

Slackware and LXC

I have a fresh Slackware 14.2 I've been enjoying since it came out this month.  I needed a hyper-visor and was getting ready to add Xen (the hyper-visor of choice on Slackware).  I like Xen, but I knew the compile times for the Slackbuilds and it's dependencies would probably take more time than I had at the moment.  Then I remembered LXC.  It comes with.

I didn't know much about LXC so did some quick reading.  They say "it's similar to Docker but easier" - I like the sound of that.  So I check it out.  It's EXACTLY like Solaris containers!  Which I've been using for over 10 years - but, again, easier!  It's pretty slick!  And it installs by default on Slackware 14.2 but there's a few things you need to change.

ON THE HOST

Edit the /etc/rc.d/rc.inet1.conf

Slackware does not have a bridged network device by default BUT it does have it defined and commented out.  I found this works nicely except I was expecting my host interface to use eth0 and lxc guest to use br0.  It was not what I expected but it works fine!

# Example of how to configure a bridge:
# Note the added "BRNICS" variable which contains a space-separated list
# of the physical network interfaces you want to add to the bridge.
IFNAME[0]="eth0"
BRNICS[0]="br0"
#IPADDR[0]=""
#NETMASK[0]=""
USE_DHCP[0]="yes"
#DHCP_HOSTNAME[0]=""

Routing = Yes

You will, of course, need your host to route packets so

# chmod 755 /etc/rc.d/rc.ip_forward

And then start it or restart.  I like to restart to make sure everything is the way it needs to be before relying on it.  You could also just

# echo 0 > /proc/sys/net/ipv4/ip_forward

LXC Config

Really the only other thing you need to do is add a bit to /etc/lxc/default.conf.  This worked for me:

root@slacks:~# cat /etc/lxc/default.conf
lxc.network.type=veth
lxc.network.link=br0
lxc.network.flags=up

ON THE LXC GUEST

Just run netconfig and set a static address or DHCP and then restart rc.inet1.  

WHAT LXC GUEST?!!

Oh, I skipped that bit, eh?  Super simple.  Try this:
  
# lxc-create -n lxcguest -t /usr/share/lxc/templates/lxc-slackware
# lxc-start -n lxcguest -d
# lxc-console -n lxcguest  (it'll tell you how to login)

Now, run netconfig.  

What?!  You're already running Slackware on the host and you'd like to try something different?  Just run list the contents of  /usr/share/lxc/templates and then try one or a dozen of the other 18 pre-installed templates.  Like:

root@slacks:~# ls /usr/share/lxc/templates
lxc-alpine*     lxc-cirros*    lxc-openmandriva*  lxc-sparclinux*
lxc-altlinux*   lxc-debian*    lxc-opensuse*      lxc-sshd*
lxc-archlinux*  lxc-download*  lxc-oracle*        lxc-ubuntu*
lxc-busybox*    lxc-fedora*    lxc-plamo*         lxc-ubuntu-cloud*
lxc-centos*     lxc-gentoo*    lxc-slackware*


If you down like any of those, try something else with this command:

# lxc-create -t /usr/share/lxc/templates/lxc-download -n newguest

You will be given an even bigger choice.  Knowing Slackware and how stable it is, I would stay with the local choices to ensure that legendary stability stays as is (but that's just me). 

THE END

Well, that's all of my notes.  Postive comments and any kind of experiences with LXC are always welcome below.