我的内核命令行如下所示：
root=31:0 ro noinitrd console=ttyS0,115200 root=/dev/mtdblock2 rootfstype=squashfs
我认为第一个root条目通过其主要和次要设备号标识磁盘，第二个条目通过其名称标识它。我可以确认rootfs确实是 on/dev/mtdblock2但我不知道如何解释31:0。
参考这里，配置为
Run Code Online (Sandbox Code Playgroud)grub> root (hd0,0) grub> kernel /vmlinuz-i686-up-4GB root=/dev/hda9 grub> boot前面的内容通常足以启动 Linux 机器。standalone
root语句告诉包含内核的分区。该语句描述了包含内核的分区内内核的kernel路径和文件名。该语句的参数的参数告诉包含 的分区，这当然是引导系统中的根分区。root=kernel/sbin/init小心这些相互冲突的
root关键词。独立的是从 grub 中看到的根目录，包含内核。该kernel语句的参数是从完全启动的系统中看到的根，并包含/sbin/init.
我不太明白这两个root配置的含义。这是否意味着操作系统保持在/dev/hda9待安装状态(hd0, 0)，或者操作系统将/vmlinuz被安装到/dev/had9？
我只有1 个 BTRFS 分区，其中包含/和/home。
我已经通过以下命令对根文件系统进行了快照：
btrfs subvolume snapshot / /root/snapshots/test
现在我想恢复这个快照。我怎么做 ？
当我启动到救援介质并安装时，我得到：
# mount -t btrfs /dev/sda3 /mnt
# ls /mnt
# bin boot dev etc home lib lib64 lost+found media mnt opt proc root run sbin srv sys tmp usr var
正如您所看到的，我的子卷从这里不可见。
但是当我这样做时：
$ btrfs subvolume list /
ID 256 gen 3794 top level 5 path fedora
ID 264 gen 2296 top level 256 path root/snapshots/test
如何恢复这个快照？
教程说我必须将子卷重命名为根。我怎么做 ？
我尝试过编辑/etc/fstab但没有效果。
我正在尝试构建一个全面的过滤器/排除文件，以防止备份没有意义的内容，例如临时/缓存数据或易于重新创建的文件。如果您可以分享（部分）rsync 备份的排除列表，我将不胜感激。
这是我到目前为止所拥有的：
## Universal excludes
lost+found
ld.so.cache
# backup text files (e.g. from Emacs)
- *~
- \#*\#
# Commonly distributed Mac OS X cache
- .DS_Store
# Commonly distributed Windows cache
- Thumbs.db
## Root file system
- /dev/
- /etc/modules.conf
- /media/
- /proc/
- /sys/
- /tmp/
- /usr/portage/
- /usr/src/
- /var/tmp/
- /var/log/
# Of the mounted stuff, whitelist only my two data partitions
- /mnt/
+ /mnt/data1
+ /mnt/data2
# Common package managers …我遇到了很多问题，让加密的多磁盘根文件系统在 Debian Jessie 上的 systemd 下可靠启动，而只需输入一次密码。以前，我在 Debian 中通过使用decrypt_derived/etc/crypttab 中的keyscript 为除第一个设备之外的每个设备处理此问题，并且效果很好。
但是，当引入 systemd 时，这并不能很好地发挥作用。systemd-cryptsetup-generator不处理密钥脚本，并且在尝试查找有关如何解决此问题的更多信息时，我仅在其中一位 systemd 开发人员的电子邮件中发现了对某些自定义密码代理的模糊引用，该电子邮件仅给出了“易于编写”的无用建议其他代理。要遵循的基本算法如下所示”，然后是要采取的 13 个步骤的列表。显然不适合最终用户。
我是 Debian，通过使用几个内核选项告诉 systemd/etc/crypttab在引导期间忽略或完全忽略它，我已经让它在某种程度上工作。Debianupdate-initramfs会将密钥脚本复制到 initramfs 并在 systemd 接管之前解锁设备，但我发现它稍后会导致问题，因为 systemd 现在没有用于解密设备的任何单元文件，因此依赖它们的挂载有时似乎挂起或延迟。一个中断的地方是尝试挂载 btrfs 子卷时；它们是从与 root 相同的物理设备挂载的，但 systemd 不知道这些设备已经解锁，并在启动时停止。
TL; DR - 我的实际问题：
处理跨越多个设备（无论是 btrfs 系统、LVM 镜像等）的加密根文件系统的 systemd 方法是什么，您只需要输入一次密码？我几乎不认为这是一个非常不寻常的案例，因此希望有一种方法可以做到这一点。
想到了一些可能的解决方案：
我确实只运行 Debian，但是在尝试了几天来为我的问题找到解决方案之后，我觉得这可能是一个更广泛的系统问题。
我正在尝试减少专用于 root LVM 的空间，因为我真的不需要它，而且我有一些疑问。以下是输出lvdisplay：
# lvdisplay
--- Logical volume ---
LV Path /dev/pc_rperez_lvm/root
LV Name root
VG Name pc_rperez_lvm
LV UUID m7XejM-82cZ-hODn-nT8H-y2BM-3B4s-lq2xgn
LV Write Access read/write
LV Status available
# open 1
LV Size 72.37 GiB
Current LE 18527
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:0
--- Logical volume ---
LV Path /dev/pc_rperez_lvm/home
LV Name home
VG Name pc_rperez_lvm
LV UUID Ehl9tF-XV30-uF4Y-T1Bc-WB8r-Pfim-ONQFn3
LV Write Access read/write
LV Status available …是否有可能工会安装包含根文件系统到一个现有的磁盘映像upperdir的overlayfs安装架，用于读写访问？
我正在尝试/tmp/使用预先存在的脚本（最初在 Ubuntu 12.04 上编写并移植到 14.04）将一些旧磁盘映像联合挂载到Ubuntu 16.04 机器上的目录中。
旧的自动化脚本用于overlayfs在ext2/3镜像之上创建和联合挂载可写磁盘squashfs镜像——像这样：
cd /tmp
mkdir lower upper union
losetup /dev/loop1 /tmp/image.sfs
losetup /dev/loop2 /tmp/image.ext2
mount -t squashfs -o ro /dev/loop1 /tmp/lower
mount -t ext2 -o rw /dev/loop2 /tmp/upper
mount -t overlayfs -o rw,lowerdir=/tmp/lower,upperdir=/tmp/upper overlayfs /tmp/union
它们最后用于 3.x 内核（可能是 3.18 之前的），并且该方法似乎不再起作用。叠加现在需要一个workdir选项——例如：
mount -t overlay -o rw,lowerdir=/tmp/lower,upperdir=/tmp/upper,workdir=/tmp/work overlay /tmp/union
问：是否可以调整自动化脚本以在 4.x 内核上以可写状态挂载和使用现有映像？我可以避免重新编写它们以包含类似root和work目录的内容吗？在某些情况下，这可能会破坏它们在其他地方的使用。
根据文档，workdir必须是upperdir …
我正在开发一个嵌入式 Linux，使用 u-boot 作为引导加载程序和 systemd init 系统。这些工具仅限于标准 busybox。
在分析一些问题时，我发现根文件系统是只读的，这导致了问题。原因是某些服务和程序依赖于可写的根文件系统，导致故障。
经过一段时间的研究，我发现根文件系统只有在断电时才是只读的。（当遇到某些错误时，主单元会触发电源回收。）我怀疑当根文件系统尝试写入某些关键文件或更新某些服务/进程时，在电源故障时会在文件系统上设置错误标志。下次启动时，fsck 会读取该标志并将根目录安装/重新安装为只读，或者 fsck 强制进入某种恢复模式（我不知道是否存在任何恢复模式）。
我的假设正确吗？如果是这样，那么错误时在 FS 上设置的 fs 标志是什么？如何防止 root 作为 RO 启动？
笔记：
根文件系统使用“errors=continue”挂载。因此，如果 fsck 读取重新安装选项的超级块，它应该忽略该错误并重新安装为 RW。
我尝试重现该情况，在运行 dd 命令时关闭电源，但从未能够重现。
附加问题：哪个 udev/systemd 魔法挂载 root fs？
许多系统的 ext4 直接位于块设备上，而其他系统则位于 lvm 上。我通常会直接在块设备上使用 ext4 创建新系统，并使用une2fs 进行自动文件系统检查。在旧版本的 CentOS（例如 4,5 或 6）中，我可以对 LVM 上的 ext 文件系统执行相同的操作，但不能对新版本执行相同的操作。确保驻留在 LVM 上的文件系统得到检查的最佳实践命令集是什么？
确保 lvm 卷不损坏的最佳方法是什么？如何针对 LVM 文件系统运行 fsck？lvm中有内置的东西可以自动检查fs吗？如果是这样，哪个日志文件条目实际上证明已完成检查？
mount以确保所有 lvm 卷均未安装。 fsck /dev/mapper/vg0用什么参数？/或者从不会自动挂载 LVM 的LiveCD 启动 并从那里运行 fsck？有没有办法在 LVM 上对 ext 文件系统使用une2fs？我运行文件系统检查的最常见方法是让操作系统在启动时通过tune2fs定期自动执行这些检查： tunefs -c 5 -i 7days /dev/sda1 但这不适用于lvm。
如果 fsck 是一种方法，那么将什么开关传递给它？如果没有lvm，我fsck -c -c -D -C0 /dev/sda1可以消除坏块并优化文件夹结构。在运行 fsck 之前应运行哪些 lvm 命令？
我过去引用的大部分文档都不可用。