READ FIRST:
I've used
ChatGPT 5.4 Plus Extended Thinking to generate the text below the horizontal line from the OP's information. I hope it's useful by itself or by providing some sort of clue. I recommend
reading it in full before doing anything and
contrasting it with official sources. It
may contain errors.
This looks more like a Linuxulator/Vim runtime bug than a bad Vim config.
Upstream Vim has had the same
E1286: Could not set timeout class of failure on non-Linux Unix systems when its
timer_create() /
timer_settime() timeout backend misbehaves, and FreeBSD’s Linuxulator does implement those timer syscalls, so I would suspect an ABI/semantic mismatch rather than a missing syscall. See
linux(4)() for the compatibility layer itself.
Start with
vim --clean, then try
TERM=xterm-256color vim --clean and check
infocmp "$TERM" inside the jail to rule out a terminfo mismatch. The relevant references there are
infocmp(1)() and
terminfo(5)().
Warning: The next step traces a live process. It is low-risk, but it may expose command lines and terminal activity, so review the output before posting it publicly.
After that, trace it from the FreeBSD side with
truss(1)(), entering the jail with
jexec(8)(), and look for
timer_settime returning
EINVAL:
Code:
# truss -f -o /tmp/vim.truss jexec linuxjail sh -lc 'TERM=xterm-256color vim --clean </dev/tty >/dev/tty 2>&1'
# grep -E 'timer_(create|settime|delete)|EINVAL' /tmp/vim.truss
If that shows up, it is likely a Linuxulator bug or a case where Linux Vim needs to be built without the
timer_create() timeout path on FreeBSD. Also test in
emulators/linux_base-rl9, since Rocky Linux 9 is the packaged Linux base FreeBSD recommends. For the jail side of things,
jail(8)() is also worth keeping nearby.
