Re: Request for Testing: TCP RACK
W dniu 17.11.2023 o 00:13, tue...@fh-muenster.de pisze: On Nov 16, 2023, at 17:50, Marek Zarychta wrote: W dniu 16.11.2023 o 10:13, tue...@freebsd.org pisze: Dear all, recently the main branch was changed to build the TCP RACK stack which is a loadable kernel module, by default: https://cgit.FreeBSD.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc That's really good news and long-awaited change. Thank you. As discussed on the bi-weekly transport call, it would be great if people could test the RACK stack for their workload. Please report any problems to the net@ mailing list or open an issue in the bug tracker and drop me a note via email. This includes regressions in CPU usage, regressions in performance or any other unexpected change you observe. You can load the kernel module using kldload tcp_rack You can make the RACK stack the default stack using sysctl net.inet.tcp.functions_default=rack Based on the feedback we get, the default stack might be switched to the RACK stack. Yes, please do it, at least for CURRENT. Last problem I have spotted with RACK was fixed in June: it was missing support TCP-MD5: https://cgit.freebsd.org/src/commit/?id=02b885b09d1e90574162a1442b9ede06cef2b13a We switched to RACK since upgrading to early stable/13 and genuinely appreciate this gift from Netflix. The performance improvement is invaluable, both in a lossy LAN and on a long-haul overseas TCP connection. Please let me know if you have any questions. Are any MFCs planned, especially to stable/14 ? Now, when stable/14 is almost in sync with main aka CURRENT it's an optimal time for such a MFC. When the change hits stable/14, it would be possible to test it extensively and have it fully functional in 14.1-RELEASE. Let me bring that up on the next Transport call. Will report back. Best regards Michael Thank you ! From now on stable/14 and in the future on 14.1-RELEASE one will be able to load tcp_rack and tcp_bbr out of the box running GENERIC kernel.[1] 1. https://cgit.freebsd.org/src/commit/?id=123fd2a -- Marek Zarychta
Re: Proposal: Disable compression of newsyslog by default
e. Thank you for the new newsyslog(8) -c option providing this feature ! With kind regards -- Marek Zarychta
Re: Request for Testing: TCP RACK
W dniu 16.11.2023 o 10:13, tue...@freebsd.org pisze: Dear all, recently the main branch was changed to build the TCP RACK stack which is a loadable kernel module, by default: https://cgit.FreeBSD.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc That's really good news and long-awaited change. Thank you. As discussed on the bi-weekly transport call, it would be great if people could test the RACK stack for their workload. Please report any problems to the net@ mailing list or open an issue in the bug tracker and drop me a note via email. This includes regressions in CPU usage, regressions in performance or any other unexpected change you observe. You can load the kernel module using kldload tcp_rack You can make the RACK stack the default stack using sysctl net.inet.tcp.functions_default=rack Based on the feedback we get, the default stack might be switched to the RACK stack. Yes, please do it, at least for CURRENT. Last problem I have spotted with RACK was fixed in June: it was missing support TCP-MD5: https://cgit.freebsd.org/src/commit/?id=02b885b09d1e90574162a1442b9ede06cef2b13a We switched to RACK since upgrading to early stable/13 and genuinely appreciate this gift from Netflix. The performance improvement is invaluable, both in a lossy LAN and on a long-haul overseas TCP connection. Please let me know if you have any questions. Are any MFCs planned, especially to stable/14 ? Now, when stable/14 is almost in sync with main aka CURRENT it's an optimal time for such a MFC. When the change hits stable/14, it would be possible to test it extensively and have it fully functional in 14.1-RELEASE. Best regards -- Marek Zarychta
Re: revision not displayed in a2440348eed7
W dniu 9.11.2023 o 05:32, Warner Losh pisze:
Do you have WITHOUT_REPRODUCEABLE_BUILDS=YES in your src.conf?
Yes, I have it.
Warner
On Wed, Nov 8, 2023, 9:03 PM Cy Schubert
wrote:
On Wed, 8 Nov 2023 15:14:34 +0100
Marek Zarychta wrote:
> W dniu 8.11.2023 o 14:10, Marek Zarychta pisze:
> >
> > W dniu 27.09.2023 o 01:07, Tomoaki AOKI pisze:
> >> On Tue, 26 Sep 2023 15:19:46 -0700
> >> Cy Schubert wrote:
> >>
> >>> In message
<20230926231431.20f42fec1075c3980446c...@dec.sakura.ne.jp>,
> >>> Tomoaki
> >>> AOKI writes:
> >>>> On Tue, 26 Sep 2023 15:48:50 +0200
> >>>> Marek Zarychta wrote:
> >>>>
> >>>>> W dniu 26.09.2023 o 13:30, KIRIYAMA Kazuhiko pisze:
> >>>>>> At least up to 15.0-CURRENT, nothing has happend by
> >>>>>> WITHOUT_REPRODUCIBLE_BUILD=yes. Something has changed in
> >>>>>> 15.0-CURRENT at some time. I've rebuilded with 3fb80f1476c7,
> >>>>>> but revision not showed by `uname -a' ;-(
> >>>>>>
> >>>>>> What changed
> >>>>> Nothing changed. Perhaps your build system can't check git
hash ? If
> >>>>> your sources are from git repository, you need at least
git-lite
> >>>>> installed and full git repository available on build
machine. If you
> >>>>> checked out the repository with gitup and have gitup
installed, it
> >>>>> should also work. It won't work if your build machine has
access to
> >>>>> only a part of the repository like worktree.
> >>>>>
> >>>>> Cheers
> >>>>>
> >>>>> --
> >>>>> Marek Zarychta
> >>>> Just a possibility, but copying src tree to directory other
than the
> >>>> directory where checked out from git repo and building
there could
> >>>> lose track with git hash.
> >>>>
> >>>> Another possibility is that if you build src with any user
other than
> >>>> the one owning local (pulled) git repo could also lose
track with git
> >>>> hash. For example, if I `git log HEAD` with regular user
and the local
> >>>> repo is pulled by root, it fails. No special configuration
is done.
> >>>>
> >>>> % git log HEAD
> >>>> fatal: detected dubious ownership in repository at '/usr/src'
> >>>> To add an exception for this directory, call:
> >>>>
> >>>> git config --global --add safe.directory /usr/src
> >>>>
> >>>>
> >>> This could be due to e6dc6a27230, which was committed this
morning.
> >>> There
> >>> is discussion on the src commits ML (dev-commits-src-all,
> >>> dev-commits-src-main) about reverting the change.
> >>>
> >>>
> >>> --
> >>> Cheers,
> >>> Cy Schubert
> >>> FreeBSD UNIX: Web: https://FreeBSD.org
<https://FreeBSD.org>
> >>> NTP: Web: https://nwtime.org
> >>>
> >>> e^(i*pi)+1=0
> >> Would be unrelated here, unfortunately.
> >> As the subject says, the commit the original reporter is
bitten at (not
> >> bi-sected) is at a2440348eed7, which is before e6dc6a27230.
> >
> > Let's refresh this thread. It looks like (at least for stable/14)
> > build system doesn't hardcode revision into the kernel
anymore. Last
> > time it worked to me was just after branching stable/14. Today
I tried
> > to build kernel from sources mounted over NFS and I ened with:
> >
> > # strings /usr/obj/usr/src/amd64.amd64/sys/BSDONDELL/kernel |
grep
> > 14.0-STABLE
> > @(#)FreeBSD 14.0-STABLE #6 -dirty: Tue Nov 7 14:04:35 CET 2023
> > FreeBSD 14.0-STABLE #6 -dirty: Tue Nov 7 14:04:35 CET 2023
> > 14.0-STABLE
> >
> > the source repository is updated, consisted, but mounted
read-only
> > over NFS
> >
> > /usr/src# git status
> > On branch stable/14
> > Your branch is up to date with 'origin/stable/14'.
> >
> > Untracked files:
> > (use &qu
Re: revision not displayed in a2440348eed7
W dniu 8.11.2023 o 14:10, Marek Zarychta pisze: W dniu 27.09.2023 o 01:07, Tomoaki AOKI pisze: On Tue, 26 Sep 2023 15:19:46 -0700 Cy Schubert wrote: In message <20230926231431.20f42fec1075c3980446c...@dec.sakura.ne.jp>, Tomoaki AOKI writes: On Tue, 26 Sep 2023 15:48:50 +0200 Marek Zarychta wrote: W dniu 26.09.2023 o 13:30, KIRIYAMA Kazuhiko pisze: At least up to 15.0-CURRENT, nothing has happend by WITHOUT_REPRODUCIBLE_BUILD=yes. Something has changed in 15.0-CURRENT at some time. I've rebuilded with 3fb80f1476c7, but revision not showed by `uname -a' ;-( What changed Nothing changed. Perhaps your build system can't check git hash ? If your sources are from git repository, you need at least git-lite installed and full git repository available on build machine. If you checked out the repository with gitup and have gitup installed, it should also work. It won't work if your build machine has access to only a part of the repository like worktree. Cheers -- Marek Zarychta Just a possibility, but copying src tree to directory other than the directory where checked out from git repo and building there could lose track with git hash. Another possibility is that if you build src with any user other than the one owning local (pulled) git repo could also lose track with git hash. For example, if I `git log HEAD` with regular user and the local repo is pulled by root, it fails. No special configuration is done. % git log HEAD fatal: detected dubious ownership in repository at '/usr/src' To add an exception for this directory, call: git config --global --add safe.directory /usr/src This could be due to e6dc6a27230, which was committed this morning. There is discussion on the src commits ML (dev-commits-src-all, dev-commits-src-main) about reverting the change. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 Would be unrelated here, unfortunately. As the subject says, the commit the original reporter is bitten at (not bi-sected) is at a2440348eed7, which is before e6dc6a27230. Let's refresh this thread. It looks like (at least for stable/14) build system doesn't hardcode revision into the kernel anymore. Last time it worked to me was just after branching stable/14. Today I tried to build kernel from sources mounted over NFS and I ened with: # strings /usr/obj/usr/src/amd64.amd64/sys/BSDONDELL/kernel | grep 14.0-STABLE @(#)FreeBSD 14.0-STABLE #6 -dirty: Tue Nov 7 14:04:35 CET 2023 FreeBSD 14.0-STABLE #6 -dirty: Tue Nov 7 14:04:35 CET 2023 14.0-STABLE the source repository is updated, consisted, but mounted read-only over NFS /usr/src# git status On branch stable/14 Your branch is up to date with 'origin/stable/14'. Untracked files: (use "git add ..." to include in what will be committed) sys/amd64/conf/BSDONDELL It took 2.53 seconds to enumerate untracked files. See 'git help status' for information on how to improve this. nothing added to commit but untracked files present (use "git add" to track) Any clues what could be wrong ? Does /usr/src/ require write permissions now ? I am sorry for the false alarm. It looks like using META MODE prevented updating this info. After cleaning obj dir and rebuilding revision is visible: # strings /usr/obj/usr/src/amd64.amd64/sys/BSDONDELL/kernel | grep 14.0-STABLE @(#)FreeBSD 14.0-STABLE #0 stable/14-n265707-d2c65a1c9486: Wed Nov 8 14:16:31 CET 2023 FreeBSD 14.0-STABLE #0 stable/14-n265707-d2c65a1c9486: Wed Nov 8 14:16:31 CET 2023 -- Marek Zarychta
Re: revision not displayed in a2440348eed7
W dniu 27.09.2023 o 01:07, Tomoaki AOKI pisze: On Tue, 26 Sep 2023 15:19:46 -0700 Cy Schubert wrote: In message <20230926231431.20f42fec1075c3980446c...@dec.sakura.ne.jp>, Tomoaki AOKI writes: On Tue, 26 Sep 2023 15:48:50 +0200 Marek Zarychta wrote: W dniu 26.09.2023 o 13:30, KIRIYAMA Kazuhiko pisze: At least up to 15.0-CURRENT, nothing has happend by WITHOUT_REPRODUCIBLE_BUILD=yes. Something has changed in 15.0-CURRENT at some time. I've rebuilded with 3fb80f1476c7, but revision not showed by `uname -a' ;-( What changed Nothing changed. Perhaps your build system can't check git hash ? If your sources are from git repository, you need at least git-lite installed and full git repository available on build machine. If you checked out the repository with gitup and have gitup installed, it should also work. It won't work if your build machine has access to only a part of the repository like worktree. Cheers -- Marek Zarychta Just a possibility, but copying src tree to directory other than the directory where checked out from git repo and building there could lose track with git hash. Another possibility is that if you build src with any user other than the one owning local (pulled) git repo could also lose track with git hash. For example, if I `git log HEAD` with regular user and the local repo is pulled by root, it fails. No special configuration is done. % git log HEAD fatal: detected dubious ownership in repository at '/usr/src' To add an exception for this directory, call: git config --global --add safe.directory /usr/src This could be due to e6dc6a27230, which was committed this morning. There is discussion on the src commits ML (dev-commits-src-all, dev-commits-src-main) about reverting the change. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 Would be unrelated here, unfortunately. As the subject says, the commit the original reporter is bitten at (not bi-sected) is at a2440348eed7, which is before e6dc6a27230. Let's refresh this thread. It looks like (at least for stable/14) build system doesn't hardcode revision into the kernel anymore. Last time it worked to me was just after branching stable/14. Today I tried to build kernel from sources mounted over NFS and I ened with: # strings /usr/obj/usr/src/amd64.amd64/sys/BSDONDELL/kernel | grep 14.0-STABLE @(#)FreeBSD 14.0-STABLE #6 -dirty: Tue Nov 7 14:04:35 CET 2023 FreeBSD 14.0-STABLE #6 -dirty: Tue Nov 7 14:04:35 CET 2023 14.0-STABLE the source repository is updated, consisted, but mounted read-only over NFS /usr/src# git status On branch stable/14 Your branch is up to date with 'origin/stable/14'. Untracked files: (use "git add ..." to include in what will be committed) sys/amd64/conf/BSDONDELL It took 2.53 seconds to enumerate untracked files. See 'git help status' for information on how to improve this. nothing added to commit but untracked files present (use "git add" to track) Any clues what could be wrong ? Does /usr/src/ require write permissions now ? -- Marek Zarychta
Re: revision not displayed in a2440348eed7
W dniu 26.09.2023 o 13:30, KIRIYAMA Kazuhiko pisze: At least up to 15.0-CURRENT, nothing has happend by WITHOUT_REPRODUCIBLE_BUILD=yes. Something has changed in 15.0-CURRENT at some time. I've rebuilded with 3fb80f1476c7, but revision not showed by `uname -a' ;-( What changed Nothing changed. Perhaps your build system can't check git hash ? If your sources are from git repository, you need at least git-lite installed and full git repository available on build machine. If you checked out the repository with gitup and have gitup installed, it should also work. It won't work if your build machine has access to only a part of the repository like worktree. Cheers -- Marek Zarychta
Re: dhclient unable to negotiate on WPA2-Enterprise network (eduroam)
C=BE/O=GlobalSign nv-sa/CN=GlobalSign RSA OV SSL CA 2018' hash=[redacted] Jun 28 12:44:25 neon wpa_supplicant[1517]: wlan0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=CA/ST=Ontario/L=Waterloo/O=University of Waterloo/CN=eduroam.uwaterloo.ca' hash=[redacted] Jun 28 12:44:25 neon wpa_supplicant[1517]: wlan0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:eduroam.uwaterloo.ca Jun 28 12:44:25 neon wpa_supplicant[1517]: wlan0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:cn-aaa.uwaterloo.ca Jun 28 12:44:25 neon wpa_supplicant[1517]: wlan0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:ns-aaa.uwaterloo.ca Jun 28 12:44:25 neon wpa_supplicant[1517]: wlan0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:auth-x.uwaterloo.ca Jun 28 12:44:25 neon wpa_supplicant[1517]: wlan0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:guest.wifi.uwaterloo.ca Jun 28 12:44:25 neon wpa_supplicant[1517]: wlan0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:ns-ise-psn-a.private.uwaterloo.ca Jun 28 12:44:25 neon wpa_supplicant[1517]: wlan0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:ns-ise-psn-b.private.uwaterloo.ca Jun 28 12:44:25 neon wpa_supplicant[1517]: wlan0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:ns-ise-psn-c.private.uwaterloo.ca Jun 28 12:44:25 neon wpa_supplicant[1517]: wlan0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:ns-ise-psn-d.private.uwaterloo.ca Jun 28 12:44:25 neon wpa_supplicant[1517]: wlan0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:ns-ise-psn-e.private.uwaterloo.ca Jun 28 12:44:25 neon wpa_supplicant[1517]: OpenSSL: EVP_DigestInit_ex failed: error:12800067:DSO support routines::could not load the shared library Jun 28 12:44:25 neon kernel: Jun 28 12:44:25 neon wpa_supplicant[1517]: OpenSSL: EVP_DigestInit_ex failed: error:12800067:DSO support routines::could not load the shared library Jun 28 12:44:25 neon wpa_supplicant[1517]: EAP-MSCHAPV2: Failed to derive response This makes me think the change might be related to the recent OpenSSL migration? Either way, things seem to be broken at the moment and a solution would be appreciated. Thanks, Naman. (they/them) Thanks for the report. Have you tried security/wpa_supplicant BTW? -- Marek Zarychta
Re: Surprise null root password
W dniu 26.05.2023 o 19:35, bob prohaska pisze:
While going through normal security email from a Pi2
running -current I was disturbed to find:
Checking for passwordless accounts:
root::0:0::0:0:Charlie &:/root:/bin/sh
This thread reminded me of another issue with passwords I encountered a
few years ago.
Setting stronger passwords by users can be enforced by pam_passwdqc(8).
But if the password expiration policy is enabled, it doesn't work since
the password change for expired passwords is called by ssh or login PAM
module, thus to enforce stronger passwords for users with passwords
expired pam_passwdqc should be added also to both:
/etc/pam.d/{login,sshd}, otherwise user with an expired password just
presses return twice during the login prompt and has an empty password
set. I even have risen D27656 some time ago, but it had gained not much
interest except for some rephrasing/grammar advice.
So to use a password expiration policy and enforce high-quality
passwords together, pam_passwdqc(8) has to activated in the three:
/etc/pam.d/{login,passwd,sshd}.
Cheers
--
Marek Zarychta
Re: Problem compiling py-* ports
W dniu 18.04.2023 o 10:46, Felix Palmen pisze: * Filippo Moretti [20230418 08:12]: File "/usr/local/lib/python3.9/site-packages/setuptools/_importlib.py", line 31, in if isinstance(ob, importlib_metadata.MetadataPathFinder) AttributeError: module 'importlib_metadata' has no attribute 'MetadataPathFinder' I am also hitting this bug with Python 3.8, so I recently considered an upgrade to 3.10, but it comes out that flaw is not version dependent. Looks like you're building directly on your host (not in clean jails) and the build picks up "something" that's already installed. What is the culprit? Removing blindly all py- packages for all affected hosts with dependent software is not the best solution. I'd probably try to uninstall all python packages, check whether there are leftovers in LOCALBASE/lib/python3.9 (and remove them if necessary) and then do a rebuild. You can avoid this class of issues using poudriere btw... -- Marek Zarychta
Re: cant login after make installworld: pam_opie.so.6 not found
W dniu 3.01.2023 o 22:39, Ivan Quitschal pisze: now I cant login (only thru single user) looks like the “make delete-old-libs” has deleted that lib pam_opie.so.6 and now I cannot pass the login prompt says the error “pam_opie.so: not found how can I get it back? I tried everything and nothing brought it back , not even another make installworld any insights? Remove dependencies from /etc/pam.d/ files. Use either etcupdate(7) or mergemaster(8) or do it by hand. -- Marek Zarychta
Re: native recording of all network connections on freebsd
W dniu 29.12.2022 o 02:58, Damjan Jovanovic pisze: On Wed, Dec 28, 2022 at 4:21 PM Dan Mack wrote: I'm wondering if anyone can help point me at a good way to continously capture every inbound and outbound connection made to a freebsd system. I'd prefer a way that is native in base if possible. I don't really want to record all the packets, just the src:dest:rport:dport stats. Happy to RTFM as well, Dan Another possibility is to enable Netflow in ipfw (there is an ipfw_netflow service), which submits periodic reports of all connections made and their data usage, and then collect and process the Netflow data using a Netflow server. Or develop a custom Netgraph service that examines packets and logs connections. This would even work in the absence of any firewall. Such a node exists: ng_netflow(4) and works flawlessly. -- Marek Zarychta
Re: [iwlwifi] ipv6 connection problem
W dniu 11.08.2022 o 17:53, Nuno Teixeira pisze:
Hello Bjoern!
/etc/rc.conf:
---
wlans_iwlwifi0="wlan0"
create_args_wlan0="wlanmode sta regdomain ETSI country PT"
ifconfig_wlan0_ipv6="inet6 accept_rtadv"
ifconfig_wlan0="WPA SYNCDHCP"
rtsold_enable="YES"
---
If you are connecting to IPv6 only WLAN than you can probably either
disable DHCP (if the RDNSS is provided for this network):
ifconfig_wlan0="WPA up"
or install dhcp client capable of acquiring DHCPv6 lease and use it
instead of standard dhclient(8) from the base which doesn't support DHCPv6.
`ifconfig wlan0`:
---
wlan0: flags=8c43 metric
0 mtu 1500
ether 6c:6a:77:df:09:21
inet6 fe80::6e6a:77ff:fedf:921%wlan0 prefixlen 64 scopeid 0x3
groups: wlan
ssid "" channel 6 (2437 MHz 11g)
regdomain ETSI country PT authmode WPA1+WPA2/802.11i privacy MIXED
deftxkey UNDEF txpower 30 bmiss 7 scanvalid 60 protmode CTS wme
roaming MANUAL bintval 0
parent interface: iwlwifi0
media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
status: no carrier
nd6 options=23
---
(a) this is unlikely related to IPv6? The only thing that would do
is pass down more multicast addresses than with just IPv4 (and that's
after assoc normally). I run some on IPv6-only.
Let me ask you anyway, so we can be sure. If you remove the IPv6
config,
does wpa_supplicant associate fine? (could also be a different
tooling issue).
With ipv4 wireless work ok and wpa_supplicant associate ok.
(b) does `ifconfig wlan0 list scan` show your AP when it doesn't?
If it doesn't that is more likely the problem. And that remains a
problem
for some conditions I am also facing. More on 11a than 11g.
`ifconfig wlan0 list scan`:
---
SSID/MESH ID BSSID CHAN RATE S:N
INT CAPS
MEO-3637C0 00:06:91:36:37:c0 11 54M -53:-96
100 EP RSN BSSLOAD HTCAP WPS WME
MEO-WiFi 00:06:91:36:37:c2 11 54M -53:-96
100 E BSSLOAD HTCAP WME
MEO-3637C0 00:06:91:36:37:c1 60 54M -61:-96
100 EP RSN BSSLOAD HTCAP VHTCAP VHTOPMODE VHTPWRENV WPS WME
MEO-WiFi 00:06:91:36:37:c6 60 54M -60:-96
100 E BSSLOAD HTCAP VHTCAP VHTOPMODE VHTPWRENV WME
---
(c) Then the question is if wpa_supplicant blacklists the network;
`wpa_cli blacklist` would show. If it does try the following sequence
to make it try more often:
CMD=wpa_cli
SSID=
${CMD} blacklist clear
${CMD} disable ${SSID}
${CMD} enable ${SSID}
${CMD} list_networks
`wpa_cli blacklist`:
---
Failed to connect to non-global ctrl_ifname: (nil) error: Inappropriate
ioctl for device
---
(d) given you didn't say, what does `freebsd-version -r -u`
say, just to rule out you are missing the latest wpa fixes.
`freebsd-version -r -u`:
---
14.0-CURRENT
14.0-CURRENT
---
@1ffd352bc25b
(e) what you can do is enable more wpa_supplicant logging; I often use
wpa_supplicant_flags="-sdd" in /etc/rc.conf which will log to
syslog instead
of the debug file but it'll increase debugging a lot (and warning, it
may also log keying material).
Ok.
Cheers,
--
Nuno Teixeira
FreeBSD Committer (ports)
--
Marek Zarychta
OpenPGP_signature
Description: OpenPGP digital signature
Re: exec(btxld) failed (No such file or directory) and obj via nullfs
W dniu 4.06.2022 o 01:39, Rozhuk Ivan pisze:
Hi!
I found a way to fix error during install: exec(btxld) failed (No such file or
directory)
in case obj is nullfs mounted.
Use option: -o nocache
mount_nullfs -o rw -o nocache -o noatime "${MAKEOBJDIRPREFIX_TMP}"
"${MAKEOBJDIRPREFIX}"
This helps for me, hope it will be usfull for community.
PS: this works even without https://reviews.freebsd.org/D23411 patch.
I do not dig inside this and have no idea why this option undocumented.
Probably this some kernel/nullfs bug that must be investigated, or just
remove option and make it always enabled.
The build race has been fixed[1].
Sine then I am no more encountering problems while building to nullfs
mounted OBJDIR, at least in CURRENT and 13-STABLE.
[1]
https://cgit.freebsd.org/src/commit/sys/fs/nullfs?id=42881526d401e7a9c09241e392b7ffa18cfe11d6
--
Marek Zarychta
OpenPGP_signature
Description: OpenPGP digital signature
Re: Kernel panic on armv7 when PF is enabled
W dniu 2.05.2022 o 11:02, Kristof Provost pisze: On 1 May 2022, at 5:13, qroxana wrote: After git bisecting the panic started since this commit. commit 78bc3d5e1712bc1649aa5574d2b8d153f9665113 Author: Kristof Provost < k...@freebsd.org Date: Mon Feb 14 20:09:54 2022 +0100 vlan: allow net.link.vlan.mtag_pcp to be set per vnet The primary reason for this change is to facilitate testing. MFC after: 1 week sys/net/if_ethersubr.c | 9 + sys/net/if_vlan.c | 5 +++-- 2 files changed, 8 insertions(+), 6 deletions(-) The armv7 board boots from a NFS root, it can boot without any problem if PF is disabled. Any helps? add host ::1: gateway lo0 fib 0: route already in table add net fe80::: gateway ::1 add net ff02::: gateway ::1 add net :::0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 Enabling pf. Kernel page fault with the following non-sleepable locks held: shared rm pf rulesets (pf rulesets) r = 0 (0xe3099430) locked @ /usr/src/sys/netpfil/pf/pf.c:6493 exclusive rw tcpinp (tcpinp) r = 0 (0xdb748d88) locked @ /usr/src/sys/netinet/tcp_usrreq.c:1008 stack backtrace: #0 0xc0355cac at witness_debugger+0x7c #1 0xc0356ef0 at witness_warn+0x3fc #2 0xc05ec048 at abort_handler+0x1d8 #3 0xc05cb5ac at exception_exit+0 #4 0xe3083c10 at pf_syncookie_validate+0x60 #5 0xe30496a8 at pf_test+0x518 #6 0xe306d768 at pf_check_out+0x30 #7 0xc0415b44 at pfil_run_hooks+0xbc #8 0xc0445cfc at ip_output+0xce8 #9 0xc045bc9c at tcp_default_output+0x20ac #10 0xc0471eb4 at tcp_usr_send+0x1ac #11 0xc0389464 at sosend_generic+0x490 #12 0xc0389790 at sosend+0x64 #13 0xc0502888 at clnt_vc_call+0x560 #14 0xc05009d8 at clnt_reconnect_call+0x170 #15 0xc01e7b14 at newnfs_request+0xb20 #16 0xc0230218 at nfscl_request+0x60 #17 0xc020d9bc at nfsrpc_getattr+0xb0 Fatal kernel mode data abort: 'Alignment Fault' on read trapframe: 0xdf1f1c90 FSR=0001, FAR=d7840264, spsr=4013 r0 =6a228eda, r1 =dac0d785, r2 =d7840264, r3 =db5527c0 r4 =df1f1e00, r5 =dac0d75f, r6 =0018, r7 =d9422c00 r8 =c093e5e4, r9 =0001, r10=df1f1f5c, r11=df1f1d38 r12=e3098dd0, ssp=df1f1d20, slr=e3083bdc, pc =e3083c10 The commit you point at is entirely unrelated to the code where the panic occurred, so I’m pretty sure something went wrong in your bisect. I was experiencing this panic also running FreeBSD 14.0-CURRENT #1 main-n253028-2ec9a427c85: Tue Feb 8 17:49:25 CET 2022 on armv7, so it's unrelated to aforementioned commit which is dated 2022-02-14. It's very interesting and weird bug, loading pf.ko, enabling PF, loading the rules work as expected, but processing the filtered traffic by PF triggers the panic. The backtrace would suggest the issue occurs in the pf_syncookie_validate() function, and likely in the line |if (atomic_load_64(_pf_status.syncookies_inflight[cookie.flags.oddeven]) == 0)| The obvious way for that to panic would be to call it without the curvnet context set, but pf_test() uses it earlier, so that’s going to be fine. Given that this is unique to armv7 I’d recommend talking to the armv7 maintainer about 64 bit atomic operations. You can probably avoid the atomic load with this patch (and not enabling syncookie support): |diff --git a/sys/netpfil/pf/pf_syncookies.c b/sys/netpfil/pf/pf_syncookies.c index 5230502be30c..c86d469d3cef 100644 --- a/sys/netpfil/pf/pf_syncookies.c +++ b/sys/netpfil/pf/pf_syncookies.c @@ -313,6 +313,9 @@ pf_syncookie_validate(struct pf_pdesc *pd) ack = ntohl(pd->hdr.tcp.th_ack) - 1; cookie.cookie = (ack & 0xff) ^ (ack >> 24); + if (V_pf_status.syncookies_mode == PF_SYNCOOKIES_NEVER) + return (0); + /* we don't know oddeven before setting the cookie (union) */ if (atomic_load_64(_pf_status.syncookies_inflight[cookie.flags.oddeven]) == 0) | That shouldn’t be required though. Br, Kristof -- Marek Zarychta OpenPGP_signature Description: OpenPGP digital signature
Re: discussion on future removal of empty $FreeBSD$ tags
W dniu 2.05.2022 o 22:09, Warner Losh pisze: The current plans are to keep $FreeBSD$ in main until stable/12 is out of support. no new files will have it added, unless they are to be merged to stable/12 and are installed / managed by mergemaster. We'll do a coordinated sweep of the tree removing them after stable/12 drops out of support and we'll do similar commits to stable/13 to reduce as much as possible any merge conflicts after that point. stable/13 and newer they are, of course, just noise. mergemaster doesn't require them to be non-empty, but will skip modified files if they match. Though it's been a while since I've used mergemaster... It has no maintainer and only receives emergency fixes when something breaks (and it usually takes a while for the right people to notice). Warner Thank you for the reply and for revealing your official plans regarding $FreeBSD$ tags. Marek Zarychta On Mon, May 2, 2022 at 12:25 PM Marek Zarychta wrote: Dear subscribers, after one of the recent commits[1] surprisingly we got rid of $FreeBSD$ from among others, two configuration files: /etc/ssh/ssh_config and /etc/ssh/sshd_config. I was told these IDs are going to be deprecated in the whole source tree when 12.x branch reaches EoL, what is surprising news, at least for me. While indeed empty $FreeBSD$ tags after the transition to git became useless, leaving them in config files, still might be handy. Please let me explain why. After the transition to git, a lot of people complained about breakage in mergemaster(8). Finally, they were told that this tool is outdated, cannot do 3-way merge, has no maintainer, etc. so it's going to be deprecated soon. Then appropriate notice was added, the handbook got updated, so seemingly everyone was fine with this depreciation. I am not going to bring any serious arguments against etcupdate(8), but when providing support on IRC, a few cases of foot shooting with this tool had been reported to me and the last one happened this year IIRC. Moreover some people, including me, just like and are used to old sdiff(1)-way work of mergemaster(8). So soon after the transition to git to overcome this deficiency I wrote for myself a git primer helping with quick creation of local repository including $FreeBSD$ recreation for mergemaster(8) relying on empty $FreeBSD$ tags. I will attach this primer[2] for users here, maybe someone (noncommitter) will benefit from this (if it will not get burned with fire here earlier). Please don't get me wrong, I am not fighting with etcupdate(8) which works almost flawlessly in unison with freebsd-update(8), but people who follow STABLE/CURRENT really do appreciate the existence of mergemaster(8) and still use it behind the scenes, including probably members of core@ team. I am only asking for leaving these empty $FreeBSD$ IDs in config files. This will of course add some burden to committers' work but might be beneficial in the future. I am neither committer, nor contributor, but the voice from the userbase. Best regards, Marek Zarychta [1] https://cgit.freebsd.org/src/commit/?id=835ee05f [2] # # FreeBSD Git src with worktrees and clean/smudge filters # for mergemaster(8) # # Preparation of the tree zfs create zroot/usr/src_head zfs create zroot/usr/src_13 # Making src of stable/13 mountable in /usr/src echo "/usr/src_13 /usr/src nullfs rw,late 0 0" >> /etc/fstab mount -al # Cloning the repository cd /usr/src_head git clonehttps://git.freebsd.org/src.git/ ./ # Adding filters # Filters require lang/ruby and lang/perl installed git config filter.freebsdid.smudge expand_freebsd git config filter.freebsdid.clean 'perl -pe "s/\\\$FreeBSD[^\\\$]*\\\$/\\\$FreeBSD\\\$/"' # Limiting filters scope # In /usr/src_head create file .git/info/attributes with # following contents (at least): cut cat > .git/info/attributes << EOF etc/* filter=freebsdid etc/*/* filter=freebsdid libexec/rc/*filter=freebsdid libexec/rc/rc.d/* filter=freebsdid *.conf filter=freebsdid dot.??* filter=freebsdid lib/libc/gen/shells filter=freebsdid lib/libc/net/hosts filter=freebsdid lib/libpam/pam.d/* filter=freebsdid lib/libwrap/hosts.allow filter=f
discussion on future removal of empty $FreeBSD$ tags
Dear subscribers,
after one of the recent commits[1] surprisingly we got rid of $FreeBSD$
from among others, two configuration files: /etc/ssh/ssh_config and
/etc/ssh/sshd_config. I was told these IDs are going to be deprecated in
the whole source tree when 12.x branch reaches EoL, what is surprising
news, at least for me. While indeed empty $FreeBSD$ tags after the
transition to git became useless, leaving them in config files, still
might be handy. Please let me explain why.
After the transition to git, a lot of people complained about breakage
in mergemaster(8). Finally, they were told that this tool is outdated,
cannot do 3-way merge, has no maintainer, etc. so it's going to be
deprecated soon. Then appropriate notice was added, the handbook got
updated, so seemingly everyone was fine with this depreciation. I am not
going to bring any serious arguments against etcupdate(8), but when
providing support on IRC, a few cases of foot shooting with this tool
had been reported to me and the last one happened this year IIRC.
Moreover some people, including me, just like and are used to old
sdiff(1)-way work of mergemaster(8). So soon after the transition to
git to overcome this deficiency I wrote for myself a git primer helping
with quick creation of local repository including $FreeBSD$ recreation
for mergemaster(8) relying on empty $FreeBSD$ tags. I will attach this
primer[2] for users here, maybe someone (noncommitter) will benefit from
this (if it will not get burned with fire here earlier).
Please don't get me wrong, I am not fighting with etcupdate(8) which
works almost flawlessly in unison with freebsd-update(8), but people who
follow STABLE/CURRENT really do appreciate the existence of
mergemaster(8) and still use it behind the scenes, including probably
members of core@ team. I am only asking for leaving these empty
$FreeBSD$ IDs in config files. This will of course add some burden to
committers' work but might be beneficial in the future. I am neither
committer, nor contributor, but the voice from the userbase.
Best regards,
Marek Zarychta
[1] https://cgit.freebsd.org/src/commit/?id=835ee05f
[2]
#
# FreeBSD Git src with worktrees and clean/smudge filters
# for mergemaster(8)
#
# Preparation of the tree
zfs create zroot/usr/src_head
zfs create zroot/usr/src_13
# Making src of stable/13 mountable in /usr/src
echo "/usr/src_13 /usr/src nullfs rw,late 0 0" >> /etc/fstab
mount -al
# Cloning the repository
cd /usr/src_head
git clonehttps://git.freebsd.org/src.git/ ./
# Adding filters
# Filters require lang/ruby and lang/perl installed
git config filter.freebsdid.smudge expand_freebsd
git config filter.freebsdid.clean 'perl -pe
"s/\\\$FreeBSD[^\\\$]*\\\$/\\\$FreeBSD\\\$/"'
# Limiting filters scope
# In /usr/src_head create file .git/info/attributes with
# following contents (at least):
cut
cat > .git/info/attributes << EOF
etc/* filter=freebsdid
etc/*/* filter=freebsdid
libexec/rc/*filter=freebsdid
libexec/rc/rc.d/* filter=freebsdid
*.conf filter=freebsdid
dot.??* filter=freebsdid
lib/libc/gen/shells filter=freebsdid
lib/libc/net/hosts filter=freebsdid
lib/libpam/pam.d/* filter=freebsdid
lib/libwrap/hosts.allow filter=freebsdid
usr.sbin/services_mkdb/services filter=freebsdid
usr.sbin/bsnmpd/bsnmpd/snmpd.config filter=freebsdid
usr.sbin/periodic/etc/* filter=freebsdid
usr.sbin/cron/cron/crontab filter=freebsdid
crypto/openssh/ssh*_config filter=freebsdid
EOF
cut
# Smudge filter setup
# Create file /usr/local/bin/expand_freebsd with following
# contents and make it executable.
cut
#!/usr/bin/env ruby
data = STDIN.read
last_info = `git log --pretty=format:"%h %ae %ad" -1`
puts data.gsub('$FreeBSD$', '$FreeBSD: ' + last_info.to_s + '$')
cut
chmod a+x /usr/local/bin/expand_freebsd
# Adding worktrees
# Add worktree for stable/13, filters will be applied
git worktree add /usr/src_13 stable/13
# To have IDs in main (HEAD)
# do checkout of filtered files again
cd /usr/src_head
rm etc/master.passwd etc/group
rm libexec/rc/rc.d/*
git checkout -f -- .
# To find more files with $FreeBSD tags which might
# be added to .git/info/attributes file issue command:
find . -type f -a -not -name '*~' | xargs grep -l '$FreeBSD'
--
Marek Zarychta
Re: ext2fs: WARNING: mount of XXXX denied due to unsupported optional features: needs_recovery
W dniu 28.04.2022 o 21:21, FreeBSD User pisze: Running XigmaNAS 12.3.0.4.9009 on amd64 hardware, we try to mount HDD to rescue them and store the data on ZFS volumes. Mounting of the HDD doesn't work, FreeBSD 12.3 obviously lack in some etx2 features, namely "needs_recovery". The kernel reports: WARNING: mount of da4p3 denied due to unsupported optional features: needs_recovery How can this problem be solved? Thanks in advance, oh Probably as the name of the mailing list suggest you should upgrade to 14.0-CURRENT and maybe run fsck.ext2(8) on this partition to fix it. -- Marek Zarychta
Re: DHCPDv6 in non-vnet jail
Dnia Tue, Mar 29, 2022 at 10:11:29AM +0200, Goran Mekić napisał(a): > On Sun, Mar 27, 2022 at 02:34:11PM +, Bjoern A. Zeeb wrote: > > I assume you have /dev/bpf available inside that jail by a devfs rule so > > effectively you have all network interfaces and traffic available? > As a form of test I've put rtadvd inside the same non-vnet jail and I > can see RA message arrive to the vnet jail. I though I "disconnected" > something concerning IPv6, but that's obviously not the case. > > Let's take a step back. Is there any howto/tutorial on how to put > isc-dhcpd6 in a non-vnet jail? I don't care if it's jail.conf or some > jail manager. Can I somehow see where packets end up, like dtrace? > Should I try some other server/client for DHCPv6? If I can make it work > in any scenario, that would be good starting point for me to figure out > what's wrong with my current setup. > > Regards, > meka Running DHCPv6 in a jail is possible and pretty straigtforward if /dev/bpf is exposed, but I have never tried to run rtadvd(8) in the jail. The net/isc-dhcp44-server works flawlessy in dedicated DHCPv6 reduntant jails without VNET, but the RA is always done on the core switches for all suppoted subnets in my case. Please consider that DHCPv6 is never replacement, but addition to properly confiugred RA. Best regards, -- Marek Zarychta
Re: HEADS-UP: PIE enabled by default on stable/13
Hello Marcin W dniu 24.01.2022 o 19:43, Marcin Wojtas pisze: Hi Marek, pon., 24 sty 2022 o 08:17 Marek Zarychta napisał(a): W dniu 24.01.2022 o 07:42, Marcin Wojtas pisze: +freebsd-stable@ niedz., 23 sty 2022 o 11:36 Marcin Wojtas napisał(a): Hi, As of 396e9f259d962 the base system binaries are now built as position-independent executable (PIE) by default, for 64-bit architectures. Thanks to that enabling ASLR can be done simply by sysctls knobs when booting the kernel. If you track stable/13 and normally build WITHOUT_CLEAN you'll need to do one initial clean build -- either run `make cleanworld` or set WITH_CLEAN=yes. The change is a pure MFC of the changes integrated to -CURRENT early 2021 and no issues are expected, but in case any problems are observed, please issue a PR and/or let me know in this thread. Best regards, Marcin Thanks for enabling this. If I understand it correctly we got some improvements mentioned here[1] and it doesn't imply that ASLR has to be enabled, especially kern.elf64.aslr.pie_enable can be still set to 0 ? Currently it still remains opt-in on stable/13 and is disabled by default. Best regards, Marcin Thanks for the answer. I am not willing to turn ASLR on at this point, but rather asking if my world, already built with PIE, will bring any other enhancements or improvements? [1] https://www.mail-archive.com/freebsd-current@freebsd.org/msg183605.html With kind regards, -- Marek Zarychta OpenPGP_signature Description: OpenPGP digital signature
Re: HEADS-UP: PIE enabled by default on stable/13
W dniu 24.01.2022 o 07:42, Marcin Wojtas pisze: +freebsd-stable@ niedz., 23 sty 2022 o 11:36 Marcin Wojtas napisał(a): Hi, As of 396e9f259d962 the base system binaries are now built as position-independent executable (PIE) by default, for 64-bit architectures. Thanks to that enabling ASLR can be done simply by sysctls knobs when booting the kernel. If you track stable/13 and normally build WITHOUT_CLEAN you'll need to do one initial clean build -- either run `make cleanworld` or set WITH_CLEAN=yes. The change is a pure MFC of the changes integrated to -CURRENT early 2021 and no issues are expected, but in case any problems are observed, please issue a PR and/or let me know in this thread. Best regards, Marcin Thanks for enabling this. If I understand it correctly we got some improvements mentioned here[1] and it doesn't imply that ASLR has to be enabled, especially kern.elf64.aslr.pie_enable can be still set to 0 ? [1] https://www.mail-archive.com/freebsd-current@freebsd.org/msg183605.html -- Marek Zarychta OpenPGP_signature Description: OpenPGP digital signature
Re: Make etcupdate bootstrap requirement due to previous mergemaster usage more clear in handbook
W dniu 3.12.2021 o 14:54, Jeffrey Bouquet pisze: On Fri, 3 Dec 2021 13:58:39 +0100, Miroslav Lachman <000.f...@quip.cz> wrote: On 03/12/2021 12:52, Yetoo Happy wrote: [...] Thank you Yetoo for describing your experience, bringing the topic again and provoking this discussion. Quick Start* and follow the instructions and get to step 7 and may think that even though etcupdate is different from mergemaster from the last time they used the handbook they have faith that following the instructions won't brick their system. This user will instead find that faith in general is just a very complex facade for the pain and suffering of not following *24.5.6.1 Merging Configuration Files* because the user doesn't know that step exists or relevant to the current step and ends up unknowingly having etcupdate append "<<<< yours ... >>>>> new" to the top of the user's very important configuration files that they didn't expect the program to actually modify that way when they resolved differences nor could they predict easily because the diff format is so unintuitive and different from mergemaster. Now unable to login or boot into single user mode because redirections instead of the actual configuration is parsed the user goes to the handbook to find out what might have happened and scrolls down to find *24.5.6.1 Merging Configuration Files* is under *24.5.6. [...] That's why I think etcupdate is not so intuitive as tool like this should be and etcupdate is extremely dangerous because it intentionally breaks syntax of files vital to have system up and running. If anything goes wrong with mergemaster automatic process then your have configuration not updated which is almost always fine to boot the system and fix it. But after etcupdate? Much worse... I maintain about 30 machines for 2 decades and had problems with etcupdate many times. I had ti use mergemaster as fall back many times. Mainly because of etcupdate said "Reference tree to diff against unavailable" or "No previous tree to compare against, a sane comparison is not possible.". And sometimes because etcupdate cannot automatically update many files in /etc/rc.d and manual merging of a lot of files with "<<<< >>>>" is realy painful while with mergemaster only simple keyboard shortcuts will solve it. All of this must be very stressful for beginners. So beside the update of documentation I really would like to see some changes to etcupdate workflow where files are modified in temporary location and moved to destination only if they do not contain any syntax breaking changes like <<<<, , >>>>. Kind regards Miroslav Lachman Agree. I fell back to mergemaster this Nov on 13-stable when the /var files pertaining to etcupdate were all missing current /etc data, and no study of man etcupdate was clear enough to rectify such a scenario, and suspect my initial use of etcupdate will or may require a planned reinstall, not having had to do so since Jan 2004 iirc, [ vs failed hard disk migrations ] and I am just hoping mergemaster stays in /usr/src and updated So do I. for system changes, even if moved to 'tools' or something, since its use seems intuitive and much less of a black box. Also, /usr/src/UPDATING still at the bottom emphasizes mergemaster still. Some people are pushing toward etcupdate(8) for the automation and 3-way merge support, but updating old STABLE with this tool could be really stressful and time-consuming challenge. How would one for example find old sources to perform "etcupdate extract" ? From my experience etcupdate(8) is only useful for updating RELEASEs or frequently updated CURRENT. The power of sdiff(1) way merge giving full control over the update process is the real strength of cursed mergemaster(8). Maybe it's a barrier for people not familiar with vi(1) and requires more time per update, but so far never failed me. The missing $FreeBSD ...$ IDs can be regenerated in local git repo with smudge filters. Generating locally these IDs for the specific set of files which mergemaster(8) operates on doesn't slow down the repository and shouldn't be considered as argument for deprecation and removal of mergemaster(8). I tried to use etcupdate(8) for STABLE a few times, but the ricochet shot my foot once or twice, so stepped back. I still maintain what I have written earlier, that a well-worn hammer could be in some cases better than a nailgun. Biased, 20+ years FreeBSD and mergemaster(8) user, -- Marek Zarychta OpenPGP_signature Description: OpenPGP digital signature
Re: Deprecating smbfs(5) and removing it before FreeBSD 14
W dniu 29.10.2021 o 08:29, Andrea Venturoli pisze:
On 10/29/21 00:47, Tomoaki AOKI wrote:
But possibly we need to delete current smbfs code from base and switch
to ports (sysutils/*?) if it require some code having incompatible
license for base.
+1 for removing smbfs(5) from the base and eventually moving it to the
ports tree. I know some people are still using it with a bit of duct
tape and baling twine to workaround SMBv{2,3) incompatibility.
With SMBv1 support, only our smbfs(5) became useless a few years ago.
Unfortunately, there is no replacement in the ports tree. To mount SMB
shares for Nextcloud the port net/pecl-smbclient can be used, but
definitely deploying Nextcloud to mount only SMB shares is overkill.
OTOH having a port is not in any way worse as having a broken piece of
base.
It sounds reasonable. Moreover, the story of net/wireguard-kmod has
proven that moving some modules into ports, where the software
development is done in a more flexible way, can be beneficial for both:
the developers and the community.
My opinion is only the opinion of the FreeBSD user, but I believe that
sometimes the feedback from the userbase is important, especially that a
few months I was told by one of the younger *NIX admins that our
(FreeBSD) community is the best and he is willing to make a transition
of some services to FreeBSD as soon as he gets permission from the
management.
With kind regards,
--
Marek Zarychta
Re: [HEADSUP] making /bin/sh the default shell for root
W dniu 22.09.2021 o 19:46, Warner Losh pisze: > On Wed, Sep 22, 2021 at 9:35 AM John Baldwin wrote: > >> On 9/22/21 1:36 AM, Baptiste Daroussin wrote: >>> Hello, >>> >>> TL;DR: this is not a proposal to deorbit csh from base!!! >>> >>> For years now, csh is the default root shell for FreeBSD, csh can be >> confusing >>> as a default shell for many as all other unix like settled on a bourne >> shell >>> compatible interactive shell: zsh, bash, or variant of ksh. >>> >>> Recently our sh(1) has receive update to make it more user friendly in >>> interactive mode: >>> * command completion (thanks pstef@) >>> * improvement in the emacs mode, to make it behave by default like other >> shells >>> * improvement in the vi mode (in particular the vi edit to respect >> $EDITOR) >>> * support for history as described by POSIX. >>> >>> This makes it a usable shell by default, which is why I would like to >> propose to >>> make it the default shell for root starting FreeBSD 14.0-RELEASE (not >> MFCed) >>> >>> If no strong arguments has been raised until October 15th, I will make >> this >>> proposal happen. >>> >>> Again just in case: THIS IS NOT A PROPOSAL TO REMOVE CSH FROM BASE! >> >> I think this is fine. I would also be fine with either removing 'toor' >> from the >> default password file or just leaving it as-is for POLA. (I would probably >> prefer removing it outright.) >> > > I think this is also fine. I also think we should remove toor from the > default > password file for one fewer attack surfaces. I strongly prefer this. Users > that want toor can add it to their system and/or provisioning scripts. > > Warner > I am curious which attacks you are referring to since I have never heard of attacks on toor account. I have seen a lot of malware attacking root, admin, nobody, and other accounts, but never toor. TBH toor might be handy as a backdoor account if you are familiar with FreeBSD enough to take advantage of it. It can also act as an account of last resort when someone breaks into your system and changes root password, wipes ssh keys etc, so it cuts both ways, not even mentioning POLA. The transition from csh to sh as a default root's shell will probably save some CPU cycles for people using Chef, Ansible, etc thus pushing FreeBSD toward green computing. Sysadmins bound to csh will be fine until it remains in the base system and chsh works. I shouldn't probably post here since I am only a voice from the userbase but can't help doing so. Kind regards, -- Marek Zarychta OpenPGP_signature Description: OpenPGP digital signature
Re: [HEADSUP] making /bin/sh the default shell for root
W dniu 22.09.2021 o 10:36, Baptiste Daroussin pisze: > Hello, > > TL;DR: this is not a proposal to deorbit csh from base!!! > > For years now, csh is the default root shell for FreeBSD, csh can be confusing > as a default shell for many as all other unix like settled on a bourne shell > compatible interactive shell: zsh, bash, or variant of ksh. > > Recently our sh(1) has receive update to make it more user friendly in > interactive mode: > * command completion (thanks pstef@) > * improvement in the emacs mode, to make it behave by default like other > shells > * improvement in the vi mode (in particular the vi edit to respect $EDITOR) > * support for history as described by POSIX. > > This makes it a usable shell by default, which is why I would like to propose > to > make it the default shell for root starting FreeBSD 14.0-RELEASE (not MFCed) > > If no strong arguments has been raised until October 15th, I will make this > proposal happen. > > Again just in case: THIS IS NOT A PROPOSAL TO REMOVE CSH FROM BASE! > > Best regards, > Baptiste > Is /bin/csh going to become default toor's default shell since then? -- Marek Zarychta OpenPGP_signature Description: OpenPGP digital signature
htcp is not NEWRENO:newreno
Dear subscribers and devs, I am running CURRENT with RACK[1] and HTCP[2] and recently get kernel message buffer messages like this one: cc_algo:htcp is not NEWRENO:newreno Should I be worried about this assertion? [1] net.inet.tcp.functions_default=rack [2] net.inet.tcp.cc.algorithm=htcp -- Marek Zarychta OpenPGP_signature Description: OpenPGP digital signature
Re: choosing different sound input and output devices
W dniu 21.04.2021 o 14:11, Hans Petter Selasky pisze: On 4/21/21 1:42 PM, Marek Zarychta wrote: Dear subscribers, I tried to deploy the Chromium browser run on FreeBSD CURRENT to work with Microsoft Teams and it almost works fine except for audio settings. To use USB microphone I have changed sysctl hw.snd.default_unit and was able to use my microphone, but it broke the playback. Is it possible to use different audio input and output devices ? Any clues, especially with regard to www/chromium will be appreciated. Perhaps the list I am posting this question on was not carefully chosen, but haven't found any sound/audio specific mailing lists. With kind regards, Hi, Virtual OSS from ports can do this for you. Now also via the command line tool virtual_oss_cmd See: https://wiki.freebsd.org/Sound Thank you for the clue. I should have put more effort into finding this on FreeBSD Wiki pages. With Virtual OSS (audio/virtual_oss) installed and configured teleconferencing on Microsoft Teams platform works fine with Chromium native FreeBSD package (www/chromium) installed - as far as I have tested it. -- Marek Zarychta ___ 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"
choosing different sound input and output devices
Dear subscribers, I tried to deploy the Chromium browser run on FreeBSD CURRENT to work with Microsoft Teams and it almost works fine except for audio settings. To use USB microphone I have changed sysctl hw.snd.default_unit and was able to use my microphone, but it broke the playback. Is it possible to use different audio input and output devices ? Any clues, especially with regard to www/chromium will be appreciated. Perhaps the list I am posting this question on was not carefully chosen, but haven't found any sound/audio specific mailing lists. With kind regards, -- Marek Zarychta ___ 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: btxld not found
W dniu 29.01.2020 o 16:35, Nick Hibma pisze:
>>
>>>> Could anyone explain to me what I am doing wrong? make installworld fails
>>>> each time with the following error
>>>>
>>>> ===> stand/i386/libi386 (install)
>>>> ===> stand/i386/loader_4th (install)
>>>> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym
>>>> btxld -v -f aout -e 0x20 -o loader_4th -l
>>>> /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr -b
>>>> /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin
>>>> make[6]: exec(btxld) failed (No such file or directory)
>>>> *** Error code 1
>>>>
>>>> This is with source of last week. I had this problem before (from old
>>>> sources) and fixed it by specifying the full path to btxld in the
>>>> stand/i386/*/Makefile.
>>>
>>> Yes, this is most likely your clock(s) being off. At installworld time,
>>> it should *not* start rebuilding your loader.
>>>
>>> Usually this happens if you build on one machine, and install on
>>> another, while the install machine's time is behind the build machine's
>>> time. But it can also happens on one machine, for instance if you
>>> start in single user mode, and the clock is not yet synchronized.
>>>
>>> -Dimitry
>>>
>> Dimitry,
>>
>> My VirtualBox VMs do have a tendency to lag when I am not using them for a
>> while. I've adjusted time and started ntpd. In the past that would not fix
>> the time lag permanently.
>>
>> I'll do a fresh buildworld and see whether that completes.
>>
>> Nick
>
> Nope, make buildworld && make installworld results in, so I guess the job
> ordering suggestion is a better one (VM with 2 processors on a variably
> loaded laptop, no -j option, time accurate):
>
> install -o root -g wheel -m 444 mbr /boot/mbr
> ===> stand/i386/pmbr (install)
> install -o root -g wheel -m 444 pmbr /boot/pmbr
> ===> stand/i386/boot0 (install)
> install -o root -g wheel -m 444 boot0 /boot/boot0
> ===> stand/i386/boot0sio (install)
> install -o root -g wheel -m 444 boot0 /boot/boot0sio
> ===> stand/i386/btx (install)
> ===> stand/i386/btx/btx (install)
> ===> stand/i386/btx/btxldr (install)
> ===> stand/i386/btx/lib (install)
> ===> stand/i386/boot2 (install)
> objcopy -S -O binary boot1.out boot1
> objcopy -S -O binary boot2.out boot2.bin
> btxld -v -E 0x2000 -f bin -b
> /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx -l boot2.ldr -o boot2.ld
> -P 1 boot2.bin
> make[6]: exec(btxld) failed (No such file or directory)
> *** Error code 1
>
> ...
>
> {e}nick@fimkjecurrent:/usr/src % sudo find / -name btxld -type f -ls
> 1908308 48 -r-xr-xr-x1 root wheel
> 22988 Jan 27 23:37 /usr/sbin/btxld
> 3441268 52 -rwxr-xr-x1 root wheel
> 25816 Jan 29 16:09
> /usr/obj/usr/src/i386.i386/usr.sbin/btxld/btxld
> {e}nick@fimkjecurrent:/usr/src % date
> Wed Jan 29 16:30:21 CET 2020
> {e}nick@fimkjecurrent:/usr/src % make -dA
> ...
> Global:MFLAGS = -d A
> job_pipe -1 -1, maxjobs 1, tokens 1, compat 1
> ...
I am still running into this occasionally on amd64 with 13.0-STABLE,
especially while updating from src and obj directories exported over
NFS, but it happens sometimes also for locally mounted src and obj.
===> stand/i386/mbr (install)
install -o root -g wheel -m 444 mbr /boot/mbr
===> stand/i386/pmbr (install)
install -o root -g wheel -m 444 pmbr /boot/pmbr
===> stand/i386/boot0 (install)
install -o root -g wheel -m 444 boot0 /boot/boot0
===> stand/i386/boot0sio (install)
install -o root -g wheel -m 444 boot0 /boot/boot0sio
===> stand/i386/boot2 (install)
objcopy -S -O binary boot2.out boot2.bin
objcopy: open boot2.bin failed: Read-only file system
*** Error code 1
Running make buildworld with only one job solves the issue. I am
building with WITH_META_MODE=yes, so I work around this by subsequent
builds:
make -sj32 buildworld && make -s buildworld
--
Marek Zarychta
OpenPGP_signature
Description: OpenPGP digital signature
Re: DRM and Radeon
W dniu 26.01.2021 o 10:15, Toomas Soome pisze: On 26. Jan 2021, at 10:18, Marek Zarychta <mailto:zarych...@plan-b.pwste.edu.pl>> wrote: W dniu 26.01.2021 o 08:58, Graham Perrin pisze: On 26/01/2021 07:02, Alexey Dokuchaev wrote: > Re: loading drm crashes system > … There are known issues with Radeon cards, they were quite well > supported a year ago, then something got broken. I've promised to > bisect this and find the cause, but there were several > syscall-related changes in -CURRENT though the course of the last > year, so bisecting just the kernel is not enough (machine won't get > to login prompt if the userland does not match), which cripples the > process. > > I still intend to take this quest, just not sure when. :( > > ./danfe Any cards in particular? <https://old.reddit.com/r/freebsd/comments/kyoxmc/freebsd_quarterly_status_report_fourth_quarter/gjiw3y3/ <https://old.reddit.com/r/freebsd/comments/kyoxmc/freebsd_quarterly_status_report_fourth_quarter/gjiw3y3/>> – whilst I didn't mention Radeon there, for me it _was_ the Radeon story that seemed to improve a few months ago. <https://bsd-hardware.info/?id=pci:1002-6841-103c-17a9 <https://bsd-hardware.info/?id=pci:1002-6841-103c-17a9>> AMD Thames [Radeon HD 7550M/7570M/7650M] For example old RS880 [Radeon HD 4200]. After deprecation of graphics/drm-fbsd12.0-kmod I found that it is still supported fine on 12-STABLE with legacy /boot/kernel/radeonkms.ko from the base. While trying the driver from graphics/drm-fbsd12.0-kmod I was not able to use this card with gdm, only startx or x11/slim worked. On 13-ALPHA this card still works fine with deprecated graphics/drm-legacy-kmod. Does X11 cliegdm start X in specific way? I mean, afaik, gdm is nt as any other, so the question would be, how does gdm get Xorg started, what is different compared to startx etc? Might it be about gdm user permissions to access drm devices? my 2cents.. toomas Thanks for the clue, I added user gdm to the group video, but nothing changed. Gdm starts, after some delay, but there is no visible username/ password prompt or it's beyond the viewable area, on the other hand, the viewable area seems to fit the screen correctly. To start gdm I have to wait a while until something happens with the resolution of text in the console. I have to mention that with this driver, the vty console resolution changes a while after loading the driver and starting all services (usually it lasts one minute or less after services startup) and after this time the text on vty can be seen in a kind of window covering: on first monitor 50% of the screen in left upper corner and on the second monitor, the viewable area of text console exceeds screen dimensions, but on both the text in console looks blurry. Please don't get it wrong it's nether EFI nor boot loader problem since this is an old machine with BIOS only and I am booting FreeBSD on this with GRUB2 (booting, not chainloading). With /boot/kernel/radeonkms.ko or radeonks.ko from deprecated graphics/drm-legacy-kmod everything looks fine on vty on both monitors and login and password prompt for gdm appears correctly. So this is not only gdm issue. I have tested drm-current-kmod with fresh 14-CURRENT sources and indeed, it panicked for me. I have installed deprecated drm-legacy-kmod and it works fine with this old HW and 14-CURRENT. While writing this post I am using: FreeBSD 14.0-CURRENT #3 main-c256281-g25cdacf79b0 drm-legacy-kmod-g20200825 gpu-firmware-kmod-g20201213 -- Marek Zarychta ___ 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: DRM and Radeon
W dniu 26.01.2021 o 08:58, Graham Perrin pisze: On 26/01/2021 07:02, Alexey Dokuchaev wrote: > Re: loading drm crashes system > … There are known issues with Radeon cards, they were quite well > supported a year ago, then something got broken. I've promised to > bisect this and find the cause, but there were several > syscall-related changes in -CURRENT though the course of the last > year, so bisecting just the kernel is not enough (machine won't get > to login prompt if the userland does not match), which cripples the > process. > > I still intend to take this quest, just not sure when. :( > > ./danfe Any cards in particular? <https://old.reddit.com/r/freebsd/comments/kyoxmc/freebsd_quarterly_status_report_fourth_quarter/gjiw3y3/> – whilst I didn't mention Radeon there, for me it _was_ the Radeon story that seemed to improve a few months ago. <https://bsd-hardware.info/?id=pci:1002-6841-103c-17a9> AMD Thames [Radeon HD 7550M/7570M/7650M] For example old RS880 [Radeon HD 4200]. After deprecation of graphics/drm-fbsd12.0-kmod I found that it is still supported fine on 12-STABLE with legacy /boot/kernel/radeonkms.ko from the base. While trying the driver from graphics/drm-fbsd12.0-kmod I was not able to use this card with gdm, only startx or x11/slim worked. On 13-ALPHA this card still works fine with deprecated graphics/drm-legacy-kmod. -- Marek Zarychta ___ 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: loading drm crashes system
W dniu 26.01.2021 o 08:02, Alexey Dokuchaev pisze: On Mon, Jan 25, 2021 at 10:21:16PM -0500, Robert Huff wrote: Niclas Zeising asks: When did it stop working? September ... I _think_. Yeah, that sounds about right. There are known issues with Radeon cards, they were quite well supported a year ago, then something got broken. I've promised to bisect this and find the cause, but there were several syscall-related changes in -CURRENT though the course of the last year, so bisecting just the kernel is not enough (machine won't get to login prompt if the userland does not match), which cripples the process. I still intend to take this quest, just not sure when. :( ./danfe ___ 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" TBH I have backed up deprecated port graphics/drm-legacy-kmod and use it on 13-ALPHA. The port graphics/drm-current-kmod was unusable (console resolution, flaky gdm start etc.), tough no panics were observed. One should be still able to build graphics/drm-legacy-kmod on 14-CURRENT for some time till the issue gets resolved. -- Marek Zarychta ___ 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: CURRENT, usr/src on git, howto "mergemaster"?
W dniu 04.01.2021 o 20:27, Enji Cooper pisze: > >> On Jan 4, 2021, at 11:15 AM, Jeffrey Bouquet >> wrote: > > … > >>> Dear Enji, >>> >>> to satisfy your curiosity: Yes, I have tried etcupdate(8) a few times >>> over years. It works fine, but I don't like the idea of editing >>> conflicted files. >>> >>> I won't complain about etcupdate(8), but please leave mergemaster(8) >>> as is. I believe we need both: solid, fast black boxes driven it auto >>> mode and fragile tools in the base. mergemaser is rather not a potential >>> security hole in the system. > > Hi Jeffrey and Marek, > Could you please be more specific in your concerns? I don’t mind > helping resolve them, but unfortunately the concerns noted above are a bit > nebulous. Dear Enji, it's probably high time to stop escalating this thread. Some people like the way in which mergemaster copes with updates, some people like etcupdate. With Git clean and smudge filters applied on local repo and $FreeBSD$ IDs regenerated, mergemaster still works great and is more ergonomic in use for at least two people. Kind regards, -- Marek Zarychta OpenPGP_signature Description: OpenPGP digital signature
Re: CURRENT, usr/src on git, howto "mergemaster"?
W dniu 04.01.2021 o 19:54, Enji Cooper pisze: > >> On Jan 4, 2021, at 10:49 AM, Marek Zarychta >> wrote: > > … > >> Terrible idea IMHO, but I am only the weak voice from the userbase. >> >> It's like deprecating old, well-worn hammer in the favour of the nail >> gun. Why not deprecate biff(1), pom(6), nvi(1) etc.? > > Marek, > I’m curious: have you used etcupdate before instead of mergemaster? If > so when? If you ran into issues (UX as well as functional): could you please > report them on bugs.freebsd.org <http://bugs.freebsd.org/> ? > etcupdate is a less fragile tool that’s broken my systems less when > compared with mergemaster. Dear Enji, to satisfy your curiosity: Yes, I have tried etcupdate(8) a few times over years. It works fine, but I don't like the idea of editing conflicted files. I won't complain about etcupdate(8), but please leave mergemaster(8) as is. I believe we need both: solid, fast black boxes driven it auto mode and fragile tools in the base. mergemaser is rather not a potential security hole in the system. With kind regards, -- Marek Zarychta OpenPGP_signature Description: OpenPGP digital signature
Re: CURRENT, usr/src on git, howto "mergemaster"?
W dniu 04.01.2021 o 19:30, Enji Cooper pisze: > >> On Jan 4, 2021, at 10:19, Warner Losh wrote: >> >> On Mon, Jan 4, 2021 at 9:36 AM Marek Zarychta >> >> wrote: >> >>> W dniu 04.01.2021 o 17:14, Warner Losh pisze: >>> >>>> etcupdate does a full three merge, while mergemaster fakes it in a number >>>> of ways. etcupdate directly keeps track of the resolutions, which is why >>>> $FreeBSD$ doesn't matter so much to it. >>>> >>>> mergemaster is deprecated and will likely be removed from the system >>>> because it has no maintainer and is quite a bit harder to keep working >>> than >>>> etcupdate. >>>> >>> >>> Please don't sacrifice mergemaster(8) for the successful transition to >>> Git. The amount of feedback on the mailing list should give the core@ >>> some idea of how widely mergemasted is still deployed. Some people just >>> like to merge files side by side with pressing keys. Why innocent >>> mergemaster(8) has to be a victim of switching to Git? Sacrifice please >>> svnlite(1) - it became completely useless for HEAD and upcoming stable >>> branches. >>> >> >> mergemaster has been on its way out since well before the switch to git. >> It's been disfavored for at least a decade and basically unmaintained in >> the base for maybe last 5 years. Apart from major breakage, only doc >> changes have happened in that time. > > Adding to this: it has no maintainer, it’s less featureful, and it lacks > tests. Once I switched to etcupdate a few years back I never looked back at > mergemaster. > > I honestly think it should be deprecated in 13.x and removed in 14.x. It’s > been several major releases since it’s been unofficially deprecated. > Terrible idea IMHO, but I am only the weak voice from the userbase. It's like deprecating old, well-worn hammer in the favour of the nail gun. Why not deprecate biff(1), pom(6), nvi(1) etc.? Kind regards, -- Marek Zarychta OpenPGP_signature Description: OpenPGP digital signature
Re: CURRENT, usr/src on git, howto "mergemaster"?
W dniu 04.01.2021 o 17:14, Warner Losh pisze: > etcupdate does a full three merge, while mergemaster fakes it in a number > of ways. etcupdate directly keeps track of the resolutions, which is why > $FreeBSD$ doesn't matter so much to it. > > mergemaster is deprecated and will likely be removed from the system > because it has no maintainer and is quite a bit harder to keep working than > etcupdate. > Please don't sacrifice mergemaster(8) for the successful transition to Git. The amount of feedback on the mailing list should give the core@ some idea of how widely mergemasted is still deployed. Some people just like to merge files side by side with pressing keys. Why innocent mergemaster(8) has to be a victim of switching to Git? Sacrifice please svnlite(1) - it became completely useless for HEAD and upcoming stable branches. Kind regards, -- Marek Zarychta OpenPGP_signature Description: OpenPGP digital signature
Re: CURRENT, usr/src on git, howto "mergemaster"?
W dniu 04.01.2021 o 14:32, David Wolfskill pisze: > On Mon, Jan 04, 2021 at 05:22:10AM -0800, Jeffrey Bouquet wrote: >> ... >> after checking out stable/12 with git, here a >> # cd /usr/src/usr.sbin/mergemaster >> # sh ./mergemaster.sh -piPcv >> >> and then answering 'l' for left for most merges >> it seems to have sufficed. >> This was before installworld. > > Yes. However, the salient issue for me is that with the Ids in the > file, on subsequent invocations, mergemaster would leave the file as-is > unless the Id changed. This wass usually on the order of a few times > per year for a given file. > > Now that the Ids are no longer present, mergemaster will now prompt on > every invocation for each file locally modified on each machine. > > This amounts to about a dozen opportunities to screw things up for each > machine daily for me; that's just not ... reasonable. > > So far, etcupdate seems to be working out OK for me (as in "not > prompting for each of the files in question on each invocation"). > >> In case that helps. >> I keep that command parameter in /etc/motd for each time around lookup. >> $FreeBSD$ tags can be regenerated locally with Git clean and smudge filters[1] applied on local git repository. This helps to keep the track of files updated by mergemaster(8) or etcupdate(8). The filters should be applied to only the files important for mergemagster. Applying filters to the whole repository degrades performance. [1]https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes Regards, -- Marek Zarychta OpenPGP_signature Description: OpenPGP digital signature
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
W dniu 17.12.2020 o 01:46, Warner Losh pisze: > Greetings, > > The FreeBSD project will be moving it's source repo from subversion to git > starting this this weekend. The docs repo was moved 2 weeks ago. The ports > repo will move at the end of March, 2021 due to timing issues. > > The short version is that we're switching the version control we're using. > This switch will preserve much of the current FreeBSD development workflow. > After the switch, the subversion repo will become almost read-only. All > future work will be done in git, however as a transition aide we'll be > replaying the MFCs to stable/11, stable/12 and the related releng branches > for the life of those branches. > > For more detailed information, please see > https://github.com/bsdimp/freebsd-git-docs/ for the current documentation. > > Please see https://wiki.freebsd.org/git for the latest detailed schedule > (please note that this schedule is subject to change). > > 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" > Will the project utilize gitatributes(5) to support ident as $Id:$ in git repository? In file header, we have now only $FreeBSD$ since svn tags disappeared after the transition. Adding ident tags to certain files which are updated by mergemaster(8) or etcupdated(8) would be appreciated. Best regards, -- Marek Zarychta ___ 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: clang build buggy code with certain CPUTYPE setting
On 28.09.2020 10:59, Andriy Gapon wrote: On 26/09/2020 22:55, Marek Zarychta wrote: Thank you for the information and for the fix. Sadly I must admit it doesn't work for me. I have tried two builds with fresh sources today to be certain and it looks like the bug is still present on FreeBSD 13-CURRENT r366186. Either the upstream fixed it only partially or it is another bug. As a workaround, I will build worlds without CPUTYPE?=amdfam10 for a while. I hope the problem will be resolved before clang 11 is MFCed to 12-STABLE. Can you disassemble the faulting instruction in the core dump? Can you provide full CPU ID / features information from dmesg? I tried to reproduce this for debugging purposes, but I am not able to. Either my builds were somehow polluted, though obj directory was cleaned before each build, or not patched LLVM was bootstrapping itself in a wrong way despite updated sources. Anyway the issue has gone and it is possible to run world built with CPUTYPE?=amdfam10 using r366241 as starting point. Thank you guys for your assistance, patience and work which gives us the ability to use well maintained, rock-stable and modern OS. -- Marek Zarychta OpenPGP_signature Description: OpenPGP digital signature
Re: clang build buggy code with certain CPUTYPE setting
On Sat, Sep 26, 2020 at 05:48:33PM +0200, Dimitry Andric wrote: > On 26 Sep 2020, at 13:40, Marek Zarychta > wrote: > > > > I have done a few builds of CURRENT in a row one or two weeks apart. The > > builds with CPUTYPE?=amdfam10 set produce buggy code, for example while > > running mergemaster I get this error: > > > > PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and > > include the crash backtrace, preprocessed source, and associated run > > script. > > Stack dump: > > 0. Program arguments: cc --version > > #0 0x040ede6e (/usr/bin/cc+0x40ede6e) > > #1 0x040ec0e5 (/usr/bin/cc+0x40ec0e5) > > #2 0x040ee550 (/usr/bin/cc+0x40ee550) > > #3 0x00080553babe (/lib/libthr.so.3+0x19abe) > > Illegal instruction > > make: "/usr/src/share/mk/bsd.compiler.mk" line 181: Unable to determine > > compiler type for CC=cc. Consider setting COMPILER_TYPE. > > > > The 13-CURRENT world built without CPUTYPE runs fine, the same for > > recent 12.2-STABLE world build with CPUTYPE?=amdfam10 on the same > > machine. > > Hi Marek, > > In r365507 (on 2020-09-09) I committed a fix for amdfam10: > > > r365507 | dim | 2020-09-09 20:11:04 +0200 (Wed, 09 Sep 2020) | 17 lines > > Merge commit e6bb4c8e7 from llvm git (by Craig Topper): > > [X86] SSE4_A should only imply SSE3 not SSSE3 in the frontend. > > SSE4_1 and SSE4_2 due imply SSSE3. So I guess I got confused when > switching the code to being table based in D83273. > > Fixes PR47464 > > This should fix builds with -march=amdfam10 emitting SSSE3 instructions > such as pshufb, which lead to programs crashing with SIGILL on such > processors. > > Reported by:avg > MFC after: 6 weeks > X-MFC-With: r364284 > > So I expect that the "Illegal instruction" you are seeing is an SSSE3 > instruction. If this happens with your base compiler, please get a > known-good copy from one of the snapshot images. Ensure your /usr/src is > r365507 or later, then do a full buildworld and reinstall. > > -Dimitry > Dear Dimitry, Thank you for the information and for the fix. Sadly I must admit it doesn't work for me. I have tried two builds with fresh sources today to be certain and it looks like the bug is still present on FreeBSD 13-CURRENT r366186. Either the upstream fixed it only partially or it is another bug. As a workaround, I will build worlds without CPUTYPE?=amdfam10 for a while. I hope the problem will be resolved before clang 11 is MFCed to 12-STABLE. -- Marek Zarychta signature.asc Description: PGP signature
clang build buggy code with certain CPUTYPE setting
Dear list, I have done a few builds of CURRENT in a row one or two weeks apart. The builds with CPUTYPE?=amdfam10 set produce buggy code, for example while running mergemaster I get this error: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: cc --version #0 0x040ede6e (/usr/bin/cc+0x40ede6e) #1 0x040ec0e5 (/usr/bin/cc+0x40ec0e5) #2 0x040ee550 (/usr/bin/cc+0x40ee550) #3 0x00080553babe (/lib/libthr.so.3+0x19abe) Illegal instruction make: "/usr/src/share/mk/bsd.compiler.mk" line 181: Unable to determine compiler type for CC=cc. Consider setting COMPILER_TYPE. The 13-CURRENT world built without CPUTYPE runs fine, the same for recent 12.2-STABLE world build with CPUTYPE?=amdfam10 on the same machine. Any tips would be appreciated, -- Marek Zarychta signature.asc Description: PGP signature
Re: r360902 breaks VLAN interface on if_em (82579LM)
W dniu 27.05.2020 o 09:19, Martin MATO pisze: > I was about to fill a bug report about this. > My network card in that case is a 82574L intel based adapter > As a workaround; bringing down and up the link by ifconfig(8) (and not > by unplug/replug the ethernet cable) > restore the connectivity for the vlan interface (in my case it is an isp > dhcp-based authentication) > and also i narrowed down when the problem appears, and it is at this > revision (r360902) > Do you have filled a bug report? > Please take a look at my comment 10 to PR 240818, but perhaps new bug has to reported. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818 -- Marek Zarychta signature.asc Description: OpenPGP digital signature
Re: btxld not found
W dniu 28.01.2020 o 23:22, Kyle Evans pisze:
> On Tue, Jan 28, 2020 at 3:28 PM Kyle Evans wrote:
>>
>> On Tue, Jan 28, 2020 at 2:15 PM Mark Millard wrote:
>>>
>>> Marek Zarychta zarychtam at plan-b.pwste.edu.pl wrote on
>>> Tue Jan 28 19:33:45 UTC 2020 :
>>>
>>>> W dniu 28.01.2020 o 19:11, Dimitry Andric pisze:
>>>>> On 28 Jan 2020, at 12:36, Nick Hibma wrote:
>>>>>>
>>>>>> Could anyone explain to me what I am doing wrong? make installworld
>>>>>> fails each time with the following error
>>>>>>
>>>>>> ===> stand/i386/libi386 (install)
>>>>>> ===> stand/i386/loader_4th (install)
>>>>>> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym
>>>>>> btxld -v -f aout -e 0x20 -o loader_4th -l
>>>>>> /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr -b
>>>>>> /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin
>>>>>> make[6]: exec(btxld) failed (No such file or directory)
>>>>>> *** Error code 1
>>>>>>
>>>>>> This is with source of last week. I had this problem before (from old
>>>>>> sources) and fixed it by specifying the full path to btxld in the
>>>>>> stand/i386/*/Makefile.
>>>>>
>>>>> Yes, this is most likely your clock(s) being off. At installworld time,
>>>>> it should *not* start rebuilding your loader.
>>>>>
>>>>> Usually this happens if you build on one machine, and install on
>>>>> another, while the install machine's time is behind the build machine's
>>>>> time. But it can also happens on one machine, for instance if you
>>>>> start in single user mode, and the clock is not yet synchronized.
>>>>>
>>>>> -Dimitry
>>>>>
>>>>
>>>> I build and install on the same machine, WITH_META_MODE=yes
>>> . . .
>>>
>>> Same here on a ThreadRipper 1950X: a self hosted build and
>>> install gets the issue at install time. WITH_META_MODE in use.
>>>
>>> Never started in single user mode. Also happens for targeting a
>>> local directory tree in the install, instead of updating the
>>> live system. (A directory tree used later with poudriere.)
>>>
>>> https://lists.freebsd.org/pipermail/freebsd-toolchain/2019-December/005130.html
>>>
>>> has some timestamps that I observed. btxld.full was about 27
>>> seconds later in the file system than btxld.meta, btxld.debug,
>>> and such (until I rebuilt).
>>>
>>> Looks to me more like multiple parallel builds that stomp on
>>> each other.
>>>
>>
>> I suspect y'all want something like the following:
>>
>
> Sorry, that patch is clearly wrong- here's take two. A lot of these
> have dependencies on btxldr that aren't formally described in the
> targets, so I missed... a lot. New version just builds btx first gated
> behind a .WAIT then parallel the rest.
>
> diff --git a/stand/i386/Makefile b/stand/i386/Makefile
> index a9d402acf60..24255eefabf 100644
> --- a/stand/i386/Makefile
> +++ b/stand/i386/Makefile
> @@ -4,7 +4,10 @@ NO_OBJ=t
>
> .include
>
> -SUBDIR.yes=mbr pmbr boot0 boot0sio btx boot2 cdboot gptboot \
> +# Almost everything else here relies on btxldr, so we must make sure it's
> built
> +# before everything else proceeds so we don't end up building against a stale
> +# btxldr and ending up with a build-during-install scenario.
> +SUBDIR.yes=btx .WAIT mbr pmbr boot0 boot0sio boot2 cdboot gptboot \
> isoboot libi386
>
> SUBDIR.${MK_LOADER_FIREWIRE}+= libfirewire
> ___
> 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"
>
I have not correctly applied the patch. I am sorry for the confusion.
The world builds fine with this second patch. I am not able to reproduce
the original error anymore (buildworld and installworld after that, both
go fine even with unpatched stand/i386/Makefile b/stand/i386/Makefile).
--
Marek Zarychta
signature.asc
Description: OpenPGP digital signature
Re: btxld not found
W dniu 28.01.2020 o 22:28, Kyle Evans pisze:
> On Tue, Jan 28, 2020 at 2:15 PM Mark Millard wrote:
>>
>> Marek Zarychta zarychtam at plan-b.pwste.edu.pl wrote on
>> Tue Jan 28 19:33:45 UTC 2020 :
>>
>>> W dniu 28.01.2020 o 19:11, Dimitry Andric pisze:
>>>> On 28 Jan 2020, at 12:36, Nick Hibma wrote:
>>>>>
>>>>> Could anyone explain to me what I am doing wrong? make installworld fails
>>>>> each time with the following error
>>>>>
>>>>> ===> stand/i386/libi386 (install)
>>>>> ===> stand/i386/loader_4th (install)
>>>>> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym
>>>>> btxld -v -f aout -e 0x20 -o loader_4th -l
>>>>> /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr -b
>>>>> /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin
>>>>> make[6]: exec(btxld) failed (No such file or directory)
>>>>> *** Error code 1
>>>>>
>>>>> This is with source of last week. I had this problem before (from old
>>>>> sources) and fixed it by specifying the full path to btxld in the
>>>>> stand/i386/*/Makefile.
>>>>
>>>> Yes, this is most likely your clock(s) being off. At installworld time,
>>>> it should *not* start rebuilding your loader.
>>>>
>>>> Usually this happens if you build on one machine, and install on
>>>> another, while the install machine's time is behind the build machine's
>>>> time. But it can also happens on one machine, for instance if you
>>>> start in single user mode, and the clock is not yet synchronized.
>>>>
>>>> -Dimitry
>>>>
>>>
>>> I build and install on the same machine, WITH_META_MODE=yes
>> . . .
>>
>> Same here on a ThreadRipper 1950X: a self hosted build and
>> install gets the issue at install time. WITH_META_MODE in use.
>>
>> Never started in single user mode. Also happens for targeting a
>> local directory tree in the install, instead of updating the
>> live system. (A directory tree used later with poudriere.)
>>
>> https://lists.freebsd.org/pipermail/freebsd-toolchain/2019-December/005130.html
>>
>> has some timestamps that I observed. btxld.full was about 27
>> seconds later in the file system than btxld.meta, btxld.debug,
>> and such (until I rebuilt).
>>
>> Looks to me more like multiple parallel builds that stomp on
>> each other.
>>
>
> I suspect y'all want something like the following:
>
> diff --git a/stand/i386/Makefile b/stand/i386/Makefile
> index a9d402acf60..5b4e34ce587 100644
> --- a/stand/i386/Makefile
> +++ b/stand/i386/Makefile
> @@ -18,4 +18,9 @@ SUBDIR.yes+= pxeldr
>
> SUBDIR.${MK_LOADER_ZFS}+= zfsboot gptzfsboot
>
> +SUBDIR_DEPEND_pxeldr= btx
> +SUBDIR_DEPEND_loader_4th= btx
> +SUBDIR_DEPEND_loader_lua= btx
> +SUBDIR_DEPEND_loader_simp= btx
> +
> .include
Thank you for taking care of this. The patch above worked and I confirm
it solves the issue for me.
I was not able to build the world with the patch you have posted later,
here is the link to build log --> https://bsd.to/jTpd
--
Marek Zarychta
signature.asc
Description: OpenPGP digital signature
Re: btxld not found
W dniu 28.01.2020 o 19:11, Dimitry Andric pisze: > On 28 Jan 2020, at 12:36, Nick Hibma wrote: >> >> Could anyone explain to me what I am doing wrong? make installworld fails >> each time with the following error >> >> ===> stand/i386/libi386 (install) >> ===> stand/i386/loader_4th (install) >> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym >> btxld -v -f aout -e 0x20 -o loader_4th -l >> /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr -b >> /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin >> make[6]: exec(btxld) failed (No such file or directory) >> *** Error code 1 >> >> This is with source of last week. I had this problem before (from old >> sources) and fixed it by specifying the full path to btxld in the >> stand/i386/*/Makefile. > > Yes, this is most likely your clock(s) being off. At installworld time, > it should *not* start rebuilding your loader. > > Usually this happens if you build on one machine, and install on > another, while the install machine's time is behind the build machine's > time. But it can also happens on one machine, for instance if you > start in single user mode, and the clock is not yet synchronized. > > -Dimitry > I build and install on the same machine, WITH_META_MODE=yes the CPU is Origin="AuthenticAMD" Id=0x100f43 Family=0x10 Model=0x4 Stepping=3, underlining filesystem is ZFS, OBJDIR is /usr/obj though it's really /usr/amdfam10obj.head mounted with nullfs. For build/install I am using still these old way commands: make -sj4 buildworld && make installworld On the same machine I am building/installing 12-STABLE world as well, but this error is only present for CURRENT. It has appeared for the first time in early October last year and remains unresolved to me. I just ignore errors on installworld since then. ===> stand/i386/btx (install) ===> stand/i386/btx/btx (install) ===> stand/i386/btx/btxldr (install) ===> stand/i386/btx/lib (install) ===> stand/i386/boot2 (install) btxld -v -E 0x2000 -f bin -b /usr/obj/usr/src/amd64.amd64/stand/i386/btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin make[6]: exec(btxld) failed (No such file or directory) *** Error code 1 -- Marek Zarychta signature.asc Description: OpenPGP digital signature
Re: btxld not found
W dniu 28.01.2020 o 12:36, Nick Hibma pisze: > Folks, > > Could anyone explain to me what I am doing wrong? make installworld fails > each time with the following error > > ===> stand/i386/libi386 (install) > ===> stand/i386/loader_4th (install) > strip -R .comment -R .note -o loader_4th.bin loader_4th.sym > btxld -v -f aout -e 0x20 -o loader_4th -l > /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr -b > /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin > make[6]: exec(btxld) failed (No such file or directory) > *** Error code 1 > > This is with source of last week. I had this problem before (from old > sources) and fixed it by specifying the full path to btxld in the > stand/i386/*/Makefile. > > Any pointers? > > Nick Hibma > n...@van-laarhoven.org > > -- Open Source: We stand on the shoulders of giants. > I am experiencing also the same issue on CURRENT for some time (a few months). Removing /usr/src and fresh checkout solved the issue for a while but it returned soon. I am not to complain here but to confirm that it happens. Best regards, -- Marek Zarychta signature.asc Description: OpenPGP digital signature
Re: ZFS with 32-bit, non-x86 kernel
On 04.10.2019 21:37, Ian Lepore wrote: > On Fri, 2019-10-04 at 13:27 -0600, Warner Losh wrote: >> On Fri, Oct 4, 2019, 1:07 PM Dennis Clarke wrote: >> >>> On 10/4/19 10:05 AM, Andriy Gapon wrote: >>>> >>>> Does anyone use ZFS with a 32-bit kernel, that is also not i386 ? >>>> If you do, could you please let me know? Along with uname -rmp output. >>>> Thank you! >>>> >>> >>> I don't know if that has even been attempted by anyone. The ZIL and ZFS >>> log comonents require substantial amounts of memory and I am not aware >>> of anyone with arm devices that have 8GB+ of memory. I have had FreeBSD >>> current on RISC-V running fairly well with ZFS however that was a purely >>> rv64imafdc architecture. >>> >> >> In the FreeBSD 10 time frame I know people were running ZFS on arm7 boards. >> Iirc, there was a long list of tweaks needed to size of the ZIL. A quick >> google didn't find it. >> >> Otoh, I looked at ZFS for NanoBSD when it first came out. I gave up because >> the 256MB boards at the time made any kind of storage traffic ran things >> out of memory. >> >> Warner >> >> >> I will watch this thread with curiosity. > > There have been several threads about using zfs on armv7 over the > years. Some of them are from 2013 and indicate little sucess. Others, > from 2015, indicate it works... > > https://lists.freebsd.org/pipermail/freebsd-arm/2015-March/010607.html > https://lists.freebsd.org/pipermail/freebsd-arm/2015-March/010649.html > > There have also been some bug reports as recently as 2017 indicating > that people are still doing this on small armv7 systems. > > -- Ian Following this thread, where Bernd Walter wrote small howto: https://lists.freebsd.org/pipermail/freebsd-arm/2019-February/019455.html I had converted root filesystem to ZFS on SD card used with RaspberryPi2, then used it with no issues running 13-CURRENT for 6 months until that old SD card got worn. -- Marek Zarychta signature.asc Description: OpenPGP digital signature
Re: Elantech touchpad (HID over I2C): any work planned?
W dniu 08.05.2019 o 18:54, Nikola Lečić pisze: > Hi, > > After buying a new Asus Zenbook 14 UX410UFR, I was unpleasantly > surprised that its touchpad (Elantech over I2C) isn't supported under > FreeBSD. > > I see that this kind of problem was discussed several times in the past: > https://lists.freebsd.org/pipermail/freebsd-current/2018-June/069704.html > https://lists.freebsd.org/pipermail/freebsd-mobile/2017-August/013617.html > https://lists.freebsd.org/pipermail/freebsd-mobile/2016-March/013370.html > https://lists.freebsd.org/pipermail/freebsd-mobile/2016-November/013577.html > > OpenBSD's imt(4) driver detects this touchpad, and it works normally. > Please find the relevant info below. > > Can someone tell us if any kind of work on porting imt(4) driver (or > writing FreeBSD's own from scratch) is planned? Or it's better to > return this laptop and buy another one? > > OpenBSD dmesg: > > May 8 15:23:29 thorium /bsd: dwiic0 at pci0 dev 21 function 0 "Intel 100 > Series I2C" rev 0x21: apic 2 int 16 > May 8 15:23:29 thorium /bsd: iic0 at dwiic0 > May 8 15:23:29 thorium /bsd: dwiic1 at pci0 dev 21 function 1 "Intel 100 > Series I2C" rev 0x21: apic 2 int 17 > May 8 15:23:29 thorium /bsd: iic1 at dwiic1 > May 8 15:23:29 thorium /bsd: ihidev0 at iic1 addr 0x15 (polling), vendor > 0x4f3 product 0x309c, ELAN1200 > May 8 15:23:29 thorium /bsd: ihidev0: 11 report ids > May 8 15:23:29 thorium /bsd: imt0 at ihidev0: clickpad, 5 contacts > May 8 15:23:29 thorium /bsd: wsmouse0 at imt0 mux 0 > May 8 15:23:29 thorium /bsd: "Intel 100 Series I2C" rev 0x21 at pci0 dev 21 > function 2 not configured > May 8 15:23:29 thorium /bsd: "Intel 100 Series MEI" rev 0x21 at pci0 dev 22 > function 0 not configured > > Linux Xorg.0.log: > > [22.259] (II) config/udev: Adding input device ELAN1200:00 04F3:309C > Touchpad (/dev/input/event9) > [22.259] (**) ELAN1200:00 04F3:309C Touchpad: Applying InputClass > "libinput touchpad catchall" > [22.259] (II) Using input driver 'libinput' for 'ELAN1200:00 04F3:309C > Touchpad' > [22.259] (**) ELAN1200:00 04F3:309C Touchpad: always reports core events > [22.259] (**) Option "Device" "/dev/input/event9" > > Linux dmesg: > > [ 18.700018] input: ELAN1200:00 04F3:309C Touchpad as > /devices/pci:00/:00:15.1/i2c_designware.1/i2c-9/i2c-ELAN1200:00/0018:04F3:309C.0001/input/input10 > [ 18.700101] hid-multitouch 0018:04F3:309C.0001: input,hidraw0: I2C HID > v1.00 Mouse [ELAN1200:00 04F3:309C] on i2c-ELAN1200:00 > Please follow the thread on the phabricator: https://reviews.freebsd.org/D16698 It's still work in progress, but works fine for me (not counting the fact that it broke suspend/resume). -- Marek Zarychta signature.asc Description: OpenPGP digital signature
Re: HEAD'S UP: fusefs sysctls going away
W dniu 06.04.2019 o 17:28, Alan Somers pisze: > On Sat, Apr 6, 2019 at 8:52 AM Marek Zarychta > wrote: > >>>> After recent changes in fusefs code I am getting such panics regularly >>>> on amd64: >>>> >>>> >>>> Fatal trap 12: page fault while in kernel mode >>>> cpuid = 3; apic id = 03 >>>> fault virtual address= 0x248 >>>> fault code= supervisor read data , page not present >>>> instruction pointer= 0x20:0x82d6250c >>>> stack pointer= 0x28:0xfe005dc2c630 >>>> frame pointer= 0x28:0xfe005dc2c7b0 >>>> code segment= base 0x0, limit 0xf, type 0x1b >>>> = DPL 0, pres 1, long 1, def32 0, gran 1 >>>> processor eflags= interrupt enabled, resume, IOPL = 0 >>>> current process= 2016 (mount_fusefs) >>>> trap number= 12 >>>> panic: page fault >>>> cpuid = 3 >>>> time = 1554528396 >>>> KDB: stack backtrace: >>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >>>> 0xfe005dc2c2e0 >>>> vpanic() at vpanic+0x19d/frame 0xfe005dc2c330 >>>> panic() at panic+0x43/frame 0xfe005dc2c390 >>>> trap_fatal() at trap_fatal+0x394/frame 0xfe005dc2c3f0 >>>> trap_pfault() at trap_pfault+0x49/frame 0xfe005dc2c450 >>>> trap() at trap+0x29f/frame 0xfe005dc2c560 >>>> calltrap() at calltrap+0x8/frame 0xfe005dc2c560 >>>> --- trap 0xc, rip = 0x82d6250c, rsp = 0xfe005dc2c630, rbp = >>>> 0xfe005dc2c7b0 --- >>>> fuse_vfsop_mount() at fuse_vfsop_mount+0x5dc/frame 0xfe005dc2c7b0 >>>> vfs_domount() at vfs_domount+0xace/frame 0xfe005dc2c9e0 >>>> vfs_donmount() at vfs_donmount+0x934/frame 0xfe005dc2ca80 >>>> sys_nmount() at sys_nmount+0x69/frame 0xfe005dc2cac0 >>>> amd64_syscall() at amd64_syscall+0x36e/frame 0xfe005dc2cbf0 >>>> fast_syscall_common() at fast_syscall_common+0x101/frame >>>> 0xfe005dc2cbf0 >>>> --- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x8002d510a, rsp = >>>> 0x7fffe128, rbp = 0x7fffe730 --- >>>> KDB: enter: panic >>>> >>>> Last time I have checked it happened on FreeBSD 13.0-CURRENT #21 >>>> r345948: Fri Apr 5 17:12:53 CEST 2019. >>>> >>>> As a workaround loading fusefs.ko and fuse.ko modules can be disabled. >>>> >>>> -- >>>> Marek Zarychta >>> Thanks for the bug report. This is probably fixed by r345419 (which >>> hasn't been merged to head yet). If so, then it indicates that your fuse >>> daemon >>> is doing something wrong. What fuse file system are you trying to use, and >>> what command are you using to start it? >>> -Alan >> XFCE4 desktop environment seems to be the culprit of the whole anxiety. >> It has installed fusefs-libs-2.9.9 as a dependency. I get these panics >> during the XFCE session startup. Furthermore, I haven't any fusefs >> packages installed beside mentioned fusefs-libs. >> >> -- >> Marek Zarychta > > Then the culprit is probably /usr/local/libexec/gvfsd-fuse. But on my > XFCE4 system, that command never runs. I don't know why not. Try this > patch: > https://reviews.freebsd.org/D19836 > > -Alan Thank you for the fast-tracked patch. It resolves the issue. I have XFCE4 coexisting with Gnome and some extra, non-native disk partitions on this workstation, this is probably the cause that /usr/local/libexec/gvfsd-fuse comes into play. -- Marek Zarychta signature.asc Description: OpenPGP digital signature
Re: HEAD'S UP: fusefs sysctls going away
W dniu 06.04.2019 o 15:39, Alan Somers pisze: > On Fri, Apr 5, 2019 at 11:48 PM Marek Zarychta < > zarych...@plan-b.pwste.edu.pl> wrote: > >> W dniu 21.03.2019 o 17:03, Alan Somers pisze: >>> On Thu, Mar 21, 2019 at 10:00 AM Shawn Webb >> wrote: >>>> On Thu, Mar 21, 2019 at 09:55:15AM -0600, Alan Somers wrote: >>>>> On Thu, Mar 21, 2019 at 9:49 AM Shawn Webb >> wrote: >>>>>> Hey Alan, >>>>>> >>>>>> Thank you very much for your work in maintaining fusefs. I only use >>>>>> fusefs in very limited circumstances, so take what I'm about to say >>>>>> with a grain of salt. >>>>>> >>>>>> On Thu, Mar 21, 2019 at 09:43:07AM -0600, Alan Somers wrote: >>>>>>> fusefs has several sysctl knobs that seem to be workarounds for bugs >>>>>>> in particular fuse daemons. However, there is no indication as to >>>>>>> which those daemons are, neither in the code nor in SVN. All of the >>>>>>> workarounds are at least 6.5 years old, so the original bugs may have >>>>>>> been fixed already. Since the original bugs aren't documented, I >>>>>>> consider these workarounds to be unmaintainable, and I'm planning to >>>>>>> delete them unless anybody objects. Please pipe up if you still use >>>>>>> them! >>>>>>> >>>>>>> vfs.fusefs.mmap_enable: If non-zero, and data_cache_mode is also >>>>>>> non-zero, enable mmap(2) of FUSE files >>>>>> I'm curious if the security impacts of removing the toggle to disable >>>>>> mmap support for fusefs. Is there a per-fusefs replacement for >>>>>> mmap_enable? From a security perspective, it would be nice to keep the >>>>>> ability to disable mapping of files mounted on a fusefs. >>>>> As a matter of fact, there are three other ways to disable mmap: >>>>> 1) Set vfs.fusefs.data_cache_mode=0. This completely disables caching >>>>> file data, which precludes mmap. >>>>> 2) Use the undocumented -o no_datacache mount option, which does the >>>>> same thing on a per-mount basis. >>>>> 3) Use the undocumented -o no_mmap mount option, which disables mmap >>>>> on a per-mount basis. >>>> Awesome! I wasn't aware of these. Thanks! >>>> >>>>> Are you aware of any general security problems with using mmap? >>>>> Anything that would apply to fusefs but not other filesystems? >>>> Primarily because I trust the filesystems natively implemented in my >>>> OS more than I trust some (potentially random) fusefs module. >>>> >>>> For example, if I'm in a shared hosting environment, implemented with >>>> jails, and I let the customer mount a fusefs module in the jail (which >>>> is now possible, if I remember right), then I must trust that the >>>> module's mmap integration is properly implemented. I'm not sure I >>>> personally am okay with that level of trust. >>> Ah, well you needn't worry about that. mmap is handled entirely >>> within the kernel. The userland fusefs module only sees writes and >>> reads. From userland's perspective, the only real difference is that >>> mmap()ed writes don't identify the pid of the originating process, >>> whereas direct writes do (except when vfs.fusefs.data_cache_mode==2). >>> >>>> However, the point is moot now that you documented the three ways to >>>> disable mmap (two of which work on a per-mount basis). >> After recent changes in fusefs code I am getting such panics regularly >> on amd64: >> >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 3; apic id = 03 >> fault virtual address= 0x248 >> fault code= supervisor read data , page not present >> instruction pointer= 0x20:0x82d6250c >> stack pointer= 0x28:0xfe005dc2c630 >> frame pointer= 0x28:0xfe005dc2c7b0 >> code segment= base 0x0, limit 0xf, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags= interrupt enabled, resume, IOPL = 0 >> current process= 2016 (mount_fusefs) >> trap number= 12 >> panic: page fault >> cpuid = 3 >> time = 1554528396 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xf
Re: HEAD'S UP: fusefs sysctls going away
W dniu 21.03.2019 o 17:03, Alan Somers pisze: > On Thu, Mar 21, 2019 at 10:00 AM Shawn Webb > wrote: >> On Thu, Mar 21, 2019 at 09:55:15AM -0600, Alan Somers wrote: >>> On Thu, Mar 21, 2019 at 9:49 AM Shawn Webb >>> wrote: >>>> Hey Alan, >>>> >>>> Thank you very much for your work in maintaining fusefs. I only use >>>> fusefs in very limited circumstances, so take what I'm about to say >>>> with a grain of salt. >>>> >>>> On Thu, Mar 21, 2019 at 09:43:07AM -0600, Alan Somers wrote: >>>>> fusefs has several sysctl knobs that seem to be workarounds for bugs >>>>> in particular fuse daemons. However, there is no indication as to >>>>> which those daemons are, neither in the code nor in SVN. All of the >>>>> workarounds are at least 6.5 years old, so the original bugs may have >>>>> been fixed already. Since the original bugs aren't documented, I >>>>> consider these workarounds to be unmaintainable, and I'm planning to >>>>> delete them unless anybody objects. Please pipe up if you still use >>>>> them! >>>>> >>>>> vfs.fusefs.mmap_enable: If non-zero, and data_cache_mode is also >>>>> non-zero, enable mmap(2) of FUSE files >>>> I'm curious if the security impacts of removing the toggle to disable >>>> mmap support for fusefs. Is there a per-fusefs replacement for >>>> mmap_enable? From a security perspective, it would be nice to keep the >>>> ability to disable mapping of files mounted on a fusefs. >>> As a matter of fact, there are three other ways to disable mmap: >>> 1) Set vfs.fusefs.data_cache_mode=0. This completely disables caching >>> file data, which precludes mmap. >>> 2) Use the undocumented -o no_datacache mount option, which does the >>> same thing on a per-mount basis. >>> 3) Use the undocumented -o no_mmap mount option, which disables mmap >>> on a per-mount basis. >> Awesome! I wasn't aware of these. Thanks! >> >>> Are you aware of any general security problems with using mmap? >>> Anything that would apply to fusefs but not other filesystems? >> Primarily because I trust the filesystems natively implemented in my >> OS more than I trust some (potentially random) fusefs module. >> >> For example, if I'm in a shared hosting environment, implemented with >> jails, and I let the customer mount a fusefs module in the jail (which >> is now possible, if I remember right), then I must trust that the >> module's mmap integration is properly implemented. I'm not sure I >> personally am okay with that level of trust. > Ah, well you needn't worry about that. mmap is handled entirely > within the kernel. The userland fusefs module only sees writes and > reads. From userland's perspective, the only real difference is that > mmap()ed writes don't identify the pid of the originating process, > whereas direct writes do (except when vfs.fusefs.data_cache_mode==2). > >> However, the point is moot now that you documented the three ways to >> disable mmap (two of which work on a per-mount basis). After recent changes in fusefs code I am getting such panics regularly on amd64: Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0x248 fault code = supervisor read data , page not present instruction pointer = 0x20:0x82d6250c stack pointer = 0x28:0xfe005dc2c630 frame pointer = 0x28:0xfe005dc2c7b0 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 2016 (mount_fusefs) trap number = 12 panic: page fault cpuid = 3 time = 1554528396 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe005dc2c2e0 vpanic() at vpanic+0x19d/frame 0xfe005dc2c330 panic() at panic+0x43/frame 0xfe005dc2c390 trap_fatal() at trap_fatal+0x394/frame 0xfe005dc2c3f0 trap_pfault() at trap_pfault+0x49/frame 0xfe005dc2c450 trap() at trap+0x29f/frame 0xfe005dc2c560 calltrap() at calltrap+0x8/frame 0xfe005dc2c560 --- trap 0xc, rip = 0x82d6250c, rsp = 0xfe005dc2c630, rbp = 0xfe005dc2c7b0 --- fuse_vfsop_mount() at fuse_vfsop_mount+0x5dc/frame 0xfe005dc2c7b0 vfs_domount() at vfs_domount+0xace/frame 0xfe005dc2c9e0 vfs_donmount() at vfs_donmount+0x934/frame 0xfe005dc2ca80 sys_nmount() at sys_nmount+0x69/frame 0xfe005dc2cac0 amd64_syscall() at amd64_syscall+0x36e/frame 0xfe005dc2cbf0 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe005dc2cbf0 --- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x8002d510a, rsp = 0x7fffe128, rbp = 0x7fffe730 --- KDB: enter: panic Last time I have checked it happened on FreeBSD 13.0-CURRENT #21 r345948: Fri Apr 5 17:12:53 CEST 2019. As a workaround loading fusefs.ko and fuse.ko modules can be disabled. -- Marek Zarychta signature.asc Description: OpenPGP digital signature
Re: What is evdev and autoloading?
W dniu 18.02.2019 o 18:17, Pete Wright pisze: > > > On 2/18/19 8:50 AM, Rodney W. Grimes wrote: >>> On Mon, Feb 18, 2019 at 9:12 AM Rodney W. Grimes < >>> >>> I don't know. I think the fact that drm2 doesn't support anything newer >>> than 5-year-old hardware is a pretty convincing evidence that the >>> old way >>> is broken and doesn't work. >> But it DOES work, I am pretty sure we have 1000's of users on that 5 >> year >> old hardware that are totally happy with the intree DRM2 that is in >> stable/12, >> and some of whom have ventured into head/13 are having issues with >> thete a >> "new" model (ie kmod broken by a base commit). I know that there is wip >> to get CI coverage for that, but wip is wip, and we need to start >> changing >> the cart horse driver order we keep doing and get things right. Port >> up and working, with CI testing *before* we go remove kmod'ed code from >> base would be a much more appropriate path. >> >> I think one serious problem here is the summary dismissal of things >> simply on the "5 year old" basis. Not everyone, and infact few now >> a days other than corporate buyers, can afford new hardware, >> giving the minimal performance increase in systems over the last 5 >> years the cost/benifit factor of a new computer is just too low. > I've put a lot of effort helping test and document how to get a usable > desktop environment on a modern laptop. there were two issues which > motivated me to do this: > > 1) my observation that many developers at conferences and online were > using macOS as their primary desktop environment. when comparing this > to the OpenBSD and Linux community I felt pretty embarrassed, but it > did explain the stagnant nature of our graphics subsystem. people > seemed afraid to touch things due the brittle nature of its hardware > support. > > 2) i was in need to an *affordable* machine with a warranty. > fortunately there are many affordable laptops at staples, best-buy and > amazon - but they were all post haswell systems, rendering them > basically useless from a FreeBSD perspective. > > after trying to get traction to update the in-tree drm subsystem i was > lucky enough to sync up with the graphics team which was working on > syncing things up with modern hardware support. because of that i'm > now able to get my small startup pretty much all on board with > FreeBSD. i use it on my workstations as well as on or server > infrastructure (physical and AWS). i would consider this a success > for our community as it's opened up the eyes to a whole new generation > of devs to FreeBSD. > > one thing missing from all of these arguments is real data. how many > people are on haswell era hardware? i can tell from my experience the > past several years the number of people who have post-haswell gear > seem to be more numerous, or at least more vocal (and frankly easier > to work with while squashing bugs). > > i can also say that personally it would be great to improve support > for systems requiring drm2 - but that gear is hard to come by, so we > are really dependent on helpful collaboration from those who are being > effected. > Thank you for reworking laptop hardware support, it has been improved a lot lately. Nowadays almost everything works out of the box. In my case things not working, for a brand new laptop, had patches in the review and available to download from FreeBSD Phabricator. Laptop support is the key to gain popularity of the OS, especially among the younger generation of users. From the other hand, I am not able to boot 12.0 RELEASE on a couple of ~10 years old servers, though I still can actively follow 11-STABLE there. It's not easy to find the cause of the breakage. I'd like to encourage you Developers to MFC as much as we can handle into the STABLE branch to involve even more users into the software testing process. Breaking ABI is unacceptable, but brave MFC would sometimes help the community avoid/reduce a gap between STABLE and CURRENT which accumulates and appears in the final of the release cycle. With best regards, -- Marek Zarychta signature.asc Description: OpenPGP digital signature
Re: 12.0-BETA1 vnet with pf firewall
On Fri, Nov 02, 2018 at 02:20:53PM +, Bjoern A. Zeeb wrote: > On 28 Oct 2018, at 22:07, Marek Zarychta wrote: > > > Some time ago I submitted a PR about this, but I was unaware that the > > case of failure during loading ipsec.ko is caused by the presence of > > already loaded pf.ko > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228854 > > > This bug and the current report should be fixed in stable/11, stable/12 > (including the upcoming BETA3), and HEAD. > > If you continue to experience this problem, please re-open the bug > report and follow-up there! > > > Thanks a lot for your reports and testings. > Thank you for resolving this non-trivial issue, applying the quick fix and expedited MFC. -- Marek Zarychta signature.asc Description: PGP signature
Re: 12.0-BETA1 vnet with pf firewall
W dniu 28.10.2018 o 22:39, Rodney W. Grimes pisze: >> Bjoern A. Zeeb wrote: >>> On 28 Oct 2018, at 15:31, Ernie Luzar wrote: >>> >>>> Tested with host running ipfilter and vnet running pf. Tried loading >>>> pf from host console or from vnet console using kldload pf.ko command >>>> and get this error message; >>>> >>>> linker_load_file: /boot/kernel/pf.ko-unsupported file type. >>>> >>>> Looks like the 12.0 version of pf which is suppose to work in vnet >>>> independent of what firewall is running on the host is not working. >>> You cannot load pf from inside a jail (with or without vnet). Kernel >>> modules are global objects loaded from the base system or you compile >>> the devices into the kernel; it is their state which is virtualised. >>> >>> If you load multiple firewalls they will all be available to the base >>> system and all jails+vnet. Whichever you configure in which one is up >>> to you. Just be careful as an unconfigured firewall might have a >>> default action affecting the outcome of the overall decision. >>> >>> For example you could have: >>> >>> a base system using ipfilter and setting pf to default accept everything >>> and a jail+vnet using pf and setting ipfilter there to accept everything. >>> >>> >>> Hope that clarifies some things. >>> >>> /bz >>> >> Hello Bjoern. >> >> What you said is correct for 10.x & 11.x. But I an talking about >> 12.0-beta1. I have the ipfilter options enabled in rc.conf of the host >> and on boot ipfilter starts just like it all ways does. Now to prep the >> host for pf in a vnet jail, I issue from the host console the >> "kldload pf.ko" command and get this error message; >> >> linker_load_file: /boot/kernel/pf.ko-unsupported file type. >> >> Something is wrong here. This is not suppose to happen according to your >> post above. >> >> Remember that in 12.0 vimage is included in the base system kernel. > Confirmed, if I boot a clean install and issue: > kldload ipfilter.ko > kldload pf.ko > my dmesg has: > IP Filter: v5.1.2 initialized. Default = pass all, Logging = enabled > linker_load_file: /boot/kernel/pf.ko - unsupported file type > The same when loading pf.ko combined with ipsec.ko, both can't be loaded on the same running kernel # kldload ipsec && echo ok || echo fail ; kldload pf && echo ok || echo fail ok kldload: an error occurred while loading module pf. Please check dmesg(8) for more details. fail Another try in reverse order (both modules unloaded first): # kldload pf && echo ok || echo fail ; kldload ipsec && echo ok || echo fail ok kldload: an error occurred while loading module ipsec. Please check dmesg(8) for more details. fail Some time ago I submitted a PR about this, but I was unaware that the case of failure during loading ipsec.ko is caused by the presence of already loaded pf.ko https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228854 -- Marek Zarychta signature.asc Description: OpenPGP digital signature
Re: SVN r339216 breaks ssh to i386 devices
W dniu 09.10.2018 o 01:28, Dag-Erling Smørgrav pisze: > Please try the attached patch. I expect it to fix i386. If it also > fixes arm32, all the better, although I don't quite see why it would. I have connected serial console to affected box and upgraded system from patched sources. I am sorry to say that this patch doesn't solve the issue for 32-bit ARM (RPi2). Still sshd terminates session with the error "fatal: mm_getpwnamallow: receive get struct passwd failed [preauth]". -- Marek Zarychta signature.asc Description: OpenPGP digital signature
Re: SVN r339216 breaks ssh to i386 devices
On Mon, Oct 08, 2018 at 02:43:32PM -0400, Michael Butler wrote: > With an i386 system, ssh sessions to the updated sshd fail with: > > sshd[28771]: fatal: mm_getpwnamallow: receive get struct passwd failed > [preauth] > > This is reproducible on both real hardware and in a VM running an i386 > build, > sshd running on 32-bit ARM architecture seems to be also affected after update to 12.0-ALPHA8 r339223. -- Marek Zarychta signature.asc Description: PGP signature
Re: ntpd user and group missing when upgrading from sources from 11-stable to 12-current
On Thu, Sep 13, 2018 at 04:16:26PM -0500, Eric van Gyzen wrote: > On 9/13/18 4:07 PM, Marek Zarychta wrote: > > Dear subscribers, > > > > stable/12 hasn't been branched yet, so it could be not a bug. Since > > r336525 make installworld fails on 11-stable when installing world for > > 12-current without ntpd user/group added. Of course, as a workaround > > user and group could be added manually. Mergemeaster also fails when it > > is run before installworld, what is IMHO predictable and expected > > behaviour. So mergemaster will not help with this issue. > > > > So the question arises, is it a feature or should a PR be submitted? > > Did you run mergemaster with the -p flag before installworld? > > Eric Thank you for the clue, TBH I didn't use -p flag which was my fault. I am sorry for the needless noise I have made on the list. -- Marek Zarychta signature.asc Description: PGP signature
ntpd user and group missing when upgrading from sources from 11-stable to 12-current
Dear subscribers, stable/12 hasn't been branched yet, so it could be not a bug. Since r336525 make installworld fails on 11-stable when installing world for 12-current without ntpd user/group added. Of course, as a workaround user and group could be added manually. Mergemeaster also fails when it is run before installworld, what is IMHO predictable and expected behaviour. So mergemaster will not help with this issue. So the question arises, is it a feature or should a PR be submitted? -- Marek Zarychta signature.asc Description: PGP signature
