diff --git a/.obsidian/plugins/hoarder-sync/data.json b/.obsidian/plugins/hoarder-sync/data.json index 9346c4a..c1304ad 100644 --- a/.obsidian/plugins/hoarder-sync/data.json +++ b/.obsidian/plugins/hoarder-sync/data.json @@ -1,10 +1,10 @@ { "apiKey": "ak2_930f821671cbe46c8d7e_0df2443dba6dd9fe1dc8ebf52d6ac96e", "apiEndpoint": "https://kara.werats.gay/api/v1", - "syncFolder": "KaraKeep", - "attachmentsFolder": "KaraKeep/attachments", + "syncFolder": "Hoarder", + "attachmentsFolder": "Hoarder/attachments", "syncIntervalMinutes": 60, - "lastSyncTimestamp": 1776655042620, + "lastSyncTimestamp": 1776992561660, "updateExistingFiles": false, "excludeArchived": true, "onlyFavorites": false, diff --git a/KaraKeep/2026-04-20-How-to-Configure-K3s-for-IPv6.md b/KaraKeep/2026-04-20-How-to-Configure-K3s-for-IPv6.md new file mode 100644 index 0000000..9d40860 --- /dev/null +++ b/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) \ No newline at end of file diff --git a/KaraKeep/2026-04-20-Installing-Arch-with-Secure-Boot,.md b/KaraKeep/2026-04-20-Installing-Arch-with-Secure-Boot,.md new file mode 100644 index 0000000..04462bd --- /dev/null +++ b/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) \ No newline at end of file diff --git a/KaraKeep/2026-04-20-Making-dual-stack-ipv6-work-with.md b/KaraKeep/2026-04-20-Making-dual-stack-ipv6-work-with.md new file mode 100644 index 0000000..f041735 --- /dev/null +++ b/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) \ No newline at end of file diff --git a/KaraKeep/2026-04-20-Multi-seat-support-·-Wiki-·-ACS.md b/KaraKeep/2026-04-20-Multi-seat-support-·-Wiki-·-ACS.md new file mode 100644 index 0000000..067af49 --- /dev/null +++ b/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) \ No newline at end of file diff --git a/KaraKeep/2026-04-20-[Hyprland]-As-fluid-as-it-gets.-r.md b/KaraKeep/2026-04-20-[Hyprland]-As-fluid-as-it-gets.-r.md new file mode 100644 index 0000000..31bbdc1 --- /dev/null +++ b/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]() + +![[Hyprland] As fluid as it gets. : r/unixporn - Screenshot]() + +## 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) \ No newline at end of file diff --git a/KaraKeep/2026-04-20-[OC]-A-cozy-pixelaeted-collection.md b/KaraKeep/2026-04-20-[OC]-A-cozy-pixelaeted-collection.md new file mode 100644 index 0000000..bd01fd8 --- /dev/null +++ b/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]() + +![[OC] A cozy pixelaeted collection of lockscreen themes made with QML for sddm / quickshell! : r/unixporn - Screenshot]() + +## 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) \ No newline at end of file diff --git a/KaraKeep/2026-04-20-[SOLVED]-Nvidia-dual-gpu-stack.md b/KaraKeep/2026-04-20-[SOLVED]-Nvidia-dual-gpu-stack.md new file mode 100644 index 0000000..fa77c87 --- /dev/null +++ b/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]() + +![[SOLVED] Nvidia dual gpu stack config question / Kernel & Hardware / Arch Linux Forums - Screenshot]() + +![[SOLVED] Nvidia dual gpu stack config question / Kernel & Hardware / Arch Linux Forums - linkHtmlContent]() + +## Notes + + + +[Visit Link](https://bbs.archlinux.org/viewtopic.php?id=305746) + +[View in Hoarder](https://kara.werats.gay/dashboard/preview/patx7n11kkumw5cffcvq4i41) \ No newline at end of file diff --git a/KaraKeep/2026-04-20-dm-crypt-Encrypting-an-entire.md b/KaraKeep/2026-04-20-dm-crypt-Encrypting-an-entire.md new file mode 100644 index 0000000..0555df5 --- /dev/null +++ b/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) \ No newline at end of file diff --git a/KaraKeep/2026-04-20-login(3)-Linux-manual-page.md b/KaraKeep/2026-04-20-login(3)-Linux-manual-page.md new file mode 100644 index 0000000..4d0f725 --- /dev/null +++ b/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]() + +![login(3) - Linux manual page - Screenshot]() + +![login(3) - Linux manual page - linkHtmlContent]() + +## 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) \ No newline at end of file diff --git a/KaraKeep/2026-04-20-redhead,-face,-braids,-Tidsean,.md b/KaraKeep/2026-04-20-redhead,-face,-braids,-Tidsean,.md new file mode 100644 index 0000000..571a30b --- /dev/null +++ b/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) \ No newline at end of file diff --git a/KaraKeep/2026-04-20-systemd-cryptenroll-ArchWiki.md b/KaraKeep/2026-04-20-systemd-cryptenroll-ArchWiki.md new file mode 100644 index 0000000..ac58322 --- /dev/null +++ b/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) \ No newline at end of file diff --git a/KaraKeep/2026-04-23-Pokemon-Champions-Speed-Tiers-VGC.md b/KaraKeep/2026-04-23-Pokemon-Champions-Speed-Tiers-VGC.md new file mode 100644 index 0000000..ee51410 --- /dev/null +++ b/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) \ No newline at end of file diff --git a/KaraKeep/attachments/03283c3e-1171-48e1-a537-e758a715e108-Multi-seat-support-·-Wiki-·.jpg b/KaraKeep/attachments/03283c3e-1171-48e1-a537-e758a715e108-Multi-seat-support-·-Wiki-·.jpg new file mode 100644 index 0000000..f4aa16b Binary files /dev/null and b/KaraKeep/attachments/03283c3e-1171-48e1-a537-e758a715e108-Multi-seat-support-·-Wiki-·.jpg differ diff --git a/KaraKeep/attachments/040320f7-8aa7-4688-9531-3ebbc2d334d1-How-to-Configure-K3s-for-IPv6.jpg b/KaraKeep/attachments/040320f7-8aa7-4688-9531-3ebbc2d334d1-How-to-Configure-K3s-for-IPv6.jpg new file mode 100644 index 0000000..2e21bfb Binary files /dev/null and b/KaraKeep/attachments/040320f7-8aa7-4688-9531-3ebbc2d334d1-How-to-Configure-K3s-for-IPv6.jpg differ diff --git a/KaraKeep/attachments/0e6f3b83-37cb-479d-90d5-5ef9305d8479-Installing-Arch-with-Secure.jpg b/KaraKeep/attachments/0e6f3b83-37cb-479d-90d5-5ef9305d8479-Installing-Arch-with-Secure.jpg new file mode 100644 index 0000000..ca84ffd Binary files /dev/null and b/KaraKeep/attachments/0e6f3b83-37cb-479d-90d5-5ef9305d8479-Installing-Arch-with-Secure.jpg differ diff --git a/KaraKeep/attachments/22d9b6ff-a6f6-4d92-b16f-bebe89b6fd70-How-to-Configure-K3s-for-IPv6.jpg b/KaraKeep/attachments/22d9b6ff-a6f6-4d92-b16f-bebe89b6fd70-How-to-Configure-K3s-for-IPv6.jpg new file mode 100644 index 0000000..4864ce2 --- /dev/null +++ b/KaraKeep/attachments/22d9b6ff-a6f6-4d92-b16f-bebe89b6fd70-How-to-Configure-K3s-for-IPv6.jpg @@ -0,0 +1,169 @@ +
+

Introduction

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.

Prerequisites

  • Linux host with IPv6 network connectivity
  • IPv6 subnet available for pod and service CIDR allocation
  • Kernel with IPv6 support (all modern Linux kernels)
  • No IPv4-only constraints in your environment

Step 1: Verify IPv6 Support on the Host

# Check if IPv6 is enabled
+
+cat /proc/sys/net/ipv6/conf/all/disable_ipv6
+# 0 = enabled, 1 = disabled
+
+# If disabled, enable it
+echo 0 > /proc/sys/net/ipv6/conf/all/disable_ipv6
+
+# Make permanent
+cat >> /etc/sysctl.conf << 'EOF'
+net.ipv6.conf.all.disable_ipv6 = 0
+net.ipv6.conf.default.disable_ipv6 = 0
+net.ipv6.conf.lo.disable_ipv6 = 0
+EOF
+sysctl -p
+
+# Check the host's IPv6 address
+ip -6 addr show
+# Should show your IPv6 addresses
+
+# Test IPv6 connectivity
+ping6 -c 4 2001:4860:4860::8888  # Google's IPv6 DNS

Step 2: Configure IPv6 Forwarding

Kubernetes requires IP forwarding to route pod traffic:

# Enable IPv6 forwarding
+cat >> /etc/sysctl.conf << 'EOF'
+net.ipv6.conf.all.forwarding = 1
+net.ipv6.conf.default.forwarding = 1
+EOF
+
+sysctl -p
+
+# Verify
+cat /proc/sys/net/ipv6/conf/all/forwarding
+# Should output: 1

Step 3: Install K3s with IPv6 Configuration

# Plan your IPv6 subnets:
+# Cluster CIDR (pod IPs): fd42::/24
+# Service CIDR: fd43::/112
+# Node CIDR size: /80 per node
+
+# Install K3s server with IPv6
+curl -sfL https://get.k3s.io | \
+  INSTALL_K3S_EXEC="
+    --cluster-cidr=fd42::/24
+    --service-cidr=fd43::/112
+    --cluster-dns=fd43::10
+    --flannel-ipv6-masq=true
+  " \
+  sh -

Or using a config file:

# /etc/rancher/k3s/config.yaml
+# IPv6 single-stack configuration
+cluster-cidr: "fd42::/24"
+service-cidr: "fd43::/112"
+cluster-dns: "fd43::10"
+
+# Flannel IPv6 settings
+flannel-ipv6-masq: true
+
+# Optional: specify flannel backend
+flannel-backend: vxlan

Step 4: Install K3s Agent with IPv6

# Agent nodes need the server's IPv6 address
+curl -sfL https://get.k3s.io | \
+  K3S_URL=https://[<server-ipv6>]:6443 \
+  K3S_TOKEN=<node-token> \
+  sh -
+
+# Note: IPv6 addresses in URLs must be enclosed in brackets
+# Example: https://[2001:db8::1]:6443

Step 5: Verify IPv6 Cluster

# Check nodes have IPv6 addresses
+kubectl get nodes -o wide
+# Internal-IP should show IPv6 addresses
+
+# Check pods have IPv6 IPs
+kubectl get pods -A -o wide
+# Pod IP should be from the fd42::/24 range
+
+# Check services have IPv6 cluster IPs
+kubectl get svc -A
+# Cluster IP should be from fd43::/112 range
+
+# Verify DNS is using IPv6
+kubectl run dns-test --image=busybox --restart=Never -- sleep 3600
+kubectl exec dns-test -- nslookup kubernetes.default.svc.cluster.local
+# Should resolve to IPv6 address
+
+kubectl delete pod dns-test

Step 6: Test IPv6 Pod Communication

# Deploy a test application
+cat <<'EOF' | 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  # Note: need proper label
+  ports:
+    - port: 80
+      targetPort: 80
+  type: ClusterIP
+EOF
+
+# Get the service ClusterIP (should be IPv6)
+kubectl get svc ipv6-server-svc
+
+# Test connectivity from another pod
+kubectl run test-client --image=curlimages/curl --restart=Never \
+  -- curl -v http://ipv6-server-svc/
+
+kubectl logs test-client
+
+# Clean up
+kubectl delete pod ipv6-server test-client
+kubectl delete svc ipv6-server-svc

Step 7: Configure IPv6-Aware Ingress

For Traefik to listen on IPv6:

# /var/lib/rancher/k3s/server/manifests/traefik-ipv6.yaml
+apiVersion: helm.cattle.io/v1
+kind: HelmChartConfig
+metadata:
+  name: traefik
+  namespace: kube-system
+spec:
+  valuesContent: |-
+    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

Step 8: CoreDNS IPv6 Configuration

Ensure CoreDNS is configured for IPv6:

# Verify CoreDNS has IPv6 service IP
+kubectl get svc coredns -n kube-system
+
+# The cluster-dns flag should point to an IPv6 address
+# Default: fd43::10 (from service CIDR)
+
+# Verify DNS resolution works over IPv6
+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

Step 9: Network Policy with IPv6

# ipv6-network-policy.yaml
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: allow-internal-ipv6
+  namespace: default
+spec:
+  podSelector: {}
+  policyTypes:
+    - Ingress
+    - Egress
+  ingress:
+    - from:
+        - ipBlock:
+            # Allow from the pod CIDR
+            cidr: fd42::/24
+  egress:
+    - to:
+        - ipBlock:
+            cidr: fd42::/24
+    - ports:
+        # Allow DNS over IPv6
+        - port: 53
+          protocol: UDP
+        - port: 53
+          protocol: TCP

Conclusion

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.

\ No newline at end of file diff --git a/KaraKeep/attachments/24d8fac9-182c-40e9-b9c6-f8dbd832d26d-[Hyprland]-As-fluid-as-it.jpg b/KaraKeep/attachments/24d8fac9-182c-40e9-b9c6-f8dbd832d26d-[Hyprland]-As-fluid-as-it.jpg new file mode 100644 index 0000000..ef70498 Binary files /dev/null and b/KaraKeep/attachments/24d8fac9-182c-40e9-b9c6-f8dbd832d26d-[Hyprland]-As-fluid-as-it.jpg differ diff --git a/KaraKeep/attachments/25d78444-1af2-4d98-8d56-7350aef62955-Making-dual-stack-ipv6-work.jpg b/KaraKeep/attachments/25d78444-1af2-4d98-8d56-7350aef62955-Making-dual-stack-ipv6-work.jpg new file mode 100644 index 0000000..d1265d9 --- /dev/null +++ b/KaraKeep/attachments/25d78444-1af2-4d98-8d56-7350aef62955-Making-dual-stack-ipv6-work.jpg @@ -0,0 +1,132 @@ +

2021-07-27 - How to setup a working ipv4/ipv6 service on k3s
Tags: Ipv6 K3s Kubernetes

Introduction

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.

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.

Installation

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 :

network:
+    version: 2
+    ethernets:
+        ens3:
+            dhcp4: true
+            match:
+                macaddress: fa:16:3e:82:71:b7
+            mtu: 1500
+            set-name: ens3
+            dhcp6: no
+            addresses:
+                - 2001:41d0:401:3100:0:0:0:fd5/128
+            gateway6: 2001:41d0:0401:3100:0000:0000:0000:0001
+            routes:
+                - to: 2001:41d0:0401:3100:0000:0000:0000:0001
+                  scope: link
+

After installation I just ran an apt dist-upgrade then installed ipvsadm. Afterwards it’s all k3s :

export INSTALL_K3S_VERSION=v1.21.3+k3s1
+export INSTALL_K3S_EXEC="server --disable traefik --disable servicelb --disable metrics-server --disable-cloud-controller \
+       --kube-proxy-arg proxy-mode=ipvs --cluster-cidr=10.42.0.0/16,fd42::/48 --service-cidr=10.43.0.0/16,fd43::/112 \
+       --disable-network-policy --flannel-backend=none --node-ip=37.187.244.19,2001:41d0:401:3100::fd5"
+

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.

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.

Once ready review the k3s installation script then run it :

wget https://get.k3s.io -O k3s.sh
+less k3s.sh
+bash k3s.sh
+

With k3s installed you should be able to access the kubernetes cli with kubectl get nodes but basic services like coredns pod won’t start before calico is setup.

Calico

Retrieve Calico’s manifests with :

wget https://docs.projectcalico.org/manifests/calico.yaml
+

Edit this file and locate the ipam section of the ConfigMap. Change it to the following :

"ipam": {
+    "type": "calico-ipam",
+    "assign_ipv4": "true",
+    "assign_ipv6": "true"
+},
+

Then locate the FELIX_IPV6SUPPORT variable in the calico-node DaemonSet configuration and set it to true.

You can then apply this manifest :

kubectl apply -f calico.yaml
+

From there for standard pods and services should start properly, give calico some time and check :

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
+

You should have four pods running : coredns, two calico pods and k3s’ local path provisionner.

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 :

wget https://raw.githubusercontent.com/metallb/metallb/v0.10.2/manifests/namespace.yaml -O metallb-namespace.yaml
+wget https://raw.githubusercontent.com/metallb/metallb/v0.10.2/manifests/metallb.yaml -O metallb-0.10.2-manifest.yaml
+kubectl apply -f metallb-namespace.yaml -f metallb-0.10.2-manifest.yaml
+

Then create a metallb-config.yaml with content like this :

apiVersion: v1
+kind: ConfigMap
+metadata:
+  namespace: metallb-system
+  name: config
+data:
+  config: |
+    address-pools:
+    - name: default
+      protocol: layer2
+      addresses:
+      - 37.187.244.19/32
+      - 2001:41d0:401:3100::fd5/128
+

Don’t forget to replace the ipv4 and ipv6 addresses with the ones configured on your node. Then apply this manifest :

kubectl apply -f metallb-config.yaml
+

Give it a minute then check that everything is ok :

kubectl -n metallb-system get pods
+NAME                              READY   STATUS    RESTARTS   AGE
+pod/controller-6b78bff7d9-szz78   1/1     Running   0          86s
+pod/speaker-mx46m                 1/1     Running   0          86s
+

Ingress-nginx

From there we can setup our ingress-nginx, but it will require a bit of service customization :

wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.48.1/deploy/static/provider/baremetal/deploy.yaml \
+     -O ingress-nginx-0.48.1.yaml
+

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 :

apiVersion: v1
+kind: Service
+metadata:
+  annotations:
+  labels:
+    helm.sh/chart: ingress-nginx-3.34.0
+    app.kubernetes.io/name: ingress-nginx
+    app.kubernetes.io/instance: ingress-nginx
+    app.kubernetes.io/version: 0.48.1
+    app.kubernetes.io/managed-by: Helm
+    app.kubernetes.io/component: controller
+  name: ingress-nginx-controller-v4
+  namespace: ingress-nginx
+spec:
+  type: LoadBalancer
+  ipFamilies:
+    - IPv4
+  ports:
+    - name: http
+      port: 80
+      protocol: TCP
+      targetPort: http
+    - name: https
+      port: 443
+      protocol: TCP
+      targetPort: https
+  selector:
+    app.kubernetes.io/name: ingress-nginx
+    app.kubernetes.io/instance: ingress-nginx
+    app.kubernetes.io/component: controller
+---
+apiVersion: v1
+kind: Service
+metadata:
+  annotations:
+  labels:
+    helm.sh/chart: ingress-nginx-3.34.0
+    app.kubernetes.io/name: ingress-nginx
+    app.kubernetes.io/instance: ingress-nginx
+    app.kubernetes.io/version: 0.48.1
+    app.kubernetes.io/managed-by: Helm
+    app.kubernetes.io/component: controller
+  name: ingress-nginx-controller-v6
+  namespace: ingress-nginx
+spec:
+  type: LoadBalancer
+  ipFamilies:
+    - IPv6
+  ports:
+    - name: http
+      port: 80
+      protocol: TCP
+      targetPort: http
+    - name: https
+      port: 443
+      protocol: TCP
+      targetPort: https
+  selector:
+    app.kubernetes.io/name: ingress-nginx
+    app.kubernetes.io/instance: ingress-nginx
+    app.kubernetes.io/component: controller
+

Note the metadata names with -v4 and -v6 suffixes, the type: LoadBalancer and the respective ipFamilies. You can now apply this manifest :

kubectl apply -f ingress-nginx-0.48.1.yaml
+

Give it some time, then check that the two controller services each get the ipv4 or ipv6 address of your node :

kubectl -n ingress-nginx get pods,svc
+NAME                                            READY   STATUS      RESTARTS   AGE
+pod/ingress-nginx-admission-create-hcgdm        0/1     Completed   0          52s
+pod/ingress-nginx-admission-patch-hl2vw         0/1     Completed   1          52s
+pod/ingress-nginx-controller-5cb8d9c6dd-5692s   1/1     Running     0          52s
+
+NAME                                         TYPE           CLUSTER-IP      EXTERNAL-IP               PORT(S)                      AGE
+service/ingress-nginx-controller-admission   ClusterIP      10.43.244.41    <none>                    443/TCP                      37s
+service/ingress-nginx-controller-v4          LoadBalancer   10.43.139.251   37.187.244.19             80:31501/TCP,443:32318/TCP   37s
+service/ingress-nginx-controller-v6          LoadBalancer   fd43::2a99      2001:41d0:401:3100::fd5   80:31923/TCP,443:30428/TCP   36s
+

Conclusion

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.

\ No newline at end of file diff --git a/KaraKeep/attachments/39a606a1-ba75-41a2-a697-6f34b0c6803c-Installing-Arch-with-Secure.jpg b/KaraKeep/attachments/39a606a1-ba75-41a2-a697-6f34b0c6803c-Installing-Arch-with-Secure.jpg new file mode 100644 index 0000000..01965f7 Binary files /dev/null and b/KaraKeep/attachments/39a606a1-ba75-41a2-a697-6f34b0c6803c-Installing-Arch-with-Secure.jpg differ diff --git a/KaraKeep/attachments/43a375b6-1b59-4572-b713-e125c9963eaa-[SOLVED]-Nvidia-dual-gpu.jpg b/KaraKeep/attachments/43a375b6-1b59-4572-b713-e125c9963eaa-[SOLVED]-Nvidia-dual-gpu.jpg new file mode 100644 index 0000000..9a82f8d --- /dev/null +++ b/KaraKeep/attachments/43a375b6-1b59-4572-b713-e125c9963eaa-[SOLVED]-Nvidia-dual-gpu.jpg @@ -0,0 +1,376 @@ +
+ + +
+

#1 2025-05-22 16:26:41

+
+
+
+
+
Succulent of your garden
+
Member
+
+
From: Majestic kingdom of pot plants
+
Registered: 2024-02-29
+
Posts: 1,509
+
+
+
+

[SOLVED] Nvidia dual gpu stack config question

+
+

Hi!

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.

As you can see in the https://wiki.archlinux.org/title/NVIDIA the packages for the drivers are different for each gpu.

So first question: Is Arch currently supporting the RTX 5000 series with the nvidia-open and nvidia-open-lts packages ?
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.

+

Last edited by Succulent of your garden (2025-05-24 23:40:06)

+
+

str( @soyg ) == str( @potplant ) btw!

Also now with avatar logo included!

+
+
+
+

Offline

+
+
+
+ +
+

#2 2025-05-22 17:00:25

+
+
+
+
+
Xephon
+
Member
+
Registered: 2024-12-22
+
Posts: 189
+
+
+
+

Re: [SOLVED] Nvidia dual gpu stack config question

+
+

RTX 5000 cards are supported by nvidia-open and nvidia-open-lts.

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.

+
+
+
+
+

Offline

+
+
+
+ +
+

#3 2025-05-22 17:23:48

+
+
+
+
+
Succulent of your garden
+
Member
+
+
From: Majestic kingdom of pot plants
+
Registered: 2024-02-29
+
Posts: 1,509
+
+
+
+

Re: [SOLVED] Nvidia dual gpu stack config question

+

But in the worst scenario can I just use the nouveau driver  for the pascal based  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.

+

str( @soyg ) == str( @potplant ) btw!

Also now with avatar logo included!

+
+
+
+

Offline

+
+
+
+ +
+

#4 2025-05-22 17:38:14

+
+
+
+
+
Xephon
+
Member
+
Registered: 2024-12-22
+
Posts: 189
+
+
+
+

Re: [SOLVED] Nvidia dual gpu stack config question

+
+

https://wiki.archlinux.org/title/NVIDIA

The nvidia-utils package contains a file which blacklists the nouveau module once you reboot

You can't have two different nvidia drivers running simultaneously on the same system.

+
+
+
+
+

Offline

+
+
+
+ +
+

#5 2025-05-22 20:37:28

+
+
+
+
+
Succulent of your garden
+
Member
+
+
From: Majestic kingdom of pot plants
+
Registered: 2024-02-29
+
Posts: 1,509
+
+
+
+

Re: [SOLVED] Nvidia dual gpu stack config question

+
+

thanks for the info. So there is no any chance to un-blacklist  the nouveau driver so I can get my pascal gpu working together ?

Why is this the case ? Does the same happen with amd cards ?

+
+

str( @soyg ) == str( @potplant ) btw!

Also now with avatar logo included!

+
+
+
+

Offline

+
+
+
+ +
+

#6 2025-05-22 21:28:59

+
+
+
+
+
Xephon
+
Member
+
Registered: 2024-12-22
+
Posts: 189
+
+
+
+

Re: [SOLVED] Nvidia dual gpu stack config question

+
+

Nouveau is blacklisted for a reason. If you un-blacklist it, nouveau will load instead of nvidia-open.

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.

+
+
+
+
+

Offline

+
+
+
+ +
+

#7 2025-05-22 21:56:16

+
+
+
+
+
loqs
+
Member
+
Registered: 2014-03-06
+
Posts: 18,860
+
+
+
+

Re: [SOLVED] Nvidia dual gpu stack config question

+

You could pass one of the cards through to a virtual machine to use avoiding having conflicting kernel modules loaded by the same kernel.

+
+
+
+

Offline

+
+
+
+ +
+

#8 2025-05-23 06:58:48

+
+
+
+
+
seth
+
Member
+
+
From: Don't DM me only for attention
+
Registered: 2012-09-03
+
Posts: 74,630
+
+
+
+

Re: [SOLVED] Nvidia dual gpu stack config question

+
+

Also

The OP wrote:

I want to have the second one to do gpu pass-through to virtual machines.

What makes the entire thread moot.

+
+ +
+
+
+

Online

+
+
+
+ +
+

#9 2025-05-23 16:05:24

+
+
+
+
+
Succulent of your garden
+
Member
+
+
From: Majestic kingdom of pot plants
+
Registered: 2024-02-29
+
Posts: 1,509
+
+
+
+

Re: [SOLVED] Nvidia dual gpu stack config question

+
+

Okey. Let summarize everything:

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  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  one. Does the same happen ?

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  and put the driver in the vm right ? I'm seeing this setup like this:

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.
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.

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  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 ?

+

Last edited by Succulent of your garden (2025-05-23 16:08:25)

+
+

str( @soyg ) == str( @potplant ) btw!

Also now with avatar logo included!

+
+
+
+

Offline

+
+
+
+ +
+

#10 2025-05-23 18:44:10

+
+
+
+
+
Xephon
+
Member
+
Registered: 2024-12-22
+
Posts: 189
+
+
+
+

Re: [SOLVED] Nvidia dual gpu stack config question

+
+

1)

So this is an issue only with nividia or when  you are running a stack with all the cards from the same manufacture but one card is much older than the new one ?

It's an issue when you are running a stack containing some cards from the same manufacturer that require different drivers and those drivers are in conflict with each other. 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.

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 https://looking-glass.io/

+
+
+
+
+

Offline

+
+
+
+ +
+

#11 2025-05-23 19:21:37

+
+
+
+
+
seth
+
Member
+
+
From: Don't DM me only for attention
+
Registered: 2012-09-03
+
Posts: 74,630
+
+
+
+

Re: [SOLVED] Nvidia dual gpu stack config question

+
+

Does the monitor have multiple inputs and the ability to switch between them?

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.
Don't overcomplicate this, vfio forwarding is covered extensively in the wiki.

+
+ +
+
+
+

Online

+
+
+
+ +
+

#12 2025-05-24 15:00:40

+
+
+
+
+
Succulent of your garden
+
Member
+
+
From: Majestic kingdom of pot plants
+
Registered: 2024-02-29
+
Posts: 1,509
+
+
+
+

Re: [SOLVED] Nvidia dual gpu stack config question

+
+

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:

AMD or Intel for the client
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.

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.

NVIDIA for the guest
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.

source: https://looking-glass.io/docs/B7/requirements/

But as far as I know the Blackwell architecture is currently having the drivers open source right ?  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.

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.

EDIT: My monitor does have multiple inputs and is possible to switch between them.

+

Last edited by Succulent of your garden (2025-05-24 15:27:56)

+
+

str( @soyg ) == str( @potplant ) btw!

Also now with avatar logo included!

+
+
+
+

Offline

+
+
+
+ +
+

#13 2025-05-24 17:15:05

+
+
+
+
+
Xephon
+
Member
+
Registered: 2024-12-22
+
Posts: 189
+
+
+
+

Re: [SOLVED] Nvidia dual gpu stack config question

+
+

No one can guarantee that you won't have any problems, but it looks like you're gonna be fine.

Looking Glass developers confirm that nvidia-open allows to use foreign DMABUF objects. Should be no problems using Blackwell for the host.
https://github.com/NVIDIA/open-gpu-kern … t-11022142

And Pascal in VM won't need DMABUF support capabilities

+
+
+
+
+

Offline

+
+
+
+ +
+

#14 2025-05-24 23:39:43

+
+
+
+
+
Succulent of your garden
+
Member
+
+
From: Majestic kingdom of pot plants
+
Registered: 2024-02-29
+
Posts: 1,509
+
+
+
+

Re: [SOLVED] Nvidia dual gpu stack config question

+

Thanks very much for your help Xephon, and also for the info by Seth.  Really appreciated smile

+

str( @soyg ) == str( @potplant ) btw!

Also now with avatar logo included!

+
+
+
+

Offline

+
+
+
+ + +
\ No newline at end of file diff --git a/KaraKeep/attachments/4b4bafa3-ef7a-4133-96fe-1f18d932adca-[Hyprland]-As-fluid-as-it.jpg b/KaraKeep/attachments/4b4bafa3-ef7a-4133-96fe-1f18d932adca-[Hyprland]-As-fluid-as-it.jpg new file mode 100644 index 0000000..2eff21b Binary files /dev/null and b/KaraKeep/attachments/4b4bafa3-ef7a-4133-96fe-1f18d932adca-[Hyprland]-As-fluid-as-it.jpg differ diff --git a/KaraKeep/attachments/4ecd662c-8fd7-44b1-8f78-fdaae95bf83a-systemd-cryptenroll-ArchWiki.jpg b/KaraKeep/attachments/4ecd662c-8fd7-44b1-8f78-fdaae95bf83a-systemd-cryptenroll-ArchWiki.jpg new file mode 100644 index 0000000..c831a89 Binary files /dev/null and b/KaraKeep/attachments/4ecd662c-8fd7-44b1-8f78-fdaae95bf83a-systemd-cryptenroll-ArchWiki.jpg differ diff --git a/KaraKeep/attachments/68f59c48-9625-4f07-9e08-d2cd2577e253-Multi-seat-support-·-Wiki-·.jpg b/KaraKeep/attachments/68f59c48-9625-4f07-9e08-d2cd2577e253-Multi-seat-support-·-Wiki-·.jpg new file mode 100644 index 0000000..1272437 --- /dev/null +++ b/KaraKeep/attachments/68f59c48-9625-4f07-9e08-d2cd2577e253-Multi-seat-support-·-Wiki-·.jpg @@ -0,0 +1,172 @@ +
+ + + + + +
+ Skip to main content +
+
+
+ + + + + + + + + + +

Multi seat support

Multi-seat Confiuration

+

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.

+

Setup

+

HW Requirements (validated only on AMDGPU setup)

+
    +
  1. APU + DGPU setup.
    2. +
  2. Card0 and Card1 should be enumerated under /dev/dri/ folder.
    3. +
  3. Each APU and dGPU should be connected with individual monitor, mouse and keyboard.
    4. +
  4. Connect extra pair of keyboard and mouse which could be easily distinguished (different vendor or product id) with already connected pair.
    5. +
+

One Time Setup

+

Step 1:

+

To make multi-seat setup, make sure to comment the "additional-devices=card1" config in weston.ini.

+

additional_card

+

Step 2: Create udev rule to create a new seat

+
    +
  • Create a new udev rules file under /etc/udev/rules.d/ by following the below naming convention.
    • +
+
<priority>-<device name>.rules
+
    +
  • +

    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/

    +

    Ex: New rule 69-graphics-seat.rules in the below figure is created with priority 69.

    +

    Copy the below contents into 69-graphics-multseat.rules and update the parameters from next step.

    +
    • +
