本文面向已经“听说过 Conan”的同学，帮你把“能跑起来”到“能上线”的每一步都踩实。官方文档很香，但太长；这篇博客很干，但够短。

官网指路
Conan 官网：https://conan.io/
可用包速查：https://conan.io/center
官方完整文档（建议完整阅读一遍）：https://docs.conan.io/2/index.html

1. 30 秒完成环境初始化

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# 1. 装 Conan（Python3 自备）
pip3 install "conan>=2.17.0"

# 2. 生成默认 profile（只跑一次）
conan profile detect --force

# 3. 拉依赖、编缺失
conan install . --build=missing -s build_type=Release

# 4. 本地打包（可跳过）
conan create . --user=myname

# 5. 推到私有仓库
conan upload ffmpeg/5.0 -r myrepo

2. 先把项目摆成“Conan 喜欢的样子”

以 CMake 工程为例，推荐目录：

1
2
3
4

conan-fmt-demo/
├── conanfile.txt       # 或 conanfile.py，二选一
├── CMakeLists.txt
└── main.cpp

最小可用 conanfile.txt

1
2
3
4
5
6

[requires]
fmt/10.1.1

[generators]
CMakeDeps
CMakeToolchain

说明

• fmt/10.1.1：告诉 Conan“我要这个版本”。
• CMakeDeps + CMakeToolchain：自动生成 fmt-config.cmake 和 toolchain 文件，CMake 一句 find_package(fmt) 就能用。

想知道还有哪些版本？两条路：

1
2

conan search fmt                  # 本地+远端一起搜
# 或者打开浏览器：https://conan.io/center

3. 一条命令安装全部依赖

1

conan install . --build=missing -s build_type=Release

• --build=missing：远端没有现成二进制就本地现编。
• 成功后会在 build/Release/generators/ 里吐出 conan_toolchain.cmake。

4. 编译项目：两种姿势，任选

姿势 A：经典手写

1
2
3
4
5

cmake -G "Unix Makefiles" \
      -DCMAKE_TOOLCHAIN_FILE=build/Release/generators/conan_toolchain.cmake \
      -DCMAKE_BUILD_TYPE=Release \
      -S . -B build/Release
cmake --build build/Release -j$(nproc)

姿势 B：CMake ≥3.19 的 preset（真香）

1
2

cmake --preset conan-default
cmake --build --preset conan-release

老版本 CMake 想用 preset？官方教你曲线救国：https://docs.conan.io/2/tutorial/consuming_packages/use_tools_as_conan_packages.html

5. 踩坑现场：缺失系统库怎么办？

典型报错：

1

ERROR: vaapi/system … No package 'libva' found

原因：vaapi/system 这类 system 包不会帮你编 libva，它假设系统里已经装好。
解决（Ubuntu/Debian 演示）：

1
2
3
4
5
6
7
8
9
10

# 1. 装 apt-file 并更新索引
sudo apt update && sudo apt install apt-file
sudo apt-file update

# 2. 找到提供 libva.pc 的包
apt-file search libva.pc
# 输出：libva-dev: /usr/lib/.../libva.pc

# 3. 装它
sudo apt install libva-dev

如果缺失的不止一个，可以偷懒用脚本：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77

#!/usr/bin/env bash
# 暴力补齐任意 system 包缺失的 .pc 系统依赖
# Ubuntu/Debian 专用

set -euo pipefail

# ======== 用户可编辑区域 ========
SYSTEM_PKGS=(
  xorg/system
  vaapi/system
  vdpau/system
  
  # 继续往这里加其他 system 包
)
# ================================

echo "=== 开始暴力补齐 system 包缺失依赖 ==="

# 确保 apt-file 存在且索引最新
if ! command -v apt-file &>/dev/null; then
  sudo apt-get update && sudo apt-get install -y apt-file
  sudo apt-file update
fi

declare -A SEEN  # 记录已处理过的 .pc，避免死循环

pip3 install conan>=2.17.0

echo "检测本地编译工具"
conan profile detect --force

for sys_pkg in "${SYSTEM_PKGS[@]}"; do
  echo "🔍 检查 $sys_pkg ..."
  while :; do
    OUTPUT=$(mktemp)
    trap 'rm -f "$OUTPUT"' EXIT

    set +e
    conan install --requires="$sys_pkg" \
        -c tools.system.package_manager:mode=check \
        -c tools.system.package_manager:sudo=False \
        >"$OUTPUT" 2>&1
    RET=$?
    set -e

    # 提取所有缺失的 .pc 名
    mapfile -t MISSING < <(grep -oP "No package '\K[^']+" "$OUTPUT" | sort -u)

    [[ ${#MISSING[@]} -eq 0 ]] && { echo "✅ $sys_pkg 已满足"; break; }

    for pc in "${MISSING[@]}"; do
      [[ -n "${SEEN[$pc]:-}" ]] && continue
      SEEN[$pc]=1

      echo "🔍 查找缺失 .pc：$pc.pc"
      PKG=$(apt-file search "$pc.pc" | awk -F: '{print $1}' | sort -u)

      case $(echo "$PKG" | wc -l) in
        0)
          echo "⚠️  未找到包含 $pc.pc 的包，跳过"
          continue
          ;;
        1)
          echo "📦 安装 $PKG"
          sudo apt-get install -y "$PKG"
          ;;
        *)
          echo "❓ 多个候选包：$PKG"
          echo "   请手动处理：sudo apt install <包名>"
          ;;
      esac
    done
  done
done

echo "=== 所有 system 包依赖已补齐 ==="

脚本会自动扫描 xorg/system、vaapi/system、vdpau/system 等常见 system 包，缺啥补啥，直到全部绿灯。

6. 私有仓库：又快又稳

6.1 添加仓库

1

conan remote add myrepo https://your-private-repo.com --index=0

--index=0 把私有仓库置顶，优先级最高。
登录（仅上传时需要）：

1

conan remote login myrepo <user> -p <pass>

6.2 查看 / 调整顺序

1
2
3

conan remote list
conan remote remove myrepo          # 先删
conan remote add myrepo <url> --index=0

7. 把包推上去

场景 A：官方包直接迁到私有

1
2

conan install --requires=ffmpeg/5.0@ --build=missing
conan upload ffmpeg/5.0 -r myrepo --confirm

场景 B：自研项目

1
2

conan create . --user=mychannel
conan upload mylib/1.0@mychannel -r myrepo --confirm

8. 命令小抄（建议收藏）

9. 结语

• 装好 Conan → profile detect → conan install，项目就跑起来了。
• 缺系统库 → apt-file 搜 -dev 包，或者一键脚本。
• 私有仓库 → remote add --index=0 置顶，上传一条命令搞定。

祝你编译愉快，一路无坑！

注意：本指南默认您已掌握C语言基础和Linux命令行操作。若不会使用gcc，建议先学习《C语言：从入门到内存泄漏》。

一、FFmpeg简介：音视频界的瑞士军刀

FFmpeg集成了600+编解码器和100+封装格式的超级工具链：

核心组件功能：

• libavcodec：编解码器大本营（H.264/HEVC/AAC/MP3）
• libavformat：封装/解封装指挥官（MP4/FLV/TS等）
• libavdevice：硬件设备特工（摄像头/麦克风/屏幕捕获）
• libswscale：像素魔术师（YUV↔RGB转换）
• libavutil：工具百宝箱（哈希/数学/日志）

官网金句：FFmpeg is the future, but you can type ffmpeg today

下面用「一句话 + 命令/思路」的形式，把 FFmpeg 能做的「日常必备」到「高阶黑科技」一次性列给你。直接复制命令即可跑；带 ‼ 的表示进阶/易踩坑。

1.常用操作（90% 场景覆盖）

2. 高级玩法（性能/画质/实时向）

3.黑科技天花板（需要二次开发/脚本）

4.速查表

一句话总结：
从「剪个 10 秒小视频」到「4K60 帧低延迟直播」，FFmpeg 一条命令行就能搞定；再往上，用脚本/代码把 FFmpeg 当「底层 GPU 音视频引擎」用，天花板几乎没有。

二、核心数据结构：四大天王

1. AVFormatContext - 容器指挥官

1
2

AVFormatContext* fmt_ctx = NULL;
avformat_alloc_output_context2(&fmt_ctx, NULL, "mp4", "output.mp4");

职责：

• 管理文件/流的封装信息
• 关键字段：
  • nb_streams：流数量
  • pb：I/O上下文指针

类比：快递分拣中心，管理所有包裹（音视频流）

2. AVCodecContext - 编解码大脑

1
2
3
4

AVCodec* codec = avcodec_find_encoder(AV_CODEC_ID_H264);
AVCodecContext* codec_ctx = avcodec_alloc_context3(codec);
codec_ctx->bit_rate = 4000000;  // 4Mbps
codec_ctx->framerate = (AVRational){30, 1}; // 30FPS

避坑指南：未设置帧率会导致视频加速播放

3. AVPacket - 压缩数据包

1
2
3
4
5

AVPacket* pkt = av_packet_alloc();
while (av_read_frame(fmt_ctx, pkt) >= 0) {
    // 处理H.264 NAL单元
    av_packet_unref(pkt); // 关键！防内存泄漏
}

特点：

• 携带编码后的音视频数据
• 使用引用计数管理内存

4. AVFrame - 原始数据帧

1
2
3

AVFrame* frame = av_frame_alloc();
frame->format = AV_PIX_FMT_YUV420P;
av_frame_get_buffer(frame, 0); // 显式分配内存

数据存储：

• 视频：data[0](Y), data[1](U), data[2](V)
• 音频：data[0](左声道), data[1](右声道)

冷知识：人眼对亮度敏感度是色度的6倍，故YUV420P更省带宽！

三、核心API详解

1.设备操作三剑客

2.编解码关键流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

// 查找编解码器
AVCodec *codec = avcodec_find_encoder(AV_CODEC_ID_H264);

// 创建编解码上下文
AVCodecContext *ctx = avcodec_alloc_context3(codec);
ctx->width = 1920; 
ctx->height = 1080;
ctx->time_base = (AVRational){1, 30}; // 必须设置！

// 打开编解码器
if (avcodec_open2(ctx, codec, NULL) < 0) {
    char err_buf[256];
    av_strerror(ret, err_buf, sizeof(err_buf)); // 错误解析
}

// 编码循环
avcodec_send_frame(ctx, frame); // 送入原始帧
while (avcodec_receive_packet(ctx, pkt) == 0) {
    // 处理编码包
}

3.数据转换核心

四、深入PulseAudio

1.核心架构

2.设备类型详解

3.实战场景

1
2
3
4
5
6

// 录制麦克风
avformat_open_input(&ctx, "default", av_find_input_format("pulse"), NULL);

// 录制系统声音（关键！）
avformat_open_input(&ctx, "alsa_output.pci-0000_00_1f.3.analog-stereo.monitor", 
                    av_find_input_format("pulse"), NULL);

系统救星：pulseaudio -k && pulseaudio --start 解决90%音频问题

五、音视频录制实战

1. 摄像头录制（Linux V4L2）

1
2
3
4
5
6
7
8
9
10
11
12
13
14

avdevice_register_all();
AVInputFormat* input_fmt = av_find_input_format("v4l2");
avformat_open_input(&cam_ctx, "/dev/video0", input_fmt, NULL);

// 转码决策树
if (codecpar->codec_id == AV_CODEC_ID_MJPEG) {
    // 直接流复制
    avcodec_parameters_copy(out_stream->codecpar, codecpar);
} else {
    // 完整转码流水线
    AVCodec *decoder = avcodec_find_decoder(codecpar->codec_id);
    AVCodec *encoder = avcodec_find_encoder(AV_CODEC_ID_H264);
    // ...构建解码->处理->编码流水线
}

2. 麦克风录制（PulseAudio）

1
2
3
4
5
6
7

