* [Buildroot] grub on target
@ 2015-04-21 6:30 Mike Musterd
2015-04-21 20:07 ` Arnout Vandecappelle
2015-04-22 19:52 ` Mark Mason
0 siblings, 2 replies; 6+ messages in thread
From: Mike Musterd @ 2015-04-21 6:30 UTC (permalink / raw)
To: buildroot
Hello list,
I am developing a small OS that functions as a sort of bootloader for windows. Its primary function is to check whether windows is available and if so, reboot to windows once (then, after that, boot into the bootloader again).
If not it will repartition disk, install itself on new partition, and format drives and clone windows (from a network source) all from within this bootloader.
I am using grub for that, with some custom fixes to the grub-reboot script to make it behave as required.
However to my dismay I found that the grub package does not actually build grub for the target.
grub.mk claims as much:
# We're cheating here as we're installing the grub binary not in the
# target directory (where it is useless), but in the host
# directory. This grub binary can be used to install grub into the MBR
# of a disk or disk image.
In my use case I need grub in the target directory, and it's not useless at all. So I modified the grub.mk to actually make grub for the target, and it all works.
Now my question is: is my usecase generic enough to warrant a patch submission, or is the 'useless' part always true except in my case?
Kind regards,
Mike
This email is non-binding, is subject to contract, and neither Kulicke and Soffa Industries, Inc. nor its subsidiaries (each and collectively "K&S") shall have any obligation to you to consummate the transactions herein or to enter into any agreement, other than in accordance with the terms and conditions of a definitive agreement if and when negotiated, finalized and executed between the parties. This email and all its contents are protected by International and United States copyright laws. Any reproduction or use of all or any part of this email without the express written consent of K&S is prohibited.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20150421/f7b7a377/attachment.html>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] grub on target
2015-04-21 6:30 [Buildroot] grub on target Mike Musterd
@ 2015-04-21 20:07 ` Arnout Vandecappelle
2015-04-22 19:52 ` Mark Mason
1 sibling, 0 replies; 6+ messages in thread
From: Arnout Vandecappelle @ 2015-04-21 20:07 UTC (permalink / raw)
To: buildroot
On 21/04/15 08:30, Mike Musterd wrote:
> Hello list,
>
>
>
> I am developing a small OS that functions as a sort of bootloader for windows.
> Its primary function is to check whether windows is available and if so, reboot
> to windows once (then, after that, boot into the bootloader again).
>
> If not it will repartition disk, install itself on new partition, and format
> drives and clone windows (from a network source) all from within this bootloader.
>
>
>
> I am using grub for that, with some custom fixes to the grub-reboot script to
> make it behave as required.
>
>
>
> However to my dismay I found that the grub package does not actually build grub
> for the target.
>
>
>
> grub.mk claims as much:
>
> # We're cheating here as we're installing the grub binary not in the
>
> # target directory (where it is useless), but in the host
>
> # directory. This grub binary can be used to install grub into the MBR
>
> # of a disk or disk image.
>
>
>
> In my use case I need grub in the target directory, and it?s not useless at all.
> So I modified the grub.mk to actually make grub for the target, and it all works.
Well, in fact grub2 _is_ made for the target, but it is installed in the host
directory instead of in the target. So indeed, the same files can just be copied
to the target and they will work there.
> Now my question is: is my usecase generic enough to warrant a patch submission,
> or is the ?useless? part always true except in my case?
I agree that it is useful enough. Add a config option
BR2_TARGET_GRUB2_INSTALL_TOOLS (with appropriate help text) to conditionally
install them.
Thanks!
Regards,
Arnout
>
>
>
> Kind regards,
>
>
>
> Mike
>
>
>
> This email is non-binding, is subject to contract, and neither Kulicke and Soffa
> Industries, Inc. nor its subsidiaries (each and collectively ?K&S?) shall have
> any obligation to you to consummate the transactions herein or to enter into any
> agreement, other than in accordance with the terms and conditions of a
> definitive agreement if and when negotiated, finalized and executed between the
> parties. This email and all its contents are protected by International and
> United States copyright laws. Any reproduction or use of all or any part of this
> email without the express written consent of K&S is prohibited.
>
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] grub on target
2015-04-21 6:30 [Buildroot] grub on target Mike Musterd
2015-04-21 20:07 ` Arnout Vandecappelle
@ 2015-04-22 19:52 ` Mark Mason
2015-04-24 17:41 ` Mark Mason
1 sibling, 1 reply; 6+ messages in thread
From: Mark Mason @ 2015-04-22 19:52 UTC (permalink / raw)
To: buildroot
I've installed the Grub2 tools on the target as part of the pre-fs
script, but I've never figured out how to actually make it install a
working bootloader. If you're using it with UEFI then I'd be
interested in knowing what you did you make it work.
I'm trying to make the simplest possible x86_64 UEFI config work -
just boot a single image off a FAT32 boot partition. No extra logic,
no loading modules, no fiddling with video modes, no anything except
booting. Mostly I get either hangs on entry to the kernel or the
kernel parameters appear to not be passed through correctly, resulting
in no rootfs.
Something else I'd like to be able to do is make a disk image that I
can run through a disk duplicator to make bootable disks, but I'm not
sure if that's possible without rewriting the grub.cfg after the first
boot since the UUIDs appear to different for different disks.
I've tried the instructions that are in the Grub2 menuconfig help,
which mostly works on some machines while on others it either hangs
after a "Couldn't terminate EFI services" message or else is unable to
find the root device. I haven't been able to identify any differences
between the working and non-working machines, and I've tested against
probably 20 different ones. The machines are a DN2820FYKF Intel NUC,
the lowest end NUC, and the BIOS doesn't inspire confidence, so there
might be bugs there.
I'd appreciate some advice if anyone has any idea what might be going
wrong.
Thanks!
Mike Musterd <MMusterd@kns.com> wrote:
> Hello list,
>
> I am developing a small OS that functions as a sort of bootloader for windows.
> Its primary function is to check whether windows is available and if so, reboot
> to windows once (then, after that, boot into the bootloader again).
>
> If not it will repartition disk, install itself on new partition, and format
> drives and clone windows (from a network source) all from within this
> bootloader.
>
> I am using grub for that, with some custom fixes to the grub-reboot script to
> make it behave as required.
>
> However to my dismay I found that the grub package does not actually build grub
> for the target.
>
> grub.mk claims as much:
>
> # We're cheating here as we're installing the grub binary not in the
> # target directory (where it is useless), but in the host
> # directory. This grub binary can be used to install grub into the MBR
> # of a disk or disk image.
>
> In my use case I need grub in the target directory, and it?s not useless at all.
> So I modified the grub.mk to actually make grub for the target, and it all
> works.
>
> Now my question is: is my usecase generic enough to warrant a patch submission,
> or is the ?useless? part always true except in my case?
>
> Kind regards,
>
>
> Mike
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] grub on target
2015-04-22 19:52 ` Mark Mason
@ 2015-04-24 17:41 ` Mark Mason
2015-04-28 18:52 ` Arnout Vandecappelle
0 siblings, 1 reply; 6+ messages in thread
From: Mark Mason @ 2015-04-24 17:41 UTC (permalink / raw)
To: buildroot
To answer my own question, it looks like I was having some sort of
UEFI-related problem, and it was fixed by a newer version of Grub2.
When booting from Grub2 under some circumstances (seemingly involving
the phase of the moon and how frustrated I was) I'd get a message
saying "Couldn't terminate EFI service", then some sort of hang. Some
digging around turned up a Grub2 patch to address this issue that
buildroot-2015-02 doesn't have - Grub2 simply retries the service stop
if it fails the first time, emitting a message about retrying the
service stop instead of a message about being unable to stop.
I have no idea what service(s) are involved, but I've now got reliable
booting.
It's worth nothing that the Grub2 info page does address
phase-of-the-moon issues, but only involving the graphics.
Mark Mason <mason+buildroot@postdiluvian.org> wrote:
> I've installed the Grub2 tools on the target as part of the pre-fs
> script, but I've never figured out how to actually make it install a
> working bootloader. If you're using it with UEFI then I'd be
> interested in knowing what you did you make it work.
>
> I'm trying to make the simplest possible x86_64 UEFI config work -
> just boot a single image off a FAT32 boot partition. No extra logic,
> no loading modules, no fiddling with video modes, no anything except
> booting. Mostly I get either hangs on entry to the kernel or the
> kernel parameters appear to not be passed through correctly, resulting
> in no rootfs.
>
> Something else I'd like to be able to do is make a disk image that I
> can run through a disk duplicator to make bootable disks, but I'm not
> sure if that's possible without rewriting the grub.cfg after the first
> boot since the UUIDs appear to different for different disks.
>
> I've tried the instructions that are in the Grub2 menuconfig help,
> which mostly works on some machines while on others it either hangs
> after a "Couldn't terminate EFI services" message or else is unable to
> find the root device. I haven't been able to identify any differences
> between the working and non-working machines, and I've tested against
> probably 20 different ones. The machines are a DN2820FYKF Intel NUC,
> the lowest end NUC, and the BIOS doesn't inspire confidence, so there
> might be bugs there.
>
> I'd appreciate some advice if anyone has any idea what might be going
> wrong.
>
> Thanks!
>
> Mike Musterd <MMusterd@kns.com> wrote:
>
> > Hello list,
> >
> > I am developing a small OS that functions as a sort of bootloader for windows.
> > Its primary function is to check whether windows is available and if so, reboot
> > to windows once (then, after that, boot into the bootloader again).
> >
> > If not it will repartition disk, install itself on new partition, and format
> > drives and clone windows (from a network source) all from within this
> > bootloader.
> >
> > I am using grub for that, with some custom fixes to the grub-reboot script to
> > make it behave as required.
> >
> > However to my dismay I found that the grub package does not actually build grub
> > for the target.
> >
> > grub.mk claims as much:
> >
> > # We're cheating here as we're installing the grub binary not in the
> > # target directory (where it is useless), but in the host
> > # directory. This grub binary can be used to install grub into the MBR
> > # of a disk or disk image.
> >
> > In my use case I need grub in the target directory, and it?s not useless at all.
> > So I modified the grub.mk to actually make grub for the target, and it all
> > works.
> >
> > Now my question is: is my usecase generic enough to warrant a patch submission,
> > or is the ?useless? part always true except in my case?
> >
> > Kind regards,
> >
> >
> > Mike
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] grub on target
2015-04-24 17:41 ` Mark Mason
@ 2015-04-28 18:52 ` Arnout Vandecappelle
2015-05-01 17:54 ` Mark Mason
0 siblings, 1 reply; 6+ messages in thread
From: Arnout Vandecappelle @ 2015-04-28 18:52 UTC (permalink / raw)
To: buildroot
Hi Mark,
On 04/24/15 19:41, Mark Mason wrote:
> To answer my own question, it looks like I was having some sort of
> UEFI-related problem, and it was fixed by a newer version of Grub2.
Perhaps you'd like to submit a patch to bump grub2 to a newer version?
Regards,
Arnout
>
> When booting from Grub2 under some circumstances (seemingly involving
> the phase of the moon and how frustrated I was) I'd get a message
> saying "Couldn't terminate EFI service", then some sort of hang. Some
> digging around turned up a Grub2 patch to address this issue that
> buildroot-2015-02 doesn't have - Grub2 simply retries the service stop
> if it fails the first time, emitting a message about retrying the
> service stop instead of a message about being unable to stop.
>
> I have no idea what service(s) are involved, but I've now got reliable
> booting.
>
> It's worth nothing that the Grub2 info page does address
> phase-of-the-moon issues, but only involving the graphics.
[snip]
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] grub on target
2015-04-28 18:52 ` Arnout Vandecappelle
@ 2015-05-01 17:54 ` Mark Mason
0 siblings, 0 replies; 6+ messages in thread
From: Mark Mason @ 2015-05-01 17:54 UTC (permalink / raw)
To: buildroot
Arnout Vandecappelle <arnout@mind.be> wrote:
> Hi Mark,
>
> On 04/24/15 19:41, Mark Mason wrote:
> > To answer my own question, it looks like I was having some sort of
> > UEFI-related problem, and it was fixed by a newer version of Grub2.
>
> Perhaps you'd like to submit a patch to bump grub2 to a newer version?
>
> Regards,
> Arnout
I will do that when I get one. I needed a working grub immediately,
so I took a newer grubx64.efi off an Ubuntu machine and patched it
with emacs to use the generic paths that I needed.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-05-01 17:54 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-04-21 6:30 [Buildroot] grub on target Mike Musterd
2015-04-21 20:07 ` Arnout Vandecappelle
2015-04-22 19:52 ` Mark Mason
2015-04-24 17:41 ` Mark Mason
2015-04-28 18:52 ` Arnout Vandecappelle
2015-05-01 17:54 ` Mark Mason
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox