Scribbles for my memory

Your server has no GUI — just the bare console TTY — and you want to read and type Chinese on it. Installing fonts does nothing: the kernel console draws with a ~256-glyph VGA font baked into the driver, so CJK renders as diamonds no matter what you install. The fix has two halves: fbterm draws text onto the framebuffer itself (display), and fcitx5 with its fbterm frontend supplies the input method (typing). Here's the whole setup, including the three gotchas that cost me an evening.

Everything below was done on Ubuntu 24.04 (Mint 22.3) over SSH; the target machine is an old laptop used headless. Swap davidwei for your user.

Display: fbterm

sudo apt install fbterm fonts-wqy-microhei
sudo usermod -aG video $USER   # needed for /dev/fb0; re-login to apply

Log in on the physical console and run fbterm — it opens a full terminal on the framebuffer using fontconfig fonts. It cannot start over SSH (no framebuffer there, and you don't need it: your SSH client renders CJK itself).

Font gotcha #1: fbterm renders TrueType fonts well but tends to clip outline fonts at the right/bottom of the character cell, and --font-width/--font-height only change the cell metrics — they don't scale the glyphs. WenQuanYi Zen Hei Mono with an 8px cell worked for me where Noto CJK and default settings clipped. Put it in ~/.fbtermrc:

font-names=WenQuanYi Zen Hei Mono
font-size=16
font-width=8

An SSH .pub file is only the public half of a key pair. If it is missing, or if it is an old file that no longer matches the private key, regenerate it from the private key:

cp ~/.ssh/id_rsa.pub ~/.ssh/id_rsa.pub.backup 2>/dev/null || true
ssh-keygen -y -f ~/.ssh/id_rsa > ~/.ssh/id_rsa.pub
chmod 644 ~/.ssh/id_rsa.pub

ssh-keygen -y derives and prints the public key without exposing the private key. This also fixes errors such as:

identity_sign: private key ... contents do not match public

Verify the resulting public-key fingerprint with:

ssh-keygen -lf ~/.ssh/id_rsa.pub

I run a lid-closed laptop with two external monitors as a remote-access host. Remote desktop into it works perfectly, but the physical monitors sitting on my desk were pitch black. Cables fine, monitors powered, nothing in the logs.

The screens weren't broken — they were just DPMS-blanked, and nothing I did remotely could wake them:

$ sudo XAUTHORITY=/var/run/lightdm/root/:0 DISPLAY=:0 xset q
DPMS (Display Power Management Signaling):
  Standby: 600    Suspend: 0    Off: 900
  DPMS is Enabled
  Monitor is Off

One command brings them back:

sudo XAUTHORITY=/var/run/lightdm/root/:0 DISPLAY=:0 xset dpms force on

The reason it happened at all is the part worth remembering: xrdp gives you a second X server. The console session is Xorg :0; your RDP session is Xorg :10. They're separate processes with separate idle timers. Every keystroke and mouse move you make remotely resets the idle timer on :10 — and :0 never hears about any of it. So :0 sits there accumulating idle time forever and blanks on schedule, no matter how busy you look on the other display.

If the host is supposed to stay lit, disable blanking in the console user's session, not yours. On XFCE:

xfconf-query -c xfce4-power-manager -p /xfce4-power-manager/dpms-enabled -s false
for k in blank-on-ac blank-on-battery dpms-on-ac-sleep dpms-on-ac-off \
         dpms-on-battery-sleep dpms-on-battery-off; do
  xfconf-query -c xfce4-power-manager -p /xfce4-power-manager/$k -s 0
done

Those only take effect when xfce4-power-manager restarts, so log the console user out and back in. Note the settings persist to ~/.config/xfce4/xfconf/xfce-perchannel-xml/, not ~/.config/xfconf/ — I looked in the wrong place first.

One trap after all that: I logged back in, confirmed DPMS is Disabled, and declared victory too early. xset q still read timeout: 600. That's X's own built-in screensaver, a completely separate mechanism that the power manager's blank-on-ac=0 never touched. DPMS controls whether the monitor gets powered down; the X screensaver just paints over the screen while it stays on. From a chair three feet away the two are indistinguishable, and remote input can't dismiss either one. Kill both, from the console user's autostart:

xset s off s noblank -dpms

Check for timeout: 0 and DPMS is Disabled before you believe it.

On a Toshiba CB35-3340 (Bay Trail Chromebook running MX Linux / Debian 13 on MrChromebox firmware), the internal Intel Wireless 7260 disappears every few hours. The SSID list goes empty, every scan fails with -EIO, and toggling wifi does nothing. Only a reboot brought it back.

The giveaway is in the kernel log:

iwlwifi 0000:01:00.0: iwlwifi device memory mapped registers:
iwlwifi 0000:01:00.0: 00000000: ffffffff ffffffff ffffffff ffffffff
WARNING: ... __iwl_trans_pcie_grab_nic_access+0x14c/0x150 [iwlwifi]
iwlwifi 0000:01:00.0: Error sending STATISTICS_CMD: enqueue_hcmd failed: -5

MMIO reads returning all-ones means the device is off the bus, not merely confused. That is why modprobe -r iwlwifi && modprobe iwlwifi fails with Could not load the [0] uCode section — there is nothing there to load firmware into.

Two things fix the recovery path. First, let the driver admit the device is gone:

I wanted a second local account to read /home/davidw. The user was already in group davidw, and ls looked like it should just work:

$ ls -ld /home/davidw
drwxrwx---+ 272 davidw davidw 16384 Aug 19 16:56 /home/davidw

Group davidw has rwx, right there in the middle. Except every access failed:

$ sudo -u desk ls /home/davidw
ls: cannot open directory '/home/davidw': Permission denied

The + at the end of the mode string is the tell. Once a file has a POSIX ACL, the middle triad printed by ls stops being the group permission and becomes the ACL mask — a ceiling on what every named user, named group, and the owning group may get. The real group entry is only visible via getfacl:

$ getfacl -p /home/davidw
user::rwx
user:libvirt-qemu:--x
group::---          <-- the actual group permission: nothing
mask::rwx           <-- this is what ls printed as "rwx"
other::---

So the directory was 700 all along. Someone (libvirt, in my case) added user:libvirt-qemu:--x at some point, and adding any named entry forces a mask into existence — set wide enough to cover that entry. ls dutifully displayed the mask, and it looked exactly like group access.

The mask cuts both ways: it can also revoke access that getfacl seems to grant. An entry of user:desk:rwx under mask::r-x yields read-only — getfacl marks it for you:

user:desk:rwx                   #effective:r-x

Two consequences worth internalizing. First, on any path with a +, getfacl is the only source of truth; don't reason from ls. Second, chmod g+rx on an ACL'd file doesn't set the group permission — it sets the mask, which is almost never what you meant. Grant access with a named entry instead, which is narrower and trivially reversible:

sudo setfacl -m u:desk:rwx /home/davidw   # grant
sudo setfacl -x u:desk     /home/davidw   # revert

One unrelated snag if you're doing this to share a checkout: git will refuse the now-reachable repos with detected dubious ownership in repository, because they're owned by a different uid. Fix it per-user, not with sudo:

sudo -u desk git config --global --add safe.directory '*'