SwrContext* swr = swr_alloc_set_opts(NULL, 
                                     AV_CH_LAYOUT_STEREO, AV_SAMPLE_FMT_FLTP, 44100, // 输出格式
                                     src_ch_layout, src_sample_fmt, src_sample_rate, // 输入格式
                                     0, NULL);
swr_init(swr); // 必须初始化！

// 音频冷知识：AAC编码器强制要求浮点平面格式(AV_SAMPLE_FMT_FLTP)

3. 音视频同步（核心！）

1
2
3
4
5
6
7
8
9
10

// 统一时间基准（微秒级精度）
int64_t video_pts = av_rescale_q(frame->pts, video_time_base, AV_TIME_BASE_Q);
int64_t audio_pts = av_rescale_q(samples->pts, audio_time_base, AV_TIME_BASE_Q);

// 同步写入决策
if (video_pts <= audio_pts) {
    av_interleaved_write_frame(fmt_ctx, video_pkt); // 优先写视频
} else {
    av_interleaved_write_frame(fmt_ctx, audio_pkt); // 优先写音频
}

同步要诀：使用av_rescale_q而非手动计算，避免精度丢失

4.音频录制+重采样实战

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

// 1. 打开麦克风
avformat_open_input(&audio_fmt_ctx, "default", av_find_input_format("pulse"), NULL);

// 2. 创建音频编码器
AVCodec *audio_codec = avcodec_find_encoder(AV_CODEC_ID_AAC);
AVCodecContext *a_codec_ctx = avcodec_alloc_context3(audio_codec);
a_codec_ctx->sample_rate = 44100;
a_codec_ctx->channel_layout = AV_CH_LAYOUT_STEREO;

// 3. 重采样设置（解决格式不匹配）
SwrContext *swr = swr_alloc();
swr_alloc_set_opts2(&swr,
                    &a_codec_ctx->ch_layout, a_codec_ctx->sample_fmt, a_codec_ctx->sample_rate,
                    &in_ch_layout, in_sample_fmt, in_sample_rate,
                    0, NULL);
swr_init(swr);

// 4. 处理循环
while (1) {
    av_read_frame(audio_fmt_ctx, pkt);
    swr_convert(swr, out_samples, out_sample_count, 
                (const uint8_t**)pkt->data, pkt->size/4);
    // 编码处理...
}

六、高级开发技巧

1. 性能优化三连击

1
2
3
4
5
6
7
8
9

// CUDA硬件加速（5x+速度提升）
ctx->hw_device_ctx = av_hwdevice_ctx_alloc(AV_HWDEVICE_TYPE_CUDA);

// 多线程编码（榨干CPU）
ctx->thread_count = 16; 
ctx->thread_type = FF_THREAD_FRAME;

// 零拷贝优化
av_frame_make_writable(frame);  // 避免隐式拷贝

2. 调试神器

3.必备诊断命令

1
2
3
4
5
6
7
8

# 检查设备支持
ffmpeg -f pulse -list_devices true -i dummy

# 测试摄像头
ffplay -f v4l2 -video_size 1280x720 /dev/video0

# 分析输出文件
ffprobe -show_streams output.mp4

4.经典错误表

5. 常见问题急救包

问题：视频花屏
原因：

• 关键帧丢失（I帧被狗吃了）
• PTS时间戳不连续
  解决方案：

1
2
3
4
5
6

// 强制插入关键帧
frame->key_frame = 1;
frame->pict_type = AV_PICTURE_TYPE_I;

// 修复时间戳（避免跳跃）
frame->pts = last_pts + av_rescale_q(1, time_base, stream_time_base);

6. 跨平台兼容方案

注意事项

1. Linux (PulseAudio)：
   • 需要安装libpulse-dev
   • 设备名称为default或特定设备名称
2. Windows (DirectShow)：
   • 修改设备名称为audio=麦克风名称
   • 可能需要先列出可用设备
3. macOS (AVFoundation)：
   • 修改设备名称为:0或特定设备索引
   • 输入格式应为avfoundation

七、终极Q&A

1. 为什么摄像头录制中同时需要解码器和编码器

• 摄像头输出是压缩数据（如MJPEG）
• 目标格式需要重新编码（如H.264）
• 转码流水线：MJPEG -> YUV -> H.264

2.AVPacket 和 AVFrame 之间的关系

1. 解码过程：
   • 从多媒体文件中读取 AVPacket。
   • 使用解码器将 AVPacket 中的压缩数据解码到 AVFrame 中。
   • 处理（例如，显示或进一步处理）AVFrame 中的未压缩数据。
2. 编码过程：
   • 从原始数据（例如，摄像头捕获的视频帧或麦克风捕获的音频样本）创建 AVFrame。
   • 使用编码器将 AVFrame 中的未压缩数据编码到 AVPacket 中。
   • 将 AVPacket 写入到多媒体文件中。
3. 转换过程：
   • 读取 AVPacket，解码到 AVFrame。
   • 对 AVFrame 进行格式转换或处理。
   • 将处理后的 AVFrame 重新编码到 AVPacket。
   • 写入新的 AVPacket 到输出文件。

通过这种方式，AVPacket 和 AVFrame 在 FFmpeg 的多媒体处理流程中起到了桥梁的作用，确保数据能够在不同的处理阶段之间正确传递和转换。

3.一些性能优化思路(待验证)

1.从DRM（Direct Rendering Manager）直接获取帧数据可以显著提高屏幕捕获效率，避免通过 X11 的额外开销—缺点是通过 drm 需要 root 权限，仅支持 linux，实现起来较为复杂。

2.优化转码算法,录屏耗时一般都在捕获和转码阶段，参考开源录屏应用 simplescreenrecorder(ssr) 的算法实现，可有效较少转码耗时—转码本质上是数学运算，一些 cpu 指令集对特定数学运算也有较好的加速效果。

3.RGB 到 YUV 的转换可以使用更高效的 SIMD 指令优化

4.录制音频时怎么查找系统的默认音频设备

1
2
3

$ pactl list sources short
0alsa_output.pci-0000_00_1f.3.analog-stereo.monitormodule-alsa-card.cs16le 2ch 44100HzSUSPENDED
1alsa_input.pci-0000_00_1f.3.analog-stereomodule-alsa-card.cs16le 2ch 44100HzSUSPENDED

选 **带 ****monitor** 的那一行即可。

也可以到操作系统的设置中查看输出设备是否一致，命令可能会查询到多个输出设备

5.官方示例

以 linux 操作系统为例，如果是基于 Debian 的发行版，运行以下命令安装示例：

1

sudo apt install ffmpeg-doc

6.录制的视频有时候会花屏

1.帧间预测依赖链断裂-视频编码基于 I帧(关键帧)、P帧(前向预测) 和 B帧(双向预测)(见附2,先了解下 I P B 帧的概念)

2.时间戳不连续，也就是帧的 pts

7.视频播放速度是怎么控制的

播放行为本质上是：

1. 以PTS为绝对时间基准
2. 以预设帧率为初始化参考
3. 通过动态同步算法实时调整

八、结语：通往音视频大师之路

当你：

1. 能30分钟写出录制程序 → 青铜
2. 搞定音视频同步 → 白银
3. 实现4K60帧编码 → 黄金
4. 修复花屏/卡顿问题 → 王者
5. 给FFmpeg提交补丁 → 封神

FFmpeg不是一天学会的，每个崩溃的程序都让你离大师更近一步。

附0：ffmpeg重点接口

1.编解码相关接口

2.格式上下文相关接口

3.图像转换相关接口

4.其他重要接口

5.高级功能

附1：FFmpeg编解码器与封装格式大全

温馨提示：本清单仅展示FFmpeg支持的部分代表性格式（完整列表超600+），建议保存备用。当有人质疑FFmpeg能力时，请优雅地甩出此表😎

1.视频编解码器

2.音频编解码器

3.视频容器格式

4.音频容器格式

5.特殊格式

冷知识：FFmpeg甚至支持解析 .gif动图 和 .ico图标文件，堪称格式界的”瑞士军刀”

6.结语：

当看到如此庞大的格式支持列表时，请记住FFmpeg作者的名言：

“我们不是选择支持什么格式，而是选择不支持什么格式——因为实在太少了”

（注：完整列表可通过 ffmpeg -codecs 和 ffmpeg -formats 查看）

附2：视频编码中的 I P B帧

庆幸的是，在 ffmpeg 的音视频编程中，我们只需要知道 IPB 帧 的概念即可，ffmpeg会自动处理这些帧。

1.I帧（Intra-coded Frame，关键帧）

• 定义：完全独立编码的帧，不依赖其他帧即可解码。类似静态JPEG图像，仅使用帧内压缩（空间冗余压缩）。
• 特点：
  • 包含完整图像数据，解码时无需参考其他帧。
  • 压缩率最低（因无时间冗余利用），但可作为随机访问点（如快进、seek操作）。
  • 通常定期插入（如每秒1次），用于错误恢复（若P/B帧丢失，可从下一个I帧重新开始解码）。
• 应用场景：
  • 视频开头（首个帧必须是I帧）。
  • 场景切换时（新旧场景无关联，需重新生成完整帧）。
  • 广播流媒体（支持随机换台）。

2.P帧（Predicted Frame，前向预测帧）

• 定义：通过前向预测编码的帧，仅参考过去的I帧或P帧。
• 工作原理：
  • 基于运动估计（Motion Estimation），在参考帧中查找相似块（宏块），记录运动矢量（位移数据）和残差（预测误差）。
  • 例如：若背景静止，P帧只需编码移动物体的变化，大幅节省数据量。
• 特点：
  • 压缩率高于I帧（利用时间冗余），但解码依赖参考帧（若参考帧丢失会出错）。
  • 无法处理未来帧的遮挡关系（如物体从后方出现）。
• 应用场景：
  • 大多数连续运动的视频片段（如人物行走）。

3.B帧（Bidirectional Frame，双向预测帧）

• 定义：通过双向预测编码的帧，可同时参考过去和未来的I/P帧。
• 工作原理：
  • 综合前后参考帧进行插值预测。例如：若物体从左侧移动到右侧，B帧可结合前一帧（物体在左）和后一帧（物体在右）生成中间状态。
  • 支持直接模式（Direct Mode）：复用运动矢量，进一步减少数据量。
• 特点：
  • 压缩率最高（因时间冗余利用最充分），但引入编码延迟（需等待未来帧到达）。
  • 解码顺序与显示顺序可能不同（如先解码未来的P帧再解码B帧）。
• 应用场景：
  • 非实时场景（如点播视频、蓝光光盘）。
  • 高速运动场景（如体育赛事），通过双向预测减少残差数据。

4.三者的协同工作流程

以典型的 IBBPBBP… GOP（Group of Pictures）结构为例：

1. 解码顺序：I₀ → P₃ → B₁ → B₂ → P₆ → B₄ → B₅…
2. 显示顺序：I₀ → B₁ → B₂ → P₃ → B₄ → B₅ → P₆…
   • 解码器会缓存未来帧（如P₃），以便解码B₁/B₂时使用。

5.关键对比表

6.实际应用中的权衡

• 直播场景：通常减少B帧（或不用）以降低延迟（如RTMP协议常用IPPP结构）。
• 存储场景：大量使用B帧（如H.264的IBBBP... 结构），节省50%以上码率。
• 错误恢复：若P/B帧丢失，解码器会跳过到下一个I帧（可能出现短暂花屏）。

理解这三类帧的机制，对优化编码参数（如GOP长度、B帧数量）和排查播放问题（如花屏、卡顿）至关重要。

网络上也有比较好的文章可以参考：https://zhuanlan.zhihu.com/p/614236013

附3： YUV 格式与 RGB 图像格式介绍

在YUV文件中，Y、U、V分别代表亮度（Luma）和两个色差（Chroma）分量。与一张真正的RGB图片相比，它们的对应关系如下：

1.Y (Luma) - 亮度分量

• 作用：表示图像的黑白（灰度）信息，即每个像素的明暗程度。
• 类比：相当于将彩色照片去色后的灰度图，单独看Y分量时，是一张完整的黑白图片。
• 示例：一张彩色照片中的白色区域Y值高，黑色区域Y值低。

2.U/V (Chroma) - 色差分量

• 作用：表示颜色信息（色调和饱和度），通过两个色差信号（U和V）描述颜色与亮度的差异。
  • U (Cb)：蓝色与亮度的差值（B - Y）。
  • V (Cr)：红色与亮度的差值（R - Y）。
• 类比：相当于给灰度图“上色”的指令。单独看U或V分量时，是模糊的色度图（类似低分辨率的彩色蒙版）。
• 示例：红色区域V值高，蓝色区域U值高，绿色通过U和V的组合间接表示。

3.与RGB图片的对比

4.实际存储示例（YUV420格式）

• Y：每像素一个值（分辨率=原图）。
• U/V：每2x2像素共享一个U和V值（分辨率=原图的1/4）。
• 效果：人眼对亮度更敏感，这种压缩对视觉影响小。

5.总结

• Y：黑白细节，决定清晰度。
• U/V：颜色信息，决定色调。
• 关系：YUV通过牺牲部分色度精度，用更小体积存储接近RGB的视觉内容。

注：以下是一个将 rgb 的图像格式转换为 yuv420 图像格式的 demo：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81

/*
 * gcc make_yuv.c -o make_yuv
 * ./make_yuv
 * 生成文件: yellow_red_64x64.yuv
 * @note 用于了解 yuv420p 文件格式，以及和 rgb 图像元素的对应关系
 * @note: ffplay -f rawvideo -pixel_format yuv420p -video_size 64x64 yellow_red_64x64.yuv 可查看 yuv 图片内容
 */

#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>

#define W 64
#define H 64
#define HALF_W (W/2)
#define HALF_H (H/2)

/* 标准 BT.601 转换系数 */
static inline uint8_t RGB_TO_Y(uint8_t r, uint8_t g, uint8_t b)
{
    return (uint8_t)( ( 66 * r + 129 * g +  25 * b + 128) >> 8) + 16;
}
static inline uint8_t RGB_TO_U(uint8_t r, uint8_t g, uint8_t b)
{
    return (uint8_t)( (-38 * r -  74 * g + 112 * b + 128) >> 8) + 128;
}
static inline uint8_t RGB_TO_V(uint8_t r, uint8_t g, uint8_t b)
{
    return (uint8_t)( (112 * r -  94 * g -  18 * b + 128) >> 8) + 128;
}

int main(void)
{
    /* 申请 Y,U,V 三个平面 */
    uint8_t *y = malloc(W * H);
    uint8_t *u = malloc(HALF_W * HALF_H);
    uint8_t *v = malloc(HALF_W * HALF_H);

    /* 1. 填充 Y */
    for (int row = 0; row < H; ++row) {
        for (int col = 0; col < W; ++col) {
            if (col < W/2) {               /* 左侧黄色 */
                y[row * W + col] = RGB_TO_Y(255, 255, 0);
            } else {                       /* 右侧红色 */
                y[row * W + col] = RGB_TO_Y(255, 0,   0);
            }
        }
    }

    /* 2. 填充 U/V（2×2 平均后下采样） */
    for (int row = 0; row < HALF_H; ++row) {
        for (int col = 0; col < HALF_W; ++col) {
            int even_row = row * 2;
            int even_col = col * 2;

            /* 取 2×2 块左上角像素的颜色做近似 */
            uint8_t r, g, b;
            if (even_col < W/2) {          /* 黄色 */
                r = 255; g = 255; b = 0;
            } else {                       /* 红色 */
                r = 255; g = 0;   b = 0;
            }

            u[row * HALF_W + col] = RGB_TO_U(r, g, b);
            v[row * HALF_W + col] = RGB_TO_V(r, g, b);
        }
    }

    /* 3. 写入文件 */
    FILE *fp = fopen("yellow_red_64x64.yuv", "wb");
    if (!fp) { perror("fopen"); return 1; }

    fwrite(y, 1, W * H, fp);
    fwrite(u, 1, HALF_W * HALF_H, fp);
    fwrite(v, 1, HALF_W * HALF_H, fp);
    fclose(fp);

    free(y); free(u); free(v);
    puts("yellow_red_64x64.yuv 已生成");
    return 0;
}

附4：PulseAudio 中的 Sink 和 Source 详解

在 PulseAudio 音频系统中，sink 和 source 是两个核心概念，它们代表了音频流的两个不同方向：

1.Sink（接收器）

• 定义：音频输出设备（播放设备）
• 功能：接收音频流并将其播放出来
• 对应设备：
  • 扬声器（内置或外接）
  • 耳机
  • HDMI/DisplayPort 音频输出
  • 蓝牙音频设备
• 命令：

1

pacmd list-sinks  # 列出所有可用的音频输出设备

• 示例输出：

1

name: <alsa_output.pci-0000_00_1f.3.analog-stereo>

2.Source（源）

• 定义：音频输入设备（录制设备）
• 功能：捕获音频流并将其发送到系统
• 对应设备：
  • 麦克风（内置或外接）
  • 线路输入
  • 蓝牙麦克风
  • 系统音频捕获（监视器）
• 命令：

1

pacmd list-sources  # 列出所有可用的音频输入设备

• 示例输出：

1

name: <alsa_input.pci-0000_00_1f.3.analog-stereo>

3.特殊类型：监视器（Monitor）

在 PulseAudio 中，还有一个重要的概念是监视器（Monitor）：

• 定义：一种特殊的 source（输入设备）
• 功能：捕获从 sink（输出设备）播放的音频
• 命名规则：<sink名称>.monitor
• 用途：
  • 录制系统声音（如音乐、通知音）
  • 创建虚拟音频设备
• 示例：

1

name: <alsa_output.pci-0000_00_1f.3.analog-stereo.monitor>

4.实际应用场景

1. 设置默认输出设备（sink）

1

pacmd set-default-sink alsa_output.pci-0000_00_1f.3.analog-stereo

2. 设置默认输入设备（source）

1

pacmd set-default-source alsa_input.pci-0000_00_1f.3.analog-stereo

3. 录制系统声音（使用监视器）

1

ffmpeg -f pulse -i alsa_output.pci-0000_00_1f.3.analog-stereo.monitor output.wav

4. 查看所有设备状态

1
2
3
4
5

# 完整输出设备列表
pacmd list-sinks

# 完整输入设备列表
pacmd list-sources

5.常见问题解决

如果您遇到 未指定有效的命令 错误，可能是以下原因：

1. PulseAudio 未运行：

1

pulseaudio --start

2. 命令语法错误：

1
2
3

# 正确命令
pactl get-default-sink
pactl get-default-source

3. 权限问题：

1

sudo usermod -aG audio $USER

4. PulseAudio 配置问题：

1
2
3

