<samueldr> oops
<samueldr> thinking back I never had grub cross-compiling I think, it was native
<samueldr> in other news: it now is cross-compiling
<gchristensen> wow, nice!
Thra11 has joined #nixos-aarch64
<samueldr> it's half a lie... EFI grub doesn't yet
<gchristensen> close enough
<clever> ive also found nvme support in grub to be a lie
<clever> it relies on the EFI to provide nvme drivers
<samueldr> the thing is... at its inception EFI was *supposed* to deal with providing basic drivers
<samueldr> and operating systems to embrace them
<clever> except, some motherboards dont ship with nvme drivers
<clever> so a grub on a sata disk, cant open a /boot on nvme
<samueldr> [citation needed, memory might be wrong]
<gchristensen> oof
<thefloweringash> before I roll my own, does anyone happen to have a nice recipe for running an armv7l-linux builder vm with managed nixos config, in something like a systemd unit?
<gchristensen> hah
<gchristensen> I've been looking for one for ages :P
<clever> one minute
<clever> thefloweringash: this is configured to generate an x86_64-linux nixos running under a qemu built for builtins.currentSystem
<clever> the idea, was to run x86 nixos under darwin
<clever> but if you just replace x86_64 with armv7l, it would do arm instead
<clever> currently, it has a bootstrapping issue
<clever> so you need an arm to build the arm guest
<thefloweringash> interesting, what's the story for storage there? does the netboot-minimal profile have a self contained system?
<clever> thefloweringash: the netboot profile will put the entire initial nix store into a squashfs held in the initrd
<clever> thefloweringash: all r/w activity on the nix store is just a tmpfs (increase the ram for the guest) and is lost on shutdown
<thefloweringash> clever: thanks, I've hit build, I'll see if it works once it's finished bootstrapping armv7l
prusnak has quit [Quit: Connection closed for inactivity]
<samueldr> checking the other grub2_* attrs, but _efi now builds
h0m1 has quit [Ping timeout: 276 seconds]
h0m1 has joined #nixos-aarch64
orivej has quit [Ping timeout: 250 seconds]
<samueldr> /nix/store/kgazap16hfy6p1s7w496qp7hhsshvxis-nixos.iso-armv7l-unknown-linux-gnueabihf
<clever> samueldr: ive confirmed that the rpi kernel i'm building is not entirely broken, it can boot under the rpi firmware
<samueldr> great
<clever> only change, is that i re-enabled the option to allow linux to talk to the firmware
<clever> with that off, under my firmware, it fails with division by zero, due to a 0mhz clock
<samueldr> less great is that the nixos iso I cross-compiled is not bootable
<clever> :(
<clever> does it at least have an error?
<samueldr> I think the iso is not respecting the eltorito spec
<samueldr> or something like that
<samueldr> or something else?
<samueldr> I need to look at the logs
<clever> drivers/char/mem.c: device_create(mem_class, NULL, MKDEV(MEM_MAJOR, minor),
<samueldr> oh, it's supposed to be UEFI, so I'm not even sure eltorito matters here
<samueldr> I'm uploading a known good UEFI armv7 iso to validate first that the tianocore build I have here is good
<clever> 63 #ifdef CONFIG_STRICT_DEVMEM
<clever> there it is!
<clever> but its already disabled...
<samueldr> so, next step is uh... figure out the cross-compilation issue with the iso image or... just use the one I had laying around to test
<samueldr> lol
<clever> in my case, i'm trying to read /dev/mem to test things
<clever> but its fauling with a generic EFAULT
<samueldr> will need to figure out whether we enable LPAE outright on armv7 or not
zupo has joined #nixos-aarch64
<clever> 106 /* Ignore what the user says - they're getting the GPIO regs
<clever> 107 whether they like it or not! */
<clever> lol
zupo has quit [Ping timeout: 250 seconds]
zupo has joined #nixos-aarch64
Guest62 has joined #nixos-aarch64
<Guest62> Hi. I'm trying to get hydra on aarch64 to run a build. It seems to run all the pre-requisite steps for a particular build, then stops and never actually starts the queued build. I've tried to fill in "buildMachines" with localhost and "supportedFeatures" but it doesn't have an impact. When looking at the logs I have noticed that "hydra-queue-runner
<Guest62> status" has an empty "supportedFeatures" list for localhost. Any suggestions?
<clever> Guest62: can you pastebin the output of `sudo -u hydra -i hydra-queue-runner --status | jq` ?
<clever> Guest62: line 35 says that you have a builder at localhost, which can run aarch64-linux jobs, and doesnt support any features...
<clever> Guest62: and line 54 says you have one aarch64-linux job, that needs the big-parallel feature
<clever> so, you need to add big-parallel to localhost
<clever> Guest62: what is the current content of /etc/nix/machines and have you tried adding big-parallel?
<Guest62> Yes. That's what I thought. This is what I have in my configuration.nix: nix.buildMachines = [ { hostName = "localhost"; system = "aarch64-linux"; supportedFeatures = ["kvm" "nixos-test" "big-parallel" "benchmark" ]; } ];
<clever> and what did that translate to within /etc/nix/machines ?
<Guest62> localhost aarch64-linux - 6 1 kvm,nixos-test,big-parallel,benchmark
<clever> one min
<clever> Guest62: `grep NIX_REMOTE_SYSTEMS /etc/systemd/system/hydra-queue-runner.service` ?
<Guest62> Environment="NIX_REMOTE_SYSTEMS="
<clever> thats the problem, one minute
<clever> Guest62: did you set services.hydra.buildMachinesFiles ?
<Guest62> I set it to an empty list. That's what I saw in the issue tracker somewhere.
<clever> Guest62: that tells hydra to entirely ignore /etc/nix/machines, and to auto-generate its own localhost config
<clever> Guest62: deleting that line should fix things
<Guest62> Ok. So I should unset it.
<Guest62> Thanks. I'll have a go
<Guest62> clever: you are indeed clever :). I wish I coulda worked that out :S.
<clever> i happen to have spent an hour fixing the exact same issue for somebody else a month ago
<clever> samueldr: i tried dumping the entire IO bank, and the pi took offense to my peeking!
<clever> ext4 barfed huge errors, and the program segfaulted
<clever> and the ELF file truncated itself
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Guest62 has quit [Remote host closed the connection]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 265 seconds]
prusnak has joined #nixos-aarch64
orivej has joined #nixos-aarch64
<thefloweringash> well, it's not pretty, but it works: https://bitbucket.org/thefloweringash/alex-config/src/master/build-slave.nix (clever , gchristensen)
vika_nezrimaya has joined #nixos-aarch64
grw has quit [Ping timeout: 276 seconds]
ryantrinkle has quit [Ping timeout: 240 seconds]
prusnak has quit [Quit: Connection closed for inactivity]
ryantrinkle has joined #nixos-aarch64
grw has joined #nixos-aarch64
vika_nezrimaya has quit [Ping timeout: 250 seconds]
<thefloweringash> except it seems to run at about half the speed as running the sdimage in qemu :-(
kai_w has quit [Quit: Konversation terminated!]
chris| has quit [Quit: ZNC 1.7.3 - https://znc.in]
t184256 has left #nixos-aarch64 [#nixos-aarch64]
t184256 has joined #nixos-aarch64
Thra11 has quit [Ping timeout: 250 seconds]
zupo has joined #nixos-aarch64
<samueldr> oh, I was building an iso... without the bootable stuff
<samueldr> now that I imported the right module, it built something that `file` sees as bootable
<gchristensen> nice
<samueldr> still uploading
<samueldr> it technically boots
<samueldr> mount: mounting unionfs on /mnt-root/nix/store failed: No such device
<gchristensen> ehh good enough
<gchristensen> didn't need that store anyway
<samueldr> I hate seeing my nickname in URLs for search terms I don't know I have a solution for
<gchristensen> lol
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
vika_nezrimaya has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
vika_nezrimaya has quit [Quit: ERC (IRC client for Emacs 26.3)]
<samueldr> I wanted to see if it was an armv7l or cross-compilation issue
<samueldr> went and eval'd a nix-build on armv7l vm
<samueldr> error: invalid integer '4294967295'
<samueldr> looks valid, though that's exactly 32 1 as 32 bit, so minus a sign might explain it
* samueldr tries eval'ing something smaller
<samueldr> okay, nix-build -A nix started building
<samueldr> from the only two results online, it's possible it's been fixed in a newer nix than I'm running
<samueldr> might need to go back one step before continuing on that track...
<samueldr> anyway I can just reuse the known booting iso for just validating the current issue