example.com

Alpine Linux 'diskless' install | kris.sh

2026-04-12T05:27:24-05:00

Alpine Linux is an interesting distribution- it's incredibly small, uses a solid software stack, and I seem to be unable to stop making posts about it.

One interesting thing that can be done with Alpine is a "diskless" installation- that being an installation where the system is loaded into RAM on startup, and runs there until the system shuts down.

In addition, by default, none of the changes made to this in-RAM system will be saved to the actual disk on the system, making it "amnesic." This is particularly useful for applications where one may not want changes/logs/etc to be saved to the disk (such as for a VPN gateway/host). Of course, changes can be explicitly committed to the disk- otherwise, it would be pretty much impossible to make a useful system out of this.

In my case, I have acquired a Dell Wyse 3040 N10D thin client- a system that has 8G of soldered EMMC storage with no decent ways to expand. Given how notoriously fragile EMMC is, let alone how slow it is, running a system from the 2G of memory this system has suddenly looks extremely appealing in order to touch the EMMC as little as possible.

Precursory information as to why I've done this aside, here's how this can be set up:

Diskless Alpine Installation

This guide assumes you've already written an Alpine live ISO to a flash drive/dvd/otherwise, and have booted it up.

First, log into the installation media- we're going to use the default Alpine ISO utilities to deploy the system.

Once logged in, run the setup-alpine script as per usual (I'm not going to cover this in the guide, it's well documented external to this, including in other posts on my blog).

Proceed through the installation process as per usual until you've chosen an apk mirror, and hit Ctrl+C to quit the installer- we will continue with that later. The point of this is to configure a few of the basics like networking in the live environment.

Once you've exited the Alpine installer, we need to install a few utilities via: apk add util-linux wipefs lsblk, wipefs here is optional if the internal storage is already completely blank, but it's always best to make sure regardless. util-linux will provide us with fdisk so we can format the internal drive.

Next, run lsblk and figure out what disk you're going to turn into your diskless boot drive- for this guide I am going to assume /dev/vda.

In order to wipe the disk, you may run wipefs --all /dev/vda. BE AWARE, this will completely wipe the drive- back up anything on it you may want to keep beforehand (though, please try to avoid storing important data on EMMC if you can avoid it).

Once your disk has been nuked, run fdisk /dev/vda and create a partition table. After the partition table has been created, you may create a single FAT32 partition- this is where your boot files and configuration will live.

The key combination I've used to do this is as follows: o n p <enter> <enter> <enter> t b w, as shown below:

This key combination will create a partition table, a primary partition to hold your boot files, and set the type to W95 FAT32.

After exiting fdisk, we need to format the new partition- this can be done with: mkfs.vfat /dev/vda1, again, adjusting for the drive/partition that applies to you.

Next, we need to figure out where the installation media is mounted- you can find this information by running df as shown below:

In my case, the live media is /media/cdrom.

Now, to actually deploy the system to the "diskless" boot drive, we're going to use Alpine's setup-bootable script. The syntax is as follows: setup-bootable <live_system> <target>

<target> in this case is the drive we want to deploy to, so in my case, the correct command would be: setup-bootable /media/cdrom /dev/vda1.

Once you've done this, you're free to shut the system down and pull your live media. The system should now start off of the "diskless" boot drive.

Configuring a new diskless Alpine installation

You may notice upon booting that the system is almost identical to the live media you just removed- because it pretty much is.

Now that the system has started off of the "new" installation, run setup-alpine again. This time, we will be going through it to completion as you would with a normal Alpine installation- but with a few important differences.

Once making it to the point in the Alpine installer that you're asked to select a disk, you should enter none. After doing this, the installer will prompt us to enter locations for storing configs- one of these should be the disk we've just booted from, and one will be a directory on the same disk to store apk cache.

Configure as follows, replacing the values with ones that apply to your system:

Ignore the error about apk cache here, this will be solved when you run apk update on the new system and commit that change.

Once you've finished this, run lbu commit to make your configuration save to disk to be loaded on the next startup. This command should be kept in mind- if you make any changes to the new system, they will not persist across boots unless you commit them to the disk like this.

Congrats your new diskless Alpine install!

Notes on lbu and disk commits

By default, there are some directories that aren't tracked by lbu, namely /home and /root. Of course, this can be an issue if you set up a normal user- luckily this is very easy to fix.

In order to add directories to be captured in your disk commits, run lbu add /dir, replacing /dir with the directory you would like to add, such as /home.

Important configuration directories such as /etc should be captured in your disk commits by default.

Editing kernel parameters

In order to configure kernel parameters on your new system, you'll have to mount the disk as read/write as opposed to read-only. To do this, you can simply run mount -o remount,rw /media/vda1, replacing vda1 with your partition. Once you've done this, you can open up /media/vda1/boot/grub/grub.cfg in a text editor and configure your kernel parameters to your heart's content (Alpine includes vi by default).

After editing, simply run: sync && mount -o remount,ro /media/vda1 to put things back how they were, and then reboot the system to see them applied as per usual.

Closing thoughts

