pbb has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
rajivr has joined #nixos-aarch64
wavirc22 has quit [Ping timeout: 260 seconds]
wavirc22_ has joined #nixos-aarch64
<unclechu> noneucat: i did it but it seems to apply the change it requires a reboot
<unclechu> but after a reboot it stops working
<unclechu> it doesn’t matter whether i resize partition or not
<noneucat> you mean the changes don't persist?
<unclechu> it says that i have to reboot to get more space
<samueldr> the aarch64 sd image should automatically resize the last partition on first boot
<samueldr> if it doesn't there's a bug
<unclechu> samueldr: then there is a bug, right?
<samueldr> I don't know :)
<samueldr> but sounds like there's an issue somehwere at leas
<samueldr> least*
<samueldr> raspberry pi 3B or 3B+?
<unclechu> have anyone tried to install nixos on rpi3 last month?
<unclechu> it didn’t resize for me neither on rpi1 nor on rpi3
<samueldr> been a while since I did, but I'm about to check
<unclechu> samueldr: 3b+
<samueldr> I don't have a 3B+
<unclechu> samueldr: but should this sd-image stop working after a reboot?
<samueldr> it shouldn't really
tilpner has quit [Remote host closed the connection]
<samueldr> but that's a bit vague without knowing *everything* you did
<samueldr> I'll try on my 3B
<samueldr> I don't have a 3B+
<unclechu> samueldr: first: `unzstd nixos-sd-image-20.09.2190.78dc359abf8-armv6l-linux.img.zst -o /dev/stdout --no-sparse | sudo dd bs=4k of=/dev/mmcblk0`
<samueldr> yeah, I'm thinking more on the booted OS
<samueldr> it shouldn't either break itself once booted
<unclechu> then boot on rpi, then run `sudo reboot` on rpi, see “starting kernel” or something like this, nothing changes
<samueldr> though "starting kernel" is not a symptom of one particular issue
<unclechu> actually it was `nixos-sd-image-20.09.2444.388ed4e09f3-aarch64-linux.img.zst`, not `2190`
<samueldr> oh
<samueldr> 20.09?
* samueldr downloads 20.09
<unclechu> yes
<unclechu> what else?
<unclechu> do you use older one?
<samueldr> I don't really
<samueldr> the pi hasn't been booted for a good while
<samueldr> but last time I verified changes to the sd images it still worked
<samueldr> been a couple months though
<unclechu> then it might be the case that i came right after the bug had appeared
<samueldr> plausible
<samueldr> let's first try to reproduce here
<unclechu> trying now a bit newer release: `unzstd nixos-sd-image-20.09.2469.78a5623173c-aarch64-linux.img.zst -o /dev/stdout --no-sparse | sudo dd of=/dev/mmcblk0b`
<unclechu> s/mmcblk0p/mmcblk0/
<samueldr> currently trying off 388ed4e09f3
<unclechu> i accidentally chose a partition instead of the whole disk initially
<samueldr> that can lead to weird behaviour
<samueldr> were your previous burns made on a partition?
<unclechu> samueldr: yes, that’s why i’m doing this again. it happened just a minute ago when i started to try newer release
<samueldr> I meant, on your previous failing boots
<unclechu> i did it correctly for previous builds
<unclechu> previous builds was loaded to the sd-card correctly
<unclechu> were
<samueldr> alright
<unclechu> it died anyway with this error: “dd: writing to '/dev/mmcblk0b': No space left on device”
tilpner has joined #nixos-aarch64
<unclechu> okay, it seems that newer build just stucks on “starting kernel ...” from the first boot
<unclechu> how long should it take?
* samueldr can't find the serial cable
<samueldr> it shouldn't be that long from that message, but been a while since I last looked at this
<unclechu> what do you need a serial cable for?
<samueldr> to see what is going on
<samueldr> because during that "starting kernel..." there's quite likely messages on the serial port
pbb has joined #nixos-aarch64
<unclechu> when it boots it do few “retrieving file”s, last one looks like this:
<unclechu> “retrieving file: /boot/extlinux/../nixos/blablasomehashblabla-linux-5.4.86-dtbs/broadcom/bcm2837-rpi-3-b-plus.dtb”
<unclechu> then it says “14470 bytes read in 6 ms (2.3 MiB/s)”
<unclechu> then some “Flattened Device Tree blob at ...”, “Booting using the fdt blob at ...” and “Using Device Tree in place at ..., end ...”
<unclechu> then “Starting kernel ...”
<unclechu> but it handles the connected keyboard, reboots when i press ctrl-alt-del
<unclechu> i plugged in ethernet cable, it even connects to the network
<unclechu> even ssh server works
<unclechu> but i can’t login, probably there is no default password for `nixos` user?
<unclechu> technically i can try to resize the partition and the file system from my laptop
<unclechu> as well as chroot and set a password for `nixos` user
<unclechu> at least we can tell that kernel boots, only the console doesn’t want to appear
<unclechu> okay, i unplugged the rpi and put the sd-card into laptop. when it booted it didn’t resize the partition still
<samueldr> I don't know about the "won't reboot" issue
<samueldr> but for the pi3 is works to reboot
<samueldr> but resize indeed is broken on 20.09
* samueldr looks
<samueldr> I have the cause
<samueldr> I'm not really in the mood though to see that in 20.09
<{^_^}> #106751 (by urbas, 3 weeks ago, merged): nixos/sd-image: explicit reference to the gawk package
<samueldr> there's a fix for it for unstable
tilpner_ has joined #nixos-aarch64
tilpner has quit [Ping timeout: 272 seconds]
tilpner_ is now known as tilpner
<samueldr> [20:58:05] [{^_^}] [nixpkgs] @samueldr pushed commit from @urbas to release-20.09 « nixos/sd-image: explicit reference to the gawk package »: https://git.io/JLFml
<samueldr> unclechu: fixed for the resize issue
<samueldr> noneucat: (from backlog) the sd image *should* resize itself when booting, FYI :)
<samueldr> unclechu: about the weirdness on boot being "stuck" at `starting kernel...` it's likely a 3B+ specific issue
<samueldr> and this symptom will appear for a WIDE range of issues
<samueldr> basically what you see is the last thing u-boot wrote to the display
<samueldr> which could mean that the kernel didn't even start properly, or that it started, but couldn't use the display, for many reasons
<unclechu> samueldr: so, i could just wait when the fix from unstable gets to the nixos-20.09 release branch?
<samueldr> you could also, as you said, resize the partition from your computer beforehand
<samueldr> using gparted to do so is not a sin
<samueldr> using fdisk like a caveman is fraught with perils
<samueldr> you need the partition to have the "bootable" flag, in addition to the general messyness of using fdisk
<unclechu> samueldr: okay, thanks, i’ll try
quinn has quit [Quit: ZNC 1.8.1 - https://znc.in]
quinn has joined #nixos-aarch64
<noneucat> huh, i've always had to resize the last partition manually...
<noneucat> something Wacky is going on with suspend and the modem on the pinephone that i need to look into
h0m1 has quit [Ping timeout: 260 seconds]
h0m1 has joined #nixos-aarch64
<samueldr> interersting, both sentences
<samueldr> though it really has been a good while since I last booted a fresh sd image
<samueldr> (and verified the resize worked)
quinn has quit [Quit: ZNC 1.8.1 - https://znc.in]
quinn has joined #nixos-aarch64
cptchaos83 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
<unclechu> it’s a known bug in the wiki about stucking on “starting kernel” with HDMI
<unclechu> samueldr: resize worked on unstable or stable 20.09?
<samueldr> I haven't *verified* it works on unstable, but the change is already present
<samueldr> and the change has been pushed to 20.09, so no need to document it as it's soon going to be updated to towk
<samueldr> to work*
<samueldr> the "starting kernel..." issues documented on the nixos wiki are... as I tried to explain... of various causes
<samueldr> that alone as a symptom is not enough to know what the issue is
<samueldr> it's like you told me that on your laptop "there's nothing on the screen" when you start it
<samueldr> could be a wide range of issues
<samueldr> (I'm pretty sure I wrote the sections on the wiki page about it)
<unclechu> it just recommends to replug the HDMI after boot
<samueldr> it helped for one (1) user
<unclechu> samueldr: okay, i build my first config and successfully rebooted and sshed into the rpi
<unclechu> thanks for your help
<unclechu> it seems now i can go forward
<samueldr> you're welcome
<samueldr> hopefully you can figure out something for the hdmi output not really working well
<samueldr> it's a bit odd and problematic how no one who could check seems to have a 3B+ on hand to do so
andi- has quit [Remote host closed the connection]
andi- has joined #nixos-aarch64
<unclechu> i didn’t do `passwd` for my user, now i can’t do `sudo`
<unclechu> is there any way to do this from my laptop?
<samueldr> from u-boot you should be able to select a previous generation (before starting kernel...)
<unclechu> chroot wouldn’t work i suppose since binaries are not compatible
<samueldr> you could also undeclaratively edit the /boot/extlinux.conf file in the rootfs to change the default generation it boots from
<samueldr> that will be reset on the next rebuild
<unclechu> samueldr: hm... but how i would change a password for the user that does not exist in that generation?
<samueldr> hmmm... you might sudo passwd to change the root user's password
<samueldr> oh, but then ssh as root is not a thing
<samueldr> you could also drop a .ssh/authorized_keys in the new user's home dir?
<unclechu> yeah, unless i allow ssh as root in the config
<samueldr> (mind the correct file and directory modes)
<unclechu> i did that, i mean i added my authorized keys
<unclechu> i can ssh as my user
<samueldr> ah
<samueldr> then you can passwd root
<unclechu> but when i ssh-ed i can’t do `sudo smth`
<samueldr> (on an older generation
<samueldr> and then ssh, su, then passwd your new user
<unclechu> yeah, i’ll probably just temporarily allow ssh as root
zarel has quit [Ping timeout: 256 seconds]
veleiro has joined #nixos-aarch64
Asmadeus has joined #nixos-aarch64
<noneucat> mmmmm
<noneucat> looks like the modem/suspend situation for pp is still a little hackish now
<noneucat> some stuff has been upstreamed, but there are still one or two hacky patches i would need to apply to get some stuff working
<samueldr> go on
<noneucat> the main issue i'm struggling with is with the pp missing either calls or sms that were received during a suspend
<samueldr> yeah, but that doesn't tell me anything about the two hacky patches
<samueldr> are there reasons for us not to include them?
<noneucat> there are some behaviors that were patched out in pmos to facilitate that, like preventing MM from hanging up on probes and patching a parser to fix some vendor weirdness
<noneucat> they're not the 'right' solutions i guess
zarel has joined #nixos-aarch64
<noneucat> i guess they could be put in the pinephone overlay
<samueldr> or maybe outright mobile nixos overlay
<samueldr> but yeah, pinephone overlay seems okay enough
<noneucat> currently building mm with the changes to test them out
<samueldr> in a way, mobile nixos is not against pragmatic changes like those
<samueldr> after all, look at the vendor kernels
<noneucat> hahaha
<Ke> my honeycomb is now in finland
<noneucat> i just looked it up
<noneucat> looks fancy!
<noneucat> damn, my local build is failing :/ guess i need to grab a cloud box to build this on
ib07 has quit [Ping timeout: 256 seconds]
cole-h has quit [Quit: Goodbye]
orivej has joined #nixos-aarch64
Darkmatter66 has joined #nixos-aarch64
wavirc22_ has quit [Ping timeout: 256 seconds]
Darkmatter66 has quit [Ping timeout: 264 seconds]
orivej has quit [Ping timeout: 264 seconds]
<Ke> ups ninja attempted delivery and I was not at home
<Ke> which is news to me
<Ke> at least there are ups access points nearby
veleiro has quit [Ping timeout: 256 seconds]
Darkmatter66 has joined #nixos-aarch64
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
<sphalerite> Ke: oh yeah probably same for me, except I know I'm not there and I knew I wouldn't be there a week ago and I couldn't do a thing about it.
<sphalerite> \o/
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
<DigitalKiwi> i thought everyone was at home
Darkmatter66 has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
ehmry has quit [Read error: Connection reset by peer]
justanotheruser has quit [Ping timeout: 272 seconds]
ehmry has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
alpernebbi has joined #nixos-aarch64
elvishjerricco has quit [Ping timeout: 260 seconds]
globin_ has quit [Quit: o/]
globin has joined #nixos-aarch64
globin has joined #nixos-aarch64
globin has quit [Changing host]
elvishjerricco has joined #nixos-aarch64
quinn has quit [Ping timeout: 264 seconds]
quinn has joined #nixos-aarch64
<yorick> is there any raspberryi4 armv7l image?
<patagonicus> yorick: The RPi3 can boot the multiplatform armv7l image, but I don't think the RPi4 can because it needs non-mainline kernel (although I'm not sure if it boots with mainline). You could either try cross-compiling or natively compiling if you have a working armv7l system and generate the multiplatform image, but with the RPi4 kernel.
<yorick> patagonicus: thanks, I'll try that
<patagonicus> yorick: I'd start with https://github.com/samueldr/cross-system for cross-compiling, otherwise it's probably not going to be fun. You'll want to use ./build.sh --argstr system armv7-linux and add whatever RPi4 specific stuff you need to configuration.nix - or copy armv7-linux to raspberrypi4-armv7l.nix, add stuff there and then use ./build.sh …
<patagonicus> raspberrypi4-armv7l
<yorick> patagonicus: I do have a bunch of the armv7l-multiplatform builds already, so they might just need the different kernel
<patagonicus> Without looking into it, my guess is also that it's just the kernel. And potentially the bootloader, although I'd guess that that shouldn't change between 32-bit and 64-bit ARM.
jb55 has quit [Remote host closed the connection]
<flokli> there is pkgs.ubootRaspberryPi4_32bit and pkgs.ubootRaspberryPi4_64bit
quinn has quit [Ping timeout: 272 seconds]
<yorick> hmm, already having fun cross-compiling adventures
orivej has quit [Ping timeout: 265 seconds]
<flokli> Hmmh. I wonder if we could have a bit more of that stuff built by hydra
<yorick> seems like staging-next doesn't cross compile to armv7, anyways
<yorick> perl failure
<yorick> in perlPackages.ModuleBuild
<{^_^}> #66741 (by lopsided98, 1 year ago, open): perlPackages.ModuleBuild (a dependency of git) fails to cross-compile
<yorick> it's not far enough to tell me what depends on that, though
orivej has joined #nixos-aarch64
rajivr has quit [Quit: Connection closed for inactivity]
<flokli> yorick: what did you try to build?
<noonien> hello folks
<noonien> has anyone managed to get mjpg-streamer working on a raspberry pi?
quinn has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
veleiro has joined #nixos-aarch64
<yorick> flokli: staging-next, samueldr/cross-system, armv7l-linux
cole-h has joined #nixos-aarch64
Darkmatter66 has joined #nixos-aarch64
orivej has joined #nixos-aarch64
<noonien> hmm, i can't seem to get the camera working on the raspberry pi 3 B+
<yorick> interestingly, it looks like linux-headers doesn't build at all on armv7l unstable
<yorick> segfaults in fixdep
<noneucat> noonien: what issues are you facing?
<{^_^}> #107386 (by Gaelan, 1 week ago, open): Can't build linux-headers on armv6l
<noonien> noneucat: well, /dev/video* doesn't exist
<noonien> i'm putting raspbian on a sdcard now, to check if perhaps it's a problem with the ribbon cable
<noonien> if raspbian should detect the camera, then so should nixos
<noneucat> hmmm
<noneucat> it is possible the kernel wasn't built with the camera stuff enabled?
<samueldr> * if they're using the same kernel and same configuration
<noneucat> ^
<samueldr> many hardware-based things on the raspberry pi are built with the vendor ecosystem in mind
<yorick> Gaelan: how's your rpi4 build machine doing?
<samueldr> which means letting the raspberry pi firmware deal with launching the kernel
<samueldr> and using the vendor kernel (from the raspberry pi foundation)
<samueldr> if starting from the usual generic sd image, it boots using u-boot, and uses the mainline linux kernel
<noneucat> i guess i should be looking at the aws graviton instances to spin up a temp. arm builder
<noonien> i'm using the instructions from: https://nixos.wiki/wiki/NixOS_on_ARM/Raspberry_Pi_3#Camera
<samueldr> oh, noneucat, I forgot to link this to you https://github.com/nix-community/aarch64-build-box
<noonien> should i boot with the rpi foundation kernel, and the other bootloader, not uboot?
<noneucat> ah, i do need to submit a pr for that
<samueldr> I guess that might work, assuming they didn't forget about the raspberry pi foundation kernel in their snippet
<samueldr> noneucat: read and understand the implications of the README, and do
<yorick> Ericson2314: yeah, I'm also seeing that binutils armv7l linux-headers fixdep thing
<samueldr> noneucat: while you shouldn't trust a binary built on it, you can at least iterate quickly
<noneucat> oh yeah, just want to make sure stuff builds and works before making prs
alpernebbi has quit [Quit: alpernebbi]
red[evilred] has joined #nixos-aarch64
<red[evilred]> psst sphalerite (IRC) - it's here!
<sphalerite> red[evilred]: jealous.
<sphalerite> red[evilred]: lol, it's 22:31 here and UPS says "Estimated Time: by End of Day"
<noneucat> is this the honeycomb? :)
<sphalerite> yes
veleiro has quit [Ping timeout: 240 seconds]
<Ericson2314> yorick: linkers are the worse!
<Ericson2314> I bet the segfaulting bootstrap tools are also due to linkers
jumper149 has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 246 seconds]
Acou_Bass has quit [Ping timeout: 240 seconds]
<noonien> hmm, can i use the raspberry foundation kernel in nixos? so i can use the camera?
<noonien> is pkgs.linuxPackages_rpi3 that kernel (for rpi3)?
<clever> noonien: i believe thats the rpi fork, built with nix
<noonien> i see. so that's not the same kernel i get on a raspbian install
Acou_Bass has joined #nixos-aarch64
<clever> same source and config, different build
<noonien> doesn't their kernel also include binary blobs?
<clever> the blobs arent in the kernel
<noonien> or are they separate .ko's?
<clever> the blob is what loads the kernel
<clever> it needs the blobs to even boot
<clever> so if you where missing the blob, it wouldnt even turn on
<noonien> i see
<noonien> i'll give linuxPackages_rpi3 a try, maybe the camera will work
<clever> for the rpi3, there are 4 stages to booting
<clever> stage 0, the rom in the soc initializes the L2 cache and loads stage 1
<clever> stage 1, the bootcode.bin blob brings dram online, and loads stage 2
<clever> stage 2, the start.elf brings everything else up, and loads stage 3
<clever> stage 3, the kernel.img begins to run on the arm core (either linux or uboot)
<clever> start_x.elf contains the camera drivers, if you add "start_x=1" to "config.txt", then stage1 will load a diff file for stage2
<clever> root@pi400:~# vcgencmd get_camera
<clever> supported=0 detected=0
<clever> noonien: if you use the wrong blob, it will report that it is detected, but not supported
<noonien> ah, now that start_x=1 makes sense
<clever> ive also been working on https://github.com/librerpi/rpi-open-firmware
<clever> it gets rid of every blob
<clever> rpi-open-firmware replaces stage1's bootcode.bin, and skips stage2 entirely
<clever> but it doesnt have camera or hdmi support yet
<noonien> ah, nice!
<noonien> what package is vcgencmd from?
<clever> raspberrypi-tools
<clever> arm32 only
<noonien> oh
<clever> but you can run arm32 userland on an arm64 kernel
<clever> oh, gencmd may work on arm64 though
<noonien> $ sudo vcgencmd get_camera
<noonien> supported=0 detected=0
<noonien> i'll reboot into linuxPackages_rpi3
<clever> then the camera is not plugged in
<clever> changing the kernel wont affect the detected=