<Dezgeg>
just nix-collect-garbage -d won't cut it if it's already full given that it first copies new kernels and only then deletes the old ones
<gchristensen>
really? :/
<gchristensen>
I had it work for me recently, though
<Dezgeg>
I typically play it risky and 'rm /boot/nixos/*' beforehand and hope it will go fine
<gchristensen>
:O
<Dezgeg>
maybe it's different for grub?
<Dezgeg>
I thought it still suffered from the same problem
<gchristensen>
this was with a systemd-boot machine
<samueldr>
well, it's safe enough as long as your device don't crash I think
<Dezgeg>
yeah, and none of our bootloader updates are crash-safe anyway
<samueldr>
though, is it /boot/nix instead of /boot/nixos?
<Dezgeg>
it is /boot/nixos/
<samueldr>
ah, no, /boot/nixos
<samueldr>
grub uses a store path iirc /me verifies
<samueldr>
no, I was wrong, sorry
<Dezgeg>
if they are on a same partition then grub doesn't need to copy
<kier>
for me a nix-collect-garbage -d by itself didn't free up any space in /boot
<gchristensen>
it won't
<gchristensen>
its the `nixos-rebuild switch` which I'm expecting to free up space
<Dezgeg>
these /boot-gets-full things really should be fixed properly, but I guess it gets too complicated to do in a bash script
<kier>
oh, right
<Dezgeg>
(unless we get MichaelRaskin to do it I suppose :P)
<gchristensen>
Dezgeg: nothing is too complicated for a bash script *walks off a cliff*
<gchristensen>
what, you don't trust my bash? :P
<Dezgeg>
luckily I learned some Perl for code golf competitions, maybe it can be finally put into actual use
<samueldr>
don't golf and nix :|
<gchristensen>
not sure if I'd rather bash or perl
<samueldr>
perl doesn't have to be a write-once read-never language :)
<kier>
script everything in rust and never experience unexpected failure scenarios ever again
<kier>
(because you'll never manage to compile it in the first place)
<gchristensen>
lol
<gchristensen>
for that I think we'd need to use Idris
<gchristensen>
or write the bootloader updater in Coq
<kier>
haha
<Dezgeg>
I guess one part of the problem is that it's quite painful to estimate how much disk space a given directory tree will actually use
<kier>
now getting:
<kier>
> building the system configuration...
<kier>
> warning: error(s) occurred while switching to the new configuration
<kier>
> cat: write error: No space left on device
<samueldr>
[09:39:35] <Dezgeg> just nix-collect-garbage -d won't cut it if it's already full given that it first copies new kernels and only then deletes the old ones
<kier>
i'm blind
<kier>
that makes sense
<samueldr>
no worries :)
<Dezgeg>
try removing /boot/nixos or moving it away to a safe place
<kier>
rm -r /boot/nixos && cross-fingers
<Dezgeg>
yes
<gchristensen>
don't forget to nixos-rebuild switch after you do that :P
<samueldr>
Dezgeg: any plans to make the use of /boot/ partition configurable for ARM images?
<samueldr>
I mean, the partition would always be present, but not necessarily used for kernels
<gerschtli>
i updated manually the firmware and now it boots in some console.. really dont know what type of console that is because like the first 5 or so characters aren't displayed
<gerschtli>
oh thanks, that wasnt the answer i wanted to hear :D
<samueldr>
the "yet" is important, it will, but aarch64 isn't the usual setup for raspberry pis
<gerschtli>
is there any known workaround for it? if not, i will try ARMv7..
<gerschtli>
am i wrong or should the ARMv7 image work on my pi? or is the pi 3 b+ with 32 bit also not supported..?
<gerschtli>
because it boots again in this strange console..
Sonarpulse has quit [Ping timeout: 260 seconds]
<gerschtli>
samueldr, Dezgeg: i'm having a hard time to believe that the kernel release 4.18 is mandatory to use the raspberry pi 3 b+ with 64 bit, because there are configurations like this gentoo build ( https://github.com/sakaki-/gentoo-on-rpi3-64bit ), which runs with kernel 4.14 and supports this board under 64 bit..
<gerschtli>
maybe you could give me a hint where my assumptions go wrong, i'm very new to this low level topic..
<elvishjerricco>
gerschtli: The kernel at github.com/raspberrypi/linux at least boots in 64bit. I'm told there will be hardware problems though.
<elvishjerricco>
Not sure where that other OS is getting its kernel from though
<Dezgeg>
the word for the rpi foundation kernel seems to be still that aarch64 is not supported and probably won't be
<elvishjerricco>
Dezgeg: To be fair, the newest comment in that thread is from January 2017. Plenty time for minds to change :) But yea, it would probably depend on the support coming in 4.18
<Dezgeg>
that's not talking about rpi 3 b+ specifically
<Dezgeg>
but aarch64 mode support in general
<gerschtli>
ah okay, thank you!
orivej has joined #nixos-aarch64
Sonarpulse has joined #nixos-aarch64
shad has quit [Quit: No Ping reply in 180 seconds.]
shad has joined #nixos-aarch64
shad has quit [Client Quit]
shad has joined #nixos-aarch64
shad has quit [Quit: No Ping reply in 180 seconds.]
shad has joined #nixos-aarch64
shad has quit [Quit: No Ping reply in 180 seconds.]
shad has joined #nixos-aarch64
Sonarpulse has quit [Ping timeout: 240 seconds]
shad has quit [Quit: No Ping reply in 180 seconds.]