Linux on DevOps OPf

TPM2 Autodecrypt on Arch Linux with UKI and Secure Boot

Tue, 05 May 2026 00:00:00 +0000

Prerequisites

Before we begin, the following conditions must be met:

Requirement	Check command
LUKS2 (not LUKS1)	`cryptsetup luksDump /dev/nvme1n1p2 \| grep "Version:"`
TPM2 chip present	`systemd-cryptenroll --tpm2-device=list`
Secure Boot active (User Mode)	`bootctl status \| grep "Secure Boot"`
systemd-boot as bootloader	`bootctl status`
UKI-based boot	`ls /boot/EFI/Linux/*.efi`

⚠️ Important: This guide is specifically for systems that use Unified Kernel Images (UKI) — i.e. .efi files under /boot/EFI/Linux/ rather than classic loader entries under /boot/loader/entries/. The procedure differs for classic setups with loader entries.

Background: Why UKI + sd-encrypt?

A Unified Kernel Image bundles the kernel, initramfs, microcode and kernel cmdline into a single signed .efi file. Combined with Secure Boot, this creates a complete chain of trust: the firmware verifies the UKI signature before the kernel even starts.

The TPM2 chip uses PCR registers (Platform Configuration Registers) to measure the system state. By binding the LUKS key to PCR 0 (firmware integrity) and PCR 7 (Secure Boot state), the key is only released when the system boots in the expected state — i.e. with active Secure Boot and unchanged firmware.

The classic encrypt hook in mkinitcpio does not support TPM2. The sd-encrypt hook is required for this, which is based on systemd-cryptsetup and reads its configuration from /etc/crypttab.

Step 1: Enroll the TPM2 Key

systemd-cryptenroll writes a TPM2-bound key directly into the LUKS2 header. The existing passphrase is always retained as a fallback.

1

sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=0+7 /dev/nvme1n1p2

Verify the enrollment:

1

sudo systemd-cryptenroll /dev/nvme1n1p2

Expected output:

1
2
3


SLOT TYPE
 0 password
 2 tpm2

Step 2: Populate `/etc/crypttab`

This is the most common mistake in failed setups: the sd-encrypt hook reads exclusively from /etc/crypttab — if this file is empty, it cannot find the LUKS partition and the boot will fail.

First, retrieve the UUID of the LUKS partition:

1

sudo blkid -s UUID -o value /dev/nvme1n1p2

Then add it to /etc/crypttab:

1

sudo nano /etc/crypttab

1
2


# <name> <device> <password> <options>
root UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx - tpm2-device=auto

⚠️ Choose the name (here root) to exactly match how the LUKS partition is currently mapped — verify with lsblk.

Step 3: Clean Up the Kernel Cmdline

Kernel parameters for UKIs are embedded from /etc/kernel/cmdline. The cryptdevice= parameter belongs to the old encrypt hook and must be removed — sd-encrypt does not recognise it.

1

sudo nano /etc/kernel/cmdline

Before:

1

cryptdevice=PARTUUID=xxxx:root root=/dev/mapper/root rootflags=subvol=@ rw rootfstype=btrfs

After:

1

root=/dev/mapper/root rootflags=subvol=@ rw rootfstype=btrfs

⚠️ Everything must remain on a single line with no trailing newline.

Step 4: Adjust the mkinitcpio Hooks

1

sudo nano /etc/mkinitcpio.conf

Before:

1

HOOKS=(base udev autodetect microcode modconf kms keyboard keymap consolefont block encrypt filesystems fsck)

After:

1

HOOKS=(base systemd autodetect microcode modconf kms keyboard sd-vconsole block sd-encrypt filesystems fsck)

Summary of changes:

Old	New	Reason
`udev`	`systemd`	Required base for all `sd-*` hooks
`keymap consolefont`	`sd-vconsole`	systemd equivalent, reads from `/etc/vconsole.conf`
`encrypt`	`sd-encrypt`	TPM2 support via `systemd-cryptsetup`

Step 5: Rebuild Only the Main UKI

If an LTS kernel is installed, it is recommended to only rebuild the main UKI and keep the LTS UKI as a fallback. This allows booting with a password using the LTS kernel if something goes wrong.

1

sudo mkinitcpio -p linux

Step 6: Sign the New UKI with sbctl

