Re: [Bug 254395] bsdinstall: fail script install after BETA3

[Warner Losh]

On Fri, Mar 19, 2021 at 5:45 PM Chris  wrote:

> On 2021-03-19 15:55, Warner Losh wrote:
> > On Fri, Mar 19, 2021 at 4:49 PM Toomas Soome via freebsd-current <
> > freebsd-current@freebsd.org> wrote:
> >
> >>
> >>
> >> > On 20. Mar 2021, at 00:21, Yuri Pankov  wrote:
> >> >
> >> > Chris wrote:
> >> >> On 2021-03-19 13:06, bugzilla-nore...@freebsd.org wrote:
> >> >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395
> >> >>>
> >> >>> Nathan Whitehorn  changed:
> >> >>>
> >> >>>What|Removed |Added
> >> >>>
> >>
> 
> >> >>>
> >> >>>Severity|Affects Only Me |Affects Some People
> >> >>>  CC||i...@freebsd.org
> >> >>>Priority|--- |Normal
> >> >>>
> >> >>> --- Comment #6 from Nathan Whitehorn  ---
> >> >>> Thanks for the suggestion about the documentation -- I've updated
> the
> >> >>> man page.
> >> >>>
> >> >>> The core problem here is that our tar can't extract archives to
> FAT32
> >> >>> with
> >> >>> default options, since it treats inability to set modification time
> as
> >> >>> a fatal
> >> >>> error and FAT32 doesn't let you do that on the root directory. As
> >> >>> such, any
> >> >>> file in the release tarballs can't be extracted to FAT32. For
> >> interactive
> >> >>> installations, the bsdinstall distextract tool, a CURSES-y frontend
> to
> >> >>> libarchive, solves this by ignoring ctime/mtime errors.
> >> >>>
> >> >>> Some extra commentary on solutions, so it can be in one place.
> >> >>> Possibilities
> >> >>> are:
> >> >>>
> >> >>> 1. We drop /boot/efi from mtree. That will result in it not
> existing in
> >> >>> base.txz, solving this issue, but will result in it not being in
> >> >>> mtree. It will
> >> >>> also leave in place an identical bug that will break scripted
> >> >>> installation on
> >> >>> bare-metal POWER8 and POWER9 systems, although that is a tier-2
> >> platform.
> >> >>>
> >> >>> 2. We add an option to tar to ignore failure in setting ctime/mtime,
> >> >>> like the
> >> >>> interactive installer uses. This has the difficulty that the patch
> is
> >> >>> hacky and
> >> >>> would have to go through upstream.
> >> >>>
> >> >>> 3. We go back to using distextract for scripted installations as
> well
> >> as
> >> >>> interactive ones, reverting
> d7640440fb644fde697f62fdff0b55aa3a4d5ef7.
> >> >>> This
> >> >>> fixes this issue but will result in installation failures for
> scripted
> >> >>> installs
> >> >>> without a controlling tty. (It will also add nice progress bars to
> >> >>> scripted
> >> >>> installs).
> >> >>>
> >> >>> 4. We do --exclude /boot/efi when running tar, then mkdir -p it by
> hand
> >> >>> afterward. This is incredibly hacky and otherwise essentially
> >> >>> functionally
> >> >>> equivalent to #1. Like #1, it will fix this issue and has no obvious
> >> >>> functional
> >> >>> downside, but leaves scripted installs bare-metal POWER8 and POWER9
> >> >>> broken.
> >> >>>
> >> >>> 5. We patch the file system driver to (pretend to) allow setting
> times
> >> >>> on the
> >> >>> mount point. I don't want to do this, since I don't want to solve
> this
> >> >>> in the
> >> >>> kernel at RC3 and I don't like it pretending to do things it can't
> do.
> >> >>
> >> >>  6. (my favorite) do NOT require that the efi/ partition be in
> strictly
> >> a
> >> >>  fat32 format. I mean fat32 is not strictly required as the format
> for
> >> >> the efi
> >> >>  partition. It is simply _assumed_ to be the required format and as
> >> >> such, the
> >> >>  one used in so many cases.
> >> >
> >> > Wrong, see "13.3 File System Format" in UEFI specification.
> >> >
> >>
> >> it is not as simple as that:)
> >>
> >>
> >> 13.3.1.1 is more specific:
> >> =
> >> The EFI firmware must support the FAT32, FAT16, and FAT12 variants of
> the
> >> EFI file system. What variant of EFI FAT to use is defined by the size
> of
> >> the media. The rules defining the relationship between media size and
> FAT
> >> variants is defined in the specification for the EFI file system.
> >>
> >
> > We've also seen a few non-conformant systems where FAT12 support has been
> > removed, so there's also a bit of real-world experience that goes along
> > with reading the UEFI specification :(.
> I suppose that may be part of where my understanding came from. I've
> got a couple of "hackintoshes" that dual-boot OS X, and FreeBSD. Part of
> the process was working with the EFI partition (ESP) to get recognition
> of both OS's in the (EFI) boot menu, as well as getting the firmware
> properly functional in both instances. I also draw from a long article
> by a boot manager author whom insisted that fat32 was not a requirement.
> I've not got the time ATM to dig up the article. But it had many pointers
> to the EFI spec to prove the point. All of which I verified.
> In any case, sor

Re: [Bug 254395] bsdinstall: fail script install after BETA3

[Chris]

On 2021-03-19 15:55, Warner Losh wrote:

On Fri, Mar 19, 2021 at 4:49 PM Toomas Soome via freebsd-current <
freebsd-current@freebsd.org> wrote:




> On 20. Mar 2021, at 00:21, Yuri Pankov  wrote:
>
> Chris wrote:
>> On 2021-03-19 13:06, bugzilla-nore...@freebsd.org wrote:
>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395
>>>
>>> Nathan Whitehorn  changed:
>>>
>>>What|Removed |Added
>>>

>>>
>>>Severity|Affects Only Me |Affects Some People
>>>  CC||i...@freebsd.org
>>>Priority|--- |Normal
>>>
>>> --- Comment #6 from Nathan Whitehorn  ---
>>> Thanks for the suggestion about the documentation -- I've updated the
>>> man page.
>>>
>>> The core problem here is that our tar can't extract archives to FAT32
>>> with
>>> default options, since it treats inability to set modification time as
>>> a fatal
>>> error and FAT32 doesn't let you do that on the root directory. As
>>> such, any
>>> file in the release tarballs can't be extracted to FAT32. For
interactive
>>> installations, the bsdinstall distextract tool, a CURSES-y frontend to
>>> libarchive, solves this by ignoring ctime/mtime errors.
>>>
>>> Some extra commentary on solutions, so it can be in one place.
>>> Possibilities
>>> are:
>>>
>>> 1. We drop /boot/efi from mtree. That will result in it not existing in
>>> base.txz, solving this issue, but will result in it not being in
>>> mtree. It will
>>> also leave in place an identical bug that will break scripted
>>> installation on
>>> bare-metal POWER8 and POWER9 systems, although that is a tier-2
platform.
>>>
>>> 2. We add an option to tar to ignore failure in setting ctime/mtime,
>>> like the
>>> interactive installer uses. This has the difficulty that the patch is
>>> hacky and
>>> would have to go through upstream.
>>>
>>> 3. We go back to using distextract for scripted installations as well
as
>>> interactive ones, reverting d7640440fb644fde697f62fdff0b55aa3a4d5ef7.
>>> This
>>> fixes this issue but will result in installation failures for scripted
>>> installs
>>> without a controlling tty. (It will also add nice progress bars to
>>> scripted
>>> installs).
>>>
>>> 4. We do --exclude /boot/efi when running tar, then mkdir -p it by hand
>>> afterward. This is incredibly hacky and otherwise essentially
>>> functionally
>>> equivalent to #1. Like #1, it will fix this issue and has no obvious
>>> functional
>>> downside, but leaves scripted installs bare-metal POWER8 and POWER9
>>> broken.
>>>
>>> 5. We patch the file system driver to (pretend to) allow setting times
>>> on the
>>> mount point. I don't want to do this, since I don't want to solve this
>>> in the
>>> kernel at RC3 and I don't like it pretending to do things it can't do.
>>
>>  6. (my favorite) do NOT require that the efi/ partition be in strictly
a
>>  fat32 format. I mean fat32 is not strictly required as the format for
>> the efi
>>  partition. It is simply _assumed_ to be the required format and as
>> such, the
>>  one used in so many cases.
>
> Wrong, see "13.3 File System Format" in UEFI specification.
>

it is not as simple as that:)


13.3.1.1 is more specific:
=
The EFI firmware must support the FAT32, FAT16, and FAT12 variants of the
EFI file system. What variant of EFI FAT to use is defined by the size of
the media. The rules defining the relationship between media size and FAT
variants is defined in the specification for the EFI file system.



We've also seen a few non-conformant systems where FAT12 support has been
removed, so there's also a bit of real-world experience that goes along
with reading the UEFI specification :(.

I suppose that may be part of where my understanding came from. I've
got a couple of "hackintoshes" that dual-boot OS X, and FreeBSD. Part of
the process was working with the EFI partition (ESP) to get recognition
of both OS's in the (EFI) boot menu, as well as getting the firmware
properly functional in both instances. I also draw from a long article
by a boot manager author whom insisted that fat32 was not a requirement.
I've not got the time ATM to dig up the article. But it had many pointers
to the EFI spec to prove the point. All of which I verified.
In any case, sorry for the noise if I'm wrong. I'll dig up my references
when I can find the time. :-)

--Chris


Warner

On Fri, Mar 19, 2021 at 4:49 PM Toomas Soome via freebsd-current <
freebsd-current@freebsd.org> wrote:

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [Bug 254395] bsdinstall: fail script install after BETA3

[Warner Losh]

On Fri, Mar 19, 2021 at 4:49 PM Toomas Soome via freebsd-current <
freebsd-current@freebsd.org> wrote:

>
>
> > On 20. Mar 2021, at 00:21, Yuri Pankov  wrote:
> >
> > Chris wrote:
> >> On 2021-03-19 13:06, bugzilla-nore...@freebsd.org wrote:
> >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395
> >>>
> >>> Nathan Whitehorn  changed:
> >>>
> >>>What|Removed |Added
> >>>
> 
> >>>
> >>>Severity|Affects Only Me |Affects Some People
> >>>  CC||i...@freebsd.org
> >>>Priority|--- |Normal
> >>>
> >>> --- Comment #6 from Nathan Whitehorn  ---
> >>> Thanks for the suggestion about the documentation -- I've updated the
> >>> man page.
> >>>
> >>> The core problem here is that our tar can't extract archives to FAT32
> >>> with
> >>> default options, since it treats inability to set modification time as
> >>> a fatal
> >>> error and FAT32 doesn't let you do that on the root directory. As
> >>> such, any
> >>> file in the release tarballs can't be extracted to FAT32. For
> interactive
> >>> installations, the bsdinstall distextract tool, a CURSES-y frontend to
> >>> libarchive, solves this by ignoring ctime/mtime errors.
> >>>
> >>> Some extra commentary on solutions, so it can be in one place.
> >>> Possibilities
> >>> are:
> >>>
> >>> 1. We drop /boot/efi from mtree. That will result in it not existing in
> >>> base.txz, solving this issue, but will result in it not being in
> >>> mtree. It will
> >>> also leave in place an identical bug that will break scripted
> >>> installation on
> >>> bare-metal POWER8 and POWER9 systems, although that is a tier-2
> platform.
> >>>
> >>> 2. We add an option to tar to ignore failure in setting ctime/mtime,
> >>> like the
> >>> interactive installer uses. This has the difficulty that the patch is
> >>> hacky and
> >>> would have to go through upstream.
> >>>
> >>> 3. We go back to using distextract for scripted installations as well
> as
> >>> interactive ones, reverting d7640440fb644fde697f62fdff0b55aa3a4d5ef7.
> >>> This
> >>> fixes this issue but will result in installation failures for scripted
> >>> installs
> >>> without a controlling tty. (It will also add nice progress bars to
> >>> scripted
> >>> installs).
> >>>
> >>> 4. We do --exclude /boot/efi when running tar, then mkdir -p it by hand
> >>> afterward. This is incredibly hacky and otherwise essentially
> >>> functionally
> >>> equivalent to #1. Like #1, it will fix this issue and has no obvious
> >>> functional
> >>> downside, but leaves scripted installs bare-metal POWER8 and POWER9
> >>> broken.
> >>>
> >>> 5. We patch the file system driver to (pretend to) allow setting times
> >>> on the
> >>> mount point. I don't want to do this, since I don't want to solve this
> >>> in the
> >>> kernel at RC3 and I don't like it pretending to do things it can't do.
> >>
> >>  6. (my favorite) do NOT require that the efi/ partition be in strictly
> a
> >>  fat32 format. I mean fat32 is not strictly required as the format for
> >> the efi
> >>  partition. It is simply _assumed_ to be the required format and as
> >> such, the
> >>  one used in so many cases.
> >
> > Wrong, see "13.3 File System Format" in UEFI specification.
> >
>
> it is not as simple as that:)
>
>
> 13.3.1.1 is more specific:
> =
> The EFI firmware must support the FAT32, FAT16, and FAT12 variants of the
> EFI file system. What variant of EFI FAT to use is defined by the size of
> the media. The rules defining the relationship between media size and FAT
> variants is defined in the specification for the EFI file system.
>

We've also seen a few non-conformant systems where FAT12 support has been
removed, so there's also a bit of real-world experience that goes along
with reading the UEFI specification :(.

Warner

On Fri, Mar 19, 2021 at 4:49 PM Toomas Soome via freebsd-current <
freebsd-current@freebsd.org> wrote:

>
>
> > On 20. Mar 2021, at 00:21, Yuri Pankov  wrote:
> >
> > Chris wrote:
> >> On 2021-03-19 13:06, bugzilla-nore...@freebsd.org wrote:
> >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395
> >>>
> >>> Nathan Whitehorn  changed:
> >>>
> >>>What|Removed |Added
> >>>
> 
> >>>
> >>>Severity|Affects Only Me |Affects Some People
> >>>  CC||i...@freebsd.org
> >>>Priority|--- |Normal
> >>>
> >>> --- Comment #6 from Nathan Whitehorn  ---
> >>> Thanks for the suggestion about the documentation -- I've updated the
> >>> man page.
> >>>
> >>> The core problem here is that our tar can't extract archives to FAT32
> >>> with
> >>> default options, since it treats inability to set modification time as
>

Re: [Bug 254395] bsdinstall: fail script install after BETA3

[Toomas Soome via freebsd-current]

> On 20. Mar 2021, at 00:21, Yuri Pankov  wrote:
> 
> Chris wrote:
>> On 2021-03-19 13:06, bugzilla-nore...@freebsd.org wrote:
>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395
>>> 
>>> Nathan Whitehorn  changed:
>>> 
>>>What|Removed |Added
>>> 
>>> 
>>>Severity|Affects Only Me |Affects Some People
>>>  CC||i...@freebsd.org
>>>Priority|--- |Normal
>>> 
>>> --- Comment #6 from Nathan Whitehorn  ---
>>> Thanks for the suggestion about the documentation -- I've updated the
>>> man page.
>>> 
>>> The core problem here is that our tar can't extract archives to FAT32
>>> with
>>> default options, since it treats inability to set modification time as
>>> a fatal
>>> error and FAT32 doesn't let you do that on the root directory. As
>>> such, any
>>> file in the release tarballs can't be extracted to FAT32. For interactive
>>> installations, the bsdinstall distextract tool, a CURSES-y frontend to
>>> libarchive, solves this by ignoring ctime/mtime errors.
>>> 
>>> Some extra commentary on solutions, so it can be in one place.
>>> Possibilities
>>> are:
>>> 
>>> 1. We drop /boot/efi from mtree. That will result in it not existing in
>>> base.txz, solving this issue, but will result in it not being in
>>> mtree. It will
>>> also leave in place an identical bug that will break scripted
>>> installation on
>>> bare-metal POWER8 and POWER9 systems, although that is a tier-2 platform.
>>> 
>>> 2. We add an option to tar to ignore failure in setting ctime/mtime,
>>> like the
>>> interactive installer uses. This has the difficulty that the patch is
>>> hacky and
>>> would have to go through upstream.
>>> 
>>> 3. We go back to using distextract for scripted installations as well as
>>> interactive ones, reverting d7640440fb644fde697f62fdff0b55aa3a4d5ef7.
>>> This
>>> fixes this issue but will result in installation failures for scripted
>>> installs
>>> without a controlling tty. (It will also add nice progress bars to
>>> scripted
>>> installs).
>>> 
>>> 4. We do --exclude /boot/efi when running tar, then mkdir -p it by hand
>>> afterward. This is incredibly hacky and otherwise essentially
>>> functionally
>>> equivalent to #1. Like #1, it will fix this issue and has no obvious
>>> functional
>>> downside, but leaves scripted installs bare-metal POWER8 and POWER9
>>> broken.
>>> 
>>> 5. We patch the file system driver to (pretend to) allow setting times
>>> on the
>>> mount point. I don't want to do this, since I don't want to solve this
>>> in the
>>> kernel at RC3 and I don't like it pretending to do things it can't do.
>> 
>>  6. (my favorite) do NOT require that the efi/ partition be in strictly a
>>  fat32 format. I mean fat32 is not strictly required as the format for
>> the efi
>>  partition. It is simply _assumed_ to be the required format and as
>> such, the
>>  one used in so many cases.
> 
> Wrong, see "13.3 File System Format" in UEFI specification.
> 

it is not as simple as that:)


