pants

I think both upgrade strategies are valid and the right one to employ depends on how a particular system is used. For people who regularly work on their server and want to take advantage of the newest features, moving to the latest release makes sense. For others who invested a lot of time initially to get things working and then moved on to other projects but still rely on their server to always be up and running, upgrading infrequently may meet their needs better. Limetech seems to tacitly support both upgrade strategies given that the USB Creator app allows users to select 6.11.5, 6.12.4, 6.12.5, 6.12.6 when deploying Unraid on a new server implying that there is a "limetech endorsed" reason for at least some users to start on 6.11.5 rather than 6.12.X. I'm aware of the changes to the bz* files in Unriad 6.12. Again for future readers, the only change to bzroot in 6.12 is that the /usr directory tree was moved from bzroot to bzfirmware. The full set of changes to all the bz* files is well-documented by limetech here. Nice! This is much more concise and functional than the set of commands I posted earlier. Just to reiterate for posterity though, using the --no-absolute-filenames option when expanding the cpio archive might improperly alter symlinks with relative paths on 6.10+ (although if I remember correctly those symlinks are in /usr/local/ so it may be safe to use the option again on 6.12+). Also, recompressing with --ia64 is probably not ideal for users who aren't running on itanium cpus. For those who want to incorporate these changes, line 3 and 5 of the commands above would become: dd if=/boot/bzroot bs=512 skip=$(cpio -ivt -H newc < /boot/bzroot 2>&1 > /dev/null | awk '{print $1}') | xzcat | cpio -i -d -H newc find . | cpio -o -H newc | xz --check=crc32 --x86 --lzma2=preset=9e --threads=$(nproc --all) >> /your/work/dir/bzroot.part When I found this bug, I actually did search for the upgradepkg script in that repository but could not find it within the sbin directory. Perhaps slackware files modified by limetech (as opposed to source code originally authored by limetech) are not committed to that repo since they may need to be manually recreated each release if the upstream file changes in slackware? While it's true that I would not have experienced this particular issue, there are many reasons why upgrading immediately is not always possible. As one example, if people rely on plugins that are not compatible with the latest release they must either wait for the plugins to be updated or take the time to find and deploy an alternative if the plugins have been abandoned by their author. I did consider manually changing the build numbers of the package names in /boot/extra but ultimately decided against it because that approach would require that I remember to continually modify the build numbers of any packages I download in the future. It also has the undesirable side-effect of making the names of local packages differ from their official release names which may cause confusion down the line. Patching the upgradepkg script itself in bzroot is undeniably the "correct" solution since that is how limetech themselves eventually fixed it -- any other approach would just be a workaround.

I didn't file a report since the bug is fixed in 6.12. Unfortunately, I have had limited success getting limetech to fix bugs I've filed in the past (see this report and this comment) and have often had to resort to my own patches / customizations. As for why I do not run the current version of Unraid, in the interest of stability I prefer to stay at least one major release behind current and only upgrade to the final minor release after the subsequent major release comes out. Upgrading can be time consuming depending on how smoothly it goes so I prefer to limit upgrades to at most once a year if possible. I certainly understand your point of view from a supportability perspective and I'm not suggesting that modifying the initramfs in bzroot be encouraged in general. Nowadays it probably only makes any sense to do in very unusual circumstances. I wasn't around in the old days but I'm guessing Unraid-Kernel-Helper made modifying the bz* files a little too easy for the average user to the point where people were doing it in situations where it wasn't strictly necessary; if that's the case discontinuing it was likely a smart move. Having said that, I still think a working set of commands to make changes to bzroot should be documented (and ideally kept up to date). Limiting the procedure to a list of commands rather than building a plugin or app around it should discourage less tech-savvy users from making changes while still helping more experienced folks avoid unnecessary pitfalls. While it's certainly possible that an inexperienced user might introduce problems by improperly modifying bzroot, the nearly working set of commands already present in this thread is actively causing frustration and wasting people's time. The issue is that I assumed upgradepkg itself is being called during startup to install the packages in /boot/extra. If that's the case, to fix the bug the script really needs to be replaced before that point in startup (otherwise some packages in /boot/extra may not be properly installed). I don't know much about the init sequence and I was worried that trying to replace the script after boot would leave a window for the buggy script to be invoked so I thought the safest thing to do was to replace it entirely. Given that the bug is fixed in 6.12, it's also a fairly clean solution for me since my changes will be automatically wiped away during upgrade without requiring me to do any manual cleanup.

In my case, I did it to fix a bug introduced by limetech into the "upgradepkg" script that exists in Unraid versions 6.10-6.11 (fixed in 6.12). Specifically the version_compare() function (included below) does not properly populate the ARCH, and VER variables and ends up only comparing packages by build number which prevents newer packages from being installed if they have a build number that is lower than an older package with the same name: # limetech - # Here's a function that figures out if one package is a newer version than # another package. We use this to prevent "upgrading" an existing package # to an older one. # We're lazy so use PHP's version_compare() function to do the heavy lifting. version_compare() { STRING="$1" BUILD=${STRING##*-} STRING=${STRING%*-} // <-- Should be STRING=${STRING%-*} ARCH=${STRING##*-} STRING=${STRING%*-} // <-- Should be STRING=${STRING%-*} VER=${STRING%*-} OLDVERSION="$VER.$BUILD" STRING="$2" BUILD=${STRING##*-} STRING=${STRING%*-} // <-- Should be STRING=${STRING%-*} ARCH=${STRING##*-} STRING=${STRING%*-} // <-- Should be STRING=${STRING%-*} VER=${STRING%*-} NEWVERSION="$VER.$BUILD" php -r "echo version_compare('$OLDVERSION', '$NEWVERSION');" } Normally, to fix a bug like this I would build a custom package with the fixed file and put it in /boot/extra to be applied during startup but that approach itself relies on "upgradepkg" to install the fix which presented a bit of a chicken-and-egg paradox. To solve the problem, I ended up grabbing the "upgradepkg" script from Unraid 6.12.5 and copying it into the initramfs in my bzroot. In general, I agree that modifying the initramfs in bzroot should be avoided if possible and only done as a last resort. However, I do think a working procedure for modifying bzroot should be easily available in the rare case it is necessary as it would save hours of time.

In case others who are trying to make changes to bzroot stumble on this thread, I had the same problem as @Masterwishx did (see above) and was able to solve it by removing the "--no-absolute-filenames" cpio option when unpacking the initramfs. It appears that as of at least Unraid 6.10+ the initramfs cpio archive uses relative paths and relies on some relative symlinks (e.g. ../../<link>) which are incorrectly altered if the archive is expanded with "--no-absolute-filenames". A working procedure for modifying bzroot on Unraid 6.10+ might look something like this: ##Extract microcode dd if=/boot/bzroot bs=512 count=$(cpio -ivt -H newc < /boot/bzroot 2>&1 > /dev/null | awk '{print $1}') of=/tmp/bzmicrocode ##Unpack mkdir /tmp/unpacked-bzroot cd /tmp/unpacked-bzroot dd if=/boot/bzroot bs=512 skip=$(cpio -ivt -H newc < /boot/bzroot 2>&1 > /dev/null | awk '{print $1}') | xzcat | cpio -i -d -H newc ##Make desired modifications to the expanded bzroot filesystem in /tmp/unpacked-bzroot ##Prepend microcode and Compress cd /tmp/unpacked-bzroot find . | cpio -o -H newc | xz --check=crc32 --x86 --lzma2=preset=9e > /tmp/bzroot_new cat /tmp/bzmicrocode /tmp/bzroot_new > /tmp/bzroot sha256sum /tmp/bzroot > /tmp/bzroot.sha256 ##Finally edit bzroot.sha256 to remove the trailing filename and copy the new files into /boot

The site is accessible using the Wayback Machine: https://web.archive.org/web/20230316082324/https://blog.siglerdev.us/unraidos/

@binhex Thanks for all your work creating and maintaining this container! I've just filed an issue on github to request that the file /etc/urbackup/backupfolder/ be automatically populated with the backup folder in order to improve support for btrfs snapshots. I turned btrfs snapshots on by creating the file within the container last year without thinking and just discovered that it was (of course) blown away when the docker image changed during the update from urbackup 2.4 to urbackup 2.5. Completely my fault for not adding it in a truly persistent way. Urbackup is very resilient so it continued to make backups without btrfs. However, the fallout over ~6 months was hundreds of GBs of error messages in my urbackup log file along with backups that totaled 1-2TBs bigger than they should be. In case anyone else hits this, my workaround for the time being is to add the following command which creates the file as a post-arg (note the leading semicolon): ; docker exec <urbackup-container> bash -c "mkdir -p /etc/urbackup; echo '/media' > /etc/urbackup/backupfolder" EDIT: And it's already been fixed. Thanks again for the amazing support binhex!

