Does the Image Repo for firmware versions not go back further?
I was interested in downgrading the Omega2+ to about the version in mid-2017, so I could replicate a project done at the time. There's too much changed with the Omega that it doesn't seem possible on the up-to-date version.
I took a look at the directory for versions, but couldn't find anything before late 2018. Are there any other locations with previous firmware images stored?
@Scruffy But why? I assume you mean you have an old project that no longer runs on the current firmware releases. Why not just address that rather than try to go back to old firmware versions and then struggle to port your app forward? I suspect that troubleshooting your current issue maybe a better solution. logread is your friend
@crispyoz I can try that, I suppose. And no, this is just just trying to get the old Bluetooth Speaker project from Vol 1 working. I have just been having zero luck with the Omega2+ computers, and I'm starting to run out of ideas on progression, since I don't want to keep posting each tedious question I have on the forums. It took me almost a week just to properly update the device, and it ended up not working to the point I tried just buying a new one, to no avail.
This is on top of working with RasPi, now SHARC DSP technology in CCES, and possibly Arduino. Out of them all, Omega is the one that just doesn't feel...consistent. It's the only one where one solved obstacle is replaced by one or two others without fail. Not even C/C++, the bane of my existence for coursework, has given me this much trouble.
@Scruffy welcome to the wonderful and frustrating world of making stuff. The community is here to help and once you get through the initial hurdles the haze will disappear and it will be plain sailing.
Omega is basically running Linux, the internet is swamped with people experiencing issues with Linux, not because Linux is particularly flawed, but because it was designed, like Unix was, to be flexible. Just as C is flexible and that leads to programmers getting into strife, but Pascal is not as flexible so programmers complain it is not flexible enough.
There honestly is no underlying issue or reliability problem with the Omega2 series, and the OS OpenWrt runs on millions of routers and other devices around the internet, so it's solid. But we are making and learning so we have to deal with the hurdles.
So let's refocus on your experiences and track down the underlying problem you are experiencing. As I recall you are having connectivity issues so please run these commands and post your results
uci show wireless
Brand and model of the router/access point you are connecting to.
Connectivity seems to be fine now. I remedied that one by the manual cmd approach. The current obstacle is figuring out how some of the commands from the original project have changed with the firmware updates, if at all.
@Scruffy Are any of the commands reporting an error? What specific issue are you experiencing?
The wireless connection is set up at this point. I was more referring to the bluetooth project from the 2017 project book (Vol. 1).
@Scruffy But my question remains the same.
Well, while I know I've already mentioned this on the other chat, it's the section on setting up the background 'pulseaudio', since commands are outdated on the device. I know that it may be excessive to think of downgrading to a "compatible" version, but I've been having little success finding alternatives or replacements for commands originally used like said 'udevd'.
@Scruffy I just looked at the doc and it does seem to be out of date. I personally do not use sound on any of my devices so I don't use pulse audio, however a took a quick look at the build system and the repos and it seems you should just be able to install pulseaudio-daemon-avahi to get a functioning daemon.
Edit /etc/opkg/disfeeds.conf and uncomment lines 2 and 5
opkg install pulseaudio-daemon-avahi
Restart your system. The daemon code relies upon the existence of some device files related to the sound device so this tells me the you will need to have the bluetooth and audio expansions connected so that the drivers will load and create the device files.
Others may have more experience with pulseaudio, I prefer quiet machines
@crispyoz Currently at the daemon installation. There seems to be several data file clashes with what's already on the device.
Files it wants to install: libavahi-common.so.3, libavahi-common.so.3.5.3, libavahi-core.so.7, libavahi-core.so.7.0.2. These are all under /usr/lib/.
It says these files are already provided in the package labelled 'libavahi-nodbus-support'. Is this one perhaps under one of the uncommented packages? I don't know whether one should go in and just delete them, or if the files necessary are already installed for progression.
@Scruffy just use the --force-overwrite option for opkg:
opkg --force-overwrite install pulseaudio-daemon-avahi
Part of building stuff is about breaking stuff, you focus on what you are trying to get running and once you're successful in that then you step back and look at the larger picture of what your final device firmware will look like. Worst case scenario is something stops running and you have to do a factory reset. Don't be shy to test the boundaries, I promise you that no software you install on your Omega will cause an atomic mushroom cloud
This post is deleted!
@crispyoz Okay. It needed to refresh the updates once before, but after that, it replaced the existing files without any trouble this time.
@Scruffy Always a good idea to run opkg update before doing any install or upgrade. opkg only knows about what it has indexed and it only updates its index when you update. It's a little rudimentary but that's how it works.
@crispyoz Proceeding from there, I was seeing if it could work with pulseaudio yet, though it fails to load or detect the module. Not sure if that was the correct process of events.
@Scruffy pulseaudio daemon expects to find the device files, if they don't exist it will fail.
If you run:
what is the output?
Since pulse audio is dependent upon the device files, and the device files are created by the device modules, this should inform the resolution
chown: /dev/mixer: No such file or directory
chown: /dev/dsp: No such file or directory
chmod: /dev/mixer: No such file or directory
chmod: /dev/dsp: No such file or directory
This followed opkg update. Could there still be crucial files missing, or commented packages that should be activated?
@Scruffy I wanted to chime in here on the repo question
The older firmware images can be found here: http://repo.onion.io/omega2/images/
This repository has all of the 0.1.x and 0.2.x firmware images (2018 and earlier).
The new repository is here: http://repo.onioniot.com/
We switched to that in early 2019 and it has all of the 0.3.x firmware images
You can use NCM to upgrade the firmware on many devices in one operation. Because security fixes are distributed as new firmware revisions, upgrading firmware helps network administrators correct security vulnerabilities.