13.3.1.1 is more specific:
=
The EFI firmware must support the FAT32, FAT16, and FAT12 variants of the EFI 
file system. What variant of EFI FAT to use is defined by the size of the 
media. The rules defining the relationship between media size and FAT variants 
is defined in the specification for the EFI file system.

=

rgds,
toomas

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [Bug 254395] bsdinstall: fail script install after BETA3

[Yuri Pankov]

Chris wrote:
> On 2021-03-19 13:06, bugzilla-nore...@freebsd.org wrote:
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395
>>
>> Nathan Whitehorn  changed:
>>
>>    What    |Removed |Added
>> 
>>
>>    Severity|Affects Only Me |Affects Some People
>>  CC|    |i...@freebsd.org
>>    Priority|--- |Normal
>>
>> --- Comment #6 from Nathan Whitehorn  ---
>> Thanks for the suggestion about the documentation -- I've updated the
>> man page.
>>
>> The core problem here is that our tar can't extract archives to FAT32
>> with
>> default options, since it treats inability to set modification time as
>> a fatal
>> error and FAT32 doesn't let you do that on the root directory. As
>> such, any
>> file in the release tarballs can't be extracted to FAT32. For interactive
>> installations, the bsdinstall distextract tool, a CURSES-y frontend to
>> libarchive, solves this by ignoring ctime/mtime errors.
>>
>> Some extra commentary on solutions, so it can be in one place.
>> Possibilities
>> are:
>>
>> 1. We drop /boot/efi from mtree. That will result in it not existing in
>> base.txz, solving this issue, but will result in it not being in
>> mtree. It will
>> also leave in place an identical bug that will break scripted
>> installation on
>> bare-metal POWER8 and POWER9 systems, although that is a tier-2 platform.
>>
>> 2. We add an option to tar to ignore failure in setting ctime/mtime,
>> like the
>> interactive installer uses. This has the difficulty that the patch is
>> hacky and
>> would have to go through upstream.
>>
>> 3. We go back to using distextract for scripted installations as well as
>> interactive ones, reverting d7640440fb644fde697f62fdff0b55aa3a4d5ef7.
>> This
>> fixes this issue but will result in installation failures for scripted
>> installs
>> without a controlling tty. (It will also add nice progress bars to
>> scripted
>> installs).
>>
>> 4. We do --exclude /boot/efi when running tar, then mkdir -p it by hand
>> afterward. This is incredibly hacky and otherwise essentially
>> functionally
>> equivalent to #1. Like #1, it will fix this issue and has no obvious
>> functional
>> downside, but leaves scripted installs bare-metal POWER8 and POWER9
>> broken.
>>
>> 5. We patch the file system driver to (pretend to) allow setting times
>> on the
>> mount point. I don't want to do this, since I don't want to solve this
>> in the
>> kernel at RC3 and I don't like it pretending to do things it can't do.
> 
>  6. (my favorite) do NOT require that the efi/ partition be in strictly a
>  fat32 format. I mean fat32 is not strictly required as the format for
> the efi
>  partition. It is simply _assumed_ to be the required format and as
> such, the
>  one used in so many cases.

Wrong, see "13.3 File System Format" in UEFI specification.

> Whould it actually be that much harder to use ffs/ufs?
> 
> You asked. ;-)
> 
>>
>> 
>>
>> Of these, 1, 3, and 4 are quite easy to implement, but all have some
>> downside.
>> My temptation is to do 4 for 13.0, since it will definitely work but
>> is just
>> lame, then either do #2 or a variant on #3 where distextract notices
>> there is
>> no tty and doesn't try to set up a dialog as a longer-term fix in
>> HEAD. Any
>> thoughts?

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [Bug 254395] bsdinstall: fail script install after BETA3

[Chris]

On 2021-03-19 13:06, bugzilla-nore...@freebsd.org wrote:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395