rm ~/.config/pulse/*
pulseaudio -k
pulseaudio --start

理解 sink 和 source 的概念对于在 Linux 系统上管理音频设备至关重要，特别是在开发音频应用程序或进行多媒体录制时。

附5：简单 demo

在学习 ffmpeg 的过程中，我尽可能将一些简单的功能抽取了单独的 demo。See：https://github.com/ssk-wh/ffmpeg-demo

注：主要以UOS举例，其他发行版步骤类似，只是细节可能有些不同。

引导文件丢失

如果用户的引导文件（如/boot/grub/grub.cfg文件）被损坏或删除，系统将无法正常启动。启动系统时可能出现图中的场景：

接下来，我将针对这一场景介绍相应的解决办法：

在 GRUB 的终端交互界面中，使用 ls 命令查看当前块设备信息，并找到用户存放 boot 数据的分区位置（由于内核和 initrd 均位于 boot 目录下，后续步骤中需要用到该分区信息）。例如，若 boot 数据位于 (hd0,gpt3)，则通过输入 set root=(hd0,gpt3) 命令来指定该设备。

接下来，你需要获取一份与当前系统版本相同的grub.cfg配置文件，并参考其内容，依次执行其中的GRUB命令。通常情况下，这些命令主要包括加载内核和initrd。以下是其他机器的/boot/grub/grub.cfg文件内容，供你参考。

重点关注linux和initrd这两行内容。linux命令用于指定引导的内核及其参数，不同机器的内核参数会有所不同。其中，root和ostree参数尤为重要（这里针对的是UOS磐石镜像，其他发行版一般只需指定root参数即可）。

在UOS磐石镜像中，ostree参数指向系统部署的一个特定目录，通常位于/persistent/ostree/data/[commit]/checkout。你可以先通过ls命令查看当前系统中实际的目录路径（幸好可以补全，否则手动输入ostree参数可能会让人感到头疼……-_ -）。

接下来，根据示例grub.cfg的内容，使用linux命令指定root=/dev/sda3和ostree=...，注意在ostree参数中需去掉实际目录前的/persistent路径前缀。然后，通过initrd命令加载实际的initrd文件。完成后，使用boot命令开始加载当前设置的引导信息。

如果输入无误，此时即可进入系统。但当前系统的/boot/grub/grub.cfg仍处于损坏状态。进入系统后，你可以通过运行grub-mkconfig -o /boot/grub/grub.cfg或update-grub命令来重建引导信息。之后，系统再次启动时，便无需再手动执行上述命令了。

至此，引导修复结束。

启动后光标一直闪烁

在grub引导项点击确认后,之后系统一直处于光标闪动的状态.

这种情况，根据经验推测，可能是 /boot 目录下的 initrd 文件未被正确找到或加载。首先应检查 GRUB 引导参数中 initrd 相关配置是否存在错误。在 GRUB 菜单中，按 e 键进入引导参数编辑页面，仔细查看以 initrd 开头的那一行内容，确认其路径和文件名是否准确无误。initrd 是一个临时的根文件系统，内核在启动后会将其挂载，它在内核启动的早期阶段提供必要的驱动程序和工具，以便内核能够顺利访问实际的根文件系统。

针对此类问abbrlink题，可以在 GRUB 参数编辑页面中，在以 linux 开头的那一行末尾添加 "debug" 参数。若内核因找不到 initrd 而触发 panic，其报错内容大致如下：`

上图可以明显看到rootfs 无法挂载,这种情况,只需分析为何找不到 initrd 的原因即可.

启动后卡住

有时候系统启动后会卡在某个服务上，屏幕上只显示系统 logo 闪烁，而看不到相关日志。这种情况下，可以删除 GRUB 参数中的 quiet splash，以便查看详细的启动日志.

如果希望进一步查看内核日志，可以将 loglevel 参数的值设置为最高级别（7，0 是最低级别）。在 GRUB 菜单中，按 e 键进入引导参数编辑页面，然后在 linux 开头的行中添加 loglevel=7 参数，最后按 F10 键加载引导信息，即可看到更详细的日志信息。

启动后系统进入emergency mode

系统启动后进入了紧急模式怎么办

按下 Ctrl + Alt + Del 组合键重启系统。在 GRUB 引导菜单页面中，选择当前的引导项，然后按下 e 键进入 GRUB 编辑模式。在以 linux 开头的行的末尾，添加 init=/bin/bash 参数。

接下来，按下 F10 键以加载引导程序，使系统启动后直接进入 bash 环境，而不是执行默认的 /sbin/init 进程。这样可以为我们后续的调试工作提供便利。

进入此阶段后，我们需要深入分析导致系统进入紧急模式（Emergency Mode）的原因。实际上，紧急模式是由 systemd 提供的一个特殊服务。

在 systemd 的启动流程中，如果某些关键服务启动失败，系统会触发 emergency.target，进而执行 emergency.service，最终进入紧急模式。以下是可能导致系统进入紧急模式的服务故障情况：

接下来，我们将深入分析系统的运行日志，以查找是否有相关服务的报错信息。通过执行 **journalctl** 命令，可以查询 systemd 服务的运行历史日志。在日志中，我们能够定位到问题发生的具体时间点。从日志信息中可以发现，local-fs.target 的依赖条件未能满足，导致该目标未能成功完成初始化。显然，这会触发系统的紧急模式（Emergency Mode）。

在进一步分析系统运行日志时，我们注意到日志中显示的红色超时信息，特别是 dev-disk-by***.service 服务的超时问题。通过查询相关资料，我们了解到 dev-disk-by***.service 是由 udev 规则触发并由 systemd 动态生成的服务，主要用于管理设备挂载。

系统中的设备挂载配置大概分为两部分：一部分在 initrd 中，另一部分在 /etc/fstab 文件中。从日志中可以看到，由于某个块设备的 UUID 挂载失败，导致 local-fs.target 未能完成初始化，进而触发了紧急模式（Emergency Mode）。

为了进一步排查问题，可以查询系统中所有块设备的 UUID。以下是常用的命令：

1. lsblk -f：列出所有块设备及其文件系统信息，包括 UUID。
2. blkid：直接显示所有块设备的 UUID，包括文件系统类型和分区信息。

执行以下命令来查询所有块设备的 UUID：

1

blkid -f

该命令将列出系统中所有块设备的 UUID，帮助我们确定挂载失败的具体设备

在排查过程中，我们发现 /dev/vda1 的 UUID 与报错信息中显示的 UUID 仅相差一位。这引起了我们的怀疑，于是进一步检查 /etc/fstab 文件。果不其然，问题出在这里——/etc/fstab 中的 UUID 写错了。

实际上，这是为了展示分析步骤而手动修改的（故意引入了一个错误）。将 /etc/fstab 中多余的字符“a”删除后，重新启动系统，一切便恢复正常了。

(注：实际是我手动改的，为了展示 /etc/fstab 内容错误导致系统无法正常启动时的分析步骤)

删除 UUID 最前面的多余字符“a”，保存文件后重启系统，随后系统便能够正常启动了。

找不到 init进程

如果开机后能看到 GRUB 引导项，但系统无法正常启动，通常问题不大。

选中对应的引导项，按 e 键进入引导参数编辑页面。

如果系统在确认引导项后卡死，或者进入 initramfs 的 shell 页面，需要具体分析问题。例如，当系统实际的 / 无法找到时，通常会在 initramfs 阶段进入 busybox 内置的 shell 环境。

在这种情况下，可以查看内核参数，确认是否存在参数错误。例如，在 GRUB 编辑页面中，ostree= 参数的值被我故意在最后添加一个字母,从而让系统启动出错,方面展开接下来的排错过程。

此时，需要确认对应的目录是否存在。注意，ostree 参数的值通常需要以 /root/persistent 为前缀，之所以如此,当然是因为我提前看过initrd中对 ostree 参数的处理啦。

该问题源于系统启动过程中检查的checkouta目录不存在，而实际正确的目录名称应为checkout，这导致系统启动失败。
在排查类似问题时，建议在内核参数中添加debug选项，以获取 initramfs 初始化阶段的详细调试信息。

之后按下 F10,加载引导信息,当前这里的checkout我仍然修改为checkouta,方便我们复现问题并分析,不出意外,我们又来到了熟悉的页面

在 initramfs 的 shell 中，可以通过查看 /run/initramfs/initramfs.debug 文件来分析日志。日志文件中包含了详细的启动过程信息，通过查看日志可以找到报错的地方。

这里都是熟悉的 bash 脚本,相信阅读对大家来说不会产生障碍,接下来就是找到报错的地方

(initramfs 中存在许多天然断点，这些断点可以通过在 GRUB 参数中添加 break=[break_point] 来触发。break_point 的取值包括以下几种：

• top：initramfs 启动过程的最开始阶段。
• modules：加载必要的内核模块阶段。
• premount：挂载根文件系统之前的准备阶段。
• mount：挂载根文件系统的阶段。
• mountroot：挂载根文件系统的具体实现阶段。
• bottom：initramfs 启动过程的最后阶段。

通过在特定阶段暂停启动过程，可以方便地检查和干预启动过程)。

我一般习惯先开最后,再看开头,翻到最后面,可以明显看到是 initramfs 阶段找不到对应的init进程(其实就是找不到系统的/),所以就单独启动了一个sh终端,方便使用者自行分析。

系统无法启动的原因已经找到,接下来就是查看为何找不到init进程,这需要我们找到最初开始报错的地方,查找起来实际还是很轻松的,如下图,果然是这里异常了,知道了问题我们在下次启动时,手动调整对应的grub参数即可解决.

分阶段调试

前面说了,initramfs 中存在很多maybe_break的天然断点,按照先后执行顺序如下所示:

• 1. top

作用：这是 initramfs 启动过程的最开始阶段。

调试用途：如果在启动参数中设置 break=top，系统会在 initramfs 的初始化脚本开始执行时暂停，方便用户检查早期启动环境。

• 2. modules

作用：在这个阶段，系统会加载必要的内核模块。这些模块通常是根据 /conf/modules 文件的配置加载的，尽管在现代系统中，/conf/modules 文件可能不存在，因为很多模块已经通过 udev 动态加载。

调试用途：如果设置 break=modules，系统会在加载模块之前暂停，用户可以检查模块加载情况或干预模块加载过程。

• 3. premount

作用：这个阶段是为了挂载根文件系统做准备。它会运行 /scripts/init-premount 目录下的脚本，这些脚本通常用于初始化设备和文件系统，例如启动 udev 守护进程、处理 USB 或 FireWire 设备等。

调试用途：如果设置 break=premount，系统会在挂载根文件系统之前暂停，用户可以检查设备初始化情况。

• 4. mount

作用：这个阶段的主要任务是挂载根文件系统。它会执行 /scripts/local 中的 mountroot 函数，检测根文件系统的类型并将其挂载到 ${rootmnt}。

调试用途：如果设置 break=mount，系统会在挂载根文件系统之前暂停，用户可以检查挂载参数或干预挂载过程。

• 5. mountroot

作用：这个阶段是挂载根文件系统的具体实现阶段。它会根据启动参数（如 root=）解析根文件系统的设备路径，并尝试将其挂载到指定的挂载点。

调试用途：如果设置 break=mountroot，系统会在挂载根文件系统的过程中暂停，用户可以检查挂载失败的原因。

• 6. bottom

作用：这是 initramfs 启动过程的最后阶段。在这个阶段，系统会执行 /scripts/init-bottom 目录下的脚本，这些脚本通常用于清理和完成启动过程中的最后一步操作。

调试用途：如果设置 break=bottom，系统会在启动过程的最后阶段暂停，用户可以检查启动过程中的最后一步操作。

通过在 grub 中添加break=[break_point]可以让启动过程分别停止在不同的阶段并启动一个 sh环境,更方便我们确认是哪个环节出现了问题。

在这个sh环境中，当我们检查完系统信息后，可以执行 exit命令，此时系统会继续启动。

分析 initrd内容

当我们安装内核获驱动时,我们一般会执行 update-initramfs 命令,生成新的 initrd,偶尔也会出现生成的initrd内容异常的问题.我们可以对比 update-initramfs 前后的 initrd 内容.

initrd 存放于 /boot/initrd.img-* ,大小一般在200MB以内, 通过lsinitramfs命令查看其内容,通过对比更新前后的 initrd 可以发现绝大部分问题,

如果确实是update-initramfs命令执行后 initrd 内容出现了问题,也不要恐慌,update-initramfs 也只是一个普通的 bash 脚本而已,分析其源码实现即可,这也是我们了解系统启动过程的一个绝好机会.

卡死无输出,无日志,键鼠无反应

实话说,很少见,一般都出现在未适配的硬件上面,这种情况需要电脑有串口(电脑没有串口怎么办?凉拌),通过串口查询内核输出的日志,串口的使用网络上有很多资料,因为问题不太常见所以在碰到后您可以直接百度搜索如何配置串口参数,并联系专业的内核研发人员陪同定位.

启动阶段

在 grub 编辑阶段，添加参数 init=/bin/bash，此时处于刚挂载根文件系统，系统中的其他进程都没还启动。
添加参数 systemd.debug-shell=1，在启动后，systemd 会占用 tty9，可以按 Ctrl + Alt + F9 进入此终端，此时用户默认具有 root 权限。
添加参数 break=bottom ,然后在接下来的 sh 环境中,先找到根文件系统，之后设置 /etc/systemd/system/default.target 指向的不同 target,可以让后续 systemd 在启动时运行到不同的级别。
或者添加参数 systemd.unit=multi-user.target，效果和上面的操作等同，您也可以设置为其他的 target。

写在最后

想到哪里就记到哪里了,后续再随时补充…

一、AT-SPI 与 D-Bus 的核心作用

Linux 系统中的无障碍功能主要通过 AT-SPI（Assistive Technology Service Provider Interface）实现，而 AT-SPI 服务与应用程序之间的通信则依赖于 D-Bus 这一强大的 IPC（进程间通信）机制。

• AT-SPI 提供了统一的接口，允许辅助技术（如屏幕阅读器、语音控制工具）访问应用程序的用户界面元素。
• D-Bus 作为系统级的消息总线，为 AT-SPI 服务与应用程序之间提供了高效可靠的通信渠道。

二、安装与启动无障碍服务

1. 安装必要的软件包

在 Debian/Ubuntu 系统中，我们可以使用以下命令安装 at-spi2-core：

1

$ sudo apt install at-spi2-core

2. 启动 AT-SPI 服务

安装完成后，我们需要确保 AT-SPI 服务（at-spi2-registryd）已经启动。你可以手动启动服务：

1

$ /usr/libexec/at-spi2-registryd

三、检查无障碍服务状态

1. 使用 d-feet 工具连接到 Session Bus，查找 org.a11y.Bus 服务。

2. 如果服务状态为 Enabled: false，我们需要手动启用：

1

$ busctl --user set-property org.a11y.Bus /org/a11y/bus org.a11y.Status IsEnabled b true

四、获取应用的 Bus 地址

1. 通过 d-feet 获取 a11y 服务的 bus address

2. 使用 d-feet 的 “连接到其他总线” 功能，输入之前获取的 Bus 地址。注意：地址前后的单引号需要去掉。

3. 成功连接后，切换到当前 Bus,并通过 Registry 服务的 GetChildren 方法查看已注册的应用程序。

4. 这些应用可以通过无障碍服务进行页面元素的访问，包括但不限于：

• 模拟点击
• 文本读取
• 获取屏幕坐标
• 监听控件状态变化

五、高级调试与事件监听

1. 使用 dbus-monitor 监听事件

通过 dbus-monitor 工具，我们可以实时监听特定应用的状态变化。请根据你的系统环境调整 Bus 地址：

1

$ dbus-monitor --address unix:path=/run/user/1000/at-spi/bus_0,guid=eb7bf1d52d6058ef7a2efe7a67da5f88

在对应应用进行操作时，终端会显示对应事件，这对自动化测试的开发与调试非常有帮助。

六、实际应用案例

1. 应用截图与自动化测试

结合无障碍功能，我们可以实现以下高级功能：

• 精确获取应用窗口的位置和大小信息
• 模拟用户操作（如点击、输入）
• 截取特定应用区域的屏幕截图（类似 Windows 的 Snipaste 功能）

2. 坐标定位与自动化脚本开发

通过获取应用内部控件的坐标信息，我们可以实现：

• 高效的区域截图
• 自动化测试脚本
• 桌面应用的自动化操作

注意事项

1. 所有需要修改系统服务的操作都需要管理员权限。
2. 不同 Linux 发行版可能需要安装不同的软件包。
3. 如果遇到服务无法启动的问题，可以检查系统日志以获取更多信息。
   通过本文的介绍，相信你已经对 Linux 系统中的无障碍支持有了更深入的理解，并能够将其应用到实际开发场景中。

在 initramfs 的 bash 中,使用 blkid 查看块设备信息,找到 Roota 设备,将其挂载到创建的 /roota 目录上(因为 boot 目录的数据一般都在 roota 上)
进入 roota 目录,可以看到其中存在 boot 目录,编辑 boot/grub/grub.cfg,找到 menuentry 引导项菜单的内容,首先去掉 quiet splash选项,为了方便调试,额外加了一条 systemd.debug-shell=1 的参数
此时,忽然发现 grub 参数中还存在 fusec 之类的安全特性参数,这些参数是需要配置安全的定制软件包使用的,可能会导致挂载失败,删除掉它
Ctrl + Alt + Del 重启电脑,之后顺利进入系统

GPG签名简介

GPG（GNU Privacy Guard）签名是一种用于验证数字内容完整性和真实性的方法。GPG是一个开源的加密软件，广泛用于数据加密和数字签名。

GPG签名的工作原理

生成密钥对

• 用户生成一对密钥：一个私钥（private key）和一个公钥（public key）。
• 私钥用于创建签名，公钥用于验证签名。

签名过程

• 当用户想要对一段数据（如文件、电子邮件等）进行签名时，GPG使用用户的私钥对数据进行哈希运算，生成一个摘要（hash）。
• 这个摘要通过私钥加密后，形成签名附加在原始数据上。

验证签名

• 接收者使用签名者的公钥对签名进行解密，得到哈希值。
• 接收者对接收到的数据重新计算哈希值，并与解密得到的哈希值进行比较。
• 如果两个哈希值一致，说明数据没有被篡改，并且签名确实是由持有私钥的人生成的。

GPG签名的应用

• 软件分发：开发者使用GPG签名他们发布的软件，用户可以通过验证签名确保下载的软件是原版且未被篡改。
• 电子邮件：使用GPG对电子邮件进行签名，接收者可以确认邮件内容的完整性和发送者的身份。
• 文档和合同：对重要的文件和合同进行数字签名，确保文件在传输过程中的完整性。

使用GPG签名的步骤

安装 GPG

如果尚未安装 GPG，可以通过以下命令安装：

1

sudo apt install gnupg

生成密钥对

如果尚未生成 GPG 密钥对，可以使用以下命令生成：

1

gpg --full-generate-key

选择合适的选项并按照提示生成密钥对。

签名文件

1

gpg --sign <file>

验证签名

1

gpg --verify <file>.gpg

通过GPG签名，可以有效地保护数字内容的完整性和真实性，广泛应用于软件开发、安全通信和数据保护等领域。

OSTree GPG 签名的原理

GPG 签名用于验证数据的完整性和来源。通过对 OSTree 提交进行 GPG 签名，可以确保文件系统树在传输和部署过程中没有被篡改，并且确实来自预期的签名者。

配置和使用 OSTree GPG 签名

准备工作

列出所有 GPG 密钥

1

gpg --list-keys

这将显示你密钥环中的所有公钥。输出类似于以下格式：

1
2
3
4
5

pub   rsa2048 2021-01-01 [SC] [expires: 2023-01-01]
      3AA5C34371567BD2
uid           [ultimate] Your Name <youremail@example.com>
sub   rsa2048 2021-01-01 [E] [expires: 2023-01-01]

识别密钥 ID

在输出中，pub 行包含公钥信息。下面是如何识别密钥 ID：

• 公钥行的第二行显示密钥 ID。例如，上面的输出中，3AA5C34371567BD2 是密钥 ID。
• uid 行显示用户名和电子邮件地址。你可以通过用户名或电子邮件地址识别你感兴趣的密钥。

导出 GPG 公钥

通过密钥 ID 导出公钥以供其他人验证签名：

1

gpg --armor --export <your-key-id> > pubkey.asc

签名和验证 OSTree 提交

初始化 OSTree 仓库

如果尚未初始化 OSTree 仓库，可以使用以下命令：

1

ostree init --repo=repo --mode=archive-z2

注：在使用 OSTree 时，可以通过环境变量 OSTREE_REPO 指定仓库的地址。这个环境变量允许你在命令行中不必每次都指定 –repo 参数，而是通过设置环境变量来定义仓库的位置。
export OSTREE_REPO=/path/to/your/repo

签名 OSTree 提交

创建一个提交并进行签名：

1

ostree commit --repo=repo --branch=example-branch --gpg-sign=<your-key-id> --subject="Example Commit" --body="This is an example commit"

其中 <your-key-id> 是你的 GPG 密钥 ID。

验证 OSTree 提交

在另一个系统上验证签名，需要首先导入公钥：

1

gpg --import pubkey.asc

然后验证签名：

1

ostree pull --repo=repo --gpg-verify=true <remote-repo> <branch>

发布和部署

1. 发布签名的 OSTree 提交

将签名的提交推送到远程仓库：

1
2

ostree --repo=repo remote add --gpg-import=pubkey.asc origin <remote-url>
ostree --repo=repo push --remote=origin <branch>

2. 部署签名的 OSTree 提交

在客户端系统上，拉取并部署签名的提交：

1
2
3

ostree remote add --gpg-import=pubkey.asc origin <remote-url>
ostree pull origin <branch>
ostree admin deploy <branch>

实践示例

以下是一个完整的示例，从签名到验证和部署：

服务器端（签名和发布）

初始化仓库

1

ostree init --repo=repo --mode=archive-z2

创建并签名提交

1

ostree commit --repo=repo --branch=example-branch --gpg-sign=<your-key-id> --subject="Initial Commit" --body="Initial commit with GPG signature"

推送提交

1
2

ostree remote add --repo=repo --gpg-import=pubkey.asc origin <remote-url>
ostree --repo=repo push --remote=origin example-branch

客户端（验证和部署）

导入公钥

1

gpg --import pubkey.asc

添加远程仓库并拉取提交

1
2

ostree remote add --gpg-import=pubkey.asc origin <remote-url>
ostree pull origin example-branch

部署提交

1

ostree admin deploy example-branch

通过以上步骤，你可以实现 OSTree 提交的 GPG 签名和验证，从而确保文件系统树的安全性和完整性。

CPU的主频

主频（Clock Speed）是指CPU的工作频率，通常以GHz（千兆赫兹）为单位。它表示CPU每秒钟能够执行的指令周期数。例如，一个主频为3.5GHz的CPU，每秒钟可以进行35亿个指令周期。

为什么主频重要？

1. 执行速度：主频越高，CPU在单位时间内能够执行的指令就越多，处理速度也就越快。
2. 响应时间：高主频的CPU可以更快速地响应系统和应用程序的需求，提高计算机的整体性能。

CPU的外频

外频（External Clock）是指主板与CPU之间的基准时钟频率。它通常由主板上的时钟发生器提供。外频的单位同样是Hz（赫兹）。

外频的作用

外频是决定CPU最终工作频率（即主频）的基础参数。外频与倍频相结合，确定了CPU的主频。例如，如果外频为100MHz，而倍频为35，那么CPU的主频就是100MHz × 35 = 3500MHz（即3.5GHz）。

CPU的倍频

倍频（Multiplier）是一个无量纲的系数，它将外频放大，从而得到CPU的主频。倍频由CPU内部的倍频器决定，一般由CPU的设计厂商设定。

倍频的特点

1. 可调节性：许多高端CPU支持倍频调节，允许用户在一定范围内调整倍频，从而超频或降频，以满足不同的性能需求和节能要求。
2. 灵活性：通过调整倍频，用户可以在不改变外频的情况下，灵活调整CPU的工作频率，提供更好的系统稳定性和性能优化。

主频、倍频与外频的关系

简单来说，CPU的主频由外频和倍频共同决定，公式为： 主频=外频×倍频\text{主频} = \text{外频} \times \text{倍频}

举例说明

假设一款CPU的外频为100MHz，倍频为35，那么它的主频就是：
主频=100MHz×35=3500MHz=3.5GHz

通过调整外频和倍频的组合，可以实现对CPU主频的精确控制。例如，通过将外频提升到105MHz，倍频保持35不变，新的主频就是：
主频=105MHz×35=3675MHz=3.675GHz

如何调节外频和倍频

现代计算机主板和CPU通常允许用户在BIOS/UEFI设置中调整外频和倍频。这一过程称为“超频”（Overclocking）或“降频”（Underclocking）。不过，超频可能会带来系统不稳定和过热的问题，需要谨慎操作并确保良好的散热条件。

总结

理解CPU的主频、倍频和外频是提升计算机性能的重要一步。主频是CPU性能的直接表现，而外频和倍频则共同决定了这一表现。通过合理调整这两个参数，用户可以在一定范围内优化CPU的工作频率，从而满足不同的计算需求。
希望通过本文，您对CPU的主频、倍频和外频有了更清晰的认识。如果有任何疑问或需要进一步的探讨，欢迎在评论区留言，我会尽力解答您的问题。

以下是使用 makeself 创建自解压安装脚本的步骤。

安装

在大多数 Linux 发行版中，makeself 工具可以通过包管理器安装。以下是一些常见的安装方法：

• Ubuntu/Debian:

1

sudo apt-get install makeself

• Fedora:

1

sudo dnf install makeself

• Arch Linux:

1

sudo pacman -S makeself

准备文件

假设你有一组文件或一个目录需要打包。在这个例子中，我们将使用一个目录 my_app。

编写安装脚本

编写一个名为 install.sh 的脚本，定义如何安装和配置你的应用程序。以下是一个简单的例子：

1
2
3
4
5

#!/bin/bash
echo "正在安装 My App..."
# 执行安装步骤，例如复制文件、设置权限等
cp -r * /opt/my_app/
echo "安装完成！"

确保你的安装脚本是可执行的：

1

chmod +x install.sh

使用makeself创建自解压安装包

使用 makeself 工具创建自解压安装包。以下是一个示例命令：

1

makeself my_app my_app_installer.run "My App Installer" ./install.sh

• my_app 是包含你所有文件的目录。
• my_app_installer.run 是生成的自解压安装包的名称。
• "My App Installer" 是安装包的描述。
• ./install.sh 是安装脚本的路径。

完整示例

假设你有以下目录结构：

1
2
3
4
5
6

my_app/
├── install.sh
├── bin/
│   └── my_app_executable
└── lib/
    └── my_app_library.so

1. 创建 install.sh：

1
2
3
4
5
6
7

#!/bin/bash
echo "正在安装 My App..."
# 创建目标目录
mkdir -p /opt/my_app
# 复制文件
cp -r * /opt/my_app/
echo "安装完成！"

2. 确保 install.sh 是可执行的：

1

chmod +x my_app/install.sh

3. 使用 makeself 创建自解压安装包：

1

makeself my_app my_app_installer.run "My App Installer" ./install.sh

运行自解压安装包

用户可以通过执行生成的 .run 文件来安装应用程序：

1

./my_app_installer.run

这会解压文件并运行 install.sh 脚本，完成应用程序的安装。
通过这些步骤，你可以轻松创建一个自解压安装脚本，方便分发和安装你的 Linux 应用程序。

解压为原始文件

通过 makeself 制作的自解压安装包同样支持解压为原始文件，您可以在修改后重新打包为 .run 格式的自解压安装包。

1

./my_app_installer.run --noexec --targegt my_app_dir

查看压缩包内容

压缩后的可执行文件可以通过 –list 参数查看文件内容

1

./my_app_installer.run --list

什么是宏内核？

宏内核是一种传统的操作系统内核设计，其特点是将操作系统的大部分功能都集成在一个大内核中。这个大内核直接运行在硬件之上，并且具有完整的系统功能，包括进程管理、内存管理、文件系统、设备驱动等。
优点：

1. 性能高： 由于大部分服务都在内核空间内运行，系统调用和进程间通信的开销较低。
2. 实现简单： 开发者可以直接在内核空间内实现大部分功能，减少了用户空间与内核空间之间的切换。

缺点：

1. 稳定性差： 由于所有功能都在内核空间运行，一旦某个部分出现错误，可能导致整个系统崩溃。
2. 维护复杂： 宏内核代码量大，任何修改都需要对整个内核进行重新编译，测试和调试难度较大。

实际例子：

• Linux内核： Linux是最典型的宏内核操作系统，它将大部分功能集成在内核中。
• Windows NT内核： 尽管微软声称Windows NT内核是微内核架构，但实际上它更接近于宏内核设计，因为许多服务都在内核模式下运行。

什么是微内核？

微内核则采用了截然不同的设计思路。它将操作系统的核心功能精简到最小，仅保留最基础的部分，如进程间通信、基本的内存管理和简单的硬件驱动。其他系统服务则运行在用户空间，以减少内核的复杂度。
优点：

1. 稳定性高： 由于内核中只包含最基本的功能，即使某个用户空间服务崩溃，系统整体仍能保持稳定。
2. 安全性好： 用户空间服务与内核之间的隔离，减少了内核受到攻击的可能性。

缺点：

1. 性能低： 由于系统服务运行在用户空间，频繁的系统调用和进程间通信会带来较大的性能开销。
2. 实现复杂： 需要设计高效的通信机制，以保证用户空间服务之间的交互顺畅。

实际例子：

• MINIX： MINIX是一个典型的微内核操作系统，因其简洁的设计而被广泛用于教学。
• QNX： QNX是一种商用实时操作系统，采用微内核设计，广泛应用于嵌入式系统中。

宏内核与微内核的比较

结语

宏内核和微内核各有优缺点，选择哪种内核架构取决于具体的应用场景和需求。对于需要高性能和快速响应的系统，如桌面操作系统和服务器操作系统，宏内核通常是首选。而对于需要高稳定性和安全性的系统，如嵌入式系统和实时操作系统，微内核则更具优势。通过理解这两种内核架构的特点和差异，开发者可以更好地设计和优化操作系统，以满足不同的应用需求。
希望这篇文章能帮助你更好地理解宏内核和微内核。如果你有任何疑问或需要进一步探讨，欢迎在评论区留言。

段页式内存管理的基本概念

段（Segment）

• 分段：内存被划分为不同的段，每个段代表一个逻辑单位，比如代码段、数据段、堆栈段等。每个段有一个段基址和段长度。
• 段表（Segment Table）：操作系统为每个进程维护一个段表，段表条目包含段基址和段长度，用于将逻辑地址转换为段内的偏移地址。

页（Page）

• 分页：每个段进一步划分为固定大小的页，内存被划分成大小相等的页框（Page Frame）。
• 页表（Page Table）：每个段对应一个页表，页表条目包含页框号，用于将段内的偏移地址转换为物理地址。

地址转换过程

段页式内存管理将逻辑地址转换为物理地址的过程涉及两个步骤：

1. 段选择：首先根据段号查找段表，获取段基址和段长度。如果逻辑地址中的偏移量超过了段长度，触发段错误（Segment Fault）。
2. 页选择：其次在段内进行分页，根据段内的页号查找页表，获取对应的页框号，将页内偏移量加到页框基址上，形成最终的物理地址。

具体步骤如下：

• 逻辑地址（段号：段内偏移）：逻辑地址由段号（Segment Number）和段内偏移（Offset within Segment）组成。
• 段表查找：使用段号在段表中查找，获取段基址和段长度。
• 页表查找：将段内偏移分为页号（Page Number）和页内偏移（Offset within Page），使用页号在页表中查找，获取页框号。
• 物理地址计算：将页框号和页内偏移组合，形成最终的物理地址。

优点

• 灵活性：结合了分段和分页的优点，既支持逻辑分段，又能够有效利用内存碎片。
• 保护和共享：通过段表和页表的多级映射，可以实现内存保护和进程间的内存共享。
• 减少外部碎片：分页的引入减少了分段带来的外部碎片问题。

示例

假设一个逻辑地址由段号、页号和页内偏移组成，如下所示：

1

逻辑地址格式： 段号（S） 页号（P） 页内偏移（D）

具体转换过程如下：

1. 使用段号S在段表中查找，得到段基址和段长度。
2. 将逻辑地址中的页号P和页内偏移D分离，计算段内偏移。
3. 使用页号P在对应段的页表中查找，得到页框号。
4. 将页框号和页内偏移D组合，形成物理地址。

示例数据

假设段表和页表如下：
段表：

页表（段0）：

页表（段1）：

假设逻辑地址为：(1, 1, 50) ，表示段1，页1，页内偏移50：

1. 在段表中查找段1，得到段基址2000。
2. 使用页号1在段1的页表中查找，得到页框号10。
3. 将页框号10转换为物理地址，假设每页大小为100：
   • 物理地址 = 页框号 * 页大小 + 页内偏移
   • 物理地址 = 10 * 100 + 50 = 1050

最终物理地址为1050。

段页式内存管理的应用

段页式内存管理广泛应用于现代操作系统，如Windows和Unix/Linux，这些系统通过段页式内存管理实现内存保护、多任务处理和虚拟内存管理。通过段页式管理，操作系统可以灵活地分配和管理内存，提高系统的可靠性和效率。

Fedora 中提供了 greenboot 服务，这是一款基于 rpm-ostree 的系统上 systemd 的通用运行状况检查框架。

Greenboot 由两部分组成：

• greenboot ：检查提供的脚本，如果这些检查未通过则重新启动，如果重新启动未能解决问题则回滚到之前的部署。
• greenboot-default-health-checks ，由 Greenboot 维护者提供的一系列可选和策划的健康检查。

安装

为了在 Fedora Silverblue、Fedora IoT 或 Fedora CoreOS 上获得完整的 Greenboot ，请使用如下命令安装

1
2

rpm-ostree install greenboot greenboot-default-health-checks
systemctl reboot

名词介绍

• MOTD：指/run/motd.d/boot-status，存放 greenboot 运行阶段的一些日志信息。

脚本目录

目录结构

1
2
3
4
5
6
7

/etc
└── greenboot
    ├── check
    │   ├── required.d
    │   └── wanted.d
    ├── green.d
    └── red.d

• /etc/greenboot/check/required.d：此目录中的运行状态检查脚本不得失败。如果此文件夹中的任何脚本退出时出现错误代码，则启动将被声明为失败。错误消息将出现在 MOTD 和 journalctl -u greenboot-healthcheck.service 中。
• /etc/greenboot/check/wanted.d：此目录中的运行状态检查脚本可能失败，。此文件夹中的脚本可以退出并显示错误代码，并且启动不会被声明为失败。错误消息将出现在 MOTD 和 journalctl -u greenboot-healthcheck.service -b 中。
• /etc/greenboot/green.d：此目录中的交叉脚本将在启动成功（绿色）后运行。
• /etc/greenboot/red.d：此目录中的交叉脚本将在启动失败（红色）后运行。

除非您的发行版中默认启用 greenboot，否则请通过运行 systemctl enable greenboot-task-runner greenboot-healthcheck greenboot-status greenboot-loading-message greenboot-grub2-set-counter greenboot-grub2-set-success greenboot-rpm-ostree-grub2-check-fallback redboot-auto-reboot redboot-task-runner 来启用它。它将在下次启动过程中自动启动并运行检查。

之后当您 ssh 进入计算机时，将显示启动状态消息：
Boot Status is GREEN - Health Check SUCCESS
Boot Status is RED - Health Check FAILURE!

greenboot-default-health-checks

这些运行状况检查可在 rpm-ostree 系统中的只读目录 /usr/lib/greenboot/check 中找到。

• 检查存储库 URL 是否仍可通过 DNS 解析：此脚本位于 /usr/lib/greenboot/check/required.d/01_repository_dns_check.sh 下，并确保对存储库 URL 的 DNS 查询仍然可用。
• 检查更新平台是否仍然可访问：此脚本位于 /usr/lib/greenboot/check/wanted.d/01_update_platform_check.sh 下，并尝试连接并从 /etc/ostree/remotes.d 中定义的更新平台获取 2XX 或 3XX HTTP 代码。
• 检查当前启动是否由硬件看门狗触发：此脚本位于 /usr/lib/greenboot/check/required.d/02_watchdog.sh 下，用于检查当前启动是否由看门狗触发。如果是，但在一定的宽限期（默认为 24 小时，可通过 /etc/greenboot/greenboot.conf 中的 GREENBOOT_WATCHDOG_GRACE_PERIOD=number_of_hours 配置）后重新启动，Greenboot 不会将当前启动标记为红色，并且不会回滚到之前的部署。如果在宽限期内发生，此时当前启动将被标记为红色，但 Greenboot 不会回滚到之前的部署。默认情况下启用，但可以通过将 /etc/greenboot/greenboot.conf 中的 GREENBOOT_WATCHDOG_CHECK_ENABLED 修改为 false 来禁用它。

使用 systemd 服务进行健康检查

总体启动成功是根据 boot-complete.target 来衡量的。

Required Checks

创建一个不能失败的一次性健康检查服务单元，例如 /etc/systemd/system/required-check.service 。确保它在失败时调用 redboot.target ( OnFailure=redboot.target )。运行 systemctl enable required-check 来启用它。

1
2
3
4
5
6
7
8
9
10
11
12
13

[Unit]
Description=Custom Required Health Check
Before=boot-complete.target
OnFailure=redboot.target
OnFailureJobMode=fail

[Service]
Type=oneshot
ExecStart=/usr/libexec/mytestsuite/required-check

[Install]
RequiredBy=boot-complete.target
WantedBy=multi-user.target

Wanted Checks

创建一个可能会失败的一次性健康检查服务单元，例如 /etc/systemd/system/wanted-check.service 。运行 systemctl enable wanted-check 来启用它。

1
2
3
4
5
6
7
8
9
10
11

[Unit]
Description=Custom Wanted Health Check
Before=boot-complete.target

[Service]
Type=oneshot
ExecStart=/usr/libexec/mytestsuite/wanted-check

[Install]
WantedBy=boot-complete.target
WantedBy=multi-user.target

配置

目前，可以通过环境变量自定义以下参数。这些环境变量也可以在配置文件 /etc/greenboot/greenboot.conf 中描述：

• GREENBOOT_MAX_BOOT_ATTEMPTS：在声明部署有问题并回滚到上一个部署之前尝试启动的最大次数,默认为3。
• GREENBOOT_WATCHDOG_CHECK_ENABLED：启用/禁用检查当前启动是否已由硬件看门狗健康检查触发。有关健康检查的更多信息包含在子包 greenboot-default-health-checks 部分中。
• GREENBOOT_WATCHDOG_GRACE_PERIOD：升级后我们认为新部署导致重新启动的小时数。

流程

• greenboot-rpm-ostree-grub2-check-fallback.service 在 greenboot-healthcheck.service 之前运行，并检查 GRUB2 环境变量 boot_counter 是否为 -1。
  • 如果为 -1，则意味着系统处于回退部署中，并将执行 rpm-ostree rollback 返回到之前的工作部署。
  • 如果 boot_counter 不为-1，则此步骤不执行任何操作。
• greenboot-healthcheck.service 在 systemd 的 boot-complete.target 之前运行。它启动 /usr/libexec/greenboot/greenboot check ，它运行 required.d 和 wanted.d 脚本。
  • 如果 required.d 文件夹中的任何脚本失败，则调用 redboot.target 。
    • 它触发 redboot-task-runner.service ，从而启动 /usr/libexec/greenboot/greenboot red 。这将运行 red.d 文件夹中的脚本。
    • 经过上述操作后：
      • greenboot-status.service 运行，创建 MOTD 指定哪些脚本失败。
      • redboot-auto-reboot.service 已运行。它执行一系列检查以确定是否需要手动干预。如果没有，它将重新启动系统。
  • 如果 required.d 文件夹中的所有脚本都成功：
    • 已达到 boot-complete.target
    • greenboot-grub2-set-success.service 已运行。它取消设置 boot_counter GRUB 环境变量并将 boot_success GRUB 环境变量设置为 1。
    • greenboot-task-runner.service 启动 /usr/libexec/greenboot/greenboot green ，它运行 green.d 文件夹中的脚本，这些脚本将在成功更新后运行。
    • greenboot-status.service 运行，创建 MOTD 并显示成功消息。

Services 一览

grub2-editenv

在设置 GRUB 环境的时候，用到了 grub2-editenv 命令，由 grub2-tools-minimal 提供。
查阅其 源码 可以得知，这里只是把 set 的内容写入 /boot/grub2/grubenv 文件中进行保存。

BindPaths 是通过使用 Linux 内核的挂载命名空间（mount namespaces）和绑定挂载（bind mounts）来实现的。这些功能允许在特定进程的命名空间中修改文件系统的视图，而不会影响到其他进程或系统的全局视图。

挂载命名空间（mount namespaces）允许在特定进程的视图中隔离和重新配置挂载点。创建一个新的挂载命名空间后，进程可以在不影响其他进程的情况下修改其挂载点。
绑定挂载（bind mounts）是 Linux 文件系统功能的一部分，允许将一个目录或文件挂载到另一个目录。这使得同一目录或文件可以在多个位置同时出现。

以下是一个示例，展示如何配置一个 systemd 服务单元文件以重定向目录访问：

服务单元

假设你有一个名为 example.service 的服务单元文件，路径可能在 /etc/systemd/system/example.service 或 /lib/systemd/system/example.service。

1
2
3
4
5
6
7
8
9
10
11

[Unit]
Description=Example Service

[Service]
ExecStart=/usr/bin/example-binary
BindPaths=/path/to/redirected:/path/to/original
# 或者使用只读绑定
# BindReadOnlyPaths=/path/to/redirected:/path/to/original

[Install]
WantedBy=multi-user.target

在这个示例中，/path/to/original 是应用程序预期访问的目录，/path/to/redirected 是你希望应用程序实际访问的目录。

修改单元文件后，重新加载 systemd 配置以使更改生效，在 example-binary 中访问 /path/to/original 目录的内容时，此时均会重定向至 /path/to/redirected 目录。

1
2
3
4
5

# 重新加载 systemd 配置
sudo systemctl daemon-reload

# 启动或重启服务
sudo systemctl restart example.service

其他配置

除了 BindPaths ，systemd还提供了其他的选项，使用者可以根据自己的需求选择合适的配置。

BindPaths

• BindPaths=/target:/source
• 将 /source 目录绑定到 /target 目录。服务访问 /source 目录时实际上会访问 /target 目录。

BindReadOnlyPaths

• BindReadOnlyPaths=/target:/source
• 与 BindPaths 类似，但绑定的目录为只读模式。服务只能读取 /target 目录，无法进行写操作。

ReadWritePaths

• ReadWritePaths=/path/to/dir
• 指定服务可以读写访问的目录。这些目录将被临时挂载为读写，即使根文件系统是只读的。

ReadOnlyPaths

• ReadOnlyPaths=/path/to/dir
• 指定服务可以只读访问的目录。这些目录将被临时挂载为只读。

InaccessiblePaths

• InaccessiblePaths=/path/to/dir
• 指定服务无法访问的目录。访问这些目录将导致权限错误。

TemporaryFileSystem

• TemporaryFileSystem=/path/to/dir:mode=755,size=10M
• 将指定目录挂载为临时文件系统（tmpfs），类似于 mount -t tmpfs。可以用来提供服务的临时存储空间。

PrivateTmp

• PrivateTmp=yes
• 启用服务的私有 /tmp 和 /var/tmp 目录，防止不同服务之间的临时文件相互影响。

ProtectSystem

• ProtectSystem=full
• 限制服务对系统文件和目录的写入访问。
  • ProtectSystem=yes：将 /usr 和其他系统目录设置为只读。
  • ProtectSystem=full：将 /etc 也设置为只读。
  • ProtectSystem=strict：将整个系统设置为只读，除了通过 ReadWritePaths 显式允许的目录。

ProtectHome

• ProtectHome=yes
• 限制服务对用户主目录的访问。
  • ProtectHome=yes：将用户主目录挂载为不可访问。
  • ProtectHome=read-only：将用户主目录挂载为只读。
  • ProtectHome=no：不限制用户主目录的访问。

MountFlags

• MountFlags=slave
• 设置挂载点的标志。通常用来隔离服务的挂载命名空间。

备注

部分环境中设置后并不能生效，报错内容如下：

你需要升级systemd和内核。

systemd在 233 版本之后对这一特性添加了支持。见systemd-man-BindPaths。
内核版本不确定，笔者在4.19的内核上测试失败但在6.1.32的内核验证成功。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

root@fedora:/etc/grub.d# ls -al
总计 108
drwx------. 1 root root   392  6月11日 13:16 .
drwxr-xr-x. 1 root root  4048  6月11日 13:22 ..
-rwxr-xr-x. 1 root root  9346  6月11日 13:16 00_header
-rwxr-xr-x. 1 root root   236  6月11日 13:16 01_users
-rwxr-xr-x. 1 root root   835  6月11日 13:16 08_fallback_counting
-rwxr-xr-x. 1 root root 19332  6月11日 13:16 10_linux
-rwxr-xr-x. 1 root root   833  6月11日 13:16 10_reset_boot_success
-rwxr-xr-x. 1 root root   892  6月11日 13:16 12_menu_auto_hide
-rwxr-xr-x. 1 root root   410  6月11日 13:16 14_menu_show_once
lrwxrwxrwx. 1 root root    38  6月11日 13:16 15_ostree -> /usr/libexec/libostree/grub2-15_ostree
-rwxr-xr-x. 1 root root 13613  6月11日 13:16 20_linux_xen
-rwxr-xr-x. 1 root root  2562  6月11日 13:16 20_ppc_terminfo
-rwxr-xr-x. 1 root root 10869  6月11日 13:16 30_os-prober
-rwxr-xr-x. 1 root root  1122  6月11日 13:16 30_uefi-firmware
-rwxr-xr-x. 1 root root   725  6月11日 13:16 35_fwupd
-rwxr-xr-x. 1 root root   218  6月11日 13:16 40_custom
-rwxr-xr-x. 1 root root   219  6月11日 13:16 41_custom
-rw-r--r--. 1 root root   483  6月11日 13:16 README

ostree 修改 grub 引导项

核心逻辑见最后一行

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66

#!/usr/bin/sh
#
# Copyright (C) 2014 Colin Walters <walters@verbum.org>
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published
# by the Free Software Foundation; either version 2 of the licence or (at
# your option) any later version.
#
# This library is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
# Lesser General Public License for more details.
#
# You should have received a copy of the GNU Lesser General
# Public License along with this library. If not, see <https://www.gnu.org/licenses/>.

# Gracefully exit if ostree is not installed, or there's
# no system repository initialized.
if ! which ostree >/dev/null 2>/dev/null; then
    exit 0
fi
if ! test -d /ostree/repo; then
    exit 0
fi

# Gracefully exit if we can not find the grub2 'default' configuration as it is
# the case on new installations with bootupd where it is not needed.
if ! test -f /etc/default/grub; then
    exit 0
fi

# Gracefully exit if the grub2 configuration has BLS enabled,
# and the installed version has support for the blscfg module.
# Since there is no need to create menu entries for that case.
# See: https://src.fedoraproject.org/rpms/grub2/c/7c2bab5e98d
. /etc/default/grub
if test -f /boot/grub2/.grub2-blscfg-supported && \
   test "${GRUB_ENABLE_BLSCFG}" = "true"; then
   exit 0
fi

# Make sure we're in the right environment
if ! test -n "${GRUB_DEVICE}"; then
    echo "This script must be run as a child of grub2-mkconfig" 1>&2
    exit 1
fi

set -e

# Pick up stuff from grub's helper that we want to inject into our
# generated bootloader configuration.  Yes, this is pretty awful, but
# it's a lot better than reimplementing the config-generating bits of
# OSTree in shell script.

. /usr/share/grub/grub-mkconfig_lib

DEVICE=${GRUB_DEVICE_BOOT:-${GRUB_DEVICE}}

GRUB2_BOOT_DEVICE_ID="$(grub_get_device_id ${DEVICE})"
export GRUB2_BOOT_DEVICE_ID
GRUB2_PREPARE_ROOT_CACHE="$(prepare_grub_to_access_device ${DEVICE})"
export GRUB2_PREPARE_ROOT_CACHE

exec ostree admin instutil grub2-generate

具体实现

阅读 ostree 源码，函数调用顺序如下：
ot_admin_instutil_builtin_grub2_generate
ostree_generate_grub2_config
impl_ostree_generate_grub2_config
_ostree_bootloader_grub2_generate_config // 向target_fd(实际是向标准输出)中写入引导数据

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119

/* This implementation is quite complex; see this issue for
 * a starting point:
 * https://github.com/ostreedev/ostree/issues/717
 */
