Thra11 has quit [Ping timeout: 250 seconds]
Thra11 has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
Thra11 has quit [Ping timeout: 250 seconds]
<hark> output '/nix/store/ghd51ri92p7m6wm5885y2d72x4x64z2b-docbook-xml-4.1.2-aarch64-unknown-linux-gnu' is not allowed to refer to the following paths:
<hark> /nix/store/iqsld34p9685qvj31gcaqss6i0yv1rhj-hook
<hark> does someone know what that means?
<sphalerite> hark: the docbook-xml derivation has a {dis,}allowed{References,Requisites} attribute which isn't being satisfied https://nixos.org/nix/manual/#sec-advanced-attributes
<hark> ah, propagatedNativeBuildInputs = [ findXMLCatalogs ]; < thats the issue
<nbp> Ok, I gave up on installing NixOS on the SoftIron Overdrive 1000. Fedora documentation mention that this is the same as rpi3, but the USB stick was hazardly recognized during boot, and when it was it would not boot either. :/
<nbp> So, I am falling back on running Nix on OpenSuse. :(
<samueldr> I'm guessing *for fedora* they're using the same stick :/
<samueldr> the few lookups I made made me think it has a full-blown uefi on it
<nbp> The boot manager, let me poke at the USB file system and locate some initrd file, but nothing which can be used for booting on the USB stick
<samueldr> The OverDrive 1000 uses UEFI as its pre-boot environment. This environment
<samueldr> is based on the Tianocore edk2 project hosted by Intel along with
<samueldr> platform software from Linaro and its OpenPlatformPkg project.
<samueldr> thanks PDF
<samueldr> (thanks PDF since it broke the lines where I didn't want to break lines)
<samueldr> and going from that screencast, I'm like 99% sure that if you *somehow* built an image that had grub configured as it would usually for x86_64 it would boot fine https://asciinema.org/a/117490
<samueldr> (assuming the mainline kernel works fine)
<samueldr> the *somehow* is the part I don't know off the top of my head
<nbp> samueldr: That's how I got the sd_image the first time, by building it.
<nbp> samueldr: however, the EFI menu does not seems to indicate that OpenSuse is using the MBR.
<samueldr> sd-image-aarch64.nix, unless you customized it, doesn'T have anything EFI
<nbp> samueldr: it did mention it on the USB stick the last time it was plugged, but I did not knew how to boot on the USB stick from the EFI menu.
<samueldr> it's built for use with u-boot, and a u-boot that has its extlinux options available and turned on
<samueldr> one thing I'd try to sanity-check that I can boot UEFI programs would be to try booting refind, using a usb drive and the default fallback location (/EFI/boot/boota64.efi for aarch64)
<nbp> samueldr: booting refind?
<samueldr> only since it's something pre-built that hopefully should boot
<samueldr> oh, they also have a usb drive image
<samueldr> let me check if it has the boota64.efi file at the right location
<nbp> samueldr: I will try that later, once I am finished with the current compilation of the build environment that I would need later.
<samueldr> I'll try an experiment this evening (in 8+ hours) with the raspberry pi...
<samueldr> (it doesn't boot EFI by default, but it can do just enough with u-boot to be useful in figuring an important bit out)
<nbp> samueldr: Thanks :)
vasarmilan has joined #nixos-aarch64
vasarmilan has left #nixos-aarch64 [#nixos-aarch64]
<hark> does a remote builder have to run nixos?, or can i use some board with debian/armbian with nix installed?
<gchristensen> that would work
<gchristensen> if I get Firefly to send me a 60 core box for hydra, will anyone help me get it running?
<samueldr> depends on what's to do :)
Thra11 has joined #nixos-aarch64
<flokli> gchristensen: oh yes please, count me in on that fun :-)
<flokli> Btw, is their website broken? At least the link in discourse didn't work
<gchristensen> cool, because I have to promise I'll try hard to make it work, but I lack a lot of the knowledge / exerience / time / interest to actually grind throughh it all myself
<hark> mm, where do i find nix binaries for arm?
<sphalerite> hark: for aarch64, the regular installer should work
<sphalerite> hark: for 32-bit ARM, build it yourself, or fiddle about to get it from one of the multiple binary caches
<gchristensen> I wonder what it'd take to publish an aarch64 image on https://nixos.org/nixos/download.html
<samueldr> not exceeding output size, first https://hydra.nixos.org/build/84458193
<sphalerite> much more uniformity in boot processes as well I'd guess
<samueldr> AFAIK, other than depthcharge, everything is pretty uniform, no?
<samueldr> oh, and the uefi platform there
<sphalerite> there's EFI but you still need to have and load the right DTBs AFAIU?
<gchristensen> sure
<gchristensen> we could publish not a generic one, but a "raspberry pi" one
<sphalerite> samueldr: and not really that either AFAIK, lots of different u-boots which are loaded from and configured in different places
<sphalerite> although I'm certainly not an expert
<sphalerite> the only thing I have practical experience with is depthcharge :')
<samueldr> as far as allwinner images are concerned (not sure yet about rockchip non-chromebook) the SBL is a simple operation, with a bunch already being built by hydra
<samueldr> well, bunch, a small bunch, but a couple still :)
<clever> samueldr: it should also be simple to make something that boots on both rpi and allwinner
<samueldr> I wonder, though, what could be done for depthcharge hardware, I guess it's possible to build useful USB images for them
<samueldr> clever: you mean the same image, but multiple allwinner boards?
<clever> just make a fat32 partition for the rpi firmware and uboot, and another unformatted partition for the SPL (at the right offset)
<clever> and then both uboots load from a common /boot (which could be the fat32, or an ext4)
<samueldr> ah, just like it is now, but with a protected location instead of simply writing in the blank space
<clever> yeah
<clever> just make a proper parttiion at the SPL offset
<gchristensen> I was trying to build ./nixos/release.nix but wouldn't auto-complete ... turned out I had a commit from Tue Sep 11 22:30:30 2007 +0000 checked out :')
<clever> samueldr: and if the rpi firmware can handle GPT, i would use the bios boot partition for the SPL
<samueldr> yeah
<samueldr> I wonder if there's limitations due to the "size" of GPT, maybe one of the aarch64 boards with such a uboot would cause issue?
<clever> ah, it may overrun the SPL location...
<clever> would need testing to confirm
<clever> thats when i was messing with a banana pi
<samueldr> what is there to see?
<clever> i think my problems where due to the PSU, it would eratically fail to even boot u-boot
<clever> just which uboot i used, and how i dd'd it to a uSD
<clever> and the serial output at boot
<samueldr> hah
<samueldr> had a thought
<samueldr> -p : size (in blocks) of the disk to pad between the primary GPT header and its entries
<clever> yeah, that sounds of use
Thra11 has quit [Ping timeout: 252 seconds]
<flokli> gchristensen: seems like their website works again. some nice hardware on there, which I'd probably use for some home infopanels, but I guess the 60 core board can't be found there, right? ;-)
<gchristensen> no idea, I don't know anything about it other than walter on discoures mentioned it :)
shad has quit [Ping timeout: 250 seconds]
shad has joined #nixos-aarch64