Hi, Adrian. ---- On Sat, 14 Sep 2024 17:56:17 +0400 adrian15sgd wrote --- > Well, that needs more detailed explanation.
Debian has 4 signed GRUB images ( https://salsa.debian.org/grub-team/grub/-/blob/master/debian/build-efi-images?ref_type=heads ) (I will refer to this file as "build-efi-images"): - gcdx64.efi - grubx64.efi - grubnetx64.efi - grubnetx64-installer.efi (Note that in this letter I will use the latest version of "build-efi-images", available at link above.) (Again: versions of involved software matter. For example, as well as I understand, bookworm version of "build-efi-images" differs from the git version. So, when reading this letter use versions I use.) So far when I wrote my previous letters I kept in mind grubx64.efi, not gcdx64.efi . And I wrote about boot process of debian installer, not debian live. Debian installer uses grubx64.efi and debian live uses gcdx64.efi . So, again: all I wrote in my previous letters applies to debian installer with grubx64.efi, not to debian live with gcdx64.efi . Okay, now let me describe how boot process works. First I will talk about debian installer, and then about debian live. I got all this information from experiments. Also: I suggest grubx64.efi as opposed to gcdx64.efi for super grub disk for reasons explained below. Part 1. Debian installer. I will use this image https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso . Note that this image (specially: iso fs) contains file /.disk/mkisofs, which contains the exact xorriso invocation, which created this image. Iso fs contains file /boot/grub/efi.img , which is ESP partition (EFI System Partition). This partition (i. e. fat fs) contains these 3 files: /efi/boot/bootx64.efi , /efi/boot/grubx64.efi and /efi/debian/grub.cfg . (Yes, we see /efi here, not /EFI, but this is not important, because this is a FAT filesystem, and so it is case-insensitive.) Main fs, i. e. iso fs, contains exactly the same files (but with EFI, not efi). Part 1.1. UEFI CD boot Firmware executes /efi/boot/bootx64.efi from ESP (which is shim). The shim executes /efi/boot/grubx64.efi from ESP (which is grubx64.efi , not gcdx64.efi). grubx64.efi loads /EFI/debian/grub.cfg from iso fs (not from ESP). grubx64.efi does this, because this path is hardcoded in the binary. It is hardcoded, because "build-efi-images" builds grubx64.efi using 'grub-mkimage -p "/EFI/$efi_vendor" ...', and $efi_vendor is "debian". grubx64.efi has no "early config". Also grubx64.efi has memdisk, but the memdisk doesn't have any configuration, so memdisk doesn't affect boot logic. Okay, so /EFI/debian/grub.cfg from iso fs is loaded. This is a short file, which finds iso fs root using "search --file --set=root /.disk/id/dae2967f-d173-4909-90fd-7cb26e6945dc". In this particular case this is not needed, because $root is already set to iso fs. So this "search" is no-op. Then /EFI/debian/grub.cfg sets $prefix and loads /boot/grub/x86_64-efi/grub.cfg from iso fs, which is "real" grub config. Part 1.2. UEFI USB boot Exactly the same thing happens as we know from UEFI CD boot. With the following changes. grubx64.efi loads /EFI/debian/grub.cfg from ESP, not from iso fs. (But these two files are same anyway.) Then this /EFI/debian/grub.cfg performs "search --file --set=root /.disk/id/dae2967f-d173-4909-90fd-7cb26e6945dc", and this time this "search" is not no-op. It actually matters. Because it changes $root from ESP to iso fs. Then /EFI/debian/grub.cfg sets $prefix and loads /boot/grub/x86_64-efi/grub.cfg from iso fs, which is "real" grub config. Part 2. Debian live I will use https://cdimage.debian.org/cdimage/weekly-live-builds/amd64/iso-hybrid/debian-live-testing-amd64-standard.iso This image also contains /.disk/mkisofs , which contains xorriso invocation. This image (i. e. iso fs) contains /boot/grub/efi.img , which is ESP partition. ESP contains 3 files: /EFI/boot/bootx64.efi (shim), /EFI/boot/grubx64.efi (this is actually gcdx64.efi , as opposed to debian installer) and /boot/grub/grub.cfg . These 3 files are NOT identical to corresponding files on iso fs (as opposed to debian installer). I. e. bootx64.efi and grubx64.efi seem to be identical. But /boot/grub/grub.cfg is not. Part 2.1. UEFI CD boot Firmware executes /EFI/boot/bootx64.efi from ESP. bootx64.efi executes /EFI/boot/grubx64.efi from ESP. grubx64.efi (which is actually gcdx64.efi), as opposed to real grubx64.efi , contains so-called early config. I know this, because in "build-efi-images" I see that gcdx64.efi is generated using "grub-mkimage -c ... ...". Option "-c" means early config. That early config loads grub.cfg from memdisk. Memdisk's grub.cfg is a complicated "if"-based script. You can see it in "build-efi-images". I will not explain in detail how this "grub.cfg" works. (But if you want, I can explain it.) Anyway, this "grub.cfg" loads /boot/grub/x86_64-efi/grub.cfg from iso fs (we booted using UEFI CD, so $root is already set to iso fs). /boot/grub/x86_64-efi/grub.cfg from iso fs loads /boot/grub/grub.cfg from iso fs, which is the main config. Part 2.2. UEFI USB boot Everything is the same as part 2.1 with the following changes. When grub.cfg from memdisk is executed, $root is set to ESP, not to iso fs. So grub.cfg from memdisk executes differently. (Again, I will not get into details about how it is executed, but you can ask me.) This time grub.cfg from memdisk loads /boot/grub/grub.cfg from ESP. This /boot/grub/grub.cfg executes "search --set=root --file /.disk/info". This command finds the real root, i. e. iso fs. I. e. this command changes $root from ESP to iso fs. Of course, this is very fragile, because we simply switch to whatever disk, which contains /.disk/info . This will not work if our system has multiple live debian disks inserted. I think this is a bug, so I reported it to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081041 . So I suggest using grubx64.efi as opposed to gcdx64.efi for super grub disk. Okay, so /boot/grub/grub.cfg from ESP executed "search" and set $root. Then this /boot/grub/grub.cfg sets $prefix and loads /boot/grub/grub.cfg from iso fs, which is the main config. Small note: I'm 100% sure about how debian installer boot process works. Because I did a lot of experiments. And I'm 90% sure about how debian live boot process works. Because I didn't perform any experiments with debian live. I simply applied my knowledge, gained from debian installer experiments, to debian live boot process. So, we get 90% only, not 100%. My main doubt about debian live boot process is how grub.cfg from memdisk is executed. I didn't do any experiments with this grub.cfg, I simply have read it and executed in my head. printf-debugging would be certainly better. I. e. what I really should do is to insert "echo" commands to this grub.cfg, then regenerate gcdx64.efi (using code from "build-efi-images") (unsigned, of course), then regenerate debian live image (for example, by reexecuting command from /.disk/mkisofs ) and then run it in qemu. I did not do this, you can do this if you want. I can explain in more detail how to do this, this is easy. But again: I'm 90% sure about how debian live boot process works. 90% is a high probability. Okay, so hopefully I explained everything. If you have any questions, ask me. Also: when I said "GRUB searches for files in ISO fs when booted from CD (in UEFI mode)", I meant that GRUB itself (not any kind of configs) sets $root to iso fs, when booted as UEFI-CD. This is how GRUB itself works, this is not related to Debian GRUB images or any particular configs. It is even possible that reasons are even deeper, i. e. reason is not GRUB, but UEFI itself or something. Anyway, when we boot using UEFI-CD, $root is set to iso fs, and when we boot using UEFI-USB, $root is set to ESP. This applies to all GRUB images, not necessary to Debian GRUB images. And we should keep this in mind when we execute any kind of GRUB configs in our heads. But there is a note here: this applies in these two situations: 1. GRUB image was generated without memdisk 2. GRUB image was generated with memdisk, but when generating -p option (to grub-mkimage) was set after -m option In these two situations $root will be set as I described above (I know this from experiments). There is also 3rd situation: 3. GRUB image was generated with memdisk, and there was no -p option after -m Well, I don't know what will happen in this case, I didn't do experiments on this. Also, my algorithm on determining $root applies if prefix set using -p option to grub-mkimage starts with "/", for example, /boot/grub. I don't know what will happen if it starts from "(" or anything else. > A Debian live cd as you have pointed out reuses a gcdx64.efi file. Yes. > That gcdx64.efi file has an embedded memdisk with a special grub.cfg. Yes. As I explained above, first early config is executed, then it executes grub.cfg from memdisk. > Then that special grub.cfg finds those CD files and configfiles to there. Yes. I explained above how this happens. Also, it "sources", not "configfiles", according to "build-efi-images" from current git. > As I want to be able to read the ElTorito image contents somehow I don't know terminology here well. What do you mean by ElTorito image? You mean ESP partition? And you want to extract ESP partition from official debian live image? This is easy. Mount iso image. You will see xorriso command in /.disk/mkisofs . That command mentions /boot/grub/efi.img . So this is ESP. Just mount it. > I am > actually trying to build a barebones Grub ElTorito image for UEFI CD > boot in my Rescatux development streams. I can help. Just tell exactly what you are trying to build. GRUB image? I. e. what is generated by grub-mkimage? Or .iso? Or both? Or ESP?! Tell in detail what you want to build and I will give you commands to do this. > I want to check what actually happens in that scenario without an > embedded memdisk. Again: tell in details what you want to check. I will try to give you commands. -- Askar Safin https://types.pl/@safinaskar _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
