ljm42

I can't reproduce this on any of my systems (bare metal or VM) but I agree the command is missing from your logs. Looking into it, although still open to ideas from other folks : )

The system is still getting call traces. If you are fine with ipvlan, please do this: * Settings > Network Settings > eth0 > Enable Bridging = Yes * Settings > Docker > Docker custom network type = ipvlan (then reboot)

I have a feeling you might be right here. Will somebody who is running 6.12.4 please provide diagnostics after a reboot, after the container is started, but before you manually re-edit the listening interfaces. i.e. the listening interfaces should have the correct values from a previous boot, but I want logs that show they are ignored. Thanks!

Yeah, adding it to Tools > Update OS is just the first step. We'll deal with the banner in the future.

@TheDon thanks for the diagnostics, but I moved your post to its own thread since it looks like it will take more back and forth than makes sense in a release thread:

reload the page : )

FWIW, this was an issue that happened when shutting down 6.12.3, it was not related to the upgrade to 6.12.4. The upgrade changes the files on the flash drive, it does not change the running system. So applying an upgrade will have no effect on whether the running system is able to shutdown properly. i.e. the unclean shutdown likely would have happened the next time you rebooted, regardless of whether an upgrade was involved or not. Please see this thread for more discussion and a recommendation: https://forums.unraid.net/topic/144649-6123-unclean-shutdown/#comment-1302638 I don't know why your systems had this issue. It would be helpful if you check the logs folder on your flash drive for diagnostics with the right date and upload them to that thread so I can look for clues.

What I am saying is that the system likely would have had the same unclean shutdown if you had simply restarted it without doing an upgrade to 6.12.4, because the logs show that 6.12.3 issued the `rc.docker stop` command: Sep 4 08:53:21 NAS-UNRAID-2 emhttpd: shcmd (299441): /etc/rc.d/rc.docker stop Sep 4 08:53:30 NAS-UNRAID-2 root: stopping dockerd ... but when it later tried to unmount the volume, it failed: Sep 4 08:53:31 NAS-UNRAID-2 emhttpd: shcmd (299442): umount /var/lib/docker Sep 4 08:53:31 NAS-UNRAID-2 root: umount: /var/lib/docker: target is busy. Sep 4 08:53:31 NAS-UNRAID-2 emhttpd: shcmd (299442): exit status: 32 For now, I would suggest that you follow the instructions in this post when shutting down: https://forums.unraid.net/topic/144429-unraid-os-version-6124-available/#comment-1300996 i.e. 1) stop the array. 2) `umount /var/lib/docker` if needed, then 3) shutdown/restart. This will avoid any unclean shutdowns by ensuring the array is stopped before shutting down.