+
SUBSYSTEM=="drm", KERNEL=="card1", KERNELS=="0000:c7:00.0", TAG+="master-of-seat", 
+ENV{ID_SEAT}="seat1"
+SUBSYSTEM=="drm", KERNEL=="renderD129", KERNELS=="0000:c7:00.0", ENV{ID_SEAT}="seat1"
+SUBSYSTEM=="graphics", KERNEL=="fb1", KERNELS=="0000:c7:00.0", ENV{ID_SEAT}="seat1"
+SUBSYSTEM=="input", ATTRS{devnum}=="9", ATTRS{idVendor}=="1bcf", ATTRS{idProduct}=="08a0", 
+OWNER="acs2", ENV{ID_SEAT}="seat1"
+SUBSYSTEM=="input", ATTRS{devnum}=="4", ATTRS{idVendor}=="1a2c", ATTRS{idProduct}=="4c5e", 
+OWNER="acs2", ENV{ID_SEAT}="seat1"
+
    +
  • First 3 lines in above udev script will assign card1 to seat1.
    • +
  • Last 2 lines will assign specific keyboard and mouse to seat1.
    • +
  • By default, system will always have CARD0 assigned to DGPU, and CARD1 to APU.
    • +
  • In above example, update keys like KERNELS, idVendor etc. with the system specific parameters and OWNER with system user-name.
    • +
  • 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"
    • +
+
$ sudo chmod 777 <path>/share/weston/devices.sh
+$ cd <path>/share/weston && ./devices.sh
+
Sample output of devices.sh script
+
+--------------Card1 details-------------------
+
+/dev/dri/card1 value of KERNELS: 0000:c7:00.0
+fb1 value of KERNELS: 0000:c7:00.0
+render not value of KERNELS: 0000:c7:00.0
+
+---------------Mouses connected-----------------
+Mouse 1:
+Vendor ID: 1bcf
+Product ID: 08a0
+Device No: 009
+
+Mouse 2:
+Vendor ID: 1bcf
+Product ID: 08a0
+Device No: 008
+
+---------------Keyboards connected-----------------
+Keyboard 1:
+Vendor ID: 1a2c
+Product ID: 4c5e
+Device No: 004
+
+Keyboard 2:
+Vendor ID: 1a2c
+Product ID: 4c5e
+Device No: 002
+
    +
  • Update the KERNELS param in rule file for card1, fb1 and renderD129 entries based on output from device.sh script.
    • +
  • Select the keyboard and mouse based on information from device.sh and update the idVendor and idProduct, devnum params in rule file.
    • +
  • ATTR{devnum} value can change on reboot so, we need to check this value used in rule on each reboot.
    • +
  • When there is a change update the rule and run below command to reload new rule.
    • +
+
Reload udev rules:
+$ sudo udevadm control --reload-rules
+
+Trigger udev to apply the new rules:
+$ sudo udevadm trigger
+

Step 3 : Copy service files

+
    +
  1. Execute the below commands to copy the multi-seat related service files present under /opt/amdgpu/share/weston to respective locations.
    2. +
+
$ sudo cp <path>/share/weston/mysession.service /etc/systemd/system
+$ sudo cp <path>/share/weston/mysession.target /etc/systemd/user
+$ sudo cp <path>/share/weston/weston.service /etc/systemd/user
+$ sudo cp <path>/share/weston/weston.socket /etc/systemd/user
+
    +
  1. Edit /etc/systemd/system/mysession.service file as shown below and update User and Group with system's username.
    2. +
+

image-2024-7-10_17-16-33

+
    +
  1. Edit /etc/systemd/user/weston.service file and update the config file path if needed.
    2. +
+

image-2024-7-10_17-23-6

+
    +
  1. Run the below commands to reload systemd
    2. +
+
$ systemctl daemon-reload
+$ systemctl --user daemon-reload
+

Step 4 : Disable GDM

+
    +
  1. Execute the below commands to disable GDM which internally disables GUI
    2. +
+
$ sudo systemctl disable gdm3
+$ sudo reboot
+
    +
  1. After system is rebooted, TTY terminal will appear for login. Login with credentials.
    2. +
+

With this, One Time Setup for Multi-Seat is completed. These steps are not required unless Multi-Seat setup is disabled.

+

Launching ACS on Multi-Seat

+
    +
  1. 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.
    2. +
+
$ loginctl list-seats
+
    +
  1. 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
    2. +
+
Reload udev rules:
+$ sudo udevadm control --reload-rules
+
+Trigger udev to apply the new rules:
+$ sudo udevadm trigger
+
    +
  1. Edit /share/weston/multi-seat-setup.sh file to update the user-name and seat name as per the system.
    2. +
  2. Optional : update the config file path in multi-seat-setup.sh with custom config file path.
    3. +
  3. 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.]
    4. +
  4. Result - ACS desktop should appear on both the monitors each controllable with set of keyboard and mouse.
    5. +
+

Disable Multi-Seat setup

+
    +
  1. Move or delete the rule file created in /etc/udev/rules.d/
    2. +
  2. Enable GDM - systemctl set-default graphical.target
    3. +
  3. sudo reboot
    4. +
+ +
+
+ + + + + + + + +
\ No newline at end of file diff --git a/KaraKeep/attachments/691ef2bd-f242-43d4-91dd-1ed12e1aa837-[SOLVED]-Nvidia-dual-gpu.jpg b/KaraKeep/attachments/691ef2bd-f242-43d4-91dd-1ed12e1aa837-[SOLVED]-Nvidia-dual-gpu.jpg new file mode 100644 index 0000000..b7bef87 Binary files /dev/null and b/KaraKeep/attachments/691ef2bd-f242-43d4-91dd-1ed12e1aa837-[SOLVED]-Nvidia-dual-gpu.jpg differ diff --git a/KaraKeep/attachments/69abf5b9-a761-47e1-b0ff-29e9a24d0966-[OC]-A-cozy-pixelaeted.jpg b/KaraKeep/attachments/69abf5b9-a761-47e1-b0ff-29e9a24d0966-[OC]-A-cozy-pixelaeted.jpg new file mode 100644 index 0000000..e041296 Binary files /dev/null and b/KaraKeep/attachments/69abf5b9-a761-47e1-b0ff-29e9a24d0966-[OC]-A-cozy-pixelaeted.jpg differ diff --git a/KaraKeep/attachments/7d8f62bc-aa84-45e1-ac6b-95781a20a1da-Making-dual-stack-ipv6-work.jpg b/KaraKeep/attachments/7d8f62bc-aa84-45e1-ac6b-95781a20a1da-Making-dual-stack-ipv6-work.jpg new file mode 100644 index 0000000..9df5db7 Binary files /dev/null and b/KaraKeep/attachments/7d8f62bc-aa84-45e1-ac6b-95781a20a1da-Making-dual-stack-ipv6-work.jpg differ diff --git a/KaraKeep/attachments/8118b0ec-f950-42f7-851a-2261ed9df314-redhead,-face,-braids,.jpg b/KaraKeep/attachments/8118b0ec-f950-42f7-851a-2261ed9df314-redhead,-face,-braids,.jpg new file mode 100644 index 0000000..55f747f --- /dev/null +++ b/KaraKeep/attachments/8118b0ec-f950-42f7-851a-2261ed9df314-redhead,-face,-braids,.jpg @@ -0,0 +1 @@ +
\ No newline at end of file diff --git a/KaraKeep/attachments/8ee7b7c0-86e5-4862-a8e7-61a814ff1746-redhead,-face,-braids,.jpg b/KaraKeep/attachments/8ee7b7c0-86e5-4862-a8e7-61a814ff1746-redhead,-face,-braids,.jpg new file mode 100644 index 0000000..5cc9419 Binary files /dev/null and b/KaraKeep/attachments/8ee7b7c0-86e5-4862-a8e7-61a814ff1746-redhead,-face,-braids,.jpg differ diff --git a/KaraKeep/attachments/90e61b51-7cff-4b61-9672-fe6f64dbdd3f-redhead,-face,-braids,.jpg b/KaraKeep/attachments/90e61b51-7cff-4b61-9672-fe6f64dbdd3f-redhead,-face,-braids,.jpg new file mode 100644 index 0000000..1d86a1f Binary files /dev/null and b/KaraKeep/attachments/90e61b51-7cff-4b61-9672-fe6f64dbdd3f-redhead,-face,-braids,.jpg differ diff --git a/KaraKeep/attachments/94834e31-cabc-4c43-9fef-ee27d58ebf41-Pokemon-Champions-Speed-Tiers.jpg b/KaraKeep/attachments/94834e31-cabc-4c43-9fef-ee27d58ebf41-Pokemon-Champions-Speed-Tiers.jpg new file mode 100644 index 0000000..5be55ce Binary files /dev/null and b/KaraKeep/attachments/94834e31-cabc-4c43-9fef-ee27d58ebf41-Pokemon-Champions-Speed-Tiers.jpg differ diff --git a/KaraKeep/attachments/9a9b353a-8157-4a4d-83fb-110aacca7bc3-dm-crypt-Encrypting-an-entire.jpg b/KaraKeep/attachments/9a9b353a-8157-4a4d-83fb-110aacca7bc3-dm-crypt-Encrypting-an-entire.jpg new file mode 100644 index 0000000..5781381 --- /dev/null +++ b/KaraKeep/attachments/9a9b353a-8157-4a4d-83fb-110aacca7bc3-dm-crypt-Encrypting-an-entire.jpg @@ -0,0 +1,951 @@ +

+ +The following are examples of common scenarios of full system encryption with dm-crypt. They explain all the adaptations that need to be done to the normal installation procedure. All the necessary tools are on the installation image. +

If you want to encrypt an existing unencrypted file system, see dm-crypt/Device encryption#Encrypt an existing unencrypted file system. +

+ +

Overview

+

Securing a root file system is where dm-crypt 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 locate and /var/log/. Furthermore, an encrypted root file system makes tampering with the system far more difficult, as everything except the boot loader and (usually) the kernel is encrypted. +

All scenarios illustrated in the following share these advantages, other pros and cons differentiating them are summarized below: +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Scenarios +Advantages +Disadvantages +
#LUKS on a partition +

shows a basic and straightforward set-up for a fully LUKS encrypted root. +

+		 + + +
  • Inflexible; disk-space to be encrypted has to be pre-allocated
+
#LUKS on a partition with TPM2 and Secure Boot +

Similar to the example above, with Secure Boot and TPM2 providing additional layers of security. +

+		 +

Same advantages as above, and +

+
  • Secure Boot allows protection against Evil maid attacks
    • +
  • TPM2 prevents the system from being unlocked if Secure Boot is disabled or modified
+		 +
  • Same disadvantages as above.
+
#LVM on LUKS +

achieves partitioning flexibility by using LVM inside a single LUKS encrypted partition. +

+		 +
  • Simple partitioning with knowledge of LVM
    • +
  • Only one key required to unlock all volumes (e.g. easy resume-from-disk setup)
    • +
  • Volume layout not visible when locked
    • +
  • Easiest method to allow suspension to disk
+		 +
  • LVM adds an additional mapping layer and hook
    • +
  • Less useful, if a singular volume should receive a separate key
    • +
  • 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.
+
#LUKS on LVM +

uses dm-crypt only after the LVM is setup. +

+		 +
  • LVM can be used to have encrypted volumes span multiple disks
    • +
  • Easy mix of un-/encrypted volume groups
+		 +
  • Complex; changing volumes requires changing encryption mappers too
    • +
  • Volumes require individual keys
    • +
  • LVM layout is visible when locked
    • +
  • Slower boot time; each encrypted LV must be unlocked seperately
+
#LUKS on software RAID +

uses dm-crypt only after RAID is setup. +

+		 +
  • Analogous to LUKS on LVM
+		 +
  • Analogous to LUKS on LVM and Encrypted boot partition (GRUB)
+
#Plain dm-crypt +

uses dm-crypt plain mode, i.e. without a LUKS header and its options for multiple keys. +

This scenario also employs USB devices for /boot and key storage, which may be applied to the other scenarios. +

+		 + + +
  • High care to all encryption parameters is required
    • +
  • Single encryption key and no option to change it
    • +
  • Very complicated setup for a regular used system
+
#Encrypted boot partition (GRUB) +

shows how to encrypt the boot partition using the GRUB boot loader. +

This scenario also employs an EFI system partition, which may be applied to the other scenarios. +

+		 +
  • Same advantages as the scenario the installation is based on (LVM on LUKS for this particular example)
    • +
  • Less data is left unencrypted, i.e. the boot loader and the EFI system partition, if present
+		 +
  • Same disadvantages as the scenario the installation is based on (LVM on LUKS for this particular example)
    • +
  • More complicated configuration
    • +
  • Not supported by other boot loaders
    • +
  • GRUB takes a long time to unlock LUKS, thus slowing down boot
+
#Root on ZFS + +
  • In the case of a encrypted zpool all datasets are contained inside the same cryptographic environment making it easy to dual-boot and share data across installs.
    • +
  • Backups can be made to a destination with an unencrypted zfs setup. Snapshots will be encrypted natively on the destination.
+		 +
  • ZFS will not encrypt 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).
    • +
  • Pool creation requires the user to have a more in-depth knowledge of disks geometry setting even block size (ashift) for best performance.
    • +
  • ZFS has some caveats with its own implementation of aes and some encryption algorithms may not perform well.
    • +
  • Swap on a zvol or file inside a dataset is a old and well-known issue with no workaround other than having your swap in another partition or lv and suspend to disk disabled (see below).
+
+

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 Data-at-rest encryption to plan ahead. +

See dm-crypt/Drive preparation#Partitioning for a general overview of the partitioning strategies used in the scenarios. +

Another area to consider is whether to set up an encrypted swap partition and what kind. See dm-crypt/Swap encryption for alternatives. +

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 dm-crypt/Specialties#Securing the unencrypted boot partition for further possibilities after following one of the scenarios. +

For solid state drives you might want to consider enabling TRIM support, but be warned, there are potential security implications. See dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD) for more information. +

+

Warning

  • In any scenario, never use file system repair software such as fsck 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.
    • +
  • 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 --pbkdf-memory option to control memory usage.[1]
    • +
  • GRUB's support for LUKS2 is limited; see GRUB#Encrypted /boot for details. Use LUKS2 with PBKDF2 (cryptsetup luksFormat --pbkdf pbkdf2) for partitions that GRUB will need to unlock.
    • +
  • 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. Reference here.
+
+

LUKS on a partition

+

This example covers a full system encryption with dm-crypt + LUKS in a simple partition layout: +

+
+-----------------------+------------------------+-----------------------+
+| 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              |                       |
++-----------------------+------------------------+-----------------------+
+
+

The first steps can be performed directly after booting the Arch Linux install image. +

+

Preparing the disk

+

Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in dm-crypt/Drive preparation. +

Then create the needed partitions, at least one for / (e.g. /dev/sda2) and /boot (/dev/sda1). See Partitioning. +

+

Preparing non-boot partitions

+

This and the next section replace the instructions of Installation guide#Format the partitions. +

The following commands create and mount the encrypted root partition. They correspond to the procedure described in detail in dm-crypt/Device encryption#Encrypting devices with LUKS mode. If you want to use particular non-default encryption options (e.g. cipher, key length, sector size), see the encryption options before executing the first command. +

+
# cryptsetup -v luksFormat /dev/sda2
+# cryptsetup open /dev/sda2 root
+
+

Create a file system on unlocked LUKS device. For example, to create an Ext4 file system, run: +

+
# mkfs.ext4 /dev/mapper/root
+
+

Mount the root volume to /mnt: +

+
# mount /dev/mapper/root /mnt
+
+

Check the mapping works as intended: +

+
# umount /mnt
+# cryptsetup close root
+# cryptsetup open /dev/sda2 root
+# mount /dev/mapper/root /mnt
+
+

If you created separate partitions (e.g. /home), these steps have to be adapted and repeated for all of them, except for /boot. See dm-crypt/Encrypting a non-root file system#Automated unlocking and mounting on how to handle additional partitions at boot. +

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 crypttab. See dm-crypt/Device encryption#Using LUKS to format partitions with a keyfile for instructions. +

+

Preparing the boot partition

+

