UniFi OS - Dream Machines 3.x #523
Comments
|
use udm-boot-2x, it does not use ssh-proxy |
|
Did you compain to Ubi regarding apt not pointing at bullseye? |
|
Yeah just dropped that info on the UI discussion |
|
I havve requested the kernel sources for 3.0.19, lets see how long it takes |
|
Hello, |
|
@mabunixda : after your message on ui forum, rekoil says that his sources are pointing at bullseye. Maybe EA problem |
|
I'd prefer a common solution that is backwards compatible about podman/docker 🤔 @marco3181 Yeah donot know ... could be EA stuff yeah |
|
My /etc/apt/sources.list is properly pointing to bullseye (and have been since the start). I updated only a few hours after 3.x landed for UDM Pro in EA. |
|
Mine too (updates within minutes after EA announcement: root@udmp:~# cat /etc/apt/sources.list
deb http://deb.debian.org/debian/ bullseye main contrib non-free
deb http://deb.debian.org/debian/ bullseye-updates main contrib non-free
deb http://deb.debian.org/debian/ bullseye-backports main
deb http://security.debian.org/debian-security bullseye-security main contrib non-free |
|
Fixed it on my installation - might also be an old EA update that did not change this definitions... |
|
See my update here
|
Yeah that works for the short term, I think I can get podman working see above. It's really just a matter of pulling anything bpf related. Thats all for rootless containers and we don't have to worry about it. Also make sure you do the fix for the disk space when using VFS |
|
You know what it just dawned on the current builds should work fine on the latest 3. You just need to edit /usr/share/containers/seccomp.json and disallow any bpf syscalls, BOOM. Beyound that you can just do this --security-opt=seccomp=unconfined in your podman command and it wont call bpf at all, no security stuff happening. |
|
New builds coming out now with a fixxed seccomp.json that removevs bpf from the allows, also fixes some registry issues |
|
Grab the two latest builds here if ipfs is being a shit head https://github.com/unifi-utilities/unifios-utilities/actions |
No bueno @boostchicken, it still doesn't work with these modification and your new build. Still same issue with BPF error, unfortunately. |
|
Yes, same issue and I was wondering if I did something wrong! I also started getting warning for namespace: |
|
UDM Boot remote script still works fine. Firmware 3.X comes with DNSCrypt-Proxy service already pre-installed natively, which is a great replacement for simpe local DNS servers and doesn't require Podman! |
That's quite interesting! Wondering if I can get that to work with my blocklist (https://oisd.nl). I only use porman for Adguard, so this looks like a nice workaround. |
Absolutely can be. You'll need to trigger the generate-domains-blocklist.py with your configs during cron and possibly reload dnscrypt-proxy afterwards. |
From the UDM, i can use it via |
|
I also need specific instructions on how to make DNSCrypt-Proxy the main DNS resolver for UDM for WAN and for LAN. I think DNSCrypt-Proxy is normally configured via a TOML file, but UDM firmware 3.X uses SystemD, which is listed in DNSCrypt-Proxy manual as a non-standard way of making it work. So... Still need specific instructions. |
|
I've followed @peacey's https://github.com/peacey/unifios-utilities/tree/nspawn/nspawn-container instructions to make nspawn containers replacement work for me. I created an Alpine nspawn container instead of Debian (5Mb instead of 300+, and it takes seconds to bootstrap) using https://gist.github.com/sfan5/52aa53f5dca06ac3af30455b203d3404#file-alpine-container-sh with replacing With installing the [Exec]
Boot=on
Capability=all
Parameters=multicast-relay.py --interfaces br0 br4 --foreground
[Network]
Private=off
VirtualEthernet=off
ResolvConf=off |
|
@paskal - An on boot script also works to just call the python script directly. |
|
@gatesry do you have an example? |
|
@Stealthii For sure! |
|
Thanks @gatesry! I'd no idea that the script was that simple all the dependencies were available in the UDM environment. No real need for a container. |
|
Is it possible to make the on-boot script load sooner? I think it is set to "After/Wants=network-online.target". It loads my scripts like custom IPTables after UDM makes network connections. I need my custom rules to load before such connections happen. With old UniFi-OS 1.X firmware, booting sequence was stricter, I think. FYI, there is no more need for SSH on-boot scripts. Once authorized_keys file is made, it persists after reboots on its own. |
|
I found the correct string to use in the systemd unit file for the udm-boot.service.
Full unit file is as follows: |
|
For reference. Installed today in a UDM-PRO running # Download package
curl -L https://github.com/unifi-utilities/unifios-utilities/raw/main/on-boot-script-2.x/packages/udm-boot-2x_1.0.1_all.deb -o /tmp/udm-boot-2x_1.0.1_all.deb
# Install it
dpkg -i /tmp/udm-boot-2x_1.0.1_all.deb
# Patches for 'udm-boot-2x_1.0.1_all.deb' package
sed -i 's/Description=Run On Startup UDM 2.x/Description=Run On Startup UDM 3.x/g' /lib/systemd/system/udm-boot.service
sed -i '/Restart=on-failure/d' /lib/systemd/system/udm-boot.service
sed -i '/RestartSec=5s/d' /lib/systemd/system/udm-boot.service
# Enable reload and start
systemctl enable udm-boot
systemctl daemon-reload
systemctl start udm-bootEverything is working fine. Except for a minor bump I hit with |
|
@fdcastel does not work on my UDM v3.1.16 |
|
Sorry @bruvv but I have no idea what could possibly be wrong just looking at this log. We will probably need help from the script authors.
All I can suggest you for now is to uninstall the .deb package and try again. If possible, post here the output of installation process. |
Can it be one of the scripts in the startup folder that does not terminate timely? EDIT: the package basically justs runs your scripts in the /data/on_boot.d folder in a sorted order. So if any of these times out it could well give that error. EDIT2: also what file did you install? the output indicates an older version, mine reads: |
|
Ooops indeed I already had a version installed, removed everything redid and it works. saidly I am running against errors with podman and zerotier. |
That is to be expected though, given 3.x doesn't support podman. |
@m4n63 Nice catch! I didn't see this. @bruvv It seems you have installed the wrong package. If you follow the same steps I did this should be: Note that mine says sed -i 's/Description=Run On Startup UDM 2.x/Description=Run On Startup UDM 3.x/g' /lib/systemd/system/udm-boot.service |
Working for 3.1.16 for me too. Has anyone successfully gone to 3.2.7? |
I can confirm that the above snippet works on 3.2.7. |
I upgraded and initially my Pi-hole container didn't start. I had to run |
Tonight, my UDM-PRO was upgraded from 3.1.16 to 3.2.7. Unfortunately,
A reinstall (following these steps) was needed to bring it back again. Until we have a fix for this, I'd recommend keeping the Unifi OS Console away from auto-updates. |
|
UDM nSpawn Setup.pdf
|
|
For whatever it's worth, my udm-boot service survived the upgrade from 3.1.16 to 3.2.7, on a UDMB. But I only use it to kick off a script on boot, that uses cron to re-schedule itself to run a couple times a day. And I had most recently installed it using this method: |
|
I think I've figured out the root cause of some of the issues people are having (in particular @bruvv and @m4n63 and maybe others). I too followed the steps from @fdcastel several times, but noticed that the comments about being labeled "Run On Startup UDM 3.x" weren't there when doing a systemctl status udm-boot. That's when I also noticed that it was loading /etc/systemd/system/udm-boot.service NOT /lib/systemd/system/udm-boot.service (notice the /etc instead of /lib). For some reason a previous version of the install script put things in /etc, and while dpkg was reinstalling stuff in /lib, the /etc version was still being used (and the /etc version seems to still be hardcoded in the remote_install.sh [FYI @boostchicken ]) So to get it working, all I had to do was to 'back out of everything I could': Then run the commands multiple people have already posted: Previously, when I ran this last command it would sit forever and then give me a time out error. This time it completed nearly immediately. A systemctl status udm-boot shows it as active and most importantly has the "Run On Startup UDM 3.x" label. Hope this helps some people! |
|
Another minor issue I just discovered. Looks like I had one of the original podman versions of containers running, and as such I had the 04-container-common.sh script in my on_boot.d folder, which is supposed to set limits on podman container logs. However, with podman gone in unifi os 3+, that script generates an error, which cause the udm-boot service to fail and exit instead of exit and stay active. I wonder if this is also causing some of the weirdness / inconsistencies people are seeing? Bottom line is to check for various older scripts in on_boot.d folder and remove them. Also might want to make a comment about not needing this script anymore in the appropriate readme here: https://github.com/unifi-utilities/unifios-utilities/blob/main/container-common/README.md |
|
@achalker could you please provide the output for the following command on your UDM-PRO? # find / | grep -F 'udm-boot' | grep -v -e '^/sys/fs/cgroup' | sortEdit: Added This will list every file containing |
|
@fdcastel happy to. Note I don't have a UDM-PRO, just a plain old UDM (I've got 3 of them are various relatives sites in fact). Keep in mind I did already manually remove the /etc/systemd/system/udm-boot.service file yesterday on all 3 of them, as well as the symlink in /etc/systemd/system/multi-user.target.wants/udm-boot.service Here's the output you requested from the newest UDM, which appears to be identical to yours. Running this on the oldest UDM (which I did most of my original testing / setup on), the output is similar, but there are some differences: |
It is. Except for
There are two differences:
Unfortunately I don't have any UDM to inspect. Anybody could chime in about these 2 files and tell us if this is the expected state on a UDM? |
|
From 3.1.16 to 3.2.9 and on_boot scripts weren't deleted... Confirmed working with 3.2.9 on UDM-Pro. |
|
Also running into the podman issues. Is there a workaround for this? Trying to get ZeroTier running on my UDM. |
|
Manually upgraded from 3.2.7 to 3.2.9. Unfortunately, once again,
A reinstall (following these steps) was needed to bring it back again. Until we have a fix for this, I'd recommend keeping the Unifi OS Console away from auto-updates. |
Just thought I'd share that an abbreviated version of above linked 'recipe' has worked for me in my recent OS upgrade efforts: systemctl enable udm-boot |
|
I spent a little time digging into this yesterday. Unfortunately, I don't have a solution yet, but do have a pretty good understanding of why udm-boot is not surviving updates. I know that udm-boot used to survive firmware updates, but I don't have a udmpro running really old firmware and don't want to risk trying to downgrade that far, so I haven't determined what might have been different on the older firmwares. Here is what I've figured out, which I thought might help if others also want to dig in... TLDR;Only these packages will be restored on firmware update: ubnt-dpkg-cache/restoreWhen a package is installed (e.g. udm-boot-2x), a hook ( This behavior can be changed by adding Unfortunately, this isn't enough. The I manually created the "install" action, hoping this would be enough: Unfortunately, I was thwarted again by the Test SetupTo help others that have a udmpro that they can experiment with, here are the steps I used to facilitate repeated testing of the firmware update from v3.1.16 to v3.2.12. I started with a udmpro fully updated to v3.2.12. I disconnected the WAN cable from the udmpro and am wired to a LAN port from my computer, which is also connected to internet via wifi. This ensures that firmware will NOT update during the initial setup wizard! I downloaded copies of the the v3.1.16 and v3.2.12 firmwares on my laptop using the download links from the corresponding releases posts: Factory Reset to v3.1.16The udmpro can be downgraded to v3.1.16 by first scp'ing the firmware to the udmpro: Then from the udmpro, apply the firmware update: After the update completes, hold the hardware reset button down to force a factory reset. The setup wizard will allow you to complete an offline setup. Enable ssh and set a password and you have a fresh v3.1.16 udmpro to test with. Update to v3.2.12After installing udm-boot and making any other tweaks to try and get it to survive the firmware update, the update can be applied in the same manner as v3.1.16 (without the factory reset). First scp the firmware to the udmpro: Then from the udmpro, apply the firmware update: After confirming the failure to preserve udm-boot, repeat the downgrade / factory reset to v3.1.16 to try again! |
and others
Ubiquiti recently made 3.0.19 available in EA at https://community.ui.com/releases/UniFi-OS-Dream-Machines-3-0-19/aae685bb-4b96-4016-9125-29e57d7f2844
Known aspects of 3.x
/datais preserved in the upgrade, butudm-boot_1.0.7_all.debneeds to be installed again;ssh-proxyis not present in 3.x, but manual install runs correctly;CONFIG_BPF_SYSCALL(tracked in Error when trying to run pihole container on UDM SE #510), meaning podman cannot run on it without a custom kernel;The. It now points to/etc/apt/sources.listis still pointing tostretchbullseye.UPDATE: I've started a discussion at https://github.com/orgs/unifi-utilities/discussions/564 to get some feedback on how the migration to 3.x went for the more adventurous users among us.
The text was updated successfully, but these errors were encountered: