Grub kfreebsd with pxe & nfs
I have two separate issues involving the {kfreebsd} code in grub.cfg:
* First is, code snippet to get mount_root to use NFS V3 instead of V2. The
code for this in FreeBSD's /boot/loader.conf is: {boot-nfsroot-options=“nfsv3”}
The comparable grub.cfg code should be as below, but does not work (mount_root
hangs for some time, then falls back to V2)
{set kfreebsd.boot.nfsroot.options="nfsv3"}
* Second issue is, how to over-ride the {option root-path
"192.168.2.1:/data/amd64"} code defined by dhcp? This is needed for example
when I want to boot a i386 version of FreeBSD rather than amd64. As above, this
does not work correctly:
{set kfreebsd.vfs.root.mountfrom="nfs:192.168.2.1:/data/amd64/alt_root/path"}
Also, which file in the grub code can I look through to get a list of options
supported by the kfreebsd operator?
--
FreeBSD_amd64_11-Current_RadeonKMS
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub kfreebsd with pxe & nfs
В Sun, 26 Oct 2014 20:03:00 +0200
Beeblebrox пишет:
> I have two separate issues involving the {kfreebsd} code in grub.cfg:
>
> * First is, code snippet to get mount_root to use NFS V3 instead of V2. The
> code for this in FreeBSD's /boot/loader.conf is:
> {boot-nfsroot-options=“nfsv3”}
>
> The comparable grub.cfg code should be as below, but does not work
> (mount_root hangs for some time, then falls back to V2)
> {set kfreebsd.boot.nfsroot.options="nfsv3"}
>
This should be kFreeBSD
> * Second issue is, how to over-ride the {option root-path
> "192.168.2.1:/data/amd64"} code defined by dhcp? This is needed for example
> when I want to boot a i386 version of FreeBSD rather than amd64. As above,
> this does not work correctly:
> {set kfreebsd.vfs.root.mountfrom="nfs:192.168.2.1:/data/amd64/alt_root/path"}
>
Same.
> Also, which file in the grub code can I look through to get a list of options
> supported by the kfreebsd operator?
>
Which operator? freebsd loader simply strips kFreeBSD. prefix from
variable name and exports the rest as environment variable for
FreeBSD kernel. So list of options is whatever is supported by
FreeBSD kernel.
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub kfreebsd with pxe & nfs
> > * First is, code snippet to get mount_root to use NFS V3 instead of
> > V2. grub.cfg code should be as below, but does not work
> This should be kFreeBSD
Still does not work with
{set kFreeBSD.boot.nfsroot.options="nfsv3"}
mount_root this time does not hang, but resulting mounted root is still V2
* grub.cfg does not accept kFreeBSD for all parameters, and needs mixed syntax.
Example:
menuentry 'FreeBSD 11_amd64' {
kfreebsd kernel/kernel
# NOT kFreeBSD kernel/kernel
set FreeBSD.acpi_load=YES
kfreebsd_loadenv device.hints
# NOT kFreeBSD_loadenv device.hints
kfreebsd_module kernel/if_sis.ko
# NOT kFreeBSD_module kernel/if_sis.ko
* I disabled these 3 params:
# set kFreeBSD.vfs.root.mountfrom="nfs:192.168.2.1:/data/amd64"
# set kFreeBSD.vfs.root.mountfrom.options="ro"
# set kFreeBSD.boot.nfsroot.options="nfsv3"
And saw that FreeBSD boots normally through grub. This means that the {set
kFreeBSD.*} settings are very likely being ignored as boot settings. The
mount_root is successful because FreeBSD executes what is passed from dhcp.
Regards.
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB booting Mac OS X (xnu)
On Oct 26, 2014, at 12:53 AM, Andrei Borzenkov wrote: > > The error message on your screenshot does not look like coming from > grub2. Also magic it displays is rather amusing > > bor@opensuse:~/src/grub> echo -e '\x73\x69\x68\x54' > sihT It looks like it's coming from the Apple bootloader, not GRUB, and you can also see screen artifacts in that photo. So some memory or graphics state doesn't seem right. However, if I use grub command exit, OS X boots! And it does this using the identical boot.efi I'm using with chainloader. > > Could you test with earlier versions? I tested with a GRUB2 2.00 versions from Fedora 19 and 20 and posted those, and it still fails but differently. I uploaded two new photos for each showing their different failure messages. Also weirdly, the GRUB ls command doesn't list files and tab won't autocomplete; whereas chainloader does tab autocomplete and I'm able to navigate to the boot.efi file. And I also note that Recovery HD (Apple Boot partition type GUID) contains two bootloaders: /System/Library/CoreServices/boot.efi /com.apple.recovery.boot/boot.efi Their sha256sums are identical though. Chris Murphy ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
building grub2 on a Mac, possible bug
This is on a macbookpro9,2, running Fedora 20, and I've git cloned from git://git.savannah.gnu.org/grub.git and I'm in master branch. $ ./configure checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type… x86_64-unknown-linux-gnu The unknown seems suspicious. And at the end I see "GRUB2 will be compiled with following components: Platform: i386-pc" which is also wrong. If I use --with-platform=efi, then at the end I get "GRUB2 will be compiled with following components: Platform: x86_64-efi" which is correct. In the configure file I see this: # Guess the platform if not specified. if test "x$with_platform" = x; then case "$target_cpu"-"$target_vendor" in i386-apple) platform=efi ;; i386-*) platform=pc ;; x86_64-apple) platform=efi ;; I guess $target_vendor isn't getting set to apple and therefore platform doesn't get set to efi. Chris Murphy ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: building grub2 on a Mac, possible bug
В Sun, 26 Oct 2014 21:00:18 -0600 Chris Murphy пишет: > This is on a macbookpro9,2, running Fedora 20, and I've git cloned from > git://git.savannah.gnu.org/grub.git and I'm in master branch. > > $ ./configure > checking build system type... x86_64-unknown-linux-gnu > checking host system type... x86_64-unknown-linux-gnu > checking target system type… x86_64-unknown-linux-gnu > This is normal; I get the same on openSUSE and IIRC it had always been the case. > The unknown seems suspicious. And at the end I see "GRUB2 will be compiled > with following components: > Platform: i386-pc" which is also wrong. > Well ... short of checking for /sys/firmware/efi, how can we know we may need efi build? > If I use --with-platform=efi, then at the end I get "GRUB2 will be compiled > with following components: > Platform: x86_64-efi" which is correct. > > In the configure file I see this: > # Guess the platform if not specified. > if test "x$with_platform" = x; then > case "$target_cpu"-"$target_vendor" in > i386-apple) platform=efi ;; > i386-*) platform=pc ;; > x86_64-apple) platform=efi ;; > > I guess $target_vendor isn't getting set to apple and therefore platform > doesn't get set to efi. You are running Linux, not OS X here, so $target_vendore cannot be apple. It refers to OS vendor, not underlying hardware vendor. > > > Chris Murphy > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB booting Mac OS X (xnu)
OK I've got this working. The problem was user error. Explicitly setting root is necessary, and I've updated the bug. https://savannah.gnu.org/bugs/index.php?42954 So the approach of chainloading Apple's boot.efi is valid. What's needed is to consider Recovery HD (Apple Boot partitiontype GUID) to be the partition searched by os-prober, figure out its UUID so that set root can be done by UUID. The Apple Boot [1] is used by OS X 10.7 through 10.10, so it's a good start point to search for OS X since it won't be anywhere else. Going forward, any conventional HFS+ partition [2] isn't going to be OS X, but instead will be any distribution using mactel boot, since putting grubx64.efi on the FAT32 ESP is *not* picked up by Apple's firmware as a legit bootloader. Only if there is an NVRAM entry for it, and bootcurrent has it listed first, can it be used. By putting grubx64.efi on hfsplus, and tricking the firmware into thinking it's an OS X bootloader, we get a prettier user friendly linux boot experience on Macs. [1] partitiontype GUID 426F6F74--11AA-AA11-00306543ECAC [2] partitiontype GUID 48465300--11AA-AA11-00306543ECAC Chris Murphy ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB booting Mac OS X (xnu)
On Oct 26, 2014, at 10:06 PM, Chris Murphy wrote: > OK I've got this working. The problem was user error. Explicitly setting root > is necessary, and I've updated the bug. > https://savannah.gnu.org/bugs/index.php?42954 > > So the approach of chainloading Apple's boot.efi is valid. What's needed is > to consider Recovery HD (Apple Boot partitiontype GUID) to be the partition > searched by os-prober, figure out its UUID so that set root can be done by > UUID. > > The Apple Boot [1] is used by OS X 10.7 through 10.10, so it's a good start > point to search for OS X since it won't be anywhere else. > > Going forward, any conventional HFS+ partition [2] isn't going to be OS X, > but instead will be any distribution using mactel boot, since putting > grubx64.efi on the FAT32 ESP is *not* picked up by Apple's firmware as a > legit bootloader. Only if there is an NVRAM entry for it, and bootcurrent has > it listed first, can it be used. By putting grubx64.efi on hfsplus, and > tricking the firmware into thinking it's an OS X bootloader, we get a > prettier user friendly linux boot experience on Macs. > > > [1] partitiontype GUID 426F6F74--11AA-AA11-00306543ECAC > [2] partitiontype GUID 48465300--11AA-AA11-00306543ECAC mactel-boot http://www.codon.org.uk/~mjg59/mactel-boot/ Chris Murphy ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
