Posts made by Florian Heigl

@Zendog said in Help with bricked Omega 2+:

@Lazar-Demin thanks! I thought as much. Many thanks for looking into this either way.

Luckily, I was a KS backer of the Onion Omega 2+ and got a bundle of 8 of them off the back of enjoying having bought 2 of the first Omegas to be released. 1 down, 7 to go...

So, as a parting shot, can you please point me in the right direction?

I plan to upgrade all the others and hopefully not run into the same issues.

Should my upgrade process for each be:

• Upgrade uboot image first with the latest version, then
• Upgrade the firmware Omega .bin file with the latest version

... Then reboot. That's the right thing to do to get it to the latest version, right?

Do both of the above points in one go or reboot after uboot is update?

for the record/clarity, you can sysupgrade into the new image from an old Omega2 firmware.

I tried today, using the 'beta firmware' instructions via archive.org (couldn't find any working link otherwise)

https://web.archive.org/web/20250213213028/https://documentation.onioniot.com/firmware/installing-firmware/

used that with the latest 23.05 image from the repo

http://repo.onioniot.com/omega2/images/openwrt-23.05/
(no https is available)

So I've turned my Omega2+ back on, and looked for updates.
oupdate says i'm on the latest available (o160)

opkg --list-upgradeable shows a lot

we have had a few high-risk linux/wifi security issues since start of the year, yet if I look at when b160 come out and what I can find at http://repo.onion.io/omega2/images/ it seems like no activity has been triggered by this.

I can see from the image list that the project has been inactive since march. Without any doubt.
Are there any recommended workarounds?
Any "best" opkg package lists one should use instead of the factory ones?
Has there been any news if / when new images are going to be released?

Thank you for sharing your experiences...

I can't find the Onion-specific builds any more. Anyone else get this?:

root@Omega-ECFB:~# opkg update
Downloading http://downloads.lede-project.org/releases/17.01-SNAPSHOT/targets/ramips/mt7688/packages/Packages.gz
Updated list of available packages in /var/opkg-lists/reboot_core
Downloading http://downloads.lede-project.org/releases/17.01-SNAPSHOT/targets/ramips/mt7688/packages/Packages.sig
Signature check passed.
[...]
Downloading http://downloads.lede-project.org/releases/17.01-SNAPSHOT/packages/mipsel_24kc/onion/Packages.gz
*** Failed to download the package list from http://downloads.lede-project.org/releases/17.01-SNAPSHOT/packages/mipsel_24kc/onion/Packages.gz

Collected errors:
 * opkg_download: Failed to download http://downloads.lede-project.org/releases/17.01-SNAPSHOT/packages/mipsel_24kc/onion/Packages.gz, wget returned 8.

My distfeeds.conf looks like this:

root@Omega-ECFB:~# cat /etc/opkg/distfeeds.conf
src/gz reboot_core http://downloads.lede-project.org/releases/17.01-SNAPSHOT/targets/ramips/mt7688/packages
src/gz reboot_base http://downloads.lede-project.org/releases/17.01-SNAPSHOT/packages/mipsel_24kc/base
#src/gz reboot_onion http://downloads.lede-project.org/releases/17.01-SNAPSHOT/packages/mipsel_24kc/onion
# src/gz reboot_luci http://downloads.lede-project.org/releases/17.01-SNAPSHOT/packages/mipsel_24kc/luci
# src/gz reboot_packages http://downloads.lede-project.org/releases/17.01-SNAPSHOT/packages/mipsel_24kc/packages
# src/gz reboot_routing http://downloads.lede-project.org/releases/17.01-SNAPSHOT/packages/mipsel_24kc/routing
# src/gz reboot_telephony http://downloads.lede-project.org/releases/17.01-SNAPSHOT/packages/mipsel_24kc/telephony

I agree, I had already typed my reply and then deleted the draft.
Douglas, you just didn't carefully read what he wrote
I could see along the lines that he'd referred to the conclusions / breaking point of existing threads on this. Besides, the question was if there is any PLAN NOW to get things sorted, which is independent of any prior unanswered (and also different) threads.
Plus, not continuing to ask is the one way that can't have an effect.

I sense the guys have been quite busy considering they already got a 300+page book written, and I also can see on here that the Onion team is recovering or busy on something since 4weeks+.

In any case, like he wrote, it's a deprecated standard. It should be resolved, and likely can, and likely will. Knowing if it someone has set aside some time for this in, say August, or during Winter time, would allow for a rough plan and mean people can decide what they can build based on the hardware, and what not.

I'm not sure where I should put this.
Anyway, I wanted to suggest for the Powerdock to use a charger circuit that works for LiFePo batteries.
There are some can be selectively set/soldered to work for either LiPo or LiFePo.
The former are the ones that you are to never charge unattended, discharge unattended or store anywhere near something flammable.
The latter (LiFePo) are considered a lot safer and less likely to start burning.

I would love to attach a battery, but even if you buy a "good" one it's still a lot riskier to use LiPo batteries. And of course I'd like to use it as a tiny UPS and put the Omega somewhere where I'm not around all day.

What to do? Build an iron or ceramic casing? Use a safer type of battery?
Honestly, I like the second idea. they cost like very little more than the less safe ones, so this would be OK.

I've seen that they're also easier to charge and that cheap charger circuits for like $3 are perfectly able to switch between the two types.

I'm not sure if the electronics on the PowerDock couldbe modified, but I wanna suggest it as at least a long-term improvement.

My only Beowulf was on Pentium1 boards, so this might be almost faster now

(but no I'll pass, hehe)

Hi,

I got my Omega2+ last week and am still learning some basics.
One issue I got is this:

Card is plugged in but not visible after reboot

 root@Omega-ECFB:~# df
 Filesystem           1K-blocks      Used Available Use% Mounted on
 /dev/root                 5632      5632         0 100% /rom
 tmpfs                    62872       696     62176   1% /tmp
 /dev/mtdblock6           25664      2876     22788  11% /overlay
 overlayfs:/overlay       25664      2876     22788  11% /
 tmpfs                      512         0       512   0% /dev

Remove the card, plug back in:

 root@Omega-ECFB:~# df
 Filesystem           1K-blocks      Used Available Use% Mounted on
 /dev/root                 5632      5632         0 100% /rom
 tmpfs                    62872       696     62176   1% /tmp
 /dev/mtdblock6           25664      2876     22788  11% /overlay
 overlayfs:/overlay       25664      2876     22788  11% /
 tmpfs                      512         0       512   0% /dev
 /dev/mmcblk0p1         1863088      5664   1744736   0% /tmp/run/mountd/mmcblk0p1

Basically I'll always have the card there, so it'd be OK if I can just turn off the "mountd" thing and use fstab? or udev (already remembered that OpenWRT isn't exactly a udev thing)
I suppose anything I do there will be lost on a firmware update?

Not sure how this works.
Does anyone know how to always "see" the SD card on a poweron or boot?
I've formatted it as plain ext4.

And I've also read this:
https://community.onion.io/topic/1282/omega2-reboot-and-sd-card-fixed/30

But I think that was about general reboot issues and not mounting the card at all.

Both works and I'm on the right fw version I think:

root@Omega-ECFB:~# oupgrade -l
> Device Firmware Version: 0.1.10 b160
> Checking latest version online...
> Repo Firmware Version: 0.1.10 b163
> Comparing version numbers
> New build of current firmware available, upgrade is optional, rerun with '-force' option to upgrade

From what I understood b163 is a no-go for the 2+ and it'll also just not install it if I try. Please correct me if I got that one wrong.

Performance shouldn't be too worrysome - assuming the Onion is the endpoint - it's CPU/IO limited in itself, so the VPN overhead will surely make it worse, but I'd imagine it's like dropping from 200KB/s to 100KB/s. A large overhead, but if we're honest, it's something you can adapt to.