On Nov 2, 2014, at 10:31 PM, Andrei Borzenkov <arvidj...@gmail.com> wrote:
> В Sun, 2 Nov 2014 15:11:29 -0700 > Chris Murphy <li...@colorremedies.com> пишет: > >> >> On Nov 1, 2014, at 11:27 PM, Andrei Borzenkov <arvidj...@gmail.com> wrote: >> >>> В Sat, 1 Nov 2014 14:35:57 -0600 >>> Chris Murphy <li...@colorremedies.com> пишет: >>>> >>>> Why not have a dedicated partition with MBR type code for core.img, >>>> equivalent to BIOSBoot currently used on GPT? freedesktop.org has a >>>> proposal to use type code 0xEA for this purpose (in part). The boot.img >>>> code in the MBR can arbitrarily jump to any LBA, so 0xEA doesn't need to >>>> be a primary partition does it? >>>> >>> >>> It is rarely needed in simple cases; in complicated cases (btrfs or >>> LVM) we already have space dedicated for core.img. It seems more >>> logical to use this space. >> >> Well actually it isn't rare in simple cases. The most common case on Linux >> is booting from ext which grub won't embed to either without >> --force.xz_dec_lzma2 > > We are discussing installation in MBR here, not in partition. The point is that GRUB has difficulty even in the simple case because it either can't fit in the MBR gap, or something else could just as legitimately use the MBR gap. Right now the fallback depends on a complex matrix depending on the file system being used rather than the primary use case rarely depending on fallback because it's a sure thing and consistent regardless of file system used. > >> So we have to have core.img embedded somewhere else. UEFI it's a fixed > location. BIOS+GPT it's a fixed location. Only on MBR is it in an > unreserved location or forcibly embedded - that's really where the > problem is. It seems a lot simpler to constrain the MBR options down > to only a reserved partition just like elsewhere where it's now much > simpler because it can only properly go in one location. >> >> >>> Also you still need to tell grub-setup to use this special partition at >>> which point why not extend it to support arbitrary location for >>> core.img? It could be made check partition type and not refuse to >>> install on raw partition for special 0xEA type then as a bonus. >> >> I never tell grub-setup to use BIOSboot partition type. It always just finds >> it automatically. >> > > I do not really trust anyone respect partition types on MBR to be > honest. So I would rather avoid blindly overwriting anything without > explicit user's consent. These two things are orthogonal. Relying on the user to know even basic things about how computers boot, is unreasonable. They don't understand such things, they never will, and expecting them to is simply out of scope. If you don't trust others to respect partition types, then how do you trust them to respect non-partitioned regions like the MBR gap? The concept works quite well on UEFI and BIOS+GPT, I don't see why it should be any different on MBR, except for the small problem that we don't have as many type codes available. But certainly even that problem is more reliable than nothing at all. Chris Murphy _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
