orivej has quit [(Ping timeout: 265 seconds)]
orivej has joined joined #nixos-aarch64
orivej has quit [(Remote host closed the connection)]
orivej has joined joined #nixos-aarch64
orivej has quit [(Remote host closed the connection)]
orivej has joined joined #nixos-aarch64
<gchristensen> aarch64 friends, any ideas on this fella? https://gist.github.com/grahamc/69006d2e6a08dcdfc0841d1c752e24f5
<Dezgeg> mark it x86-only
<gchristensen> ah, I was hoping an easy fix would make it aarch64 friendly
<gchristensen> sounds good though
<samueldr> I'm working on the NixOS_on_ARM page(s) on the wiki, is it good enough to say that the raspberry pi 3 is supported upstream in the unstable aarch64 port?
<samueldr> (and mark all other boards as community effort supported)
<gchristensen> I'd say rpi3 support is Beta
<samueldr> good enough :)
orivej has quit [(Ping timeout: 268 seconds)]
orivej has joined joined #nixos-aarch64
orivej has quit [(Ping timeout: 260 seconds)]
orivej_ has joined joined #nixos-aarch64
<andi-> just came back to my mind again: is there and issue with moving the kernels away from /boot where extkinux and the raspi config is? after 2-3 kernel changes /boot is full with the default image...
<samueldr> heh
<samueldr> I was thinking about that right now
<samueldr> I'm editing the nixos wiki pages about ARM
<samueldr> and I saw the section about how it boots, and if I understood it properly, nothing forces /boot to be FAT, except possibly the raspberry pi
orivej_ has quit [(Ping timeout: 248 seconds)]
<samueldr> (and even then, I haven't checked)
<samueldr> there is a small bit about resizing partitions
<andi-> extlinux claims to be able to boot off ext4/btrfs/... so should be feasible?
<samueldr> it's not using extlinux to boot (just in case you were looking at syslinux/extlinux's configuration)
<samueldr> it's the format of extlinux's configuration file, but still u-boot
<andi-> ahh
<samueldr> now, u-boot should, too, be able to boot off ext4, I hope
<andi-> and u-boot definitly should be able to boot from non-fat
<samueldr> ^ :)
<samueldr> I've been thinking while destroying^W editing the wiki page that it might be possible to make a FAT-free boot image
<gchristensen> samueldr: thank you for taking care of that wiki article
<andi-> where does the raspi config come from then
<samueldr> that's it, I was thinking about non-raspis :S
<andi-> wasnt that some firmware before the bootloader that read it?
<andi-> ahh
<samueldr> let me fish out a document from their website
<andi-> ok
<clever> andi-: there is a blob in a boot rom, that loads bootcode.bin from the 1st FAT partition, into the L2 cache, and executes it
<andi-> ok
<clever> andi-: bootcode.bin is then responsible for configuring the dram controller, and loading start.elf into ram
<clever> andi-: then start.elf is responsible for parsing config.txt from the FAT partition, and loading the configured kernel (or u-boot)
<samueldr> (I think)
<samueldr> though, it looks like it's possible to *append* the fat partition
<samueldr> (but that breaks expanding!)
<andi-> fair enough, rpi will stay a special snowflake then?!?
<andi-> but then you can't resize rootfs to max size on first boot?
<samueldr> I wouldn't bet on that fact, other boards might also like FAT partitions
<clever> bootcode.bin could also be on mass-storage (still fat), nand flash (not supported fully), SPI flash (also not supported fully), and a usb ethernet NIC
<andi-> sure you can "move" it further back and resize then.,.,.
<clever> the bootrom can load bootcode.bin from nand/spi flash, but the public bootcode.bin doesnt support that, so the boot will fail
<clever> and its not documented at what offset into the flash it belongs
<samueldr> I think the solution would be to use the FAT32 partition only to store bootcode.bin and config.txt for raspi, making u-boot always load /boot/extlinux/exlinux.conf from ext4
<samueldr> but then there might be any number of reasons that the setup is like that right now
<andi-> still havent heard back from the maintainer of of-tee regarding submitting the patch to the 4.14 stable/lts queue :/ probably havee to send it there myself if I do not hear anything in the next 3 days
<clever> samueldr: the rpi also needs start.elf, config.txt, and a relocation file i believe
<samueldr> well, let's re-phrase what I said with "and supporting necessities for raspberry pis"
<samueldr> what I meant with that is if possible, keep the kernels in the ext4 partition
<gchristensen> clever: I'd like to do something worthy of your nick
<clever> yeah, if there is a u-boot on the fat32, the kernels could go elsewhere
orivej has joined joined #nixos-aarch64
<gchristensen> I think I'd like to, in a netboot, prior to mounting disks, reformat /dev/sda, mount it to /mnt-root, and rsync the nix store over from the squashfs to the disk. all the while running libeatmydata. does this seem workable / like it will produce a working single-boot nixos system?
<clever> gchristensen: that does sound like it could work
<gchristensen> clever: anything I should watch out for?
<clever> total data loss from it auto-installing nixos everywhere :D
<clever> make sure you dont tell it to make paperclips
<samueldr> writing a nixos maximizer I see
<gchristensen> haha
<gchristensen> well so really I just want https://github.com/nix-community/aarch64-build-box to stop using unionfs
<clever> ah
<clever> another option, dont use squashfs
<clever> embed an ext4 image into the initrd, and just dd it directly to /dev/sda2
<gchristensen> that seems reasonable too
<clever> then run resize2fs to expand
<gchristensen> neat
<clever> another optimization
<clever> dont embed the ext4 image into the initrd, isntead, put it on an http server, and curl URL > /dev/sda2
<gchristensen> lol
<gchristensen> nah, needs to be self contained
<clever> may also want to gzip that ext4 image
<gchristensen> I think I'd probably just go the rsync route, less fighting what already works :P
orivej has quit [(Write error: Connection reset by peer)]
orivej_ has joined joined #nixos-aarch64
<clever> gchristensen: when i ran gentoo, i had made a usb stick, that booted with the entire system in a squashfs, with a union to a tmpfs
<clever> gchristensen: and i could at shutdown either save a tar of the tmpfs that restored on boot, or remake the entire squashfs
<clever> or neither, and have it all revert!
orivej_ is now known as orivej
<gchristensen> nice!
<Dezgeg> yeah, putting the extlinux.conf + kernels on ext4 on rpi (or anything using u-boot) works fine