EdgeMAX EdgeRouter software version v2.0.0 has been released!

[fromport]

---

@jms33 wrote:

---

@maxried wrote:

What are the differences to the last beta version? Could you point me towards the changelog?

---

The SHA256 hashes are not the same as beta.3 so something must have changed! 

---

Just changing the version number from 2.0.0-beta3 -> 2.0.0 already changes the hashes

[jms33]

---

@fromport wrote:

---

@jms33 wrote:

---

@maxried wrote:

What are the differences to the last beta version? Could you point me towards the changelog?

---

The SHA256 hashes are not the same as beta.3 so something must have changed! 

---

Just changing the version number from 2.0.0-beta3 -> 2.0.0 already changes the hashes

---

Are you certain? I guess I am not, but the build version (minor version number?) has changed as well.  For example, the Cavium versions from beta.3 were 5151964, now they are 5155284.

[DeviceLocksmith]

2.0 is a much needed release. I am happy it is released even though there may be some remaining issues. No complex piece of software is ever bug-free. 1.x was running on pre-historic kernel and a Debian distribution that has been long out of support.

Now we could finally get up-to-date software without overriding a ton of dependencies manually. This newer Debian release is going to be receiving updates at least through June 2022. That means that we are more likely to receive timely quality vulnerability fixes from the upstream, without UBNT having to do any backporting, which may not be easy for older software.

No one forces you to upgrade to 2.x until the bugs are fixed. I almost never upgrade my production equipment to bleeding edge releases of code, unless I have good enough reasons for it. 

[DeviceLocksmith]

For those that need upstream Debian packages, below are the commands to configure APT.

Remove backports if you don't need them.

Spoiler

set system package repository stretch components 'main contrib'
set system package repository stretch distribution stretch
set system package repository stretch password ''
set system package repository stretch url 'http://http.us.debian.org/debian'
set system package repository stretch username ''
set system package repository stretch-backports components 'main contrib'
set system package repository stretch-backports distribution stretch-backports
set system package repository stretch-backports password ''
set system package repository stretch-backports url 'http://deb.debian.org/debian'
set system package repository stretch-backports username ''
set system package repository stretch-security components 'main contrib'
set system package repository stretch-security distribution stretch/updates
set system package repository stretch-security password ''
set system package repository stretch-security url 'http://deb.debian.org/debian-security/'
set system package repository stretch-security username ''
set system package repository stretch-updates components 'main contrib'
set system package repository stretch-updates distribution stretch-updates
set system package repository stretch-updates password ''
set system package repository stretch-updates url 'http://deb.debian.org/debian'
set system package repository stretch-updates username ''

[Rotary_Convert]

I too was a bit surprised by this release.  I've watched this go from alpha to beta and now stable.

It's great to see the Debian upgrade, the new features (love the hardware offloading for bonded interfaces) but I'm in the not-running-this-in-production crowd for the foreseeable future.  Maybe after hotfix 1 ...

James

[legacy0]

This new release broke my real dmz setup please fix rolling back to 1.10.8.

https://community.ubnt.com/t5/EdgeMAX-Stories/How-to-real-DMZ-with-NAT-with-one-IP/cns-p/1525933

[ricktendo]

Upgrade seems fine on my ER4, not sure if I should worry about these errors in my serial log (let me know if you want me to provide the full log)

OF: fdt:not creating '/sys/firmware/fdt': CRC check failed

This architecture does not have kernel memory protection.

ubnt_platform: loading out-of-tree module taints kernel.
ubnt_platform: module license 'Proprietary' taints kernel.
Disabling lock debugging due to kernel taint

dwc3 1680000000000.xhci: Configuration mismatch. dr_mode forced to host
dwc3 1690000000000.xhci: Configuration mismatch. dr_mode forced to host

[Sammutd88]

Have installed on ER X SFP. Offloading off, will see if it solves the rebooting issue in the beta. Still no individual port throughput stats in GUI and UNMS. Can’t believe this has been released as a stable just yet. 

[GatorHat]

Moving forward, will there be updates/maintenance releases for v1.x.x?

Or is v1.10.8 the last of the v1 series?

Just trying to plan for the future, thanks!

[DeviceLocksmith]

---

@ricktendo wrote:

Upgrade seems fine on my ER4, not sure if I should worry about these errors in my serial log (let me know if you want me to provide the full log)

This architecture does not have kernel memory protection.

ubnt_platform: loading out-of-tree module taints kernel.
ubnt_platform: module license 'Proprietary' taints kernel.
Disabling lock debugging due to kernel taint

