Re: Why special linux code in grub2/util/grub-setup.c

[Chris Murphy]

Summary: a way for grub-install to support installation to a partition when 
formatted ext[234], without --force and blocklists.


On Jul 25, 2013, at 3:17 PM, Vladimir 'φ-coder/phcoder' Serbinenko 
<address@hidden> wrote:
>> 
>> The embedding zone is not accessible and could not be changed. This
>> ensure, that block lists keep stable.
>> 
>> If you want to change the content, then you have to install a new file
>> using IOCTL (and you will get back the previous embedded file in exchange).
>> 
> That's a problem since the old zone will stay here and it's one of big 
> vectors of problems with blocklists. This approach actually *ensures* that 
> blocklist will *change* every time so it makes some simultaneous 
> installations impossible and will create an illusion that any lingering 
> bootsector is still active. Better way would be:
> 1) have a way to reserve some space, near the beginning. E.g. IOCTL 
> CREATE_EMBEDDING_ZONE with argument size=5M (number coming from my draft on 
> LVM zones). This has to have synchronous semantics. Blocklist is fixed after 
> this operation.
> 2) A way to retrieve its blocklist
> 3) A way to overwrite parts of its contents in a way that ensures bypassing 
> journal, COW, compression, encryption, hyperspace or any other advanced 
> features.

5MB? The current BIOS Boot is 1MB. And the Btrfs pad is 64KB. Are these still 
sufficient?

I'm uncertain of the scope, but the following bug indicates potentially 
widespread use of LBA 36 as a start LBA by Dell, which leaves a totally 
insufficiently sized MBR gap to install GRUB:

https://bugzilla.redhat.com/show_bug.cgi?id=986431

It seems there should be a way to accommodate this automagically by any 
installer, presently they'll fail when installing to the disk device, i.e. 
/dev/sda, where --force isn't applicable. It seems there'd need to be a test 
for a sufficiently large MBR gap, and if not fallback to a way to embed into a 
boot partition.


Chris Murphy