George Robinson's questions

在搜索GRUB2Debian v9.11.0 “Stretch”的可用软件包时，我只beta列出了软件包：

root@Debian:~# apt search GRUB2
Sorting... Done
Full Text Search... Done
grub-imageboot/oldstable 0.6 all
  boot iso, harddisk and floppy images with grub2 and syslinux memdisk

grub2/oldstable,now 2.02~beta3-5+deb9u2 amd64 [residual-config]
  GRand Unified Bootloader, version 2 (dummy package)

grub2-common/oldstable 2.02~beta3-5+deb9u2 amd64
  GRand Unified Bootloader (common files for version 2)

grub2-splashimages/oldstable 1.0.1+nmu1 all
  a collection of great GRUB2 splashimages

live-wrapper/oldstable 0.6+nmu1 all
  Wrapper for vmdebootstrap for creating live images

live-wrapper-doc/oldstable 0.6+nmu1 all
  Wrapper for vmdebootstrap for creating live images (Documentation)

vmdebootstrap/oldstable 1.7-1 amd64
  Bootstrap Debian into a (virtual machine) disk image

如您所见，此搜索仅返回beta包。我不得不跳过箍来安装一个稳定的GRUB2包，请参阅： 如何在不安装 Beta 版本的情况下将 GRUB v1 升级到 GRUB v2？

问题：为什么 Debian “Stretch” 存储库首先只包含 beta版本GRUB2？毕竟，稳定GRUB版 v2.00 是在 Debian “Stretch”发布前 5 年发布的，请参见此处： ftp.gnu.org/gnu/grub

这是此发行版存储库中的错误吗？

我的 Linux Debian v9.11.0 (Stretch) 目前已经GRUB1安装。

root@Debian:~# grub-install -v
grub-install (GNU GRUB 0.97)

我的其他 Ubuntu Linux 已GRUB2安装：

root@Ubuntu:~# grub-install -V
grub-install (GRUB) 2.02+dfsg1-20

我想安装GRUB2，但如果我尝试在 Debian 上安装它，安装apt-get install grub2的是 beta 版本GRUB2！

root@Debian:~# grub-install -V
grub-install (GRUB) 2.02~beta3-5+deb9u2

我不想要这个 beta 版本——我想要一个稳定的版本，GRUB2就像 Ubuntu 已经安装的版本一样。

GRUB2从 Debian搜索可用软件包时，我只得到beta列出的软件包：

root@Debian:~# apt search GRUB2
Sorting... Done
Full Text Search... Done
grub-imageboot/oldstable 0.6 all
  boot iso, harddisk and floppy images with grub2 and syslinux memdisk

grub2/oldstable,now 2.02~beta3-5+deb9u2 amd64 [residual-config]
  GRand Unified Bootloader, version 2 (dummy package)

grub2-common/oldstable 2.02~beta3-5+deb9u2 amd64
  GRand Unified Bootloader (common files for version 2)

grub2-splashimages/oldstable 1.0.1+nmu1 all
  a collection of great GRUB2 splashimages

live-wrapper/oldstable 0.6+nmu1 all
  Wrapper for vmdebootstrap for creating live images

live-wrapper-doc/oldstable 0.6+nmu1 all
  Wrapper for vmdebootstrap for creating live images (Documentation)

vmdebootstrap/oldstable 1.7-1 amd64
  Bootstrap Debian into a (virtual machine) disk image

如何在 Debian 上安装非 beta版本？GRUB2

Netfilter 的扩展手册页指出：

MASQUERADE：这个目标只在nat表中有效，在POSTROUTING链中

问题：如何使用目标克隆目标的输出？MASQUERADETEE

如果您查看下图netfilter/iptables，您会注意到这nat.POSTROUTING是在将数据包发送到出站接口之前要评估的最后一个链。没有raw.POSTROUTING链条，……或者有吗？

也看到这个。

PS当数据通过这些接口（出口和入口）以相反方向流动时，在and接口以相同顺序
处理mangle和表的基本原理是什么？natoutboundinbound

iptables-mod-tee当我添加这样的规则时，打包后的克隆是否被克隆了？：

iptables -t mangle -A POSTROUTING -o eth2 -j TEE --gateway 192.168.0.3

请参考下图。我认为很明显，使用上面的命令，iptables-mod-tee模块使用 的POSTROUTING chain作为mangle table克隆源，但是数据包被克隆后会发生什么？即克隆去哪个链和表？

