On Sun, Mar 29, 2020 at 9:44 PM Simon J. Gerraty wrote:
> Warner Losh wrote:
> > True, but as we move from boot1.efi to loader.efi, the need will
> > grow... Even if we keep boot1.efi, loader.efi will be needed for
> > interesting secure systems, so we can't cop-out like we have in the
> > past
Warner Losh wrote:
> True, but as we move from boot1.efi to loader.efi, the need will
> grow... Even if we keep boot1.efi, loader.efi will be needed for
> interesting secure systems, so we can't cop-out like we have in the
> past.
Sigh, that would force me to have to add verification to boot1.ef
29.03.20 14:55, Dimitry Andric пишет:
On 29 Mar 2020, at 13:02, Alexandr Krivulya wrote:
28.03.20 18:32, Dimitry Andric пишет:
On 28 Mar 2020, at 13:48, Alexandr Krivulya wrote:
...
This typically happens if you don't run "make buildworld", or at least
"make kernel-toolchain" before running
On Sun, Mar 29, 2020 at 9:24 PM Kyle Evans wrote:
> On Sun, Mar 29, 2020 at 10:16 PM Rebecca Cran wrote:
> >
> >
> > > On Mar 29, 2020, at 9:11 PM, Nathan Whitehorn
> wrote:
> > >
> > > The problem then is that we have treated loader as a
> > > continuously-updatable part of the OS, like the ke
On Sun, Mar 29, 2020 at 9:14 PM Nathan Whitehorn
wrote:
>
>
> On 2020-03-29 20:02, Simon J. Gerraty wrote:
> > Nathan Whitehorn wrote:
> >> It's basically this that has been the problem: we need a way to manage
> >> updates of the EFI loader in this situation, which we don't currently
> >> have.
On Sun, Mar 29, 2020 at 9:23 PM Rebecca Cran wrote:
>
> > On Mar 29, 2020, at 9:11 PM, Nathan Whitehorn
> wrote:
> >
> > The problem then is that we have treated loader as a
> > continuously-updatable part of the OS, like the kernel, and the update
> > system and development process assumes they
On Sun, Mar 29, 2020 at 10:16 PM Rebecca Cran wrote:
>
>
> > On Mar 29, 2020, at 9:11 PM, Nathan Whitehorn
> > wrote:
> >
> > The problem then is that we have treated loader as a
> > continuously-updatable part of the OS, like the kernel, and the update
> > system and development process assumes
> On Mar 29, 2020, at 9:11 PM, Nathan Whitehorn wrote:
>
> The problem then is that we have treated loader as a
> continuously-updatable part of the OS, like the kernel, and the update
> system and development process assumes they get updated in sync.
But at the moment how often do users mount
Nathan Whitehorn wrote:
> It's basically this that has been the problem: we need a way to manage
> updates of the EFI loader in this situation, which we don't currently
> have. The ESP needs to be mounted at a standard point,
> installworld/freebsd-update/etc. need to know to replace files there,
On 2020-03-29 20:02, Simon J. Gerraty wrote:
> Nathan Whitehorn wrote:
>> It's basically this that has been the problem: we need a way to manage
>> updates of the EFI loader in this situation, which we don't currently
>> have. The ESP needs to be mounted at a standard point,
>> installworld/fre
Rebecca Cran wrote:
> That's another thing: we should be installing loader.efi as
> \efi\boot\bootx64.efi (as well as \boot\freebsd\loader.efi) since it's
> entirely possible to lose the Boot Manager entry and end up with an
> unbootable system as a result. Unfortunately people have had bad
> expe
On 2020-03-29 19:09, Kyle Evans wrote:
> On Sun, Mar 29, 2020 at 6:19 PM Rebecca Cran wrote:
>> On 3/29/20 6:11 AM, Tomoaki AOKI wrote:
>>
>>> 3. based solution looks good to me.
>>>
>>> IMHO, assuming /efi/bootx[64|32].efi is boot1.efi or loader.efi
>>> or EFI environment pointing to either on
On 3/29/20 8:09 PM, Kyle Evans wrote:
I'd be in favor of installing to \EFI\BOOT\... as well if and only if
the file doesn't already exist, assuming we can figure out how to make
it not a maintenance nightmare -- which I suspect would just mean that
we have some tool that users use to update the
On Sun, Mar 29, 2020 at 6:19 PM Rebecca Cran wrote:
>
> On 3/29/20 6:11 AM, Tomoaki AOKI wrote:
>
> >
> > 3. based solution looks good to me.
> >
> > IMHO, assuming /efi/bootx[64|32].efi is boot1.efi or loader.efi
> > or EFI environment pointing to either one is properly used,
>
>
> That's another
> On 3/29/20 6:11 AM, Tomoaki AOKI wrote:
>
> >
> > 3. based solution looks good to me.
> >
> > IMHO, assuming /efi/bootx[64|32].efi is boot1.efi or loader.efi
> > or EFI environment pointing to either one is properly used,
>
>
> That's another thing: we should be installing loader.efi as
> \e
On 3/29/20 6:11 AM, Tomoaki AOKI wrote:
3. based solution looks good to me.
IMHO, assuming /efi/bootx[64|32].efi is boot1.efi or loader.efi
or EFI environment pointing to either one is properly used,
That's another thing: we should be installing loader.efi as
\efi\boot\bootx64.efi (as wel
On Sun, 2020-03-29 at 09:44 -0700, Thomas Skibo wrote:
> On Sun, Mar 29, 2020 at 12:29:00AM -0700, Mark Millard via freebsd-
> arm wrote:
> > While trying to update the head version
> > in use I ran into boot hangups on the
> > OrangePi+ 2e and did an approximate
> > bisect of artificact.freebsd.or
Hello,
I am trying to build -CURRENT with some custom build options, which are
the following:
WITH_EXTRA_TCP_STACKS=1
WITH_BEARSSL=1
WITH_PIE=1
WITH_RETPOLINE=1
But WITH_PIE=1 seems to break the build while linking sbin/veriexec with the
following error messages.
===> sbin/veriexec (all)
===> l
On Sat, 28 Mar 2020 12:57:21 -0700
Chris wrote:
> On Sat, 28 Mar 2020 11:07:38 +0200 Toomas Soome tso...@me.com said
>
(snip)
> Thank you very much for your reply, Toomas.
> > How loader is working is that it does search for *first* “usable” freebsd
> > partition and will use it. Usable is def
I keep getting errors in building my ports from portsbuilder.
But it is with Current/Clang10.
So I'm trying to get a server at that level, but building world
keeps giving me:
--- all_subdir_cddl ---
ld: error: /usr/obj/usr/srcs/head/amd64.amd64/tmp/usr/lib/libuutil.so:
undefined reference to __a
On 29 Mar 2020, at 13:02, Alexandr Krivulya wrote:
>
> 28.03.20 18:32, Dimitry Andric пишет:
>> On 28 Mar 2020, at 13:48, Alexandr Krivulya wrote:
...
>> This typically happens if you don't run "make buildworld", or at least
>> "make kernel-toolchain" before running "make buildkernel", and your
29.03.20 14:12, David Wolfskill пишет:
On Sun, Mar 29, 2020 at 02:02:02PM +0300, Alexandr Krivulya wrote:
28.03.20 18:32, Dimitry Andric пишет:
...
This typically happens if you don't run "make buildworld", or at least
"make kernel-toolchain" before running "make buildkernel", and your
userland
On Sun, Mar 29, 2020 at 02:02:02PM +0300, Alexandr Krivulya wrote:
> 28.03.20 18:32, Dimitry Andric пишет:
> ...
> > This typically happens if you don't run "make buildworld", or at least
> > "make kernel-toolchain" before running "make buildkernel", and your
> > userland is missing those headers,
28.03.20 18:32, Dimitry Andric пишет:
On 28 Mar 2020, at 13:48, Alexandr Krivulya wrote:
28.03.20 14:35, David Wolfskill пишет:
On Sat, Mar 28, 2020 at 02:01:39PM +0200, Alexandr Krivulya wrote:
Hello,
on latest CURRENT kernel fails to build:
===> aesni (all)
[Creating objdir
/usr/obj/usr/s
While trying to update the head version
in use I ran into boot hangups on the
OrangePi+ 2e and did an approximate
bisect of artificact.freebsd.org kernels
to find approximately which kernel
version the issue started at.
I found that head -r359309 boots and
-r359311 fails (shown later below).
The o
25 matches
Mail list logo
