<dtz>
and if you're against it, please come discuss that too! :)
<dtz>
still in-progress but looking for co-authors and such, this channel seemed like a good place to look around :D
<sphalerite_>
Dezgeg: that error is what I get when trying to do "file nix-store" in gdb, and nix-store is a *64-bit* image
<sphalerite_>
also iirc the gdb in nixpkgs is now multi-target by default
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 248 seconds]
<sphalerite_>
I don't get it… it seems to throw up a SIGSYS right after the exec: set_tid_address(0x7fb8000958 <unfinished ...> \n+++ killed by SIGSYS +++
<sphalerite_>
that set_tid_address is the first system call after execve
<sphalerite_>
and this only happens when nix is invoking the build, I can build it in a nix-shell just fine
<sphalerite_>
Is it maybe a result of how nix is using clone rather than fork, with some tid magic? I don't really understand what the parameters for clone that differentiate it from fork in this case are and how they might affect this
<sphalerite_>
Although what's also weird is that there's a SIGSYS later on if I use a 32-bit nix
<sphalerite_>
err nvm it's the same
<sphalerite_>
Since this seems to be the go-to place for questions about non-intel systems in general… I've got some stuff building for mips with musl, but it seems I have to run it a couple of times on the target system before it will run reliably
<sphalerite_>
i.e. I'll get SIGILL, maybe SIGTRAP, a couple of times, but from then on it works fine
<sphalerite_>
Any ideas what might cause this sort of funkiness!?
<dtz>
So I missed the context of this entirely, but.. is seccomp filter kicking in? re:sigsys
<dtz>
Iirc an strace can make that more clear, although it caught me off guard first time I saw it since it does some funky things lol
<dtz>
Sigill seems wrong, but dunno. Sigtrap might just be boehmgc doing its thing.
<sphalerite_>
dtz: I was using strace to try and work it out
<sphalerite_>
so disabling seccomp in nix might be something to explore?
<dtz>
Well as a debugging measure maybe. It's possible something needs to be whitelisted or a newer version used... Esp on non-standard platforms
<sphalerite_>
hm I set filter-syscall = false which AFAIU should disable seccomp
<sphalerite_>
and it still got the same SIGSYS failure
<sphalerite_>
filter-syscalls*
<sphalerite_>
as a debugging measure of course, I don't intend to actually use that permanently!
<dtz>
Can't confirm if that's sufficient, but hmm was a thought maybe it's not seccomp :(
<dtz>
This mips still?
<sphalerite_>
OH! Actually I was just calling the wrong nix-store
<sphalerite_>
no sorry there are two things I'm complaining about
<sphalerite_>
the first thing was the 32-bit-capable aarch64 machine which doesn't want to build 32-bit stuff, which I've tried disabling seccomp for and which seems to have helped (yay!)
<sphalerite_>
yep it builds fine with seccomp disabled, thanks for the pointer!
<dtz>
Yay! Hopefully that's enough to carve out a direction for investigating that further. Hip hip hooray!
<sphalerite_>
will have to look into how to handle multi-arch stuff with libseccomp, shouldn't be too hard since the code's already there for 32/64-bit x86
<sphalerite_>
The MIPS issue is that stuff I've built with nix will crash in various ways the first 2 or 3 times I try to run it, and work fine from then on
<sphalerite_>
which seems very strange to me!
<dtz>
My thoughts exactly, although my experience with libseccomp is limited to debugging with porting/maintainer hat on hehe
<dtz>
That is very strange. Lmao what.
chris| has quit [Ping timeout: 256 seconds]
<sphalerite_>
I've observed this with rsync just now
<sphalerite_>
and GNU hello previously, I think
<sphalerite_>
need to double-check by running it again
<dtz>
I mean for something like MIPS... try luck with different gcc/binutils while scouring Google and bug reports? lol :P
<dtz>
Hopefully doesn't come to that
<sphalerite>
hahah
<sphalerite>
for now I think I'll A, blame the kernel, and B, just use the workaround of trying to run the programs several times until they start working xD
chris| has joined #nixos-aarch64
chris| has quit [Ping timeout: 256 seconds]
<sphalerite_>
dtz: it was a very simple fix to get seccomp working on armv7-capable aarch64 :D thanks again for pointing me that way
<dtz>
:D:D hooray
chris| has joined #nixos-aarch64
<sphalerite_>
dtz: also about the getopts bug — it appears to be fixed in nix master as well, is that right?
<dtz>
uhhh it is when built against a recent nixpkgs
<dtz>
which I think as of a few hours ago is probably the case? Haven't chased what's included in that branch
<gchristensen>
we need to be running NixOS tests as part of the release
<Dezgeg>
yeah, might not be worth it to have it in each single hydra eval if we don't upload them to packet frequently
<gchristensen>
yeah
<samueldr>
can the components of said image be tested?
<samueldr>
(so there's a relatively sane assumption that the image will work)
<Dezgeg>
for nixos tests, I doubt not all can be fixed in the timeframe, but a reasonable subset is, someone just needs to decide what's the subset
<Dezgeg>
I think tests.installer.simpleUefiGrub (or whatever it is) is one that definitely needs fixing (mostly to build an UEFI implementation on aarch64, I think)
<gchristensen>
not really, samueldr, not within hydra
<Dezgeg>
well, it's just mostly an UEFI-bootable image, so I don't see why not
buovjaga has quit [Remote host closed the connection]
orivej has joined #nixos-aarch64
<sphalerite_>
dtz: getting some more interesting failures which I think migth be caused by the bootstrpa changes as well :/
<sphalerite_>
specifically rhash
<dtz>
oh no!
<sphalerite_>
wait no
<sphalerite_>
wait yeah
<dtz>
sphalerite_: in a phone call, but that's a priority so any and all details welcome and I'll take a look
<sphalerite_>
these issues are so confusing because the same derivation will succeed or fail depending on the nix version and I keep switching nix versions as well
<dtz>
well stop switching then, silly! ;) :P
<sphalerite_>
trying nix build /nix/store/410q7h8ki4nkpvzsl2sga5sxd1b8gizy-hello-2.10.drv --store /tmp --substituters '' on a machine I'm not otherwise actively using just now
<sphalerite_>
after that I'll try the same with nix itself
<sphalerite_>
actually scratch that I might as well set it off now
<dtz>
if you ever have a nix you're not sure about, you can 'strings' on libnixstore.so (or using some nix-store -q --tree invocation, whatever) and find the 'busybox' it uses, look for the "/bin/sh=/nix/store/hashhashhash-busybox/bin/busybox" and "nix log" on that, filter the "CONFIG_" things.... and check if, for example to build attr, if you see setting CONFIG_FEATURE_SH_MATH=y
<dtz>
i have some tower-of-leaning-toothpicks one-liner on some github issue lol
<dtz>
I started that sentence with the intention of conveying knowledge that would help simplify things for you