What you do have to setup is a non-encrypted /boot partition, which is needed for an encrypted root. For an EFI system partition on UEFI systems, execute the following command to format the newly created partition: +

+

Warning 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.

+
# mkfs.fat -F32 /dev/sda1
+
+

or for an ordinary boot partition on BIOS systems: +

+
# mkfs.ext4 /dev/sda1
+
+

Afterwards create the directory for the mountpoint and mount the partition: +

+
# mount --mkdir /dev/sda1 /mnt/boot
+
+

Mounting the devices

+

At the step Installation guide#Mount the file systems, you should mount the /dev/mapper/* devices (the contents of LUKS), not the actual partitions. Of course, the partition for /boot, which is not encrypted, should still be mounted directly. During installation, it should be mounted to /mnt/boot (assuming the device for the root file system is mounted to /mnt during installation). +

+

Configuring mkinitcpio

+

Before following Installation guide#Initramfs you must do the following to your new system: +

If using the default systemd-based initramfs, add the keyboard and sd-encrypt hooks to mkinitcpio.conf. If you use a non-US console keymap or a non-default console font, additionally add the sd-vconsole hook. +

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

If using a busybox-based initramfs, add the keyboard and encrypt hooks. If you use a non-US console keymap or a non-default console font, additionally add the keymap and consolefont hooks, respectively. +

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

Regenerate the initramfs after saving the changes. See dm-crypt/System configuration#mkinitcpio for details and other hooks that you may need. +

+

Configuring the boot loader

+

In order to unlock the encrypted root partition at boot, the following kernel parameters need to be set by the boot loader: +

+
rd.luks.name=device-UUID=root root=/dev/mapper/root
+
+

If using the encrypt hook, the following need to be set instead: +

+
cryptdevice=UUID=device-UUID:root root=/dev/mapper/root
+
+

The device-UUID refers to the UUID of the LUKS superblock. See Persistent block device naming for details. +

Also see dm-crypt/System configuration#Kernel parameters for more details. +

+

Tip If the root partition is on the same disk as the /boot partition and your UEFI boot loader supports GPT partition automounting, you can configure the partition type GUID (type should be "Root partition", not "LUKS partition") and rely on systemd-gpt-auto-generator(8) instead of using the kernel parameters.

+

LUKS on a partition with TPM2 and Secure Boot

+

This example is similar to #LUKS on a partition, but integrates the use of Secure Boot and a Trusted Platform Module (TPM), enhancing the overall security of the boot process. +

In this configuration, only the EFI system partition remains unencrypted, housing a unified kernel image and systemd-boot—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. +

Make sure to thoroughly read the discussion and warnings in Trusted Platform Module#LUKS encryption. +

In this example, partitions are created respecting systemd#GPT partition automounting, there is no need for an fstab or crypttab file. +

+
+-----------------------+---------------------------------+
+| EFI system partition  | LUKS encrypted root partition   |
+|                       |                                 |
+|                       |                                 |
+| /boot                 | /                               |
+|                       |                                 |
+|                       | /dev/mapper/root                |
+|                       |---------------------------------|
+| /dev/sda1             | /dev/sda2                       |
++-----------------------+---------------------------------+
+
+

Follow the Installation guide up to step Installation guide#Partition the disks. +

+

Preparing the disk

+

Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in dm-crypt/Drive preparation. +

Partition the drive with the GUID Partition Table (GPT). +

Create an EFI system partition (e.g., /dev/sda1) with an appropriate size. This will be mounted at /boot. +

In the remaining space, create a root partition (e.g., /dev/sda2) that will be encrypted and mounted at /. Set the partition type GUID for the root partition using type "Linux root (x86-64)" in fdisk or type code 8304 in gdisk. +

Check the output of fdisk -l to make sure partition types are properly set. +

+

Preparing the root partition

+

The following commands create and mount the encrypted root partition. They correspond to the procedure described in detail in dm-crypt/Device encryption#Encrypting devices with LUKS mode. +

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 encryption options before executing the first command. +

+

Warning 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.

+

Create the LUKS volume and mount it: +

+
# cryptsetup luksFormat /dev/sda2
+# cryptsetup open /dev/sda2 root
+
+

Create a file system on unlocked LUKS device. For example, to create an Ext4 file system, run: +

+
# mkfs.ext4 /dev/mapper/root
+
+

Mount the root volume to /mnt: +

+
# mount /dev/mapper/root /mnt
+
+

Preparing the EFI system partition

+

Format the newly created EFI system partition as instructed in EFI system partition#Format the partition and mount it afterwards. +

+
# mount --mkdir /dev/sda1 /mnt/boot
+
+

Continue the installation process until Installation guide#Initramfs. You can skip Installation guide#Fstab. +

+

Configuring mkinitcpio

+

To build a working systemd based initramfs, modify the HOOKS= line in mkinitcpio.conf as follows: +

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

Next, see Unified kernel image#mkinitcpio to configure mkinitcpio for Unified kernel images. +

Do not regenerate the initramfs yet, as the /boot/EFI/Linux directory needs to be created by the boot loader installer first. +

+

Installing the boot loader

+

You can configure your system to directly boot the UEFI image without any boot loader, see Unified kernel image#Directly from UEFI. +

If a boot loader is desired, continue installing systemd-boot with +

+
# bootctl install
+
+

The Unified kernel image generated by mkinitcpio will be automatically recognized and does not need an entry in /boot/loader/entries/. +

See systemd-boot#Updating the UEFI boot manager and systemd-boot#Loader configuration for further configuration. +

+

Finalizing the installation

+

First, Regenerate the initramfs, and make sure the image generation is successful. +

Make sure you did not forget to set a root password, reboot to finish the installation. +

+

Secure Boot

+

You can now sign the boot loader executables and the EFI binary, in order to enable Secure Boot. For a quick and easy way, see Unified Extensible Firmware Interface/Secure Boot#Assisted process with sbctl. +

+

Enrolling the TPM

+

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 PCR 7 (Secure Boot 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 systemd-cryptenroll#Trusted Platform Module and systemd-cryptenroll(1). +

+
# systemd-cryptenroll /dev/sda2 --recovery-key
+# systemd-cryptenroll /dev/sda2 --wipe-slot=empty --tpm2-device=auto --tpm2-pcrs=7+15:sha256=0000000000000000000000000000000000000000000000000000000000000000
+
+

Note

  • If a passphrase was set during the LUKS format process, the corresponding keyslot should be wiped (e.g. --wipe-slot=0).
    • +
  • You can list keyslots using systemd-cryptenroll /dev/sda2. See systemd-cryptenroll#List keyslots.
+
+

Tip Add --tpm2-with-pin=yes to require an additional PIN to unlock at boot time.

+

Warning

  • Make sure Secure Boot is active and in user mode when binding to PCR 7, otherwise, unauthorized boot devices could unlock the encrypted volume.
    • +
  • The state of PCR 7 can change if firmware certificates change, which can risk locking the user out. This can be implicitly done by fwupd[2] or explicitly by rotating Secure Boot keys.
+
+

LVM on LUKS

+

The straightforward method is to set up LVM 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. +

The disk layout in this example is: +

+
+-----------------------------------------------------------------------+ +----------------+
+| 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      |
++-----------------------------------------------------------------------+ +----------------+
+
+ +

Tip Two variants of this setup: +

+
+

Preparing the disk

+

Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in dm-crypt/Drive preparation. +

+ +

Create a partition to be mounted at /boot with a size of 1 GiB or more. +

+ +

Create a partition which will later contain the encrypted container. +

Create the LUKS encrypted container at the designated partition. Enter the chosen password twice. +

+
# cryptsetup luksFormat /dev/sda1
+
+

For more information about the available cryptsetup options see the LUKS encryption options prior to above command. +

Open the container: +

+
# cryptsetup open /dev/sda1 cryptlvm
+
+

The decrypted container is now available at /dev/mapper/cryptlvm. +

+

Preparing the logical volumes

+

Create a physical volume on top of the opened LUKS container: +

+
# pvcreate /dev/mapper/cryptlvm
+
+

Create a volume group (in this example named MyVolGroup, but it can be whatever you want) and add the previously created physical volume to it: +

+
# vgcreate MyVolGroup /dev/mapper/cryptlvm
+
+

Create all your logical volumes on the volume group: +

+

Tip If a logical volume will be formatted with ext4, leave at least 256 MiB free space in the volume group to allow using e2scrub(8). After creating the last volume with -l 100%FREE, this can be accomplished by reducing its size with lvreduce -L -256M MyVolGroup/home.

+
# lvcreate -L 4G -n swap MyVolGroup
+# lvcreate -L 32G -n root MyVolGroup
+# lvcreate -l 100%FREE -n home MyVolGroup
+
+

Format your file systems on each logical volume. For example, using Ext4 for the root and home volumes: +

+
# mkfs.ext4 /dev/MyVolGroup/root
+# mkfs.ext4 /dev/MyVolGroup/home
+# mkswap /dev/MyVolGroup/swap
+
+

Mount your file systems: +

+
# mount /dev/MyVolGroup/root /mnt
+# mount --mkdir /dev/MyVolGroup/home /mnt/home
+# swapon /dev/MyVolGroup/swap
+
+

Preparing the boot partition

+

The boot loader loads the kernel, initramfs, and its own configuration files from the /boot directory. Any file system on a disk that can be read by the boot loader is eligible. +

Create a file system on the partition intended for /boot. For an EFI system partition on UEFI systems, execute the following command to format the newly created partition: +

+

Warning 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.

+
# mkfs.fat -F32 /dev/sdb1
+
+

or for an ordinary boot partition on BIOS systems: +

+
# mkfs.ext4 /dev/sdb1
+
+

Mount the partition to /mnt/boot: +

+
# mount --mkdir /dev/sdb1 /mnt/boot
+
+

At this point resume the common Installation guide#Installation steps. Return to this page to customize the Initramfs and Boot loader steps. +

+

Configuring mkinitcpio

+

Make sure the lvm2 package is installed. +

If using the default systemd-based initramfs, add the keyboard, sd-encrypt and lvm2 hooks to mkinitcpio.conf. If you use a non-US console keymap or a non-default console font, additionally add the sd-vconsole hook. +

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

If using a busybox-based initramfs, instead add the keyboard, encrypt and lvm2 hooks. If you use a non-US console keymap or a non-default console font, additionally add the keymap and consolefont hooks, respectively. +

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

Regenerate the initramfs after saving the changes. See dm-crypt/System configuration#mkinitcpio for details and other hooks that you may need. +

+

Configuring the boot loader

+

In order to unlock the encrypted root partition at boot, the following kernel parameters need to be set by the boot loader: +

+
rd.luks.name=device-UUID=cryptlvm root=/dev/MyVolGroup/root
+
+

If using the encrypt hook, the following needs to be set instead: +

+
cryptdevice=UUID=device-UUID:cryptlvm root=/dev/MyVolGroup/root
+
+

The device-UUID refers to the UUID of the LUKS superblock, in this example it is the UUID of /dev/sda1 e.g. a144e931-7580-40bf-ae8c-6beff4c1ac45. See Persistent block device naming for details. +

If using dracut, these parameters are known to work: +

+
rd.luks.uuid=device-UUID root=/dev/MyVolGroup/root
+
+

you may need a more extensive list of parameters, try: +

+
rd.luks.uuid=luks-deviceUUID rd.lvm.lv=MyVolGroup/root  rd.lvm.lv=MyVolGroup/swap  root=/dev/mapper/MyVolGroup-root rootfstype=ext4 rootflags=rw,relatime
+
+

See dm-crypt/System configuration#Kernel parameters for details. +

+

LUKS on LVM

+

To use encryption on top of LVM, 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. +

+

Tip Unlike #LVM on LUKS, this method allows normally spanning the logical volumes over multiple disks.

+

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. +

If you want to span a logical volume over multiple disks that have already been set up, or expand the logical volume for /home (or any other volume), a procedure to do so is described in dm-crypt/Specialties#Expanding LVM on multiple disks. It is important to note that the LUKS encrypted container has to be resized as well. +

+
+

This article or section needs expansion.

+

Reason: The intro of this scenario needs some adjustment now that a comparison has been added to #Overview. A suggested structure is to make it similar to the #LUKS on a partition intro. (Discuss in Talk:Dm-crypt/Encrypting an entire system)

+
+

Preparing the disk

+

Partitioning scheme: +

+
+----------------+-------------------------------------------------------------------------------------------------+
+| 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                                                     |
++----------------+-------------------------------------------------------------------------------------------------+
+
+

Randomise /dev/sda2 according to dm-crypt/Drive preparation#dm-crypt wipe on an empty device or partition. +

+

Preparing the logical volumes

+
# 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
+
+
# cryptsetup luksFormat /dev/MyVolGroup/cryptroot
+# cryptsetup open /dev/MyVolGroup/cryptroot root
+
+

Create a file system on unlocked LUKS device and mount it. For example, to create an Ext4 file system, run: +

+
# mkfs.ext4 /dev/mapper/root
+# mount /dev/mapper/root /mnt
+
+

More information about the encryption options can be found in dm-crypt/Device encryption#Encryption options for LUKS mode. +Note that /home will be encrypted in #Encrypting logical volume /home. +

+

Tip If you ever have to access the encrypted root from the Arch-ISO, the above open action will allow you to after the LVM shows up.

+

Preparing the boot partition

+

Create a file system on the partition intended for /boot. For an EFI system partition on UEFI systems, execute the following command to format the newly created partition: +

+

Warning 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.

+
# mkfs.fat -F32 /dev/sda1
+
+

or for an ordinary boot partition on BIOS systems: +

+
# mkfs.ext4 /dev/sda1
+
+

Afterwards create the directory for the mountpoint and mount the partition: +

+
# mount --mkdir /dev/sda1 /mnt/boot
+
+

Configuring mkinitcpio

+

Make sure the lvm2 package is installed. +

If using the default systemd-based initramfs, add the keyboard, sd-encrypt and lvm2 hooks to mkinitcpio.conf. If you use a non-US console keymap or a non-default console font, additionally add the sd-vconsole hook. +

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

If using a busybox-based initramfs, instead add the keyboard, encrypt and lvm2 hooks. If you use a non-US console keymap or a non-default console font, additionally add the keymap and consolefont hooks, respectively. +

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

Regenerate the initramfs after saving the changes. See dm-crypt/System configuration#mkinitcpio for details and other hooks that you may need. +

+

Configuring the boot loader

+

In order to unlock the encrypted root partition at boot, the following kernel parameters need to be set by the boot loader: +

+
rd.luks.name=device-UUID=root root=/dev/mapper/root
+
+

If using the encrypt hook, the following need to be set instead: +

+
cryptdevice=UUID=device-UUID:root root=/dev/mapper/root
+
+

The device-UUID refers to the UUID of the LUKS superblock, in this example it is the UUID of /dev/MyVolGroup/cryptroot e.g. a144e931-7580-40bf-ae8c-6beff4c1ac45. See Persistent block device naming for details. +

See dm-crypt/System configuration#Kernel parameters for details. +

+

Configuring fstab and crypttab

+

Both crypttab and fstab 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: +

+
/etc/crypttab
+
swap	/dev/MyVolGroup/cryptswap	/dev/urandom	swap,cipher=aes-xts-plain64,size=256,sector-size=4096
+
/etc/fstab
+
/dev/mapper/root                          /     ext4   defaults  0 1
+UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /boot ext4   defaults  0 2
+/dev/mapper/swap                          none  swap   defaults  0 0
+

Encrypting logical volume /home

+

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 /home 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 keyfile is created: +

+
# dd bs=512 count=4 if=/dev/random iflag=fullblock | install -m 0600 /dev/stdin /etc/cryptsetup-keys.d/home.key
+
+

The logical volume is encrypted with it: +

+
# 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
+
+

Create a file system on unlocked LUKS device and mount it. For example, to create an Ext4 file system, run: +

+
# mkfs.ext4 /dev/mapper/home
+# mount /dev/mapper/home /home
+
+

The encrypted mount is configured in both crypttab and fstab: +

+
/etc/crypttab
+
home	/dev/MyVolGroup/crypthome   none
+
+
/etc/fstab
+
/dev/mapper/home        /home   ext4        defaults        0       2
+
+

LUKS on software RAID

+

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 /boot) for all drives, with the SSDs in a RAID0 array, and keyfiles used to unlock all encryption after GRUB is given a correct passphrase at boot. +

