<srk>
hmm, but that imports the installation-device transitively
<dramforever>
yup
<srk>
so, avoid importing complete <nixpkgs/nixos/modules/installer/cd-dvd/sd-image-raspberrypi4.nix> and only pick few config options for it like boot.* and fileSystems.*
<srk>
*from it
<dramforever>
I guess that's what I'm going to do
<srk>
like, I was wondering about exactly this yesterday - I have a configuration.nix used to produce an installer image but it can't be imported from installed machine because it contains installation-device
<srk>
importing profiles is weird, seems to me it would be better if these were modules itself
Cadey has quit [Ping timeout: 246 seconds]
Cadey has joined #nixos-aarch64
<dramforever>
My feeling is that this config is 'wrong', and this profile is only meant to be used to build the image on hHydra
<dramforever>
*Hydra
<srk>
well, mostly, you don't need sdImage part nor installation-device profile
<srk>
sdImage is required to build the image, installation-device is required so you don't get an image which can't log-in to
<dramforever>
Yeah, I mean the config on the wiki doesn't look right
<srk>
there's a lot of outdated or just plain wrong stuff on the wiki
<srk>
feel free to try fixing it :)
<dramforever>
Yeah, but seems like it's the best we've got on this topic
rajivr has quit [Quit: Connection closed for inactivity]
justanotheruser has quit [Ping timeout: 258 seconds]
AmandaC has quit [Quit: Toodles]
AmandaC has joined #nixos-aarch64
veleiro has quit [Ping timeout: 246 seconds]
jumper149 has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
juliosueiras has quit [Ping timeout: 246 seconds]
alp has quit [Ping timeout: 244 seconds]
alp has joined #nixos-aarch64
superherointj has joined #nixos-aarch64
Darkmatter66_ has quit [Quit: ZNC 1.7.5 - https://znc.in]
Darkmatter66 has joined #nixos-aarch64
<superherointj>
Hello. Does ARM virtualization (libvirtd / qemu / kvm) in NixOS works? Tried enabling it (virtualisation.libvirtd.enable=true) but it kernel panicked w/ RockPro64.
<samueldr>
kvm is known to work
<samueldr>
so that means qemu should, and probably libvirtd
<superherointj>
Thanks. Will try it. As soon as I learn how to recover the OS.
<superherointj>
It is not booting, as there is no grub, I cannot use it to rollback. Need to boot by other means. :)
<samueldr>
you should have u-boot that shows you a selection at boot, not sure if it inits the display on that board though
<superherointj>
I've inserted the SDCard in my computer, and mounted the partition, and I have access to it, I have edited `/etc/nixos/configuration.nix`, but then I need to rebuild it. But my computer is x86. I wonder if it will cause any trouble.
<samueldr>
might need serial
<samueldr>
you could edit /boot/extlinux.conf to change the default
<superherointj>
Oh. Found it.
<samueldr>
if this is not a one-off for you, you should invest in a serial cable if you do anything with SBCs and similar boards :)
<samueldr>
and "invest" is a strong word for a couple bucks for a known good cable
<superherointj>
Thanks.
<samueldr>
you can also go for cheaper, but if you buy from a trustable source you can assume that the cable is good
<superherointj>
I have purchased the cable but I was not able to make it work already.
<superherointj>
(purchased adapter)
<superherointj>
Your method might work. And I agree.
<samueldr>
I once bought an horrible batch cheap for ~2$ each where the usb terminals were not anchored to the pcb, so any kind of light tweak on the usb connector would make it flex in unwholesome ways
<W1lkins>
Hmm, this Helios64 looks neat
<samueldr>
W1lkins: if you sit tight for a couple mores month they're also releasing boards with ECC
<samueldr>
a bit annoying that it wasn't an option early on :)
<samueldr>
superherointj: you might want to not enable libvirtd in your next rebuild, and instead just run qemu with kvm manually to test
<superherointj>
samueldr, I was able to recover access to the board. Thank you!
<samueldr>
you know, it might not even be kvm, but rather libvirtd doing something weird? (though unlikely)
<W1lkins>
samueldr: well, I'm definitely in no rush.. and would've probably ordered one if you hadn't mentioned it, I will wait
<clever>
samueldr: ive been reading a lot of arm docs, and it seems that the A53 core has the option for L1 and L2 ECC, single bit correction, 2 bit detection
<clever>
but i dont know what chips actually enable it
<samueldr>
I don't know :)
<samueldr>
I didn't even realize SBCs were able to until I saw that, since seemingly no other SBC has that
<clever>
arm8 (pi3 and pi4) also includes a special opcode, that can zer out 64 bytes of ram at once
justanotheruser has quit [Read error: Connection reset by peer]
<clever>
if the given 64 bytes arent in the cache, it will not even allocate to the cache, and just write 64 0's directly to ram
<clever>
so you can bulk zero ram, without poluting the cache with useless data
<superherointj>
It still kernel panics with "pkgs.linuxPackages_latest".
<samueldr>
tried without libvirtd, and running qemu kvm directly?