Re: buildworld failed (usr.bin/kyua)

2020-03-28 Thread Ruslan Garipov 
On 3/28/2020 4:29 AM, Brooks Davis wrote:
> On Fri, Mar 27, 2020 at 08:07:08PM +, Brooks Davis wrote:
>> On Fri, Mar 27, 2020 at 06:40:18PM +0500, Ruslan Garipov wrote:
>>> I failed to update FreeBSD 13.0-CURRENT amd64 r359231 to r359351.
>>>
>>> End of the build log:
>>>
>>> $ su root -c "make -j16 buildworld"
>>> ...
>>> ld: error: unable to find library -lkyua_cli_pie
>>> ld: error: unable to find library -lkyua_drivers_pie
>>> ld: error: unable to find library -lkyua_model_pie
>>> ld: error: unable to find library -llutok_pie
>>> ld: error: unable to find library -lkyua_engine_pie
>>> ld: error: unable to find library -llutok_pie
>>> ld: error: unable to find library -lkyua_utils_pie
>>> ld: error: unable to find library -llutok_pie
>>> ld: error: unable to find library -lkyua_store_pie
>>> ld: error: unable to find library -lkyua_model_pie
>>> ld: error: unable to find library -llutok_pie
>>> ld: error: unable to find library -lkyua_utils_pie
>>> ld: error: unable to find library -llutok_pie
>>> ld: error: unable to find library -lkyua_engine_pie
>>> ld: error: unable to find library -llutok_pie
>>> ld: error: unable to find library -lkyua_utils_pie
>>> ld: error: unable to find library -llutok_pie
>>> ld: error: unable to find library -lkyua_model_pie
>>> ld: error: unable to find library -llutok_pie
>>> ld: error: unable to find library -lkyua_store_pie
>>> ld: error: too many errors emitted, stopping now (use -error-limit=0
>>> to see all errors)
>>> c++: error: linker command failed with exit code 1 (use -v to see
>>> invocation)
>>> --- all_subdir_lib ---
>>> --- cpuset_getdomain.po ---
>>> --- all_subdir_usr.bin ---
>>> *** [kyua] Error code 1
>>>
>>> make[4]: stopped in /usr/src/usr.bin/kyua
>>> 1 error
>>>
>>> make[4]: stopped in /usr/src/usr.bin/kyua
>>> *** [all_subdir_usr.bin/kyua] Error code 2
>>> ...
>>>
>>> May be it's related to r359260[1].  Therefore, here is my TEST-settings:
>>>
>>> $ fgrep TEST /etc/src.conf
>>> WITHOUT_GOOGLETEST=
>>> WITHOUT_TESTS=
>>> WITH_TESTS_SUPPORT=
>>>
>>> Also what has confused me: it's a virtual machine which failed to build.
>>> A physical one built userland and kernel just fine.  Both the physical
>>> and virtual machines have almost the same (differ only by CPU
>>> "selection" options) make.conf and src.conf and different kernel
>>> configurations.  Both the machines were FreeBSD 13.0-CURRENT amd64
>>> r359231.  I've started to build on clean systems (no /usr/obj at all).
>>>
>>> Can anyone help me to resolve this issue?
>>
>> I've replicated this issue and it goes back the the way
>> WITH_TESTS_SUPPORT was implemented way back in r273449
>>
>> This patch fixes WITHOUT_TESTS=t WITH_TESTS_SUPPORT=t for me.
>>
>> Index: Makefile.inc1
>> ===
>> --- Makefile.inc1   (revision 359367)
>> +++ Makefile.inc1   (working copy)
>> @@ -1100,7 +1100,7 @@
>>  @echo
>> "--"
>>  ${_+_}cd ${.CURDIR}; \
>>  ${WMAKE} -DNO_FSCHG MK_HTML=no -DNO_LINT MK_MAN=no \
>> -MK_PROFILE=no MK_TESTS=no MK_TESTS_SUPPORT=${MK_TESTS}
>> libraries
>> +MK_PROFILE=no MK_TESTS=no libraries
>>  everything: .PHONY
>>  @echo
>>  @echo
>> "--
>>
>> I've not committed it yet because I'm trying to figure out why this was
>> needed.  I simply don't see how there could be a race between lib/aft and
>> libexec/aft as described.  I suspect this may have been an error.
> 
> I've committed a different fix in r359382.
Thanks a lot!  I'll try it latter.

> 
> The above change fixed the case at hand, but broke the default.
> 
> -- Brooks
> 
___
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: When will the FreeBSD (u)EFI work?

2020-03-28 Thread Clay Daniels 
"*Stop* blockquoting massive amounts of reply text, it is not necessary,
trim it out leaving only the few lines of what you are replying to directly
above your reply."

What good advice. I finally figured out how to do this in gmail:

https://it.stonybrook.edu/help/kb/understanding-whats-included-in-google-mail-replies

Thanks
___
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: When will the FreeBSD (u)EFI work?

2020-03-28 Thread grarpamp 
List users please adhere to email formatting netiquette
and *stop* blockquoting massive amounts of reply text,
it is not necessary, trim it out leaving only the few lines
of what you are replying to directly above your reply.
___
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: When will the FreeBSD (u)EFI work?

2020-03-28 Thread Chris 

On Sat, 28 Mar 2020 11:07:38 +0200 Toomas Soome tso...@me.com said


> On 28. Mar 2020, at 05:28, Chris  wrote:
> 
> On Fri, 27 Mar 2020 18:31:50 -0700 bsd-li...@bsdforge.com

>  said
> 
>> On Fri, 27 Mar 2020 17:27:27 -0600 Warner Losh i...@bsdimp.com said

