<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?
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
<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]
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
<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
<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
<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>
[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>
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>
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 10.0.164.11
<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>
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
<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
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