On Thu, Nov 14, 2019 at 9:19 AM Andrei Borzenkov <arvidjaar@xxxxxxxxx> wrote: > > On Thu, Nov 14, 2019 at 12:50 AM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > But GRUB does have a way of detecting core.img on it, and > > No. GRUB does not "detect" core.img at all. On Legacy BIOS stage0 code > in MBR includes hardcoded absolute disk location of core.img (as list > of extents). Stage0 does not care whether this location is post-MBR > gap, BIOS boot partition or file inside another file system, it simply > loads absolute disk blocks and jumps to loaded code. > > > avoids overwriting it by preferring to write in free space within that > > partition, ostensibly to support multiple instances of GRUB (multiple > > distributions), > > Sorry? What are you talking about? grub-install does this, at least it's what someone on grub-devel@ list told me ages ago. > > and some degree of atomicity as the core.img is > > written first to this partition before the boot.img or "jump code" is > > written in the first 440 bytes of the MBR. > > > > core.img must match block list recorded in MBR; as soon as core.img is > overwritten in-place you cannot guarantee that whatever stage0 will > read matches what has been written if stage0 update was aborted for > whatever reasons. Yeah what I was told is grub-install tries not to overwrite core.img. Obviously if it's unavoidable, the update can't be atomic. > This is outside of scope of EFI, really. GRUB consists of two parts - > kernel (which is implicitly embedded in core.img/core.efi) and > loadable modules. They must match. So to ensure atomic update on any > architecture one has to > > 1. Write new core.img. > 2. Write new /boot/grub/$platform content (new modules). > 3. Switch boot information to use new version. The need to update modules is sort of a problem for atomicity too. > > On EFI this would simple mean to write grubx64.efi with different name > or location on ESP and then update EFI boot variable to point to it. > Like > > \EFI\vendor\image1\grubx64.efi > \EFI\vendor\image2\grubx64.efi Yes, although I'm not a fan of writes to NVRAM. They really should be minimized. It's not high wear NVRAM, and no way to replace it if it starts crapping out. > > If you want make it alternate between two independent ESP for > additional redundancy. > > /boot/grub/$platform is more involved, as a lot of code in grub2 > assumes location is always under /boot/grub ($prefix more precisely). > SUSE had to introduce concept of "mounting" subvolumes on btrfs as > quick hack to overcome it. > > On Legacy BIOS having two copy of core.img even more involved as it > likely really needs some primitive filesystem to manage multiple > copies. GRUB Is just too complicated. i'd really like to see it simplified and for sure no longer depend on os-prober. When distributions are considering things like petiboot, and linux as a bootloader, something's gotten too complicated. -- Chris Murphy
