Re: ntpd as ntpd user question

[Chris H]

On Mon, 23 Jul 2018 12:57:28 +0200 "Niclas Zeising" 
 said


On 07/21/18 19:56, RW wrote:
> On Sat, 21 Jul 2018 11:14:45 -0600
> Ian Lepore wrote:
> 
> 
>> There's a "pre-world" stage of mergemaster (-Fp option I think) which

>> isn't needed often, but one of the times it is needed is apparently
>> when new user ids are added.
> 
> I wish mergemaster had an option to just add new users and groups,

> rather than merging the files.

etcupdate is usually pretty good at automatically merge updates to files 
without user interaction, even when the files are locally edited as 
well.  For instance, I had no problem merging /etc/master.passwd and 
/etc/group for the ntp change.

Regards
--
Niclas

FWIW I found mergemaster intimidating when I was first starting out. Not
because I didn't understand patch(1)/diff(1). I was well familiar there.
But I found it unintuitive. Despite the messages regarding it's usage.
Anyway. I finally developed a strategy that worked for me.
I start out with the standard

mergemaster -p

then the installworld
But I implement the following mergemster, thusly

mergemaster -vF

It dispenses with asking about all the files that only have revision
changes, and date differences, and just updates them, the -v portion,
just keeps "enlightened" as to wtf is actually happening during the
process.
Then all that's left are just some 5-9 files I need to deal with,
with mergemaster informing me that by default, it'll leave them
for me, to look at later. To which I reply Y. Done.
Knowing diff/patch, makes the resulting unmerged files a trivial
task, requiring perhaps 5-10 minutes while still at the console.
Then I reboot into the new system.

HTH

--Chris



___
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"



___
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 208938] usr.sbin/config does not preserve whitespace in static env

[bugzilla-noreply]

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

Kyle Evans  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|kev...@freebsd.org

-- 
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 208938] usr.sbin/config does not preserve whitespace in static env

[bugzilla-noreply]

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

Kyle Evans  changed:

   What|Removed |Added

  Flags||mfc-stable10-,
   ||mfc-stable11?
 Status|New |In Progress
 CC||kev...@freebsd.org

--- Comment #2 from Kyle Evans  ---
Hi,

Sorry for the radio silence on this. I committed a new version of the env line
sanitizer (written by ian@) in r335642 which also fixed this, and later
revisions to config(8) fixed this same kind of bug in hints.

I'll be MFC'ing the rewrite and all of my other env work (deduplication, fixing
the order of precedence) likely this weekend.

Thanks,

Kyle Evans

-- 
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: EFI issues

[Oleg Lelchuk]

Yes, I also had the same issue until I followed the suggestions given in
this email exchange. Thanks!