>> > On Fri, Mar 27, 2020 at 4:54 PM Chris  wrote:
>> > > > On Sat, 28 Mar 2020 01:10:37 +0300 Andrey Fesenko f0and...@gmail.com
> said
>> > >
>> > > > On Sat, Mar 28, 2020 at 12:53 AM Chris 
> wrote:
>> > > > >
>> > > > > On an experiment of the FreeBSD EFI implementation. I installed
>> > > > > a copy of releng/12 from install media. Which left me with:
>> > > > > # gpart show ada0
>> > > > > =>   40  312581728  ada0  GPT  (149G)
>> > > > >  40 409600 1  efi  (200M)
>> > > > >  409640   31047680 2  freebsd-ufs  (15G)
>> > > > >31457320768 3  freebsd-swap  (3.7G)
>> > > > >74788904  237792864- free -  (141G)
>> > > > >
>> > > > > On this Intel based system, I can stab the F12 key to pick
>> > > > > my UEFI bootable OS, or let it boot according to the order
>> > > > > I setup in the BIOS. So far, so good.
>> > > > > I needed a copy of releng/13 to also work with. Installed a copy
>> > > > > from install media. Which left me with:
>> > > > > # gpart show ada0
>> > > > > =>   40  312581728  ada0  GPT  (149G)
>> > > > >  40 409600 1  efi  (200M)
>> > > > >  409640   31047680 2  freebsd-ufs  (15G)
>> > > > >31457320768 3  freebsd-swap  (3.7G)
>> > > > >39137320 532480 4  efi  (260M)
>> > > > >39669800   35119104 5  freebsd-ufs  (17G)
>> > > > >74788904  237792864- free -  (113G)
>> > > > > I *assumed* that the install would activate the new install, and I
>> > > > > would boot straight into it. But no. I am still on the previous
>> > > > > install, and worse, I can't get into the new install -- even if
>> > > > > picking it via stabbing the F12 key. I *still* end up in the
> previous
>> > > > > install. So looking at what might be causing it. I found the
>> > following:
>> > > > > # releng/12
>> > > > > # mount -t msdosfs /dev/ada0p1 /mnt/
>> > > > >
>> > > > > # ls /mnt/efi/boot/
>> > > > > BOOTx64.efi
>> > > > > startup.nsh
>> > > > >
>> > > > > # cat /mnt/efi/boot/startup.nsh
>> > > > > BOOTx64.efi
>> > > > >
>> > > > > # umount /mnt/
>> > > > >
>> > > > > releng/13
>> > > > > # mount -t msdosfs /dev/ada0p4 /mnt/
>> > > > >
>> > > > > # ls /mnt/EFI/freebsd/
>> > > > > loader.efi
>> > > > >
>> > > > > Why the difference? When will FreeBSD (u)EFI work as expected?
>> > > > >
>> > > > > Thanks in advance for any insights!
>> > > > >
>> > > >
>> > > > Require only single efi part
>> > > >
>> > > > See
>> > > >
>> > >
>> >
> https://forums.freebsd.org/threads/two-freebsd-installations-and-efi.73968/
>> > > Thanks for they reply, and link, Andrey!
>> > > Well that confirms it. FreeBSD, unlike other OS implementations, will
> not
>> > > permit booting your chosen "version" via EFI.
>> > > Firstly, *huge* thanks for your informative reply, Warner!
>> > It does today. If you use efibootmgr, you can boot exactly what you want.
> I
>> > do it all the time...  Though your BIOS may overwrite the EFI vars if you
>> > set too many (I'm looking at you supermicro). When you use the efi
> Boot
>> > variables, it's possible to boot one of many different things on the
>> > system...  Though I've not done 11, just 12 and current.
>> Well. That's the thing. I *am* on 12 && 13. Well *trying* to get into 13.
>> When I started this whole thing, I had some 15 entries returned by
>> efibootmgr(8) -v.
>> So I trimmed the list down to the 2 my BIOS presents as UEFI:
>> Boot0015  UEFI: WDC WD1600JS-98MHB0
>> PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x0,0x,0x0)/HD(4,GPT,6688c5af-6f93...
>> Boot0011* UEFI: WDC WD1600JS-98MHB0
>> PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x0,0x,0x0)/HD(1,GPT,260d2df2-6a10...
>> another entry created when I installed releng/13:
>> Boot0014  FreeBSD (ada0p4)
>>
> 
HD(4,GPT,6688c5af-6f93-11ea-adbb-4c72b9f5e07f,0x2553028,0x82000)/File(\EFI\free...
>> and a Windows reference (currently not installed).
>> I activated *both* Boot0015 and Boot0011:
>> efibootmgr -a 0015 0011. Output confirmed success. Bounced box, choose
>> Boot0015. Which booted
>> initial releng/12 install. Fail. OK Try something different;
>> efibootmgr -a 0014 -L FreeBSD-13. Output confirms the -L switch is broken,
>> but 00114 is active.
>> Bounce box && choose 0014. Boots to initial releng/12 install.
>> Conclusion; FreeBSD EFI/ESP is not ready for prime time. :(
>> Thanks again for the reply, Warner! :)
>> --Chris



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 defined as having /boot/loader.efi.

Yes, I understand how this is currently implemented. :)


Therefore, you may have 2 or more freebsd instances on the disk, it re

Bridge project update (Week of March 23rd)

2020-03-28 Thread Kristof Provost 

Hi,

This week I got a prototype patch running, along the ideas discussed 
last week. Essentially, we keep the BRIDGE_LOCK for any add/delete of 
interfaces or rt entries, but use CK_LIST and epoch in the data path.
This is a relatively straightforward change, and currently passes the 
regression tests (WITNESS/INVARIANTS enabled). I’ve also run traffic 
through it without issue.
My current test setup fails to generate sufficient packets to truly 
stress the code. I’m hoping to get access to a more suitable setup 
next week so I can usefully measure the improvement.


The prototype patch is also running on my home gateway right now. So far 
so good!
Assuming no major issues come up in the next week or two I hope to post 
the patch for initial review in the near future.


Best regards,
Kristof
___
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: kernel build failed

2020-03-28 Thread 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/src/amd64.amd64/sys/GENERIC-NODEBUG/modules/usr/src/sys/modules/aesni...]
>>> ...
>>> /usr/src/sys/crypto/aesni/aesni_ghash.c:75:10: fatal error: 'wmmintrin.h'
>>> file not found
>>> #include 
>>>  ^
>>> 1 error generated.
>>> *** Error code 1
>>> 
>> I had no issues updating from r359325 to r359356 yesterday, or from
>> r359356 to r359389 today (using META_MODE).
> 
> So what may be a reason? I tried:
> - remove and checkout source tree
> - remove /usr/obj
> 
> wmmintrin.h is present under 
> /usr/src/contrib/llvm-project/clang/lib/Headers/wmmintrin.h
> 
> /etc/make.conf:
> KERNCONF=GENERIC-NODEBUG
> MALLOC_PRODUCTION=yes
> 
> no /etc/src.conf

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, for some reason. (Usually people
seem to do a WITHOUT_CLANG installation or strip out 'unnecessary'
stuff manually...)

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: TLS certificates for NFS-over-TLS floating client

2020-03-28 Thread Rick Macklem 
John-Mark Gurney wrote:
>Rick Macklem wrote this message on Thu, Mar 26, 2020 at 14:33 +:
>> John-Mark Gurney wrote:
>> [lots of stuff snipped]
>> >Rick Macklem wrote:
>> >> I had originally planned on some "secret" in the certificate (like a CN 
>> >> name
>> >> that satisfies some regular expression or ???) but others convinced me 
>> >> that
>> >> that wouldn't provide anything beyond knowing that the certificate was
>> >> signed by the appropriate CA, so I have not implemented anything.
>> >
>> >Yeah, having a "secret" in the CN doesn't make sense, but what does make
>> >sense is allowing the exports line to specify what the CN should contain
>> >to be authenticated...
>> >
>> >Say as a corp, you issue personal certificates to everyone.  This is
>> >because you require everyone to sign and/or encrypt their email w/
>> >S/MIME.  Each cert includes the email address of that person, so you
>> >could simply do something like:
>> >/home/alice -tlscert -tlsroot /etc/company.pem -email al...@example.com
>> >
>> >And anyone who has the certificate w/ al...@example.com that was signed
>> >by the public key in /etc/company.pem would be granted access to the
>> >export /home/alice.
>> >
>> >If it allowed ANY cert signed by the CA specified, then that introduces
>> >an authentication problem, as now if Malory is a coworker of Alice
>> >could also access Alice's home directory...
>> >
>> >IMO, this is one auth feature that MUST be supported...
Here's what I have just coded up:
- If an option is set for the server TLS handshake daemon and it gets a verified
  certificate from the client
  - It looks at the CN and if it is of the form "user@domain", it tries to 
translate
"user@domain" to a POSIX  using the same mechanism that
nfsuserd(8) currently uses. ("user@domain" is what NFSv4 uses for a file 
Owner.)
- Then all RPCs on this TCP connection are done using the  
above,
   ignoring the authenticator in the RPC message header. (Yes, similar to 
the
   -mapall exports option.)