gboolean
_ostree_bootloader_grub2_generate_config (OstreeSysroot                 *sysroot,
                                          int                            bootversion,
                                          int                            target_fd,
                                          GCancellable                  *cancellable,
                                          GError                       **error)
{
    /* So... yeah.  Just going to hardcode these. */
    static const char hardcoded_video[] = "load_video\n"
        "set gfxpayload=keep\n";
    static const char hardcoded_insmods[] = "insmod gzio\n";
    const char *grub2_boot_device_id =
        g_getenv ("GRUB2_BOOT_DEVICE_ID");
    const char *grub2_prepare_root_cache =
        g_getenv ("GRUB2_PREPARE_ROOT_CACHE");

    /* We must have been called via the wrapper script */
    g_assert (grub2_boot_device_id != NULL);
    g_assert (grub2_prepare_root_cache != NULL);

    /* Passed from the parent */
    gboolean is_efi = g_getenv ("_OSTREE_GRUB2_IS_EFI") != NULL;

    g_autoptr(GOutputStream) out_stream = g_unix_output_stream_new (target_fd, FALSE);

    g_autoptr(GPtrArray) loader_configs = NULL;
    if (!_ostree_sysroot_read_boot_loader_configs (sysroot, bootversion,
                                                 &loader_configs,
                                                 cancellable, error))
        return FALSE;

    g_autoptr(GString) output = g_string_new ("");
    for (guint i = 0; i < loader_configs->len; i++)
    {
        OstreeBootconfigParser *config = loader_configs->pdata[i];
        const char *title;
        const char *options;
        const char *kernel;
        const char *initrd;
        const char *devicetree;
        char *quoted_title = NULL;
        char *uuid = NULL;
        char *quoted_uuid = NULL;

        title = ostree_bootconfig_parser_get (config, "title");
        if (!title)
            title = "(Untitled)";

        kernel = ostree_bootconfig_parser_get (config, "linux");

        quoted_title = g_shell_quote (title);
        uuid = g_strdup_printf ("ostree-%u-%s", (guint)i, grub2_boot_device_id);
        quoted_uuid = g_shell_quote (uuid);
        g_string_append_printf (output, "menuentry %s --class gnu-linux --class gnu --class os --unrestricted %s {\n", quoted_title, quoted_uuid);
        g_free (uuid);
        g_free (quoted_title);
        g_free (quoted_uuid);

        /* Hardcoded sections */
        g_string_append (output, hardcoded_video);
        g_string_append (output, hardcoded_insmods);
        g_string_append (output, grub2_prepare_root_cache);
        g_string_append_c (output, '\n');

        if (!kernel)
            return glnx_throw (error, "No \"linux\" key in bootloader config");
        g_string_append (output, "linux");
        if (is_efi)
            g_string_append (output, GRUB2_EFI_SUFFIX);
        else
            g_string_append (output, GRUB2_SUFFIX);
        g_string_append_c (output, ' ');
        g_string_append (output, kernel);

        options = ostree_bootconfig_parser_get (config, "options");
        if (options)
        {
            g_string_append_c (output, ' ');
            g_string_append (output, options);
        }
        g_string_append_c (output, '\n');

        initrd = ostree_bootconfig_parser_get (config, "initrd");
        if (initrd)
        {
            g_string_append (output, "initrd");
            if (is_efi)
                g_string_append (output, GRUB2_EFI_SUFFIX);
            else
                g_string_append (output, GRUB2_SUFFIX);
            g_string_append_c (output, ' ');
            g_string_append (output, initrd);
            g_string_append_c (output, '\n');
        }

        devicetree = ostree_bootconfig_parser_get (config, "devicetree");
        if (devicetree)
        {
            g_string_append (output, "devicetree");
            g_string_append_c (output, ' ');
            g_string_append (output, devicetree);
            g_string_append_c (output, '\n');
        }

        g_string_append (output, "}\n");
    }

    gsize bytes_written;
    if (!g_output_stream_write_all (out_stream, output->str, output->len,
                                  &bytes_written, cancellable, error))
        return FALSE;

    return TRUE;
}