On Sun, Jul 29, 2018 at 8:35 AM, O. Hartmann  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Am Sun, 29 Jul 2018 15:17:53 +0400
> Roman Bogorodskiy  schrieb:
>
> >   O. Hartmann wrote:
> >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA512
> > >
> > > Am Sun, 29 Jul 2018 12:09:58 +0400
> > > Roman Bogorodskiy  schrieb:
> > >
> > > >   O. Hartmann wrote:
> > > >
> > > > > -BEGIN PGP SIGNED MESSAGE-
> > > > > Hash: SHA512
> > > > >
> > > > > Am Sat, 28 Jul 2018 11:29:40 +0400
> > > > > Roman Bogorodskiy  schrieb:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I have a test box that's updated to -CURRENT usually once in a
> week or
> > > > > > two. This box boots using UEFI. After a regular update about two
> weeks
> > > > > > ago it started to panic on boot frequently (not UEFI related),
> but I
> > > > > > could not get a crash dump because my swap partition was too
> small. So I
> > > > > > moved data to the backup drive, repartitioned the main drive and
> boot
> > > > > > again. This went fine, so I decided to upgrade to fresh -CURRENT
> from
> > > > > > ~Jul 27th. Booting with the new kernel went fine, but after
> installworld
> > > > > > machine stopped booting, and on the screen I see:
> > > > > >
> > > > > > FreeBSD/amd64 EFI loader, ...
> > > > > >
> > > > > > ..
> > > > > >
> > > > > > BootOrder: 
> > > > > >
> > > > > > And then it gets stuck and nothing happens.
> > > > > >
> > > > > > As I already have a fresh backup, I decided that it'd be easier
> to
> > > > > > just re-install and copy data back over (maybe I messed up with
> > > > > > repartitioning). So I've downloaded a fresh snapshot:
> > > > > >
> > > > > > FreeBSD-12.0-CURRENT-amd64-20180726-r336739-memstick.img
> > > > > >
> > > > > > And re-installed. In the installer I choose all the same
> settings that
> > > > > > were before: UEFI + GPT, default partition scheme it suggested
> (efi
> > > > > > followed by freebsd-ufs followed by freebsd-swap), just
> increased the
> > > > > > swap size.
> > > > > >
> > > > > > And the newly installed system won't boot just like a previous
> one:
> > > > > >
> > > > > > https://people.freebsd.org/~novel/misc/freebsd_efi_lookup.jpg
> > > > > >
> > > > > > Is there a way to recover this?
> > > > > >
> > > > > > Roman Bogorodskiy
> > > > >
> > > > > Just curious:
> > > > >
> > > > > When I installed FreeBSD last time from the recent (2018-07-26)
> USB flash drive
> > > > > on a SSD, the freebsd-swap partition followed immediately after
> the ESP and/or
> > > > > freebsd-boot GPT loader partition. But in most cases I used to use
> ZFS for
> > > > > testing.
> > > >
> > > > When I reinstalled it yesterday from -CURRENT snapshot mentioned
> above,
> > > > in guided mode it suggested a similar partitioning schema that I use:
> > > >
> > > > =>40  1953525088  ada0  GPT  (932G)
> > > >   40  409600 1  efi  (200M)
> > > >   409640  1803550720 2  freebsd-ufs  (860G)
> > > >   1803960360   148897792 3  freebsd-swap  (71G)
> > > >   1952858152  666976- free -  (326M)
> > > >
> > > > The only difference it that the freebsd-swap size was 3.5G (and
> > > > therefore, freebsd-ufs is large), the order was the same.
> > > >
> > > > > Since I had my UEFI adventure of my own these days and received
> valuable hints
> > > > > from the development/maintenance team on some UEFI aspects, it
> would be of
> > > > > interest to know your recent hardware and, more importantly since
> I see the boot
> > > > > order presented in you screenshot, a dump of the efi variable
> settings. Just for
> > > > > curiosity. For that, you have to boot the recent USB flash drive
> image with
> > > > > UEFI-only, then logon as root and perform
> > > > >
> > > > > kldload efirt
> > > > >
> > > > > and then issue
> > > > >
> > > > > # efibootmgr -v
> > > > >
> > > > > In my case, it looks like
> > > > >
> > > > > [...]
> > > > > [ohartmann]: sudo efibootmgr -v
> > > > > BootCurrent: 0001
> > > > > Timeout: 3 seconds
> > > > > BootOrder  : 0001, 0002, 0003, 0004, 0005, 
> > > > > +Boot0001* FreeBSD-12 \
> > > > >HD(1,GPT,e1460941-e2e9-11e5-b913-d0509907ef09,0x28,0x640)/
> File(\efi\boot\BOOTx64.efi)
> > > > > \ ada0p1:/efi/boot/BOOTx64.efi (null)
> > > > >  Boot0002* Hard Drive  BBS(HD,,0x0)
> > > > >  Boot0003* CD/DVD Drive  BBS(CDROM,,0x0)
> > > > >  Boot0004* USB  BBS(USB,,0x0)
> > > > >  Boot0005* Network Card  BBS(Network,,0x0)
> > > > >  Boot  FreeBSD-12
> > > > > HD(1,GPT,e1460941-e2e9-11e5-b913-d0509907ef09,0x28,0x640)/
> File(\efi\boot\BOOTx64.efi)
> > > > > ada0p1:/efi/boot/BOOTx64.efi (null)
> > > > >
> > > > >
> > > > > Unreferenced Variables:
> > > > > [...]
> > > > >
> > > > > Boot is the same as Boot0001 and is defined due to some "bug"
> Warner Losh has
> > > > > fixed recently, it is the same as Boot0001
> > > >
> > > > 

