I upgraded, did the config-migration and everything works great as before.
Thanks a lot!
f.
1 Like
I upgraded too and it is working fine.
1 Like
happy to hear that guys...
as mentioned those with complex configs with fancy protocols or interface setups may run into problems..
the thing is... we are tracking master... and 21.x is also getting device-migration so we may as well bite the bullet (generally speaking) and help out with any potential issues...
we are a little privileged not to have DSA or complex wireless so it's a bit easier for us to isolate and test the general stuff... (sdcard based recovery options also allow us to take alot more risk)
thanks for being early adopters (taking risks) and providing feedback...
Updated to 3.2.13-2. No visible problems so far, but I had to manually enable Mosquitto and Adblock (they were enabled previously).
1 Like
are they in ENABLEDSERVICES in wrt.ini?
No, I've just enabled in Luci.
1 Like
quite possibly mosquitto was accidentally default enabled when it was added for a build or two... ( added it maybe two months ago? )...
adblock not too sure what might have went on there... thanks for the report 
actually... I almost/maybe had code that tried to re-instate automatically what services you had enabled last time... which I recently felt was a little dubious / not sure whether it was functioning right so may have disabled it's payload... in other words... it was working right for you if you never had adblock in enabledservices... good to know...
I'm happy (and lucky) that you added mosquitto to this build. Now I can use it instead of regular distros.
1 Like
Would it be possible to add kmod-rtc-ds1307 to support various RTCs on I2C? I have a DS3231 attached to my Rpi4 so it can act as an NTP server for my network after power outage even if external internet service is down.
sounds reasonable... mind sharing the runtime code/config for that?
I haven't got it working on OpenWRT (since neither snapshot nor your community builds include support yet 
), but with Raspbian, I was able to follow this process successfully:
1 Like
no worries... there are no kernel incompatibilities on this build... 
opkg install <package>
let us know if you nail down some specifics on the config (hint: it's less than three lines)
edit: seems that kmod is not available / bundled for this target... there are upm/high level packages only... so maybe more than three lines until support is added...
you can test/get(builtin support) in a buildroot by adding;
# CONFIG_RTC_CLASS is not set > CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_DS1307=y
CONFIG_RTC_I2C_AND_SPI=y
to target/linux/bcm27xx/bcm2711/config-5.4
to prevent kernel incompatibilites this build is created with the imagebuilder... which means i'm unable to perform the actions above
or use higher level utilities over i2c which is included by default...
as a final option for anyone good at C ... I have some basic support for microcontroller over usb-serial for vfd / rtc / relay / whatever... I suck at C tho' (actually that's an overstatement) so stopped development(at vfd)... for rtc... it's a bit of a pain because you have to provide the date string conversion and hwclock abstraction...
I'm new to building OpenWRT (but not at all new to configuring/building the Linux kernel) -- can you point me to something that explains this limitation?
(edited to reply since my Discourse account is too new to reply >3x)
Ah, ok, you're just passing through the snapshot kernel, not building a new one, so can't just add kmods.
good question...
put simply... kernel modules 'kmods' are tied to the kernel from the same compile run...
https://forum.openwrt.org/search?q=opkg%20kernel%20incompatible
- you compile your own OpenWrt you can't install official kmod packages
- you use snapshot ( which is rebuilt daily-ish ) you cannot install kmods tommorrow ( without installing the matching tommorrow kernel )
bingo
future of the build
guys... I don't want to be alarmist... but with 21.02 stable coming up... following a discussion... I wanted to get the ball rolling with a discussion about the future of the build...
some points...
get a wider community support (i.e. more people will be willing to contribute) if the build process is transparent and automated
reaching the point where the code is getting stale / needs rewriting in several places... and unsure of just how long or to what extent I can keep pushing on... likely outcome (without qualified help) is 2-3 months max and the build will need to be retired...
files structure has been coded to be portable across devices... ( you will see an experimental "ventoy_x64" community build in the devel folder )... [snip whinge about expecting help] if any decent coders jump onboard the "files" project we can likely switch to master ( buildroot ) and open the whole process up
The build has approx 25-30 (regular) users which has doubled over the last 5-6months... ( it's not my goal to make it famous... just worth it to see all the sweat for a reason )...
I would ask for general input... but surveys seem to work alot better... so let's see if I can whip something up...
- I like the build how it is... master based... opkg works...
- Switching to 21.02(ib) seems sensible... with or without github automated builds (leave comment)
- Switching to master buildroot and no opkg or limited repo/installable ipks is the way forward via github actions (leave comment)
- Open up the files and concentrate on portability across many devices via github actions (with either ib or buildroot > leave comment)
0
voters
note: "via github actions" could potentially be any automated framework... i.e. a single downloadable script + files... etc. etc.
2 Likes
I'm not sure which voting option expresses me, so I'll better write here.
The point of the community build, for me at least, was to have something stable and optimized. I am not using the wifi, but it was nice to have most of the applications already installed in the image. If it is a burden for you to maintain the build and the packages in your repository, I truly understand and the stable release will work fine for me, hopefully the openssl optimization too.
Elseif on the other hand you want to keep doing it for you primarily and share with the community, I'd be happy to continue using it and promise not to bust your balls too often 
3 Likes
I'm a newbie, and I do not intend to develop OpenWRT skills. I did not adopt this build initially, but have done it as soon as I thought it was stable. Compared with official builds it has three major advantages for me:
- It comes with preinstalled packages and with a very nice Luci UI
- It includes drivers for usb2ethernet adapters (great idea, I have internet access from the beggining without the need to rewire Pi and switch during upgrade)
- The SD card does not need repartitioning
Upgrading with wulfy23's build takes 5 minutes, with the official build it's almost 1h. I will glady pay a beer to thank all the effort.
Of course I understand if @anon50098793 does not continue the effort on this build.
2 Likes
gee guys... big head now... poll closed... made things very clear... i'm clear on the best direction to head in.... (combination of options that have selections)...
i think the biggest issues has been finding it difficult to switch off... and needing to stay on top of changes picking the 'better times' to create images... the system is setup... its mostly self managing at the moment...
i'll see about maybe committing to some sort of schedule ( once a month or something ) although i'm hopeless with 'order'... that should make some decent room(excuse) and reclaim alot more time and energy...
1 Like
You Da Man!
1 Like
Hey @anon50098793,
I'm the guy who posted this issue on your repo the other day. I didn't see the poll you posted yesterday, but my 2 cents are as follows:
- If you open up the files and concentrate on portability you can ensure that the project continues in the long run. You can also maintain different builds (e.g. continue support on the current version and also work on 21.02 if you like).
- I would encourage you to enable Sponsorships on your GitHub repo, so that all of us could 'buy you a beer' to help out
I'm sure that plenty of people, including myself would be happy to help out with development when we can . By documenting your roadmap for this project (via GitHub Project Boards) and maintaining your scripts on GitHub you will also enable future contributors to fork your repo and contribute via pull requests which you can review and approve if it fits.
Just a small suggestion - I have a feeling that more than ~25 people use your build of RPi 
it would be interesting if you could publish the build somewhere where you can pull metrics off downloads (maybe GitHub Releases or SourceForge).
4 Likes