* Re: [Buildroot] Grub2 changes since 2021.10.2
2021-10-23 16:20 [Buildroot] Grub2 changes since 2021.10.2 David Laight
@ 2021-10-24 12:23 ` Yann E. MORIN
0 siblings, 0 replies; 2+ messages in thread
From: Yann E. MORIN @ 2021-10-24 12:23 UTC (permalink / raw)
To: David Laight
Cc: Köry Maincent, 'Peter Seiderer', Walter, Stefan,
buildroot@buildroot.org
David, All,
In the title, you mention "2021.10.2". There is no such release of
Buildroot... Did you mean 2021.08.1, 2021.02.2, or something else?
On 2021-10-23 16:20 +0000, David Laight spake thusly:
> Do the recent changes to grub2 make it any easier to install
> the version of grub2 built by buildroot?
> I'm pretty sure the commands in the scripts I inherited install
> grub from the host system.
> This is made much more likely because the actual boot disks
> are made on a second system (by production, not development).
I am not sure I understand what your problem is...
From what I understand, you have some scripts, that you did not write,
that you do not entirely understand, that do some magic fiddling with
the grub2 as installed by Buildroot, so that part of the build happens
on one machine, and another part on another machine.
If that's the case, then this is clearly not something that has been
envisioned by Buildroot. And I am not even sure this is something that
we should even cater to...
> I've tried setting the BR option to include the grub objects
> in the built 'root' filesystem.
> While this adds files to the image, even when booted from the
> disk the grub install program fails - IIRC due to missing files.
And now, you are speaking about things that are missing in the installed
grub on the target. Seems like this is a legitimate issue, even if
separate from the rest...
However, you are not providing enough context and details as to see what
is missing. Maybe you could provide a runtime test with your use-case,
like we have in support/testing//tests/boot/, to validate that the grub
installation we do actually works as it should?
You could take a peek at support/testing/tests/fs/test_iso9660.py for a
few already existing use-cases of booting a system with grub2, from a
CDROM.
> Either the host's own 'grub install' program needs to install
> these files from somewhere (I could parcel them up somewhere else)
All the files installed by the target variant of grub2 are installed
in output/images/ (the actual boot files, like grub.img for the legacy
BIOS boot) and, if $(BR2_TARGET_GRUB2_INSTALL_TOOLS)==y, to
output/target/lib/grub/*/ (where grub modules for each platform are
located) and somewhere in output/target/bin/ and output/target/sbin/
(for the grub tools to run on the target).
> or I need to get the 'host' version of the required binaries
> into my release (they should run on production's system, the
> ones from the image itself won't).
Again that two-machine setup that has nothing to do with Buildroot...
> This is all x86_64 using MBR disks (EFI causes too much grief).
> I understand all about the x86 boot process (I rewrote NetBDS's
> MBR and PBR code many years ago),
I do not question your knowledge about how a PC boots, and from what you
said, I believe you even know way much more than I do.
> but where grub2 installs anything
> (and which programs update what) seems to have been deleted
> from any user documentation.
That the grub documentation is lacking can't really be blamed onto
Buildroot, can it? ;-)
> AFAICT grub writes all over parts of the disk (like the rest of
> track 0?) that aren't actually reserved for boot code.
That's too bad, because I had seen a recent thread in the grub archives,
that indeed seem to imply that there were quite a lot of locations where
grub would write things, but I can't find that thread again... But
again, I don't understand how this is related to Buildroot, except if we
were to generate improper disk images borked because we put things
overwritten by some grub tools. In which case a runtime test to validate
that would be much appreciated too.
> I've also got a problem where the grub build objects to /usr/bin/gcc
> being earlies that gcc 5.1 (it is 4.8.5 on a Centos 7 system).
> I expected everything to be built with the gcc 10 I specified.
> Has this been fixed by the recent changes to the CC path in the
> grub package?
That is because the host variant grub build would so far build and
install modules, and so would use the host compiler.
This has been fixed as of yesterday, now: the host grub build no longer
builds for any platform; it just builds the tools. The grub modules are
now all built as part of the target variant, for each of the platform
enabled in the configuration.
If $(BR2_TARGET_GRUB2_INSTALL_TOOLS)==y, then all grub modules are
installed in output/target/lib/grub/*/ now (as they were before the
recent multi-platform rework; so at least in this respect, we've fixed
that regression).
What might be missing, though, is an option to also install them in,
say, output/images/grub/*/. But this would be a new feature, as this had
never been the case.
And in the end, I am still not sure I understood what your problems
are... Maybe all you need is a way to actually collect the grub modules
in a known location?
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 2+ messages in thread