2026-05-04

Hermes

This morning, I suddenly wanted to try Hermes. The "one-command" installation failed, so I decided to clone the repository locally and do a developer installation.

I configured Kimi Coding Plan for it. When setting up the channel, I was pleasantly surprised to find that integrating the Feishu bot had been simplified to just scanning a QR code—after scanning, the bot was automatically created. (User experience wise, Bytedance really delivers.)

So far, the most intuitive impression is that it responds faster than OpenClaw, though I'm not sure if that's just because it doesn't have much memory yet.

Pick a competition to join

Earlier, I had an Agent collect information on each competition topic. The Agent recommended one and gave detailed reasons. But is it really reliable? I installed Qiushi Skill on Hermes, and it gave me the opposite opinion, saying that what the Agent said was too idealistic and didn't consider many practical factors.

Indeed, current AI tends to fawn over users too much. We need to think independently and judge for ourselves.

Accidentally deleted ~/.ssh, Kimi to the rescue

I wanted to delete some expired key pairs, so I used:

rm xxx*

Unfortunately, there was an extra space between the asterisk and the prefix, which wiped out everything in the .ssh directory.

I remember a few years ago, when I was using Git, I had an issue where all my changes were lost due to unfamiliarity with Git operations, but I recovered them using a method suggested by AI. So I immediately discussed the recovery plan with Kimi.

对话记录

💬

me

I accidentally deleted everything in ~/.ssh. How do I recover?

🤖

Kimi

Accidentally deleting ~/.ssh can have consequences ranging from minor to severe, depending on whether you have backups. Here are the recovery options in order of priority: ...

💬

me

I used rm to wipe it clean. Are there any recovery methods?

🤖

Kimi

Stop writing any data to that partition immediately. ** rm directly releases inodes, and new writes will overwrite the original data blocks.
Execute the following in order of decreasing success rate:
1. Check ssh-agent (highest probability, least hassle) ...

💬

me

archlinux

🤖

Kimi

Arch Linux, likely ext4. *Time is critical. Execute the following in order, and do not write any files to the /home partition (including downloading large files in the browser). ...

💬

me

ssh-add -l
Could not open a connection to your authentication agent.

🤖

Kimi

Arch Linux + rm + no agent = do filesystem recovery immediately, but success rate drops with every second of writes.
Execute the following commands, do not reboot (rebooting will write a lot of logs):
Step 1: Determine your filesystem and partition
# Find the device path and filesystem type of the partition containing ~/.ssh
findmnt -n -o SOURCE,FSTYPE ~
...

💬

me

findmnt -n -o SOURCE,FSTYPE ~
Output is empty

🤖

Kimi

Empty output from findmnt means ~ is not a separate mount point; it's likely under the root partition. Confirm with these two commands:
bash
Copy
df -T ~
stat -f -c "Type: %T Device: %d" ~
Paste the output of these two commands immediately, and I'll give you the exact recovery command based on the filesystem type (ext4 / btrfs / xfs / zfs).
If it's btrfs (Arch's default in recent installers), recovery will be much easier—maybe even a snapshot rollback. If ext4, continue with extundelete.

💬

me

me@archlinux ~/.ssh [1]> df -T ~
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/nvme0n1p2 btrfs 999153664 397731496 600087800 40% /home
me@archlinux ~/.ssh> stat -f -c "Type: %T Device: %d" ~

💬

type

btrfs Device: 0

🤖

Kimi

btrfs! That's the best news. Arch's default installation usually enables snapper snapshots, or at least btrfs's COW feature keeps data blocks around longer.
Execute the following immediately, do not reboot:
Step 1: Check snapper snapshots (highest probability)
# Check if snapper is configured
sudo snapper list-configs ...

💬

me

me@archlinux ~/.ssh> sudo snapper list-configs
[sudo] password for me:
Config │ Subvolume
───────┼──────────
home │ /home
root │ /
me@archlinux ~/.ssh> sudo snapper -c home list
# │ Type │ Pre # │ Date │ User │ Cleanup │ Description │ Userdata
─────┼────────┼───────┼─────────────────────────────────┼──────┼──────────┼─────────────┼─────────
0 │ single │ │ │ root │ │ current │
1 │ single │ │ Fri 19 Dec 2025 03:00:03 AM CST │ root │ timeline │ timeline │
42 │ single │ │ Tue 03 Feb 2026 05:51:48 PM CST │ root │ timeline │ timeline │
204 │ single │ │ Sun 01 Mar 2026 01:00:12 PM CST │ root │ timeline │ timeline │
1555 │ single │ │ Mon 04 May 2026 11:00:02 AM CST │ root │ timeline │ timeline │