I don't have any, but this section seems to always exist. Have fun with your new install.

What Linux distro should I use? | kris.sh

2025-07-30T09:57:13-05:00

This has become an incredibly difficult or impossible question to answer.

This post is inclined to be somewhat based on opinion, You have been warned.

If you want the short answer, pick something that looks interesting to you, try it out, and if you hate it? There are practically an infinite number of distros out there to try out next. (Though, I don't want to create a distrohopping addiction via this post.)

Everything sucks in one way or another? (foreshadowing) Well, you could always create your own or find something like kiss linux to base off of and bootstrap your own thing, though I do think this is (slightly) unreasonable to expect from a new user.

Some basic criteria for a new user

Display server

First and foremost, there are a lot of people with fairly "unusual" (these quotes are quite load-bearing) display setups, and despite whatever illogical thought process would lead one to disagree with this- Wayland support for a new user is going to be incredibly important.

In the context of distributions that are typically recommended to new users, Linux Mint for example is one that usually comes up in the discussion, and with no hostility towards Linux Mint whatsoever, there is no stable/established Wayland support with any of their default desktop environment options.

Problems that may arise from X11 only environments would primarily include lack of support for mixed refresh rate displays without horrifically hacky workarounds that at best result in major amounts of screen tearing, due to the fact that both displays are more or less treated as one- running the higher refresh rate display at the framerate corresponding to the lower one, or vice versa (hence hacky workaround). This is a problem I personally fought with for years via my high (170/240hz) and low (60hz) refresh rate displays until I bought an AMD graphics card years ago and was finally able to move to Wayland permanently.

Another notable issue that does not matter much to me personally, with X11 you are unable to use freesync at all if you have more than one display connected- even if they're identical.

Of course, scaling on X11 can also be a problem, among issues with modern display features in general.

The solution? Ask some questions about the hardware someone is using before making a suggestion- or just recommend something that provides a Wayland option that is relatively stable and established- such as an option that provides KDE or GNOME.

The primary concern here is that a user is going to install this, spend a bit trying to figure out why their monitors don't work correctly, and then bounce to something else or just flee back to Windows.

Sensibly up to date software

When I suggest something "sensible" in this context- what I mean is generally not outdated enough to be a problem with newer hardware- which immediately rules out certain things that are (unreasonably) highly outdated- Debian for example, unless one chooses to use Debian Testing or pull specific things from backports so one is able to use newer hardware.

I think there's a happy medium here- my personal general distribution of choice, Void, typically does not roll out "bleeding edge" software, but is also not generally "outdated." I tend to also be a fan of distributions that roll out a new release every 6 months or so, an example of a distro that does this (or sometimes, roughly this) would be Fedora, though for various reasons (moderately annoying to pull Nvidia graphics drivers, weirdness around codecs, heavy-handed corporate involvement regardless of what people may suggest), I find it difficult to recommend. Alpine is another distribution that roughly does this, though quite difficult to recommend to newer users.

Arch would be a distro with relatively sanely up to date software, though I am personally not a fan of the "update just because there's an update" mentality around bleeding edge distributions.

Software availability

While less of a concern compared to the days of old due to awesome solutions like flatpak, software availability does matter in certain contexts. I imagine most users are allergic to packaging the things they need themselves, and should find something that has a lot of packages (preferably of decent quality) available.

I really seem to be talking about Arch a lot for someone who isn't a big fan, but I do think it is appropriate for newer users these days who aren't quite sure what they want.

Arch is pretty good at this due to the AUR, or Arch User Repository. The problem here is that random things on the AUR cannot be trusted. At minimum, you should be seeking packages that have a positive reputation and good comments, and preferably actually auditing packages you install yourself. There have been many cases of something malicious being uploaded to the AUR, and really the responsibility for that falls on the user being conscious of what they're doing.

Also, just to hammer that in, for all intents and purposes the AUR should be treated like a public torrent tracker, just with generic Arch packages as opposed to torrents. Oh, the days of keygen music and 12 toolbars suddenly appearing in Internet Explorer, along with the search engine changing on its own! Seriously though, most packages are inclined to be fine but please be careful.

Being responsible with recommending a distribution

The point I am more or less trying to make here is that there isn't a good recommendation, and if you're asking the question of "What Linux distro should I use?" then generally, it probably doesn't matter much as you've yet to reach the point of developing opinions about certain software, but try not to deploy something that is going to be predictably problematic in one way or another. The key here is up to date software and a choice of what higher level software (desktop environments and the like) you interact with.

If suggesting distributions, try to keep in mind the experience a newer user may have with the thing you recommend in their case, with their hardware and level of experience may completely tarnish their opinion of the Linux ecosystem in general (though personally, I think modern Linux is a bit of a nightmare, blanket statement.)

More or less what I mean here is that new users are not going to stick around if they're dropped into the deep end immediately. Though, there is some value to this- given someone chooses to stick around and actually learn Linux, they're bound to be a higher quality member of the community in general.

So what distributions do YOU like, then?

I get the sense that answering this question may lead to the (incredibly few) readers of this article interpreting my answer as a distro recommendation- it isn't.

Though, I know an answer is probably expected here, and reasonably so, so with the above in mind:

Void - Has been my daily driver on both server and desktop for nearing 4 years as of the time of writing.
Kiss - Uses a software stack I agree with by default assuming one uses the musl branch.
Crux - I like the packaging system, and may only get slightly irritated with glibc.

Importantly, there are certain bits of software that I fundamentally disagree with- such as systemd. I definitely do not want spark some sort of illogical and ill-willed argument about systemd, the "religious" haters tend to completely miss the mark here. Fundamentally, if I don't want to use a specific piece of software (or in the case of systemd, a massive metapackage of random things), I should not have to. Opinions like this are what influence my own distribution choices. And again because I know someone will ask- runit is my preferred init system / service manager, and a bunch of random other software to fill in the minor gaps for things that require systemd-isms- because that's sadly where the ecosystem has landed.

The above minor example of an opinion about what software goes into creating a Linux operating system is the type of opinion that will generally be developed over time via exposure, I wouldn't get too caught up on specific details like this until you've gained some experience.

Should your opinions influence my own?

No. Your own opinions are realistically the only ones that should matter to you. I am merely trying to bring up issues with the various approaches here.

This is the place this conversation usually leads to, and I know you are expecting some form of direct answer. In short- I have absolutely no idea. I do not know you, nor how you use your computer, nor what kind of hardware you have, nor your philosophical views which may influence your choice.

At best, I may be able to provide moderately random shots in the dark that may or may not stick, but do see the above "Being responsible with recommending a distribution."

Depending on someones level of experience with computers in general, I have a knack for recommending Arch installed via archinstall, as one of these "shots in the dark."

Despite the numerous issues with archinstall (mostly in terms of stability and questionable defaults), and despite the fact that it's not recommended by the Arch team (despite the fact that it's included in the official ISO by default? hello???), it may be a very quick and easy way for someone to get a system up that has up to date software, assuming they have someone to bounce questions off of while running the installer, and a practically endless level of software support, though I personally do not like Arch very much myself.

