UDMPRO SE

[jlauzer11]

Describe the bug

Hi just received the UDMPRO SE. I'm not able to get this package to install on it. Wondering if anyone has any ideas? When I SSH into the UDM there is no "unifi-os shell" anymore. Here's what happens when I try to install:

To Reproduce

`root@UDM-PRO:~# curl -L https://udm-boot.boostchicken.dev -o udm-boot_1.0.5_all.deb % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 100 3364 100 3364 0 0 5857 0 --:--:-- --:--:-- --:--:-- 5857

root@UDM-PRO:~# dpkg -i udm-boot_1.0.5_all.deb

(Reading database ... 71403 files and directories currently installed.) Preparing to unpack udm-boot_1.0.5_all.deb ... /var/lib/dpkg/tmp.ci/preinst: 19: /var/lib/dpkg/tmp.ci/preinst: /sbin/ssh-proxy: not found dpkg: error processing archive udm-boot_1.0.5_all.deb (--install): subprocess new pre-installation script returned error exit status 127 /var/lib/dpkg/tmp.ci/postrm: 24: /var/lib/dpkg/tmp.ci/postrm: /sbin/ssh-proxy: not found dpkg: error while cleaning up: subprocess new post-removal script returned error exit status 127 Errors were encountered while processing: udm-boot_1.0.5_all.deb

root@UDM-PRO:~# `

UDM Information

• Variant: UDMPRO SE
• Firmware Version: 2.2.4
• Controller Version: 6.3.51

Additional context

If there's anything else I can send you please let me know. I know the SE just starting hitting people this week!

[MichaelisForMe]

The UDMP SE boots into UnifiOS and moves away from ubios. It’s firmware is 2.x branch which would indicate the UDM and UDMP will be moving to this branch. I am also in the same boat as @jlauzer11

[fabianishere]

@MichaelisForMe Does this mean you login directly into UniFi OS when SSH into the device? If the root filesystem is now persistent, you could try to create a systemd unit yourself (like the on-boot script does) to run your scripts, assuming of course that systemd is still installed on this new firmware 😅

[peacey]

Hi all,

I've had the pleasure of using a friend's UDMP SE, and it seems most of the system is persistent on reboot, including systemd units and custom dpkg/apt packages that are installed. I was able to create various systemd service files to run things and enable them on startup, including wpasupplicant or wireguard, or whatever else. So basically we can just use it as a normal Debian system and we don't need any custom boot script package anymore. Multiple reboots confirmed everything is working on boot.

The only question now is whether the new systemd service files will remain even after a firmware update, not just a reboot. This hasn't been tested yet as there isn't any new firmware available yet. If the new files are removed on firmware update, we will have to find a solution. Otherwise, it seems to be working perfectly fine with just systemd service files for your scripts to start them on boot.

If, instead of multiple service files for each of your startup scripts, you prefer to use this on_boot script's way of doing things (as in startup scripts in /mnt/data/on_boot.d), then you can create a systemd service file for the on_boot service by creating a file under /etc/systemd/system/udm-boot.service with the following:

[Unit]
Description=Run On Startup UDM
Wants=network-online.target
After=network-online.target

[Service]
Type=forking
ExecStart=bash -c 'mkdir -p /mnt/data/on_boot.d && find -L /mnt/data/on_boot.d -mindepth 1 -maxdepth 1 -type f -print0 | sort -z | xargs -0 -r -n 1 -- bash -c \'if test -x "$0"; then echo "%n: running $0"; "$0"; else case "$0" in *.sh) echo "%n: sourcing $0"; . "$0";; *) echo "%n: ignoring $0";; esac; fi\''

[Install]
WantedBy=multi-user.target

Afterwards run,

systemctl daemon-reload
systemctl enable udm-boot
systemctl start udm-boot

If it worked you should see a new directory called on_boot.d created under /mnt/data. Start by adding a basic script to run at startup to the /mnt/data/on_boot.d/ folder. Make sure to give it the #!/bin/bash shebang, a .sh extension, and chmod +x it, then run the udm-boot service again with systemctl start udm-boot. Your startup script should have run now, so check whatever it was supposed to do happened. It makes it easier if your test script is just echoing to some file (e.g.: echo hi >> /mnt/data/test) so you can easily check if the file was created with right contents.

If everything is working, restart the SE and check that your script ran on boot as well. If it worked, add your startup scripts and run them. Make sure there weren't any issues running your scripts because of bash/sh incompatibilities. You might have to tweak some scripts a little for bash syntax.

Some notes:

This service file is the same as the on_boot service file in this repo, but with these changes:

• Removed ssh-proxy
• Replaced sh with bash. This is because the SE comes with bash pre-installed, and the sh binary on the SE is actually dash instead of the busybox sh like in the UDMP. This might cause incompatibilities in some scripts if you used dash instead of bash.
• Changed Type to forking instead of oneshot so that you can run things in the background. Type=oneshot would actually kill long-running processes that get started by the startup scripts.

[TheJulianJES]

You can try to "upgrade" to the same firmware version using the command and URL (posted in the UI community forums).

Command: ubnt-systool fwupdate firmware_url

The firmware_url is in this post at the bottom:

Community post: https://community.ui.com/releases/UniFi-OS-Dream-Machine-Pro-SE-2-2-4/e20af77c-075a-4c49-a41d-eac404d00560

[peacey]

Thanks @TheJulianJES. I actually thought about that but had some doubts it would be an accurate test because I was worried the upgrade would go differently if it was a different version.

Nevertheless, I tried it to upgrade the firmware to the same version, and good news! The systemd service files were still there and enabled, and they ran on boot after the "upgrade". Custom apt/dpkg packages that I installed were not still installed however, so the upgrade seems to wipe the new dpkg packages. That's not so much of a problem though, because the systemd service files were still there and ran, so you can just install anything extra on boot if it doesn't exist (for example with ExecStartPre in the service unit itself).

So, a pretty good indicator! We'll have to see if this result holds up when we're upgrading to a different version.

[lehighkid]

Hi all,

I've had the pleasure of using a friend's UDMP SE, and it seems most of the system is persistent on reboot, including systemd units and custom dpkg/apt packages that are installed. I was able to create various systemd service files to run things and enable them on startup, including wpasupplicant or wireguard, or whatever else. So basically we can just use it as a normal Debian system and we don't need any custom boot script package anymore. Multiple reboots confirmed everything is working on boot.

The only question now is whether the new systemd service files will remain even after a firmware update, not just a reboot. This hasn't been tested yet as there isn't any new firmware available yet. If the new files are removed on firmware update, we will have to find a solution. Otherwise, it seems to be working perfectly fine with just systemd service files for your scripts to start them on boot.

If, instead of multiple service files for each of your startup scripts, you prefer to use this on_boot script's way of doing things (as in startup scripts in /mnt/data/on_boot.d), then you can create a systemd service file for the on_boot service by creating a file under /etc/systemd/system/udm-boot.service with the following:

[Unit]
Description=Run On Startup UDM
Wants=network-online.target
After=network-online.target

[Service]
Type=forking
ExecStart=bash -c 'mkdir -p /mnt/data/on_boot.d && find -L /mnt/data/on_boot.d -mindepth 1 -maxdepth 1 -type f -print0 | sort -z | xargs -0 -r -n 1 -- bash -c \'if test -x "$0"; then echo "%n: running $0"; "$0"; else case "$0" in *.sh) echo "%n: sourcing $0"; . "$0";; *) echo "%n: ignoring $0";; esac; fi\''

[Install]
WantedBy=multi-user.target

Afterwards run,

systemctl daemon-reload
systemctl enable udm-boot
systemctl start udm-boot

If it worked you should see a new directory called on_boot.d created under /mnt/data. Start by adding a basic script to run at startup to the /mnt/data/on_boot.d/ folder. Make sure to give it the #!/bin/bash shebang, a .sh extension, and chmod +x it, then run the udm-boot service again with systemctl start udm-boot. Your startup script should have run now, so check whatever it was supposed to do happened. It makes it easier if your test script is just echoing to some file (e.g.: echo hi >> /mnt/data/test) so you can easily check if the file was created with right contents.

If everything is working, restart the SE and check that your script ran on boot as well. If it worked, add your startup scripts and run them. Make sure there weren't any issues running your scripts because of bash/sh incompatibilities. You might have to tweak some scripts a little for bash syntax.

Some notes:

This service file is the same as the on_boot service file in this repo, but with these changes:

• Removed ssh-proxy
• Replaced sh with bash. This is because the SE comes with bash pre-installed, and the sh binary on the SE is actually dash instead of the busybox sh like in the UDMP. This might cause incompatibilities in some scripts if you used dash instead of bash.
• Changed Type to forking instead of oneshot so that you can run things in the background. Type=oneshot would actually kill long-running processes that get started by the startup scripts.