OK, so that sounds less like networking and more like the system was under such heavy load that it couldn't respond to anything. To confirm that, type "htop" at the console and keep an eye on the load as you start more containers. If it gets to where it is unresponsive again, I'm thinking all the CPUs will be pegged and the load will be skyhigh. If possible, take a photo of the screen with your phone so we can see what commands are the culprits (I'm guessing Docker, but better to have proof) To recover from this... first I would let it run for a while. See if it can finish doing whatever it is doing and recover on its own. After a while (at least an hour) you could try exiting htop and typing `/etc/rc.d/rc.docker stop`. It may be able to stop things to the point that the load recovers and you can stop the array. If that fails, you'll probably have to hit the power button again. If it looks like Docker is the issue, I'm thinking it might be worth deleting and recreating the Docker image: https://forums.unraid.net/topic/36647-official-guide-restoring-your-docker-applications-in-a-new-image-file/

The upgrade changes the files on the flash drive, it does not change the running system. So applying an upgrade will have no effect on whether the running system is able to shutdown properly.

FWIW, this was an issue that happened when shutting down 6.12.3, it was not related to the upgrade to 6.12.4. However, if there is a bug here it was probably not solved by 6.12.4. The logs show that we issued the `rc.docker stop` command: Sep 4 08:53:21 NAS-UNRAID-2 emhttpd: shcmd (299441): /etc/rc.d/rc.docker stop Sep 4 08:53:30 NAS-UNRAID-2 root: stopping dockerd ... but when we try to unmount the volume, it fails: Sep 4 08:53:31 NAS-UNRAID-2 emhttpd: shcmd (299442): umount /var/lib/docker Sep 4 08:53:31 NAS-UNRAID-2 root: umount: /var/lib/docker: target is busy. Sep 4 08:53:31 NAS-UNRAID-2 emhttpd: shcmd (299442): exit status: 32 We may need to add more logging to figure out what the issue is. For now, I would suggest that you follow the instructions in this post when shutting down: https://forums.unraid.net/topic/144429-unraid-os-version-6124-available/#comment-1300996 i.e. 1) stop the array. 2) `umount /var/lib/docker` if needed, then 3) shutdown/restart. This will avoid any unclean shutdowns by ensuring the array is stopped before shutting down.

@johnwhicker I moved your posts to their own thread

@IFireflyl I moved your posts to their own thread:

Would you please post the full diagnostics? We need to see what happened before this for a clue as to what is keeping the drive busy

In the syslog, I can see where you pressed the power button: Sep 3 09:41:36 unRAID elogind-daemon[1326]: Power key pressed. But before that, there are no indications of any problems. I'm wondering if the system is experiencing network problems. Maybe it isn't actually hanging, but is losing access to the network for some reason? This would result in it appearing to be unresponsive from the network. Can you plug a keyboard/monitor into the system and try logging in to the console while it is unresponsive? If you can get in, try to ping another system on your network

Interesting. So 6.12.4 looks fine on Chrome on my Android phone. I went to whatsmybrowser.org and it says I have Chrome 116 on my phone, what version do you have on your tablet? Also, would you please test in safe mode when you get the chance? It will help narrow down where the problem could be.

Sure. If you do end up with call traces then follow the instructions in the release notes to remediate them

That is confusing. There are a few things I would try if it were my system: 1) Check the bios for anything related to "fast boot" and disable it 2) Avoid rebooting. Instead, do a shutdown to power the system off fully and then start it back up. 3) Go to Settings -> Disk Settings and set "Enable Auto Start" to "no". This will ensure that if it crashes while booting, the array will not be affected. Of course, it also means you will have to manually start the array using the webgui once the system comes up.

6.12 has issues with macvlan where 6.11 did not. If you have macvlan enabled in 6.11 and make no configuration changes when upgrading, you will likely get call traces and crashes related to macvlan in 6.12.x Switching from macvlan to ipvlan is still a valid solution for most people but 6.12.4 has an alternate solution that allows you to stay with macvlan if you would rather do that.

Oh for some reason I thought you had blanked that area out of the screenshot. Didn't realize that is what I was supposed to focus on : ) Try booting in safe mode to determine whether the issue is related to a plugin. Also, do you have any other computer/browsers you can try?

Not sure what version you are running, but since you have IPv6 I'll suggest upgrading to 6.12.4 as it does have improvements for IPv6. If you continue to have issues please upload your full diagnostics.zip (from Tools -> Diagnostics)

Yes, the tiles are just minimized. Click the little down arrow next to each tile to open them back up.

This thread is perfect for quick questions or comments, but if you suspect there will be back and forth for your specific issue, please start a new topic. Be sure to include your diagnostics.zip.

Chances are, the only change you need to make is: Settings > Docker > Docker custom network type = ipvlan But here is some more info: Settings > Network Settings > eth0 > Enable Bonding = Yes or No, either work Settings > Network Settings > eth0 > Enable Bridging = Yes (must be yes to use ipvlan) Settings > Docker > Docker custom network type = ipvlan Settings > Docker > Host access to custom networks = Enabled (assuming you want that. disabled is ok too)

This thread is perfect for quick questions or comments, but if you suspect there will be back and forth for your specific issue, please start a new topic. Be sure to include your diagnostics.zip.