Omarchy on MacBook 系统环境配置：快捷键/亮度修复 / fcitx5 智能ABC双拼 / sshd 安全加固 / 双机互信 / Mac 双系统启动(Limine chainload macOS)

fcitx5-shuangpin-abc-cloudpinyin.md

fcitx5 双拼（智能ABC）+ 云拼音 + 动态词频配置实录

环境：Omarchy (Arch Linux) / fcitx5 5.1.22 / fcitx5-chinese-addons 5.1.14 目标：智能ABC 双拼方案、云拼音（GoogleCN 后端）、基于使用频率的动态词频调整

1. 安装

sudo pacman -S --needed fcitx5-chinese-addons fcitx5-lua
# 依赖自动带入：libime、opencc、marisa
# fcitx5-lua 是可选依赖，提供符号/emoji 候选触发（sx、v 模式）

环境变量（Wayland/Hyprland 下 GTK/Qt 走 wayland text-input，无需额外设置）： XMODIFIERS=@im=fcitx、QT_IM_MODULE=fcitx、SDL_IM_MODULE=fcitx

2. 输入法注册：~/.config/fcitx5/profile

只注册 shuangpin 一个输入法：

[Groups/0]
Name=Default
Default Layout=us
DefaultIM=shuangpin

[Groups/0/Items/0]
Name=keyboard-us
Layout=

[Groups/0/Items/1]
Name=shuangpin
Layout=

[GroupOrder]
0=Default

3. 双拼引擎配置：~/.config/fcitx5/conf/pinyin.conf

ShuangpinProfile=ABC
ShowShuangpinMode=True
PageSize=9
CloudPinyinEnabled=True
CloudPinyinIndex=2
CloudPinyinAnimation=True
KeepCloudPinyinPlaceHolder=True
PinyinInPreedit=True
Prediction=True
PredictionSize=49
Learning=True

[Fuzzy]
VE_UE=True
NG_GN=True
Inner=True
InnerShort=True
PartialFinal=True
PartialSp=True
Correction=QWERTY

关键项说明（与 fcitx5-chinese-addons 源码 im/pinyin/pinyin.h 对照过）：

键	作用
ShuangpinProfile=ABC	双拼方案枚举：Ziranma, MS, Ziguang, ABC(智能ABC), Zhongwenzhixing, PinyinJiajia, Xiaohe, GB, Custom
Learning=True	动态词频：根据选词自动调整用户词库频率（libime user lexicon，无独立开关名“词频调整”）
CloudPinyinEnabled/Index	云拼音候选插在第 2 位
KeepCloudPinyinPlaceHolder=True	云结果未返回时占位不塌缩，候选列表不跳动
PinyinInPreedit=True	预编辑显示完整拼音而非双拼字母，可读性好
Prediction=True	上屏后预测下一词
PartialSp=True	输入长度 >4 时允许部分双拼匹配（双拼用户实用）
Correction=QWERTY	邻键纠错

4. 云拼音后端：~/.config/fcitx5/conf/cloudpinyin.conf

MinimumPinyinLength=4
Backend=GoogleCN

后端枚举只有三个（modules/cloudpinyin/backend.h）：Google, GoogleCN, Baidu。没有腾讯/微信后端，Proxy 是全局单值（cURL 格式，如 Proxy=http://host:port），无法按后端区分。

后端可达性测试（直连 vs 代理）

# Google:   https://www.google.com/inputtools/request?ime=pinyin&text=<pinyin>
# GoogleCN: https://www.google.cn/inputtools/request?ime=pinyin&text=<pinyin>
# Baidu:    https://olimenew.baidu.com/py?input=<pinyin>&inputtype=py&resultcoding=utf-8

curl -sS -m 10 "https://www.google.cn/inputtools/request?ime=pinyin&text=nihaoshijie"
# ["SUCCESS",[["nihaoshijie",["你好世界"],[],{...}]]]   ← 解析路径 jv[1][0][1][0]

