[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Xen
Subject: Re: Force location of GRUB's boot and core images ?
Date: Sun, 09 Apr 2017 12:09:38 +0200
User-agent: Roundcube Webmail/1.2.4

Pascal Hambourg schreef op 09-04-2017 10:14:

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]