Ubuntu on Chris J Arges

grub-reboot with submenus

Thu, 25 Feb 2016 10:05:51 -0500

Occasionally it is useful to be able to reboot a machine into an earlier kernel and watching and waiting for the grub menu isn’t always feasible or convenient.

The command grub-reboot allows you to set a temporary entry to use for the next reboot; however you need to know the correct input in order for it to work.

First, look at /boot/grub/grub.cfg and determine which kernel you want to reboot into. Note the menu and submenus to construct a string of the form menu>submenu. For example if you want to reboot into an older kernel you can do:

building ubuntu kernels with debug symbols

Fri, 02 Oct 2015 08:53:52 -0500

Occasionally it is useful to be able to build a kernel the Ubuntu way with debug symbols. The following is how to install dependencies, clone the tree, and finally build in such a way that ddeb packages get generated.

Here’s how:

sudo apt-get build-dep linux-image-$(uname -r)
sudo apt-get install fakeroot pkg-config-dbgsym git
git clone git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/wily 
cd wily
fakeroot debian/rules clean
debian/rules build-generic
fakeroot debian/rules binary-generic binary-headers skipdbg=false

Wait a bit and you should see a -dbgsym package get generated.

using linux livepatch on ubuntu

Mon, 21 Sep 2015 13:03:26 -0500

Livepatching was introduced in the v4.0 kernel, and now Ubuntu 15.10 has a kernel capable of using this new and exciting feature. This works by using ftrace to redirect kernel function calls to the newly patched functions. In addition mechanisms for hooking into module insertion and removal are used for patching loadable modules. This feature also has sysfs directories for tracking which patches are applied and which functions they modify. With the basics aside, this blog post will show some simple examples of how to livepatch your kernel.

linux make deb-pkg speedup

Thu, 30 Jul 2015 15:20:31 -0500

Because I’ve run make deb-pkg so many times, I’ve started to see exactly where it starts to slow down even with really large machines. Observing cpu usage, I noticed that many parts of the build were serialized on a single core. Upon further investigation I found the following.

Upstream Packaging

Module installation takes a really long time, and when building with make deb-pkg -jN, you’ll see output like the following:

accessing maas database directly

Wed, 27 May 2015 13:02:46 -0500

Let’s say you’ve messed up your MAAS installation and have no idea how to recover data about your nodes. Have no fear, you can access the django managed database directly.

Just use the following as root:

maas-region-admin dbshell --installed

Now you have access to an SQL command line interface.

For example if I want to see all hostnames and power_parameters for my servers, I can do the following:

select hostname,power_parameters from maasserver_node;

qemu/kvm guest debugging

Mon, 13 Apr 2015 12:24:22 -0500

Occasionally it is useful to debug a running guest VM’s kernel. Setup your host machine for virtual machine hosting with QEMU/KVM, and add ddebs to your host system using this wiki.

Next, compile your own qemu with --enable-debug. Setup your environment to use this binary (if using libvirt), or call it directly using qemu.

Ensure you have vmlinux of the L1 guest somewhere in your L0 machine.

First, setup your L1 guest. If running with qemu add the -s flag. With libvirt you can add the following entry to your machine description:

getting kernel crashdumps for hung machines

Fri, 31 Oct 2014 13:53:00 -0700

Debugging hung machines can be a bit tricky. Here I’ll document methods to trigger a crashdump when these hangs occur. What exactly does it mean when a machine ‘hangs’ or ‘freezes-up’? More information can be found in the kernel documentation, but overall there are really a few types of hangs.

A “Soft Lock-Up” is when the kernel loops in kernel mode for a duration without giving tasks a chance to run. A “Hard Lock-Up” is when the kernel loops in kernel mode for a duration without letting other interrupts run. In addition a “Hung Task” is when a userspace task has been blocking for a duration.

using ktest.pl with ubuntu

Tue, 01 Jul 2014 13:10:00 -0700

Bisecting the kernel is one of those tasks that’s time-consuming and error prone. Ktest.pl is a script that lives in the linux kernel source tree that helps to automate this process. The script is extremely extensible and as such takes time to understand which variables need to be set and where. In this post, I’ll go over how to perform a kernel bisection using a VM as the target machine. In this example I’m using ‘ubuntu’ as the VM name.

using CRIU to checkpoint a kernel build