查看所属软件包

1
2

root@fedora:/etc/grub.d# rpm -qf /usr/libexec/libostree/grub2-15_ostree
ostree-grub2-2024.5-1.fc40.x86_64

查询软件包提供者

源码也是由 ostree 提供

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

root@fedora:/etc/grub.d# rpm -qi ostree-grub2
Name        : ostree-grub2
Version     : 2024.5
Release     : 1.fc40
Architecture: x86_64
Install Date: 2024年04月15日 星期一 02时09分59秒
Group       : Unspecified
Size        : 2266
License     : LGPL-2.0-or-later
Signature   : RSA/SHA256, 2024年03月15日 星期五 07时19分33秒, Key ID 0727707ea15b79cc
Source RPM  : ostree-2024.5-1.fc40.src.rpm
Build Date  : 2024年03月15日 星期五 06时09分26秒
Build Host  : buildhw-x86-08.iad2.fedoraproject.org
Packager    : Fedora Project
Vendor      : Fedora Project
URL         : https://ostree.readthedocs.io/en/latest/
Bug URL     : https://bugz.fedoraproject.org/ostree
Summary     : GRUB2 integration for OSTree
Description :
GRUB2 integration for OSTree

结论

ostree-grub2 安装时提供了 /usr/libexec/libostree/grub2-15_ostree , 并链接至 /etc/grub.d/15_ostree，在重启前，执行 grub-mkconfig 操作，更新 grub 引导数据。

