broke imagebuilder for 24 hours... (did not select firewall4)
nftables-json wants to install file build_dir/target-aarch64_cortex-a72_musl/root-bcm27xx/usr/lib/libnftables.so
But that file is already provided by package * nftables-nojson
>>>>>>>* opkg_install_cmd: Cannot install package luci.
* check_conflicts_for: The following packages conflict with firewall:
>>>>> * check_conflicts_for: firewall4 *
* opkg_install_cmd: Cannot install package firewall.
my understanding now is that was unintentional... so perhaps not cause for alarm just yet... guess i'm just a bit lost on what/when stuff is supposed to be... and how to toggle/validate it...
I always saw the firmware load error in the kernel log when using a RTL8153 dongle like the TPLink UE300, but since things work just fine, never paid much attention to it.
Seeing how things work at the moment, I wonder how much could the proper firmware affect how these dongles work/perform/behave.
cheers... yeah, came across it and seemed noteworthy (thanks for the heads up)
ok... so it might apply to our 8153, interesting... somehow in my mind was picturing the newer multigig chips to use these and the dude who reported issue with those dont have his full log...
just checked logs... no entries for me so maybe only rev3 or similar....
if any other build users wanted to see before the after
fgrep -r 'unable to load' /boot/plog/plogread-* | grep -v fstab
this was the line that stood out to me re: multigig
Add kmod-usb-net-cdc-ncm to support RTL8156A and RTL8156B 2.5G ethernet
which I didn't really understand, as that package already existed... maybe they ammended cool stuff to it or similar
big thanks @mj22226 for the PR, looks the business
8153upstream-message
r8152: support request_firmware for RTL8153
This patch supports loading additional firmware file through
request_firmware().
A firmware file may include a header followed by several blocks
which have different types of firmware. Currently, the supported
types are RTL_FW_END, RTL_FW_PLA, and RTL_FW_USB.
The firmware is used to fix some compatible or hardware issues. For
example, the device couldn't be found after rebooting several times.
The supported chips are
RTL_VER_04 (rtl8153a-2.fw)
RTL_VER_05 (rtl8153a-3.fw)
RTL_VER_06 (rtl8153a-4.fw)
RTL_VER_09 (rtl8153b-2.fw)
Signed-off-by: HWang
Reviewed-by: PMalani
Signed-off-by: David S. Miller
well, put it this way... I may not be putting anything new in 'stable'/'current' at anytime (all depends on how things progress with that firewall stuff discussed)
I mean I have a workaround for the broken imagebuilder right now... but time is limited... and i'm not really comfortable just pumping that out to 100 people... ( actually, it's probably time I enable ujail now ... so will probably do that soon also while stuff goes into 'testing' )
but this is all just speculation... no idea how things will progress... but anyone DEPENDING on something new in master ( i.e. driver for seeed studio cm4 carrier was just added big thanks to @chunkeey and @Pepe for making this a reality ) may get a shock / sick of wondering why no newer master builds anymore...
put simply...; if I put it in 'stable' IT IS OK... but 'stable' may not be updated for a long time... just a heads up
well for the heck of it i've uploaded;
fw3 r18523
fw4 r18523
size is comparable that's a bonus
############################# fw4
-rw-r--r-- 1 vert vert 77879506 Jan 9 14:27 rpi4.64-snapshot-27193-5.0.6-2-r18523-ext4-sys.img.gz
############################# fw3
-rw-r--r-- 1 vert vert 77824719 Jan 9 13:47 rpi4.64-snapshot-27191-3.5.350-3-r18523-ext4-sys.img.gz
update: master builds should still continue with fw3 as long as it is buildable without too much hassle / bug potential
(they will now include ujail tho'... while no issues arise)
tested fw4 and there were not many/any build specific problems with it, but we will be leaving the adoption of that to others for the forseeable future due to no banip/mwan and actual build creation overheads
(i will however leave a single one up for testing from time to time)
5.0.11_r18531 includes
so anyone with the 2.5 rtl or oddities with rtl8153 may notice changes in dmesg or better operation? (report back if anyone notices anything)
dmesg | grep -E '(rtl|ncm)'
before and after should show any changes maybe
(plus ujail plus seeeeeedstudio (cm4-carrier microchip) lan78xx support)
note: to any cm4 users... onboard emmc operation has not been tested... i.e. rootfsexpand so may be some issues there but OTOH it should work fine...
yeah... dfrobot and seeed are going to loose alot of revenue from this dry market
suspect by the time it picks up better options will arrive
the seeed is practically the same as a stand alone rpi4 ... you gain tidier ethernet ports and ability to upgrade the cm4 itself at the additional cost and luxury of having their own distro/fork available (which technically should work on most rpi anyway)
radxa taco has a price hit (and probably availability issues also) but offers quite a lot over a stand alone rpi4 from a networking perspective from the other three it's more 'flip a coin' depending on what you can get/small differences
dfrobot - small neat, best network performance(ish) - no usb3
rpi4 / seeed depends on what you like
radxa more future options
but I think by the time most people can buy these again reliably... rpi4 will have serious (better) competition
Mon Jan 10 19:16:33 2022 daemon.warn dnsmasq[1]: failed to create listening socket for fe80::f3:bc0c%pppoe-wan: Address not available
Mon Jan 10 19:16:33 2022 daemon.warn dnsmasq[1]: failed to create listening socket for fe80::f3:bc0c%pppoe-wan: Address not available
actually while we are on the topic of saved logs... I noticed mine are finally getting semi large...
du -chs /boot/plog/plogread-202* | tail -n1
86.9M total
anyone who wants to;
-speed up upgrades and
-does not feel they will need long term log retention and
-has been running the same build(base) for at 3-6months