Re: February 2024 stabilization week
Am 2024-02-24 21:18, schrieb Konstantin Belousov: On Fri, Feb 23, 2024 at 08:34:21PM -0800, Gleb Smirnoff wrote: Hi FreeBSD/main users, the February 2024 stabilization week started with 03cc3489a02d that was tagged as main-stabweek-2024-Feb. At the moment of the tag creation we already knew about several regression caused by libc/libsys split. In the stabilization branch stabweek-2024-Feb we accumulated following cherry-picks from FreeBSD/main: 1) closefrom() syscall was failing unless you have COMPAT_FREEBSD12 in kernel 99ea67573164637d633e8051eb0a5d52f1f9488e eb90239d08863bcff3cf82a556ad9d89776cdf3f 2) nextboot -k broken on ZFS 3aefe6759669bbadeb1a24a8956bf222ce279c68 0c3ade2cf13df1ed5cd9db4081137ec90fcd19d0 3) libsys links to libc baa7d0741b9a2117410d558c6715906980723eed 4) sleep(3) no longer being a pthread cancellation point 7d233b2220cd3d23c028bdac7eb3b6b7b2025125 We are aware of two regressions still unresolved: 1) libsys/rtld breaks bind 9.18 / mysql / java / ... https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277222 Konstantin, can you please check me? Is this the same issue fixed by baa7d0741b9a2117410d558c6715906980723eed or a different one? Most likely. Since no useful diagnostic was provided, I cannot confirm. It is. And for the curious reader: this affected a world which was build with WITH_BIND_NOW (ports build with RELRO and BIND_NOW were unaffected, as long as the basesystem was not build with BIND_NOW). Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature
Re: February 2024 stabilization week
On Fri, Feb 23, 2024 at 08:34:21PM -0800, Gleb Smirnoff wrote: > Hi FreeBSD/main users, > > the February 2024 stabilization week started with 03cc3489a02d that was tagged > as main-stabweek-2024-Feb. At the moment of the tag creation we already knew > about several regression caused by libc/libsys split. > > In the stabilization branch stabweek-2024-Feb we accumulated following > cherry-picks > from FreeBSD/main: > > 1) closefrom() syscall was failing unless you have COMPAT_FREEBSD12 in kernel >99ea67573164637d633e8051eb0a5d52f1f9488e >eb90239d08863bcff3cf82a556ad9d89776cdf3f > 2) nextboot -k broken on ZFS >3aefe6759669bbadeb1a24a8956bf222ce279c68 >0c3ade2cf13df1ed5cd9db4081137ec90fcd19d0 > 3) libsys links to libc >baa7d0741b9a2117410d558c6715906980723eed > 4) sleep(3) no longer being a pthread cancellation point >7d233b2220cd3d23c028bdac7eb3b6b7b2025125 > > We are aware of two regressions still unresolved: > > 1) libsys/rtld breaks bind 9.18 / mysql / java / ... >https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277222 > >Konstantin, can you please check me? Is this the same issue fixed by >baa7d0741b9a2117410d558c6715906980723eed or a different one? Most likely. Since no useful diagnostic was provided, I cannot confirm. > > 2) panic: ... - wait_fw_init - mlx5_load_one >https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277211 > > Hopefully they would be fixed before March stabweek. > > We closed the stabilization period on Thursday. > > If you want to reap the fruits of the stabweek and you are very conservative > and want to use only changes that passed certain level of testing, you can use > the stabweek-2024-Feb branch. The branch is published at > https://github.com/glebius/FreeBSD/tree/stabweek-2024-Feb. > > Otherwise I would recommend to use 7d233b2220cd3d23c028bdac7eb3b6b7b2025125 of > FreeBSD/main as a good point to update. We did not observe any large or risky > changes in main during the week. > > -- > Gleb Smirnoff
commit f74352f breaks world
Moving these definitions breaks world outside the kernel :-( building shared library libmapper_std.so.5 Building /usr/obj/usr/src/amd64.amd64/lib/libiconv_modules/mapper_zone/libmapper_zone.so.5 building shared library libmapper_zone.so.5 Building /usr/obj/usr/src/amd64.amd64/lib/libstats/tcp_stats.o /usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:137:38: error: use of undeclared identifier 'CC_ECN' 137 | STATS_VSS_DVHIST32_USR(HBKTS(DVBKT(CC_ECN), DVBKT(CC_RTO), |^ /usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:137:38: error: use of undeclared identifier 'CC_ECN' /usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:137:53: error: use of undeclared identifier 'CC_RTO' 137 | STATS_VSS_DVHIST32_USR(HBKTS(DVBKT(CC_ECN), DVBKT(CC_RTO), | ^ /usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:137:53: error: use of undeclared identifier 'CC_RTO' /usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:138:13: error: use of undeclared identifier 'CC_RTO_ERR' 138 | DVBKT(CC_RTO_ERR), DVBKT(CC_NDUPACK)), 0) | ^ /usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:138:13: error: use of undeclared identifier 'CC_RTO_ERR' /usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:138:32: error: use of undeclared identifier 'CC_NDUPACK' 138 | DVBKT(CC_RTO_ERR), DVBKT(CC_NDUPACK)), 0) | ^ /usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:138:32: error: use of undeclared identifier 'CC_NDUPACK' /usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:137:38: error: use of undeclared identifier 'CC_ECN' 137 | STATS_VSS_DVHIST32_USR(HBKTS(DVBKT(CC_ECN), DVBKT(CC_RTO), |^ /usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:137:38: error: use of undeclared identifier 'CC_ECN' /usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:137:53: error: use of undeclared identifier 'CC_RTO' 137 | STATS_VSS_DVHIST32_USR(HBKTS(DVBKT(CC_ECN), DVBKT(CC_RTO), | ^ /usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:137:53: error: use of undeclared identifier 'CC_RTO' /usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:138:13: error: use of undeclared identifier 'CC_RTO_ERR' 138 | DVBKT(CC_RTO_ERR), DVBKT(CC_NDUPACK)), 0) | ^ /usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:138:13: error: use of undeclared identifier 'CC_RTO_ERR' /usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:138:32: error: use of undeclared identifier 'CC_NDUPACK' 138 | DVBKT(CC_RTO_ERR), DVBKT(CC_NDUPACK)), 0) | ^ /usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:138:32: error: use of undeclared identifier 'CC_NDUPACK' /usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:142:6: error: invalid application of 'sizeof' to an incomplete type 'struct voistatspec[]' 142 | NVSS(vss_congsig), vss_congsig, 0); | ^ /usr/obj/usr/src/amd64.amd64/tmp/usr/include/sys/stats.h:440:32: note: expanded from macro 'NVSS' 440 | #define NVSS(vss_slots) (sizeof((vss_slots)) / sizeof(struct voistatspec)) |^ 17 errors generated. *** [tcp_stats.o] Error code 1 make[5]: stopped in /usr/src/lib/libstats ERROR_TARGET='tcp_stats.o'
Re: Missing files on -current
On Sat, Feb 24, 2024 at 03:59:01PM +, Gary Jennejohn wrote: > > The function run_rc_scripts is defined in /usr/src/libexec/rc/rc.subr and > is called in /usr/src/libexec/rc/rc. /etc/rc includes /etc/rc.subr. > > So, maybe one of these files is not up to date under /etc? > My fault, etcupdate reported a conflict and I didn't notice it. Sorry for the noise! bob prohaska
Re: Missing files on -current
On Sat, 24 Feb 2024 06:53:37 -0800 bob prohaska wrote: > A Pi4 running -current completed a build/install cycle for world and kernel > without obvious errors but failed to reboot, reporting: > ... > Warning: no time-of-day clock registered, system time will not be set > accurately > Dual Console: Serial Primary, Video Secondary > /etc/rc: run_rc_scripts: not found > /etc/rc: run_rc_scripts: not found > /etc/rc: have: not found > > Sat Feb 24 13:42:09 UTC 2024 > 2024-02-24T13:42:10.007616+00:00 - init 31 - - can't exec getty > '/usr/libexec/getty' for port /dev/ttyv1: No such file or directory > ... > > Uname -a reports: > FreeBSD 15.0-CURRENT FreeBSD 15.0-CURRENT #121 main-n268499-b9870ba93ea9: > Fri Feb 23 23:14:59 PST 2024 > b...@nemesis.zefox.com:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC > arm64distribution. > > Power cycling allowed boot to single-user, running fsck -fy reports a clean > root file system. > > /etc/fstab contains > /dev/da0s2a / ufs rw 1 1 > /dev/da0s1 /boot/msdos msdosfs rw,noatime 0 0 > #tmpfs /tmp tmpfs rw,mode=1777,size=50m 0 0 > /dev/da0s2d /usrufs rw 2 2 > /dev/da0s2b noneswapsw > > There does not seem to be a file named run_rc_scripts present > in the filesystem. > > Any suggestions on how to back myself out of this corner > would be much appreciated! > > Thanks for reading, > The function run_rc_scripts is defined in /usr/src/libexec/rc/rc.subr and is called in /usr/src/libexec/rc/rc. /etc/rc includes /etc/rc.subr. So, maybe one of these files is not up to date under /etc? -- Gary Jennejohn
Re: Missing files on -current
On Sat, Feb 24, 2024 at 07:02:19AM -0800, David Wolfskill wrote: > > This is from an amd64 system at main-n268514-61b88a230bac, but > run_rc_scripts is a shell function defined in /etc/rc.subr. > > So the whine about not finding run_rc_scripts would indicate that at > least one of the following is true: > > * The script that should have sourced /etc/rc.subr failed to do so. > > * /etc/rc.csubr is corrupted, and fails to define run_rc_scripts(). > Indeed, it seems to be absent: root@:~ # more /etc/rc.csubr /etc/rc.csubr: No such file or directory root@:~ # However, the same is true of a Pi3 running 14-release p5. It boots reliably once it reaches loader. I wouldn't expect this part of the boot process to be platform dependent. Maybe -current and -release do things differently? > * /etc/rc.subr is missing. Present and accounted for: root@:~ # ls -l /etc/rc.subr -rw-r--r-- 1 root wheel 51911 Nov 18 21:46 /etc/rc.subr root@:~ # Thanks for writing! bob prohaska
Missing files on -current
A Pi4 running -current completed a build/install cycle for world and kernel without obvious errors but failed to reboot, reporting: ... Warning: no time-of-day clock registered, system time will not be set accurately Dual Console: Serial Primary, Video Secondary /etc/rc: run_rc_scripts: not found /etc/rc: run_rc_scripts: not found /etc/rc: have: not found Sat Feb 24 13:42:09 UTC 2024 2024-02-24T13:42:10.007616+00:00 - init 31 - - can't exec getty '/usr/libexec/getty' for port /dev/ttyv1: No such file or directory ... Uname -a reports: FreeBSD 15.0-CURRENT FreeBSD 15.0-CURRENT #121 main-n268499-b9870ba93ea9: Fri Feb 23 23:14:59 PST 2024 b...@nemesis.zefox.com:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64distribution. Power cycling allowed boot to single-user, running fsck -fy reports a clean root file system. /etc/fstab contains /dev/da0s2a / ufs rw 1 1 /dev/da0s1 /boot/msdos msdosfs rw,noatime 0 0 #tmpfs /tmp tmpfs rw,mode=1777,size=50m 0 0 /dev/da0s2d /usrufs rw 2 2 /dev/da0s2b noneswapsw There does not seem to be a file named run_rc_scripts present in the filesystem. Any suggestions on how to back myself out of this corner would be much appreciated! Thanks for reading, bob prohaska
Re: FreeBSD CURRENT stabilization cycle
Hi, And whom do you want to „stab“ with this? ;) Why not do the same thing that ports does and call this „monthly“ which is pretty much what it is and easy to understand and you can have one build at the end of that week? Cheers, Franco > On 24. Feb 2024, at 12:51, Kirill Ponomarev wrote: > > On 02/23, Mark Millard wrote: >> Gleb Smirnoff wrote on >> Date: Sat, 24 Feb 2024 04:32:52 UTC : >> >>> More seriously speaking, I >>> actually hope that in some future snapshots.FreeBSD.org will start using >>> these >>> points for snapshot generation. >> >> How about also the likes of: >> >> https://pkg.freebsd.org/FreeBSD:15:aarch64/stabweek/ >> >> for pkgbase (various "aarch64" replacements too)? > > yes, great idea, base_stabweek or similar is something I'd vote for.
Re: FreeBSD CURRENT stabilization cycle
On 02/23, Mark Millard wrote: > Gleb Smirnoff wrote on > Date: Sat, 24 Feb 2024 04:32:52 UTC : > > > More seriously speaking, I > > actually hope that in some future snapshots.FreeBSD.org will start using > > these > > points for snapshot generation. > > How about also the likes of: > > https://pkg.freebsd.org/FreeBSD:15:aarch64/stabweek/ > > for pkgbase (various "aarch64" replacements too)? yes, great idea, base_stabweek or similar is something I'd vote for. signature.asc Description: PGP signature