I have also added a "-tlscnuser" exports option that would require all clients
to have the above form of certificate. (Without this exports option, the above
would work assuming the daemon option is set, but other mounts would be
allowed as well.)

The problem of handling multiple "user" domains has never been solved.
(That is what your -tlsroot option was intended to do assuming a 1 to 1
 relationship between CA root and username domains, I think?)
The problem is that getpwnam(3) needs to know how to look up user names
for these different "domain" values. (Now, both nfsused(8) and this daemon
only strips off the default domain, if it matches, and then hands the rest of
the string to getpwnam(2).)

Although "user@domain" isn't exactly an email address, they often are the
same string in practice.

I have not yet posted to nf...@ietf.org to see what they think.
However, I don't think there is any changes in the draft required to do this.
Also, I think interoperability should be ok, since it is controlled by whoever
issues the certificate for the client and the NFS client will normally just
handle this certificate opaquely.

Btw, the server TLS handshake daemon does do a SSL_CTX_set_client_CA_list(),
so it tells the client which CA (usually only one) that it wants a certificate 
for.

>> The draft does not address user authentication, only machine authentication.
>> --> ie. The certificate is used to decide if a system can do a mount.
>>   Users are still identified via user credentials in the RPC message 
>> header.
>>   For AUTH_SYS, that still means .
>>   Otherwise, you need to use Kerberos (sec=krb5[ip]).
>>   You could use "tls,sec=krb5" for a mount, but the only advantage that
>>   might have over "sec=krb5p" is performance, if there is hardware assist
>>   for TLS or something like that.
>>
>> >Now that I reread your comments, it sounds like any certificate would be
>> >allowed in #2 as long as it is valid, and that would only be marginally
>> >better than verification by IP, and in some ways worse, in that now any
>> >user could pretend to be any other user, or you have to do something
>> >crazy like have a CA per user.
>> The case where I see #2 is useful is where this discussion started some 
>> weeks ago.
>> The example I started with was:
>> /home -tls -network 192.168.1.0 -mask 255.255.255.0
>> /home -tlscert
>>
>> This says that machines on the local lan can mount and do not need to have
>> certificates, but must use TLS so data is encrypted on the wire.
>> Mounts from anywhere else (presumably laptops) are allowed so long as they 
>> have a
>> certificate signed by me (as in the site local CA).
>> I trust these machines enough that I am willing to allow them to use 
>> AUTH_SYS,
>> which is what 99.9...% of NFS mounts do now.
>> (So, I'd agree that the site local certificate is not a lot better than IP 
>> address
>>  for client machine identity, just that it is an alternative that c

Re: ZFS: destroying snapshots without compromising boot environments

2020-03-28 Thread Graham Perrin 

On 28/03/2020 15:19, Allan Jude wrote:

> You can try to destroy the snapshot, if it is the basis of a clone, then
> you will get an error, that you'd need to destroy the BE first, so you
> might decide to keep that snapshot. As long as you don't use the -R flag
> to zfs destroy dataset@snapshot, it will not destroy the clones.
>
> You can also use 'zfs promote' to make the clone into the parent, making
> the original parent into the clone. This allows you to destroy that
> original and the snapshot while keeping the clone.

Perfect, thank you. I was nervous about destruction without warning.

Below, are the differences (in measurement) between beadm and bectl to 
be expected?




root@momh167-gjp4-8570p:~ # beadm list
BE   Active Mountpoint  Space Created
Waterfox -  -   15.9G 2020-03-10 18:24
r357746f -  -    1.3G 2020-03-20 06:19
r359249b NR /   74.7G 2020-03-28 01:19
root@momh167-gjp4-8570p:~ # beadm list -aDs
BE/Dataset/Snapshot    Active Mountpoint Space 
Created


Waterfox
  copperbowl/ROOT/Waterfox -  - 137.0M 
2020-03-10 18:24
    r359249b@2020-03-17-21:57:17   -  - 59.2G 
2020-03-17 21:57
  copperbowl/ROOT/Waterfox@2020-03-20-06:19:45 -  - 67.0M 
2020-03-20 06:19


r357746f
  copperbowl/ROOT/r357746f -  - 1.2G 2020-03-20 
06:19
    Waterfox@2020-03-20-06:19:45   -  - 59.2G 
2020-03-20 06:19


r359249b
  copperbowl/ROOT/r359249b@2020-03-17-21:57:17 -  - 15.7G 
2020-03-17 21:57
  copperbowl/ROOT/r359249b NR / 59.0G 
2020-03-28 01:19

root@momh167-gjp4-8570p:~ # bectl list
BE   Active Mountpoint Space Created
Waterfox -  -  204M  2020-03-10 18:24
r357746f -  -  1.21G 2020-03-20 06:19
r359249b NR /  74.7G 2020-03-28 01:19
root@momh167-gjp4-8570p:~ # bectl list -aDs
BE/Dataset/Snapshot  Active Mountpoint Space 
Created


Waterfox
  copperbowl/ROOT/Waterfox   -  - 204M  
2020-03-10 18:24
  Waterfox@2020-03-20-06:19:45   -  - 67.0M 
2020-03-20 06:19


r357746f
  copperbowl/ROOT/r357746f   -  - 1.21G 
2020-03-20 06:19


r359249b
  copperbowl/ROOT/r359249b   NR / 74.7G 
2020-03-28 01:19
  r359249b@2020-03-17-21:57:17   -  - 15.7G 
2020-03-17 21:57

root@momh167-gjp4-8570p:~ # zfs list -t snapshot
NAME USED AVAIL  
REFER  MOUNTPOINT

copperbowl/ROOT/Waterfox@2020-03-20-06:19:45    67.0M -  59.2G  -
copperbowl/ROOT/r359249b@2020-03-17-21:57:17    15.7G -  59.2G  -
copperbowl/iocage/releases/12.0-RELEASE/root@jbrowsers 8K -  1.24G  -
copperbowl/poudriere/jails/head@clean    328K -  1.89G  -
root@momh167-gjp4-8570p:~ # zfs destroy 
copperbowl/ROOT/r359249b@2020-03-17-21:57:17
cannot destroy 'copperbowl/ROOT/r359249b@2020-03-17-21:57:17': snapshot 
has dependent clones

use '-R' to destroy the following datasets:
copperbowl/ROOT/r357746f
copperbowl/ROOT/Waterfox@2020-03-20-06:19:45
copperbowl/ROOT/Waterfox
root@momh167-gjp4-8570p:~ # date ; uname -v
Sat Mar 28 15:30:57 GMT 2020
FreeBSD 13.0-CURRENT #1 r359249: Tue Mar 24 00:12:27 GMT 2020 
root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG

root@momh167-gjp4-8570p:~ #

___
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: OpenZFS: sysctl: unknown oid 'vfs.zfs.arc_max'

2020-03-28 Thread Allan Jude 
On 2020-03-28 02:43, Graham Perrin wrote:
> This occurs when I enable OpenZFS:
> 
> OpenZFS: sysctl: unknown oid 'vfs.zfs.arc_max'
> 
> Is it to be deprecated? Or is it not yet a feature of OpenZFS for FreeBSD?
> 
> From :
> 
> grahamperrin@momh167-gjp4-8570p:~ % sysctl vfs.zfs.arc_max
> sysctl: unknown oid 'vfs.zfs.arc_max'
> grahamperrin@momh167-gjp4-8570p:~ % date ; uname -v
> Wed 25 Mar 2020 04:52:22 GMT
> FreeBSD 13.0-CURRENT #1 r359249: Tue Mar 24 00:12:27 GMT 2020
> root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG
> grahamperrin@momh167-gjp4-8570p:~ % kldstat | grep zfs
>  2    1 0x82108000   58ac58 openzfs.ko
> grahamperrin@momh167-gjp4-8570p:~ % grep zfs /boot/loader.conf
> # zfs_load="YES"
> openzfs_load="YES"
> grahamperrin@momh167-gjp4-8570p:~ % grep zfs /etc/sysctl.conf
> vfs.zfs.min_auto_ashift=12
> # HP EliteBook 8570p 16 GB memory vfs.zfs.arc_max defaults to 15523106816
> # vfs.zfs.arc_max="7761553408"
> vfs.zfs.arc_max="2147483648"
> grahamperrin@momh167-gjp4-8570p:~ % zfs-stats -a
> 
> …
> ___
> 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"

The OpenZFS, the variable is vfs.zfs.arc.max

Basically 'arc' was converted to a subtree.

We should add some backwards compat sysctls to cover some of these
renames etc so configs and scripts don't break etc.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: ZFS: destroying snapshots without compromising boot environments

2020-03-28 Thread Allan Jude 
On 2020-03-28 03:24, Graham Perrin wrote:
> I imagine that some of the 2019 snapshots below are redundant.
> 
> Can I safely destroy any of them?
> 
> $ zfs list -t snapshot
> NAME USED AVAIL 
> REFER  MOUNTPOINT
> copperbowl/ROOT/Waterfox@2020-03-20-06:19:45    67.0M -  59.2G  -
> copperbowl/ROOT/r359249b@2019-08-18-04:04:53    5.82G -  40.9G  -
> copperbowl/ROOT/r359249b@2019-08-18-11:28:31    4.32G -  40.7G  -
> copperbowl/ROOT/r359249b@2019-09-13-18:45:27-0  9.43G -  43.4G  -
> copperbowl/ROOT/r359249b@2019-09-19-20:03:26    5.13G -  43.3G  -
> copperbowl/ROOT/r359249b@2019-09-24-20:45:59-0  7.67G -  44.6G  -
> copperbowl/ROOT/r359249b@2020-01-09-17:05:57-0  7.66G -  55.2G  -
> copperbowl/ROOT/r359249b@2020-01-11-14:15:47    7.41G -  56.2G  -
> copperbowl/ROOT/r359249b@2020-03-17-21:57:17    12.0G -  59.2G  -
> copperbowl/iocage/releases/12.0-RELEASE/root@jbrowsers 8K -  1.24G  -
> copperbowl/poudriere/jails/head@clean    328K -  1.89G  -
> $ beadm list
> BE   Active Mountpoint  Space Created
> Waterfox -  -   12.2G 2020-03-10 18:24
> r357746f -  -    1.3G 2020-03-20 06:19
> r359249b NR /  148.9G 2020-03-28 01:19
> $ beadm list -aDs
> BE/Dataset/Snapshot  Active Mountpoint 
> Space Created
> 
> Waterfox
>   copperbowl/ROOT/Waterfox   -  - 137.0M
> 2020-03-10 18:24
>     r359249b@2020-03-17-21:57:17 - -   59.2G
> 2020-03-17 21:57
>   copperbowl/ROOT/Waterfox@2020-03-20-06:19:45   - -   67.0M
> 2020-03-20 06:19
> 
> r357746f
>   copperbowl/ROOT/r357746f   - -    1.2G
> 2020-03-20 06:19
>     Waterfox@2020-03-20-06:19:45 - -   59.2G
> 2020-03-20 06:19
> 
> r359249b
>   copperbowl/ROOT/r359249b@2019-08-18-04:04:53   - -    5.8G
> 2019-08-18 04:04
>   copperbowl/ROOT/r359249b@2019-08-18-11:28:31   - -    4.3G
> 2019-08-18 11:28
>   copperbowl/ROOT/r359249b@2019-09-13-18:45:27-0 - -    9.4G
> 2019-09-13 18:45
>   copperbowl/ROOT/r359249b@2019-09-19-20:03:26   - -    5.1G
> 2019-09-19 20:03
>   copperbowl/ROOT/r359249b@2019-09-24-20:45:59-0 - -    7.7G
> 2019-09-24 20:45
>   copperbowl/ROOT/r359249b@2020-01-09-17:05:57-0 - -    7.7G
> 2020-01-09 17:05
>   copperbowl/ROOT/r359249b@2020-01-11-14:15:47   - -    7.4G
> 2020-01-11 14:15
>   copperbowl/ROOT/r359249b@2020-03-17-21:57:17   - -   12.0G
> 2020-03-17 21:57
>   copperbowl/ROOT/r359249b   NR /   59.0G
> 2020-03-28 01:19
> $
> 
> ___
> 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"


You can try to destroy the snapshot, if it is the basis of a clone, then
you will get an error, that you'd need to destroy the BE first, so you
might decide to keep that snapshot. As long as you don't use the -R flag
to zfs destroy dataset@snapshot, it will not destroy the clones.

You can also use 'zfs promote' to make the clone into the parent, making
the original parent into the clone. This allows you to destroy that
original and the snapshot while keeping the clone.


-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: kernel build failed

2020-03-28 Thread Alexandr Krivulya 

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/src/amd64.amd64/sys/GENERIC-NODEBUG/modules/usr/src/sys/modules/aesni...]
...
/usr/src/sys/crypto/aesni/aesni_ghash.c:75:10: fatal error: 'wmmintrin.h'
file not found
#include 
  ^
