<exarkun1> Trying to boot sd-image-aarch64-linux with qemu-system-aarch4 and the qemu arm defconfig boot dtb. Boot fails with "Bad Linux ARM zImage magic!". Anyone have any tips on this?
<samueldr> while it's for 32 bit ARM, maybe you can extrapolate from the command here https://nixos.wiki/wiki/NixOS_on_ARM/QEMU
<samueldr> (and document a working one)
<exarkun1> That's pretty much what I tried. I can boot an armv7l system from those instructions but I'm lost/stumped when it comes to aarch64.
<samueldr> but sounds like qemu is trying to do something clever with the image, which has to be booted from u-boot (for our setup)
<samueldr> sorry, never tried sd-image really
<samueldr> but
<samueldr> hmm
* samueldr checks hydra
<samueldr> I've had good success using the EFI image and aarch64 with qemu (kvm on aarch64) https://hydra.nixos.org/job/nixos/trunk-combined/nixos.iso_minimal.aarch64-linux
<samueldr> and I *think* I had it working on x86_64 too
<samueldr> you'll need an aarch64 bios
<samueldr> the second build product, click Help to get a store path for the -fd output of an aarch64 OVMF
<samueldr> is you want to try that way
<samueldr> not saying it'll fit your needs (I don't know them), but that's an alternative
<exarkun1> I guess I have approximately no idea what any of that means. Guess I should learn something about EFI?
<exarkun1> I find this area of the system is difficult to break in to. If you know of any documentation resources that cover it, I'd appreciate any suggestions.
<samueldr> the good thing is that with qemu, booting an EFI image is the same for x86_64 and aarch64 (and also for x86 and armv7l)
<samueldr> the main difference is that it needs a bios built for the specific arch
* samueldr looks for reading material
<samueldr> this is pretty specific to running the UEFI firmware (doesn't deal with booting) https://wiki.linaro.org/LEG/UEFIforQEMU
<samueldr> and I'm pretty sure only adding -cdrom path-to.iso should boot, once the UEFI is working
<samueldr> as for installing, qemu-img to generate a drive and attach it like any other qemu vm
<samueldr> sorry, just realised it's this late
<samueldr> I've got to do some things
<exarkun1> np, thanks for those pointers, I'll see what I can do and probably bug the channel more later :)
orivej has quit [Ping timeout: 240 seconds]
efraim has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
efraim has joined #nixos-aarch64
efraim has quit [Client Quit]
efraim has joined #nixos-aarch64
efraim_ has joined #nixos-aarch64
efraim has quit [Ping timeout: 252 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has joined #nixos-aarch64
efraim_ is now known as efraim
zupo has joined #nixos-aarch64
jtojnar has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<makefu> btw is it currently possible to cross a complete system derivation? even though there is no way to "upgrade" on the system itself it should still be possible to cross-compile the update, nix-copy-closure it and activate it via nix-env, right?
<gchristensen> there is trouble with perl not cross compiling
<exarkun1> Indeed. I have tried cross-compiling a whole system a number of times and never gotten to the end.
<gchristensen> there was a PR to rewrite the core perl pieces to python, but it failed for a few reasons. doing a rewrite is dangerous work, niksnut'd prefer moving to a stricter language (he told me Rust would be okay)
<gchristensen> if anyone wants to take this on, I wrote a pretty good fstab parser, thinking about it :)
<makefu> i like the idea of having a stricter language for the glue code, especially if it provides us with the means to cross a complete system :)
<gchristensen> +1
<exarkun1> Rust sure seems popular now.
<gchristensen> C++ could work too
<exarkun1> Eessh.
<exarkun1> I'm surprised there isn't more focus on a functional language.
<exarkun1> Functional languages only good for toy projects like package/system management? ;)
<gchristensen> lol
<gchristensen> any nice FP langs you like, which produce small binaries?
<exarkun1> intentional goal-post moving (we were discussing cross-compilation, not binary size), unintentional goal-post moving, or is there a set of requirements for the core nix tools written up somewhere that I should look at?
<gchristensen> there is a set of requirements
<gchristensen> a major goal of Eelco's is keeping minimal closure sizes small
<exarkun1> How large is the current nix toolchain implementation, including the set of perl packages required to use it? I'd be surprised if there weren't a mainstream functional language runtime that could produce executables in smaller space.
<gchristensen> this isn't about Nix's toolchain, but about what is present on the minimal NixOS system
<gchristensen> for example, we can't use java's (excellent) XML tooling in the nixos docs by default because users often have to rebuild docs when they change their system -- and java is a large dependency
<gchristensen> correction: this isn't about Nix's toolchain, but about what is required to build the minimal NixOS system
<gchristensen> _and_ what is present in the final image
<exarkun1> can we use "toolchain" as shorthand for "what is required to build the minimal NixOS system"? Or does that have another name?
<gchristensen> sure, the point of confusion was you said "nix toolchain" :)
<exarkun1> ok, sorry
<gchristensen> and this isn't about nix
<exarkun1> it was sloppy of me, indeed.
<gchristensen> (note: before going off and building a new implementation in a language different from Rust or C++ I'd recommend getting a +1)
<exarkun1> So if the perl tools are ported to C++ then the size of the C++ compiler is a factor here?
<gchristensen> mmm not sure
<exarkun1> Don't worry there's -13% chance that I'm going to reimplement anything in the next 5 years
<gchristensen> :)
<gchristensen> it might be reasonable to expect that the tool is fetched from hydra and not rebuilt when you build your system
<gchristensen> (this is not currently true because the perl scripts are regenerated each time the system is built, whereas a compiled version would likely accept these values as run-time parameters)
<gchristensen> in the case of fetching a prebuilt artifact, the important factor is size of the final product
<exarkun1> Okay. So a large build-time toolchain for the implementation language of the relevant artifacts (we're talking about, like, `nix-env` and such, right?) isn't necessarily a disqualifying factor.
<gchristensen> it would be disqualifying if it is common to need to rebuild them
<gchristensen> (see the java bits)
<gchristensen> but not necessarily, right
<exarkun1> right, okay. So needing the build-time toolchain for the implementation language of the relevant artifacts is disqualifying if that toolchain is large.
<exarkun1> But if either you don't need it or it isn't large, it's okay
<exarkun1> (whatever "large" means)
<gchristensen> pretty much
<exarkun1> thanks for the insight
<gchristensen> also probably some qualitative "fitness of purpose" to be part of the judgement. brainfuck would not be a good choice. Idris would probably not be a good choice
<exarkun1> certainly. probably a number of other requirements as well. eg, platform support.
<gchristensen> right
<gchristensen> ah, yes! definitely :)
<exarkun1> and maybe it would even be nice if cross-compilation was supported! ;)
<gchristensen> oh, right, that!
<gchristensen> also a preference for tools which are already part of the toolchain... since the users will already have them ... but... yeah.
<andi-> LLVM-IR? :)
<gchristensen> yes
<andi-> I would rate that more closely to brainfuck but thats my feeling.
* samueldr wonders about perl to LLVM-IR
<andi-> there used to be a Perl to C "transpiler"
<andi-> not sure what it did.. I expect it to have bundled a interpreter and the script in an ELF file..
<exarkun1> Somehow I think that might be a step in the wrong direction
<andi-> My serious thoughts about a replacement are somewhat split.. Moving to a language higher up the "stack" of dependencies/abstractions/… means we will have very frequent rebuilds and many dependencies that can break rebuilds. Looking at how we currently build rust packages I do not like either approach for such a basic component.. I think the optimal solution (for my current view) would be more towards
<andi-> C and C++. Rust would certainly be great for safety/ease of mind/…. 🤔
<samueldr> is Rust useful without dependencies or whatever the "current;u build rust packages" means?
<andi-> It could be but you easily end up in a position where using a crate is favorable over reimplementing things. There is stuff other langauges have in the sdlib that was put into crates on purpose - for good reason IMO..
<andi-> you can also "vendor" all of them (preverably not with the fixed output "hack" we have currently..
<gchristensen> carnix is not any fun at all
<samueldr> I'm sure treating first-party code differently than third-party is a thing that can be argued, possibly with success
<gchristensen> the cargo256 hash thing we do now is pretty nice, actually
<gchristensen> UX wise
<andi-> i have some ongoing off-on discussion with tazjin regarding rewriting the carnix code generator... That is the most painful part fo us.. It breaks in many curious ways and lacks any kind of tests..
<gchristensen> +1
<exarkun1> andi-: I think you can separate "dependencies" from "abstractions". A higher-level language should let you have less churn. Choosing to use fewer outside dependencies should let you have less churn. You can make those decisions somewhat independently.
<andi-> yes UX wise until it shadows a segfault in the tool used ;)
<gchristensen> every time I bump ofborg's deps it is hours of remembering how I use it
* samueldr has about zero experience with the rust thingies
<samueldr> only overhead things
<andi-> I gave up on my nix security tooling because of the carnix experience.. Doesn't help that I rewrote it all but can't deploy it because of syntax errors in the generated nix.
<gchristensen> :|
<andi-> anyway, I think C++ or rust a good alternatives.. it is a tradeoff (as always).
<andi-> one good thing about the python port was that all of the dependencies were in the standard lib...
<gchristensen> wouldn't know that until it is done :P
<gchristensen> the nixos tools are not so complicated, it is possible they won't require external deps
* andi- checks his crytal ball
<gchristensen> > Ask again later
<{^_^}> undefined variable 'Ask' at (string):222:1
zupo has joined #nixos-aarch64
<andi-> if you think about things like the grub installer that take full blown XML as an input you probably wont get away with just commandline arguments. Having something like a JSON parser in the stdlib makes that easier..
<gchristensen> ah true
<gchristensen> let's start the meme RWiiB
<samueldr> RWiiB?
<andi-> rewrite in bash? (where is the 2nd i?)
<samueldr> it in
<andi-> i know but makes no sense to me
<gchristensen> bash ;)
<samueldr> rewriting it in bash or the "it in" ? :)
<samueldr> werll
<samueldr> well*
<andi-> samueldr: I'd say both :)
<samueldr> that sure would reduce the closure size
<gchristensen> the first mis-qualified `rm -rf` would reduce a lot of closures' sizes
<samueldr> your store is rw?
<gchristensen> some of those scripts run before /nix/store is remounted ro
<samueldr> :)
<gchristensen> :)
<andi-> preload a library that prohibits file removal!
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tilpner_ has joined #nixos-aarch64
tilpner has quit [Ping timeout: 268 seconds]
Thra11 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 268 seconds]
tilpner_ is now known as tilpner
zupo_ has quit [Quit: Textual IRC Client: www.textualapp.com]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has quit [Ping timeout: 255 seconds]
zupo has joined #nixos-aarch64
tilpner has quit [Ping timeout: 245 seconds]
tilpner has joined #nixos-aarch64
Thra11 has quit [Ping timeout: 250 seconds]
orivej has joined #nixos-aarch64
Acou_Bass has quit [Quit: byeeeeeeeeeeeeeee]
jackdk has joined #nixos-aarch64
Acou_Bass has joined #nixos-aarch64