[+grembo@ for iocage]
On 3/15/25 06:26, Alexander Leidinger wrote:
Am 2025-02-26 16:20, schrieb Alexander Leidinger:
Hi,
the working system is from 2025-01-25-141603, the non working system
is from 2025-02-21-115311.
I'm not sure what the issue is exactly. I have traced down the change
of behavior to
---snip---
if not LIBC.setfstab(fstab_file_path.encode()):
---snip---
In the working case LIBC.setfstab returns true (so with the not it
doesn't take this branch), and in the non-working case it returns
false (so with the not it takes this branch).
Is someone aware of a change in this area? Searching for it (https://
cgit.freebsd.org/src/log/?qt=grep&q=setfstab) only brings the initial
commit.
Interestingly my own commit triggers this issue.
I bisected and commit 1c2ae9233b0ed4f6b92c59c0e4026f6ddc073e4a is
causing this. This is the first ref which triggers the issue that iocage
can not mount filesystems anymore. And the failing call in iocage seems
to be the python LIBC.setfstab() call. And this only triggers, when the
basesystem is compiled with the stack clash protection. I do not see any
obvious issue in our setfstab code. Anyone with an idea?
setfstab() implementation seems more or less fine, but it's hard to tell
what's going on with iocage there. setfstab(3) doesn't actually have a
return value in any version of FreeBSD, so I guess it's picking up some
sort of garbage as the return value.
Looking at the context, you can only tell if the open failed with the
subsequent getfsent()/setfsent(); that branch should probably just be
removed entirely, and the initial getfsent() might be worth
error-checking for potential error or premature EOF.
Thanks,
Kyle Evans
