00:56 <owrt-images-builds> Build [#186](https://buildbot.openwrt.org/images/#/builders/67/builds/186) of `main_armsr/armv7` failed: failed './scripts/feeds update' (failure)

01:38 <Rondom> superior6570: git cherry-pick -x <commit-id>

04:03 <mrnuke> hurricos: pong v2

04:06 <mrnuke> hurricos: I was asking if you'd be able to take a look at some realtek-poe PRs, and maybe merge the easy ones

04:07 <mrnuke> hurricos: the RYL8288B needs a bit of love so that I can get the descriptors from 'static' to 'static const', althoug I an curious if the hybrid dialect mapping approach makes sense to you

04:08 <mrnuke> of course, my message would make a lot more sense if I could spell "RTL8238B" properly :p

04:46 <owrt-images-builds> Build [#183](https://buildbot.openwrt.org/images/#/builders/192/builds/183) of `main_gemini/generic` failed: failed Images built and installed (failure)

04:56 <owrt-images-builds> Build [#181](https://buildbot.openwrt.org/images/#/builders/24/builds/181) of `main_mvebu/cortexa53` completed successfully.

06:47 <vics[m]> Did anyone think about adding gcc-15?

09:40 <owrt-images-builds> Build [#204](https://buildbot.openwrt.org/images/#/builders/4/builds/204) of `main_mpc85xx/p1010` failed: failed Target files uploaded (failure)

10:56 <owrt-images-builds> Build [#187](https://buildbot.openwrt.org/images/#/builders/67/builds/187) of `main_armsr/armv7` completed successfully.

11:34 <owrt-images-builds> Build [#185](https://buildbot.openwrt.org/images/#/builders/225/builds/185) of `main_mpc85xx/p2020` completed successfully.

11:39 <owrt-images-builds> Build [#205](https://buildbot.openwrt.org/images/#/builders/4/builds/205) of `main_mpc85xx/p1010` completed successfully.

13:45 <owrt-images-builds> Build [#120](https://buildbot.openwrt.org/images/#/builders/86/builds/120) of `openwrt-24.10_kirkwood/generic` failed: failed './scripts/feeds update' (failure)

15:34 <hurricos> mrnuke: believe it or not, it made sense on its own, because I have been away long enough to remember concepts but not strings like that lmao. Which pr #? My GH inbox is full

15:34 <hurricos> I am actually putting one PoE switch into lab prod again so testing is a quarter turn easier now

15:54 <schmars[m]> blocktrron: i made PRs for poemgr update: https://github.com/openwrt/packages/pull/26612 & https://github.com/openwrt/packages/pull/26613

16:02 <owrt-images-builds> Build [#122](https://buildbot.openwrt.org/images/#/builders/139/builds/122) of `openwrt-24.10_bcm27xx/bcm2709` completed successfully.

18:31 <Nick[m]> schmars: you have to make the PR against master and than backport it with cherry-pick -x

18:31 <schmars[m]> ah right, so first have it merged to master and then cherry-pick

18:40 <dansan> Hello. I'm booting an rk3568-based dev board from MYiR. I think it's pretty similar to the Rockchip RK3568 EVB. Anyway, it hgas a 16GiB mmc and I can't get first preinit / mount_root or whatever to use my /dev/mmcblk0p3 that I've formatted ext4, labled "rootfs_data", added to boot cmdline as "rootfs_data=PARTUUID=5452574f-03", etc.

18:42 <dansan> If I make my rootfs partition /dev/mmcblk0p2 large enough for a loop with f2fs then it will put my overlay in ram. If make the rootfs just a bit larger than the squashfs (500kib or so) then it will put the f2fs in that space, but then I have to manually specify the overlay and reboot before it takes affect

18:45 <dansan> I added https://bpa.st/6IAQ as my /etc/board.d/99_99-rootfs_data. I suppose I could just swap out the overlay there, but would rather do it right

18:46 <Nick[m]> schmars: exactly

18:48 <dansan> btw, this is the board https://www.myirtech.com/list.asp?id=769 I haven't submitted my board files just yet, still working on this kink

19:10 <tmn505> dansan: what are Your expectations of partition+filesystem layout? Because I think You're overcomplicating things.

19:24 <dansan> tmn505: Hello! Yes, I believe I am. I only want to use /dev/mmcblk0p1 as my overlay. I'm reading more about preinit and the preinit_mount_root hook and it looks like that's where i need to be

19:27 <dansan> I'm reading through the /lib/preinit scripts and it's starting to come together in my mind

19:28 <tmn505> most (if not all) devices in OpenWrt using block devices to boot have 1st partiion with kernel+dtb+bootscript and 2nd partition used as rootfs (might be with overlay - more common or raw ext4 without overlay). You trying to put overlay on 1st partition is unusual and will probably require a lot of hackery.

19:29 <dansan> oh no! I want it on the 3rd partition

19:30 <tmn505> So what will be 1st and 2nd partitions used for?

19:30 <dansan> Yes, I believe that's the layout, 1st partition is kernel + dbt and I presume also bootscript?

19:30 <dansan> second is a partition that contains squashfs

19:33 <dansan> Right now I've got a copy of gen_image_generic.sh that's slightlty modified, but will modify further once I get this simplified

19:34 <tmn505> I see Your missconception. You don't need the 3rd dedicated partition for overlay. OpenWrt on first boot splits 2nd partition.

19:35 <dansan> Right! And I was just about to say that the root problem is that that isn't happening when I leave a lot of room in the 2nd partition; I end up with tmpfs for an overlay. So probably addressing that bug is important

19:35 <dansan> And I was wrong earlier, it's ext4 and not f2fs

19:36 <tmn505> Do You have a git tree with Your code so I can look at it?

19:37 <tmn505> or a full patch

19:38 <dansan> It's a big git tree, but some of it I can't post... Let me finish feeding my face real fast and I'll update my openwert fork

19:39 <tmn505> look at this directory https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/ image with which suffix are You using?

19:59 <owrt-images-builds> Build [#123](https://buildbot.openwrt.org/images/#/builders/214/builds/123) of `openwrt-24.10_bmips/bcm63268` completed successfully.

20:10 <dansan> tmn505: sorry for the wait, I got it updated. I'll need to clean it up further before I'm ready to submit a real patch though: https://github.com/daniel-santos/openwrt/tree/myd-lr3568

20:11 <dansan> openwrt-24.10-snapshot-r28530+173-315943c616-rockchip-armv8-myir_myd-lr3568-squashfs-sysupgrade.img.gz

20:12 <dansan> Also, my company's product files aren't fully separated from the dev board. I'm prototyping it on the dev board (plus hardware), but I'm under time pressures so getting a bit messy

20:13 <dansan> now that I look at those commits, I have a lot of patches I need to submit

20:25 <tmn505> After looking at the commits very briefly You're not doing much out of the ordinary. So maybe there's really a bug with large squashfs+f2fs. BTW keep in mind that when rootfs is split on first boot the formating (with f2fs) of overlay may take long time. Anyway, to test with large ext4 overlay patch this file:

20:25 <tmn505> https://git.openwrt.org/?p=project/fstools.git;a=blob;f=libfstools/common.h;h=28b82d2aee519de72aefce78cf1e2839f78ce649;hb=HEAD#l22

20:26 <tmn505> line 22 defines if below 100MiB overlay is formated with ext4, above that, f2fs is used.

20:28 <tmn505> Also remember to use gen_image_squash_ext4.sh

20:28 <tmn505> sorry should be gen_image_generic.sh script

20:34 <dansan> ah hah! then perhaps I don't have f2fs driver. I'll check

20:36 <dansan> hrn, it's in my kernel

20:37 <dansan> ah but no f2fs programs. So it probably tried to make that and failed

20:38 <dansan> Thank you tmn505!! You've been very helpful!

20:39 <dansan> imo, if it fails to create an f2fs file system, it should have some fallbacks

20:40 <tmn505> YW. The mkf2fs are enabled by default on rockchip target maybe You've disabled it later in in Your .config. The fallback is creating overlay in tmpfs

20:40 <dansan> Probably so

20:41 <dansan> Oh yeah, what I was getting -- tempfs

20:41 <dansan> However, I think I might want to keep my overlay in a separate partition and leave p2 with room enough that I can flash upgrades to it and keep my existing overlay. Not 100% certain yet, but this thing has 16GiB of mmc

20:44 <tmn505> On most targets sysupgrade doesn't touch 3rd partition if partition layout/size of 1st and 2nd didn't change. So it can be used as storage without issues

20:45 <tmn505> I think rockchip also implements that, so test it out

20:47 <tmn505> Yeah, it does check platform_check_image in target/linux/rockchip/armv8/base-files/lib/upgrade/platform.sh

20:49 <dansan> cool, thanks!

22:09 <mrnuke> hurricos: https://github.com/Hurricos/realtek-poe/pull/49, https://github.com/Hurricos/realtek-poe/pull/46 (easy)

22:09 <mrnuke> hurricos: https://github.com/Hurricos/realtek-poe/pull/35 (not easy)

22:30 <dansan> hrm, can I pop a /bin/ash -l in a preinit script (maybe after 50) and get an interactive shell on the serial console?

23:07 <dansan> woo hoo! I got a preinit shell to poke around and explore! :)

23:08 <Habbie> yay!

23:10 <dansan> only I should have dumped the env first, because I can't see the state of the hooks, but that's ok. I ran run mount_root and try to figure out why it's not using my rootfs_data

23:11 <dansan> oh, too bad I didn't put a debug version on so I could debug it. I started working on an interactive boot framework a few years ago, but I got interruped by life