Re: Force location of GRUB's boot and core images ?

[Xen]

Pascal Hambourg schreef op 09-04-2017 10:14:
> Hello,
>
> In some cases I would need to force installation of GRUB's boot and
> core images into a specific location on the drive instead of letting
> grub-install decide automatically.
>
> For example :
> - install the boot image in the first sector of an unformatted 
> partition
> - install the core image in the second and next sectors of that 
> partition.

Do you mean that the partition being unformatted makes a difference?

Andrei alludes that only a partition with a filesystem will have code 
(in Grub) to deal with the issue.

In the grub-pvinstall patch that I was never able to complete there is 
code that will check a PV's structure in order to determine whether 
there is an area to embed into.

Initially there were issues with libblkid not recognising a PV when 
there was a MBR in there, so if the first sector was MBR, and the second 
sector was PV, it would not recognise the PV and call it an MS-DOS 
partition table (dos) even though there was none; based only on the MBR 
signature.

This got fixed in version 2.29 of libblkid which didn't make it into 
Ubuntu until version 17.04 I believe, which is the upcoming release I 
guess.

So in/after version 17.04 of Ubuntu it would be possible to have 
auto-activation of a PV directly on disk WITH a preceding MBR in which 
Grub was installed.

At least -- autoactivation failed before because the udev script for LVM 
would skip devices that were not recognised as LVM2-member.

The same thing happens with disks that have a "RAID" signature at the 
end, getting recognised as that raid disk and not as what is in front. 
But in that case it'd be your responsibility to just wipe that signature 
if you are not using that.

There were some unanswered questions for this patch, such as:

- should it be allowed to install on a PV that has no VG? Perfectly 
possible just the original code (of the patch) used some VG specific 
code (in Grub) to determine whether we had a valid PV; this could be 
avoided by using PV-header routines directly.

- Andrei insisted that the filesystem check needed to be used (the one 
you can avoid with -s) even though the filesystem check would prevent 
installation on a PV and as such only installation with use of the -s 
flag (to grub-install) would succeed; I did not understand this.

- I needed to study the actual code of the patch because my testing 
revealed that the code would 'validate' installation on a previous-valid 
PV that had since been overwritten with an invalid PV; what I mean is 
that an older PV with an embedded area would somehow give the green 
light to a current PV without embedded area; so the check was done wrong 
and some left-over data from the previous PV on that disk would be used 
instead of the actual current data on disk for some reason.

Other than that the patch worked flawlessly and I am using it to this 
day.

Regards.