#luks — Public Fediverse posts

Und auch der Zugriff auf #LUKS klappt mit beiden Yubikeys. Das war ja einfach...

root@j20:~# systemd-cryptenroll /dev/sda1
SLOT TYPE    
   1 fido2
   2 recovery

root@j20:~# systemd-cryptsetup attach testcrypt /dev/sda1 && mount /dev/mapper/testcrypt /mnt && cat /mnt/secure
🔐 Please enter LUKS2 token PIN: •••••••••••••           
Asking FIDO2 token for authentication.
👆 Please confirm presence on security token to unlock.
42

#YubiKey #FIDO2 #EncryptItAll #GNU/Linux #security #systemd

I documented how I replaced the Debian crypttab `keyscript` with systemd socket activation:

https://anisse.astier.eu/keyscript-to-socket-activation.html

#systemd #Debian #Ubuntu #LUKS #cryptsetup #perl

I documented how I replaced the Debian crypttab `keyscript` with systemd socket activation:

https://anisse.astier.eu/keyscript-to-socket-activation.html

#systemd #Debian #Ubuntu #LUKS #cryptsetup #perl

I documented how I replaced the Debian crypttab `keyscript` with systemd socket activation:

https://anisse.astier.eu/keyscript-to-socket-activation.html

#systemd #Debian #Ubuntu #LUKS #cryptsetup #perl

I documented how I replaced the Debian crypttab `keyscript` with systemd socket activation:

https://anisse.astier.eu/keyscript-to-socket-activation.html

#systemd #Debian #Ubuntu #LUKS #cryptsetup #perl

I documented how I replaced the Debian crypttab `keyscript` with systemd socket activation:

https://anisse.astier.eu/keyscript-to-socket-activation.html

#systemd #Debian #Ubuntu #LUKS #cryptsetup #perl

@ubuntu i recently tried installing kubuntu resolute with encryption and the installer has an error there:

It uses LUKS2 instead of LUKS1

Grub is by default only compartible with LUKS1

For LUKS2 ist a maunal configuration witch dracut neccecary which can be very annoying

I tried that with the help of deepseek and failed i can upload the german AI chats if someone is interested

Please fix that ubuntu team

==============

#ubuntu #kubuntu #luks #linux #grub

From ESP32 to Linux LUKS: Turning an SD card into a zero-trust hardware token! 🔐

Instead of files, we use RAW noise. On ESP32, it's low-level SPI. On Linux, an initramfs hook uses dd to read a hidden offset from the SD, mixes it with the card's factory CID and the motherboard's UUID.

The result is a SHA-256 hash unlocking LUKS purely in RAM. Stolen laptop or stolen card alone? Useless. True paranoid DIY security using FOSS tools! 🐧

[AI Translated]

#Linux #LUKS #ESP32 #Security #FOSS

Is it possible for the OS to proceed after a failed LUKS decryption? #encryption #luks

https://askubuntu.com/q/1566775/612

Is it possible for the OS to proceed after a failed LUKS decryption? #encryption #luks

https://askubuntu.com/q/1566775/612

Is it possible for the OS to proceed after a failed LUKS decryption? #encryption #luks

https://askubuntu.com/q/1566775/612

Is it possible for the OS to proceed after a failed LUKS decryption? #encryption #luks

https://askubuntu.com/q/1566775/612

Is it possible for the OS to proceed after a failed LUKS decryption? #encryption #luks

https://askubuntu.com/q/1566775/612

Just to be absolutely clear: #LUKS with TPM unlocking is equally vulnerable to various attacks. You should definitely use TPM+PIN with LUKS as well. See systemd-cryptenroll --tpm2-with-pin=yes

https://wiki.archlinux.org/title/Systemd-cryptenroll#Trusted_Platform_Module

Just to be absolutely clear: #LUKS with TPM unlocking is equally vulnerable to various attacks. You should definitely use TPM+PIN with LUKS as well. See systemd-cryptenroll --tpm2-with-pin=yes

https://wiki.archlinux.org/title/Systemd-cryptenroll#Trusted_Platform_Module

Just to be absolutely clear: #LUKS with TPM unlocking is equally vulnerable to various attacks. You should definitely use TPM+PIN with LUKS as well. See systemd-cryptenroll --tpm2-with-pin=yes