sudo apt install ostree

init

cd ostree/
ostree init –repo=. init

Just make your own changes and continueostree…

commit

将 tree/ 目录下的内容导入，提交信息未填写默认为空
ostree –repo=. commit –branch=foo tree/

指定提交内容

refs

列出仓库分支

ls

查看文件系统树的内容

cat

查看文件内容

checkout

检出

reset

重置到某个提交，在此之后的提交全部丢弃

log

查看分支提交信息

show

查看最新一笔提交

diff

比较提交差异

OSTREE_REPO

指定仓库地址，从而无需在命令中指定–repo

Manual

https://ostreedev.github.io/ostree/man/

开发

https://github.com/qt/qtotaupdate

基本概念

OverlayFS有三个主要的目录概念：

• Lower Directory（下层目录）：这是底层的只读文件系统。

• Upper Directory（上层目录）：这是上层的可写文件系统。

• Work Directory（工作目录）：这是一个用于支持上层目录操作的工作目录。

OverlayFS通过将上层目录和下层目录合并，提供一个统一的视图给用户。在这个视图中，上层目录的文件会覆盖下层目录中的文件。

工作原理

当你挂载OverlayFS时，你指定一个下层目录（lowerdir）、一个上层目录（upperdir）和一个工作目录（workdir）。合并后的结果会展示在一个挂载点（merged）上。
以下是一些操作如何在OverlayFS中处理：