Nathan Whitehorn  changed:

   What|Removed |Added

   Severity|Affects Only Me |Affects Some People
 CC||i...@freebsd.org
   Priority|--- |Normal

--- Comment #6 from Nathan Whitehorn  ---
Thanks for the suggestion about the documentation -- I've updated the man 
page.


The core problem here is that our tar can't extract archives to FAT32 with
default options, since it treats inability to set modification time as a 
fatal

error and FAT32 doesn't let you do that on the root directory. As such, any
file in the release tarballs can't be extracted to FAT32. For interactive
installations, the bsdinstall distextract tool, a CURSES-y frontend to
libarchive, solves this by ignoring ctime/mtime errors.

Some extra commentary on solutions, so it can be in one place. Possibilities
are:

1. We drop /boot/efi from mtree. That will result in it not existing in
base.txz, solving this issue, but will result in it not being in mtree. It 
will
also leave in place an identical bug that will break scripted installation 
on

bare-metal POWER8 and POWER9 systems, although that is a tier-2 platform.

2. We add an option to tar to ignore failure in setting ctime/mtime, like 
the
interactive installer uses. This has the difficulty that the patch is hacky 
and

would have to go through upstream.

3. We go back to using distextract for scripted installations as well as
interactive ones, reverting d7640440fb644fde697f62fdff0b55aa3a4d5ef7. This
fixes this issue but will result in installation failures for scripted 
installs

without a controlling tty. (It will also add nice progress bars to scripted
installs).

4. We do --exclude /boot/efi when running tar, then mkdir -p it by hand
afterward. This is incredibly hacky and otherwise essentially functionally
equivalent to #1. Like #1, it will fix this issue and has no obvious 
functional

downside, but leaves scripted installs bare-metal POWER8 and POWER9 broken.

5. We patch the file system driver to (pretend to) allow setting times on 
the
mount point. I don't want to do this, since I don't want to solve this in 
the

kernel at RC3 and I don't like it pretending to do things it can't do.


 6. (my favorite) do NOT require that the efi/ partition be in strictly a
 fat32 format. I mean fat32 is not strictly required as the format for the 
efi

 partition. It is simply _assumed_ to be the required format and as such, the
 one used in so many cases.

Whould it actually be that much harder to use ffs/ufs?

You asked. ;-)





Of these, 1, 3, and 4 are quite easy to implement, but all have some 
downside.

My temptation is to do 4 for 13.0, since it will definitely work but is just
lame, then either do #2 or a variant on #3 where distextract notices there 
is

no tty and doesn't try to set up a dialog as a longer-term fix in HEAD. Any
thoughts?

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Getting started with ktls

[Rick Macklem]

J. wrote:
>on the (main/14) server, /etc/rpc.tlsservd was not already there; I had
>to create it. Is this correct?
>
>version is main-n245454
I'll admit I have no idea what n245454 means, but the daemons were
committed to main on Feb 18, 2021.
Installing them from ports should be fine.

rick

--
J.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[Bug 254395] bsdinstall: fail script install after BETA3

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395