编辑：在上图中添加了一条红色虚线，以描述答案中描述的克隆数据包的路径。

以下引导日志中列出的 MTD 分区的命名方案是什么？

5 cmdlinepart partitions found on MTD device phys_mapped_flash
Creating 5 MTD partitions on "phys_mapped_flash":
0x00000000-0x00080000 : "bootloader" 
0x00080000-0x00680000 : "kernel"
0x00680000-0x01680000 : "rootfs" 
0x01680000-0x01780000 : "data"
0x01780000-0x017a0000 : "bootload-env"

特别是，我询问使用什么命名方案来指定 U-Boot 提示符中的“rootfs”分区作为命令的参数：

setenv bootargs 'root= ???????'

IMO，我需要指定root= 因为引导日志显示内核不知道根设备是什么。

VFS: Cannot open root device "<NULL>" or unknown-block(0,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

...而且启动日志显示：

Kernel command line:  bootoctlinux 0x2a00200 mtdparts=phys_mapped_flash:512k(bootloader)ro,6M(kernel),16M(rootfs),1024k(data),128k(bootload-env) console=ttyS0,115200

顺便说一句：根文件系统作为 gzip 压缩的 cpio 存档存储在内核 ELF 文件 (vmlinux64) 的嵌入式部分 (.init.ramfs) 中，并且引导日志表明它已成功加载到 RAM 中：

Loading .init.ramfs @ 0xffffffff806ac000 (0x185ac7 bytes)

这是在仅具有 32MB 闪存存储的嵌入式系统上（Linux 内核 v2.6.21.7（发行版：Cavium-Octeon for MIPS64））。
U-Boot 1.1.1（开发版本，svnversion：176）

编辑： 有人说是 MTD1，有人说是 MTD2，有人说是 /dev/MTD1，有人说是 /dev/mtd1，有人说是 MTDblock1，有人说是 mtdblock1，有人说是 mtdblock2，有人说是 ubi.mtdblock1，有人说是 ubi:mtdblock1，（为什么是冒号?) 等等....
真相是什么？如何仅从 U-Boot 提示符或引导日志中发现它？

以下引导文件 (vmlinux64) 适用于 Linux 内核 v2.6.21.7（发行版：Cavium-Octeon for MIPS64）：

ELF HEADER:
------------------------------------------
Magic: 0x7f 0x45 0x4c 0x46 ("ELF")
Class: 64-bit
Encoding: Big-Endian
ELF version: 1
OS ABI: System V
ABI Version: 0
Type: ET_EXEC
Machine: MIPS
Version: 1
Entry Point: 0xffffffff804b0000
Program Headers Offset: 0x40
Section Headers Offset: 0x572C70
Flags: 0x808b0001
ELF Header Size: 0x40
Program Header Entry Size: 0x38
Program Header Entries: 1
Section Header Entry Size: 0x40
Section Header Entries: 0x21
.shstrtab Index: 0x20

有这些段和部分：

_______________________________________________________________________________________________
PROGRAM HEADERS:
_______________________________________________________________________________________________
Index Type    Flags           SizeInMem  MemVirtAddress      FileOffs  SizeInFile
-----------------------------------------------------------------------------------------------
0    PT_LOAD  Write+Read+Exec 0x5AB200   0xffffffff80100000  0x4000    0x56EAC7                                           

