Monthly Archives: July 2023

Elemental Dice – Cerium Problem

After a few months in a box in a close, it is obvious that Cerium has a problem.

I have received a replacement Cerium die, with cerium in resin.

Debian 12 on a 2-drive NUC

After my relative success with Debian 12 on my Hades Canyon I decided to install Debian 12 on an older NUC as well, the NUC D54250WYKH with an i5-4250U. The nice thing with this NUC is that it both has an mSATA slot and room for a good old 2.5-inch drive. So I have:

  • 1 TB 5400 rpm HDD
  • 240 GB SSD

The annoying thing is that the BIOS/UEFI only wants to boot from the SATA drive, and the SATA drive shows up first in Linux. The easy way for me to install this computer would be

  • 240 GB SSD: /, /boot, /swap, /home
  • 1000 GB HDD: /home/sync (for syncthing data)

I could do a simple guided-encrypted-lvm-all-drive on the 240 GB, and a single encrypted partition on 1TB. But Debian 12 installation fails when it comes to installing GRUB, and the installed system does not boot.

Using LVM to make a logical volume spanning a small fast SSD and a large slow HDD makes no sense.

Partitioning in Debian

There is a guided option and a manual option to do Partitioning in Debian. I feel neither is good for me.

  • Guided: fails to lay out things easily on the two drives in a way that works
  • Manual: honestly, too complicated, particularly:
    • LVM and encryption hide few details, requires many steps, and hard to undo half-way
    • I understood that LILO needed to go the beginning of the drive BIOS was set to boot, and that LILO needed to see /boot (whether its own partition or root). However, with GRUB and UEFI, there are two separate extra partitions (/boot and some FAT-partition I think) and I am not allowed to control where the GRUB code goes (if anywhere). So I do not dare to set up this manually.

To make things worse (admittedly, I used the minimal.iso Debian installer which pulls things over the network to make things slower), when restarting the computer/installer there are quite many steps until my drives are detected and I can even erase partition tables and start over.

What I did

After two failed installation attempts, and several more restarts of the installer, I found a working solution.

I first erased all traces of partitions and boot code on both drives to be on the safe side. /dev/sda is the installation media.

  1. # dd if=/dev/zero of=/dev/sdb bs=1024 count=10240
  2. # dd if=/dev/zero of=/dev/sdc bs=1024 count=10240
  3. Guided non encrypted setup of 1000 TB drive, with separate /home
  4. I didn’t even install X/Gnome this time to save time

This gave me working computer that makes no use of my SSD. As root on the console I did:

  1. Backup the home directory of my non-root-user (just in case) to /root
  2. Remove /home from fstab
  3. Restart
  4. install cryptsetup and cryptsetup-run
  5. encrypt /dev/sda4 using cryptsetup (900GB+ HDD partition)
  6. encrypt /dev/sdb1 using cryptsetup (240GB SSD only partition)
  7. add entries to /etc/crypttab:
    sda4enc /dev/sda4
    sdb1enc /dev/sdb1
  8. Restart
  9. Give master encryption password (just once since I used the same)
  10. mkfs.ext4 /dev/mapper/sda4enc
  11. mkfs.ext4 /dev/mapper/sdb1enc
  12. add entries to /etc/fstab
    /dev/sdb1enc /home +options
    /dev/sda4enc /home/sync +options
  13. Restart

The result is almost 100% good. A few comments:

  • swap ended up on slow 1TB HDD, which I am fine with since I have 16GB RAM
  • root filesystem (with /usr, /root, /var, /etc and more) is not encrypted now, but I can live with having only my data (/home, /home/sync) encrypted
  • using cryptsetup/luks directly on partitions, not bothering with LVM, is much more simple
  • with /etc/crypttab and cryptsetup-run, encryption is really simple and understandable

As long as I do not run into something strange with X/Wayland/Gnome and drivers for this old NUC, I think I am good now.

What I would have wanted

I hear people have been fearing the Debian installer, up to Debian 12. I have not feared it in the past, but now I kind of do (after having issues installing two different NUCs the same week).

This is the partitioning experience I would have liked. My input/selections as [ ].

You have three drives with multiple partitions. Select all you want to keep, use as is, or delete:

/dev/sda (Debian installation media)
[KEEP] /dev/sda1 ...
[KEEP] /dev/sda2 ...
[KEEP] /dev/sda3 ...