Re: Status of OpenSSL 1.1.1

[Benjamin Kaduk]

On Wed, Aug 01, 2018 at 10:05:28AM -0400, Eric McCorkle wrote:
> On 08/01/2018 09:02, Warner Losh wrote:
> > 
> > 
> > On Wed, Aug 1, 2018, 12:31 PM Eric McCorkle  > > wrote:
> > 
> > Hi folks,
> > 
> > I'm wondering what's the status of OpenSSL 1.1.1 integration into base?
> > More specifically, is there a repo or a branch that's started the
> > integration?  I'm aware of the wiki page and the list of port build
> > issues, but that seems to be based on replacing the base OpenSSL with a
> > port build (similar to the way one replaces it with LibreSSL).
> > 
> > I have some work I'd like to do that's gating on sorting out the
> > kernel/loader crypto situation, and I'd very much like to see OpenSSL
> > 1.1.1 get merged, so I can start to look into doing that.
> > 
> > 
> > There are patches to use bear SSL for the loader. OpenSSL is simply too
> > large to use due to limits the loader operates under.
> 
> I was going to look into the feasibility of doing something like what
> LibreSSL does with portable, where they extract a subset of the full
> library designed to be embedded in the kernel, loader, etc.
> 
> I think it ought to be possible to do something like that, but it really
> ought to be done in a tree with 1.1.1 integrated.
> 

It wouldn't be terribly easy or effective, IMO.  OpenSSL wasn't designed
with such modularity in mind.

-Ben

___
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: acpiconf -s 3 does not call acpi sleep event handlers

[Conrad Meyer]

For those not on the bug, this is being followed up in PR 230290.

On Wed, Aug 1, 2018 at 10:27 PM, Johannes Lundberg  wrote:
>
>
> On Thu, Aug 2, 2018 at 06:20 Andriy Gapon  wrote:
>>
>> On 02/08/2018 01:17, Conrad Meyer wrote:
>> > I don't understand the concern.  There is only one listener to the
>> > event and it just invokes ReqSleepState, which is responsible for
>> > performing all suspend behavior.  The behavior is identical between
>> > lid close and acpiconf.
>>
>> Unless someone is adding a new listener for that event.
>
>
> Exactly my point.
>
>>
>> --
>> Andriy Gapon
___
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: acpiconf -s 3 does not call acpi sleep event handlers

[Ian Lepore]

On Thu, 2018-08-02 at 08:20 +0300, Andriy Gapon wrote:
> On 02/08/2018 01:17, Conrad Meyer wrote:
> > 
> > I don't understand the concern.  There is only one listener to the
> > event and it just invokes ReqSleepState, which is responsible for
> > performing all suspend behavior.  The behavior is identical between
> > lid close and acpiconf.
> Unless someone is adding a new listener for that event.
> 

Or if there is some listener in some proprietary or local module that's
not part of base freebsd. The ability to support modules that didn't
exist at the time the event was added is exactly the main benefit of a
loose-runtime-binding scheme such as event notifications.

-- Ian
___
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: Unable to UEFI boot 11.2 via pxeboot

[Toomas Soome]

> On 2 Aug 2018, at 16:42, Kyle Evans  wrote:
> 
> On Thu, Aug 2, 2018 at 7:45 AM, Toomas Soome  wrote:
>>> On 2 Aug 2018, at 15:32, Toomas Soome  wrote:
>>> 
>>> 
>>> 
 On 2 Aug 2018, at 15:08, Timo Völker >>> > wrote:
 
 It seems this issue is related to current as well. I did a quick test and 
 got this output, while I tried to (pxe)boot FreeBSD current (without a USB 
 stick plugged in)
 
 https://ibb.co/no8Fve 
 
 Best regards
 
 Timo