Wed, 25 Jun 2014 13:46:00 -0700

CRIU stands for Checkpoint/Restart in Userspace. As the criu package should be landing in Utopic soon, and I wanted to test drive it to see how it handles.

I thought of an interesting example of being in the middle of a linux kernel build and a security update needing to be installed and the machine rebooted. While most of us could probably just reboot and rebuild, why not checkpoint it and save the progress; then restore after the system update? I admit its not the most useful example; but it is pretty cool nonetheless.

manually deploying openstack with a virtual maas on ubuntu trusty (part 2)

Mon, 16 Jun 2014 10:16:00 -0700

In the previous post, I went over how to setup a virtual MAAS environment using KVM [1]. Here I will explain how to setup Juju for use with this environment.

For this setup, we’ll use the maas-server as the juju client to interact with the cluster.

This guide was very useful:
https://maas.ubuntu.com/docs/juju-quick-start.html

Update to the latest stable tools:

sudo apt-add-repository ppa:juju/stable
sudo apt-get update

Next we want to setup juju on the host machine.

sudo apt-get install juju-core

Create juju environment file.

juju init

Generate a specific MAAS API key by using the following link:
http://192.168.100.10/MAAS/account/prefs/

write the following to ~/.juju/environments.yaml replacing ‘maas api key’ with what was generated above:

default: vmaas
environments:
  vmaas:
    type: maas
    maas-server: 'http://192.168.100.10/MAAS'
    maas-oauth: '<maas api key>'
    admin-secret: ubuntu # or something generated with uuid
    default-series: trusty

Now let’s sync tools and bootstrap a node. Note, if you have multiple juju environments then you may need to specify ‘-e vmaas’ if it isn’t your default environment.

juju sync-tools
juju bootstrap # add --show-log --debug  for more output

See if it works by using the following command:

juju status

You should see something similar to the following:

~$ juju status
environment: vmaas
machines:
  "0":
    agent-state: down
    agent-state-info: (started)
    agent-version: 1.18.4
    dns-name: maas-node-0.maas
    instance-id: /MAAS/api/1.0/nodes/node-e41b0c34-e1cb-11e3-98c6-5254001aae69/
    series: trusty
services: {}

Now we can do a test deployment with the juju-gui to our bootstrap node.

juju deploy juju-gui

While it is deploying you can type the following to get a log.

juju debug-log

I wanted to be able to access the juju-gui from an ‘external’ address, so I edited /etc/networking/interfaces on that machine to have a static address:

juju ssh 0

sudo vim /etc/networking/interfaces

Add the following to the file:

auto eth0
iface eth0 inet static
  address 192.168.100.11
  netmask 255.255.255.0

Bring that interface up.

sudo ifup eth0

The password can be found here on the host machine:

grep pass .juju/environments/vmaas.jenv

If you used the above configurations it should be ‘ubuntu’.

Log into the service so you can monitor the status graphically during the deployment.

If you get errors saying that servers couldn’t be reached you may have DNS configuration or proxy issues. You’ll have to first resolve these before using Juju. I’ve had is intermittent network issues in my lab. In order to workaround those physical issues you may have to retry the bootstrap, or increase the timeout values in ~/.juju/environments.yaml to use the following:

  bootstrap-retry-delay: 5
  bootstrap-timeout: 1200

Now you’re cooking with juju.

http://dinosaursareforever.blogspot.com/2014/06/manually-deploying-openstack-with.html

manually deploying openstack with a virtual maas on ubuntu trusty (part 1)

Fri, 13 Jun 2014 15:05:00 -0700

The goal of this new few series of posts is to be able to setup virtual machines to simulate a real-world openstack deployment using maas and juju. This goes through setting up a maas-server in a VM as well as setting up maas-nodes in VMs and getting them enlisted/commissioned into the maas-server. Next juju is configured to use the maas cluster. Finally, openstack is deployed using juju.

Overview

Requirements

Ideally, a large server with 16 cores, 32G memory, 500G disk. Obviously you can tweak this setup to work with less; but be prepared to lock up lesser machines. In addition your host machine needs to be able to support nested virtualization.

Topology

Here is the basics of what will be setup for our virtual maas cluster. Each red box is a virtual machine with two interfaces. The eth0 interface in the VM connects to the NATed maas-internet network, while the VM’s eth1 interface connects to the isolated maas-management network. The number of maas-nodes should match what is required for the deployment; however it is simple enough to enlist more nodes later. I choose to use a public/private network in order to be more flexible later in how openstack networking is set up.

Setup Host Machine

Install Requirements

First install all required programs on the host machine.

sudo apt-get install libvirt-bin qemu-kvm cpu-checker virtinst uvtool

Next, check if kvm is working correctly.

kvm-ok

Ensure nested KVM is enabled. (replace intel with amd if necessary)

cat /sys/module/kvm_intel/parameters/nested

This should output Y, if it doesn’t do the following:

sudo modprobe -r kvm_intel
sudo modprobe kvm_intel nested=1

Ensure $USER is added to libvirtd group.

groups | grep libvirtd

Ensure host machine has SSH keys generated and setup. (Be careful, don’t overwrite your existing keys)

[ -d ~/.ssh ] || ssh-keygen -t rsa

Virtual Network Setup

This step can be done via virt-manager, but also done via command line using virsh.

Setup a virtual network which uses NAT to communicate with the host machine with the following parameters:

Network Name: maas_internet
Network: 192.168.100.0/24
Do _not_ Enable DHCP.
Forwarding to physical network; Any physical device; NAT

And setup an isolated virtual network the following parameters:

Network Name: maas_management
Network: 10.10.10.0/24
Do _not_ Enable DHCP.
Isolated network;

Install the MAAS Server

Download and Start the Install

Ensure you have virt-manager connected to the hypervisor.
While there are many ways we can create virtual machines, I chose the tool uvtool because it works well in Trusty and quickly creates VM based on the Ubuntu cloud image.

Sync the latest cloud trusty cloud image:

uvt-simplestreams-libvirt sync release=trusty arch=amd64

Create a maas-server VM:

uvt-kvm create maas-server release=trusty arch=amd64 --disk 20 --memory 2048 --password ubuntu

After it boots, shut it down and edit the VM’s machine configuration.
Make the two network interfaces connect to maas_internet and maas_management respectively.

Now edit /etc/network/interfaces to have the following:

auto eth0
iface eth0 inet static
  address 192.168.100.10
  netmask 255.255.255.0
  gateway 192.168.100.1
  dns-nameservers 10.10.10.10 192.168.100.1

auto eth1
iface eth1 inet static
  address 10.10.10.10
  netmask 255.255.255.0
  dns-nameservers 10.10.10.10 192.168.100.1

And follow the instructions here:
http://maas.ubuntu.com/docs/install.html#pkg-install

Which is essentially:

sudo apt-get install maas maas-dhcp maas-dns

MAAS Server Post Install Tasks

http://maas.ubuntu.com/docs/install.html#post-install

First let’s check if the webpage is working correctly. Depending on your installation, you may need to proxy into a remote host hypervisor before accessing the webpage. If you’re working locally you should be able to access this address directly (as the libvirt maas_internet network is already connected to your local machine).

If you need to access it indirectly (and 192.168.100.0 is a non-conflicting subnet):

sshuttle -D -r <hypervisor IP> 192.168.100.0/24

Access the following:
http://192.168.100.10/MAAS
It should remind you that post installation tasks need to be completed.

Let’s create the admin user from the hypervisor machine:
ssh ubuntu@192.168.100.10

sudo maas-region-admin createadmin --username=root --email="user@host.com" --password=ubuntu

If you want to limit the types of boot images that can be created you need to edit

sudo vim /etc/maas/bootresources.yaml

Import boot images, using the new root user you created to log in:
http://192.168.100.10/MAAS/clusters/
Now click 'import boot images' and be patient as it will take some time before these images are imported.

Add a key for the host machine here:
http://192.168.100.10/MAAS/account/prefs/sshkey/add/

Configure the MAAS Cluster

Follow instructions here to setup cluster:
http://maas.ubuntu.com/docs/cluster-configuration.html

http://192.168.100.10/MAAS/clusters/
Click on ‘Cluster master’
Click on edit interface eth1.

Interface: eth1
Management: DHCP and DNS
IP: 10.10.10.10
Subnet mask: 255.255.255.0
Broadcast IP: 10.10.10.255
Router IP: 10.10.10.10
IP Range Low: 10.10.10.100
IP Range High: 10.10.10.200

Click Save Interface
Ensure Nodes Auto-Enlist