According to the "running" section of the urbackup docker README, btrfs support requires adding the `--cap-add SYS_ADMIN` parameter to the docker run command (it can be added as an `EXTRA_PARAMETER` in the unraid template). After adding this parameter, I no longer need to run the container as privileged to use btrfs.

In case others would like to add comments to the bug so that it gets more attention and is more likely to be fixed, I think the main report for the problem can be found here: In the meantime, it looks like there is a patch that can be applied via a user script which I've copied below. It is described in more detail in this blog post and is discussed on reddit here (the original idea for the scripted fix seems to have come from this comment on another post in the Unraid forums): #!/bin/bash ip link | grep 'shim-br0' &> /dev/null if [ $? != 0 ]; then echo "No shim br0 found, creating it!" ip link add shim-br0 link br0 type macvlan mode bridge ip link set shim-br0 up ip route add 192.168.1.0/25 dev shim-br0 ip route add 192.168.1.128/25 dev shim-br0 else echo "shim-br0 network was found!" fi Note that you may need to change the IP range to match the subnet of your home network if you are using something other than 192.168.1.0/24

I recently experienced this issue on Unraid 6.10.3 as well. I noticed that I was unable to send packets between docker containers on br0 and the Unraid server (pings to the server's ip address from containers on br0 failed) even though the docker setting "Host access to custom networks" was enabled. I then checked the routing table on the network settings page and saw that no routes referencing the shim interfaces appeared in the table. Stopping and starting the docker service recreated the shim routes and restored connectivity. Unfortunately, I did not think to check if the shim interfaces actually existed by running ifconfig before restarting docker. It looks like some users have patched this issue via a user script (see https://blog.siglerdev.us/unraidos/ for more details)

Thanks for all your work on this essential plugin (and your many others)! Just a few questions... What user are the start and stop scripts executed as? Based on the source code, it looks like they must be invoked as root since the /boot/config/plugins/ca.update.applications/scripts directory has mode 600 and is owned by root. if ( is_file("/boot/config/plugins/ca.update.applications/scripts/starting/$containerScript") ) { logger("Executing custom start script /boot/config/plugins/ca.update.applications/scripts/starting/$containerScript"); exec("/bin/bash /boot/config/plugins/ca.update.applications/scripts/starting/$containerScript"); } Also, could you provide a link to the CA manual referenced in the quote above?

The amount of time required for the time drift to become relevant may be hardware dependent as I think the system relies on an oscillator/clock on the motherboard to keep time when ntp is unreachable meaning drift rate would depend on how accurate those components of the board are. For me a drift of a few seconds was noticeable within tens of minutes/an hour and the problem became serious when the server time drifted far enough that my dockers which are configured to use one-time-passwords generated by authenticator apps (e.g. BitWarden/VaultWarden) were out of sync with network time by at least one "password window". This resulted in the docker container not agreeing with the password generated by the authenticator and blocking log-ins. My current solution is to create a custom slackware package containing a modified copy of rc.ntpd adding the line mentioned above that I place in /boot/extra so it automatically overwrites the original rc.ntpd during startup (package attached for reference). I am content with this fix but since rc.ntpd may change between Unraid versions I have to rebuild the package as part of my upgrade process just to be safe so it makes Unraid OS upgrades a bit more cumbersome. Since "VPN tunneled access for system" is an option presented to the user in the UI it would be nice to get an official fix at some point. rc.ntpd-fixed.tgz

This problem occurs when tunneling the entire system's access to the WAN using peer type "VPN tunneled access for system"

Just upgraded to Unraid 6.10.3 and have confirmed that this issue is still present. root@myserver:~# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== *LOCAL(0) .LOCL. 10 l 18 64 377 0.000 +0.000 0.000 time1.google.co .INIT. 16 u - 128 0 0.000 +0.000 0.000 time.cloudflare .INIT. 16 u - 128 0 0.000 +0.000 0.000 uschi5-ntp-001. .INIT. 16 u - 64 0 0.000 +0.000 0.000 168.61.215.74 .INIT. 16 u - 64 0 0.000 +0.000 0.000

I use the "raw files" category in Ubooquity for this. My PDFs are organized as follows: /media/pdfs/manuals /media/pdfs/datasheets /media/pdfs/... Then I point the "/files" path in the Ubooquity docker container to "/media/pdfs"

The issue described above turned out to be a bug in ebtables. More information on the bug can be found here. I resolved the issue by installing an older version of ebtables which was not susceptible to the bug from pkgs.org found here.