>>> 
>>> the hint is about efipart_inithandles() returning 2, thats errno code for 
>>> ENOENT. congratz, you have hit the corner case:D
>>> 
>>> Since efinet_dev is part of devsw, we can not skip the devswitch init with 
>>> such error, we still need to walk the list. Let me see if I can provide 
>>> quick fix.
>>> 
>>> rgds,
>>> toomas
>>> 
>> 
>> Could you check the current with 
>> https://svnweb.freebsd.org/changeset/base/337131 
>> 
>> 
>> thanks,
>> toomas
>> 
> 
> Hmm... that's less than great. Is this worth an MFC + 11.2 EN? I'd
> suspect it's not an entirely common case at all, but loader.efi is
> highly visible and actually updated in stable/11 (vs. soon-to-be
> thrown on ESP in head.
> 
> 

Once the fix is confirmed, I think it is worth MFC (I haven't checked 11 
source, however). I just want to be sure the provided patch will provide 
complete fix.

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: Unable to UEFI boot 11.2 via pxeboot

[Kyle Evans]

On Thu, Aug 2, 2018 at 7:45 AM, Toomas Soome  wrote:
>> On 2 Aug 2018, at 15:32, Toomas Soome  wrote:
>>
>>
>>
>>> On 2 Aug 2018, at 15:08, Timo Völker >> > wrote:
>>>
>>> It seems this issue is related to current as well. I did a quick test and 
>>> got this output, while I tried to (pxe)boot FreeBSD current (without a USB 
>>> stick plugged in)
>>>
>>> https://ibb.co/no8Fve 
>>>
>>> Best regards
>>>
>>> Timo
>>
>> the hint is about efipart_inithandles() returning 2, thats errno code for 
>> ENOENT. congratz, you have hit the corner case:D
>>
>> Since efinet_dev is part of devsw, we can not skip the devswitch init with 
>> such error, we still need to walk the list. Let me see if I can provide 
>> quick fix.
>>
>> rgds,
>> toomas
>>
>
> Could you check the current with 
> https://svnweb.freebsd.org/changeset/base/337131 
> 
>
> thanks,
> toomas
>

Hmm... that's less than great. Is this worth an MFC + 11.2 EN? I'd
suspect it's not an entirely common case at all, but loader.efi is
highly visible and actually updated in stable/11 (vs. soon-to-be
thrown on ESP in head.

Thanks,

Kyle Evans
___
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: Unable to UEFI boot 11.2 via pxeboot

[Toomas Soome]

> On 2 Aug 2018, at 15:08, Timo Völker  wrote:
> 
> It seems this issue is related to current as well. I did a quick test and got 
> this output, while I tried to (pxe)boot FreeBSD current (without a USB stick 
> plugged in)
> 
> https://ibb.co/no8Fve
> 
> Best regards
> 
> Timo

the hint is about efipart_inithandles() returning 2, thats errno code for 
ENOENT. congratz, you have hit the corner case:D

Since efinet_dev is part of devsw, we can not skip the devswitch init with such 
error, we still need to walk the list. Let me see if I can provide quick fix.

rgds,
toomas


> 
>> On 31. Jul 2018, at 14:16, Timo Völker  wrote:
>> 
>> Hi,
>> 
>> I'm unable to boot up the amd64 11.2 via pxeboot using UEFI on a Dell 
>> PowerEdge R430. I get this output
>> 
>> https://ibb.co/h5ntuT
>> 
>> If I press a key to interrupt reboot, I get to the OK prompt. If I enter 
>> lsdev -v, it prints nothing more than "net devices:". The variable currdev 
>> is not set (show currdev prints variable 'currdev' not found). I configured 
>> pxeboot to be the one and only boot medium in BIOS setup. 
>> 
>> However, I found a workaround that works for me. If I put an (empty) USB 
>> stick in a USB port of the PowerEdge, it successfully boots via pxeboot 
>> (which is still the one and only configured boot medium). I then get this 
>> output
>> 
>> https://ibb.co/mU8SM8
>> 
>> With FreeBSD 11.1 pxeboot worked on the Dell PowerEdge R430, even without a 
>> USB stick plugged in. I couldn't test this with FreeBSD 12-current. Hope 
>> this helps anyway to find an open issue.
>> 
>> I found this thread which seems to be related.
>> 
>> https://lists.freebsd.org/pipermail/freebsd-current/2018-July/070082.html
>> 
>> Thanks,
>> 
>> Timo
> 

___
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: Unable to UEFI boot 11.2 via pxeboot

[Toomas Soome]

Could you check the current with 
https://svnweb.freebsd.org/changeset/base/337131 


thanks,
toomas

> On 2 Aug 2018, at 15:32, Toomas Soome  wrote:
> 
> 
> 
>> On 2 Aug 2018, at 15:08, Timo Völker > > wrote:
>> 
>> It seems this issue is related to current as well. I did a quick test and 
>> got this output, while I tried to (pxe)boot FreeBSD current (without a USB 
>> stick plugged in)
>> 
>> https://ibb.co/no8Fve 
>> 
>> Best regards
>> 
>> Timo
> 
> the hint is about efipart_inithandles() returning 2, thats errno code for 
> ENOENT. congratz, you have hit the corner case:D
> 
> Since efinet_dev is part of devsw, we can not skip the devswitch init with 
> such error, we still need to walk the list. Let me see if I can provide quick 
> fix.
> 
> rgds,
> toomas
> 
> 
>> 
>>> On 31. Jul 2018, at 14:16, Timo Völker >> > wrote:
>>> 
>>> Hi,
>>> 
>>> I'm unable to boot up the amd64 11.2 via pxeboot using UEFI on a Dell 
>>> PowerEdge R430. I get this output
>>> 
>>> https://ibb.co/h5ntuT 
>>> 
>>> If I press a key to interrupt reboot, I get to the OK prompt. If I enter 
>>> lsdev -v, it prints nothing more than "net devices:". The variable currdev 
>>> is not set (show currdev prints variable 'currdev' not found). I configured 
>>> pxeboot to be the one and only boot medium in BIOS setup. 
>>> 
>>> However, I found a workaround that works for me. If I put an (empty) USB 
>>> stick in a USB port of the PowerEdge, it successfully boots via pxeboot 
>>> (which is still the one and only configured boot medium). I then get this 
>>> output
>>> 
>>> https://ibb.co/mU8SM8
>>> 
>>> With FreeBSD 11.1 pxeboot worked on the Dell PowerEdge R430, even without a 
>>> USB stick plugged in. I couldn't test this with FreeBSD 12-current. Hope 
>>> this helps anyway to find an open issue.
>>> 
>>> I found this thread which seems to be related.
>>> 
>>> https://lists.freebsd.org/pipermail/freebsd-current/2018-July/070082.html
>>> 
>>> Thanks,
>>> 
>>> Timo
>> 
> 

___
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: Unable to UEFI boot 11.2 via pxeboot

[Timo Völker]

It seems this issue is related to current as well. I did a quick test and got 
this output, while I tried to (pxe)boot FreeBSD current (without a USB stick 
plugged in)

https://ibb.co/no8Fve

Best regards

Timo

> On 31. Jul 2018, at 14:16, Timo Völker  wrote:
> 
> Hi,
> 
> I'm unable to boot up the amd64 11.2 via pxeboot using UEFI on a Dell 
> PowerEdge R430. I get this output
> 
> https://ibb.co/h5ntuT
> 
> If I press a key to interrupt reboot, I get to the OK prompt. If I enter 
> lsdev -v, it prints nothing more than "net devices:". The variable currdev is 
> not set (show currdev prints variable 'currdev' not found). I configured 
> pxeboot to be the one and only boot medium in BIOS setup. 
> 
> However, I found a workaround that works for me. If I put an (empty) USB 
> stick in a USB port of the PowerEdge, it successfully boots via pxeboot 
> (which is still the one and only configured boot medium). I then get this 
> output
> 
> https://ibb.co/mU8SM8
> 
> With FreeBSD 11.1 pxeboot worked on the Dell PowerEdge R430, even without a 
> USB stick plugged in. I couldn't test this with FreeBSD 12-current. Hope this 
> helps anyway to find an open issue.
> 
> I found this thread which seems to be related.
> 
> https://lists.freebsd.org/pipermail/freebsd-current/2018-July/070082.html
> 
> Thanks,
> 
> Timo



smime.p7s
Description: S/MIME cryptographic signature