EndeavourOS seems to be a valid shout, as it's relatively close to the Arch upstream and changes very few things that are bound to be minor adjustments to most users. The target here in my opinion would be people who look at a command line application (such as archinstall) and immediately decide it's too difficult. More or less, this will theoretically provide an Arch experience with "less effort."

Things that don't have much of a reason to exist, generally. There are tons of Arch based distributions for example that do absolutely nothing notable, and at most just ship a desktop environment by default that may or may not have a preconfigured "rice." Most distros like this are pointless.
There are also various distros with an incredibly negative history, things like Manjaro for example, do see manjarno for information about that specifically- it would be redundant for me to type out all of this information here.
Incredibly small/niche distributions are sometimes really cool and are fine to use, and other times they're not. Before Solus had died out, it was my absolute favorite "This just works out of the box!" type distribution, as it was also not the most bloated thing on earth. Nowadays, Solus is apparently back, but the point here is that you may find yourself in a situation of needing to distrohop because the distro you chose has randomly ceased to exist, or it's no longer maintained very well or at all.
Somewhat included in the above bullet point, things that are poorly maintained. PopOS used to be the generic youtuber type suggestion, and at the time that may have been valid, but these days it is quite outdated and quite poorly maintained, as the effort has moved over to developing the Cosmic desktop environment for the time being. Even with major distributions like this, sometimes there are problems that are the same as or adjacent to the above bullet point.

Arch is difficult to use! Muh elitism! I'm so good at computer because I installed Arch!

Stop. This is idiotic and intended to exclude people in a baseless manner. Once Arch has been installed, I personally refute the idea that it is somehow substantially more difficult to use than something else- install your software, use your software, update your system fairly regularly, ask questions, and I promise you'll have things figured out in no time. There is absolutely zero shame in asking questions- just don't be a help vampire, try to respect the nature of receiving free support at the expense of someone elses time in a chatroom on IRC or Discord, a forum somewhere, or whatever you may be using.

All distributions are pretty much the same thing anyway, why does it matter?

Quit it, or I'll get out the rolled up newspaper. This is highly incorrect- and may just seem this way if you only interact with Firefox and Steam on a daily basis and not much else.

DIY Mesh Router | kris.sh

2024-02-16T20:51:42-06:00

A while back, I wrote a script to set up a WiFi to Ethernet bridge device, and I have been using this for my connection at home for a while now. In this post, I will be describing the process of manually setting this up.

If you just want to get your network up without reading further or performing a manual setup, the script can be found on my GitHub here.

I purchased a Dell Optiplex 3040 Micro for ~$100 USD on eBay a bit ago specifically for this purpose due to its awesome WiFi antenna, and have been using this to provide my devices with a connection for roughly a week as of the time of writing.

For the price, this machine wasn't a bad buy (aside from the UEFI implementation being worse than MSIs) with an i5 6500t, 8gb of 1600mhz DDR3, and a 256gb TeamGroup Vulcan Z SSD that magically only had 1 power on hour and 27 power cycles according to S.M.A.R.T data. This machine is completely inaudible, even when under load.

Now, I'm sure you're thinking "Why didn't you just run an Ethernet cable or use MOCA?"

Well, I do not have Coaxial cables ran for MOCA, and I did not want to run an Ethernet cable up my stairs or drill a hole in the ceiling to route the cable through, nor did I want to get WiFi cards for each of my machines as I would prefer to keep my LAN transfers on Ethernet, so this machine connected to a switch is a good solution.

Necessary software

To achieve this setup, we will be using nftables for our NAT (Network Address Translation), dnsmasq for our DHCP server to provide devices with IP addresses, and iproute or ifupdown to configure our interfaces.

ifupdown is really preferred here, as with iproute we will be creating services to run our commands, while ifupdown is an actual process rather than just a CLI tool. However, some Linux distributions do not use or package ifupdown.

Regardless of the Linux distribution you choose to use here, they should have nftables and dnsmasq packaged. For iproute or ifupdown, consult your distributions documentation and choose the appropriate one.

In my case, I will be using Alpine Linux which uses ifupdown.

ifupdown setup

Note: If your distribution does not package ifupdown, you should skip to the iproute setup section instead of following ifupdown instructions.

The goal is to assign a static IP address to this interface, as the IP address of this interface should not be changing.

To set up ifupdown, the following needs to be added to /etc/network/interfaces:

auto <ethernet-interface> 
allow-hotplug <ethernet-interface>
iface <ethernet-interface> inet static
    address <ethernet-interface-ip> 
    gateway <ethernet-interface-ip>

<ethernet-interface> in the auto, allow-hotplug, and iface lines should be replaced with the ethernet interface you intend to use for connecting other devices you'd like to provide with internet, such as eth0.

<ethernet-interface-ip> in the address line should be replaced with the IP address you want to give this interface, I typically put 10.0.1.1/24 here because I use 10.0.0.X on my normal networks. /24 here specifies the subnet mask via CIDR notation.

<ethernet-interface-ip> in the gateway line should specify the gateway, you can enter the same value as the address line, so 10.0.1.1/24 for this example.

Once you've done this, your Ethernet interface has been fully configured and you can continue to the nftables setup.

iproute setup

Note: If your distribution packages ifupdown, you should go back to the ifupdown section instead of using iproute commands.

Unlike ifupdown, iproute is just a CLI tool to configure an interface.

In order to achieve what we're trying to do here, it's necessary to have these commands run on every boot, so the most straightforward option is to use SystemD/OpenRC services.

The goal is to assign a static IP address to this interface, as the IP address of this interface should not be changing.

OpenRC:

Create a file in /etc/init.d to be your service, you can name this anything you want to, however I will call mine "wirelessebridge"

Contents of /etc/init.d/wirelessebridge:

#!/sbin/openrc-run
command="ip addr add <ethernet-interface-ip> dev <ethernet-interface> && \
ip link set <ethernet-interface> up && \
rc-service dnsmasq restart"

SystemD:

Create a file in /etc/systemd/system to be your service, you can name this anything you want to, however I will call mine "wirelessebridge.service"

Contents of /etc/systemd/system/wirelessebridge.service:

Description=Configure wireless eth bridge interface

[Service]
Type=oneshot
ExecStart=/bin/sh -c "ip addr add <ethernet-interface-ip> dev <ethernet-interface> && \
ip link set <ethernet-interface> up && \
systemctl restart dnsmasq"

[Install]
WantedBy=multi-user.target

For both of these setups, <ethernet-interface> should be replaced with the Ethernet interface you intend to use for connecting other devices you'd like to provide with internet, such as eth0.

<ethernet-interface-ip> should be replaced with the IP address you want to give this interface, I typically put 10.0.1.1/24 here because I use 10.0.0.X on my normal networks. /24 here specifies the subnet mask via CIDR notation.

Once you've set this up for the init system you are using, your Ethernet interface has been fully configured and you can continue to the nftables setup.

nftables setup

After you have set up ifupdown OR iproute services, it's time to begin setting up our NAT with nftables.

The role of NAT (Network Address Translation) is at the core of how this functions, as NAT provides us with a way to route traffic to another IP address, such as from our wireless interface to our Ethernet interface.

To get started, we need to create a NAT table with:

nft add table ip nat, the type ip here does specify IPv4 addresses.

Once we've created our table to store our chains, it's time to create the postrouting chain in the NAT table with:

nft add chain ip nat postrouting '{type nat hook postrouting priority 100; policy accept;}'

Postrouting allows us to alter packets after they have exited the output chain.

Next, we need to add a rule to our postrouting chain with:

nft add rule ip nat postrouting oifname <wireless-interface> masquerade

<wireless-interface> here should be replaced with the name of the wireless interface on the system, such as wlan0.

oifname here specifies the output interface.

masquerade is a Linux networking concept that allows us to translate an IP address (or multiple IP addresses) to a different single IP address.

If you have a filter table in your nftables config, you need to allow forwarding via:

nft add chain inet filter forward '{type filter hook forward priority 0; policy accept;}'