I was able to successfully follow this process w/ success; however, I am running into issues setting anything else up because I cannot find the Podman executable.

root@UDM-Pro-SE:/mnt/data/on_boot.d# ls -al
total 20
drwxr-xr-x 2 root root 4096 Jul 28 15:46 ./
drwxr-xr-x 8 root root 4096 Jul 28 16:36 ../
-rwxr-xr-x 1 root root 4780 Jul 28 13:19 05-install-cni-plugins.sh*
-rwxr-xr-x 1 root root 3658 Jul 28 13:24 10-dns.sh*
root@UDM-Pro-SE:/mnt/data/on_boot.d# ./05-install-cni-plugins.sh
Pouring /mnt/data/.cache/cni-plugins/cni-plugins-linux-arm64-v0.9.1.tgz
root@UDM-Pro-SE:/mnt/data/on_boot.d# ./10-dns.sh
RTNETLINK answers: File exists
RTNETLINK answers: File exists
RTNETLINK answers: File exists
./10-dns.sh: 70: ./10-dns.sh: podman: not found
<11>Jul 28 16:37:14 podman-dns: Container pihole not found, make sure you set the proper name, you can ignore this error if it is your first time setting it up
root@UDM-Pro-SE:/mnt/data/on_boot.d# 

What am I missing?

EDIT:

I was able to install podman from here: https://github.com/risdenk/udm-podman/releases/tag/v0.1-alpha

[peacey]

@lehighkid, there is no podman on the SE. I was only referring to starting things on boot, not using podman. The stuff I started on boot did not require podman, so I never installed podman.

If you need podman, you will need to install it separately. You can try to install it via apt by adding the testing repository to apt, or installing the dpkg manually with all the dependencies. You will also need to configure podman to use the correct directories for storage.

EDIT:

I was able to install podman from here: https://github.com/risdenk/udm-podman/releases/tag/v0.1-alpha

That's great to hear! Much easier than I thought. Make sure you create a systemd service file to install it on boot if it doesn't exist, because it will most likely get wiped after a factory reset (not reboot).

[mandreko]

Oh man. I just picked up a UDM Pro SE as well, and was trying to do this exact setup. I'm wondering what the "right" way is going to end up being with this new device.

[lehighkid]

So in the end I was able to get it up and running after a couple hours - I hacked together my steps but in essence, I had to reverse the 01-podman-update.sh script to install podman, create some directories and modify some scripts for missing directories/binaries, etc. In the end, everything runs and persists on reboot - I moved pihole from my nas. peacey's approach above was very helpful as well.

I too am waiting for the right approach...

[patelng]

So in the end I was able to get it up and running after a couple hours - I hacked together my steps but in essence, I had to reverse the 01-podman-update.sh script to install podman, create some directories and modify some scripts for missing directories/binaries, etc. In the end, everything runs and persists on reboot - I moved pihole from my nas. peacey's approach above was very helpful as well.

I too am waiting for the right approach...

Could you post your script with the modifications? I am stuck at getting Podman installed on my UDMP SE.

Thanks!

[lehighkid]

Could you post your script with the modifications? I am stuck at getting Podman installed on my UDMP SE.

I don’t have a script only a series of commands i cobbled together saved to a gist here

HTH!

EDIT: It is worth noting that this uses insecure methods, vfs for storage since I couldn’t get overlay to work, and some other changes to get it to run but so far so good. Use as your own risk.

[mpreissner]

Has anyone updated to Beta firmware 2.2.5? I've got that on my SE. Very interested to use this in the near future...willing to be a guinea pig as well since it's sitting on a test bench for the moment.

[yoyellow]

Has anyone updated to Beta firmware 2.2.5? I've got that on my SE. Very interested to use this in the near future...willing to be a guinea pig as well since it's sitting on a test bench for the moment.

i just received my UDM pro SE and updated everything to latest. that seems to be 2.2.5 so dont think its beta (anymore?)

The update did fix a whiny Fan so i happy with that :P

[mpreissner]

Has anyone updated to Beta firmware 2.2.5? I've got that on my SE. Very interested to use this in the near future...willing to be a guinea pig as well since it's sitting on a test bench for the moment.

i just received my UDM pro SE and updated everything to latest. that seems to be 2.2.5 so dont think its beta (anymore?)

The update did fix a whiny Fan so i happy with that :P