1 error generated.
*** Error code 1


I had no issues updating from r359325 to r359356 yesterday, or from
r359356 to r359389 today (using META_MODE).


So what may be a reason? I tried:
- remove and checkout source tree
- remove /usr/obj

wmmintrin.h is present under 
/usr/src/contrib/llvm-project/clang/lib/Headers/wmmintrin.h


/etc/make.conf:
KERNCONF=GENERIC-NODEBUG
MALLOC_PRODUCTION=yes

no /etc/src.conf
___
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: USB microphones with FreeBSD-CURRENT

2020-03-28 Thread Jan Beich 
Graham Perrin  writes:

> I can't get web browsers to recognise USB microphones.
>
> USB output (e.g. to my headphones) is OK.
>
> USB input (e.g. from the microphone part of the headphones) is not.
>
> Any suggestions?

Firefox uses "pulse-rust" cubeb backend *by default* if "pulseaudio"
package is installed. getUserMedia is supposed to preset a dropdown menu
to select a microphone. Make sure pulseaudio actually recognizes the
desired microphone e.g., debug via "pactl list" and "parec".

I don't have a mic but, looking at the code, only pulse-rust or pulse
backends on Linux/FreeBSD support selecting non-default audio device.
It maybe possible to use other backends but if audio device used for
output and input are different that'd require routing defaults which can
be done via config file (e.g., ~/.asoundrc) or externally via virtual_oss.

> pcm3:  (play/rec) default
> pcm4:  (rec)

Are these distinct physical devices?

> hw.snd.default_unit: 3

Have you tried using 4?
___
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: kernel build failed