You should also allow input from the Ethernet interface:

nft add rule inet filter input iifname <ethernet-interface> accept

Similar to oifname for the wireless interface, iifname here specifies the input interface.

After you've completed these steps, do save your nftables config via:

nft list ruleset > /etc/nftables.conf or potentially nft list ruleset > /etc/nftables.nft, depending on where this config should exist for your distro of choice. On Alpine Linux, this file exists at /etc/nftables.nft.

Enabling IPv4 forwarding

Enabling IPv4 forwarding should be the same process on all Linux distros, just adding a line to the /etc/sysctl.conf file with:

echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf

If this line already exists in this file, uncomment it instead of adding a new line.

dnsmasq setup

Finally, we need to set up dnsmasq for our DHCP server.

Add the following contents to /etc/dnsmasq.d/ethbridge.conf:

interface=<ethernet-interface>
bind-interfaces
server=<dns-server>
domain-needed
bogus-priv
dhcp-range=<dhcp-range>

Replace <ethernet-interface> here with the name of the same Ethernet interface we specified earlier, such as eth0.

Replace <dns-server> here with the IP address of your preferred upstream DNS server, since I prefer Quad9, I use 9.9.9.9 for this value.

Replace <dhcp-range> with your desired range of IP addresses and their lease time, since I use 10.0.1.X addresses for this, I will use 10.0.1.2,10.0.1.254,24h for this value. This specifies a range of 10.0.1.2 through 10.0.1.254 with a lease time of 24 hours, starting at 10.0.1.2 because 10.0.1.1 belongs to the Ethernet interface on this device.

bind-interfaces here tells dnsmasq to bind only the interfaces it is listening on, instead of binding the wildcard address.

domain-needed here tells dnsmasq to never forward plain names. (Names without a dot or domain part)

bogus-priv here tells dnsmasq to never forward addresses in the non-routed address spaces.

According to the dnsmasq example config file, the last two options (domain-needed and bogus-priv) filter out queries which the public DNS cannot answer, and which load the servers unnecessarily.

Once you have completed this, assuming you've also completed your nftables and ifupdown or iproute setup, you should be able to reboot this machine and get an IP address and internet from the Ethernet port on this device! (Assuming it's connected to WiFi.)

Closing thoughts

While this is a somewhat lengthy process to complete manually, my goal here was to explain a bit about the technology that goes into a setup like this. However, if you just went for the script to set this up automatically, that's still awesome!

If you found this script or blogpost useful, I would appreciate a star on the Github repository for this script!

MSI Motherboard Woes | kris.sh

2024-02-04T14:59:53-06:00

I just can't get enough UEFI, huh?

Introduction

I have had my fair share of problems related to MSI motherboards, and I thought it may be reasonable to briefly talk about some of these issues and provide the workarounds I've discovered for them.

UEFI Standards Compliance

Unfortunately, we live in a world where not all UEFI implementations are ideal or correct.

According to the UEFI specifications, "The firmware should not, under normal operation, automatically remove any correctly formed Boot#### variable currently referenced by the BootOrder or BootNext variables. Such removal should be limited to scenarios where the firmware is guided by direct user interaction."

It seems to be a trend with MSI motherboards to directly violate this. This issue can be discovered when one chooses to pursue a somewhat abnormal setup, such as booting from a UKI (Unified Kernel Image) or by using efistub, but also with run-of-the-mill setups when installing GRUB normally via the grub-install command.

After running grub-install, or using efibootmgr to create the boot entry, it's possible to list the current boot entries by running efibootmgr without any additional arguments. There, the boot entry should be visible until you reboot. Once rebooted, you may notice that you've not booted into your freshly installed Linux distribution at all, and after booting back into the live Linux system to investigate, running efibootmgr shows your boot entry has magically gone missing.

So what now?

If you're using the GRUB bootloader, this problem can be worked around by adding the --removable flag to your grub-install command.

Otherwise, if you don't want to do that OR are running without a bootloader for an efistub or a UKI setup, it's possible to create an empty file in the expected location to kind of trick the motherboard into not removing your boot entries.

I have achieved this by running mkdir -p /boot/EFI/BOOT and then just creating an empty file there with touch /boot/EFI/BOOT/BOOTX64.EFI, which should work for basically all boot setups.

This behavior has been observed on both my MSI Z490 MAG TOMAHAWK as well as a friend's MSI MPG Z690 EDGE WIFI DDR5.

Do note that if you're using Secure Boot, you'll want to change the boot order on your system so you don't receive a Secure Boot violation when you attempt to boot your system because this empty file isn't signed.

Not-so-Secure Boot

By default, a ton of MSI motherboards have extremely insecure Secure Boot defaults, and my Z490 MAG TOMAHAWK is no exception.

Tucked away in a submenu of the Secure Boot menu that may not be immediately obvious, there's another section called "Image Execution Policy" that determines how it will handle Secure Boot violations, and on a lot of boards, the default is "Always Execute."

"Always Execute" here is an absolutely terrible default, given that if a user were to enable Secure Boot and not check this menu, they will have enabled a feature that does exactly nothing due to it always executing on violation.