_______________________________________________________________________________________________
SECTION HEADERS:
_______________________________________________________________________________________________
Index Name                   Type        Flags        MemVirtAddress      FileOffs  SizeInFile
-----------------------------------------------------------------------------------------------
0                            K_NULL                                  0x0       0x0       0x0
1   .text                    K_PROGBITS  Alloc+Exec   0xffffffff80100000    0x4000  0x30DFE8
2   __ex_table               K_PROGBITS  Alloc+       0xffffffff8040dff0  0x311FF0    0x5EA0
3   __dbe_table              K_PROGBITS  Alloc+       0xffffffff80413e90  0x317E90       0x0
4   .rodata                  K_PROGBITS  Alloc+       0xffffffff80414000  0x318000   0x48B68
5   .pci_fixup               K_PROGBITS  Alloc+       0xffffffff8045cb68  0x360B68     0xB20
7   __ksymtab                K_PROGBITS  Alloc+       0xffffffff8045d688  0x361688    0x8EA0
8    __ksymtab_gpl           K_PROGBITS  Alloc+       0xffffffff80466528  0x36A528    0x2580
17  __ksymtab_strings        K_PROGBITS  Alloc+       0xffffffff80468aa8  0x36CAA8    0xEBA8
18   __param                 K_PROGBITS  Alloc+       0xffffffff80477650  0x37B650     0x6E0
19  .data                    K_PROGBITS  Alloc+Write  0xffffffff80478000  0x37C000   0x2FD20
20  .data.cacheline_aligned  K_PROGBITS  Alloc+Write  0xffffffff804a8000  0x3AC000    0x7280
21  .init.text               K_PROGBITS  Alloc+Exec   0xffffffff804b0000  0x3B4000   0x31270
22  .init.data               K_PROGBITS  Alloc+Write  0xffffffff804e1270  0x3E5270    0x3708
23  .init.setup              K_PROGBITS  Alloc+Write  0xffffffff804e4980  0x3E8980     0x5B8
24  .initcall.init           K_PROGBITS  Alloc+Write  0xffffffff804e4f38  0x3E8F38     0x6D8
25  .con_initcall.init       K_PROGBITS  Alloc+Write  0xffffffff804e5610  0x3E9610      0x10
27  .exit.text               K_PROGBITS  Alloc+Exec   0xffffffff804e5620  0x3E9620    0x30C0
28  .init.ramfs              K_PROGBITS  Alloc+       0xffffffff804e9000  0x3ED000  0x185AC7
32  .shstrtab                K_STRTAB                                0x0  0x572AC7     0x1A7
6   .rio_route               K_PROGBITS  Write        0xffffffff8045d688  0x572AC7       0x0
9   __ksymtab_unused         K_PROGBITS  Write        0xffffffff80468aa8  0x572AC7       0x0
10  __ksymtab_unused_gpl     K_PROGBITS  Write        0xffffffff80468aa8  0x572AC7       0x0
11  __ksymtab_gpl_future     K_PROGBITS  Write        0xffffffff80468aa8  0x572AC7       0x0
12  __kcrctab                K_PROGBITS  Write        0xffffffff80468aa8  0x572AC7       0x0
13  __kcrctab_gpl            K_PROGBITS  Write        0xffffffff80468aa8  0x572AC7       0x0
14  __kcrctab_unused         K_PROGBITS  Write        0xffffffff80468aa8  0x572AC7       0x0
15  __kcrctab_unused_gpl     K_PROGBITS  Write        0xffffffff80468aa8  0x572AC7       0x0
16  __kcrctab_gpl_future     K_PROGBITS  Write        0xffffffff80468aa8  0x572AC7       0x0
26  .security_initcall.init  K_PROGBITS  Write        0xffffffff804e5620  0x572AC7       0x0
29  .sbss                    K_PROGBITS  Alloc+Write  0xffffffff8066f000  0x572AC7       0x0
30  .bss                     K_NOBITS    Alloc+Write  0xffffffff80670000  0x572AC7   0x3AEF0
31  .cvmx_shared_bss         K_NOBITS    Alloc+Write  0xffffffff806aaef0  0x572AC7     0x310  
_______________________________________________________________________________________________

请注意，此 ELF 文件有一个嵌入的 1558kB init.ramfs 部分，其中包含对操作系统至关重要的文件。这部分是 gzip 的，包含一个包含 1805 个文件和目录的 cpio 存档。

根据： Kernel.org 和 Wikipedia，Linux Kernel cpio 提取器将这个 init.ramfs 部分解压缩到内存中的某个位置。

我的问题是：

1. 是什么决定了提取 cpio 存档内容的内存地址？
2. 提取后，内核如何找到特定文件的数据的内存地址，...例如 /sbin/init 文件？
3. cpio 存档的内容是否被提取到某种文件系统中，允许内核稍后找到这些文件......或者这些文件的内存地址是否在内核代码中硬编码？

回复：问题 1：我不认为 .init.ramfs 部分可以解压缩到 ELF 文件的部分标题中所述的 0xffffffff804e9000 内存地址，因为在下一部分之前只有 1560kB 可用空间（“. sbss") 从内存中的 0xffffffff8066f000 开始，而 ungzip 的 cpio 存档占用 4035kB。