--- Comment #11 from Nathan Whitehorn  ---
(In reply to Warner Losh from comment #10)

It's pretty tricky, since it touches code in a lot of places, has to be
conditional on platform, and runs a risk of breaking interactive installs just
because it is pretty invasive.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

no time selection screen in installer anymore

[Yuri Pankov]

Installing from
FreeBSD-14.0-CURRENT-amd64-20210318-a771bf748f9-245511-disc1.iso, I
noticed that there's no time selection screen anymore; TZ is there, date
is there, and only time is missing.

Not that I miss it much, but it does not seem to be removed from source,
so I'm wondering if it's recent dialog update that broke it?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[Bug 254395] bsdinstall: fail script install after BETA3

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395

--- Comment #10 from Warner Losh  ---
(In reply to Ryan Moeller from comment #8)
Oh! I like this idea better, I think, but I don't know how hard it is to do.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[Bug 254395] bsdinstall: fail script install after BETA3

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395

--- Comment #9 from Nathan Whitehorn  ---
(In reply to Ryan Moeller from comment #8)

We could delay it, but it's harder and less-localized than the other solutions.
It also completely breaks PowerPC and other systems with analagous but non-ESP
boot partions.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[Bug 254395] bsdinstall: fail script install after BETA3

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395

--- Comment #8 from Ryan Moeller  ---
Would it be possible to defer mounting the ESP until after the tarballs have
been extracted? We don't actually have anything in /boot/efi in the base
archive. My understanding is that it's just there to ensure the mountpoint
exists.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[Bug 254395] bsdinstall: fail script install after BETA3

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395

--- Comment #7 from Warner Losh  ---
#4 sounds good for 13.0. Of the hacks, it's the most localized and least hacky,
imho.

I'd prefer #5, honestly, longer term but I've not thought through all the
implictions. We should loop in cem@ since he's been touching that code most
recently. Or delphij@ as he has too...

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Important Message curr...@freebsd.org

[ANZ Internet Banking]

  
   
 
 
   
 
 
   
 Dear ANZ customer 
 
 Your ANZ Internet Banking access has been violated. We suspected someone other 
than you with IP 178.210.92*** trying to access your information's. 
 
Please verify your banking information with us to show that you are not 
currently away. You have to verify this as soon as possible to prevent your 
online bank account from getting suspended. 
Restore your Access  
© Australia and New Zealand Banking Group Limited (ANZ) ABN 11 005 357 522. 
ACLN and AFSL Number 234527. 
 
 
 
   
 
 
  
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[Bug 254395] bsdinstall: fail script install after BETA3

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395

Nathan Whitehorn  changed:

   What|Removed |Added

   Severity|Affects Only Me |Affects Some People
 CC||i...@freebsd.org
   Priority|--- |Normal

--- Comment #6 from Nathan Whitehorn  ---
Thanks for the suggestion about the documentation -- I've updated the man page.

The core problem here is that our tar can't extract archives to FAT32 with
default options, since it treats inability to set modification time as a fatal
error and FAT32 doesn't let you do that on the root directory. As such, any
file in the release tarballs can't be extracted to FAT32. For interactive
installations, the bsdinstall distextract tool, a CURSES-y frontend to
libarchive, solves this by ignoring ctime/mtime errors.

Some extra commentary on solutions, so it can be in one place. Possibilities
are:

1. We drop /boot/efi from mtree. That will result in it not existing in
base.txz, solving this issue, but will result in it not being in mtree. It will
also leave in place an identical bug that will break scripted installation on
bare-metal POWER8 and POWER9 systems, although that is a tier-2 platform.

2. We add an option to tar to ignore failure in setting ctime/mtime, like the
interactive installer uses. This has the difficulty that the patch is hacky and
would have to go through upstream.

3. We go back to using distextract for scripted installations as well as
interactive ones, reverting d7640440fb644fde697f62fdff0b55aa3a4d5ef7. This
fixes this issue but will result in installation failures for scripted installs
without a controlling tty. (It will also add nice progress bars to scripted
installs).

4. We do --exclude /boot/efi when running tar, then mkdir -p it by hand
afterward. This is incredibly hacky and otherwise essentially functionally
equivalent to #1. Like #1, it will fix this issue and has no obvious functional
downside, but leaves scripted installs bare-metal POWER8 and POWER9 broken.

5. We patch the file system driver to (pretend to) allow setting times on the
mount point. I don't want to do this, since I don't want to solve this in the
kernel at RC3 and I don't like it pretending to do things it can't do.



Of these, 1, 3, and 4 are quite easy to implement, but all have some downside.
My temptation is to do 4 for 13.0, since it will definitely work but is just
lame, then either do #2 or a variant on #3 where distextract notices there is
no tty and doesn't try to set up a dialog as a longer-term fix in HEAD. Any
thoughts?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[Bug 254395] bsdinstall: fail script install after BETA3

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395

Andrey Fesenko  changed:

   What|Removed |Added

 Blocks||231027


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231027
[Bug 231027] [META] FreeBSD-Foundation sponsored issues for FreeBSD 13-CURRENT
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Getting started with ktls

[tech-lists]

On Sun, Mar 14, 2021 at 11:07:23PM +, tech-lists wrote:

On Sun, Mar 14, 2021 at 08:55:18PM +, Rick Macklem wrote:

If you want to try NFS-over-TLS, see this:
https://people.freebsd.org/~rmacklem/nfs-over-tls-setup.txt



Please let us know if you try it, rick


Hi,

on the (main/14) server, /etc/rpc.tlsservd was not already there; I had
to create it. Is this correct?

version is main-n245454
--
J.


signature.asc
Description: PGP signature

Re: panic: malloc(M_WAITOK) with sleeping prohibited

[Warner Losh]

On Fri, Mar 19, 2021 at 7:23 AM Yuri Pankov  wrote:

> Yuri Pankov wrote:
> > H/W: Supermicro X9DRI-LN4F+, booting from IPMI Virtual CD-ROM using
> > FreeBSD-14.0-CURRENT-amd64-20210311-15565e0a217-257277-disc1.iso.
>
> Somehow I missed that it was already reported (a lot) and seems to be
> already fixed with
> FreeBSD-14.0-CURRENT-amd64-20210318-a771bf748f9-245511-disc1.iso, sorry
> for the noise.
>

Thanks for testing the newer version. It was the first thing I was going to
ask...

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[Bug 254395] bsdinstall: fail script install after BETA3

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395

--- Comment #5 from Andrey Fesenko  ---
(In reply to Nathan Whitehorn from comment #3)
If possible, it is also worth mentioning in the release notes that you no
longer need to specify the efi and boot partitions, but is it possible to make
the efi partition smaller, since 260M is a lot for a virtual machine, where
there will be only 1 system

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[Bug 254395] bsdinstall: fail script install after BETA3

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395

--- Comment #4 from Andrey Fesenko  ---
(In reply to Nathan Whitehorn from comment #1)

Installer fail, if set PARTITIONS="$DISKSLICE GPT { auto freebsd-ufs / }" fail
too
https://64.media.tumblr.com/2c95d2ddeed5cc2bd7ffb8fc68f34436/f8abb8c6d81ea645-e4/s1280x1920/6c4753c8bfdd3af75f597371189c4dcb1cbf0880.png

build packer
"qemu_binary": "/usr/libexec/qemu-kvm",
"-bios",
"/usr/share/edk2.git/ovmf-x64/OVMF-pure-efi.fd"

Check virtualbox builder BETA4 installer ok. RC2 fail, similar error

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: malloc(M_WAITOK) with sleeping prohibited

[Yuri Pankov]

Yuri Pankov wrote:
> H/W: Supermicro X9DRI-LN4F+, booting from IPMI Virtual CD-ROM using
> FreeBSD-14.0-CURRENT-amd64-20210311-15565e0a217-257277-disc1.iso.

Somehow I missed that it was already reported (a lot) and seems to be
already fixed with
FreeBSD-14.0-CURRENT-amd64-20210318-a771bf748f9-245511-disc1.iso, sorry
for the noise.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[Bug 254395] bsdinstall: fail script install after BETA3

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395

--- Comment #3 from Nathan Whitehorn  ---
Well, I found the issue and there's even a nice comment in the relevant code
that an older, smarter version of me put in in 2018 describing exactly why this
is going to break:


# Unpack distributions
bsdinstall checksum
for set in $DISTRIBUTIONS; do
f_dprintf "Extracting $BSDINSTALL_DISTDIR/$set"
# XXX: this will fail if any mountpoints are FAT, due to inability to
# set ctime/mtime on the root of FAT partitions. tar has no option to
# ignore this. We probably need to switch back to distextract here
# to properly support EFI.
tar -xf "$BSDINSTALL_DISTDIR/$set" -C $BSDINSTALL_CHROOT
done



I'll try to get a patch in today. Apologies for the breakage, and thanks for
the report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

panic: malloc(M_WAITOK) with sleeping prohibited

[Yuri Pankov]

H/W: Supermicro X9DRI-LN4F+, booting from IPMI Virtual CD-ROM using
FreeBSD-14.0-CURRENT-amd64-20210311-15565e0a217-257277-disc1.iso.

Root mount waiting for: usbus0
ugen0.4:  at usbus0
umass0 numa-domain 0 on uhub2
umass0: 
on usbus0
umass0: SCSI over Bulk-Only; quirks = 0xc101
umass0:7:0: Attached to scbus7
umass1 numa-domain 0 on uhub2
umass1: 
on usbus0
umass1: 8070i (ATAPI) over Bulk-Only; quirks = 0xc101
umass1:8:1: Attached to scbus8
panic: malloc(M_WAITOK) with sleeping prohibited
cpuid = 37
time = 9
KDB: stack backtrace:
db_trace_self_wrapper()
vpanic()
malloc_dbg()
malloc()
disk_alloc()
cdregister()
cam_periph_alloc()
cdasync()
xpt_async_process_dev()
xpt_async_process()
xpt_done_process()
xpt_done_td()
fork_exit()
fork_trampoline()
--- trap 0, rip = 0, rsp = 0, rbp =0 ---
KDB: enter: panic
[ thread pid 49 tid 100383 ]
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[Bug 254395] bsdinstall: fail script install after BETA3

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395

Ryan Moeller  changed:

   What|Removed |Added

 CC||freql...@freebsd.org

--- Comment #2 from Ryan Moeller  ---
This affects me as well. The install completely fails. I'm even doing EFI
installs: PARTITIONS="zvol/pool/dataset/vol gpt"

I've used this same script quite a lot and it has only started to fail
recently. I noticed yesterday and started looking into it a bit before I got
pulled into something else.

The tarball that fails to be extracted is base.txz (it's the one that contains
./boot/efi). The output on the console shows this as well:

DEBUG: dialog.subr: DEBUG_SELF_INITIALIZE=[]
DEBUG: UNAME_S=[FreeBSD] UNAME_P=[amd64] UNAME_R=[14.0-CURRENT]
DEBUG: common.subr: Successfully loaded.
DEBUG: f_debug_init: ARGV=[mount] GETOPTS_STDARGS=[dD:]
DEBUG: f_debug_init: debug=[1] debugFile=[]
DEBUG: Running installation step: mount
DEBUG: dialog.subr: DEBUG_SELF_INITIALIZE=[]
DEBUG: UNAME_S=[FreeBSD] UNAME_P=[amd64] UNAME_R=[14.0-CURRENT]
DEBUG: common.subr: Successfully loaded.
DEBUG: f_debug_init: ARGV=[checksum] GETOPTS_STDARGS=[dD:]
DEBUG: f_debug_init: debug=[1] debugFile=[]
DEBUG: Running installation step: checksum
DEBUG: Extracting /storage/bhyve/14.0-CURRENT/a771bf748f9/kernel.txz
DEBUG: Extracting /storage/bhyve/14.0-CURRENT/a771bf748f9/kernel-dbg.txz
DEBUG: Extracting /storage/bhyve/14.0-CURRENT/a771bf748f9/base.txz
ERROR: bsdinstall script failed

At this point the script exits, leaving the filesystems mounted even:

/dev/zvol/storage/bhyve/14.0-CURRENT/a771bf748f9/templatep2 on /mnt (ufs,
local, journaled soft-updates)
/dev/zvol/storage/bhyve/14.0-CURRENT/a771bf748f9/templatep1 on /mnt/boot/efi
(msdosfs, local)
devfs on /mnt/dev (devfs)

# cat /tmp/bsdinstall-tmp-fstab
/dev/zvol/storage/bhyve/14.0-CURRENT/a771bf748f9/templatep1 /mnt/boot/efi  
msdosfs rw  2   2
/dev/zvol/storage/bhyve/14.0-CURRENT/a771bf748f9/templatep2 /mntufs
rw  1   1
# cat /tmp/bsdinstall_etc/fstab
# DeviceMountpoint  FStype  Options DumpPass#
/dev/zvol/storage/bhyve/14.0-CURRENT/a771bf748f9/templatep1 /boot/efi  
msdosfs rw  2   2
/dev/zvol/storage/bhyve/14.0-CURRENT/a771bf748f9/templatep2 /  
ufs rw  1   1
/dev/zvol/storage/bhyve/14.0-CURRENT/a771bf748f9/templatep3 none   
swapsw  0   0

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Boot time crash - Sleeping thread owns a non-sleepable lock

[Hans Petter Selasky]

On 3/19/21 2:09 AM, David R. Bergstein wrote:
I have been seeing this boot time crash on an intermittent basis on a 
virtual machine; FreeBSD-13.0-RC2.   Below is a copy of the kernel crash 
dump file in case it is helpful to anyone:


--

drb-freebsd-13.localdomain dumped core - see /var/crash/vmcore.4

Thu Mar 18 20:58:47 EDT 2021

FreeBSD drb-freebsd-13.localdomain 13.0-RC2 FreeBSD 13.0-RC2 #0 
releng/13.0-n244684-13c22f74953: Fri Mar 12 04:05:19 UTC 2021 
r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64


panic: sleeping thread

GNU gdb (GDB) 10.1 [GDB v10.1 for FreeBSD]
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd13.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
     .

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...
Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug...

Unread portion of the kernel message buffer:
---<>---
Copyright (c) 1992-2021 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
     The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 13.0-RC2 #0 releng/13.0-n244684-13c22f74953: Fri Mar 12 04:05:19 
UTC 2021

r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
FreeBSD clang version 11.0.1 (g...@github.com:llvm/llvm-project.git 
llvmorg-11.0.1-0-g43ff75f2c3fe)

VT(vga): text 80x25
CPU: Intel(R) Core(TM) i7 CPU 950  @ 3.07GHz (3103.68-MHz 
K8-class CPU)

   Origin="GenuineIntel"  Id=0x106a5  Family=0x6  Model=0x1a Stepping=5
Features=0x1783fbff 


   Features2=0x180201
   AMD Features=0x28100800
   AMD Features2=0x1
   Structured Extended Features3=0x1000
   TSC: P-state invariant
real memory  = 9126805504 (8704 MB)
avail memory = 8285257728 (7901 MB)
Event timer "LAPIC" quality 100
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 1 package(s) x 4 cache groups x 1 core(s)
random: unblocking device.
ioapic0: MADT APIC ID 4 != hw id 0
ioapic0  irqs 0-23
Launching APs: 2 1 3
Timecounter "TSC-low" frequency 1551839460 Hz quality 1000
KTLS: Initialized 4 threads
random: entropy device external interface
[ath_hal] loaded
WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 
14.0.

kbd1 at kbdmux0
000.58 [4350] netmap_init   netmap: loaded module
mlx5en: Mellanox Ethernet driver 3.6.0 (December 2020)
nexus0
vtvga0: 
cryptosoft0: 
aesni0: No AES or SHA support.
acpi0: 
acpi0: Power Button (fixed)
acpi0: Sleep Button (fixed)
cpu0:  on acpi0
attimer0:  port 0x40-0x43,0x50-0x53 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
isab0:  at device 1.0 on pci0
isa0:  on isab0
atapci0:  port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xd000-0xd00f at device 1.1 on pci0

ata0:  at channel 0 on atapci0
ata1:  at channel 1 on atapci0
vgapci0:  mem 0xe000-0xefff irq 18 at 
device 2.0 on pci0

vgapci0: Boot video device
em0:  port 0xd010-0xd017 mem 
0xf000-0xf001 irq 19 at device 3.0 on pci0

em0: Using 1024 TX descriptors and 1024 RX descriptors
<6>em0: Ethernet address: 08:00:27:dd:d4:fc
<6>em0: netmap queues/slots: TX 1/1024, RX 1/1024
pcm0:  port 0xd100-0xd1ff,0xd200-0xd23f irq 21 at 
device 5.0 on pci0

pcm0: 
ohci0:  mem 
0xf0804000-0xf0804fff irq 22 at device 6.0 on pci0

usbus0 on ohci0
usbus0: 12Mbps Full Speed USB v1.0
pci0:  at device 7.0 (no driver attached)
ehci0:  mem 
0xf0805000-0xf0805fff irq 19 at device 11.0 on pci0

usbus1: EHCI version 1.0
usbus1 on ehci0
usbus1: 480Mbps High Speed USB v2.0
acpi_acad0:  on acpi0
atkbdc0:  port 0x60,0x64 irq 1 on acpi0
atkbd0:  irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
psm0:  irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
WARNING: Device "psm" is Giant locked and may be deleted before FreeBSD 
14.0.

psm0: model IntelliMouse Explorer, device ID 4
orm0:  at iomem 0xc-0xc7fff,0xe2000-0xe2fff pnpid 
ORM on isa0
vga0:  at port 0x3c0-0x3df iomem 0xa-0xb pnpid 
PNP0900 on isa0

atrtc0:  at port 0x70 irq 8 on isa0
atrtc0: registered as a time-of-day clock, resolution 1.00s
Event timer "R

[Bug 254395] bsdinstall: fail script install after BETA3

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395

Nathan Whitehorn  changed:

   What|Removed |Added

 CC||nwhiteh...@freebsd.org

--- Comment #1 from Nathan Whitehorn  ---
You should not include the EFI partition in the PARTITIONS variable in general,
but that won't cause this issue. Does the installer actually fail, resulting in
a non-bootable system? Or do you just see this message in the output? Any more
detail about your install script? What are you untarring?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"