https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194359
--- Comment #14 from Craig Rodrigues ---
lstewart described the problem he encountered here:
https://lists.freebsd.org/pipermail/freebsd-fs/2012-August/014864.html
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194359
--- Comment #13 from Marcel Moolenaar ---
(In reply to Ed Maste from comment #12)
> From that file:
> > 73 if (stat("/sys/firmware/efi", &buf) != -1)
> > 74 flag |= EFI_SUPPORT;
>
> I'm not sure if Linux creates /
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194359
--- Comment #12 from Ed Maste ---
>From that file:
> 73 if (stat("/sys/firmware/efi", &buf) != -1)
> 74 flag |= EFI_SUPPORT;
I'm not sure if Linux creates /sys/firmware/efi for the legacy boot case, but
if so we'd
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194359
--- Comment #11 from Marcel Moolenaar ---
(In reply to Ed Maste from comment #9)
> > If the installer knows what the firmware is ((I don't know if we pass
> > anything from the loader to the kernel))
>
> We report if the system was booted
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194359
h...@beastielabs.net changed:
What|Removed |Added
CC||h...@beastielabs.net
--- Com
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194359
--- Comment #9 from Ed Maste ---
> If the installer knows what the firmware is ((I don't know if we pass
> anything from the loader to the kernel))
We report if the system was booted by BIOS or UEFI via the machdep.bootmethod
sysctl (retu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194359
Craig Rodrigues changed:
What|Removed |Added
CC||rodr...@freebsd.org
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194359
--- Comment #7 from Allan Jude ---
Ok, I can test the UEFI stuff on this side.
I can easily add the gpart set to the zfsboot portion of bsdinstall
Although I might make more sense to add it elsewhere to make it apply to
Nathan's parts of
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194359
--- Comment #6 from Colin Percival ---
Allan: My laptop doesn't refuse to boot, but it does behave badly (bogus error
message) when booting via BIOS + GPT if the fake MBR is not set to active.
Running the above-mentioned command fixes this
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194359
--- Comment #5 from Allan Jude ---
I don't have one of the systems that does not work, so it is hard for me to
test.
Who has a system that refuses to boot if the fake partition in the fake MBR
used in a GPT partition table is not set to ac
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194359
--- Comment #4 from Colin Percival ---
I have only a very vague notion of how booting works these days, but my
understanding is that we're already setting up things differently based on
whether we expect to boot via BIOS or UEFI; and that (
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194359
--- Comment #3 from Marcel Moolenaar ---
Indeed. The set attribute command was deliberately changed to apply not just to
partitions, but also to the scheme itself. This made it possible to to set the
active flag in the PMBR for the GPT sche
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194359
--- Comment #2 from Colin Percival ---
Very easy, once you know how: gpart set -a active
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org m
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194359
--- Comment #1 from Allan Jude ---
Is there an easy way to do that? Generally we're just installing what is in the
'/boot/pmbr' file. I don't think the gpart utility has the ability to set this
flag.
We either need gpart to be able to do t
14 matches
Mail list logo
