Tuesday, November 28, 2017

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.

Tuesday, February 21, 2017

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],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 -u
Logging out of session [sid: 1, target: iqn.2001-05.com.emc:0-af1ff6-c57ac0bd5-7
12a2878fd0533c6-backuppc, portal:,3260]
Logout of [sid: 1, target: iqn.2001-05.com.emc:0-af1ff6-c57ac0bd5-712a2878fd0533
c6-backuppc, portal:,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

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