00:08 <owrt-images-builds> Build [#35](https://buildbot.openwrt.org/images/#/builders/224/builds/35) of `openwrt-23.05_mediatek/filogic` failed.

08:12 <ynezz> nbd: hi, there seems to be umdns crashing since 23.05.0 https://github.com/openwrt/openwrt/issues/14120 and one of the affected users "confirmed", that its fixed in main branch, which lead me to the following cherry-pick https://github.com/openwrt/mdnsd/pull/14 - I've created openwrt-23.05 branch as it seems, that due to udebug and other new features we wont be able to use main anymore, can you

08:12 <ynezz> please confirm/double check that, I'll then update the package

10:44 <nbd> ynezz: ack

10:45 <f00b4r0> nbd: hi, dunno if you got my last message, is there any further data I can collect on the device to help you?

10:55 <owrt-images-builds> Build [#36](https://buildbot.openwrt.org/images/#/builders/33/builds/36) of `openwrt-23.05_ipq40xx/mikrotik` completed successfully.

11:16 <nbd> f00b4r0: can't think of anything at the moment

11:16 <nbd> need to look further into it myself

11:16 <f00b4r0> ok thanks, I'll reboot it then

11:18 <f00b4r0> another datapoint if that matters: when the crash occurred there were 7 STAs across the 6 phyN-apM tuples

14:22 <jow> rmilecki: sorry, totally overlooked your patch

14:22 <rmilecki> jow: no problem

14:56 <Ansuel> aparcar ping?

20:20 <rmilecki> jow: would you review my other fix?

20:20 <rmilecki> [PATCH] base-files: sysupgrade: handle errors when generating backup

20:51 <schmars[m]> neocturne that commit of yours about compile deps yesterday - the thing it fixes is `No rule to make target '/path/to/sdk/staging_dir/target-x86_64_musl/.prepared', needed by 'package/toolchain/compile'. Stop.` yes?

20:55 <schmars[m]> or maybe your commit breaks it? :D just wondering what broke my SDK script in the past few days

21:29 <rmilecki> any idea what problem may it be?

21:29 <rmilecki> [ 61.478467] do_page_fault(): sending SIGSEGV to ujail for invalid read access from 00000036

21:29 <rmilecki> [ 61.495195] epc = 77d30d0b in libubox.so.20230523[77d2d000+1f000]

21:30 <rmilecki> [ 61.507471] ra = 5555482b in ujail[55550000+14000]

21:30 <rmilecki> it's on freshly installed openwrt-23.05.2-ramips-mt7621-netgear_r6220-squashfs-sysupgrade.bin

21:36 <neocturne> schmars[m]: hmm, it is possible that my commit breaks it, I didn't test with the SDK

21:36 <neocturne> Will have to check tomorrow

21:39 <schmars[m]> thank you, the build system is way over my head

21:40 <neocturne> Might just need to conditionalize the new dependencies so they are ignored when in SDK (and maybe IB)

21:43 <schmars[m]> IB seems to be ok. if you need a repro here's the script: https://github.com/freifunk-berlin/falter-packages/blob/master/build/build.sh (nothing special really)

21:44 <neocturne> Thanks. Can you tell me at which command it fails?

21:45 <schmars[m]> right, make -j8 V=s package/falter-berlin-admin-keys/compile - the first iteration of that loop

21:47 <mrkiko> rmilecki: beware of the flash on that device

21:47 <mrkiko> rmilecki: are you able to read all contents of /rom without encountering errors?

21:49 <rmilecki> mrkiko: find /rom/ worked fine

21:49 <rmilecki> do you want to me actually read all files?

21:49 <mrkiko> rmilecki: mhm... I would try a grep

21:49 <rmilecki> mrkiko: what's up with flash?

21:49 <mrkiko> rmilecki: in other words - in some cases reading /rom did lead to squashfs errors for me, and reflashing a sysupgrade "magically" solved the problem

21:50 <mrkiko> rmilecki: with a very old sample I remember the system not being able to boot at some point, after having left it turned off for sometime

21:50 <mrkiko> rmilecki: the flash seems to work well in general, but with some hickups

21:51 <rmilecki> interesting

21:51 <rmilecki> could that be fauly device?

21:52 <rmilecki> mrkiko: or did you test more than 1 unit?

21:54 <mrkiko> rmilecki: I've seen this thing on 2 units; in the first case I solved the problem flashing stock firmware since I was giving the device away. In the second case the device did still boot and a sysupgrade fixed it. when I expressed this n IRc i met another user experiencing the same issue on a different ramips board but probably all of this means little to nothing. If grepping in your /rom didn't

21:54 <mrkiko> give you any squashfs error... then it's probably a genuine software issue

21:55 <rmilecki> uh

21:56 <rmilecki> would following command be a good test? grep -r . / > /dev/null

21:57 <mrkiko> rmilecki: yeah, I did limit it to rom at that time but that should be ok

21:57 <rmilecki> right, i meant /rom/

21:57 <rmilecki> i'll try that tomorrow

21:57 <rmilecki> right now i"m stress testing MT7603E

21:57 <mrkiko> rmilecki: out of curiosity - how do you stress test it?

21:58 <mrkiko> - I remember that times when I used it

21:58 <rmilecki> oh, just a client connected to it running iperf client to service behind R6220's WAN port

21:58 <mrkiko> :)

22:08 <rmilecki> it didn't took long, MT7603E support is still broken :/

22:10 <rmilecki> suffers from random stalls in wireless traffic

22:10 <rmilecki> [ 3] 910.0-915.0 sec 0.00 Bytes 0.00 bits/sec

23:00 <neocturne> schmars[m]: pushed the fix. Thanks for reporting!

23:00 <schmars[m]> nice, thanks :)