This setup utilizes a very simplistic partitioning scheme, with all the available RAID storage being mounted at / (no separate /boot partition), and the decrypted HDD being mounted at /data. +

Please note that regular backups 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 RAID level if fault tolerance is important to you. +

The encryption is not deniable in this setup. +

For the sake of the instructions below, the following block devices are used: +

+
/dev/sda = first SSD
+/dev/sdb = second SSD
+/dev/sdc = HDD
+
+
+---------------------+---------------------------+---------------------------+ +---------------------+---------------------------+---------------------------+ +---------------------------+
+| 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                 |
++---------------------+---------------------------+---------------------------+ +---------------------+---------------------------+---------------------------+ +---------------------------+
+
+

Be sure to substitute them with the appropriate device designations for your setup, as they may be different. +

+

Preparing the disks

+

Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in dm-crypt/Drive preparation. +

For BIOS systems with GPT, create a BIOS boot partition with size of 1 MiB for GRUB to store the second stage of BIOS boot loader. Do not mount the partition. +

For UEFI systems create an EFI system partition with an appropriate size, it will later be mounted at /efi. +

In the remaining space on the drive create a partition (/dev/sda3 in this example) for "Linux RAID". Choose partition type ID fd for MBR or partition type GUID A19D880F-05FC-4D3B-A006-743F0F84911E for GPT. +

Once partitions have been created on /dev/sda, the following commands can be used to clone them to /dev/sdb. +

+
# sfdisk -d /dev/sda > sda.dump
+# sfdisk /dev/sdb < sda.dump
+
+

The HDD is prepared with a single Linux partition covering the whole drive at /dev/sdc1. +

+

Building the RAID array

+

Create the RAID array for the SSDs. +

+

Note

  • All parts of an EFI system partition RAID array must be individually usable, that means that ESP can only placed in a RAID1 array.
    • +
  • The RAID superblock must be placed at the end of the EFI system partition using --metadata=1.0, otherwise the firmware will not be able to access the partition.
+
+
# mdadm --create --verbose --level=1 --metadata=1.0 --raid-devices=2 /dev/md/ESP /dev/sda2 /dev/sdb2
+
+

This example utilizes RAID0 for root, you may wish to substitute a different level based on your preferences or requirements. +

+
# mdadm --create --verbose --level=0 --metadata=1.2 --raid-devices=2 /dev/md/root /dev/sda3 /dev/sdb3
+
+

Preparing the block devices

+

As explained in dm-crypt/Drive preparation, the devices are wiped with random data utilizing /dev/zero and a crypt device with a random key. Alternatively, you could use dd with /dev/random or /dev/urandom, though it will be much slower. +

+
# 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
+
+

And repeat above for the HDD (/dev/sdc1 in this example). +

Set up encryption for /dev/md/root: +

+

Warning GRUB's support for LUKS2 is limited; see GRUB#Encrypted /boot for details. Use LUKS2 with PBKDF2 (cryptsetup luksFormat --pbkdf pbkdf2) for partitions that GRUB will need to unlock.

+
# cryptsetup -v luksFormat --pbkdf pbkdf2 /dev/md/root
+# cryptsetup open /dev/md/root root
+
+

Create a file system on unlocked LUKS device. For example, to create an Ext4 file system, run: +

+
# mkfs.ext4 /dev/mapper/root
+
+

Mount the root volume to /mnt: +

+
# mount /dev/mapper/root /mnt
+
+

And repeat for the HDD: +

+
# cryptsetup -v luksFormat /dev/sdc1
+# cryptsetup open /dev/sdc1 data
+# mkfs.ext4 /dev/mapper/data
+# mount --mkdir /dev/mapper/data /mnt/data
+
+

For UEFI systems, format the newly created EFI system partition and mount it: +

+

Warning 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.

+
# mkfs.fat -F32 /dev/md/ESP
+# mount --mkdir /dev/md/ESP /mnt/efi
+
+

Configuring GRUB

+

Configure GRUB for the LUKS encrypted system by editing /etc/default/grub with the following: +

+
GRUB_CMDLINE_LINUX="cryptdevice=/dev/md/root:root"
+GRUB_ENABLE_CRYPTODISK=y
+
+

If you have a USB keyboard on a newer system either enable legacy USB support in firmware or add the following to /etc/default/grub: +

+
GRUB_TERMINAL_INPUT="usb_keyboard"
+GRUB_PRELOAD_MODULES="usb usb_keyboard ohci uhci ehci"
+
+

Otherwise you may not be able to use your keyboard at the LUKS prompt. +

See dm-crypt/System configuration#Kernel parameters and GRUB#Encrypted /boot for details. +

Complete the GRUB install to both SSDs (in reality, installing only to /dev/sda will work). +

+
# 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
+
+

Creating the keyfiles

+

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 keyfile for the encryption and adding it to the initramfs image to allow the encrypt hook to unlock the root device. See dm-crypt/Device encryption#With a keyfile embedded in the initramfs for details. +

+
  • Create the keyfile and add the key to /dev/md/root.
    • +
  • Create another keyfile for the HDD (/dev/sdc1) 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 /etc/crypttab to decrypt the HDD at boot. See dm-crypt/System configuration#Unlocking with a keyfile.
+

Configuring the system

+

Edit fstab to mount the root and data block devices and the ESP: +

+
/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
+
+

Save the RAID configuration: +

+
# mdadm --detail --scan >> /etc/mdadm.conf
+
+

Edit mkinitcpio.conf to include your keyfile and add the proper hooks: +

+
FILES=(/crypto_keyfile.bin)
+HOOKS=(base udev autodetect microcode modconf kms keyboard keymap consolefont block mdadm_udev encrypt filesystems fsck)
+
+

See dm-crypt/System configuration#mkinitcpio for details. +

+

Plain dm-crypt

+

Contrary to LUKS, dm-crypt plain 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 deniable encryption. See also wikipedia:Disk encryption#Full disk encryption. +

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. LUKS features like key management with multiple passphrases/key-files, master key backups or re-encrypting a device in-place are unavailable with plain mode. +

Plain 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 plain mode also requires more manual configuration of encryption options to achieve the same cryptographic strength. See also Data-at-rest encryption#Cryptographic metadata. Using plain mode could also be considered if concerned with the problems explained in dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD). +

+

Tip If headerless encryption is your goal but you are unsure about the lack of key-derivation with plain mode, then two alternatives are: +

  • dm-crypt LUKS mode with a detached header by using the cryptsetup --header option. It cannot be used with the standard encrypt hook, but the hook may be modified.
    • +
  • tcplay which offers headerless encryption but with the PBKDF2 function.
+
+

The scenario uses two USB sticks: +

+
  • 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;
    • +
  • 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 Wikipedia:Security through obscurity, follow dm-crypt/Device encryption#Keyfiles to prepare the keyfile.
+

The disk layout is: +

+
+----------------------+----------------------+----------------------+ +----------------+ +----------------+
+| 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    |
++--------------------------------------------------------------------+ +----------------+ +----------------+
+
+

Tip

  • It is also possible to use a single USB key physical device: +
    • By putting the key on another partition (/dev/sdb2) of the USB storage device (/dev/sdb).
      • +
    • By copying the keyfile to the initramfs directly. An example keyfile /etc/cryptsetup-keys.d/root.key gets copied to the initramfs image by setting FILES=(/etc/cryptsetup-keys.d/root.key) in /etc/mkinitcpio.conf. The way to instruct the encrypt hook to read the keyfile in the initramfs image is using rootfs: prefix before the filename, e.g. cryptkey=rootfs:/etc/cryptsetup-keys.d/root.key.
    • +
  • Another option is using a passphrase with good entropy.
+
+

Preparing the disk

+

It is vital that the mapped device is filled with random data. In particular this applies to the scenario use case we apply here. +

See dm-crypt/Drive preparation and dm-crypt/Drive preparation#dm-crypt specific methods +

+

Preparing the non-boot partitions

+

See dm-crypt/Device encryption#Encryption options for plain mode for details. +

Using the device /dev/sda, with the aes-xts cipher with a 512 bit key size and using a keyfile we have the following options for this scenario: +

+
# cryptsetup open --type plain --cipher=aes-xts-plain64 --offset=0 --key-file=/dev/sdc --key-size=512 --sector-size 4096 /dev/sda cryptlvm
+
+

Unlike encrypting with LUKS, the above command must be executed in full whenever the mapping needs to be re-established, so it is important to remember the cipher, and key file details. +

We can now check a mapping entry has been made for /dev/mapper/cryptlvm: +

+
# fdisk -l
+
+

Tip

  • 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.
    • +
  • If a logical volume will be formatted with ext4, leave at least 256 MiB free space in the volume group to allow using e2scrub(8). After creating the last volume with -l 100%FREE, this can be accomplished by reducing its size with lvreduce -L -256M MyVolGroup/home.
+
+

Next, we setup LVM logical volumes on the mapped device. See Install Arch Linux on LVM for further details: +

+
# 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
+
+

We format and mount them and activate swap. See File systems#Create a file system for further details: +

+
# 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
+
+

Preparing the boot partition

+

The /boot 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 partitioning tool of your choice. +

Create a file system on the newly created partition intended for /boot: +

+

Warning 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.

+
# mkfs.fat -F32 /dev/sdb1
+# mount --mkdir /dev/sdb1 /mnt/boot
+
+

Configuring mkinitcpio

+

Make sure the lvm2 package is installed. +

If using a busybox-based initramfs, add the keyboard, encrypt and lvm2 hooks. If you use a non-US console keymap or a non-default console font, additionally add the keymap and consolefont hooks, respectively. +

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

Regenerate the initramfs after saving the changes. See dm-crypt/System configuration#mkinitcpio for details and other hooks that you may need. +

+

Configuring the boot loader

+

In order to boot the encrypted root partition, the following kernel parameters need to be set by the boot loader (note that 64 is the number of bytes in 512 bits): +

+
cryptdevice=/dev/disk/by-id/disk-ID-of-sda:cryptlvm:sector-size=4096 cryptkey=/dev/disk/by-id/disk-ID-of-sdc:0:64 crypto=:aes-xts-plain64:512:0:
+
+

The disk-ID-of-disk refers to the id of the referenced disk. See Persistent block device naming for details. +

See dm-crypt/System configuration#Kernel parameters for details and other parameters that you may need. +

+

Tip If using GRUB, you can install it on the same USB as the /boot partition. +

For BIOS: +

+
# grub-install --target=i386-pc --recheck /dev/sdb
+

For UEFI: +

+
# grub-install --target=x86_64-efi --efi-directory=/boot --removable
+
+

Post-installation

+

You may wish to remove the USB sticks after booting. Since the /boot partition is not usually needed, the noauto option can be added to the relevant line in /etc/fstab: +

+
/etc/fstab
+
# /dev/sdb1
+UUID=XXXX-XXXX /boot vfat noauto,rw,noatime 0 2
+

However, when an update to anything used in the initramfs, or a kernel, or the boot loader is required; the /boot partition must be present and mounted. As the entry in fstab already exists, it can be mounted simply with: +

+
# mount /boot
+
+

Encrypted boot partition (GRUB)

+

This setup utilizes the same partition layout and configuration as the previous #LVM on LUKS section, with the difference that the GRUB boot loader is used since it is capable of booting from an LVM logical volume and a LUKS-encrypted /boot. See also GRUB#Encrypted /boot. +

The disk layout in this example is: +

+
+---------------------+----------------------+----------------------+----------------------+----------------------+
+| 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                              |
++---------------------+----------------------+--------------------------------------------------------------------+
+
+

Tip

  • 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 #LVM on LUKS.
    • +
  • You can use cryptboot script from cryptbootAUR package for simplified encrypted boot management (mounting, unmounting, upgrading packages) and as a defense against Evil Maid attacks with UEFI Secure Boot. For more information and limitations see cryptboot project page.
+
+

Preparing the disk

+

Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in dm-crypt/Drive preparation. +

For UEFI systems create an EFI system partition with an appropriate size, it will later be mounted at /efi. +

For BIOS/GPT setups create a BIOS boot partition 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. +

Create a partition of type 8309, which will later contain the encrypted container for the LVM. +

Create the LUKS encrypted container: +

+

Warning GRUB's support for LUKS2 is limited; see GRUB#Encrypted /boot for details. Use LUKS2 with PBKDF2 (cryptsetup luksFormat --pbkdf pbkdf2) for partitions that GRUB will need to unlock.

+
# cryptsetup luksFormat --pbkdf pbkdf2 /dev/sda3
+
+

For more information about the available cryptsetup options see the LUKS encryption options prior to above command. +

Your partition layout should look similar to this: +

+
# gdisk -l /dev/sda
+
...
+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
+
+

Open the container: +

+
# cryptsetup open /dev/sda3 cryptlvm
+
+

The decrypted container is now available at /dev/mapper/cryptlvm. +

+

Preparing the logical volumes

+

The LVM logical volumes of this example follow the exact layout as the #LVM on LUKS scenario. Therefore, please follow #Preparing the logical volumes above and adjust as required. +

For UEFI systems, create a mountpoint for the EFI system partition at /efi for compatibility with grub-install and mount it: +

+
# mount --mkdir /dev/sda2 /mnt/efi
+
+

At this point, you should have the following partitions and logical volumes inside of /mnt: +

+
$ lsblk
+
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
+
+

Now at this point resume the common Installation guide#Installation steps. Return to this page to customize the Initramfs and Boot loader steps. +

+

Configuring mkinitcpio

+

Make sure the lvm2 package is installed. +

If using the default systemd-based initramfs, add the keyboard, sd-encrypt and lvm2 hooks to mkinitcpio.conf. If you use a non-US console keymap or a non-default console font, additionally add the sd-vconsole hook. +

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

If using a busybox-based initramfs, instead add the keyboard, encrypt and lvm2 hooks. If you use a non-US console keymap or a non-default console font, additionally add the keymap and consolefont hooks, respectively. +

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

Regenerate the initramfs after saving the changes. See dm-crypt/System configuration#mkinitcpio for details and other hooks that you may need. +

+

Configuring GRUB

+

Configure GRUB to allow booting from /boot on a LUKS encrypted partition: +

+
/etc/default/grub
+
GRUB_ENABLE_CRYPTODISK=y
+

Set the kernel parameters, so that the initramfs can unlock the encrypted root partition. Using the sd-encrypt hook: +

+
/etc/default/grub
+
GRUB_CMDLINE_LINUX="... rd.luks.name=device-UUID=cryptlvm ..."
+

If using the encrypt hook, the following need to be set instead: +

+
/etc/default/grub
+
GRUB_CMDLINE_LINUX="... cryptdevice=UUID=device-UUID:cryptlvm ..."
+

See dm-crypt/System configuration#Kernel parameters and GRUB#Encrypted /boot for details. The device-UUID refers to the UUID of the LUKS superblock, in this example it is the UUID of /dev/sda3 (the partition which holds the lvm containing the root file system) e.g. a144e931-7580-40bf-ae8c-6beff4c1ac45. See Persistent block device naming for details. +

install GRUB to the mounted ESP for UEFI booting: +

+
# grub-install --target=x86_64-efi --efi-directory=/efi --bootloader-id=GRUB --recheck
+
+

install GRUB to the disk for BIOS booting: +

+
# grub-install --target=i386-pc --recheck /dev/sda
+
+

Generate GRUB's configuration file: +

+
# grub-mkconfig -o /boot/grub/grub.cfg
+
+

If all commands finished without errors, GRUB should prompt for the passphrase to unlock the /dev/sda3 partition after the next reboot. +

+

Avoiding having to enter the passphrase twice

+ +

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. +

This section deals with extra configuration to let the system boot by only entering the passphrase once, in GRUB. This is accomplished by with a keyfile embedded in the initramfs. +

First create a keyfile and add it as LUKS key: +

+
# 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
+
+

Add the keyfile to the initramfs image: +

+
/etc/mkinitcpio.conf
+
FILES=(/etc/cryptsetup-keys.d/cryptlvm.key)
+

Regenerate the initramfs. +

When using the default sd-encrypt hook, /etc/cryptsetup-keys.d/name.key will be used by default, so no additional kernel parameters need to be set. +

When using the encrypt hook, set the following kernel parameters to unlock the LUKS partition with the keyfile: +

