<enyc>
In lieu of a whole abstraction system for underpinning devicename finding, I really think the above should be put into 24.10 tree for 24.10.1 onwards to take onboard.
<f00b4r0>
enyc: saying you've tested that PR on the PR itself would probably help
mko has quit [Ping timeout: 480 seconds]
mko has joined #openwrt-devel
burlak has joined #openwrt-devel
n3ph_ has joined #openwrt-devel
n3ph has quit [Ping timeout: 480 seconds]
gromero has joined #openwrt-devel
n05oh3r42 has joined #openwrt-devel
<n05oh3r42>
hey there! just finished building OpenWRT v24.10.0.for bananpi-r3. Booted from sd card and package update shows than every package installed have update. How that can be if i useing fresh build. git log --oneline shows im on v24.10.0 tag ( 1fad1b4965 (HEAD, tag: v24.10.0) OpenWrt v24.10.0: adjust config defaults )
<n05oh3r42>
for example mod-rpc is 4 major releases old: luci-mod-rpc21.020.56896~af422b1 » 25.035.62793~4f7a183
<n05oh3r42>
or luci-mod-admin-full19.253.48496~3f93650 » 25.035.62793~4f7a183
<n05oh3r42>
even more old
<n05oh3r42>
why versions built with image so old?
<n05oh3r42>
i did './scripts/feeds update -a && ./scripts/feeds install -a' after git checkout
<n05oh3r42>
actually all init was like: git clone https://git.openwrt.org/openwrt/openwrt.git && cd openwrt && git pull && git checkout v24.10.0 && make distclean && ./scripts/feeds update -a && ./scripts/feeds install -a
<Habbie>
n05oh3r42, cd feeds/packages; git branch; git show
<Habbie>
i would -not- have expect master in a 24.10 build
<n05oh3r42>
Habbie, im a bit noob with git, where i made mistake? i thought git checkout v24.10.0 will limit everything to that tag.
<Habbie>
i think the feeds script is supposed to do it
<Habbie>
but i don't know for sure
<Ansuel>
let me test it
awgh_ has quit [Ping timeout: 480 seconds]
awgh has joined #openwrt-devel
<Ansuel>
indeed it's strange...
<Ansuel>
oh wait... i didn't change branch...
<n05oh3r42>
so i neet to ' git checkout openwrt-24.10 ' first and then ' git checkout v24.10.0-rc7 ' ?
<n05oh3r42>
need*
<Ansuel>
no
<n05oh3r42>
oops not rc7 but v24.10.0
<n05oh3r42>
Ansuel So, is it neccessary to specify branch with 'git checkout openwrt-24.10' first before 'git checkout v24.10.0'
<Ansuel>
no the thing is correct we are not sourcing out of master... 201fd099b80a2931b7326ce20b0cbb824296c99f is a commit in 24.10 branch so everything is working correctly for the clone and checkout part
<Ansuel>
i'm a bit confused how this is possible luci-mod-rpc 21.020.56896~af422b1 » 25.035.62793~4f7a183
<n05oh3r42>
FYI what shoys luci info string: Powered by LuCI openwrt-24.10 branch (25.014.55016~7046a1c)
<n05oh3r42>
Ansuel: well, as you may know mod-rpc is not enabled by default in menuconfig ( atr least for filogic\bananapi-r3 in stock config.build info) i enabled it in menuconfig manually, same way as some other packages i need. but i guess luci-mod-admin-full 19.253.48496~3f93650 » 25.035.62793~4f7a183 is builtin package and as you can see it even older
<n05oh3r42>
thats confusing me same way. moreover ithought every pkg will be up to date. but every shows update available
<russell-->
n05oh3r42: what are the hashes of your feeds?
<n05oh3r42>
FYI https://imgur.com/6c6BrJJ screen of packages ( skin installed manually, not prebuild)
<n05oh3r42>
russell: not sure how to check hashes of feeds/ how to do that
<n05oh3r42>
russell: 'cd feeds/packages; git branch; git show' is ' * 201fd099b80a2931b7326ce20b0cbb824296c99f master' if you talking about that
<russell-->
if you do a git branch -a in feeds/packages, you'll see there is an openwrt-24.10 branch
<russell-->
i don't build "releases", so this might be way off, but i'd expect you want to checkout openwrt-24.10 of the packages feed to build with the release branch of openwrt
<n05oh3r42>
russell: init was like: git clone https://git.openwrt.org/openwrt/openwrt.git && cd openwrt && git pull && git checkout v24.10.0 && make distclean && ./scripts/feeds update -a && ./scripts/feeds install -a
<n05oh3r42>
russell: where i made mistake? im a bit noob with git.
<russell-->
the feeds update was using a feeds.conf.default to define your feeds
<soxrok2212>
Ansuel: for this w1700k, do you have an idea why br-lan would not start until a radio turns on?
skynet2 has joined #openwrt-devel
<Ansuel>
honestly... it's a problem i'm trying to bisect but very little time to understand why... seems something is not getting detected on our netif scripts...
<soxrok2212>
oh so you've seen it too?
<soxrok2212>
i thought i was going crazy...
<soxrok2212>
if it helps, the lan interfaces are not starting automatically either
<russell-->
soxrok2212: are there ethernet interfaces in the br-lan bridge?
<soxrok2212>
yes
skynet2_ has joined #openwrt-devel
<soxrok2212>
its a "vanilla" config. lan1 and lan2 dont come up automatically, and br-lan doesnt start until a radio turns on, which is off by default
skynet2 has quit [Ping timeout: 480 seconds]
<Ansuel>
russell-- any idea if netifd requires anything? the network config is ok. The only strange thing is lack of ethtool status and no phylink but i don't think that is related...
<soxrok2212>
one thing i notice is it uses the generic phy driver
<n05oh3r42>
is there any legal way to override image size? because i need to include much more packages to image, but build fails because of image size too big...
<slh>
it's never a legaly problem, what is possible -and what not- depends on the device in question, usually there's little wiggle room
goliath has joined #openwrt-devel
<n05oh3r42>
slh: well, on bananpi-r3 there is 8 Gb EMMC
<n05oh3r42>
slh: i already increased rootfs size in menuconfig, but how to adjust bigger image size to build?
<n05oh3r42>
schmars: i already increaset it: Symbol: TARGET_ROOTFS_PARTSIZE [=4000]
<KanjiMonster>
n05oh3r42: TARGET_ROOTFS_PARTSIZE is only for machines that boot from a sdcard or similar (and images generated for those devices). If there is a image size too large error, it means that there is a hard limit to how large your image can be, and there is no way around it
<Habbie>
unless you replaced the actual flash chip
<n05oh3r42>
KanjiMonster: but i building sdcard image and banana-pi-r3 have EMMC 8Gb onboard ( even more - there is m2 nvme slot, buit no way to boot from it, only for storage)
<KanjiMonster>
that one should follow TARGET_ROOTFS_PARTSIZE
<n05oh3r42>
KanjiMonster: that config option does not help when i include a few more packages. MAx Image size i succesfully made is limited to about ~70-80 mb gzipped and ~100 mb after extraction. Few more packages produces "image too big" error.
<slh>
n05oh3r42: be aware that the full TARGET_ROOTFS_PARTSIZE is rewritten in a sysupgrade, if you go overboard with that, sysupgrade will take ages to complete. it's more sensible to use additional partitions for data or other things that need 'a lot' of space
<n05oh3r42>
Also i noticed that mold is not working in v24.10.0, same as dead code elimination. But it was fine in RC7... mold fails on lto-wrapper (have no idea why, because lto was not enabled in menuconfig, seems some custom package optimizaton...) Anyway DCE marked experimental, but mold...
n3ph has quit [Ping timeout: 480 seconds]
<n05oh3r42>
slh: So that strange image limit looks now even more strange for me. Because if i cant embed everything in one image, i need to install and upgrade manually later, and sysupgrade can make a more mess, even than dependencies update . VERY strange image size limit, especially when i have 8GB emmc on board.
n3ph has joined #openwrt-devel
minimal has joined #openwrt-devel
dmsza has joined #openwrt-devel
dmsza has quit []
<n05oh3r42>
slh: and TBH compiling anything on router is kind of PITA and waste of EMMC life source, even with f2fs and zram for swap. Bad idea even with bananpi-r3's nice CPU and big amount of RAM (as for router).
<KanjiMonster>
n05oh3r42: can you plaease pastebin the actual error you get (with context)? (with no -j)
<n05oh3r42>
KanjiMonster: you talking about "image too big"?
<KanjiMonster>
yes
<slh>
n05oh3r42: I have never suggested anything of that kind, OpenWrt is not self-hosting anyways and the runtime toolchain packages are very, very basic and barely support anything but compiling hello_world.c
<Habbie>
slh, i tried once, i had a bad time
<Habbie>
with enough free space, sticking debian into an lxc/docker/chroot might work (instead of trying to do it on openwrt) but it's rarely a good idea, indeed
<n05oh3r42>
slh: i have no idea how sysupgrade works, you said its rewriting all rootfs, so i decided it compiles something...
<Habbie>
it does not
<Habbie>
it requires an image already built
<slh>
n05oh3r42: sysupgrade does an in-place image upgrade, nothing else -no compiling involved- it just writes out the kernel/ rootfs and overlay partitions (with some smarts to retain configuration, if you want it to). it's the default image upgrade process on OpenWrt for all devices
<slh>
Habbie: I know that it's possible (if you do quite some weird stuff to get the missing -dev and toolchain packages copied over (I'm not going to call it 'installing')), but that's a different story - the chroot (or similar) approach would be more sensible - if the target is fast enough (CPU, RAM and storage I/O)
<Habbie>
yes
<Habbie>
certainly not recommending any of that
<slh>
maybe for filogic 880 or ipq9574
<Habbie>
and various pi
<Habbie>
and x86_64
<slh>
I really don't want to try that experiment on my x86_64 Atom j1900 ;)
<Habbie>
haha no
<Habbie>
i have a local x86_64 box (not running openwrt) that is capable enough for small experiments, but when i do openwrt stuff there, i grab a VM
<slh>
but it makes a pretty decent router ;)
<slh>
n100 should be a different story though
<Habbie>
yes
<enyc>
** just pointed out a weird OOM error in #openwrt
<enyc>
for 24.10.0
<enyc>
not sure if atypical
<enyc>
or somehow o debug or report
<enyc>
Alas, I get impression 24.10.0 is buggier than usual series release.
<minimal>
slh: isn't a J1900 a Celeron, not an Atom?
<Habbie>
correct
<Habbie>
not sure it matters a lot for this conversation
n3ph has quit [Ping timeout: 480 seconds]
<slh>
minimal: both is correct, it calles itself "Intel Celeron J1900", it is a baytrail-d Atom SOC
<minimal>
slh: confused now... (though as Habbie said not relevant to discussion)
<minimal>
slh: I have devices with both CPUs though I've never compared their performance
n3ph has joined #openwrt-devel
<slh>
the j1900 has an advantage of less power consumption (11 watts vs 15 watts) and (for this particular device) 4 e1000e networking ports (vs 2), that's why I use it. the j1900 maxes out at ~800 MBit/s sqm/cake (which is fine, I only need it to do half of that), the c1037u doesn't even clock up from its base frequency to do 1 GBit/s wirespeed