问从GRUB2引导位于LVM上的ISO文件

EN

正如frostschutz所说，在内核命令行参数中添加live-media=/dev/mapper/Fedora-root findiso=ISO/kali-linux-2019.1a-amd64.iso是有效的。因此，这就是新的菜单条目的外观。

menuentry "Kali Live ISO - findiso" --class gnu-linux {
  insmod lvm
  insmod ext2
  set root="lvm/Fedora-root"
  search --no-floppy --fs-uuid --set=root --hint=${root} 29e2f518-5fad-49c9-90ef-966b0c033c5e
  set isofile="/ISO/kali-linux-2019.1a-amd64.iso"
  loopback loop $isofile
  linux (loop)/live/vmlinuz boot=live live-media=/dev/mapper/Fedora-root findiso=ISO/kali-linux-2019.1a-amd64.iso noconfig=sudo username=root hostname=kali
  initrd (loop)/live/initrd.img
}

原来kali initramfs不支持iso-scan/filename=参数。

你可能是因为误会而被困住了。

Grub天生无法启动任何ISO。

是的，Grub可以解密加密的设备，理解RAID和LVM，安装大量的文件系统，甚至是循环挂载ISO。但是所有这些花哨的功能只有一个目的：

加载内核和initrd。

最后，Grub仍然只是一个引导加载程序。

一旦您能够加载内核和initrd，这并不重要，您让Grub跳过什么箍。结果与直接将这两个文件复制到一个简单的未加密的/boot分区完全一样。

mount -o loop kali-linux-2019.1a-amd64.iso /mnt/iso
cp /mnt/iso/live/{vmlinuz,initrd.img} /boot/kali

然后像这样引导它：

menuentry "Kali Live ISO" {
    linux kali/vmlinuz ...parameters...
    initrd kali/initrd.img
}

如果这两个文件(vmlinuz和initrd.img)是从相应的ISO文件中提取的，则与您的文件相同。

这是一回事真的。Grub只是想要这两个文件，不管怎么做。您可以使用任何可以加载内核和initrd的引导加载程序来引导ISO，所有这些都不依赖于Grub的奇特特性(尽管它可能更方便)。

所以Grub只加载内核，传递一些内核参数和initrd，仅此而已。一旦加载了内核，就没有LVM、没有(循环)和ISO。不管Grub做了什么，都会被内核本身所取代。

那么，ISO是如何启动的呢？

它会自动启动。这就是为什么您必须将ISO的文件名作为内核参数传递，因此它知道要查找哪个文件。如果默认文件名是在ISO initramfs中硬编码的，那么即使这也是可选的。

然后，ISO的initramfs中有一些代码可以遍历所有存储设备，挂载所有文件系统，并搜索这个文件。当它找到文件时，它会循环挂载它。

这就是它的工作原理，实现这个功能的不是Grub，而是ISO本身，并且取决于这个实现(如果有一个实现--否则它就不能工作)，它可能支持也可能不支持在LVM逻辑卷上定位这个文件，甚至支持RAID和加密。

尤其是卡利，我不知道这是否可能。我试着阅读一下Kali的initramfs代码，而iso-scan/filename=似乎根本不存在，相反，它应该是findiso=，在它前面加上一个/dev/mapper/路径，或者用live-media=单独补充它可能会启用LVM支持。

但是我自己还没有试过，而initramfs很难破解，所以你必须自己做实验/调查，或者把这个问题带到Kali社区。

或者，只需将ISO文件放在一个更容易到达的位置(常规分区)。

我确认了启动ISO的可能性，这是在Grub 2.00的逻辑卷上进行的。在我的例子中，我有一个惟一的LVM类型的分区MBR (整个磁盘)。我只有两个LV(启动和iso)，我可以启动这个ubuntu-18.04.2-桌面-amd64.iso。不幸的是，由于casper (ubuntu的livecd机制)能力不足，我在initramfs中修复了一个文件(但没有修改iso)。

对于卡利来说，是的，最后一个解决方案是有效的，而且它更简单