Bug 18761 - Installer allows grub2 on a partition but writes no PBR
Summary: Installer allows grub2 on a partition but writes no PBR
Status: RESOLVED WONTFIX
Alias: None
Product: Mageia
Classification: Unclassified
Component: Installer (show other bugs)
Version: Cauldron
Hardware: i586 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Mageia tools maintainers
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 416
  Show dependency treegraph
 
Reported: 2016-06-22 17:18 CEST by Frank Griffin
Modified: 2020-02-17 00:07 CET (History)
10 users (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments

Description Frank Griffin 2016-06-22 17:18:23 CEST
The installer Summary->Bootloader allows you to choose grub2-graphical on the freshly installed partition, but writes no PBR on the partition to be the target of a chainloader directive from a standard MBR/PBR bootloader.  This applies, of course, to grub-legacy chainloader, but applies equally well to any other legacy bootloader which expects to find a PBR to which to pass control.

I've verified that the PBR of my fresh grub2 partition install is all zeros.

In googling this, I find some solutions which I cannot reconcile with MGA6.  The most common one is to use the --force option on grub-install, e. g.
                 grub-install --force /dev/sdaX
The problem is, on MGA6 grub-install is part of legacy grub and not of grub2, so I have no idea what to use in place of grub-install.

There is a workaround for legacy grub in the MBR which involves a legacy grub entry to invoke the grub2 core.img on /dev/sdaX directly, but this obviously won't work for non-legacy-grub BIOS bootloaders, and it's undesirable even for grub-legacy since it introduces a partition bootloader type dependency into the MBR, as opposed to chainloader which doesn't care.

grub2 supports chainloading, but without a PBR I don't see how even grub2 could chainload to a grub2 partition.

A related problem is that there is no message indicating that any sort of error occurred.
Adrien Guichard 2016-06-22 17:45:02 CEST

CC: (none) => guichard.adrien

Comment 1 Thierry Vignaud 2016-06-22 19:02:32 CEST
If you choose not to write to a partition (which is a feature asked by some users), you must  chainload from another bootloader installed in the PBR.

For grub2, you have grub2-install...

CC: (none) => thierry.vignaud, zen25000

Comment 2 Thierry Vignaud 2016-06-22 19:03:05 CEST
We can add a warning when such a choice is done.
Comment 3 Frank Griffin 2016-06-22 19:26:41 CEST
I did the following from another working partition (most would be unnecessary in the installer):

[root@ftglap ~]# mount --bind /dev /mnt/disk/dev
[root@ftglap ~]# chroot /mnt/disk
[root@ftglap /]# mount -t proc none /proc
[root@ftglap /]# mount -t sysfs none /sys
[root@ftglap /]# mount -t tmpfs none /run
[root@ftglap /]# systemd-tmpfiles --create
[root@ftglap /]# rm -f /run/nologin
[root@ftglap /]# grub2-install --force /dev/sda1
Installing for i386-pc platform.
grub2-install: warning: File system âext2â doesn't support embedding.
grub2-install: warning: Embedding is not possible.  GRUB can only be installed in this setup by using blocklists.  However, blocklists are UNRELIABLE and their use is discouraged..
Installation finished. No error reported.

/dev/sda1 is the partition to which the fresh install was done, and I verified that after this there *was* a valid PBR on /dev/sda1.

I'll reboot this now to see if it actually works.  If it does, I'd say we need to use --force when a user selects a partition for bootloader install.
Comment 4 Frank Griffin 2016-06-22 19:49:37 CEST
Worked like a charm.  I'm only familiar with BIOS bootloading, so I don't know how applicable this is to other arrangements, but for BIOS booting it looks like we only need --force to make things work.

The reason the grub2 devs don't like partition installs is because grub2 is dependent on the physical location of the core.img file (shades of lilo) and they prefer to put core.img on a part of the disk outside of any filesystem so that it can't be moved.  For a partition install it has to be under the partiton's /boot/grub2, and can be moved by filesystem compaction or whatever.  But, for some reason, they don't mark core.img as immutable, which would prevent this.  Maybe *we* should.
Comment 5 Thomas Backlund 2016-06-22 20:16:31 CEST
I wonder if we should try to add support for this in some "expert mode" ?

CC: (none) => tmb

Comment 6 Frank Griffin 2016-06-22 21:39:53 CEST
I'd say not, because we present it to the user as an option in normal mode.  If we do that but implement it in a way we *know* is going to fail, that's not good.

We could put up a popup saying essentially what the grub2-install messages say, or something slightly more friendly, in an "are you sure" fashion.  Because you know that 99% of the people who say "install on a partition" actually *do* want to install on that partition and aren't going to give a rat's whatever about the grub2 devs' preferences.

On the other hand, if we just use --force and make core.img immutable, the grub2 devs' concerns won't really come back to bite the user, so one could argue that there's no real reason to give users apprehension about a situation that will never occur.

The downside to immutable is that if they try to regenerate it, the effort would fail.
Felix Miata 2016-06-22 22:08:35 CEST

CC: (none) => mrmazda

Comment 7 Barry Jackson 2016-06-23 00:48:34 CEST
It is by design that grub2 does not write to the PBR for all the good reasons that grub2 upstream point out.

There is no need to do this as grub2 reads file systems and can access core.img without using blocklists so there is no need for immutable or any other undue complication.

The "install to partition" really means "don't write anything to MBR (PC-BIOS) or ESP (UEFI) but just install/update the grub2 files in /boot/grub2/, including core.* so the current 'master' bootloader is not clobbered.

Doing this means of course that the user will arrange for an entry to be made in their preferred 'master' bootloader as was always the case with legacy.

I have been chainloading/multibooting into grub2 this way since before Mageia 1.

A typical entry in another 'master' grub2's grub.cfg for chainloading (UEFI) would be:

menuentry 'Mageia 6 on /dev/sdb2' {
search --no-floppy --fs-uuid --set=root "e5e0b591-1a33-4c25-b18e-aa32de5903bc"
chainloader /boot/grub2/x86_64-efi/core.efi
}

In a PC-BIOS setting the following would be suitable:

menuentry 'Mageia 6 on /dev/sdb2' {
search --no-floppy --fs-uuid --set=root "e5e0b591-1a33-4c25-b18e-aa32de5903bc"
chainloader /boot/grub2/i386-pc/core.img
}

The above (UEFI) entry is from my 'master' grub2 bootloader generated by this script: https://wiki.mageia.org/en/User_talk:Barjac

I hope that helps,

Barry
Comment 8 Frank Griffin 2016-06-23 05:57:50 CEST
(In reply to Barry Jackson from comment #7)
> It is by design that grub2 does not write to the PBR for all the good
> reasons that grub2 upstream point out.
> 
> There is no need to do this as grub2 reads file systems and can access
> core.img without using blocklists so there is no need for immutable or any
> other undue complication.
> 
> The "install to partition" really means "don't write anything to MBR
> (PC-BIOS) or ESP (UEFI) but just install/update the grub2 files in
> /boot/grub2/, including core.* so the current 'master' bootloader is not
> clobbered.
> 
> Doing this means of course that the user will arrange for an entry to be
> made in their preferred 'master' bootloader as was always the case with
> legacy.
> 
> I have been chainloading/multibooting into grub2 this way since before
> Mageia 1.
> 
> A typical entry in another 'master' grub2's grub.cfg for chainloading (UEFI)
> would be:
> 
> menuentry 'Mageia 6 on /dev/sdb2' {
> search --no-floppy --fs-uuid --set=root
> "e5e0b591-1a33-4c25-b18e-aa32de5903bc"
> chainloader /boot/grub2/x86_64-efi/core.efi
> }
> 
> In a PC-BIOS setting the following would be suitable:
> 
> menuentry 'Mageia 6 on /dev/sdb2' {
> search --no-floppy --fs-uuid --set=root
> "e5e0b591-1a33-4c25-b18e-aa32de5903bc"
> chainloader /boot/grub2/i386-pc/core.img
> }
> 
> The above (UEFI) entry is from my 'master' grub2 bootloader generated by
> this script: https://wiki.mageia.org/en/User_talk:Barjac
> 
> I hope that helps,
> 
> Barry

Thanks, Barry, but you're missing the point.  For one thing, A lot of us simply want to put up a fence so that each partition relies on its own bootloader software.  For another, your solution won't work for non-grub-legacy bootloaders which chainload to a PBR and won't go looking for a core.img on any filesystem regardless of what it is.

I remember arguments about this going back several years, and grub2 still allows partition installs in spite of grousing about it.  I imagine there's a reason for that, which is pretty much what I've laid out here.

Nobody with any sort of multiboot architecture who uses anything other than grub2 for their MBR bootloader is going to voluntarily convert to grub2 just because grub2 has decided that it wants to own the MBR.  The fact remains that legacy grub chainloader is filesystem-agnostic, while all this stuff about core.img can only be supported by grub bootloaders.

Sorry, but the initial objection stands.  If our drakboot is going to offer partition install as an option, then whatever we give the user damn well better work.  Right now it doesn't, and I'm not in favor of screwing up our usability image for some religious viewpoints of the grub2 dev team.  Yeah, I get that they want to discourage partition installs and own the MBR themselves, but I suspect that if they could have eliminated them by now they would have.  They haven't, so they can't.  Personally, I doubt that they ever will in the near future.

So arguments in the vein of "well, you can make it work with grub-legacy by doing such-and-such" don't really apply because many people using multiple bootloaders aren't using ones that are capable of doing anything more than chaining to the PBR of partitions that are marked "active" in the MBR (or wherever the particular bootloader stores its preferences).
Comment 9 Barry Jackson 2016-06-23 15:15:32 CEST
(In reply to Frank Griffin from comment #8)

> Thanks, Barry, but you're missing the point.  For one thing, A lot of us
> simply want to put up a fence so that each partition relies on its own
> bootloader software. 

Exactly which is why this option is offered.

> For another, your solution won't work for
> non-grub-legacy bootloaders which chainload to a PBR and won't go looking
> for a core.img on any filesystem regardless of what it is.

I don't understand. It does work from grub legacy and from grub2.

> 
> I remember arguments about this going back several years, and grub2 still
> allows partition installs in spite of grousing about it.  I imagine there's
> a reason for that, which is pretty much what I've laid out here.

Yes you can FORCE the use of blocklists but believe me it will come back to bite you - I have done extensive testing of this in the past and it works for a while then fails when you least expect it.

> 
> Nobody with any sort of multiboot architecture who uses anything other than
> grub2 for their MBR bootloader is going to voluntarily convert to grub2 just
> because grub2 has decided that it wants to own the MBR.  The fact remains
> that legacy grub chainloader is filesystem-agnostic, while all this stuff
> about core.img can only be supported by grub bootloaders.
> 

Well nothing has changed in Mageia 6 in this regard.

> Sorry, but the initial objection stands.  If our drakboot is going to offer
> partition install as an option, then whatever we give the user damn well
> better work.  Right now it doesn't, and I'm not in favor of screwing up our
> usability image for some religious viewpoints of the grub2 dev team.

It's not religion, it's reliability, and it has not changed.
I agree that "Install to partition" maybe implies something to you that was not intended.
It installs all the grub2 files to the root partition, avoiding to disturb the MBR or ESP so the description is not incorrect, however if this causes you confusion and you think it will to others then maybe we should say something different.

> Yeah,
> I get that they want to discourage partition installs and own the MBR
> themselves, but I suspect that if they could have eliminated them by now
> they would have.  They haven't, so they can't.  Personally, I doubt that
> they ever will in the near future.
> 
> So arguments in the vein of "well, you can make it work with grub-legacy by
> doing such-and-such" don't really apply because many people using multiple
> bootloaders aren't using ones that are capable of doing anything more than
> chaining to the PBR of partitions that are marked "active" in the MBR (or
> wherever the particular bootloader stores its preferences).

I have no idea who you are talking about here or what bootloaders they may be using, but maybe they should upgrade to grub2 ;)
Comment 10 Frank Griffin 2016-06-23 16:11:14 CEST
>> For another, your solution won't work for
>> non-grub-legacy bootloaders which chainload to a PBR and won't go looking
>> for a core.img on any filesystem regardless of what it is.

>I don't understand. It does work from grub legacy and from grub2.

I said "non-grub-legacy bootloaders", such as Windows, OS/2 Boot Manager, OSX, and anything else that doesn't know about core.img and relies on chaining to a valid PBR.

>Yes you can FORCE the use of blocklists but believe me it will come back to bite >you - I have done extensive testing of this in the past and it works for a while >then fails when you least expect it.

That puts it in the same boat with LILO.  We lived with LILO for quite a while and were used to rerunning it when needed.


>Well nothing has changed in Mageia 6 in this regard.
Yes it has.  grub-legacy can't support current ext4 formatting, so the installer no longer offers it.  For MGA6 it's grub2 or nothing.
Comment 11 Thierry Vignaud 2016-06-24 08:34:40 CEST
Installer now warns that if you choose not to install on MBR, you need chain loading from another boot-loader.
Which works fine with grub2+os-prober from another distro as is the default for most distros those days

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Comment 12 Frank Griffin 2016-06-24 13:52:34 CEST
But do we now use --force to cause a PBR to be written ?
Comment 13 Barry Jackson 2016-06-24 15:20:05 CEST
No, but what you do to your machine is entirely your decision.
Comment 14 Frank Griffin 2016-06-24 15:43:50 CEST
Well, in that case it's not fixed.  We are telling the user that he will need to chainload from his MBR, but we're still not giving him anything to chain to, and delivering him an unbootable system.

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

Comment 15 Thierry Vignaud 2016-06-24 16:28:55 CEST
Chain loading works fine from another grub2 which is what every distro uses nowadays...
Comment 16 Frank Griffin 2016-06-24 17:39:38 CEST
That may be, but the whole point of the bug report is to get a PBR written that non-grub2 chainloaders can use.  Is there breally such a problem using --force ?
Comment 17 Barry Jackson 2016-06-24 18:53:58 CEST
Frank, I understand your frustration, but this topic has been aired over and over many times in various places and it all depends on the 'risk' you are prepared to take.
I don't think we should knowingly expose users to a risk that is known.

As I said before, what you do on your own system is up to you. I have been there and tested it in the past and it bit me.

If you have an hour or so to spare:
https://lists.gnu.org/archive/html/grub-devel/2013-02/msg00032.html
Comment 18 Frank Griffin 2016-06-24 23:17:13 CEST
Barry, I have no problem with grub2 devs pushing their agenda, but I *do* have a problem with MGA6 breaking something that users are going to expect to work.

I read your thread, and what I found were a large number of people asking "why doesn't this work anymore ?" and one guy saying basically that they all ought to suck it up and replace whatever they have with grub2.

He also kept saying that they could do it themselves with --force just by chrooting and issuing the command, but he must have a different chroot than I do because I also have to mount --bind /dev and set up some of the other file systems that our chroot doesn't have (see above).

If we ship this, anybody who installs to a partition, sees the warning saying "you'll need to chainload from another bootloader", and says "oh, I know how to do that" is going to be screwed unless his other bootloader is grub2, because anything else that tries to chainload is actually going to chainload and is going to find no PBR.  This is even true for grub-legacy as anyone who has set up grub-legacy with chainloading and doesn't know about core.img isn't going to be able to boot until he finds out about it.

The archlinux wiki has the usual stuff about the grub2 devs disapproving, but then describes --force and gives the chattr -i and +i commands for making the core.img file immutable, and also claims that this works.

The filesystems mailing list link from some of the thread posts is more interesting, as most of the ext4 dev posters think the grub2 guys are paranoid (their word).

We have two possible options.  One is to have the popup give a scary warning, and if they accept the risk, use --force and chattr for them.  That at least gives them a bootable system.  The other is to tell them "hey, now that you've spent an hour or so watching this grind away, we'd just like to let you know that unless you decide right now to let us take over your master boot record with something you've never used before, we're going to leave your system unbootable".

Which one do you think the user community will be happier with ?  A lot of people may be open to converting to grub2 MBR, but I don't think many of them want to have to make the decision during an install with possibly no internet access for research.

Also, considering that reviewers are likely heavy users of chainloading (multiple test partitions), I'm sure they're going to love this.
Comment 19 Barry Jackson 2016-06-25 00:53:03 CEST
I'm sorry but I don't share your blinkered view on this.

Before Mageia was even born I spent a lot of time helping Mandriva users in the forums deal with multi-boot issues caused by other distro's grub2 systems that were not being included in Mandriva's grub menu (before it became known as legacy grub).
Over 2000 forum posts IIRC.

I could see then that the writing was on the wall for grub legacy and that I had to better understand grub2 and be prepared to use it.

I have never used grub legacy in Mageia from day one.

When Mageia was launched I immediately started to push for the use of grub2 in Mageia and imported the package on Mon May 28 2012.

Now we finally have grub2 fully integrated with Mageia tools thanks to a valiant effort by Thierry who has pulled out all the stops to fix all the final bugs for Mageia 6.

I really don't see why anyone should be at all surprised that Mageia has finally dropped the dinosaur - we kept it alive longer than most.

As regards people who "suddenly find they are screwed unless their bootloader is grub2.....and they know about core.img etc etc."

They are not screwed even if they allow Mageia to install grub2 to MBR as Mageia will boot and assuming they don't disable os-prober in the installer they will be able to boot their other systems as well.

Please, this is nothing new. We are one of the last few to move to grub2 and it's been talked about for years. Anyone who multi-boots between grub, grub2 and whatever else knows how to do it, or how to Google...

If you or anyone else want to "grub2-install --force" then feel free, but I don't think it is Mageia's job to promote or facilitate that.

My last 2 cents on this.

Barry
Comment 20 Felix Miata 2016-06-25 01:28:01 CEST
Quoting ancient sage advice from https://old-en.opensuse.org/Bugs/grub :
"...the only sure thing about PC disk booting is that the BIOS will load the first block into memory and likely execute its code. Very few BIOSes apply one or more sanity checks to the MBR.

"We recommend to keep the MBR "neutral", that is, not consider it part of any operating system. For that purpose, a generic MBR can be used, that simply determines one of the 4 primary partitions by a bit flag, and then loads the first block of that partition in turn, to continue the boot process. The Yast installation offers the option to install such generic code in the MBR; do it when in doubt. The next operating system to be installed may do something similar, so all should agree on the expected behaviour of the MBR. There might also be an older SuSE Linux installation left on the disk, with some boot loader's first stage in the MBR. With a new boot loader installed over the rest, the remaining first stage alone will not work any more. Again, laptops have been found to abuse the MBR for recovery. They work well when you assume the generic behaviour, but things break when the MBR gets overwritten. Use a generic MBR wherever you can."

IMO, usurping the MBR from any previously installed OS remaining installed is simply not acceptable, which directly contradicts Grub2 developer policy, and is thus a major factor why I don't use Grub2 as a matter of policy, as well as convenience. That Windows' installers routinely do the same thing is no justification for such rude behavior as a matter of policy.

FWIW for users of Grub 0.9x as a master bootloader, chainloading in generic terms doesn't require the chainloader command as the term is defined in any Grub man page. Alternatives:

1.A "master" Grub can use a /boot/grub/menu.lst living on any partition it can access.

2.A "master" Grub can load a kernel and initrd from a partition other than the one on which it lives.

WRT #1, Mageia could create both grub.cfg and menu.lst, allowing a master Grub to use the configfile command to load Mageia's menu.lst.

#2 is already facilitated, as standard Mageia kernel installation procedure includes creating symlinks to current kernel and initrd. Configuring the master to use the symlinks instead of versioned files obviates need to update the master bootloader itself when each kernel update occurs.

If 64 bit node enabling on MGA6 EXT4 / would be an obstacle to either approach, it should be simple enough to provide an option of some kind at installation time to prevent 64 bit nodes. Formatting in advance without 64 bit enabled would be another workaround, as would using EXT3 instead of EXT4.
Comment 21 Frank Griffin 2016-06-25 07:03:35 CEST
OK, i agree with Barry that every possible viewpoint has been stated.

I just find it a little odd that we only made the transition to grub2 at the last minute for MGA6 because of the ext4 64bit issue, and amended the drakboot stuff accordingly, but now we're proposing an MBR coup-d'etat or else a finger-spank to chainloader users with no previous warning to anybody that this was coming down the pike.  I certainly don't remember a thread discussing it here.

I'm concerned that, whether or not grub2 is the way to go (and BTW I accept that it is, if only because some filesystem designers appear to have taken the altogether unecessary step of appropriating the PBR), we are going to take a lot of flak because this will be viewed as an attempt to drag grub2 in through the back door with no warning to users who have no idea that a functionality they rely on is getting yanked out from under their feet, especially with a misleading warning that leads them to believe that legacy chainloading will still work.

If we truly want to walk away from legacy chainloading, the proper procedure (I think) would be to put this out in the dev/discuss MLs and forums and give people notice that this will be unsupported in MGA7.  It's really a little late in the cycle to say "oh by the way, we could support this with a caveat, but we've decided that we'll make the decision for you even though we gave you no heads-up that this was coming".  This is exactly the sort of high-handed stuff that got GNOME3 its well-deserved shitstorm.  

I'm going to leave this OPEN for the determination of whoever has the final say on installer issues (I don't think that's Barry, but I could be wrong).  If you really want to go down this path, close it as WONTFIX.
Thierry Vignaud 2016-07-04 15:56:36 CEST

Blocks: (none) => 416

Comment 22 Peter D 2016-07-14 14:34:46 CEST
I am way too late to be discussing the design philosophy of boot loaders, but... 

If older boot loaders (Grub classic, LiLo, ... ) can not cope with 64bit enabled versions of ext4, or a few other file systems, it is only necessary to insist that the /boot partition (not to be confused with the EFI partition or the BIOS boot partition / Grub partition) is formatted with a file system that is acceptable - such as ext2/3.  LiLo puts its "map" file there, kernel and initrd files go there.  I think that Grub classic's stuff goes there too, apart from the stuff that goes outside of a file system.

CC: (none) => 0123peter

Comment 23 Thierry Vignaud 2016-07-14 14:52:56 CEST
That's not the only issue.
Those bootloaders are no more supported.
In the past we could rely on other distros to patch them but now we would be the only one still using it.
It's time to simplify the support matrix...
Adding more more checks in drakboot doesn't simplify our work
Comment 24 Peter D 2016-07-22 15:18:20 CEST
Parallel redundancy!  If you have three bootloaders and one fails, it is embarrassing.  If you have one bootloader and it fails, it is a disaster.  

Default to the bootloader that you like, and mark the unsupported ones as not supported, but please don't insist on installing Grub2 when it is not wanted.  

As far as I understand it; 
LiLo, not supported, but works, 
Grub classic, not supported, but works, 
rEFInd, is supported and works on EFI machines, 
Grub 2, is supported and mostly works.
Samuel Verschelde 2016-11-01 22:58:17 CET

Assignee: bugsquad => mageiatools

Comment 25 Maurice Batey 2016-11-17 12:53:12 CET
> rEFInd, is supported and works on EFI machines, 

  - and allows Grub2 to be uninstalled, as well as dynamically building a boot menu of all visible .efi boot files (optionally with exclusions).

For EFI installs, could this not be put in place by the Installer?

CC: (none) => maurice

Comment 26 Neal Gompa 2016-11-17 13:00:37 CET
As far as I'm aware, we don't support rEFInd in drakboot.

And GRUB 2 does work in EFI environments fairly well.

CC: (none) => ngompa13

Comment 27 Maurice Batey 2016-11-17 13:05:02 CET
See also http://bugs.mageia.org/15153 

Far better solution than Grub2 for EFI environment?
Comment 28 Daniel Kalweit 2017-03-14 09:05:52 CET
I tried to install Mageia 6 sta2 and missed the option to install Grub2 on a PBR.
When I check "Do not touch ESP or MBR" I am not able to chainload Mageiea 6 from XOSL which is my "Masterbootloader".
So the only way to use Mageia 6 ist to install Grub2 to the MBR.

But with Grub2 I'm not able to hide/unhide several Partitions for my 2 Windows installations.

Second way to install Mageia 6 was to upgrade from Mageia 5 and leave grub legacy as Bootloader in the Mageia Partition, but installation stopped with a message that it is not possible to write to a partition where Windows was locatet on.... ?? Why wants Mageia write on Windows partitions???

CC: (none) => d.kalweit

Comment 29 Daniel Kalweit 2017-03-14 09:08:54 CET
Sorry for my bad english :) ... and I don't have much time - have 2 jobs and don't sleep much...
Comment 30 Barry Jackson 2017-03-14 14:31:29 CET
(In reply to Daniel Kalweit from comment #28)
> I tried to install Mageia 6 sta2 and missed the option to install Grub2 on a
> PBR.

There isn't one as this is not recommended - see discussions earlier in this bug report.

> When I check "Do not touch ESP or MBR" I am not able to chainload Mageiea 6
> from XOSL which is my "Masterbootloader".
> So the only way to use Mageia 6 ist to install Grub2 to the MBR.
> 

Depending on your "Masterbootloader" you can chain into the core.img directly (certainly with a grub2 master bootloader).

> But with Grub2 I'm not able to hide/unhide several Partitions for my 2
> Windows installations.

Yes you can. Add this line to /etc/default/grub and run update-grub2:

GRUB_OS_PROBER_SKIP_LIST="<uuid_of_unwanted_win_partition>@/dev/sdaXY"
e.g. GRUB_OS_PROBER_SKIP_LIST="A3F5-6DF3@/dev/sda1"

There may be more than one entry in the list.

> Second way to install Mageia 6 was to upgrade from Mageia 5 and leave grub
> legacy as Bootloader in the Mageia Partition, but installation stopped with
> a message that it is not possible to write to a partition where Windows was
> locatet on.... ?? Why wants Mageia write on Windows partitions???

Best to avoid legacy grub as it's obsolete.
Comment 31 Daniel Kalweit 2017-03-14 16:19:58 CET
Chainloading Grub-legacy or booting any other OS from my X.O.S.L Bootmanager worked flawlessly for about 20 years. I used to have up to 6 Operating Systems on 2 built-in Hardddisks and even booted from external (USB)Harddisk. And it is absolutely easy to hide/unhide Partitions - you have just to check or uncheck an entry in the partition list.

I'm very unhappy if I'm forced to install Grub2 to the MBR.
I understand to switch from Grub-legacy to Grub2, but I don't understand why chainloading to a PBR from another Bootloader than Grub-legacy or Grub2 shouldn't work anymore!
Comment 32 Daniel Kalweit 2017-03-14 16:41:54 CET
...but if Grub2 will be as easy to configure as X.O.S.L I certainly would intall it to the MBR instead :)
Comment 33 Peter D 2017-03-18 07:33:15 CET
There is another nasty GOTCHA here; logical partitions of a traditional partitioning scheme start with a modified boot record in their zeroth sector - the PBR.  Primary partitions can easily have a sector reserved, and I believe almost always do.  

GPT partitions have no need for the information stored in the zeroth sector of a traditional logical partition, and so don't have a PBR.  Writing anything to a sector that has not been allocated will require a hack.  I can think of a few ways to do it but I don't like any of them.  Also, space between partitions on a SSD can be used by background house keeping TRIM, so don't rely on that. 

Don't attempt to use a PBR on a GPT disk. 

For traditional partitioning schemes, there are multiple ways to multi boot.  The logically cleanest is to have each OS install to a PBR (check that something exists in the MBR) then say, "I don't know or care what is in the other partitions".  Few installers were willing, or now even able, to do that.  The common choice was to ignore all PBRs, find all bootable images (maybe) and take control of the MBR (or warn the user to "do something").  That might be the least bad option possible now.  No one ever seemed to look for images AND PBRs.  <shrug> 

Why won't GRUB2 write to the PBR (on a traditional disk)?  That is a question for the GRUB developers that no one else will be easily able to override their decision.

CC: (none) => peter_s_d

Comment 34 Barry Jackson 2017-03-18 14:31:48 CET
(In reply to Peter D from comment #33)

> Why won't GRUB2 write to the PBR (on a traditional disk)? 

It will, with --force, but it is not recommended as it uses block lists which can break if disk housekeeping moves blocks around, so for that reason Mageia does not facilitate it's use.
I don't think you read all of this bug report ;)
Comment 35 Peter D 2017-03-21 15:01:14 CET
I have read it all, but a very long time ago.  Apologies for what I have forgotten.  Nearly a year ago I wrote that it was too late in the development cycle to be arguing about this.  I was wrong.  It is also the wrong forum for it, but I don't know where to go.  

There is some confusion between boot.img and core.img.  

The "--force" option allows you to put core.img in a place that the GRUB2 developers do not approve of, but does not write to the PBR because they have found a way to bypass it, which is fine - if you are chaining from GRUB to GRUB but not if you are trying to chain from something else to GRUB (the reason for this bug report).  The PBR contains a partition table so it is pretty sacrosanct.  It can not be moved by anything short of re-partitioning.  It is only one block long and a block list of one block is not very vulnerable.  Now core.img on the other hand...  But if that gets messed up, it does not matter how you were getting to core.img, you are un-bootable.  Or were you worried about bad sectors being remapped by the hard disk?  That should be invisible to even the BIOS.  

Boot.img is 512 byte long, including a partition table.  It is written to the MBR or the PBR - except that GPT disks don't have PBRs and the GRUB2 developers seem to have decided not to write to the PBRs of traditional disks at all lately.  The PBR is before the first block of any file system and not subject to file system house keeping.  The empty PBR is the subject of this bug report.  Boot.img is just to find the first block of core.img (in GRUB) or of map (in LiLo) or possibly another PBR, etc. 

GRUB's core.img is much larger and is usually written after the MBR, or after a PBR, or inside a file system (with the "--force" option), or to a GPT disk's BIOS boot partition.  Core.img could be somewhat protected by only mounting /boot read-write during kernel updates, maybe not mounting it at all during normal operation, that might not work. 

Chain loading to a PBR or an MBR of another disk is easy, all you have to do is find one sector and go there.  

New term: "GRUB loading" is finding a GRUB core.img and going there.  It is somewhat harder than chain loading.  The GRUB developers call GRUB loading chain loading.  GRUB can GRUB load another GRUB installation, so GRUB doesn't bother writing anything to the PBR any more.  That is fine if GRUB is your one and only boot loader.  Other boot loaders can struggle to handle a GRUB installation, because there is nothing in the PBR and core.img is hard to find.  

Theoretically the code that writes boot.img to the MBR could be modified to write something sensible to a PBR, then a root install could write core.img to a partition, a modified boot.img to its PBR AND write a boot.img to the MBR (if empty) and core.img in the post MBR gap (if empty).  So, GRUB loaders (that is GRUB) could GRUB load core.imgs, boot loaders could find PBRs (which would load core.img or map files or whatever), but in practice I don't want to do the work.  Sorry.
papoteur 2019-07-29 08:40:02 CEST

See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=25195

Comment 36 Frank Griffin 2020-01-10 00:52:12 CET
Are we going to leave this hanging forever ?
Comment 37 Thierry Vignaud 2020-02-17 00:07:09 CET
Let's close it

Status: REOPENED => RESOLVED
Resolution: (none) => WONTFIX


Note You need to log in before you can comment on or make changes to this bug.