Documentation of this behavior and a list of impacted motherboards exists on sbctl's issue tracker.

To solve this issue, if you're using secure boot, do change the "Removable Media" and "Fixed Media" options to "Deny Execute"

Absolutely do not set these to "Always Deny" unless you are aware of what you're doing.

Changing Option ROM to "Deny Execute" can also be a little bit touchy, do be careful if you choose to do so.

Of course, having a security setting that doesn't do what it claims to do by default is worse than just not having said security feature.

There are quite a few other security issues with MSI motherboards that have been well explained on Dawid Potocki's blog, so I won't go into those here.

Closing thoughts

It is quite unfortunate that these issues exist, given that MSI motherboards have some of the best hardware and they tend to be quite reliable.

Hopefully these issues will be solved at some point in the future.

Alpine Linux encrypted UKI install | kris.sh

2024-01-24T10:24:59-06:00

Continuing with my trend of discussing UEFI related topics, today we will be setting up Alpine Linux with encryption and a UKI.

UKI stands for Unified Kernel Image, and it is a single file that will contain our initramfs (which will include CPU microcode if applicable), kernel, kernel parameters, and our os-release information.

This gives us a single file to sign for secure boot, and provides better security compared to running a normal efistub setup with secure boot.

To begin, I assume you've already booted into an Alpine Linux live system via a USB flash drive, CD, or otherwise.

Modifying the Alpine installer

By default, Alpine deploys a typical bootloader, but we can set a variable in the install script to skip installing a bootloader and then chroot into the new system to configure our UKI and boot entry.

Open the /sbin/setup-disk script in a text editor such as vi and add BOOTLOADER"none"= like so:

After this, save the file and continue installing Alpine Linux as you normally would, with the setup-alpine command. Be sure to configure the disk with encryption and LVM.

Mounting partitions

After installing, we need to mount the root partition to /mnt so that we can chroot into it before first boot.

On the live Alpine system, I'm going to install lsblk to get a list of disks and partitions with apk add lsblk. After this, run lsblk to see a list of disks and partitions, in my case:

We need to unlock our new encrypted partition, to do so run cryptsetup luksOpen /dev/vda2 cryptroot, replacing /dev/vda2 with your drives encrypted partition and cryptroot with what you would like to name it, and then enter your encryption passphrase.

Next, run vgchange -ay to activate logical volumes. Then, after running lsblk again, we can see our logical volumes containing the root and swap:

We now need to mount our lv_root to /mnt. To do so, run mount /dev/mapper/vg0-lv_root /mnt. We also need to mount our boot partition, mount /dev/vda1 /mnt/boot in my case.

There are a few more directories that should be mounted before we do anything, condensed into a one-line command:

for dir in dev proc sys run; do mkdir -p /mnt/$dir ; mount --rbind /$dir /mnt/$dir ; mount --make-rslave /mnt/$dir ; done

After that, we can chroot into our new system with chroot /mnt and begin building our initramfs.

Building the new initramfs

If you do not want to include CPU microcode, feel free to skip this section.

Install the intel-ucode, amd-ucode, or otherwise applicable CPU microcode package with apk add cpu-ucode.

To build our new initramfs that includes our CPU microcode, run the following:

cat /boot/intel-ucode.img /boot/initramfs-lts > /tmp/initramfs-lts

Replacing intel-ucode.img as necessary (amd-ucode.img for AMD CPUs).

Kernel parameters

We need to put our kernel parameters into a file to later give our UKI. I'm going to place mine at /root/kernelparams, so run vi /root/kernelparams and begin adding kernel parameters.

Your kernel parameters should not include an initrd parameter.

I am going to include the following:

cryptroot=UUID=<UUID> cryptdm=cryptroot root=/dev/mapper/vg0-lv_root rootfstype=ext4 rw

<UUID> in the cryptroot=UUID= line should be replaced by the UUID of the encrypted root partition. One way of getting the disks UUID is by running blkid -o value -s UUID /dev/vda2 in my case, do replace /dev/vda2 according to your setup.

Replace cryptroot in the cryptdm=cryptroot line with what you would like to name this. I used cryptroot earlier when we opened our LUKS partition, and I will go with that again here.

If you are using another filesystem, such as xfs, be sure to change rootfstype=ext4 accordingly, such as to rootfstype=xfs.

If you would like a quiet output on boot, add loglevel=4 to your kernel parameters.

Save and exit this file.

Building the UKI