The hardware itself is still an EA product...until the UDM and UDMP get merged into the 2.x branch, any UDMPSE firmware will be Beta/Release Candidate. In fact, I'm going to bet that UI won't release a 2.x for the UDM and UDMP until the UDMPSE is GA.

Did you install the UDM Utilities prior to upgrading? That's one of the questions that I'm not sure is definitively answered yet...does anything survive the firmware update process...?

[mpreissner]

Thanks @TheJulianJES. I actually thought about that but had some doubts it would be an accurate test because I was worried the upgrade would go differently if it was a different version.

Nevertheless, I tried it to upgrade the firmware to the same version, and good news! The systemd service files were still there and enabled, and they ran on boot after the "upgrade". Custom apt/dpkg packages that I installed were not still installed however, so the upgrade seems to wipe the new dpkg packages. That's not so much of a problem though, because the systemd service files were still there and ran, so you can just install anything extra on boot if it doesn't exist (for example with ExecStartPre in the service unit itself).

So, a pretty good indicator! We'll have to see if this result holds up when we're upgrading to a different version.

Just curious, did any boot scripts you placed in /mnt/data/on_boot.d/ also persist after the "upgrade"? I decided to use a single udm-boot service file as you described above, but if the on_boot.d directory doesn't persist across upgrades, then I'd either need to re-upload any scripts I've created after every upgrade or use the other method of making a service file and storing the scripts in a location that we know will persist across upgrades.

Thanks!

[peacey]

@mpreissner, the /mnt/data directory shouldn't be touched by the system at all, so that's very odd. When I upgraded, it wasn't wiped. Are you sure this happened?

[mpreissner]

@mpreissner, the /mnt/data directory shouldn't be touched by the system at all, so that's very odd. When I upgraded, it wasn't wiped. Are you sure this happened?

Sorry, I’m new to the UDM series of devices, so I just wasn’t sure what parts of the file system were/weren’t persistent. Just thinking ahead to the next firmware update since I was already on 2.2.5 when I started playing around with things. I’ve put together scripts to set up my 6-over-4 tunnel, monitor my WAN IP for changes to update my 6-4 tunnel config, and update my SSL cert…would hate for all that work to go to waste by being on a non-persistent partition. I’m even working on a possible dual-WAN load balancing option…wouldn’t want to have to recreate that from scratch.

[mpreissner]

Just an update...as I've had to reboot my SE a few times, I've found that my udm-boot.service (relying on network-online.target) is failing to bring up my tunnelbroker 6-over-4 tunnel (script works fine when called manually). Combing the logs, it seems that network-online target is satisfied by a link up, not by actually having an IP address. As a result, the script that sets up my tunnel fails because it can't enumerate the local IPv4 WAN address. We could probably add a "sleep 1m" to delay the script from actually running (there's less than a minute between when the script initially triggered and when I obtained a DHCP address on my WAN interface), or use networkd-dispatcher (scripts in the routable.d directory) to trigger certain scripts instead of relying on cron and udm-boot.

Also, upgrading to 2.2.7 went fine. All systemd files/services and /mnt/data/on_boot.d scripts survived. I think the important distinction between the SE and other UDM models is that it's simply a debian linux machine configured as a router. Firmware isn't really firmware, but rather a package/configuration baseline. When updating firmware, the update script simply upgrades all installed packages to the version UI has specified for that revision, and removes any unnecessary packages. For any heavy modifications (like extra packages, non-supported configurations, etc.), it's best to script the setup and monitoring of those configs to give them persistence across firmwares.

[boostchicken]

I added podman binaries for the SE to this repo

[jessesanford]

@peacey where did you put your systemd service unit files? Where did you store the tailscale bins?

[gtrabanco]

@jessesanford /etc/systemd/system/udm-boot.service

[hoppel118]

Hi, some days ago, I got my udm pro se and everything works as expected.

@peacey I want to thank you for writing down your findings. This changes everything for me. It took me 10 minutes and my iptables masquerades are persistent:

https://github.com/rytilahti/python-miio/issues/422#issuecomment-1000574930

Regards Hoppel

[lanwin]

Sidequestion. Is there somewhere a good doc on how the new SE os is structured?

[gtrabanco]

It is almost like the inside os unifi-os shell in regular udm-pro.

The unique thing different I've found is the version of radius which now could not be updates as previous udm-pro or any other because now is using freeradius 3 instead of v2.