/dev/sdb (1000 GB HITACHI)
[DELETE] /dev/sdb1  200 GB NTFS
[DELETE] /dev/sdb2  750 GB ext4
[/mnt/backup] /dev/sdb3 50 GB (just an example of something to keep

/dev/sdc (240 GB SAMSUNG)
[DELETE] /dev/sdc1  500MB FAT
[DELETE] /dev/sdc2  400MB ext2
[DELETE] /dev/sdc3  239GB ext4

With that out of the way, I would like Debian to ask me:

What device should contain 2 small partitions for boot purposes?
[X] /dev/sdb  -- 950 GB free
[ ] /dev/sdc  -- 240 GB free

Where do you want swap partitions, and what size?
[      ] /dev/sdb -- 950 GB free
[ 16GB ] /dev/sdc -- 240 GB free

Where do you want /, and what size
[      ] /dev/sdb -- 950 GB free
[ 30GB ] /dev/scd -- 224 GB free

Do you want a separate /home, and what size
[       ] /dev/sdb -- 950 GB free
[ 194GB ] /dev/scd -- 194 GB free

Do you want a separate /var, and what size
[       ] /dev/sdb -- 950 GB free
[       ] /dev/scd --   0 GB free

Do you want to set up extra non-standard mounts?
[ 950GB ] [ /home/sync ] /dev/sdb -- 950 GB free

Now it is time to choose encryption and format options:

UEFI-BOOT    500MB   [ FAT ]
/boot        500MB   [ ext2 ]
/             30GB   [ ext4 + encrypt ]
/home        194GB   [ ext4 + encrypt ]
/home/sync   950GB   [ ext4 + encrypt ]
/mnt/backup   50GB   [ KEEP ]

Finally, choose encryption password (the same, or separate).

This would have been a much better experience for me. I understand there can be more cases:

  • Computers with multiple disks may want to use LVM for to make logical volumes spanning several physical volumes. That would probably be a question between (1) and (2) above.
  • Multiple filesystems could live on a common encrypted volume, with a common encryption key, making use of LVM. That could be a question in the end:
    /usr and /var are on the same disk, do you want them to share encryption key on a common volume


I would guess that the use cases are:

  • 80% Simple 1-drive computers (Guided, automatic, defaults)
  • 10% Multi-disk servers with specific requirements (Manual, expert mode)
  • 10% 2-3 drive computers (not well supported today with Debian 12)

I am just making 80/10/10 up, of course. The unsupported 10% can be made up of:

  • Laptops or desktops that come with a small SSD and a large HDD (it happens)
  • Desktop computers with extra drives installed
  • Simple servers

Perhaps in Debian 13!

Debian 12 on Hades Canyon NUC

I have a Hades Canyon NUC (NUC8i7HVK) that I have been running Ubuntu and later Fedora on. Ubuntu has been fine for years but I didn’t want Snap (especially not for Firefox) so I tried out Fedora and that was also fine.

I realize that I did not leave Ubuntu because I did not want to have Snap, I left it because I want 100% apt. So in the long run I feel a bit alienated with Fedora and with Debian 12 out and getting good reviews I thought about giving it a try.

This desktop computer is a bit like your typical laptop when it comes to Linux, not sure everything works out of the box. I used to struggle a bit with Bluetooth and Audio, but I don’t do those things on this machine anymore. Ubuntu and Fedora are kind of already configured with proprietary non-free drivers for this NUC, but Debian is not.


I am running Debian 12 now, installed from the “minimal.iso” debian image, and with a number of extra packages installed. The InstallingDebianOn-page for this machine is ok. All I actually did was to add non-free and contrib to sources.list and install the extra packages recommended:

I have done no extra configuration or tweaking on Debian 12, but I am not using Audio-IN, Bluetooth or Wifi so I have not tested.

Broken Live Image

I didn’t throw Fedora 38 out without doing some testing first, so I downloaded the Live image for Debian 12 and successfully tried it. Then I installed Debian 12 from the Live image (choosing install immediately at the Grub menu), which was 99% successful. But it left some Raspberry-Pi packages and some stuff in /boot, resulting in that apt could not finish rebuilding the ramdisk. Computer started, but error remained. I searched on forums, it is a known problem with the Live image, there are solutions and when I tried I just got more errors. So I ended up reinstalling Debian 12 from scratch.


I downloaded the minimal.iso, convenient so I did not have to use a large USB-key, and installed from it. What a nice text/curses based installation! Then I got a non booting system!

I had to disable “Intel IGD” (I think that was how it was called) in “BIOS” (it is not BIOS anymore), becuase this machine has an Intel GPU that is not connected to any output, and with this rudimentary Debian install, somehow the system would not start.

When that was done, and I started Debian and logged in, Gnome (and neofetch I presume) reported GPU=Software. I could watch Youtube with high CPU load. That was when I installed the extra packages listed above, and since then I have been happy.


Debian 12 is fine on Hades Canyon NUC8i7HVK. The InstallingDebianOn-page linked above tells you more than you need. It was written from Debian 10.7.

Trying tmux

It seems screen is old and tmux is what I should use. Here are some findings and notes.

Cheat Sheet

I found a decent Cheat Sheet.

macOS backspace issue

There seems to be a problem with backspace in tmux on macOS. I installed tmux via pkgin, so if you use brew or something, perhaps the situation is different.

The simple fix I found here was to create a ~/.tmux.conf and add one line:

set -g default-terminal "screen"


set -g default-terminal "screen-256color"

Other solutions fixing tmux-256color with infocmp and tmp failed for me. I probably just didn’t use the right versions of the commands in the right way.

macOS resizing panes

As I understand it, panes are resized with CTRL+B+ArrowKey. But CTRL+ArrowKey does something else on macOS. I have not decided if I need to solve this yet.


Scrolling was always a hassle in screen. In tmux, this is a nobrainer for me (again ~/.tmux.conf):

set -g mouse on

On RHEL and downstream clones

I have been using Linux, being fascinated with Linux, since 1997. It makes me sad to see the current situation with RHEL, Alma and Rocky.

I have since long been a user of Debian and different versions of Ubuntu. Recently I have switched to Fedora on my workstations because I don’t appreciate Snap in Ubuntu.

I think Linux, how it is delivered, compared to Windows, has two advantages (apart from price):

  • Everyone can use the same version of Linux (I don’t have arbitrary limitations on my Home computer compared to my Professional computer, or my Server computer)
  • Anyone can make their own flavour (with KDE, for Gaming, for sound engineers, for servers, without systemd, for network routers and firewalls)

To me, this is about economy. Not purchase price, but about not doing the same work over and over again, on different computers, in different projects, or in different organisations. This is about maximising synergy, and minimising waste.


RHEL is, from my perspective, about

  • Not everyone can use the same version of Linux (because RHEL is dominant but not for everyone)
  • Since last weeks, nobody should make their own flavours of RHEL

I understand it makes sense from a corporate perspective, but it makes less sense from a holistic Linux perspective. But this was kind of true for RHEL even before last weeks shutting off patches downstream.

To me, RHEL is less free, in lack of a better word. I can have it for 0 USD, I can get the source under GPL, but it still comes with strings attached that I rather don’t have.

Alma and Rocky

I have occasionally logged in to a RHEL computer but I have never done anything with Alma or Rocky. I understand if you technically want RHEL but you do not want a relationship with Red Hat, Alma or Rocky solves that. And perhaps RHEL (or Alma or Rocky) is more fit-for-purpose for you than any alternative (like Debian or Ubuntu).

I always refused to use pirated Windows because I argued that even if I pay Microsoft nothing, I am still supporting their entire ecosystem, not helping things to get better. To me, Alma and Rocky are not pirated versions of RHEL (of course not). But to me, they also do not contribute to making RHEL or any other Linux system better. And they do not make the REAL alternatives to RHEL any more viable, while supporting the RHEL ecosystem. They are just community effort to duplicate work, and from my perspective that effort could have been used for something better (like Debian – if you want free Linux).

Fedora -> CentOS Stream -> RHEL -> Clones

I kind of agree with the Red Hat position, that supporting Fedora and CentOS Stream, upstream, is their best way of serving the community. And that the clones themselves add nothing.

To me Fedora and CentOS Stream makes more sense and have more appeal, than Alma and Rocky. But I don’t need to run some enterprise applications so perhaps I do not understand.

Red Hat business model

As I understand it (and I just run Debian on my servers, so I may not know) Canonical has free download available for all versions of Ubuntu (also enterprise server versions that compete with RHEL). But you can pay for support if you want.

If Red Hat did the same, Alma and Rocky would disappear. Or they would turn into niche variants/remixes of RHEL. I have seen other places in the open source world where you need to pay for extended support, which seems to be what RHEL and the cost of RHEL is much about.

I read that Red Hat realised that customers had 1 paid RHEL computer, and 999 CentOS computers, and the support was always for the RHEL computer. That was why Red Hat moved CentOS upstream. Perhaps that was the wrong move to increase customer RHEL support loyalty, and perhaps this late move of Red Hat is also the wrong move for the same old problem.


Alma and Rocky exist only because Red Hat and RHEL comes with strings attached that many people do not want in the Linux world. However, there were still strings, and now Red Hat pulls them.

There are only two good solutions:

  1. Red Hat understands the real need for no strings attached
  2. People understand to move away from RHEL entirely, and truly support the real alternatives

I hope for any of these. Not for a RHEL-Alma-Rocky conflict situation.