Since Secure Boot is active, the newly built UKI must be signed before the firmware will accept it:

1
2


sudo sbctl sign /boot/EFI/Linux/arch-linux.efi
sudo sbctl verify

Step 7: Reboot and Test

1

sudo reboot

On success: no password prompt, direct boot via TPM2 unlock.

If a password is still requested: that is the normal fallback — the TPM did not release the key. The most common cause is an unexpected PCR state (e.g. Secure Boot disabled or a firmware update that changed PCR 0).

Step 8 (After Successful Test): Update the LTS UKI as Well

1
2


sudo mkinitcpio -p linux-lts
sudo sbctl sign /boot/EFI/Linux/arch-linux-lts.efi

Troubleshooting

TPM does not release the key

1
2


# Check systemd-cryptsetup log
journalctl -b -u systemd-cryptsetup@root

Common causes:

crypttab is empty or misconfigured
cryptdevice= is still present in the kernel cmdline
A firmware update changed PCR 0 → re-enrollment required

Reset enrollment and re-enroll

1
2
3
4
5
6
7
8
9


# Remove TPM2 slot
sudo systemd-cryptenroll --wipe-slot=tpm2 /dev/nvme1n1p2

# Re-enroll
sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=0+7 /dev/nvme1n1p2

# Rebuild and sign the UKI
sudo mkinitcpio -p linux
sudo sbctl sign /boot/EFI/Linux/arch-linux.efi

That’s it. The system will now boot without a password prompt — as long as Secure Boot is active and the firmware remains unchanged. The LUKS passphrase is always available as a fallback.

Setting Up Systemd Timers

Sat, 10 May 2025 00:00:00 +0000

Systemd timers are a powerful alternative to cron jobs for scheduling tasks. They offer greater flexibility and better integration into the systemd ecosystem. In this article, I’ll show you how to set up and use systemd timers.

What is a systemd timer?

A systemd timer is a systemd unit that schedules another service to run at specific times. Timers replace cron jobs and offer advantages such as:

Better logging with journalctl.
The ability to define dependencies and startup conditions.
More precise control over execution times.

Basic Structure

A systemd timer consists of two files:

Service file: Defines what should be executed.
Timer file: Defines when the service should be executed.

Both files are stored in the /etc/systemd/system/ directory.

Step 1: Create the Service File

The service file describes the action to be executed. For example, let’s run a script located at /usr/local/bin/backup.sh.

Create a file named backup.service:

1

nano /etc/systemd/system/backup.service

Content of the file:

1
2
3
4
5
6
7


[Unit]
Description=Backup Script
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

Explanation:

[Unit]: Describes the unit. Description provides a short description, and After=network.target ensures the network is available before the service starts.
[Service]: Defines the service. Type=oneshot means the service performs a one-time action. ExecStart specifies the command or script to be executed.

Step 2: Create the Timer File

The timer file defines when the service should be executed. Create a file named backup.timer:

1

nano /etc/systemd/system/backup.timer

Content of the file:

1
2
3
4
5
6
7
8
9


[Unit]
Description=Run Backup Script Daily

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

Explanation:

[Unit]: Similar to the service file, this provides a short description.
[Timer]: Defines the scheduling.
- OnCalendar=daily: Runs the service daily at midnight. Other time specifications can also be used (see below).
- Persistent=true: Ensures the timer runs after a restart, even if it was missed during downtime.
[Install]: WantedBy=timers.target ensures the timer is activated at system startup.

Time Specifications for systemd Timers

The time for a systemd timer is defined in the timer file using the OnCalendar option. Systemd supports a flexible and powerful time format for both simple and complex schedules. Here are some examples and explanations:

Basic Format

The general format for OnCalendar is:

1

OnCalendar=YYYY-MM-DD HH:MM:SS

YYYY: Year (e.g., 2025)
MM: Month (01 to 12)
DD: Day (01 to 31)
HH: Hour (00 to 23)
MM: Minute (00 to 59)
SS: Second (00 to 59)

You can use wildcards (*) to make certain parts flexible.

Common Time Specifications

Hourly (every full hour):
1

OnCalendar=hourly
Equivalent to: *-*-* *:00:00
Daily at midnight:
1

OnCalendar=daily
Equivalent to: *-*-* 00:00:00
Weekly (Sunday at midnight):
1