The necessary packages for this are binutils and gummiboot-efistub. binutils will provide objcopy, which we will be using to build our UKI, and gummiboot-efistub will provide our stub (don't worry, only this file, not the whole bootloader). These can be installed by running apk add binutils gummiboot-efistub.

Create a script with vi build-uki.sh and give it the following contents:

#!/bin/sh

objcopy \
    --add-section .osrel="/etc/os-release" --change-section-vma .osrel=0x20000 \
    --add-section .cmdline="/root/kernelparams" --change-section-vma .cmdline=0x30000 \
    --add-section .linux="/boot/vmlinuz-lts" --change-section-vma .linux=0x40000 \
    --add-section .initrd="/tmp/initramfs-lts" --change-section-vma .initrd=0x3000000 \
    /usr/lib/gummiboot/linuxx64.efi.stub /boot/alpine.efi

This script will build our UKI with all of the necessary contents. If you placed your kernel parameter file elsewhere, do change the .cmdline"/root/kernelparams"= line to point at your kernel parameter file.

If you chose not to include CPU microcode in your initramfs, point at the normal /boot/initramfs-lts file here instead of the one that would have been placed in /tmp/initramfs-lts if you included CPU microcode earlier.

To make this script executable, run chmod +x build-uki.sh and execute it with ./build-uki.sh.

Once the UKI has been generated, we can create a boot entry that points at it with efibootmgr.

Creating the boot entry

Install efibootmgr with apk add efibootmgr.

To create the boot entry, run the following command:

efibootmgr --create --label "Alpine Linux" --disk /dev/vda --part 1 --loader "\alpine.efi"

Be sure to replace /dev/vda according to your setup.

Finalizing

Assuming all went well, you should be able to boot into the new Alpine Linux install via the UKI.

If you would like to use secure boot, follow the instructions on my Secure Boot on Linux with sbctl post, signing only the UKI file we created in this post (/boot/alpine.efi).

If you would like, place all of the commands ran here into a single script to simplify this process.

Secure Boot on Linux with sbctl | kris.sh

2024-01-17T17:35:10-06:00

Secure boot on Linux has always been a bit of a challenge, however Arch Linux developer Foxboron has created a very useful program called 'sbctl' which makes setting up secure boot extremely simple, boiling the process down to just a few commands.

The GitHub repository for sbctl can be found here.

Preparing the system

To begin, I assume you have a Linux distribution already set up and ready to use.

If you are using the GRUB bootloader, you will have to add the options --modules="tpm" and --disable-shim-lock to your grub-install command for this to work properly. Do consult GRUB documentation if you are unfamiliar with grub-install before continuing.

If you are using efistub, such as guided by my Alpine Linux with efistub and encryption post, no further configuration on the bootloader side of things is necessary.

Our system should have secure boot disabled and should be rebooted into setup mode. The process of rebooting into setup mode does vary by motherboard, so do consult your motherboards manual or look around in your UEFI BIOS for an option to reboot the system into setup mode.

Once you have rebooted the system into setup mode, install the sbctl package according to your distribution of choice.

After installing sbctl, make sure the system is running in setup mode by running the sbctl status command, like so:

After verifying your system is in setup mode, we can begin setting up secure boot.

Creating and enrolling secure boot keys

Begin by running sbctl create-keys to create your secure boot keys. This process may take a moment.

Once this has completed, run sbctl enroll-keys to enroll your secure boot keys. If you are prompted with red text saying Option ROM is present, there are a few options to continue.

The safest option to continue is to enroll using the Microsoft CA, though I have had great success by enabling TPM on my systems and using checksums from the TPM eventlog. Do be very cautious here, as there is a potential to soft-brick your hardware in the event that your GPU Option ROM cannot load, and due to this, you are unable to disable secure boot due to lack of a display output. Having a system with an iGPU could come in handy if this problem arises.

Regardless, once you have enrolled your secure boot keys, we need to make sure that all of the necessary files are signed using the sbctl verify command.

If you recieve the error failed to find EFI system partition, the path to your EFI partition can be specified manually by setting the $ESP_PATH variable. In my case, this error is solved by running export ESP_PATH=/boot as the root user.

If there are any unsigned files listed by this command, they can be signed manually by running sbctl sign -s /path/to/unsigned/file like so:

Once all necessary files are signed, it's time to reboot and enable secure boot.

Finalizing

After rebooting with secure boot enabled, you can verify everything is correct by running sbctl status, and making sure that Setup Mode is disabled and Secure Boot is enabled like so:

If everything looks good, you're all set. Do remember to sign files again if necessary after system updates.

It may be worth looking into creating a UKI (Unified Kernel Image) if you're using an efistub setup.

If you're using GRUB, it may be worth looking into hardening GRUB itself to secure your boot process more.

Alpine Linux with efistub and encryption | kris.sh

2024-01-01T19:01:33-06:00

The Linux kernel can be booted directly by the UEFI firmware, making a traditional bootloader like GRUB not necessary in many cases.

In this post, we're going to set up an Alpine Linux system that uses both efistub and LVM on LUKS.

To begin, I assume you've already booted into an Alpine Linux live system via a USB flash drive, CD, or otherwise.

Modifying the Alpine installer

By default, Alpine deploys a typical bootloader, but we can set a variable in the install script to skip installing a bootloader and then chroot into the new system to configure efistub.

Open the /sbin/setup-disk script in a text editor such as vi and add BOOTLOADER"none"= like so:

After this, save the file and continue installing Alpine Linux as you normally would, with the setup-alpine command. Be sure to configure the disk with encryption and LVM.

Mounting partitions

After installing, we need to mount the root partition to /mnt so that we can chroot into it before first boot.

On the live Alpine system, I'm going to install lsblk to get a list of disks and partitions with apk add lsblk. After this, run lsblk to see a list of disks and partitions, in my case:

Next, run vgchange -ay to activate logical volumes. Then, after running lsblk again, we can see our logical volumes containing the root and swap:

We now need to mount our lv_root to /mnt. To do so, run mount /dev/mapper/vg0-lv_root /mnt. We also need to mount our boot partition, mount /dev/vda1 /mnt/boot in my case.

There are a few more directories that should be mounted before we do anything, condensed into a one-line command:

for dir in dev proc sys run; do mkdir -p /mnt/$dir ; mount --rbind /$dir /mnt/$dir ; mount --make-rslave /mnt/$dir ; done

After that, we can chroot into our new system with chroot /mnt and begin setting up efistub.

Creating the efistub boot entry

For this, we're going to need our encrypted partitions UUID to create a robust boot entry.

One way of accomplishing this is running blkid -o value -s UUID /dev/vda2 and noting down its output. Do change the /dev/vda2 part of this command according to your setup.

To create the efistub boot entry, we will create a script to generate it for us.

First, we need to install the efibootmgr package. Run apk add efibootmgr.

Then, change directories with cd /root, and then vi setup-bootentry.sh to begin creating this script. Do feel free to replace vi with another text editor if you prefer.

Contents of the script:

#!/bin/sh

params="cryptroot=UUID=<UUID> cryptdm=cryptroot \
    root=/dev/mapper/vg0-lv_root rootfstype=ext4 rw \
    initrd=\intel-ucode.img \
    initrd=\initramfs-lts"

efibootmgr --create --label "Alpine Linux" \
    --disk /dev/vda --part 1 \
    --loader /vmlinuz-lts \
    --unicode "${params}" \
    --verbose

params is our list of kernel parameters, while the efibootmgr command is what creates our boot entry.

Replace <uuid> in the cryptroot=UUID=<uuid> line with the UUID of the partition we got earlier from the blkid command.

Replace cryptroot in the cryptdm=cryptroot line with what you would like to name this. I used cryptroot earlier when we opened our LUKS partition, and I will go with that again here.

Change initrd=\intel-ucode.img according to what kind of CPU you have, if you would like. You may also remove this line.

Change --disk /dev/vda according to your setup, pointing at the disk that contains our /boot partition and our LUKS encrypted partition.

If you are using another filesystem, such as xfs, be sure to change rootfstype=ext4 accordingly, such as to rootfstype=xfs.

Once finished creating the script, save the file. We need to mark the script as executable by running chmod +x setup-bootentry.sh, and then we can execute it with ./setup-bootentry.sh

Now, if we run efibootmgr, we should see a new boot entry with the label defined in our script, Alpine Linux.

Finalizing

To exit the chroot, run exit. We can now reboot the system with reboot now, be sure to remove any live media so you don't boot into the wrong system.

If all went well, our system should begin booting (with a lot of noise) and prompt us for our encryption passphrase:

After entering the encryption passphrase, we should be booted into the new Alpine system.

If you would like to quiet down the logs during boot, we can add the loglevel=4 kernel parameter to our script at /root/setup-bootentry.sh, adding another backslash after the previous parameter:

And then creating another boot entry.

Before executing the script again, remove the old boot entry with efibootmgr -b 0004 -B, replacing 0004 with the number of the old boot entry. The current boot entries can once again be listed by running efibootmgr.

Then, execute the script again with ./setup-bootentry.sh.

After rebooting, we can see that the output is much quieter:

That's it!

example.com

Alpine Linux 'diskless' install | kris.sh

Diskless Alpine Installation

Configuring a new diskless Alpine installation

Notes on lbu and disk commits

Editing kernel parameters

Closing thoughts

What Linux distro should I use? | kris.sh

Some basic criteria for a new user

Display server

Sensibly up to date software

Software availability

Being responsible with recommending a distribution

So what distributions do YOU like, then?

Should your opinions influence my own?

So what distro do you recommend I use?

What distros (or type of distros) do you NOT recommend I use?

Arch is difficult to use! Muh elitism! I'm so good at computer because I installed Arch!

All distributions are pretty much the same thing anyway, why does it matter?

DIY Mesh Router | kris.sh

Necessary software

ifupdown setup

iproute setup

nftables setup

Enabling IPv4 forwarding

dnsmasq setup

Closing thoughts

MSI Motherboard Woes | kris.sh

Introduction

UEFI Standards Compliance

Not-so-Secure Boot

Closing thoughts

Alpine Linux encrypted UKI install | kris.sh

Modifying the Alpine installer

Mounting partitions

Building the new initramfs

Kernel parameters

Building the UKI

Creating the boot entry

Finalizing

Secure Boot on Linux with sbctl | kris.sh

Preparing the system

Creating and enrolling secure boot keys

Finalizing

Alpine Linux with efistub and encryption | kris.sh

Modifying the Alpine installer

Mounting partitions

Creating the efistub boot entry

Finalizing