This is normal. MIPS linux kernel does not offer memory protection and closed source firmware always taints kernel.

[Sammutd88]

---

@GatorHat wrote:

Moving forward, will there be updates/maintenance releases for v1.x.x?

Or is v1.10.8 the last of the v1 series?

Just trying to plan for the future, thanks!

---

I daresay 1.10.8 is the last v1. 

[Lanna]

I decided to test this on one of my many ER-X devices. It came back up (connected devices are contactable) but the ER-X itself now has no GUI or SSH access. It's doesn't even answer pings. Tried a power cycle by resetting the upstream port PoE, but still no go.

[DeviceLocksmith]

If factory reset does not work, you may be able to recover with serial console
https://community.ubnt.com/t5/EdgeRouter/How-to-connect-ER-X-serial-console/m-p/2607963#M233420

[Lanna]

OK thanks. When I can get physical access to the device I'll of course be trying a reset. Clearly this 'stable' release is not, NOT fit to be named as stable. I advise anyone against using this in a production environment.

I've come to expect dodgy release practices in other UBNT departments but I'm really surprised to see it in the EdgeMAX offices. I'm a beta tester and I don't mind testing new software when I have time, but when something is labelled 'stable' I darn well expect it to be. 'Carrier Grade' hardware needs carrier grade firmware. Do you get it?

[RobbieTT]

I didn't think anyone over on the beta side thought this was stable and, as stated previously, quite a few of us were stunned to see this out in the wild.  I still have it on my test router but not on my active router and I am not minded to change given the issues.

[DeviceLocksmith]

I am a Cisco consultant and Cisco bugs is one of the most important things that pays my bills. If Cisco "carrier grade" software was bug free, I would be out of business. As a general rule, if it is not broken, don't fix it. There is no reason to upgrade to the latest firmware, unless you know that it fixes an issue you are having, provides new functionality that you need, or fixes a vulnerability that affects your environment. When you have manufacturer support, another good reason to upgrade is when your version goes out of support, but that does not apply to UBNT.

[bgh]

failed! ERL upgrading from beta 3.

gui reports upload failed, not enough space.

root@gate:/tmp# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/root              1649416     86848   1477116   6% /root.dev
overlay                1649416     86848   1477116   6% /
devtmpfs                245636         0    245636   0% /dev
tmpfs                   245768         0    245768   0% /dev/shm
tmpfs                   245768     24996    220772  10% /run
tmpfs                     5120         0      5120   0% /run/lock
tmpfs                   245768         0    245768   0% /sys/fs/cgroup
tmpfs                   245768         0    245768   0% /run/shm
tmpfs                   245768         0    245768   0% /lib/init/rw
tmpfs                   245768     86212    159556  35% /tmp
tmpfs                   245768       592    245176   0% /var/log
none                    245768      8908    236860   4% /opt/vyatta/config
overlay                 245768     86212    159556  35% /opt/vyatta/config/tmp/new_config_16197
overlay                 245768     86212    159556  35% /opt/vyatta/config/tmp/new_config_17187
overlay                 245768     86212    159556  35% /opt/vyatta/config/tmp/new_config_c869099532db402587e782bb20387d37
tmpfs                    49152         0     49152   0% /run/user/1000
overlay                 245768     86212    159556  35% /opt/vyatta/config/tmp/new_config_24352a9267a048469bbe5c7164357d9b
root@gate:/tmp#

[Lanna]

Meh, there are bugs and there are blocker bugs.

[DeviceLocksmith]

Have you tried rolling back to 1.x and upgrading again?

[BuckeyeNet]

Did you read what was posted?  How could that possibly be done?

"I decided to test this on one of my many ER-X devices. It came back up (connected devices are contactable) but the ER-X itself now has no GUI or SSH access. It's doesn't even answer pings. Tried a power cycle by resetting the upstream port PoE, but still no go."

This release reminds me of Win 10 1809.   edit:  At least Ubiquiti doesn't force you to update.

But I definitely wouldn't recommend this update to people that

1. Don't have a backup of their config
2. Don't have a spare of the same type with the existing config loaded
3. Are not physically present at the location of the device to be upgraded
4. Don't have a console connected to the device when the router is updated.

It seems at this time, the ability to connect to a serial console is almost a requirement. (with either a "rollover" console cable for routers with externally accessible console ports, or a ubs to ttl (3.3v) adapter for routers (like ERX) with console header pins)