![给超级书呆子的更多解释](https://linux22.com/image/228858/%E7%BB%99%E8%B6%85%E7%BA%A7%E4%B9%A6%E5%91%86%E5%AD%90%E7%9A%84%E6%9B%B4%E5%A4%9A%E8%A7%A3%E9%87%8A.png)
到目前为止,我设法让内核和 systemd 在系统串行端口上启动时输出第一条日志消息。此外,在启动过程(几乎)完成后,journald 也会继续将其所有内容记录到串行中(例如,当任何服务记录某些内容时)。但是,在很短的时间内我在串行控制台上没有得到任何输出。它总是在 systemd 启动该单元后恰好发生dev-mqueue.mount
,并且日志记录最终继续显示该消息Console: switching to colour frame buffer device 240x67
。所以串行控制台错过了大约。 5 秒的关键日志消息。我所有的重试都是这样。我不确定为什么日志记录在此时继续。
我的问题是:我怎样才能在这 5 秒内继续将某些内容记录到串行控制台?
系统信息:(如果是系统特定问题):
- 系统:树莓派 4B(4 GB RAM)
- 操作系统:Debian GNU/Linux(2023.11.09 的镜像来自这里)
- 更远
apt update && apt upgrade
- 核心:
Linux rpi4-20231108 6.1.0-17-arm64 #1 SMP Debian 6.1.69-1 (2023-12-30) aarch64 GNU/Linux
- 从 SD 卡启动
- 更远
- 通过 GPIO 引脚使用 RPi4 的本机串行输出
- 串行输入适配器:CP2101(设置为 3.3 V 模式)通过 USB
picocom
在 Debian 桌面系统上使用
当前配置:(也许对其他在成功启动后只需要通过串行记录的人也有帮助)
为了启用 RPi 的本机串行控制台,enable_uart=1
必须进行设置/boot/firmware/config.txt
(大多数映像上的默认设置)。此外,内核需要知道它应该使用串行端口作为其控制台。在 RPi4 上,/dev/ttyS1
可通过引脚 8 和 10 调用一个(请参阅这里)。此外,systemd 和journald 也需要知道这一点。所以我做了以下事情:
在/etc/default/raspi-config
我设置CONSOLES="tty0 ttyS1,115200"
指令内核。我/etc/default/raspi-extra-cmdline
添加了配置systemd.journald.forward_to_console=1
来从 initramfs 指示日志。过了很长一段时间update-initramfs -u -k all
,/boot/firmware/cmdline.txt
现在包含:console=tty0 console=ttyS1,115200 systemd.journald.forward_to_console=1 root=LABEL=RASPIROOT rw fsck.repair=yes net.ifnames=0 rootwait
。
我为 Journald post-initramfs 创建了文件,/etc/systemd/journald.conf.d/forwardto-ttyS1.conf
内容如下:
[Journal]
ForwardToConsole=yes
TTYPath=/dev/ttyS1
MaxLevelConsole=info
最后,为了避免 getty 在串口上显示登录提示,我禁用了它对于这个特定的 tty通过跑步。systemctl mask [email protected]
到目前为止我尝试过的:
- 添加
systemd.log_target=console
和loglevel=7
到 cmdline:没有改变任何内容 - 添加
systemd.log_target=kmsg
到cmdline:没有改变任何内容 - 将波特率从 115200 更改为 9600:启动速度变慢,但 5 秒内仍然没有记录任何内容
完整的串行输出(asciinema 录音,也可用于115200和9600) 并发布 115200 和 9600 波特率运行的日志日志这里(注意:CPU 使用率可能较高, 读这里是元)。
语境:我想要此日志输出,因为我的一个定制设计的 Debian 映像在启动时崩溃,然后才能以读写方式安装其驱动器以最终将日志文件保存到其中。屏幕输出的刷新率太慢,无法显示最后的关键消息,这可能解释了它崩溃的原因。崩溃前不久的这些消息也不会记录到串行中,因此几乎不可能对其进行调试。
答案1
通过在浏览器中重播 asciinema 记录,我发现该问题并未记录在案。这是由 tmux 引起的“显示问题”。当在 tmux 会话之外查看 asciinema(或连接到串行)时,日志会继续并且看起来完整。但在 tmux 中,即使使用默认配置,它也会崩溃。 (以防万一:我在 xterm 和 KDE 的 Konsole 以及 bash 和 zsh 中测试了是否使用 tmux)
对于这里可能造成的干扰,我们深表歉意。以防万一,我会继续提出我的问题,以防其他人遇到同样的问题并得到我的回答的帮助,即使我认为这几乎是不可能的……
给超级书呆子的更多解释
出现此问题是因为打印了这一行未逃脱的(这就是 asciinema 保存该行的方式,开头的空格被截断):
Mounting \u001b[0;1;39mdev-mqueue.mount\u001b…POSIX Message Queue File System...\r\n
这转义字符 \u001b
被发送以调用终端仿真器中的操作(称为ANSI 转义序列。总而言之,例如\u001b[0;1;39m
“重置”( 0
)、“切换粗体/增加强度”( 1
) 和“默认前景色”( 39
)。之后的代码应该再次重置所有内容,但是 systemd-journald 断言原始行太长,因此它通过用椭圆 ( …
) 替换中间部分来截断原始行(这被解释为这里),只留下一个转义字符。
虽然大多数终端模拟器(包括 Linux 虚拟 tty)似乎能够很好地处理这个问题(最多不打印几个字符),但 tmux 继续解析转义码,导致 5 秒内 tmux 没有打印任何内容。