Rpi4 < $(community_build)

i get:

pre-requisites-missing: coreutils-od
pre-requisites-missing: coreutils-od

while trying to update eeprom. So i guess you forgot the package :stuck_out_tongue:

1 Like

od is in the build... but i'm being 'non-community friendly' and sticking to the 'official' package check...

thanks for the notice tho'... turns out my installer... never actually attempted to 'install' at all...

all fixed in newer versions...

1 Like

speaking of official packages... as an fyi to all on this topic... 'bcm27xx-eeprom' is/has been available for a while... ( didn't actually know that )....

it is 97% functional... includes all the prerequisites(and firmware selection)... it's just a few minor 'full-distro' related scripting mods to make it actually work...

the features in the build are based on (and utilize) the above... so thanks to whoever setup that package...

verbage

the exceptions being that the build;
-adds ability(necessity) to manually 'fetch' from rpi-github based on release hash
-adds some fancy eeprom-config modding features (boot order etc.)
-adds some custom backup of flashed config and bin

rpi4_eeprom.sh update #calls rpi-eeprom-update -a
rpi4_eeprom.sh updaterecommended #mods bootorder for try usb first and some other mods

the native rpi command(s);

rpi-eeprom-update #and rpi-eeprom-config

should also work directly (after 'fetch') so feel free to also play with those as per any official(foundation) documentation...

here is a very crude 'patch' for someone (mainline users... build users should not install this package) who wants to use the official 'bcm27xx-eeprom' directly;

Summary
mkdir -p /etc/default
cat <<'TTT' > /etc/default/rpi-eeprom-update

FIRMWARE_ROOT=/lib/firmware/raspberrypi/bootloader
FIRMWARE_RELEASE_STATUS="stable"
FIRMWARE_IMAGE_DIR="${FIRMWARE_ROOT}/${FIRMWARE_RELEASE_STATUS}"
FIRMWARE_BACKUP_DIR="/var/lib/raspberrypi/backup"
BOOTFS=/boot
EEPROM_CONFIG_HOOK=
TTT

sed -i 's!\-f go+r!755!g' /usr/bin/rpi-eeprom-update

wow so nice thank you :innocent:

1 Like

Sorry, but I just have to say that your build is great. It has all the features I need (and propably 1000 more), is 100% stable (for me) and gets better with every update (update via luci, eeprom update,...).

I just want to say thank you very much for your great work!

f.

4 Likes

this is kinda interesting... and again... you are a bit of a pioneer because I've not tested config restorations at this level much... some points to re-iterate...

details-on-how-settings-come-about

when flashing via the luci firmware upgrade... you probably want;

AUTORESTOREAPPLY=1

enabled in /root/wrt.ini ( luci > startup > custom startup ) well on that old version it was in banip...

this enables -R option for sysupgrade so you keep any added packages...

not sure how sqm became enabled... as it's disabled in the buildroot...

Disabling sqm

what should govern this is 'ENABLEDSERVICES="sqm"' if you've added that...

otherwise it should be disabled... pretty sure somewhere in the process the ini file was not present during setup... or similar unusual condition... but no matter... seems most things went fairly ok... so i'm pretty pleased with the outcome...

thanks again for the testing and report...

1 Like

updated eeprom

rpi4_eeprom.sh update
BOOTLOADER: up to date
   CURRENT: Thu Apr 29 16:11:25 UTC 2021 (1619712685)
    LATEST: Thu Apr 29 16:11:25 UTC 2021 (1619712685)
   RELEASE: stable (/lib/firmware/raspberrypi/bootloader/stable)

     VL805: [bootloader-EEPROM] [up-to-date]
   CURRENT: 000138a1
    LATEST: 000138a1
1 Like

in principle... the chef image builder site should allow you to create official-ish iimages realatovy easily that include wireguard and your wan network driver...

This tool is very interesting, I appreciate you taking the time to show me this stuff... Will take a look and give a try sometime when the internet is not so crucial in the family.

what should govern this is 'ENABLEDSERVICES="sqm"' if you've added that...

Don't believe I've added this line, but when I am back at my router I can take a closer look at /root/wrt.ini and double check. More likely I think some bug happened where the ini file wasn't present during setup as you said.

thanks again for the testing and report...

Glad I am able to help with my limited knowledge!

1 Like

yeah... I also remembered there were a few workarounds I added when there was a problem with sqm starting on firstboot...

it's likely there is a bug in those... so thanks for the report... i'll try to nail it down the next time im in that area...

( or if it happens again... please try to run the command 'dmesg | grep -i sqm' whilst still in that state at firstboot )

the majority of build actions do log themselves so it's always with having a look at the log to see if there is a message about what was done

cheers!

1 Like

Thanks for all the hard work put into this - been enjoying stable internet since adding my pi to the net as main gateway, thanks to this build! Been lurking a while and getting my answers where I can, but lately I've been stumped with packages.

Specifically, since I've run into some stability issues with the latest community build on 21.02 I reverted to release firmware and added the necessary packages post-install, but for the LIFE of me I can't figure out which packages I need to enable the "devices" sub-menu in luci under network>interfaces (nested between the 'interfaces' tab and the 'global network options' tab). I'm trying to setup macvlan via luci, which I was able to do with the community build but despite installing a ton of luci-mod/luci-proto/luci-app packages still no luck getting the options available.

Thanks in advance for any insight! I really appreciate the work that's gone into getting all these features packed in and working :grinning_face_with_smiling_eyes:

edit for clarity: Moving to 21.02_rc1 from r16595

logout > login?

'proto' stuff may also need a restart of rpcd (or reboot)....

Yeah, I've rebooted & cleared cache/site data, etc. No luck. Even changed themes over to argon to see if that was the issue, but not that I could tell. I'm thinking I'm missing some basic kmod packages or something else obvious - I'm admittedly NOT a network expert in any way, just need a few advanced features to get a home business up and running on the cheap

on the upside...

running official means you can ask about it on the general forum... maybe it's a 21.02 bug or something...

most of the stuff that turns up in luci is not by my design... but a fluke of nature as a result of packages suggested by others...

'router' alias...

adding a 'router' alias in future builds... this means you can reach the router via addresses like;

http://router
http://dl.router
ping router

let me know there are any potential conflicts

2 Likes

@anon50098793
Hi
I am using dual wan (mwan3) config with 2x UE300.
One is plugged into the bottom USB 3 port (wan) and the other in the bottom USB 2 port (wanb).
When I reboot the RPi4, I lose internet connectivity after the reboot.
To rectify it, while the RPi4 is powered on I unplug both USB adapters and plug in the wan USB first, it connects automatically to the internet after a few seconds, then I plug in the wanb USB adapter and it also connects automatically to the internet after a few seconds.
Is there a way to fix it so that it can automatically connect after a reboot?

update: script now in build see here

original response

there is no easy way unless you an find a (logiclevel) 'usb3-relay' on alibaba or something...

(edit: a managed switch+vlans is probably the cleanest workable current reliable solution)

I used to provide a 000-nicmove hotplug script for this purpose, although it semi requires advanced skillas and/or a console connection

afaik (limited feedback) 3 people were unable to set it up properly so it has been taken down.

as stated previously on thread.... this should really be addressed at an os level...

the rpi4 is particularly 'random' when it comes to usb assignment... any advanced users facing this issue would also be advised to research / experiment with the various eeprom/config,txt msd or similar options and delays(or removal of)...

Ah okay, I see.
I am not willing to mess around with any other config files if it might complicate upgrading to future builds.
I placed an order for a TP-Link TL-SG108PE, I see it supports VLAN's and at least I will be able to power my UniFi U6-Lite from it also.
Thanks

1 Like

I probably should have got that model also...

got a gs308e this week... and while it's 'ok' for basic internal use... the security on it IMHO is not good enough for unsecure (wan) networks...

I still need a poe for the home... but can never pick one as they all seem to offer one thing and not another...

almost pulled the trigger on some ubiquiti units about 10 times this year... but always change my mind due to reliability concerns...

on the upside ( not that i'd want to really leave it enabled )... the gs-308e(and some other gs models) do have a basic python API... so i'm able to query the switch info from openwrt command line...

writing settings is broken tho... (at least on this model)... but in all honesty i'd probably want to disable the 'app-management' feature on these anyway...

USB assignment is always random, while it may be a trickier on OpenWrt you can usually use serial number to identify an induvidual adapter. Zyxel switches are nice and not that much more expensive fwiw

1 Like

When it comes to managed switches, you should really go for one supported by the realtek target. The stock firmware will be as good as any of the other shit out there, but you can simply replace it with OpenWrt. That's worth the small extra cost IMHO. Which is paying for better hardware (RAM, flash, CPU) anyway.

This means moving up a small step from the "Plus" to the "Smart" swithces in Netgear-speak. I.e. GS308T instead of GS308E. The GS308T support was added a week ago: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=c829bc1f2c3c47e230905864f2f5f8c759f88ce6

But take the usual care when buying hardware for OpenWrt: Model numbers are recycled by some vendors. For example the Netgear GS108Tv3 (which is the currently available variant) is supported, but the older v1/v2 were based on different hardware and will therefore never be.

Personally I like the ZyXEL GS1900 series. Most of these have presoldered UART headers as an extra bonus. I am using a GS1900-10HP which has a 77W PoE budget and two SFP ports. All working perfectly with OpenWrt. I would definitely recommend it, or the -8HP if you don't need fiber, for anyone looking for a small PoE switch.

I also have a GS108Tv3, which has the advantage that it can optionally be powered by PoE. But like other Netgear switches, this one requires soldering a header for console. It can be converted to OpenWrt without console access, though,

4 Likes