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-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: NFS issues since upgrading to 13-RELEASE
Just fyi, I just got a "recursed on non-recursed mutex" panic in socantrcvmore() with the D29690 patch, so you might not want to test with that one yet. rick From: owner-freebsd-curr...@freebsd.org on behalf of Olav Gjerde Sent: Thursday, April 15, 2021 3:21 PM To: Allan Jude Cc: freebsd-current@freebsd.org Subject: Re: NFS issues since upgrading to 13-RELEASE CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to ith...@uoguelph.ca Well something do happen if I restart NFS Service on FreeBSD , it works for like 10 seconds then it gets unresponsive again. This is my output from `nfsstat -d 1` 0.00 00.00 0.00 00.00 0.00 00.00 0.00 0 0 0.00 00.00 0.00 00.00 0.00 00.00 0.00 0 0 0.00 00.00 0.00 00.00 0.00 00.00 0.00 0 0 0.00 00.00 0.00 00.00 0.00 00.00 0.00 0 0 0.00 00.00 0.00 00.00 0.00 00.00 0.00 0 0 0.00 00.00 0.00 00.00 0.00 00.00 0.00 0 0 0.00 00.00 0.00 00.00 0.00 00.00 0.00 0 0 0.00 00.00 0.00 00.00 0.00 00.00 0.00 0 0 0.00 00.00 0.00 00.00 0.00 00.00 0.00 0 0 0.00 00.00 0.00 00.00 0.00 00.00 0.00 0 0 0.00 00.00 0.00 00.00 0.00 00.00 0.00 0 0 0.00 00.00 0.00 00.00 0.00 00.00 0.00 0 0 0.00 00.00 0.00 00.00 0.00 00.00 0.00 0 0 0.00 00.00 0.00 00.00 0.00 00.00 0.00 0 0 0.00 00.00 0.00 00.00 0.00 00.00 0.00 0 0 8.00 10258.00 8.02 17170 134.54 2.01 72716 142.54 0.07 51 34 8.00 2273 17.76 7.99 31273 244.07 2.01 133267 261.83 0.14 20 82 8.03 4889 38.33 7.99 25885 202.07 2.06 119340 240.40 0.13 21 81 [= Read =] [= Write ] [=== Total ] KB/t tpsMB/s KB/t tpsMB/s KB/t tpsMB/sms ql %b 7.98 8811 68.64 8.00 12997 101.54 2.22 78396 170.18 0.15 1 80 7.99 9227.20 8.00 3798 29.68 2.10 17965 36.87 0.09 0 11 8.07 2959 23.31 0.00 00.00 2.67 8938 23.31 0.86 32 72 7.97 7088 55.18 0.00 00.00 2.66 21233 55.18 1.05 16 98 7.98 4666 36.38 0.00 00.00 2.66 13986 36.38 0.36 9 29 8.00 4513 35.24 8.00 7662 59.86 2.20 44188 95.10 0.27 10 49 7.98 4799 37.40 8.00 11422 89.23 2.16 60076 126.63 0.19 0 51 8.00 4322 33.76 0.00 00.00 2.67 12967 33.76 0.89 0 42 8.02 4839 37.91 0.00 00.00 2.67 14550 37.91 0.54 17 41 8.01 4516 35.32 0.00 00.00 2.67 13569 35.32 0.57 27 38 7.95 4459 34.62 8.00 11959.34 2.49 18109 43.96 0.55 0 45 0.00 00.00 0.00 00.00 0.00 00.00 0.00 0 0 0.00 00.00 0.00 00.00 0.00 00.00 0.00 0 0 0.00 00.00 0.00 00.00 0.00 00.00 0.00 0 0 0.00 00.00 0.00 00.00 0.00 00.00 0.00 0 0 0.00 00.00 0.00 00.00 0.00 00.00 0.00 0 0 0.00 00.00 0.00 00.00 0.00 00.00 0.00 0 0 0.00 00.00 0.00 00.00 0.00 00.00 0.00 0 0 0.00 00.00 0.00 00.00 0.00 00.00 0.00 0 0 0.00 00.00 0.00 00.00 0.00 00.00 0.00 0 0 On Thu, Apr 15, 2021 at 9:07 PM Olav Gjerde wrote: > I have the same issue, using Ubuntu 20.10 with Linux 5.8 kernel. The Linux > NFS client will get unresponsive and it does not recover in my case, even > if I restart NFS on FreeBSD. I upgraded from FreeBSD 12.1-RELEASE though. > > On Thu, Apr 15, 2021 at 8:36 PM Allan Jude wrote: > >> On 4/15/2021 9:22 AM, Chris Roose wrote: >> > I posted this in -questions and someone suggested I post here as well. >> > >> > I'm having NFS availability issues between my Proxmox client and >> FreeBSD server (10G link) since upgrading to 13-RELEASE. And unfortunately >> I upgraded my ZFS pool to v2.0.0 before I noticed the issue, so I'm kind of >> stuck. >> > >> > Periodically, the NFS server (I've tried both v3 and v4.2 clients) will >> go unresponsive for several minutes. I never had this problem on 12.2, and >> as far as I can tell it's not a disk or network I/O issue. I'll get several >> "nfs: server not responding, still trying" messages on the client and a few >> minutes later it usually recovers. It's not clear to me yet what's causing >> the block. Restarting nfsd on the server will resolve the issue if it >> doesn't clear itself. >> > >> > Any pointers for troubleshooting this? I've been lookin
Re: sys/sys/param.h: 'main' instead of 'Master'?
On Fri, Apr 16, 2021 at 12:20 PM Michael Gmelin wrote: > > > > On 16. Apr 2021, at 19:29, Rodney W. Grimes < > freebsd-...@gndrsh.dnsmgr.net> wrote: > > > > > >> > >> n Fri, Apr 16, 2021 at 11:36 AM Rainer Hurling wrote: > >>> > >>> While viewing sys/sys/param.h I noticed that the comment of the > >>> definition of __FreeBSD_version is probably out of date. > >>> > >>> Since the switch to Git, doesn't it have to be 'main' instead of > 'master'? > >>> > >> > >> This isn't based on a branch name, though I guess if one were going to > >> touch it anyways then "Authoritative" would be a better descriptor. > > > > As well as "Origin". > > (Single) Source of Truth, maybe? > s/Master, p/P/ also makes sense. Warner > -m > > > > >> > >>> #cd /usr/src > >>> #diff -urN sys/sys/param.h.orig sys/sys/param.h | colordiff > >>> --- sys/sys/param.h.orig2021-04-09 12:59:25.363286000 +0200 > >>> +++ sys/sys/param.h 2021-04-16 18:28:46.621429000 +0200 > >>> @@ -60,7 +60,7 @@ > >>> * in the range 5 to 9. > >>> */ > >>> #undef __FreeBSD_version > >>> -#define __FreeBSD_version 147 /* Master, propagated to > newvers */ > >>> +#define __FreeBSD_version 147 /* main, propagated to newvers > */ > >>> > >>> /* > >>> * __FreeBSD_kernel__ indicates that this system uses the kernel of > >>> FreeBSD, > >>> > >>> ___ > >>> freebsd-current@freebsd.org mailing list > >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current > >>> To unsubscribe, send any mail to " > freebsd-current-unsubscr...@freebsd.org" > >> ___ > >> freebsd-current@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to " > freebsd-current-unsubscr...@freebsd.org" > >> > > > > -- > > Rod Grimes > rgri...@freebsd.org > > ___ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscr...@freebsd.org" > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sys/sys/param.h: 'main' instead of 'Master'?
> On 16. Apr 2021, at 19:29, Rodney W. Grimes > wrote: > > >> >> n Fri, Apr 16, 2021 at 11:36 AM Rainer Hurling wrote: >>> >>> While viewing sys/sys/param.h I noticed that the comment of the >>> definition of __FreeBSD_version is probably out of date. >>> >>> Since the switch to Git, doesn't it have to be 'main' instead of 'master'? >>> >> >> This isn't based on a branch name, though I guess if one were going to >> touch it anyways then "Authoritative" would be a better descriptor. > > As well as "Origin". (Single) Source of Truth, maybe? -m > >> >>> #cd /usr/src >>> #diff -urN sys/sys/param.h.orig sys/sys/param.h | colordiff >>> --- sys/sys/param.h.orig2021-04-09 12:59:25.363286000 +0200 >>> +++ sys/sys/param.h 2021-04-16 18:28:46.621429000 +0200 >>> @@ -60,7 +60,7 @@ >>> * in the range 5 to 9. >>> */ >>> #undef __FreeBSD_version >>> -#define __FreeBSD_version 147 /* Master, propagated to newvers */ >>> +#define __FreeBSD_version 147 /* main, propagated to newvers */ >>> >>> /* >>> * __FreeBSD_kernel__ indicates that this system uses the kernel of >>> FreeBSD, >>> >>> ___ >>> freebsd-current@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" >> ___ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" >> > > -- > Rod Grimes rgri...@freebsd.org > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sys/sys/param.h: 'main' instead of 'Master'?
> n Fri, Apr 16, 2021 at 11:36 AM Rainer Hurling wrote: > > > > While viewing sys/sys/param.h I noticed that the comment of the > > definition of __FreeBSD_version is probably out of date. > > > > Since the switch to Git, doesn't it have to be 'main' instead of 'master'? > > > > This isn't based on a branch name, though I guess if one were going to > touch it anyways then "Authoritative" would be a better descriptor. As well as "Origin". > > > #cd /usr/src > > #diff -urN sys/sys/param.h.orig sys/sys/param.h | colordiff > > --- sys/sys/param.h.orig2021-04-09 12:59:25.363286000 +0200 > > +++ sys/sys/param.h 2021-04-16 18:28:46.621429000 +0200 > > @@ -60,7 +60,7 @@ > > * in the range 5 to 9. > > */ > > #undef __FreeBSD_version > > -#define __FreeBSD_version 147 /* Master, propagated to newvers */ > > +#define __FreeBSD_version 147 /* main, propagated to newvers */ > > > > /* > > * __FreeBSD_kernel__ indicates that this system uses the kernel of > > FreeBSD, > > > > ___ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sys/sys/param.h: 'main' instead of 'Master'?
Am 16.04.21 um 18:38 schrieb Kyle Evans: > n Fri, Apr 16, 2021 at 11:36 AM Rainer Hurling wrote: >> >> While viewing sys/sys/param.h I noticed that the comment of the >> definition of __FreeBSD_version is probably out of date. >> >> Since the switch to Git, doesn't it have to be 'main' instead of 'master'? >> > > This isn't based on a branch name, though I guess if one were going to > touch it anyways then "Authoritative" would be a better descriptor. Sounds reasonable. Thanks for the explanation. > >> #cd /usr/src >> #diff -urN sys/sys/param.h.orig sys/sys/param.h | colordiff >> --- sys/sys/param.h.orig2021-04-09 12:59:25.363286000 +0200 >> +++ sys/sys/param.h 2021-04-16 18:28:46.621429000 +0200 >> @@ -60,7 +60,7 @@ >> * in the range 5 to 9. >> */ >> #undef __FreeBSD_version >> -#define __FreeBSD_version 147 /* Master, propagated to newvers */ >> +#define __FreeBSD_version 147 /* main, propagated to newvers */ >> >> /* >> * __FreeBSD_kernel__ indicates that this system uses the kernel of >> FreeBSD, >> ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sys/sys/param.h: 'main' instead of 'Master'?
n Fri, Apr 16, 2021 at 11:36 AM Rainer Hurling wrote: > > While viewing sys/sys/param.h I noticed that the comment of the > definition of __FreeBSD_version is probably out of date. > > Since the switch to Git, doesn't it have to be 'main' instead of 'master'? > This isn't based on a branch name, though I guess if one were going to touch it anyways then "Authoritative" would be a better descriptor. > #cd /usr/src > #diff -urN sys/sys/param.h.orig sys/sys/param.h | colordiff > --- sys/sys/param.h.orig2021-04-09 12:59:25.363286000 +0200 > +++ sys/sys/param.h 2021-04-16 18:28:46.621429000 +0200 > @@ -60,7 +60,7 @@ > * in the range 5 to 9. > */ > #undef __FreeBSD_version > -#define __FreeBSD_version 147 /* Master, propagated to newvers */ > +#define __FreeBSD_version 147 /* main, propagated to newvers */ > > /* > * __FreeBSD_kernel__ indicates that this system uses the kernel of > FreeBSD, > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
sys/sys/param.h: 'main' instead of 'Master'?
While viewing sys/sys/param.h I noticed that the comment of the definition of __FreeBSD_version is probably out of date. Since the switch to Git, doesn't it have to be 'main' instead of 'master'? #cd /usr/src #diff -urN sys/sys/param.h.orig sys/sys/param.h | colordiff --- sys/sys/param.h.orig2021-04-09 12:59:25.363286000 +0200 +++ sys/sys/param.h 2021-04-16 18:28:46.621429000 +0200 @@ -60,7 +60,7 @@ * in the range 5 to 9. */ #undef __FreeBSD_version -#define __FreeBSD_version 147 /* Master, propagated to newvers */ +#define __FreeBSD_version 147 /* main, propagated to newvers */ /* * __FreeBSD_kernel__ indicates that this system uses the kernel of FreeBSD, ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
AW: NFS issues since upgrading to 13-RELEASE
FWIW: r367492 fixes an issue around "premature" transmission of an ACK due to the incoming segment only been partially processed at the time - related to in-kernel TCP consumers which use socket upcalls. Rick mentioned, that the NFS server (one in-kernel TCP user) has stringent requirements on the state of the socket during the upcall, thus D29690 is retaining the lock on the socket buffer until TCP processing is finalized and the upcall can be done without running any risk for transmitting outdated information back to the other end. However, I have no proper way to verify/validate this interaction. My ask would be to test the behavior with D29690 first - but if similar hangs keep reoccurring, then revert r367492 (which will also mean more severe surgery on the TCP processing flow). Thanks. Richard Scheffenegger -Ursprüngliche Nachricht- Von: Rick Macklem Gesendet: Donnerstag, 15. April 2021 23:05 An: Allan Jude ; freebsd-current@freebsd.org Cc: Richard Scheffenegger ; Juraj Lutter Betreff: Re: NFS issues since upgrading to 13-RELEASE NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe. I wrote: [stuff snipped] >- Alternately you can try rscheff@'s alternate proposed patch that is >at > https://reviews.freebsd.og/D29690. Oops, that's https:/reviews.freebsd.org/D29690 rick I have not yet had time to test this one, but since I cannot reproduce the hang, I can only do testing of it to see that it is "no worse" than reverting r367492 for my setup. Please let us know which you choose and whether or not it fixes your problem. >> Any pointers for troubleshooting this? I've been looking through vmstat, >> gstat, top, etc. when the problem occurs, but I haven't been able to >> pinpoint the issue. I can get pcap, but it would be from the hosts, because >> I don't have a 10G tap or managed switch. >> > >run `nfsstat -d 1` and try to capture a few lines from before, during, >and after the stall, and that may provide some insight. > >Specifically, does the queue length grow, suggesting it is waiting on >the I/O subsystem, or does it just stop getting traffic all together. If the revert of r367492 does not fix the problem, monitor the TCP connection(s) via "netstat -a" and, if possible, capture packets via tcpdump -s 0 -w hang.pcap host or similar, run on the server. Ideally the tcpdump would be started before the "hang" occurs, but running one while the hang is occurring (until after it recovers) could also be useful. Thanks for reporting this, rick -- Allan Jude ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Cross-compiling CURRENT to Raspberry 4
Hi, I've been running 14.0-CURRENT with the default raspberry image (main-n245255-483c6da3a20) on my Raspberry 4. I would like to follow CURRENT but there is not enough space with just the SD card to compile on the pi. I tried to compile the kernel, using the same git version but without debug on my other computer (amd64, running 13.0-RELEASE) and install it with SSHFS. But the new kernel failed to boot with an error 19. Here is how I compiled the kernel : > git clone -o freebsd -b main https://git.freebsd.org/src.git src > git checkout -b 483c6da3a20 > mkdir obj > setenv MAKEOBJDIRPREFIX ~/softwares/raspberry-update/obj/ > time make -j 4 TARGET=arm64 TARGET_ARCH=aarch64 buildkernel > KERNCONF=GENERIC-NODEBUG > sshfs -o idmap=user root@raspberry:/ /raspberry > make TARGET_ARCH=aarch64 DESTDIR=/raspberry/ KERNCONF=GENERIC-NODEBUG > installkernel Any ideas ? Thanks ! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Trying to build Current
On 15-4-2021 14:20, Emmanuel Vadot wrote: On Thu, 15 Apr 2021 10:51:39 +0200 Willem Jan Withagen via freebsd-current wrote: Hi, I actually went completely back to the basic setup with directories /usr/src and /usr/obj But even then I do not manage to buildworld. The process keeps bumping into missing bsm/audit. First case was when it tried to build the 64bit libc. I copied the bsm directory into /usr/obj/usr/src/amd64.amd64/tmp/usr/include/sys/ Which allowed it to continue. But then a bit further on it halts again in 32bit libc. Whcih I could fix the same way. --- fts.o --- In file included from /usr/src/lib/libc/gen/fts.c:40: In file included from /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/mount.h:38: /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/ucred.h:42:10: fatal error: 'bsm/audit.h' file not found #include ^ Even defining HISTORICAL_MAKE_WORLD did not help, but then I'm not doing 'make world' So why is this include file missing? Try with https://cgit.freebsd.org/src/commit/?id=f41efc453ab5563cde214cb19273d87e6e4aa2d4 applied. You probably have WITHOUT_AUDIT=yes in src.conf That seems to do the trick. Thanx, --WjW ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