+
GRUB_CMDLINE_LINUX="... cryptkey=rootfs:/etc/cryptsetup-keys.d/cryptlvm.key"
+
+

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. +

+

Tip If you want to encrypt the /boot partition to protect against offline tampering threats, the mkinitcpio-chkcryptoboot hook has been contributed to help.

+

Using a USB drive to unlock /boot

+

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. +

First, generate a keyfile in the same way as in #Avoiding having to enter the passphrase twice. 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. +

Copy this keyfile to your USB drive and create a new GRUB configuration file: +

+
/boot/grub/grub-pre.cfg
+
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
+

Create a GRUB image and install it (not all of these modules will be needed depending on your file system): +

+
# 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
+
+

Root on ZFS

+
+

This article or section is being considered for removal.

+

Reason: 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 Talk:Dm-crypt/Encrypting an entire system)

+
+

To use dm-crypt with ZFS, see ZFS#Encryption in ZFS using dm-crypt. +

Additionally, ZFS features native encryption, which may also be utilized to encrypt the system root, excluding the boot loader and file system metadata. See: +

+ +

After the installation, a boot loader can be verified with Secure Boot on UEFI-based systems. +

+ + + + +
\ No newline at end of file diff --git a/KaraKeep/attachments/9d0b360d-6dee-453e-994c-15c043e19760-[SOLVED]-Nvidia-dual-gpu.jpg b/KaraKeep/attachments/9d0b360d-6dee-453e-994c-15c043e19760-[SOLVED]-Nvidia-dual-gpu.jpg new file mode 100644 index 0000000..a32ce88 Binary files /dev/null and b/KaraKeep/attachments/9d0b360d-6dee-453e-994c-15c043e19760-[SOLVED]-Nvidia-dual-gpu.jpg differ diff --git a/KaraKeep/attachments/a660e0a8-6879-4709-9b88-c8db9140597a-dm-crypt-Encrypting-an-entire.jpg b/KaraKeep/attachments/a660e0a8-6879-4709-9b88-c8db9140597a-dm-crypt-Encrypting-an-entire.jpg new file mode 100644 index 0000000..13d257e Binary files /dev/null and b/KaraKeep/attachments/a660e0a8-6879-4709-9b88-c8db9140597a-dm-crypt-Encrypting-an-entire.jpg differ diff --git a/KaraKeep/attachments/bc1e8b42-d238-4476-867c-052d1446edde-systemd-cryptenroll-ArchWiki.jpg b/KaraKeep/attachments/bc1e8b42-d238-4476-867c-052d1446edde-systemd-cryptenroll-ArchWiki.jpg new file mode 100644 index 0000000..15f06c4 --- /dev/null +++ b/KaraKeep/attachments/bc1e8b42-d238-4476-867c-052d1446edde-systemd-cryptenroll-ArchWiki.jpg @@ -0,0 +1,136 @@ +
+ +

From systemd-cryptenroll(1): +

+
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.
+

systemd-cryptenroll allows enrolling smartcards, FIDO2 tokens and Trusted Platform Module security chips into LUKS devices, as well as regular passphrases. These devices are later unlocked by systemd-cryptsetup@.service(8), using the enrolled tokens. +

+ +

Installation

+

systemd-cryptenroll is part of and packaged with systemd. However, extra packages are required to use hardware devices as keys: +

+ +

List keyslots

+

systemd-cryptenroll can list the keyslots in a LUKS device, similar to cryptsetup luksDump, but in a more user-friendly format. +

+
# systemd-cryptenroll /dev/disk
+
SLOT TYPE    
+   0 password
+   1 recovery
+   2 tpm2
+
+

Erasing keyslots

+
# systemd-cryptenroll /dev/disk --wipe-slot=SLOT
+
+

Where SLOT can be: +

+
  • A single keyslot index, as represented in #List keyslots
    • +
  • A type of keyslot, which will erase all keyslots of that type. Valid types are empty, password, recovery, pkcs11, fido2, tpm2
    • +
  • A combination of all of the above, separated by commas
    • +
  • The string all, which erases all keyslots on the device. This option can only be used when enrolling another device or passphrase at the same time.
+

The --wipe-slot operation can be used in combination with all enrollment options, which is useful to update existing device enrollments: +

+
# systemd-cryptenroll /dev/disk --wipe-slot=fido2 --fido2-device=auto
+
+

Enrolling passphrases

+

Regular password

+

This is equivalent to cryptsetup luksAddKey. +

+
# systemd-cryptenroll /dev/disk --password
+
+

Recovery key

+

From systemd-cryptenroll(1): +

+
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.
+

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. +

+
# systemd-cryptenroll /dev/disk --recovery-key
+
+

Enrolling hardware devices

+

The --type-device options must point to a valid device path of their respective type. A list of available devices can be obtained by passing the list argument to this option. Alternatively, if you only have a single device of the desired type connected, the auto option can be used to automatically select it. +

+ +

PKCS#11 tokens or smartcards

+

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. +

+
# systemd-cryptenroll /dev/disk --pkcs11-token-uri=device
+
+

FIDO2 tokens

+

Any FIDO2 token that supports the "hmac-secret" extension can be used with systemd-cryptenroll. The following example would enroll a FIDO2 token to an encrypted LUKS2 block device, requiring only user presence as authentication. +

+
# systemd-cryptenroll /dev/disk --fido2-device=device --fido2-with-client-pin=no
+
+

In addition, systemd-cryptenroll supports using the token's built-in user verification methods: +

+
  • --fido2-with-user-presence defines whether to verify the user presence (i.e. by tapping the token) before unlocking, defaults to yes
    • +
  • --fido2-with-user-verification defines whether to require user verification before unlocking, defaults to no
+

Note

  • These options will have no effect if the token does not support these features.
    • +
  • See User Presence vs User Verification for more information on the difference between the two.
+
+

By default, the cryptographic algorithm used when generating a FIDO2 credential is es256 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. +

+

Note This may also be desirable for those concerned with ECDSA. See SSH keys#ECDSA for details.

+

Suppose that a previous FIDO2 token has already been enrolled and the user wishes to enroll another, the following generates an eddsa credential which denotes EdDSA over Curve25519 with SHA-512 and authenticates the device with a previous enrolled token instead of a password. +

+
# systemd-cryptenroll /dev/disk --fido2-device=device --fido2-credential-algorithm=eddsa --unlock-fido2-device=auto
+
+

Note Both tokens must be plugged in to the system for successful enrollment.

+

Trusted Platform Module

+
+

This article or section needs expansion.

+

Reason: Document --tpm2-seal-key-handle --tpm2-device-key --tpm2-pcrlock (Discuss in Talk:Systemd-cryptenroll)

+
+

systemd-cryptenroll has native support for enrolling LUKS keys in TPMs. It requires the following: +

+ +

To begin, run the following command to list your installed TPMs and the driver in use: +

+
$ systemd-cryptenroll --tpm2-device=list
+
+

Tip

  • If your computer has multiple TPMs installed, specify the one you wish to use with --tpm2-device=/path/to/tpm2_device in the following steps.
    • +
  • Consider using PCR policies instead of binding secrets to raw PCR values.
+

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 (Secure Boot state): +

+
# systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 /dev/sdX
+
+

where /dev/sdX is the full path to the encrypted LUKS volume. Use --unlock-key-file=/path/to/keyfile if the LUKS volume is unlocked by a keyfile instead of a passphrase. +

Refer to systemd-cryptenroll(1) and Trusted Platform Module#Accessing PCR registers for common PCR measurements in Linux. Adjust --tpm2-pcrs=7 as necessary (parameters are separated by the + symbol). +

+

Warning

  • Make sure Secure Boot is active and in user mode when binding to PCR 7, otherwise, unauthorized boot devices could unlock the encrypted volume.
    • +
  • The state of PCR 7 can change if firmware certificates change, which can risk locking the user out. This can be implicitly done by fwupd[1] or explicitly by rotating Secure Boot keys.
    • +
  • 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 Brave New Trusted Boot World and BitLocker documentation for additional information.
    • +
  • A solution for the root volume is to bind to an empty PCR 15 using --tpm2-pcrs=other_pcrs+15:sha256=0000000000000000000000000000000000000000000000000000000000000000. If you set any rd.luks kernel parameters or use /etc/crypttab.initramfs, additionally add the tpm2-measure-pcr=yes option to rd.luks.options= or the fourth field in /etc/crypttab.initramfs; this is not required when relying on GPT partition automounting. After the root volume is unlocked in early userspace, PCR 15 will change and the enrolled key will no longer be retrievable.
    • +
  • Another cleaner solution is described in the Pinning a LUKS volume section.
+
+

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 Secure Boot state, or different boot devices. As another example, Microsoft's Bitlocker prefers PCR 7+11, but may also use other PCR combinations. +

+

Note

  • It is possible to require a PIN to be entered in addition to the TPM state being correct. Simply add the option --tpm2-with-pin=yes to the command above and enter the PIN when prompted.
    • +
  • systemd-cryptenroll does not check the TPM measurement before asking for the PIN, therefore consider using a unique PIN since the environment may be untrustworthy.
+
+

To check that the new key was enrolled, dump the LUKS configuration and look for a systemd-tpm2 token entry, as well as an additional entry in the Keyslots section: +

+
# cryptsetup luksDump /dev/sdX
+
+

To test that the key works, run the following command while the LUKS volume is closed: +

+
# systemd-cryptsetup attach mapping_name /dev/sdX none tpm2-device=auto
+
+

where mapping_name is your chosen name for the volume once opened. +

See dm-crypt/System configuration#crypttab and dm-crypt/System configuration#Trusted Platform Module and FIDO2 keys in order to unlock the volume at boot time. +

+

Note While you may specify the UUID of your LUKS volume in place of the pathname in /etc/crypttab, the systemd-cryptenroll command itself currently only supports path names.

+

See systemd-cryptenroll(1) and crypttab(5) for more information and examples. +

+

See also

+ + + + + +
\ No newline at end of file diff --git a/KaraKeep/attachments/c2ac1a1d-adea-4825-81ad-8d35e8def5a9-Multi-seat-support-·-Wiki-·.jpg b/KaraKeep/attachments/c2ac1a1d-adea-4825-81ad-8d35e8def5a9-Multi-seat-support-·-Wiki-·.jpg new file mode 100644 index 0000000..6b998ab Binary files /dev/null and b/KaraKeep/attachments/c2ac1a1d-adea-4825-81ad-8d35e8def5a9-Multi-seat-support-·-Wiki-·.jpg differ diff --git a/KaraKeep/attachments/c448a225-1fb2-49a7-9668-9b25881996df-How-to-Configure-K3s-for-IPv6.jpg b/KaraKeep/attachments/c448a225-1fb2-49a7-9668-9b25881996df-How-to-Configure-K3s-for-IPv6.jpg new file mode 100644 index 0000000..857210f Binary files /dev/null and b/KaraKeep/attachments/c448a225-1fb2-49a7-9668-9b25881996df-How-to-Configure-K3s-for-IPv6.jpg differ diff --git a/KaraKeep/attachments/d7bed340-5cd5-4cbb-a9ce-9a10f07a0f6d-Pokemon-Champions-Speed-Tiers.jpg b/KaraKeep/attachments/d7bed340-5cd5-4cbb-a9ce-9a10f07a0f6d-Pokemon-Champions-Speed-Tiers.jpg new file mode 100644 index 0000000..b20d14a --- /dev/null +++ b/KaraKeep/attachments/d7bed340-5cd5-4cbb-a9ce-9a10f07a0f6d-Pokemon-Champions-Speed-Tiers.jpg @@ -0,0 +1,5076 @@ +
+
+

Pikalytics | Labs

+ +

+ Browse Pokemon Champions speed tiers for every Pokemon and + Mega in the VGC 2026 Reg. M-A format, with base Speed, max Speed, neutral natures, and + Choice Scarf calcs. +

+ + +
+ + + +
+

+ Scroll sideways to compare speed tiers. +

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + Pokemon + Pokemon + + + + + + Max Speed + Max + + + + Neutral +32 SP + +32 + + + + Neutral 0 SP + Ntrl 0 + + + + -Spe 0 SP + -Spe + + + + Max + Scarf + Scarf + + + + Neutral +32 + Scarf + +32 Sc + +
+
+

Aerodactyl-Mega

+

Aerodactyl-Mega

+

+ Base 150 +

+
+
+ 		150222202170153333303
+
+

Alakazam-Mega

+

Alakazam-Mega

+

+ Base 150 +

+
+
+ 		150222202170153333303
+
+

Beedrill-Mega

+

Beedrill-Mega

+

+ Base 145 +

+
+
+ 		145216197165148324295
+
+

Dragapult

+

Dragapult

+

+ Base 142 +

+
+
+ 		142213194162145319291
+
+

Greninja-Mega

+

Greninja-Mega

+

+ Base 142 +

+
+
+ 		142213194162145319291
+
+

Lopunny-Mega

+

Lopunny-Mega

+

+ Base 135 +

+
+
+ 		135205187155139307280
+
+

Manectric-Mega

+

Manectric-Mega

+

+ Base 135 +

+
+
+ 		135205187155139307280
+
+

Delphox-Mega

+

Delphox-Mega

+

+ Base 134 +

+
+
+ 		134204186154138306279
+
+

Aerodactyl

+

Aerodactyl

+

+ Base 130 +

+
+
+ 		130200182150135300273
+
+

Gengar-Mega

+

Gengar-Mega

+

+ Base 130 +

+
+
+ 		130200182150135300273
+
+

Jolteon

+

Jolteon

+

+ Base 130 +

+
+
+ 		130200182150135300273
+
+

Talonflame

+

Talonflame

+

+ Base 126 +

+
+
+ 		126195178146131292267
+
+

Weavile

+

Weavile

+

+ Base 125 +

+
+
+ 		125194177145130291265
+
+

Meowstic-Mega

+

Meowstic-Mega

+

+ Base 124 +

+
+
+ 		124193176144129289264
+
+

Meowscarada

+

Meowscarada

+

+ Base 123 +

+
+
+ 		123192175143128288262
+
+

Noivern

+

Noivern

+

+ Base 123 +

+
+
+ 		123192175143128288262
+
+

Greninja

+

Greninja

+

+ Base 122 +

+
+
+ 		122191174142127286261
+
+

Pidgeot-Mega

+

Pidgeot-Mega

+

+ Base 121 +

+
+
+ 		121190173141126285259
+
+

Alakazam

+

Alakazam

+

+ Base 120 +

+
+
+ 		120189172140126283258
+
+

Froslass-Mega

+

Froslass-Mega

+

+ Base 120 +

+
+
+ 		120189172140126283258
+
+

Sneasler

+

Sneasler

+

+ Base 120 +

+
+
+ 		120189172140126283258
+
+

Starmie-Mega

+

Starmie-Mega

+

+ Base 120 +

+
+
+ 		120189172140126283258
+
+

Hawlucha

+

Hawlucha

+

+ Base 118 +

+
+
+ 		118187170138124280255
+
+

Hawlucha-Mega

+

Hawlucha-Mega

+

+ Base 118 +

+
+
+ 		118187170138124280255
+
+

Salazzle

+

Salazzle

+

+ Base 117 +

+
+
+ 		117185169137123277253
+
+

Whimsicott

+

Whimsicott

+

+ Base 116 +

+
+
+ 		116184168136122276252
+
+

Absol-Mega

+

Absol-Mega

+

+ Base 115 +

+
+
+ 		115183167135121274250
+
+

Houndoom-Mega

+

Houndoom-Mega

+

+ Base 115 +

+
+
+ 		115183167135121274250
+
+

Starmie

+

Starmie

+

+ Base 115 +

+
+
+ 		115183167135121274250
+
+

Serperior

+

Serperior

+

+ Base 113 +

+
+
+ 		113181165133119271247
+
+

Lucario-Mega

+

Lucario-Mega

+

+ Base 112 +

+
+
+ 		112180164132118270246
+
+

Lycanroc (Midday)

+

Lycanroc (Midday)

+

+ Base 112 +

+
+
+ 		112180164132118270246
+
+

Maushold

+

Maushold

+

+ Base 111 +

+
+
+ 		111179163131117268244
+
+

Espeon

+

Espeon

+