# 走代理对比：
curl -sS -m 10 -x http://10.10.100.100:64540 "https://www.google.com/inputtools/request?ime=pinyin&text=nihao"

实测：google.com 直连超时、走代理 0.9s；google.cn 直连 0.37s（最优，故选 GoogleCN 且不设 Proxy）。

5. 踩坑：systemd unit 启动时序竞态覆盖配置

Omarchy 用 omarchy-fcitx5.service（systemd user unit）管理 fcitx5，且带自动重启。安装 chinese-addons 期间 unit 自动重启了一次（早于包安装完成），旧实例退出时把内存中的 profile（只有 keyboard-us）写回磁盘，覆盖了新配置；随后新实例读到的就是被覆盖后的文件。

正确姿势：

systemctl --user stop omarchy-fcitx5.service   # 先停干净
# 写 profile / conf/*.conf
systemctl --user start omarchy-fcitx5.service  # 再启动

另一个坑：fcitx5-remote -o 在 headless shell 里永远返回 inactive(1)——它作用于焦点输入上下文，没有窗口焦点时无效，属正常现象。AvailableInputMethods dbus 调用返回的是全部可用目录（含所有键盘布局），不是当前启用的组，别拿它当启用验证。

6. 使用要点

操作	键
激活/切换	Ctrl+Space（激活后显示 双（智能ABC））
云拼音候选位置	第 2 位（输入 ≥4 个音节才触发）
云拼音开关	Ctrl+Alt+Shift+C
忘词（重置词频/删自学习词）	Ctrl+7
快速输入	; 或 v 引导（www. / http: / 颜文字 / emoji）
以词定字	[ ] 取词组第 1/2 字

验证配置是否被正确读取：

busctl --user call org.fcitx.Fcitx5 /controller org.fcitx.Fcitx.Controller1 CurrentInputMethod
journalctl --user -u omarchy-fcitx5.service -n 20
# 首次启动 "Failed to load pinyin history: io fail" 属正常——历史文件尚不存在，Learning 会创建

omarchy-macbook-hotkeys.md

Fixing Brightness Keys on MacBook Pro (Omarchy / Hyprland)