2020-03-28 Thread 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/src/amd64.amd64/sys/GENERIC-NODEBUG/modules/usr/src/sys/modules/aesni...]
> ...
> /usr/src/sys/crypto/aesni/aesni_ghash.c:75:10: fatal error: 'wmmintrin.h'
> file not found
> #include 
>  ^
> 1 error generated.
> *** Error code 1
> 

I had no issues updating from r359325 to r359356 yesterday, or from
r359356 to r359389 today (using META_MODE).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
It's disingenuous to claim a low rate of infection based on test results
if the tests are not done.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

kernel build failed

2020-03-28 Thread Alexandr Krivulya 

Hello,
on latest CURRENT kernel fails to build:

===> aesni (all)
[Creating objdir 
/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/modules/usr/src/sys/modules/aesni...]

machine -> /usr/src/sys/amd64/include
x86 -> /usr/src/sys/x86/include
awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h
awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h
ln -sf /usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/opt_bus.h opt_bus.h
awk -f /usr/src/sys/tools/makeobjops.awk 
/usr/src/sys/opencrypto/cryptodev_if.m -h
cc -target x86_64-unknown-freebsd13.0 
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -c -O2 -pipe 
-fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -DKLD_TIED -nostdinc 
-DHAVE_KERNEL_OPTION_HEADERS -include 
/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/opt_global.h -I. 
-I/usr/src/sys -I/usr/src/sys/contrib/ck/include -g 
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 
-fdebug-prefix-map=./machine=/usr/src/sys/amd64/include 
-fdebug-prefix-map=./x86=/usr/src/sys/x86/include 
-I/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG -MD 
-MF.depend.genoffset.o -MTgenoffset.o -mcmodel=kernel -mno-red-zone 
-mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables 
-ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef 
-Wno-pointer-sign -D__printf__=__freebsd_kprintf__ 
-Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas 
-Wno-error-tautological-compare -Wno-error-empty-body 
-Wno-error-parentheses-equality -Wno-error-unused-function 
-Wno-error-pointer-sign -Wno-error-shift-negative-value 
-Wno-address-of-packed-member -Wno-format-zero-length -mno-aes -mno-avx 
-std=iso9899:1999  /usr/src/sys/kern/genoffset.c

sh /usr/src/sys/kern/genoffset.sh genoffset.o > offset.inc
cc -target x86_64-unknown-freebsd13.0 
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -c -O3 -pipe 
-fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -DKLD_TIED 
-DHAVE_KERNEL_OPTION_HEADERS -include 
/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/opt_global.h -I. 
-I/usr/src/sys -I/usr/src/sys/contrib/ck/include -fno-common -g 
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 
-fdebug-prefix-map=./machine=/usr/src/sys/amd64/include 
-fdebug-prefix-map=./x86=/usr/src/sys/x86/include 
-I/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG -MD 
-MF.depend.aesni_ghash.o -MTaesni_ghash.o -mcmodel=kernel -mno-red-zone 
-mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables 
-ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef 
-Wno-pointer-sign -D__printf__=__freebsd_kprintf__ 
-Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas 
-Wno-error-tautological-compare -Wno-error-empty-body 
-Wno-error-parentheses-equality -Wno-error-unused-function 
-Wno-error-pointer-sign -Wno-error-shift-negative-value 
-Wno-address-of-packed-member -Wno-format-zero-length 
-Wno-error-cast-qual -mno-aes -mno-avx -std=iso9899:1999 -Werror -mmmx 
-msse -msse4 -maes -mpclmul /usr/src/sys/crypto/aesni/aesni_ghash.c
/usr/src/sys/crypto/aesni/aesni_ghash.c:75:10: fatal error: 
'wmmintrin.h' file not found

#include 
 ^
1 error generated.
*** Error code 1

Stop.
make[4]: stopped in /usr/src/sys/modules/aesni
*** Error code 1

Stop.
make[3]: stopped in /usr/src/sys/modules
*** Error code 1

Stop.
make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src
___
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: When will the FreeBSD (u)EFI work?