OnCalendar=weekly
Equivalent to: Sun *-*-* 00:00:00
Monthly (1st day of the month at midnight):
1

OnCalendar=monthly
Equivalent to: *-*-01 00:00:00
Yearly (January 1st at midnight):
1

OnCalendar=yearly
Equivalent to: *-01-01 00:00:00

Custom Time Specifications

Every day at 15:30:
1

OnCalendar=*-*-* 15:30:00
Every Monday at 08:00:
1

OnCalendar=Mon *-*-* 08:00:00
Every first day of the month at 12:00:
1

OnCalendar=*-*-01 12:00:00
Every last day of the month at 23:59:
1

OnCalendar=*-*-28..31 23:59:00
(Systemd automatically detects the last day of the month, e.g., 28, 30, or 31.)

Every second day at 06:00:

1

OnCalendar=*-*-1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31 06:00:00

Repetitions and Intervals

Every 5 minutes:
1

OnCalendar=*:0/5
(Runs at minute 0, 5, 10, 15, etc., every hour.)
Every 2 hours:
1

OnCalendar=*-*-* 0/2:00:00
(Runs at 00:00, 02:00, 04:00, etc.)
Every 15 minutes:
1

OnCalendar=*:0/15
(Runs at 00, 15, 30, and 45 minutes past the hour.)
Every 10 days:
1

OnCalendar=*-*-01,11,21 00:00:00

Step 3: Reload Systemd

After creating the files, reload the systemd configuration:

1

systemctl daemon-reload

Step 4: Enable and Start the Timer

Enable the timer so it starts automatically at system boot:

1

systemctl enable backup.timer

If you want to start it manually:

1

systemctl start backup.service

Step 5: Verify the Timer

To ensure the timer is set up correctly, check its status:

1

systemctl status backup.timer

And to check the service:

1

systemctl status backup.service

Optional Commands and Tips

List all timers:
1

systemctl list-timers --all
This displays all active and inactive timers, including their next and last execution times.
Check service status:
1

systemctl status backup.service
View service logs:
1

journalctl -u backup.service

Stop or disable a timer:

Stop the timer:
1

systemctl stop backup.timer
Disable the timer:
1

systemctl disable backup.timer

Conclusion

Systemd timers are a modern and powerful alternative to cron jobs. They offer precise control, better logging, and seamless integration into the system. With the steps described above, you can easily set up and manage your own timers.

rpm-ostree Commands

Thu, 20 Mar 2025 00:00:00 +0000

Remove a system package

To remove a system package, use the following command. In this example, Firefox and its language pack are removed:

1

rpm-ostree override remove firefox-langpacks-136.0.1-1.fc41.x86_64 firefox

Restore a system package

If you want to restore a previously removed package, use the following command. Here, Firefox and its language pack are reset:

1

rpm-ostree override reset firefox-langpacks-136.0.1-1.fc41.x86_64 firefox

Note: The command rpm-ostree override reset allows you to revert all overrides and restore the system to its original state.

Replace or downgrade the kernel

An alternative to the standard update process is to replace or downgrade the kernel using the following command:

1

sudo rpm-ostree override replace <http or local file paths of kernel packages>

For example, you can replace a kernel from a specific build server like this:

1

sudo rpm-ostree override replace https://koji.fedoraproject.org/koji/buildinfo?buildID=2667987

Reset the override

Once the required fix has been landed in the official repository, you can reset the changes to the kernel with the following command:

1

sudo rpm-ostree override reset <kernel packages that have been overridden>

Example: Kernel downgrade

In this example, the kernel was downgraded from version 6.13.8-200.fc41 to 6.13.5-200.fc41. The affected packages are:

kernel
kernel-core
kernel-modules
kernel-modules-core
kernel-modules-extra
kernel-tools
kernel-tools-libs
python3-perf

Command used:

1

sudo rpm-ostree override replace https://koji.fedoraproject.org/koji/buildinfo?buildID=2693823

To undo all changes, you can use the following command:

1

sudo rpm-ostree override reset

Useful tips

Rollback: If a previous deployment was working correctly, you can easily roll back to that state without manually modifying packages.
Reset overrides: The command rpm-ostree override reset resets all changes made to system packages. This is useful for returning the system to a clean state.

Set up autostart

Thu, 20 Mar 2025 00:00:00 +0000