🤖

Kimi

Perfect, snapper takes snapshots every hour. It's currently 11:19, and the latest snapshot 1555 is from 11:00, which almost certainly contains the keys you just deleted.
Execute immediately:
# 1. Create mount point
sudo mkdir -p /mnt/snap ...

💬

me

me@archlinux ~/.ssh> ls /mnt/
snap/
me@archlinux ~/.ssh> sudo mount -o ro,subvol=.snapshots/1555/snapshot /dev/nvme0n1p2 /mnt/snap

💬

mount

/mnt/snap: fsconfig() failed: No such file or directory.
dmesg(1) may have more information after failed mount system call.

🤖

Kimi

Wrong path. The actual structure of snapshot subvolumes for snapper -c home needs verification. Run this diagnostic:
# 1. List all subvolumes on the partition and find the real path of the snapshot
sudo btrfs subvolume list /home | grep 1555 ...

💬

me

me@archlinux ~/.ssh [32]> sudo btrfs subvolume list /home | grep 1555
ID 3372 gen 173251 top level 263 path .snapshots/1555/snapshot
ID 3373 gen 173252 top level 262 path @/.snapshots/1555/snapshot

💬

me

Let me summarize the current situation so I can continue with Kimi in the Kimi CLI.

🤖

Kimi

Current status summary (can be copied directly to Kimi CLI):
---
Problem: User me on Arch Linux accidentally ran rm -rf ~/.ssh/, deleting all SSH keys. Current time: 2026-05-04 11:25.
System environment:
- OS: Arch Linux
- Filesystem: btrfs
- Device: /dev/nvme0n1p2 mounted at /home
- User home: /home/me
Recovery path discovered:
- snapper -c home is configured, taking hourly automatic snapshots.
- Latest snapshot before deletion: ID 1555 (Mon 04 May 2026 11:00:02 AM CST), likely contains the complete .ssh.
- btrfs subvolume list /home | grep 1555 output:
ID 3372 gen 173251 top level 263 path .snapshots/1555/snapshot
ID 3373 gen 173252 top level 262 path @/.snapshots/1555/snapshot
Already attempted but failed:
sudo mount -o ro,subvol=.snapshots/1555/snapshot /dev/nvme0n1p2 /mnt/snap
# Error: mount: /mnt/snap: fsconfig() failed: No such file or directory.
Next steps (please continue in Kimi CLI):
1. Mount the snapshot using subvolid directly for ID 3372:
sudo mount -o ro,subvolid=3372 /dev/nvme0n1p2 /mnt/snap
2. If successful, check and copy:
ls -la /mnt/snap/home/me/.ssh/ # or /mnt/snap/me/.ssh/
cp -a /mnt/snap/home/me/.ssh/ ~/.ssh/
chmod 700 ~/.ssh && chmod 600 ~/.ssh/*
3. If subvolid=3372 also fails, try:
sudo mount -o ro,subvol=@home/.snapshots/1555/snapshot /dev/nvme0n1p2 /mnt/snap
# or
sudo mount -o ro,subvol=home/.snapshots/1555/snapshot /dev/nvme0n1p2 /mnt/snap
Important reminder: The user is still using the system normally. btrfs COW does not overwrite in place, but new writes will consume new blocks, so recovery should be completed as soon as possible.

Halfway through the conversation, I was still nervous, but when I saw that the host used the btrfs filesystem with snapshot capability and that a snapshot had been taken just an hour earlier, I immediately felt optimistic.

To speed up the process, I decided to have Kimi summarize the current situation and paste the context into the kimi-cli running on the host, so Kimi could act faster.

💬

Kimi CLI

3 rounds · 12 tool calls · btrfs + snapper snapshot recovery

→

In the end, recovery was successful! 👍