2020-03-28 Thread Andrey Fesenko 
On Sat, Mar 28, 2020 at 12:14 PM Toomas Soome  wrote:
>
>
>
> > On 28. Mar 2020, at 05:28, Chris  wrote:
> >
> > On Fri, 27 Mar 2020 18:31:50 -0700 bsd-li...@bsdforge.com 
> >  said
> >
> >> On Fri, 27 Mar 2020 17:27:27 -0600 Warner Losh i...@bsdimp.com said
> >> > On Fri, Mar 27, 2020 at 4:54 PM Chris  wrote:
> >> > > > On Sat, 28 Mar 2020 01:10:37 +0300 Andrey Fesenko f0and...@gmail.com 
> >> > > > said
> >> > >
> >> > > > On Sat, Mar 28, 2020 at 12:53 AM Chris  
> >> > > > wrote:
> >> > > > >
> >> > > > > On an experiment of the FreeBSD EFI implementation. I installed
> >> > > > > a copy of releng/12 from install media. Which left me with:
> >> > > > > # gpart show ada0
> >> > > > > =>   40  312581728  ada0  GPT  (149G)
> >> > > > >  40 409600 1  efi  (200M)
> >> > > > >  409640   31047680 2  freebsd-ufs  (15G)
> >> > > > >31457320768 3  freebsd-swap  (3.7G)
> >> > > > >74788904  237792864- free -  (141G)
> >> > > > >
> >> > > > > On this Intel based system, I can stab the F12 key to pick
> >> > > > > my UEFI bootable OS, or let it boot according to the order
> >> > > > > I setup in the BIOS. So far, so good.
> >> > > > > I needed a copy of releng/13 to also work with. Installed a copy
> >> > > > > from install media. Which left me with:
> >> > > > > # gpart show ada0
> >> > > > > =>   40  312581728  ada0  GPT  (149G)
> >> > > > >  40 409600 1  efi  (200M)
> >> > > > >  409640   31047680 2  freebsd-ufs  (15G)
> >> > > > >31457320768 3  freebsd-swap  (3.7G)
> >> > > > >39137320 532480 4  efi  (260M)
> >> > > > >39669800   35119104 5  freebsd-ufs  (17G)
> >> > > > >74788904  237792864- free -  (113G)
> >> > > > > I *assumed* that the install would activate the new install, and I
> >> > > > > would boot straight into it. But no. I am still on the previous
> >> > > > > install, and worse, I can't get into the new install -- even if
> >> > > > > picking it via stabbing the F12 key. I *still* end up in the 
> >> > > > > previous
> >> > > > > install. So looking at what might be causing it. I found the
> >> > following:
> >> > > > > # releng/12
> >> > > > > # mount -t msdosfs /dev/ada0p1 /mnt/
> >> > > > >
> >> > > > > # ls /mnt/efi/boot/
> >> > > > > BOOTx64.efi
> >> > > > > startup.nsh
> >> > > > >
> >> > > > > # cat /mnt/efi/boot/startup.nsh
> >> > > > > BOOTx64.efi
> >> > > > >
> >> > > > > # umount /mnt/
> >> > > > >
> >> > > > > releng/13
> >> > > > > # mount -t msdosfs /dev/ada0p4 /mnt/
> >> > > > >
> >> > > > > # ls /mnt/EFI/freebsd/
> >> > > > > loader.efi
> >> > > > >
> >> > > > > Why the difference? When will FreeBSD (u)EFI work as expected?
> >> > > > >
> >> > > > > Thanks in advance for any insights!
> >> > > > >
> >> > > >
> >> > > > Require only single efi part
> >> > > >
> >> > > > See
> >> > > >
> >> > >
> >> > https://forums.freebsd.org/threads/two-freebsd-installations-and-efi.73968/
> >> > > Thanks for they reply, and link, Andrey!
> >> > > Well that confirms it. FreeBSD, unlike other OS implementations, will 
> >> > > not
> >> > > permit booting your chosen "version" via EFI.
> >> > > Firstly, *huge* thanks for your informative reply, Warner!
> >> > It does today. If you use efibootmgr, you can boot exactly what you 
> >> > want. I
> >> > do it all the time...  Though your BIOS may overwrite the EFI vars if you
> >> > set too many (I'm looking at you supermicro). When you use the efi 
> >> > Boot
> >> > variables, it's possible to boot one of many different things on the
> >> > system...  Though I've not done 11, just 12 and current.
> >> Well. That's the thing. I *am* on 12 && 13. Well *trying* to get into 13.
> >> When I started this whole thing, I had some 15 entries returned by
> >> efibootmgr(8) -v.
> >> So I trimmed the list down to the 2 my BIOS presents as UEFI:
> >> Boot0015  UEFI: WDC WD1600JS-98MHB0
> >> PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x0,0x,0x0)/HD(4,GPT,6688c5af-6f93...
> >> Boot0011* UEFI: WDC WD1600JS-98MHB0
> >> PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x0,0x,0x0)/HD(1,GPT,260d2df2-6a10...
> >> another entry created when I installed releng/13:
> >> Boot0014  FreeBSD (ada0p4)
> >> HD(4,GPT,6688c5af-6f93-11ea-adbb-4c72b9f5e07f,0x2553028,0x82000)/File(\EFI\free...
> >> and a Windows reference (currently not installed).
> >> I activated *both* Boot0015 and Boot0011:
> >> efibootmgr -a 0015 0011. Output confirmed success. Bounced box, choose
> >> Boot0015. Which booted
> >> initial releng/12 install. Fail. OK Try something different;
> >> efibootmgr -a 0014 -L FreeBSD-13. Output confirms the -L switch is broken,
> >> but 00114 is active.
> >> Bounce box && choose 0014. Boots to initial releng/12 install.
> >> Conclusion; FreeBSD EFI/ESP is not ready for prime time. :(
> >> Thanks again for the reply, Warner! :)
> >> --Chris
>
>
> How loader is working is that it does search for *first* “usable” freebsd 
> partition

Re: OpenZFS: sysctl: unknown oid 'vfs.zfs.arc_max'

2020-03-28 Thread Rodney W. Grimes 
> This occurs when I enable OpenZFS:
> 
> OpenZFS: sysctl: unknown oid 'vfs.zfs.arc_max'
> 
> Is it to be deprecated? Or is it not yet a feature of OpenZFS for FreeBSD?
> 
>  From :
> 
> grahamperrin@momh167-gjp4-8570p:~ % sysctl vfs.zfs.arc_max
> sysctl: unknown oid 'vfs.zfs.arc_max'
> grahamperrin@momh167-gjp4-8570p:~ % date ; uname -v
> Wed 25 Mar 2020 04:52:22 GMT
> FreeBSD 13.0-CURRENT #1 r359249: Tue Mar 24 00:12:27 GMT 2020 
> root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG
> grahamperrin@momh167-gjp4-8570p:~ % kldstat | grep zfs
>  ?2??? 1 0x82108000?? 58ac58 openzfs.ko
> grahamperrin@momh167-gjp4-8570p:~ % grep zfs /boot/loader.conf
> # zfs_load="YES"
> openzfs_load="YES"
> grahamperrin@momh167-gjp4-8570p:~ % grep zfs /etc/sysctl.conf
> vfs.zfs.min_auto_ashift=12
> # HP EliteBook 8570p 16 GB memory vfs.zfs.arc_max defaults to 15523106816
> # vfs.zfs.arc_max="7761553408"
> vfs.zfs.arc_max="2147483648"
> grahamperrin@momh167-gjp4-8570p:~ % zfs-stats -a

Is zfs actually loaded?

kldstat | grep zfs


Does perhaps openZfs use a seperate tree?
sysctl -a | grep arc_max

-- 
Rod Grimes rgri...@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"

Re: ZFS: destroying snapshots without compromising boot environments

2020-03-28 Thread Andrey Fesenko 
On Sat, Mar 28, 2020 at 10:30 AM Graham Perrin  wrote:
>
> I imagine that some of the 2019 snapshots below are redundant.
>
> Can I safely destroy any of them?
>
> $ zfs list -t snapshot
> NAME USED AVAIL
> REFER  MOUNTPOINT
> copperbowl/ROOT/Waterfox@2020-03-20-06:19:4567.0M -  59.2G  -
> copperbowl/ROOT/r359249b@2019-08-18-04:04:535.82G -  40.9G  -
> copperbowl/ROOT/r359249b@2019-08-18-11:28:314.32G -  40.7G  -
> copperbowl/ROOT/r359249b@2019-09-13-18:45:27-0  9.43G -  43.4G  -
> copperbowl/ROOT/r359249b@2019-09-19-20:03:265.13G -  43.3G  -
> copperbowl/ROOT/r359249b@2019-09-24-20:45:59-0  7.67G -  44.6G  -
> copperbowl/ROOT/r359249b@2020-01-09-17:05:57-0  7.66G -  55.2G  -
> copperbowl/ROOT/r359249b@2020-01-11-14:15:477.41G -  56.2G  -
> copperbowl/ROOT/r359249b@2020-03-17-21:57:1712.0G -  59.2G  -
> copperbowl/iocage/releases/12.0-RELEASE/root@jbrowsers 8K -  1.24G  -
> copperbowl/poudriere/jails/head@clean328K -  1.89G  -
> $ beadm list
> BE   Active Mountpoint  Space Created
> Waterfox -  -   12.2G 2020-03-10 18:24
> r357746f -  -1.3G 2020-03-20 06:19
> r359249b NR /  148.9G 2020-03-28 01:19
> $ beadm list -aDs
> BE/Dataset/Snapshot  Active Mountpoint
> Space Created
>
> Waterfox
>copperbowl/ROOT/Waterfox   -  - 137.0M
> 2020-03-10 18:24
>  r359249b@2020-03-17-21:57:17 - -   59.2G
> 2020-03-17 21:57
>copperbowl/ROOT/Waterfox@2020-03-20-06:19:45   - -   67.0M
> 2020-03-20 06:19
>
> r357746f
>copperbowl/ROOT/r357746f   - -1.2G
> 2020-03-20 06:19
>  Waterfox@2020-03-20-06:19:45 - -   59.2G
> 2020-03-20 06:19
>
> r359249b
>copperbowl/ROOT/r359249b@2019-08-18-04:04:53   - -5.8G
> 2019-08-18 04:04
>copperbowl/ROOT/r359249b@2019-08-18-11:28:31   - -4.3G
> 2019-08-18 11:28
>copperbowl/ROOT/r359249b@2019-09-13-18:45:27-0 - -9.4G
> 2019-09-13 18:45
>copperbowl/ROOT/r359249b@2019-09-19-20:03:26   - -5.1G
> 2019-09-19 20:03
>copperbowl/ROOT/r359249b@2019-09-24-20:45:59-0 - -7.7G
> 2019-09-24 20:45
>copperbowl/ROOT/r359249b@2020-01-09-17:05:57-0 - -7.7G
> 2020-01-09 17:05
>copperbowl/ROOT/r359249b@2020-01-11-14:15:47   - -7.4G
> 2020-01-11 14:15
>copperbowl/ROOT/r359249b@2020-03-17-21:57:17   - -   12.0G
> 2020-03-17 21:57
>copperbowl/ROOT/r359249b   NR /   59.0G
> 2020-03-28 01:19
> $


beadm destroy ? ;)
___
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: USB microphones with FreeBSD-CURRENT

2020-03-28 Thread Hans Petter Selasky 

On 2020-03-28 07:31, Graham Perrin wrote:

I can't get web browsers to recognise USB microphones.

USB output (e.g. to my headphones) is OK.

USB input (e.g. from the microphone part of the headphones) is not.

Any suggestions?

 From :



What are the mixer values?

mixer -f /dev/mixerN

Are you sure the volume is set high enough?

--HPS

___
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: When will the FreeBSD (u)EFI work?

2020-03-28 Thread Toomas Soome 


> On 28. Mar 2020, at 05:28, Chris  wrote:
> 
> On Fri, 27 Mar 2020 18:31:50 -0700 bsd-li...@bsdforge.com 
>  said
> 
>> On Fri, 27 Mar 2020 17:27:27 -0600 Warner Losh i...@bsdimp.com said
>> > On Fri, Mar 27, 2020 at 4:54 PM Chris  wrote:
>> > > > On Sat, 28 Mar 2020 01:10:37 +0300 Andrey Fesenko f0and...@gmail.com 
>> > > > said
>> > >
>> > > > On Sat, Mar 28, 2020 at 12:53 AM Chris  wrote:
>> > > > >
>> > > > > On an experiment of the FreeBSD EFI implementation. I installed
>> > > > > a copy of releng/12 from install media. Which left me with:
>> > > > > # gpart show ada0
>> > > > > =>   40  312581728  ada0  GPT  (149G)
>> > > > >  40 409600 1  efi  (200M)
>> > > > >  409640   31047680 2  freebsd-ufs  (15G)
>> > > > >31457320768 3  freebsd-swap  (3.7G)
>> > > > >74788904  237792864- free -  (141G)
>> > > > >
>> > > > > On this Intel based system, I can stab the F12 key to pick
>> > > > > my UEFI bootable OS, or let it boot according to the order
>> > > > > I setup in the BIOS. So far, so good.
>> > > > > I needed a copy of releng/13 to also work with. Installed a copy
>> > > > > from install media. Which left me with:
>> > > > > # gpart show ada0
>> > > > > =>   40  312581728  ada0  GPT  (149G)
>> > > > >  40 409600 1  efi  (200M)
>> > > > >  409640   31047680 2  freebsd-ufs  (15G)
>> > > > >31457320768 3  freebsd-swap  (3.7G)
>> > > > >39137320 532480 4  efi  (260M)
>> > > > >39669800   35119104 5  freebsd-ufs  (17G)
>> > > > >74788904  237792864- free -  (113G)
>> > > > > I *assumed* that the install would activate the new install, and I
>> > > > > would boot straight into it. But no. I am still on the previous
>> > > > > install, and worse, I can't get into the new install -- even if
>> > > > > picking it via stabbing the F12 key. I *still* end up in the previous
>> > > > > install. So looking at what might be causing it. I found the
>> > following:
>> > > > > # releng/12
>> > > > > # mount -t msdosfs /dev/ada0p1 /mnt/
>> > > > >
>> > > > > # ls /mnt/efi/boot/
>> > > > > BOOTx64.efi
>> > > > > startup.nsh
>> > > > >
>> > > > > # cat /mnt/efi/boot/startup.nsh
>> > > > > BOOTx64.efi
>> > > > >
>> > > > > # umount /mnt/
>> > > > >
>> > > > > releng/13
>> > > > > # mount -t msdosfs /dev/ada0p4 /mnt/
>> > > > >
>> > > > > # ls /mnt/EFI/freebsd/
>> > > > > loader.efi
>> > > > >
>> > > > > Why the difference? When will FreeBSD (u)EFI work as expected?
>> > > > >
>> > > > > Thanks in advance for any insights!
>> > > > >
>> > > >
>> > > > Require only single efi part
>> > > >
>> > > > See
>> > > >
>> > >
>> > https://forums.freebsd.org/threads/two-freebsd-installations-and-efi.73968/
>> > > Thanks for they reply, and link, Andrey!
>> > > Well that confirms it. FreeBSD, unlike other OS implementations, will not
>> > > permit booting your chosen "version" via EFI.
>> > > Firstly, *huge* thanks for your informative reply, Warner!
>> > It does today. If you use efibootmgr, you can boot exactly what you want. I
>> > do it all the time...  Though your BIOS may overwrite the EFI vars if you
>> > set too many (I'm looking at you supermicro). When you use the efi Boot
>> > variables, it's possible to boot one of many different things on the
>> > system...  Though I've not done 11, just 12 and current.
>> Well. That's the thing. I *am* on 12 && 13. Well *trying* to get into 13.
>> When I started this whole thing, I had some 15 entries returned by
>> efibootmgr(8) -v.
>> So I trimmed the list down to the 2 my BIOS presents as UEFI:
>> Boot0015  UEFI: WDC WD1600JS-98MHB0
>> PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x0,0x,0x0)/HD(4,GPT,6688c5af-6f93...
>> Boot0011* UEFI: WDC WD1600JS-98MHB0
>> PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x0,0x,0x0)/HD(1,GPT,260d2df2-6a10...
>> another entry created when I installed releng/13:
>> Boot0014  FreeBSD (ada0p4)
>> HD(4,GPT,6688c5af-6f93-11ea-adbb-4c72b9f5e07f,0x2553028,0x82000)/File(\EFI\free...
>> and a Windows reference (currently not installed).
>> I activated *both* Boot0015 and Boot0011:
>> efibootmgr -a 0015 0011. Output confirmed success. Bounced box, choose
>> Boot0015. Which booted
>> initial releng/12 install. Fail. OK Try something different;
>> efibootmgr -a 0014 -L FreeBSD-13. Output confirms the -L switch is broken,
>> but 00114 is active.
>> Bounce box && choose 0014. Boots to initial releng/12 install.
>> Conclusion; FreeBSD EFI/ESP is not ready for prime time. :(
>> Thanks again for the reply, Warner! :)
>> --Chris


How loader is working is that it does search for *first* “usable” freebsd 
partition and will use it. Usable is defined as having /boot/loader.efi.

Therefore, you may have 2 or more freebsd instances on the disk, it really does 
not matter, only first is used. If you have multiple disks, you can have 
different order on second disk.

Why it is so? We do build loader.efi and we do copy it to the

ZFS: destroying snapshots without compromising boot environments

2020-03-28 Thread Graham Perrin 

I imagine that some of the 2019 snapshots below are redundant.

Can I safely destroy any of them?

$ zfs list -t snapshot
NAME USED AVAIL  
REFER  MOUNTPOINT

copperbowl/ROOT/Waterfox@2020-03-20-06:19:45    67.0M -  59.2G  -
copperbowl/ROOT/r359249b@2019-08-18-04:04:53    5.82G -  40.9G  -
copperbowl/ROOT/r359249b@2019-08-18-11:28:31    4.32G -  40.7G  -
copperbowl/ROOT/r359249b@2019-09-13-18:45:27-0  9.43G -  43.4G  -
copperbowl/ROOT/r359249b@2019-09-19-20:03:26    5.13G -  43.3G  -
copperbowl/ROOT/r359249b@2019-09-24-20:45:59-0  7.67G -  44.6G  -
copperbowl/ROOT/r359249b@2020-01-09-17:05:57-0  7.66G -  55.2G  -
copperbowl/ROOT/r359249b@2020-01-11-14:15:47    7.41G -  56.2G  -
copperbowl/ROOT/r359249b@2020-03-17-21:57:17    12.0G -  59.2G  -
copperbowl/iocage/releases/12.0-RELEASE/root@jbrowsers 8K -  1.24G  -
copperbowl/poudriere/jails/head@clean    328K -  1.89G  -
$ beadm list
BE   Active Mountpoint  Space Created
Waterfox -  -   12.2G 2020-03-10 18:24
r357746f -  -    1.3G 2020-03-20 06:19
r359249b NR /  148.9G 2020-03-28 01:19
$ beadm list -aDs
BE/Dataset/Snapshot  Active Mountpoint  
Space Created


Waterfox
  copperbowl/ROOT/Waterfox   -  - 137.0M 
2020-03-10 18:24
    r359249b@2020-03-17-21:57:17 - -   59.2G 
2020-03-17 21:57
  copperbowl/ROOT/Waterfox@2020-03-20-06:19:45   - -   67.0M 
2020-03-20 06:19


r357746f
  copperbowl/ROOT/r357746f   - -    1.2G 
2020-03-20 06:19
    Waterfox@2020-03-20-06:19:45 - -   59.2G 
2020-03-20 06:19


r359249b
  copperbowl/ROOT/r359249b@2019-08-18-04:04:53   - -    5.8G 
2019-08-18 04:04
  copperbowl/ROOT/r359249b@2019-08-18-11:28:31   - -    4.3G 
2019-08-18 11:28
  copperbowl/ROOT/r359249b@2019-09-13-18:45:27-0 - -    9.4G 
2019-09-13 18:45
  copperbowl/ROOT/r359249b@2019-09-19-20:03:26   - -    5.1G 
2019-09-19 20:03
  copperbowl/ROOT/r359249b@2019-09-24-20:45:59-0 - -    7.7G 
2019-09-24 20:45
  copperbowl/ROOT/r359249b@2020-01-09-17:05:57-0 - -    7.7G 
2020-01-09 17:05
  copperbowl/ROOT/r359249b@2020-01-11-14:15:47   - -    7.4G 
2020-01-11 14:15
  copperbowl/ROOT/r359249b@2020-03-17-21:57:17   - -   12.0G 
2020-03-17 21:57
  copperbowl/ROOT/r359249b   NR /   59.0G 
2020-03-28 01:19

$

___
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: TLS certificates for NFS-over-TLS floating client

2020-03-28 Thread John-Mark Gurney 
Rick Macklem wrote this message on Thu, Mar 26, 2020 at 14:33 +:
> John-Mark Gurney wrote:
> [lots of stuff snipped]
> >Rick Macklem wrote:
> >> I had originally planned on some "secret" in the certificate (like a CN 
> >> name
> >> that satisfies some regular expression or ???) but others convinced me that
> >> that wouldn't provide anything beyond knowing that the certificate was
> >> signed by the appropriate CA, so I have not implemented anything.
> >
> >Yeah, having a "secret" in the CN doesn't make sense, but what does make
> >sense is allowing the exports line to specify what the CN should contain
> >to be authenticated...
> >
> >Say as a corp, you issue personal certificates to everyone.  This is
> >because you require everyone to sign and/or encrypt their email w/
> >S/MIME.  Each cert includes the email address of that person, so you
> >could simply do something like:
> >/home/alice -tlscert -tlsroot /etc/company.pem -email al...@example.com
> >
> >And anyone who has the certificate w/ al...@example.com that was signed
> >by the public key in /etc/company.pem would be granted access to the
> >export /home/alice.
> >
> >If it allowed ANY cert signed by the CA specified, then that introduces
> >an authentication problem, as now if Malory is a coworker of Alice
> >could also access Alice's home directory...
> >
> >IMO, this is one auth feature that MUST be supported...
> The draft does not address user authentication, only machine authentication.
> --> ie. The certificate is used to decide if a system can do a mount.
>   Users are still identified via user credentials in the RPC message 
> header.
>   For AUTH_SYS, that still means .
>   Otherwise, you need to use Kerberos (sec=krb5[ip]).
>   You could use "tls,sec=krb5" for a mount, but the only advantage that
>   might have over "sec=krb5p" is performance, if there is hardware assist
>   for TLS or something like that.
> 
> >Now that I reread your comments, it sounds like any certificate would be
> >allowed in #2 as long as it is valid, and that would only be marginally
> >better than verification by IP, and in some ways worse, in that now any
> >user could pretend to be any other user, or you have to do something
> >crazy like have a CA per user.
> The case where I see #2 is useful is where this discussion started some weeks 
> ago.
> The example I started with was:
> /home -tls -network 192.168.1.0 -mask 255.255.255.0
> /home -tlscert
> 
> This says that machines on the local lan can mount and do not need to have
> certificates, but must use TLS so data is encrypted on the wire.
> Mounts from anywhere else (presumably laptops) are allowed so long as they 
> have a
> certificate signed by me (as in the site local CA).
> I trust these machines enough that I am willing to allow them to use AUTH_SYS,
> which is what 99.9...% of NFS mounts do now.
> (So, I'd agree that the site local certificate is not a lot better than IP 
> address
>  for client machine identity, just that it is an alternative that can be 
> useful.
>  Without TLS, a line like "/home" allows anyone to mount /home from anywhere
>  and I think you'd agree that few NFS admins. will want to do that. I'm 
> assuming
>  no external firewall for this example.)
> 
> Now, your suggestion of identifying a user via the CN and then having the
> server do all RPCs for the mount as that user is an interesting one.
> My concern w.r.t. implementing it would be interoperability.
> Put another way, if other servers such as Linux, Netapp,... don't adopt it
> (and they won't until there is a draft/RFC specifying it), it would be
> FreeBSD server specific and I'd like to avoid that.
> There was some discussion w.r.t. user authentication via certificates
> during development of the draft, but they decided to defer that work for
> now, so they could get something in place for machine authentication first.
> (If I understood the discussion on nf...@ietf.org.)

There's a fine line between machine and user authentication when you can
add -mapall=someuser.  :)

Yes, a certificate may be used to identify a machine, but if any machine
can be identified by any cert as it appears that #2 is proposed to do, then
you're not actually identifying a machine, you're identifying group of
machines...  Though per the draft, this is explicitly allowed.

It'd be nice to be able to identify particular machines though, and be
able to set the options based upon that..

> >I'm wonder if your use of the term secret was the problem, and not the
> >idea...  Anything that goes in the client cert is by definition public...
> >TLS prior to 1.3 sends the client cert in clear text...  But keying
> >based upon the contents of the cert is fine, as that's the point of
> >what a cert is..  It's trusting the CA to say that the CN and other
> >fields in the cert corresponds to this user, and you can use parts of
> >the cert, like the CN to decide which user the public key in the cert
> >corresponds to.

Rick Mack