<justanotheruser> why would it work poorly?
<samueldr> I mean, any fairphone, not even an option
<samueldr> lack of bands for north america
<justanotheruser> you can get 3G, but the variable available of 4G is a negative, definitely
<samueldr> yeah, and 3G is not all bands
<samueldr> e.g. I'd be on 2 out of 3 of my telco, so spottier reception
<samueldr> I mean, it's not great for selling here... but it's I think a terrible thing for visitors!
<samueldr> imagine a european visiting and not being able to use the bands of telcos with chich their own operators have agreements!
<samueldr> that was the reasoning I gave in favour to having a global (more expensive) modem for the pinephone
<samueldr> we almost had a N/A version and a EUR version
<justanotheruser> yes, I almost got a pinephone, but its camera quality and speed were not sufficient to try it as a primary
<samueldr> yeah, it's more of an early adopter's toy/actually useful device
<samueldr> than a fully fleged end-user product
<colemickens> I actually laughed out loud at the camera. It's fine, I'm not complaining, but it was kind of funny. Reminded me of my Brio when it's in IR mode.
<ashkitten> oh right that webcam has an ir camera
<ashkitten> i was thinking of trying to use something like that for head tracking in 3d stuff
<samueldr> colemickens: pinephone? you did end up booting?
<samueldr> ashkitten: mostly unrelated to the discussion, but I figure you heard about https://github.com/relativty/Relativty
<ashkitten> ooh
orivej has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
h0m1 has quit [Ping timeout: 260 seconds]
h0m1 has joined #nixos-aarch64
Darkmatter66 has joined #nixos-aarch64
Darkmatter66_ has quit [Ping timeout: 240 seconds]
knerten1 has joined #nixos-aarch64
lordcirth has joined #nixos-aarch64
knerten2 has quit [Ping timeout: 240 seconds]
<lordcirth> Trying to "stack build" a haskell project, using lts-12.26. Pinebook Pro, nixos 20.03. ld.gold fails with ENOSPC, but there's 25GB left on /, and no other fs's.
<{^_^}> easybuilders/easybuild-easyconfigs#6097 (by edmondac, 2 years ago, closed): GCCcore's use of gold by default fails on some platforms
<lordcirth> But my / is ext4 and definitely supports fallocate
<samueldr> tmpfs for /tmp ?
<lordcirth> samueldr, /tmp is on /, I thought of that too... it's wierd
<samueldr> couldn't say, unlikely to be PBP specific though
<lordcirth> Now, /run and /run/wrappers are separate tmpfs, though
<lordcirth> Yeah, I thought it *might* be ARM-specific
<samueldr> probably
<samueldr> IIRC nix uses /tmp for its builds
t184256 has left #nixos-aarch64 ["Error from remote client"]
<clever> samueldr: i believe nix uses $TMPDIR, which defaults to /tmp on nixos, but things like ubuntu and single-user nix shove it in /run with only 100mb
<samueldr> yeah
<samueldr> makes sense
<samueldr> though TMPDIR of... the daemon I suppose?
<clever> yep
<lordcirth> Should be /tmp then... but $TMPDIR isn't set in bash
t184256 has joined #nixos-aarch64
<samueldr> and anyway it would be the daemon's
<clever> [root@amd-nixos:~]# xargs -0 -n1 echo < "/proc/$(pidof nix-daemon | head)/environ"
<clever> none of the $TMP's are even set, so it defaults to /tmp
rajivr has joined #nixos-aarch64
<lordcirth> It's very strange
<clever> lordcirth: if you build with --keep-failed, youll see where it put things, when it does run out
<clever> lordcirth: also, what does `df -i /` report?
<lordcirth> Good question. -i shows 25% used on /
<lordcirth> This is a stack build, not nix-build, so not sure what the equivalent of --keep-failed is
<samueldr> ooh, I assumed it was in a nix build
<clever> is $HOME seperate from / ?
<samueldr> (through stack)
<samueldr> I don't know most of haskelly things
<samueldr> could that one be running under /run ?
<lordcirth> Well, I think the issue is more ld.gold specific, rather than haskell
<lordcirth> Nope, only real fs is /
<samueldr> well, $XDG_RUNTIME_DIR
<clever> lordcirth: run `watch -d df -h` and watch it while things build
<lordcirth> huh, /run/user/1001 is a tmpfs and is flickering
<clever> `watch -d 'df -h ; ls -ltrh /run/user/1001'` ?
<samueldr> $XDG_RUNTIME_DIR :)
<samueldr> it's like your own personal hell^W tmpfs
<samueldr> try export XDG_RUNTIME_DIR=$HOME/deletemelater # then your command
<lordcirth> I'll try that. If it works, is there a way to increase the tmpfs size permanently?
<samueldr> good question
<clever> mount /whatever -o remount,size=123g
<clever> you can freely resize a tmpfs at any time
<lordcirth> yeah, but how can I have it get created with the new size every boot?
<lordcirth> Just a filesystem entry?
<clever> systemd-logind options i think
<lordcirth> Ah, ok
<clever> it gets dynamically created upon login
<clever> and un-mounted on logout
<samueldr> though this dips into your RAM
<samueldr> so YMMV depending on the size of the build
<clever> it only uses the ram df reports as used
<clever> the size is only the max when it says no more
<clever> you can make it 20tb if you want, and it wont care
<lordcirth> /home/lordcirth/stacktmp/env-vars: No such file or directory
<lordcirth> oh wait, wrong dir
<lordcirth> It's building on one core, might take a while to work for sure ...
<lordcirth> I think it's past the original fail point, though. Thanks guys!
lordcirth has quit [Read error: Connection reset by peer]
justanotheruser has quit [Ping timeout: 244 seconds]
Darkmatter66_ has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 240 seconds]
orivej has quit [Ping timeout: 258 seconds]
criptonauta_ has quit [Remote host closed the connection]
criptonauta_ has joined #nixos-aarch64
criptonauta_ has quit [Remote host closed the connection]
criptonauta_ has joined #nixos-aarch64
criptonauta_ has quit [Remote host closed the connection]
criptonauta_ has joined #nixos-aarch64
criptonauta_ has quit [Remote host closed the connection]
criptonauta_ has joined #nixos-aarch64
criptonauta_ has quit [Remote host closed the connection]
cole-h has joined #nixos-aarch64
juliosue1ras has quit [Ping timeout: 256 seconds]
juliosueiras has joined #nixos-aarch64
<colemickens> btw on pinephone I burned uboot to an SD Card and then did a typical GPT install to the eMMC
<colemickens> For now, I just leave the SD Card in. I'll replace it with an SPI flash whenever things stabilize. I decided it wasn't something I cared enough to mess with now.
alp has joined #nixos-aarch64
<sphalerite> colemickens: hm, can't you put u-boot on the eMMC?
<colemickens> sphalerite: not with GPT as I understand it, based on where the offset it expects uboot at
<colemickens> sphalerite: granted, I don't think there was any reason I needed GPT, but I just wanted to stick with what I was used ot.
cole-h has quit [Quit: Goodbye]
juliosueiras has quit [Ping timeout: 240 seconds]
<sphalerite> aaah I see
<sphalerite> yeah makes sense
orivej has joined #nixos-aarch64
ArtemVorotnikov[ has quit [Ping timeout: 244 seconds]
danielrf[m] has quit [Ping timeout: 244 seconds]
theotherjimmy[m] has quit [Ping timeout: 244 seconds]
kyren has quit [Ping timeout: 240 seconds]
taktoa[c] has quit [Ping timeout: 240 seconds]
claudiii has quit [Ping timeout: 244 seconds]
jackdk has quit [Ping timeout: 244 seconds]
pinage404[m] has quit [Ping timeout: 240 seconds]
Jake[m] has quit [Ping timeout: 244 seconds]
alp has quit [Ping timeout: 256 seconds]
hpfr has quit [Ping timeout: 240 seconds]
taktoa[c] has joined #nixos-aarch64
Ox4A6F has quit [Ping timeout: 244 seconds]
claudiii has joined #nixos-aarch64
kyren has joined #nixos-aarch64
jackdk has joined #nixos-aarch64
Jake[m] has joined #nixos-aarch64
Ke has quit [Ping timeout: 240 seconds]
alp has joined #nixos-aarch64
blitzclone[m] has quit [Ping timeout: 240 seconds]
theotherjimmy[m] has joined #nixos-aarch64
puzzlewolf has quit [Ping timeout: 244 seconds]
hpfr has joined #nixos-aarch64
thefloweringash has quit [Ping timeout: 244 seconds]
Dandellion has quit [Ping timeout: 240 seconds]
Ke has joined #nixos-aarch64
fgaz has quit [Ping timeout: 244 seconds]
noneucat has quit [Ping timeout: 240 seconds]
puzzlewolf has joined #nixos-aarch64
ArtemVorotnikov[ has joined #nixos-aarch64
thefloweringash has joined #nixos-aarch64
noneucat has joined #nixos-aarch64
Ox4A6F has joined #nixos-aarch64
blitzclone[m] has joined #nixos-aarch64
fgaz has joined #nixos-aarch64
rajivr has quit [Quit: Connection closed for inactivity]
danielrf[m] has joined #nixos-aarch64
Dandellion has joined #nixos-aarch64
alp has quit [Remote host closed the connection]
alp has joined #nixos-aarch64
sphalerite has quit [Quit: WeeChat 2.6]
alp_ has joined #nixos-aarch64
alp__ has joined #nixos-aarch64
alp has quit [Ping timeout: 240 seconds]
alp_ has quit [Ping timeout: 244 seconds]
alp has joined #nixos-aarch64
sphalerite has joined #nixos-aarch64
alp__ has quit [Ping timeout: 244 seconds]
alp has quit [Remote host closed the connection]
Guest39002 is now known as prusnak
prusnak is now known as Guest89309
quinn has quit [Quit: ZNC 1.8.1 - https://znc.in]
alp has joined #nixos-aarch64
alp has quit [Ping timeout: 244 seconds]
h0m1 has quit [Ping timeout: 260 seconds]
adisbladis has quit [Quit: ZNC 1.7.5 - https://znc.in]
adisbladis has joined #nixos-aarch64
adisbladis has quit [Remote host closed the connection]
adisbladis has joined #nixos-aarch64
h0m1 has joined #nixos-aarch64
Guest89309 is now known as prusnak_
Darkmatter66 has joined #nixos-aarch64
Darkmatter66_ has quit [Ping timeout: 260 seconds]
orivej has quit [Ping timeout: 240 seconds]
alp has joined #nixos-aarch64
rajivr has joined #nixos-aarch64
jumper149 has joined #nixos-aarch64
alp has quit [Ping timeout: 240 seconds]
t184256 has left #nixos-aarch64 ["Disconnected: Replaced by new connection"]
t184256 has joined #nixos-aarch64
elvishjerricco has quit [Ping timeout: 272 seconds]
elvishjerricco has joined #nixos-aarch64
orivej has joined #nixos-aarch64
Asmadeus has quit [Ping timeout: 260 seconds]
justanotheruser has joined #nixos-aarch64
juliosueiras has joined #nixos-aarch64
<clever> samueldr: have you heard about how NOOBS works on the pi's?
alp has joined #nixos-aarch64
justanotheruser has quit [Ping timeout: 244 seconds]
<samueldr> clever: no
<samueldr> clever: anything specific you want to share?
<samueldr> colemickens: no SPI flash on the pinephone
<samueldr> colemickens: you have the 3GB version right? the u-boot worked out of the box?
<clever> samueldr: basically, when noobs boots, it loads bootcode.bin, start.elf, linux+initrd from the 1st fat32 partition
<samueldr> sphalerite/colemickens: u-boot can be made to work with GPT with different methods on allwinner and rockchip systems
<clever> samueldr: when you select an OS from the noobs menu (or it picks the defalt one), it will put a special number into one of the registers that persists across resets
<clever> samueldr: and then hard-reset the whole pi
<samueldr> for rockchip just make sure first_lba is 64; then you can make dumb partitions to point at
<clever> samueldr: the bootcode.bin on the 1st fat32 will notice that number, and then load start.elf from a different partition, and continue as normal
<clever> so you can have multiple start.elf files, each with their own /boot and config.txt
<samueldr> that's the stock bootcode.bin?
<clever> yeah
<clever> so basically, you make 10+ fat32 partitions, all but 1 are /boot for different distros (with the normal start.elf+kernel+config.txt)
<clever> and then the gui on the 1st one uses a magic register, to tell bootcode.bin to use a different one on next boot
<samueldr> I don't really like that :)
<clever> which part?
<samueldr> feels like workaround-city
<samueldr> magic register that loads a different still-awful bootloader
<clever> i think the main thing they wanted to avoid, was modifying the SD card during boot
<clever> but if i'm using a custom bootcode.bin, i can have that register do anything i want
<clever> the magic in the register only extends as far as it persisting across resets
quinn has joined #nixos-aarch64
<Ke> for any device that runs linux on arch that supports kexec: port petitboot
<Ke> not doing that myself, because I am lazy
betrion[m] has joined #nixos-aarch64
<Ke> I am actually unsure what it the hard part of porting, since all the hard parts I can think of are already there, you need to configure the kernel, I guess also all drivers need to have sufficient reset capabilities
<clever> Ke: the main difference between what noobs does and kexec, is that it can also swap out the VPU firmware, along with any side-effects config.txt causes to the firmware
<samueldr> kexec has been showing issues on some devices due to implementation not thinking it'd be kexecing
<samueldr> and petitboot doesn't solve the real main issue: sharing the main storage with the device's "bios-type" firmware
<Ke> other things than devices being in bad state?
<samueldr> I don't know
<samueldr> but that's mostly it I suppose
<samueldr> but still, as you said, you're lazy... I'm lazy... other devs are lazy
<samueldr> u-boot is crazy good too
<clever> one thing ive got working, i now have a custom bootcode.bin, that can load a custom start.elf, on a pi3
<samueldr> what I'd actually want to see is mode EDK2 ports and/or coreboot ports
<clever> and start.elf doesnt have a 128kb limit to its size
<clever> so i can more easily shove u-boot.bin into the mix, and gave fun with that
<Ke> does edk2 nowadays build with supported gcc
<samueldr> no clue
<clever> samueldr: oh!, my bootcode.bin also supports ext2, and might be able to load the official start.elf ...
<Ke> that was definitely my main grievance for macchiatobin
<clever> samueldr: what do you think of a bootcode.bin, that will respect nixos generations, and load start.elf from the right generation, with rollback support?
alp has quit [Ping timeout: 244 seconds]
<samueldr> clever: what would be missing is a UI to select a generation I figure
<samueldr> clever: but that would be more palatable than the standard boot firmware
<clever> yeah, it would have to be serial or gpio based currently
<clever> or more automated, it didnt boot right, try previos
<clever> currently, there are ~2 main barriers for my open bootcode loading a closed start.elf
<clever> 1: fixup.dat, without figuring that out, it will mess with how much ram the arm can use
<samueldr> though I guess there's still the issue that this is specific to that board, rather than standard
<samueldr> so any effort is mostly wasted
<clever> 2: start.elf will still expect to find config.txt and kernel.img on a fat32, so id have to copy things to the right place on each boot
<samueldr> u-boot and/or standard UEFI (tianocore) are way better in that sense
<samueldr> and petitboot a close third
bennofs_ has joined #nixos-aarch64
<clever> yeah, uboot and uefi can support ext2/3/4, and wont have those issues
alp has joined #nixos-aarch64
<clever> it could be a seperate profile from nixos
<clever> so you get start.elf generations, in parallel to nixos generations
<sphalerite> Ke: hm, it looks to me like the edk2 in nixpkgs is built with the regular stdenv? or am I understanding what you're asking about wrong?
<clever> then you can undo a firmware bricking, without undoing a nixos update
<Ke> sphalerite: probably you understood me correct, wonder if there are patches
<clever> samueldr: oh, i could also flip things the other way around!, closed bootcode.bin loads open start.elf by default (1st part), but then use the noobs mechanism to load the closed start.elf+linux
cole-h has joined #nixos-aarch64
<Ke> maybe I should look into it, right now my mcbin runs ancient build
<Ke> and debian as OS so nothing it built from nixpkgs
<samueldr> Ke: if it doesn't use mainline EDK2, it could be part of the issue; old code dump that didn't do it well
bennofs__ has quit [Ping timeout: 246 seconds]
<Ke> sure, but my impression is that it's mainline, but I maybe the url just looked so professional
<Ke> -I
<Ke> https://github.com/tianocore/edk2 is my origin at least now
<Ke> right now I am concerned I have hw issues on the board so putting too much effort on sw or fw is not motivating me
alp has quit [Ping timeout: 240 seconds]
wrench[m] has joined #nixos-aarch64
rajivr has quit [Quit: Connection closed for inactivity]
pinage404[m] has joined #nixos-aarch64
jumper149 has quit [Quit: WeeChat 2.9]
<pinage404[m]> betrion:
<pinage404[m]> * betrion:it's working : it's booting and i have SSH, but i don't have everything that i would like
<wrench[m]> Did anyone successfully build an image for arm on x86_64
<wrench[m]> * Did anyone successfully build an image for arm on x86_64?
<pinage404[m]> betrion: you can search more configuration here https://search.tx0.co/?q=raspberry&i=nope&files=&repos=
<samueldr> though note that this doesn't produce a "native" image, so all store paths will need to be redownloaded or rebuilt (depending) on first nixos-rebuild since the inputs are different
alp has joined #nixos-aarch64
<pinage404[m]> i have an USB sound card that is recognised by `lsusb` and `lshw`
<pinage404[m]> but `pacmd list-cards` don't find any cards and their is no sound
<pinage404[m]> when i plugin the USB sound card on my NixOS laptop, it works instantly
<pinage404[m]> i tried many thing but i don't know what to do to have working sound on my Pi, does anyone can help me please ?
<pinage404[m]> * i tried many things but i don't know what to do to have working sound on my Pi, does anyone can help me please ?
<sphalerite> pinage404[m]: it's most likely the relevant kernel driver isn't included in the driver you're using
<sphalerite> err thinko
<pinage404[m]> sphalerite: which kernel driver should i includes ? and how ?
<sphalerite> pinage404[m]: sorry, got that completely wrong. What does lshw say about the driver being used for the USB sound card on the laptop?
<sphalerite> pinage404[m]: and likewise, does it show one on the pi?
<pinage404[m]> sphalerite: sorry, it's in french, i don't know how to change this without changing my whole system
<sphalerite> that's fine, I can deal with French :p
<sphalerite> usbhid seems like an odd driver for that to use though…
<sphalerite> is it possible that what you've got there is an input device provided by the sound card?
<sphalerite> maybe it has volume buttons or something?
<sphalerite> pinage404[m]: do you have anything using snd-usb-audio on the laptop?
<pinage404[m]> the USB card has no button
<pinage404[m]> how can i check that ?
<sphalerite> see if snd-usb-audio is anywhere in lshw's output
<sphalerite> my USB audio interface looks like this https://gist.github.com/lheckemann/6e2b7ab3f21ee498d4f25fa72789b7c7
<pinage404[m]> the only audio that i grep is what that i pasted
<sphalerite> huh, weird
<sphalerite> I don't know then :/
<pinage404[m]> althrougth thanks for your time =)
alp has quit [Ping timeout: 244 seconds]
<betaboon> hello. I'm trying to use the raspberrypi4 image mentioned in the wiki, but after a `nixos-rebuild switch` and a reboot it will boot into the "installer" again. any hints ?
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
<samueldr> is the /boot partition mounted when you rebuild? there seems to be an issue and it sometimes doesn't mount
cole-h has quit [Quit: Goodbye]
<betaboon> samueldr: I'm assuming i am running into https://github.com/NixOS/nixpkgs/pull/78090 !?
<{^_^}> #78090 (by cmacrae, 33 weeks ago, open): sd-image: Fix Raspberry Pi 4 image builder
<betaboon> samueldr: yep /boot is mounted
<samueldr> was it when you last rebuilt? you can't know for sure :)
<samueldr> that's the issue, it sometimes *fails* to mount
<samueldr> while this PR wasn't merged, another that fixed the /boot issue was made
<samueldr> but it seems there's still another problem that is linked; the FS is not marked as required for boot, so if it fails to mount it still continue to boot
<samueldr> and I've personally seen it happen
<samueldr> guess I found what I'll be doing; looking at u-boot+rpi4 again
orivej has quit [Ping timeout: 240 seconds]
<betaboon> samueldr: are my assumptions about the installation story correct: get the sd-card-image (from hydra), dd to sd-card, boot pi4, create /etc/nixos/configuration.nix which imports `.../installer/cd-dvd/sd-image-raspberrypi4.nix` and adds changes, run `nixos-rebuild switch`, reboot ?
<samueldr> if you add that import, that brings in the installer image settings!
<betaboon> samueldr: that's what i thought. (the wiki is misleading on that then)
* samueldr looks
<samueldr> eek
<samueldr> first off, I want to split the raspberry pi page!
<samueldr> way too much conflicting information
<betaboon> samueldr: would this be enough: https://gist.github.com/betaboon/e3f64e7ab521899835760a74a970b696 ?
<samueldr> I think so
* betaboon rebuilds sd-card from scratch ...
<samueldr> I think nixos-generate-config should generate a proper basic config
<samueldr> I'll edit the wiki assuming so
<betaboon> samueldr: so boot into sd-card (from hydra-image) and run nixos-generate-config ? gonna try that and report back in a moment
<samueldr> yes
<betaboon> back at an old employer of mine we had the saying "the wiki is where information goes to die" sadly holds true way to often
<samueldr> I guess it depends what the wiki is intended for
<samueldr> some wikis are for random not-docs docs
<samueldr> but for NixOS on ARM it's the current root of truth for docs
<samueldr> it's been maintained much better than some other sections
<betaboon> samueldr: do you remember from the top of your head which console is correct for pi4, ttyAMA0 or ttyS0 ?
<samueldr> but I kinda don't like the raspberry pi platform, so I haven't really invested time into it :)
<samueldr> no I don't, but I think AMA0
alp has joined #nixos-aarch64
<betaboon> i had to get network-boot working for raspberries recently. weird story as well
<betaboon> ttyAMA0 was correct ;)
<betaboon> on first boot /boot is not mounted here, I
<betaboon> I'm assuming i should mount it before running nixos-generate-config ?
<samueldr> yes
<samueldr> I wonder if it's quite reproducible
<samueldr> but I'm also currently "working" on looking at u-boot on rpi4 again
<samueldr> if it works then it won't matter anymore
<betaboon> samueldr: the fstab on the image says: `/dev/disk/by-label/NIXOS_BOOT /boot vfat nofail,noauto`
<samueldr> hm
<samueldr> noauto sure would do that
<samueldr> I thought it was just nofail
<betaboon> i think i had u-boot working on rpi4 recently. not sure tho. juggled to many different pi models
<samueldr> the noauto comes from co-opting the firmware mount point
<samueldr> yeah, I had u-boot working too, but it wouldn't boot the system :)
<samueldr> and I didn't care to follow-up why
<samueldr> I was already (at that time) getting frustrated by it for other reasons
<samueldr> [15:34:47] <samueldr> the noauto comes from co-opting the firmware mount point
<samueldr> yes :)
<samueldr> the actual solution would be to use u-boot
<betaboon> samueldr: i think i experienced the same, uboot working but not being able to boot into nixos, for pi3 and orange-pi-zero it worked fine tho
<samueldr> then we can make the difference between the defconfig and the pi4 image simply the kernel
<betaboon> i think i resorted to going back to stock pi bootloader when i figure out i can have model-based config-sections in config.txt
<samueldr> if we can reduce it to that single difference, there's also a clear upgrade path for when the mainline kernel works
<betaboon> I'm delivering all that and the nix-store via nfs via tftp/netboot
<betaboon> i realy dislike how nixos-generate-config doesnt use partition-labels for the filesystems
<samueldr> it'd be a good addition as an option, --prefer-partition-labels
<samueldr> or --partitions=by-label
<betaboon> samueldr: https://gist.github.com/betaboon/e3f64e7ab521899835760a74a970b696 < i doubt the generated configuration.nix will work as it enables grub (which has been mentioned not to work yet)
<samueldr> odd, it should detect some things
* samueldr looks at the source
<samueldr> there is no equivalent for the raspberry pi
<samueldr> right, so for the pi4's instructions we'll need to document it properly in the upcoming device-specific page.
<betaboon> I'll try with the configuration i initially posted
<samueldr> yeah, that should do it
<samueldr> since that's what's actually needed from the installer profile you included beforehand
<samueldr> (also note that you'll want to mutate root's password with sudo passwd)
<betaboon> ok. i set root-password with passwd, added `console` options to `boot.kernelParams` and connected to wifi using wpa_supplicant (as documented in the manual), now running `nixos-rebuild switch` as root. fingers crossed
<betaboon> seems to have worked. no wifi interface now tho
<samueldr> betaboon: can you confirm that it's using PXE for network boot?%
juliosueiras has quit [Ping timeout: 260 seconds]
<betaboon> samueldr: no it is not
<betaboon> samueldr: it is doing very weird stuff. basically it tries to lookup all the files that normally go in the boot-partition (like bootcode.bin, config.txt etc) on a tftp-server
<samueldr> good, will just call it "netboot" in its boot order
<betaboon> yep do that. thats what the pi documentation refers as well
<betaboon> samueldr: should `hardware.enableRedistributableFirmware = true;` solve the wifi-device not showing up after reboot ?
<samueldr> oh, possibly yes
<betaboon> samueldr: yes it did fix it. so the config in my gist works
<samueldr> thanks
<samueldr> betaboon: is it alright to include that on the wiki page?
<betaboon> samueldr: sure
<betaboon> argh ofc with that configuration wpa_supplicant is not installed XD
<samueldr> that's kind of a non-issue
<samueldr> the interface's there, the wiki assumes *some* agency in the reader :)
<betaboon> yep XD
<samueldr> the important bits are the non-obvious ones
<betaboon> hm wpa_supplicant failed to start after reboot
<samueldr> right, so now we have a specific page https://nixos.wiki/wiki/NixOS_on_ARM/Raspberry_Pi_4
<samueldr> probably much more clearer than all bunched up in that one page
<samueldr> we still have the overview page https://nixos.wiki/wiki/NixOS_on_ARM/Raspberry_Pi
<samueldr> which has the unhelpful details for the 0, 1 and 2
<samueldr> but links to the more fleshed-out pages for the 3 and 4
<colemickens> samueldr: I was talking pinebook pro as far as the install. I am actually being stubborn and won't flash a mobile-nixos build until I get it building via flakes. So for now, just Manjaro on eMMC and I did play with a Glodroid build installed to the SD Card.
<samueldr> [02:50:50] <colemickens> btw on pinephone I burned uboot to an SD Card and then did a typical GPT install to the eMMC
<samueldr> slip of the pine?
<colemickens> oh no :( yes
<samueldr> typical with UEFI or typical with extlinux.conf?
justanotheruser has joined #nixos-aarch64
<samueldr> :< cross-compiling regressions are the worst
<samueldr> especially with bad error messages
<samueldr> >> configure: error: cannot run test program while cross compiling
<samueldr> see, that's perfectly fine
<samueldr> except it doesn't tell me *which* test
<samueldr> part of the AFAICT autoconf, just tells me it cannot run the test, but not which
<samueldr> aaaand it turns out it's not something that can be overriden trivially
<pie_> iscsiadm: exiting due to idbm configuration error
<pie_> iscsiadm: Could not make /etc/iscsi/ 13
<pie_> clever: any advice?: $ iscsiadm -m discovery -t st -p
<hexa-> uh, looks like you're unprivileged
<hexa-> elevate
<pie_> i mean, obviously it wants to make the directory
<pie_> but should i let it?
<clever> yes
<pie_> and stuff
<pie_> for apparently how simple iscsi is supposed to be it looks like theres a lot of knobs and stuff
<clever> it has multi-path and auth stuff mixed in
<clever> nbd is a lot simpler
<clever> but ive had trouble with nbd being very unreliable
<pie_> never heard of nbd
<pie_> re, auth mixed in, ironically its not very strong from what ive seen
<clever> i believe it also has encryption too
<pie_> not that i know of?
<pie_> at least i saw people explicitly stating that iscsi is unencrypted
<pie_> so you shouldnt run it over untrusted connections or something
<clever> i think thats just for the default state
<pie_> hm
<pie_> iscsiadm: can not connect to iSCSI daemon (111)!
<pie_> iscsiadm: iscsid is not running. Could not start it up automatically using the startup command in the /etc/iscsi/iscsid.conf iscsid.startup setting. Please check that the file exists or that your init scripts have started iscsid.
<pie_> iscsiadm: can't open iscsid.startup configuration file /etc/iscsi/iscsid.conf
<clever> iscsid must be running first
<pie_> well, i didnt see anyone say anything about needing to run an iscsid :P
<pie_> clever: how did you figure this stuff out?
<pie_> read the man pages?
<clever> pie_: that, and reading guides, i set it up on my pi ages ago
<pie_> man, i dont like it when people dont make stuff like this self contained
<pie_> why should i need to run a daemon to do discovery
<clever> yeah, discovery is a bit anoying
<clever> but you also need to discover before you can login
<clever> the daemon saves the results and needs them for login
* clever looks
<clever> pie_: thats using iscsistart, which is a static binary that skips the need for a daemon, since its meant for use in the initrd
<pie_> aha
<clever> pie_: you still need to switch to iscsid as you boot, so you have reconnect logic
<pie_> maybe i want to use that?
<pie_> aha.
<clever> as for why i even began that
<clever> i tried using nfs backed by xfs, for my rpi roots
<clever> and everything failed :P
<pie_> oh no :P
<clever> half the tools used in nixos boostrap (like font packing for the initrd and even stdenv building) dont deal with 64bit off_t properly
<pie_> off_t?
<clever> with xfs, the inodes are spread evenly over the disk, and paired up with the first data block, to reduce seek times
<clever> so any data starting >1tb into the disk, has an inode# that is >32 bits in size
<pie_> aha
<clever> nfs properly carries that 64bit inode over the network
<clever> the 32bit compatability stat() and readdir() just return EOVERFLOW, because the inode wont fit
<clever> you must build the program with large file support, making the typedef off_t 64bits large
<clever> half the tools in the stdenv, tread readdir() == EOVERFLOW as EOF instead
<clever> and silently claim files dont exist, when they do
<pie_> :I
<clever> the solution, was to use iscsi to map the disks over
<pie_> so ...do those tools just...normally fail on other distros too
<clever> then the FS runs on the pi, plain ext3, and the inode#'s wont be insane, due to it being both ext3 and small
<clever> ext3 doesnt have such huge inodes normally
<clever> it only fails if your on xfs, with 1tb already on your disk, before you create the system files
<clever> and only with a 32bit userland
<pie_> ok i was assuming 64bit userland
<pie_> i dont really know how this works, i figured inode numbers are entries in a table ro something
<clever> 64bit userland doesnt have the 32bit compat syscalls
<pie_> yeah i was going to ask abut that because under my assumptions it sounded weird
<clever> stat() and readdir() HAD (in the 32bit days) a 32bit wide field for the inode#
<clever> and then 64bit kernels made that field bigger
<clever> but you cant change the struct on a 32bit kernel, because that would break pre-compiled stuff
<clever> so the 32bit userland, has a stat64() and readdir64() syscall, that return 64bit fields instead
<clever> and you then compile your program the right way, and libc maps it for oyu
<clever> pie_: the real fun thing though, is that i took the iscsi-boot module from a pi, shoved it into an x86 laptop with grub, and it booted perfectly on the first try
<pie_> oh i though tdiscovery is something like ls but its not
<clever> [root@amd-nixos:~]# iscsiadm -m discovery -t sendtargets -p nas.localnet
<clever>,1 iqn.2019-01.amd-steam
<pie_> :D <clever> pie_: the real fun thing though, is that i took the iscsi-boot module from a pi, shoved it into an x86 laptop with grub, and it booted perfectly on the first try
<clever> this is what i get when i run discovery
<clever> that laptop was even using iscsi more then the pi was
<clever> sanboot iscsi:
<clever> it was using this in ipxe
<clever> that causes ipxe to hijack the legacy (x86 bios style) disk io routines, and map them over iscsi
<clever> so when grub loads up, it thinks its dealing with a local hdd!
<clever> and things just boot like normal, until linux takes over
<pie_> i did leave out a bunch of config probably
<pie_> how come nixos doesnt have an iscsi module :P
<clever> i never bothered to PR the modules i linked above
<clever> and the tgtd module still needs work
<pie_> it would probably be more work to genericize them
<pie_> oh i didnt check your iscsi module
<pie_> doh
<clever> iscsi_module just starts the daemon and nothing else
<clever> iscsi-boot connects to things only during the initrd
<clever> tgt-module (same repo), needs work, it randomly fails
<pie_> my initiatorname and iscsid config _are_ empty
<pie_> but i didnt configure auth or anything on the target
<clever> iscsiadm: connected local port 39304 to
<clever> mine prints this when i add `-d6` to it
<pie_> clever: sorry pebkac, i probably forgot the remote firewall
<clever> check what tcpdump and strace have to say?
<pie_> i thought of that earlier then forgot
<pie_> but yeah its not very hjelpful it doesnt say it failed to connect
<pie_> (btw the 6 is arbitrary)
<pie_> wait how did i end up in -aarch, i meant to be in main
<pie_> oh well
<pie_> (theyre right next to eachother)
<clever> not for me, this is window6, and #nixos is 8
<clever> and -dev is 7
<pie_> :p
Darkmatter66 has quit [Quit: ZNC 1.7.5 - https://znc.in]
Darkmatter66 has joined #nixos-aarch64
<pie_> opening the firewall didnt change the message so i guess lack of config might be taking precedence
<clever> pie_: does strace or tcpdump reveal anything?
<pie_> dunno what to look for in strace but tcpdump shows my nmap but nothing coming when i try to start the discovery
<pie_> to be clear i have a really barebones config here, i didnt set up any config files on the client
<pie_> iscsid is just sudo iscsid -f
<clever> pie_: strace -e connect
<clever> you may need to strace both the daemon and the iscsiadm
<pie_> for adm its just
<pie_> connect(4, {sa_family=AF_UNIX, sun_path=@"ISCSIADM_ABSTRACT_NAMESPACE"}, 30) = 0
<pie_> connect(3, {sa_family=AF_UNIX, sun_path=@"ISCSIADM_ABSTRACT_NAMESPACE"}, 30) = 0
justanotheruser has quit [Ping timeout: 240 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<pie_> all that comes from the daemon is connect(7, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = 0
<clever> try adding a -f to strace for both
<pie_> doh
<pie_> well, the daemon does say:
<pie_> iscsid: Warning: InitiatorName file /etc/iscsi/initiatorname.iscsi does not exist or does not contain a properly formatted InitiatorName. If using software iscsi (iscsi_tcp or ib_iser) or partial offload (bnx2i or cxgbi iscsi), you may not be able to log into or discover targets. Please create a file /etc/iscsi/initiatorname.iscsi that contains a sting with the format: InitiatorName=iqn.yyyy-mm.<reversed domain name>[:identifier].
<clever> check my iscsi_module.nix
<pie_> yeah afaict nothing really gets triggered with networking
<pie_> yeah i got nothin
<pie_> i used your -i and -c
<clever> and did the interpolation right?
<pie_> yeaú
<pie_> doent complain about configs missing anymore
<clever> not sure then
<pie_> doesnt even seem to try to use the network
<pie_> ok maybe it didnt do anything because there is already an entry in the db
<pie_> no idea how this works
<pie_> not sure how there would have been an entry lacking an open firewall rule but eh
<pie_> or the mode i was using manually adds an entry, idk
juliosueiras has joined #nixos-aarch64
<pie_> well, i mean, im looking at https://www.howtoforge.com/how-to-setup-iscsi-storage-server-on-ubuntu-1804/ and its not doing the thing
<pie_> but im probably about to go to sleep
<pie_> hm the discovery command works on the remote ubuntu target machine
<clever> try a reboot?
<pie_> on which machine
<clever> the client
<pie_> got too much stuff open :
<pie_> :/
<pie_> how could that even help though
<clever> the modules or daemon could be in a weird state
<pie_> im starting the daemon manually and i dont think i even have a module on the client?
<pie_> i jsut deleted /etc/iscsi
<pie_> setting -d8 on the daemon enanbles soem more output but nothing interesting happens when i run the iscsiadm comman
<clever> just pastebin the whole `strace -f` for both the daemon and adm?
<pie_> aight
<pie_> clever: btw the client doesnt exit
<clever> which process is the client?
zupo has joined #nixos-aarch64
<pie_> clever: what do you mean?
<clever> iscsid or iscsiadm ?
<clever> both are running on the client machine
<pie_> i mean the iscsiadm doesnt exit
<clever> ah, thats abnormal
<clever> it should always exit
<clever> the strace logs may hint at why it isnt
<pie_> clever: daemon: https://bpa.st/P3PQ
<pie_> i ^C the client. the daemon doesnt exit uder ^C until the client does
orivej has joined #nixos-aarch64
<pie_> clever: client: https://bpa.st/PSLA
<clever> if you look at the daemon, near the accept()
<clever> it accepts a connecting from the client, reads a 16kb packet, then just hangs up in its face
<pie_> line 753?
<clever> yep
<pie_> well, there are several instances of that
<clever> but each time, it never says anything to the client, and doesnt seem to act on the messsage in any way
<clever> and the client isnt getting the message when it hangs up
<clever> so it just hangs
<pie_> yeah i gues
<pie_> dunno what to do about it
<clever> is this running in the initrd or under a full nixos?
<pie_> full nixos
<pie_> im just trying to mount a disk or something
<clever> then its not the /etc/passwd bug
<pie_> loll
<pie_> open-iscsi is quality software? :P
<pie_> why does it seem like noone has tried to use iscsi under nixos
<clever> when you connect, it uses unix sockets to query your remote uid (0 in this case)
<clever> it then reads /etc/passwd to see who 0 is (its root)
<clever> but in an initrd, /etc/passwd doesnt exist, so you get denied access
<clever> iscsistart uses a special function to bypass that lookup
<clever> you could try that anyways?
<pie_> you mean try iscsistart?
<clever> yeah
alp_ has joined #nixos-aarch64
<pie_> whats a target portal group tag
<clever> the `-g 0`? not sure what that does
<pie_> i did g1 and it didnt immediately complain
<pie_> how do i ^C this thing it doesnt waant to die :P
<pie_> kill -9
<pie_> hm it ust stopped at some point
<pie_> complains abou tdaemon not running
<pie_> guess ill start the daemon
<pie_> didnt you say it was a static exe that doesnt need the daemon?
<pie_> or was i not paying enough attention
<pie_> or is this a different iscsistart
<clever> iscsistart shouldnt need the daemon
<pie_> works better with sudo :P
<pie_> guess it looks for the daemon if its not root
<clever> yes :P
<pie_> iscsistart: initiator reported error (15 - session exists)
<pie_> iscsistart: Logging into wtf:lun1,1
<pie_> iscsistart: version 2.1.2
alp has quit [Ping timeout: 244 seconds]
<clever> try a different initiator name?
<pie_> same eror
<clever> restart the target daemon on the remote end?
alp_ has quit [Ping timeout: 244 seconds]
<pie_> i restarted tgt, same thing
<clever> no idea then
<pie_> dunno if thats like ssh though where it doesnt kill sessions ro something .p
<clever> stop tgtd and then confirm if all procs are stopped?
<pie_> on the upside, seems like network traffic happened
<pie_> yeah i got nothin
<pie_> moar strace
<pie_> clever: bruh,
<pie_> tcp: [1],0 wtf:lun1 (non-flash)
<pie_> sudo iscsiadm -m session
<pie_> ive no idea what this means but i seem to have some sort of session on the client i guess
<pie_> im assuming thats not clearing with a restart
<pie_> idek how to select that and delete it
<pie_> this is going under my "list of tools that are hard to use" list
orivej has quit [Ping timeout: 240 seconds]
<pie_> *shrug* https://bpa.st/PMYQ
justanotheruser has joined #nixos-aarch64
<pie_> ok some things are starting to make a little sense
<pie_> i had to start the daemon (obviously) to get operations to run
<pie_> and i think i managed to log out of that session, whether or not it actually existed
<pie_> though the command still doesnt seem to want to terminate
<pie_> ok maybe its not able to log out of it
stiell has quit [Ping timeout: 265 seconds]