Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in a zfs file systems context)
On 2021-May-23, at 01:27, Mark Millard wrote: > On 2021-May-23, at 00:44, Mark Millard wrote: > >> On 2021-May-21, at 17:56, Rick Macklem wrote: >> >>> Mark Millard wrote: >>> [stuff snipped] >>>> Well, why is it that ls -R, find, and diff -r all get file >>>> name problems via genet0 but diff -r gets no problems >>>> comparing the content of files that it does match up (the >>>> vast majority)? Any clue how could the problems possibly >>>> be unique to the handling of file names/paths? Does it >>>> suggest anything else to look into for getting some more >>>> potentially useful evidence? >>> Well, all I can do is describe the most common TSO related >>> failure: >>> - When a read RPC reply (including NFS/RPC/TCP/IP headers) >>> is slightly less than 64K bytes (many TSO implementations are >>> limited to 64K or 32 discontiguous segments, think 32 2K >>> mbuf clusters), the driver decides it is ok, but when the MAC >>> header is added it exceeds what the hardware can handle correctly... >>> --> This will happen when reading a regular file that is slightly less >>> than a multiple of 64K in size. >>> or >>> --> This will happen when reading just about any large directory, >>>since the directory reply for a 64K request is converted to Sun XDR >>>format and clipped at the last full directory entry that will fit within >>> 64K. >>> For ports, where most files are small, I think you can tell which is more >>> likely to happen. >>> --> If TSO is disabled, I have no idea how this might matter, but?? >>> >>>> I'll note that netstat -I ue0 -d and netstat -I genet0 -d >>>> do not report changes in Ierrs or Idrop in a before vs. >>>> after failures comparison. (There may be better figures >>>> to look at for all I know.) >>>> >>>> I tried "ifconfig genet0 -rxcsum -rxcsum -rxcsum6 -txcsum6" >>>> and got no obvious change in behavior. >>> All we know is that the data is getting corrupted somehow. >>> >>> NFS traffic looks very different than typical TCP traffic. It is >>> mostly small messages travelling in both directions concurrently, >>> with some large messages thrown in the mix. >>> All I'm saying is that, testing a net interface with something like >>> bulk data transfer in one direction doesn't verify it works for NFS >>> traffic. >>> >>> Also, the large RPC messages are a chain of about 33 mbufs of >>> various lengths, including a mix of partial clusters and regular >>> data mbufs, whereas a bulk send on a socket will typically >>> result in an mbuf chain of a lot of full 2K clusters. >>> --> As such, NFS can be good at tickling subtle bugs it the >>>net driver related to mbuf handling. >>> >>> rick >>> >>>>> W.r.t. reverting r367492...the patch to replace r367492 was just >>>>> committed to "main" by rscheff@ with a two week MFC, so it >>>>> should be in stable/13 soon. Not sure if an errata can be done >>>>> for it for releng13.0? >>>> >>>> That update is reported to be causing "rack" related panics: >>>> >>>> https://lists.freebsd.org/pipermail/dev-commits-src-main/2021-May/004440.html >>>> >>>> reports (via links): >>>> >>>> panic: _mtx_lock_sleep: recursed on non-recursive mutex so_snd @ >>>> /syzkaller/managers/i386/kernel/sys/modules/tcp/rack/../../../netinet/tcp_stacks/rack.c:10632 >>>> >>>> Still, I have a non-debug update to main building and will >>>> likely do a debug build as well. llvm is rebuilding, so >>>> the builds will take a notable time. >> >> I got the following built and installed on the two >> machines: >> >> # uname -apKU >> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #1 >> main-n246854-03b0505b8fe8-dirty: Sat May 22 16:25:04 PDT 2021 >> root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-DBG-CA72 >> arm64 aarch64 1400013 1400013 >> >> # uname -apKU >> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #1 >> main-n246854-03b0505b8fe8-dirty: Sat May 22 16:25:04 PDT 2021 >> root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-DBG-CA72 >> arm64 aarch64 1400013 1400013 >>
Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in a zfs file systems context)
On 2021-May-23, at 00:44, Mark Millard wrote: > On 2021-May-21, at 17:56, Rick Macklem wrote: > >> Mark Millard wrote: >> [stuff snipped] >>> Well, why is it that ls -R, find, and diff -r all get file >>> name problems via genet0 but diff -r gets no problems >>> comparing the content of files that it does match up (the >>> vast majority)? Any clue how could the problems possibly >>> be unique to the handling of file names/paths? Does it >>> suggest anything else to look into for getting some more >>> potentially useful evidence? >> Well, all I can do is describe the most common TSO related >> failure: >> - When a read RPC reply (including NFS/RPC/TCP/IP headers) >> is slightly less than 64K bytes (many TSO implementations are >> limited to 64K or 32 discontiguous segments, think 32 2K >> mbuf clusters), the driver decides it is ok, but when the MAC >> header is added it exceeds what the hardware can handle correctly... >> --> This will happen when reading a regular file that is slightly less >> than a multiple of 64K in size. >> or >> --> This will happen when reading just about any large directory, >> since the directory reply for a 64K request is converted to Sun XDR >> format and clipped at the last full directory entry that will fit within >> 64K. >> For ports, where most files are small, I think you can tell which is more >> likely to happen. >> --> If TSO is disabled, I have no idea how this might matter, but?? >> >>> I'll note that netstat -I ue0 -d and netstat -I genet0 -d >>> do not report changes in Ierrs or Idrop in a before vs. >>> after failures comparison. (There may be better figures >>> to look at for all I know.) >>> >>> I tried "ifconfig genet0 -rxcsum -rxcsum -rxcsum6 -txcsum6" >>> and got no obvious change in behavior. >> All we know is that the data is getting corrupted somehow. >> >> NFS traffic looks very different than typical TCP traffic. It is >> mostly small messages travelling in both directions concurrently, >> with some large messages thrown in the mix. >> All I'm saying is that, testing a net interface with something like >> bulk data transfer in one direction doesn't verify it works for NFS >> traffic. >> >> Also, the large RPC messages are a chain of about 33 mbufs of >> various lengths, including a mix of partial clusters and regular >> data mbufs, whereas a bulk send on a socket will typically >> result in an mbuf chain of a lot of full 2K clusters. >> --> As such, NFS can be good at tickling subtle bugs it the >> net driver related to mbuf handling. >> >> rick >> >>>> W.r.t. reverting r367492...the patch to replace r367492 was just >>>> committed to "main" by rscheff@ with a two week MFC, so it >>>> should be in stable/13 soon. Not sure if an errata can be done >>>> for it for releng13.0? >>> >>> That update is reported to be causing "rack" related panics: >>> >>> https://lists.freebsd.org/pipermail/dev-commits-src-main/2021-May/004440.html >>> >>> reports (via links): >>> >>> panic: _mtx_lock_sleep: recursed on non-recursive mutex so_snd @ >>> /syzkaller/managers/i386/kernel/sys/modules/tcp/rack/../../../netinet/tcp_stacks/rack.c:10632 >>> >>> Still, I have a non-debug update to main building and will >>> likely do a debug build as well. llvm is rebuilding, so >>> the builds will take a notable time. > > I got the following built and installed on the two > machines: > > # uname -apKU > FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #1 > main-n246854-03b0505b8fe8-dirty: Sat May 22 16:25:04 PDT 2021 > root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-DBG-CA72 > arm64 aarch64 1400013 1400013 > > # uname -apKU > FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #1 > main-n246854-03b0505b8fe8-dirty: Sat May 22 16:25:04 PDT 2021 > root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-DBG-CA72 > arm64 aarch64 1400013 1400013 > > Note that both are booted with debug builds of main. > > Using the context with the alternate EtherNet device that has not > had an associated diff -r, find, pr ls -R failure yet > yet got a panic that looks likely to be unrelated: > > # mount -onoatime 192.168.1.187:/usr/ports/ /mnt/ > # diff -r /usr/ports/ /mnt/ | more > nvme0: cpl does not map to outstanding cmd
Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in a zfs file systems context)
On 2021-May-21, at 17:56, Rick Macklem wrote: > Mark Millard wrote: > [stuff snipped] >> Well, why is it that ls -R, find, and diff -r all get file >> name problems via genet0 but diff -r gets no problems >> comparing the content of files that it does match up (the >> vast majority)? Any clue how could the problems possibly >> be unique to the handling of file names/paths? Does it >> suggest anything else to look into for getting some more >> potentially useful evidence? > Well, all I can do is describe the most common TSO related > failure: > - When a read RPC reply (including NFS/RPC/TCP/IP headers) > is slightly less than 64K bytes (many TSO implementations are > limited to 64K or 32 discontiguous segments, think 32 2K > mbuf clusters), the driver decides it is ok, but when the MAC > header is added it exceeds what the hardware can handle correctly... > --> This will happen when reading a regular file that is slightly less > than a multiple of 64K in size. > or > --> This will happen when reading just about any large directory, > since the directory reply for a 64K request is converted to Sun XDR > format and clipped at the last full directory entry that will fit within > 64K. > For ports, where most files are small, I think you can tell which is more > likely to happen. > --> If TSO is disabled, I have no idea how this might matter, but?? > >> I'll note that netstat -I ue0 -d and netstat -I genet0 -d >> do not report changes in Ierrs or Idrop in a before vs. >> after failures comparison. (There may be better figures >> to look at for all I know.) >> >> I tried "ifconfig genet0 -rxcsum -rxcsum -rxcsum6 -txcsum6" >> and got no obvious change in behavior. > All we know is that the data is getting corrupted somehow. > > NFS traffic looks very different than typical TCP traffic. It is > mostly small messages travelling in both directions concurrently, > with some large messages thrown in the mix. > All I'm saying is that, testing a net interface with something like > bulk data transfer in one direction doesn't verify it works for NFS > traffic. > > Also, the large RPC messages are a chain of about 33 mbufs of > various lengths, including a mix of partial clusters and regular > data mbufs, whereas a bulk send on a socket will typically > result in an mbuf chain of a lot of full 2K clusters. > --> As such, NFS can be good at tickling subtle bugs it the > net driver related to mbuf handling. > > rick > >>> W.r.t. reverting r367492...the patch to replace r367492 was just >>> committed to "main" by rscheff@ with a two week MFC, so it >>> should be in stable/13 soon. Not sure if an errata can be done >>> for it for releng13.0? >> >> That update is reported to be causing "rack" related panics: >> >> https://lists.freebsd.org/pipermail/dev-commits-src-main/2021-May/004440.html >> >> reports (via links): >> >> panic: _mtx_lock_sleep: recursed on non-recursive mutex so_snd @ >> /syzkaller/managers/i386/kernel/sys/modules/tcp/rack/../../../netinet/tcp_stacks/rack.c:10632 >> >> Still, I have a non-debug update to main building and will >> likely do a debug build as well. llvm is rebuilding, so >> the builds will take a notable time. I got the following built and installed on the two machines: # uname -apKU FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-n246854-03b0505b8fe8-dirty: Sat May 22 16:25:04 PDT 2021 root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-DBG-CA72 arm64 aarch64 1400013 1400013 # uname -apKU FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-n246854-03b0505b8fe8-dirty: Sat May 22 16:25:04 PDT 2021 root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-DBG-CA72 arm64 aarch64 1400013 1400013 Note that both are booted with debug builds of main. Using the context with the alternate EtherNet device that has not had an associated diff -r, find, pr ls -R failure yet yet got a panic that looks likely to be unrelated: # mount -onoatime 192.168.1.187:/usr/ports/ /mnt/ # diff -r /usr/ports/ /mnt/ | more nvme0: cpl does not map to outstanding cmd cdw0: sqhd:0020 sqid:0003 cid:007e p:1 sc:00 sct:0 m:0 dnr:0 panic: received completion for unknown cmd cpuid = 3 time = 1621743752 KDB: stack backtrace: db_trace_self() at db_trace_self db_trace_self_wrapper() at db_trace_self_wrapper+0x30 vpanic() at vpanic+0x188 panic() at panic+0x44 nvme_qpair_process_completions() at nvme_qpair_process_completions+0x1fc nvme_timeout() at nvme_timeout+0x3c softclock_call_cc() at softclock_call_cc+0x124 so
Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in a zfs file systems context)
On 2021-May-21, at 09:00, Rick Macklem wrote: > Mark Millard wrote: >> On 2021-May-20, at 22:19, Rick Macklem wrote: > [stuff snipped] >>> ps: I do not think that r367492 could cause this, but it would be >>>nice if you try a kernel with the r367492 patch reverted. >>>It is currently in all of releng13, stable13 and main, although >>>the patch to fix this is was just reviewed and may hit main soon. >> >> Do you want a debug kernel to be used? Do you have a preference >> for main vs. stable/13 vs. release/13.0.0 based? Is it okay to >> stick to the base version things are now based on --or do you >> want me to update to more recent? (That last only applies if >> main or stable/13 is to be put to use.) > Well, it sounds like you've isolated it to the genet interface. > Good sluething. > Unfortunately, NFS is only as good as the network fabric under it. > However, it's usually hangs or poor performance. Except maybe > for the readdir issue that Jason Bacon reported and resolved via > an upgrade, this is a first. > --> In the old days, I would have expected IP checksums to catch > this, but I'm guessing the hardware/net driver are doing them > these days? Well, why is it that ls -R, find, and diff -r all get file name problems via genet0 but diff -r gets no problems comparing the content of files that it does match up (the vast majority)? Any clue how could the problems possibly be unique to the handling of file names/paths? Does it suggest anything else to look into for getting some more potentially useful evidence? I'll note that netstat -I ue0 -d and netstat -I genet0 -d do not report changes in Ierrs or Idrop in a before vs. after failures comparison. (There may be better figures to look at for all I know.) I tried "ifconfig genet0 -rxcsum -rxcsum -rxcsum6 -txcsum6" and got no obvious change in behavior. > W.r.t. reverting r367492...the patch to replace r367492 was just > committed to "main" by rscheff@ with a two week MFC, so it > should be in stable/13 soon. Not sure if an errata can be done > for it for releng13.0? That update is reported to be causing "rack" related panics: https://lists.freebsd.org/pipermail/dev-commits-src-main/2021-May/004440.html reports (via links): panic: _mtx_lock_sleep: recursed on non-recursive mutex so_snd @ /syzkaller/managers/i386/kernel/sys/modules/tcp/rack/../../../netinet/tcp_stacks/rack.c:10632 Still, I have a non-debug update to main building and will likely do a debug build as well. llvm is rebuilding, so the builds will take a notable time. > Thanks for isolating this, rick > ps: Co-incidentally, I've been thinking of buying an RBPi4 as a toy. I'll warn that the primary "small arm" development/support folk(s) do not work on the RPi*'s these days, beyond committing what others provide and the like. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
odd behaviour using lagg on bridge
Hi List, I’m observing some odd behaviour after I decided to put the 2 interfaces in my system into a lagg failover bond - Can’t add the lagg to a bridge, it will say: $ sudo ifconfig vm-public addm lagg0 ifconfig: BRDGADD lagg0: Device busy I also witnessed that starting a vm after having it reconfigured to use a manual bridge (instead of the vm-bhyve managed one) where lagg0 is present all IPv6 addresses are being stripped from the lagg interface. A service netif/routing restart doesn’t restore ipv6 connectivity. I think I saw something similar with a (iocage managed) vnet jail too, as that uses bridges too Regards, Ruben signature.asc Description: Message signed with OpenPGP
Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in a zfs file systems context) [RPi4B genet0 involved in problem]
th sides at the same time: No differences found by diff -r this way (expected result). So it looks like genet0 or its supporting software is contributing to the problems that I had reported. It is interesting that there were no examples of the content of files reporting a mismatch, just some file names/paths not finding matches, some with truncated names or obvious-garbage bytes in names. Note: The faster machine is a MACCCHIATObin Double Shot. The slower machine is a RPi4B 8 GiByte. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in a zfs file systems context)
On 2021-May-20, at 22:19, Rick Macklem wrote: > Ok, so it isn't related to "soft". > I am wondering if it is something specific to what > "diff -r" does? > > Could you try: > # cd /usr/ports > # ls -R > /tmp/x > # cd /mnt > # ls -R > /tmp/y > # cd /tmp > # diff -u -p x y > --> To see if "ls -R" finds any difference? > # diff -u -p x y --- x 2021-05-20 22:35:48.021663000 -0700 +++ y 2021-05-20 22:39:03.691936000 -0700 @@ -227209,10 +227209,10 @@ patch-chrome_browser_background_background__mode__mana patch-chrome_browser_background_background__mode__optimizer.cc patch-chrome_browser_browser__resources.grd patch-chrome_browser_browsing__data_chrome__browsing__data__remover__delegate.cc +patch-chrome_browser_chrome__browser patch-chrome_browser_chrome__browser__interface__binders.cc patch-chrome_browser_chrome__browser__main.cc patch-chrome_browser_chrome__browser__main__linux.cc -patch-chrome_browser_chrome__browser__main__posix.cc patch-chrome_browser_chrome__content__browser__client.cc patch-chrome_browser_chrome__content__browser__client.h patch-chrome_browser_crash__upload__list_crash__upload__list.cc # find /usr/ports/ -name 'patch-chrome_browser_chrome__browser*' -print | more /usr/ports/devel/electron12/files/patch-chrome_browser_chrome__browser__main__linux.cc /usr/ports/devel/electron12/files/patch-chrome_browser_chrome__browser__main.cc /usr/ports/devel/electron12/files/patch-chrome_browser_chrome__browser__main__posix.cc /usr/ports/devel/electron12/files/patch-chrome_browser_chrome__browser__interface__binders.cc /usr/ports/www/chromium/files/patch-chrome_browser_chrome__browser__main__posix.cc /usr/ports/www/chromium/files/patch-chrome_browser_chrome__browser__main.cc /usr/ports/www/chromium/files/patch-chrome_browser_chrome__browser__main__linux.cc /usr/ports/www/chromium/files/patch-chrome_browser_chrome__browser__interface__binders.cc find /mnt/ -name 'patch-chrome_browser_chrome__browser*' -print | more /mnt/devel/electron12/files/patch-chrome_browser_chrome__browser__main__linux.cc /mnt/devel/electron12/files/patch-chrome_browser_chrome__browser__main.cc /mnt/devel/electron12/files/patch-chrome_browser_chrome__browser__main__posix.cc /mnt/devel/electron12/files/patch-chrome_browser_chrome__browser__interface__binders.cc /mnt/www/chromium/files/patch-chrome_browser_chrome__browser /mnt/www/chromium/files/patch-chrome_browser_chrome__browser__main.cc /mnt/www/chromium/files/patch-chrome_browser_chrome__browser__main__linux.cc /mnt/www/chromium/files/patch-chrome_browser_chrome__browser__interface__binders.cc So: patch-chrome_browser_chrome__browser appears to be a truncated: patch-chrome_browser_chrome__browser__main__posix.cc file name and find also gets the same oddity. (Note: This had /usr/ports in a main context and /mnt/ referring to a release/13.0.0 context.) > ps: I do not think that r367492 could cause this, but it would be > nice if you try a kernel with the r367492 patch reverted. > It is currently in all of releng13, stable13 and main, although > the patch to fix this is was just reviewed and may hit main soon. Do you want a debug kernel to be used? Do you have a preference for main vs. stable/13 vs. release/13.0.0 based? Is it okay to stick to the base version things are now based on --or do you want me to update to more recent? (That last only applies if main or stable/13 is to be put to use.) > . . . old history deleted . . . === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in a zfs file systems context)
[Direct drive connection to machine: no problem.] On 2021-May-20, at 21:40, Mark Millard wrote: > [main test example and main/releng/13 mixed example] > > On 2021-May-20, at 20:36, Mark Millard wrote: > >> [stable/13 test: example ends up being odder. That might >> allow eliminating some potential alternatives.] >> >> On 2021-May-20, at 19:38, Mark Millard wrote: >>> >>> On 2021-May-20, at 18:09, Rick Macklem wrote: >>>> >>>> Oh, one additional thing that I'll dare to top post... >>>> r367492 broke the TCP upcalls that the NFS server uses, such >>>> that intermittent hangs of NFS mounts to FreeBSD13 servers can occur. >>>> This has not yet been resolved in "main" etc and could explain >>>> why an RPC could time out for a soft mount. >>> >>> See later notes that I added: soft mount is not required >>> to see the problem. >>> >>>> You can revert the patch in r367492 to avoid the problem. >>> >>> If I understand right, you are indicating that this would >>> not apply to the non-soft mount case that I got. >>> >>>> Disabling TSO, LRO are also de-facto standard things to do when >>>> you observe weird NFS behaviour, because they are often broken >>>> in various network device drivers. >>> >>> I'll have to figure out how to experiment with such. Things >>> are at defaults rather generally on the systems. I'm not >>> literate in the subject areas. >>> >>> I'm the only user of the machines and network. It is not >>> outward facing. It is a rather small EtherNet network. >>> >>>> rick >>>> >>>> >>>> From: owner-freebsd-sta...@freebsd.org >>>> on behalf of Rick Macklem >>>> Sent: Thursday, May 20, 2021 8:55 PM >>>> To: FreeBSD-STABLE Mailing List; Mark Millard >>>> Subject: Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs >>>> (in a zfs file systems context) >>>> >>>> Mark Millard wrote: >>>>> [I warn that I'm a fairly minimal user of NFS >>>>> mounts, not knowing all that much. I'm mostly >>>>> reporting this in case it ends up as evidence >>>>> via eventually matching up with others observing >>>>> possibly related oddities.] >>>>> >>>>> I got the following odd sequence (that I've >>>>> mixed notes into). It involved a diff -r over NFS >>>>> showing differences (files missing) and then a >>>>> later diff finding matches for the same files, >>>>> no file system changes made on either machine. >>>>> I'm unable to reproduce the oddity on demand. >>>>> >>>>> Note: A larger scope diff -r originally returned the >>>>> below as well, but doing the narrower diff -r did >>>>> repeat the result and that is what I show. (I >>>>> make no use of devel/ice .) >>>>> >>>>> # diff -r /usr/ports/devel/ice/files /mnt/devel/ice/files | more >>>>> Only in /usr/ports/devel/ice/files: Make.rules.FreeBSD >>> . . . >>>>> Only in /usr/ports/devel/ice/files: patch-scripts-TestUtil.py >>>>> >>>>> Note: The above was not expected. So I tried: >>>>> >>>>> # ls -Tld /mnt/devel/ice/files/* >>>>> -rw-r--r-- 1 root wheel 755 Apr 21 21:07:54 2021 >>>>> /mnt/devel/ice/files/Make.rules.FreeBSD >>> . . . >>>>> -rw-r--r-- 1 root wheel 2588 Apr 21 21:07:54 2021 >>>>> /mnt/devel/ice/files/patch-scripts-TestUtil.py >>>>> >>>>> Note: So that indicated that the files were there on the >>>>> machine that /mnt references. So attempting the original >>>>> diff -r again: >>>>> >>>>> # diff -r /usr/ports/devel/ice/files /mnt/devel/ice/files | more >>>>> # >>>>> >>>>> (Empty difference.) >>>>> >>>>> Note: So after the explicit "ls -Tld /mnt/devel/ice/files/*" >>>>> the odd result of the diff -r no longer happened: no >>>>> differences reported. >>>>> >>>>> >>>>> >>>>> For reference (both machines reported): >>>>> >>>>> . . . >>>>> The original mount command w
Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in a zfs file systems context)
[main test example and main/releng/13 mixed example] On 2021-May-20, at 20:36, Mark Millard wrote: > [stable/13 test: example ends up being odder. That might > allow eliminating some potential alternatives.] > > On 2021-May-20, at 19:38, Mark Millard wrote: >> >> On 2021-May-20, at 18:09, Rick Macklem wrote: >>> >>> Oh, one additional thing that I'll dare to top post... >>> r367492 broke the TCP upcalls that the NFS server uses, such >>> that intermittent hangs of NFS mounts to FreeBSD13 servers can occur. >>> This has not yet been resolved in "main" etc and could explain >>> why an RPC could time out for a soft mount. >> >> See later notes that I added: soft mount is not required >> to see the problem. >> >>> You can revert the patch in r367492 to avoid the problem. >> >> If I understand right, you are indicating that this would >> not apply to the non-soft mount case that I got. >> >>> Disabling TSO, LRO are also de-facto standard things to do when >>> you observe weird NFS behaviour, because they are often broken >>> in various network device drivers. >> >> I'll have to figure out how to experiment with such. Things >> are at defaults rather generally on the systems. I'm not >> literate in the subject areas. >> >> I'm the only user of the machines and network. It is not >> outward facing. It is a rather small EtherNet network. >> >>> rick >>> >>> >>> From: owner-freebsd-sta...@freebsd.org >>> on behalf of Rick Macklem >>> Sent: Thursday, May 20, 2021 8:55 PM >>> To: FreeBSD-STABLE Mailing List; Mark Millard >>> Subject: Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs >>> (in a zfs file systems context) >>> >>> Mark Millard wrote: >>>> [I warn that I'm a fairly minimal user of NFS >>>> mounts, not knowing all that much. I'm mostly >>>> reporting this in case it ends up as evidence >>>> via eventually matching up with others observing >>>> possibly related oddities.] >>>> >>>> I got the following odd sequence (that I've >>>> mixed notes into). It involved a diff -r over NFS >>>> showing differences (files missing) and then a >>>> later diff finding matches for the same files, >>>> no file system changes made on either machine. >>>> I'm unable to reproduce the oddity on demand. >>>> >>>> Note: A larger scope diff -r originally returned the >>>> below as well, but doing the narrower diff -r did >>>> repeat the result and that is what I show. (I >>>> make no use of devel/ice .) >>>> >>>> # diff -r /usr/ports/devel/ice/files /mnt/devel/ice/files | more >>>> Only in /usr/ports/devel/ice/files: Make.rules.FreeBSD >> . . . >>>> Only in /usr/ports/devel/ice/files: patch-scripts-TestUtil.py >>>> >>>> Note: The above was not expected. So I tried: >>>> >>>> # ls -Tld /mnt/devel/ice/files/* >>>> -rw-r--r-- 1 root wheel 755 Apr 21 21:07:54 2021 >>>> /mnt/devel/ice/files/Make.rules.FreeBSD >> . . . >>>> -rw-r--r-- 1 root wheel 2588 Apr 21 21:07:54 2021 >>>> /mnt/devel/ice/files/patch-scripts-TestUtil.py >>>> >>>> Note: So that indicated that the files were there on the >>>> machine that /mnt references. So attempting the original >>>> diff -r again: >>>> >>>> # diff -r /usr/ports/devel/ice/files /mnt/devel/ice/files | more >>>> # >>>> >>>> (Empty difference.) >>>> >>>> Note: So after the explicit "ls -Tld /mnt/devel/ice/files/*" >>>> the odd result of the diff -r no longer happened: no >>>> differences reported. >>>> >>>> >>>> >>>> For reference (both machines reported): >>>> >>>> . . . >>>> The original mount command was on CA72_16Gp_ZFS: >>>> >>>> # mount -onoatime,soft 192.168.1.170:/usr/ports/ /mnt/ >>> The likely explanation for this is your use of a "soft" mount. >>> - If the NFS server is slow to respond or there is a temporary network >>> issue, >>> the RPC request can time out and then the >>> syscall can fail with EINT/ETIMEDOUT. Since almost nothing, including the >>> readdir(3) libc functions ex
Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in a zfs file systems context)
[stable/13 test: example ends up being odder. That might allow eliminating some potential alternatives.] On 2021-May-20, at 19:38, Mark Millard wrote: > > On 2021-May-20, at 18:09, Rick Macklem wrote: >> >> Oh, one additional thing that I'll dare to top post... >> r367492 broke the TCP upcalls that the NFS server uses, such >> that intermittent hangs of NFS mounts to FreeBSD13 servers can occur. >> This has not yet been resolved in "main" etc and could explain >> why an RPC could time out for a soft mount. > > See later notes that I added: soft mount is not required > to see the problem. > >> You can revert the patch in r367492 to avoid the problem. > > If I understand right, you are indicating that this would > not apply to the non-soft mount case that I got. > >> Disabling TSO, LRO are also de-facto standard things to do when >> you observe weird NFS behaviour, because they are often broken >> in various network device drivers. > > I'll have to figure out how to experiment with such. Things > are at defaults rather generally on the systems. I'm not > literate in the subject areas. > > I'm the only user of the machines and network. It is not > outward facing. It is a rather small EtherNet network. > >> rick >> >> ____ >> From: owner-freebsd-sta...@freebsd.org on >> behalf of Rick Macklem >> Sent: Thursday, May 20, 2021 8:55 PM >> To: FreeBSD-STABLE Mailing List; Mark Millard >> Subject: Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs >> (in a zfs file systems context) >> >> Mark Millard wrote: >>> [I warn that I'm a fairly minimal user of NFS >>> mounts, not knowing all that much. I'm mostly >>> reporting this in case it ends up as evidence >>> via eventually matching up with others observing >>> possibly related oddities.] >>> >>> I got the following odd sequence (that I've >>> mixed notes into). It involved a diff -r over NFS >>> showing differences (files missing) and then a >>> later diff finding matches for the same files, >>> no file system changes made on either machine. >>> I'm unable to reproduce the oddity on demand. >>> >>> Note: A larger scope diff -r originally returned the >>> below as well, but doing the narrower diff -r did >>> repeat the result and that is what I show. (I >>> make no use of devel/ice .) >>> >>> # diff -r /usr/ports/devel/ice/files /mnt/devel/ice/files | more >>> Only in /usr/ports/devel/ice/files: Make.rules.FreeBSD > . . . >>> Only in /usr/ports/devel/ice/files: patch-scripts-TestUtil.py >>> >>> Note: The above was not expected. So I tried: >>> >>> # ls -Tld /mnt/devel/ice/files/* >>> -rw-r--r-- 1 root wheel 755 Apr 21 21:07:54 2021 >>> /mnt/devel/ice/files/Make.rules.FreeBSD > . . . >>> -rw-r--r-- 1 root wheel 2588 Apr 21 21:07:54 2021 >>> /mnt/devel/ice/files/patch-scripts-TestUtil.py >>> >>> Note: So that indicated that the files were there on the >>> machine that /mnt references. So attempting the original >>> diff -r again: >>> >>> # diff -r /usr/ports/devel/ice/files /mnt/devel/ice/files | more >>> # >>> >>> (Empty difference.) >>> >>> Note: So after the explicit "ls -Tld /mnt/devel/ice/files/*" >>> the odd result of the diff -r no longer happened: no >>> differences reported. >>> >>> >>> >>> For reference (both machines reported): >>> >>> . . . >>> The original mount command was on CA72_16Gp_ZFS: >>> >>> # mount -onoatime,soft 192.168.1.170:/usr/ports/ /mnt/ >> The likely explanation for this is your use of a "soft" mount. >> - If the NFS server is slow to respond or there is a temporary network issue, >> the RPC request can time out and then the >> syscall can fail with EINT/ETIMEDOUT. Since almost nothing, including the >> readdir(3) libc functions expect syscalls to fail this way... >> Then the cached directory is messed up. >> Doing the "ls" read the directory again and fixed the problem. >> >> Try to reproduce it for a mount without the "soft" option. >> (If a mount point is hung, due to an unresponsive server "umount -N /mnt" >> can usually get rid of it.) >> Personally, I thought "soft" was a bad idea when Sun introduced it in NFS in >> 1985 >> and I still feel that
Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in a zfs file systems context)
> On 2021-May-20, at 18:09, Rick Macklem wrote: > > Oh, one additional thing that I'll dare to top post... > r367492 broke the TCP upcalls that the NFS server uses, such > that intermittent hangs of NFS mounts to FreeBSD13 servers can occur. > This has not yet been resolved in "main" etc and could explain > why an RPC could time out for a soft mount. See later notes that I added: soft mount is not required to see the problem. > You can revert the patch in r367492 to avoid the problem. If I understand right, you are indicating that this would not apply to the non-soft mount case that I got. > Disabling TSO, LRO are also de-facto standard things to do when > you observe weird NFS behaviour, because they are often broken > in various network device drivers. I'll have to figure out how to experiment with such. Things are at defaults rather generally on the systems. I'm not literate in the subject areas. I'm the only user of the machines and network. It is not outward facing. It is a rather small EtherNet network. > rick > > ________ > From: owner-freebsd-sta...@freebsd.org on > behalf of Rick Macklem > Sent: Thursday, May 20, 2021 8:55 PM > To: FreeBSD-STABLE Mailing List; Mark Millard > Subject: Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs > (in a zfs file systems context) > > Mark Millard wrote: >> [I warn that I'm a fairly minimal user of NFS >> mounts, not knowing all that much. I'm mostly >> reporting this in case it ends up as evidence >> via eventually matching up with others observing >> possibly related oddities.] >> >> I got the following odd sequence (that I've >> mixed notes into). It involved a diff -r over NFS >> showing differences (files missing) and then a >> later diff finding matches for the same files, >> no file system changes made on either machine. >> I'm unable to reproduce the oddity on demand. >> >> Note: A larger scope diff -r originally returned the >> below as well, but doing the narrower diff -r did >> repeat the result and that is what I show. (I >> make no use of devel/ice .) >> >> # diff -r /usr/ports/devel/ice/files /mnt/devel/ice/files | more >> Only in /usr/ports/devel/ice/files: Make.rules.FreeBSD . . . >> Only in /usr/ports/devel/ice/files: patch-scripts-TestUtil.py >> >> Note: The above was not expected. So I tried: >> >> # ls -Tld /mnt/devel/ice/files/* >> -rw-r--r-- 1 root wheel 755 Apr 21 21:07:54 2021 >> /mnt/devel/ice/files/Make.rules.FreeBSD . . . >> -rw-r--r-- 1 root wheel 2588 Apr 21 21:07:54 2021 >> /mnt/devel/ice/files/patch-scripts-TestUtil.py >> >> Note: So that indicated that the files were there on the >> machine that /mnt references. So attempting the original >> diff -r again: >> >> # diff -r /usr/ports/devel/ice/files /mnt/devel/ice/files | more >> # >> >> (Empty difference.) >> >> Note: So after the explicit "ls -Tld /mnt/devel/ice/files/*" >> the odd result of the diff -r no longer happened: no >> differences reported. >> >> >> >> For reference (both machines reported): >> >> . . . >> The original mount command was on CA72_16Gp_ZFS: >> >> # mount -onoatime,soft 192.168.1.170:/usr/ports/ /mnt/ > The likely explanation for this is your use of a "soft" mount. > - If the NFS server is slow to respond or there is a temporary network issue, > the RPC request can time out and then the > syscall can fail with EINT/ETIMEDOUT. Since almost nothing, including the >readdir(3) libc functions expect syscalls to fail this way... >Then the cached directory is messed up. >Doing the "ls" read the directory again and fixed the problem. > > Try to reproduce it for a mount without the "soft" option. > (If a mount point is hung, due to an unresponsive server "umount -N /mnt" > can usually get rid of it.) > Personally, I thought "soft" was a bad idea when Sun introduced it in NFS in > 1985 > and I still feel that way. > --> If you can reproduce it without "soft" then I can't explain it. > To be honest, the directory reading/caching code in the NFSv3 client > hasn't changed significantly in literally decades, as far as I can > remember. Well . . . trying an even wider scope diff than the original . . . # umount /mnt/ # mount -onoatime 192.168.1.170:/usr/ports/ /mnt/ # diff -r /usr/ports/ /mnt/ | more Only in /mnt/databases/mongodb42/files/aarch64: patch-src_third__party_mozjs-60_ Only in /usr/ports/databases/mongodb42/files/aarch64: patch-src_th
releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in a zfs file systems context)
-ScannerConfig.h -rw-r--r-- 1 root wheel 588 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-cpp-src-Glacier2CryptPermissionsVerifier-CryptPermissionsVerifierI.cpp -rw-r--r-- 1 root wheel 384 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-cpp-src-Ice-ProxyFactory.cpp -rw-r--r-- 1 root wheel 691 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-cpp-src-IceGrid-PluginFacadeI.cpp -rw-r--r-- 1 root wheel 440 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-cpp-src-IceGrid-RegistryI.cpp -rw-r--r-- 1 root wheel 543 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-cpp-src-IceSSL-Makefile -rw-r--r-- 1 root wheel 990 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-cpp-test-Glacier2-ssl-Server.cpp -rw-r--r-- 1 root wheel 1280 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-cpp-test-Glacier2-staticFiltering-run.py -rw-r--r-- 1 root wheel 867 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-cpp-test-Ice-info-AllTests.cpp -rw-r--r-- 1 root wheel 3337 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-cpp-test-Ice-metrics-AllTests.cpp -rw-r--r-- 1 root wheel 752 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-cpp-test-Ice-objects-Makefile -rw-r--r-- 1 root wheel 730 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-cpp-test-Ice-properties-run.py -rw-r--r-- 1 root wheel 718 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-cpp-test-IceGrid-admin-run.py -rw-r--r-- 1 root wheel 8800 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-cpp-test-IceGrid-deployer-AllTests.cpp -rw-r--r-- 1 root wheel 438 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-cpp-test-IceGrid-deployer-Makefile -rw-r--r-- 1 root wheel 787 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-cpp-test-IceGrid-deployer-application.xml -rw-r--r-- 1 root wheel 997 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-cpp-test-IceGrid-distribution-AllTests.cpp -rw-r--r-- 1 root wheel 434 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-cpp-test-IceGrid-distribution-application.xml -rw-r--r-- 1 root wheel 459 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-cpp-test-IceGrid-distribution-run.py -rw-r--r-- 1 root wheel 741 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-cpp-test-IceGrid-session-run.py -rw-r--r-- 1 root wheel 1179 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-cpp-test-IceSSL-configuration-AllTests.cpp -rw-r--r-- 1 root wheel 1038 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-cpp-test-IceSSL-configuration-run.py -rw-r--r-- 1 root wheel 3490 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-cpp-test-Slice-headers-run.py -rw-r--r-- 1 root wheel 484 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-cpp-test-Slice-unicodePaths-run.py -rw-r--r-- 1 root wheel 608 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-cpp-test-include-TestCommon.h -rw-r--r-- 1 root wheel 341 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-php-Makefile -rw-r--r-- 1 root wheel 951 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-php-config-Make.rules.php -rw-r--r-- 1 root wheel 434 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-php-lib-Makefile -rw-r--r-- 1 root wheel 322 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-python-Makefile -rw-r--r-- 1 root wheel 2629 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-python-config-Make.rules -rw-r--r-- 1 root wheel 3394 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-python-modules-IcePy-Types.cpp -rw-r--r-- 1 root wheel 5092 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-python-modules-IcePy-Types.h -rw-r--r-- 1 root wheel 668 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-python-python-Makefile -rw-r--r-- 1 root wheel 2640 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-python-test-Ice-info-AllTests.py -rw-r--r-- 1 root wheel 736 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-python-test-Ice-properties-run.py -rw-r--r-- 1 root wheel 490 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-python-test-Slice-unicodePaths-run.py -rw-r--r-- 1 root wheel 381 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-scripts-Expect.py -rw-r--r-- 1 root wheel 793 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-scripts-IceGridAdmin.py -rw-r--r-- 1 root wheel 2588 Apr 21 21:07:54 2021 /mnt/devel/ice/files/patch-scripts-TestUtil.py Note: So that indicated that the files were there on the machine that /mnt references. So attempting the original diff -r again: # diff -r /usr/ports/devel/ice/files /mnt/devel/ice/files | more # (Empty difference.) Note: So after the explicit "ls -Tld /mnt/devel/ice/files/*" the odd result of the diff -r no longer happened: no differences reported. For reference (both machines reported): # uname -apKU FreeBSD CA72_16Gp_ZFS 13.0-RELEASE FreeBSD 13.0-RELEASE #0 releng/13.0-n244733-ea31abc261ff-dirty: Thu Apr 29 21:53:20 PDT 2021 root@CA72_4c8G_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300139 1300139 # ~/
Re: ENOTCAPABLE returned without Capsicum
On 2021-May-16 11:48:24 +1000, Peter Jeremy via freebsd-stable wrote: >I am running 13-stable from a couple of weeks ago, without Capsicum >(neither CAPABILITY_MODE nor CAPABILITIES are specified in my kernel). >Despite this, I am getting Capsicum-related errors. As an example: >openat(AT_FDCWD, "/") >will return ENOTCAPABLE. Please ignore. I worked out I was misreading how O_RESOLVE_BENEATH worked. -- Peter Jeremy signature.asc Description: PGP signature
ENOTCAPABLE returned without Capsicum
I am running 13-stable from a couple of weeks ago, without Capsicum (neither CAPABILITY_MODE nor CAPABILITIES are specified in my kernel). Despite this, I am getting Capsicum-related errors. As an example: openat(AT_FDCWD, "/") will return ENOTCAPABLE. Rummaging around the sources, it seems that there's a non-trivial amount of code in kern/vfs_lookup.c that's capable of returning capability-related errors but isn't protected by CAPABILITY_MODE. This seems undesirable since it means that FreeBSD is defaulting to being locked down but unless I build it with Capsicum, there's no way to change the processes capabilities. -- Peter Jeremy signature.asc Description: PGP signature
fileargs_init(3) doesn't work without CAPABILITIES (was: Re: tail(1) broken in 13-stable)
On 2021-May-06 19:07:23 -0400, monochrome wrote: ... >On 5/6/21 7:49 AM, Peter Jeremy via freebsd-stable wrote: ... >> server% tail /COPYRIGHT <&- >> Assertion failed: (procfd > STDERR_FILENO), function service_clean, file >> /usr/src/lib/libcasper/libcasper/service.c, line 394. >> tail: unable to init casper: Socket is not connected >I get a different error on a 13.0-RELEASE machine I converted from 12 to >current about a year ago (bash and sh): > >$ tail /COPYRIGHT <&- >tail: can't limit stdio rights: Bad file descriptor I've done some more testing across a number of systems and narrowed the difference in behaviour down to the presence of the CAPABILITIES option in the kernel (it looks like I never added it to my kernel config on that system): If CAPABILITIES is present then the cap_rights_limit(2) call for the closed FD fails, generating the "can't limit stdio rights" error. (Whether this behaviour is reasonable is a different issue - it was introduced in r348708, based on https://reviews.freebsd.org/D20393 and the issue of closed file descriptors doesn't seem to have been considered). If CAPABILITIES is not present then the cap_rights_limit() failure is (correctly) ignored but the subsequent fileargs_init(3) call gets upset at opening a FD <= 2. This behaviour seems wrong - if CAPABILITIES aren't present in the kernel then the userland behaviour should be the same as if WITHOUT_CASPER is specified. IMO, this is a bug in fileargs_init(3). -- Peter Jeremy signature.asc Description: PGP signature
Fresh releng/13.0 release/13.0.0 install: "newsyslog: malformed 'at' value" messages
Having used bsdinstall to make a USB3 SSD on a RPi4B (zfs-on-root, GPT parition, RPi4B materials copied copied to msdos file system), booting gets error notices: newsyslog: malformed 'at' value: /var/log/all.log600 7 *@T00 J newsyslog: malformed 'at' value: /var/log/auth.log 600 7 1000 @0101T JC newsyslog: malformed 'at' value: /var/log/daily.log 640 7 *@T00 JN newsyslog: malformed 'at' value: /var/log/maillog640 7 *@T00 JC newsyslog: malformed 'at' value: /var/log/messages 644 5 1000 @0101T JC newsyslog: malformed 'at' value: /var/log/utx.log644 3 *@01T05 B newsyslog: malformed 'at' value: /var/log/daemon.log 644 5 1000 @0101T JC It is apparently complaining about some of the content in: # more /etc/newsyslog.conf # configuration file for newsyslog # $FreeBSD$ # # Entries which do not specify the '/pid_file' field will cause the # syslogd process to be signalled when that log file is rotated. This # action is only appropriate for log files which are written to by the # syslogd process (ie, files listed in /etc/syslog.conf). If there # is no process which needs to be signalled when a given log file is # rotated, then the entry for that file should include the 'N' flag. # # Note: some sites will want to select more restrictive protections than the # defaults. In particular, it may be desirable to switch many of the 644 # entries to 640 or 600. For example, some sites will consider the # contents of maillog, messages, and lpd-errs to be confidential. In the # future, these defaults may change to more conservative ones. # # logfilename [owner:group]mode count size when flags [/pid_file] [sig_num] /var/log/all.log600 7 *@T00 J /var/log/auth.log 600 7 1000 @0101T JC /var/log/console.log600 5 1000 * J /var/log/cron 600 3 1000 * JC /var/log/daily.log 640 7 *@T00 JN /var/log/debug.log 600 7 1000 * JC /var/log/init.log 644 3 1000 * J /var/log/kerberos.log 600 7 1000 * J /var/log/maillog640 7 *@T00 JC /var/log/messages 644 5 1000 @0101T JC /var/log/monthly.log640 12*$M1D0 JN /var/log/devd.log 644 3 1000 * JC /var/log/security 600 101000 * JC /var/log/utx.log644 3 *@01T05 B /var/log/weekly.log 640 5 *$W6D0 JN /var/log/daemon.log 644 5 1000 @0101T JC /etc/newsyslog.conf.d/[!.]*.conf /usr/local/etc/newsyslog.conf.d/[!.]*.conf Specifically, the 7 lines with "@" involved under "when" get the complaints. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: tail(1) broken in 13-stable
On 2021-May-06 12:59:54 +0200, Mariusz Zaborski wrote: >Could you provide details how to reproduce this? > >On Thu, 6 May 2021 at 12:13, Peter Jeremy via freebsd-stable > wrote: >> >> Since updating from 12-stable to 13-stable, I've found that tail(1) >> crashes, reporting: >> Assertion failed: (procfd > STDERR_FILENO), function service_clean, file >> /usr/src/lib/libcasper/libcasper/service.c, line 394. >> tail: unable to init casper: Socket is not connected >> unless all three of stdin, stdout and stderr are open. Whilst it >> probably doesn't make sense to call tail without stdout open. there's >> no obvious reason to require that stdin or stderr must be open. server% tail /COPYRIGHT <&- Assertion failed: (procfd > STDERR_FILENO), function service_clean, file /usr/src/lib/libcasper/libcasper/service.c, line 394. tail: unable to init casper: Socket is not connected -- Peter Jeremy signature.asc Description: PGP signature
tail(1) broken in 13-stable
Since updating from 12-stable to 13-stable, I've found that tail(1) crashes, reporting: Assertion failed: (procfd > STDERR_FILENO), function service_clean, file /usr/src/lib/libcasper/libcasper/service.c, line 394. tail: unable to init casper: Socket is not connected unless all three of stdin, stdout and stderr are open. Whilst it probably doesn't make sense to call tail without stdout open. there's no obvious reason to require that stdin or stderr must be open. -- Peter Jeremy signature.asc Description: PGP signature
Re: zpool list -p 's FREE vs. zfs list -p's AVAIL ? FREE-AVAIL == 6_675_374_080 (199G zroot pool)
On 2021-May-5, at 17:01, Yuri Pankov wrote: > Mark Millard via freebsd-current wrote: >> Context: >> >> # gpart show -pl da0 >> => 40 468862048da0 GPT (224G) >> 40 532480 da0p1 efiboot0 (260M) >> 532520 2008 - free - (1.0M) >> 534528 25165824 da0p2 swp12a (12G) >> 25700352 25165824 da0p4 swp12b (12G) >> 50866176 417994752 da0p3 zfs0 (199G) >> 468860928 1160 - free - (580K) >> >> There is just one pool: zroot and it is on zfs0 above. >> >> # zpool list -p >> NAME SIZEALLOC FREE CKPOINT EXPANDSZ FRAG >> CAP DEDUPHEALTH ALTROOT >> zroot 213674622976 71075655680 142598967296- - 28 >> 33 1.00ONLINE - >> >> So FREE: 142_598_967_296 >> (using _ to make it more readable) >> >> # zfs list -p zroot >> NAME USED AVAIL REFER MOUNTPOINT >> zroot 71073697792 135923593216 98304 /zroot >> >> So AVAIL: 135_923_593_216 >> >> FREE-AVAIL == 6_675_374_080 >> >> >> >> The questions: >> >> Is this sort of unavailable pool-free-space normal? >> Is this some sort of expected overhead that just is >> not explicitly reported? Possibly a "FRAG" >> consequence? > > From zpoolprops(8): > > freeThe amount of free space available in the pool. By contrast, >the zfs(8) available property describes how much new data can be >written to ZFS filesystems/volumes. The zpool free property is >not generally useful for this purpose, and can be substantially >more than the zfs available space. This discrepancy is due to >several factors, including raidz parity; zfs reservation, quota, >refreservation, and refquota properties; and space set aside by >spa_slop_shift (see zfs-module-parameters(5) for more >information). Thanks for pointing to the reference material. 6_675_374_080/213_674_622_976 =approx= 0.03124 =approx= 1.0/32.0 and spa_slop_shift's description reports: QUOTE spa_slop_shift (int) Normally, we don't allow the last 3.2% (1/(2^spa_slop_shift)) of space in the pool to be consumed. This ensures that we don't run the pool completely out of space, due to unaccounted changes (e.g. to the MOS). It also limits the worst-case time to allocate space. If we have less than this amount of free space, most ZPL operations (e.g. write, create) will return ENOSPC. Default value: 5. END QUOTE So in my simple context, apparently not much else contributes and the figures are basically as expected. Thanks again. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
zpool list -p 's FREE vs. zfs list -p's AVAIL ? FREE-AVAIL == 6_675_374_080 (199G zroot pool)
Context: # gpart show -pl da0 => 40 468862048da0 GPT (224G) 40 532480 da0p1 efiboot0 (260M) 532520 2008 - free - (1.0M) 534528 25165824 da0p2 swp12a (12G) 25700352 25165824 da0p4 swp12b (12G) 50866176 417994752 da0p3 zfs0 (199G) 468860928 1160 - free - (580K) There is just one pool: zroot and it is on zfs0 above. # zpool list -p NAME SIZEALLOC FREE CKPOINT EXPANDSZ FRAGCAP DEDUPHEALTH ALTROOT zroot 213674622976 71075655680 142598967296- - 28 33 1.00ONLINE - So FREE: 142_598_967_296 (using _ to make it more readable) # zfs list -p zroot NAME USED AVAIL REFER MOUNTPOINT zroot 71073697792 135923593216 98304 /zroot So AVAIL: 135_923_593_216 FREE-AVAIL == 6_675_374_080 The questions: Is this sort of unavailable pool-free-space normal? Is this some sort of expected overhead that just is not explicitly reported? Possibly a "FRAG" consequence? For reference: # zpool status pool: zroot state: ONLINE scan: scrub repaired 0B in 00:31:48 with 0 errors on Sun May 2 19:52:14 2021 config: NAMESTATE READ WRITE CKSUM zroot ONLINE 0 0 0 da0p3 ONLINE 0 0 0 errors: No known data errors === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS rename with associated snapshot present: odd error message
On 2021-May-5, at 05:28, Mark Millard wrote: > On 2021-May-5, at 02:47, Andriy Gapon wrote: > >> On 05/05/2021 01:59, Mark Millard via freebsd-current wrote: >>> I had a: >>> # zfs list -tall >>> NAME USED AVAIL REFER MOUNTPOINT >>> . . . >>> zroot/DESTDIRs/13_0R-CA72-instwrld-norm 1.44G 117G 96K >>> /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm >>> zroot/DESTDIRs/13_0R-CA72-instwrld-norm@dirty-style 1.44G - 1.44G >>> -. . . >>> . . . >>> (copied/pasted from somewhat earlier) and then attempted: >>> # zfs rename zroot/DESTDIRs/13_0R-CA72-instwrld-norm >>> zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0 >>> cannot open 'zroot/DESTDIRs/13_0R-CA72-instwrld-norm@dirty-style': snapshot >>> delimiter '@' is not expected here >>> Despite the "cannot open" message, the result looks like: >>> # zfs list -tall >>> NAME USED AVAIL >>> REFER MOUNTPOINT >>> . . . >>> zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0 1.44G 114G >>> 96K /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt-0 >>> zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0@dirty-style 1.44G - >>> 1.44G - >>> . . . >>> Still, it leaves me wondering if everything is okay >>> given that internal attempt to use the old name with >>> @dirty-style when it was apparently no longer >>> available under that naming. >>> For reference: >>> # uname -apKU >>> FreeBSD CA72_4c8G_ZFS 13.0-RELEASE FreeBSD 13.0-RELEASE #0 >>> releng/13.0-n244733-ea31abc261ff-dirty: Thu Apr 29 21:53:20 PDT 2021 >>> root@CA72_4c8G_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 >>> arm64 aarch64 1300139 1300139 >> >> Cannot reproduce here (but with much simpler names and on stable/13): >> zfs create testz/test >> zfs snapshot testz/test@snap1 >> zfs rename testz/test testz/test2 >> >> All worked. >> > > I've noticed that sometimes in my explorations it has been > silent instead of complaining. I've no clue at this point > what prior activity (or lack of activity) makes the > difference for if a message will be generated vs. not. One difference in context is that your above sort of sequence generates the after-snapshot context (using some things I have around now): zroot/DESTDIRs/13_0R-CA53-poud 1.45G 127G 1.45G /usr/obj/DESTDIRs/13_0R-CA53-poud zroot/DESTDIRs/13_0R-CA53-poud@test 0B - 1.45G - where my example had something more like (hand edited the above just for illustration): zroot/DESTDIRs/13_0R-CA53-poud 1.45G 125G 96K /usr/obj/DESTDIRs/13_0R-CA53-poud zroot/DESTDIRs/13_0R-CA53-poud@test1.45G - 1.45G - before the rename. In other words, I'd updated the original (almost?) completely after the snapshot (as a side effect of my overall activity). It was only later that I tried the rename to track a new purpose/context that I was going to switch to. I'm not claiming that such is sufficient to (always? ever?) reproduce the message. I'm just pointing out that I'd had some significant activity on the writable file system before the rename. Some of my activity has been more like your test and I'd not seen the problems from such. But it is not a very good comparison/contrast context so I'd not infer much. I still can not at-will set up a context to produce the messages. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files? [aarch64 test did not reproduce the issue]
apshot/commited-style-0/usr/13_0R-src/arm64.aarch64/toolchain-metadata.mk > 2021-05-04 10:55:26.030179000 -0700 > +++ > /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/.zfs/snapshot/commited-style-1/usr/13_0R-src/arm64.aarch64/toolchain-metadata.mk > 2021-05-04 16:14:24.513346000 -0700 > @@ -1,4 +1,4 @@ > -.info Using cached toolchain metadata from build at CA72_4c8G_ZFS on Tue May > 4 10:55:26 PDT 2021 > +.info Using cached toolchain metadata from build at CA72_4c8G_ZFS on Tue May > 4 16:14:24 PDT 2021 > _LOADED_TOOLCHAIN_METADATA=t > COMPILER_VERSION=110001 > X_COMPILER_VERSION=110001 > > > > I may run a 'target cortex-a7 (so: armv7) from aarch64' test > next. That was the context for the original discovery and > report. > > The armv7 builds and installs get the same sort of diff results as the aarch64 ones. So it does not look like I can readily reproduce the problem files that had differences. Given the time it takes to run the experiments, I would not expect to reproduce the problem on any given timescale. I'll stop the reporting as I go along in my activities --unless I end up with a repetition of the problem. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS rename with associated snapshot present: odd error message
On 2021-May-5, at 02:47, Andriy Gapon wrote: > On 05/05/2021 01:59, Mark Millard via freebsd-current wrote: >> I had a: >> # zfs list -tall >> NAME USED AVAIL REFER MOUNTPOINT >> . . . >> zroot/DESTDIRs/13_0R-CA72-instwrld-norm 1.44G 117G 96K >> /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm >> zroot/DESTDIRs/13_0R-CA72-instwrld-norm@dirty-style 1.44G - 1.44G >> -. . . >> . . . >> (copied/pasted from somewhat earlier) and then attempted: >> # zfs rename zroot/DESTDIRs/13_0R-CA72-instwrld-norm >> zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0 >> cannot open 'zroot/DESTDIRs/13_0R-CA72-instwrld-norm@dirty-style': snapshot >> delimiter '@' is not expected here >> Despite the "cannot open" message, the result looks like: >> # zfs list -tall >> NAME USED AVAIL >> REFER MOUNTPOINT >> . . . >> zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0 1.44G 114G >> 96K /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt-0 >> zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0@dirty-style 1.44G - >> 1.44G - >> . . . >> Still, it leaves me wondering if everything is okay >> given that internal attempt to use the old name with >> @dirty-style when it was apparently no longer >> available under that naming. >> For reference: >> # uname -apKU >> FreeBSD CA72_4c8G_ZFS 13.0-RELEASE FreeBSD 13.0-RELEASE #0 >> releng/13.0-n244733-ea31abc261ff-dirty: Thu Apr 29 21:53:20 PDT 2021 >> root@CA72_4c8G_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 >> arm64 aarch64 1300139 1300139 > > Cannot reproduce here (but with much simpler names and on stable/13): > zfs create testz/test > zfs snapshot testz/test@snap1 > zfs rename testz/test testz/test2 > > All worked. > I've noticed that sometimes in my explorations it has been silent instead of complaining. I've no clue at this point what prior activity (or lack of activity) makes the difference for if a message will be generated vs. not. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files? [aarch64 test did not reproduce the issue]
N_METADATA=t COMPILER_VERSION=110001 X_COMPILER_VERSION=110001 I may run a 'target cortex-a7 (so: armv7) from aarch64' test next. That was the context for the original discovery and report. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
ZFS rename with associated snapshot present: odd error message
I had a: # zfs list -tall NAME USED AVAIL REFER MOUNTPOINT . . . zroot/DESTDIRs/13_0R-CA72-instwrld-norm 1.44G 117G 96K /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm zroot/DESTDIRs/13_0R-CA72-instwrld-norm@dirty-style 1.44G - 1.44G -. . . . . . (copied/pasted from somewhat earlier) and then attempted: # zfs rename zroot/DESTDIRs/13_0R-CA72-instwrld-norm zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0 cannot open 'zroot/DESTDIRs/13_0R-CA72-instwrld-norm@dirty-style': snapshot delimiter '@' is not expected here Despite the "cannot open" message, the result looks like: # zfs list -tall NAME USED AVAIL REFER MOUNTPOINT . . . zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0 1.44G 114G 96K /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt-0 zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0@dirty-style 1.44G - 1.44G - . . . Still, it leaves me wondering if everything is okay given that internal attempt to use the old name with @dirty-style when it was apparently no longer available under that naming. For reference: # uname -apKU FreeBSD CA72_4c8G_ZFS 13.0-RELEASE FreeBSD 13.0-RELEASE #0 releng/13.0-n244733-ea31abc261ff-dirty: Thu Apr 29 21:53:20 PDT 2021 root@CA72_4c8G_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300139 1300139 === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files? [Ignore recent test: -dirty vs. checked-in usage difference]
[The first buidlworld is still in process. So while waiting . . .] On 2021-May-4, at 10:31, Mark Millard wrote: > I probably know why the huge count of differences this time > unlike the original report . . . > > Previously I built based on a checked-in branch as part of > my experimenting. This time it was in a -dirty form (not > checked in), again as part of my experimental exploration. > > WITH_REPRODUCIBLE_BUILD= makes a distinction between these > if I remember right: (partially?) disabling itself for > -dirty style. > > To reproduce the original style of test I need to create > a branch with my few patches checked in and do the > buildworlds from that branch. > > This will, of course, take a while. > > Sorry for the noise. > I've confirmed some of the details of the large number of files with difference while waiting for the 1st buildworld : The 4 bytes at the end of the .gnu_debuglink section that are ending up different are the checksum for the .debug file. The .debug files have differences such as: │ -<1a> DW_AT_comp_dir: (indirect string) /usr/obj/BUILDs/13_0R-CA72-nodbg-clang-alt/usr/13_0R-src/arm64.aarch64/lib/csu/aarch64 │ +<1a> DW_AT_comp_dir: (indirect string) /usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/lib/csu/aarch64 So I need to build, snapshot (in case need to reference), install, clean-out, build, install elsewhere, compare. (Or analogous that uses the same build base-path for both installs despite separate buildworld's.) This is separate from any potential -dirty vs. checked-in handling variation by WITH_REPRODUCIBLE_BUILD= . My process that produced the original armv7 report happened to do that before I accidentally discovered the presence of the few files with differences. My new experiments were different and I'd not though of needing to vary the procedure to get you the right evidence. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
diffoscope's odd UnicodeDecodeError error message: reason found
I had reported in the reproducable build list messages:
> # diffoscope /.zfs/snapshot/2021-04-*-01:40:48-0/bin/sh
> [...]
> $<3/>2021-05-04 08:49:21 W: diffoscope.main: Fuzzy-matching is currently
> disabled as the "tlsh" module is unavailable.
> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb7 in position 18:
> invalid start byte
Well, it turns out that the file name pattern was
incorrect and only matched one file.
By contrast:
# diffoscope /.zfs/snapshot/2021-04-*/bin/sh
$<3/>2021-05-04 11:05:25 W: diffoscope.main: Fuzzy-matching is currently
disabled as the "tlsh" module is unavailable.
worked fine.
And making the "one file" status obvious:
# diffoscope c_tests/a.out
$<3/>2021-05-04 11:11:45 W: diffoscope.main: Fuzzy-matching is currently
disabled as the "tlsh" module is unavailable.
$<3/>Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/diffoscope/main.py", line 745,
in main
sys.exit(run_diffoscope(parsed_args))
File "/usr/local/lib/python3.7/site-packages/diffoscope/main.py", line 677,
in run_diffoscope
difference = load_diff_from_path(path1)
File "/usr/local/lib/python3.7/site-packages/diffoscope/readers/__init__.py",
line 31, in load_diff_from_path
return load_diff(codecs.getreader("utf-8")(fp), path)
File "/usr/local/lib/python3.7/site-packages/diffoscope/readers/__init__.py",
line 35, in load_diff
return JSONReaderV1().load(fp, path)
File "/usr/local/lib/python3.7/site-packages/diffoscope/readers/json.py",
line 33, in load
raw = json.load(fp)
File "/usr/local/lib/python3.7/json/__init__.py", line 293, in load
return loads(fp.read(),
File "/usr/local/lib/python3.7/codecs.py", line 504, in read
newchars, decodedbytes = self.decode(data, self.errors)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb7 in position 18:
invalid start byte
Not exactly an obvious error message for the issue.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
_______
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files? [Ignore recent test: -dirty vs. checked-in usage difference]
I probably know why the huge count of differences this time unlike the original report . . . Previously I built based on a checked-in branch as part of my experimenting. This time it was in a -dirty form (not checked in), again as part of my experimental exploration. WITH_REPRODUCIBLE_BUILD= makes a distinction between these if I remember right: (partially?) disabling itself for -dirty style. To reproduce the original style of test I need to create a branch with my few patches checked in and do the buildworlds from that branch. This will, of course, take a while. Sorry for the noise. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files?
00 0 0 1 > 50c4-50b8 == 0xC Note: 0xC+0x4 == 0x10 (the size), so the last 4 bytes of .gnu_debuglink > For all I know, some individual byte(s) in the 4 might accidentally > match sometimes. The addition offset after .gnu_debuglink's file > offset does vary (0xC and 0x10 above). Specifically: the last 4 bytes of the .gnu_debuglink section. > The content of those differences do not look like > file path components, for example the 0x08 byte. > > I do build with: > > # Avoid stripping but do not control host -g status as well: > DEBUG_FLAGS+= > # > WITH_REPRODUCIBLE_BUILD= > WITH_DEBUG_FILES= > > But that was true for the earlier armv7 target example > that I reported that only got a few files with > differences. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files?
0003bc8 == 0xC # cmp -x /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/chflags /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/chflags 2208 88 a1 2209 e6 40 220a 60 94 220b bf ce # ls -Tld /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/chflags /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/chflags -r-xr-xr-x 1 root wheel 11440 May 4 08:55:01 2021 /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/chflags -r-xr-xr-x 1 root wheel 11440 May 3 23:16:36 2021 /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/chflags Sections: Idx Name Size VMA LMA File off Algn . . . 25 .gnu_debuglink 0014 21f8 2**0 CONTENTS, READONLY 2208-21f8 == 0x10 # cmp -x /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/chio /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/chio 50c4 6b 3e 50c5 08 ca 50c6 7a 2f 50c7 5d 64 # ls -Tld /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/chio /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/chio -r-xr-xr-x 1 root wheel 23728 May 4 08:55:01 2021 /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt/bin/chio -r-xr-xr-x 1 root wheel 23728 May 3 23:16:37 2021 /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm/bin/chio Sections: Idx Name Size VMA LMA File off Algn . . . 25 .gnu_debuglink 0010 50b8 2**0 CONTENTS, READONLY 50c4-50b8 == 0xC For all I know, some individual byte(s) in the 4 might accidentally match sometimes. The addition offset after .gnu_debuglink's file offset does vary (0xC and 0x10 above). The content of those differences do not look like file path components, for example the 0x08 byte. I do build with: # Avoid stripping but do not control host -g status as well: DEBUG_FLAGS+= # WITH_REPRODUCIBLE_BUILD= WITH_DEBUG_FILES= But that was true for the earlier armv7 target example that I reported that only got a few files with differences. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files?
On 2021-May-4, at 06:01, Ed Maste wrote:
> On Mon, 3 May 2021 at 22:26, Mark Millard wrote:
>>
>> But I'll note that I've built and stalled py37-diffoscope
>> (new to me). A basic quick test showed that it reports:
>>
>> W: diffoscope.main: Fuzzy-matching is currently disabled as the "tlsh"
>> module is unavailable.
>
> I just looked up tlsh - its "A Locality Sensitive Hash"; I presume
> diffoscope uses it to infer file renames. I believe the warning
> emitted here should have no impact on the output we're looking for.
Okay.
> As far as the utf-8 issues go, diffoscope requires a utf-8 locale and
> I suspect that is the issue. If you don't have LANG set already, try
> setting LANG=C.UTF-8 in your environment.
That is not the issue for the UnicodeDecodeError:
# echo $LANG
C.UTF-8
# diffoscope /.zfs/snapshot/2021-04-*-01:40:48-0/bin/sh
$<3/>2021-05-04 08:49:21 W: diffoscope.main: Fuzzy-matching is currently
disabled as the "tlsh" module is unavailable.
$<3/>Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/diffoscope/main.py", line 745,
in main
sys.exit(run_diffoscope(parsed_args))
File "/usr/local/lib/python3.7/site-packages/diffoscope/main.py", line 677,
in run_diffoscope
difference = load_diff_from_path(path1)
File "/usr/local/lib/python3.7/site-packages/diffoscope/readers/__init__.py",
line 31, in load_diff_from_path
return load_diff(codecs.getreader("utf-8")(fp), path)
File "/usr/local/lib/python3.7/site-packages/diffoscope/readers/__init__.py",
line 35, in load_diff
return JSONReaderV1().load(fp, path)
File "/usr/local/lib/python3.7/site-packages/diffoscope/readers/json.py",
line 33, in load
raw = json.load(fp)
File "/usr/local/lib/python3.7/json/__init__.py", line 293, in load
return loads(fp.read(),
File "/usr/local/lib/python3.7/codecs.py", line 504, in read
newchars, decodedbytes = self.decode(data, self.errors)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb7 in position 18:
invalid start byte
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files?
On 2021-May-3, at 21:27, Mark Millard wrote:
> On 2021-May-3, at 19:26, Mark Millard wrote:
>
>> On 2021-May-3, at 10:51, Mark Millard wrote:
>>
>>> On 2021-May-3, at 07:47, Ed Maste wrote:
>>>
>>>> On Thu, 29 Apr 2021 at 02:50, Mark Millard via freebsd-current
>>>> wrote:
>>>>>
>>>>> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping and
>>>>> /usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping differ
>>>>> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping6 and
>>>>> /usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping6 differ
>>>>> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/usr/bin/ntpq and
>>>>> /usr/obj/DESTDIRs/13_0R-CA7-poud/usr/bin/ntpq differ...
>>>>
>>>> This is unexpected. Unfortunately I haven't looked at reproducibility
>>>> in a while, and my work was all on x86. This could be a regression or
>>>> a longstanding issue with arm64.
>>>>
>>>> If you install the diffoscope package (py37-diffoscope) and run it on
>>>> the two directories / files it should give a more convenient view of
>>>> the differences. (Or, if you can make a tarball of the differing files
>>>> I can take a look.)
>>>
>>> I no longer have the same content in those directory
>>> trees: newer rebuild and the same buildworld used to
>>> installworld to both places, instead of 2 different
>>> buildworld's. I'm also unsure how reproducible getting
>>> differences was.
>>>
>>> I can eventually do experiments to test multiple separate
>>> buildworld's and installworld's, but the machine is busy
>>> building ports and the llvm builds involved means it
>>> will be some time before I'd switch activities. And the
>>> buildworld's involve llvm builds as well and take notable
>>> time themselves. So my next comparison will not be any
>>> time soon.
>>>
>>> I'll let you know if I manage to generate another example,
>>> this time being sure to keep the data. If I try multiple
>>> times without finding any differences, I'll eventually
>>> decide "enough is enough" and let you know.
>>
>> I've still got a long ways to go to do the first
>> actual comparison of builds.
>>
>> But I'll note that I've built and stalled py37-diffoscope
>> (new to me). A basic quick test showed that it reports:
>>
>> W: diffoscope.main: Fuzzy-matching is currently disabled as the "tlsh"
>> module is unavailable.
>>
>> As I'm not familiar with the tool, you might need to send
>> notes about how you want me to use the tool to get the
>> output that you would want. (And, so, I get to learn . . .)
>
> I've tried another experiment (* in the path matches "28" and "30"):
>
> # diffoscope /.zfs/snapshot/2021-04-*-01:40:48-0/bin/sh
> $<3/>2021-05-03 21:08:48 W: diffoscope.main: Fuzzy-matching is currently
> disabled as the "tlsh" module is unavailable.
> $<3/>Traceback (most recent call last):
> File "/usr/local/lib/python3.7/site-packages/diffoscope/main.py", line 745,
> in main
>sys.exit(run_diffoscope(parsed_args))
> File "/usr/local/lib/python3.7/site-packages/diffoscope/main.py", line 677,
> in run_diffoscope
>difference = load_diff_from_path(path1)
> File
> "/usr/local/lib/python3.7/site-packages/diffoscope/readers/__init__.py", line
> 31, in load_diff_from_path
>return load_diff(codecs.getreader("utf-8")(fp), path)
> File
> "/usr/local/lib/python3.7/site-packages/diffoscope/readers/__init__.py", line
> 35, in load_diff
>return JSONReaderV1().load(fp, path)
> File "/usr/local/lib/python3.7/site-packages/diffoscope/readers/json.py",
> line 33, in load
>raw = json.load(fp)
> File "/usr/local/lib/python3.7/json/__init__.py", line 293, in load
>return loads(fp.read(),
> File "/usr/local/lib/python3.7/codecs.py", line 504, in read
>newchars, decodedbytes = self.decode(data, self.errors)
> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb7 in position 18:
> invalid start byte
>
> The two older snapshots of a Boot Environment have
> bin/sh files that compare equal. But every program I
> tried the above sort of thing against on got the same
> UnicodeDecodeError result from diffoscope, byte value
> and position matching.
>
> These snapshots have more than an installworld in them
> and so are messy to compare overall. But the
> installworld (and
Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files?
On 2021-May-3, at 19:26, Mark Millard wrote:
> On 2021-May-3, at 10:51, Mark Millard wrote:
>
>> On 2021-May-3, at 07:47, Ed Maste wrote:
>>
>>> On Thu, 29 Apr 2021 at 02:50, Mark Millard via freebsd-current
>>> wrote:
>>>>
>>>> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping and
>>>> /usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping differ
>>>> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping6 and
>>>> /usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping6 differ
>>>> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/usr/bin/ntpq and
>>>> /usr/obj/DESTDIRs/13_0R-CA7-poud/usr/bin/ntpq differ...
>>>
>>> This is unexpected. Unfortunately I haven't looked at reproducibility
>>> in a while, and my work was all on x86. This could be a regression or
>>> a longstanding issue with arm64.
>>>
>>> If you install the diffoscope package (py37-diffoscope) and run it on
>>> the two directories / files it should give a more convenient view of
>>> the differences. (Or, if you can make a tarball of the differing files
>>> I can take a look.)
>>
>> I no longer have the same content in those directory
>> trees: newer rebuild and the same buildworld used to
>> installworld to both places, instead of 2 different
>> buildworld's. I'm also unsure how reproducible getting
>> differences was.
>>
>> I can eventually do experiments to test multiple separate
>> buildworld's and installworld's, but the machine is busy
>> building ports and the llvm builds involved means it
>> will be some time before I'd switch activities. And the
>> buildworld's involve llvm builds as well and take notable
>> time themselves. So my next comparison will not be any
>> time soon.
>>
>> I'll let you know if I manage to generate another example,
>> this time being sure to keep the data. If I try multiple
>> times without finding any differences, I'll eventually
>> decide "enough is enough" and let you know.
>
> I've still got a long ways to go to do the first
> actual comparison of builds.
>
> But I'll note that I've built and stalled py37-diffoscope
> (new to me). A basic quick test showed that it reports:
>
> W: diffoscope.main: Fuzzy-matching is currently disabled as the "tlsh" module
> is unavailable.
>
> As I'm not familiar with the tool, you might need to send
> notes about how you want me to use the tool to get the
> output that you would want. (And, so, I get to learn . . .)
I've tried another experiment (* in the path matches "28" and "30"):
# diffoscope /.zfs/snapshot/2021-04-*-01:40:48-0/bin/sh
$<3/>2021-05-03 21:08:48 W: diffoscope.main: Fuzzy-matching is currently
disabled as the "tlsh" module is unavailable.
$<3/>Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/diffoscope/main.py", line 745,
in main
sys.exit(run_diffoscope(parsed_args))
File "/usr/local/lib/python3.7/site-packages/diffoscope/main.py", line 677,
in run_diffoscope
difference = load_diff_from_path(path1)
File "/usr/local/lib/python3.7/site-packages/diffoscope/readers/__init__.py",
line 31, in load_diff_from_path
return load_diff(codecs.getreader("utf-8")(fp), path)
File "/usr/local/lib/python3.7/site-packages/diffoscope/readers/__init__.py",
line 35, in load_diff
return JSONReaderV1().load(fp, path)
File "/usr/local/lib/python3.7/site-packages/diffoscope/readers/json.py",
line 33, in load
raw = json.load(fp)
File "/usr/local/lib/python3.7/json/__init__.py", line 293, in load
return loads(fp.read(),
File "/usr/local/lib/python3.7/codecs.py", line 504, in read
newchars, decodedbytes = self.decode(data, self.errors)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb7 in position 18:
invalid start byte
The two older snapshots of a Boot Environment have
bin/sh files that compare equal. But every program I
tried the above sort of thing against on got the same
UnicodeDecodeError result from diffoscope, byte value
and position matching.
These snapshots have more than an installworld in them
and so are messy to compare overall. But the
installworld (and installkernel) content show similar
differences to what I reported before as far as
example files with differences go. But this is aarch64,
not armv7.
It will still be notable time before I have simple
installworld tree's to compare.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files?
On 2021-May-3, at 10:51, Mark Millard wrote: > On 2021-May-3, at 07:47, Ed Maste wrote: > >> On Thu, 29 Apr 2021 at 02:50, Mark Millard via freebsd-current >> wrote: >>> >>> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping and >>> /usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping differ >>> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping6 and >>> /usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping6 differ >>> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/usr/bin/ntpq and >>> /usr/obj/DESTDIRs/13_0R-CA7-poud/usr/bin/ntpq differ... >> >> This is unexpected. Unfortunately I haven't looked at reproducibility >> in a while, and my work was all on x86. This could be a regression or >> a longstanding issue with arm64. >> >> If you install the diffoscope package (py37-diffoscope) and run it on >> the two directories / files it should give a more convenient view of >> the differences. (Or, if you can make a tarball of the differing files >> I can take a look.) > > I no longer have the same content in those directory > trees: newer rebuild and the same buildworld used to > installworld to both places, instead of 2 different > buildworld's. I'm also unsure how reproducible getting > differences was. > > I can eventually do experiments to test multiple separate > buildworld's and installworld's, but the machine is busy > building ports and the llvm builds involved means it > will be some time before I'd switch activities. And the > buildworld's involve llvm builds as well and take notable > time themselves. So my next comparison will not be any > time soon. > > I'll let you know if I manage to generate another example, > this time being sure to keep the data. If I try multiple > times without finding any differences, I'll eventually > decide "enough is enough" and let you know. I've still got a long ways to go to do the first actual comparison of builds. But I'll note that I've built and stalled py37-diffoscope (new to me). A basic quick test showed that it reports: W: diffoscope.main: Fuzzy-matching is currently disabled as the "tlsh" module is unavailable. As I'm not familiar with the tool, you might need to send notes about how you want me to use the tool to get the output that you would want. (And, so, I get to learn . . .) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files?
On 2021-May-3, at 07:47, Ed Maste wrote: > On Thu, 29 Apr 2021 at 02:50, Mark Millard via freebsd-current > wrote: >> >> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping and >> /usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping differ >> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping6 and >> /usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping6 differ >> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/usr/bin/ntpq and >> /usr/obj/DESTDIRs/13_0R-CA7-poud/usr/bin/ntpq differ... > > This is unexpected. Unfortunately I haven't looked at reproducibility > in a while, and my work was all on x86. This could be a regression or > a longstanding issue with arm64. > > If you install the diffoscope package (py37-diffoscope) and run it on > the two directories / files it should give a more convenient view of > the differences. (Or, if you can make a tarball of the differing files > I can take a look.) I no longer have the same content in those directory trees: newer rebuild and the same buildworld used to installworld to both places, instead of 2 different buildworld's. I'm also unsure how reproducible getting differences was. I can eventually do experiments to test multiple separate buildworld's and installworld's, but the machine is busy building ports and the llvm builds involved means it will be some time before I'd switch activities. And the buildworld's involve llvm builds as well and take notable time themselves. So my next comparison will not be any time soon. I'll let you know if I manage to generate another example, this time being sure to keep the data. If I try multiple times without finding any differences, I'll eventually decide "enough is enough" and let you know. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Slow iSCSI discovery on boot halting the boot process.
On 2021-04-30 11:12, Arrigo Marchiori via freebsd-stable wrote: > On Fri, Apr 30, 2021 at 10:29:33AM +0200, Andrea Brancatelli via > freebsd-stable wrote: > >> Hello, >> >> I'm having an annoying problem with FreeBSD 12.2-RELEASE-p6, iscsid, >> geom multiparty, a Dell MD3200i and fstab. >> >> Long story short, iSCSI login/connection/whatever is slower than the >> boot process and the machine always get stuck with "cannot find >> /san_storage (/dev/multipath/...) please enter /bin/sh location" > > Did you try putting in /boot/loader.conf: > kern.cam.boot_delay=1 > > It should wait for 10 seconds before attempting to mount the root > partition. OK, I've put it in /boot/loader.conf, let's see if it helps. Unfortunately it's a production machine so I cannot reboot it now to try it. Thanks for the suggestion. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Slow iSCSI discovery on boot halting the boot process.
Hello, On Fri, Apr 30, 2021 at 10:29:33AM +0200, Andrea Brancatelli via freebsd-stable wrote: > Hello, > > I'm having an annoying problem with FreeBSD 12.2-RELEASE-p6, iscsid, > geom multiparty, a Dell MD3200i and fstab. > > Long story short, iSCSI login/connection/whatever is slower than the > boot process and the machine always get stuck with "cannot find > /san_storage (/dev/multipath/...) please enter /bin/sh location" Did you try putting in /boot/loader.conf: kern.cam.boot_delay=1 It should wait for 10 seconds before attempting to mount the root partition. This solves the issue for me on certain embedded systems, and when trying to boot from cheap USB pen drives. I hope this helps. Best regards, -- Arrigo _______ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Slow iSCSI discovery on boot halting the boot process.
On 2021-04-30 10:29, Andrea Brancatelli via freebsd-stable wrote: > Hello, > > I'm having an annoying problem with FreeBSD 12.2-RELEASE-p6, iscsid, > geom multiparty, a Dell MD3200i and fstab. Geom multiparty is probably the best typo/autocorrect ever. --- Andrea Brancatelli ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Slow iSCSI discovery on boot halting the boot process.
Hello,
I'm having an annoying problem with FreeBSD 12.2-RELEASE-p6, iscsid,
geom multiparty, a Dell MD3200i and fstab.
Long story short, iSCSI login/connection/whatever is slower than the
boot process and the machine always get stuck with "cannot find
/san_storage (/dev/multipath/...) please enter /bin/sh location"
Usually we just press enter, press control-d, and the boot process
continues.
The problem is that the machine cannot boot unattended.
Those are some cfg files:
[root@arsenico ~]# cat /etc/fstab
# Device Mountpoint FStype Options Dump Pass#
/dev/mirror/gm0s1a / ufs rw 1 1
/dev/mirror/gm0s1b none swap sw 0 0
md98 none swap sw,file=/usr/swap1,late 0 0
md99 none swap sw,file=/usr/swap0,late 0 0
/dev/mirror/gm0s1d /var ufs rw 2 2
/dev/mirror/gm0s1e /tmp ufs rw 2 2
/dev/mirror/gm0s1f /usr ufs rw 2 2
/dev/mirror/gm0s1g /repository ufs rw 2 2
fdesc /dev/fd fdescfs rw 0 0
/dev/multipath/Krypton /san_storage ufs rw,late 0 0
As you see the filesystem is already flagged as "late"...
[root@arsenico ~]# cat /etc/iscsi.conf
Krypton_C0_P0 {
TargetName=iqn.1984-05.com.dell:powervault.md3200i.6782bcb0007496a24f1e49ee
TargetAddress=10.40.3.200
}
That's the SAN, we dropped the dual connection so maybe we could get rid
of geom_multipath if that is the problem, but... hey...
[root@arsenico ~]# gmultipath list
Geom name: Krypton
Type: AUTOMATIC
Mode: Active/Active
UUID: 101b1867-c623-11e8-8bab-90e2ba021650
State: DEGRADED
Providers:
1. Name: multipath/Krypton
Mediasize: 15998753177088 (15T)
Sectorsize: 512
Mode: r1w1e1
State: DEGRADED
Consumers:
1. Name: da2
Mediasize: 15998753177600 (15T)
Sectorsize: 512
Mode: r2w2e2
State: ACTIVE
[root@arsenico ~]# camcontrol devlist
at scbus0 target 5 lun 0 (pass0,da0)
at scbus0 target 6 lun 0 (pass1,da1)
at scbus3 target 0 lun 0 (cd0,pass2)
at scbus5 target 0 lun 0 (da2,pass3)
at scbus5 target 0 lun 1f (da3,pass4)
Any interesting suggestions?
Thanks a lot.
--
Andrea Brancatelli
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FYI: WITH_REPRODUCIBLE_BUILD= problem for some files?
I did 2 test buildworld's based on: # ~/fbsd-based-on-what-freebsd.sh branch: releng/13.0 merge-base: ea31abc261ffc01b6ff5671bffb15cf910a07f4b merge-base: CommitDate: 2021-04-09 00:14:30 + ea31abc261ff (HEAD -> releng/13.0, tag: release/13.0.0, freebsd/releng/13.0) 13.0: update to RELEASE n244733 (--first-parent --count for merge-base) and produced separate build trees. I also installed the world build into two separate directory trees: /usr/obj/DESTDIRs/13_0R-CA7-chroot/ vs. /usr/obj/DESTDIRs/13_0R-CA7-poud/ This was for other reasons. But eventually I happened to do a diff -rq of the two trees and ended up with the output showing some differing files: Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping and /usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping differ Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping6 and /usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping6 differ Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/usr/bin/ntpq and /usr/obj/DESTDIRs/13_0R-CA7-poud/usr/bin/ntpq differ Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/usr/lib/debug/sbin/ping.debug and /usr/obj/DESTDIRs/13_0R-CA7-poud/usr/lib/debug/sbin/ping.debug differ Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/usr/lib/debug/usr/sbin/ntpd.debug and /usr/obj/DESTDIRs/13_0R-CA7-poud/usr/lib/debug/usr/sbin/ntpd.debug differ Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/usr/lib/debug/usr/tests/sbin/ping/in_cksum_test.debug and /usr/obj/DESTDIRs/13_0R-CA7-poud/usr/lib/debug/usr/tests/sbin/ping/in_cksum_test.debug differ Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/usr/sbin/ntp-keygen and /usr/obj/DESTDIRs/13_0R-CA7-poud/usr/sbin/ntp-keygen differ Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/usr/sbin/ntpd and /usr/obj/DESTDIRs/13_0R-CA7-poud/usr/sbin/ntpd differ Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/usr/sbin/ntpdate and /usr/obj/DESTDIRs/13_0R-CA7-poud/usr/sbin/ntpdate differ Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/usr/sbin/ntpdc and /usr/obj/DESTDIRs/13_0R-CA7-poud/usr/sbin/ntpdc differ Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/usr/sbin/sntp and /usr/obj/DESTDIRs/13_0R-CA7-poud/usr/sbin/sntp differ Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/usr/tests/sbin/ping/in_cksum_test and /usr/obj/DESTDIRs/13_0R-CA7-poud/usr/tests/sbin/ping/in_cksum_test differ (That is all.) For as much as I've looked at (not much), it looks to be variations in byte-padding values. The builds both were set up to tune for cortex-a7 explicitly. I patch top's source code. I patch the OOM kill code to report the specific reason for a kill. I still have some bcm2838 pci/xhci patching in place from an old investigation, but that would be kernel code. None of the patching is specific to the above list of files. The hosting context was: # uname -apKU FreeBSD CA72_4c8G_ZFS 13.0-RELEASE FreeBSD 13.0-RELEASE #1 releng/13.0-n244733-ea31abc261ff-dirty: Wed Apr 28 05:45:27 PDT 2021 root@CA72_4c8G_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300139 1300139 based on building the same source code (tuning for cortex-a72). It was the same media for all the activity. Unlike the past many years for me, the context is using ZFS instead of UFS, not that I think that makes a difference here. The differences do not mess up my activity but others might notice and care about such differences. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Updated to 13-STABLE in VirtualBox; on shutdown stuck after uhub[01] being detached
(Changed my email address to the one I used to subscribe to the mailing list.) On Wed, Apr 28, 2021 at 10:05 AM Guido Falsi wrote: Hi, On 28/04/21 00:12, parv wrote: > > I had updated FreeBSD, in VirtualBox 5.22 on Windows with EFI, from > > 12-STABLE > > to 13-STABLE; upgraded the ZFS pools & the EFI boot loader. Currently > > testing with 13 GENERIC kernel. > > You mean you enabled EFI inside virtualbox? Why do you need that? For testing if FreeBSD can boot with EFI (with ZFS-on-root) ... one day I may just install the thing directly on a disk, outside of a virtual machine ... one day! > EFI > support in VirtualBox is experimental and is available for OSes unable > to boot without EFI. FreeBSD is perfectly able to boot in virtualbox > without EFI so no need for it. > I am aware. > > Now on shutdown, "shutdown -p now" (in single user mode, after manually > > unmounting > > ZFS datasets [...] the shutting down process gets stuck, > > and CPU use jumps to 80% > ... > > In the end I chose "Power Off" from VirutalBox menu. "Reset" reboots the > > machine. > > None of these have any effect ... > >- Send the shutdown signal > >- ACPI Shutdown > > > > Help please. > Solved the issue via ... % sysctl hw.efi.poweroff=0 ... after that shudown went on as expected. Got that from ... https://forums.freebsd.org/threads/freebsd-13-does-not-shut-down-my-laptop.79853/ NOt sure even which further information to ask about this, but to be > sure I understand correctly, FreeBSD is the guest here, correct? Yes, FreeBSD is the guest on Windows 10 host. - parv _______ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Updated to 13-STABLE in VirtualBox; on shutdown stuck after uhub[01] being detached
On 28/04/21 00:12, parv wrote: Hi there, I had updated FreeBSD, in VirtualBox 5.22 on Windows with EFI, from 12-STABLE to 13-STABLE; upgraded the ZFS pools & the EFI boot loader. Currently testing with 13 GENERIC kernel. You mean you enabled EFI inside virtualbox? Why do you need that? EFI support in VirtualBox is experimental and is available for OSes unable to boot without EFI. FreeBSD is perfectly able to boot in virtualbox without EFI so no need for it. Now I understand reconfiguring the VM to not use EFI can be annoying, but you should really verify if the problem goes away without EFI. Also can you try installing another FreeBSD VM and verify the problem happens for that one too? This could help understand if the problem is with virtualization or specific to the VM. Now on shutdown, "shutdown -p now" (in single user mode, after manually unmounting ZFS datasets via "zfs unmount -a"), the shutting down process gets stuck, and CPU use jumps to 80% (Intel i5 6300U, 3 CPUs given to VM, of Thinkpad X260). Last few lines are ... ... All buffers synced. Uptime: uhub0: detached uhub1: detached In the end I chose "Power Off" from VirutalBox menu. "Reset" reboots the machine. None of these have any effect ... - Send the shutdown signal - ACPI Shutdown Help please. NOt sure even which further information to ask about this, but to be sure I understand correctly, FreeBSD is the guest here, correct? -- Guido Falsi ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: iPhone tethering not working
> 在 2021年4月25日，23:04，Li-Wen Hsu 写道： > > On Sun, Apr 25, 2021 at 9:55 PM 宋立杰 wrote: >> >> Yes, there is no ue0. And I made a mistake, it is 12.2-RELEASE other than >> STABLE. Sorry for that. Do I need to install STABLE to keep up with the >> newest development? >> >> This time usbmuxd works, but why it has to run in foreground? And what’s the >> difference to usb_config? >> And running in background, I can get DHCP offer this time, but I still can’t >> ping to any website, “The network is down”. Why? >> >> Best wishes, >> A BSD newbie > > Please don't forget CC the list unless there is sensitive information, > the discussion may also help others. > > For iOS 14, that patch is needed so if Apple did the same change in > the newer iOS 13 branch, upgrading to 12.2-STABLE is necessary. You > can also upgrade to 13.0-RELEASE if you want to keep tracking > -RELEASE. > > You can exit usbmuxd when you see ue0 is available. TBH I don't check > the details in those tools. > > If you can get an IP from DHCP, but cannot do any transmission, that's > exactly the same behavior on iOS 14 without that patch so upgrading to > a newer version might help. > > Best, > Li-Wen Sorry, I made another mistake , this is my first time to use a mailing list. Applying the 12.2-RELEASE-p6 patch doesn’t seem to work, how can I transfer to 12.2-STABLE? Best wishes, A BSD newbie _______ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: (D29934) Reorder commented steps in UPDATING following sequential order. (was: etcupdate -p vs. root on zfs (and bectl use and such): no /usr/src/etc/master.passwd (for example))
On 2021-Apr-25, at 08:14, Graham Perrin wrote: > On 23/04/2021 08:39, Mark Millard via freebsd-current wrote: > >> [3] > > > With regard to mounting ZFS file systems in single user mode > > What's currently footnote 3 will probably become footnote 4, please see: > > <https://reviews.freebsd.org/D29934#inline-186101> > > … and so on. If it were me, I'd probably do something to make the mounting of file systems and such have an explicit reminder as its own step, something like: [4] mergemaster -Fp [5] I just do not think of such as part of : it is already rebooted in single user at that point in my view. Sorry that I missed what was there in UPDATING. However, /usr/src/Makefile has: # 1. `cd /usr/src' (or to the directory containing your source tree). # 2. `make buildworld' # 3. `make buildkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). # 4. `make installkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). # [steps 3. & 4. can be combined by using the "kernel" target] # 5. `reboot'(in single user mode: boot -s from the loader prompt). # 6. `mergemaster -p' # 7. `make installworld' # 8. `mergemaster'(you may wish to use -i, along with -U or -F). # 9. `make delete-old' # 10. `reboot' # 11. `make delete-old-libs' (in case no 3rd party program uses them anymore) without such material, even in footnotes. Side notes: "From the bootblocks, boot -s, and then do": "From the boot loader, boot -s, and then do"? etcupdate vs. mergemaster and the $FreeBSD$ issue? Is mergemaster going to stay as the recommented command to use? If so, with which command line options? === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 13.0 terrible performance in KVM
Hello, I have reinstalled it with GPT/ZFS and your right it's much better. Same search taking 3-6 seconds so I have deleted now all my old UFS based FreeBSD images. I wonder how I didn't notice this earlier because I had 12.0, 12.2 base images and now that I retested them they had the exact same issues. I guess after the stuff is loaded into memory it doesn't matter anymore. This must be something related to the virtual disk access. I was not thinking on using ZFS due to the higher memory recommendations, some of these VMs I using them for tiny tasks like DNS server and I don't give them more than 256, 512MB of ram. Also I don't take advantage of snapshotting either since it's a VM and it's either snapshotted or I just have base images and copy them when creating new VMs. Well UFS is on it's way out anyway. ‐‐‐ Original Message ‐‐‐ On Saturday, April 24, 2021 3:03 PM, Jeff Love j...@burgh.net wrote: > I'm running 12.2 and 13.0 on KVM using virtio and zfs. I am not having > disk I/O issues. > Jeff Love > On 4/24/21 5:25 AM, dashdruid via freebsd-stable wrote: > >> Hello List, >> I hope some other folks out there running FreeBSD on KVM as well. I set up a >> base VM while doing so I noticed that the disk operations are very slow. >> Many times I edit a file in vim or try to run a command there is a huge lag. >> I use UFS as the root filesystem. To have something to compare it with I >> have tested it against an OpenBSD 6.6 VM on the same host, same hardware. >> both have 1 vCPU and 1GB of ram, 20GB virtual disk (they are exactly on the >> same physical disk no raid or anything to have a fair comparison). >> Here is an example simple file search time for a non-existent file: >> FreeBSD 13 >> time find / -name cacert.pem >> real 0m30.656s >> user 0m0.516s >> sys 0m3.938s >> Second run even worse >> real 2m38.618s >> user 0m0.711s >> sys 0m6.882s >> While on the OpenBSD VM I get >> time find / -name cacert.pem >> real 0m2.258s >> user 0m0.290s >> sys 0m1.970s >> The amount of data is about the same on both systems but I would not >> consider this a "slight" performance degradation. If the base system is so >> slow then imagine putting Apache and other servers on top of it. Did anyone >> run into this? >> Unless there is a definitive solution I will opt out to using other BSD >> variants. >> freebsd-stable@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
iPhone tethering not working
I tried to connect my iPhone SE2 (iOS 13.7) to FreeBSD 12.2-stable. After loaded the kernel module if_ipheth, I connected my phone. > ugen0.2: at usbus0 Then I typed usbconfig -u 0 -a 2 set_config 3 > ipeth0 on uhub6 > Ipeth0: on usbus0 Then I chose to trust the computer, but nothing happened. My computer still can’t get to the internet. This is ifconfig ue0 output: > ue0: flags=8843 metric 0 mtu 1500 > ether > nd6 options=29 I tried dhclient ue0, but got no reply from iPhone. What can I do? _______ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Despite the documentation, "etcupdate extract" handles -D destdir (and its contribution to the default workdir)
# etcupdate -? Illegal option -? usage: etcupdate [-npBF] [-d workdir] [-r | -s source | -t tarball] [-A patterns] [-D destdir] [-I patterns] [-L logfile] [-M options] etcupdate build [-B] [-d workdir] [-s source] [-L logfile] [-M options] etcupdate diff [-d workdir] [-D destdir] [-I patterns] [-L logfile] etcupdate extract [-B] [-d workdir] [-s source | -t tarball] [-L logfile] [-M options] etcupdate resolve [-p] [-d workdir] [-D destdir] [-L logfile] etcupdate status [-d workdir] [-D destdir] The "etcupdate extract" material does not show -D destdir as valid. # man etcupdate . . . SYNOPSIS etcupdate [-npBF] [-d workdir] [-r | -s source | -t tarball] [-A patterns] [-D destdir] [-I patterns] [-L logfile] [-M options] etcupdate build [-B] [-d workdir] [-s source] [-L logfile] [-M options] tarball etcupdate diff [-d workdir] [-D destdir] [-I patterns] [-L logfile] etcupdate extract [-B] [-d workdir] [-s source | -t tarball] [-L logfile] [-M options] etcupdate resolve [-p] [-d workdir] [-D destdir] [-L logfile] etcupdate status [-d workdir] [-D destdir] . . . Again the "etcupdate extract" material does not show -D destdir as valid. But I used it: # etcupdate extract -D usr/obj/DESTDIRs/13_0R-CA7-for-chroot and it created and filled in the workdir: /usr/obj/DESTDIRs/13_0R-CA7-for-chroot/var/db/etcupdate/ I have not checked on if "etcupdate build" has a similar issue vs. not. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 13.0 terrible performance in KVM
We have over 50 FreeBSD VM on KVM for years, several Proxmox (5x,6x) and Centos (6.x,7.x) servers, and never experienced performance problem like this. Your example on fresh new 13 VM: # time -p find / -name cacert.pem real 0.28 user 0.00 sys 0.13 12.2 our syslog server: # time -p find / -name cacert.pem real 4.12 user 0.21 sys 3.77 Our hardware are Supermicro, IBM and Fujitsu servers with Xeon CPU-s, some with HW raid, others with ZFS as datastore, previous we had several IBM x3650 ... Everything was ok. No big difference between Linux and FreeBSD guests. We use Linux as guests only if we have to. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FreeBSD 13.0 terrible performance in KVM
Hello List, I hope some other folks out there running FreeBSD on KVM as well. I set up a base VM while doing so I noticed that the disk operations are very slow. Many times I edit a file in vim or try to run a command there is a huge lag. I use UFS as the root filesystem. To have something to compare it with I have tested it against an OpenBSD 6.6 VM on the same host, same hardware. both have 1 vCPU and 1GB of ram, 20GB virtual disk (they are exactly on the same physical disk no raid or anything to have a fair comparison). Here is an example simple file search time for a non-existent file: FreeBSD 13 time find / -name cacert.pem real 0m30.656s user 0m0.516s sys 0m3.938s Second run even worse real 2m38.618s user 0m0.711s sys 0m6.882s While on the OpenBSD VM I get time find / -name cacert.pem real 0m2.258s user 0m0.290s sys 0m1.970s The amount of data is about the same on both systems but I would not consider this a "slight" performance degradation. If the base system is so slow then imagine putting Apache and other servers on top of it. Did anyone run into this? Unless there is a definitive solution I will opt out to using other BSD variants. _______ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
https://artifact.ci.freebsd.org/snapshot/stable-13/?C=M=D messed up dates and HASHID-only use make things extremely hard to find "in time order"
Using an example to illustrate problems finding artifacts, the problems not being limited to the example's specifics. I have historically used https://artifact.ci.freebsd.org/snapshot/ to do build-less approximate bisecting (and other things). Such use is very messed up since the git-related URL conventions chosen were put in place. The below illustrates an example of the mess for how things are currently presented. https://artifact.ci.freebsd.org/snapshot/stable-13/?C=M=D lists ac845558f7b626d9a31b8f6dab686c45d39dc5a0/ as having date/time 2021-Apr-10 18:43 . But: https://artifact.ci.freebsd.org/snapshot/stable-13/ac845558f7b626d9a31b8f6dab686c45d39dc5a0/?C=M=D lists: powerpc/ and arm/ as having date/times 2021-Apr-10 18:54 and 2021-Apr-10 18:50 yet lists... i386/ and arm64/ as having date/times 2021-Feb-19 19:00 and 2021-Feb-19 18:50 . But it gets worse: https://artifact.ci.freebsd.org/snapshot/stable-13/ac845558f7b626d9a31b8f6dab686c45d39dc5a0/powerpc/?C=M=D shows an empty directory. Same for: https://artifact.ci.freebsd.org/snapshot/stable-13/ac845558f7b626d9a31b8f6dab686c45d39dc5a0/arm/?C=M=D By contrast, https://artifact.ci.freebsd.org/snapshot/stable-13/ac845558f7b626d9a31b8f6dab686c45d39dc5a0/i386/?C=M=D shows i386/ with date/time 2021-Apr-10 18:43 but https://artifact.ci.freebsd.org/snapshot/stable-13/ac845558f7b626d9a31b8f6dab686c45d39dc5a0/i386/i386/?C=M=D shows all the file dates as 2021-Feb-19 19:00 . Going back to arm64/ I find a similar 2021-Feb-19 dating, although 21021-Feb does show up in more places: https://artifact.ci.freebsd.org/snapshot/stable-13/ac845558f7b626d9a31b8f6dab686c45d39dc5a0/arm64/?C=M=D shows aarch64/ with date/time 2021-Feb-19 18:50 and https://artifact.ci.freebsd.org/snapshot/stable-13/ac845558f7b626d9a31b8f6dab686c45d39dc5a0/arm64/aarch64/?C=M=D shows the files also having the date/time 2021-Feb-19 18:50 . In my view the choice to only use the hash-id for the commit in the url is a usability mistake and the url prefix should be of a form more like (for this example context): https://artifact.ci.freebsd.org/snapshot/stable-13/n??-HASHID/ where the ?? is from: git rev-list --first-parent --count (as used elsewhere by FreeBSD). (The HASHID might be just the 12 character prefix instead of the whole hash-id as well.) Such a convention would be more independent of dates possibly being touched on the file server and would make time ordered finding of things (such as for build-less approximate bisecting) far more reasonable. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: zfs native encryption best practices on RELENG13
On 4/23/21 13:53, mike tancsa wrote: > Starting to play around with RELENG_13 and wanted explore ZFS' built in > encryption. Is there a best practices doc on how to do full disk > encryption anywhere thats not GELI based ? There are lots for > GELI, > but nothing I could find for native OpenZFS encryption on FreeBSD > > i.e box gets rebooted, enter in passphrase to allow it to boot kind of > thing from the boot loader prompt ? I think loader do not support the native OpenZFS encryption yet. However, you can encrypt non-essential datasets on a boot pool (that is, if com.datto:encryption is "active" AND the bootfs dataset is not encrypted, you can still boot from it). BTW instead of entering passphrase at loader prompt, if / is not encrypted, it's also possible to do something like https://lists.freebsd.org/pipermail/freebsd-security/2012-August/006547.html . Personally I'd probably go with GELI (or other kind of full disk encryption) regardless if OpenZFS's native encryption is used because my primary goal is to be able to just throw away bad disks when they are removed from production [1]. If the pool is not fully encrypted, there is always a chance that the sensitive data have landed some unencrypted datasets and never gets fully overwritten. [1] Also keep in mind: https://xkcd.com/538/ Cheers, OpenPGP_signature Description: OpenPGP digital signature
Is stable/13 going to start getting snapshot builds?
Is stable/13 going to start getting snapshot builds? (As stands, main , stable/12 , and stable/11 are getting them.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
etcupdate -p vs. root on zfs (and bectl use and such): no /usr/src/etc/master.passwd (for example)
FYI: The default bsdinstall result for auto ZFS that I tried has a separate zroot/usr/src dataset, which zfs mounts at /usr/src . UPDATING and such places indicate sequences like: (think etcupdate where it lists mergemaster and ignore -F and -Fi) make buildworld make buildkernel KERNCONF=YOUR_KERNEL_HERE make installkernel KERNCONF=YOUR_KERNEL_HERE [1] [3] mergemaster -Fp [5] NOTE: What /usr/src/etc/master.passwd here? (for example) make installworld mergemaster -Fi [4] make delete-old [6] etcupdate has the logic for handling -p: if [ -n "$preworld" ]; then # Build a limited tree that only contains files that are # crucial to installworld. for file in $PREWORLD_FILES; do name=$(basename $file) mkdir -p $1/etc >&3 2>&1 || return 1 cp -p $SRCDIR/$file $1/etc/$name || return 1 done Note the "$SRCDIR/$file". But for a boot -s after installing the kernel there is only zroot/ROOT/NAME and no zroot/usr/src zfs mount so /usr/src/ is empty. This leads to needing an additional step: zfs mount zroot/usr/src (The instructions do not deal with making / writable at this stage either.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
AR9462 runs only at 11g mode
I newly installed FreeBSD 12.2-release, but I found my wireless card Dell 1901(AR9462) work only at 11g and not steadily . "Failed to add supported operating classes IE" occurs occasionally, why? _______ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
13.0-RELEASE bsdinstall failure : looked for MANIFEST in wrong place (not with *.txz files)
Booted RPi4 via micrsd card dd'd from: FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img I attempted a bsdinstall onto a USB3 SSD. The following reports what happened. # bsdinstall default keymap Select Hostname OK ftp mirror OK Auto (ZFS) OK Install Select stripe OK [*] da0 OK Last Chance! da0 YES Error while fetching file:///usr/freebsd-dist/MANIFEST │ : No such file or directory OK Exit NOTE: the path is /usr/freebsd-dist/MANIFEST instead of /mnt/usr/freebsd-dist/MANIFEST but . . . # df -m Filesystem 1M-blocks Used Avail Capacity Mounted on /dev/ufs/rootfs28862 3217 2333612%/ devfs 00 0 100%/dev /dev/msdosfs/MSDOSBOOT49 24 2549%/boot/msdos tmpfs 500 49 1%/tmp zroot/ROOT/default197406 183 197222 0%/mnt zroot/tmp 1972220 197222 0%/mnt/tmp zroot/usr/home1972220 197222 0%/mnt/usr/home zroot/usr/ports 1972220 197222 0%/mnt/usr/ports zroot/usr/src 1972220 197222 0%/mnt/usr/src zroot/var/audit 1972220 197222 0%/mnt/var/audit zroot/var/crash 1972220 197222 0%/mnt/var/crash zroot/var/log 1972220 197222 0%/mnt/var/log zroot/var/mail1972220 197222 0%/mnt/var/mail zroot/var/tmp 1972220 197222 0%/mnt/var/tmp zroot 1972220 197222 0%/mnt/zroot # ls -Tla /mnt/usr/freebsd-dist/ total 187454 drwxr-xr-x 2 root wheel 4 Apr 9 07:39:20 2021 . drwxr-xr-x 6 root wheel 6 Apr 9 07:39:20 2021 .. -rw-r--r-- 1 root wheel 165248188 Apr 9 07:39:20 2021 base.txz -rw-r--r-- 1 root wheel 26552108 Apr 9 07:39:21 2021 kernel.txz # ls -Tla /usr/freebsd-dist/ ls: /usr/freebsd-dist/: No such file or directory NOTE: creating /usr/freebsd-dist/ with a copy of the MANIFEST file in it was enough to get past this issue: it is doing Archive Extraction now. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: freebsd-update and speed
On 2021-04-15 14:20, Ferdinand Goldmann wrote: > I've noticed that ever since update3.freebsd.org is gone (which was in Czech > republic I think), FreeBSD updates are often quite slow for me (= > Austria/Europe) > Especially so for major release upgrades. In fact so slow that I have time > to type this mail while waiting for '8778 patches'. I was experiencing the same problem and modified freebsd-update's config file to point directly to one of the other server, can't remember if update1 or update2 and it was fast. --- Andrea Brancatelli _______ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Deprecating base system ftpd
On Fri, 09 Apr 2021 07:32:12 +0900 aventa...@fastmail.fm wrote: >It makes me think that there should be an offering for two completely >different audiences: >(1) FreeBSD core (a very minimal offering for folks that want to build things, >like a Desktop, etc.) >(2) FreeBSD server (an offering for folks that want a server build) > >Perhaps that idea is just unreasonably crazy as well. > LOL! You have what is called a very big ask. I would like something far smaller, namely, a choice of schedulers during/just after installation of a -RELEASE without having to a) download the entire source tree, b) make buildworld, and c) make buildkernel. The kernel developers in their wisdom--ahem--have burdened all new installations with the abysmal performance of the ULE scheduler. The installation images for -STABLE versions are much the same. The 4BSD scheduler has been far from optimal, and the ULE scheduler looked like a nice idea on paper for newer CPUs, but in fact, the ULE scheduler's performance is awful, even when compared with the 4BSD scheduler, which generally gives acceptable, though not optimal, performance. If the owner of a new installation wants to get passably usable performance from his new system, he must first perform the tasks noted above. The second and third tasks will take *a lot* of extra time because they must be done under the ULE scheduler. Then one must install the new kernel, reboot, do the mergemaster or /etc/update steps, install the new world, more mergemaster or /etc/update, and reboot again. Two ways of allowing a choice of scheduler are 1) to provide two GENERIC kernels, e.g., GENERIC.ULE and GENERIC.4BSD, from which one could choose at boot time, and 2) to compile both schedulers into the GENERIC kernel, which could be selected from by a loader tunable at boot time. The current system is yet another discouragement to upgrading to a new -RELEASE via a new installation. Further, this fix to bad performance by default is not documented anywhere. How is a user who is new to FreeBSD to know about it? Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** _______ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Vinum deprecation for FreeBSD 14 - are there any remaining Vinum users?
Eugene Grosbein wrote: > 07.04.2021 12:49, Scott Bennett via freebsd-stable wrote: > > > At least w.r.t. gvinum's raid5, I can attest that the kernel panics > > are real. Before settling on ZFS raidz2 for my largest storage pool, I > > experimented with gstripe(8), gmirror(8), graid3(8), and graid5(8) (from > > sysutils/graid5). All worked reasonably well, except for one operation, > > namely, "stop". Most/all such devices cannot actually be stopped because > > a stopped device does not *stay* stopped. As soon as the GEOM device > > node is destroyed, all disks are retasted, their labels, if any, are > > recognized, and their corresponding device nodes are recreated and placed > > back on line. :-( All of this happens too quickly for even a series of > > commands entered on one line to be able to unload the kernel module for > > the device node type in question, so there is no practical way to stop > > such a device once it has been started. > > In fact, you can disable re-tasting with sysctl kern.geom.notaste=1, > stop an GEOM, clear its lables and re-enable tasting setting > kern.geom.notaste=0 back. Thank you for this valuable, but undocumented, workaround! However, it serves to demonstrate the bugs in gstripe(8), gmirror(8), graid3(8), and graid5(8), and perhaps a few others, either in the commands themselves, which do not behave as advertised in their respective man pages or in their man pages for not correctly documenting the commands' actual behavior. > > > A special note is needed here regarding gcache(8) and graid3(8). The > > documentation of gcache parameters for sector size for physical devices > > and gcache logical devices is very unclear, such that a user must have the > > device nodes and space on them available to create test cases and do so, > > whereas a properly documented gcache(8) would obviate the need to set up > > such experiments. There is similar lack of clarity in various size > > specifications for blocks, sectors, records, etc. in many of the man pages > > for native GEOM commands. > > I found gcache(8) very nice at first, it really boosts UFS performance > provided > you have extra RAM to dedicate to its cache. gcache can be stacked with > gmirror etc. > but I found it guilty to some obscure UFS-related panics. It seems there were > races or something. > No data loss, though as it is intended to be transparent for writing. There are other, also undocumented, problems. For example, I played with gcache(8) for a short time as a method of dividing a ZFS pool into two extents on a drive in order to place a frequently accessed partition between them. It worked nicely for a while, but the first time that gcache(8) choked it made a real mess of the ZFS pool's copy on that drive. As a result I immediately abandoned that use of gcache(8). gcache(8) usses two poorly defined sysctl values, kern.geom.cache.used_hi and kern.geom.cache.used_lo. Its man page shows them with default values, but neglects to mention whether they are enforced limits or merely sysctl variables that report current or high and low watermark usages. > > I was forced to stop using gcache for sake of stability and it's a shame. > For example, dump(8) speed-up due to gcache was 2x at least with big cache > comparing to dump -C32 without gcache. > I used it to make all accesses to a graid3(8) set of partitions work with 64 KB and 32 KB block sizes for UFS2 efficiency on a graid3(8) device. That use worked very nicely, but it took some experimentation to figure out how to do it because the man page is so ambiguous about the gcache command's options and arguments. A similar complaint could be leveled at the man pages for gstripe(8), graid3(8), and graid5(8) w.r.t. their undocumented definitions of stripe size, sector size, and block size. At present, without reading the command and kernel source code for each or experimenting extensively, it is difficult to understand what the commands' options and arguments will do and which combinations of their numerical values can be valid and accepted. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ********** ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Vinum deprecation for FreeBSD 14 - are there any remaining Vinum users?
Ed, On Thu, 25 Mar 2021 13:25:44 -0400 Ed Maste wrote: >Vinum is a Logical Volume Manager that was introduced in FreeBSD 3.0, >and for FreeBSD 5 was ported to geom(4) as gvinum. gvinum has had no >specific development at least as far back as 2010 and it is not clear >how well it works today. There are open PRs with reports of panics >upon removing disks, etc. And, it also imposes an ongoing cost as it First off, the "port" to geom(4) was incomplete in that gvinum is somehow not restricted to the geom(4) device nodes presented to it, but instead always grabs the entire physical device and node to do its own label processing. Second, gvinum is completely incompatible with GPT partitioning because, regardless of the device nodes given it to use, it always writes and reads its own label to and from the ends of the physical drives. That means it overwrites the GPT secondary partition table with its own labels, which soon causes error/warning messages from the kernel about a damaged/missing secondary partition table and recommending a recovery of that damaged/missing partition table. Doing the recovery then will overwrite gvinum's labels, which is likely to cause a kernel panic or worse. My memory on gvinum's compatibility with glabel(8) labels is fuzzy at the present remove, but I seem to recall having encountered problems there, too. This is not unique, unfortunately, to gvinum(8). For example, using glabel(8) to label swap partitions, as well as bsdlabel(8)ed partitions, can lead to many unexpected problems. Such inconsistencies should be researched and fixed. GPT labels allow a partition type of "freebsd-vinum". I did not try to play with that one, but I suspect that it would not work correctly because gvinum is somehow not limited to the GEOM device node for a partition. However, if you decide to keep gvinum(8) for some reason, then this matter should be checked out in detail and its inconsistencies fixed.. At least w.r.t. gvinum's raid5, I can attest that the kernel panics are real. Before settling on ZFS raidz2 for my largest storage pool, I experimented with gstripe(8), gmirror(8), graid3(8), and graid5(8) (from sysutils/graid5). All worked reasonably well, except for one operation, namely, "stop". Most/all such devices cannot actually be stopped because a stopped device does not *stay* stopped. As soon as the GEOM device node is destroyed, all disks are retasted, their labels, if any, are recognized, and their corresponding device nodes are recreated and placed back on line. :-( All of this happens too quickly for even a series of commands entered on one line to be able to unload the kernel module for the device node type in question, so there is no practical way to stop such a device once it has been started. Because gvinum's raid5 was always unbearably slow and also subject to kernel panics, I soon excluded it from further consideration. GEOM is one of the brightest gems of modern FreeBSD design. GEOM's native functions should not be corrupted or ignored as a result of a botched attempt to "modernize" an old monstrosity like gvinum, which was originally written for a system that lacked GEOM and has not fit well into a modern system that *has* GEOM, not to mention GPT partitioning. All of these specific, native GEOM second-level devices otherwise work pretty much as advertised. graid5(8), however, was recently marked as deprecated, which is a real shame. I would vote for finishing its man page, which is very incomplete, and for adding a subcommand to do some sort of scrub procedure like many hardware RAID5 controllers do. There are perfectly valid reasons to use these devices in some situations instead of ZFS, e.g., better performance for temporary/disposable data, especially for situations involving millions of very short files like ccache(1) directory trees, portmaster(8)'s $WRKDIRPREFIX, and likely others. gvinum(8) appears to have been broken in several ways since FreeBSD 5.0, is unmaintained as you wrote, and should be deprecated and eliminated for the reasons given above. The simple GEOM devices provide much the same flexibility that gvinum was intended to provide without the need to learn gvinum's peculiar configuration method. Once one understands how GEOM devices work and can be stacked, they are generally very simple to use in contrast to gvinum, which remains broken in multiple ways. >must be updated when other work is done (such as the recent MAXPHYS >work). I suspect that by now all users have migrated to either >graid(8) or ZFS. graid(8) is not always a good option. If you read its man page, you will see that RAID5 is usually only supported as read-only devices, where it is supported at all. This can be helpful for recovering data from a proprietary RAID device, but is not generally useful for actively used and updated data. IOW, it can be helpful in a p
Re: Portsnap no updates since 3/31/2021 ?
> On Apr 6, 2021, at 7:10 AM, Gary Palmer wrote: > > On Tue, Apr 06, 2021 at 06:49:17AM -0400, Robert Blayzor via freebsd-stable > wrote: >> I have several servers running 11.4 and 12.2 that do nightly portsnap >> updates and the last time they've seen anything new is 3/31/2021, since >> then, nothing. >> >> This seems highly unusual since seems like there was always SOMETHING >> updated daily now nothing. > > git transition > > https://wiki.freebsd.org/git <https://wiki.freebsd.org/git> Is portsnap still going to be supported? I was noticing my local ports tree (which autoupdates every night with portsnap) was looking pretty dated, so I started googling and found talk on the forums that portsnap was going away (this was late 2020) and folks were suggesting svnlite and fetching updates via svn. Based on that, I just nuked my ports tree and grabbed it again via git, which seems to have worked. What’s odd is that looking at that wiki entry, this port should have been up to date if I was using portsnap: https://www.freshports.org/multimedia/plexmediaserver-plexpass/ <https://www.freshports.org/multimedia/plexmediaserver-plexpass/> But portsnap kept insisting that I was up to date even though I was seeing version 1.21.3.4015… Anyhow, if anyone can confirm portsnap status, I’d love to know what the official line is and whether I should expect to see it around for awhile. Is the git transition impacting freebsd-update at all? etcupdate? Thanks, Charles > > Regular service should resume soon > > Regards, > > Gary > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" _______ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Portsnap no updates since 3/31/2021 ?
I have several servers running 11.4 and 12.2 that do nightly portsnap updates and the last time they've seen anything new is 3/31/2021, since then, nothing. This seems highly unusual since seems like there was always SOMETHING updated daily now nothing. -- inoc.net!rblayzor XMPP: rblayzor.AT.inoc.net PGP: https://pgp.inoc.net/rblayzor/ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Deprecating base system ftpd?
On 2021-04-05 02:05, Daniel Morante via freebsd-stable wrote: > My vote is for no. > > Reasoning is simple... at what point does it stop? By continuously moving > stuff from base to ports, FreeBSD slowly becomes just a Kernel. I strongly agree with this consideration. --- Andrea Brancatelli ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Deprecating base system ftpd?
> On Apr 5, 2021, at 3:01 PM, Patrick M. Hausen wrote: > > Hi all, > > I absolutely freaked out when Apple removed the telnet and ftp clients > from Mac OS and I needed to reinstall them via MacPorts. Yep, and what I think many miss IRT to the stock ftpd is that it’s dumb simple and “just works”. For web hosting stuff I generally use something like Proftpd or vsftpd, and, IMHO, that’s when you should have to expend brain power to choose something from ports - when your use-case (supporting hosting customers, virtual users, etc.) requires a non-trivial ftp implementation. Also I can count on my left hand the number of web hosting customers I’ve run into that actually use scp for sftp or even know what that is. They’re using the same ftp client they’ve always used (ws-ftp quite often) and the last thing they want to do is learn something new. > People who manage any larger collection of networking gear *depend* > on these outdated but simple services. Client and server side alike. I frequently work with people who have limited budgets, and I don’t think I’m alone in that. Ebay is chock full of high-volume sellers turning over old networking gear that is amazingly good stuff that’s just outdated. I can grab a 48 port GigE switch with 10gb/s uplink ports for under $200. The market is gigantic, and putting old stuff to use on an internal network with proper safeguards is not totally crazy. Customers can have multiple fully-loaded spares on-site for less than what a year of SmartNet coverage would cost. My server platform of choice when I want a “support server” for this old stuff has always been FreeBSD. Stock tftpd and ftpd are wonderful, and anyone professing that those two tiny daemons are “bloat” just hasn’t used Linux. > TFTP is not going away, neither is FTP. I'm dead serious. Remote media > via Supermicro IPMI in 2021? SMB1. Firmware updates for my UPS? FTP. > Scanner/printer/fax all-in-one thingy? Uploads received fax transmissions > via FTP. PBX? Uploads usage reports via FTP. This stuff is here to stay. > In local networks, of course. Preach! And plenty of VoIP gear too! There are absolutely real world uses for these simple daemons, and I trust some stock FreeBSD daemon like this more than something I might fetch from ports - both in terms of knowing it’s had some kind of auditing/maintenance by qualified people and that it’s going to have an accurate manpage, sane defaults, and remain relatively simple/minimal. I think as everyone has moved to the cloud and devops and all that they forget about sysadmins standing up servers as simple utility boxes that support a bunch of other gear. > But still even on "the Internet", FTP is the most used method for customers > of static website hosting. You cannot teach these people what an SSH key is. > Just my experience, but backed by a load of customer interactions over more > than 20 years … I think some people mean well, and they imagine that if we just tell people to move to some monstrosity like Filezilla the problem is solved, but realistically it’s just a good way to lose paying customers. Charles > > Kind regards, > Patrick > -- > punkt.de GmbH > Patrick M. Hausen > .infrastructure > > Kaiserallee 13a > 76133 Karlsruhe > > Tel. +49 721 9109500 > > https://infrastructure.punkt.de > i...@punkt.de > > AG Mannheim 108285 > Geschäftsführer: Jürgen Egeling, Daniel Lienert, Fabian Stein > signature.asc Description: Message signed with OpenPGP
Re: FreeBSD 13.0-RC5 Now Available
I don't know, ask yourself that, you did the same thing On 4/4/21 6:21 PM, Glen Barber wrote: Is it necessary to quote the*entire* email (including checksums)? Glen Sent from my phone. Please excuse my brevity and/or typos. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Deprecating base system ftpd?
> On 3 Apr 2021, at 22:39, Ed Maste wrote: > > I propose deprecating the ftpd currently included in the base system > before FreeBSD 14, and opened review D26447 > (https://reviews.freebsd.org/D26447) to add a notice to the man page. > I had originally planned to try to do this before 13.0, but it dropped > off my list. FTP is not nearly as relevant now as it once was, and it > had a security vulnerability that secteam had to address. > > I'm happy to make a port for it if anyone needs it. Comments? Make it a port It is time to deprecate ftp altogether, and any other protocols that embed protocol information in layer 7, thus hurting any #IPv6 migration and deployment technology (SIIT-DC e.g). Hopefully the IETF can put up a deprecation notice, just as was done for e.g. TLS 1.0. Then we move onward to the self regulating capacity of the community, warning each other on “you have ftp” running. ftp, a protocol not using TLS protection but by adding it a netadmin needs to manage the port range in their firewalls too because clients behind nat can’t use passive mode with TLS as NAT can’t map things around ¯\_(ツ)_/¯ It is not worth the time and the hassle. Keep FTP(s) for legacy and internal, serve anyone else with https Best Regards, Ruben signature.asc Description: Message signed with OpenPGP
Re: Deprecating base system ftpd?
> On Apr 4, 2021, at 8:05 PM, Daniel Morante via freebsd-stable > wrote: > > My vote is for no. > > Reasoning is simple... at what point does it stop? By continuously moving > stuff from base to ports, FreeBSD slowly becomes just a Kernel. That’s a +1 here, both for the “keep it” and for the comment above regarding complete OS vs. kernel and a teeny userland. Ideally, we’d modernize ftpd to support TLS. The PITA with ports solutions is you immediate run into the issue of which of the many ftp daemons is going to fit your needs and not require some non-trivial amount of configuration. The stock ftpd ‘just works’ for local user accounts and has a simple method for blocking of swaths of users from using it if that sort of restriction is needed. This reminds me of Apple removing the telnet client. Sure, most people don’t *need* telnet, but it’s handy to have, both as a simple test tool and as a way to get into old crufty network gear that never moved on to ssh. Charles > > On 4/3/2021 4:39 PM, Ed Maste wrote: >> I propose deprecating the ftpd currently included in the base system >> before FreeBSD 14, and opened review D26447 >> (https://reviews.freebsd.org/D26447) to add a notice to the man page. >> I had originally planned to try to do this before 13.0, but it dropped >> off my list. FTP is not nearly as relevant now as it once was, and it >> had a security vulnerability that secteam had to address. >> >> I'm happy to make a port for it if anyone needs it. Comments? >> ___ >> freebsd-stable@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" >> > signature.asc Description: Message signed with OpenPGP
Re: Deprecating base system ftpd?
My vote is for no. Reasoning is simple... at what point does it stop? By continuously moving stuff from base to ports, FreeBSD slowly becomes just a Kernel. On 4/3/2021 4:39 PM, Ed Maste wrote: I propose deprecating the ftpd currently included in the base system before FreeBSD 14, and opened review D26447 (https://reviews.freebsd.org/D26447) to add a notice to the man page. I had originally planned to try to do this before 13.0, but it dropped off my list. FTP is not nearly as relevant now as it once was, and it had a security vulnerability that secteam had to address. I'm happy to make a port for it if anyone needs it. Comments? ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" smime.p7s Description: S/MIME Cryptographic Signature
Re: ZFS (in virtual machine): $HOME being a dataset causes xauth to timeout- access delays?
On Thu, Apr 1, 2021 at 3:38 PM parv/freebsd wrote: I am wondering if $SRC_BASE, $MAKEOBJDIRPREFIX, & $WRKDIRPREFIX being ZFS datasets now would increase compile time. I will found that out in few weeks (in case of buildworld & kernel) as earlier I had both $SRC_BASE & $MAKEOBJDIRPREFIX as plain directories & took ~5--6 hours. I have FreeBSD 12-STABLE in VirtualBox 5.2.44 on Windows 10. All the "disks" > are file-backed virtual disks. > > I noticed that after making $HOME a ZFS dataset, there were delays ... > - generally in start of Xorg; > - exhibited by xauth (after using "startx") error messages about timeout > with authority files. > > After reverting back $HOME not being a dataset on its own as before, there > are > no delays in start of Xorg; nor are any timeout message from xauth as > before. > > Has anybody else noticed that? > ... - parv ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
ZFS (in virtual machine): $HOME being a dataset causes xauth to timeout- access delays?
Hi there, I have FreeBSD 12-STABLE in VirtualBox 5.2.44 on Windows 10. All the "disks" are file-backed virtual disks. I noticed that after making $HOME a ZFS dataset, there were delays ... - generally in start of Xorg; - exhibited by xauth (after using "startx") error messages about timeout with authority files. After reverting back $HOME not being a dataset on its own as before, there are no delays in start of Xorg; nor are any timeout message from xauth as before. Has anybody else noticed that? - parv Before making $HOME (/aux/home/parv) a dataset ... aux0 mounted at /aux aux0/home at /aux/home Conversion of $HOME to a dataset .. % zfs create aux0/home/parv2 % mv /aux/home/parv/* /aux/home/parv2/ % mv /aux/home/parv/.* /aux/home/parv2/ % rm -rf /aux/home/parv % zfs rename aux0/home/parv2 aux0/home/parv ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Update to the 13.0-RELEASE schedule
On Wed, Mar 31, 2021 at 03:58:51PM +, Glen Barber wrote: > A small set of updates that we consider blocking the 13.0 release have > been brought to our attention. As such, the 13.0-RELEASE schedule has > been updated to include a fifth release candidate (RC5). > > The updated schedule is available on the FreeBSD Project website: > > https://www.freebsd.org/releases/13.0R/schedule/ > > As usual, we will continue to consider critical bug fixes only for the > duration of this release cycle. > > Thank you for your cooperation, and for your patience. > > Glen > On behalf of: re@ > I rather that than a buggy realease. Good show. I will continue to test on my workstation running a Supermicro X10sL7-f -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b We cannot change human failings by ridding ourselves of machines. -unknown ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: qlnxe driver not in 13.0 arm64
I tried to move the lines, but maybe I did something wrong since it failed to build. make[3]: stopped in /usr/src/sys/modules *** [modules-all] Error code 2 make[2]: stopped in /usr/obj/usr/src/arm64.aarch64/sys/THUNDERX2 15 errors The full output is here: http://venus.morante.net/downloads/unibia/freebsd/misc/arm64/qlnxe_13.0-RC4-arm64.log On 3/30/21 2:31 PM, John-Mark Gurney wrote: Daniel Morante via freebsd-stable wrote this message on Sun, Mar 28, 2021 at 03:23 -0400: I installed 13.0-RC3 ARM64 from the DVD ISO image (FreeBSD-13.0-BETA4-arm64-aarch64-dvd1.iso <http://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/13.0/FreeBSD-13.0-BETA4-arm64-aarch64-dvd1.iso>). There is no "if_qlnxe" kernel model present on the install media, or on the system after installing. Next I try to build a custom kernel. I add "device qlnxe" to the configuration file as instructed in https://www.freebsd.org/cgi/man.cgi?query=qlnxe=FreeBSD+13.0-current. Running "make buildkernel KERNCONF=THUNDERX2" results in: config: Error: device "qlnxe" is unknown Is this module not available for ARM64 architecture? Correct, this is only available for amd64. HPS might have some more insight as to why it's amd64 only. I have cc'd him. It could be as simple as moving the qlnxe lines from files.amd64 to files, but it does appear that qnlxe depends upon the Linux compat layer, which may not be complete for arm64.. # # GENERIC -- Generic kernel configuration file for FreeBSD/arm64 # # For more information on this file, please read the config(5) manual page, # and/or the handbook section on Kernel Configuration Files: # # https://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (https://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD$ cpu ARM64 ident GENERIC makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols makeoptions WITH_CTF=1 # Run ctfconvert(1) for DTrace support options SCHED_ULE # ULE scheduler options NUMA# Non-Uniform Memory Architecture support options PREEMPTION # Enable kernel thread preemption options VIMAGE # Subsystem virtualization, e.g. VNET options INET# InterNETworking options INET6 # IPv6 communications protocols options IPSEC_SUPPORT # Allow kldload of ipsec and tcpmd5 options ROUTE_MPATH # Multipath routing support options TCP_OFFLOAD # TCP offload options TCP_HHOOK # hhook(9) framework for TCP options TCP_RFC7413 # TCP Fast Open options SCTP_SUPPORT# Allow kldload of SCTP options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL# Enable gjournal-based UFS journaling options QUOTA # Enable disk quotas for UFS options MD_ROOT # MD is a potential root device options NFSCL # Network Filesystem Client options NFSD# Network Filesystem Server options NFSLOCKD# Network Lock Manager options NFS_ROOT# NFS usable as /, requires NFSCL options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options TMPFS # Efficient memory filesystem options GEOM_RAID # Soft RAID functionality. options GEOM_LABEL # Provides labelization options EFIRT # EFI Runtime Services support options COMPAT_FREEBSD32# Compatible with FreeBSD/arm options COMPAT_FREEBSD11# Compatible with FreeBSD11 options COMPAT_FREEBSD12# Compatible with FreeBSD12 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support
powerpc64le is missing in: https://www.freebsd.org/platforms/
When I looked at https://www.freebsd.org/platforms/ I noticed that "64-bit little-endian PowerPC" powerpc64le is not listed. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: qlnxe driver not in 13.0 arm64
To test it with a custom kernel, would I only need to add these lines
(https://cgit.freebsd.org/src/tree/sys/conf/files.amd64#n279-306)?
|dev/qlnx/qlnxe/ecore_cxt.c optional qlnxe pci \ compile-with
"${LINUXKPI_C}" dev/qlnx/qlnxe/ecore_dbg_fw_funcs.c optional qlnxe pci \
compile-with "${LINUXKPI_C}" dev/qlnx/qlnxe/ecore_dcbx.c optional qlnxe
pci \ compile-with "${LINUXKPI_C}" dev/qlnx/qlnxe/ecore_dev.c optional
qlnxe pci \ compile-with "${LINUXKPI_C}" dev/qlnx/qlnxe/ecore_hw.c
optional qlnxe pci \ compile-with "${LINUXKPI_C}"
dev/qlnx/qlnxe/ecore_init_fw_funcs.c optional qlnxe pci \ compile-with
"${LINUXKPI_C}" dev/qlnx/qlnxe/ecore_init_ops.c optional qlnxe pci \
compile-with "${LINUXKPI_C}" dev/qlnx/qlnxe/ecore_int.c optional qlnxe
pci \ compile-with "${LINUXKPI_C}" dev/qlnx/qlnxe/ecore_l2.c optional
qlnxe pci \ compile-with "${LINUXKPI_C}" dev/qlnx/qlnxe/ecore_mcp.c
optional qlnxe pci \ compile-with "${LINUXKPI_C}"
dev/qlnx/qlnxe/ecore_sp_commands.c optional qlnxe pci \ compile-with
"${LINUXKPI_C}" dev/qlnx/qlnxe/ecore_spq.c optional qlnxe pci \
compile-with "${LINUXKPI_C}" dev/qlnx/qlnxe/qlnx_ioctl.c optional qlnxe
pci \ compile-with "${LINUXKPI_C}" dev/qlnx/qlnxe/qlnx_os.c optional
qlnxe pci \ compile-with "${LINUXKPI_C}"|
On 3/30/21 3:00 PM, Hans Petter Selasky wrote:
On 3/30/21 8:31 PM, John-Mark Gurney wrote:
Daniel Morante via freebsd-stable wrote this message on Sun, Mar 28,
2021 at 03:23 -0400:
I installed 13.0-RC3 ARM64 from the DVD ISO image
(FreeBSD-13.0-BETA4-arm64-aarch64-dvd1.iso
<http://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/13.0/FreeBSD-13.0-BETA4-arm64-aarch64-dvd1.iso>).
There is no "if_qlnxe" kernel model present on the install media, or on
the system after installing.
Next I try to build a custom kernel. I add "device qlnxe" to the
configuration file as instructed in
https://www.freebsd.org/cgi/man.cgi?query=qlnxe=FreeBSD+13.0-current.
Running "make buildkernel KERNCONF=THUNDERX2" results in:
config: Error: device "qlnxe" is unknown
Is this module not available for ARM64 architecture?
Correct, this is only available for amd64.
HPS might have some more insight as to why it's amd64 only.
I have cc'd him.
It could be as simple as moving the qlnxe lines from files.amd64 to
files,
but it does appear that qnlxe depends upon the Linux compat layer, which
may not be complete for arm64..
The LinuxKPI works for ARM64 aswell. Maybe the QLNXE driver is not
tested for ARM64.
--HPS
smime.p7s
Description: S/MIME Cryptographic Signature
Re: possibly silly question regarding freebsd-update
On 30/03/21 17:38, tech-lists wrote: On Tue, Mar 30, 2021 at 05:22:30PM +0200, Guido Falsi via freebsd-stable wrote: No, as you can see in the commit in the official git [1] while for current and stable the new upstream version of openssl was imported for the release the fix was applied without importing the new release and without changing the reported version of the library. So with 12.2p5 you do get the fix but don't get a new version of the library. [1] https://cgit.freebsd.org/src/commit/?h=releng/12.2=af61348d61f51a88b438d41c3c91b56b2b65ed9b On this url, near the top, there's this: "Fix multiple OpenSSL vulnerabilities. Add UPDATING and bump version." next to that, we have "releng/12.2". So, I'm expecting the version information pertaining to opensslto be bumped. Is this expectation unreasonable? I'm not a developer. The "bumping verion" part refers to bumping the FreeBSD version, that's the p4 -> p5 part of the patch, last hunk referring to file sys/conf/newvers.sh -- Guido Falsi _______ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: possibly silly question regarding freebsd-update
On 30/03/21 15:35, tech-lists wrote: Hi, Recently there was https://lists.freebsd.org/pipermail/freebsd-security/2021-March/010380.html about openssl. Upgraded to 12.2-p5 with freebsd-update and rebooted. What I'm unsure about is the openssl version. Up-to-date 12.1-p5 instances report OpenSSL 1.1.1h-freebsd 22 Sep 2020 Up-to-date stable/13-n245043-7590d7800c4 reports OpenSSL 1.1.1k-freebsd 25 Mar 2021 shouldn't the 12.2-p5 be reporting openssl 1.1.1k-freebsd as well? No, as you can see in the commit in the official git [1] while for current and stable the new upstream version of openssl was imported for the release the fix was applied without importing the new release and without changing the reported version of the library. So with 12.2p5 you do get the fix but don't get a new version of the library. [1] https://cgit.freebsd.org/src/commit/?h=releng/12.2=af61348d61f51a88b438d41c3c91b56b2b65ed9b -- Guido Falsi ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: possibly silly question regarding freebsd-update
Hi, Did you mean 12.1-p5 or 12.2-p5 ? I'm asking because you refer to both 12.1-p5 and 12.2-p5 (typo?). If you meant 12.2-p5: Perhaps the FreeBSD security team did not bump the version, but "only" backported the patches to version 1.1.1h ? Regards, Ruben On 3/30/21 3:35 PM, tech-lists wrote: Hi, Recently there was https://lists.freebsd.org/pipermail/freebsd-security/2021-March/010380.html about openssl. Upgraded to 12.2-p5 with freebsd-update and rebooted. What I'm unsure about is the openssl version. Up-to-date 12.1-p5 instances report OpenSSL 1.1.1h-freebsd 22 Sep 2020 Up-to-date stable/13-n245043-7590d7800c4 reports OpenSSL 1.1.1k-freebsd 25 Mar 2021 shouldn't the 12.2-p5 be reporting openssl 1.1.1k-freebsd as well? thanks, _______ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
qlnxe driver not in 13.0 arm64
I installed 13.0-RC3 ARM64 from the DVD ISO image (FreeBSD-13.0-BETA4-arm64-aarch64-dvd1.iso <http://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/13.0/FreeBSD-13.0-BETA4-arm64-aarch64-dvd1.iso>). There is no "if_qlnxe" kernel model present on the install media, or on the system after installing. Next I try to build a custom kernel. I add "device qlnxe" to the configuration file as instructed in https://www.freebsd.org/cgi/man.cgi?query=qlnxe=FreeBSD+13.0-current. Running "make buildkernel KERNCONF=THUNDERX2" results in: config: Error: device "qlnxe" is unknown Is this module not available for ARM64 architecture? _______ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Filesystem operations slower in 13.0 than 12.2
On 2021-Mar-22, at 22:51, Kevin Oberman wrote: > On Mon, Mar 22, 2021 at 8:19 AM Adrian Chadd wrote: >> On Mon, 15 Mar 2021 at 14:58, Kevin Oberman wrote: >> >> > > >> > > It appears that the messages are associated with reading >> > > the disk(s), not directly with writing them, where the >> > > reads take more than "hz * 20" time units to complete. >> > > (I'm looking at main (14) code.) What might contribute >> > > to the time taken for the pending read(s)? >> > > >> > The reference to hz * 20 woke up a few sleeping memory cells. I forgot that >> > I cleaned up my loader.conf. It was largely a copy of the one on my >> > decade-old T520. I commented out "kern.hz=100". I don't recall the details, >> > but I think it was actually from an even older system, my T42 from before I >> > retired. >> > >> > In any case, restoring this setting has greatly improved the situation. I >> > now have really bad disk I/O performance on large disk to disk activity >> > (untarring the firefox distro) instead of terrible performance and the >> > system freezes have vanished, though I do see pauses in response to clicks >> > or text entry, but the display remains active and the pauses are short... 1 >> > to 15 seconds, I'd guess. No, I have no idea what this indicates. >> >> ... which drive controller is this? Is it just a laptop ATA disk? >> >> > I'm still not seeing the performance I was seeing back in February when 40 >> > MB/s for extended intervals was common and I once untarred firefox.tar.gz2 >> > in under a minute and performance seldom dropped below 1.4 MB/s. >> >> Did you find a resolution? I wonder if setting kern.hz is kicking >> some process(es) to get some time more frequently due to bugs >> elsewhere in the system (interrupts, IPI handling, wake-ups, etc) >> >> >> >> -adrian > No resolution. This is a Lenovo L15 ThinkPad with a 2TB ATAPI drive. I've not found documentation indicating the "which drive controller" answer. That may have to be answered from boot messages or boot -v messages or other such on FreeBSD. (I've no access to such a machine.) You might want to put a copy of such a log someplace that folks could look at it. There may be commands that some folks would like to see the output of. (I'm not all that likely to be one that could put such to use but other folks might be able to.) Intel® Celeron®? 10th Generation Intel CoreTM i3? i5? i7? > The current drive is a Seagate. All testing has been done since I got it > back from Lenovo in late January. I can read or write the drive at reasonable > rates that exceed 50 MB/s. Extracting a tar distribution file is painful. I > have had firefox extracts take over a half hour. Worse, if I do other > operations while the extract is taking place, I often see a 30 second (and, > occasionally 60 second) display freezes I thought that you had reported that use of kern.hz=100 had lead to "the system freezes have vanished" and "pauses are short... 1 to 15 seconds". Did more testing show that to not be always the case? > as well as log reports that of "swap_pager: indefinite wait buffer:" Unfortunately, I do not know how to investigate what is leading to those message being generated. Figuring that out would seem to be important but I do not know what to monitor to at least potentially eliminate some possibilities. One possible thing to look at is something like "gstat -spod" output spanning the time of the untar. It would at least indicate if a large queue backlog was accumulating on the device. And the ms/r and ms/w columns would give a clue if commands are sitting in the queues for long periods. (The "d" may be a waste: no BIO_DELETEs possible? Also, the r/s vs. ms/r are not rescaled reciprocals but distinct measurements. Similarly for: the w/s vs. ms/w.) Given the "indefinite wait buffer" messages, I expect the ms/r and/or ms/w figures to be large at least some of the time. Knowing how large may be of use to someone. But I can not eliminate anything with such information. > This is a bit odd as I have 20G of RAM and am pretty close to no swap space > activity, but, of course, paging does occur. With 20 GiBytes of RAM, what is going on at the time that leads to paging activity? I'm thinking of just untarring the firefox file, not building firefox or such. Can you test such an untar in a context that is not otherwise paging (nor swapping)? If yes, is the behavior different in any readily noticeable way? > This system is CometLake and graphics are not supported on 12. I am not > absolutely sure that there is no
Re: FreeBSD 13.0-RC3 Now Available
Hello, I see the RC3 in the "Latest News" but not here: https://www.freebsd.org/releases/13.0R/schedule/ I hope I'm writing to the proper channels/list about this. Regards, meka signature.asc Description: PGP signature
Re: ThinkPad X1 Carbon Gen 4 unable to boot 13.0-RC1
On 3/20/21 10:26 AM, Kevin Oberman wrote: On Sat, Mar 20, 2021 at 8:35 AM Fred via freebsd-stable < freebsd-stable@freebsd.org> wrote: On 3/19/21 7:59 PM, Mathias Picker wrote: Fred Hall via freebsd-stable writes: I have a ThinkPad X1 Carbon Gen 4 (20FCS0NB00) which has happily run FreeBSD 11 and 12, but which can't boot 13.0-RC1 from memstick or via freebsd-update. In both cases the boot process locks up on the line "hwpstate_intel0: on cpu0" If running freebsd-update, a work around is to add hint.hwpstate_intel.0.disabled="1" in loader.conf. See the note under the Eighth Generation (2020) in https://wiki.freebsd.org/Laptops/Thinkpad_X1_Carbon I was quite surprised to find the lack of support for hwpstate_intel in 13 when it apparently worked under 11 and 12. Does anyone know the status of hwpstate_intel on ThinkPads? I’m running 13 -STABLE from 10 days ago on a Thinkpad Yoga 3rd gen, and hwpstate_intel works fine, never had a problem. mathiasp:~% sysctl dev.hwpstate_intel dev.hwpstate_intel.7.epp: 15 dev.hwpstate_intel.7.%parent: cpu7 dev.hwpstate_intel.7.%pnpinfo: dev.hwpstate_intel.7.%location: dev.hwpstate_intel.7.%driver: hwpstate_intel dev.hwpstate_intel.7.%desc: Intel Speed Shift dev.hwpstate_intel.6.epp: 15 dev.hwpstate_intel.6.%parent: cpu6 dev.hwpstate_intel.6.%pnpinfo: dev.hwpstate_intel.6.%location: dev.hwpstate_intel.6.%driver: hwpstate_intel dev.hwpstate_intel.6.%desc: Intel Speed Shift [snip] The gen3 is using sudo dmesg|grep -i c CPU: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz (1992.08-MHz K8-class CPU) [snip, snip] mathiasp:~% uname -a FreeBSD Danton 13.0-STABLE FreeBSD 13.0-STABLE #2 stable/13-n244845-f21c0366f53: Wed Mar 10 20:53:26 CET 2021 root@Danton:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 Cheers, Mathias Thanks for the feed back. Good to know most people won't encounter the problem. Perhaps it is a bios issue specific to the model. I did update to the latest bios version but that made no difference. I have chosen to rollback to 12.2 as it works perfectly for me. Cheers, Fred There are two long tickets about this. Take a look at tickets 248659 <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248659> and 253288 <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253288>. This problem appeared in 13-current in Jan 2020 and I first saw it on my new Lenovo L15 that summer. It appears specific to Lenovo laptops. It appears that similar issues have been seen with Linux. Thank for the links to the bug reports, it would appear to be the same issue. I tested my wife's X1 Carbon Gen 3 and it worked fine. Perhaps a bios bug with the processor in my 4th gen. CPU: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz (2808.11-MHz K8-class CPU) In the 24 hours I tested 13.0, I also had some X windows failures while waking up from suspend which never happens with 12.2. Oh well, no worries. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 _______ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ThinkPad X1 Carbon Gen 4 unable to boot 13.0-RC1
On 3/19/21 7:59 PM, Mathias Picker wrote: Fred Hall via freebsd-stable writes: I have a ThinkPad X1 Carbon Gen 4 (20FCS0NB00) which has happily run FreeBSD 11 and 12, but which can't boot 13.0-RC1 from memstick or via freebsd-update. In both cases the boot process locks up on the line "hwpstate_intel0: on cpu0" If running freebsd-update, a work around is to add hint.hwpstate_intel.0.disabled="1" in loader.conf. See the note under the Eighth Generation (2020) in https://wiki.freebsd.org/Laptops/Thinkpad_X1_Carbon I was quite surprised to find the lack of support for hwpstate_intel in 13 when it apparently worked under 11 and 12. Does anyone know the status of hwpstate_intel on ThinkPads? I’m running 13 -STABLE from 10 days ago on a Thinkpad Yoga 3rd gen, and hwpstate_intel works fine, never had a problem. mathiasp:~% sysctl dev.hwpstate_intel dev.hwpstate_intel.7.epp: 15 dev.hwpstate_intel.7.%parent: cpu7 dev.hwpstate_intel.7.%pnpinfo: dev.hwpstate_intel.7.%location: dev.hwpstate_intel.7.%driver: hwpstate_intel dev.hwpstate_intel.7.%desc: Intel Speed Shift dev.hwpstate_intel.6.epp: 15 dev.hwpstate_intel.6.%parent: cpu6 dev.hwpstate_intel.6.%pnpinfo: dev.hwpstate_intel.6.%location: dev.hwpstate_intel.6.%driver: hwpstate_intel dev.hwpstate_intel.6.%desc: Intel Speed Shift [snip] The gen3 is using sudo dmesg|grep -i cpu CPU: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz (1992.08-MHz K8-class CPU) [snip, snip] mathiasp:~% uname -a FreeBSD Danton 13.0-STABLE FreeBSD 13.0-STABLE #2 stable/13-n244845-f21c0366f53: Wed Mar 10 20:53:26 CET 2021 root@Danton:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 Cheers, Mathias Thanks for the feed back. Good to know most people won't encounter the problem. Perhaps it is a bios issue specific to the model. I did update to the latest bios version but that made no difference. I have chosen to rollback to 12.2 as it works perfectly for me. Cheers, Fred ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" _______ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Request: Mount zfs encrypted datasets at boot? Re: FreeBSD 13.0-RC2 Now Available
Hi, > On 13 Mar 2021, at 1:11, Glen Barber wrote: > > The second RC build of the 13.0-RELEASE release cycle is now available. Might it be interesting to change the zfs mount -a / zfs unmount -a in /etc/rc.d/zfs to zfs mount -al / zfs unmount -au so that filesystems using the openzfs encryption feature can be automatically mounted? given their keylocation is not “prompt" and accessible during boot. This would make it possible for me to move away from my current dual pool boot setup, in where the boot pool has the geli keys for my geli encrypted system pool, which seems to be incompatible with beadm/bectl handling of things these days… The single geli encrypted pool does not work for me as it doesn’t allow for unattended reboots. Best regards, Ruben signature.asc Description: Message signed with OpenPGP
ThinkPad X1 Carbon Gen 4 unable to boot 13.0-RC1
I have a ThinkPad X1 Carbon Gen 4 (20FCS0NB00) which has happily run FreeBSD 11 and 12, but which can't boot 13.0-RC1 from memstick or via freebsd-update. In both cases the boot process locks up on the line "hwpstate_intel0: on cpu0" If running freebsd-update, a work around is to add hint.hwpstate_intel.0.disabled="1" in loader.conf. See the note under the Eighth Generation (2020) in https://wiki.freebsd.org/Laptops/Thinkpad_X1_Carbon I was quite surprised to find the lack of support for hwpstate_intel in 13 when it apparently worked under 11 and 12. Does anyone know the status of hwpstate_intel on ThinkPads? Cheers, Fred ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
13-RC2 Serial Console not accepting Input
I upgraded a system from 12.2 to 13-RC2 running on an PC Engines Alix APU1D4 system board. It boots and works fine, however despite console output displaying fine, it will not accept any keyboard input. I have the following in my /boot/loader.conf # Enable Serial Console console="comconsole" comconsole_speed="115200" boot_serial="YES" Am I missing something else that has changed requiring a new option to be set for serial consoles? -- Thanks, Dean E. Weimer http://www.dweimer.net/ _______ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Updating to 13-stable and existing ZFS pools: any gotchas?
On 2021-03-17 9:59 am, tech-lists wrote: On Sun, Mar 14, 2021 at 09:59:21AM +0100, Stefan Bethke wrote: I'm planning to upgrade three production machines with existing ZFS pools to 13-stable. Is there anything I need to pay attention to wrt OpenZFS? Or should it be fully transparent, apart from updating loader? My (limited) testing with VMs went without a hitch, but I want to make sure I don't paint myself into a corner. Hi, I'm interested in this as well. I'm not using root-on-zfs. The zpool is 5* spinning rust, the booting media is ssd/ufs2. Is updating the bootcode only relevant for root-on-zfs? I've not done that for a similarly configured desktop system, and it seems to be running stable/13 fine. (the desktop was a stable/12 to stable/13 upgrade). thanks, If you are not booting from zfs its seemless. Just remembe once you issue zpool upgrade you wont be able to go back to older version. If booting from ZFS, just update your boot loader. I have updated a couple of systems from 12.2-RELEASE-p3 to 13.0-RC2. One using UEFI and the other using legacy bios with no problems. for UEFI I mounted EFI Boot partition EFI update, New ZFS data set was mounted at ROOT, zpool is mirror. Updated both EFI partitions in case primary goes offline. zpool set bootfs=ssd/ROOT/13.0-RC2 ssd mount -t msdosfs /dev/ada0p1 /mnt cp ROOT/boot/loader.efi /mnt/EFI/BOOT/BOOTX64.efi umount /mnt mount -t msdosfs /dev/ada1p1 /mnt cp ROOT/boot/loader.efi /mnt/EFI/BOOT/BOOTX64.efi umount /mnt Legacy Bios, again new ZFS data set was mounted at ROOT, and zpool is mirror, updated both boot partitions zpool set bootfs=zroot/ROOT/13.0-RC2 zroot gpart bootcode -b ROOT/boot/pmbr -p ROOT/boot/gptzfsboot -i 1 ada0 gpart bootcode -b ROOT/boot/pmbr -p ROOT/boot/gptzfsboot -i 1 ada1 Everything worked as expected. -- Thanks, Dean E. Weimer http://www.dweimer.net/ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Filesystem operations slower in 13.0 than 12.2
VM_CNT_INC(v_intrans);
>>> if (VM_OBJECT_SLEEP(object, >handle, PSWP,
>>> "swread", hz * 20)) {
>>> printf(
>>> "swap_pager: indefinite wait buffer: bufobj: %p, blkno: %jd, size: %ld\n",
>>> bp->b_bufobj, (intmax_t)bp->b_blkno,
>>> bp->b_bcount);
>>> }
>>> }
>>> VM_OBJECT_WUNLOCK(object);
>>> . . .
>>>
>>> where:
>>>
>>> #define VM_OBJECT_SLEEP(object, wchan, pri, wmesg, timo)\
>>> rw_sleep((wchan), &(object)->lock, (pri), (wmesg), (timo))
>>>
>>> and:
>>>
>>> #define rw_sleep(chan, rw, pri, wmesg, timo)\
>>> _sleep((chan), &(rw)->lock_object, (pri), (wmesg), \
>>> tick_sbt * (timo), 0, C_HARDCLOCK)
>>>
>>> (I do not claim to be able to interpret the implications
>>> of the code that leads to the messages. But seeing some
>>> of the code might prompt a thought by someone that knows
>>> the code's context and operation.)
>>>
>>> > . . .
>>> > Backing off to Mar. 4 was not an improvement. My untar did seem better
>>> > for a couple of minutes, but then the display froze again for 30 seconds
>>> > and disk performance dropped to <1M.
>>
>> You were able to see the disk performance drop while
>> the display was frozen?
>>
>
> No, but it refreshed the display when it un-froze and the refreshed display
> showed a one-minute history that showed that data was still transferring
> during the pause.
>
>> It might not be the best for monitoring but I'll ask
>> this in terms of top output: Does Inact, Laundry,
>> Wired, Free, or other such show anything fairly unique
>> for around the problematical time frame(s)?
>
> These all look pretty normal. Free memory stays at 13G throughout hte
> operatioin.
>
>>> > then things got really bad and behaved in a manner that was baffling to
>>> > me. The screen froze again, but stayed frozen after half a minute. I
>>> > clicked on a couple of buttons in Firefox to no effect and then hit
>>> > ctrl-q to quit. After the long pause, I pressed the power button to try
>>> > to force a shutdown. Suddenly, it started unwinding everything I had done
>>> > during the freeze. My browser did the updates from my mouse clicks
>>> > including quitting. It then switched to a different workspace from
>>> > ctrl-alt-right and did a clean shutdown.
>>> >
>>> > Do I also have a graphics issue? Examining log files show no indication
>>> > that anything was happening. SMART shows no errors and reasonable values
>>> > for everything. No indication of a HW problem. The system performs well
>>> > unless I do something that tries a bulk disk data move. Building world
>>> > takes about 75 minutes. I just have a very hard time building big ports.
>>
>> Almost like things were stuck-sleeping and then the
>> sleep(s) finished?
> Exactly!
Multi-socket (and possibly multi-core) PowerMacs have
not historically had the times used for controlling
sleeping that can be used across FreeBSD's cpus well
matched in any FreeBSD build without extra patches.
They suffer threads being stuck-sleeping for periods
not intended. This leads to fans running wild and
obvious problems during shutdown having timeouts,
though there are more consequences than are so
obvious.
That is where I got the idea for the question: some
similarity to operational problems that I've seen
when not using my patches that provide a work around
matching the times better in my contexts.
(I'm told the type of issue is not limited to PowerMacs,
but PowerMacs are the only PowerPCish machines I've
had access to. Doing the most accurate time matching
gets into platform specific operations, no general
solution for such accuracy. Similarly, only platform
specifics might scale to lots of sockets/cores well,
even without trying to be as well matched. My workaround
is generic to the range of PowerMacs that I've had
access to but is not as accurate about matching the
times.)
For your context: how many sockets? Cores per socket?
Any other information that might be relevant to
matching times across sockets/cores? I suppose that
the board matters, not just the processor(s) in the
sockets. But what all would be appropriate information?
I do not know.
I'm not sure if the kern.hz=100 results fit with this
idea or not. (Such was never involved in my PowerMac
experiments.)
It is only somewhat suggestive evidence as stands. But
time mismatches across socket/cores might be a
direction for investigation? (Not that I've a great
idea for how to investigate such.)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Filesystem operations slower in 13.0 than 12.2
reasonable values for > everything. No indication of a HW problem. The system performs well unless I > do something that tries a bulk disk data move. Building world takes about 75 > minutes. I just have a very hard time building big ports. Almost like things were stuck-sleeping and then the sleep(s) finished? === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 13.0 RC1 UEFI RAID-10 boot problems under VMware Fusion
I’ve updated the installation to RC2, the behaviour has changed in vmware fusion to when I installed one of the BETA releases. The initial boot fails, the system will reboot again and then it succeeds, though more predictable than with the BETAs I’m trying to see the differences in screen recording I made, and I can only see the “Image base” is changed. Load path, load device, bootcurrent, bootinfo path, currdev (disk0p1, EFI)) has not changed. Either something in the loader(s) was changed, or the RC1 to RC2 update placed contents on more “favourable" places on disk that made it possible to boot again. But I do not understand how the loader interacts with the (Vmware) EFI firmware to make sense out of it. > On 10 Mar 2021, at 12:22, Ruben van Staveren wrote: > > To continue on the subject of UEFI booting weirdness > >> On 9 Mar 2021, at 16:57, Ruben van Staveren wrote: >> >> If I press escape and end up in VMWare’s UEFI setup screen I can boot from >> any ada*p1 drive and continue as normal. >> Is UEFI with OpenZFS too new, or is this an issue in VMWare? > > I got an off list tip to see whether this was also the case in bhyve, so I > also created the setup in there, using UEFI boot, and no problems even with > the special/log/cache NVMe vdevs attached to the pool. > > So I’m starting to wonder whether the loader / VMware UEFI firmware (??) > interaction is a bug in VMware or an edge case that needs to be supported too. > > Btw, bhyve is looking nice these days! > > Cheers, >Ruben > signature.asc Description: Message signed with OpenPGP
Re: FreeBSD 13.0 RC1 UEFI RAID-10 boot problems under VMware Fusion
To continue on the subject of UEFI booting weirdness > On 9 Mar 2021, at 16:57, Ruben van Staveren wrote: > > If I press escape and end up in VMWare’s UEFI setup screen I can boot from > any ada*p1 drive and continue as normal. > Is UEFI with OpenZFS too new, or is this an issue in VMWare? I got an off list tip to see whether this was also the case in bhyve, so I also created the setup in there, using UEFI boot, and no problems even with the special/log/cache NVMe vdevs attached to the pool. So I’m starting to wonder whether the loader / VMware UEFI firmware (??) interaction is a bug in VMware or an edge case that needs to be supported too. Btw, bhyve is looking nice these days! Cheers, Ruben _______ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 13.0 RC1 UEFI RAID-10 boot problems under VMware Fusio
> Also, I’m missing /boot/*efifat* in FreeBSD13. What is the procedure for > updating EFI loaders? > > They have been removed because they are no longer needed (filesystem images > for boot blocks trouble me too). Agree, but I’ve felt I’ve missed the memo > > mount -t msdos /dev/da0pX /mnt > mv /mnt/efi/boot/bootx64.efi /mnt/efi/boot/bootx64-old.efi > cp /boot/loader.efi /mnt/efi/boot/bootx64.efi > > The ESP on UEFI systems is just a FAT filesystem. Yes. I think it it noteworthy to have this in the release notes somewhere. that is, if bootx64.efi needs updates every now and then > > One issue you may run into is the size of the partition. If it is tiny, > you'll likely have to create a new ESP. Using /boot/boot1.efi may help and > can be used in the last step instead of loader.efi, but it's much less > flexible than loader.efi. > > Warner Thanks, Ruben signature.asc Description: Message signed with OpenPGP
FreeBSD 13.0 RC1 UEFI RAID-10 boot problems under VMware Fusio
Hi List, With FreeBSD 13 getting near release I was trying out a new hardware setup for a future upgrade, in where a zfs SATA RAID-10 array would be accelated by some NVME devices for cache, log, and special meta data. However, booting the setup under VMWare fusion gives me a lot of zio_read error: 5 / ZFS: i/o error - all block copies unavailable whereas in VirtualBox using the same VMDKs the setup boots without issue, both in UEFI mode I used the guided ZFS install, GPT UEFI only, and choose RAID-10 and zero swap as I want to use the NVME devices for that later on. when on the loader prompt lsdev / lszfs / ls works through latter two throw out zio_read error: 5 but show recognisable output (zfs filesystems, files) disk0 through 4 are the SATA disks with only an EFI and ZFS GPT partition each, disk4/5 is reserved for the special vdevs (but not in use yet) and swap If I press escape and end up in VMWare’s UEFI setup screen I can boot from any ada*p1 drive and continue as normal. Is UEFI with OpenZFS too new, or is this an issue in VMWare? Also, I’m missing /boot/*efifat* in FreeBSD13. What is the procedure for updating EFI loaders? signature.asc Description: Message signed with OpenPGP
Re: geli broken in 13.0-BETA4 and later on armv8
On 2021-Mar-06 10:39:02 -0800, Oleksandr Tymoshenko wrote: >Peter Jeremy via freebsd-current (freebsd-curr...@freebsd.org) wrote: >> [Adding arm@ and making it clearer that this is armv8-only] >> >> On 2021-Mar-06 20:26:19 +1100, Peter Jeremy >> wrote: >> >On 2021-Mar-06 19:18:37 +1100, Peter Jeremy via freebsd-stable >> > wrote: >> >>Somewhere between 13.0-ALPHA2 (c256201-g02611ef8ee9) and 13.0-BETA4 >> >>(releng/13.0-n244592-e32bc253629), geli (at least on my RockPro64 - >> >>RK3399, arm64) has changed so that a geli-encrypted partition (using >> >>AES-XTS 128) that was readable on 13.0-ALPHA2 becomes garbage on >> >>13.0-BETA4. >> > >> >I've confirmed that the problem is f76393a6305b - reverting that >> >commit fixes the problem in releng/13.0. >> > >> >I've further verified that the bug is still present in main (14.x) >> >at 028616d0dd69. > >Could you test this patch and let me know if it fixes the issue? > >https://people.freebsd.org/~gonzo/patches/armv8crypto-xts-fix.diff Yes, it does. Thank you very much. --- Peter Jeremy signature.asc Description: PGP signature
Re: geli broken in 13.0-BETA4 and later on armv8
[Adding arm@ and making it clearer that this is armv8-only] On 2021-Mar-06 20:26:19 +1100, Peter Jeremy wrote: >On 2021-Mar-06 19:18:37 +1100, Peter Jeremy via freebsd-stable > wrote: >>Somewhere between 13.0-ALPHA2 (c256201-g02611ef8ee9) and 13.0-BETA4 >>(releng/13.0-n244592-e32bc253629), geli (at least on my RockPro64 - >>RK3399, arm64) has changed so that a geli-encrypted partition (using >>AES-XTS 128) that was readable on 13.0-ALPHA2 becomes garbage on >>13.0-BETA4. > >I've confirmed that the problem is f76393a6305b - reverting that >commit fixes the problem in releng/13.0. > >I've further verified that the bug is still present in main (14.x) >at 028616d0dd69. -- Peter Jeremy signature.asc Description: PGP signature
Re: geli broken in 13.0-BETA4 and later
On 2021-Mar-06 19:18:37 +1100, Peter Jeremy via freebsd-stable wrote: >Somewhere between 13.0-ALPHA2 (c256201-g02611ef8ee9) and 13.0-BETA4 >(releng/13.0-n244592-e32bc253629), geli (at least on my RockPro64 - >RK3399, arm64) has changed so that a geli-encrypted partition (using >AES-XTS 128) that was readable on 13.0-ALPHA2 becomes garbage on >13.0-BETA4. I've confirmed that the problem is f76393a6305b - reverting that commit fixes the problem in releng/13.0. I've further verified that the bug is still present in main (14.x) at 028616d0dd69. -- Peter Jeremy signature.asc Description: PGP signature
geli broken in 13.0-BETA4 and later
Somewhere between 13.0-ALPHA2 (c256201-g02611ef8ee9) and 13.0-BETA4 (releng/13.0-n244592-e32bc253629), geli (at least on my RockPro64 - RK3399, arm64) has changed so that a geli-encrypted partition (using AES-XTS 128) that was readable on 13.0-ALPHA2 becomes garbage on 13.0-BETA4. I've verified that the garbage seems consistent between reboots and isn't impacted by enabling the big cores in 7ba4d0f82955. There's nothing useful reported via geli debugging. I've tried updating to releng/13.0 60e8939aa85b and it's still broken. My suspicion is f76393a6305b - whilst that just talks about AES-GCM, it does a reasonable job of roto-tilling the entire armv8crypto stack. I notice that there are a fixes to f76393a6305b that don't seem to have made it into releng/13.0 and I will continue to investigate. -- Peter Jeremy signature.asc Description: PGP signature
Re: Filesystem operations slower in 13.0 than 12.2
Konstantin Belousov kostikbel at gmail.com wrote on Fri Mar 5 23:12:13 UTC 2021 : > On Sat, Mar 06, 2021 at 12:27:55AM +0200, Christos Chatzaras wrote: . . . > > Command: /usr/bin/time -l portsnap extract (these tests done with 2 > > different idle servers but with same 4TB HDDs models) > > > > FreeBSD 12.2p4 > > > >99.45 real34.90 user59.63 sys > > 100.00 real34.91 user59.97 sys > >82.95 real 35.98 user60.68 sys > > > > FreeBSD 13.0-RC1 > > > > 217.43 real75.67 user 110.97 sys > > 125.50 real63.00 user96.47 sys > > 118.93 real62.91 user96.28 sys > . . . > In the portsnap results for 13RC1, the variance is too high to conclude > anything, I think. I'll note that there are other reports of wide variance in transfer rates observed during an overall operation such as "make extract". The one I'm thinking of is: https://lists.freebsd.org/pipermail/freebsd-stable/2021-March/093251.html which is an update to earlier reports, but based on more recent stable/13. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253968 comment 4 has some more notes about the context. The "make extract" for firefox likely is not as complicated as the portsnap extract example's execution structure. Might be something to keep an eye on if there are on-going examples of over time. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Filesystem operations slower in 13.0 than 12.2
On 2021-Mar-4, at 14:16, Mark Millard wrote:
> Christos Chatzaras chris at cretaforce.gr wrote on
> Thu Mar 4 21:41:01 UTC 2021 :
>
>
>> After finding slow filesystem operations with 13.0-BETA2 I did more tests.
>>
>> All tests done with same hardware (Seagate ST4000NM0245 4TB HDD - 2 disks
>> with RAID-1 using gmirror).
>>
>> Filesystem mounted with noatime.
>>
>> Command used:
>>
>> /usr/bin/time -l portsnap extract
>>
>> but similar differences I see with "/usr/bin/time -l rm -fr /usr/ports"
>
> I doubt that "rm -fr" gets large differences of the
> type:
>
> (from 12.2p4:)
> 0 messages sent
> 0 messages received
> vs. (13.0-BETA4 and 14.0-CURRENT:)
> 4412 messages sent
> 2536379 messages received
The more I think above the above figures, the more
it seems like 12.2 probably just does not track
messsages sent and received, especially given the
lack of huge "voluntary context switches" differences
vs. 13.0-BETA4 and 14.0-CURRENT. (I expect the message
sends/receives to context switch, but I might be
wrong.)
> In other words, large variations in Inter-Process-Communiciation
> counts, especially "received".
>
> It is not obvious that the "portsnap extract" issue
> is dominated by file system I/O vs IPC issues.
>
> portsanp is a script and does something that looks
> like the following, with the "while read" happening
> over 29000 times:
>
> . . . | while read FILE HASH; do
>echo ${PORTSDIR}/${FILE}
>if ! [ -s "${WORKDIR}/files/${HASH}.gz" ]; then
>echo "files/${HASH}.gz not found -- snapshot corrupt."
>return 1
>fi
>case ${FILE} in
>*/)
>rm -rf ${PORTSDIR}/${FILE%/}
>mkdir -p ${PORTSDIR}/${FILE}
>tar -xz --numeric-owner -f ${WORKDIR}/files/${HASH}.gz
> \
>-C ${PORTSDIR}/${FILE}
>;;
>*)
>rm -f ${PORTSDIR}/${FILE}
>tar -xz --numeric-owner -f ${WORKDIR}/files/${HASH}.gz
> \
>-C ${PORTSDIR} ${FILE}
>;;
>esac
>done; then
>
> I expect that the "tar -xz . . . *.gz" sort of commands
> also involve internal IPC use. (It looked like the
> portsnap script has not changed noticeably since
> something like late 2016.)
I wonder if the large user and/or sys differences between
12.2 and 13.0-BETA4 might be in process creation given the
over 29000 repititions of the loop and the number of
processes created per loop iteration.
The block input and output figures make no clear
difference that I can tell:
29 block input operations
2783 block output operations
vs.
716 block input operations
868 block output operations
There is also:
11821398 page reclaims
vs.
12288156 page reclaims
but none of that suggests that scale of differences in:
98.18 real35.31 user59.31 sys
vs.
163.81 real71.93 user 107.32 sys
So it might be that "time -l" just does not report
on what makes up much of the difference.
Given the scale of the differences, I'd not expect
the variations in the likes of "involuntary context
switches" or the like to explain much of the
observed differences.
(I avoid 14.0-CURRENT for this because of its debug
build status that was reported. I avoid 13.0-BETA2
because of know block input/output operation count
issues.)
> (13.0-BETA2 showed a large "voluntary context switches"
> difference as well, but I ignore that middle step in
> the version sequence here.)
>
> So I expect publishing the "rm -fr /usr/ports" figures
> from "time -l" would be appropriate. I do not know if
> the reports should be via separate topic or not but I
> doubt the figures with large differences will be the
> same for most-modern vs. older: I do not expect notable
> IPC from "rm -fr".
>
>> --
>>
>> FreeBSD 12.2p4
>>
>> 98.18 real35.31 user59.31 sys
>> 49064 maximum resident set size
>>21 average shared memory size
>> 3 average unshared data size
>>86 average unshared stack size
>> 11821398 page reclaims
>> 0 page faults
>> 0 swaps
>>29 block input operations
>> 2783 block output operations
>> 0 messages sent
>> 0 me
Re: Filesystem operations slower in 13.0 than 12.2
Christos Chatzaras chris at cretaforce.gr wrote on
Thu Mar 4 21:41:01 UTC 2021 :
> After finding slow filesystem operations with 13.0-BETA2 I did more tests.
>
> All tests done with same hardware (Seagate ST4000NM0245 4TB HDD - 2 disks
> with RAID-1 using gmirror).
>
> Filesystem mounted with noatime.
>
> Command used:
>
> /usr/bin/time -l portsnap extract
>
> but similar differences I see with "/usr/bin/time -l rm -fr /usr/ports"
I doubt that "rm -fr" gets large differences of the
type:
(from 12.2p4:)
0 messages sent
0 messages received
vs. (13.0-BETA4 and 14.0-CURRENT:)
4412 messages sent
2536379 messages received
In other words, large variations in Inter-Process-Communiciation
counts, especially "received".
It is not obvious that the "portsnap extract" issue
is dominated by file system I/O vs IPC issues.
portsanp is a script and does something that looks
like the following, with the "while read" happening
over 29000 times:
. . . | while read FILE HASH; do
echo ${PORTSDIR}/${FILE}
if ! [ -s "${WORKDIR}/files/${HASH}.gz" ]; then
echo "files/${HASH}.gz not found -- snapshot corrupt."
return 1
fi
case ${FILE} in
*/)
rm -rf ${PORTSDIR}/${FILE%/}
mkdir -p ${PORTSDIR}/${FILE}
tar -xz --numeric-owner -f ${WORKDIR}/files/${HASH}.gz \
-C ${PORTSDIR}/${FILE}
;;
*)
rm -f ${PORTSDIR}/${FILE}
tar -xz --numeric-owner -f ${WORKDIR}/files/${HASH}.gz \
-C ${PORTSDIR} ${FILE}
;;
esac
done; then
I expect that the "tar -xz . . . *.gz" sort of commands
also involve internal IPC use. (It looked like the
portsnap script has not changed noticeably since
something like late 2016.)
(13.0-BETA2 showed a large "voluntary context switches"
difference as well, but I ignore that middle step in
the version sequence here.)
So I expect publishing the "rm -fr /usr/ports" figures
from "time -l" would be appropriate. I do not know if
the reports should be via separate topic or not but I
doubt the figures with large differences will be the
same for most-modern vs. older: I do not expect notable
IPC from "rm -fr".
> --
>
> FreeBSD 12.2p4
>
>98.18 real35.31 user59.31 sys
> 49064 maximum resident set size
> 21 average shared memory size
> 3 average unshared data size
> 86 average unshared stack size
> 11821398 page reclaims
> 0 page faults
> 0 swaps
> 29 block input operations
> 2783 block output operations
> 0 messages sent
> 0 messages received
> 0 signals received
> 354648 voluntary context switches
>322 involuntary context switches
>
> --
>
> FreeBSD 13.0-BETA2 (2021-02-12)
>
> 497.88 real76.06 user 120.03 sys
> 49032 maximum resident set size
> 22 average shared memory size
> 3 average unshared data size
> 91 average unshared stack size
> 12288156 page reclaims
> 23 page faults
> 0 swaps
> 29890 block input operations
> 621229 block output operations
> 4412 messages sent
>2536379 messages received
> 0 signals received
>1004790 voluntary context switches
>251 involuntary context switches
>
> --
>
> FreeBSD 13.0-BETA4 (2021-02-26)
>
> 163.81 real71.93 user 107.32 sys
> 49032 maximum resident set size
> 21 average shared memory size
> 3 average unshared data size
> 89 average unshared stack size
> 12288156 page reclaims
> 5 page faults
> 0 swaps
>716 block input operations
>868 block output operations
> 4412 messages sent
>2536379 messages received
> 0 signals received
> 355244 voluntary context switches
>277 involuntary context switches
>
> --
>
> FreeBSD 14-CURRENT (2021-03-04)
>
> 255.43 real74.94 user 148.90 sys
> 49032 maximum resident set size
> 23 average shared memory size
> 3 average unshared data size
> 96 average unshared stack size
> 12288156 page reclaims
> 23 page faults
> 0 swaps
> 31207 block input operations
Re: Trying do mount a slice containing a r/o mounted partition makes the filesystem unreadable
Dear All, On Tue, Mar 02, 2021 at 10:55:15AM +0200, Andriy Gapon wrote: > On 02/03/2021 09:50, Arrigo Marchiori via freebsd-stable wrote: > > Dear All, > > > > On Sat, Feb 27, 2021 at 04:34:52PM +0100, Arrigo Marchiori via > > freebsd-stable wrote: > > > >> Hello Helge, and thank you for replying again. > >> > >> On Sat, Feb 27, 2021 at 03:43:52PM +0100, Helge Oldach wrote: > >> > >>> Arrigo Marchiori via freebsd-stable wrote on Sat, 27 Feb 2021 14:00:24 > >>> +0100 (CET): > >>>> On the memstick, the root filesystem is mounted read-only. I > >>>> apologize, I should have told it explicitly. The ``invalid'' attempt > >>>> is to mount it read-write (no mode is indicated on the command line). > >>> > >>> Try to make it r/w mounted (which I suspect you are attempting to > >>> achieve): > >>> > >>> mount -uw / > >> > >> Ok, I will try this. > >> > >> But just for the record: I am not try to achieve anything. I gave the > >> ``invalid'' mount command by mistake (I wanted to mount a partition > >> from another disk and wrote "da0" instead of "da1") and I saw that the > >> system became unstable. I thought that this should not happen and I > >> reported it here. > > > > I have two updates. > > > > 1- the da0s2a slice starts 16 (blocks?) after the beginning of da0s2. > > bsdlabel(8) output (copied by hand): > > # /dev/da0s2: > > 8 partitions: > > # size offsetfstype[fsize bsize bps/cpg] > > a: 1491200 164.2BSD 0 0 0 > > c: 1491216 0unused 0 0 # "raw" part, don't > > edit > > > > 2- if I mount the partition rw, then the mount command _always_ fails > > with error "operation not permitted" and the system _always_ remains > > stable. This is independent from mounting from /dev/ufs/label or > > /dev/da0s2a. > > > > Therefore I can change the description of this problem report as: > > > > 8<8<8<8<8<8<8<- > > > > When a BSD partition is mounted _read_only_ to / (suppose > > /dev/da0s2a), if I try to mount its containing slice (/dev/da0s2) I > > receive a ``strange'' error message, and from that moment the mounted > > filesystem becomes unreadable. > > > > - If the partition is mounted from /dev/ufs/label, then mount(8) > > reports "Operation not permitted" and the system remains stable. > > This is the expected behavior IMHO. > > > > - If the partition is mounted read_write, from any special device, > >then mount(8) reports: > > - "Operation not permitted" if I try to mount the slice rw, > > - the same strange error message if I try to mount the slice ro, > >and the system remains stable. > > > > - The "strange error message" is "invalid argument" on 11.4-STABLE. > > > > 8<8<8<8<8<8<8<- > > > > Now to the question: is this worth a PR? Was it already reported? Or > > is it just something that ``should not happen'' because root should be > > allowed to shoot themselves in the foot? > > > > Thank you in advance and best regards, > > I think that this is worth a PR. Just reported: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254005 > I think that even when mounting read-only the underlying GEOM object should be > marked for exclusive use. > I vaguely recall that UFS has some quirk in this respect to allow for > modifications by fsck. That is supposed to be limited to the root filesystem. > Maybe it should further be limited to certain boot stages to prevent > foot-shooting after a system is fully booted. Thank you and best regards, -- Arrigo http://rigo.altervista.org ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 13.0-BETA2 and slow IO
Kevin Oberman rkoberman at gmail.com wrote on Mon Mar 1 07:11:32 UTC 2021 : > On Sun, Feb 28, 2021 at 12:49 PM Christos Chatzaras > wrote: > > > Did someone test if this is fixed in BETA4? > > > > Just tried to "make extract" on firefox and I am still seeing transfer > rates around 1.7M when I would expect more like 50M. If I see the same > thing others are, it runs for a while at >40MB and abruptly drops to > 1.5-20M for some random time varying from a few seconds to minutes before > jumping back to >40MB. Is this what others are seeing? I'll note that someone submitted: https://lists.freebsd.org/pipermail/freebsd-bugs/2021-March/100124.html against 13.0-BETA4 for the UFS journaled soft-updates related performance issue(s). They compared something to 12.1-RELEASE for illustration. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
