How Big Should an EFI Ve

My “standard” partition scheme is always, EFI, Boot, Swap, Data. I have been toying with an idea to swap EFI and Boot around but I stuck with the same order for a while now. However, sizes have changed over the time. One that changed the most is EFI.

Under Linux, assuming you have a separate Boot partition, you can have EFI really small. I’ve ran it at 32 MB for a while, not observing any negative issues. Until I did.

While most of the time Linux doesn’t really use EFI partition for much, things get interesting with firmware updates (fwupdmgr update). The only way for Linux (or any other OS, for that matter) to pass files to UEFI is a common partition. That common partition can only be FAT32 EFI. And, depending on your system, those files might need over 64 MB.

Translated, your EFI needs to be able to have more than 64 MB. How much more? Playing with power of two values is an unofficial standard and thus 128 MB is the next good spot.

But, is that future proof? Considering BIOS images are 32 MB these days (256 MBit), it’ll take a while before 128 MB is not enough

I am almost certain that more space will be needed at undefined time in the future. However, I won’t lose any sleep about it for at least couple of years.

PS: If you are dual-booting Windows, I would say doubling the partition might be a good idea as Windows does have a larger footprint on EFI partition.

When Standard Is Not a Standard

Having a standard is a beautiful thing. While US sockets are really shitty in general, I love how standardized they are. Every single apartment I ever lived in had the same double outlet setup. Its welcoming smiley face just awaits a device to power.

Except that this is not the standard orientation.

The standard orientation is actually upside-down of what everybody is used to. Well, when I say “the standard”, I say this loosely since it’s not part of NEC (National Electrical Code) as such. But, if you go to any hospital or industrial setting, chances are that you will find it in the “correct” orientation.

If you want to hear more then you ever cared about this, you can watch Technology Connections dealing with this exact topic. In any case, I am not watching that video ever again as it made me cry for Schuko.

In any case, I was mounting some stuff on the DIN rail and I had a choice to make. The way I planned to route wires and the text on the socket itself were both pointing toward “the standard” orientation. So I ran with it.

Do you see the problem here?

While orientation of the socket itself is not really defined, position of live and neutral wires is. In “the standard” orientation, the hot goes on the left and the neutral wire goes on the right. But here, my second socket actually has the neutral on the left. And yes, I did check that screw feeds into the socket straight up.

Since the other way of finding the neutral - its longer slot - points toward the neutral on the right, it’s obvious that markings are in fact incorrect. Manufacturer, instead of fixing the mold, just decided to sell devices nonetheless. I mean, US outlet is as shitty as it gets so it’s not like swapping the live and the neutral wire will make it any worse.

And, in reality, there is no real issue if you swap these wires at the outlet side. Heck, my belowed Schuko goes either way and even burned one is way safer than any US outlet. Outside of a few contrived examples involving houses with ancient wiring without ground, or really specific dumb equipment, which wire is live and which one is neutral doesn’t really matter.

But I find it amusing that product having such a strong opinion about the ground pin position can be so nonchalant when it comes to position of its current carrying wires.

PS: And yes, if I didn’t have two of them side by side, I would have probably missed wire labeling issue.

Updating Framework's QMK Firmware

New BIOS for Framework 16, brought also a problem. Every boot I got a message that my keyboard firmware is outdated. It was true, but also annoying warning as it paused the boot process. Normal person would just update keyboard but I had a few customizations and thus could not do the same.

What customizations? Well…

• Entering QMK firmware by holding CapsLock (keyboard) or NumLock (numpad)
• Key to mute microphone
• Disabling airplane mode key
• Reconfiguring numpad to allow volume and media controls
• Using brightness as a NumLock signal
• Simplifying background light setup

Could I live without those? Yes, but I still would prefer not to. So, I had to redo my changes on top of v0.3.1 which was simple enough as I just pretty much cherry-picked my changes directly. Maybe for the next version I also squash a few of them but I was lazy this time.

Short flash later and my numpad had a newer firmware with the same behavior. Happily I proceeded to flash the keyboard but in my excitement, I forgot to change my command line from framework/numpad to framework/ansi. Thus, I flashed my numpad firmware onto my keyboard. Annoying mistake but easily corrected by just reflashing the correct firmware on top of it. Or so I though.

My keyboard still didn’t work even after the correct firmware has been flashed. Some keys did produce something but it was never a correct letter. Did I brick my keyboard? Well, fortunately for me, with QMK answer is never yes.

QMK flashing doesn’t erase the full EEPROM when new version is loaded. So, if you end up corrupting the whole thing by flashing something very incompatible, you cannot just flash new firmware and be ok. What you need is to erase the old firmware all together. There are a few tools to do it, but I like this one.

Once EEPROM was erased, flashing my keyboard firmware worked like a charm.

Using ZFS in Docker

I have most of workloads on my server setup in Docker. It makes for self-documenting configuration, easier move to other machine, and less dependencies on the underlying OS. But one workload I kept on server itself - reporting.

The way my scripts were written, they required proper ZFS access. Now, I could adjust script to loopback via SSH to OS itself, but there was an easier way.

Docker allows for device exposing, and in the case of ZFS, all you need is to point container toward /dev/zfs:

    devices:
      - /dev/zfs:/dev/zfs

Now your scripts in container will have proper ZFS access.

Forcing a reboot

After messing with my remote server, there came a time for a reboot. Simple enough - but this time it ended in error.

Call to Reboot failed: Connection timed out

I’ve been using Linux servers for decades now and I was never faced with this issue. Fortunately, somebody at Unix StackExchange did.

Solution was to manually enter a few letters into /proc/sysrq-trigger, one letter at a time.

echo s > /proc/sysrq-trigger ; echo u > /proc/sysrq-trigger ; echo b > /proc/sysrq-trigger

This (attempts to) execute three distinct commands:

• s: syncs all file systems
• u: makes all file systems read-only
• b: reboots the system in agressive manner.

If you are curious about what other things you can do, kernel.org has a nice documentation page.