pants

Would it be possible for the plugin to call /usr/local/emhttp/webGui/scripts/notify if a user script returns a non-zero exit code passing something like "User Script Failed" as the subject and the filename of the script as the message? It could be optional (i.e. a feature that can be enabled or disabled) and disabled by default if there are any concerns that it would disrupt existing plugin users. Right now I am adding calls to notify within many of my scripts so that I am alerted if they fail -- they would be much less redundant if the plugin executing script handled error notifications.

With respect to the original issue regarding the MAC address (data link layer address) of shim-br0 changing on reboot, I suspect the code responsible for assigning the MAC address to shim-br0 can be found in rc.docker here: # hack to let containers talk to host if [[ $TYPE == br ]]; then SHIM=shim-$NETWORK if [[ $DOCKER_ALLOW_ACCESS == yes && -n $IPV4 ]]; then # create shim interface if [[ ! -e $SYSTEM/$SHIM ]]; then run ip link add link $NETWORK name $SHIM type $ATTACH mode $MODE # <-***--THIS LINE CREATES shim-br0 run ip link set $SHIM up fi ... fi else ... fi fi doneBased on the ip-link docs, it looks like the ip link add command takes an address argument which can be used to specify the MAC address of the new interface. If the address argument is not used it seems like the kernel may choose a MAC address randomly by following a procedure similar to the one outlined in this stackoverflow post. It may be possible to assign a static MAC address to shim-br0 by supplying one to the ip-link command via the address argument. However, it would need to be generated programmatically using a procedure similar to the kernel to avoid conflicts but deterministically instead of randomly.

@fabianonline I'm not sure why but for some reason the combination of read and process substitution in the following line contained in the disk.sh script leads to disk.sh becoming a <defunct> zombie process each time it is called which eventually results in my server hitting the "max user processes" limit thereby preventing any new processes from being forked: read bytes_read bytes_written _ < <(grep $device"=" /var/local/emhttp/diskload.ini | cut -d"=" -f2) I was able to prevent disk.sh from becoming a zombie by replacing the problematic line (and the subsequent line) with the following line which uses awk instead of "read <()": grep $device"=" /var/local/emhttp/diskload.ini | cut -d"=" -f2 | awk '{print "\"bytes_reading\":"$1", \"bytes_writing\":"$2"}"}'

I took a look at the github repo corresponding to this docker image. It is a fork of a well-maintained image that receives regular updates from mvance. You can switch this template to use that image instead of the out-of-date / abandoned one by replacing the "Repository" field with: "mvance/unbound:latest" If you compare the other fields in the Unraid template to the fields mentioned in the instructions for setting up mvance's docker image on Unraid contained in this reddit post they match up exactly so it's no surprise that the template is compatible with mvance's image. Furthermore, if you look at the diff between the downstream image and the upstream image, only the README has been changed and only to update links to point to the forked repo rather than the parent repo. I have submitted a pull request to update the repository reference in the container template to point to the regularly maintained image. Hopefully @kutzilla will merge it so that users of this template are able to receive regular updates without his ongoing involvement. If he is MIA, the other option would be to publish a new Unbound template which points to the mvance Repository and formally deprecate & abandon this one.

@kutzilla Has this container been abandoned? If not, would it possible to update it semi-annually (or at minimum, annually)? The latest release of unbound at the time of this comment is 1.22. Based on the log output, it looks like this container is running Unbound version 1.13.1 which was released Feb 9, 2021 which is now over 4 years old. [1738914858] unbound[1:0] info: start of service (unbound 1.13.1). Last year there were only 7 releases so bi-annual updates would likely be enough to keep this container within 3-4 releases of current.

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

@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

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?