Hardware: MacBook Pro 11,5 (Mid-2015, 15", dGPU Radeon + i915, gmux backlight) Software: Omarchy (Arch Linux + Hyprland), kernel 7.2.5

This document captures the full investigation and the minimal, correct fix for the F1/F2 brightness keys behaving the macOS-native way: press F1 / F2 to dim/brighten the panel, hold Fn and press F1 / F2 to send a plain F1 / F2 to the focused app. It also covers binding F3 (Mission Control) and F4 (Launchpad), which the Apple keyboard emits as KEY_SCALE (evdev 120) and KEY_ALL_APPLICATIONS (evdev 204) under fnmode=1 and which Hyprland cannot bind by keysym.

TL;DR

If you just want it working, do these four things and reboot:

# 1. Make macOS-native fn mode permanent.
echo 'options hid_apple fnmode=1' | sudo tee /etc/modprobe.d/hid_apple.conf

# 2. Tell Hyprland that the internal panel is "Unknown-1" so it stays bound
#    across reloads (otherwise it can lose the output on hot-reload).
cat > ~/.config/hypr/monitors.lua <<'EOF'
local omarchy_gdk_scale = 2
local omarchy_monitor_scale = 1.6

hl.env("GDK_SCALE", tostring(omarchy_gdk_scale))
-- The internal panel on MacBookPro11,x reports as "Unknown-1" because
-- gmux-controlled i915 doesn't expose an eDP connector name. The wrapper
-- at ~/.local/bin/omarchy-hyprland-monitor-focused translates it to eDP-1
-- so omarchy-brightness-display routes through gmux_backlight instead of
-- the failing DDC/CI path.
hl.monitor({ output = "Unknown-1", mode = "preferred", position = "auto", scale = omarchy_monitor_scale })
EOF

# 3. Shadow omarchy's monitor-name query so the panel is recognised as
#    internal (eDP-1) by brightness/audio/etc. scripts.
cat > ~/.local/bin/omarchy-hyprland-monitor-focused <<'EOF'
#!/bin/bash
exec /usr/share/omarchy/bin/omarchy-hyprland-monitor-focused "$@" \
  | sed -E 's/^Unknown-1$/eDP-1/'
EOF
chmod +x ~/.local/bin/omarchy-hyprland-monitor-focused

# 4. Prepend ~/.local/bin to PATH for keybind-spawned processes.
#    Append this block at the end of ~/.config/hypr/hyprland.lua:
cat >> ~/.config/hypr/hyprland.lua <<'EOF'

do
  local current = os.getenv("PATH") or ""
  local prepended = os.getenv("HOME") .. "/.local/bin"
  local seen = {}
  local out = { prepended }
  for entry in current:gmatch("[^:]+") do
    if entry ~= "" and entry ~= prepended and not seen[entry] then
      seen[entry] = true
      table.insert(out, entry)
    end
  end
  hl.env("PATH", table.concat(out, ":"))
end
EOF

# Apply (Hyprland reload is enough; kernel module needs a reboot for fnmode).
hyprctl reload
sudo reboot

The Problem

On the MacBook Pro 11,5 the Apple Internal Keyboard (USB device 05ac:0274) sends HID scancodes that the Linux hid_apple driver is supposed to translate to KEY_BRIGHTNESSDOWN / KEY_BRIGHTNESSUP when the keys are pressed without Fn. On this kernel, the translation is happening — but two other things are wrong:

1. Hyprland names the internal panel Unknown-1 instead of eDP-1, because the gmux-controlled i915 output has no proper EDID connector name. Omarchy's omarchy-brightness-display script classifies anything not matching ^(eDP|LVDS|DSI)- as an external display and tries to use DDC/CI, which silently fails. Pressing the brightness keys then has no visible effect.

2. The default fnmode shipped with hid_apple (and assumed by most online guides) is the opposite of the macOS default. Kernel 7.2's modinfo hid_apple is unambiguous about it:

   fnmode: 0 = disabled
           1 = fkeyslast    <- macOS default: media keys first
           2 = fkeysfirst   <- inverted: F-keys first
   

   Anything still relying on fnmode=2 to get macOS behaviour is wrong.

The Diagnosis Path (what we ran)

These are kept for reference; the actual fix above needs none of them.

1. Read the keyboard's raw evdev stream

/dev/input/event6 is the Apple Internal Keyboard / Trackpad's keyboard interface. With libinput debug-events, the F1 press shows up as KEYBOARD_KEY … (-1) pressed — the kernel hid_apple is sending an event the userspace libinput cannot decode.

A raw-bytes probe (parsing struct input_event directly) gives us both MSC_SCAN (the raw HID usage) and the Linux keycode:

MSC_SCAN  0x0007003a
EV_KEY code=59(0x03b) value=1   <- plain F1 -> KEY_F1

2. Discover the monitor name mismatch

$ hyprctl monitors -j | jq -r '.[] | .name'
Unknown-1

And omarchy-brightness-display shells out to a classification function:

monitor_is_internal() {
  [[ $monitor =~ ^(eDP|LVDS|DSI)- ]]
}

So Omarchy routes the brightness action through DDC/CI for this panel, which fails. Manual brightnessctl -d gmux_backlight works fine — backlight device exists and is writable — confirming the wiring is correct.

3. Identify the fnmode inversion

Reading modinfo hid_apple fnmode gives:

Mode of fn key on Apple keyboards (0 = disabled, 1 = fkeyslast, 2 = fkeysfirst, ...)

fkeyslast (fnmode=1) is what macOS ships with: media keys take precedence, F1–F12 need Fn for the F-keys. The default at boot is 2 (fkeysfirst) on Arch's hid_apple. Setting it to 1 is the macOS-native choice.

4. Verify with a focused raw-bytes probe

After setting fnmode=1, the same probe shows the kernel now does the translation natively:

Press	HID scancode	Linux keycode	Behavior
F1 alone	0x0007003a	224	KEY_BRIGHTNESSDOWN ✓ macOS default
F2 alone	0x0007003b	225	KEY_BRIGHTNESSUP ✓
Fn + F1	0x0007003a	59	KEY_F1 ✓
Fn + F2	0x0007003b	60	KEY_F2 ✓

No userspace remapper (keyd, python daemon, udev hwdb) is needed once fnmode=1 is in place.

False Leads (and why they didn't end up in the fix)

udev hwdb mapping 0x7003a/3b → brightnessdown/up

Useful only when fnmode is mis-set (and only as a stopgap): it forces every press of the scancode to be a brightness key, regardless of whether Fn is held, so it breaks the "Fn+F1 = plain F1" half of the requirement. Removed once fnmode=1 was confirmed working.

keyd daemon

Installed and configured as [fn] brightnessdown = f1 to translate when Fn is down. The [fn] layer was ending up "always on" because keyd's view of fn differs from the kernel's, and the layer ended up intercepting brightness-down events with no Fn held. Not worth the complexity once fnmode=1 alone solves it.

Python daemon via libevdev/uinput

Same idea as keyd but rolled by hand. Same problem as keyd: anything we build here is patching around the wrong fnmode value, not the real root cause.

Files Touched (final state)

/etc/modprobe.d/hid_apple.conf                       # options hid_apple fnmode=1
~/.config/hypr/monitors.lua                          # hl.monitor({ output = "Unknown-1", ... })
~/.config/hypr/hyprland.lua                          # ~/.local/bin prepended to PATH + hymission config
~/.local/bin/omarchy-hyprland-monitor-focused        # Unknown-1 -> eDP-1 wrapper
~/.config/hypr/bindings.lua                          # F3 / F4 bindings (see below)

Bonus: F3 (Mission Control) and F4 (Launchpad)

With fnmode=1 the remaining top-row keys also work macOS-natively out of the box except F3 / F4, which have no Omarchy binding:

evdev code	Kernel key	Meaning
120	KEY_SCALE	Compiz Expose
204	KEY_ALL_APPLICATIONS	Launchpad / Show apps

Two gotchas were required to get F3 / F4 bound:

1. Hyprland code:N uses XKB keycodes = evdev + 8

Hyprland's bind will fire for a key pressed with a different number than the Linux evdev code. The input.keyboard.key Lua event reports XKB keycodes, which are evdev + 8:

F3: evdev 120 -> XKB 128
F4: evdev 204 -> XKB 212

So the correct bindings are code:128 and code:212, not code:120 / code:204. Verify with a probe that writes XKB keycodes to a file:

hl.on("input.keyboard.key", function(keycode, mods, pressed)
  if not pressed then return end
  local f = io.open("/tmp/keys.log", "a")
  if f then f:write(keycode .. "\n"); f:close() end
end)

2. No XKB keysym exists for KEY_SCALE / KEY_ALL_APPLICATIONS

On a default XKB keymap, evdev 120 and 204 do not map to any standard XF86* keysym, so you cannot bind them by keysym name (XF86FullScreen, XF86Tools, etc. all mismatch). You must use the XKB keycode form.

3. Mission Control via a Hyprland plugin

Omarchy has no Mission Control equivalent. The hymission plugin (https://github.com/gfhdhytghd/hymission) provides one:

hyprpm update
hyprpm add https://github.com/gfhdhytghd/hymission
hyprpm enable hymission
hyprpm reload

~/.config/hypr/hyprland.lua:

-- Dark backdrop + focus indicator so the overview is visibly distinct.
hl.config({
  plugin = {
    hymission = {
      only_active_workspace = 0,
      only_active_monitor = 0,
      backdrop_blur = 1,
      backdrop_color = "rgba(0c0c1aee)",
      show_focus_indicator = 1,
      debug_logs = 0,
    },
  },
})

~/.config/hypr/bindings.lua:

-- Note: Hyprland code:N is XKB keycode (evdev + 8).
o.bind("code:128", "Mission Control", function() hl.plugin.hymission.toggle() end)
o.bind("code:212", "Launchpad", "omarchy-menu toggle apps")

F4 deliberately repeats SUPER + ALT + SPACE (Apps menu) — that is the macOS-natural Launchpad action; the keycap duplicates rather than diverges.

Verification Commands

# fnmode survived reboot:
cat /sys/module/hid_apple/parameters/fnmode           # -> 1

# Wrapper is in effect for spawned keybind commands:
PATH=$HOME/.local/bin:/usr/share/omarchy/bin:/usr/bin \
  omarchy-hyprland-monitor-focused                     # -> eDP-1

# Backlight device exists and responds:
brightnessctl -d gmux_backlight get                   # current value
PATH=$HOME/.local/bin:/usr/share/omarchy/bin:/usr/bin \
  omarchy-brightness-display +5%                      # +5% step
brightnessctl -d gmux_backlight get                   # value increased

# Plugin is loaded:
hyprctl version | head -1                             # Hyprland 0.56.x
hyprctl plugins list 2>&1 | head                      # hymission 0.8.x

# F3/F4 bindings are registered:
hyprctl binds | grep -A1 "Mission Control\|Launchpad"

Pressing F1 / F2 pops the OSD and adjusts brightness; Fn + F1 / Fn + F2 sends a real F1 / F2 to the focused window. Pressing F3 opens a Mission-Control style overview of all windows across workspaces (press F3 again or Escape to close). Pressing F4 opens the Omarchy Apps menu (Launchpad).

omarchy-system-environment.md

Omarchy 系统 basic 环境配置：sshd / 安全加固 / 双机互信 / 双系统启动

环境：Omarchy 4.x (Arch) / 真 Mac (Apple UEFI) 单盘 GPT：ESP(Limine) + APFS(macOS) + btrfs(Omarchy) 网络：10.10.0.0/16 局域网，GFW 环境，HTTP 代理 http://10.10.100.100:64540

1. 启用 sshd（密码 + key 认证）

sudo ssh-keygen -A                      # 首次生成 host keys
cat ~/.ssh/id_ed25519.pub >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys

/etc/ssh/sshd_config.d/10-lax-login.conf（主配置只有 Include，策略全放 drop-in）：

Port 22
PubkeyAuthentication yes
PasswordAuthentication yes
PermitRootLogin no
AllowUsers lax

sudo sshd -t && sudo systemctl enable --now sshd.service
sudo ufw allow 22/tcp comment 'ssh'
# 验证：实际登录一次
ssh -o BatchMode=yes lax@127.0.0.1 'echo ok'

2. 远程登录安全加固（防锁死顺序：先 ufw → 再 sshd → 最后 fail2ban）

ufw 收紧（LAN-only + 限速）：

sudo ufw delete allow 22/tcp
sudo ufw limit proto tcp from 10.10.0.0/16 to any port 22 comment 'ssh lan'
sudo ufw allow proto tcp from 10.10.0.0/16 to any port 53317 comment 'localsend lan'
sudo ufw allow proto udp from 10.10.0.0/16 to any port 53317 comment 'localsend lan'

sshd 收紧（并入上面的 drop-in）：

MaxAuthTries 3            # 默认 6
LoginGraceTime 30         # 默认 120
ClientAliveInterval 300   # 空闲 ~10 分钟断开
ClientAliveCountMax 2
AllowTcpForwarding no     # 关隧道（按需取舍）

fail2ban（Arch 无 auth.log，用 journal 后端）— /etc/fail2ban/jail.d/sshd.local：

[sshd]
enabled = true
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h

sudo pacman -S --needed fail2ban
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd          # 看 jail 是否挂上 journal
sudo fail2ban-client set sshd unbanip <IP> # 手工解封

3. 双机 SSH 对等互信（别名 + 专用密钥）

本机 ~/.ssh/config（0600）：

Host meowium
    HostName 10.10.100.100
    User lax
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

反向：在远端生成专用密钥（不复用旧 RSA/GitHub key）：

ssh meowium 'ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_omarchy -N "" -C "lax@meowium-to-omarchy"'
ssh meowium 'cat ~/.ssh/id_ed25519_omarchy.pub' >> ~/.ssh/authorized_keys

远端已有 host omarchy 块时，精准改 IdentityFile + 加 IdentitiesOnly yes。 安全补丁法：先备份 → grep -c 确认块唯一 → python3 按块边界（host omarchy 到下一个 host 行）替换，匹配数 ≠1 直接 abort 不写盘 → diff config.bak config 回归确认只动了目标块。

注意 ssh_config 语义：先到先得（first-obtained wins）——主机专用块必须放在 host * 通配块之前；IdentityFile 是累积项，多个块会叠加。回程实测用 ssh -o BatchMode=yes（强制仅 key，能过才算数）。

4. 真 Mac 双系统：确认 macOS 还能不能启动

lsblk -o NAME,SIZE,FSTYPE,PARTTYPE,PARTUUID   # APFS 分区 type GUID: 7c3457ef-0000-11aa-aa11-00306543ecac
sudo efibootmgr                               # 注意：只列出“标准命名空间”的启动项

要点（MacBookPro11,5 + Omarchy 实测）：

• macOS 固件真正依赖的启动项在 Apple 私有命名空间（a5ce328c-769d-11e9-94c7-8c85906bac48）的 Boot0080，描述为空；efibootmgr 只读标准命名空间（8be4df61-…），因此看不到它。
• 标准命名空间里叫 Mac OS X 的条目（如 Boot0081）由 macOS 维护，重分区/重装后可能过期：其设备路径的 HD(2,GPT,<UUID>) 与 APFS 分区当前 PARTUUID 对不上。此时按 Option (⌥) 仍能进 macOS（固件用的是 Boot0080），但 Limine 的 efi_boot_entry "Mac OS X" 会失败。
• 判定：把条目设备路径里的 HD(2,GPT,<UUID>) 与 lsblk 的 APFS PARTUUID 逐字符比对，一致才算有效。Apple 私有条目可直接读 /sys/firmware/efi/efivars/Boot0080-a5ce328c-…——efivarfs 文件前 4 字节是变量属性，其后才是 EFI_LOAD_OPTION，别把前缀当数据。

启动 macOS：开机按 Option (⌥) 选 macOS（最可靠），或在 macOS 的“启动磁盘”里设默认。

5. 在 Limine 里加 macOS 条目（关键：Limine 读不了 APFS）

先纠正一个误区：Limine 只支持 FAT12/16/32 与 ISO9660，不支持 APFS。 所以 protocol: efi + path: guid(<APFS UUID>):/System/Library/CoreServices/boot.efi 这种“GRUB 式 chainload macOS”不可能成功（早期草案里那套 UUID 方案是错的，实测全部失败）。要让固件代劳跳转，只有两条路：

1. protocol: efi_boot_entry：Limine 把控制权交回固件，由固件启动某个具名 NVRAM 条目（回固件跳一次，官方协议、最稳）。
2. 把 OpenCore 放进 FAT 的 ESP，Limine 用 protocol: efi chainload boot():/EFI/OC/OpenCore.efi，由 OpenCore 自己读 APFS。

这里用方案 1。/efi/limine.conf（Omarchy 的 ESP 挂在 /efi，文件 root 0700，改前备份）：

timeout: 5                # 不设时 Limine 停在菜单无限等待；default_entry: 2 不动
...
/macOS
comment: Chainload firmware macOS entry "Mac OS X"
    protocol: efi_boot_entry
    entry: Mac OS X

Mac OS X 条目过期时：从 Apple 命名空间回填设备路径

有效路径保存在 Apple 命名空间的 Boot0080（描述为空）。把整段 device path 拷进标准命名空间的 Boot0081（保留名字 Mac OS X），并把 0081 加入 BootOrder：

# sudo python3；先备份 Boot0081 原始字节（需 omarchy sudo passwordless）
import os, struct, glob, subprocess
G='8be4df61-93ca-11d2-aa0d-00e098032b8c'; A='a5ce328c-769d-11e9-94c7-8c85906bac48'
vp=lambda n,ns: glob.glob(f'/sys/firmware/efi/efivars/Boot{n}-{ns}')[0]
def loadopt(raw):                 # 跳过 efivarfs 的 4 字节属性前缀，解析 EFI_LOAD_OPTION
    fplen=struct.unpack_from('<H',raw,8)[0]; i=10
    while struct.unpack_from('<H',raw,i)[0]: i+=2
    return raw[4:8], raw[i+2:i+2+fplen]
def w(p,b):
    try: open(p,'wb').write(b)
    except OSError:
        subprocess.run(['chattr','-i',p],check=False); os.remove(p); open(p,'wb').write(b)
at,fp = loadopt(open(vp('0080',A),'rb').read())
desc = "Mac OS X".encode('utf-16-le')+b'\0\0'
w(vp('0081',G), b'\x07\x00\x00\x00'+at+struct.pack('<H',len(fp))+desc+fp)
# BootOrder 追加 0081（标准命名空间）
bo=glob.glob(f'/sys/firmware/efi/efivars/BootOrder-{G}')[0]; raw=open(bo,'rb').read()
if b'\x81\x00' not in raw[4:]: w(bo, b'\x07\x00\x00\x00'+raw[4:]+b'\x81\x00')

坑与说明：

• 写 efivarfs 建变量时，前 4 字节属性必须用 0x00000007；读出来看到的 0x80000007 高比特是读侧标志，照抄写回会 EINVAL。改已有变量要 chattr -i → rm → 再建。
• efibootmgr --bootnext 0080 / -o 0080,… 对 Apple 私有命名空间的条目无效（efibootmgr 只认标准命名空间）；要默认进 macOS 请在 macOS 里设“启动磁盘”。
• limine-entry-tool --add-efi 只接受 ESP 上真实存在的 EFI 文件，efi_boot_entry 这类条目手写进 conf；limine-entry-tool --tree 能解析即语法 OK。
• 手动条目在内核更新、工具重写 conf 后检查是否仍在。
• 验证：efibootmgr -v 里 Mac OS X 的 HD(2,GPT,…) 应与 APFS 分区 PARTUUID 一致。

6. GFW 环境网络测试技巧

# 同一 API 直连 vs 代理对比（curl -x 走 HTTP 代理，HTTPS 自动 CONNECT）
curl -sS -m 10 "https://target/api" -o /dev/null -w "%{http_code} %{time_total}s\n"
curl -sS -m 10 -x http://10.10.100.100:64540 "https://target/api" -o /dev/null -w "%{http_code} %{time_total}s\n"

# 代理读 GitHub raw（拿官方文档/源码）
curl -sS -m 60 -x http://10.10.100.100:64540 https://raw.githubusercontent.com/<owner>/<repo>/<branch>/<path>
# gh CLI 同理：https_proxy=http://10.10.100.100:64540 gh ...

对比结论示例：google.com 直连超时/代理 0.9s；google.cn 直连 0.37s —— 直连快就别绕代理。