GNOME uses .desktop files to launch applications. If you want an application to start automatically when the system boots, you need to place a .desktop file in the ~/.config/autostart/ directory. Follow these steps:

Create the Directory (if it doesn’t exist)

The directory ~/.config/autostart/ is where GNOME looks for autostart files. If this directory doesn’t already exist, you can create it with the following command:

1

mkdir -p ~/.config/autostart

The -p flag ensures that the directory is created, even if parent directories are missing.

Copy the `.desktop` File

Many applications already provide .desktop files, which are located in the /usr/share/applications/ directory. These files contain all the necessary information to start the application. You can copy the .desktop file of the desired application to the autostart directory:

1

cp /usr/share/applications/<application>.desktop ~/.config/autostart/

Replace <application> with the name of the desired application. For example, to start Firefox at boot, you would enter:

1

cp /usr/share/applications/firefox.desktop ~/.config/autostart/

Edit the `.desktop` File (Optional)

If you want to customize the startup parameters of the application, you can edit the copied .desktop file using a text editor. For example, open the file with nano:

1

nano ~/.config/autostart/<application>.desktop

Here, you can make changes like adding additional startup options or configuring the autostart for specific conditions. Be sure to save the file after editing.

Test the Autostart

To verify that the application starts automatically on the next boot, you can log out and log back in or restart the system. The application should now start automatically.

Swapfile creation

Sat, 24 Feb 2024 00:00:00 +0000

To create and enable a swap file on your Linux system, follow these steps:

Create the Swap File

First, create a file that will be used as the swap space. In this example, we are creating a 2 GB swap file:

1

fallocate -l 2G /swapfile

Set the Correct Permissions

For security reasons, only the root user should have read and write access to the swap file. Set the appropriate permissions using the following command:

1

chmod 600 /swapfile

Set Up the Swap Area

Use the mkswap tool to configure the file as a Linux swap area:

1

mkswap /swapfile

Activate the Swap File
Enable the swap file so the system can start using it immediately:

1

swapon /swapfile

Make the Change Permanent

To ensure the swap file is activated automatically at system startup, you need to edit the /etc/fstab file. Open the file with a text editor, for example:

1

nano /etc/fstab

Add the following line to the file:

1

/swapfile swap swap defaults 0 0

Save and close the file. The swap file will now be permanently enabled.

Logical Volume Management (LVM) Guide

Thu, 24 Aug 2023 00:00:00 +0000

Logical Volume Management (LVM) is a flexible method for managing storage on Linux systems. It allows you to dynamically adjust storage space without recreating partitions or deleting data. This guide explains how to create, extend, and permanently mount an LVM.

Create LVM

Create a Physical Volume (PV)

A Physical Volume (PV) is the foundation of LVM. It represents a physical disk or partition to be used by LVM. To create a PV, run:

1

pvcreate /dev/sdb

Explanation:

/dev/sdb is the disk you want to use for LVM. Replace it with the actual device name of your disk.
This step marks the disk as LVM-compatible and prepares it for use in a Volume Group.##

Create a Volume Group (VG)

A Volume Group (VG) is a collection of Physical Volumes. It provides the storage space from which Logical Volumes are created. To create a VG and add the previously created PV, use:

1

vgcreate vg_data /dev/sdb

Explanation:

vg_data is the name of the Volume Group. You can choose any name that makes sense for your setup.
/dev/sdb is the Physical Volume to be added to the Volume Group.##

Create a Logical Volume (LV)

A Logical Volume (LV) is the actual usable storage space allocated from a Volume Group. To create an LV that uses all available space in the Volume Group, run:

1

lvcreate -l 100%FREE -n lv_data vg_data

Explanation:

-l 100%FREE allocates all available space in the Volume Group to the Logical Volume.
-n lv_data assigns the name lv_data to the Logical Volume.
vg_data is the Volume Group from which the space is allocated.##

Create a Filesystem

To use the Logical Volume, you need to create a filesystem on it. In this example, we use the ext4 filesystem:

1

mkfs.ext4 /dev/vg_data/lv_data

Explanation:

/dev/vg_data/lv_data is the path to the Logical Volume.
The ext4 filesystem is a common choice for Linux systems, but you can use other filesystems like XFS or btrfs depending on your requirements.##

Extend LVM

If you need more storage space, you can extend an existing LVM. Follow these steps:

