<samueldr>
built using nix-build -A config.system.build.isoImage -I nixos-config=modules/installer/cd-dvd/installation-cd-minimal-new-kernel.nix in the <nixpkgs/nixos> folder
<samueldr>
the archlinuxarm sd_fusing puts it at 512*97
<samueldr>
(I based the built off of archlinuxarm's
<samueldr>
it's kinda annoying how hardkernel's seems to want to be in the mbr
<samueldr>
can't do gpt I guess
<samueldr>
(bs=1 count=442 is mbr, right?)
<clever>
the MBR and x86 bootstub share the first 512 bytes
<clever>
GPT also has a protective MBR in the first 512
<samueldr>
hm, maybe there's hope
<samueldr>
it would be nice to have a really universal image, UEFI + u-boot "fusable"
<clever>
depending on what tool you use to partition the disk, it can either duplicate the tables to the protective mbr, or just create a single dummy partition, claiming the disk is 100% in use
<samueldr>
with EBBR or u-boot on SPI it would be really "just dd it"
<nbp>
samueldr: Thanks, I will cherry-pick / checkout these changes and test them later today.
LnL has quit [Max SendQ exceeded]
LnL has joined #nixos-aarch64
<exarkun22>
Hi. I'm not ussing AArch64 but I am using armv7l (on pi 3 b+) and having problems with the extlinux bootloader ... anyone mind if I ask some questions about why I'm failing to upgrade my kernel here?
arianvp has quit [Ping timeout: 244 seconds]
<exarkun22>
oh hey look there's an unmounted bootable fat partition with an old kernel on it :/
arianvp has joined #nixos-aarch64
<exarkun22>
cool, took bootable flag off that, put it on the good partition, all is well now
<exarkun22>
(well, except that I still have no gpio access even after switching kernels...)
zimbatm has left #nixos-aarch64 [#nixos-aarch64]
orivej has quit [Ping timeout: 252 seconds]
<nbp>
samueldr: Damn, the kernel compilation is taking a really long time :/
<nbp>
samueldr: not sure I would be able to test it today.
<samueldr>
not saying you should install from it, but you could verify it boots using the pre-built image, it most likely shouldn't cause any issues with regards to trust, hopefully
<nbp>
samueldr: I will try… in the mean time there is still a bunch of tests running in the background, so no hurry to test yet.
<samueldr>
I'm mostly curious, it'd be nice to add aarch64 uefi support that way with the sd-image-aarch64 image... which might be possible
<nbp>
samueldr: If the compilation does not finish soon, I will tell you on Monday.
<gchristensen>
nbp: I could set you up withaccess to the (probably much faster) builder
<nbp>
gchristensen: It might just be that the box is doing something else at the same time.
<nbp>
gchristensen: and I am not in a hurry either ;)
<gchristensen>
are you using aarch64.nixos.community?
<nbp>
gchristensen: I downloaded samueldr iso file, while building it.
<gchristensen>
ah ok
<nbp>
gchristensen: I will tests later, or Monday.
<nbp>
using the linuxPackages_latest is not helping me, as I rebuilds the kernel.
<nbp>
which makes me wonder whether the CONFIG_COMPAT flag is set and if I would have to recompile it anyway :/
<gchristensen>
well, if you would like to have access to a powerful aarch64 builder to help you, send a PR https://github.com/nix-community/aarch64-build-box (note: the cautions in that document apply to the iso from samueldr, afair)
<nbp>
gchristensen: Noted.
FRidh has quit [Quit: Konversation terminated!]
<samueldr>
_latest is not strictly needed
<samueldr>
it was for the raspberry pi to work, but it's not related to UEFI booting, just 4.14 being a bit long in the tooth
<nbp>
samueldr: oh, good to know, I will try without it then.
andi- has quit [Ping timeout: 250 seconds]
<samueldr>
do note that it *could* be needed for better support for stuff, but that's really depending on your board, no idea for its support on mainline
<samueldr>
(e.g. the raspberry pi works without latest, but the video output doesn't once modesetting turns on on 4.14)
<nbp>
oh great …’it recompiles again :/
andi- has joined #nixos-aarch64
<nbp>
samueldr: With your iso, grubs works :)
<samueldr>
that confirms that at least your UEFI is standard and working well
<samueldr>
wondering though "grub works", how does nixos fare?
<nbp>
samueldr: currently it is waiting on "A start job is running for udev Wai…e Initialization"
<samueldr>
hm, so at least the kernel does boot, everything after is uh, out of my knowledge area :)
<nbp>
samueldr: ok, it booted.
<nbp>
samueldr: and give me a login prompt \o/
* nbp
now I will have to find a good name for this box.
<nbp>
samueldr: Thanks :)
<samueldr>
you're welcome, have fun :)
<samueldr>
they I guess this means we need to figure out a good way to make the image uefi-bootable :D
<samueldr>
(while still working for those u-boot slammed right into the initial sectors)
<bennofs[m]>
does the current sd-image have support for headless setup? is there some way to easily execute an initial setup script on first boot=
<samueldr>
the sd-image acts pretty much like the x86_64 installer iso
<samueldr>
in fact, it loads common a configuration
<samueldr>
so, no, but if it was contributed to the x86_64 iso, it should be possible to make it work on aarch64 also
<nbp>
:thinking: Technically, you could make an iso / sd_image which does the intallation for you.
<nbp>
I guess the only trick would be to not loop, and automagically reboot on the newly created system.
<samueldr>
right now, the main difference between sd-image and the iso installer image is that one does a squashfs on iso9660 + EFI support files and the other makes an ext4 partition + FAT32 support partition for raspberry pi, both possibly could be combined
<bennofs[m]>
yeah but it's harder to do so on ARM if you don't have any other ARM machines lying around :)
<bennofs[m]>
where can I find the newest aarch64 image on hydra? seems nixos/trunk-combined doesn't have the aarch64 image anymore and the 18.09 release branch never had a successful build of sd_image for aarch64
<samueldr>
AFAIK there's no "newest" build available yet :/
<samueldr>
(which is now a bit over two months old)
orivej has joined #nixos-aarch64
<gchristensen>
nbp: there are at least a few implementations of that around, notably clever's and the one used for Packet.net's provisioning process :)
<andi->
probabyl fits best here: While crosscompiling from x86_64-linux -> raspberryPi (not the aarch64 version, armv6 IIRC) I need a 32bit x86 compiler for luajit to build some tools it runs during compilation.. It seems like something like `buildPackages.pkgsi686Linux.stdenv.cc` will then be the cross-compiler for x86-64 -> armv6 again. I can not wrap around that issue.. Just adding `-m32` to the HOST_CFLAGS
<andi->
doesn't do the trick since then glibc would need the 32bit stubs which it doesn't have...
<bennofs[m]>
I think we have a gcc-multilib? But that doesn't solve the general issue of course
<samueldr>
andi-: you may want to ask on the discourse AFAIK the ones holding deep cross-compilation knowledge are more likely to read and reply there :/
<andi->
ok, I just saw that there are a few cases were we just create empty stub files.. I'll play around with that first :/
<andi->
there is the multilib stdenv... Yields same result.. seems like I really would need to gain access to `nixpkgsFun` to get another combination of *platform :/
<clever>
andi-: note, that only the oldest rpi's are armv6, the middle generation are armv7, and the newest are armv6+armv7+aarch64
<andi->
I have an RPi1 compatible FPGA board so that is correct
<clever>
ah
<andi->
it is just the closest match we have to that
<andi->
Compiling my little application on that board takes around 50 Minutes... I was hoping crosscompiling would reduce that a bit
<clever>
ah
<clever>
andi-: i'm thinking that the luajit stuff may be broken for cross-compiles
<clever>
if its needing a 32bit x86->32bit arm, then its not correctly changing the bit size when cross-compiling
<andi->
That is why I wanted the 32bit compiler
<andi->
since with just -m32 it didn't properly link anymore and all the libs are not there that it tries to link against
<clever>
pkgsi686Linux gives you a copy of nixpkgs, that is purely 32bit