<colemickens>
good enough, there's a commit to use
<colemickens>
why can't they tag it?
<colemickens>
oh well
<colemickens>
thanks for the pointers
<samueldr>
that would be too easy
<samueldr>
why isn't it more open source?
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
superherointj has joined #nixos-aarch64
zupo has joined #nixos-aarch64
superherointj has quit [Client Quit]
superherointj has joined #nixos-aarch64
hexa- has quit [*.net *.split]
danielrf[m] has quit [*.net *.split]
yangm has quit [*.net *.split]
Ericson2314 has quit [*.net *.split]
jdnixx-M has quit [*.net *.split]
jdnixx-M has joined #nixos-aarch64
danielrf[m] has joined #nixos-aarch64
Ericson2314 has joined #nixos-aarch64
yangm has joined #nixos-aarch64
hexa- has joined #nixos-aarch64
yangm has quit [Ping timeout: 242 seconds]
Ericson2314 has quit [Ping timeout: 242 seconds]
craige[m] has quit [Ping timeout: 268 seconds]
submoo[m] has quit [Ping timeout: 240 seconds]
danielrf[m] has quit [Ping timeout: 258 seconds]
thefloweringash has quit [Ping timeout: 268 seconds]
mica[m] has quit [Ping timeout: 260 seconds]
puzzlewolf has quit [Ping timeout: 268 seconds]
Ox4A6F has quit [Ping timeout: 244 seconds]
hiroshi[m] has quit [Ping timeout: 244 seconds]
DavHau[m] has quit [Ping timeout: 246 seconds]
veleiro has quit [Ping timeout: 240 seconds]
manveru[m] has quit [Ping timeout: 240 seconds]
JJJollyjim has quit [Ping timeout: 240 seconds]
noneucat has quit [Ping timeout: 244 seconds]
leonardp has quit [Ping timeout: 244 seconds]
pinage404[m] has quit [Ping timeout: 244 seconds]
roberth has quit [Ping timeout: 244 seconds]
pachumicchu has quit [Ping timeout: 268 seconds]
LinuxHackerman has quit [Ping timeout: 268 seconds]
flo[m] has quit [Ping timeout: 268 seconds]
edrex has quit [Ping timeout: 240 seconds]
colemickens has quit [Ping timeout: 240 seconds]
fgaz has quit [Ping timeout: 240 seconds]
siraben has quit [Ping timeout: 240 seconds]
Dandellion has quit [Ping timeout: 240 seconds]
unclechu has quit [Ping timeout: 240 seconds]
bbigras has quit [Ping timeout: 240 seconds]
cornu has quit [Ping timeout: 246 seconds]
l-as has quit [Ping timeout: 260 seconds]
kloenk has quit [Ping timeout: 268 seconds]
Danct12[m] has quit [Ping timeout: 268 seconds]
Ke has quit [Ping timeout: 268 seconds]
hpfr has quit [Ping timeout: 268 seconds]
dtz has quit [Ping timeout: 268 seconds]
superherointj has quit [Quit: Leaving]
superherointj has joined #nixos-aarch64
superherointj has quit [Client Quit]
zarel has quit [Ping timeout: 265 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
DavHau[m] has joined #nixos-aarch64
bbigras has joined #nixos-aarch64
manveru[m] has joined #nixos-aarch64
pinage404[m] has joined #nixos-aarch64
kloenk has joined #nixos-aarch64
LinuxHackerman has joined #nixos-aarch64
puzzlewolf has joined #nixos-aarch64
Danct12[m] has joined #nixos-aarch64
colemickens has joined #nixos-aarch64
edrex has joined #nixos-aarch64
Ox4A6F has joined #nixos-aarch64
hpfr has joined #nixos-aarch64
unclechu has joined #nixos-aarch64
Ericson2314 has joined #nixos-aarch64
danielrf[m] has joined #nixos-aarch64
dtz has joined #nixos-aarch64
Ke has joined #nixos-aarch64
leonardp has joined #nixos-aarch64
l-as has joined #nixos-aarch64
submoo[m] has joined #nixos-aarch64
flo[m] has joined #nixos-aarch64
siraben has joined #nixos-aarch64
JJJollyjim has joined #nixos-aarch64
mica[m] has joined #nixos-aarch64
roberth has joined #nixos-aarch64
fgaz has joined #nixos-aarch64
noneucat has joined #nixos-aarch64
thefloweringash has joined #nixos-aarch64
cornu has joined #nixos-aarch64
hiroshi[m] has joined #nixos-aarch64
Dandellion has joined #nixos-aarch64
yangm has joined #nixos-aarch64
veleiro has joined #nixos-aarch64
craige[m]1 has joined #nixos-aarch64
pachumicchu has joined #nixos-aarch64
mahogany has joined #nixos-aarch64
superherointj has joined #nixos-aarch64
superherointj has quit [Quit: Leaving]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
zupo has joined #nixos-aarch64
zarel has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has quit [Ping timeout: 265 seconds]
dev_mohe has joined #nixos-aarch64
<dev_mohe>
Hi, when running `nix-build nixos -I nixos-config=nixos/modules/installer/cd-dvd/sd-image-raspberrypi4.nix -A config.system.build.sdImage --argstr system aarch64-linux` does anybody else also get `ErroSysError~executing '/nix/store/ksfgyji1gnn5lzjgb03knlz7kav1wj8i-bash-4.4-p23/bin/bash': No such file or directory` or knows how to fix it?
zupo has joined #nixos-aarch64
<pbb>
dev_mohe: are you doing this on an aarch64 machine?
<dev_mohe>
no, I'm using qemu emulation (binfmt)
<dev_mohe>
on NixOS
<dev_mohe>
x86_64
<pbb>
sounds like it can not find the qemu binary
<pbb>
can you do `ls -l /run/binfmt/aarch64-linux` ?
<pbb>
does it exist?
<dev_mohe>
```ls -l /run/binfmt/aarch64-linux
<dev_mohe>
-rwxr-xr-x 1 root root 103 Jan 22 14:38 /run/binfmt/aarch64-linux``` so yes
<pbb>
and in /proc/sys/fs/binfmt_misc/aarch64-linux it is set as interpreter?
<pbb>
I usually use `--system aarch64-linux` instead of argstr, let's see if that makes a difference
<pbb>
I get: modprobe: FATAL: Module sun4i_drm not found in directory /nix/store/9n2rlgg5r808rd85jqmb0qkimm2q9v01-linux-5.4.79-1.20201201-modules/lib/modules/5.4.79
<pbb>
D:
<pbb>
I'll try building an sd-image-aarch64-new-kernel.nix instead
<dev_mohe>
I should probably mention that I'm using flakes...
<pbb>
oh, but the command you posted is not using flakes?
<dev_mohe>
is there an alternative command for flakes because the wiki didn't help
<pbb>
you posted a command to build an sd-image that works independently of nixflk or flakes
<pbb>
dev_mohe: I can not reproduce your problem. Running `nix-build nixos -I nixos-config=nixos/modules/installer/cd-dvd/sd-image-aarch64-new-kernel.nix -A config.system.build.sdImage --argstr system aarch64-linux` in my nixpkgs master checkout works.
<pbb>
what nixpkgs version/checkout are you using?
<dev_mohe>
b91b91c03bdf6377f0e1bae9fba73f3715a33837 which should be current master
<dev_mohe>
system: "x86_64-linux", multi-user?: yes, version: nix-env (Nix) 2.4pre20201205_a5d85d0, channels(root): "", channels(moritz): "", nixpkgs: /nix/store/15l3rwi1apxdh12dy2mrd1bhry2006r5-source shows empty channels so it should not be able to pick up a wrong version
<pbb>
can you run a nix-collect-garbage and try again?
<dev_mohe>
still the same. I already verified the store but no errors. I think it may have something to do with flakes or some strange config.
<pbb>
As I said: The command you sent does _not_ use flakes in anyway
<dev_mohe>
but then how should I use it instead? because it would make sense then that it doesn't work because i have no channels or so idk
<pbb>
you're not using flakes and you're also not using channels and that's fine
<pbb>
does /nix/store/ksfgyji1gnn5lzjgb03knlz7kav1wj8i-bash-4.4-p23/bin/bash exist?
<pbb>
can you run it from a normal shell?
<dev_mohe>
it exists and I can run it on the host machine
<pbb>
are you using a nixUnstable or nixFlakes nix-daemon on the host?
<pbb>
like: is `nix.package = pkgs.nixUnstable;` in your host config?
<dev_mohe>
nix.package = pkgs.nixFlakes;
<pbb>
okay, I'll try that and see if it gives me the same error
<dev_mohe>
thanks a lot for helping btw.
<pbb>
I'm curious what the problem is as well
<pbb>
strange, it's the same with nixFlakes for me
<dev_mohe>
like it doesnt work or it works?
<pbb>
sd-image-raspberrypi4 fails but with a different error as yours, sd-image-aarch64-new-kernel works
<pbb>
I'm pretty sure it's something with your binfmt setup
<pbb>
maybe /run/binfmt isn't in your sandbox paths
<dev_mohe>
I think I just set `boot.binfmt.emulatedSystems = [ "aarch64-linux" ];`
<pbb>
what is nix.sandboxPaths on your host machen?
<dev_mohe>
I'm back although I lost the chat history. Would there have been a way to keep it? (probably not using the web interface)
<pbb>
yeah, not using the web interface
<pbb>
I use quassel
<pbb>
I run the quasselcore daemon on a server, it keeps connected and logs everything even when my desktops and laptops are off. Then I can connect from any computer using the quassel client.
<dev_mohe>
how does nix find qemu?
<pbb>
in doesn't. the kernel does.
<dev_mohe>
ahh yeah, just check the sandbox qemu is the same as the binfmt one
<pbb>
yes
<pbb>
but it should be, because both are from your system configuration
<dev_mohe>
I have some suspicions with the nixflk config - give me a moment
<pbb>
it still doesn't work?
<dev_mohe>
I found some interactiveShellInit settings in the flake template I'm using and I now get another error message (also disabled sandbox though)
<pbb>
now try building sd-image-aarch64-new-kernel instead of sd-image-raspberrypi4 please
<dev_mohe>
but this means that not a clean bash is used
<pbb>
that is because you disabled the sadnbox i suppose
<pbb>
*sandbox
<dev_mohe>
I'm checking
<pbb>
usually /usr/bin/env should not exist in the sandbox in the first place
<dev_mohe>
dammit you were right
<pbb>
so now? does it work?
<dev_mohe>
no with the sandbox I get the original error again
<dev_mohe>
`nix-build nixos -I nixos-config=nixos/modules/installer/cd-dvd/sd-image-aarch64-new-kernel.nix -A config.system.build.sdImage --system aarch64-linux -j 1` for this
<pbb>
meh
<pbb>
can you check if the correct sandbox paths are in /etc/nix/nix.conf?
<pbb>
hm. I'm out of ideas. you can download an sd-image-aarch64-new-kernel from hydra and boot it on your raspberry pi, but it's probably not what you want?
<dev_mohe>
yeah I know thanks, but I would like to do some modifications and play with it.
<dev_mohe>
still thanks a lot for your efforts
<pbb>
You can also build an sd-image-aarch64-new-kernel on your raspberry pi afterwards
<dev_mohe>
oh no :D
<pbb>
with your modifications
<pbb>
it shouldn't take so long
<dev_mohe>
you're right, because of the binary cache, I forgot
<pbb>
binfmt on a fast x86 is actually similar speed as native aarch64 on th raspberry pi 4
<samueldr>
neat! the peeps working on the somewhat-liberated modem firmware for the pinephone might soon have a replacement for yet another proprietary component
<{^_^}>
#110540 (by mohe2015, 41 seconds ago, open): Can't cross-compile aarch64 images on x86_64 with binfmt and flake master
pbb has joined #nixos-aarch64
<samueldr>
sorry to be a nit picker, but it's not cross-compiling unless it comes from the champagne region, otherwise it's bubbling compilation
<samueldr>
uh, unless it's using a cross-compiler* otherwise it's native compilation through qemu-user
<samueldr>
it's important because it changes a lot of assumptions
<dev_mohe>
oh yeah, better now?
<samueldr>
sure :)
<samueldr>
it's also about future users searching through issues; generally solutions for one don't apply for the other
<samueldr>
dev_mohe: can you run `file /nix/store/fj18xk7dwk706mfki61klg69dg84gsim-bootstrap-tools/bin/bash`?
<dev_mohe>
of course, I just forgot that it's not actually called like that. Thanks for teaching.
<samueldr>
(sorry if you did earlier and I missed it)
<samueldr>
because `No such file or directory` on running a binary tells me that it might not be using qemu through binfmt, but maybe the binary is somehow wrong in another manner?
<dev_mohe>
but the sandbox is more or less the only possibility left
<dev_mohe>
especially as I get another error when running without the sandbox about sh. Although this may be because of some sandbox internals I don't know of
<samueldr>
is the qemu path direct to the binary, or a wrapper?
<samueldr>
that could be wrapping qemu from another path
<samueldr>
I assume here that adding a nix store path to the sandbox does not bring in all dependencies intrinsically
<samueldr>
(which is what I tried using in the past before there was a NixOS module)
<clever>
ldd sets some magic vars, which causes ld-linux.so to print libs instead of running main()
<clever>
the arm ldd, winds up causing the x86 ld-linux.so for qemu to print the vars, and never actually run qemu's main()
<clever>
so it never runs the arm ld-linux.so
<dev_mohe>
sorry but I don't understand at all what this should tell me :D
<clever>
you need a static build of qemu, for ldd to function properly
<dev_mohe>
but how did people (including me) do this in the past then?
zupo has joined #nixos-aarch64
<samueldr>
you'd need to compare changes from a known-good revision of Nixpkgs for your system build
<samueldr>
(sorry, I really haven't been using binfmt from NixOS)
<dev_mohe>
I did this ages ago and likely not with flakes. But as I have a reproducible example with a cloud-server I may just try some versions there.
<samueldr>
maybe a package was built static beforehand, and now isn't
<samueldr>
dev_mohe: I would hazard a bet that flakes isn't part of the issue
<samueldr>
except maybe, but not really because of flakes, but maybe if you have an overlay from a flake that replaces qemu or something of the like
<dev_mohe>
see the linked gist. it's vanilla and I don't think there is anything strange in there
jumper149 has joined #nixos-aarch64
<dev_mohe>
also works on my local machine with a way more complex cofig
<colemickens>
you know what that kind of looks like?
<colemickens>
a mismatched arch thing, somehow you're pulling in another nixpkgs and not passing in the right system to it
<colemickens>
so you're getting an x86_64 bash and then that results in the "not found" error
<samueldr>
colemickens: here I was going on the assumption that the qemu binary being dynamic is what's wrong
zupo has quit [Client Quit]
zupo has joined #nixos-aarch64
Acou_Bass has joined #nixos-aarch64
<colemickens>
maybe, I just sort of recognized this error and remember it popping up after adopting flakes and wanted to throw it out
<samueldr>
right, not saying it can't be the issue
adisbladis has quit [Ping timeout: 256 seconds]
adisbladis has joined #nixos-aarch64
zupo has quit [Client Quit]
<colemickens>
it looks like I 'mv' instead of 'git mv' in the past and lost the history, but I can see somewhere that I was importing a fetchFromGitHub'ed nixpkgs (rather than using flakes) deep inside my config, and had to add `system = pkgs.system` to the import to get it to do the "right thing" when I evaluated my config on x86_64.
bdju has quit [Read error: Connection reset by peer]
bdju has joined #nixos-aarch64
dev_mohe has quit [Quit: dev_mohe]
{^_^} has quit [Remote host closed the connection]
{^_^} has joined #nixos-aarch64
Acou_Bass has quit [Ping timeout: 256 seconds]
Acou_Bass has joined #nixos-aarch64
<colemickens>
I think I got the kernel to boot but it doesn't see usb storage to pivot to stage-2. I had fixed this with the old bootloader setup, seems like from Arch forums there might be another module or two to add to fix?
<colemickens>
It also looks like there's another u-boot patch on master to help booting larger kernels on rpi3/4 that hasn't hit nixos-unstable(-small) yet. Though, like I said, I did actually see the kernel boot. (Updating the "firmware" [start.elf and friends] seemed to unlock that step)
<samueldr>
colemickens: is that patch the one coming from p//bb? :)
<colemickens>
oh had to look it up the get the acronym, :P yes.
<samueldr>
that's their nickname here
<colemickens>
aha
orivej has joined #nixos-aarch64
<samueldr>
hm, can't find the patch on the patchwork
<samueldr>
unless you mean on our master branch
<samueldr>
(now I think that's what you meant)
<samueldr>
as far as the driver to add, it should be trivial