Resize the Physical Volume (PV)

If the underlying disk has been expanded (e.g., by adding more storage in a virtual machine), you need to update the Physical Volume:

1

pvresize /dev/sdb

Explanation:

This command adjusts the size of the Physical Volume to match the new size of the disk.
/dev/sdb is the disk you are resizing.##

Extend the Logical Volume (LV)

To use the additional storage space, extend the Logical Volume:

1

lvextend -l +100%FREE /dev/vg_data/lv_data

Explanation:

-l +100%FREE extends the Logical Volume by using all available free space in the Volume Group.
/dev/vg_data/lv_data is the Logical Volume you are extending.##

Resize the Filesystem

After extending the Logical Volume, you need to resize the filesystem to utilize the new space:

1

resize2fs /dev/mapper/vg_data-lv_data

Explanation:

resize2fs adjusts the size of the ext4 filesystem to match the new size of the Logical Volume.
/dev/mapper/vg_data-lv_data is the path to the Logical Volume.##

Add Entry to `/etc/fstab`

To ensure the Logical Volume is automatically mounted at system startup, you need to add it to the /etc/fstab file.

Display the UUID

Find the UUID of the Logical Volume:

1

lsblk -f

Explanation:

The UUID is a unique identifier for the Logical Volume. It is required to add the volume to /etc/fstab.##

Add Entry to `/etc/fstab`

Add the UUID to the /etc/fstab file so the volume is mounted automatically at boot:

1

echo "UUID=foo /mnt/data ext4 defaults 0 0" >> /etc/fstab

Explanation:

Replace foo with the actual UUID of the Logical Volume.
/mnt/data is the mount point where the Logical Volume will be accessible. Adjust this to your desired directory.
ext4 is the filesystem type. Use the appropriate type if you used a different filesystem.##

Reload Systemd

Reload the Systemd configuration to apply the changes:

1

systemctl daemon-reload

Explanation:

This ensures that Systemd recognizes the updated /etc/fstab configuration.##

Mount the Volume

Finally, mount the volume to verify that everything is working correctly:

1

mount -a

Explanation:

This command mounts all filesystems listed in /etc/fstab. If there are no errors, the Logical Volume should now be mounted and accessible.

Linux on DevOps OPf

TPM2 Autodecrypt on Arch Linux with UKI and Secure Boot

Prerequisites

Background: Why UKI + sd-encrypt?

Step 1: Enroll the TPM2 Key

Step 2: Populate /etc/crypttab

Step 3: Clean Up the Kernel Cmdline

Step 4: Adjust the mkinitcpio Hooks

Step 5: Rebuild Only the Main UKI

Step 6: Sign the New UKI with sbctl

Step 7: Reboot and Test

Step 8 (After Successful Test): Update the LTS UKI as Well

Troubleshooting

TPM does not release the key

Reset enrollment and re-enroll

Setting Up Systemd Timers

What is a systemd timer?

Basic Structure

Step 1: Create the Service File

Step 2: Create the Timer File

Time Specifications for systemd Timers

Basic Format

Common Time Specifications

Custom Time Specifications

Repetitions and Intervals

Step 3: Reload Systemd

Step 4: Enable and Start the Timer

Step 5: Verify the Timer

Optional Commands and Tips

Conclusion

rpm-ostree Commands

Remove a system package

Restore a system package

Replace or downgrade the kernel

Reset the override

Example: Kernel downgrade

Useful tips

Set up autostart

Create the Directory (if it doesn’t exist)

Copy the .desktop File

Edit the .desktop File (Optional)

Test the Autostart

Swapfile creation

Create the Swap File

Set the Correct Permissions

Set Up the Swap Area

Make the Change Permanent

Logical Volume Management (LVM) Guide

Create LVM

Create a Physical Volume (PV)

Create a Volume Group (VG)

Create a Logical Volume (LV)

Create a Filesystem

Extend LVM

Resize the Physical Volume (PV)

Extend the Logical Volume (LV)

Resize the Filesystem

Add Entry to /etc/fstab

Display the UUID

Add Entry to /etc/fstab

Reload Systemd

Mount the Volume

Step 2: Populate `/etc/crypttab`

Copy the `.desktop` File

Edit the `.desktop` File (Optional)

Add Entry to `/etc/fstab`

Add Entry to `/etc/fstab`