https://wiki.archlinux.org/title/Systemd-cryptenroll#Trusted_Platform_Module

Just to be absolutely clear: #LUKS with TPM unlocking is equally vulnerable to various attacks. You should definitely use TPM+PIN with LUKS as well. See systemd-cryptenroll --tpm2-with-pin=yes

https://wiki.archlinux.org/title/Systemd-cryptenroll#Trusted_Platform_Module

Just to be absolutely clear: #LUKS with TPM unlocking is equally vulnerable to various attacks. You should definitely use TPM+PIN with LUKS as well. See systemd-cryptenroll --tpm2-with-pin=yes

https://wiki.archlinux.org/title/Systemd-cryptenroll#Trusted_Platform_Module

Is LUKS encryption with DE autologin safe?

https://piefed.social/c/linux4noobs/p/2057925/is-luks-encryption-with-de-autologin-safe

When two Hetzner servers died at the same time

On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

Several hours went into hypotheses that turned out to be wrong:

• The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
• PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
• Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
• Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
• Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

What it almost certainly was

Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

• Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
• New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

Why it matters for anyone running this stack

If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

Tooling

While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

→ github.com/kevinveenbirkenbach/hetzner-arch-luks

Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

When two Hetzner servers died at the same time

On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

Several hours went into hypotheses that turned out to be wrong:

• The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
• PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
• Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
• Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
• Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

What it almost certainly was

Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

• Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
• New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

Why it matters for anyone running this stack

If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

Tooling

While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

→ github.com/kevinveenbirkenbach/hetzner-arch-luks

Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

When two Hetzner servers died at the same time

On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

Several hours went into hypotheses that turned out to be wrong:

• The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
• PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
• Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
• Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
• Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

What it almost certainly was

Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

• Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
• New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

Why it matters for anyone running this stack

If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

Tooling

While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

→ github.com/kevinveenbirkenbach/hetzner-arch-luks

Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

When two Hetzner servers died at the same time

On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

Several hours went into hypotheses that turned out to be wrong:

• The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
• PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
• Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
• Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
• Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

What it almost certainly was

Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

• Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
• New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

Why it matters for anyone running this stack

If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

Tooling

While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

→ github.com/kevinveenbirkenbach/hetzner-arch-luks

Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

When two Hetzner servers died at the same time

On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

Several hours went into hypotheses that turned out to be wrong:

• The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
• PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
• Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
• Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
• Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

What it almost certainly was

Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

• Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
• New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

Why it matters for anyone running this stack

If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

Tooling

While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

→ github.com/kevinveenbirkenbach/hetzner-arch-luks

Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

@nickbearded kali has a very good guide for this - it is about 6 steps #encrypted persistence #luks

@nickbearded kali has a very good guide for this - it is about 6 steps #encrypted persistence #luks

@nickbearded kali has a very good guide for this - it is about 6 steps #encrypted persistence #luks

@nickbearded kali has a very good guide for this - it is about 6 steps #encrypted persistence #luks

As I understand it, #nixos is not vulnerable by default. However, if you use #luks and kernel lower then 6.18 or 7.0, for example, the module is already in your system. A quick fix:

```
{
boot.extraModprobeConfig = ''
install algif_aead ${pkgs.coreutils}/bin/false
'';
boot.blacklistedKernelModules = [ "algif_aead" ];
}
```

As I understand it, #nixos is not vulnerable by default. However, if you use #luks and kernel lower then 6.18 or 7.0, for example, the module is already in your system. A quick fix:

```
{
boot.extraModprobeConfig = ''
install algif_aead ${pkgs.coreutils}/bin/false
'';
boot.blacklistedKernelModules = [ "algif_aead" ];
}
```

As I understand it, #nixos is not vulnerable by default. However, if you use #luks and kernel lower then 6.18 or 7.0, for example, the module is already in your system. A quick fix:

```
{
boot.extraModprobeConfig = ''
install algif_aead ${pkgs.coreutils}/bin/false
'';
boot.blacklistedKernelModules = [ "algif_aead" ];
}
```

As I understand it, #nixos is not vulnerable by default. However, if you use #luks and kernel lower then 6.18 or 7.0, for example, the module is already in your system. A quick fix:

```
{
boot.extraModprobeConfig = ''
install algif_aead ${pkgs.coreutils}/bin/false
'';
boot.blacklistedKernelModules = [ "algif_aead" ];
}
```

As I understand it, #nixos is not vulnerable by default. However, if you use #luks and kernel lower then 6.18 or 7.0, for example, the module is already in your system. A quick fix:

```
{
boot.extraModprobeConfig = ''
install algif_aead ${pkgs.coreutils}/bin/false
'';
boot.blacklistedKernelModules = [ "algif_aead" ];
}
```

Ein lieber Mensch hat mir seinen recht aktuellen Desktop vermacht, zu einem Preis für den aktuell vermutlich grad mal das RAM zu bekommen wäre. Das System darf dann mein fast volljähriges mit Xeao 550 i7 und GTX 770 ablösen.
Nur: Damals gab es noch kein Secure Boot, TPM und GPT und ich verzweifle daran auf dem neumodischem Schnickschnack ein #Arch mit #LVM auf #LUKS mit einem funktionierdem bootloader zu versehen.
Ob sich so Opa gefühlt hat, als er den VHS-Rekorder nicht programmieren konnte?

Ein lieber Mensch hat mir seinen recht aktuellen Desktop vermacht, zu einem Preis für den aktuell vermutlich grad mal das RAM zu bekommen wäre. Das System darf dann mein fast volljähriges mit Xeon 550 i7 und GTX 770 ablösen.
Nur: Damals gab es noch kein Secure Boot, TPM und GPT und ich verzweifle daran auf dem neumodischem Schnickschnack ein #Arch mit #LVM auf #LUKS mit einem funktionierdem bootloader zu versehen.
Ob sich so Opa gefühlt hat, als er den VHS-Rekorder nicht programmieren konnte?

Ein lieber Mensch hat mir seinen recht aktuellen Desktop vermacht, zu einem Preis für den aktuell vermutlich grad mal das RAM zu bekommen wäre. Das System darf dann mein fast volljähriges mit Xeon 550 i7 und GTX 770 ablösen.
Nur: Damals gab es noch kein Secure Boot, TPM und GPT und ich verzweifle daran auf dem neumodischem Schnickschnack ein #Arch mit #LVM auf #LUKS mit einem funktionierdem bootloader zu versehen.
Ob sich so Opa gefühlt hat, als er den VHS-Rekorder nicht programmieren konnte?

Ein lieber Mensch hat mir seinen recht aktuellen Desktop vermacht, zu einem Preis für den aktuell vermutlich grad mal das RAM zu bekommen wäre. Das System darf dann mein fast volljähriges mit Xeon 550 i7 und GTX 770 ablösen.
Nur: Damals gab es noch kein Secure Boot, TPM und GPT und ich verzweifle daran auf dem neumodischem Schnickschnack ein #Arch mit #LVM auf #LUKS mit einem funktionierdem bootloader zu versehen.
Ob sich so Opa gefühlt hat, als er den VHS-Rekorder nicht programmieren konnte?

Ein lieber Mensch hat mir seinen recht aktuellen Desktop vermacht, zu einem Preis für den aktuell vermutlich grad mal das RAM zu bekommen wäre. Das System darf dann mein fast volljähriges mit Xeao 550 i7 und GTX 770 ablösen.
Nur: Damals gab es noch kein Secure Boot, TPM und GPT und ich verzweifle daran auf dem neumodischem Schnickschnack ein #Arch mit #LVM auf #LUKS mit einem funktionierdem bootloader zu versehen.
Ob sich so Opa gefühlt hat, als er den VHS-Rekorder nicht programmieren konnte?

In actuality, typing my #LUKS phrase is probably the single least efficient part of the #boot...

In actuality, typing my #LUKS phrase is probably the single least efficient part of the #boot...

In actuality, typing my #LUKS phrase is probably the single least efficient part of the #boot...

In actuality, typing my #LUKS phrase is probably the single least efficient part of the #boot...

Unification de l'installeur : Le projet va désormais utiliser l'installeur de #LMDE (le "live-installer") pour toutes ses versions, remplaçant ainsi #Ubiquity. Ce changement permet de mieux supporter l' #OEM, le #SecureBoot et #LVM / #LUKS.

Arrivée de "Alfa" (Mint 23) : Une version de développement nommée provisoirement "Alfa" est déjà sur les rails.

Unification de l'installeur : Le projet va désormais utiliser l'installeur de #LMDE (le "live-installer") pour toutes ses versions, remplaçant ainsi #Ubiquity. Ce changement permet de mieux supporter l' #OEM, le #SecureBoot et #LVM / #LUKS.

Arrivée de "Alfa" (Mint 23) : Une version de développement nommée provisoirement "Alfa" est déjà sur les rails.

Unification de l'installeur : Le projet va désormais utiliser l'installeur de #LMDE (le "live-installer") pour toutes ses versions, remplaçant ainsi #Ubiquity. Ce changement permet de mieux supporter l' #OEM, le #SecureBoot et #LVM / #LUKS.

Arrivée de "Alfa" (Mint 23) : Une version de développement nommée provisoirement "Alfa" est déjà sur les rails.

Unification de l'installeur : Le projet va désormais utiliser l'installeur de #LMDE (le "live-installer") pour toutes ses versions, remplaçant ainsi #Ubiquity. Ce changement permet de mieux supporter l' #OEM, le #SecureBoot et #LVM / #LUKS.

Arrivée de "Alfa" (Mint 23) : Une version de développement nommée provisoirement "Alfa" est déjà sur les rails.

Unification de l'installeur : Le projet va désormais utiliser l'installeur de #LMDE (le "live-installer") pour toutes ses versions, remplaçant ainsi #Ubiquity. Ce changement permet de mieux supporter l' #OEM, le #SecureBoot et #LVM / #LUKS.

Arrivée de "Alfa" (Mint 23) : Une version de développement nommée provisoirement "Alfa" est déjà sur les rails.

Update: #OpenSuse Tumbleweed handled it! So much for dunking on YaST, guys, it's the bomb!!!
Also, as much as I enjoy dunking on the systemd empire, systemd-boot is good (compared to grub, at least). ;)

#LUKS is gonna drive me mad.

This is on a brand new #Debian install. All I'm trying to do is have my home partition encrypted on a second SSD. No matter what I try, I get an unbootable system or it just ignores the second SSD. Right now, the last thing I tried to do was to use LVM to add the second SSD as a physical partition. But that didn't work either.

The last thing I tried was to boot into the graphical installer (not the live session) and install it with the guided partitioning using LVM and encryption. I then booted into a live session, Set up the second SSD as a physical volume and then add that physical volume to the main volume group. I then extended the swap and root partition into the new space provided by the second SSD as physical volume, but it doesn't boot.

Are there any distros that handle this automatically? I'm tired of pulling my hair out.

Update: #OpenSuse Tumbleweed handled it! So much for dunking on YaST, guys, it's the bomb!!!
Also, as much as I enjoy dunking on the systemd empire, systemd-boot is good (compared to grub, at least). ;)

#LUKS is gonna drive me mad.

This is on a brand new #Debian install. All I'm trying to do is have my home partition encrypted on a second SSD. No matter what I try, I get an unbootable system or it just ignores the second SSD. Right now, the last thing I tried to do was to use LVM to add the second SSD as a physical partition. But that didn't work either.

The last thing I tried was to boot into the graphical installer (not the live session) and install it with the guided partitioning using LVM and encryption. I then booted into a live session, Set up the second SSD as a physical volume and then add that physical volume to the main volume group. I then extended the swap and root partition into the new space provided by the second SSD as physical volume, but it doesn't boot.

Are there any distros that handle this automatically? I'm tired of pulling my hair out.

Update: #OpenSuse Tumbleweed handled it! So much for dunking on YaST, guys, it's the bomb!!!
Also, as much as I enjoy dunking on the systemd empire, systemd-boot is good (compared to grub, at least). ;)

#LUKS is gonna drive me mad.

This is on a brand new #Debian install. All I'm trying to do is have my home partition encrypted on a second SSD. No matter what I try, I get an unbootable system or it just ignores the second SSD. Right now, the last thing I tried to do was to use LVM to add the second SSD as a physical partition. But that didn't work either.

The last thing I tried was to boot into the graphical installer (not the live session) and install it with the guided partitioning using LVM and encryption. I then booted into a live session, Set up the second SSD as a physical volume and then add that physical volume to the main volume group. I then extended the swap and root partition into the new space provided by the second SSD as physical volume, but it doesn't boot.

Are there any distros that handle this automatically? I'm tired of pulling my hair out.