Re: git: 61194e9852e6 - main - Add kqueue1() syscall
On Fri, Mar 31, 2023 at 01:27:54PM -0400, Ed Maste wrote: > On Fri, 31 Mar 2023 at 12:38, Charlie Li wrote: > > > > Konstantin Belousov wrote: > > > The branch main has been updated by kib: > > > > > > URL: > > > https://cgit.FreeBSD.org/src/commit/?id=61194e9852e641d1533cd04a5679d6042ff975d3 > > > > > > commit 61194e9852e641d1533cd04a5679d6042ff975d3 > > > Author: Konstantin Belousov > > > AuthorDate: 2023-03-25 23:39:02 + > > > Commit: Konstantin Belousov > > > CommitDate: 2023-03-27 23:39:26 + > > > > > > Add kqueue1() syscall > > > > > > It takes the flags argument. Immediate use is to provide the > > > KQUEUE_CLOEXEC > > > flag for kqueue(2). > > > > > This commit series causes x11/libinput to hit an assert (which also > > silently crashes X on launch): > > > Assertion failed: (libinput->refcount > 0), function libinput_unref, file > > > ../src/libinput.c, line 1957. > > > > devel/libepoll-shim, x11/libinput's prime dependency, has its own > > kqueue1() implementation, which is used when the system does not already > > have one. Reverting this series and rebuilding devel/libepoll-shim to > > use its included implementation allows x11/libinput to work again. > > Ah, NetBSD added kqueue1 some time ago, and it uses the already > existing flags (O_CLOEXEC etc.) > If it's easy to test, can you try changing libepoll-shim to call > kqueue1(KQUEUE_CLOEXEC)? Overloading open(2) flags this way is not wise IMO. Not to mention that a lot of them do not make sense in kqueue(2) context, and that we might want to add other flags which would put even more pressure on the limited O_* bit set. Please see https://reviews.freebsd.org/D39377 for my attempt to somewhat mitigate the mess.
Re: git: 61194e9852e6 - main - Add kqueue1() syscall
On Fri, 31 Mar 2023 at 12:38, Charlie Li wrote: > > Konstantin Belousov wrote: > > The branch main has been updated by kib: > > > > URL: > > https://cgit.FreeBSD.org/src/commit/?id=61194e9852e641d1533cd04a5679d6042ff975d3 > > > > commit 61194e9852e641d1533cd04a5679d6042ff975d3 > > Author: Konstantin Belousov > > AuthorDate: 2023-03-25 23:39:02 + > > Commit: Konstantin Belousov > > CommitDate: 2023-03-27 23:39:26 + > > > > Add kqueue1() syscall > > > > It takes the flags argument. Immediate use is to provide the > > KQUEUE_CLOEXEC > > flag for kqueue(2). > > > This commit series causes x11/libinput to hit an assert (which also > silently crashes X on launch): > > Assertion failed: (libinput->refcount > 0), function libinput_unref, file > > ../src/libinput.c, line 1957. > > devel/libepoll-shim, x11/libinput's prime dependency, has its own > kqueue1() implementation, which is used when the system does not already > have one. Reverting this series and rebuilding devel/libepoll-shim to > use its included implementation allows x11/libinput to work again. Ah, NetBSD added kqueue1 some time ago, and it uses the already existing flags (O_CLOEXEC etc.) If it's easy to test, can you try changing libepoll-shim to call kqueue1(KQUEUE_CLOEXEC)?
Re: git: 61194e9852e6 - main - Add kqueue1() syscall
Konstantin Belousov wrote: The branch main has been updated by kib: URL: https://cgit.FreeBSD.org/src/commit/?id=61194e9852e641d1533cd04a5679d6042ff975d3 commit 61194e9852e641d1533cd04a5679d6042ff975d3 Author: Konstantin Belousov AuthorDate: 2023-03-25 23:39:02 + Commit: Konstantin Belousov CommitDate: 2023-03-27 23:39:26 + Add kqueue1() syscall It takes the flags argument. Immediate use is to provide the KQUEUE_CLOEXEC flag for kqueue(2). This commit series causes x11/libinput to hit an assert (which also silently crashes X on launch): Assertion failed: (libinput->refcount > 0), function libinput_unref, file ../src/libinput.c, line 1957. devel/libepoll-shim, x11/libinput's prime dependency, has its own kqueue1() implementation, which is used when the system does not already have one. Reverting this series and rebuilding devel/libepoll-shim to use its included implementation allows x11/libinput to work again. -- Charlie Li …nope, still don't have an exit line. OpenPGP_signature Description: OpenPGP digital signature
Re: NanoBSD: CURRENT unable to compile 13-STABLE : ld: error: args.o: Opaque pointers are only supported in -opaque-pointers mode (Producer: 'LLVM15.0.7' Reader: 'LLVM 14.0.5')
void wrote on Date: Fri, 31 Mar 2023 13:18:34 UTC : > On Thu, Mar 30, 2023 at 07:30:15PM -0700, Mark Millard wrote: > >Warner Losh wrote on > >Date: Thu, 30 Mar 2023 22:15:38 UTC : > > > >> On Thu, Mar 30, 2023, 3:45 PM void wrote: > >> > >> > On Thu, Mar 30, 2023 at 12:56:53PM -0700, Mark Millard wrote: > >> > > >> > >To my knowledge, FreeBSD has not actively supported newer > >> > >FreeBSD building older FreeBSD across versions. > >> > > >> > Are you sure? I routinely build & run 12.4 and 12-stable bhyve and > >> > poudriere jail instances on -current. > >> > > > >Do you use main's toolchain to do your builds of releng/12.4 > >and stable/12 ? The first time? Their updating builds? As far > >as I can see use of main's toolchain means not using an older > >user space (via/in-a chroot, jail, etc.) to do the builds. > > I don't know in detail about the toolchain. When 12.4 builds on > -current, the screen shows it bootstrapping, and I guess this is for > 12.4. > > The reason I commented on what you wrote was because your assertion > appeared to me[1] to be incorrect, in that logically following on from that > assertion would mean 'don't expect it to work because it's 'not > actively supported' meaning that it's 'unsupported'. > > But I can't contextualise 'actively supported' into 'should work' or > 'expected to work' given Warren's comment about 'best effort basis'. > > I build poudriere jails for 12.4 on -current like so: > > 1. git -C /usr/src checkout releng/12.4 > 2. poudriere jail -c -j 124Ramd64 -J12 -m src=/usr/src -b -v releng/12.4 > > To update: > > 3. git -C /usr/src checkout releng/12.4 > 4. git -C /usr/src pull --ff-only > 5. then I have to delete and build the jail as in [2] otherwise it'll > complain about wrong objectprefix > > is this workflow incorrect? I do my own system builds in a directory tree, such as /usr/obj/DESTDIRs/13_1R-CA72-poud , and then have pourdiere(-devel) null mount such to run its jails in for, in this case, releng/13.1 port building on a main [so: 14] system. So I'd need to investigate some to figure out for sure if there is anything odd about your sequence but the delete and build from scratch I'd expect to automatically do a bootstrap toolchain build and then use that build for the later activity that actually targets releng/12.4 . > >A sequence can be bootstrapped by starting from materials for > >a pre-built release or snapshot of the older user space and > >then update via its internal toolchain. My understanding is > >this is the actively supported way, not building older > >user spaces directly from a newer user space and its > >newer toolchain. > > It appears to me[1] to be building its own toolchain and building within > that. The ports it builds work on the machine it's built for, without > errors about things like ABI etc. I don't do any pre-building, and am > unsure if the poudriere jailbuilding process does anything outside of > the standard build process. > > [1] non-expert in any of this! So it looks to me you are building normal bootstrap toolchains and such via normal procedures. My original note was split in 2 parts: building/using bootstrap toolchains vs. otherwise, with the bulk of the text being just about the "otherwise" case: QUOTE I'm unclear here. Is the goal that a system clang 15+ toolchain can build just the bootstrap toolchain and such that are then used to actually build stable/13? Otherwise I'm unclear on how compatibility with what a system clang 14 toolchain would produce is established. . . . END QUOTE Most anything in the "otherwise" material was not intended to apply to the bootstrap case: very different contexts. By contrast, I was not so worried if building and then using a bootstrap toolchain was the intent (instead of direct use of the newer toolchain for everything). I could not tell which case(s) were the intend coverage for what I was replying to. So, overall, I think that you just went in a different direction than I was trying to go in the "otherwise" part of my original note. === Mark Millard marklmi at yahoo.com
Re: NanoBSD: CURRENT unable to compile 13-STABLE : ld: error: args.o: Opaque pointers are only supported in -opaque-pointers mode (Producer: 'LLVM15.0.7' Reader: 'LLVM 14.0.5')
On Thu, Mar 30, 2023 at 07:30:15PM -0700, Mark Millard wrote: Warner Losh wrote on Date: Thu, 30 Mar 2023 22:15:38 UTC : On Thu, Mar 30, 2023, 3:45 PM void wrote: > On Thu, Mar 30, 2023 at 12:56:53PM -0700, Mark Millard wrote: > > >To my knowledge, FreeBSD has not actively supported newer > >FreeBSD building older FreeBSD across versions. > > Are you sure? I routinely build & run 12.4 and 12-stable bhyve and > poudriere jail instances on -current. > Do you use main's toolchain to do your builds of releng/12.4 and stable/12 ? The first time? Their updating builds? As far as I can see use of main's toolchain means not using an older user space (via/in-a chroot, jail, etc.) to do the builds. I don't know in detail about the toolchain. When 12.4 builds on -current, the screen shows it bootstrapping, and I guess this is for 12.4. The reason I commented on what you wrote was because your assertion appeared to me[1] to be incorrect, in that logically following on from that assertion would mean 'don't expect it to work because it's 'not actively supported' meaning that it's 'unsupported'. But I can't contextualise 'actively supported' into 'should work' or 'expected to work' given Warren's comment about 'best effort basis'. I build poudriere jails for 12.4 on -current like so: 1. git -C /usr/src checkout releng/12.4 2. poudriere jail -c -j 124Ramd64 -J12 -m src=/usr/src -b -v releng/12.4 To update: 3. git -C /usr/src checkout releng/12.4 4. git -C /usr/src pull --ff-only 5. then I have to delete and build the jail as in [2] otherwise it'll complain about wrong objectprefix is this workflow incorrect? A sequence can be bootstrapped by starting from materials for a pre-built release or snapshot of the older user space and then update via its internal toolchain. My understanding is this is the actively supported way, not building older user spaces directly from a newer user space and its newer toolchain. It appears to me[1] to be building its own toolchain and building within that. The ports it builds work on the machine it's built for, without errors about things like ABI etc. I don't do any pre-building, and am unsure if the poudriere jailbuilding process does anything outside of the standard build process. [1] non-expert in any of this! --
Re: Kernel panic on jail start
On Thu, Mar 30, 2023 at 07:08:28PM +0200, Goran Mekić wrote:
> Hello,
>
> I get the kernel panic when starting jail. With git bisect I found out
> the offending commit is 0b56641cfcda30d06243223f37781ccc18455bef. After
> reverting it, everything is back to normal. For completeness, this is my
> jail.conf:
>
> network {
> $id = 1;
> $base = /var/jails;
> persist;
> vnet;
> path = "${base}/${name}";
> mount.devfs;
> host.domainname = "example.com";
> host.hostname = "${name}.${host.domainname}";
> vnet.interface = "epair${id}b";
> devfs_ruleset = 8;
> allow.raw_sockets;
>
> mount += "/var/run/reggae ${path}/var/run/reggae nullfs ro 0 0";
>
> exec.prepare = "[ ! -e ${path}/var/run/reggae ] && mkdir
> ${path}/var/run/reggae || true";
> exec.prepare += "ifconfig epair${id}a && ifconfig epair${id}a destroy ||
> true";
> exec.prestart = "ifconfig epair${id} create up group $(echo ${name} | cut
> -b 1-15) || (ifconfig epair${id}a destroy && false)";
> exec.prestart += "ifconfig jails addm epair${id}a";
> exec.start = "echo ifconfig_${vnet.interface}_name=\\"eth0\\"
> >/etc/rc.conf.d/network";
ah, I see where the problem is,
until its fixed you can try to set compat.linux.use_real_ifnames to 1, or
s/eth0/to some oyhe if name/
> exec.start += "/bin/sh /etc/rc";
> exec.stop = "/bin/sh /etc/rc.shutdown";
> exec.poststop = "ifconfig epair${id}a destroy";
> exec.clean;
> exec.consolelog = "/var/log/jails/${host.hostname}";
> }
>
> The jail root is created with bsdinstall disinstall/distfetch and
> 14-CURRENT.
>
> Regards,
> meka
