09:20 <russell--> there are two kernel partitions on a ubiquiti erx, for a total of 6MiB, but we are limited to using one and v6.6 is apparently too big to fit.

14:13 <mrkiko> robimarko: and I was wondering how the offset was calculated, and how I may be able to mount the loop space on a image taken directly from mmbclkX. I cobbled togeter this https://paste.debian.net/1317147/

14:14 <mrkiko> robimarko: the code was taken more or less directly from fstools which calculates that offset

14:15 <robimarko> mrkiko: Thanks for that, I figured out my issue yesteday

14:15 <mrkiko> robimarko: saying this to you just in case you might find it useful

14:15 <robimarko> Luckily it was not an fstools issue but using MMC with rootdisk creating an overlay exposed it

14:15 <robimarko> Thanks anyway as this stuff is not so straightforward with all of the possible combinations

14:20 <mrkiko> robimarko: well, my code covers just the case I met, "plain" case I suppose. However it can save som time :)

14:56 <rsalvaterra> nbd: Quick question, is it normal for cake to bin packets differently, when they have the same dscp value?

14:58 <rsalvaterra> I done some testing with tcpdump. I'm seeing tcp packets in tin 0 and udp packets in tin 2, when both have tos 0x4 (with qosify, diffserv8).

16:37 <rsalvaterra> nbd: It seems that commenting the "option dscp_default_udp besteffort" defaults line in /etc/config/qosify fixed the issue. Is it possible that qosify is applying the best effort dscp code to udp packets which already have a dscp code != 0?

17:43 <stintel> anyone working on BPI-F3 (RISC-V) support by chance?

17:44 <rsalvaterra> Didn't even know it existed. Cute…!

18:14 <owrt-images-builds> Build [#74](https://buildbot.openwrt.org/images/#/builders/143/builds/74) of `openwrt-23.05_x86/geode` completed successfully.

18:23 <robimarko> mrkiko: Yes, it saves time as even finding it takes a while