一句话总结🤓
纯纯的通马桶剧情，千万不要玩，千万不要为了工厂玩法入坑，但如果你和我一样是个只要游戏画面好看有心意就愿意花时间的话… 那还不错（？
场景和角色的美术超级好看，也怪不得鹰角自己宣传的时候也在说这些。
武陵好好看呃啊wwww 能不能把四号谷地删掉，求求了。最好再把所有通马桶一样的主线剧情删掉
其实我个人觉得终末地的每个玩法本身还是不错的，但是串联它们的剧情实在是惨不忍睹。唉，可惜咯（怎么说得好像只要鹰角做得好我就会长期玩一样，玩抽卡二游没有好下场）
一上手 Mac 给人最大的不同就是就连复制粘贴这类耳熟能详的 Control C/V 都变成了 Command C/V，小拇指的肌肉记忆也在反反复复的按地球仪键并打开 emoji 选择器（什）。
不仅如此包括全选（Ctrl+A）、前后跳转一个单词（Ctrl+Left/Right）、跳到行首行尾（Home/End，它们在笔记本上位置一般很奇怪或者没有所以超级影响打字体验）全都变成了另一种以 Command 为中心的快捷键。
在几乎一天的不习惯但好奇的尝试之后这套方案逐渐让我感受到了它和 IBM 和微软最初的设计师在理念上最大的差异：到底是小拇指还是大拇指灵活。
如果作为读者的你正在用着常见布局的键盘，不妨重新尝试一下让左手从手指平摊在 asdf 到小拇指放在 ctrl 上的过程，即使食指保留了键盘突起所在的位置其它两根本不该移动的手指依然改变了位置，这就造成了输入完快捷键后重新定位时的轻微不自信和延迟，并且在按下 ctrl 后输入字母键时由于每根手指活动的中点从 asdf 变成了小拇指所在的键盘左下角，导致用哪根手指按下按键也和平坦状态不一样，比如 C 在平摊时属于中指而 Ctrl+C 属于食指。
而 Command 键处于常见布局中 alt 键所在的位置属于大拇指的管理范围。大拇指不参与字母键的敲击，移动起来也不受小拇指上韧带的生理所限可以在不改变手掌的情况下随意移动（只要够长x）。
明白了底层设计后我的大脑就开始用上字母键打字的肌肉记忆来完成快捷键了，相对于小拇指的设计这无疑无形中减小了很多初期的学习成本。
Tips: Command+Left/Right 是跳到行首行尾，Command+Up/Down 是跳转文件头尾（等于 Shift+Home/End）
如果说 Command 可以概括为 ctrl 的超集，那其它两个快捷键可以对应么？
虽然 Option 所在的地方看上去应该是 win 键的位置，但更像是个 alt 键。它干的所有活都很杂，属于是用 Command 屈才（idk）或者对应快捷键字母部分和 Command 一致但实现的是同一功能的变体（Option+Left/Right 前后跳转一个单词，终于找到家的感觉了）。
虽然它的位置也能用大拇指够到，但确实处于边缘位置，不过作为一个没什么字母键需要配合的家伙它的体验已经相当优秀了。
一整个 win/meta 键，和方向键一起都能控制虚拟桌面和窗口的 overview 了。
从这里开始就和左边的 fn 一起重新沦为小拇指的管理了。
不过我完全不清楚 Control 在现代快捷键方面除了多一重修饰以外还有什么用。有一种说法是作为标准 Unix 修饰符终端里处处都需要它（这是真的，比如 Ctrl+C 强行停止或者 Ctrl+D 发送 EOF），也可能是 macOS 最初采用了一堆 Emacs 快捷键所以 Control 在文本输入的时候还是有用的。
无论如何嘛…… 有点无聊。
是什么原因会让一个人在凌晨不睡觉写这些没什么用的东西呢？
可能是不记下来就会彻底忘记吧。该睡觉咯~
]]>纯纯的通马桶剧情，千万不要玩，千万不要为了工厂玩法入坑，但如果你和我一样是个只要游戏画面好看有心意就愿意花时间的话… 那还不错（？
场景和角色的美术超级好看，也怪不得鹰角自己宣传的时候也在说这些。
武陵好好看呃啊wwww 能不能把四号谷地删掉，求求了。最好再把所有通马桶一样的主线剧情删掉
其实我个人觉得终末地的每个玩法本身还是不错的，但是串联它们的剧情实在是惨不忍睹。唉，可惜咯（怎么说得好像只要鹰角做得好我就会长期玩一样，玩抽卡二游没有好下场）
My first teacher would be Minecraft, I think. Configure the java dev kit, and figure out how to use Windows 10 is a pretty challenging task for me. My friends and I want to play together, so I’m also studying how to use NAT traveling out of school.
I was born in 2009, the last gen z. Everyone was talking more about phones in my childhood. People talking, using, playing, and controlling the dumb or smart phones. Even though I still have some memories about optical disks and other things before the internet grew up.
Back then, we even tried variants of apps to run the Minecraft java version on Android for some reason(we didn’t have a PC). Tech barrier could never block tech studying.
Some others will say I have a little old-school, but that might be my practices: walk through the history once and understand where we are today. For example, I have used Nginx as reverse proxy for a long time before replacing it with Caddy.
Funny retro but not old atmosphere.
The afterword of the story was: Playing some video game and being blamed; Have been asked why I need VSCode on that computer; Following a series of stupid java tutorial videos, but have done nothing. So I never watch any long video tutorials after that.
I also had to build some physical electronic “stuff”, but that part was boring.
Why not to learn about other OS, or some other more serious programming languages? I don’t want to stop at being a tech lover. That’s why I decided to learn about Linux and C between 2022 and 2024.
My first Linux distro is Ubuntu, which is the end of 2022(probably?). Like every regular person, it’s hard. There was a desktop edition, but I use it as a server on a pretty useless PC. This is fun, but did nothing related to “server”. And I started using Debian as my day-to-day system more than six months ago.
After another six months, I had learned a lot about how to do daily tasks with Debian. Really stable distro, until you accidentally uninstall VirtualBox the wrong way. After that, I wanted to challenge myself a little and also for learning more fundamental things. In August 2023, I spent a whole night migrating my PC to Arch Linux.
In that year, I tried to jailbreak a stock Nintendo Switch. Soldered an existing hacking board and cooking some software from the community. But be honest, pricey games are not enjoyable. I’m not a genius, so I didn’t code something for that.
There is an article for that: 从头破解 Nintendo Switch 的总结与心得
At that time, I was very familiar with shell, but still knew nothing about real programming, even Python. So in 2024, I bought a book called C Primer Plus, and started learning and practicing C.
I would say attempting to do some jailbreaks every year is great. Even if they look small.
Article: 在 Chromebook 上安装完整 Linux 发行版的方法总结
In 2025, I’m focused on networking and cloud. I’m more and more seriously managing my website and domain on Cloudflare. Trying to use AWS at surface(who can master that mess :|). And… I also learned the Go language as my primary choice to build something.
In this context, I swapped my PC and server OS with Red Hat Linux family in October 2025 :>
There is a previous page of this blog, called “The Computer Science” under the “about” page. I hid it so deep and have a lot of useless stuff randomly. So I decided to organize them and add some more content to fill this empty December for me…
Networking, javascript, and the frontend are boring this year…
]]>charchar.dev 并把 blog 迁移到那里。这绝不正常，也绝不会是一个正确的决定
其实域名是我从小以来第一个觉得最酷而自己又却最触碰不到的概念。但截至 2025 年，sourlemonjuice.net 已经持续存在了一年多了，这一切都变得如此熟悉但我也一直保持着警惕。
为什么？
因为相比 github pages 这种 Platform as a Service，自己的域名和服务器基础设施需要一个维护者和金钱。这引入了一系列的不确定性，虽然对于功能网站来说这再合适不过了，但对于内容网站一旦发生变化造成的后果也是灾难性的。在过去所建立的所有链接都将无法使用，所写过的内容除了 web archive 也将无人得知。
即使我是个会把源代码公开到 github 上的人（有些人会在本地构建完后推到一个单独的公开分支上），但我相信没有多少人会真的去看的。除了自己以外再也用没人在乎的东西，可以被叫做遗物吧
对于我的时间线而言，sourlemonjuice.net 是我用来公开所有我自己需要的公开服务的地方。不考虑 URL 长度，和优雅，只有单纯的功能性和来自网络的粗旷。
至少我是这么想的，比如 connectivity.sourlemonjuice.net/generate_204 这种东西的存在都是经过考量的
而另一个新域名的背景则更为复杂：charchar.dev
我不知道如果作为读者的你看到会怎么想，但 char 是我用在拉丁字母的 nickname。我总是说着不想，但 SourLemonJuice 实在是太长太长，而且即使作为一个命名空间也不完全独特。但总的来说够用，名字嘛向来如此
但由此引发的问题是作为访问者的割裂，和维护上的多余复杂度。我想在不同的地方上写清我的名字也可以是 char，但这并不够，非最主要用途的名字注定只会被自己亲近的人知道，这对我的 blog 有什么意义呢。
我又有什么把以 SourLemonJuice 为名义认识我的人放到 charchar.dev 上呢?
但它又足够的短，足以支撑起类似 ip.charchar.dev 这样的需要经常手动输入的 URL。仔细来看我简直是在逐渐把自己绑死在这两个域名上，互相牵制，互相依赖
这永远都不应该发生
但有哪些地方做错了，又有哪些是值得保留的呢？
就保留 ip.charchar.dev 的角度来看 charchar.dev 其实是一个有用的域名，但唯独不适合长时间保存内容和当作 API 接口。
所以我也想借着这篇帖子重新捋清自己的想法：
blog.charchar.dev 就是例子或许很快就会把 blog 从 blog.charchar.dev 改到 blog.sourlemonjuice.net 吧…
The AV1 video coding format was released in 2019 and is becoming more and more common on internet video streaming platforms. Small size and high quality are best for the internet.
That’s how my hardware video accelerator zero load when watching youtube, AMD RX 5700 is strong enough, but kind of old :)
Like OpenH264 and x264, AV1 now have two major software codec: AOM-AV1 and SVT-AV1.
AOM-AV1 is developed by AOMedia(‘A’ in AV1) themselves, but… a little slow. Not the best first impression.
SVT-AV1 is second, developed by Intel and Netflix in 2020. It faster and design for serious applications.
In the past, I only know the CBR(constant) and VBR(variable) methods to adjust output size.
But instead, you can use CRF(Constant Rate Factor) to keep image quality across the video, and reduce/increase bitrate on the fly.
Unlike bitrate, CRF is completely defined by codec. If codec say it can be INT_MAX that still correct.
In SVT-AV1, 35 is the default on ffmpeg. The number is more smaller, quality and size are larger.
You may want to try it at around 30 to start. There is a incredible article of this topic:
Comparing SVT-AV1 Presets: Size, Quality, and Speed with CRF Variations
The second thing after bitrate is preset, which controls how hard to encode/decode the video could be.
You can also see the graphic table about performance in the previous link.
To evaluate how good a transcoded video and original video are, a method is calculate signal to noise ratio: PSNR. But it can’t perfectly reflect human feel.
Another option is VMAF, developed by Netflix. I would say it more considers how humans perceive video and uses machine-learning for some parts of the algorithm. It’s cool, and accurate.
You can find them implementation at GitHub: Netflix/vmaf
Or download it from your distro repo.
This article knows more and more than me: Making Sense of PSNR, SSIM, VMAF
Can not.
But set the output resolution as same as my screen resolution can prevent scaling. I think which is the most useful part of these days, haha.
PS: 丢掉的数据里好像有两篇帖子的草稿（划掉划掉
这台系统是我的主力机，Arch Linux 加上稍微调整过超频的 AMD CPU 和 GPU。在一块 NVMe 固态上用着 LUKS2 模式的 dm-crypt 加密的根文件系统，绑定了我之前写过的 systemd TPM2 Policy 解密方式。里面的文件系统是 zstd:3 压缩模式的 btrfs
或许你已经在想很多种出问题的方式了，但实际情况其实还是复杂了不少的
嘛，要从哪里开始说起呢
事情的起源并不来自于 dm-crypt 而是上层的文件系统。
虽然很匪夷所思，但这一两个月以来这台电脑在大范围更新系统的时候经常抛出错误（”Truncated tar archive”），由于出现后 pacman 并不会认为这个包安装失败了，所以在这段时间里它已经损坏了几个软件包，导致后来我见到这个报错都是直接打开新的终端单独重新安装一下出错的包
同样还出现过一次的是 kernel panic… 报错说 btrfs 的 b-tree 爆炸了，但重启后什么问题都没有，btrfs check 之类的都能通过。虽然疑点重重但后来也没有重建文件系统，毕竟太麻烦了。
但这样的问题似乎就一直存在着存在着，没有任何重要文件被损坏了，除了 pacman 外也没有其他异常。我记得好像有一个 arch forum 上的帖子说可能是硬件问题，但分区上也没有坏块。
直到有一天更新完系统后整个 KDE 桌面崩溃了，很多设置组件和整个显示设置都少了很多。或许是时候丢掉现有的文件系统了吧
之后就是提取所有 root 文件系统下的文件到一块独立的储存上打包成了 .tar 准备重建文件系统。这块储存倒是很可靠，这么长时间了一点问题也都没有，倒是让我相信了现在的处境是文件系统的问题。
创建文件系统重新解压数据，最后确认一下 fstab 和 bootloader 整个过程除了等还是等。不过这次我选了 xfs 当做文件系统，毕竟相信一个凶手在没有任何变化的情况下不杀掉数据是不现实的（而且当时我也在尝试用 Red Hat 生态的服务器系统，xfs 是它们的默认值）
但问题还是存在，而且没有了内置的文件透明压缩，磁盘占用量高了两倍左右
从 KDE 崩溃到问题的开始其实已经很近了，被这么折腾了一大圈真的好累好累。这是第一个诱因
年初的时候我就有琢磨过怎么备份才是最好的解决方案：
用端到端加密在自托管的云服务器上安全的储存和同步文件的思路
但到后来由于 webdav 在同步方面的各种不方便，就用起了 syncthing 来同步 keepass 的数据库，而帖子的主角也就是那块 root 分区的 LUKS2 恢复密钥就存在其中。
Syncthing 是一个去中心化的本地（好像也可以 relay）文件同步软件。每个客户端只要连接着彼此他们之间的更改就都可以被几乎及时的同步到其他客户端
在我的网络里有一个笔记本、一部手机、还有这台主力电脑。考虑到笔记本的开机时间大概率会和主力机错开，所以我一直都依赖手机在两者之间做缓冲，而且这样手机本身也可以查看密钥嘛
问题是…
Syncthing 如果在手机上一直启动会特别耗电…… 电池续航–
这也就导致了在整个网络中，数据能被同步的窗口从近乎90%下降到了<50%。到这里事情就已经开始不妙了
但还有更不妙的…
给手机初始化了系统，所以里面少了很多软件或者有些没有被配置。比如 syncthing…
至此，网络中的同步就开始完全依赖与主力机和笔记本同时开机了，没有任何其它冗余。而这也意味着在没有主动同时打开笔记本的情况下数据是很难离开主力机的
紧接着的一两天内我又在看 systemd 的 systemd-cryptenroll 要怎么在已经用上 TPM2 Policy 的同时绑定一个固定的 PCR 值，这并不是重点。
但在鼓捣的同时，出于某些原因我重新生成了一个新的恢复密钥并添加了一个临时密码用来快速输入去测试其他解密方式。而新的恢复密钥则和旧的一样放到了 keepass 数据库里
然后就是…
所以恢复密钥会在哪里呢？
当当当当，只有加密分区里有最新的版本。
同步系统的冗余失效了，其它冷备份在需要最新数据的场景下也显得相当无力。面对64个随机字符的恢复密钥，唯一的选择只有删除分区
之后在准备装新系统的时候打算把电脑里的 windows 和 linux 都重装一下，前者已经因为 bug 更新不了了，后者已经消失了嘛
但这时突然发现 windows 的安装过程一切顺利，但另一边新选的 Fedora 在用 btrfs 时安装会报错，而且是和 Arch 下一模一样的问题：”Truncated tar archive”
Fedora 作为 Red Hat 系列发行版的最上游，虽然发布节奏超快但发行版自身的组件相当稳定，就像 Ubuntu 非 LTS 那样。第二次重试安装后，安装时报错的包名甚至不一样了。到这里我才意识到，原来问题的根源来自硬件
想要 debug 最好的入手点就是找找我改过什么。AMD CPU 的 PBO 机制和 Intel 的睿频类似，只是可以更加细致的控制怎么提升频率，电压和频率的关系是怎么样的。
其中有个功能叫做 Curve Optimizer，一般用来欠压超频用，可以稍微省点电。这个值应该只是计算公式中的一部分，根据之前的测试，我的个这台电脑的设置是全核心 -20。但经过这件事后我就去找了正经工具测试了一下稳定性：sp00n/CoreCycler
结果反复测试发现，整个 CPU 只有一个核心的体制甚至不能支撑到 -10 的欠压，但其它核心都能跑在 -20 以下。
由于我之前给这颗体制很烂的核心也设置了 -20。在实际场景中就导致了只要有极重负载的计算落到这颗核心上持续的时间只要长过5秒就一定会返回错误结果。有一个场景很符合这种“极重负载”，加密和压缩，dm-crypt 和 btrfs 的 zstd 压缩全都占了。
可能这也是为什么之前小批量更新软件就不会出问题吧，负载分摊到这颗烂核心上的概率稍微小一些，而且即使有持续时间也不长
咕咕了很多天后，所有的事情都在被逐一解决。先是在本地常开的小服务器上跑了 syncthing 的节点，这样只要设备在家里就99%可以同步数据。加上之前给其它服务们用的 tailscale 网络，即使不在家里同步机会也相当的多
另外也在其它方面上改变了对待各种长期不变的“密钥”类数据的备份方式，不在依赖于单一备份手段了。更何况这个“备份”手段主打的功能是“同步”呢，意义上就不一样
最后就是把主力机从 Arch Linux 换成了 Fedora，我真的不知道这是不是个正确的决定，但… 我喜欢系统，不代表要天天被系统玩弄做那些学不到新东西的事情。Arch 教会了我超多的知识，但当明白了之后剩下的恼人成分反而侵蚀了日常。
不过 Arch 以后还是会在某些地方用的啦，我对系统的看法真的相当因地制宜233
终于…
可以清静一阵子了么
一般来说只读的英文全称 read-only 会在很多地方简化为 ro，对应的反义词是 read-write 简写是 rw
POSIX 文件系统作为最常见的权限系统存在于几乎所有 Unix 系统上，你可以用 ls -l <filename> 查看到相应文件的权限：
$ ll
total 4.0K
drwx------ 2 root root 60 Sep 17 04:32 ./
drwx------ 34 root root 0 Sep 17 04:32 ../
-rw-r--r-- 1 root root 10 Sep 17 04:32 filename
最下面的文件 filename 就是例子，在那一行最左边的元素 -rw-r--r-- 就是它的权限：
- |rw- |r-- |r-- |
type |owner |group |other|
Type 意味着这个文件是一个普通的文件而不是文件夹或者硬件设备。Owner 权限表示它的所有者对这个文件可读可写，Group 权限表示文件对它所属的组仅可读，Other 权限表示除此之外的所有人对它都仅可读
这里的场景也可能变成这样子：
- |rwx |rwx |rwx |
type |owner |group |other|
这样，无论是所有者还是文件所属的组还是其他人都可以读写这个文件，并且如果这个文件是可执行文件，无论是二进制文件还是脚本，所有人都有权限执行它。比如：$ ./filename
开头的 type，也可能是 d 表示目录（directory），或者 b 表示块设备（block）比如 /dev/sda 这块硬盘就是一个块设备。
另外目录“文件”必须要有可执行权限，也就是 rwx 中的 x 才能被进入，比如命令 cd。所以在 drw-rw-rw- 的情况下，所有人都可以修改这个文件夹本身的名字，但谁都不能进去看到里面的内容
更改文件权限可以用命令 chmod 实现，不过方式有很多种可能类似与下面这些形式：
chmod 700 dirname
chmod o-rwx dirname
chmod 644 filename
chmod a-w filename
如果有需要的话一个权限为 ---------- 的文件也是可以存在的（chmod 000 filename），不过除了 root 以外没人能直接读写就是了。而且所有者也可以随时把权限改成别的状态再进行读写
另外，如果你知道的话 suid 和 guid 这种东西也归这里管。好了，就说这么多
这是个我很陌生的领域，因为日常场景中基本完全不需要它。我上次见他还是在 btrfs，有一个属性可以去关闭某个文件的 CoW（写时复制）功能
想要查看当前文件拥有的属性可以用命令 lsattr，它和 ls 很像，但每一行最前面的条条变长了好多…
设置或者更改属性可以用命令 chattr，它类似于 chmod，一般来说整个命令可能看起来像这样子：chattr +i filename
和 read-only 相关的属性就是 i，他的介绍是这样的：
A file with the ‘i’ attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file, most of the file’s metadata can not be modified, and the file can not be opened in write mode. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.
具有’i’属性的文件不可修改：无法删除或重命名该文件，无法创建指向该文件的链接，文件的大部分元数据不可修改，且无法以写入模式打开该文件。仅超级用户或拥有CAP_LINUX_IMMUTABLE能力的进程可设置或清除此属性。—— Deepl.com free
大概是 immutable/不可变 的意思。
设置了这个属性的文件或者文件夹即使是所有者在也不能修改一点内容，而且即使是 root 也需要先动用特权删除这一属性才能修改内容：chattr -i filename
添加了属性后在看 lsattr 会看起来像这样：
$ lsattr
----i----------------- ./filename
在 /etc/fstab 里写文件系统的配置时，还有 mount -o <options> 时都可以指定一系列的挂载选项。用的最多的选项合集 defaults 中就包含了一个 rw 选项。与之对应的，你也可以在挂载时补上一个 ro 来在文件系统层面上禁止所有账户和软件的写入操作，甚至完全包括 root
另一个好玩的选项是 umask=XXXX，它和命令 umask 类似都是用来指定文件权限的掩码，但命令 umask 是应用于当前的终端登陆中创建的文件的，而 umask=XXXX 挂载选项则是应用在了整个文件系统上。
比如为 /boot 分区的挂载指定 umask=0077 就可以完全屏蔽掉所有原先存在的所有者以外的任何权限。权限列表也会变成 -rwx------
有一个可能的限制方式是挂载一个类型为 bind 的“文件系统”，它会将一个路径绑定到挂载点上，在这个过程中就可以加上一些挂载选项来做些什么。
比如：
mount --bind -o "ro" /path/dir /path/dir
虽然两次路径一样，但由于新加入的挂载选项也让 /path/dir 这个目录变为了文件系统级别的只读
关于挂载选项什么的，还有些比较有用的选项比如 noexec，nodev，nosuid。分别能在文件执行时阻止它，禁止出现特殊的设备文件，和禁止出现 suid 可执行文件
这是个听上去很危险的话题（事实上也是）。
一些文件系统的实现在发现磁盘上出现了自己无法处理的错误时，会触发一定的保护机制将挂载选项里的 rw 改成 ro，并拒绝执行任何更多的写入操作。btrfs 就是一个例子，因为我没遇到过 ext4 出问题过（什（怎么感觉是讽刺
一般来说重启后内核模块都会重置，文件系统会重新可写，但一定一定要在出问题后运行一次对应文件系统的检查功能。不然数据可能在过一段时间真的会消失（大概吧，也可能什么都不会发生233
虽然不知道为什么，但是突发奇想花了一个小时面无表情的写了这篇东西。校对很少，所以，谢谢你能看到这里awa
Jekyll 的 markdown 解析器把 Red Hat 链接里的 | 解析成表格了…
所以手动换成 - 咯，抱怨一下
It’s not a full tutorial, but an overall concept explanation with many examples you need.
Installing the bootloader in Arch Linux is always the first difficult and complex step that user encounter. But still under control, the beginners just need to run a few commands to get a GRUB install:
# root
grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=GRUB
grub-mkconfig -o /boot/grub/grub.cfg
After installation, each time GRUB’s EFI entry is running, it will combine the microcode, initramfs and the kernel image at runtime.
Those file archive images are stored in EFI system partition(ESP), that’s /boot in the filesystem.
So where do those archives come from?
The kernel file is a binary executable that’s downloaded from package manager, which is usually named vmlinuz-linux. The microcode is the same, but named *-ucode.img(e.g. amd-ucode.img).
But the initramfs wouldn’t appear out of the air. It actually is a cpio archive that contains the basic kernel modules and the essential support files to help the kernel prepare the entire filesystem tree, then switch root into the real filesystem that’s placed on real drives.
In Arch Linux, the initramfs is generated by Mkinitcpio(whisper: because they made this). The other alternatives are Dracut and Booster(Though I never used booster at all).
Anyway, the dracut is a popular solution for other distributions like Fedora, I also use it personally.
In addition, microcode is usually packaged in initramfs. The difference between can be found here: ArchWiki Microcode
Some initramfs generator will package them automatically, so you probably don’t need worry about microcode in the later part.
Remember, the initramfs is just a filesystem archive, they are not executable. The real software that start from UEFI(or BIOS?) can be called “bootloader”, but many of them have a select menu and a kernel parameters editor, so they also can be called “boot manager”.
GRUB is an extremely popular and common software for this purpose, almost all the distributions use it, except Arch Linux is uses systemd-boot. Considering its some auto-discover features, we will also use it later in some non-traditional way.
As an example, my dracut configuration is this:
# /etc/dracut.conf.d/<any_filename>.conf
# the world best compression algorithms.
compress="zstd"
# some essential modules for following steps, I'm not sure.
add_dracutmodules+=" systemd resume crypt tpm2-tss "
# cause bugs on my machine, but may not on yours.
omit_dracutmodules+=" brltty "
You can call it manually, but I will use kernel-install to call it automatically which I’ll explain later.
There is a last thing may cause some confusing: stub
It’s kind a filler between UEFI and kernel. So if you want, boot the kernel image just from firmware setup menu directly isn’t impossible. Don’t try it yourself, unhealthy for mind…
After finishing the classic method, let’s talk about Unified Kernel Image(UKI).
Systemd’s UKI is basically around the systemd-stub, it’s a stub that we previously talked about. But the special point is it will lookup the resources that kernel needs from its executable binary section self, like kernel command line parameters, kernel binary and initramfs.
The systemd-stub is just a bunch of support files and a format spec, the generator of this format by systemd is systemd-ukify.
It’s a command line focused software, it feels like designed for command but added config file support later.
I didn’t use it individually, but with another systemd tiny script util: kernel-install. It can help me get some kernel ver staff automatically and call ukify.
It sounds like a lot of stuff here, but the basic configuration and the usage are very simple:
# /etc/kernel/install.conf
layout=uki
initrd_generator=dracut
uki_generator=ukify
# /etc/kernel/uki.conf
# basic configuration doesn't need any content in this file
# but if you want... add a splash image are also great (O-O)
[UKI]
Splash=/usr/share/systemd/bootctl/splash-arch.bmp
# /etc/kernel/cmdline
# put your command line parameters here. for example:
ro quiet splash
Then run this to install all the kernel versions with UKI format:
# root
kernel-install add-all
It will auto-discover the ESP mount point(e.g. /boot) and output the .efi file in /boot/EFI/Linux/ directory. It maybe named <random_id>-6.15.8-arch1-2.efi.
Now you have two options to boot this efi file with UEFI firmware:
They are both ok, and I tried both of them for a long time.
By the way, the
.efifile is actually a PE format executable, just like Windows(because Microsoft is the leader of UEFI).
However, not only ukify can generate UKI. Like dracut can also do it, I used it for a long time in the past too, but more complex then ukify.
systemd-boot is a UEFI boot manager, it’s mainly used to chain-loading other efi files.
It doesn’t require much configuration, it will find common efi files with itself and show them up in the selection menu(like Windows Boot Manager or /boot/EFI/Linux/*.efi).
Run this command to install it, but notice it won’t be auto update by default:
# root
bootctl install
It will generate some stuff in /boot/loader/, don’t care.
Ok, those are all the knowledge you and me should know, time to switch_topic.service to TPM2.
The last
.serviceruns in initramfs namedswitch_root.service
I need to say it is a meaningless term, we can clearly call it “TPM2 Registers”.
The PCR is the most important part of TPM2, which measures the platform state and reflects the states into those registers.
Now, only PCR 0-15 has been used, and the PCR 0-7 are controlled by platform firmware. For example, the PCR 0 means: “Core system firmware executable code”.
A full reference: Linux TPM PCR Registry
As for the PCR 11, this register is used by systemd. The systemd-stub and systemd-pcrphase will continually extend this register in the whole boot process.
Due to the way TPM2 works, the value in PCR are inreversible, so theoretically we can restrict some action to only happen in a specific boot phase.
(even though I didn’t understand this part now, more documents please qwq)
An important tool made by systemd is systemd-measure. When generating UKI, this tool is designed for reproduce what the things that systemd-stub and systemd-pcrphase will do with PCR 11 at next time they are started. Unlike PCR 0-7, this is possible because PCR 11 is only related to systemd components in UKI.
It also can sign that PCR 11’s value with a pre-generated asymmetric encryption private key, other application can verify these signature later.
You can run these commands to generate a key pair into the default path:
# root
ukify genkey \
--pcr-private-key /etc/systemd/tpm2-pcr-private-key.pem \
--pcr-public-key /etc/systemd/tpm2-pcr-public-key.pem
To use this key pair, there’s some configuration need to be added to the ukify config file:
# /etc/kernel/uki.conf
# <previous content>
[PCRSignature:default]
PCRPrivateKey=/etc/systemd/tpm2-pcr-private-key.pem
PCRPublicKey=/etc/systemd/tpm2-pcr-public-key.pem
After generated a key pair. When next time ukify generating UKI image it will call systemd-measure to pre-calculate the PCR 11, and sign the value by above cert pair then insert the signatures into .pcrsig UKI executable section.
The public key is also placed in executable section .pcrpkey. With these two section, the application now can ensure the bootloader has not been tampered with.
You can check all the sections content with ukify inspect <UKI path>.
I don’t know what the [PCRSignature:NAME] means, but if don’t add a NAME here, everything will be wrong.
The phases of signs can also be defined with: Phases=enter-initrd, but I don’t really know how to use them, just use the defaults.
The systemd-cryptenroll can help us to setup decrypt method in systemd ecosystem.
If you don’t know, you can use this following command to bind a inflexible PCR value into LUKS2 metadata:
# root
systemd-cryptenroll --tpm2-device=auto /dev/<block_device>
Also add a
--tpm2-with-pin=trueflag will blend a password(PIN) in the authorization process. TPM2 can even protect this PIN out of brute force attacks.
Back to the TPM2 policy. It can use PCR signature(PCR 11 only at here) and asymmetric encryption key pair above to calculate a secret to encrypt/decrypt LUKS2 disks. With this method, the secrets are no longer bound to a specific set of PCR values, instead the trust chain transferred to a proof that the bootloader has not been modified.
To be fair, we always bound the PCR 7(SecureBoot state) as the LUKS2 secret to verify bootloader previously, so we are still doing the same things.
In Arch Linux, each bootloader file are generated in user’s environment self, but in many case the distribution can generate their own key pair and share the public key to the users. This is telling users their bootloader has not been modified and works properly until the decrypt moment.
(I don’t know who really did this at now, it’s a cutting-edge feature of systemd :|)
To use this TPM2 policy, you can use these following flags of systemd-cryptenroll:
# root
systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs="" --tpm2-public-key=/etc/systemd/tpm2-pcr-public-key.pem /dev/<block_device>
Emm… you can see the man page online: systemd-cryptenroll
--tpm2-public-key=PATH, --tpm2-public-key-pcrs=PCR[+PCR...], --tpm2-signature=PATH
If you don’t add --tpm2-public-key, it still will search file tpm2-pcr-public-key.pem in some directories by default.
And you maybe seen the --tpm2-public-key-pcrs flag looks so attractive, can I also bind a PCR value together with the TPM2 policy? No, it’s just an option to declare which PCR are signed, but the systemd-measure will only calculate and sign PCR 11, so it’s maybe useless now.
A TPM2 PIN is still recommended.
After enroll, you can try to close and reopen your LUKS2 disk. Since the secret is independent of the PCR’s value, feel free to turn off and on secure boot as a revenge. awa
Now I have finally said everything I want to say. It’s not my native language, and also had to reference many manuals. Tired works, it took me about two days.
But I got a new blog post for August now. Yeah, one month peace(or maybe two months).
It’s doesn’t matter, but still thank you, systemd. d(d＇∀＇)
Whisper: someone said I’m cute ^=^
After Google’s Material Design 3 Expressive, Apple released their new design system Liquid Glass. Now the whole world is shifting to using more and more glass effects. But people(customers) love glass, so I accept this fed.
But overall, they are all way better than linux desktops. qwq
Emm, another thing is that Nothing(a company name) will release a new flagship android phone: Phone (3)
It will not released until July, so now there’s nothing fun to talk about.
Speaking of Nothing, I switched my system and editor fonts recently.
For monospace font the choice is still Monaspace(by GitHub Next) but using different family: Argon -> Xenon. Also means sans-serif to serif.
I’m discovering serif font recently. Nothing is famous precisely because their graph and hardware designs, why not use their font directly? For that I find this repository: Yokilleurs/NothingFonts.
But be honest, unlike my previous choice Google Sans, their fonts are not quite so generic. So compact, so artistic. The system UI font still required sans-serif fonts.
But I used NType Mono for my window title. That doesn’t matter, dose it? Reasonable sacrifice for art:
I think that’s all.
In June 2025, I only created 23 commits on github. I haven’t focused on programming since April.
However, Now I have a long-standing repository of my solutions to algorithm problems: SourLemonJuice/algorithm-problems-archive.
I didn’t spend too much time on gaming, but I did want to finish OneShot in July.
One big change is about Heroic Games Launcher, a great manager for linux gaming. I migrated all my “Non-Steam Game” to Heroic, easy to open winecfg, explicit wine prefix path. That’s way more useful.
“Non-Steam Game” referred to pirated games, but it also covered regular windows apps(e.g. NetEase Cloud Music).
And… I finally switched my Steam UI language to English. :)
I’m really concerned about cultural issues… The publisher set up the different marketing materials for each language zone, even some game covers are also different.
I… don’t know.
I missed someone’s invitation and let their down. I’m sorry for that, if you can see this.
Maybe I should plan for only next two weeks?
Even though the pride month has ended, I think I’ll still keep that rainbow emoji on some of my messaging platforms.
Why not, especially at today.
EOF
]]>[repeating]
execute as @a if score @s playtime_ticks matches 1200.. run scoreboard players add @s playtime_minutes 1
[chain]
execute as @a if score @s playtime_ticks matches 1200.. run scoreboard players set @s playtime_ticks 0
[chain]
scoreboard players set @a kPlaytimeDisplayDivisor 60
[chain]
execute as @a run scoreboard players operation @s playtime_display = @s playtime_minutes
[chain]
execute as @a run scoreboard players operation @s playtime_display /= @s kPlaytimeDisplayDivisor
NOTE:
Please point the previous block to the next one properly.
WARNING:
Thescore @s playtime_ticks matches 1200..part must use1200..(score greater than 1200) as the condition because the chain block needs 1 tick to pass the signal to the next block.
Not doing so will cause a lot of bugs.
The scoreboard objective playtime_ticks is a temporary variable of the structure, the real playtime storage in playtime_minutes.
The minute is the smallest unit that can be recorded here, but we usually don’t want to display them directly, that would be too long.
So the second part of the code is used to calculate objective playtime_display by playtime_minutes / kPlaytimeDisplayDivisor. As an example in the code, the kPlaytimeDisplayDivisor is 60, which means the display unit is one hour.
Same thing, 120 is two hours.
Type this command to display this objective in sidebar:
/scoreboard objectives setdisplay sidebar playtime_display