我的笔记本电脑上有一个 64 位的 Debian 系统。我想 chroot 到一个 RasPiOS 系统（Raspberry Pi OS），但这个操作系统只有 32 位。当我尝试 chroot 时，出现以下错误：
# chroot /media/rpi /bin/bash
chroot: failed to run command ‘/bin/bash’: Exec format error
# ls -al /media/rpi/bin/bash
-rwxr-xr-x 1 root root 925124 2019-04-18 06:12:36 /media/rpi/bin/bash*
有人说这是因为 64 位和 32 位拱门不匹配。
那么有没有办法从 64 位主机 chroot 进入 32 位系统？
许多内核参数都分配了默认值。但其中一些并不是很清楚。我正在阅读proc 手册，在这种情况下，admin_reserve_kbytes我们可以阅读以下内容：
此文件中的默认值是 [3% of free pages, 8MiB] 的最小值，以 KiB 表示。
还有其他类似的默认值，那么这是什么意思呢？
编译内核源代码时，可以选择使用CONFIG_MODULE_SIG*选项对内核模块进行签名。该modinfo工具应该处理验证模块签名的任务，但多年来一直存在一些错误，该工具根本无法再完成这项工作。我得到的只是以下内容：
sig_id: PKCS#7
signer:
sig_key:
sig_hashalgo: md4
signature: 30:82:02:F4:06:09:2A:86:48:86:F7:0D:01:07:02:A0:82:02:E5:30:
...
所以没有密钥，哈希算法是 md4，甚至没有在内核中编译。
那么如何手动检查和验证模块签名呢？这甚至可能吗？
当你想限制每个进程的 CPU 时间时，你可以通过cgroups. 有两个参数可以完成这项工作：cpu.cfs_period_us和cpu.cfs_quota_us.
- cpu.cfs_period_us：每个调度程序周期的持续时间（以微秒为单位），用于带宽决策。这默认为 100000us 或 100ms。更长的周期会以延迟为代价来提高吞吐量，因为调度程序将能够更长时间地维持 CPU 绑定的工作负载。较小时期的情况正好相反。请注意，这只影响由 CFS 调度程序调度的非 RT 任务。
- cpu.cfs_quota_us：允许当前组在每个 cfs_period_us 中运行的最长时间（以微秒为单位）。例如，如果它设置为 cpu_period_us 的一半，cgroup 将只能在 50% 的时间内达到峰值运行。应该注意的是，这表示系统中所有 CPU 的总时间。因此，例如，为了允许两个 CPU 的充分使用，应该将此值设置为 cfs_period_us 值的两倍。
假设我想将一个进程限制为 1 个 CPU 核心。这可以通过以下方式完成：
cpu.cfs_quota_us 1.000.000
cpu.cfs_period_us 1.000.000
对比
cpu.cfs_quota_us 100.000
cpu.cfs_period_us 100.000
对比
cpu.cfs_quota_us 10.000
cpu.cfs_period_us 10.000
这三个选项有什么区别？假设我有一个 Firefox 进程，什么cpu.cfs_period_us对它更好——更长或更短，为什么？
我想让我的系统对分叉炸弹更有弹性。这可以通过使用 systemd 的DefaultTasksMax参数来部分实现，或者通过对所有有效的 shell 使用cgroup'spids控制器，例如通过 cgrulesengd：
*:bash pids users/shells/bash/
*:zsh pids users/shells/zsh/
还有一个设置 shell 限制的小脚本：
CGDIR=/sys/fs/cgroup/
mkdir -p $CGDIR/pids/users/shells/
echo '8192' > $CGDIR/pids/users/shells/pids.max
mkdir -p $CGDIR/pids/users/shells/bash/
echo '2048' > $CGDIR/pids/users/shells/bash/pids.max
mkdir -p $CGDIR/pids/users/shells/zsh/
echo '1024' > $CGDIR/pids/users/shells/zsh/pids.max
当我用 bash shell 启动一个终端并在其中执行:(){ :|:& };:时，什么都没有发生。我几乎立即得到 2048 pids.current，CPU 利用率为 50-60%。当我关闭终端时，叉形炸弹死了，一切恢复正常。
当我想用 zsh shell 对终端做同样的事情时，我会立即获得 100% 的 CPU，并且在关闭终端后，fork 炸弹仍然会杀死我的系统。解决此问题的唯一方法是在终端中发出几次killall -9 zsh，其中包含其他外壳。
为什么不能像在 bash 中一样在 zsh 中杀死 fork 炸弹？我的意思是，只要关闭终端，炸弹就会被引爆。
/sys/bus/usb/devices/usbX/authorized_default和 和有什么不一样/sys/bus/usb/devices/usbX/interface_authorized_default？基本上，这两个文件都负责拒绝将新连接的设备访问到 USB 端口，如此处所述。它们似乎以相同的方式工作，那么有什么区别？我应该使用哪一个？
基本上，EXT4 文件系统有大小为 128MiB 的数据块（默认情况下），这个块称为“组”或“块组”，在磁盘上基本上如下所示：
磁盘越大，一个接一个的组就越多。
当您使用该dumpe2fs工具时，它可以简单地告诉您您有多少个组，并返回一些关于它们的信息，例如：
Group 690: (Blocks 22609920-22642687) csum 0x7443 [ITABLE_ZEROED]
Block bitmap at 22544386 (bg #688 + 2), csum 0xab2a9072
Inode bitmap at 22544402 (bg #688 + 18), csum 0x1ef9c14a
Inode table at 22545440-22545951 (bg #688 + 1056)
0 free blocks, 8182 free inodes, 10 directories, 8182 unused inodes
Free blocks:
Free inodes: 5652491-5660672
我的问题是：如果您使用该dd工具将整个块组归零会发生什么？
如果您有一个（文件）足够小以完全适合该组，则该文件（文件）将永久丢失。但是还有其他情况，我不确定系统在这种情况下如何反应。
文件可以由许多块组进行分段和描述，这（在这种情况下）意味着文件的只有一部分被清零。运行后该文件会发生什么fsck？整个文件会放在 lost&found 目录中吗？或者也许它会在文件系统的结构中可见，但您将无法打开/访问它？
如果上面的组被清零，目录中的文件会发生什么？只有 info that 0 free blocks, 8182 free inodes, 10 directories, 8182 unused inodes，这意味着该组描述了 10 个 dirs 和 0 个文件，并且所有块都被数据使用。所以我们有 10 个目录，可能还有一些零散的大文件。至少我是这样理解信息的。但是目录可以包含文件，当您将该组归零时，目录中的文件会发生什么？之后它们可以访问fsck吗？