+ Base 110 +

+
+
+ 		110178162130117267243
+
+

Froslass

+

Froslass

+

+ Base 110 +

+
+
+ 		110178162130117267243
+
+

Gallade-Mega

+

Gallade-Mega

+

+ Base 110 +

+
+
+ 		110178162130117267243
+
+

Gengar

+

Gengar

+

+ Base 110 +

+
+
+ 		110178162130117267243
+
+

Raichu

+

Raichu

+

+ Base 110 +

+
+
+ 		110178162130117267243
+
+

Raichu (Alolan)

+

Raichu (Alolan)

+

+ Base 110 +

+
+
+ 		110178162130117267243
+
+

Skarmory-Mega

+

Skarmory-Mega

+

+ Base 110 +

+
+
+ 		110178162130117267243
+
+

Tauros

+

Tauros

+

+ Base 110 +

+
+
+ 		110178162130117267243
+
+

Zoroark (Hisuian)

+

Zoroark (Hisuian)

+

+ Base 110 +

+
+
+ 		110178162130117267243
+
+

Heliolisk

+

Heliolisk

+

+ Base 109 +

+
+
+ 		109177161129116265241
+
+

Ninetales (Alolan)

+

Ninetales (Alolan)

+

+ Base 109 +

+
+
+ 		109177161129116265241
+
+

Infernape

+

Infernape

+

+ Base 108 +

+
+
+ 		108176160128115264240
+
+

Liepard

+

Liepard

+

+ Base 106 +

+
+
+ 		106173158126113259237
+
+

Espathra

+

Espathra

+

+ Base 105 +

+
+
+ 		105172157125112258235
+
+

Lopunny

+

Lopunny

+

+ Base 105 +

+
+
+ 		105172157125112258235
+
+

Manectric

+

Manectric

+

+ Base 105 +

+
+
+ 		105172157125112258235
+
+

Pinsir-Mega

+

Pinsir-Mega

+

+ Base 105 +

+
+
+ 		105172157125112258235
+
+

Sharpedo-Mega

+

Sharpedo-Mega

+

+ Base 105 +

+
+
+ 		105172157125112258235
+
+

Zoroark

+

Zoroark

+

+ Base 105 +

+
+
+ 		105172157125112258235
+
+

Delphox

+

Delphox

+

+ Base 104 +

+
+
+ 		104171156124111256234
+
+

Meowstic

+

Meowstic

+

+ Base 104 +

+
+
+ 		104171156124111256234
+
+

Emolga

+

Emolga

+

+ Base 103 +

+
+
+ 		103170155123110255232
+
+

Excadrill-Mega

+

Excadrill-Mega

+

+ Base 103 +

+
+
+ 		103170155123110255232
+
+

Floette-Eternal-Mega

+

Floette-Eternal-Mega

+

+ Base 102 +

+
+
+ 		102169154122109253231
+
+

Furfrou

+

Furfrou

+

+ Base 102 +

+
+
+ 		102169154122109253231
+
+

Garchomp

+

Garchomp

+

+ Base 102 +

+
+
+ 		102169154122109253231
+
+

Dedenne

+

Dedenne

+

+ Base 101 +

+
+
+ 		101168153121108252229
+
+

Glimmora-Mega

+

Glimmora-Mega

+

+ Base 101 +

+
+
+ 		101168153121108252229
+
+

Pidgeot

+

Pidgeot

+

+ Base 101 +

+
+
+ 		101168153121108252229
+
+

Simipour

+

Simipour

+

+ Base 101 +

+
+
+ 		101168153121108252229
+
+

Simisage

+

Simisage

+

+ Base 101 +

+
+
+ 		101168153121108252229
+
+

Simisear

+

Simisear

+

+ Base 101 +

+
+
+ 		101168153121108252229
+
+

Charizard

+

Charizard

+

+ Base 100 +

+
+
+ 		100167152120108250228
+
+

Charizard-Mega-X

+

Charizard-Mega-X

+

+ Base 100 +

+
+
+ 		100167152120108250228
+
+

Charizard-Mega-Y

+

Charizard-Mega-Y

+

+ Base 100 +

+
+
+ 		100167152120108250228
+
+

Dragonite-Mega

+

Dragonite-Mega

+

+ Base 100 +

+
+
+ 		100167152120108250228
+
+

Gardevoir-Mega

+

Gardevoir-Mega

+

+ Base 100 +

+
+
+ 		100167152120108250228
+
+

Glalie-Mega

+

Glalie-Mega

+

+ Base 100 +

+
+
+ 		100167152120108250228
+
+

Kangaskhan-Mega

+

Kangaskhan-Mega

+

+ Base 100 +

+
+
+ 		100167152120108250228
+
+

Medicham-Mega

+

Medicham-Mega

+

+ Base 100 +

+
+
+ 		100167152120108250228
+
+

Ninetales

+

Ninetales

+

+ Base 100 +

+
+
+ 		100167152120108250228
+
+

Palafin

+

Palafin

+

+ Base 100 +

+
+
+ 		100167152120108250228
+
+

Tauros (Paldean)

+

Tauros (Paldean)

+

+ Base 100 +

+
+
+ 		100167152120108250228
+
+

Typhlosion

+

Typhlosion

+

+ Base 100 +

+
+
+ 		100167152120108250228
+
+

Volcarona

+

Volcarona

+

+ Base 100 +

+
+
+ 		100167152120108250228
+
+

Hydreigon

+

Hydreigon

+

+ Base 98 +

+
+
+ 		98165150118106247225
+
+

Morpeko

+

Morpeko

+

+ Base 97 +

+
+
+ 		97163149117105244223
+
+

Mimikyu

+

Mimikyu

+

+ Base 96 +

+
+
+ 		96162148116104243222
+
+

Arcanine

+

Arcanine

+

+ Base 95 +

+
+
+ 		95161147115103241220
+
+

Gliscor

+

Gliscor

+

+ Base 95 +

+
+
+ 		95161147115103241220
+
+

Houndoom

+

Houndoom

+

+ Base 95 +

+
+
+ 		95161147115103241220
+
+

Leafeon

+

Leafeon

+

+ Base 95 +

+
+
+ 		95161147115103241220
+
+

Sharpedo

+

Sharpedo

+

+ Base 95 +

+
+
+ 		95161147115103241220
+
+

Typhlosion (Hisuian)

+

Typhlosion (Hisuian)

+

+ Base 95 +

+
+
+ 		95161147115103241220
+
+

Tinkaton

+

Tinkaton

+

+ Base 94 +

+
+
+ 		94160146114102240219
+
+

Floette (Eternal Flower)

+

Floette (Eternal Flower)

+

+ Base 92 +

+
+
+ 		92158144112100237216
+
+

Garchomp-Mega

+

Garchomp-Mega

+

+ Base 92 +

+
+
+ 		92158144112100237216
+
+

Krookodile

+

Krookodile

+

+ Base 92 +

+
+
+ 		92158144112100237216
+
+

Rotom

+

Rotom

+

+ Base 91 +

+
+
+ 		9115714311199235214
+
+

Arcanine (Hisuian)

+

Arcanine (Hisuian)

+

+ Base 90 +

+
+
+ 		9015614211099234213
+
+

Chandelure-Mega

+

Chandelure-Mega

+

+ Base 90 +

+
+
+ 		9015614211099234213
+
+

Kangaskhan

+

Kangaskhan

+

+ Base 90 +

+
+
+ 		9015614211099234213
+
+

Lucario

+

Lucario

+

+ Base 90 +

+
+
+ 		9015614211099234213
+
+

Pikachu

+

Pikachu

+

+ Base 90 +

+
+
+ 		9015614211099234213
+
+

Roserade

+

Roserade

+

+ Base 90 +

+
+
+ 		9015614211099234213
+
+

Vivillon

+

Vivillon

+

+ Base 89 +

+
+
+ 		8915514110998232211
+
+

Excadrill

+

Excadrill

+

+ Base 88 +

+
+
+ 		8815414010897231210
+
+

Glimmora

+

Glimmora

+

+ Base 86 +

+
+
+ 		8615113810695226207
+
+

Rotom-Fan

+

Rotom-Fan

+

+ Base 86 +

+
+
+ 		8615113810695226207
+
+

Rotom-Frost

+

Rotom-Frost

+

+ Base 86 +

+
+
+ 		8615113810695226207
+
+

Rotom-Heat

+

Rotom-Heat

+

+ Base 86 +

+
+
+ 		8615113810695226207
+
+

Rotom-Mow

+

Rotom-Mow

+

+ Base 86 +

+
+
+ 		8615113810695226207
+
+

Rotom-Wash

+

Rotom-Wash

+

+ Base 86 +

+
+
+ 		8615113810695226207
+
+

Archaludon

+

Archaludon

+

+ Base 85 +

+
+
+ 		8515013710594225205
+
+

Ceruledge

+

Ceruledge

+

+ Base 85 +

+
+
+ 		8515013710594225205
+
+

Heracross

+

Heracross

+

+ Base 85 +

+
+
+ 		8515013710594225205
+
+

Kleavor

+

Kleavor

+

+ Base 85 +

+
+
+ 		8515013710594225205
+
+

Kommo-o

+

Kommo-o

+

+ Base 85 +

+
+
+ 		8515013710594225205
+
+

Pinsir

+

Pinsir

+

+ Base 85 +

+
+
+ 		8515013710594225205
+
+

Quaquaval

+

Quaquaval

+

+ Base 85 +

+
+
+ 		8515013710594225205
+
+

Samurott (Hisuian)

+

Samurott (Hisuian)

+

+ Base 85 +

+
+
+ 		8515013710594225205
+
+

Toxicroak

+

Toxicroak

+

+ Base 85 +

+
+
+ 		8515013710594225205
+
+

Gourgeist

+

Gourgeist

+

+ Base 84 +

+
+
+ 		8414913610493223204
+
+

Gyarados

+

Gyarados

+

+ Base 81 +

+
+
+ 		8114613310190219199
+
+

Gyarados-Mega

+

Gyarados-Mega

+

+ Base 81 +

+
+
+ 		8114613310190219199
+
+

Milotic

+

Milotic

+

+ Base 81 +

+
+
+ 		8114613310190219199
+
+

Altaria

+

Altaria

+

+ Base 80 +

+
+
+ 		8014513210090217198
+
+

Altaria-Mega

+

Altaria-Mega

+

+ Base 80 +

+
+
+ 		8014513210090217198
+
+

Arbok

+

Arbok

+

+ Base 80 +

+
+
+ 		8014513210090217198
+
+

Chandelure

+

Chandelure

+

+ Base 80 +

+
+
+ 		8014513210090217198
+
+

Dragonite

+

Dragonite

+

+ Base 80 +

+
+
+ 		8014513210090217198
+
+

Gallade

+

Gallade

+

+ Base 80 +

+
+
+ 		8014513210090217198
+
+

Gardevoir

+

Gardevoir

+

+ Base 80 +

+
+
+ 		8014513210090217198
+
+

Glalie

+

Glalie

+

+ Base 80 +

+
+
+ 		8014513210090217198
+
+

Goodra

+

Goodra

+

+ Base 80 +

+
+
+ 		8014513210090217198
+
+

Mamoswine

+

Mamoswine

+

+ Base 80 +

+
+
+ 		8014513210090217198
+
+

Medicham

+

Medicham

+

+ Base 80 +

+
+
+ 		8014513210090217198
+
+

Meganium

+

Meganium

+

+ Base 80 +

+
+
+ 		8014513210090217198
+
+

Meganium-Mega

+

Meganium-Mega

+

+ Base 80 +

+
+
+ 		8014513210090217198
+
+

Passimian

+

Passimian

+

+ Base 80 +

+
+
+ 		8014513210090217198
+
+

Venusaur

+

Venusaur

+

+ Base 80 +

+
+
+ 		8014513210090217198
+
+

Venusaur-Mega

+

Venusaur-Mega

+

+ Base 80 +

+
+
+ 		8014513210090217198
+
+

Vanilluxe

+

Vanilluxe

+

+ Base 79 +

+
+
+ 		791441319989216196
+
+

Basculegion

+

Basculegion

+

+ Base 78 +

+
+
+ 		781431309888214195
+
+

Basculegion (Female)

+

Basculegion (Female)

+

+ Base 78 +

+
+
+ 		781431309888214195
+
+

Blastoise

+

Blastoise

+

+ Base 78 +

+
+
+ 		781431309888214195
+
+

Blastoise-Mega

+

Blastoise-Mega

+

+ Base 78 +

+
+
+ 		781431309888214195
+
+

Diggersby

+

Diggersby

+

+ Base 78 +

+
+
+ 		781431309888214195
+
+

Feraligatr

+

Feraligatr

+

+ Base 78 +

+
+
+ 		781431309888214195
+
+

Feraligatr-Mega

+

Feraligatr-Mega

+

+ Base 78 +

+
+
+ 		781431309888214195
+
+

Watchog

+

Watchog

+

+ Base 77 +

+
+
+ 		771411299787211193
+
+

Absol

+

Absol

+

+ Base 75 +

+
+
+ 		751391279585208190
+
+

Armarouge

+

Armarouge

+

+ Base 75 +

+
+
+ 		751391279585208190
+
+

Banette-Mega

+

Banette-Mega

+

+ Base 75 +

+
+
+ 		751391279585208190
+
+

Beedrill

+

Beedrill

+

+ Base 75 +

+
+
+ 		751391279585208190
+
+

Emboar-Mega

+

Emboar-Mega

+

+ Base 75 +

+
+
+ 		751391279585208190
+
+

Florges

+

Florges

+

+ Base 75 +

+
+
+ 		751391279585208190
+
+

Garbodor

+

Garbodor

+

+ Base 75 +

+
+
+ 		751391279585208190
+
+

Heracross-Mega

+

Heracross-Mega

+

+ Base 75 +

+
+
+ 		751391279585208190
+
+

Klefki

+

Klefki

+

+ Base 75 +

+
+
+ 		751391279585208190
+
+

Scizor-Mega

+

Scizor-Mega

+

+ Base 75 +

+
+
+ 		751391279585208190
+
+

Scovillain

+

Scovillain

+

+ Base 75 +

+
+
+ 		751391279585208190
+
+

Scovillain-Mega

+

Scovillain-Mega

+

+ Base 75 +

+
+
+ 		751391279585208190
+
+

Slurpuff

+

Slurpuff

+

+ Base 72 +

+
+
+ 		721361249282204186
+
+

Tsareena

+

Tsareena

+

+ Base 72 +

+
+
+ 		721361249282204186
+
+

Sandaconda

+

Sandaconda

+

+ Base 71 +

+
+
+ 		711351239181202184
+
+

Tyranitar-Mega

+

Tyranitar-Mega

+

+ Base 71 +

+
+
+ 		711351239181202184
+
+

Tyrantrum

+

Tyrantrum

+

+ Base 71 +

+
+
+ 		711351239181202184
+
+

Castform

+

Castform

+

+ Base 70 +

+
+
+ 		701341229081201183
+
+

Clefable-Mega

+

Clefable-Mega

+

+ Base 70 +

+
+
+ 		701341229081201183
+
+

Decidueye

+

Decidueye

+

+ Base 70 +

+
+
+ 		701341229081201183
+
+

Flapple

+

Flapple

+

+ Base 70 +

+
+
+ 		701341229081201183
+
+

Luxray

+

Luxray

+

+ Base 70 +

+
+
+ 		701341229081201183
+
+

Mr. Rime

+

Mr. Rime

+

+ Base 70 +

+
+
+ 		701341229081201183
+
+

Politoed

+

Politoed

+

+ Base 70 +

+
+
+ 		701341229081201183
+
+

Polteageist

+

Polteageist

+

+ Base 70 +

+
+
+ 		701341229081201183
+
+

Samurott

+

Samurott

+

+ Base 70 +

+
+
+ 		701341229081201183
+
+

Sinistcha

+

Sinistcha

+

+ Base 70 +

+
+
+ 		701341229081201183
+
+

Skarmory

+

Skarmory

+

+ Base 70 +

+
+
+ 		701341229081201183
+
+

Victreebel

+

Victreebel

+

+ Base 70 +

+
+
+ 		701341229081201183
+
+

Victreebel-Mega

+

Victreebel-Mega

+

+ Base 70 +

+
+
+ 		701341229081201183
+
+

Corviknight

+

Corviknight

+

+ Base 67 +

+
+
+ 		671301198778195178
+
+

Skeledirge

+

Skeledirge

+

+ Base 66 +

+
+
+ 		661291188677193177
+
+

Banette

+

Banette

+

+ Base 65 +

+
+
+ 		651281178576192175
+
+

Chimecho

+

Chimecho

+

+ Base 65 +

+
+
+ 		651281178576192175
+
+

Chimecho-Mega

+

Chimecho-Mega

+

+ Base 65 +

+
+
+ 		651281178576192175
+
+

Emboar

+

Emboar

+

+ Base 65 +

+
+
+ 		651281178576192175
+
+

Flareon

+

Flareon

+

+ Base 65 +

+
+
+ 		651281178576192175
+
+

Glaceon

+

Glaceon

+

+ Base 65 +

+
+
+ 		651281178576192175
+
+

Orthworm

+

Orthworm

+

+ Base 65 +

+
+
+ 		651281178576192175
+
+

Pelipper

+

Pelipper

+

+ Base 65 +

+
+
+ 		651281178576192175
+
+

Scizor

+

Scizor

+

+ Base 65 +

+
+
+ 		651281178576192175
+
+

Umbreon

+

Umbreon

+

+ Base 65 +

+
+
+ 		651281178576192175
+
+

Vaporeon

+

Vaporeon

+

+ Base 65 +

+
+
+ 		651281178576192175
+
+

Wyrdeer

+

Wyrdeer

+

+ Base 65 +

+
+
+ 		651281178576192175
+
+

Alcremie

+

Alcremie

+

+ Base 64 +

+
+
+ 		641271168475190174
+
+

Chesnaught

+

Chesnaught

+

+ Base 64 +

+
+
+ 		641271168475190174
+
+

Tyranitar

+

Tyranitar

+

+ Base 61 +

+
+
+ 		611241138172186169
+
+

Abomasnow

+

Abomasnow

+

+ Base 60 +

+
+
+ 		601231128072184168
+
+

Aegislash

+

Aegislash

+

+ Base 60 +

+
+
+ 		601231128072184168
+
+

Clefable

+

Clefable

+

+ Base 60 +

+
+
+ 		601231128072184168
+
+

Decidueye (Hisuian)

+

Decidueye (Hisuian)

+

+ Base 60 +

+
+
+ 		601231128072184168
+
+

Empoleon

+

Empoleon

+

+ Base 60 +

+
+
+ 		601231128072184168
+
+

Farigiraf

+

Farigiraf

+

+ Base 60 +

+
+
+ 		601231128072184168
+
+

Goodra (Hisuian)

+

Goodra (Hisuian)

+

+ Base 60 +

+
+
+ 		601231128072184168
+
+

Incineroar

+

Incineroar

+

+ Base 60 +

+
+
+ 		601231128072184168
+
+

Oranguru

+

Oranguru

+

+ Base 60 +

+
+
+ 		601231128072184168
+
+

Primarina

+

Primarina

+

+ Base 60 +

+
+
+ 		601231128072184168
+
+

Sylveon

+

Sylveon

+

+ Base 60 +

+
+
+ 		601231128072184168
+
+

Toucannon

+

Toucannon

+

+ Base 60 +

+
+
+ 		601231128072184168
+
+

Clawitzer

+

Clawitzer

+

+ Base 59 +

+
+
+ 		591221117971183166
+
+

Aurorus

+

Aurorus

+

+ Base 58 +

+
+
+ 		581211107870181165
+
+

Pangoro

+

Pangoro

+

+ Base 58 +

+
+
+ 		581211107870181165
+
+

Rampardos

+

Rampardos

+

+ Base 58 +

+
+
+ 		581211107870181165
+
+

Torterra

+

Torterra

+

+ Base 56 +

+
+
+ 		561181087668177162
+
+

Trevenant

+

Trevenant

+

+ Base 56 +

+
+
+ 		561181087668177162
+
+

Ampharos

+

Ampharos

+

+ Base 55 +

+
+
+ 		551171077567175160
+
+

Golurk

+

Golurk

+

+ Base 55 +

+
+
+ 		551171077567175160
+
+

Golurk-Mega

+

Golurk-Mega

+

+ Base 55 +

+
+
+ 		551171077567175160
+
+

Machamp

+

Machamp

+

+ Base 55 +

+
+
+ 		551171077567175160
+
+

Aggron

+

Aggron

+

+ Base 50 +

+
+
+ 		501121027063168153
+
+

Aggron-Mega

+

Aggron-Mega

+

+ Base 50 +

+
+
+ 		501121027063168153
+
+

Audino

+

Audino

+

+ Base 50 +

+
+
+ 		501121027063168153
+
+

Azumarill

+

Azumarill

+

+ Base 50 +

+
+
+ 		501121027063168153
+
+

Beartic

+

Beartic

+

+ Base 50 +

+
+
+ 		501121027063168153
+
+

Kingambit

+

Kingambit

+

+ Base 50 +

+
+
+ 		501121027063168153
+
+

Sableye

+

Sableye

+

+ Base 50 +

+
+
+ 		501121027063168153
+
+

Ditto

+

Ditto

+

+ Base 48 +

+
+
+ 		481101006861165150
+
+

Hippowdon

+

Hippowdon

+

+ Base 47 +

+
+
+ 		47108996760162148
+
+

Ampharos-Mega

+

Ampharos-Mega

+

+ Base 45 +

+
+
+ 		45106976558159145
+
+

Bellibolt

+

Bellibolt

+

+ Base 45 +

+
+
+ 		45106976558159145
+
+

Conkeldurr

+

Conkeldurr

+

+ Base 45 +

+
+
+ 		45106976558159145
+
+

Chesnaught-Mega

+

Chesnaught-Mega

+

+ Base 44 +

+
+
+ 		44105966457157144
+
+

Hydrapple

+

Hydrapple

+

+ Base 44 +

+
+
+ 		44105966457157144
+
+

Crabominable

+

Crabominable

+

+ Base 43 +

+
+
+ 		43104956356156142
+
+

Araquanid

+

Araquanid

+

+ Base 42 +

+
+
+ 		42103946255154141
+
+

Ariados

+

Ariados

+

+ Base 40 +

+
+
+ 		40101926054151138
+
+

Camerupt

+

Camerupt

+

+ Base 40 +

+
+
+ 		40101926054151138
+
+

Forretress

+

Forretress

+

+ Base 40 +

+
+
+ 		40101926054151138
+
+

Rhyperior

+

Rhyperior

+

+ Base 40 +

+
+
+ 		40101926054151138
+
+

Avalugg (Hisuian)

+

Avalugg (Hisuian)

+

+ Base 38 +

+
+
+ 		3899905852148135
+
+

Drampa

+

Drampa

+

+ Base 36 +

+
+
+ 		3696885650144132
+
+

Drampa-Mega

+

Drampa-Mega

+

+ Base 36 +

+
+
+ 		3696885650144132
+
+

Garganacl

+

Garganacl

+

+ Base 35 +

+
+
+ 		3595875549142130
+
+

Mudsdale

+

Mudsdale

+

+ Base 35 +

+
+
+ 		3595875549142130
+
+

Spiritomb

+

Spiritomb

+

+ Base 35 +

+
+
+ 		3595875549142130
+
+

Toxapex

+

Toxapex

+

+ Base 35 +

+
+
+ 		3595875549142130
+
+

Crabominable-Mega

+

Crabominable-Mega

+

+ Base 33 +

+
+
+ 		3393855347139127
+
+

Stunfisk

+

Stunfisk

+

+ Base 32 +

+
+
+ 		3292845246138126
+
+

Stunfisk (Galarian)

+

Stunfisk (Galarian)

+

+ Base 32 +

+
+
+ 		3292845246138126
+
+

Abomasnow-Mega

+

Abomasnow-Mega

+

+ Base 30 +

+
+
+ 		3090825045135123
+
+

Appletun

+

Appletun

+

+ Base 30 +

+
+
+ 		3090825045135123
+
+

Bastiodon

+

Bastiodon

+

+ Base 30 +

+
+
+ 		3090825045135123
+
+

Cofagrigus

+

Cofagrigus

+

+ Base 30 +

+
+
+ 		3090825045135123
+
+

Reuniclus

+

Reuniclus

+

+ Base 30 +

+
+
+ 		3090825045135123
+
+

Runerigus

+

Runerigus

+

+ Base 30 +

+
+
+ 		3090825045135123
+
+

Slowbro

+

Slowbro

+

+ Base 30 +

+
+
+ 		3090825045135123
+
+

Slowbro (Galarian)

+

Slowbro (Galarian)

+

+ Base 30 +

+
+
+ 		3090825045135123
+
+

Slowbro-Mega

+

Slowbro-Mega

+

+ Base 30 +

+
+
+ 		3090825045135123
+
+

Slowking

+

Slowking

+

+ Base 30 +

+
+
+ 		3090825045135123
+
+

Slowking (Galarian)

+

Slowking (Galarian)

+

+ Base 30 +

+
+
+ 		3090825045135123
+
+

Snorlax

+

Snorlax

+

+ Base 30 +

+
+
+ 		3090825045135123
+
+

Steelix

+

Steelix

+

+ Base 30 +

+
+
+ 		3090825045135123
+
+

Steelix-Mega

+

Steelix-Mega

+

+ Base 30 +

+
+
+ 		3090825045135123
+
+

Aromatisse

+

Aromatisse

+

+ Base 29 +

+
+
+ 		2989814944133121
+
+

Hatterene

+

Hatterene

+

+ Base 29 +

+
+
+ 		2989814944133121
+
+

Avalugg

+

Avalugg

+

+ Base 28 +

+
+
+ 		2888804843132120
+
+

Camerupt-Mega

+

Camerupt-Mega

+

+ Base 20 +

+
+
+ 		2079724036118108
+
+

Sableye-Mega

+

Sableye-Mega

+

+ Base 20 +

+
+
+ 		2079724036118108
+
+

Torkoal

+

Torkoal

+

+ Base 20 +

+
+
+ 		2079724036118108
+
+

+ Showing 263 of 263 Pokemon. +

+
+
\ No newline at end of file diff --git a/KaraKeep/attachments/eafd3009-cb22-4061-bad4-c21b399cbc46-[OC]-A-cozy-pixelaeted.jpg b/KaraKeep/attachments/eafd3009-cb22-4061-bad4-c21b399cbc46-[OC]-A-cozy-pixelaeted.jpg new file mode 100644 index 0000000..17275e5 Binary files /dev/null and b/KaraKeep/attachments/eafd3009-cb22-4061-bad4-c21b399cbc46-[OC]-A-cozy-pixelaeted.jpg differ diff --git a/KaraKeep/attachments/f2126c6f-6dbe-4be2-8723-eaaff7e1cdb9-login(3)-Linux-manual-page.jpg b/KaraKeep/attachments/f2126c6f-6dbe-4be2-8723-eaaff7e1cdb9-login(3)-Linux-manual-page.jpg new file mode 100644 index 0000000..da3aa3f Binary files /dev/null and b/KaraKeep/attachments/f2126c6f-6dbe-4be2-8723-eaaff7e1cdb9-login(3)-Linux-manual-page.jpg differ diff --git a/KaraKeep/attachments/f54c40c9-3212-4fa9-9990-a65f87336039-Pokemon-Champions-Speed-Tiers.jpg b/KaraKeep/attachments/f54c40c9-3212-4fa9-9990-a65f87336039-Pokemon-Champions-Speed-Tiers.jpg new file mode 100644 index 0000000..b1b0429 Binary files /dev/null and b/KaraKeep/attachments/f54c40c9-3212-4fa9-9990-a65f87336039-Pokemon-Champions-Speed-Tiers.jpg differ diff --git a/KaraKeep/attachments/f89d001c-5b1f-408f-9ac6-8dd279f25bd0-login(3)-Linux-manual-page.jpg b/KaraKeep/attachments/f89d001c-5b1f-408f-9ac6-8dd279f25bd0-login(3)-Linux-manual-page.jpg new file mode 100644 index 0000000..1dc9364 Binary files /dev/null and b/KaraKeep/attachments/f89d001c-5b1f-408f-9ac6-8dd279f25bd0-login(3)-Linux-manual-page.jpg differ diff --git a/KaraKeep/attachments/f93a1a22-509f-403f-9a1d-6c11393b02b9-login(3)-Linux-manual-page.jpg b/KaraKeep/attachments/f93a1a22-509f-403f-9a1d-6c11393b02b9-login(3)-Linux-manual-page.jpg new file mode 100644 index 0000000..e61103c --- /dev/null +++ b/KaraKeep/attachments/f93a1a22-509f-403f-9a1d-6c11393b02b9-login(3)-Linux-manual-page.jpg @@ -0,0 +1,270 @@ +
+ + + + + +
+ + + + + + + + +
SD-LOGIN(3)                      sd-login                     SD-LOGIN(3)
+
+

NAME         top

       sd-login - APIs for tracking logins
+
+

SYNOPSIS         top

       #include <systemd/sd-login.h>
+
+       pkg-config --cflags --libs libsystemd
+
+

DESCRIPTION         top

       sd-login.h is part of libsystemd(3) 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
+       NULL-terminated and need to be freed by the caller with the libc
+       free(3) 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 NULL may
+       be returned, which should be treated equivalent to an empty string
+       array.
+
+       See sd_pid_get_session(3), sd_uid_get_state(3),
+       sd_session_is_active(3), sd_seat_get_active(3), sd_get_seats(3),
+       sd_login_monitor_new(3) for more information about the functions
+       implemented.
+
+

DEFINITION OF TERMS         top

       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 (<= 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.
+
+           systemd(1) 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.
+
+

UDEV RULES         top

       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 ID_SEAT
+           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 ID_SEAT=seat-waldo 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 ID_SEAT
+           property manually. Again, if a device is assigned to seat0
+           this is visible on the device in two ways: with a property
+           ID_SEAT=seat0 and with no property ID_SEAT set for it at all.
+
+           Added in version 235.
+
+       Property ID_AUTOSEAT
+           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 ID_FOR_SEAT
+           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 ID_SEAT property exists. Besides udev rules
+       there is no persistent data about seats stored on disk.
+
+       Note that systemd-logind(8) 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.
+
+

NOTES         top

       Functions described here are available as a shared library, which
+       can be compiled against and linked to with the
+       libsystemd pkg-config(1) file.
+
+       The code described here uses getenv(3), which is declared to be
+       not multi-thread-safe. This means that the code calling the
+       functions described here must not call setenv(3) from a parallel
+       thread. It is recommended to only do calls to setenv() from an
+       early phase of the program when no other threads have been
+       started.
+
+

SEE ALSO         top

       systemd(1), sd_pid_get_session(3), sd_uid_get_state(3),
+       sd_session_is_active(3), sd_seat_get_active(3), sd_get_seats(3),
+       sd_login_monitor_new(3), sd-daemon(3), pkg-config(1)
+
+       Multi-Seat on Linux[1] may also be of historical interest.
+
+

NOTES         top

        1. Multi-Seat on Linux
+           https://www.freedesktop.org/wiki/Software/systemd/multiseat
+
+

COLOPHON         top

       This page is part of the systemd (systemd system and service
+       manager) project.  Information about the project can be found at
+       ⟨http://www.freedesktop.org/wiki/Software/systemd⟩.  If you have a
+       bug report for this manual page, see
+       ⟨http://www.freedesktop.org/wiki/Software/systemd/#bugreports⟩.
+       This page was obtained from the project's upstream Git repository
+       ⟨https://github.com/systemd/systemd.git⟩ 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 not part of the original manual page), send a mail to
+       man-pages@man7.org
+
+systemd 260~devel                                             SD-LOGIN(3)
+
+ +
+

Pages that refer to this page: + libsystemd(3),  + sd_get_seats(3),  + sd_login_monitor_new(3),  + sd_machine_get_class(3),  + sd_pid_get_owner_uid(3),  + sd_seat_get_active(3),  + sd_session_is_active(3),  + sd_uid_get_state(3),  + org.freedesktop.login1(5),  + systemd.directives(7),  + systemd.index(7),  + systemd-logind.service(8),  + systemd-machined.service(8) +

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
\ No newline at end of file