dumurluk

Right, the volumes were created in command line, but unraid's gui accepts them as the host path. Same with regular named volumes, if the host path does not begin with a forward slash, docker will use a named volume instead of a bind mount. Unraid's gui simply passes that value to docker run and does not interfere with the outcome. Here's what the volume setting looks like:

Great job on the new grouped containers feature. It was much needed for containers with dependencies or external databases. It works flawlessly. However, I did run into a minor issue with nfs docker volumes that were not properly detected by the plugin and resulted in log errors. It didn't end up causing an actual issue other than log errors, so not that big of a deal in my case, but I'll detail it below. My plex container has a few docker volumes (named volumes) set up using the nfs volume driver (because my media resides on a different server): https://docs.docker.com/storage/volumes/#create-a-service-which-creates-an-nfs-volume It is a docker volume that automatically mounts a remote nfs path inside the container. The plugin settings don't detect them at all and they are not listed under "Configured Volumes" under plex. However, when I run the backup, I get the following errors where they do get detected but the plugin can't figure out the host path (there is no host path as it's not a bind mount). [06.02.2024 22:25:52][❌][plex] '3dmovies' does NOT exist! Please check your mappings! Skipping it for now. [06.02.2024 22:25:55][❌][plex] '4kmovies' does NOT exist! Please check your mappings! Skipping it for now. [06.02.2024 22:25:58][❌][plex] 'movies' does NOT exist! Please check your mappings! Skipping it for now. [06.02.2024 22:26:00][❌][plex] 'tvshows' does NOT exist! Please check your mappings! Skipping it for now. [06.02.2024 22:26:03][❌][plex] 'music' does NOT exist! Please check your mappings! Skipping it for now. As I mentioned earlier, it didn't end up causing an actual issue for me because the paths were skipped, and that would be my preference anyway since those media paths are remote. For reference, the inspect for one of those volumes looks like this: # docker inspect movies [ { "CreatedAt": "2024-02-12T03:40:01-05:00", "Driver": "local", "Labels": {}, "Mountpoint": "/var/lib/docker/volumes/movies/_data", "Name": "movies", "Options": { "device": ":/mnt/user/Movies", "o": "addr=192.168.1.10,rw", "type": "nfs" }, "Scope": "local" } ]

Updated the same server that was previously having issues, without any changes to the flash drive and 6.10.1 is starting up just fine. Thanks By the way, the issue with my flash drive was that it doesn't have a partition and is listed at "/dev/sda"

I don't believe partitioning was ever a requirement when I set my servers up. The process was just format, label, unzip the files and run the make bootable script.

I just ran "blkid" on my server currently running 6.9.2 and there is only one "sda" partition listed: /dev/sda: LABEL="UNRAID" UUID="DAA4-D416" BLOCK_SIZE="512" TYPE="vfat" Yet when I update to 6.10, unraid can't find the device

@limetechthanks for addressing the issue and providing details and a workaround. I just wanted to point out that I did not to anything special when I set up the boot drive several years ago and never messed with any partitions. At the time, the imager app was not available so I'm pretty sure I just formatted it in Windows, with the UNRAID label, added the unraid files and ran the make bootable script. I'll check its partitions next time I take my server offline and get ready for another attempt at an upgrade.

Oh yeah, I saw your post yesterday. Unfortunately it doesn't make a difference for me whether it's restarted or started from power down. Either way it gets stuck on the drive check.

There were reports but they didn't seem to be acted on. Folks seem to have just reverted back to the stable then. Here is one from last August: And here's one from September:

Yes, I agree. That's why we need @limetechto chime in on how exactly it tries to enumerate and detect the flash drive (different from 6.9.x, which works just fine). I'm really surprised that they didn't set the few days after a major stable release aside as an all hands on deck for support type of situation. It's not like they do releases often. The last one was a long time ago. Limetech is not a one person hobby project anymore. They really should be checking the bugs section on their official forum the day after a major stable release.

Tried both, no difference. Unraid 6.9.2 boots in usb3 and 2. Like I said, it's not an issue with booting. It boots fine, unraid gets loaded up in ram, it's only when the init steps are happening, unraid somehow thinks the flash drive is not there (likely for license check). There is no issue with actual bios booting

It's not the system that can't see it, it's whatever script limetech coded that can't "see" it.

@limetechcan you chime in on what that new functionality is supposed to be doing? That way we can try and properly troubleshoot. "waiting up to 30 sec for device with label UNRAID to come online"? I mean, it is booting off of the usb drive up to that point. And the usb drive is clearly labeled "UNRAID". Thanks EDIT: I have a feeling it's exclusively for checking the usb id for license check, which would be quite annoying (to bring down the whole server because of a failure in simple license check). Even Windows doesn't completely disable itself when the license activation fails.

Same issue here. Updated from previous stable via gui, rebooted and get the 30 sec message looking for device labeled UNRAID and it can't find it. I tried to manually unzip the bz files and try again, same result. I unzipped the previous stable's bz files and everything's working again. So there are no issues with my flash drive. Perhaps limetech can clarify what that new process is so we can try and figure what the issue is?

No, I did not. At this point I don't have it in me to deal with more cmos resets. I've also been dealing with another issue that affects this board on unraid (kernel panics and lock ups every 12 hours or so). This board and unraid have been a bad combo so far.

Same. I'm assuming you have unraid load igpu drivers for hw transcode? Once those drivers are loaded, the motherboard disables vga, which is connected to the IPMI for ikvm. See here for a broader discussion on that: