minor version increment [skip actions]

.gitea/workflows/deploy.yaml

@@ -2,6 +2,9 @@ name: Deploy Quartz site to Pages
 
 env:
   VERSION_FRAGMENT: minor
+  DEPLOYMENT_NAMESPACE: luxuries
+  DEPLOYMENT_LABEL: garden
+  KUBE_HOST: kubernetes.default.svc
 
 on:
   push:
@@ -79,4 +82,15 @@ jobs:
             www.tar.gz
           token: ${{secrets.CI_ACCESS}}
       - run: git push
-        working-directory: content
+        working-directory: content
+  deploy:
+    needs: [ build ]
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions-hub/kubectl@master
+        env:
+          KUBE_HOST: ${{ env.KUBE_HOST }}
+          KUBE_CERTIFICATE: ${{ secrets.KUBE_CERTIFICATE }}
+          KUBE_TOKEN: ${{ secrets.GARDEN_TOKEN }}
+        with:
+          args: delete pods -n ${{env.DEPLOYMENT_NAMESPACE}} -l app=${{ env.DEPLOYMENT_LABEL}}

.obsidian/plugins/hoarder-sync/data.json

@@ -1,10 +1,10 @@
 {
   "apiKey": "ak2_930f821671cbe46c8d7e_0df2443dba6dd9fe1dc8ebf52d6ac96e",
   "apiEndpoint": "https://kara.werats.gay/api/v1",
-  "syncFolder": "KaraKeep",
+  "syncFolder": "Hoarder",
-  "attachmentsFolder": "KaraKeep/attachments",
+  "attachmentsFolder": "Hoarder/attachments",
   "syncIntervalMinutes": 60,
-  "lastSyncTimestamp": 1775974138279,
+  "lastSyncTimestamp": 1776992561660,
   "updateExistingFiles": false,
   "excludeArchived": true,
   "onlyFavorites": false,

KaraKeep/2026-04-12-Canary-1.3.268-Ryubing-Canary.md

@@ -0,0 +1,37 @@
+---
+bookmark_id: "riq213v7sm75y92an34tor1z"
+url: |
+  https://git.ryujinx.app/Ryubing/Canary/releases/tag/1.3.268
+title: Canary 1.3.268 - Ryubing/Canary
+date: 2026-04-12T22:47:56.000Z
+modified: 2026-04-12T22:48:41.000Z
+tags:
+  - ryujinx
+  - emulator
+  - game-development
+  - canary-release
+note: 
+original_note: 
+summary: 
+banner: "[[KaraKeep/attachments/d900a45e-a408-45b6-b73b-24784ccb466d-Canary-1.3.268-Ryubing-Canary.jpg]]"
+screenshot: "[[KaraKeep/attachments/9d4ac575-4d0c-4ac2-8ff7-cd56436b6378-Canary-1.3.268-Ryubing-Canary.jpg]]"
+
+---
+
+# Canary 1.3.268 - Ryubing/Canary
+
+![Canary 1.3.268 - Ryubing/Canary - Banner Image](KaraKeep/attachments/d900a45e-a408-45b6-b73b-24784ccb466d-Canary-1.3.268-Ryubing-Canary.jpg)
+
+![Canary 1.3.268 - Ryubing/Canary - Screenshot](KaraKeep/attachments/9d4ac575-4d0c-4ac2-8ff7-cd56436b6378-Canary-1.3.268-Ryubing-Canary.jpg)
+
+## Description
+
+Canary - Builds of Ryubing compiled & published after every push to the upstream repository.
+
+## Notes
+
+
+
+[Visit Link](https://git.ryujinx.app/Ryubing/Canary/releases/tag/1.3.268)
+
+[View in Hoarder](https://kara.werats.gay/dashboard/preview/riq213v7sm75y92an34tor1z)

KaraKeep/2026-04-13-Affinity-Suite-V2-on-Linux-[-Wine-].md

@@ -0,0 +1,33 @@
+---
+bookmark_id: "u8r6pep754g6nte3w4knltaw"
+url: |
+  https://forum.affinity.serif.com/index.php?/topic/182758-affinity-suite-v2-on-linux-wine/page/19/#comment-1249400
+title: |
+  Affinity Suite V2 on Linux [ Wine ] - Page 19 - Resources - Affinity | Forum
+date: 2026-04-13T23:40:28.000Z
+modified: 2026-04-13T23:42:37.000Z
+note: 
+original_note: 
+summary: 
+banner: "[[KaraKeep/attachments/76c3aab0-4fb3-4969-b48b-b4f1fac35b96-Affinity-Suite-V2-on-Linux-[.jpg]]"
+screenshot: "[[KaraKeep/attachments/df950070-327a-42fe-9113-c84c43d4c959-Affinity-Suite-V2-on-Linux-[.jpg]]"
+additional:
+  - "[[KaraKeep/attachments/dca83f2f-e5df-40f5-be0f-0d405064f2e3-Affinity-Suite-V2-on-Linux-[.jpg]]"
+
+---
+
+# Affinity Suite V2 on Linux [ Wine ] - Page 19 - Resources - Affinity | Forum
+
+![Affinity Suite V2 on Linux [ Wine ] - Page 19 - Resources - Affinity | Forum - Banner Image](<KaraKeep/attachments/76c3aab0-4fb3-4969-b48b-b4f1fac35b96-Affinity-Suite-V2-on-Linux-[.jpg>)
+
+![Affinity Suite V2 on Linux [ Wine ] - Page 19 - Resources - Affinity | Forum - Screenshot](<KaraKeep/attachments/df950070-327a-42fe-9113-c84c43d4c959-Affinity-Suite-V2-on-Linux-[.jpg>)
+
+![Affinity Suite V2 on Linux [ Wine ] - Page 19 - Resources - Affinity | Forum - linkHtmlContent](<KaraKeep/attachments/dca83f2f-e5df-40f5-be0f-0d405064f2e3-Affinity-Suite-V2-on-Linux-[.jpg>)
+
+## Notes
+
+
+
+[Visit Link](https://forum.affinity.serif.com/index.php?/topic/182758-affinity-suite-v2-on-linux-wine/page/19/#comment-1249400)
+
+[View in Hoarder](https://kara.werats.gay/dashboard/preview/u8r6pep754g6nte3w4knltaw)

KaraKeep/2026-04-13-Introduction-Affinity-Wine.md

@@ -0,0 +1,36 @@
+---
+bookmark_id: "d7z2r60nf6lzkpulgfx1xaz0"
+url: |
+  https://affinity.liz.pet/v2/1-intro/
+title: Introduction - Affinity Wine Documentation
+date: 2026-04-13T23:38:20.000Z
+modified: 2026-04-13T23:39:28.000Z
+tags:
+  - wine
+  - affinity
+  - linux
+  - affinity-suite
+  - graphics-software
+  - installation-guide
+note: 
+original_note: 
+summary: 
+screenshot: "[[KaraKeep/attachments/51f3952c-49f5-40d4-8687-ea1c4008b7f9-Introduction-Affinity-Wine.jpg]]"
+
+---
+
+# Introduction - Affinity Wine Documentation
+
+![Introduction - Affinity Wine Documentation - Screenshot](KaraKeep/attachments/51f3952c-49f5-40d4-8687-ea1c4008b7f9-Introduction-Affinity-Wine.jpg)
+
+## Description
+
+A guide to install Affinity on linux
+
+## Notes
+
+
+
+[Visit Link](https://affinity.liz.pet/v2/1-intro/)
+
+[View in Hoarder](https://kara.werats.gay/dashboard/preview/d7z2r60nf6lzkpulgfx1xaz0)

KaraKeep/2026-04-17-MagFlött-VESA-Mount-for-iPad-Pro.md

@@ -0,0 +1,37 @@
+---
+bookmark_id: "z3r73neq4rnx612qej1m67j6"
+url: |
+  https://www.charjenpro.com/products/magflottvesamount
+title: |
+  MagFlött VESA Mount for iPad Pro | Magnetic iPad Stand
+date: 2026-04-17T20:24:48.000Z
+modified: 2026-04-17T20:26:59.000Z
+note: 
+original_note: 
+summary: 
+banner: "[[KaraKeep/attachments/84f9fcc0-df49-4cac-958b-9de4e9f08a7f-MagFlött-VESA-Mount-for-iPad.jpg]]"
+screenshot: "[[KaraKeep/attachments/65020ffb-fc0c-4468-ae15-c3d6be54c171-MagFlött-VESA-Mount-for-iPad.jpg]]"
+additional:
+  - "[[KaraKeep/attachments/2c74efd1-eb12-4bf4-8aca-ef55e7719b38-MagFlött-VESA-Mount-for-iPad.jpg]]"
+
+---
+
+# MagFlött VESA Mount for iPad Pro | Magnetic iPad Stand
+
+![MagFlött VESA Mount for iPad Pro | Magnetic iPad Stand - Banner Image](KaraKeep/attachments/84f9fcc0-df49-4cac-958b-9de4e9f08a7f-MagFlött-VESA-Mount-for-iPad.jpg)
+
+![MagFlött VESA Mount for iPad Pro | Magnetic iPad Stand - Screenshot](KaraKeep/attachments/65020ffb-fc0c-4468-ae15-c3d6be54c171-MagFlött-VESA-Mount-for-iPad.jpg)
+
+![MagFlött VESA Mount for iPad Pro | Magnetic iPad Stand - linkHtmlContent](KaraKeep/attachments/2c74efd1-eb12-4bf4-8aca-ef55e7719b38-MagFlött-VESA-Mount-for-iPad.jpg)
+
+## Description
+
+MagFlött VESA Mount turns your iPad into a floating workstation. Ultra-strong magnets, aluminum body, and VESA arm compatibility. Relieve neck strain instantly.
+
+## Notes
+
+
+
+[Visit Link](https://www.charjenpro.com/products/magflottvesamount)
+
+[View in Hoarder](https://kara.werats.gay/dashboard/preview/z3r73neq4rnx612qej1m67j6)

KaraKeep/2026-04-20-How-to-Configure-K3s-for-IPv6.md

@@ -0,0 +1,36 @@
+---
+bookmark_id: "uegrktsmsv8e96v0ll9mijbr"
+url: |
+  https://oneuptime.com/blog/post/2026-03-20-k3s-ipv6-configuration/view
+title: How to Configure K3s for IPv6
+date: 2026-04-20T08:48:19.000Z
+modified: 2026-04-20T08:50:24.000Z
+note: 
+original_note: 
+summary: 
+banner: "[[KaraKeep/attachments/040320f7-8aa7-4688-9531-3ebbc2d334d1-How-to-Configure-K3s-for-IPv6.jpg]]"
+screenshot: "[[KaraKeep/attachments/c448a225-1fb2-49a7-9668-9b25881996df-How-to-Configure-K3s-for-IPv6.jpg]]"
+additional:
+  - "[[KaraKeep/attachments/22d9b6ff-a6f6-4d92-b16f-bebe89b6fd70-How-to-Configure-K3s-for-IPv6.jpg]]"
+
+---
+
+# How to Configure K3s for IPv6
+
+![How to Configure K3s for IPv6 - Banner Image](KaraKeep/attachments/040320f7-8aa7-4688-9531-3ebbc2d334d1-How-to-Configure-K3s-for-IPv6.jpg)
+
+![How to Configure K3s for IPv6 - Screenshot](KaraKeep/attachments/c448a225-1fb2-49a7-9668-9b25881996df-How-to-Configure-K3s-for-IPv6.jpg)
+
+![How to Configure K3s for IPv6 - linkHtmlContent](KaraKeep/attachments/22d9b6ff-a6f6-4d92-b16f-bebe89b6fd70-How-to-Configure-K3s-for-IPv6.jpg)
+
+## Description
+
+Learn how to configure K3s for IPv6-only or IPv6 single-stack networking to support modern network infrastructure.
+
+## Notes
+
+
+
+[Visit Link](https://oneuptime.com/blog/post/2026-03-20-k3s-ipv6-configuration/view)
+
+[View in Hoarder](https://kara.werats.gay/dashboard/preview/uegrktsmsv8e96v0ll9mijbr)

KaraKeep/2026-04-20-Installing-Arch-with-Secure-Boot,.md

@@ -0,0 +1,29 @@
+---
+bookmark_id: "j1hf9ctcdp5i5rycu872ei2i"
+url: |
+  https://www.reddit.com/r/archlinux/comments/1me8xpt/installing_arch_with_secure_boot_encryption_and/
+title: |
+  Installing Arch with Secure Boot, encryption and TPM2 auto-unlock : r/archlinux
+date: 2026-04-20T08:07:14.000Z
+modified: 2026-04-20T08:09:22.000Z
+note: 
+original_note: 
+summary: 
+banner: "[[KaraKeep/attachments/0e6f3b83-37cb-479d-90d5-5ef9305d8479-Installing-Arch-with-Secure.jpg]]"
+screenshot: "[[KaraKeep/attachments/39a606a1-ba75-41a2-a697-6f34b0c6803c-Installing-Arch-with-Secure.jpg]]"
+
+---
+
+# Installing Arch with Secure Boot, encryption and TPM2 auto-unlock : r/archlinux
+
+![Installing Arch with Secure Boot, encryption and TPM2 auto-unlock : r/archlinux - Banner Image](KaraKeep/attachments/0e6f3b83-37cb-479d-90d5-5ef9305d8479-Installing-Arch-with-Secure.jpg)
+
+![Installing Arch with Secure Boot, encryption and TPM2 auto-unlock : r/archlinux - Screenshot](KaraKeep/attachments/39a606a1-ba75-41a2-a697-6f34b0c6803c-Installing-Arch-with-Secure.jpg)
+
+## Notes
+
+
+
+[Visit Link](https://www.reddit.com/r/archlinux/comments/1me8xpt/installing_arch_with_secure_boot_encryption_and/)
+
+[View in Hoarder](https://kara.werats.gay/dashboard/preview/j1hf9ctcdp5i5rycu872ei2i)

KaraKeep/2026-04-20-Making-dual-stack-ipv6-work-with.md

@@ -0,0 +1,34 @@
+---
+bookmark_id: "zz9m513qzd7o65kblp0n9d3d"
+url: |
+  https://www.adyxax.org/blog/2021/07/27/making-dual-stack-ipv6-work-with-k3s/
+title: |
+  Making dual stack ipv6 work with k3s | Yet Another SysAdmin Website
+date: 2026-04-20T08:49:25.000Z
+modified: 2026-04-20T08:52:25.000Z
+note: 
+original_note: 
+summary: 
+screenshot: "[[KaraKeep/attachments/7d8f62bc-aa84-45e1-ac6b-95781a20a1da-Making-dual-stack-ipv6-work.jpg]]"
+additional:
+  - "[[KaraKeep/attachments/25d78444-1af2-4d98-8d56-7350aef62955-Making-dual-stack-ipv6-work.jpg]]"
+
+---
+
+# Making dual stack ipv6 work with k3s | Yet Another SysAdmin Website
+
+![Making dual stack ipv6 work with k3s | Yet Another SysAdmin Website - Screenshot](KaraKeep/attachments/7d8f62bc-aa84-45e1-ac6b-95781a20a1da-Making-dual-stack-ipv6-work.jpg)
+
+![Making dual stack ipv6 work with k3s | Yet Another SysAdmin Website - linkHtmlContent](KaraKeep/attachments/25d78444-1af2-4d98-8d56-7350aef62955-Making-dual-stack-ipv6-work.jpg)
+
+## Description
+
+How to setup a working ipv4/ipv6 service on k3s
+
+## Notes
+
+
+
+[Visit Link](https://www.adyxax.org/blog/2021/07/27/making-dual-stack-ipv6-work-with-k3s/)
+
+[View in Hoarder](https://kara.werats.gay/dashboard/preview/zz9m513qzd7o65kblp0n9d3d)

KaraKeep/2026-04-20-Multi-seat-support-·-Wiki-·-ACS.md

@@ -0,0 +1,36 @@
+---
+bookmark_id: "lmeh5yuedry38rumiccwwcap"
+url: |
+  https://gitlab.com/acs-wayland/weston/-/wikis/home/ACS-Features/Multi-seat-support
+title: Multi seat support · Wiki · ACS-Wayland / Weston · GitLab
+date: 2026-04-20T08:08:06.000Z
+modified: 2026-04-20T08:15:23.000Z
+note: 
+original_note: 
+summary: 
+banner: "[[KaraKeep/attachments/c2ac1a1d-adea-4825-81ad-8d35e8def5a9-Multi-seat-support-·-Wiki-·.jpg]]"
+screenshot: "[[KaraKeep/attachments/03283c3e-1171-48e1-a537-e758a715e108-Multi-seat-support-·-Wiki-·.jpg]]"
+additional:
+  - "[[KaraKeep/attachments/68f59c48-9625-4f07-9e08-d2cd2577e253-Multi-seat-support-·-Wiki-·.jpg]]"
+
+---
+
+# Multi seat support · Wiki · ACS-Wayland / Weston · GitLab
+
+![Multi seat support · Wiki · ACS-Wayland / Weston · GitLab - Banner Image](KaraKeep/attachments/c2ac1a1d-adea-4825-81ad-8d35e8def5a9-Multi-seat-support-·-Wiki-·.jpg)
+
+![Multi seat support · Wiki · ACS-Wayland / Weston · GitLab - Screenshot](KaraKeep/attachments/03283c3e-1171-48e1-a537-e758a715e108-Multi-seat-support-·-Wiki-·.jpg)
+
+![Multi seat support · Wiki · ACS-Wayland / Weston · GitLab - linkHtmlContent](KaraKeep/attachments/68f59c48-9625-4f07-9e08-d2cd2577e253-Multi-seat-support-·-Wiki-·.jpg)
+
+## Description
+
+GitLab.com
+
+## Notes
+
+
+
+[Visit Link](https://gitlab.com/acs-wayland/weston/-/wikis/home/ACS-Features/Multi-seat-support)
+
+[View in Hoarder](https://kara.werats.gay/dashboard/preview/lmeh5yuedry38rumiccwwcap)

KaraKeep/2026-04-20-[Hyprland]-As-fluid-as-it-gets.-r.md

@@ -0,0 +1,35 @@
+---
+bookmark_id: "zbza95cvkl3snp9pja5jsmbt"
+url: |
+  https://www.reddit.com/r/unixporn/comments/1s84jik/hyprland_as_fluid_as_it_gets/
+title: |
+  [Hyprland] As fluid as it gets. : r/unixporn
+date: 2026-04-20T08:33:51.000Z
+modified: 2026-04-20T08:34:24.000Z
+tags:
+  - hyprland
+  - nixos
+  - linux-desktop
+  - shell-setup
+  - dotfiles
+note: 
+original_note: 
+summary: 
+banner: "[[KaraKeep/attachments/4b4bafa3-ef7a-4133-96fe-1f18d932adca-[Hyprland]-As-fluid-as-it.jpg]]"
+screenshot: "[[KaraKeep/attachments/24d8fac9-182c-40e9-b9c6-f8dbd832d26d-[Hyprland]-As-fluid-as-it.jpg]]"
+
+---
+
+# [Hyprland] As fluid as it gets. : r/unixporn
+
+![[Hyprland] As fluid as it gets. : r/unixporn - Banner Image](<KaraKeep/attachments/4b4bafa3-ef7a-4133-96fe-1f18d932adca-[Hyprland]-As-fluid-as-it.jpg>)
+
+![[Hyprland] As fluid as it gets. : r/unixporn - Screenshot](<KaraKeep/attachments/24d8fac9-182c-40e9-b9c6-f8dbd832d26d-[Hyprland]-As-fluid-as-it.jpg>)
+
+## Notes
+
+
+
+[Visit Link](https://www.reddit.com/r/unixporn/comments/1s84jik/hyprland_as_fluid_as_it_gets/)
+
+[View in Hoarder](https://kara.werats.gay/dashboard/preview/zbza95cvkl3snp9pja5jsmbt)

KaraKeep/2026-04-20-[OC]-A-cozy-pixelaeted-collection.md

@@ -0,0 +1,35 @@
+---
+bookmark_id: "pzuelktltgt3pnsumjn2rfer"
+url: |
+  https://www.reddit.com/r/unixporn/comments/1s5xwgx/oc_a_cozy_pixelaeted_collection_of_lockscreen/
+title: |
+  [OC] A cozy pixelaeted collection of lockscreen themes made with QML for sddm / quickshell! : r/unixporn
+date: 2026-04-20T08:39:56.000Z
+modified: 2026-04-20T08:40:25.000Z
+tags:
+  - linux
+  - qml
+  - lockscreen-themes
+  - pixel-art
+  - sddm
+note: 
+original_note: 
+summary: 
+banner: "[[KaraKeep/attachments/69abf5b9-a761-47e1-b0ff-29e9a24d0966-[OC]-A-cozy-pixelaeted.jpg]]"
+screenshot: "[[KaraKeep/attachments/eafd3009-cb22-4061-bad4-c21b399cbc46-[OC]-A-cozy-pixelaeted.jpg]]"
+
+---
+
+# [OC] A cozy pixelaeted collection of lockscreen themes made with QML for sddm / quickshell! : r/unixporn
+
+![[OC] A cozy pixelaeted collection of lockscreen themes made with QML for sddm / quickshell! : r/unixporn - Banner Image](<KaraKeep/attachments/69abf5b9-a761-47e1-b0ff-29e9a24d0966-[OC]-A-cozy-pixelaeted.jpg>)
+
+![[OC] A cozy pixelaeted collection of lockscreen themes made with QML for sddm / quickshell! : r/unixporn - Screenshot](<KaraKeep/attachments/eafd3009-cb22-4061-bad4-c21b399cbc46-[OC]-A-cozy-pixelaeted.jpg>)
+
+## Notes
+
+
+
+[Visit Link](https://www.reddit.com/r/unixporn/comments/1s5xwgx/oc_a_cozy_pixelaeted_collection_of_lockscreen/)
+
+[View in Hoarder](https://kara.werats.gay/dashboard/preview/pzuelktltgt3pnsumjn2rfer)

KaraKeep/2026-04-20-[SOLVED]-Nvidia-dual-gpu-stack.md

@@ -0,0 +1,33 @@
+---
+bookmark_id: "patx7n11kkumw5cffcvq4i41"
+url: |
+  https://bbs.archlinux.org/viewtopic.php?id=305746
+title: |
+  [SOLVED] Nvidia dual gpu stack config question / Kernel & Hardware / Arch Linux Forums
+date: 2026-04-20T06:44:55.000Z
+modified: 2026-04-20T06:47:02.000Z
+note: 
+original_note: 
+summary: 
+banner: "[[KaraKeep/attachments/9d0b360d-6dee-453e-994c-15c043e19760-[SOLVED]-Nvidia-dual-gpu.jpg]]"
+screenshot: "[[KaraKeep/attachments/691ef2bd-f242-43d4-91dd-1ed12e1aa837-[SOLVED]-Nvidia-dual-gpu.jpg]]"
+additional:
+  - "[[KaraKeep/attachments/43a375b6-1b59-4572-b713-e125c9963eaa-[SOLVED]-Nvidia-dual-gpu.jpg]]"
+
+---
+
+# [SOLVED] Nvidia dual gpu stack config question / Kernel & Hardware / Arch Linux Forums
+
+![[SOLVED] Nvidia dual gpu stack config question / Kernel & Hardware / Arch Linux Forums - Banner Image](<KaraKeep/attachments/9d0b360d-6dee-453e-994c-15c043e19760-[SOLVED]-Nvidia-dual-gpu.jpg>)
+
+![[SOLVED] Nvidia dual gpu stack config question / Kernel & Hardware / Arch Linux Forums - Screenshot](<KaraKeep/attachments/691ef2bd-f242-43d4-91dd-1ed12e1aa837-[SOLVED]-Nvidia-dual-gpu.jpg>)
+
+![[SOLVED] Nvidia dual gpu stack config question / Kernel & Hardware / Arch Linux Forums - linkHtmlContent](<KaraKeep/attachments/43a375b6-1b59-4572-b713-e125c9963eaa-[SOLVED]-Nvidia-dual-gpu.jpg>)
+
+## Notes
+
+
+
+[Visit Link](https://bbs.archlinux.org/viewtopic.php?id=305746)
+
+[View in Hoarder](https://kara.werats.gay/dashboard/preview/patx7n11kkumw5cffcvq4i41)

KaraKeep/2026-04-20-dm-crypt-Encrypting-an-entire.md

@@ -0,0 +1,29 @@
+---
+bookmark_id: "mehtmbwqhzg4ijbuev54x3qr"
+url: |
+  https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_entire_system#LUKS_on_a_partition_with_TPM2_and_Secure_Boot
+title: dm-crypt/Encrypting an entire system - ArchWiki
+date: 2026-04-20T08:07:27.000Z
+modified: 2026-04-20T08:13:23.000Z
+note: 
+original_note: 
+summary: 
+screenshot: "[[KaraKeep/attachments/a660e0a8-6879-4709-9b88-c8db9140597a-dm-crypt-Encrypting-an-entire.jpg]]"
+additional:
+  - "[[KaraKeep/attachments/9a9b353a-8157-4a4d-83fb-110aacca7bc3-dm-crypt-Encrypting-an-entire.jpg]]"
+
+---
+
+# dm-crypt/Encrypting an entire system - ArchWiki
+
+![dm-crypt/Encrypting an entire system - ArchWiki - Screenshot](KaraKeep/attachments/a660e0a8-6879-4709-9b88-c8db9140597a-dm-crypt-Encrypting-an-entire.jpg)
+
+![dm-crypt/Encrypting an entire system - ArchWiki - linkHtmlContent](KaraKeep/attachments/9a9b353a-8157-4a4d-83fb-110aacca7bc3-dm-crypt-Encrypting-an-entire.jpg)
+
+## Notes
+
+
+
+[Visit Link](https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_entire_system#LUKS_on_a_partition_with_TPM2_and_Secure_Boot)
+
+[View in Hoarder](https://kara.werats.gay/dashboard/preview/mehtmbwqhzg4ijbuev54x3qr)

KaraKeep/2026-04-20-login(3)-Linux-manual-page.md

@@ -0,0 +1,32 @@
+---
+bookmark_id: "ta5j5zayogogv07nuk4lffhv"
+url: |
+  https://www.man7.org/linux/man-pages/man3/sd-login.3.html
+title: login(3) - Linux manual page
+date: 2026-04-20T08:19:44.000Z
+modified: 2026-04-20T08:21:50.000Z
+note: 
+original_note: 
+summary: 
+banner: "[[KaraKeep/attachments/f89d001c-5b1f-408f-9ac6-8dd279f25bd0-login(3)-Linux-manual-page.jpg]]"
+screenshot: "[[KaraKeep/attachments/f2126c6f-6dbe-4be2-8723-eaaff7e1cdb9-login(3)-Linux-manual-page.jpg]]"
+additional:
+  - "[[KaraKeep/attachments/f93a1a22-509f-403f-9a1d-6c11393b02b9-login(3)-Linux-manual-page.jpg]]"
+
+---
+
+# login(3) - Linux manual page
+
+![login(3) - Linux manual page - Banner Image](<KaraKeep/attachments/f89d001c-5b1f-408f-9ac6-8dd279f25bd0-login(3)-Linux-manual-page.jpg>)
+
+![login(3) - Linux manual page - Screenshot](<KaraKeep/attachments/f2126c6f-6dbe-4be2-8723-eaaff7e1cdb9-login(3)-Linux-manual-page.jpg>)
+
+![login(3) - Linux manual page - linkHtmlContent](<KaraKeep/attachments/f93a1a22-509f-403f-9a1d-6c11393b02b9-login(3)-Linux-manual-page.jpg>)
+
+## Notes
+
+
+
+[Visit Link](https://www.man7.org/linux/man-pages/man3/sd-login.3.html)
+
+[View in Hoarder](https://kara.werats.gay/dashboard/preview/ta5j5zayogogv07nuk4lffhv)

KaraKeep/2026-04-20-redhead,-face,-braids,-Tidsean,.md

@@ -0,0 +1,43 @@
+---
+bookmark_id: "bzh5ctidooq4e1iuhsb81q97"
+url: |
+  https://wallhaven.cc/w/7pyolv
+title: |
+  redhead, face, braids, Tidsean, closed mouth, ringed eyes, long hair, head tilt, collarbone, smiling, looking at viewer, ponytail, Chainsaw Man, Makima (Chainsaw Man), simple background, black background, yellow eyes, anime girls, long sleeves | 2432x1368 Wallpaper - wallhaven.cc
+date: 2026-04-20T09:24:03.000Z
+modified: 2026-04-20T09:24:45.000Z
+tags:
+  - anime
+  - chainsaw-man
+  - wallpaper
+  - redhead
+  - makima
+note: 
+original_note: 
+summary: 
+banner: "[[KaraKeep/attachments/8ee7b7c0-86e5-4862-a8e7-61a814ff1746-redhead,-face,-braids,.jpg]]"
+screenshot: "[[KaraKeep/attachments/90e61b51-7cff-4b61-9672-fe6f64dbdd3f-redhead,-face,-braids,.jpg]]"
+additional:
+  - "[[KaraKeep/attachments/8118b0ec-f950-42f7-851a-2261ed9df314-redhead,-face,-braids,.jpg]]"
+
+---
+
+# redhead, face, braids, Tidsean, closed mouth, ringed eyes, long hair, head tilt, collarbone, smiling, looking at viewer, ponytail, Chainsaw Man, Makima (Chainsaw Man), simple background, black background, yellow eyes, anime girls, long sleeves | 2432x1368 Wallpaper - wallhaven.cc
+
+![redhead, face, braids, Tidsean, closed mouth, ringed eyes, long hair, head tilt, collarbone, smiling, looking at viewer, ponytail, Chainsaw Man, Makima (Chainsaw Man), simple background, black background, yellow eyes, anime girls, long sleeves | 2432x1368 Wallpaper - wallhaven.cc - Banner Image](KaraKeep/attachments/8ee7b7c0-86e5-4862-a8e7-61a814ff1746-redhead,-face,-braids,.jpg)
+
+![redhead, face, braids, Tidsean, closed mouth, ringed eyes, long hair, head tilt, collarbone, smiling, looking at viewer, ponytail, Chainsaw Man, Makima (Chainsaw Man), simple background, black background, yellow eyes, anime girls, long sleeves | 2432x1368 Wallpaper - wallhaven.cc - Screenshot](KaraKeep/attachments/90e61b51-7cff-4b61-9672-fe6f64dbdd3f-redhead,-face,-braids,.jpg)
+
+![redhead, face, braids, Tidsean, closed mouth, ringed eyes, long hair, head tilt, collarbone, smiling, looking at viewer, ponytail, Chainsaw Man, Makima (Chainsaw Man), simple background, black background, yellow eyes, anime girls, long sleeves | 2432x1368 Wallpaper - wallhaven.cc - linkHtmlContent](KaraKeep/attachments/8118b0ec-f950-42f7-851a-2261ed9df314-redhead,-face,-braids,.jpg)
+
+## Description
+
+redhead, face, braids, Tidsean, closed mouth, ringed eyes, long hair, head tilt, collarbone, smiling, looking at viewer, ponytail, Chainsaw Man, Makima (Chainsaw Man), simple background, black background, yellow eyes, anime girls, long sleeves | 2432x1368 Wallpaper
+
+## Notes
+
+
+
+[Visit Link](https://wallhaven.cc/w/7pyolv)
+
+[View in Hoarder](https://kara.werats.gay/dashboard/preview/bzh5ctidooq4e1iuhsb81q97)

KaraKeep/2026-04-20-systemd-cryptenroll-ArchWiki.md

@@ -0,0 +1,29 @@
+---
+bookmark_id: "y66wz61rxyfrw2gx0evhnfh6"
+url: |
+  https://wiki.archlinux.org/title/Systemd-cryptenroll#Regular_password
+title: systemd-cryptenroll - ArchWiki
+date: 2026-04-20T08:07:19.000Z
+modified: 2026-04-20T08:11:22.000Z
+note: 
+original_note: 
+summary: 
+screenshot: "[[KaraKeep/attachments/4ecd662c-8fd7-44b1-8f78-fdaae95bf83a-systemd-cryptenroll-ArchWiki.jpg]]"
+additional:
+  - "[[KaraKeep/attachments/bc1e8b42-d238-4476-867c-052d1446edde-systemd-cryptenroll-ArchWiki.jpg]]"
+
+---
+
+# systemd-cryptenroll - ArchWiki
+
+![systemd-cryptenroll - ArchWiki - Screenshot](KaraKeep/attachments/4ecd662c-8fd7-44b1-8f78-fdaae95bf83a-systemd-cryptenroll-ArchWiki.jpg)
+
+![systemd-cryptenroll - ArchWiki - linkHtmlContent](KaraKeep/attachments/bc1e8b42-d238-4476-867c-052d1446edde-systemd-cryptenroll-ArchWiki.jpg)
+
+## Notes
+
+
+
+[Visit Link](https://wiki.archlinux.org/title/Systemd-cryptenroll#Regular_password)
+
+[View in Hoarder](https://kara.werats.gay/dashboard/preview/y66wz61rxyfrw2gx0evhnfh6)

KaraKeep/2026-04-23-Pokemon-Champions-Speed-Tiers-VGC.md

@@ -0,0 +1,39 @@
+---
+bookmark_id: "ftsqbjaai5rgn5zw2brlagcu"
+url: |
+  https://www.pikalytics.com/speed-tiers
+title: |
+  Pokemon Champions Speed Tiers VGC 2026 | Pikalytics
+date: 2026-04-23T21:55:28.000Z
+modified: 2026-04-23T21:57:43.000Z
+tags:
+  - pokemon-champions
+note: 
+original_note: 
+summary: 
+banner: "[[KaraKeep/attachments/f54c40c9-3212-4fa9-9990-a65f87336039-Pokemon-Champions-Speed-Tiers.jpg]]"
+screenshot: "[[KaraKeep/attachments/94834e31-cabc-4c43-9fef-ee27d58ebf41-Pokemon-Champions-Speed-Tiers.jpg]]"
+additional:
+  - "[[KaraKeep/attachments/d7bed340-5cd5-4cbb-a9ce-9a10f07a0f6d-Pokemon-Champions-Speed-Tiers.jpg]]"
+
+---
+
+# Pokemon Champions Speed Tiers VGC 2026 | Pikalytics
+
+![Pokemon Champions Speed Tiers VGC 2026 | Pikalytics - Banner Image](KaraKeep/attachments/f54c40c9-3212-4fa9-9990-a65f87336039-Pokemon-Champions-Speed-Tiers.jpg)
+
+![Pokemon Champions Speed Tiers VGC 2026 | Pikalytics - Screenshot](KaraKeep/attachments/94834e31-cabc-4c43-9fef-ee27d58ebf41-Pokemon-Champions-Speed-Tiers.jpg)
+
+![Pokemon Champions Speed Tiers VGC 2026 | Pikalytics - linkHtmlContent](KaraKeep/attachments/d7bed340-5cd5-4cbb-a9ce-9a10f07a0f6d-Pokemon-Champions-Speed-Tiers.jpg)
+
+## Description
+
+The premier competitive Pokemon statistics database for VGC, Smogon, and Pokemon GO
+
+## Notes
+
+
+
+[Visit Link](https://www.pikalytics.com/speed-tiers)
+
+[View in Hoarder](https://kara.werats.gay/dashboard/preview/ftsqbjaai5rgn5zw2brlagcu)

KaraKeep/attachments/22d9b6ff-a6f6-4d92-b16f-bebe89b6fd70-How-to-Configure-K3s-for-IPv6.jpg

@@ -0,0 +1,169 @@
+<div id="readability-page-1" class="page"><div>
+                                    <h2 id="introduction">Introduction<a href="#introduction" aria-label="Link to Introduction"><svg fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M13.828 10.172a4 4 0 00-5.656 0l-4 4a4 4 0 105.656 5.656l1.102-1.101m-.758-4.899a4 4 0 005.656 0l4-4a4 4 0 00-5.656-5.656l-1.1 1.1"></path></svg></a></h2><p>As IPv4 addresses become scarce and IPv6 adoption grows, running Kubernetes with IPv6 is increasingly important. K3s supports IPv6 single-stack mode where pods, services, and nodes communicate exclusively over IPv6. This guide covers configuring K3s for IPv6 operation, including network requirements, installation, and verification.</p><h2 id="prerequisites">Prerequisites<a href="#prerequisites" aria-label="Link to Prerequisites"><svg fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M13.828 10.172a4 4 0 00-5.656 0l-4 4a4 4 0 105.656 5.656l1.102-1.101m-.758-4.899a4 4 0 005.656 0l4-4a4 4 0 00-5.656-5.656l-1.1 1.1"></path></svg></a></h2><ul><li>Linux host with IPv6 network connectivity</li><li>IPv6 subnet available for pod and service CIDR allocation</li><li>Kernel with IPv6 support (all modern Linux kernels)</li><li>No IPv4-only constraints in your environment</li></ul><h2 id="step-1-verify-ipv6-support-on-the-host">Step 1: Verify IPv6 Support on the Host<a href="#step-1-verify-ipv6-support-on-the-host" aria-label="Link to Step 1: Verify IPv6 Support on the Host"><svg fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M13.828 10.172a4 4 0 00-5.656 0l-4 4a4 4 0 105.656 5.656l1.102-1.101m-.758-4.899a4 4 0 005.656 0l4-4a4 4 0 00-5.656-5.656l-1.1 1.1"></path></svg></a></h2><pre><code data-highlighted="yes"><span># Check if IPv6 is enabled</span>
+
+<span>cat</span> /proc/sys/net/ipv6/conf/all/disable_ipv6
+<span># 0 = enabled, 1 = disabled</span>
+
+<span># If disabled, enable it</span>
+<span>echo</span> 0 &gt; /proc/sys/net/ipv6/conf/all/disable_ipv6
+
+<span># Make permanent</span>
+<span>cat</span> &gt;&gt; /etc/sysctl.conf &lt;&lt; <span>'EOF'</span>
+net.ipv6.conf.all.disable_ipv6 = 0
+net.ipv6.conf.default.disable_ipv6 = 0
+net.ipv6.conf.lo.disable_ipv6 = 0
+EOF
+sysctl -p
+
+<span># Check the host's IPv6 address</span>
+ip -6 addr show
+<span># Should show your IPv6 addresses</span>
+
+<span># Test IPv6 connectivity</span>
+ping6 -c 4 2001:4860:4860::8888  <span># Google's IPv6 DNS</span></code></pre><h2 id="step-2-configure-ipv6-forwarding">Step 2: Configure IPv6 Forwarding<a href="#step-2-configure-ipv6-forwarding" aria-label="Link to Step 2: Configure IPv6 Forwarding"><svg fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M13.828 10.172a4 4 0 00-5.656 0l-4 4a4 4 0 105.656 5.656l1.102-1.101m-.758-4.899a4 4 0 005.656 0l4-4a4 4 0 00-5.656-5.656l-1.1 1.1"></path></svg></a></h2><p>Kubernetes requires IP forwarding to route pod traffic:</p><pre><code data-highlighted="yes"><span># Enable IPv6 forwarding</span>
+<span>cat</span> &gt;&gt; /etc/sysctl.conf &lt;&lt; <span>'EOF'</span>
+net.ipv6.conf.all.forwarding = 1
+net.ipv6.conf.default.forwarding = 1
+EOF
+
+sysctl -p
+
+<span># Verify</span>
+<span>cat</span> /proc/sys/net/ipv6/conf/all/forwarding
+<span># Should output: 1</span></code></pre><h2 id="step-3-install-k3s-with-ipv6-configuration">Step 3: Install K3s with IPv6 Configuration<a href="#step-3-install-k3s-with-ipv6-configuration" aria-label="Link to Step 3: Install K3s with IPv6 Configuration"><svg fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M13.828 10.172a4 4 0 00-5.656 0l-4 4a4 4 0 105.656 5.656l1.102-1.101m-.758-4.899a4 4 0 005.656 0l4-4a4 4 0 00-5.656-5.656l-1.1 1.1"></path></svg></a></h2><pre><code data-highlighted="yes"><span># Plan your IPv6 subnets:</span>
+<span># Cluster CIDR (pod IPs): fd42::/24</span>
+<span># Service CIDR: fd43::/112</span>
+<span># Node CIDR size: /80 per node</span>
+
+<span># Install K3s server with IPv6</span>
+curl -sfL https://get.k3s.io | \
+  INSTALL_K3S_EXEC=<span>"
+    --cluster-cidr=fd42::/24
+    --service-cidr=fd43::/112
+    --cluster-dns=fd43::10
+    --flannel-ipv6-masq=true
+  "</span> \
+  sh -</code></pre><p>Or using a config file:</p><pre><code data-highlighted="yes"><span># /etc/rancher/k3s/config.yaml</span>
+<span># IPv6 single-stack configuration</span>
+<span>cluster-cidr:</span> <span>"fd42::/24"</span>
+<span>service-cidr:</span> <span>"fd43::/112"</span>
+<span>cluster-dns:</span> <span>"fd43::10"</span>
+
+<span># Flannel IPv6 settings</span>
+<span>flannel-ipv6-masq:</span> <span>true</span>
+
+<span># Optional: specify flannel backend</span>
+<span>flannel-backend:</span> <span>vxlan</span></code></pre><h2 id="step-4-install-k3s-agent-with-ipv6">Step 4: Install K3s Agent with IPv6<a href="#step-4-install-k3s-agent-with-ipv6" aria-label="Link to Step 4: Install K3s Agent with IPv6"><svg fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M13.828 10.172a4 4 0 00-5.656 0l-4 4a4 4 0 105.656 5.656l1.102-1.101m-.758-4.899a4 4 0 005.656 0l4-4a4 4 0 00-5.656-5.656l-1.1 1.1"></path></svg></a></h2><pre><code data-highlighted="yes"><span># Agent nodes need the server's IPv6 address</span>
+curl -sfL https://get.k3s.io | \
+  K3S_URL=https://[&lt;server-ipv6&gt;]:6443 \
+  K3S_TOKEN=&lt;node-token&gt; \
+  sh -
+
+<span># Note: IPv6 addresses in URLs must be enclosed in brackets</span>
+<span># Example: https://[2001:db8::1]:6443</span></code></pre><h2 id="step-5-verify-ipv6-cluster">Step 5: Verify IPv6 Cluster<a href="#step-5-verify-ipv6-cluster" aria-label="Link to Step 5: Verify IPv6 Cluster"><svg fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M13.828 10.172a4 4 0 00-5.656 0l-4 4a4 4 0 105.656 5.656l1.102-1.101m-.758-4.899a4 4 0 005.656 0l4-4a4 4 0 00-5.656-5.656l-1.1 1.1"></path></svg></a></h2><pre><code data-highlighted="yes"><span># Check nodes have IPv6 addresses</span>
+kubectl get nodes -o wide
+<span># Internal-IP should show IPv6 addresses</span>
+
+<span># Check pods have IPv6 IPs</span>
+kubectl get pods -A -o wide
+<span># Pod IP should be from the fd42::/24 range</span>
+
+<span># Check services have IPv6 cluster IPs</span>
+kubectl get svc -A
+<span># Cluster IP should be from fd43::/112 range</span>
+
+<span># Verify DNS is using IPv6</span>
+kubectl run dns-test --image=busybox --restart=Never -- <span>sleep</span> 3600
+kubectl <span>exec</span> dns-test -- nslookup kubernetes.default.svc.cluster.local
+<span># Should resolve to IPv6 address</span>
+
+kubectl delete pod dns-test</code></pre><h2 id="step-6-test-ipv6-pod-communication">Step 6: Test IPv6 Pod Communication<a href="#step-6-test-ipv6-pod-communication" aria-label="Link to Step 6: Test IPv6 Pod Communication"><svg fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M13.828 10.172a4 4 0 00-5.656 0l-4 4a4 4 0 105.656 5.656l1.102-1.101m-.758-4.899a4 4 0 005.656 0l4-4a4 4 0 00-5.656-5.656l-1.1 1.1"></path></svg></a></h2><pre><code data-highlighted="yes"><span># Deploy a test application</span>
+<span>cat</span> &lt;&lt;<span>'EOF'</span> | kubectl apply -f -
+apiVersion: v1
+kind: Pod
+metadata:
+  name: ipv6-server
+spec:
+  containers:
+    - name: server
+      image: nginx:latest
+      ports:
+        - containerPort: 80
+---
+apiVersion: v1
+kind: Service
+metadata:
+  name: ipv6-server-svc
+spec:
+  selector:
+    name: ipv6-server  <span># Note: need proper label</span>
+  ports:
+    - port: 80
+      targetPort: 80
+  <span>type</span>: ClusterIP
+EOF
+
+<span># Get the service ClusterIP (should be IPv6)</span>
+kubectl get svc ipv6-server-svc
+
+<span># Test connectivity from another pod</span>
+kubectl run test-client --image=curlimages/curl --restart=Never \
+  -- curl -v http://ipv6-server-svc/
+
+kubectl logs test-client
+
+<span># Clean up</span>
+kubectl delete pod ipv6-server test-client
+kubectl delete svc ipv6-server-svc</code></pre><h2 id="step-7-configure-ipv6-aware-ingress">Step 7: Configure IPv6-Aware Ingress<a href="#step-7-configure-ipv6-aware-ingress" aria-label="Link to Step 7: Configure IPv6-Aware Ingress"><svg fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M13.828 10.172a4 4 0 00-5.656 0l-4 4a4 4 0 105.656 5.656l1.102-1.101m-.758-4.899a4 4 0 005.656 0l4-4a4 4 0 00-5.656-5.656l-1.1 1.1"></path></svg></a></h2><p>For Traefik to listen on IPv6:</p><pre><code data-highlighted="yes"><span># /var/lib/rancher/k3s/server/manifests/traefik-ipv6.yaml</span>
+<span>apiVersion:</span> <span>helm.cattle.io/v1</span>
+<span>kind:</span> <span>HelmChartConfig</span>
+<span>metadata:</span>
+  <span>name:</span> <span>traefik</span>
+  <span>namespace:</span> <span>kube-system</span>
+<span>spec:</span>
+  <span>valuesContent:</span> <span>|-
+    additionalArguments:
+      # Listen on all interfaces including IPv6
+      - "--entrypoints.web.address=:80"
+      - "--entrypoints.websecure.address=:443"
+    # Ensure Traefik binds to IPv6
+    service:
+      ipFamilies:
+        - IPv6
+      ipFamilyPolicy: SingleStack</span></code></pre><h2 id="step-8-coredns-ipv6-configuration">Step 8: CoreDNS IPv6 Configuration<a href="#step-8-coredns-ipv6-configuration" aria-label="Link to Step 8: CoreDNS IPv6 Configuration"><svg fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M13.828 10.172a4 4 0 00-5.656 0l-4 4a4 4 0 105.656 5.656l1.102-1.101m-.758-4.899a4 4 0 005.656 0l4-4a4 4 0 00-5.656-5.656l-1.1 1.1"></path></svg></a></h2><p>Ensure CoreDNS is configured for IPv6:</p><pre><code data-highlighted="yes"><span># Verify CoreDNS has IPv6 service IP</span>
+kubectl get svc coredns -n kube-system
+
+<span># The cluster-dns flag should point to an IPv6 address</span>
+<span># Default: fd43::10 (from service CIDR)</span>
+
+<span># Verify DNS resolution works over IPv6</span>
+kubectl run dns-test --image=busybox --restart=Never -- \
+  nslookup kubernetes.default.svc.cluster.local fd43::10
+
+kubectl logs dns-test
+kubectl delete pod dns-test</code></pre><h2 id="step-9-network-policy-with-ipv6">Step 9: Network Policy with IPv6<a href="#step-9-network-policy-with-ipv6" aria-label="Link to Step 9: Network Policy with IPv6"><svg fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M13.828 10.172a4 4 0 00-5.656 0l-4 4a4 4 0 105.656 5.656l1.102-1.101m-.758-4.899a4 4 0 005.656 0l4-4a4 4 0 00-5.656-5.656l-1.1 1.1"></path></svg></a></h2><pre><code data-highlighted="yes"><span># ipv6-network-policy.yaml</span>
+<span>apiVersion:</span> <span>networking.k8s.io/v1</span>
+<span>kind:</span> <span>NetworkPolicy</span>
+<span>metadata:</span>
+  <span>name:</span> <span>allow-internal-ipv6</span>
+  <span>namespace:</span> <span>default</span>
+<span>spec:</span>
+  <span>podSelector:</span> {}
+  <span>policyTypes:</span>
+    <span>-</span> <span>Ingress</span>
+    <span>-</span> <span>Egress</span>
+  <span>ingress:</span>
+    <span>-</span> <span>from:</span>
+        <span>-</span> <span>ipBlock:</span>
+            <span># Allow from the pod CIDR</span>
+            <span>cidr:</span> <span>fd42::/24</span>
+  <span>egress:</span>
+    <span>-</span> <span>to:</span>
+        <span>-</span> <span>ipBlock:</span>
+            <span>cidr:</span> <span>fd42::/24</span>
+    <span>-</span> <span>ports:</span>
+        <span># Allow DNS over IPv6</span>
+        <span>-</span> <span>port:</span> <span>53</span>
+          <span>protocol:</span> <span>UDP</span>
+        <span>-</span> <span>port:</span> <span>53</span>
+          <span>protocol:</span> <span>TCP</span></code></pre><h2 id="conclusion">Conclusion<a href="#conclusion" aria-label="Link to Conclusion"><svg fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M13.828 10.172a4 4 0 00-5.656 0l-4 4a4 4 0 105.656 5.656l1.102-1.101m-.758-4.899a4 4 0 005.656 0l4-4a4 4 0 00-5.656-5.656l-1.1 1.1"></path></svg></a></h2><p>K3s supports IPv6 single-stack networking with a clean configuration experience. The key requirements are choosing appropriate IPv6 CIDRs for pods and services, enabling IPv6 forwarding on all nodes, and configuring Flannel for IPv6 masquerading. IPv6-only clusters are well-suited for modern data centers and IoT deployments where IPv6 is the primary or sole network protocol. Always verify end-to-end connectivity after configuration with test pods before deploying production workloads.</p>                                </div></div>

KaraKeep/attachments/25d78444-1af2-4d98-8d56-7350aef62955-Making-dual-stack-ipv6-work.jpg

@@ -0,0 +1,132 @@
+<div id="readability-page-1" class="page"><div><p>2021-07-27 - How to setup a working ipv4/ipv6 service on k3s<br>Tags: <a href="https://www.adyxax.org/tags/ipv6/">Ipv6</a> <a href="https://www.adyxax.org/tags/k3s/">K3s</a> <a href="https://www.adyxax.org/tags/kubernetes/">Kubernetes</a></p><h2 id="introduction">Introduction</h2><p>I have yet to write a lot about the kubernetes setup I use for pieces of my personal infrastructure, because I was not satisfied with what I had to show. Today I picked up k3s again which I like quite a lot for it being a light implementation. Consuming 800M of ram before you get any workload running is hardly lightweight, but it is the lightest I have experienced for kubernetes. An entry level virtual machine at ovh or hetzner having 2G of ram for 3€/month is sufficient to run it, that’s what I have been doing for the last year.</p><p>The main thing I was not satisfied was ipv6 support. I do not know what changed since last year when I tried and failed to make it work in k3s 1.19, but now with 1.21 and some effort it does work! Here is how.</p><h2 id="installation">Installation</h2><p>Let’s start with a freshly reinstalled ovh vps with Ubuntu 20.04. Make sure to properly configure ipv6 on it, for this ovh machine I configured a netplan that looks like this :</p><div><pre tabindex="0"><code data-lang="yaml"><span><span><span>network</span><span>:</span><span>
+</span></span></span><span><span><span>    </span><span>version</span><span>:</span><span> </span><span>2</span><span>
+</span></span></span><span><span><span>    </span><span>ethernets</span><span>:</span><span>
+</span></span></span><span><span><span>        </span><span>ens3</span><span>:</span><span>
+</span></span></span><span><span><span>            </span><span>dhcp4</span><span>:</span><span> </span><span>true</span><span>
+</span></span></span><span><span><span>            </span><span>match</span><span>:</span><span>
+</span></span></span><span><span><span>                </span><span>macaddress</span><span>:</span><span> </span><span>fa:16:3e:82:71:b7</span><span>
+</span></span></span><span><span><span>            </span><span>mtu</span><span>:</span><span> </span><span>1500</span><span>
+</span></span></span><span><span><span>            </span><span>set-name</span><span>:</span><span> </span><span>ens3</span><span>
+</span></span></span><span><span><span>            </span><span>dhcp6</span><span>:</span><span> </span><span>no</span><span>
+</span></span></span><span><span><span>            </span><span>addresses</span><span>:</span><span>
+</span></span></span><span><span><span>                </span>- <span>2001</span><span>:</span><span>41d0:401:3100:0:0:0:fd5/128</span><span>
+</span></span></span><span><span><span>            </span><span>gateway6</span><span>:</span><span> </span><span>2001</span><span>:</span><span>41d0:0401:3100:0000:0000:0000:0001</span><span>
+</span></span></span><span><span><span>            </span><span>routes</span><span>:</span><span>
+</span></span></span><span><span><span>                </span>- <span>to</span><span>:</span><span> </span><span>2001</span><span>:</span><span>41d0:0401:3100:0000:0000:0000:0001</span><span>
+</span></span></span><span><span><span>                  </span><span>scope</span><span>:</span><span> </span><span>link</span><span>
+</span></span></span></code></pre></div><p>After installation I just ran an <code>apt dist-upgrade</code> then installed <code>ipvsadm</code>. Afterwards it’s all k3s :</p><div><pre tabindex="0"><code data-lang="sh"><span><span><span>export</span> <span>INSTALL_K3S_VERSION</span><span>=</span>v1.21.3+k3s1
+</span></span><span><span><span>export</span> <span>INSTALL_K3S_EXEC</span><span>=</span><span>"server --disable traefik --disable servicelb --disable metrics-server --disable-cloud-controller \
+</span></span></span><span><span><span>       --kube-proxy-arg proxy-mode=ipvs --cluster-cidr=10.42.0.0/16,fd42::/48 --service-cidr=10.43.0.0/16,fd43::/112 \
+</span></span></span><span><span><span>       --disable-network-policy --flannel-backend=none --node-ip=37.187.244.19,2001:41d0:401:3100::fd5"</span>
+</span></span></code></pre></div><p>As you can see we need to disable quite a few k3s components, mainly flannel which does not support dual stack at all at this time (it has been coming soon© to flannel for quite some time) and servicelb (the internal component to k3s which allows to simply use the LoadBalancer service type). We are going to use Calico instead of flannel therefore we also disable k3s’ internal network policy system, and we are going to need to customize the ingress service so we also disable the integrated traefik. We will use metallb instead of servicelb and ingress-nginx instead of traefik.</p><p>If you are replicating this on your own setup make sure the node-ip addresses are the ones configured on your node, if the cluster-cidr and service-cidr do not conflict with your own you can keep those.</p><p>Once ready review the k3s installation script then run it :</p><div><pre tabindex="0"><code data-lang="sh"><span><span>wget https://get.k3s.io -O k3s.sh
+</span></span><span><span>less k3s.sh
+</span></span><span><span>bash k3s.sh
+</span></span></code></pre></div><p>With k3s installed you should be able to access the kubernetes cli with <code>kubectl get nodes</code> but basic services like coredns pod won’t start before calico is setup.</p><h2 id="calico">Calico</h2><p>Retrieve Calico’s manifests with :</p><div><pre tabindex="0"><code data-lang="sh"><span><span>wget https://docs.projectcalico.org/manifests/calico.yaml
+</span></span></code></pre></div><p>Edit this file and locate the <code>ipam</code> section of the ConfigMap. Change it to the following :</p><div><pre tabindex="0"><code data-lang="json"><span><span><span>"ipam"</span><span>:</span> <span>{</span>
+</span></span><span><span>    <span>"type"</span><span>:</span> <span>"calico-ipam"</span><span>,</span>
+</span></span><span><span>    <span>"assign_ipv4"</span><span>:</span> <span>"true"</span><span>,</span>
+</span></span><span><span>    <span>"assign_ipv6"</span><span>:</span> <span>"true"</span>
+</span></span><span><span><span>}</span><span>,</span>
+</span></span></code></pre></div><p>Then locate the <code>FELIX_IPV6SUPPORT</code> variable in the calico-node DaemonSet configuration and set it to <code>true</code>.</p><p>You can then apply this manifest :</p><div><pre tabindex="0"><code data-lang="sh"><span><span>kubectl apply -f calico.yaml
+</span></span></code></pre></div><p>From there for standard pods and services should start properly, give calico some time and check :</p><pre tabindex="0"><code>kubectl get pods -A
+NAMESPACE     NAME                                           READY   STATUS    RESTARTS   AGE
+kube-system   pod/local-path-provisioner-5ff76fc89d-5xvcg    1/1     Running   0          2m51s
+kube-system   pod/calico-node-dfwp5                          1/1     Running   0          67s
+kube-system   pod/coredns-7448499f4d-ckzlk                   1/1     Running   0          2m51s
+kube-system   pod/calico-kube-controllers-78d6f96c7b-m527n   1/1     Running   0          67s
+</code></pre><p>You should have four pods running : coredns, two calico pods and k3s’ local path provisionner.</p><p>Since this is a cheap and self made infrastructure we are going to rely on metallb to provide us with external connectivity. Install it with :</p><div><pre tabindex="0"><code data-lang="sh"><span><span>wget https://raw.githubusercontent.com/metallb/metallb/v0.10.2/manifests/namespace.yaml -O metallb-namespace.yaml
+</span></span><span><span>wget https://raw.githubusercontent.com/metallb/metallb/v0.10.2/manifests/metallb.yaml -O metallb-0.10.2-manifest.yaml
+</span></span><span><span>kubectl apply -f metallb-namespace.yaml -f metallb-0.10.2-manifest.yaml
+</span></span></code></pre></div><p>Then create a metallb-config.yaml with content like this :</p><div><pre tabindex="0"><code data-lang="yaml"><span><span><span>apiVersion</span><span>:</span><span> </span><span>v1</span><span>
+</span></span></span><span><span><span>kind</span><span>:</span><span> </span><span>ConfigMap</span><span>
+</span></span></span><span><span><span>metadata</span><span>:</span><span>
+</span></span></span><span><span><span>  </span><span>namespace</span><span>:</span><span> </span><span>metallb-system</span><span>
+</span></span></span><span><span><span>  </span><span>name</span><span>:</span><span> </span><span>config</span><span>
+</span></span></span><span><span><span>data</span><span>:</span><span>
+</span></span></span><span><span><span>  </span><span>config</span><span>:</span><span> </span><span>|</span><span>
+</span></span></span><span><span><span>    address-pools:
+</span></span></span><span><span><span>    - name: default
+</span></span></span><span><span><span>      protocol: layer2
+</span></span></span><span><span><span>      addresses:
+</span></span></span><span><span><span>      - 37.187.244.19/32
+</span></span></span><span><span><span>      - 2001:41d0:401:3100::fd5/128</span><span>
+</span></span></span></code></pre></div><p>Don’t forget to replace the ipv4 and ipv6 addresses with the ones configured on your node. Then apply this manifest :</p><div><pre tabindex="0"><code data-lang="sh"><span><span>kubectl apply -f metallb-config.yaml
+</span></span></code></pre></div><p>Give it a minute then check that everything is ok :</p><div><pre tabindex="0"><code data-lang="sh"><span><span>kubectl -n metallb-system get pods
+</span></span><span><span>NAME                              READY   STATUS    RESTARTS   AGE
+</span></span><span><span>pod/controller-6b78bff7d9-szz78   1/1     Running   <span>0</span>          86s
+</span></span><span><span>pod/speaker-mx46m                 1/1     Running   <span>0</span>          86s
+</span></span></code></pre></div><h2 id="ingress-nginx">Ingress-nginx</h2><p>From there we can setup our ingress-nginx, but it will require a bit of service customization :</p><div><pre tabindex="0"><code data-lang="sh"><span><span>wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.48.1/deploy/static/provider/baremetal/deploy.yaml <span>\
+</span></span></span><span><span>     -O ingress-nginx-0.48.1.yaml
+</span></span></code></pre></div><p>Edit this file and locate the ingress-nginx-controller Service, which is by default of type NodePort. We are going to replace it with two services of type LoadBalancer, one for ipv4 and one for ipv6. Theoretically a single DualStack service should be supported but it does not work for me, the service only listens on its ipv6 address. So we are going to replace the whole ingress-nginx-controller Service with these two entries :</p><div><pre tabindex="0"><code data-lang="yaml"><span><span><span>apiVersion</span><span>:</span><span> </span><span>v1</span><span>
+</span></span></span><span><span><span>kind</span><span>:</span><span> </span><span>Service</span><span>
+</span></span></span><span><span><span>metadata</span><span>:</span><span>
+</span></span></span><span><span><span>  </span><span>annotations</span><span>:</span><span>
+</span></span></span><span><span><span>  </span><span>labels</span><span>:</span><span>
+</span></span></span><span><span><span>    </span><span>helm.sh/chart</span><span>:</span><span> </span><span>ingress-nginx-3.34.0</span><span>
+</span></span></span><span><span><span>    </span><span>app.kubernetes.io/name</span><span>:</span><span> </span><span>ingress-nginx</span><span>
+</span></span></span><span><span><span>    </span><span>app.kubernetes.io/instance</span><span>:</span><span> </span><span>ingress-nginx</span><span>
+</span></span></span><span><span><span>    </span><span>app.kubernetes.io/version</span><span>:</span><span> </span><span>0.48.1</span><span>
+</span></span></span><span><span><span>    </span><span>app.kubernetes.io/managed-by</span><span>:</span><span> </span><span>Helm</span><span>
+</span></span></span><span><span><span>    </span><span>app.kubernetes.io/component</span><span>:</span><span> </span><span>controller</span><span>
+</span></span></span><span><span><span>  </span><span>name</span><span>:</span><span> </span><span>ingress-nginx-controller-v4</span><span>
+</span></span></span><span><span><span>  </span><span>namespace</span><span>:</span><span> </span><span>ingress-nginx</span><span>
+</span></span></span><span><span><span>spec</span><span>:</span><span>
+</span></span></span><span><span><span>  </span><span>type</span><span>:</span><span> </span><span>LoadBalancer</span><span>
+</span></span></span><span><span><span>  </span><span>ipFamilies</span><span>:</span><span>
+</span></span></span><span><span><span>    </span>- <span>IPv4</span><span>
+</span></span></span><span><span><span>  </span><span>ports</span><span>:</span><span>
+</span></span></span><span><span><span>    </span>- <span>name</span><span>:</span><span> </span><span>http</span><span>
+</span></span></span><span><span><span>      </span><span>port</span><span>:</span><span> </span><span>80</span><span>
+</span></span></span><span><span><span>      </span><span>protocol</span><span>:</span><span> </span><span>TCP</span><span>
+</span></span></span><span><span><span>      </span><span>targetPort</span><span>:</span><span> </span><span>http</span><span>
+</span></span></span><span><span><span>    </span>- <span>name</span><span>:</span><span> </span><span>https</span><span>
+</span></span></span><span><span><span>      </span><span>port</span><span>:</span><span> </span><span>443</span><span>
+</span></span></span><span><span><span>      </span><span>protocol</span><span>:</span><span> </span><span>TCP</span><span>
+</span></span></span><span><span><span>      </span><span>targetPort</span><span>:</span><span> </span><span>https</span><span>
+</span></span></span><span><span><span>  </span><span>selector</span><span>:</span><span>
+</span></span></span><span><span><span>    </span><span>app.kubernetes.io/name</span><span>:</span><span> </span><span>ingress-nginx</span><span>
+</span></span></span><span><span><span>    </span><span>app.kubernetes.io/instance</span><span>:</span><span> </span><span>ingress-nginx</span><span>
+</span></span></span><span><span><span>    </span><span>app.kubernetes.io/component</span><span>:</span><span> </span><span>controller</span><span>
+</span></span></span><span><span><span>---</span><span>
+</span></span></span><span><span><span>apiVersion</span><span>:</span><span> </span><span>v1</span><span>
+</span></span></span><span><span><span>kind</span><span>:</span><span> </span><span>Service</span><span>
+</span></span></span><span><span><span>metadata</span><span>:</span><span>
+</span></span></span><span><span><span>  </span><span>annotations</span><span>:</span><span>
+</span></span></span><span><span><span>  </span><span>labels</span><span>:</span><span>
+</span></span></span><span><span><span>    </span><span>helm.sh/chart</span><span>:</span><span> </span><span>ingress-nginx-3.34.0</span><span>
+</span></span></span><span><span><span>    </span><span>app.kubernetes.io/name</span><span>:</span><span> </span><span>ingress-nginx</span><span>
+</span></span></span><span><span><span>    </span><span>app.kubernetes.io/instance</span><span>:</span><span> </span><span>ingress-nginx</span><span>
+</span></span></span><span><span><span>    </span><span>app.kubernetes.io/version</span><span>:</span><span> </span><span>0.48.1</span><span>
+</span></span></span><span><span><span>    </span><span>app.kubernetes.io/managed-by</span><span>:</span><span> </span><span>Helm</span><span>
+</span></span></span><span><span><span>    </span><span>app.kubernetes.io/component</span><span>:</span><span> </span><span>controller</span><span>
+</span></span></span><span><span><span>  </span><span>name</span><span>:</span><span> </span><span>ingress-nginx-controller-v6</span><span>
+</span></span></span><span><span><span>  </span><span>namespace</span><span>:</span><span> </span><span>ingress-nginx</span><span>
+</span></span></span><span><span><span>spec</span><span>:</span><span>
+</span></span></span><span><span><span>  </span><span>type</span><span>:</span><span> </span><span>LoadBalancer</span><span>
+</span></span></span><span><span><span>  </span><span>ipFamilies</span><span>:</span><span>
+</span></span></span><span><span><span>    </span>- <span>IPv6</span><span>
+</span></span></span><span><span><span>  </span><span>ports</span><span>:</span><span>
+</span></span></span><span><span><span>    </span>- <span>name</span><span>:</span><span> </span><span>http</span><span>
+</span></span></span><span><span><span>      </span><span>port</span><span>:</span><span> </span><span>80</span><span>
+</span></span></span><span><span><span>      </span><span>protocol</span><span>:</span><span> </span><span>TCP</span><span>
+</span></span></span><span><span><span>      </span><span>targetPort</span><span>:</span><span> </span><span>http</span><span>
+</span></span></span><span><span><span>    </span>- <span>name</span><span>:</span><span> </span><span>https</span><span>
+</span></span></span><span><span><span>      </span><span>port</span><span>:</span><span> </span><span>443</span><span>
+</span></span></span><span><span><span>      </span><span>protocol</span><span>:</span><span> </span><span>TCP</span><span>
+</span></span></span><span><span><span>      </span><span>targetPort</span><span>:</span><span> </span><span>https</span><span>
+</span></span></span><span><span><span>  </span><span>selector</span><span>:</span><span>
+</span></span></span><span><span><span>    </span><span>app.kubernetes.io/name</span><span>:</span><span> </span><span>ingress-nginx</span><span>
+</span></span></span><span><span><span>    </span><span>app.kubernetes.io/instance</span><span>:</span><span> </span><span>ingress-nginx</span><span>
+</span></span></span><span><span><span>    </span><span>app.kubernetes.io/component</span><span>:</span><span> </span><span>controller</span><span>
+</span></span></span></code></pre></div><p>Note the metadata names with <code>-v4</code> and <code>-v6</code> suffixes, the <code>type: LoadBalancer</code> and the respective ipFamilies. You can now apply this manifest :</p><div><pre tabindex="0"><code data-lang="sh"><span><span>kubectl apply -f ingress-nginx-0.48.1.yaml
+</span></span></code></pre></div><p>Give it some time, then check that the two controller services each get the ipv4 or ipv6 address of your node :</p><div><pre tabindex="0"><code data-lang="sh"><span><span>kubectl -n ingress-nginx get pods,svc
+</span></span><span><span>NAME                                            READY   STATUS      RESTARTS   AGE
+</span></span><span><span>pod/ingress-nginx-admission-create-hcgdm        0/1     Completed   <span>0</span>          52s
+</span></span><span><span>pod/ingress-nginx-admission-patch-hl2vw         0/1     Completed   <span>1</span>          52s
+</span></span><span><span>pod/ingress-nginx-controller-5cb8d9c6dd-5692s   1/1     Running     <span>0</span>          52s
+</span></span><span><span>
+</span></span><span><span>NAME                                         TYPE           CLUSTER-IP      EXTERNAL-IP               PORT<span>(</span>S<span>)</span>                      AGE
+</span></span><span><span>service/ingress-nginx-controller-admission   ClusterIP      10.43.244.41    &lt;none&gt;                    443/TCP                      37s
+</span></span><span><span>service/ingress-nginx-controller-v4          LoadBalancer   10.43.139.251   37.187.244.19             80:31501/TCP,443:32318/TCP   37s
+</span></span><span><span>service/ingress-nginx-controller-v6          LoadBalancer   fd43::2a99      2001:41d0:401:3100::fd5   80:31923/TCP,443:30428/TCP   36s
+</span></span></code></pre></div><h2 id="conclusion">Conclusion</h2><p>Now you can deploy your own services, personally I am going to migrate this blog then my privatebin and miniflux instances and see if it is reliable.</p></div></div>

KaraKeep/attachments/43a375b6-1b59-4572-b713-e125c9963eaa-[SOLVED]-Nvidia-dual-gpu.jpg

@@ -0,0 +1,376 @@
+<div id="readability-page-1" class="page"><div id="punviewtopic">
+
+
+<div id="p2242690">
+	<h2><span><span>#1</span> <a href="https://bbs.archlinux.org/viewtopic.php?pid=2242690#p2242690">2025-05-22 16:26:41</a></span></h2>
+	<div>
+		<div>
+				<div>
+					<dl>
+						<dt><strong>Succulent of your garden</strong></dt>
+						<dd><strong>Member</strong></dd>
+						<dd><img src="https://bbs.archlinux.org/img/avatars/157254.jpg?m=1771340099" width="80" height="80" alt=""></dd>
+						<dd><span>From: Majestic kingdom of pot plants</span></dd>
+						<dd><span>Registered: 2024-02-29</span></dd>
+						<dd><span>Posts: 1,509</span></dd>
+					</dl>
+				</div>
+				<div>
+					<h3>[SOLVED] Nvidia dual gpu stack config question</h3>
+					<div>
+						<p>Hi! </p><p>I'm considering buying a cheap nvidia RTX 5000 series [yes, I know they are not so much better than 4000 series, but I want the 5th generation tensor cores, it's not for gaming it's for work] because I'm starting to do many machine learning stuff with deep learning libraries. But I wan't to have my PC with a dual stack gpu setup, with a pascal based gpu.</p><p>As you can see in the <a href="https://wiki.archlinux.org/title/NVIDIA" rel="nofollow">https://wiki.archlinux.org/title/NVIDIA</a> the packages for the drivers are different for each gpu. </p><p>So first question: Is Arch currently supporting the RTX 5000 series with the nvidia-open and nvidia-open-lts packages ? <br>and the second question: Can i have both gpus running in my system right ? With both packages I'm assuming that the kernel will know what to do with each gpu. I want to have the second one to do gpu pass-through to virtual machines.</p>
+						<p><em>Last edited by Succulent of your garden (2025-05-24 23:40:06)</em></p>
+					</div>
+					<div><hr><p>str( @soyg ) == str( @potplant ) btw!</p><p>Also now with avatar logo included!</p></div>
+				</div>
+			</div>
+		<div>
+				<p><span>Offline</span></p>
+			</div>
+	</div>
+</div>
+
+<div id="p2242694">
+	<h2><span><span>#2</span> <a href="https://bbs.archlinux.org/viewtopic.php?pid=2242694#p2242694">2025-05-22 17:00:25</a></span></h2>
+	<div>
+		<div>
+				<div>
+					<dl>
+						<dt><strong>Xephon</strong></dt>
+						<dd><strong>Member</strong></dd>
+						<dd><span>Registered: 2024-12-22</span></dd>
+						<dd><span>Posts: 189</span></dd>
+					</dl>
+				</div>
+				<div>
+					<h3>Re: [SOLVED] Nvidia dual gpu stack config question</h3>
+					<div>
+						<p>RTX 5000 cards are supported by nvidia-open and nvidia-open-lts.</p><p>No you can't have both Pascal and Blackwell running simultaneously. The former needs nvidia package, the latter - nvidia-open and those are in direct conflict with each other. Meaning that during the installation of one of them pacman will automatically remove the other one.</p>
+					</div>
+				</div>
+			</div>
+		<div>
+				<p><span>Offline</span></p>
+			</div>
+	</div>
+</div>
+
+<div id="p2242699">
+	<h2><span><span>#3</span> <a href="https://bbs.archlinux.org/viewtopic.php?pid=2242699#p2242699">2025-05-22 17:23:48</a></span></h2>
+	<div>
+		<div>
+				<div>
+					<dl>
+						<dt><strong>Succulent of your garden</strong></dt>
+						<dd><strong>Member</strong></dd>
+						<dd><img src="https://bbs.archlinux.org/img/avatars/157254.jpg?m=1771340099" width="80" height="80" alt=""></dd>
+						<dd><span>From: Majestic kingdom of pot plants</span></dd>
+						<dd><span>Registered: 2024-02-29</span></dd>
+						<dd><span>Posts: 1,509</span></dd>
+					</dl>
+				</div>
+				<div>
+					<h3>Re: [SOLVED] Nvidia dual gpu stack config question</h3>
+					<p>But in the worst scenario can I just use the nouveau driver&nbsp; for the pascal based&nbsp; with the blackwell using the nvidia driver ? I mean, the pascal one doesn't have tensor cores either, so I will use it for VM only use.</p>
+					<div><hr><p>str( @soyg ) == str( @potplant ) btw!</p><p>Also now with avatar logo included!</p></div>
+				</div>
+			</div>
+		<div>
+				<p><span>Offline</span></p>
+			</div>
+	</div>
+</div>
+
+<div id="p2242700">
+	<h2><span><span>#4</span> <a href="https://bbs.archlinux.org/viewtopic.php?pid=2242700#p2242700">2025-05-22 17:38:14</a></span></h2>
+	<div>
+		<div>
+				<div>
+					<dl>
+						<dt><strong>Xephon</strong></dt>
+						<dd><strong>Member</strong></dd>
+						<dd><span>Registered: 2024-12-22</span></dd>
+						<dd><span>Posts: 189</span></dd>
+					</dl>
+				</div>
+				<div>
+					<h3>Re: [SOLVED] Nvidia dual gpu stack config question</h3>
+					<div>
+						<p><a href="https://wiki.archlinux.org/title/NVIDIA" rel="nofollow">https://wiki.archlinux.org/title/NVIDIA</a></p><div><blockquote><p>The nvidia-utils package contains a file which blacklists the nouveau module once you reboot</p></blockquote></div><p>You can't have two different nvidia drivers running simultaneously on the same system.</p>
+					</div>
+				</div>
+			</div>
+		<div>
+				<p><span>Offline</span></p>
+			</div>
+	</div>
+</div>
+
+<div id="p2242735">
+	<h2><span><span>#5</span> <a href="https://bbs.archlinux.org/viewtopic.php?pid=2242735#p2242735">2025-05-22 20:37:28</a></span></h2>
+	<div>
+		<div>
+				<div>
+					<dl>
+						<dt><strong>Succulent of your garden</strong></dt>
+						<dd><strong>Member</strong></dd>
+						<dd><img src="https://bbs.archlinux.org/img/avatars/157254.jpg?m=1771340099" width="80" height="80" alt=""></dd>
+						<dd><span>From: Majestic kingdom of pot plants</span></dd>
+						<dd><span>Registered: 2024-02-29</span></dd>
+						<dd><span>Posts: 1,509</span></dd>
+					</dl>
+				</div>
+				<div>
+					<h3>Re: [SOLVED] Nvidia dual gpu stack config question</h3>
+					<div>
+						<p>thanks for the info. So there is no any chance to un-blacklist&nbsp; the nouveau driver so I can get my pascal gpu working together ? </p><p>Why is this the case ? Does the same happen with amd cards ?</p>
+					</div>
+					<div><hr><p>str( @soyg ) == str( @potplant ) btw!</p><p>Also now with avatar logo included!</p></div>
+				</div>
+			</div>
+		<div>
+				<p><span>Offline</span></p>
+			</div>
+	</div>
+</div>
+
+<div id="p2242747">
+	<h2><span><span>#6</span> <a href="https://bbs.archlinux.org/viewtopic.php?pid=2242747#p2242747">2025-05-22 21:28:59</a></span></h2>
+	<div>
+		<div>
+				<div>
+					<dl>
+						<dt><strong>Xephon</strong></dt>
+						<dd><strong>Member</strong></dd>
+						<dd><span>Registered: 2024-12-22</span></dd>
+						<dd><span>Posts: 189</span></dd>
+					</dl>
+				</div>
+				<div>
+					<h3>Re: [SOLVED] Nvidia dual gpu stack config question</h3>
+					<div>
+						<p>Nouveau is blacklisted for a reason. If you un-blacklist it, nouveau will load instead of nvidia-open.</p><p>There is no chance to run two different drivers. Period. Your assumption that the kernel will know what to do with each gpu is not based on reality.</p>
+					</div>
+				</div>
+			</div>
+		<div>
+				<p><span>Offline</span></p>
+			</div>
+	</div>
+</div>
+
+<div id="p2242754">
+	<h2><span><span>#7</span> <a href="https://bbs.archlinux.org/viewtopic.php?pid=2242754#p2242754">2025-05-22 21:56:16</a></span></h2>
+	<div>
+		<div>
+				<div>
+					<dl>
+						<dt><strong>loqs</strong></dt>
+						<dd><strong>Member</strong></dd>
+						<dd><span>Registered: 2014-03-06</span></dd>
+						<dd><span>Posts: 18,860</span></dd>
+					</dl>
+				</div>
+				<div>
+					<h3>Re: [SOLVED] Nvidia dual gpu stack config question</h3>
+					<p>You could pass one of the cards through to a virtual machine to use avoiding having conflicting kernel modules loaded by the same kernel.</p>
+				</div>
+			</div>
+		<div>
+				<p><span>Offline</span></p>
+			</div>
+	</div>
+</div>
+
+<div id="p2242780">
+	<h2><span><span>#8</span> <a href="https://bbs.archlinux.org/viewtopic.php?pid=2242780#p2242780">2025-05-23 06:58:48</a></span></h2>
+	<div>
+		<div>
+				<div>
+					<dl>
+						<dt><strong>seth</strong></dt>
+						<dd><strong>Member</strong></dd>
+						<dd><img src="https://bbs.archlinux.org/img/avatars/63451.png?m=1751375556" width="80" height="80" alt=""></dd>
+						<dd><span>From: Don't DM me only for attention</span></dd>
+						<dd><span>Registered: 2012-09-03</span></dd>
+						<dd><span>Posts: 74,630</span></dd>
+					</dl>
+				</div>
+				<div>
+					<h3>Re: [SOLVED] Nvidia dual gpu stack config question</h3>
+					<div>
+						<p>Also </p><div><p><cite>The OP wrote:</cite></p><blockquote><p>I want to have the second one to do gpu pass-through to virtual machines.</p></blockquote></div><p>What makes the entire thread moot.</p>
+					</div>
+					
+				</div>
+			</div>
+		<div>
+				<p><strong>Online</strong></p>
+			</div>
+	</div>
+</div>
+
+<div id="p2242864">
+	<h2><span><span>#9</span> <a href="https://bbs.archlinux.org/viewtopic.php?pid=2242864#p2242864">2025-05-23 16:05:24</a></span></h2>
+	<div>
+		<div>
+				<div>
+					<dl>
+						<dt><strong>Succulent of your garden</strong></dt>
+						<dd><strong>Member</strong></dd>
+						<dd><img src="https://bbs.archlinux.org/img/avatars/157254.jpg?m=1771340099" width="80" height="80" alt=""></dd>
+						<dd><span>From: Majestic kingdom of pot plants</span></dd>
+						<dd><span>Registered: 2024-02-29</span></dd>
+						<dd><span>Posts: 1,509</span></dd>
+					</dl>
+				</div>
+				<div>
+					<h3>Re: [SOLVED] Nvidia dual gpu stack config question</h3>
+					<div>
+						<p>Okey. Let summarize everything:</p><p>1) Currently I'm having amd + nvidia stack in the same PC. I made programs that run in the same OS and environment using each one of the gpus, and both at the same time, with or without the use of ROCm and CUDA in parallel. So for that reason I believe that in practice the kernel can handle more than one driver for a gpu. So this is an issue only with nividia or when&nbsp; you are running a stack with all the cards from the same manufacture but one card is much older than the new one ?. So the first question is: If I have a old Radeon card and make a setup with a newer one (The complete opposite of what I'm trying to do) this will work ? This question is made in mind using the context without the virtual machines, just os being capable of using both gpus at the same time, in this case a very old Radeon with a newer&nbsp; one. Does the same happen ? </p><p>2) So it is possible that I can use my pascal nvidia gpu in the virtual machine ? I mean I can create a VFIO passthrough&nbsp; and put the driver in the vm right ? I'm seeing this setup like this: </p><p>2.1) Host OS: Okey, when the user uses lspci I can see there is second nvidia card, but I can't use it, since I don't have a driver for that.<br>2.2) VM: Oh I have a gpu and the driver, since the user is giving me access to the pci directly since I have the IOMMU nice. </p><p>Is this scenario possible with the Blackwell architecture as primary gpu right ? If that's the case: Does the Blackwell gpu could have issues in rendering the video output of the pascal base gpu in my virtual machine ? Since the hdmi or displayport cable of the screen will be connected to the blackwell only. If I'm not remembering wrong, the amd gpus are more friendly&nbsp; to the VFIO passtrhough when they are the host gpu, and the nvidia are great for sending the gpu to the vm. But does anyone have tried a setup like what I maybe going to do ?</p>
+						<p><em>Last edited by Succulent of your garden (2025-05-23 16:08:25)</em></p>
+					</div>
+					<div><hr><p>str( @soyg ) == str( @potplant ) btw!</p><p>Also now with avatar logo included!</p></div>
+				</div>
+			</div>
+		<div>
+				<p><span>Offline</span></p>
+			</div>
+	</div>
+</div>
+
+<div id="p2242882">
+	<h2><span><span>#10</span> <a href="https://bbs.archlinux.org/viewtopic.php?pid=2242882#p2242882">2025-05-23 18:44:10</a></span></h2>
+	<div>
+		<div>
+				<div>
+					<dl>
+						<dt><strong>Xephon</strong></dt>
+						<dd><strong>Member</strong></dd>
+						<dd><span>Registered: 2024-12-22</span></dd>
+						<dd><span>Posts: 189</span></dd>
+					</dl>
+				</div>
+				<div>
+					<h3>Re: [SOLVED] Nvidia dual gpu stack config question</h3>
+					<div>
+						<p>1) </p><div><blockquote><p>So this is an issue only with nividia or when&nbsp; you are running a stack with all the cards from the same manufacture but one card is much older than the new one ?</p></blockquote></div><p>It's an issue when you are running a stack containing some cards from the same manufacturer that require <strong>different drivers</strong> and those drivers are <strong>in conflict with each other</strong>. It doesn't happen with AMD cards: amdgpu and radeon kernel modules are not in conflict and can be used together. Moreover amdgpu supports pretty old cards, so you might not even need radeon driver.</p><p>2) You definitely can use Pascal in VM (two different drivers in two separate systems). But using the same monitor for both host and VM could be tricky. Might need something like <a href="https://looking-glass.io/" rel="nofollow">https://looking-glass.io/</a></p>
+					</div>
+				</div>
+			</div>
+		<div>
+				<p><span>Offline</span></p>
+			</div>
+	</div>
+</div>
+
+<div id="p2242887">
+	<h2><span><span>#11</span> <a href="https://bbs.archlinux.org/viewtopic.php?pid=2242887#p2242887">2025-05-23 19:21:37</a></span></h2>
+	<div>
+		<div>
+				<div>
+					<dl>
+						<dt><strong>seth</strong></dt>
+						<dd><strong>Member</strong></dd>
+						<dd><img src="https://bbs.archlinux.org/img/avatars/63451.png?m=1751375556" width="80" height="80" alt=""></dd>
+						<dd><span>From: Don't DM me only for attention</span></dd>
+						<dd><span>Registered: 2012-09-03</span></dd>
+						<dd><span>Posts: 74,630</span></dd>
+					</dl>
+				</div>
+				<div>
+					<h3>Re: [SOLVED] Nvidia dual gpu stack config question</h3>
+					<div>
+						<p>Does the monitor have multiple inputs and the ability to switch between them?</p><p>The moment you add the gpu to vfio the host OS does no longer see it and whatever renders the output inside the VM, the host doesn't care. It renders whatever the VM gives it.<br>Don't overcomplicate this, vfio forwarding is covered extensively in the wiki.</p>
+					</div>
+					
+				</div>
+			</div>
+		<div>
+				<p><strong>Online</strong></p>
+			</div>
+	</div>
+</div>
+
+<div id="p2242993">
+	<h2><span><span>#12</span> <a href="https://bbs.archlinux.org/viewtopic.php?pid=2242993#p2242993">2025-05-24 15:00:40</a></span></h2>
+	<div>
+		<div>
+				<div>
+					<dl>
+						<dt><strong>Succulent of your garden</strong></dt>
+						<dd><strong>Member</strong></dd>
+						<dd><img src="https://bbs.archlinux.org/img/avatars/157254.jpg?m=1771340099" width="80" height="80" alt=""></dd>
+						<dd><span>From: Majestic kingdom of pot plants</span></dd>
+						<dd><span>Registered: 2024-02-29</span></dd>
+						<dd><span>Posts: 1,509</span></dd>
+					</dl>
+				</div>
+				<div>
+					<h3>Re: [SOLVED] Nvidia dual gpu stack config question</h3>
+					<div>
+						<p>many thanks both of you in your answers. I'm going to use looking glass, but as I know the nvidia host gpu is not recomended by the following reasons: </p><div><blockquote><div><p>AMD or Intel for the client<br>AMD and Intel both support the DMABUF feature which enables offloading memory transfers to the GPU hardware. Please note that making use of this feature requires loading the KVMFR kernel module.</p><p>Additionally AMD GPUs suffer stability issues when operating as a passthrough device and as such we do not recommend their usage for such purposes. Models of note that have issues include but are not limited to the entire Polaris, Vega, Navi and BigNavi GPU series. Vega and Navi are notably the worst and should be avoided for virtualization usage.</p><p>NVIDIA for the guest<br>NVIDIA unlike AMD do not seem to suffer from the same stability issues as AMD GPUs when operating as a passthrough GPU, however due to the closed source nature of their drivers NVIDIA can not make use of the DMABUF feature in the Linux kernel unless you use the open source NVIDIA drivers.</p></div></blockquote></div><p>source: <a href="https://looking-glass.io/docs/B7/requirements/" rel="nofollow">https://looking-glass.io/docs/B7/requirements/</a></p><p>But as far as I know the Blackwell architecture is currently having the drivers open source right ?&nbsp; Not sure if the DMABUF is needed also for the pascal gpu, since the drivers are closed source. As I'm seeing it right now, if I get the blackwell based gpu I could use looking glass without any problems. </p><p>What do you think about this ? Does any one have tried something like this ? maybe not with blackwell gpu but with two nvidia gpu stack.</p><p>EDIT: My monitor does have multiple inputs and is possible to switch between them.</p>
+						<p><em>Last edited by Succulent of your garden (2025-05-24 15:27:56)</em></p>
+					</div>
+					<div><hr><p>str( @soyg ) == str( @potplant ) btw!</p><p>Also now with avatar logo included!</p></div>
+				</div>
+			</div>
+		<div>
+				<p><span>Offline</span></p>
+			</div>
+	</div>
+</div>
+
+<div id="p2243013">
+	<h2><span><span>#13</span> <a href="https://bbs.archlinux.org/viewtopic.php?pid=2243013#p2243013">2025-05-24 17:15:05</a></span></h2>
+	<div>
+		<div>
+				<div>
+					<dl>
+						<dt><strong>Xephon</strong></dt>
+						<dd><strong>Member</strong></dd>
+						<dd><span>Registered: 2024-12-22</span></dd>
+						<dd><span>Posts: 189</span></dd>
+					</dl>
+				</div>
+				<div>
+					<h3>Re: [SOLVED] Nvidia dual gpu stack config question</h3>
+					<div>
+						<p>No one can guarantee that you won't have any problems, but it looks like you're gonna be fine.</p><p>Looking Glass developers confirm that nvidia-open allows to use foreign DMABUF objects. Should be no problems using Blackwell for the host.<br><a href="https://github.com/NVIDIA/open-gpu-kernel-modules/discussions/243#discussioncomment-11022142" rel="nofollow">https://github.com/NVIDIA/open-gpu-kern … t-11022142</a></p><p>And Pascal in VM won't need DMABUF support capabilities</p>
+					</div>
+				</div>
+			</div>
+		<div>
+				<p><span>Offline</span></p>
+			</div>
+	</div>
+</div>
+
+<div id="p2243056">
+	<h2><span><span>#14</span> <a href="https://bbs.archlinux.org/viewtopic.php?pid=2243056#p2243056">2025-05-24 23:39:43</a></span></h2>
+	<div>
+		<div>
+				<div>
+					<dl>
+						<dt><strong>Succulent of your garden</strong></dt>
+						<dd><strong>Member</strong></dd>
+						<dd><img src="https://bbs.archlinux.org/img/avatars/157254.jpg?m=1771340099" width="80" height="80" alt=""></dd>
+						<dd><span>From: Majestic kingdom of pot plants</span></dd>
+						<dd><span>Registered: 2024-02-29</span></dd>
+						<dd><span>Posts: 1,509</span></dd>
+					</dl>
+				</div>
+				<div>
+					<h3>Re: [SOLVED] Nvidia dual gpu stack config question</h3>
+					<p>Thanks very much for your help Xephon, and also for the info by Seth.&nbsp; Really appreciated <img src="https://bbs.archlinux.org/img/smilies/smile.png" width="15" height="15" alt="smile"></p>
+					<div><hr><p>str( @soyg ) == str( @potplant ) btw!</p><p>Also now with avatar logo included!</p></div>
+				</div>
+			</div>
+		<div>
+				<p><span>Offline</span></p>
+			</div>
+	</div>
+</div>
+
+
+</div></div>

KaraKeep/attachments/68f59c48-9625-4f07-9e08-d2cd2577e253-Multi-seat-support-·-Wiki-·.jpg

@@ -0,0 +1,172 @@
+<div id="readability-page-1" class="page">
+
+
+
+
+
+<header tabindex="0"><a href="#content-body" data-testid="super-topbar-skip-to">   <span>
+    Skip to main content
+   </span></a>    </header>
+<div id="static-panel-portal">
+<main id="content-body">
+
+
+
+
+
+
+
+
+
+
+<div>  <div><header><div><h2 data-testid="page-heading"> <span>Multi seat support</span> </h2> </div> </header></div> <div data-testid="wiki-page-content"><h2 id="user-content-multi-seat-confiuration" data-sourcepos="1:1-1:26" dir="auto">Multi-seat Confiuration<a href="#multi-seat-confiuration" aria-label="Link to heading 'Multi-seat Confiuration'" data-heading-content="Multi-seat Confiuration"></a></h2>
+<p data-sourcepos="3:1-3:259" dir="auto">ACS supports limited multi-seat config to allow individual set of input subsystem devices for each of the connect GPU. This support is mostly desired in Automotive/Infotainment subsystems where the screens can be used as different panels or different usages.</p>
+<h2 id="user-content-setup" data-sourcepos="5:1-5:8" dir="auto">Setup<a href="#setup" aria-label="Link to heading 'Setup'" data-heading-content="Setup"></a></h2>
+<h4 id="user-content-hw-requirements-validated-only-on-amdgpu-setup" data-sourcepos="7:1-7:57" dir="auto"><strong data-sourcepos="7:6-7:57">HW Requirements (validated only on AMDGPU setup)</strong><a href="#hw-requirements-validated-only-on-amdgpu-setup" aria-label="Link to heading 'HW Requirements (validated only on AMDGPU setup)'" data-heading-content="HW Requirements (validated only on AMDGPU setup)"></a></h4>
+<ol data-sourcepos="9:1-12:141" dir="auto">
+<li data-sourcepos="9:1-9:20">APU + DGPU setup.</li>
+<li data-sourcepos="10:1-10:63">Card0 and Card1 should be enumerated under /dev/dri/ folder.</li>
+<li data-sourcepos="11:1-11:85">Each APU and dGPU should be connected with individual monitor, mouse and keyboard.</li>
+<li data-sourcepos="12:1-13:0">Connect extra pair of keyboard and mouse which could be easily distinguished (different vendor or product id) with already connected pair.</li>
+</ol>
+<h4 id="user-content-one-time-setup" data-sourcepos="14:1-14:23" dir="auto"><strong data-sourcepos="14:6-14:23">One Time Setup</strong><a href="#one-time-setup" aria-label="Link to heading 'One Time Setup'" data-heading-content="One Time Setup"></a></h4>
+<p data-sourcepos="16:1-16:11" dir="auto"><strong data-sourcepos="16:1-16:11">Step 1:</strong></p>
+<p data-sourcepos="18:1-18:99" dir="auto">To make multi-seat setup, make sure to comment the "additional-devices=card1" config in weston.ini.</p>
+<p data-sourcepos="20:1-20:80" dir="auto"><a href="https://gitlab.com/acs-wayland/weston/-/wikis/uploads/eebd7f8c68244782d9095ef1d9fe56be/additional_card.jpg" rel="noopener noreferrer" data-canonical-src="uploads/eebd7f8c68244782d9095ef1d9fe56be/additional_card.jpg" role="button" aria-label="View image" aria-haspopup="dialog"><img data-sourcepos="20:1-20:80" alt="additional_card" decoding="async" data-canonical-src="uploads/eebd7f8c68244782d9095ef1d9fe56be/additional_card.jpg" loading="lazy" src="https://gitlab.com/acs-wayland/weston/-/wikis/home/ACS-Features/uploads/eebd7f8c68244782d9095ef1d9fe56be/additional_card.jpg" data-testid="js-lazy-loaded-content"></a></p>
+<p data-sourcepos="22:1-22:49" dir="auto"><strong data-sourcepos="22:1-22:49">Step 2: Create udev rule to create a new seat</strong></p>
+<ul data-sourcepos="24:1-24:97" dir="auto">
+<li data-sourcepos="24:1-25:0">Create a new udev rules file under /etc/udev/rules.d/ by following the below naming convention.</li>
+</ul>
+<div><pre data-sourcepos="26:1-28:3" id="code-42"><code><span id="LC1" lang="plaintext">&lt;priority&gt;-&lt;device name&gt;.rules</span></code></pre></div>
+<ul data-sourcepos="30:1-34:99" dir="auto">
+<li data-sourcepos="30:1-35:0">
+<p data-sourcepos="30:3-30:211">In the above naming convention, priority number determines the order of rule execution. Lesser the number, the higher the priority. So, use the priority number less than existing rules under /etc/udev/rules.d/</p>
+<p data-sourcepos="32:3-32:86">Ex: New rule 69-graphics-seat.rules in the below figure is created with priority 69.</p>
+<p data-sourcepos="34:3-34:99">Copy the below contents into 69-graphics-multseat.rules and update the parameters from next step.</p>
+</li>
+</ul>
+<div><pre data-sourcepos="36:1-45:3" id="code-43"><code><span id="LC1" lang="plaintext">SUBSYSTEM=="drm", KERNEL=="card1", KERNELS=="0000:c7:00.0", TAG+="master-of-seat", </span>
+<span id="LC2" lang="plaintext">ENV{ID_SEAT}="seat1"</span>
+<span id="LC3" lang="plaintext">SUBSYSTEM=="drm", KERNEL=="renderD129", KERNELS=="0000:c7:00.0", ENV{ID_SEAT}="seat1"</span>
+<span id="LC4" lang="plaintext">SUBSYSTEM=="graphics", KERNEL=="fb1", KERNELS=="0000:c7:00.0", ENV{ID_SEAT}="seat1"</span>
+<span id="LC5" lang="plaintext">SUBSYSTEM=="input", ATTRS{devnum}=="9", ATTRS{idVendor}=="1bcf", ATTRS{idProduct}=="08a0", </span>
+<span id="LC6" lang="plaintext">OWNER="acs2", ENV{ID_SEAT}="seat1"</span>
+<span id="LC7" lang="plaintext">SUBSYSTEM=="input", ATTRS{devnum}=="4", ATTRS{idVendor}=="1a2c", ATTRS{idProduct}=="4c5e", </span>
+<span id="LC8" lang="plaintext">OWNER="acs2", ENV{ID_SEAT}="seat1"</span></code></pre></div>
+<ul data-sourcepos="47:1-51:175" dir="auto">
+<li data-sourcepos="47:1-47:64">First 3 lines in above udev script will assign card1 to seat1.</li>
+<li data-sourcepos="48:1-48:64">Last 2 lines will assign specific keyboard and mouse to seat1.</li>
+<li data-sourcepos="49:1-49:79">By default, system will always have CARD0 assigned to DGPU, and CARD1 to APU.</li>
+<li data-sourcepos="50:1-50:128">In above example, update keys like KERNELS, idVendor etc. with the system specific parameters and OWNER with system user-name.</li>
+<li data-sourcepos="51:1-52:0">To get the details of KERNELS of card1, idVendor, idProduct of Keyboard and Mouse connected to the system, run the devices.sh script present under "/share/weston/devices.sh"</li>
+</ul>
+<div><pre data-sourcepos="53:1-56:3" id="code-44"><code><span id="LC1" lang="plaintext">$ sudo chmod 777 &lt;path&gt;/share/weston/devices.sh</span>
+<span id="LC2" lang="plaintext">$ cd &lt;path&gt;/share/weston &amp;&amp; ./devices.sh</span></code></pre></div>
+<div><pre data-sourcepos="58:1-88:3" id="code-45"><code><span id="LC1" lang="plaintext">Sample output of devices.sh script</span>
+<span id="LC2" lang="plaintext"></span>
+<span id="LC3" lang="plaintext">--------------Card1 details-------------------</span>
+<span id="LC4" lang="plaintext"></span>
+<span id="LC5" lang="plaintext">/dev/dri/card1 value of KERNELS: 0000:c7:00.0</span>
+<span id="LC6" lang="plaintext">fb1 value of KERNELS: 0000:c7:00.0</span>
+<span id="LC7" lang="plaintext">render not value of KERNELS: 0000:c7:00.0</span>
+<span id="LC8" lang="plaintext"></span>
+<span id="LC9" lang="plaintext">---------------Mouses connected-----------------</span>
+<span id="LC10" lang="plaintext">Mouse 1:</span>
+<span id="LC11" lang="plaintext">Vendor ID: 1bcf</span>
+<span id="LC12" lang="plaintext">Product ID: 08a0</span>
+<span id="LC13" lang="plaintext">Device No: 009</span>
+<span id="LC14" lang="plaintext"></span>
+<span id="LC15" lang="plaintext">Mouse 2:</span>
+<span id="LC16" lang="plaintext">Vendor ID: 1bcf</span>
+<span id="LC17" lang="plaintext">Product ID: 08a0</span>
+<span id="LC18" lang="plaintext">Device No: 008</span>
+<span id="LC19" lang="plaintext"></span>
+<span id="LC20" lang="plaintext">---------------Keyboards connected-----------------</span>
+<span id="LC21" lang="plaintext">Keyboard 1:</span>
+<span id="LC22" lang="plaintext">Vendor ID: 1a2c</span>
+<span id="LC23" lang="plaintext">Product ID: 4c5e</span>
+<span id="LC24" lang="plaintext">Device No: 004</span>
+<span id="LC25" lang="plaintext"></span>
+<span id="LC26" lang="plaintext">Keyboard 2:</span>
+<span id="LC27" lang="plaintext">Vendor ID: 1a2c</span>
+<span id="LC28" lang="plaintext">Product ID: 4c5e</span>
+<span id="LC29" lang="plaintext">Device No: 002</span></code></pre></div>
+<ul data-sourcepos="90:1-93:82" dir="auto">
+<li data-sourcepos="90:1-90:116">Update the KERNELS param in rule file for card1, fb1 and renderD129 entries based on output from device.sh script.</li>
+<li data-sourcepos="91:1-91:134">Select the keyboard and mouse based on information from device.sh and update the idVendor and idProduct, devnum params in rule file.</li>
+<li data-sourcepos="92:1-92:102">ATTR{devnum} value can change on reboot so, we need to check this value used in rule on each reboot.</li>
+<li data-sourcepos="93:1-94:0">When there is a change update the rule and run below command to reload new rule.</li>
+</ul>
+<div><pre data-sourcepos="95:1-101:3" id="code-46"><code><span id="LC1" lang="plaintext">Reload udev rules:</span>
+<span id="LC2" lang="plaintext">$ sudo udevadm control --reload-rules</span>
+<span id="LC3" lang="plaintext"></span>
+<span id="LC4" lang="plaintext">Trigger udev to apply the new rules:</span>
+<span id="LC5" lang="plaintext">$ sudo udevadm trigger</span></code></pre></div>
+<p data-sourcepos="103:1-103:31" dir="auto"><strong data-sourcepos="103:1-103:31">Step 3 : Copy service files</strong></p>
+<ol data-sourcepos="105:1-105:138" dir="auto">
+<li data-sourcepos="105:1-106:0">Execute the below commands to copy the multi-seat related service files present under /opt/amdgpu/share/weston to respective locations.</li>
+</ol>
+<div><pre data-sourcepos="107:1-112:3" id="code-47"><code><span id="LC1" lang="plaintext">$ sudo cp &lt;path&gt;/share/weston/mysession.service /etc/systemd/system</span>
+<span id="LC2" lang="plaintext">$ sudo cp &lt;path&gt;/share/weston/mysession.target /etc/systemd/user</span>
+<span id="LC3" lang="plaintext">$ sudo cp &lt;path&gt;/share/weston/weston.service /etc/systemd/user</span>
+<span id="LC4" lang="plaintext">$ sudo cp &lt;path&gt;/share/weston/weston.socket /etc/systemd/user</span></code></pre></div>
+<ol data-sourcepos="114:1-114:115" start="2" dir="auto">
+<li data-sourcepos="114:1-114:115">Edit /etc/systemd/system/mysession.service file as shown below and update User and Group with system's username.</li>
+</ol>
+<p data-sourcepos="116:1-116:98" dir="auto"><a href="https://gitlab.com/acs-wayland/weston/-/wikis/uploads/68e29faae4da7c0a964e96ad4c5d54a7/image-2024-7-10_17-16-33.png" rel="noopener noreferrer" data-canonical-src="uploads/68e29faae4da7c0a964e96ad4c5d54a7/image-2024-7-10_17-16-33.png" role="button" aria-label="View image" aria-haspopup="dialog"><img data-sourcepos="116:1-116:98" alt="image-2024-7-10_17-16-33" decoding="async" data-canonical-src="uploads/68e29faae4da7c0a964e96ad4c5d54a7/image-2024-7-10_17-16-33.png" loading="lazy" src="https://gitlab.com/acs-wayland/weston/-/wikis/home/ACS-Features/uploads/68e29faae4da7c0a964e96ad4c5d54a7/image-2024-7-10_17-16-33.png" data-testid="js-lazy-loaded-content"></a></p>
+<ol data-sourcepos="118:1-118:88" start="3" dir="auto">
+<li data-sourcepos="118:1-118:88">Edit /etc/systemd/user/weston.service file and update the config file path if needed.</li>
+</ol>
+<p data-sourcepos="120:1-120:96" dir="auto"><a href="https://gitlab.com/acs-wayland/weston/-/wikis/uploads/de9d65a75cb6db166b9f2d4ac59401b3/image-2024-7-10_17-23-6.png" rel="noopener noreferrer" data-canonical-src="uploads/de9d65a75cb6db166b9f2d4ac59401b3/image-2024-7-10_17-23-6.png" role="button" aria-label="View image" aria-haspopup="dialog"><img data-sourcepos="120:1-120:96" alt="image-2024-7-10_17-23-6" decoding="async" data-canonical-src="uploads/de9d65a75cb6db166b9f2d4ac59401b3/image-2024-7-10_17-23-6.png" loading="lazy" src="https://gitlab.com/acs-wayland/weston/-/wikis/home/ACS-Features/uploads/de9d65a75cb6db166b9f2d4ac59401b3/image-2024-7-10_17-23-6.png" data-testid="js-lazy-loaded-content"></a></p>
+<ol data-sourcepos="122:1-122:43" start="4" dir="auto">
+<li data-sourcepos="122:1-123:0">Run the below commands to reload systemd</li>
+</ol>
+<div><pre data-sourcepos="124:1-127:3" id="code-48"><code><span id="LC1" lang="plaintext">$ systemctl daemon-reload</span>
+<span id="LC2" lang="plaintext">$ systemctl --user daemon-reload</span></code></pre></div>
+<p data-sourcepos="129:1-129:24" dir="auto"><strong data-sourcepos="129:1-129:24">Step 4 : Disable GDM</strong></p>
+<ol data-sourcepos="131:1-131:74" dir="auto">
+<li data-sourcepos="131:1-132:0">Execute the below commands to disable GDM which internally disables GUI</li>
+</ol>
+<div><pre data-sourcepos="133:1-136:3" id="code-49"><code><span id="LC1" lang="plaintext">$ sudo systemctl disable gdm3</span>
+<span id="LC2" lang="plaintext">$ sudo reboot</span></code></pre></div>
+<ol data-sourcepos="138:1-138:88" start="2" dir="auto">
+<li data-sourcepos="138:1-138:88">After system is rebooted, TTY terminal will appear for login. Login with credentials.</li>
+</ol>
+<p data-sourcepos="140:1-140:120" dir="auto">With this, One Time Setup for Multi-Seat is completed. These steps are not required unless Multi-Seat setup is disabled.</p>
+<h2 id="user-content-launching-acs-on-multi-seat" data-sourcepos="142:1-142:34" dir="auto"><strong data-sourcepos="142:4-142:34">Launching ACS on Multi-Seat</strong><a href="#launching-acs-on-multi-seat" aria-label="Link to heading 'Launching ACS on Multi-Seat'" data-heading-content="Launching ACS on Multi-Seat"></a></h2>
+<ol data-sourcepos="144:1-144:219" dir="auto">
+<li data-sourcepos="144:1-145:0">Run the below command to list the seats connected to the system. In the case of multi-seat, it should list seat0 and seat1. If not, onetime setup is not done properly, please check the steps again for One Time Setup.</li>
+</ol>
+<div><pre data-sourcepos="146:1-148:3" id="code-50"><code><span id="LC1" lang="plaintext">$ loginctl list-seats</span></code></pre></div>
+<ol data-sourcepos="150:1-150:146" start="2" dir="auto">
+<li data-sourcepos="150:1-151:0">Run script device.sh and verify the device number returned from script is same as used in udev rule, if not udpate the rule and reload the rule</li>
+</ol>
+<div><pre data-sourcepos="152:1-158:3" id="code-51"><code><span id="LC1" lang="plaintext">Reload udev rules:</span>
+<span id="LC2" lang="plaintext">$ sudo udevadm control --reload-rules</span>
+<span id="LC3" lang="plaintext"></span>
+<span id="LC4" lang="plaintext">Trigger udev to apply the new rules:</span>
+<span id="LC5" lang="plaintext">$ sudo udevadm trigger</span></code></pre></div>
+<ol data-sourcepos="160:1-163:108" start="3" dir="auto">
+<li data-sourcepos="160:1-160:103">Edit /share/weston/multi-seat-setup.sh file to update the user-name and seat name as per the system.</li>
+<li data-sourcepos="161:1-161:94">Optional : update the config file path in multi-seat-setup.sh with custom config file path.</li>
+<li data-sourcepos="162:1-162:164">Execute /share/weston/multi-seat-setup.sh script file from target machine TTY terminal. [Note: This script shall not be executed from remote machine terminal.]</li>
+<li data-sourcepos="163:1-164:0">Result - ACS desktop should appear on both the monitors each controllable with set of keyboard and mouse.</li>
+</ol>
+<h2 id="user-content-disable-multi-seat-setup" data-sourcepos="165:1-165:31" dir="auto"><strong data-sourcepos="165:4-165:31">Disable Multi-Seat setup</strong><a href="#disable-multi-seat-setup" aria-label="Link to heading 'Disable Multi-Seat setup'" data-heading-content="Disable Multi-Seat setup"></a></h2>
+<ol data-sourcepos="167:1-169:14" dir="auto">
+<li data-sourcepos="167:1-167:61">Move or delete the rule file created in /etc/udev/rules.d/</li>
+<li data-sourcepos="168:1-168:54">Enable GDM - systemctl set-default graphical.target</li>
+<li data-sourcepos="169:1-169:14">sudo reboot</li>
+</ol></div> </div>
+
+</main>
+</div>
+
+
+
+
+
+
+
+
+</div>

KaraKeep/attachments/9a9b353a-8157-4a4d-83fb-110aacca7bc3-dm-crypt-Encrypting-an-entire.jpg

@@ -0,0 +1,951 @@
+<div id="readability-page-1" class="page"><div lang="en" dir="ltr" id="mw-content-text"><p><span>
+</span>
+The following are examples of common scenarios of full system encryption with <i>dm-crypt</i>. They explain all the adaptations that need to be done to the normal <a href="https://wiki.archlinux.org/title/Installation_guide" title="Installation guide">installation procedure</a>. All the necessary tools are on the <a rel="nofollow" href="https://archlinux.org/download/">installation image</a>.
+</p><p>If you want to encrypt an existing unencrypted file system, see <a href="https://wiki.archlinux.org/title/Dm-crypt/Device_encryption#Encrypt_an_existing_unencrypted_file_system" title="Dm-crypt/Device encryption">dm-crypt/Device encryption#Encrypt an existing unencrypted file system</a>.
+</p>
+
+<p></p><h2 id="Overview">Overview</h2><p></p>
+<p>Securing a root file system is where <i>dm-crypt</i> excels, feature and performance-wise. Unlike selectively encrypting non-root file systems, an encrypted root file system can conceal information such as which programs are installed, the usernames of all user accounts, and common data-leakage vectors such as <a href="https://wiki.archlinux.org/title/Locate" title="Locate">locate</a> and <code>/var/log/</code>. Furthermore, an encrypted root file system makes tampering with the system far more difficult, as everything except the <a href="https://wiki.archlinux.org/title/Boot_loader" title="Boot loader">boot loader</a> and (usually) the kernel is encrypted.
+</p><p>All scenarios illustrated in the following share these advantages, other pros and cons differentiating them are summarized below:
+</p>
+<table>
+<tbody><tr>
+<th>Scenarios
+</th>
+<th>Advantages
+</th>
+<th>Disadvantages
+</th></tr>
+<tr>
+<td><a href="#LUKS_on_a_partition">#LUKS on a partition</a>
+<p>shows a basic and straightforward set-up for a fully LUKS encrypted root.
+</p>
+</td>
+<td>
+<ul><li>Simple partitioning and setup</li>
+<li>On a GPT partitioned disk, <a href="https://wiki.archlinux.org/title/Systemd#GPT_partition_automounting" title="Systemd">systemd can auto-mount</a> the root partition.</li></ul>
+</td>
+<td>
+<ul><li>Inflexible; disk-space to be encrypted has to be pre-allocated</li></ul>
+</td></tr>
+<tr>
+<td><a href="#LUKS_on_a_partition_with_TPM2_and_Secure_Boot">#LUKS on a partition with TPM2 and Secure Boot</a>
+<p>Similar to the example above, with Secure Boot and TPM2 providing additional layers of security.
+</p>
+</td>
+<td>
+<p>Same advantages as above, and
+</p>
+<ul><li>Secure Boot allows protection against <a href="https://en.wikipedia.org/wiki/Evil_maid_attack" title="wikipedia:Evil maid attack">Evil maid attacks</a></li>
+<li>TPM2 prevents the system from being unlocked if Secure Boot is disabled or modified</li></ul>
+</td>
+<td>
+<ul><li>Same disadvantages as above.</li></ul>
+</td></tr>
+<tr>
+<td><a href="#LVM_on_LUKS">#LVM on LUKS</a>
+<p>achieves partitioning flexibility by using LVM inside a single LUKS encrypted partition.
+</p>
+</td>
+<td>
+<ul><li>Simple partitioning with knowledge of LVM</li>
+<li>Only one key required to unlock all volumes (e.g. easy resume-from-disk setup)</li>
+<li>Volume layout not visible when locked</li>
+<li>Easiest method to allow <a href="https://wiki.archlinux.org/title/Dm-crypt/Swap_encryption#With_suspend-to-disk_support" title="Dm-crypt/Swap encryption">suspension to disk</a></li></ul>
+</td>
+<td>
+<ul><li>LVM adds an additional mapping layer and hook</li>
+<li>Less useful, if a singular volume should receive a separate key</li>
+<li>If you have several LVM physical volumes (PVs) in a volume group that you want to use inside LUKS, then each physical volume must be encrypted separately using LUKS. In order to use them, all containers must be unlocked individually before the volume group is activated during system boot.</li></ul>
+</td></tr>
+<tr>
+<td><a href="#LUKS_on_LVM">#LUKS on LVM</a>
+<p>uses dm-crypt only after the LVM is setup.
+</p>
+</td>
+<td>
+<ul><li>LVM can be used to have encrypted volumes span multiple disks</li>
+<li>Easy mix of un-/encrypted volume groups</li></ul>
+</td>
+<td>
+<ul><li>Complex; changing volumes requires changing encryption mappers too</li>
+<li>Volumes require individual keys</li>
+<li>LVM layout is visible when locked</li>
+<li>Slower boot time; each encrypted LV must be unlocked seperately</li></ul>
+</td></tr>
+<tr>
+<td><a href="#LUKS_on_software_RAID">#LUKS on software RAID</a>
+<p>uses dm-crypt only after RAID is setup.
+</p>
+</td>
+<td>
+<ul><li>Analogous to LUKS on LVM</li></ul>
+</td>
+<td>
+<ul><li>Analogous to LUKS on LVM and Encrypted boot partition (GRUB)</li></ul>
+</td></tr>
+<tr>
+<td><a href="#Plain_dm-crypt">#Plain dm-crypt</a>
+<p>uses dm-crypt plain mode, i.e. without a LUKS header and its options for multiple keys.
+</p><p>This scenario also employs USB devices for <code>/boot</code> and key storage, which may be applied to the other scenarios.
+</p>
+</td>
+<td>
+<ul><li>Data resilience for cases where a LUKS header may be damaged</li>
+<li>Allows <a href="https://en.wikipedia.org/wiki/Deniable_encryption" title="wikipedia:Deniable encryption">deniable encryption</a></li>
+<li>Helps addressing <a href="https://wiki.archlinux.org/title/Dm-crypt/Specialties#Discard/TRIM_support_for_solid_state_drives_(SSD)" title="Dm-crypt/Specialties">problems</a> with SSDs</li></ul>
+</td>
+<td>
+<ul><li>High care to all encryption parameters is required</li>
+<li>Single encryption key and no option to change it</li>
+<li>Very complicated setup for a regular used system</li></ul>
+</td></tr>
+<tr>
+<td><a href="#Encrypted_boot_partition_(GRUB)">#Encrypted boot partition (GRUB)</a>
+<p>shows how to encrypt the boot partition using the GRUB boot loader.
+</p><p>This scenario also employs an EFI system partition, which may be applied to the other scenarios.
+</p>
+</td>
+<td>
+<ul><li>Same advantages as the scenario the installation is based on (LVM on LUKS for this particular example)</li>
+<li>Less data is left unencrypted, i.e. the boot loader and the EFI system partition, if present</li></ul>
+</td>
+<td>
+<ul><li>Same disadvantages as the scenario the installation is based on (LVM on LUKS for this particular example)</li>
+<li>More complicated configuration</li>
+<li>Not supported by other boot loaders</li>
+<li><a href="https://wiki.archlinux.org/title/GRUB/Tips_and_tricks#Speeding_up_LUKS_decryption_in_GRUB" title="GRUB/Tips and tricks">GRUB takes a long time to unlock LUKS</a>, thus slowing down boot</li></ul>
+</td></tr>
+<tr>
+<td><a href="#Root_on_ZFS">#Root on ZFS</a>
+</td>
+<td>
+<ul><li>In the case of a encrypted <code>zpool</code> all datasets are contained inside the same cryptographic environment making it easy to dual-boot and share data across installs.</li>
+<li>Backups can be made to a destination with an unencrypted zfs setup. Snapshots will be <a rel="nofollow" href="https://freebsdfoundation.org/our-work/journal/browser-based-edition/storage-and-filesystems/protecting-data-with-zfs-native-encryption/#:~:text=As%20you%20have%20seen%2C%20ZFS,able%20to%20mount%20the%20dataset.">encrypted natively on the destination</a>.</li></ul>
+</td>
+<td>
+<ul><li><a rel="nofollow" href="https://openzfs.github.io/openzfs-docs/man/v2.2/8/zfs-load-key.8.html">ZFS will not encrypt</a> metadata related to the pool structure, including dataset and snapshot names, dataset hierarchy, properties, file size, file holes, and deduplication tables (though the deduplicated data itself is encrypted).</li>
+<li>Pool creation requires the user to have a more in-depth knowledge of disks geometry setting even block size (<code>ashift</code>) for best performance.</li>
+<li>ZFS has some caveats with its own implementation of <code>aes</code> and some encryption algorithms <a rel="nofollow" href="https://github.com/openzfs/zfs/issues/15276">may not perform well</a>.</li>
+<li>Swap on a <code>zvol</code> or file inside a dataset is a <a rel="nofollow" href="https://github.com/openzfs/zfs/issues/7734">old and well-known issue</a> with no workaround other than having your swap in another partition or lv and suspend to disk disabled (see below).</li></ul>
+</td></tr></tbody></table>
+<p>While all above scenarios provide much greater protection from outside threats than encrypted secondary file systems, they also share a common disadvantage: any user in possession of the encryption key is able to decrypt the entire drive, and therefore can access other users' data. If that is of concern, it is possible to use a combination of block device and stacked file system encryption and reap the advantages of both. See <a href="https://wiki.archlinux.org/title/Data-at-rest_encryption" title="Data-at-rest encryption">Data-at-rest encryption</a> to plan ahead.
+</p><p>See <a href="https://wiki.archlinux.org/title/Dm-crypt/Drive_preparation#Partitioning" title="Dm-crypt/Drive preparation">dm-crypt/Drive preparation#Partitioning</a> for a general overview of the partitioning strategies used in the scenarios.
+</p><p>Another area to consider is whether to set up an encrypted swap partition and what kind. See <a href="https://wiki.archlinux.org/title/Dm-crypt/Swap_encryption" title="Dm-crypt/Swap encryption">dm-crypt/Swap encryption</a> for alternatives.
+</p><p>If you anticipate to protect the system's data not only against physical theft, but also have a requirement of precautions against logical tampering, see <a href="https://wiki.archlinux.org/title/Dm-crypt/Specialties#Securing_the_unencrypted_boot_partition" title="Dm-crypt/Specialties">dm-crypt/Specialties#Securing the unencrypted boot partition</a> for further possibilities after following one of the scenarios.
+</p><p>For <a href="https://wiki.archlinux.org/title/Solid_state_drive" title="Solid state drive">solid state drives</a> you might want to consider enabling TRIM support, but be warned, there are potential security implications. See <a href="https://wiki.archlinux.org/title/Dm-crypt/Specialties#Discard/TRIM_support_for_solid_state_drives_(SSD)" title="Dm-crypt/Specialties">dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD)</a> for more information.
+</p>
+<div><p><strong>Warning</strong></p><ul><li>In any scenario, never use file system repair software such as <a href="https://wiki.archlinux.org/title/Fsck" title="Fsck">fsck</a> directly on an encrypted volume, or it will destroy any means to recover the key used to decrypt your files. Such tools must be used on the decrypted (opened) device instead.</li>
+<li>The Argon2 key derivation function has a high RAM usage per design, defaulting to 1 GiB per encrypted mapper. Machines with low RAM and/or multiple LUKS2 partitions unlocked in parallel may error on boot. See the <code>--pbkdf-memory</code> option to control memory usage.<a rel="nofollow" href="https://gitlab.com/cryptsetup/cryptsetup/issues/372">[1]</a></li>
+<li>GRUB's support for LUKS2 is limited; see <a href="https://wiki.archlinux.org/title/GRUB#Encrypted_/boot" title="GRUB">GRUB#Encrypted /boot</a> for details. Use LUKS2 with PBKDF2 (<code>cryptsetup luksFormat --pbkdf pbkdf2</code>) for partitions that GRUB will need to unlock.</li>
+<li>Waking-up from suspend to disk on a ZFS dataset can corrupt your pool so, be extra careful when setting up hibernation even if swap is placed outside the zvol. <a rel="nofollow" href="https://github.com/openzfs/zfs/issues/260#issuecomment-991912492">Reference here</a>.</li></ul>
+</div>
+<p></p><h2 id="LUKS_on_a_partition">LUKS on a partition</h2><p></p>
+<p>This example covers a full system encryption with <i>dm-crypt</i> + LUKS in a simple partition layout:
+</p>
+<pre>+-----------------------+------------------------+-----------------------+
+| Boot partition        | LUKS encrypted root    | Optional free space   |
+|                       | partition              | for additional        |
+|                       |                        | partitions to be set  |
+| /boot                 | /                      | up later              |
+|                       |                        |                       |
+|                       | /dev/mapper/root       |                       |
+|                       |------------------------|                       |
+| /dev/sda1             | /dev/sda2              |                       |
++-----------------------+------------------------+-----------------------+
+</pre>
+<p>The first steps can be performed directly after booting the Arch Linux install image.
+</p>
+<p></p><h3 id="Preparing_the_disk">Preparing the disk</h3><p></p>
+<p>Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in <a href="https://wiki.archlinux.org/title/Dm-crypt/Drive_preparation" title="Dm-crypt/Drive preparation">dm-crypt/Drive preparation</a>.
+</p><p>Then create the needed partitions, at least one for <code>/</code> (e.g. <code>/dev/sda2</code>) and <code>/boot</code> (<code>/dev/sda1</code>). See <a href="https://wiki.archlinux.org/title/Partitioning" title="Partitioning">Partitioning</a>.
+</p>
+<p></p><h3 id="Preparing_non-boot_partitions">Preparing non-boot partitions</h3><p></p>
+<p>This and the next section replace the instructions of <a href="https://wiki.archlinux.org/title/Installation_guide#Format_the_partitions" title="Installation guide">Installation guide#Format the partitions</a>.
+</p><p>The following commands create and mount the encrypted root partition. They correspond to the procedure described in detail in <a href="https://wiki.archlinux.org/title/Dm-crypt/Device_encryption#Encrypting_devices_with_LUKS_mode" title="Dm-crypt/Device encryption">dm-crypt/Device encryption#Encrypting devices with LUKS mode</a>. If you want to use particular non-default encryption options (e.g. cipher, key length, sector size), see the <a href="https://wiki.archlinux.org/title/Dm-crypt/Device_encryption#Encryption_options_for_LUKS_mode" title="Dm-crypt/Device encryption">encryption options</a> before executing the first command.
+</p>
+<pre># cryptsetup -v luksFormat /dev/sda2
+# cryptsetup open /dev/sda2 root
+</pre>
+<p><a href="https://wiki.archlinux.org/title/Create_a_file_system" title="Create a file system">Create a file system</a> on unlocked LUKS device. For example, to create an <a href="https://wiki.archlinux.org/title/Ext4" title="Ext4">Ext4</a> file system, run:
+</p>
+<pre># mkfs.ext4 /dev/mapper/root
+</pre>
+<p>Mount the root volume to <code>/mnt</code>:
+</p>
+<pre># mount /dev/mapper/root /mnt
+</pre>
+<p>Check the mapping works as intended:
+</p>
+<pre># umount /mnt
+# cryptsetup close root
+# cryptsetup open /dev/sda2 root
+# mount /dev/mapper/root /mnt
+</pre>
+<p>If you created separate partitions (e.g. <code>/home</code>), these steps have to be adapted and repeated for all of them, <i>except</i> for <code>/boot</code>. See <a href="https://wiki.archlinux.org/title/Dm-crypt/Encrypting_a_non-root_file_system#Automated_unlocking_and_mounting" title="Dm-crypt/Encrypting a non-root file system">dm-crypt/Encrypting a non-root file system#Automated unlocking and mounting</a> on how to handle additional partitions at boot.
+</p><p>Note that each block device requires its own passphrase. This may be inconvenient, because it results in a separate passphrase to be input during boot. An alternative is to use a keyfile stored in the root partition to unlock the separate partition via <code>crypttab</code>. See <a href="https://wiki.archlinux.org/title/Dm-crypt/Device_encryption#Using_LUKS_to_format_partitions_with_a_keyfile" title="Dm-crypt/Device encryption">dm-crypt/Device encryption#Using LUKS to format partitions with a keyfile</a> for instructions.
+</p>
+<p></p><h3 id="Preparing_the_boot_partition">Preparing the boot partition</h3><p></p>
+<p>What you do have to setup is a non-encrypted <code>/boot</code> partition, which is needed for an encrypted root. For an <a href="https://wiki.archlinux.org/title/EFI_system_partition" title="EFI system partition">EFI system partition</a> on UEFI systems, execute the following command to format the newly created partition:
+</p>
+<p><strong>Warning</strong> Only format the EFI system partition if you created it during the partitioning step. If there already was an EFI system partition on disk beforehand, reformatting it can destroy the boot loaders of other installed operating systems.</p>
+<pre># mkfs.fat -F32 /dev/sda1
+</pre>
+<p>or for an ordinary boot partition on BIOS systems:
+</p>
+<pre># mkfs.ext4 /dev/sda1
+</pre>
+<p>Afterwards create the directory for the mountpoint and mount the partition:
+</p>
+<pre># mount --mkdir /dev/sda1 /mnt/boot
+</pre>
+<p></p><h3 id="Mounting_the_devices">Mounting the devices</h3><p></p>
+<p>At the step <a href="https://wiki.archlinux.org/title/Installation_guide#Mount_the_file_systems" title="Installation guide">Installation guide#Mount the file systems</a>, you should mount the <code>/dev/mapper/*</code> devices (the contents of LUKS), not the actual partitions. Of course, the partition for <code>/boot</code>, which is not encrypted, should still be mounted directly. During installation, it should be mounted to <code>/mnt/boot</code> (assuming the device for the root file system is mounted to <code>/mnt</code> during installation).
+</p>
+<p></p><h3 id="Configuring_mkinitcpio">Configuring mkinitcpio</h3><p></p>
+<p>Before following <a href="https://wiki.archlinux.org/title/Installation_guide#Initramfs" title="Installation guide">Installation guide#Initramfs</a> you must do the following to your new system:
+</p><p>If using the default <a href="https://wiki.archlinux.org/title/Mkinitcpio" title="Mkinitcpio">systemd-based initramfs</a>, add the <code>keyboard</code> and <code>sd-encrypt</code> hooks to <a href="https://wiki.archlinux.org/title/Mkinitcpio.conf" title="Mkinitcpio.conf">mkinitcpio.conf</a>. If you use a non-US console keymap or a non-default console font, additionally add the <code>sd-vconsole</code> hook.
+</p>
+<pre>HOOKS=(base <b>systemd</b> autodetect microcode modconf kms <b>keyboard</b> <b>sd-vconsole</b> block <b>sd-encrypt</b> filesystems fsck)
+</pre>
+<p>If using a busybox-based initramfs, add the <code>keyboard</code> and <code>encrypt</code> hooks. If you use a non-US console keymap or a non-default console font, additionally add the <code>keymap</code> and <code>consolefont</code> hooks, respectively.
+</p>
+<pre>HOOKS=(base <b>udev</b> autodetect microcode modconf kms <b>keyboard</b> <b>keymap</b> <b>consolefont</b> block <b>encrypt</b> filesystems fsck)
+</pre>
+<p><a href="https://wiki.archlinux.org/title/Regenerate_the_initramfs" title="Regenerate the initramfs">Regenerate the initramfs</a> after saving the changes. See <a href="https://wiki.archlinux.org/title/Dm-crypt/System_configuration#mkinitcpio" title="Dm-crypt/System configuration">dm-crypt/System configuration#mkinitcpio</a> for details and other hooks that you may need.
+</p>
+<p></p><h3 id="Configuring_the_boot_loader">Configuring the boot loader</h3><p></p>
+<p>In order to unlock the encrypted root partition at boot, the following <a href="https://wiki.archlinux.org/title/Kernel_parameters" title="Kernel parameters">kernel parameters</a> need to be set by the boot loader:
+</p>
+<pre>rd.luks.name=<i>device-UUID</i>=root root=/dev/mapper/root
+</pre>
+<p>If using the <code>encrypt</code> hook, the following need to be set instead:
+</p>
+<pre>cryptdevice=UUID=<i>device-UUID</i>:root root=/dev/mapper/root
+</pre>
+<p>The <code><i>device-UUID</i></code> refers to the UUID of the LUKS superblock. See <a href="https://wiki.archlinux.org/title/Persistent_block_device_naming" title="Persistent block device naming">Persistent block device naming</a> for details.
+</p><p>Also see <a href="https://wiki.archlinux.org/title/Dm-crypt/System_configuration#Kernel_parameters" title="Dm-crypt/System configuration">dm-crypt/System configuration#Kernel parameters</a> for more details.
+</p>
+<p><strong>Tip</strong> If the root partition is on the same disk as the <code>/boot</code> partition and your UEFI boot loader supports <a href="https://wiki.archlinux.org/title/Systemd#GPT_partition_automounting" title="Systemd">GPT partition automounting</a>, you can configure the <a href="https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs" title="wikipedia:GUID Partition Table">partition type GUID</a> (type should be "Root partition", not "LUKS partition") and rely on <span title="$ man 8 systemd-gpt-auto-generator"><a rel="nofollow" href="https://man.archlinux.org/man/systemd-gpt-auto-generator.8">systemd-gpt-auto-generator(8)</a></span> instead of using the kernel parameters.</p>
+<p></p><h2 id="LUKS_on_a_partition_with_TPM2_and_Secure_Boot">LUKS on a partition with TPM2 and Secure Boot</h2><p></p>
+<p>This example is similar to <a href="#LUKS_on_a_partition">#LUKS on a partition</a>, but integrates the use of <a href="https://wiki.archlinux.org/title/Secure_Boot" title="Secure Boot">Secure Boot</a> and a <a href="https://wiki.archlinux.org/title/Trusted_Platform_Module" title="Trusted Platform Module">Trusted Platform Module</a> (TPM), enhancing the overall security of the boot process.
+</p><p>In this configuration, only the <a href="https://wiki.archlinux.org/title/EFI_system_partition" title="EFI system partition">EFI system partition</a> remains unencrypted, housing a <a href="https://wiki.archlinux.org/title/Unified_kernel_image" title="Unified kernel image">unified kernel image</a> and <a href="https://wiki.archlinux.org/title/Systemd-boot" title="Systemd-boot">systemd-boot</a>—both signed for use with Secure Boot. If Secure Boot is disabled or its key databases are tampered with, the TPM will not release the key to unlock the encrypted partition. This approach is akin to BitLocker on Windows or FileVault on macOS. A recovery-key will also be created to make sure the data remains accessible in case of a problem with the TPM unlocking mechanism (unsigned boot loader or kernel update, firmware update, etc.). Optionally, a TPM pin can be set to be required during boot time to prevent fully automatic unlocking.
+</p><p>Make sure to thoroughly read the discussion and warnings in <a href="https://wiki.archlinux.org/title/Trusted_Platform_Module#LUKS_encryption" title="Trusted Platform Module">Trusted Platform Module#LUKS encryption</a>.
+</p><p>In this example, partitions are created respecting <a href="https://wiki.archlinux.org/title/Systemd#GPT_partition_automounting" title="Systemd">systemd#GPT partition automounting</a>, there is no need for an fstab or crypttab file.
+</p>
+<pre>+-----------------------+---------------------------------+
+| EFI system partition  | LUKS encrypted root partition   |
+|                       |                                 |
+|                       |                                 |
+| /boot                 | /                               |
+|                       |                                 |
+|                       | /dev/mapper/root                |
+|                       |---------------------------------|
+| /dev/sda1             | /dev/sda2                       |
++-----------------------+---------------------------------+
+</pre>
+<p>Follow the <a href="https://wiki.archlinux.org/title/Installation_guide" title="Installation guide">Installation guide</a> up to step <a href="https://wiki.archlinux.org/title/Installation_guide#Partition_the_disks" title="Installation guide">Installation guide#Partition the disks</a>.
+</p>
+<p></p><h3 id="Preparing_the_disk_2">Preparing the disk</h3><p></p>
+<p>Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in <a href="https://wiki.archlinux.org/title/Dm-crypt/Drive_preparation" title="Dm-crypt/Drive preparation">dm-crypt/Drive preparation</a>.
+</p><p><a href="https://wiki.archlinux.org/title/Partition" title="Partition">Partition</a> the drive with the <a href="https://wiki.archlinux.org/title/GUID_Partition_Table" title="GUID Partition Table">GUID Partition Table</a> (GPT).
+</p><p>Create an <a href="https://wiki.archlinux.org/title/EFI_system_partition#GPT_partitioned_disks" title="EFI system partition">EFI system partition</a> (e.g., <code>/dev/sda1</code>) with an appropriate size. This will be mounted at <code>/boot</code>.
+</p><p>In the remaining space, create a root partition (e.g., <code>/dev/sda2</code>) that will be encrypted and mounted at <code>/</code>. Set the partition type GUID for the root partition using type "Linux root (x86-64)" in <a href="https://wiki.archlinux.org/title/Fdisk" title="Fdisk">fdisk</a> or type code <code>8304</code> in <a href="https://wiki.archlinux.org/title/Gdisk" title="Gdisk">gdisk</a>.
+</p><p>Check the output of <code>fdisk -l</code> to make sure partition types are properly set.
+</p>
+<p></p><h3 id="Preparing_the_root_partition">Preparing the root partition</h3><p></p>
+<p>The following commands create and mount the encrypted root partition. They correspond to the procedure described in detail in <a href="https://wiki.archlinux.org/title/Dm-crypt/Device_encryption#Encrypting_devices_with_LUKS_mode" title="Dm-crypt/Device encryption">dm-crypt/Device encryption#Encrypting devices with LUKS mode</a>.
+</p><p>If you want to use particular non-default encryption options (e.g. cipher, key length), or if you don't want to use TPM based decryption, see the <a href="https://wiki.archlinux.org/title/Dm-crypt/Device_encryption#Encryption_options_for_LUKS_mode" title="Dm-crypt/Device encryption">encryption options</a> before executing the first command.
+</p>
+<p><strong>Warning</strong> Use a sufficiently secure password. Even though the keyslot will be wiped later, SSD wear-leveling can cause it to persist after removal for an indefinite amount of time.</p>
+<p>Create the LUKS volume and mount it:
+</p>
+<pre># cryptsetup luksFormat /dev/sda2
+# cryptsetup open /dev/sda2 root
+</pre>
+<p><a href="https://wiki.archlinux.org/title/Create_a_file_system" title="Create a file system">Create a file system</a> on unlocked LUKS device. For example, to create an <a href="https://wiki.archlinux.org/title/Ext4" title="Ext4">Ext4</a> file system, run:
+</p>
+<pre># mkfs.ext4 /dev/mapper/root
+</pre>
+<p>Mount the root volume to <code>/mnt</code>:
+</p>
+<pre># mount /dev/mapper/root /mnt
+</pre>
+<p></p><h3 id="Preparing_the_EFI_system_partition">Preparing the EFI system partition</h3><p></p>
+<p>Format the newly created EFI system partition as instructed in <a href="https://wiki.archlinux.org/title/EFI_system_partition#Format_the_partition" title="EFI system partition">EFI system partition#Format the partition</a> and mount it afterwards.
+</p>
+<pre># mount --mkdir /dev/sda1 /mnt/boot
+</pre>
+<p>Continue the installation process until <a href="https://wiki.archlinux.org/title/Installation_guide#Initramfs" title="Installation guide">Installation guide#Initramfs</a>. You can skip <a href="https://wiki.archlinux.org/title/Installation_guide#Fstab" title="Installation guide">Installation guide#Fstab</a>.
+</p>
+<p></p><h3 id="Configuring_mkinitcpio_2">Configuring mkinitcpio</h3><p></p>
+<p>To build a working systemd based initramfs, modify the <code>HOOKS=</code> line in <a href="https://wiki.archlinux.org/title/Mkinitcpio.conf" title="Mkinitcpio.conf">mkinitcpio.conf</a> as follows:
+</p>
+<pre>HOOKS=(base <b>systemd</b> autodetect microcode modconf kms <b>keyboard</b> <b>sd-vconsole</b> block <b>sd-encrypt</b> filesystems fsck)
+</pre>
+<p>Next, see <a href="https://wiki.archlinux.org/title/Unified_kernel_image#mkinitcpio" title="Unified kernel image">Unified kernel image#mkinitcpio</a> to configure mkinitcpio for <a href="https://wiki.archlinux.org/title/Unified_kernel_image" title="Unified kernel image">Unified kernel images</a>.
+</p><p>Do <b>not</b> regenerate the initramfs <b>yet</b>, as the <code>/boot/EFI/Linux</code> directory needs to be created by the boot loader installer first.
+</p>
+<p></p><h3 id="Installing_the_boot_loader">Installing the boot loader</h3><p></p>
+<p>You can configure your system to directly boot the UEFI image without any boot loader, see <a href="https://wiki.archlinux.org/title/Unified_kernel_image#Directly_from_UEFI" title="Unified kernel image">Unified kernel image#Directly from UEFI</a>.
+</p><p>If a boot loader is desired, continue installing <a href="https://wiki.archlinux.org/title/Systemd-boot" title="Systemd-boot">systemd-boot</a> with
+</p>
+<pre># bootctl install
+</pre>
+<p>The <a href="https://wiki.archlinux.org/title/Unified_kernel_image" title="Unified kernel image">Unified kernel image</a> generated by mkinitcpio will be automatically recognized and does not need an entry in <code>/boot/loader/entries/</code>.
+</p><p>See <a href="https://wiki.archlinux.org/title/Systemd-boot#Updating_the_UEFI_boot_manager" title="Systemd-boot">systemd-boot#Updating the UEFI boot manager</a> and <a href="https://wiki.archlinux.org/title/Systemd-boot#Loader_configuration" title="Systemd-boot">systemd-boot#Loader configuration</a> for further configuration.
+</p>
+<p></p><h3 id="Finalizing_the_installation">Finalizing the installation</h3><p></p>
+<p>First, <a href="https://wiki.archlinux.org/title/Regenerate_the_initramfs" title="Regenerate the initramfs">Regenerate the initramfs</a>, and make sure the image generation is successful.
+</p><p>Make sure you did not forget to <a href="https://wiki.archlinux.org/title/Installation_guide#Root_password" title="Installation guide">set a root password</a>, <a href="https://wiki.archlinux.org/title/Installation_guide#Reboot" title="Installation guide">reboot</a> to finish the installation.
+</p>
+<p></p><h3 id="Secure_Boot">Secure Boot</h3><p></p>
+<p>You can now sign the boot loader executables and the EFI binary, in order to enable <a href="https://wiki.archlinux.org/title/Secure_Boot" title="Secure Boot">Secure Boot</a>. For a quick and easy way, see <a href="https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Assisted_process_with_sbctl" title="Unified Extensible Firmware Interface/Secure Boot">Unified Extensible Firmware Interface/Secure Boot#Assisted process with sbctl</a>.
+</p>
+<p></p><h3 id="Enrolling_the_TPM">Enrolling the TPM</h3><p></p>
+<p>After signing the boot loader executables and enabling Secure Boot, you can now enroll the TPM in order to use it to unlock the LUKS volume. The following commands will remove the empty passphrase created during the LUKS format process, create a key bound to the TPM <a href="https://wiki.archlinux.org/title/Trusted_Platform_Module#Accessing_PCR_registers" title="Trusted Platform Module">PCR 7</a> (<a href="https://wiki.archlinux.org/title/Secure_Boot" title="Secure Boot">Secure Boot</a> state and enrolled certificates) and create a recovery key to be used in case of any problems. The TPM will automatically release the key as long as the boot chain is not tampered with. See <a href="https://wiki.archlinux.org/title/Systemd-cryptenroll#Trusted_Platform_Module" title="Systemd-cryptenroll">systemd-cryptenroll#Trusted Platform Module</a> and <span title="$ man 1 systemd-cryptenroll"><a rel="nofollow" href="https://man.archlinux.org/man/systemd-cryptenroll.1">systemd-cryptenroll(1)</a></span>.
+</p>
+<pre># systemd-cryptenroll /dev/sda2 --recovery-key
+# systemd-cryptenroll /dev/sda2 --wipe-slot=empty --tpm2-device=auto --tpm2-pcrs=7+15:sha256=0000000000000000000000000000000000000000000000000000000000000000
+</pre>
+<div><p><strong>Note</strong></p><ul><li>If a passphrase was set during the LUKS format process, the corresponding keyslot should be wiped (e.g. <code>--wipe-slot=0</code>).</li>
+<li>You can list keyslots using <code>systemd-cryptenroll /dev/sda2</code>. See <a href="https://wiki.archlinux.org/title/Systemd-cryptenroll#List_keyslots" title="Systemd-cryptenroll">systemd-cryptenroll#List keyslots</a>.</li></ul>
+</div>
+<p><strong>Tip</strong> Add <code>--tpm2-with-pin=yes</code> to require an additional PIN to unlock at boot time.</p>
+<div><p><strong>Warning</strong></p><ul><li>Make sure <a href="https://wiki.archlinux.org/title/Secure_Boot" title="Secure Boot">Secure Boot</a> is active and in user mode when binding to PCR 7, otherwise, unauthorized boot devices could unlock the encrypted volume.</li>
+<li>The state of PCR 7 can change if firmware certificates change, which can risk locking the user out. This can be implicitly done by <a href="https://wiki.archlinux.org/title/Fwupd" title="Fwupd">fwupd</a><a rel="nofollow" href="https://raw.githubusercontent.com/systemd/systemd/ed272a9ff59a26beedaab508dd3c9d631de67165/TODO">[2]</a> or explicitly by rotating Secure Boot keys.</li></ul>
+</div>
+<p></p><h2 id="LVM_on_LUKS">LVM on LUKS</h2><p></p>
+<p>The straightforward method is to set up <a href="https://wiki.archlinux.org/title/LVM" title="LVM">LVM</a> on top of the encrypted partition instead of the other way round. Technically the LVM is setup inside one big encrypted block device. Hence, the LVM is not visible until the block device is unlocked and the underlying volume structure is scanned and mounted during boot.
+</p><p>The disk layout in this example is:
+</p>
+<pre>+-----------------------------------------------------------------------+ +----------------+
+| Logical volume 1      | Logical volume 2      | Logical volume 3      | | Boot partition |
+|                       |                       |                       | |                |
+| [SWAP]                | /                     | /home                 | | /boot          |
+|                       |                       |                       | |                |
+| /dev/MyVolGroup/swap  | /dev/MyVolGroup/root  | /dev/MyVolGroup/home  | |                |
+|_ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _| | (may be on     |
+|                                                                       | | other device)  |
+|                         LUKS encrypted partition                      | |                |
+|                           /dev/sda1                                   | | /dev/sdb1      |
++-----------------------------------------------------------------------+ +----------------+
+</pre>
+
+<div><p><strong>Tip</strong> Two variants of this setup:
+</p><ul><li>Instructions at <a href="https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encrypted_system_using_a_detached_LUKS_header" title="Dm-crypt/Specialties">dm-crypt/Specialties#Encrypted system using a detached LUKS header</a> use this setup with a detached LUKS header on a USB device to achieve a two factor authentication with it.</li>
+<li>Instructions at <a href="https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encrypted_/boot_and_a_detached_LUKS_header_on_USB" title="Dm-crypt/Specialties">dm-crypt/Specialties#Encrypted /boot and a detached LUKS header on USB</a> use this setup with a detached LUKS header, encrypted <code>/boot</code> partition, and encrypted keyfile all on a USB device.</li></ul>
+</div>
+<p></p><h3 id="Preparing_the_disk_3">Preparing the disk</h3><p></p>
+<p>Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in <a href="https://wiki.archlinux.org/title/Dm-crypt/Drive_preparation" title="Dm-crypt/Drive preparation">dm-crypt/Drive preparation</a>.
+</p>
+
+<p><a href="https://wiki.archlinux.org/title/Installation_guide#Partition_the_disks" title="Installation guide">Create a partition</a> to be mounted at <code>/boot</code> with a size of 1 GiB or more.
+</p>
+
+<p>Create a partition which will later contain the encrypted container.
+</p><p>Create the LUKS encrypted container at the designated partition. Enter the chosen password twice.
+</p>
+<pre># cryptsetup luksFormat /dev/sda1
+</pre>
+<p>For more information about the available cryptsetup options see the <a href="https://wiki.archlinux.org/title/Dm-crypt/Device_encryption#Encryption_options_for_LUKS_mode" title="Dm-crypt/Device encryption">LUKS encryption options</a> prior to above command.
+</p><p>Open the container:
+</p>
+<pre># cryptsetup open /dev/sda1 cryptlvm
+</pre>
+<p>The decrypted container is now available at <code>/dev/mapper/cryptlvm</code>.
+</p>
+<p></p><h3 id="Preparing_the_logical_volumes">Preparing the logical volumes</h3><p></p>
+<p>Create a physical volume on top of the opened LUKS container:
+</p>
+<pre># pvcreate /dev/mapper/cryptlvm
+</pre>
+<p>Create a volume group (in this example named <code>MyVolGroup</code>, but it can be whatever you want) and add the previously created physical volume to it:
+</p>
+<pre># vgcreate MyVolGroup /dev/mapper/cryptlvm
+</pre>
+<p>Create all your logical volumes on the volume group:
+</p>
+<p><strong>Tip</strong> If a logical volume will be formatted with <a href="https://wiki.archlinux.org/title/Ext4" title="Ext4">ext4</a>, leave at least 256 MiB free space in the volume group to allow using <span title="$ man 8 e2scrub"><a rel="nofollow" href="https://man.archlinux.org/man/e2scrub.8">e2scrub(8)</a></span>. After creating the last volume with <code>-l 100%FREE</code>, this can be accomplished by reducing its size with <code>lvreduce -L -256M MyVolGroup/home</code>.</p>
+<pre># lvcreate -L 4G -n swap MyVolGroup
+# lvcreate -L 32G -n root MyVolGroup
+# lvcreate -l 100%FREE -n home MyVolGroup
+</pre>
+<p><a href="https://wiki.archlinux.org/title/Format" title="Format">Format</a> your file systems on each logical volume. For example, using <a href="https://wiki.archlinux.org/title/Ext4" title="Ext4">Ext4</a> for the root and home volumes:
+</p>
+<pre># mkfs.ext4 /dev/MyVolGroup/root
+# mkfs.ext4 /dev/MyVolGroup/home
+# mkswap /dev/MyVolGroup/swap
+</pre>
+<p>Mount your file systems:
+</p>
+<pre># mount /dev/MyVolGroup/root /mnt
+# mount --mkdir /dev/MyVolGroup/home /mnt/home
+# swapon /dev/MyVolGroup/swap
+</pre>
+<p></p><h3 id="Preparing_the_boot_partition_2">Preparing the boot partition</h3><p></p>
+<p>The boot loader loads the kernel, <a href="https://wiki.archlinux.org/title/Initramfs" title="Initramfs">initramfs</a>, and its own configuration files from the <code>/boot</code> directory. Any file system on a disk that can be read by the boot loader is eligible.
+</p><p>Create a <a href="https://wiki.archlinux.org/title/File_system" title="File system">file system</a> on the partition intended for <code>/boot</code>. For an <a href="https://wiki.archlinux.org/title/EFI_system_partition" title="EFI system partition">EFI system partition</a> on UEFI systems, execute the following command to format the newly created partition:
+</p>
+<p><strong>Warning</strong> Only format the EFI system partition if you created it during the partitioning step. If there already was an EFI system partition on disk beforehand, reformatting it can destroy the boot loaders of other installed operating systems.</p>
+<pre># mkfs.fat -F32 /dev/sdb1
+</pre>
+<p>or for an ordinary boot partition on BIOS systems:
+</p>
+<pre># mkfs.ext4 /dev/sdb1
+</pre>
+<p>Mount the partition to <code>/mnt/boot</code>:
+</p>
+<pre># mount --mkdir /dev/sdb1 /mnt/boot
+</pre>
+<p>At this point resume the common <a href="https://wiki.archlinux.org/title/Installation_guide#Installation" title="Installation guide">Installation guide#Installation</a> steps. Return to this page to customize the <a href="https://wiki.archlinux.org/title/Installation_guide#Initramfs" title="Installation guide">Initramfs</a> and <a href="https://wiki.archlinux.org/title/Installation_guide#Boot_loader" title="Installation guide">Boot loader</a> steps.
+</p>
+<p></p><h3 id="Configuring_mkinitcpio_3">Configuring mkinitcpio</h3><p></p>
+<p>Make sure the <span><a rel="nofollow" href="https://archlinux.org/packages/?name=lvm2">lvm2</a></span> package is <a href="https://wiki.archlinux.org/title/Install" title="Install">installed</a>.
+</p><p>If using the default systemd-based initramfs, add the <code>keyboard</code>, <code>sd-encrypt</code> and <code>lvm2</code> hooks to <a href="https://wiki.archlinux.org/title/Mkinitcpio.conf" title="Mkinitcpio.conf">mkinitcpio.conf</a>. If you use a non-US console keymap or a non-default console font, additionally add the <code>sd-vconsole</code> hook.
+</p>
+<pre>HOOKS=(base <b>systemd</b> autodetect microcode modconf kms <b>keyboard</b> <b>sd-vconsole</b> block <b>sd-encrypt</b> <b>lvm2</b> filesystems fsck)
+</pre>
+<p>If using a busybox-based initramfs, instead add the <code>keyboard</code>, <code>encrypt</code> and <code>lvm2</code> hooks. If you use a non-US console keymap or a non-default console font, additionally add the <code>keymap</code> and <code>consolefont</code> hooks, respectively.
+</p>
+<pre>HOOKS=(base <b>udev</b> autodetect microcode modconf kms <b>keyboard</b> <b>keymap</b> <b>consolefont</b> block <b>encrypt</b> <b>lvm2</b> filesystems fsck)
+</pre>
+<p><a href="https://wiki.archlinux.org/title/Regenerate_the_initramfs" title="Regenerate the initramfs">Regenerate the initramfs</a> after saving the changes. See <a href="https://wiki.archlinux.org/title/Dm-crypt/System_configuration#mkinitcpio" title="Dm-crypt/System configuration">dm-crypt/System configuration#mkinitcpio</a> for details and other hooks that you may need.
+</p>
+<p></p><h3 id="Configuring_the_boot_loader_2">Configuring the boot loader</h3><p></p>
+<p>In order to unlock the encrypted root partition at boot, the following <a href="https://wiki.archlinux.org/title/Kernel_parameters" title="Kernel parameters">kernel parameters</a> need to be set by the boot loader:
+</p>
+<pre>rd.luks.name=<i>device-UUID</i>=cryptlvm root=/dev/MyVolGroup/root
+</pre>
+<p>If using the <code>encrypt</code> hook, the following needs to be set instead:
+</p>
+<pre>cryptdevice=UUID=<i>device-UUID</i>:cryptlvm root=/dev/MyVolGroup/root
+</pre>
+<p>The <code><i>device-UUID</i></code> refers to the UUID of the LUKS superblock, in this example it is the UUID of <code>/dev/sda1</code> e.g. <code>a144e931-7580-40bf-ae8c-6beff4c1ac45</code>. See <a href="https://wiki.archlinux.org/title/Persistent_block_device_naming" title="Persistent block device naming">Persistent block device naming</a> for details.
+</p><p>If using <a href="https://wiki.archlinux.org/title/Dracut" title="Dracut">dracut</a>, these parameters are known to work:
+</p>
+<pre>rd.luks.uuid=<i>device-UUID</i> root=/dev/MyVolGroup/root
+</pre>
+<p>you may need a more extensive list of parameters, try:
+</p>
+<pre>rd.luks.uuid=luks-<i>deviceUUID</i> rd.lvm.lv=<i>MyVolGroup</i>/root  rd.lvm.lv=<i>MyVolGroup</i>/swap  root=/dev/mapper/<i>MyVolGroup</i>-root rootfstype=ext4 rootflags=rw,relatime
+</pre>
+<p>See <a href="https://wiki.archlinux.org/title/Dm-crypt/System_configuration#Kernel_parameters" title="Dm-crypt/System configuration">dm-crypt/System configuration#Kernel parameters</a> for details.
+</p>
+<p></p><h2 id="LUKS_on_LVM">LUKS on LVM</h2><p></p>
+<p>To use encryption on top of <a href="https://wiki.archlinux.org/title/LVM" title="LVM">LVM</a>, the LVM volumes are set up first and then used as the base for the encrypted partitions. This way, a mixture of encrypted and non-encrypted volumes/partitions is possible as well.
+</p>
+<p><strong>Tip</strong> Unlike <a href="#LVM_on_LUKS">#LVM on LUKS</a>, this method allows normally spanning the logical volumes over multiple disks.</p>
+<p>The following short example creates a LUKS on LVM setup and mixes in the use of a key-file for the /home partition and a temporary encrypted volume for swap. This is considered desirable from a security perspective, because no potentially sensitive temporary data survives the reboot, when the encryption is re-initialised. If you are experienced with LVM, you will be able to ignore/replace LVM and other specifics according to your plan.
+</p><p>If you want to span a logical volume over multiple disks that have already been set up, or expand the logical volume for <code>/home</code> (or any other volume), a procedure to do so is described in <a href="https://wiki.archlinux.org/title/Dm-crypt/Specialties#Expanding_LVM_on_multiple_disks" title="Dm-crypt/Specialties">dm-crypt/Specialties#Expanding LVM on multiple disks</a>. It is important to note that the LUKS encrypted container has to be resized as well.
+</p>
+<div>
+<p><span><span><img src="https://wiki.archlinux.org/images/1/19/Tango-view-fullscreen.svg" decoding="async" width="48" height="48"></span></span><b>This article or section needs expansion.</b></p>
+<p><b>Reason:</b> The intro of this scenario needs some adjustment now that a comparison has been added to <a href="#Overview">#Overview</a>. A suggested structure is to make it similar to the <a href="#LUKS_on_a_partition">#LUKS on a partition</a> intro. (Discuss in <a rel="nofollow" href="https://wiki.archlinux.org/title/Talk:Dm-crypt/Encrypting_an_entire_system">Talk:Dm-crypt/Encrypting an entire system</a>)</p>
+</div>
+<p></p><h3 id="Preparing_the_disk_4">Preparing the disk</h3><p></p>
+<p>Partitioning scheme:
+</p>
+<pre>+----------------+-------------------------------------------------------------------------------------------------+
+| Boot partition | dm-crypt plain encrypted volume | LUKS encrypted volume         | LUKS encrypted volume         |
+|                |                                 |                               |                               |
+| /boot          | [SWAP]                          | /                             | /home                         |
+|                |                                 |                               |                               |
+|                | /dev/mapper/swap                | /dev/mapper/root              | /dev/mapper/home              |
+|                |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|
+|                | Logical volume 1                | Logical volume 2              | Logical volume 3              |
+|                | /dev/MyVolGroup/cryptswap       | /dev/MyVolGroup/cryptroot     | /dev/MyVolGroup/crypthome     |
+|                |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|
+|                |                                                                                                 |
+|   /dev/sda1    |                                   /dev/sda2                                                     |
++----------------+-------------------------------------------------------------------------------------------------+
+</pre>
+<p>Randomise <code>/dev/sda2</code> according to <a href="https://wiki.archlinux.org/title/Dm-crypt/Drive_preparation#dm-crypt_wipe_on_an_empty_device_or_partition" title="Dm-crypt/Drive preparation">dm-crypt/Drive preparation#dm-crypt wipe on an empty device or partition</a>.
+</p>
+<p></p><h3 id="Preparing_the_logical_volumes_2">Preparing the logical volumes</h3><p></p>
+<pre># pvcreate /dev/sda2
+# vgcreate MyVolGroup /dev/sda2
+# lvcreate -L 4G -n cryptswap MyVolGroup
+# lvcreate -L 32G -n cryptroot MyVolGroup
+# lvcreate -l 100%FREE -n crypthome MyVolGroup
+</pre>
+<pre># cryptsetup luksFormat /dev/MyVolGroup/cryptroot
+# cryptsetup open /dev/MyVolGroup/cryptroot root
+</pre>
+<p><a href="https://wiki.archlinux.org/title/Create_a_file_system" title="Create a file system">Create a file system</a> on unlocked LUKS device and mount it. For example, to create an <a href="https://wiki.archlinux.org/title/Ext4" title="Ext4">Ext4</a> file system, run:
+</p>
+<pre># mkfs.ext4 /dev/mapper/root
+# mount /dev/mapper/root /mnt
+</pre>
+<p>More information about the encryption options can be found in <a href="https://wiki.archlinux.org/title/Dm-crypt/Device_encryption#Encryption_options_for_LUKS_mode" title="Dm-crypt/Device encryption">dm-crypt/Device encryption#Encryption options for LUKS mode</a>.
+Note that <code>/home</code> will be encrypted in <a href="#Encrypting_logical_volume_/home">#Encrypting logical volume /home</a>.
+</p>
+<p><strong>Tip</strong> If you ever have to access the encrypted root from the Arch-ISO, the above <code>open</code> action will allow you to after the <a href="https://wiki.archlinux.org/title/LVM#Logical_volumes_do_not_show_up" title="LVM">LVM shows up</a>.</p>
+<p></p><h3 id="Preparing_the_boot_partition_3">Preparing the boot partition</h3><p></p>
+<p>Create a <a href="https://wiki.archlinux.org/title/File_system" title="File system">file system</a> on the partition intended for <code>/boot</code>. For an <a href="https://wiki.archlinux.org/title/EFI_system_partition" title="EFI system partition">EFI system partition</a> on UEFI systems, execute the following command to format the newly created partition:
+</p>
+<p><strong>Warning</strong> Only format the EFI system partition if you created it during the partitioning step. If there already was an EFI system partition on disk beforehand, reformatting it can destroy the boot loaders of other installed operating systems.</p>
+<pre># mkfs.fat -F32 /dev/sda1
+</pre>
+<p>or for an ordinary boot partition on BIOS systems:
+</p>
+<pre># mkfs.ext4 /dev/sda1
+</pre>
+<p>Afterwards create the directory for the mountpoint and mount the partition:
+</p>
+<pre># mount --mkdir /dev/sda1 /mnt/boot
+</pre>
+<p></p><h3 id="Configuring_mkinitcpio_4">Configuring mkinitcpio</h3><p></p>
+<p>Make sure the <span><a rel="nofollow" href="https://archlinux.org/packages/?name=lvm2">lvm2</a></span> package is <a href="https://wiki.archlinux.org/title/Install" title="Install">installed</a>.
+</p><p>If using the default systemd-based initramfs, add the <code>keyboard</code>, <code>sd-encrypt</code> and <code>lvm2</code> hooks to <a href="https://wiki.archlinux.org/title/Mkinitcpio.conf" title="Mkinitcpio.conf">mkinitcpio.conf</a>. If you use a non-US console keymap or a non-default console font, additionally add the <code>sd-vconsole</code> hook.
+</p>
+<pre>HOOKS=(base <b>systemd</b> autodetect microcode modconf kms <b>keyboard</b> <b>sd-vconsole</b> block <b>sd-encrypt</b> <b>lvm2</b> filesystems fsck)
+</pre>
+<p>If using a busybox-based initramfs, instead add the <code>keyboard</code>, <code>encrypt</code> and <code>lvm2</code> hooks. If you use a non-US console keymap or a non-default console font, additionally add the <code>keymap</code> and <code>consolefont</code> hooks, respectively.
+</p>
+<pre>HOOKS=(base <b>udev</b> autodetect microcode modconf kms <b>keyboard</b> <b>keymap</b> <b>consolefont</b> block <b>encrypt</b> <b>lvm2</b> filesystems fsck)
+</pre>
+<p><a href="https://wiki.archlinux.org/title/Regenerate_the_initramfs" title="Regenerate the initramfs">Regenerate the initramfs</a> after saving the changes. See <a href="https://wiki.archlinux.org/title/Dm-crypt/System_configuration#mkinitcpio" title="Dm-crypt/System configuration">dm-crypt/System configuration#mkinitcpio</a> for details and other hooks that you may need.
+</p>
+<p></p><h3 id="Configuring_the_boot_loader_3">Configuring the boot loader</h3><p></p>
+<p>In order to unlock the encrypted root partition at boot, the following <a href="https://wiki.archlinux.org/title/Kernel_parameters" title="Kernel parameters">kernel parameters</a> need to be set by the boot loader:
+</p>
+<pre>rd.luks.name=<i>device-UUID</i>=root root=/dev/mapper/root
+</pre>
+<p>If using the <code>encrypt</code> hook, the following need to be set instead:
+</p>
+<pre>cryptdevice=UUID=<i>device-UUID</i>:root root=/dev/mapper/root
+</pre>
+<p>The <code><i>device-UUID</i></code> refers to the UUID of the LUKS superblock, in this example it is the UUID of <code>/dev/MyVolGroup/cryptroot</code> e.g. <code>a144e931-7580-40bf-ae8c-6beff4c1ac45</code>. See <a href="https://wiki.archlinux.org/title/Persistent_block_device_naming" title="Persistent block device naming">Persistent block device naming</a> for details.
+</p><p>See <a href="https://wiki.archlinux.org/title/Dm-crypt/System_configuration#Kernel_parameters" title="Dm-crypt/System configuration">dm-crypt/System configuration#Kernel parameters</a> for details.
+</p>
+<p></p><h3 id="Configuring_fstab_and_crypttab">Configuring fstab and crypttab</h3><p></p>
+<p>Both <a href="https://wiki.archlinux.org/title/Crypttab" title="Crypttab">crypttab</a> and <a href="https://wiki.archlinux.org/title/Fstab" title="Fstab">fstab</a> entries are required to both unlock the device and mount the file systems, respectively. The following lines will re-encrypt the swap volume on each reboot:
+</p>
+<pre>/etc/crypttab</pre>
+<pre>swap	/dev/MyVolGroup/cryptswap	/dev/urandom	swap,cipher=aes-xts-plain64,size=256,sector-size=4096</pre>
+<pre>/etc/fstab</pre>
+<pre>/dev/mapper/root                          /     ext4   defaults  0 1
+UUID=<i>xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</i> /boot ext4   defaults  0 2
+/dev/mapper/swap                          none  swap   defaults  0 0</pre>
+<p></p><h3 id="Encrypting_logical_volume_/home"><span id="Encrypting_logical_volume_.2Fhome"></span>Encrypting logical volume /home</h3><p></p>
+<p>Since this scenario uses LVM as the primary and dm-crypt as secondary mapper, each encrypted logical volume requires its own encryption. Yet, unlike the temporary file systems configured with volatile encryption above, the logical volume for <code>/home</code> should of course be persistent. The following assumes you have rebooted into the installed system, otherwise you have to adjust paths.
+To save on entering a second passphrase at boot, a <a href="https://wiki.archlinux.org/title/Dm-crypt/Device_encryption#Keyfiles" title="Dm-crypt/Device encryption">keyfile</a> is created:
+</p>
+<pre># dd bs=512 count=4 if=/dev/random iflag=fullblock | install -m 0600 /dev/stdin /etc/cryptsetup-keys.d/home.key
+</pre>
+<p>The logical volume is encrypted with it:
+</p>
+<pre># cryptsetup luksFormat -v /dev/MyVolGroup/crypthome /etc/cryptsetup-keys.d/home.key
+# cryptsetup -d /etc/cryptsetup-keys.d/home.key open /dev/MyVolGroup/crypthome home
+</pre>
+<p><a href="https://wiki.archlinux.org/title/Create_a_file_system" title="Create a file system">Create a file system</a> on unlocked LUKS device and mount it. For example, to create an <a href="https://wiki.archlinux.org/title/Ext4" title="Ext4">Ext4</a> file system, run:
+</p>
+<pre># mkfs.ext4 /dev/mapper/home
+# mount /dev/mapper/home /home
+</pre>
+<p>The encrypted mount is configured in both <a href="https://wiki.archlinux.org/title/Crypttab" title="Crypttab">crypttab</a> and <a href="https://wiki.archlinux.org/title/Fstab" title="Fstab">fstab</a>:
+</p>
+<pre>/etc/crypttab</pre>
+<pre>home	/dev/MyVolGroup/crypthome   none
+</pre>
+<pre>/etc/fstab</pre>
+<pre>/dev/mapper/home        /home   ext4        defaults        0       2
+</pre>
+<p></p><h2 id="LUKS_on_software_RAID">LUKS on software RAID</h2><p></p>
+<p>This example is based on a real-world setup for a workstation class laptop equipped with two SSDs of equal size, and an additional HDD for bulk storage. The end result is LUKS based full disk encryption (including <code>/boot</code>) for all drives, with the SSDs in a <a href="https://wiki.archlinux.org/title/RAID" title="RAID">RAID0</a> array, and keyfiles used to unlock all encryption after <a href="https://wiki.archlinux.org/title/GRUB" title="GRUB">GRUB</a> is given a correct passphrase at boot.
+</p><p>This setup utilizes a very simplistic partitioning scheme, with all the available RAID storage being mounted at <code>/</code> (no separate <code>/boot</code> partition), and the decrypted HDD being mounted at <code>/data</code>.
+</p><p>Please note that regular <a href="https://wiki.archlinux.org/title/System_backup" title="System backup">backups</a> are very important in this setup. If either of the SSDs fail, the data contained in the RAID array will be practically impossible to recover. You may wish to select a different <a href="https://wiki.archlinux.org/title/RAID#Standard_RAID_levels" title="RAID">RAID level</a> if fault tolerance is important to you.
+</p><p>The encryption is not deniable in this setup.
+</p><p>For the sake of the instructions below, the following block devices are used:
+</p>
+<pre>/dev/sda = first SSD
+/dev/sdb = second SSD
+/dev/sdc = HDD
+</pre>
+<pre>+---------------------+---------------------------+---------------------------+ +---------------------+---------------------------+---------------------------+ +---------------------------+
+| BIOS boot partition | EFI system partition      | LUKS encrypted volume     | | BIOS boot partition | EFI system partition      | LUKS encrypted volume     | | LUKS encrypted volume     |
+|                     |                           |                           | |                     |                           |                           | |                           |
+|                     | /efi                      | /                         | |                     | /efi                      | /                         | | /data                     |
+|                     |                           |                           | |                     |                           |                           | |                           |
+|                     |                           | /dev/mapper/root          | |                     |                           | /dev/mapper/root          | |                           |
+|                     +---------------------------+---------------------------+ |                     +---------------------------+---------------------------+ |                           |
+|                     | RAID1 array (part 1 of 2) | RAID0 array (part 1 of 2) | |                     | RAID1 array (part 2 of 2) | RAID0 array (part 2 of 2) | |                           |
+|                     |                           |                           | |                     |                           |                           | |                           |
+|                     | /dev/md/ESP               | /dev/md/root              | |                     | /dev/md/ESP               | /dev/md/root              | | /dev/mapper/data          |
+|                     +---------------------------+---------------------------+ |                     +---------------------------+---------------------------+ +---------------------------+
+| /dev/sda1           | /dev/sda2                 | /dev/sda3                 | | /dev/sdb1           | /dev/sdb2                 | /dev/sdb3                 | | /dev/sdc1                 |
++---------------------+---------------------------+---------------------------+ +---------------------+---------------------------+---------------------------+ +---------------------------+
+</pre>
+<p>Be sure to substitute them with the appropriate device designations for your setup, as they may be different.
+</p>
+<p></p><h3 id="Preparing_the_disks">Preparing the disks</h3><p></p>
+<p>Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in <a href="https://wiki.archlinux.org/title/Dm-crypt/Drive_preparation" title="Dm-crypt/Drive preparation">dm-crypt/Drive preparation</a>.
+</p><p>For <a href="https://wiki.archlinux.org/title/GRUB#BIOS_systems" title="GRUB">BIOS systems</a> with GPT, create a <a href="https://wiki.archlinux.org/title/BIOS_boot_partition" title="BIOS boot partition">BIOS boot partition</a> with size of 1 MiB for GRUB to store the second stage of BIOS boot loader. Do not mount the partition.
+</p><p>For <a href="https://wiki.archlinux.org/title/GRUB#UEFI_systems" title="GRUB">UEFI systems</a> create an <a href="https://wiki.archlinux.org/title/EFI_system_partition" title="EFI system partition">EFI system partition</a> with an appropriate size, it will later be mounted at <code>/efi</code>.
+</p><p>In the remaining space on the drive create a partition (<code>/dev/sda3</code> in this example) for "Linux RAID". Choose partition type ID <code>fd</code> for MBR or partition type GUID <code>A19D880F-05FC-4D3B-A006-743F0F84911E</code> for GPT.
+</p><p>Once partitions have been created on <code>/dev/sda</code>, the following commands can be used to clone them to <code>/dev/sdb</code>.
+</p>
+<pre># sfdisk -d /dev/sda &gt; sda.dump
+# sfdisk /dev/sdb &lt; sda.dump
+</pre>
+<p>The HDD is prepared with a single Linux partition covering the whole drive at <code>/dev/sdc1</code>.
+</p>
+<p></p><h3 id="Building_the_RAID_array">Building the RAID array</h3><p></p>
+<p>Create the RAID array for the SSDs.
+</p>
+<div><p><strong>Note</strong></p><ul><li>All parts of an EFI system partition RAID array must be individually usable, that means that ESP can only placed in a RAID1 array.</li>
+<li>The RAID superblock must be placed at the end of the EFI system partition using <code>--metadata=1.0</code>, otherwise the firmware will not be able to access the partition.</li></ul>
+</div>
+<pre># mdadm --create --verbose --level=1 --metadata=1.0 --raid-devices=2 /dev/md/ESP /dev/sda2 /dev/sdb2
+</pre>
+<p>This example utilizes RAID0 for root, you may wish to substitute a different level based on your preferences or requirements.
+</p>
+<pre># mdadm --create --verbose --level=0 --metadata=1.2 --raid-devices=2 /dev/md/root /dev/sda3 /dev/sdb3
+</pre>
+<p></p><h3 id="Preparing_the_block_devices">Preparing the block devices</h3><p></p>
+<p>As explained in <a href="https://wiki.archlinux.org/title/Dm-crypt/Drive_preparation" title="Dm-crypt/Drive preparation">dm-crypt/Drive preparation</a>, the devices are wiped with random data utilizing <code>/dev/zero</code> and a crypt device with a random key. Alternatively, you could use <code>dd</code> with <code>/dev/random</code> or <code>/dev/urandom</code>, though it will be much slower.
+</p>
+<pre># cryptsetup open --type plain --sector-size 4096 --key-file /dev/urandom /dev/md/root to_be_wiped
+# dd if=/dev/zero of=/dev/mapper/to_be_wiped bs=1M status=progress
+# cryptsetup close to_be_wiped
+</pre>
+<p>And repeat above for the HDD (<code>/dev/sdc1</code> in this example).
+</p><p>Set up encryption for <code>/dev/md/root</code>:
+</p>
+<p><strong>Warning</strong> GRUB's support for LUKS2 is limited; see <a href="https://wiki.archlinux.org/title/GRUB#Encrypted_/boot" title="GRUB">GRUB#Encrypted /boot</a> for details. Use LUKS2 with PBKDF2 (<code>cryptsetup luksFormat --pbkdf pbkdf2</code>) for partitions that GRUB will need to unlock.</p>
+<pre># cryptsetup -v luksFormat --pbkdf pbkdf2 /dev/md/root
+# cryptsetup open /dev/md/root root
+</pre>
+<p><a href="https://wiki.archlinux.org/title/Create_a_file_system" title="Create a file system">Create a file system</a> on unlocked LUKS device. For example, to create an <a href="https://wiki.archlinux.org/title/Ext4" title="Ext4">Ext4</a> file system, run:
+</p>
+<pre># mkfs.ext4 /dev/mapper/root
+</pre>
+<p>Mount the root volume to <code>/mnt</code>:
+</p>
+<pre># mount /dev/mapper/root /mnt
+</pre>
+<p>And repeat for the HDD:
+</p>
+<pre># cryptsetup -v luksFormat /dev/sdc1
+# cryptsetup open /dev/sdc1 data
+# mkfs.ext4 /dev/mapper/data
+# mount --mkdir /dev/mapper/data /mnt/data
+</pre>
+<p>For UEFI systems, format the newly created EFI system partition and mount it:
+</p>
+<p><strong>Warning</strong> Only format the EFI system partition if you created it during the partitioning step. If there already was an EFI system partition on disk beforehand, reformatting it can destroy the boot loaders of other installed operating systems.</p>
+<pre># mkfs.fat -F32 /dev/md/ESP
+# mount --mkdir /dev/md/ESP /mnt/efi
+</pre>
+<p></p><h3 id="Configuring_GRUB">Configuring GRUB</h3><p></p>
+<p>Configure <a href="https://wiki.archlinux.org/title/GRUB" title="GRUB">GRUB</a> for the LUKS encrypted system by editing <code>/etc/default/grub</code> with the following:
+</p>
+<pre>GRUB_CMDLINE_LINUX="cryptdevice=/dev/md/root:root"
+GRUB_ENABLE_CRYPTODISK=y
+</pre>
+<p>If you have a USB keyboard on a newer system either enable legacy USB support in firmware or add the following to <code>/etc/default/grub</code>:
+</p>
+<pre>GRUB_TERMINAL_INPUT="usb_keyboard"
+GRUB_PRELOAD_MODULES="usb usb_keyboard ohci uhci ehci"
+</pre>
+<p>Otherwise you may not be able to use your keyboard at the LUKS prompt.
+</p><p>See <a href="https://wiki.archlinux.org/title/Dm-crypt/System_configuration#Kernel_parameters" title="Dm-crypt/System configuration">dm-crypt/System configuration#Kernel parameters</a> and <a href="https://wiki.archlinux.org/title/GRUB#Encrypted_/boot" title="GRUB">GRUB#Encrypted /boot</a> for details.
+</p><p>Complete the GRUB install to both SSDs (in reality, installing only to <code>/dev/sda</code> will work).
+</p>
+<pre># grub-install --target=i386-pc /dev/sda
+# grub-install --target=i386-pc /dev/sdb
+# grub-install --target=x86_64-efi --efi-directory=/efi --bootloader-id=GRUB
+# grub-mkconfig -o /boot/grub/grub.cfg
+</pre>
+<p></p><h3 id="Creating_the_keyfiles">Creating the keyfiles</h3><p></p>
+<p>The next steps save you from entering your passphrase twice when you boot the system (once so GRUB can unlock the LUKS device, and second time once the initramfs assumes control of the system). This is done by creating a <a href="https://wiki.archlinux.org/title/Dm-crypt/Device_encryption#Keyfiles" title="Dm-crypt/Device encryption">keyfile</a> for the encryption and adding it to the initramfs image to allow the encrypt hook to unlock the root device. See <a href="https://wiki.archlinux.org/title/Dm-crypt/Device_encryption#With_a_keyfile_embedded_in_the_initramfs" title="Dm-crypt/Device encryption">dm-crypt/Device encryption#With a keyfile embedded in the initramfs</a> for details.
+</p>
+<ul><li>Create the <a href="https://wiki.archlinux.org/title/Dm-crypt/Device_encryption#Keyfiles" title="Dm-crypt/Device encryption">keyfile</a> and add the key to <code>/dev/md/root</code>.</li>
+<li>Create another keyfile for the HDD (<code>/dev/sdc1</code>) so it can also be unlocked at boot. For convenience, leave the passphrase created above in place as this can make recovery easier if you ever need it. Edit <code>/etc/crypttab</code> to decrypt the HDD at boot. See <a href="https://wiki.archlinux.org/title/Dm-crypt/System_configuration#Unlocking_with_a_keyfile" title="Dm-crypt/System configuration">dm-crypt/System configuration#Unlocking with a keyfile</a>.</li></ul>
+<p></p><h3 id="Configuring_the_system">Configuring the system</h3><p></p>
+<p>Edit <a href="https://wiki.archlinux.org/title/Fstab" title="Fstab">fstab</a> to mount the root and data block devices and the ESP:
+</p>
+<pre>/dev/mapper/root  /	  ext4	rw,noatime 	   0 1
+/dev/mapper/data  /data   ext4	defaults           0 2
+/dev/md/ESP       /efi     vfat	rw,relatime,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,tz=UTC,errors=remount-ro  	0 2
+</pre>
+<p>Save the RAID configuration:
+</p>
+<pre># mdadm --detail --scan &gt;&gt; /etc/mdadm.conf
+</pre>
+<p>Edit <a href="https://wiki.archlinux.org/title/Mkinitcpio.conf" title="Mkinitcpio.conf">mkinitcpio.conf</a> to include your keyfile and add the proper hooks:
+</p>
+<pre>FILES=(/crypto_keyfile.bin)
+HOOKS=(base udev autodetect microcode modconf kms <b>keyboard</b> <b>keymap</b> <b>consolefont</b> block <b>mdadm_udev</b> <b>encrypt</b> filesystems fsck)
+</pre>
+<p>See <a href="https://wiki.archlinux.org/title/Dm-crypt/System_configuration#mkinitcpio" title="Dm-crypt/System configuration">dm-crypt/System configuration#mkinitcpio</a> for details.
+</p>
+<p></p><h2 id="Plain_dm-crypt">Plain dm-crypt</h2><p></p>
+<p>Contrary to LUKS, dm-crypt <i>plain</i> mode does not require a header on the encrypted device: this scenario exploits this feature to set up a system on an unpartitioned, encrypted disk that will be indistinguishable from a disk filled with random data, which could allow <a href="https://en.wikipedia.org/wiki/Deniable_encryption" title="wikipedia:Deniable encryption">deniable encryption</a>. See also <a href="https://en.wikipedia.org/wiki/Disk_encryption#Full_disk_encryption" title="wikipedia:Disk encryption">wikipedia:Disk encryption#Full disk encryption</a>.
+</p><p>Note that if full disk encryption is not required, the methods using LUKS described in the sections above are better options for both system encryption and encrypted partitions. <a href="https://wiki.archlinux.org/title/Dm-crypt/Device_encryption#Cryptsetup_actions_specific_for_LUKS" title="Dm-crypt/Device encryption">LUKS features</a> like key management with multiple passphrases/key-files, master key backups or re-encrypting a device in-place are unavailable with <i>plain</i> mode.
+</p><p><i>Plain</i> dm-crypt encryption can be more resilient to damage than LUKS, because it does not rely on an encryption master-key which can be a single-point of failure if damaged or forcefully destroyed. However, using <i>plain</i> mode also requires more manual configuration of encryption options to achieve the same cryptographic strength. See also <a href="https://wiki.archlinux.org/title/Data-at-rest_encryption#Cryptographic_metadata" title="Data-at-rest encryption">Data-at-rest encryption#Cryptographic metadata</a>. Using <i>plain</i> mode could also be considered if concerned with the problems explained in <a href="https://wiki.archlinux.org/title/Dm-crypt/Specialties#Discard/TRIM_support_for_solid_state_drives_(SSD)" title="Dm-crypt/Specialties">dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD)</a>.
+</p>
+<div><p><strong>Tip</strong> If headerless encryption is your goal but you are unsure about the lack of key-derivation with <i>plain</i> mode, then two alternatives are:
+</p><ul><li><a href="https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encrypted_system_using_a_detached_LUKS_header" title="Dm-crypt/Specialties">dm-crypt LUKS mode with a detached header</a> by using the <i>cryptsetup</i> <code>--header</code> option. It cannot be used with the standard <i>encrypt</i> hook, but the hook may be modified.</li>
+<li><a href="https://wiki.archlinux.org/title/Tcplay" title="Tcplay">tcplay</a> which offers headerless encryption but with the PBKDF2 function.</li></ul>
+</div>
+<p>The scenario uses two USB sticks:
+</p>
+<ul><li>one for the boot device, which also allows storing the options required to open/unlock the plain encrypted device in the boot loader configuration, since typing them on each boot would be error prone;</li>
+<li>another for the encryption key file, assuming it stored as raw bits so that to the eyes of an unaware attacker who might get the usbkey the encryption key will appear as random data instead of being visible as a normal file. See also <a href="https://en.wikipedia.org/wiki/Security_through_obscurity" title="wikipedia:Security through obscurity">Wikipedia:Security through obscurity</a>, follow <a href="https://wiki.archlinux.org/title/Dm-crypt/Device_encryption#Keyfiles" title="Dm-crypt/Device encryption">dm-crypt/Device encryption#Keyfiles</a> to prepare the keyfile.</li></ul>
+<p>The disk layout is:
+</p>
+<pre>+----------------------+----------------------+----------------------+ +----------------+ +----------------+
+| Logical volume 1     | Logical volume 2     | Logical volume 3     | | Boot device    | | Encryption key |
+|                      |                      |                      | |                | | file storage   |
+| /                    | [SWAP]               | /home                | | /boot          | | (unpartitioned |
+|                      |                      |                      | |                | | in example)    |
+| /dev/MyVolGroup/root | /dev/MyVolGroup/swap | /dev/MyVolGroup/home | | /dev/sdb1      | | /dev/sdc       |
+|----------------------+----------------------+----------------------| |----------------| |----------------|
+| disk drive /dev/sda encrypted using plain mode and LVM             | | USB stick 1    | | USB stick 2    |
++--------------------------------------------------------------------+ +----------------+ +----------------+
+</pre>
+<div><p><strong>Tip</strong></p><ul><li>It is also possible to use a single USB key physical device:
+<ul><li>By putting the key on another partition (/dev/sdb2) of the USB storage device (/dev/sdb).</li>
+<li>By copying the keyfile to the initramfs directly. An example keyfile <code>/etc/cryptsetup-keys.d/root.key</code> gets copied to the initramfs image by setting <code>FILES=(/etc/cryptsetup-keys.d/root.key)</code> in <code>/etc/mkinitcpio.conf</code>. The way to instruct the <code>encrypt</code> hook to read the keyfile in the initramfs image is using <code>rootfs:</code> prefix before the filename, e.g. <code>cryptkey=rootfs:/etc/cryptsetup-keys.d/root.key</code>.</li></ul></li>
+<li>Another option is using a passphrase with good <a href="https://wiki.archlinux.org/title/Security#Choosing_secure_passwords" title="Security">entropy</a>.</li></ul>
+</div>
+<p></p><h3 id="Preparing_the_disk_5">Preparing the disk</h3><p></p>
+<p>It is vital that the mapped device is filled with random data. In particular this applies to the scenario use case we apply here.
+</p><p>See <a href="https://wiki.archlinux.org/title/Dm-crypt/Drive_preparation" title="Dm-crypt/Drive preparation">dm-crypt/Drive preparation</a> and <a href="https://wiki.archlinux.org/title/Dm-crypt/Drive_preparation#dm-crypt_specific_methods" title="Dm-crypt/Drive preparation">dm-crypt/Drive preparation#dm-crypt specific methods</a>
+</p>
+<p></p><h3 id="Preparing_the_non-boot_partitions">Preparing the non-boot partitions</h3><p></p>
+<p>See <a href="https://wiki.archlinux.org/title/Dm-crypt/Device_encryption#Encryption_options_for_plain_mode" title="Dm-crypt/Device encryption">dm-crypt/Device encryption#Encryption options for plain mode</a> for details.
+</p><p>Using the device <code>/dev/sda</code>, with the aes-xts cipher with a 512 bit key size and using a keyfile we have the following options for this scenario:
+</p>
+<pre># cryptsetup open --type plain --cipher=aes-xts-plain64 --offset=0 --key-file=/dev/sdc --key-size=512 --sector-size 4096 /dev/sda cryptlvm
+</pre>
+<p>Unlike encrypting with LUKS, the above command must be executed <i>in full</i> whenever the mapping needs to be re-established, so it is important to remember the cipher, and key file details.
+</p><p>We can now check a mapping entry has been made for <code>/dev/mapper/cryptlvm</code>:
+</p>
+<pre># fdisk -l
+</pre>
+<div><p><strong>Tip</strong></p><ul><li>A simpler alternative to using LVM, advocated in the cryptsetup FAQ for cases where LVM is not necessary, is to just create a file system on the entirety of the mapped dm-crypt device.</li>
+<li>If a logical volume will be formatted with <a href="https://wiki.archlinux.org/title/Ext4" title="Ext4">ext4</a>, leave at least 256 MiB free space in the volume group to allow using <span title="$ man 8 e2scrub"><a rel="nofollow" href="https://man.archlinux.org/man/e2scrub.8">e2scrub(8)</a></span>. After creating the last volume with <code>-l 100%FREE</code>, this can be accomplished by reducing its size with <code>lvreduce -L -256M MyVolGroup/home</code>.</li></ul>
+</div>
+<p>Next, we setup <a href="https://wiki.archlinux.org/title/LVM" title="LVM">LVM</a> logical volumes on the mapped device. See <a href="https://wiki.archlinux.org/title/Install_Arch_Linux_on_LVM" title="Install Arch Linux on LVM">Install Arch Linux on LVM</a> for further details:
+</p>
+<pre># pvcreate /dev/mapper/cryptlvm
+# vgcreate MyVolGroup /dev/mapper/cryptlvm
+# lvcreate -L 32G MyVolGroup -n root
+# lvcreate -L 4G MyVolGroup -n swap
+# lvcreate -l 100%FREE MyVolGroup -n home
+</pre>
+<p>We format and mount them and activate swap. See <a href="https://wiki.archlinux.org/title/File_systems#Create_a_file_system" title="File systems">File systems#Create a file system</a> for further details:
+</p>
+<pre># mkfs.ext4 /dev/MyVolGroup/root
+# mkfs.ext4 /dev/MyVolGroup/home
+# mount /dev/MyVolGroup/root /mnt
+# mount --mkdir /dev/MyVolGroup/home /mnt/home
+# mkswap /dev/MyVolGroup/swap
+# swapon /dev/MyVolGroup/swap
+</pre>
+<p></p><h3 id="Preparing_the_boot_partition_4">Preparing the boot partition</h3><p></p>
+<p>The <code>/boot</code> partition can be a typical FAT32 formatted partition on a USB stick, if required. But if manual partitioning is needed, then a small 1 GiB partition is all that is required. Create the partition using a <a href="https://wiki.archlinux.org/title/Partitioning#Partitioning_tools" title="Partitioning">partitioning tool</a> of your choice.
+</p><p>Create a <a href="https://wiki.archlinux.org/title/File_system" title="File system">file system</a> on the newly created partition intended for <code>/boot</code>:
+</p>
+<p><strong>Warning</strong> Only format the EFI system partition if you created it during the partitioning step. If there already was an EFI system partition on disk beforehand, reformatting it can destroy the boot loaders of other installed operating systems.</p>
+<pre># mkfs.fat -F32 /dev/sdb1
+# mount --mkdir /dev/sdb1 /mnt/boot
+</pre>
+<p></p><h3 id="Configuring_mkinitcpio_5">Configuring mkinitcpio</h3><p></p>
+<p>Make sure the <span><a rel="nofollow" href="https://archlinux.org/packages/?name=lvm2">lvm2</a></span> package is <a href="https://wiki.archlinux.org/title/Install" title="Install">installed</a>.
+</p><p>If using a busybox-based initramfs, add the <code>keyboard</code>, <code>encrypt</code> and <code>lvm2</code> hooks. If you use a non-US console keymap or a non-default console font, additionally add the <code>keymap</code> and <code>consolefont</code> hooks, respectively.
+</p>
+<pre>HOOKS=(base <b>udev</b> autodetect microcode modconf kms <b>keyboard</b> <b>keymap</b> <b>consolefont</b> block <b>encrypt</b> <b>lvm2</b> filesystems fsck)
+</pre>
+<p><a href="https://wiki.archlinux.org/title/Regenerate_the_initramfs" title="Regenerate the initramfs">Regenerate the initramfs</a> after saving the changes. See <a href="https://wiki.archlinux.org/title/Dm-crypt/System_configuration#mkinitcpio" title="Dm-crypt/System configuration">dm-crypt/System configuration#mkinitcpio</a> for details and other hooks that you may need.
+</p>
+<p></p><h3 id="Configuring_the_boot_loader_4">Configuring the boot loader</h3><p></p>
+<p>In order to boot the encrypted root partition, the following <a href="https://wiki.archlinux.org/title/Kernel_parameters" title="Kernel parameters">kernel parameters</a> need to be set by the boot loader (note that 64 is the number of bytes in 512 bits):
+</p>
+<pre>cryptdevice=/dev/disk/by-id/<i>disk-ID-of-sda</i>:cryptlvm:sector-size=4096 cryptkey=/dev/disk/by-id/<i>disk-ID-of-sdc</i>:0:64 crypto=:aes-xts-plain64:512:0:
+</pre>
+<p>The <code><i>disk-ID-of-<b>disk</b></i></code> refers to the id of the referenced disk. See <a href="https://wiki.archlinux.org/title/Persistent_block_device_naming" title="Persistent block device naming">Persistent block device naming</a> for details.
+</p><p>See <a href="https://wiki.archlinux.org/title/Dm-crypt/System_configuration#Kernel_parameters" title="Dm-crypt/System configuration">dm-crypt/System configuration#Kernel parameters</a> for details and other parameters that you may need.
+</p>
+<div><p><strong>Tip</strong> If using <a href="https://wiki.archlinux.org/title/GRUB" title="GRUB">GRUB</a>, you can install it on the same USB as the <code>/boot</code> partition.
+</p><p>For BIOS:
+</p>
+<pre># grub-install --target=i386-pc --recheck /dev/sdb</pre>
+<p>For UEFI:
+</p>
+<pre># grub-install --target=x86_64-efi --efi-directory=/boot --removable</pre>
+</div>
+<p></p><h3 id="Post-installation">Post-installation</h3><p></p>
+<p>You may wish to remove the USB sticks after booting. Since the <code>/boot</code> partition is not usually needed, the <code>noauto</code> option can be added to the relevant line in <code>/etc/fstab</code>:
+</p>
+<pre>/etc/fstab</pre>
+<pre># /dev/sdb1
+UUID=<i>XXXX-XXXX</i> /boot vfat <b>noauto</b>,rw,noatime 0 2</pre>
+<p>However, when an update to anything used in the initramfs, or a kernel, or the boot loader is required; the <code>/boot</code> partition must be present and mounted. As the entry in <code>fstab</code> already exists, it can be mounted simply with:
+</p>
+<pre># mount /boot
+</pre>
+<p></p><h2 id="Encrypted_boot_partition_(GRUB)"><span id="Encrypted_boot_partition_.28GRUB.29"></span>Encrypted boot partition (GRUB)</h2><p></p>
+<p>This setup utilizes the same partition layout and configuration as the previous <a href="#LVM_on_LUKS">#LVM on LUKS</a> section, with the difference that the <a href="https://wiki.archlinux.org/title/GRUB" title="GRUB">GRUB</a> boot loader is used since it is capable of booting from an LVM logical volume and a LUKS-encrypted <code>/boot</code>. See also <a href="https://wiki.archlinux.org/title/GRUB#Encrypted_/boot" title="GRUB">GRUB#Encrypted /boot</a>.
+</p><p>The disk layout in this example is:
+</p>
+<pre>+---------------------+----------------------+----------------------+----------------------+----------------------+
+| BIOS boot partition | EFI system partition | Logical volume 1     | Logical volume 2     | Logical volume 3     |
+|                     |                      |                      |                      |                      |
+|                     | /efi                 | /                    | [SWAP]               | /home                |
+|                     |                      |                      |                      |                      |
+|                     |                      | /dev/MyVolGroup/root | /dev/MyVolGroup/swap | /dev/MyVolGroup/home |
+| /dev/sda1           | /dev/sda2            |----------------------+----------------------+----------------------+
+| unencrypted         | unencrypted          | /dev/sda3 encrypted using LVM on LUKS                              |
++---------------------+----------------------+--------------------------------------------------------------------+
+</pre>
+<div><p><strong>Tip</strong></p><ul><li>All scenarios are intended as examples. It is, of course, possible to apply both of the two above distinct installation steps with the other scenarios as well. See also the variants linked in <a href="#LVM_on_LUKS">#LVM on LUKS</a>.</li>
+<li>You can use <code>cryptboot</code> script from <span><a rel="nofollow" href="https://aur.archlinux.org/packages/cryptboot/">cryptboot</a></span><sup><small>AUR</small></sup> package for simplified encrypted boot management (mounting, unmounting, upgrading packages) and as a defense against <a rel="nofollow" href="https://www.schneier.com/blog/archives/2009/10/evil_maid_attac.html">Evil Maid</a> attacks with <a href="https://wiki.archlinux.org/title/Secure_Boot#Using_your_own_keys" title="Secure Boot">UEFI Secure Boot</a>. For more information and limitations see <a rel="nofollow" href="https://github.com/kmille/cryptboot">cryptboot project</a> page.</li></ul>
+</div>
+<p></p><h3 id="Preparing_the_disk_6">Preparing the disk</h3><p></p>
+<p>Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in <a href="https://wiki.archlinux.org/title/Dm-crypt/Drive_preparation" title="Dm-crypt/Drive preparation">dm-crypt/Drive preparation</a>.
+</p><p>For <a href="https://wiki.archlinux.org/title/GRUB#UEFI_systems" title="GRUB">UEFI systems</a> create an <a href="https://wiki.archlinux.org/title/EFI_system_partition" title="EFI system partition">EFI system partition</a> with an appropriate size, it will later be mounted at <code>/efi</code>.
+</p><p>For <a href="https://wiki.archlinux.org/title/GRUB#GUID_Partition_Table_(GPT)_specific_instructions" title="GRUB">BIOS/GPT setups</a> create a <a href="https://wiki.archlinux.org/title/BIOS_boot_partition" title="BIOS boot partition">BIOS boot partition</a> with size of 1 MiB for GRUB to store the second stage of BIOS boot loader. Do not mount the partition. For BIOS/MBR setups this is not necessary.
+</p><p>Create a partition of type <code>8309</code>, which will later contain the encrypted container for the LVM.
+</p><p>Create the LUKS encrypted container:
+</p>
+<p><strong>Warning</strong> GRUB's support for LUKS2 is limited; see <a href="https://wiki.archlinux.org/title/GRUB#Encrypted_/boot" title="GRUB">GRUB#Encrypted /boot</a> for details. Use LUKS2 with PBKDF2 (<code>cryptsetup luksFormat --pbkdf pbkdf2</code>) for partitions that GRUB will need to unlock.</p>
+<pre># cryptsetup luksFormat --pbkdf pbkdf2 /dev/sda3
+</pre>
+<p>For more information about the available cryptsetup options see the <a href="https://wiki.archlinux.org/title/Dm-crypt/Device_encryption#Encryption_options_for_LUKS_mode" title="Dm-crypt/Device encryption">LUKS encryption options</a> prior to above command.
+</p><p>Your partition layout should look similar to this:
+</p>
+<pre># gdisk -l /dev/sda</pre>
+<pre>...
+Number  Start (sector)    End (sector)  Size       Code  Name
+   1            2048            4095   1024.0 KiB  EF02  BIOS boot partition
+   2            4096         2101247   1024.0 MiB  EF00  EFI system partition
+   3         2101248        69210111   32.0 GiB    8309  Linux LUKS
+</pre>
+<p>Open the container:
+</p>
+<pre># cryptsetup open /dev/sda3 cryptlvm
+</pre>
+<p>The decrypted container is now available at <code>/dev/mapper/cryptlvm</code>.
+</p>
+<p></p><h3 id="Preparing_the_logical_volumes_3">Preparing the logical volumes</h3><p></p>
+<p>The LVM logical volumes of this example follow the exact layout as the <a href="#LVM_on_LUKS">#LVM on LUKS</a> scenario. Therefore, please follow <a href="#Preparing_the_logical_volumes">#Preparing the logical volumes</a> above and adjust as required.
+</p><p>For UEFI systems, create a mountpoint for the <a href="https://wiki.archlinux.org/title/EFI_system_partition" title="EFI system partition">EFI system partition</a> at <code>/efi</code> for compatibility with <code>grub-install</code> and mount it:
+</p>
+<pre># mount --mkdir /dev/sda2 /mnt/efi
+</pre>
+<p>At this point, you should have the following partitions and logical volumes inside of <code>/mnt</code>:
+</p>
+<pre>$ lsblk</pre>
+<pre>NAME                  MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
+sda                   8:0      0   200G  0 disk
+├─sda1                8:1      0     1M  0 part
+├─sda2                8:2      0   550M  0 part  /mnt/efi
+└─sda3                8:3      0   100G  0 part
+  └─cryptlvm          254:0    0   100G  0 crypt
+    ├─MyVolGroup-swap 254:1    0     4G  0 lvm   [SWAP]
+    ├─MyVolGroup-root 254:2    0    32G  0 lvm   /mnt
+    └─MyVolGroup-home 254:3    0    60G  0 lvm   /mnt/home
+</pre>
+<p>Now at this point resume the common <a href="https://wiki.archlinux.org/title/Installation_guide#Installation" title="Installation guide">Installation guide#Installation</a> steps. Return to this page to customize the <a href="https://wiki.archlinux.org/title/Installation_guide#Initramfs" title="Installation guide">Initramfs</a> and <a href="https://wiki.archlinux.org/title/Installation_guide#Boot_loader" title="Installation guide">Boot loader</a> steps.
+</p>
+<p></p><h3 id="Configuring_mkinitcpio_6">Configuring mkinitcpio</h3><p></p>
+<p>Make sure the <span><a rel="nofollow" href="https://archlinux.org/packages/?name=lvm2">lvm2</a></span> package is <a href="https://wiki.archlinux.org/title/Install" title="Install">installed</a>.
+</p><p>If using the default systemd-based initramfs, add the <code>keyboard</code>, <code>sd-encrypt</code> and <code>lvm2</code> hooks to <a href="https://wiki.archlinux.org/title/Mkinitcpio.conf" title="Mkinitcpio.conf">mkinitcpio.conf</a>. If you use a non-US console keymap or a non-default console font, additionally add the <code>sd-vconsole</code> hook.
+</p>
+<pre>HOOKS=(base <b>systemd</b> autodetect microcode modconf kms <b>keyboard</b> <b>sd-vconsole</b> block <b>sd-encrypt</b> <b>lvm2</b> filesystems fsck)
+</pre>
+<p>If using a busybox-based initramfs, instead add the <code>keyboard</code>, <code>encrypt</code> and <code>lvm2</code> hooks. If you use a non-US console keymap or a non-default console font, additionally add the <code>keymap</code> and <code>consolefont</code> hooks, respectively.
+</p>
+<pre>HOOKS=(base <b>udev</b> autodetect microcode modconf kms <b>keyboard</b> <b>keymap</b> <b>consolefont</b> block <b>encrypt</b> <b>lvm2</b> filesystems fsck)
+</pre>
+<p><a href="https://wiki.archlinux.org/title/Regenerate_the_initramfs" title="Regenerate the initramfs">Regenerate the initramfs</a> after saving the changes. See <a href="https://wiki.archlinux.org/title/Dm-crypt/System_configuration#mkinitcpio" title="Dm-crypt/System configuration">dm-crypt/System configuration#mkinitcpio</a> for details and other hooks that you may need.
+</p>
+<p></p><h3 id="Configuring_GRUB_2">Configuring GRUB</h3><p></p>
+<p>Configure GRUB to allow booting from <code>/boot</code> on a LUKS encrypted partition:
+</p>
+<pre>/etc/default/grub</pre>
+<pre>GRUB_ENABLE_CRYPTODISK=y</pre>
+<p>Set the kernel parameters, so that the initramfs can unlock the encrypted root partition. Using the <code>sd-encrypt</code> hook:
+</p>
+<pre>/etc/default/grub</pre>
+<pre>GRUB_CMDLINE_LINUX="... rd.luks.name=<i>device-UUID</i>=cryptlvm ..."</pre>
+<p>If using the <code>encrypt</code> hook, the following need to be set instead:
+</p>
+<pre>/etc/default/grub</pre>
+<pre>GRUB_CMDLINE_LINUX="... cryptdevice=UUID=<i>device-UUID</i>:cryptlvm ..."</pre>
+<p>See <a href="https://wiki.archlinux.org/title/Dm-crypt/System_configuration#Kernel_parameters" title="Dm-crypt/System configuration">dm-crypt/System configuration#Kernel parameters</a> and <a href="https://wiki.archlinux.org/title/GRUB#Encrypted_/boot" title="GRUB">GRUB#Encrypted /boot</a> for details. The <code><i>device-UUID</i></code> refers to the UUID of the LUKS superblock, in this example it is the UUID of <code>/dev/sda3</code> (the partition which holds the lvm containing the root file system) e.g. <code>a144e931-7580-40bf-ae8c-6beff4c1ac45</code>. See <a href="https://wiki.archlinux.org/title/Persistent_block_device_naming" title="Persistent block device naming">Persistent block device naming</a> for details.
+</p><p><a href="https://wiki.archlinux.org/title/GRUB#Installation_2" title="GRUB">install GRUB</a> to the mounted ESP for UEFI booting:
+</p>
+<pre># grub-install --target=x86_64-efi --efi-directory=/efi --bootloader-id=GRUB --recheck
+</pre>
+<p><a href="https://wiki.archlinux.org/title/GRUB#Installation" title="GRUB">install GRUB</a> to the disk for BIOS booting:
+</p>
+<pre># grub-install --target=i386-pc --recheck /dev/sda
+</pre>
+<p>Generate GRUB's <a href="https://wiki.archlinux.org/title/GRUB#Generate_the_main_configuration_file" title="GRUB">configuration</a> file:
+</p>
+<pre># grub-mkconfig -o /boot/grub/grub.cfg
+</pre>
+<p>If all commands finished without errors, GRUB should prompt for the passphrase to unlock the <code>/dev/sda3</code> partition after the next reboot.
+</p>
+<p></p><h3 id="Avoiding_having_to_enter_the_passphrase_twice">Avoiding having to enter the passphrase twice</h3><p></p>
+
+<p>While GRUB asks for a passphrase to unlock the LUKS encrypted partition after above instructions, the partition unlock is not passed on to the initramfs. Hence, you have to enter the passphrase twice at boot: once for GRUB and once for the initramfs.
+</p><p>This section deals with extra configuration to let the system boot by only entering the passphrase once, in GRUB. This is accomplished by <a href="https://wiki.archlinux.org/title/Dm-crypt/Device_encryption#With_a_keyfile_embedded_in_the_initramfs" title="Dm-crypt/Device encryption">with a keyfile embedded in the initramfs</a>.
+</p><p>First create a keyfile and add it as LUKS key:
+</p>
+<pre># dd bs=512 count=4 if=/dev/random iflag=fullblock | install -m 0600 /dev/stdin /etc/cryptsetup-keys.d/cryptlvm.key
+# cryptsetup -v luksAddKey /dev/sda3 /etc/cryptsetup-keys.d/cryptlvm.key
+</pre>
+<p>Add the keyfile to the initramfs image:
+</p>
+<pre>/etc/mkinitcpio.conf</pre>
+<pre>FILES=(/etc/cryptsetup-keys.d/cryptlvm.key)</pre>
+<p><a href="https://wiki.archlinux.org/title/Regenerate_the_initramfs" title="Regenerate the initramfs">Regenerate the initramfs</a>.
+</p><p>When using the default <a href="https://wiki.archlinux.org/title/Sd-encrypt" title="Sd-encrypt">sd-encrypt</a> hook, <code>/etc/cryptsetup-keys.d/<i>name</i>.key</code> will be used by default, so no additional kernel parameters need to be set.
+</p><p>When using the <code>encrypt</code> hook, set the following kernel parameters to unlock the LUKS partition with the keyfile:
+</p>
+<pre>GRUB_CMDLINE_LINUX="... cryptkey=rootfs:/etc/cryptsetup-keys.d/cryptlvm.key"
+</pre>
+<p>If for some reason the keyfile fails to unlock the boot partition, systemd will fallback to ask for a passphrase to unlock and, in case that is correct, continue booting.
+</p>
+<p><strong>Tip</strong> If you want to encrypt the <code>/boot</code> partition to protect against offline tampering threats, the <a href="https://wiki.archlinux.org/title/Dm-crypt/Specialties#mkinitcpio-chkcryptoboot" title="Dm-crypt/Specialties">mkinitcpio-chkcryptoboot</a> hook has been contributed to help.</p>
+<p></p><h3 id="Using_a_USB_drive_to_unlock_/boot"><span id="Using_a_USB_drive_to_unlock_.2Fboot"></span>Using a USB drive to unlock /boot</h3><p></p>
+<p>To avoid having to memorise a complicated password, or using a simple one which may be guessed, a keyfile stored on an external USB drive can be used to unlock the LUKS volume. For this to be secure, this USB drive must be stored securely away from the computer when not in use.
+</p><p>First, generate a keyfile in the same way as in <a href="#Avoiding_having_to_enter_the_passphrase_twice">#Avoiding having to enter the passphrase twice</a>. Do not use the same keyfile as if the USB drive is lost or compromised you will need to replace the keyfile embedded in initramfs.
+</p><p>Copy this keyfile to your USB drive and create a new GRUB configuration file:
+</p>
+<pre>/boot/grub/grub-pre.cfg</pre>
+<pre>set crypto_uuid=UUID-of-the-luks-volume
+set key_disk=UUID-of-the-volume-with-the-key
+cryptomount -u $crypto_uuid -k ($key_disk)/the-location-of-the-key-on-your-usb
+set root=UUID-of-the-unlocked-volume-as-in-grub.cfg
+set prefix=($root)/boot/grub
+insmod normal
+normal</pre>
+<p>Create a GRUB image and install it (not all of these modules will be needed depending on your file system):
+</p>
+<pre># grub-mkimage -p /boot/grub -O x86_64-efi -c /boot/grub/grub-pre.cfg -o /tmp/grubx64.efi  part_gpt  part_msdos cryptodisk  luks  gcry_rijndael gcry_sha512 lvm ext2 ntfs fat exfat
+# install -v /tmp/grubx64.efi /efi/EFI/GRUB/grubx64.efi
+</pre>
+<p></p><h2 id="Root_on_ZFS">Root on ZFS</h2><p></p>
+<div>
+<p><span><span><img src="https://wiki.archlinux.org/images/0/07/Tango-edit-cut.svg" decoding="async" width="48" height="48"></span></span><b>This article or section is being considered for removal.</b></p>
+<p><b>Reason:</b> There is nothing inherently different in the encryption setup between ZFS on LUKS or plain dm-crypt compared to any other file system on LUKS or plain dm-crypt. ZFS native encryption is out of scope of this article. (Discuss in <a rel="nofollow" href="https://wiki.archlinux.org/title/Talk:Dm-crypt/Encrypting_an_entire_system">Talk:Dm-crypt/Encrypting an entire system</a>)</p>
+</div>
+<p>To use dm-crypt with <a href="https://wiki.archlinux.org/title/ZFS" title="ZFS">ZFS</a>, see <a href="https://wiki.archlinux.org/title/ZFS#Encryption_in_ZFS_using_dm-crypt" title="ZFS">ZFS#Encryption in ZFS using dm-crypt</a>.
+</p><p>Additionally, ZFS features <a href="https://wiki.archlinux.org/title/ZFS#Native_encryption" title="ZFS">native encryption</a>, which may also be utilized to encrypt the system root, excluding the boot loader and file system metadata. See:
+</p>
+<ul><li><a rel="nofollow" href="https://openzfs.github.io/openzfs-docs/Getting%20Started/Arch%20Linux/Root%20on%20ZFS.html">Arch Linux Root on ZFS</a> guide on the OpenZFS page,</li>
+<li><a href="https://wiki.archlinux.org/title/Install_Arch_Linux_on_ZFS" title="Install Arch Linux on ZFS">Install Arch Linux on ZFS</a>.</li></ul>
+<p>After the installation, a boot loader can be verified with <a href="https://wiki.archlinux.org/title/Secure_Boot" title="Secure Boot">Secure Boot</a> on UEFI-based systems.
+</p>
+
+
+
+
+</div></div>

KaraKeep/attachments/bc1e8b42-d238-4476-867c-052d1446edde-systemd-cryptenroll-ArchWiki.jpg

@@ -0,0 +1,136 @@
+<div id="readability-page-1" class="page"><div lang="en" dir="ltr" id="mw-content-text">
+
+<p>From <span title="$ man 1 systemd-cryptenroll"><a rel="nofollow" href="https://man.archlinux.org/man/systemd-cryptenroll.1">systemd-cryptenroll(1)</a></span>:
+</p>
+<dl><dd>systemd-cryptenroll is a tool for enrolling hardware security tokens and devices into a LUKS2 encrypted volume, which may then be used to unlock the volume during boot.</dd></dl>
+<p><i>systemd-cryptenroll</i> allows enrolling <a href="https://wiki.archlinux.org/title/Smartcards" title="Smartcards">smartcards</a>, <a href="https://wiki.archlinux.org/title/Universal_2nd_Factor" title="Universal 2nd Factor">FIDO2</a> tokens and <a href="https://wiki.archlinux.org/title/Trusted_Platform_Module" title="Trusted Platform Module">Trusted Platform Module</a> security chips into <a href="https://wiki.archlinux.org/title/LUKS" title="LUKS">LUKS</a> devices, as well as regular passphrases. These devices are later unlocked by <span title="$ man 8 systemd-cryptsetup@.service"><a rel="nofollow" href="https://man.archlinux.org/man/systemd-cryptsetup%40.service.8">systemd-cryptsetup@.service(8)</a></span>, using the enrolled tokens.
+</p>
+
+<p></p><h2 id="Installation">Installation</h2><p></p>
+<p><i>systemd-cryptenroll</i> is part of and packaged with <span><a rel="nofollow" href="https://archlinux.org/packages/?name=systemd">systemd</a></span>. However, extra packages are required to use hardware devices as keys:
+</p>
+<ul><li>To use PKCS#11 tokens, <a href="https://wiki.archlinux.org/title/Install" title="Install">install</a> <span><a rel="nofollow" href="https://archlinux.org/packages/?name=libp11-kit">libp11-kit</a></span>, you may also need <span><a rel="nofollow" href="https://archlinux.org/packages/?name=opensc">opensc</a></span> and <span><a rel="nofollow" href="https://aur.archlinux.org/packages/opensc-p11-kit-module/">opensc-p11-kit-module</a></span><sup><small>AUR</small></sup><sup>[<a href="https://wiki.archlinux.org/title/Help:Procedures#Fix_broken_package_links" title="Help:Procedures">broken link</a>: package not found]</sup>.</li>
+<li>To use FIDO2 tokens, install <span><a rel="nofollow" href="https://archlinux.org/packages/?name=libfido2">libfido2</a></span>.</li>
+<li>To use TPM2 devices, install <span><a rel="nofollow" href="https://archlinux.org/packages/?name=tpm2-tss">tpm2-tss</a></span>.</li></ul>
+<p></p><h2 id="List_keyslots">List keyslots</h2><p></p>
+<p><i>systemd-cryptenroll</i> can list the keyslots in a LUKS device, similar to <code>cryptsetup</code> <a href="https://wiki.archlinux.org/title/Dm-crypt/Device_encryption#Key_management" title="Dm-crypt/Device encryption">luksDump</a>, but in a more user-friendly format.
+</p>
+<pre># systemd-cryptenroll /dev/<i>disk</i></pre>
+<pre>SLOT TYPE    
+   0 password
+   1 recovery
+   2 tpm2
+</pre>
+<p></p><h2 id="Erasing_keyslots">Erasing keyslots</h2><p></p>
+<pre># systemd-cryptenroll /dev/<i>disk</i> --wipe-slot=<i>SLOT</i>
+</pre>
+<p>Where <i>SLOT</i> can be:
+</p>
+<ul><li>A single keyslot index, as represented in <a href="#List_keyslots">#List keyslots</a></li>
+<li>A type of keyslot, which will erase all keyslots of that type. Valid types are <code>empty</code>, <code>password</code>, <code>recovery</code>, <code>pkcs11</code>, <code>fido2</code>, <code>tpm2</code></li>
+<li>A combination of all of the above, separated by commas</li>
+<li>The string <code>all</code>, which erases all keyslots on the device. This option can only be used when enrolling another device or passphrase at the same time.</li></ul>
+<p>The <code>--wipe-slot</code> operation can be used in combination with all enrollment options, which is useful to update existing device enrollments:
+</p>
+<pre># systemd-cryptenroll /dev/<i>disk</i> --wipe-slot=fido2 --fido2-device=auto
+</pre>
+<p></p><h2 id="Enrolling_passphrases">Enrolling passphrases</h2><p></p>
+<p></p><h3 id="Regular_password">Regular password</h3><p></p>
+<p>This is equivalent to <code>cryptsetup luksAddKey</code>.
+</p>
+<pre># systemd-cryptenroll /dev/<i>disk</i> --password
+</pre>
+<p></p><h3 id="Recovery_key">Recovery key</h3><p></p>
+<p>From <span title="$ man 1 systemd-cryptenroll"><a rel="nofollow" href="https://man.archlinux.org/man/systemd-cryptenroll.1">systemd-cryptenroll(1)</a></span>:
+</p>
+<dl><dd>Recovery keys are mostly identical to passphrases, but are computer-generated instead of being chosen by a human, and thus have a guaranteed high entropy. The key uses a character set that is easy to type in, and may be scanned off screen via a QR code.</dd></dl>
+<p>A recovery key is designed to be used as a fallback if the hardware tokens are unavailable, and can be used in place of regular passphrases whenever they are required.
+</p>
+<pre># systemd-cryptenroll /dev/<i>disk</i> --recovery-key
+</pre>
+<p></p><h2 id="Enrolling_hardware_devices">Enrolling hardware devices</h2><p></p>
+<p>The <code>--<i>type</i>-device</code> options must point to a valid device path of their respective type. A list of available devices can be obtained by passing the <code>list</code> argument to this option. Alternatively, if you only have a single device of the desired type connected, the <code>auto</code> option can be used to automatically select it.
+</p>
+
+<p></p><h3 id="PKCS#11_tokens_or_smartcards"><span id="PKCS.2311_tokens_or_smartcards"></span>PKCS#11 tokens or smartcards</h3><p></p>
+<p>The token or smartcard must contain a RSA key pair, which will be used to encrypt the generated key that will be used to unlock the volume.
+</p>
+<pre># systemd-cryptenroll /dev/<i>disk</i> --pkcs11-token-uri=<i>device</i>
+</pre>
+<p></p><h3 id="FIDO2_tokens">FIDO2 tokens</h3><p></p>
+<p>Any FIDO2 token that supports the "hmac-secret" extension can be used with <i>systemd-cryptenroll</i>. The following example would enroll a FIDO2 token to an encrypted LUKS2 block device, requiring only user presence as authentication.
+</p>
+<pre># systemd-cryptenroll /dev/<i>disk</i> --fido2-device=<i>device</i> --fido2-with-client-pin=no
+</pre>
+<p>In addition, <i>systemd-cryptenroll</i> supports using the token's built-in user verification methods:
+</p>
+<ul><li><code>--fido2-with-user-presence</code> defines whether to verify the user presence (i.e. by tapping the token) before unlocking, defaults to yes</li>
+<li><code>--fido2-with-user-verification</code> defines whether to require user verification before unlocking, defaults to no</li></ul>
+<div><p><strong>Note</strong></p><ul><li>These options will have no effect if the token does not support these features.</li>
+<li>See <a rel="nofollow" href="https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Guide/User_Presence_vs_User_Verification.html">User Presence vs User Verification</a> for more information on the difference between the two.</li></ul>
+</div>
+<p>By default, the cryptographic algorithm used when generating a FIDO2 credential is <i>es256</i> which denotes Elliptic Curve Digital Signature Algorithm (ECDSA) over NIST P-256 with SHA-256. If desired and provided by the FIDO2 token, a different cryptographic algorithm can be specified during enrollment.
+</p>
+<p><strong>Note</strong> This may also be desirable for those concerned with ECDSA. See <a href="https://wiki.archlinux.org/title/SSH_keys#ECDSA" title="SSH keys">SSH keys#ECDSA</a> for details.</p>
+<p>Suppose that a previous FIDO2 token has already been enrolled and the user wishes to enroll another, the following generates an <i>eddsa</i> credential which denotes <a rel="nofollow" href="https://datatracker.ietf.org/doc/html/rfc8032">EdDSA</a> over Curve25519 with SHA-512 and authenticates the device with a previous enrolled token instead of a password.
+</p>
+<pre># systemd-cryptenroll /dev/<i>disk</i> --fido2-device=<i>device</i> --fido2-credential-algorithm=eddsa --unlock-fido2-device=auto
+</pre>
+<p><strong>Note</strong> Both tokens must be plugged in to the system for successful enrollment.</p>
+<p></p><h3 id="Trusted_Platform_Module">Trusted Platform Module</h3><p></p>
+<div>
+<p><span><span><img src="https://wiki.archlinux.org/images/1/19/Tango-view-fullscreen.svg" decoding="async" width="48" height="48"></span></span><b>This article or section needs expansion.</b></p>
+<p><b>Reason:</b> Document <code>--tpm2-seal-key-handle</code> <code>--tpm2-device-key</code> <code>--tpm2-pcrlock</code> (Discuss in <a rel="nofollow" href="https://wiki.archlinux.org/title/Talk:Systemd-cryptenroll">Talk:Systemd-cryptenroll</a>)</p>
+</div>
+<p><i>systemd-cryptenroll</i> has native support for enrolling LUKS keys in TPMs. It requires the following:
+</p>
+<ul><li><span><a rel="nofollow" href="https://archlinux.org/packages/?name=tpm2-tss">tpm2-tss</a></span> must be <a href="https://wiki.archlinux.org/title/Install" title="Install">installed</a>,</li>
+<li>A LUKS2 device (currently the default type used by <a href="https://wiki.archlinux.org/title/Cryptsetup" title="Cryptsetup">cryptsetup</a>),</li>
+<li>If you intend to use this method on your root partition, some tweaks need to be made to the <a href="https://wiki.archlinux.org/title/Initramfs" title="Initramfs">initramfs</a> (see <a href="https://wiki.archlinux.org/title/Dm-crypt/System_configuration#Using_systemd-cryptsetup-generator" title="Dm-crypt/System configuration">dm-crypt/System configuration#Using systemd-cryptsetup-generator</a> for advanced configuration)&nbsp;:
+<ul><li><a href="https://wiki.archlinux.org/title/Mkinitcpio" title="Mkinitcpio">mkinitcpio</a> users: enable the <code>systemd</code> and <code>sd-encrypt</code> <a href="https://wiki.archlinux.org/title/Mkinitcpio#HOOKS" title="Mkinitcpio">hooks</a>. </li>
+<li><a href="https://wiki.archlinux.org/title/Dracut" title="Dracut">dracut</a> users: enable the <code>tpm2-tss</code> <a href="https://wiki.archlinux.org/title/Dracut#dracut_modules" title="Dracut">module</a>.</li></ul></li></ul>
+<p>To begin, run the following command to list your installed TPMs and the driver in use:
+</p>
+<pre>$ systemd-cryptenroll --tpm2-device=list
+</pre>
+<div><p><strong>Tip</strong></p><ul><li>If your computer has multiple TPMs installed, specify the one you wish to use with <code>--tpm2-device=<i>/path/to/tpm2_device</i></code> in the following steps.</li>
+<li>Consider using <a href="https://wiki.archlinux.org/title/Trusted_Platform_Module#PCR_policies" title="Trusted Platform Module">PCR policies</a> instead of binding secrets to raw PCR values.</li></ul></div>
+<p>A key may be enrolled in both the TPM and the LUKS volume using only one command. The following example generates a new random key, adds it to the volume so it can be used to unlock it in addition to the existing keys, and binds this new key to PCR 7 (<a href="https://wiki.archlinux.org/title/Secure_Boot" title="Secure Boot">Secure Boot</a> state):
+</p>
+<pre># systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 /dev/<i>sdX</i>
+</pre>
+<p>where <code>/dev/<i>sdX</i></code> is the full path to the encrypted LUKS volume. Use <code>--unlock-key-file=<i>/path/to/keyfile</i></code> if the LUKS volume is unlocked by a keyfile instead of a passphrase.
+</p><p>Refer to <span title="$ man 1 systemd-cryptenroll"><a rel="nofollow" href="https://man.archlinux.org/man/systemd-cryptenroll.1">systemd-cryptenroll(1)</a></span> and <a href="https://wiki.archlinux.org/title/Trusted_Platform_Module#Accessing_PCR_registers" title="Trusted Platform Module">Trusted Platform Module#Accessing PCR registers</a> for common PCR measurements in Linux. Adjust <code>--tpm2-pcrs=7</code> as necessary (parameters are separated by the <code>+</code> symbol).
+</p>
+<div><p><strong>Warning</strong></p><ul><li>Make sure <a href="https://wiki.archlinux.org/title/Secure_Boot" title="Secure Boot">Secure Boot</a> is active and in user mode when binding to PCR 7, otherwise, unauthorized boot devices could unlock the encrypted volume.</li>
+<li>The state of PCR 7 can change if firmware certificates change, which can risk locking the user out. This can be implicitly done by <a href="https://wiki.archlinux.org/title/Fwupd" title="Fwupd">fwupd</a><a rel="nofollow" href="https://github.com/systemd/systemd/blob/ed272a9ff59a26beedaab508dd3c9d631de67165/TODO#L664-L673">[1]</a> or explicitly by rotating Secure Boot keys.</li>
+<li>Only binding to PCRs measured pre-boot (PCRs 0-7) opens a vulnerability from rogue operating systems. A rogue partition with metadata copied from the real root filesystem (such as partition UUID) can mimic the original partition. Then, initramfs will attempt to mount the rogue partition as the root filesystem (decryption failure will fall back to password entry), leaving pre-boot PCRs unchanged. The rogue root filesystem with files controlled by an attacker is still able to receive the decryption key for the real root partition. See <a rel="nofollow" href="https://0pointer.net/blog/brave-new-trusted-boot-world.html">Brave New Trusted Boot World</a> and <a rel="nofollow" href="https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/countermeasures">BitLocker documentation</a> for additional information.</li>
+<li>A solution for the root volume is to bind to an empty PCR 15 using <code>--tpm2-pcrs=<i>other_pcrs</i>+15:sha256=0000000000000000000000000000000000000000000000000000000000000000</code>. If you set any <code>rd.luks</code> kernel parameters or use <code>/etc/crypttab.initramfs</code>, additionally add the <code>tpm2-measure-pcr=yes</code> option to <code>rd.luks.options=</code> or the fourth field in <code>/etc/crypttab.initramfs</code>; this is not required when relying on <a href="https://wiki.archlinux.org/title/Systemd#GPT_partition_automounting" title="Systemd">GPT partition automounting</a>. After the root volume is unlocked in early userspace, PCR 15 will change and the enrolled key will no longer be retrievable.</li>
+<li>Another cleaner solution is described in the <a href="https://wiki.archlinux.org/title/Dm-crypt/System_configuration#Pinning_a_LUKS_Volume" title="Dm-crypt/System configuration">Pinning a LUKS volume</a> section.</li></ul>
+</div>
+<p>The combination of PCRs to bind to depends on the individual case to balance usability and lock-down. For example, you may require UEFI firmware updates without manual intervention to the <a href="https://wiki.archlinux.org/title/Secure_Boot" title="Secure Boot">Secure Boot</a> state, or different boot devices. As another example, Microsoft's <a rel="nofollow" href="https://learn.microsoft.com/en-us/windows-hardware/test/hlk/testref/954cf796-a640-4134-b742-eaf0ed2663ff#troubleshooting">Bitlocker</a> prefers PCR <code>7+11</code>, but may also use other PCR combinations.
+</p>
+<div><p><strong>Note</strong></p><ul><li>It is possible to require a PIN to be entered in addition to the TPM state being correct. Simply add the option <code>--tpm2-with-pin=yes</code> to the command above and enter the PIN when prompted.</li>
+<li><i>systemd-cryptenroll</i> does not check the TPM measurement before asking for the PIN, therefore consider using a unique PIN since the environment may be untrustworthy.</li></ul>
+</div>
+<p>To check that the new key was enrolled, dump the LUKS configuration and look for a <code>systemd-tpm2</code> token entry, as well as an additional entry in the <i>Keyslots</i> section:
+</p>
+<pre># cryptsetup luksDump /dev/sdX
+</pre>
+<p>To test that the key works, run the following command while the LUKS volume is closed:
+</p>
+<pre># systemd-cryptsetup attach <i>mapping_name</i> /dev/<i>sdX</i> none tpm2-device=auto
+</pre>
+<p>where <code><i>mapping_name</i></code> is your chosen name for the volume once opened.
+</p><p>See <a href="https://wiki.archlinux.org/title/Dm-crypt/System_configuration#crypttab" title="Dm-crypt/System configuration">dm-crypt/System configuration#crypttab</a> and <a href="https://wiki.archlinux.org/title/Dm-crypt/System_configuration#Trusted_Platform_Module_and_FIDO2_keys" title="Dm-crypt/System configuration">dm-crypt/System configuration#Trusted Platform Module and FIDO2 keys</a> in order to unlock the volume at boot time.
+</p>
+<p><strong>Note</strong> While you may specify the UUID of your LUKS volume in place of the pathname in <code>/etc/crypttab</code>, the <i>systemd-cryptenroll</i> command itself currently only supports path names.</p>
+<p>See <span title="$ man 1 systemd-cryptenroll"><a rel="nofollow" href="https://man.archlinux.org/man/systemd-cryptenroll.1">systemd-cryptenroll(1)</a></span> and <span title="$ man 5 crypttab"><a rel="nofollow" href="https://man.archlinux.org/man/crypttab.5">crypttab(5)</a></span> for more information and examples.
+</p>
+<p></p><h2 id="See_also">See also</h2><p></p>
+<ul><li><a rel="nofollow" href="https://0pointer.net/blog/unlocking-luks2-volumes-with-tpm2-fido2-pkcs11-security-hardware-on-systemd-248.html">Lennart's blog: Unlocking LUKS2 volumes with TPM2, FIDO2, PKCS#11 Security Hardware on systemd 248</a></li></ul>
+
+
+
+
+</div></div>

KaraKeep/attachments/f93a1a22-509f-403f-9a1d-6c11393b02b9-login(3)-Linux-manual-page.jpg

@@ -0,0 +1,270 @@
+<div id="readability-page-1" class="page">
+
+
+
+    
+
+<hr>
+
+
+
+
+
+
+
+
+<pre><span><i>SD-LOGIN</i>(3)                      sd-login                     <i>SD-LOGIN</i>(3)</span>
+</pre>
+<h2><a id="NAME" href="#NAME"></a>NAME  &nbsp; &nbsp; &nbsp; &nbsp; <a href="#top_of_page"><span>top</span></a></h2><pre>       sd-login - APIs for tracking logins
+</pre>
+<h2><a id="SYNOPSIS" href="#SYNOPSIS"></a>SYNOPSIS  &nbsp; &nbsp; &nbsp; &nbsp; <a href="#top_of_page"><span>top</span></a></h2><pre>       <b>#include &lt;systemd/sd-login.h&gt;</b>
+
+       <b>pkg-config --cflags --libs libsystemd</b>
+</pre>
+<h2><a id="DESCRIPTION" href="#DESCRIPTION"></a>DESCRIPTION  &nbsp; &nbsp; &nbsp; &nbsp; <a href="#top_of_page"><span>top</span></a></h2><pre>       sd-login.h is part of <a href="https://www.man7.org/linux/man-pages/man3/libsystemd.3.html">libsystemd(3)</a> and provides APIs to
+       introspect and monitor seat, login session, and user status
+       information on the local system.
+
+       Note that these APIs only allow purely passive access and
+       monitoring of seats, sessions, and users. To actively make changes
+       to the seat configuration, terminate login sessions, or switch
+       session on a seat you need to utilize the D-Bus API of
+       systemd-logind instead.
+
+       These functions synchronously access data in /proc/,
+       /sys/fs/cgroup/ and /run/. All of these are virtual file systems,
+       hence the runtime cost of the accesses is relatively cheap.
+
+       It is possible (and often a very good choice) to mix calls to the
+       synchronous interface of sd-login.h with the asynchronous D-Bus
+       interface of systemd-logind. However, if this is done you need to
+       think a bit about possible races since the stream of events from
+       D-Bus and from sd-login.h interfaces such as the login monitor are
+       asynchronous and not ordered against each other.
+
+       If the functions return string arrays, these are generally
+       <b>NULL</b>-terminated and need to be freed by the caller with the libc
+       <a href="https://www.man7.org/linux/man-pages/man3/free.3.html">free(3)</a> call after use, including the strings referenced therein.
+       Similarly, individual strings returned need to be freed, as well.
+
+       As a special exception, instead of an empty string array <b>NULL </b>may
+       be returned, which should be treated equivalent to an empty string
+       array.
+
+       See <a href="https://www.man7.org/linux/man-pages/man3/sd_pid_get_session.3.html">sd_pid_get_session(3)</a>, <a href="https://www.man7.org/linux/man-pages/man3/sd_uid_get_state.3.html">sd_uid_get_state(3)</a>,
+       <a href="https://www.man7.org/linux/man-pages/man3/sd_session_is_active.3.html">sd_session_is_active(3)</a>, <a href="https://www.man7.org/linux/man-pages/man3/sd_seat_get_active.3.html">sd_seat_get_active(3)</a>, <a href="https://www.man7.org/linux/man-pages/man3/sd_get_seats.3.html">sd_get_seats(3)</a>,
+       <a href="https://www.man7.org/linux/man-pages/man3/sd_login_monitor_new.3.html">sd_login_monitor_new(3)</a> for more information about the functions
+       implemented.
+</pre>
+<h2><a id="DEFINITION_OF_TERMS" href="#DEFINITION_OF_TERMS"></a>DEFINITION OF TERMS  &nbsp; &nbsp; &nbsp; &nbsp; <a href="#top_of_page"><span>top</span></a></h2><pre>       seat
+           A seat consists of all hardware devices assigned to a specific
+           workplace. It consists of at least one graphics device, and
+           usually also includes keyboard, mouse. It can also include
+           video cameras, sound cards and more. Seats are identified by
+           seat names, which are strings (&lt;= 255 characters), that start
+           with the four characters "seat" followed by at least one
+           character from the range [a-zA-Z0-9], "_" and "-". They are
+           suitable for use as file names. Seat names may or may not be
+           stable and may be reused if a seat becomes available again.
+
+           Added in version 235.
+
+       session
+           A session is defined by the time a user is logged in until
+           they log out. A session is bound to one or no seats (the
+           latter for 'virtual' ssh logins). Multiple sessions can be
+           attached to the same seat, but only one of them can be active,
+           the others are in the background. A session is identified by a
+           short string.
+
+           <a href="https://www.man7.org/linux/man-pages/man1/systemd.1.html">systemd(1)</a> ensures that audit sessions are identical to
+           systemd sessions, and uses the audit session ID as session ID
+           in systemd (if auditing is enabled). In general the session
+           identifier is a short string consisting only of [a-zA-Z0-9],
+           "_" and "-", suitable for use as a file name. Session IDs are
+           unique on the local machine and are never reused as long as
+           the machine is online. A user (the way we know it on UNIX)
+           corresponds to the person using a computer. A single user can
+           have multiple sessions open at the same time. A user is
+           identified by a numeric user id (UID) or a user name (a
+           string). A multi-session system allows multiple user sessions
+           on the same seat at the same time. A multi-seat system allows
+           multiple independent seats that can be individually and
+           simultaneously used by different users.
+
+           Added in version 235.
+
+       All hardware devices that are eligible to being assigned to a
+       seat, are assigned to one. A device can be assigned to only one
+       seat at a time. If a device is not assigned to any particular
+       other seat it is implicitly assigned to the special default seat
+       called "seat0".
+
+       Note that hardware like printers, hard disks or network cards is
+       generally not assigned to a specific seat. They are available to
+       all seats equally. (Well, with one exception: USB sticks can be
+       assigned to a seat.)
+
+       "seat0" always exists.
+</pre>
+<h2><a id="UDEV_RULES" href="#UDEV_RULES"></a>UDEV RULES  &nbsp; &nbsp; &nbsp; &nbsp; <a href="#top_of_page"><span>top</span></a></h2><pre>       Assignment of hardware devices to seats is managed inside the udev
+       database, via settings on the devices:
+
+       Tag "seat"
+           When set, a device is eligible to be assigned to a seat. This
+           tag is set for graphics devices, mice, keyboards, video cards,
+           sound cards and more. Note that some devices like sound cards
+           consist of multiple subdevices (i.e. a PCM for input and
+           another one for output). This tag will be set only for the
+           originating device, not for the individual subdevices. A UI
+           for configuring assignment of devices to seats should
+           enumerate and subscribe to all devices with this tag set and
+           show them in the UI. Note that USB hubs can be assigned to a
+           seat as well, in which case all (current and future) devices
+           plugged into it will also be assigned to the same seat (unless
+           they are explicitly assigned to another seat).
+
+           Added in version 235.
+
+       Tag "master-of-seat"
+           When set, this device is enough for a seat to be considered
+           existent. This tag is usually set for the framebuffer device
+           of graphics cards. A seat hence consists of an arbitrary
+           number of devices marked with the "seat" tag, but (at least)
+           one of these devices needs to be tagged with "master-of-seat"
+           before the seat is actually considered to be around.
+
+           Added in version 235.
+
+       Property <i>ID_SEAT</i>
+           This property specifies the name of the seat a specific device
+           is assigned to. If not set the device is assigned to "seat0".
+           Also, to speed up enumeration of hardware belonging to a
+           specific seat, the seat is also set as tag on the device. I.e.
+           if the property <i>ID_SEAT=seat-waldo</i> is set for a device, the
+           tag "seat-waldo" will be set as well. Note that if a device is
+           assigned to "seat0", it will usually not carry such a tag and
+           you need to enumerate all devices and check the <i>ID_SEAT</i>
+           property manually. Again, if a device is assigned to seat0
+           this is visible on the device in two ways: with a property
+           <i>ID_SEAT=seat0</i> and with no property <i>ID_SEAT</i> set for it at all.
+
+           Added in version 235.
+
+       Property <i>ID_AUTOSEAT</i>
+           When set to "1", this device automatically generates a new and
+           independent seat, which is named after the path of the device.
+           This is set for specialized USB hubs like the Pluggable
+           devices, which when plugged in should create a hotplug seat
+           without further configuration.
+
+           Added in version 235.
+
+       Property <i>ID_FOR_SEAT</i>
+           When creating additional (manual) seats starting from a
+           graphics device this is a good choice to name the seat after.
+           It is created from the path of the device. This is useful in
+           UIs for configuring seats: as soon as you create a new seat
+           from a graphics device, read this property and prefix it with
+           "seat-" and use it as name for the seat.
+
+           Added in version 235.
+
+       A seat exists only and exclusively because a properly tagged
+       device with the right <i>ID_SEAT</i> property exists. Besides udev rules
+       there is no persistent data about seats stored on disk.
+
+       Note that <a href="https://www.man7.org/linux/man-pages/man8/systemd-logind.8.html">systemd-logind(8)</a> manages ACLs on a number of device
+       classes, to allow user code to access the device nodes attached to
+       a seat as long as the user has an active session on it. This is
+       mostly transparent to applications. As mentioned above, for
+       certain user software it might be a good idea to watch whether
+       they can access device nodes instead of thinking about seats.
+</pre>
+<h2><a id="NOTES" href="#NOTES"></a>NOTES  &nbsp; &nbsp; &nbsp; &nbsp; <a href="#top_of_page"><span>top</span></a></h2><pre>       Functions described here are available as a shared library, which
+       can be compiled against and linked to with the
+       <b>libsystemd pkg-config</b>(1) file.
+
+       The code described here uses <a href="https://www.man7.org/linux/man-pages/man3/getenv.3.html">getenv(3)</a>, which is declared to be
+       not multi-thread-safe. This means that the code calling the
+       functions described here must not call <a href="https://www.man7.org/linux/man-pages/man3/setenv.3.html">setenv(3)</a> from a parallel
+       thread. It is recommended to only do calls to <b>setenv() </b>from an
+       early phase of the program when no other threads have been
+       started.
+</pre>
+<h2><a id="SEE_ALSO" href="#SEE_ALSO"></a>SEE ALSO  &nbsp; &nbsp; &nbsp; &nbsp; <a href="#top_of_page"><span>top</span></a></h2><pre>       <a href="https://www.man7.org/linux/man-pages/man1/systemd.1.html">systemd(1)</a>, <a href="https://www.man7.org/linux/man-pages/man3/sd_pid_get_session.3.html">sd_pid_get_session(3)</a>, <a href="https://www.man7.org/linux/man-pages/man3/sd_uid_get_state.3.html">sd_uid_get_state(3)</a>,
+       <a href="https://www.man7.org/linux/man-pages/man3/sd_session_is_active.3.html">sd_session_is_active(3)</a>, <a href="https://www.man7.org/linux/man-pages/man3/sd_seat_get_active.3.html">sd_seat_get_active(3)</a>, <a href="https://www.man7.org/linux/man-pages/man3/sd_get_seats.3.html">sd_get_seats(3)</a>,
+       <a href="https://www.man7.org/linux/man-pages/man3/sd_login_monitor_new.3.html">sd_login_monitor_new(3)</a>, <a href="https://www.man7.org/linux/man-pages/man3/sd-daemon.3.html">sd-daemon(3)</a>, <b>pkg-config</b>(1)
+
+       <b>Multi-Seat on Linux</b><b></b>[1] may also be of historical interest.
+</pre>
+<h2><a id="NOTES" href="#NOTES"></a>NOTES  &nbsp; &nbsp; &nbsp; &nbsp; <a href="#top_of_page"><span>top</span></a></h2><pre>        1. Multi-Seat on Linux
+           <a href="https://www.freedesktop.org/wiki/Software/systemd/multiseat">https://www.freedesktop.org/wiki/Software/systemd/multiseat</a>
+</pre>
+<h2><a id="COLOPHON" href="#COLOPHON"></a>COLOPHON  &nbsp; &nbsp; &nbsp; &nbsp; <a href="#top_of_page"><span>top</span></a></h2><pre>       This page is part of the <i>systemd</i> (systemd system and service
+       manager) project.  Information about the project can be found at
+       ⟨<a href="http://www.freedesktop.org/wiki/Software/systemd">http://www.freedesktop.org/wiki/Software/systemd</a>⟩.  If you have a
+       bug report for this manual page, see
+       ⟨<a href="http://www.freedesktop.org/wiki/Software/systemd/#bugreports">http://www.freedesktop.org/wiki/Software/systemd/#bugreports</a>⟩.
+       This page was obtained from the project's upstream Git repository
+       ⟨<a href="https://github.com/systemd/systemd.git">https://github.com/systemd/systemd.git</a>⟩ on 2026-01-16.  (At that
+       time, the date of the most recent commit that was found in the
+       repository was 2026-01-16.)  If you discover any rendering
+       problems in this HTML version of the page, or you believe there is
+       a better or more up-to-date source for the page, or you have
+       corrections or improvements to the information in this COLOPHON
+       (which is <i>not</i> part of the original manual page), send a mail to
+       man-pages@man7.org
+
+<span>systemd 260~devel                                             <i>SD-LOGIN</i>(3)</span>
+</pre>
+
+<hr>
+<p>Pages that refer to this page:
+    <a href="https://www.man7.org/linux/man-pages/man3/libsystemd.3.html">libsystemd(3)</a>,&nbsp;
+    <a href="https://www.man7.org/linux/man-pages/man3/sd_get_seats.3.html">sd_get_seats(3)</a>,&nbsp;
+    <a href="https://www.man7.org/linux/man-pages/man3/sd_login_monitor_new.3.html">sd_login_monitor_new(3)</a>,&nbsp;
+    <a href="https://www.man7.org/linux/man-pages/man3/sd_machine_get_class.3.html">sd_machine_get_class(3)</a>,&nbsp;
+    <a href="https://www.man7.org/linux/man-pages/man3/sd_pid_get_owner_uid.3.html">sd_pid_get_owner_uid(3)</a>,&nbsp;
+    <a href="https://www.man7.org/linux/man-pages/man3/sd_seat_get_active.3.html">sd_seat_get_active(3)</a>,&nbsp;
+    <a href="https://www.man7.org/linux/man-pages/man3/sd_session_is_active.3.html">sd_session_is_active(3)</a>,&nbsp;
+    <a href="https://www.man7.org/linux/man-pages/man3/sd_uid_get_state.3.html">sd_uid_get_state(3)</a>,&nbsp;
+    <a href="https://www.man7.org/linux/man-pages/man5/org.freedesktop.login1.5.html">org.freedesktop.login1(5)</a>,&nbsp;
+    <a href="https://www.man7.org/linux/man-pages/man7/systemd.directives.7.html">systemd.directives(7)</a>,&nbsp;
+    <a href="https://www.man7.org/linux/man-pages/man7/systemd.index.7.html">systemd.index(7)</a>,&nbsp;
+    <a href="https://www.man7.org/linux/man-pages/man8/systemd-logind.service.8.html">systemd-logind.service(8)</a>,&nbsp;
+    <a href="https://www.man7.org/linux/man-pages/man8/systemd-machined.service.8.html">systemd-machined.service(8)</a>
+</p>
+<hr>
+
+ 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+</div>

game stuff/dream islands.md

@@ -0,0 +1,17 @@
+---
+title: Dream Islands
+tags:
+  - pokopia
+---
+
+
+| Doll       | Item 1        | Item 2             | Item 3            | Legendary |
+| ---------- | ------------- | ------------------ | ----------------- | --------- |
+| Eevee      | Leppa         | Vine Rope          | Glowing Mushrooms | Suicune   |
+| Arcanine   | Iron Ore      | Gold Ore           | Glowing Stone     | Entei     |
+| Pikachu    | Twine         | Seaglass Fragments | Seashell          | Raikou    |
+| Dragonite  | Wastepaper    | Pokemetal          | Crystal Fragment  | Mewtwo    |
+| Clefairy   | Mushrooms     | Copper Ore         | Limestone         | None      |
+| Ditto      | Random Island |                    |                   |           |
+| Substitute | Random Island |                    |                   |           |
+![](https://www.youtube.com/shorts/YQ2rsLI7P0s?feature=share)

game stuff/food table.md

@@ -0,0 +1,41 @@
+---
+title: Pokopia Meals
+tags: pokopia
+---
+
+| Meal Tier [^1] | Meal Name [^1][^2]       | Flavor [^2]<br> | Partner Ability[^2] | Mosslax Boost [^1]                                                     | Ingredient A [^2] | Ingredient B[^2] | Ingredient C[^2] | Ingredient D[^2] | Power-Up         |     |
+| -------------- | ------------------------ | --------------- | ------------------- | ---------------------------------------------------------------------- | ----------------- | ---------------- | ---------------- | ---------------- | ---------------- | --- |
+| Best           | Vibrant hamburger steak  | Neutral         |                     | Increased rate you grow closer to Pokémon                              | Bean              | Salad            | Potato           | Any              | Ultra Rock Smash |     |
+| Best           | Bitter hamburger steak   | Bitter          |                     | Increased chance of finding rare items                                 | Bean              | Rawst Berry      | Lum Berry        | Any              | Rock Smash       |     |
+| Best           | Crushed-berry Salad      | Dry             | Crush               | Increased chance to see Pokémon with rare feathers (Lugia, Ho-Oh)      | Leaf              | Chesto Berry     |                  |                  | Leafage          |     |
+| Best           | Flavorful Soup           | sour            |                     | Increased chance of shop having "Good" items and offers a 10% discount | Water             | Burger Steak     | Aspear           | Any              | Water            |     |
+| Best           | Crouton salad            | Spicy           |                     | Increased chance of Pokémon appearing in habitats                      | Leaf              | Bread            |                  |                  | Leafage          |     |
+| Best           | Healthy Soup             | Spicy           |                     | Increased chance of Pokémon appearing in habitats                      | Water             | Bean             | Leaf             | Any              | Water            |     |
+| Best           | Fluffy bread             | Sweet           | Water               | Increased chance of Ancient Artefacts                                  | Wheat             | Pecha Berry      |                  |                  | Cut              |     |
+| Standard       | Simple Salad             | Neutral         |                     | Increased rate you grow closer to Pokémon                              | Leaf              | Any              |                  |                  | Leafage          |     |
+| Standard       | Simple Soup,             | Neutral         |                     | Increased rate you grow closer to Pokémon                              | Water             | Any              | Any              | Any              | Water            |     |
+| Standard       | Simple Bread             | Neutral         |                     | Increased rate you grow closer to Pokémon                              | Wheat             | Any              |                  |                  | Cut              |     |
+| Standard       | Simple hamburger         | Neutral         |                     | Increased rate you grow closer to Pokémon                              | Bean              | Any              | Any              | Any              | Rock Smash       |     |
+| ???            | Potato Hamburger Steak   | Sweet           |                     | Increased chance of Ancient Artefacts                                  | Bean              | Potato           | Any              | Any              | Rock Smash       |     |
+| ???            | Mushroom Hamburger Steak | Dry             |                     | Increased chance to see Pokémon with rare feathers (Lugia, Ho-Oh)      | Bean              | Mushroom         | Any              | Any              | Rock Smash       |     |
+| Weak           | Lum Berry                | Neutral         |                     | Increased rate you grow closer to Pokémon                              |                   |                  |                  |                  |                  |     |
+| Weak           | Chesto Berry             | Dry             |                     | Increased chance to see Pokémon with rare feathers (Lugia, Ho-Oh)      |                   |                  |                  |                  |                  |     |
+| Weak           | Rawst Berry              | Bitter          |                     | Increased chance of finding rare items                                 |                   |                  |                  |                  |                  |     |
+| Weak           | Pecha Berry              | Sweet           |                     | Increased chance of Ancient Artefacts                                  |                   |                  |                  |                  |                  |     |
+| Weak           | Aspear Berry             | Sour            |                     | Increased chance of shop having "Good" items and offers a 10% discount |                   |                  |                  |                  |                  |     |
+| Weak           | Leppa Berry              | Neutral         |                     | Increased rate you grow closer to Pokémon                              |                   |                  |                  |                  |                  |     |
+| Weak           | Water                    | Neutral         |                     | Increased rate you grow closer to Pokémon                              |                   |                  |                  |                  |                  |     |
+| Weak           | Soda Pop                 | Dry             |                     | Increased chance to see Pokémon with rare feathers (Lugia, Ho-Oh)      |                   |                  |                  |                  |                  |     |
+| Weak           | Roserade Tea             | Bitter          |                     | Increased chance of finding rare items                                 |                   |                  |                  |                  |                  |     |
+| Weak           | Chili                    | Spicy           |                     | Increased chance of Pokémon appearing in habitats                      |                   |                  |                  |                  |                  |     |
+| Weak           | Coffee                   | Sweet           |                     | Increased chance of Ancient Artefacts                                  |                   |                  |                  |                  |                  |     |
+| Weak           | Carrot                   | Spicy           |                     | Increased chance of Pokémon appearing in habitats                      |                   |                  |                  |                  |                  |     |
+| Weak           | Bean                     | Sweet           |                     | Increased chance of Ancient Artefacts                                  |                   |                  |                  |                  |                  |     |
+| Weak           | Wheat                    | Dry             |                     | Increased chance to see Pokémon with rare feathers (Lugia, Ho-Oh)      |                   |                  |                  |                  |                  |     |
+| Weak           | Tomato                   | Sour            |                     | Increased chance of shop having "Good" items and offers a 10% discount |                   |                  |                  |                  |                  |     |
+| Weak           | Potato                   | Bitter          |                     | Increased chance of finding rare items                                 |                   |                  |                  |                  |                  |     |
+| Weak           | Seaweed                  | Bitter          |                     | Increased chance of finding rare items                                 |                   |                  |                  |                  |                  |     |
+| Weak           | Mushrooms                | Dry             |                     | Increased chance to see Pokémon with rare feathers (Lugia, Ho-Oh)      |                   |                  |                  |                  |                  |     |
+
+[^1]: [Serebii Mosslax Page](https://www.serebii.net/pokemonpokopia/mosslaxboosts.shtml)
+[^2]: [Game8 Page](https://game8.co/games/Pokemon-Pokopia/archives/586136)

game stuff/public cloud islands.md

@@ -0,0 +1,15 @@
+---
+title: Public Cloud Islands
+tags:
+  - pokopia
+---
+
+| Code       | Description                     |
+| ---------- | ------------------------------- |
+| PXQC G03S  | Developer Island                |
+| FQBRK 7FVM | Hidetaka Kano Island            |
+| MGL4 83P4  | Rino Sashihara Island           |
+| 0XGP 4N31  | Colorful Peach collab Island    |
+| 0SJ8 5TRX  | IKEA Island                     |
+| BVLC 8WX6  | Dozie collab Island             |
+| 6DXL PD6F  | The Island with Everything (TM) |

how the site works.md

@@ -0,0 +1,9 @@
+---
+title: how the site works
+tags:
+  - nerd-shit
+  - homelab
+---
+
+
+This obsidian vault is stored in a git repository on my gitea instance. It has a workflow which clones the quartz v4 repository, installs the dependencies, patches it, copies the vault contents into the relevant quartz v4 repo folder, runs the quartz build command, and tar's the build output as a release. I then have an nginx deployment in my k3s cluster that downloads the latest release tar ball, inflates it and serves it in an nginx server. It's a lot more straight forward than you would think.

index.md

@@ -1,10 +1,25 @@
 ---
 title: Welcome
 ---
+Hello! My name is Eau - as in  [Eau De'Femme](https://fr.finalfantasyxiv.com/lodestone/character/33632636). I don't actually play FF14 very much anymore, but the name has stuck with me. I like videogames, software engineering, (astro) photography, art, cats, and my wife. Politically I lean to the left of the DNC but I don't put much thought in my politics beyond a survival imperative to move beyond capitalism. I look forward to degrowth, nuclear and renewable energy, mass public transit that rocks, walkable cities and unimpeded bodily autonomy for all.
 
+If you're curious, the games I'm currently playing are:
+- #pokopia 
+- #acnh 
+- #satisfactory
 
-This is your new *vault*.
+I play a bit of DND and run a "rat club" on Thursday evenings (best understood as an evolution of book clubs). Definitely I am more of an engineer than an artist, but I do appreciate art. You can get a sense of my tastes by browsing the [karakeep](./karakeep) folder, which is going to have a decently up-to-date collection of things I'm interested in. In general though, I like what [Tatsuki Fujimoto](https://en.wikipedia.org/wiki/Tatsuki_Fujimoto), [Yoko Taro](https://en.wikipedia.org/wiki/Yoko_Taro), and [Kenshi Yonezu](https://en.wikipedia.org/wiki/Kenshi_Yonezu) are doing. I think if I had to rank my favorite animated serialized works of all time, it would look something like this:
 
-Make a note of something, [[create a link]], or try [the Importer](https://help.obsidian.md/Plugins/Importer)!
+![[chart.png]]
 
-When you're ready, delete this note and make the vault your own.
+Video games I love but am not playing anymore are Nier: Automata / Replicant, Drakengard 1-3, the Atelier Series (specifically Ryza, Sophie and Yumia), Final Fantasy (FFX is, imo, the best storytelling done in a videogame that I have experienced to date).
+
+The music I like is pretty varied. I love a lot of pop (Sabrina Carpenter, Halsey, Hayley Williams), punk-pop (Fall Out Boy, PATD, MCR), grunge (Nirvana), rock (Matchbox 20), and classic rock / oldies.
+
+I do generally have a philosophy on life that we should strive to learn and improve all we can. Maybe that's self destructive, or maybe it isn't. When I inevitably get laid off, I think I want to go back and finish my undergrad degree. Mostly because I miss being in an environment of structured learning. But the things I'm trying to learn now are mostly 3D modeling and makeup/fashion. I'm definitely not very good at them yet :)
+
+![[image.png]]
+
+This is an obsidian vault where I will publish things I feel like yapping about - if any of the above seems like something you are interested in hearing opinions about, please feel free to subscribe to my [RSS feed](https://garden.werats.gay/index.xml) . If you have complaints questions or feedback, you can [email me](mailto:garden.7u7fl@passinbox.com) but I make no promises about a reply existing nor the quality of any reply that does exist. I do like to be helpful when I can though, so please don't feel discouraged from reaching out if you feel so inclined.
+
+This website is powered by [Quartz](https://quartz.jzhao.xyz/) and hosted on my homelab.

nerd shit/homelab.md

@@ -0,0 +1,82 @@
+---
+title: Homelab Architecture 2.0
+tags:
+  - nerd-shit
+---
+```mermaid
+block
+
+columns 6
+
+Eden["Eden\nThreadripper 3960X 24-Core CPU\n128GB DDR4\n10Gbase-T\nIntel ARC A310 6gb\nNVidia RTX 4060 Ti 16GB\n3x NVME Storage\n6x 8TB Sata HDD"]:6
+
+block:edenblock:6
+
+columns 12
+
+rootfs["TPM on NVME1\n /"]:2
+
+dockerdata["TPM on NVME1\n/etc/dockercomposedata/"]:2
+
+zfskey["TPM on NVME1\nEncryption Key for Coffers\n/etc/secrets/coffers"]:4
+
+k8sdata["ZFS on HDDs w/ NVME Journal\n /mnt/coffers"]:4
+
+K3S:8
+
+DC["docker-compose"]:4
+
+block:k3s:8
+
+columns 4
+
+longhorn["longhorn storage provider\nuses coffers ZFS"]
+
+audiobookshelf
+
+certs["cert-manager"]
+
+def["default"]
+
+fran
+
+gun
+
+identity
+
+immich
+
+intel["intel-device-plugin-system"]
+
+iot
+
+karakeep
+
+sys["kube-system"]
+
+lps["local-path-storage"]
+
+luxuries
+
+nfd["node-feature-discovery"]
+
+overseer
+
+rcs["runner-controller-system"]
+
+storage
+
+nvidia["nvidia-device-plugin"]
+
+tea
+
+end
+
+dns:2
+
+postgres:2
+
+end
+```
+
+![[Pasted image 20260419221316.png]]

readme.md

@@ -0,0 +1 @@
+# Hosts an Obsidian Garden File

test.md

@@ -0,0 +1,7 @@
+---
+title: Testing my Pipeline Improvement
+tags:
+  - nerd-shit
+  - homelab
+---
+This is just a test file I'm committing to see if the changes to my workflow file automatically reset the pods hosting the website so I can do so without having to open a terminal

version.txt

@@ -1 +1 @@
-1.12.0
+1.27.0