danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
hanetzer2 has quit [Quit: WeeChat 3.8]
<Mangix>
qemu-mips-static: Could not open '/lib/ld-musl-mips-sf.so.1': No such file or directory
<Mangix>
sigh
bluew_ has joined #openwrt-devel
bluew has quit [Ping timeout: 480 seconds]
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
dangole has quit [Ping timeout: 480 seconds]
hanetzer has joined #openwrt-devel
minimal has quit [Quit: Leaving]
tSYS has quit [Quit: *squeak*]
tSYS has joined #openwrt-devel
valku has quit [Quit: valku]
Lynx- has joined #openwrt-devel
Lynx- has quit [Ping timeout: 480 seconds]
tomn has quit [Remote host closed the connection]
tomn has joined #openwrt-devel
lemmi has quit [Remote host closed the connection]
lemmi has joined #openwrt-devel
cbeznea has joined #openwrt-devel
goliath has joined #openwrt-devel
Tapper has joined #openwrt-devel
lmahmutov has joined #openwrt-devel
sorinello has quit [Quit: Leaving]
indy_ has joined #openwrt-devel
indy has quit [Ping timeout: 480 seconds]
Misanthropos has quit [Ping timeout: 480 seconds]
indy_ is now known as indy
sorinello has joined #openwrt-devel
lmahmutov has quit [Remote host closed the connection]
shoragan has quit [Remote host closed the connection]
shoragan has joined #openwrt-devel
<oliv3r[m]>
dwfreed: well 'something' changed somewhere for this to be a problem. But according to those posts, there's cleaner ways to deal with this then going over whatever hard limit there is; but i'll leave that to the upstreams to decide :) I did notice the same issue with rsyslogd too; so it's not just faked, setting a small ulimit fixed the problem
Misanthropos has joined #openwrt-devel
<dwfreed>
oliv3r[m]: many programs will close all file descriptors above what they need; prior to Linux 5.11, there was no way to do this that was not 'loop through every possible fd number from our starting point to the limit of fds we can have'
<dwfreed>
and even since 5.11, many programs haven't been updated to use close_range or closefrom
<oliv3r[m]>
idk :) but I think the change was not so much with fakeroot/rsyslogd/docker; well maybe docker, but something in systemd/kernel/docker
<oliv3r[m]>
but we'll see, arch is bleeding edge with their kernels, so sooner or later, it'll be fixed and nobody will notice, or it'll start popping up more; i'm just happy i can mitigate it a lot by using low numer of nofiles :)
<mrkiko>
oliv3r[m]: are you using Arch as a host?
mrkiko has quit [Quit: leaving]
<oliv3r[m]>
mrkiko: for my openwrt docker container, yess
<oliv3r[m]>
so amd64(arch(docker(alpine/debian(openwrt))))
mrkiko has joined #openwrt-devel
<mrkiko>
sorry...
<oliv3r[m]>
haha, why so?
<mrkiko>
oliv3r[m]: because I rebooted the VM and so was out of irc for a while
<oliv3r[m]>
ah, I didn't notice :) (i'm on via a matrix bridge)
<oliv3r[m]>
but what I said, was I use an openwrt build container; so I have amd64(arch(docker(alpine|debain(openwrt))))
<mrkiko>
oliv3r[m]: thanks
<karlp>
dwfreed: what's the intent with closing fds above what a program needs? what's being worked around or prevented with that?
<mrkiko>
oliv3r[m]: have you ever tried compiling ipq807x ?
<oliv3r[m]>
mrkiko: nope, but I can try
<dwfreed>
karlp: making sure you eliminate any dangling file descriptors that might have been leaked to you
<dwfreed>
sudo does this too
danitool has joined #openwrt-devel
PaulFertser has quit [Ping timeout: 480 seconds]
<oliv3r[m]>
mrkiko: any reason you want me to do ipq807x?
<mrkiko>
oliv3r[m]: well, if you can / want... try compiling e.g.: ZYXEL NBG7815; just curious to know if it succeeds or fails as it does locally for me in qca-ssdk
<mrkiko>
but wait
<mrkiko>
I compile directly within arch
<mrkiko>
amd64(arch(build process))
PaulFertser has joined #openwrt-devel
<oliv3r[m]>
any particular branch?
<mrkiko>
oliv3r[m]: no, opewnrt master
<oliv3r[m]>
preference for a debian or alpine build?
<dwfreed>
should not make any difference functionally
<mrkiko>
oliv3r[m]: mhm, alpine
<oliv3r[m]>
that's what i'm doing :)
<mrkiko>
oliv3r[m]: but probably it will work fine for you because it's native
<oliv3r[m]>
it's building; but probably will take like half an hour to build all the tooling first
<mrkiko>
oliv3r[m]: thanks a lot for your test, I'm in no hurry
<oliv3r[m]>
np
<karlp>
dwfreed: right, but... why? what does that do? I'm missing something
<dwfreed>
ensures you don't have access to things you shouldn't have by accident
<dwfreed>
fds are used for more than just regular files, especially in modern linux
<dwfreed>
you can get a file descriptor that reads a hunk of memory (memfd)
<damex>
how could i debug this? i managed to take out and plug in sfp interface. i tried ODI onu sfp interface and 1gbase-t sfp interface - occasionally it corrupts overlayfs
<damex>
somehow can not cat but can do less for some files. can not do 'dmesg' - free in the middle and etc.
<damex>
i managed to save most of the configs and do firstboot -> reboot and then it works again
<dwfreed>
karlp: if you want a great story about why you should close fds so you don't leak them to your own children, see https://stackoverflow.com/a/56650860
<damex>
i managed to repeat it on another device - plug sfp out -> plug sfp in -> corrupt until you do full reset
<mrkiko>
damex: scary
<damex>
yeah, it is completely unrelated devices beside having sfp ports. mikrotik hex-s was the first one. second is banana pi r3.
<damex>
it seem okay if i plug in that sfps to any switch i own.
<karlp>
dwfreed: ok I guess? I mean, I get what you mean, it just seems odd, (to me) to start a program and decide, "I'd beter close all fds, just in case someone else left them for me, even though theyw on't be reissued to me, so if I just track my own fds, it won't ever matter"
<karlp>
I mean, yeah, I can see this being important sometimes, but it seems super niche to "close all unused fds" on startup.
<dwfreed>
karlp: it matters for things that need to care about security
<dwfreed>
which faked, rsyslog, and sudo do
<karlp>
sure,
<karlp>
I can see those cases,
<karlp>
your comment earlier made me think this was a more widespread thing that programs were doing.
<karlp>
"many programs will close all file descriptors above what they need;"
lmahmutov has joined #openwrt-devel
<karlp>
thanks for the extended information, it's appreciated.
<oliv3r[m]>
mrkiko: it booted; took an hour to build; but it's done :) need the binary to test things?
<mrkiko>
oliv3r[m]: no, the fact you told me it builds successfully, makes me understand the problem is on mysystem
<mrkiko>
oliv3r[m]: thanks a lot; I can't understand what's happening but ok
<mrkiko>
oliv3r[m]: similar to your "faked2 issue
<oliv3r[m]>
so with debian, i get corrupt binaries or something, idk and it takes forever to build; didn't look too deeply into it; on alpine, it works, but takes a bit of time
<oliv3r[m]>
you could try building with ulimit -n 1024 -Hn $((1024*1024)) or something
<mrkiko>
oliv3r[m]: thanks for the hint
<oliv3r[m]>
I have attached my docker files to https://github.com/openwrt/openwrt/pull/12022/ if you want to try with docker; but then you'd need `docker run --ulimit nofile=1024:$((1024*1024))
<oliv3r[m]>
(btw these are made up numbers, idk what's sensible, but this looked sensible :)
<damex>
any idea what i could try? firstboot -> restoring configuration partially restore config. uhttpd still does not work and reflashing firmware do nothing
<mrkiko>
oliv3r[m]: thanks! I'm not very experienced with docker
<oliv3r[m]>
mrkiko: neither was I :p but I find defining build-environment in docker to be amazing, no polution of the host :)
<oliv3r[m]>
mrkiko: what I do; `docker build --file Containerfile-debian --rm --tag openwrt:debian ./` to build a debian container. (OpenWRT also generates some, but they where failing for me due to being based on debian, so I created an alpine one which works). I build the container only once every few months, because dependencies don't change... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/wEohRHAJIoYMhNugBmdBAjLY>)
<oliv3r[m]>
build -> take an input file of instructions, and create a container image; run, take a container image tag, and execute the command (bash in this case).
<mrkiko>
oliv3r[m]: yeah, definitely very very nice, and helps a lot reproducibility
<oliv3r[m]>
obviously, doing multiple worktree's and multiple containers (initially) is very slow, as you have to rebuild the whole toolchain. Ansuel I think was working on pushing these containers from the CI somewhere for easier reuse
<oliv3r[m]>
the upside is, you can throw away an environment, and are not tied to your host
<damex>
update: [ 0.663131] OF: Bad cell count for /palmbus@1e000000/spi@b00/flash@0/partitions have tis
djfe has joined #openwrt-devel
Lynx- has joined #openwrt-devel
<mrkiko>
oliv3r[m]: very nice; so the final idea would be to have toolchain as kind of something you can use to compose the final image and build only what you need
robimarko has joined #openwrt-devel
<mrkiko>
oliv3r[m]: yeah, please ... a wiki page for this would be very very nice, seems effcient when you have the setup
Lynx- has quit [Ping timeout: 480 seconds]
dangole has joined #openwrt-devel
<mrkiko>
oliv3r[m]: to have some light on that - I used to use "make V=99" and it outputted most everything. but how does it work really? What's the difference between V=99, V=s or V=sc
lmahmutov has quit [Remote host closed the connection]
<oliv3r[m]>
I have absolutly no idea :D i just foudn that one some openwrt build document :) or maybe make spits that out on errors
<mrkiko>
oliv3r[m]: thanks
<karlp>
iirc V=99 was old "everything" V=s is equivalent to V=99, V=sc includes cmake debug,
<mrkiko>
karlp: thanks for the hint! With my last V=99 I couldn't see kernel build output as I used to
<robimarko>
oliv3r[m]: Any luck with MIPS generic?
<oliv3r[m]>
robimarko: sadly, no. I dont' know if you saw, but was talking to arndb, but he hasn't been able to help me much either
<oliv3r[m]>
robimarko: but I fixed my faked issue :p
<robimarko>
oliv3r[m]: I was/am still sick so I was away from any screens for like 4 days
<oliv3r[m]>
robimarko: the problem seems to be, that the lexra bus in our platform (well i took some comments frm the lx4189 document) that it's a 32bit Big Endian bus only
<oliv3r[m]>
robimarko: ouch; hope you get well soon!!
<karlp>
mrkiko:include/verbose.mk impiles that V=99 should still be equal to V=s, if I can read properly.
<oliv3r[m]>
robimarko: so when the soc tries to access the bus in anything that is not big endian, things no longer work (for obvious reasons) due to `CONFIG_SWAP_IO_SPACE` being considered 'generic' (for modern chips :p)
<oliv3r[m]>
MAYBE the lexra bus has a toggle for it, but I haven't seen any register information on the lexra bus, and grepping for 'lexra' in the kernel tree doesn't yield much information either.
<robimarko>
oliv3r[m]: Well, that is "fun"
<oliv3r[m]>
so what I did for now, introdce a flag, and do +select SWAP_IO_SPACE if (!SYS_HAS_BIG_ENDIAN_LEXRA_BUS || !CPU_BIG_ENDIAN) which seems reasonable enough for now
<oliv3r[m]>
I hope I can confince the mips people upstream at some point, that no, it isn't that generic, and do we prefer having generic kernel config, or have tons of them, just to avoid calling that generic :D
<oliv3r[m]>
anyway, that's a battle for later, I think this is quite a clean fix/quirck (we can argue on naming of course)
<mrkiko>
karlp: thanks a lot for the hint! Something should be strange here since I could see the build output also some days ago. Thanks for looking at it
<mrkiko>
robimarko: hope you get well soon!!
<robimarko>
Its getting better, I had to remove a damn wisdom tooth and that got complicated
<robimarko>
oliv3r[m]: I guess that combinations like these werent really intended to exist
<oliv3r[m]>
the alternative is to remove CONFIG_SWAP_IO_SPACE from the generic mips target; if its not THAT generic; i'm still not convinced its so generic, since the exposure of generic mips kernel is tiny, and tons of other targets exist too
<mrkiko>
robimarko: oh, did the same some long time ago; no fun
<oliv3r[m]>
if we want to 'migrate' towards a generic kernel, something has to give somewhere, but again, discussion with upstream; if they want to maintain a duplicate entry in the Kconfig, go for it
<robimarko>
oliv3r[m]: I guess that idea is for the MIPS generic to be generic enough
<robimarko>
Most of the other targets predate MIPS generic
<oliv3r[m]>
well we managed to squeeze an ancient arch (rtl9300 is based on ancient stuff) to work just fine with mips generic, except for the bus accessors
<oliv3r[m]>
there might still a trick somewhere, e.g. a lexra bus flip, a mips operation; but I don't know them :(
bluew_ has quit [Quit: Leaving]
<oliv3r[m]>
and then, should it be generic to 'easily' ecompass as many targets as possilbe; or should all targets just be engineerd to match mips-generic
<oliv3r[m]>
I know what deff. won't happen :p
<robimarko>
BTW, did anybody ever get SMP to work on RTL?
<robimarko>
MIPS generic is there to cover as much as possible, it cant possibly cover all of the weird HW combinations
<oliv3r[m]>
to be fair, the mangle-port.h even talks about 'sane hardware' and what not ... which is also 20 years old I think; so yeah :)
<oliv3r[m]>
besides, I don't think it's weird having a big endian bus, on a big endian CPU :)
<robimarko>
Me neither
dangole has quit [Remote host closed the connection]
<oliv3r[m]>
obviously i'm biased but I'll argue my case :p
<robimarko>
Well, that is how a middle ground is reached
valku has joined #openwrt-devel
<oliv3r[m]>
course :) but i've laid out some quesitons with the maintainer already; but he's slow to respond :D
<oliv3r[m]>
anyway, that paste hopefully answers your question :)
<robimarko>
Yeah
<robimarko>
I just found the discussion, love following upstream discussions
<oliv3r[m]>
the generic mips thread? it's me just asking questions :D
<robimarko>
Yeah
Danct12 has quit [resistance.oftc.net coherence.oftc.net]
AtomiclyCursed2 has quit [resistance.oftc.net coherence.oftc.net]
zatwai has quit [resistance.oftc.net coherence.oftc.net]
mcbridematt has quit [resistance.oftc.net coherence.oftc.net]
Namidairo has quit [resistance.oftc.net coherence.oftc.net]
madwoota has quit [resistance.oftc.net coherence.oftc.net]
AtomiclyCursed has joined #openwrt-devel
Danct12 has joined #openwrt-devel
madwoota has joined #openwrt-devel
zatwai has joined #openwrt-devel
Namidairo has joined #openwrt-devel
mcbridematt has joined #openwrt-devel
<oliv3r[m]>
How many of the gazillion openwrt patches do we really need? I get the mtd stuff; but the others
<karlp>
pick one, work on sending it upstream, continue...
<karlp>
how are you counting "gazillion" by the way?
<oliv3r[m]>
ls target/linux/generic/*-5.15 -1 | wc -l => 587
<robimarko>
I mean, thats not really accurate as a lot of those are backports
<oliv3r[m]>
though to be fair, most of it are backports and pending; so there's only 51 'hacks'
<robimarko>
But, a lot of the pending stuff is more like hacks that never got upstreamed or got NACK-ed upstream
minimal has joined #openwrt-devel
dangole_ has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
<damex>
so is there a way to debug what is going on on openwrt device if input freeze when you run dmesg/
<damex>
i don't see anything happening at the moment. no performance spikes. no activity. nothing
goliath has quit [Quit: SIGSEGV]
<stintel>
is this via serial or ssh ?
<stintel>
damex: ^
<damex>
stintel: ssh
<damex>
i have found that it free on disk/flash reading
<damex>
gotta reinstall routeros -> install openwrt all over again
<stintel>
this could be an MTU issue
<damex>
stintel: well, not sure about that 1.5k everywhere here
<stintel>
I said "could" ;)
<stintel>
you could easily test it, reduce the MTU of the interface through which you're connected to the device to 1280 or so and try again, if it still happens, continue digging
robimarko has quit [Remote host closed the connection]
robimarko has joined #openwrt-devel
cbeznea has quit [Quit: Leaving.]
djfe_ has joined #openwrt-devel
gladiac has joined #openwrt-devel
djfe has quit [Ping timeout: 480 seconds]
<damex>
stintel: so it is not MTU related. it is definitely disk/bad blocks or whatever related :)
<damex>
installed last 6.49.7 -> boot it (somehow it craps out more than needed) -> trick it to boot to netboot again (trick because mikrotik, thats why) -> boot initramfs -> flash sysupgrade :)
<damex>
i wonder if some grabage collecting could be done on linux/openwrt
<damex>
like on routeros
xes_ has quit [Ping timeout: 480 seconds]
<stintel>
you can throw it in the trash, and the garbage will be collected
<stintel>
:P
cbeznea has joined #openwrt-devel
<damex>
stintel: but hardware like mikrotik hex-s seem to be pretty decent
<damex>
actually it has NOR flash and i have no clue how come it become bad
xes has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]
<damex>
i actually have had same issue running openwrt from eMMC on bananapi r3.
<damex>
reflashing fixed it. kinda bad experience
<djfe_>
does the routeros really have only 4 partitions?
<djfe_>
or are there more and OpenWRT doesn't map all of them? I see bootloader1, bootloader2, firmware and bios
djfe_ is now known as djfe
gladiac has quit [Quit: k thx bye]
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
gch981213 has quit [Quit: Ping timeout (120 seconds)]
gch981213 has joined #openwrt-devel
dangole_ has quit [Remote host closed the connection]
<f00b4r0>
djfe: you seem to be missing soft_config and hard_config at the very least
<djfe>
those are partition names?
<djfe>
I saw them in the dts but without offsets and anything
Tapper has quit [Ping timeout: 480 seconds]
kcinimod has joined #openwrt-devel
kcinimod_ has quit [Read error: Connection reset by peer]
<mrkiko>
dangole_: still around?
<dangole_>
mrkiko: yes
srslypascal is now known as Guest6419
srslypascal has joined #openwrt-devel
Guest6419 has quit [Ping timeout: 480 seconds]
<Kufat>
has anyone else had issues with acme during the package/install stage? complains about a lack of /etc/crontabs/root and /usr/lib/acme/functions.sh even though it should create the former and the latter exists under the appropriate root dir within the target. if it's not a known issue I'll open a ticket