Create a MAAS key and use that to log in:
http://192.168.100.10/MAAS/account/prefs/
Click on ‘+ Generate MAAS key’ and copy that down.

Log into the maas-server, and then log into maas using the MAAS key:
maas login maas-server http://192.168.100.10/MAAS

Now set all nodes to auto accept:

maas maas-server nodes accept-all

Setup keys on the maas-server so it can access the virtual machine host

sudo mkdir -p ~maas
sudo chown maas:maas ~maas
sudo -u maas ssh-keygen

Add the pubkey in ~maas/.ssh/id_rsa.pub to the virsh servers authorized_keys and to the maas SSH keys (http://192.168.100.10/MAAS/account/prefs/sshkey/add/)

sudo cat /home/maas/.ssh/id_rsa.pub

Now install virsh to test a connection and allow the maas-server to control maas-nodes.

sudo apt-get install libvirt-bin

Test the connection to the hypervisor (replace ubuntu with hypervisor host user)

sudo -u maas virsh -c qemu+ssh://ubuntu@192.168.100.1/system list --all

Confirm Maas-Server Networking

Ensure we can reach important address via maas-server:

host streams.canonical.com
host store.juju.ubuntu.com
host archive.ubuntu.com

And that we can download charms if needed:

wget https://store.juju.ubuntu.com/charm-info

Setup Traffic Forwarding

Setup maas-server to forward traffic from eth1 to eth0:

You can type the following out manually or add it as an upstart script to ensure forwarding is setup properly each time add this file to /etc/init/ovs-routing.conf (thanks to Juan Negron):

description "Setup NAT rules for ovs bridge"

start on runlevel [2345]

env EXTIF="eth0"
env BRIDGE="eth1"

task

script
 echo "Configuring modules"
 modprobe ip_tables || :
 modprobe nf_conntrack || :
 modprobe nf_conntrack_ftp || :
 modprobe nf_conntrack_irc || :
 modprobe iptable_nat || :
 modprobe nf_nat_ftp || :

 echo "Configuring forwarding and dynaddr"
 echo "1" > /proc/sys/net/ipv4/ip_forward
 echo "1" > /proc/sys/net/ipv4/ip_dynaddr

 echo "Configuring iptables rules"
 iptables-restore <<-EOM
*nat
-A POSTROUTING -o ${EXTIF} -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i ${BRIDGE} -o ${EXTIF} -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -i ${EXTIF} -o ${BRIDGE} -j ACCEPT
-A FORWARD -j LOG
COMMIT
EOM

end script

Then start the service:

sudo service ovs-routing start

Setup Squid Proxy

Ensure squid proxy can access cloud images:

echo "cloud-images.ubuntu.com" | sudo tee /etc/squid-deb-proxy/mirror-dstdomain.acl.d/98-cloud-images

sudo service squid-deb-proxy restart

Install MAAS Nodes

Now we can virt-install each maas-node on the hypervisor such that it automatically pxe boots and auto-enlists into MAAS. You can adjust the script below to create as many nodes as required. I’ve also simplified things by creating everything with dual nics and ample memory and hard drive space, but of course you could use custom machines per service. Compute-nodes need more compute power, ceph nodes will need more storage, and quantum-gateway will need dual nics. In addition you could specify raw disks instead of qcow2, or use storage pools; but in this case I wanted something simple that didn’t automatically use all the space it needed.

for i in {0..19}; do
 virt-install \
 --name=maas-node-${i} \
 --connect=qemu:///system --ram=4096 --vcpus=1 --hvm --virt-type=kvm \
 --pxe --boot network,hd \
 --os-variant=ubuntutrusty --graphics vnc --noautoconsole --os-type=linux --accelerate \
--disk=/var/lib/libvirt/images/maas-node-${i}.qcow2,bus=virtio,format=qcow2,cache=none,sparse=true,size=32 \
 --network=network=maas_internet,model=virtio \
 --network=network=maas_management,model=virtio 
done

Now each node needs to be manually enlisted with the proper power configuration.
http://maas.ubuntu.com/docs/nodes.html#virtual-machine-nodes

Host Name: maas-node-${i}.vmaas
Power Type: virsh
Power Address: qemu+ssh://ubuntu@192.168.100.1/system
Power ID: maas-node-${i}

Here we need to match the machines to the mac address and update the power requirements. You can get the mac addresses of each node by using the following on the hypervisor:

virsh dumpxml maas-node-${i} | grep "mac addr"

Here is a script that helps automate some of this process, it can be run from the maas-server (replace USER ubuntu with the appropriate value) this matches mac address from virsh to the ones in maas and then sets up the power accordingly:

#!/usr/bin/python

import sys, os, libvirt
from xml.dom.minidom import parseString
os.environ['DJANGO_SETTINGS_MODULE'] = 'maas.settings'
sys.path.append("/usr/share/maas")
from maasserver.models import Node, Tag

hhost = 'qemu+ssh://ubuntu@192.168.100.1/system'

conn = libvirt.open(hhost)
nodes_dict = {}
domains = conn.listDefinedDomains()
for node_name in domains:
 node = conn.lookupByName(node_name)
 node_xml = parseString(node.XMLDesc(0))
 node_mac1 = node_xml.getElementsByTagName('interface')[0].getElementsByTagName('mac')[0].getAttribute('address')
 nodes_dict[node_mac1] = node_name

maas_nodes = Node.objects.all()
for node in maas_nodes:
 try:
 system_id = node.system_id
 mac = node.get_primary_mac()
 node_name = nodes_dict[str(mac)]
 node.hostname = node_name
 node.power_type = 'virsh'
 node.power_parameters = { 'power_address':hhost, 'power_id':node_name }
 node.save()
 except: pass

Note you will need python-libvirt and run the above command with something like the following:

sudo -u maas ./setup-nodes.py

Setup Fastpath and Commission Nodes

You most likely want to use fast-path installer on nodes to speed up installation times. Set all nodes to use fastpath installer using another bulk action on the nodes.

After you have all this done, click bulk action commission.
You should see all your machines starting up if you set things up properly, give this some time. You should have all the nodes in the 'Ready' state in maas now!
http://192.168.100.10/MAAS/nodes/

Confirm DNS setup

One point of trouble can be ensuring DNS is setup correctly. We can test this by starting a maas node and inside of that trying the following:

dig streams.canonical.com
dig store.juju.ubuntu.com

If we can’t hit those, we’ll need to ensure the maas server is setup correctly.
Go to: http://192.168.100.10/MAAS/settings/
Enter the host machines upstream DNS if necessary here, it should setup the bind configuration file and restart that service. After this re-test.

In addition I had to disable dnssec-validation for bind. Edit the following file:

sudo vim /etc/bind/named.conf.options

And change the following value:

dnssec-validation no;

And restart the service:

sudo service bind9 restart

Now you have a working virtual maas setup using the latest Ubuntu LTS!

using kgraft with ubuntu

Fri, 06 Jun 2014 11:50:00 -0700

New live kernel patching projects have hit LKML recently here and here, and I’ve taken the opportunity to test drive kGraft with the Ubuntu kernel. This post documents how to get a sample patch working.

First, I had to take the patches and apply them against the ubuntu-utopic kernel, which is based on 3.15-rc8 as of this post. They cherry-picked cleanly and the branch I’m using is stored here. In addition to applying the patches I had to also enable CONFIG_KGRAFT. A pre-built test kernel can be downloaded here.

creating a local vm easily and automatically

Wed, 05 Mar 2014 14:22:00 -0800

This is the nifty little snippet I use to create a quick and dirty VM for testing. Just apt-get install vmbuilder and run the following:

NAME="ubuntu"
vmbuilder kvm ubuntu --arch 'amd64' --suite 'precise' \
--rootsize '8096' \
--mem '1024' \
--components 'main,universe' \
--addpkg vim \
--addpkg openssh-server \
--addpkg bash-completion \
--user 'ubuntu' --pass 'ubuntu' \
-d /var/lib/libvirt/images/${NAME} \
--libvirt qemu:///system \
-o \
-v --debug \
--hostname ${NAME}

If you need additional help consult the serverguide

using LTS HWE kernels with MAAS nodes

Wed, 05 Mar 2014 14:21:00 -0800

Once you get machines setup using MAAS, you may want to be able to install an alternative kernel when starting a machine. Here’s how to do it.

This is assuming we have already commissioned a node, but have not started it.

If we are using the normal installer with MAAS do the following: Edit /etc/maas/preseeds/preseed_master on your maas-server

Add the second line as shown:

d-i base-installer/kernel/image string linux-server d-i
base-installer/kernel/override-image string linux-generic-lts-saucy

Start the node, Now when you boot you should be using the 3.11 series kernel.

creating a local vm domain from an ubuntu cloud image

Mon, 17 Feb 2014 11:43:00 -0800

It is very convenient to be able to quickly spin up a local VM in order to do some sort of bug verification or testing. Generally I can use a cloud provider to spin up an instance, but occasionally you need the flexibility of a local VM in order to setup more complex networking or other specific environments.

This link was extremely helpful in figuring our how to setup a ready to boot image, but I noticed a few issues. First, on Precise I didn’t have the cloud-localds tool, and second there wasn’t a very simple way to import the image into libvirt.

automatic bisection of qemu with console and monitor interaction

Mon, 16 Dec 2013 14:39:00 -0800

I had some fun debugging a performance issue after VM migration on v1.0. Because this was fixed in newer versions, a bisect was in order. Doing this manually becomes very tedious so writing some scripts to use git bisect run really helps. Here I’ll document how I did this in case others find it useful when trying to bisect issues in qemu.

First step is getting the problem reproducible using the command line. In addition you will also need to output anything that be used to determine if the test case passes or fails using standard console output. This makes it easy to run the test case with expect. You will need to follow on how to setup your VM to use serial output.

setup an external drives as raid1

Mon, 16 Dec 2013 14:37:00 -0800

I purchased a cheap two drive USB enclosure in order to setup an external drive that had RAID-1 so I could backup photos and recordings.

First, I formatted both drives. Then I ran extended smart self-tests to ensure I had decent drives. With RAID-1 and two drives I can only tolerate 1 drive failure.

Next ensure mdadm is installed: sudo apt-get install mdadm

Determine which dev devices the disks show up as. Next, create the raid device pointing at the correct dev directory.

use default gpg key for debuild

Tue, 10 Sep 2013 09:30:00 -0700

When using debuild -S to build a package on new machines, I need to go through the process of ensuring that my gpg is set up properly. If set up incorrectly, I get the following message with debuild -S:

gpg: skipped "User <user@host.com>": secret key not available

To fix this, I go through the following steps:

Ensure I have proper gpg keys set up. You can check if yours is installed properly using: gpg --list-keys
Add DEBEMAIL and DEBFULLNAME to ~/.bashrc. Ensure DEBEMAIL matches the email in the matching gpg key, and ensure DEBFULLNAME matches the name in same key. Put these into your ~/.bashrc file or wherever they will be sourced into your environment.
Make sure your key is the default key: Edit ~/.gnupg/gpg.conf such that default-key is set to the proper key. This should match the 8 character fingerprint that you verified in (1).
Make sure the same key is the default for debuilder: Edit /etc/devscripts.conf with the folllowing: DEBSIGN_KEYID=XXXXXX where XXXXXX is your key.
Now next time you use debuild -S it should use the proper gpg key, name and email address!

building a proper debian source package with dkms

Thu, 05 Sep 2013 07:10:00 -0700

How can one use DKMS to build a proper debian source package? The mkdsc command will actually generate one automatically, but there are a few more steps to simplify it, and bring it up to date.

First follow the steps here for setting up a DKMS package. Make sure you can build it using dkms. Then do the following:

#First pull in some dependencies as necessary
sudo apt-get install devscripts debhelper

# Create the debian source package
sudo dkms mkdsc -m hello -v 0.1

# Create a directory to work in, and let’s copy those files into it
mkdir ~/dsc && cd ~/dsc
cp /var/lib/dkms/hello/0.1/dsc/* .

# Extract the .dsc to be able to edit the directory
dpkg-source -x hello-dkms_0.1.dsc 
cd hello-dkms-0.1

If we run debuild -uc -us, we see a few lintian errors and warnings:

building a binary debian kernel module package with dkms

Tue, 23 Jul 2013 14:40:00 -0700

DKMS packaging works great for building out of tree kernel modules. However, what do you do when you need to install to a machine without a compiler? You can accompish this by using DKMS’s mkdriverdisk functionality.

First follow the steps here for setting up a proper DKMS package.

After you’ve built the module successfully, you can use the following bash script to extract the .deb installer from the driverdisk. This way you can copy the deb file to the target machine and install. You must ensure that $(uname -rm) on the target machine matches the build machine.