Remote build of the Linux Kernel via Ironic

Ampere Computing chips run the ARM64 instruction set. My laptop is a Dell running x86_64. In order to edit locally, but build remotely, I make use of servers in our datacenter. These are the steps I am taking.

Prep the machine

First, I create a new server, using Ironic. The following one-liner is the kind of call I can make to create the server instance on a baremetal machine and then add a floating IP address to it.

openstack server create --flavor bm.falcon --image fedora-server-34-aarch64-qcow2 --network baremetal-dataplane --key-name ayoung  f34-kernel-test
openstack server add floating ip f34-kernel-test

Obviously, I have a lot of pre-canned knowledge of the cluster in order to run this command. I know that the flavor bm.falcon will grab one of our falcon instances, and that the image I want for a Fedora 34 server is fedora-server-34-aarch64-qcow2. The following commands let me look up this kind of information:

openstack floating ip list
openstack flavor list
openstack image list
openstack network list
openstack keypair list

The second command adds a floating IP to the server instance. A Floating IP is routable outside of the rack. If I don’t add a floating IP, the server will only have link local IP addresses, and the VMs will only be able to talk to each other, and then only if on the same network.

Assuming I am on a machine with the private key that matches the public key identified by the –key-name parameter, I can ssh in to the VM as the fedora User.

ssh fedora@
The authenticity of host ' (' can't be established.
ED25519 key fingerprint is SHA256:sCiBSBv0bmNyBgkprz/TwyY5SI6LmciITNGfUm78wsU.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '' (ED25519) to the list of known hosts.
Failed Units: 1
[fedora@f34-kernel-test ~]$ exit

Once I can get in to the machine interactively, I can use the ssh command to run remote commands. A simple smoke test is to run pwd:

$ ssh fedora@ pwd

Or hostname

$ ssh fedora@ hostname

Send the code

I do not need the entire git repository on the remote machine in order to test it. However, I do want to make sure I check in all my code to some branch to make sure I don’t lose it. If I use the git archive command, I can send the source tree over in a stream, and expand it on the remote side.

git archive --format=tar HEAD | ssh fedora@ "mkdir  -p devel/linux && cd devel/linux && tar -x "

The && makes sure that the previous command succeeds before attempting the following command. That keeps you from expanding the contents of the linux directory into your home directory.

Yes, I made that mistake. It is a mess and a pain to clean.

Remote Compile and Install

Here is a pretty clean write up of the set of steps to follow in order to build, install, and run your own kernel.

We can use ssh in order to install the prerequisite packages needed to build the kernel…

ssh fedora@ "sudo dnf install -y kernel-devel kernel-headers bc xz cpio openssl dwarves"
ssh fedora@ sudo dnf group install -y \"Development Tools\"

and to execute the build processes…

ssh fedora@ "cd devel/linux  && make -j 32"
ssh fedora@ "cd devel/linux  && make modules -j 32"

…and to install the kernel…

ssh fedora@ "cd devel/linux  && sudo make install "
ssh fedora@ "cd devel/linux  && sudo make modules_install "

…and to configure the system to boot the kernel.

ssh fedora@ "cd devel/linux  && sudo  grubby --set-default /boot/vmlinuz-5.15.0-rc4"

Confirm that the kernel we want is configured and default:

$ ssh fedora@ "sudo grubby --default-kernel"

Reboot the remote machine and wait for it to come back up.

ssh fedora@ "sudo reboot"

And check the remote status. Note that a change of the Linux Kernel might change the ssh key fingerprint. I had to remove a couple of entries from ~/.ssh/known_hosts.

$ ssh fedora@ "uname -a"
Linux f34-kernel-test.novalocal 5.15.0-rc4 #1 SMP Thu Oct 21 20:07:43 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux

These are just my notes for a positive thread, not a recommendation of how to do it. Obviously, the repeated ssh command and parameters should be scripted somehow. Ansible is a likely target. Some of these commands could be put into a script and Some of these commands could be put into a script and executed together as well. What direction we go will in part be directed by the technology we need to perform other tasks, such as queueing and scheduling. Bash is a good starting point, as it is easy to translate to the other technologies.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.