h0m1 has quit [Ping timeout: 240 seconds]
h0m1 has joined #nixos-aarch64
cptchaos83 has joined #nixos-aarch64
h0m1 has quit [Ping timeout: 240 seconds]
h0m1 has joined #nixos-aarch64
wavirc22_ has quit [Ping timeout: 255 seconds]
wavirc22 has joined #nixos-aarch64
lovesegfault has quit [Quit: WeeChat 2.7.1]
lovesegfault has joined #nixos-aarch64
Danct12[m] has joined #nixos-aarch64
<Danct12[m]> any server for asking help with nixos-mobile porting?
<Danct12[m]> channels*
<thefloweringash> this is the place
<Danct12[m]> will nixos uses x11? or just wayland?
<Danct12[m]> * will nixos mobile uses x11? or just wayland?
lovesegfault has quit [Quit: WeeChat 2.7.1]
lovesegfault has joined #nixos-aarch64
<insep[m]> well, i'll ask a question too then
<insep[m]> is it possible to use 3.10 kernel mobile-nixos?
<clever> insep[m]: depends on the device, and if it works on that version
<insep[m]> ok, i've asked since i've heard about systemd working only on kernels 3.17+
<clever> insep[m]: some devices lack any drivers in source form, and must use whatever kernel the device originally ran with
<clever> insep[m]: others have a kernel fork without upsreamed drivers, and must run from that fork
lovesegfault has quit [Quit: WeeChat 2.7.1]
orivej has joined #nixos-aarch64
zupo has joined #nixos-aarch64
lovesegfault has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kenji has joined #nixos-aarch64
ZoomZoomZoom has joined #nixos-aarch64
ZoomZoomZoom has quit [Remote host closed the connection]
lovesegfault has quit [Ping timeout: 272 seconds]
lovesegfault has joined #nixos-aarch64
orivej has quit [Ping timeout: 265 seconds]
Acou_Bass has joined #nixos-aarch64
zupo has joined #nixos-aarch64
<insep[m]> clever: can you explain a little bit more?
<insep[m]> btw i have pmos running on that device, curious to try mobile-nixos
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…]
bennofs has joined #nixos-aarch64
<samueldr> insep[m]: you'll probably end up using the OEM's kernel source tree, and yes, it should be possible to use 3.10
orivej has joined #nixos-aarch64
<samueldr> Danct12[m]: it's kind of hard to answer the question, it's like "will nixos [non-mobile] use X11 or wayland?"
<insep[m]> <samueldr "insep: you'll probably end up us"> thanks!
<samueldr> the main goal of Mobile NixOS is to allow the user to configure the system just like they do with non-mobile nixos
<samueldr> it won't prescribe a specific way to use the device
<samueldr> though, part of the goals is to package mobile [desktop] environments, those will probably kind of dictate what you can do with it
<samueldr> insep[m]: just looked, asus-z00t uses a 3.10 kernel, and system starts
<samueldr> systemd*
<insep[m]> oh cool
<samueldr> though I you're also right in that it lacks some features
<samueldr> it will need some workarounds for some services to start
<insep[m]> then i'll just wait until armv7 works in nixos :)
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
<misuzu> thefloweringash: wow!
<thefloweringash> also watch #82051, which I think is the last piece of the puzzle before builds can start
<{^_^}> https://github.com/NixOS/nixpkgs/pull/82051 (by grahamc, 4 hours ago, open): stdenv: update ARM bootstrap tarballs
kenji has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
orivej has quit [Ping timeout: 260 seconds]
<srk> nice!
t184256 has left #nixos-aarch64 [#nixos-aarch64]
t184256 has joined #nixos-aarch64
t184256 has left #nixos-aarch64 ["Error from remote client"]
t184256 has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 258 seconds]
ryantrinkle has joined #nixos-aarch64
<gchristensen> ,tofu
<{^_^}> To get a sha256 hash of a new source, you can use the Trust On First Use model: use probably-wrong hash (for example: 0000000000000000000000000000000000000000000000000000) then replace it with the correct hash Nix expected. See: tofu-vim
<samueldr> hi :)
<samueldr> about 82051, I don't have an armv7l setup ready to do a native build to test the native build, but going from the comments, once all addressed, I don't see anything wrong
<thefloweringash> We could maybe dodge tofu by splitting busybox into fetch without executable, and then runCommand to copy and chmod +x.
<gchristensen> can you runCommand without a busybox?
<gchristensen> this is pretty ... early
<thefloweringash> That’s the part I’m not sure about
<thefloweringash> `builder = bootstrapFiles.busybox;` well then, that seems like a no
<samueldr> will the armv7l jobset be pointing to staging so it can be tested earlier? or another jobset for staging?
<gchristensen> staging already merged
<gchristensen> this PR is to master, and we'll get builds immediately :)
<samueldr> ah, great then :)
<gchristensen> thefloweringash, samueldr: https://github.com/NixOS/nixpkgs/pull/82051 updated with new tarballs / hashes from what happens to be a more recent build
<{^_^}> #82051 (by grahamc, 5 hours ago, open): stdenv: update ARM bootstrap tarballs
<gchristensen> can y'all double-check?
<samueldr> I don't see anything wrong
adisbladis has quit [Quit: WeeChat 2.4]
<thefloweringash> I think you need the `name = "busybox"` in the busyboxes
<samueldr> (but I can't test)
adisbladis has joined #nixos-aarch64
<gchristensen> eh? really?
<gchristensen> it builds here as-is, and it other thing don't already have `name = ...`
<thefloweringash> which step builds?
<thefloweringash> fetchurl defaults name to basename of the url, and i686 uses a url like http://tarballs.nixos.org/stdenv-linux/i686/4907fc9e8d0d82b28b3c56e3a478a2882f1d700f/busybox
<gchristensen> nix-build pkgs/stdenv/linux/bootstrap-files/armv{5tel,6l,7l}.nix; nix-build pkgs/stdenv/linux/bootstrap-files/armv{5tel,6l,7l}.nix --check
<gchristensen> hmm
<thefloweringash> ah, right, the build that fails is the other side: unpacking them on armv7l (and friends, I assume)
<gchristensen> oh
<gchristensen> does that change the hash?
<thefloweringash> doesn't seem to, but double check me
<gchristensen> ok
<gchristensen> does bootstrapTools need a name?
<thefloweringash> not as far as I can tell
<thefloweringash> if you wanted to match the other platforms, you could upload the tarball with the `/busybox` and `/bootstrap-tools.tar.xz` suffixes, eg: https://github.com/NixOS/nixpkgs/blob/d008a348ac0ea05bf1e8382f397f7ec32bb62156/pkgs/stdenv/linux/bootstrap-files/aarch64.nix#L3
<gchristensen> I wonder how those directory hashes are invented
<thefloweringash> seems to be the git commit that produced the builds
<gchristensen> hm
<thefloweringash> with the explicit `name="busybox"` it's building, so seems good
<gchristensen> I feel a bit brain-dead to follow vcunat's instructions
<gchristensen> I don't feel rushed to merge, though, and pointed the jobset to the branch
<samueldr> yeah, that's why, even though it happens approximately only once every three years, it should be somewhat automated so it can be done trivially
<gchristensen> and reproducibly :)
<samueldr> hopefully
adisbladis has quit [Quit: ZNC 1.7.5 - https://znc.in]
adisbladis has joined #nixos-aarch64
<gchristensen> it would be cool if the cross-built and native-built bootstraps were hash-identical :)
<samueldr> yes
<gchristensen> after a mass rebuild, it takes a significant amount of time for the queue runner to load all the queued builds in to its datastructure
h0m1 has quit [Quit: WeeChat 2.7.1]
h0m1 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
orivej has joined #nixos-aarch64
vika_nezrimaya has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
<gchristensen> thefloweringash: can you send me a follow-up PR?
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<gchristensen> hrm
<gchristensen> EFI stub: Booting Linux Kernel...
<gchristensen> EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
<gchristensen> EFI stub: Generating empty DTB
<gchristensen> EFI stub: Exiting boot services and installing virtual address map...
<gchristensen> [...]
<gchristensen> [ 4.414536] RAMDISK: incomplete write (11176 != 17225)
<gchristensen> [ 4.419670] write error
<gchristensen> [ 4.422193] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
<gchristensen> gotten this 2x in a row
<clever> gchristensen: i think your low on ram, and the initrd cant fit in ram
<gchristensen> unlikely
<clever> how much ram? how big of an intird?
<gchristensen> 1567.53mb vs. 128gb
<clever> yeah, thats unlikely
<gchristensen> :D
<gchristensen> I'll assume something went weird in transfer and rebuild it
<samueldr> gchristensen: the ramdisk is bigger, right?
<samueldr> it might not fit between different in-memory structures
<gchristensen> I'm not sure how to answer that question
<clever> there are 2 modes linux supports
<clever> one is a compressed ext2 disk image, that gets jammed into a real ramdisk
<samueldr> the initial question is easy: is that initrd bigger than the previously successful boots?
<clever> the one nixos uses, is a compressed cpio archive, which gets unpacked to a tmpfs
<samueldr> that's the second one here, RAMDISK
<samueldr> I had the same exact error, different cause, during the week
<clever> the naming has been a bit confusing, because i think grub uses the smae name for both, since that stage doesnt care
<samueldr> IIRC this can be anything that caused it to decompress wrongly
<gchristensen> seems to be 194M bigger... what did I do to make it bigger... hrm
<clever> gchristensen: how big is it after decompressing?
<gchristensen> will check shortly, if this next rebuild doesn't just fix it :)
<gchristensen> crashed again. better look after dinner
<samueldr> oops, I was culling my browser tabs and here it is "RAMDISK: incomplete write" lol
<samueldr> it might need ramdisk_size=... which may take XXM for megabytes
<samueldr> though this doc makes me think it's... not relevant? https://www.kernel.org/doc/html/latest/admin-guide/blockdev/ramdisk.html
<samueldr> >> ramdisk_size
<samueldr> This is now obsolete, and should not be used.
<samueldr> though could be coming from the EFI
andi- has quit [Ping timeout: 272 seconds]
<clever> samueldr: when using device-tree, you just pass linux the address for the first and last byte in ram, and then linux takes care of the rest