• 读取文件：如果文件存在于上层目录，则读取上层目录的文件；如果不存在，则读取下层目录的文件。
• 写入文件：写入操作始终发生在上层目录。如果文件在下层目录中存在，写入操作会在上层目录中创建一个文件副本并进行修改。
• 删除文件：删除操作在上层目录中创建一个白化文件（whiteout file），从而在合并视图中隐藏下层目录的文件。

使用示例

假设你有以下目录结构：

• lowerdir：下层只读目录。
• upperdir：上层可写目录。
• workdir：工作目录。
• merged：合并后的挂载点。

挂载OverlayFS

创建目录：

1

mkdir -p lowerdir upperdir workdir merged

挂载OverlayFS：

1
2

sudo mount -t overlay overlay -o lowerdir=lowerdir,upperdir=upperdir,workdir=workdir merged

验证挂载：
你可以通过以下命令查看挂载的结果：

1

ls merged

操作示例

读取文件

如果 lowerdir 包含 file1，但 upperdir 不包含，那么 file1 可以在 merged 中读取。

1
2
3

echo "This is a file in lowerdir" > lowerdir/file1
cat merged/file1
# 输出: This is a file in lowerdir

写入文件

如果你在 merged 中写入文件，文件会出现在 upperdir 中。

1
2
3

echo "This is a new file in merged" > merged/file2
cat upperdir/file2
# 输出: This is a new file in merged

修改文件

如果你修改 merged 中存在于 lowerdir 的文件，修改后的副本会保存在 upperdir 中。

1
2
3
4
5

echo "This is a modified file in merged" > merged/file1
cat upperdir/file1
# 输出: This is a modified file in merged
cat lowerdir/file1
# 输出: This is a file in lowerdir

删除文件

删除操作在上层目录中创建一个白化文件，从而在合并视图中隐藏下层目录的文件。

1
2
3
4
5

rm merged/file1
ls merged
# `file1` 不再存在
ls upperdir
# 输出: file1 (白化文件)

取消挂载

1
2
3
4
5

# 查看挂载信息（确认挂载点）
sudo mount | grep merged

# 取消挂载
sudo umount merged

常见使用场景

• 容器技术：Docker等容器技术广泛使用OverlayFS来管理镜像层和容器层，使得镜像可以共享底层文件而不重复存储。
• 开发和测试：开发人员可以使用OverlayFS创建临时的文件系统视图进行测试，而不影响原有文件系统。
• 系统升级和恢复：系统管理员可以使用OverlayFS进行系统升级测试，确保系统稳定后再进行实际的升级操作。

OverlayFS提供了一种高效且灵活的文件系统管理方式，适用于多种需要层叠文件系统视图的应用场景。

Wayland

关于 wayland 的总结，个人觉得下面一段话挺好：

WaylandWayland is a replacement for the X11 window system protocol and architecture with the aim to be easier to develop, extend, and maintain.

WaylandWayland 是 X11 窗口系统协议和架构的替代品，旨在更易于开发、扩展和维护。

Wayland is the language (protocol) that applications can use to talk to a display server in order to make themselves visible and get input from the user (a person). A Wayland server is called a “compositor”. Applications are Wayland clients.

Wayland 是应用程序可用来与显示服务器对话的语言（协议），以便使自己可见并获取用户（人）的输入。 Wayland 服务器被称为“合成器”。应用程序是 Wayland 客户端。

Wayland also refers to a system architecture. It is not just a server-client relationship between a compositor and applications. There is no single common Wayland server like Xorg is for X11, but every graphical environment brings with it one of many compositor implementations. Window management and the end user experience are often tied to the compositor rather than swappable components.

Wayland 也指一种系统架构。它不仅仅是合成器和应用程序之间的服务器-客户端关系。没有像 Xorg 那样适用于 X11 的单一通用 Wayland 服务器，但每个图形环境都带来了许多合成器实现之一。窗口管理和最终用户体验通常与合成器而不是可交换组件相关。

A core part of Wayland architecture is libwayland: an inter-process communication library that translates a protocol definition in XML to a C language API. This library does not implement Wayland, it merely encodes and decodes Wayland messages. The actual implementations are in the various compositor and application toolkit projects.

Wayland 架构的核心部分是 libwayland：一个进程间通信库，它将 XML 中的协议定义转换为 C 语言 API。该库没有实现 Wayland，它只是对 Wayland 消息进行编码和解码。实际的实现是在各种合成器和应用程序工具包项目中。

Wayland does not restrict where and how it is used. A Wayland compositor could be a standalone display server running on Linux kernel modesetting and evdev input devices or on many other operating systems, or a nested compositor that itself is an X11 or Wayland application (client). Wayland can even be used in application-internal communication as is done in some web browsers.

Wayland 不限制其使用地点和方式。 Wayland 合成器可以是在 Linux 内核模式设置和 evdev 输入设备或许多其他操作系统上运行的独立显示服务器，也可以是本身就是 X11 或 Wayland 应用程序（客户端）的嵌套合成器。 Wayland 甚至可以用于应用程序内部通信，就像某些 Web 浏览器中所做的那样。

Part of the Wayland project is also the Weston reference implementation of a Wayland compositor. Weston can run as an X client or under Linux KMS and ships with a few demo clients. The Weston compositor is a minimal and fast compositor and is suitable for many embedded and mobile use cases.

Wayland 项目的一部分也是 Wayland 合成器的 Weston 参考实现。 Weston 可以作为 X 客户端或在 Linux KMS 下运行，并附带一些演示客户端。 Weston 合成器是一个最小且快速的合成器，适用于许多嵌入式和移动用例。

开发库

后续开发内容均基于 libwayland-dev 进行。

主要结构体

主要函数

核心文件

wayland-server-core.h

协议分类

详见: https://wayland.app/protocols/
:::success
实际上，wayland 合成器就是一组协议的实现者。
:::
wayland 协议大致分为 core(核心)、stable(稳定)、staging(考虑中，可能会变为稳定)、unstable(不稳定)等，表明其当前状态，出于兼容考虑，合成器的开发应且务必实现 core 和 stable 协议，视情况需要实现部分 unstable 或其它甚至是自定义协议。

Core

Stable

Staging

其他协议请查阅：https://wayland.app/protocols/

自定义协议

使用 wayland-scanner 命令将协议文件(XML)生成胶水代码，如果是服务端，需设置新协议的实现，客户端直接调用胶水代码的接口即可。

服务端实现

参考 wlroots 项目，不再赘述。
附一些之前手写的合成器对 ext_session_lock_v1 协议支持的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

#pragma once

#include "ext-session-lock-server-protocol.h"

struct ext_session_lock_manager_v1
{
    struct wl_event_loop *event_loop;
    struct wl_global *global;
    struct wl_list contexts;
    struct wl_resource *client;
    struct wl_listener display_destroy;

    struct
    {
        struct wl_signal lock;
        struct wl_signal destroy;
    } events;
};

struct ext_session_lock_v1
{
    struct wl_resource *resource;
    uint32_t id;
    struct wl_list contexts;

    struct
    {
        struct wl_signal get_lock_surface;
        struct wl_signal unlock_and_destroy;
        struct wl_signal destroy;
    } events;
};

struct ext_session_lock_surface_v1
{
    struct wl_resource *resource;
    struct wl_resource *surface;
    struct wl_resource *output;
    uint32_t id;

    struct
    {
        struct wl_signal ack_configure;
        struct wl_signal destroy;
    } events;
};

void ext_session_lock_v1_destroy(struct ext_session_lock_v1 *context);
void ext_session_lock_surface_v1_destroy(struct ext_session_lock_surface_v1 *context);
struct ext_session_lock_manager_v1 *ext_session_lock_manager_v1_create(struct wl_display *display);

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240