exarkun22 has quit [Read error: Connection reset by peer]
pdafriend[m] has quit [Remote host closed the connection]
cornu has quit [Read error: Connection reset by peer]
timokau[m] has quit [Remote host closed the connection]
bkchr[m] has quit [Read error: Connection reset by peer]
Ericson2314 has quit [Read error: Connection reset by peer]
sphalerit has quit [Remote host closed the connection]
codyopel[m] has quit [Read error: Connection reset by peer]
thefloweringash has quit [Read error: Connection reset by peer]
peel has quit [Remote host closed the connection]
dtz has quit [Remote host closed the connection]
bennofs[m] has quit [Read error: Connection reset by peer]
sphalerit has joined #nixos-aarch64
Ericson2314 has joined #nixos-aarch64
peel has joined #nixos-aarch64
timokau[m] has joined #nixos-aarch64
thefloweringash has joined #nixos-aarch64
codyopel[m] has joined #nixos-aarch64
exarkun1 has joined #nixos-aarch64
cornu has joined #nixos-aarch64
dtz has joined #nixos-aarch64
bennofs[m] has joined #nixos-aarch64
pdafriend[m] has joined #nixos-aarch64
bkchr[m] has joined #nixos-aarch64
<bennofs[m]> does the sd-image for aarch64 have graphical stuff?
<bennofs[m]> i guess we could at least disable fontconfig for the sd-image?
<samueldr> nope, sd-image is close to the minimal iso
<samueldr> so yeah, I guess we could
<bennofs[m]> or just set environment.noXlibs = true
<samueldr> (I'm looking at the savings from building while including profiles/minimal.nix)
<makefu> bennofs[m]: noXlibs is like the trigger for "build everything yourself and never become happy again". also noXlibs does not really live up to its name unfortunately - you will still have tons of libs related to gui stuff in your system config
<samueldr> hmm, yeah, looking at things while the non-minimal image builds and I think you're right, don't think anything will be pre-built
<makefu> it sounded nice on paper when i tried to enable it for my vps'es but with every update the machines start compiling all their packages
<samueldr> might be fine for the installer image
<samueldr> though it's possible someone built things with noXlibs already on the community machine
<samueldr> the netboot attribute from nixos/release.nix gives a bunch of things already built :3 module = ./modules/installer/netboot/netboot-minimal.nix;
<samueldr> netboot-minimal.nix includes minimal.nix
<samueldr> so I'd say that for as long as netboot-minimal includes minimal.nix it seems not to onerous to build the sd-image defaulting with minimal.nix, **if** it reduces its size considerably
<bennofs[m]> I am checking right now, out of curiousity, how far I get with cross compiling sd-image from current master :)
<samueldr> at one point it was possible without much patching master
<bennofs[m]> that would be awesome!
<samueldr> /nix/store/b8b5jv0cgiwdcssyw7yhd0sk60pckxg1-nixos-sd-image-19.03.git.80738ed-aarch64-linux.img 4067853896
<samueldr> /nix/store/rdvmd34j170b80lcaa2f7na33w3db86m-nixos-sd-image-19.03.git.80738ed-aarch64-linux.img 3786262616
<samueldr> second one is including profiles/minimal.nix
<samueldr> -r--r--r-- 1 root root 2.4G Jan 1 1970 result-fat/sd-image/nixos-sd-image-19.03.git.80738ed-aarch64-linux.img
<samueldr> -r--r--r-- 1 root root 2.2G Jan 1 1970 result/sd-image/nixos-sd-image-19.03.git.80738ed-aarch64-linux.img
<samueldr> so uh, not a huge decrease :/
<bennofs[m]> 2gb feels very fat. when you consider that installers for full graphical distros used to fit on a cd...
<samueldr> apparently mksquashfs makes quite the difference
<samueldr> though, yes, it feels too big
<bennofs[m]> switch to compressed btrfs rootfs :p
<samueldr> one of the hard facts of the sd-image installer is that there's not much trickery that can be reliably done for the rootfs
<samueldr> since it boots in the filesystem it will be installed on (by default)
<samueldr> and uh, going from my experience from booting the uefi installer image on my raspi 3, it makes a difference at boot
<samueldr> the uefi usb installer took a bunch more time to boot
<samueldr> (possibly due to the work needed to be done to unsquash the squashfs)
<samueldr> (oh, and note I'm not trying to shoot down ideas, only barfing up my current knowledge of the situation, which may or may not be entirely factual)
orivej has joined #nixos-aarch64
makefu has quit [Ping timeout: 268 seconds]
makefu has joined #nixos-aarch64
efraim has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
efraim has joined #nixos-aarch64
Thra11 has quit [Ping timeout: 268 seconds]
orivej has quit [Ping timeout: 250 seconds]
cstrahan__ has joined #nixos-aarch64
sphalerite_ has joined #nixos-aarch64
exarkun1 has quit [*.net *.split]
cstrahan_ has quit [*.net *.split]
andi- has quit [*.net *.split]
sphalerite has quit [*.net *.split]
samueldr has quit [*.net *.split]
samueldr has joined #nixos-aarch64
exarkun1 has joined #nixos-aarch64
andi- has joined #nixos-aarch64
orivej has joined #nixos-aarch64
<bennofs[m]> is the boot partition on the pi special? i did mkfs.vfat for /boot and looks like that broke it?
<clever> bennofs[m]: bootcode.bin and start.elf must be present for it to boot
<clever> i dont think nixos generates those
<bennofs[m]> I tarred up my /boot before
<clever> what happens at boot?
<clever> is the hdmi plugged in?
<bennofs[m]> No. I can maybe check this later
sphalerite_ is now known as sphalerite
<bennofs[m]> samueldr: huh, that sd-image you linked to (from cs.helsinki.fi) fails fsck.vfat out of the box
<samueldr> hah
<samueldr> I had some doubts since a fresh~ish install failed quickly on it
<samueldr> but it's on an allwinner board on which I don't need it
orivej has quit [Ping timeout: 272 seconds]
<nbp> samueldr: Ok, I am trying to install NixOS, got rid of the previous directories, kept the /boot (ext3) and /boot/efi (fat) from OpenSuse, but I am unable to get a nixos-install command working.
<samueldr> (note: never tried to install using the usb installer, so I can't really say)
<nbp> samueldr: I either get failures from grub, when it cannot find efibootmgr, or issues becuse grubTarget / grubTargetEfi are both empty.
<samueldr> try canBootAsRemovable
* samueldr checks the proper option name
<samueldr> when using u-boot to boot uefi grub on aarch64 I was forced to do that
<nbp> samueldr: The way the option description says, seems to be only to use it for pluggable devices.
* samueldr thinks a bit
<samueldr> it might not work 100% out of the box
<samueldr> but it should
<samueldr> what "as removable" does is to use the fallback path for the efi program
<nbp> same issue: Died at /nix/store/7cnxdsk2hm65882sxblwf2y4xrw3yhry-install-grub.pl line 471.
<samueldr> instead of registering the boot option
<samueldr> :/
<samueldr> I just remember grub working pretty much out of the box
<samueldr> boot.loader.grub.efiInstallAsRemovable = true;
<samueldr> boot.loader.efi.canTouchEfiVariables = mkForce false;
<nbp> I have both, I will try the mkForce.
<samueldr> zr.boot.enable is from my custom options
<samueldr> I think the mkForce is because of that option
<samueldr> that made it use grub successfully, BUT, caveat here, using u-boot's UEFI implementation
<samueldr> so maybe grub sees the more fully-fledged uefi from your board and tries to do things it can't on u-boot's basic UEFI
<nbp> grub device = nodev ?!
<samueldr> >> The special value nodev means that a GRUB boot menu will be generated, but GRUB itself will not actually be installed
<samueldr> maybe that's the special sauce needed?
<samueldr> I never realised I had that in there
<samueldr> or that it meant *that*
<nbp> samueldr: ok, that did it :/
<nbp> I will have to reboot to confirm, but now nixos-install asked me for the root password
<samueldr> did it copy grub to the EFI folder anyways?
<samueldr> check before rebooting
<samueldr> I'm not sure if I did manual intervention into placing grub when I played around initially with UEFI
<nbp> samueldr: does not boot, and it no longer find the USB :/
<nbp> it randomly find the USB, this sounds like a race in the hardware init.
<samueldr> maybe I should try a complete install, just to get a better idea of the UEFI situation
<samueldr> (if I want to revamp everything boot-related, it's probably for the best I check)
<nbp> ./efi/EFI/NixOS-boot-efi/grubaa64.efi ?!
<nbp> ./efi is the /boot/efi which is a fat partition.
<nbp> maybe I should rename the directory /boot/efi to /boot/EFI such that it is installed in /boot/EFI/NixOS-boot-efi/grubaa64.efi
<samueldr> copy it to /efi/EFI/boot/boota64.efi
* samueldr double-checks the name
<nbp> however, I still have no idea how to call the .efi file from the EFI shell
<samueldr> bootaa64.efi, two a
<samueldr> that's the fallback location for aarch64
<samueldr> I know it says "removable media"
<samueldr> but it should be named "booting without configuring the UEFI"
<nbp> samueldr: that seems to have made it work.
<samueldr> I probably did it that way (manually copying GRUB's EFI program to bootaa64.efi) when testing things out
<samueldr> the generated config files will still work as expected
<nbp> samueldr: the .efi file is unlikely to change?
<samueldr> and if it changes, it's likely to stay compatible
<nbp> samueldr: as the grub menu entries would be in the /boot partition, I guess?
<samueldr> it acts just like it would on x86_64 UEFI
<nbp> samueldr: It booted on NixOS \o/
<nbp> samueldr: Thanks a lot.
<samueldr> yay!
<samueldr> you're welcome
<nbp> samueldr: Sounds like I would have to add documentation on how to proceed :/
<samueldr> ideally, having such a fully-featured aarch64 uefi machine available to test would help :/
<samueldr> I wonder how qemu fares there
<samueldr> even if slow, having it to test, and tested in the nixos tests would help
* samueldr wonders about kvm on aarch64
Thra11 has joined #nixos-aarch64
<sphalerite> samueldr: ssh aarch64.nixos.community ls -l /dev/kvm
<samueldr> yes
<samueldr> and ssh my-raspberry-pi.local ls -l /dev/kvm
<samueldr> and ssh my-allwinner-r18-board.local ls -l /dev/kvm
<gchristensen> what do those say?
<samueldr> similar, aarch64's community box needs root privs
<sphalerite> samueldr: /dev/kvm doesn't exist on non-kvm-capable machines AFAIK
<samueldr> exactly
<samueldr> what was more of a question was about getting a UEFI implementation booting on aarch64
<gchristensen> nix can use it b/c its root
<gchristensen> erm
<gchristensen> yeah
<sphalerite> well don't we already have it running for some stuff on x86?
<samueldr> yes
<samueldr> I just didn't check yet :)
<sphalerite> is it too naïvely optimistic of me to assume that the same thing will work on aarch64? :D
<samueldr> yes and no
<samueldr> optimistic yes, naïvely, no
<sphalerite> :D
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 250 seconds]
<bennofs[m]> btw, here's the results of running nbench with and without force_turbo=1 on my rpi model 3b: https://gist.github.com/bennofs/2ddef6495c3a3a367f817aee9dd83514
<bennofs[m]> not a large difference, but force_turbo does appear to increase performance a little bit at least
<bennofs[m]> oh I think i made a mistake there :( the -default might be with linuxPackages_rpi
<samueldr> hm, you packaged nbench?
<samueldr> quickly tried yesterday but had an issue on build, then the thing I was waiting on finally finished and I stopped
<bennofs[m]> yeah I have a package for it
<bennofs[m]> will make a PR
Thra11 has quit [Ping timeout: 244 seconds]
srk has quit [Quit: gitter]
srk has joined #nixos-aarch64