dumurluk

Thanks so much for this plugin. Just installed it and it saw the lto6 drive right away. However, just fyi, the plugin install process (at least the latest version) seems to improperly mess with the permissions of the unraid system folders so key based ssh login stops working. It required a reboot of unraid for it to be fixed. It likely means every time this plugin gets updated, I'll have to reboot the whole server to make ssh work again, which is not desirable as I run a lot of critical systems on it. Apparently other plugins also caused the same issue in the past. Here are two threads with more info on it:

I believe with fuse mounts, which is what unRAID uses for the array by default, the inode ids are generated on start/mount. So every time you reboot unraid, the inode ids of the files will change. Restic uses multiple things to determine if a file is unchanged and one of those things is the inode id. On unRAID, every time you reboot, most if not all files will be recognized as changed by restic, leading it to update metadata for every single file in the backup, which causes really long backup times. Restic recommends using the arg "--ignore-inode" on fuse mounts so it won't incorrectly recognize the files as modified when inode ids change. It will continue relying on other things like mtime. https://restic.readthedocs.io/en/latest/040_backup.html#file-change-detection

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" } ]

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.

Yeah, I spent way too much time on way too many cmos resets. I finally got it to a state where it seems to be stable (after several power cycles). At least now I have ikvm access to bios and can see most of the unraid boot process; and hw transcode works. I guess I can live without console access over ikvm.

As a last ditch effort, I tried to bump the memory limits under graphics settings to see if it would fix the black screen issue with onboard oprom set to efi, but now it is getting stuck on PCI enumeration before you can get into bios. I officially give up. Going back to legacy boot with everything else legacy and pci primary set to onboard. At least I'll have bios access and most of the boot process on ikvm (modprobe is the last line in the go file). I don't have it in me to clear cmos and start over one more time.

Hey guys, I just got the X11SCA-F and put in an E-2146G. It came with bios version 1.4. I followed all the advice and directions in this thread and nothing seems to let me have ikvm and /dev/dri at the same time. And there is one specific change that locks me out of all video output (even bios) and forces me to clear cmos and start over. Perhaps this bios version is really buggy. Here are my general observations: By default, boot is set to "dual", which should allow both legacy and uefi. When boot is set to "dual" or "legacy", most everything else is also automatically set to legacy (including the onboard video oprom option mentioned in this thread). When boot is set to "uefi", most other options also switch to uefi automatically (including onboard video oprom) Here is a list of what happens with different settings: Boot set to "dual", trying to load unraid with legacy, it gets into a boot loop where it goes through all the steps of the boot process and when it's time to boot into unraid, it resets. When I tried to boot unraid in uefi with that, same thing happened unless I selected the boot option manually, in which case it booted fine. Something about the "dual" boot setting just doesn't seem to work. Boot set to "legacy", primary display in bios set to pci, primary pci set to onboard and internal graphics set to enable, unraid boots via legacy just fine. ikvm works right up until modprobe and then it drops (tried with and without monitor attached) Boot set to "uefi", primary display in bios set to pci and internal graphics set to enable, unraid boots via uefi just fine. ikvm works right up until modprobe and then it drops (tried with and without monitor attached). One interesting thing is that when boot is set to uefi, the options "primary pci" and "primary peg" disappear from graphics settings, very strange. Now if boot is set to legacy, and I follow this thread's advice and set onboard video oprom to uefi, I can see the boot process with the Supermicro background, but it goes to a black screen (sometimes green and sometimes red) when it tries to boot into unraid or bios. This I tried with and without a monitor attached, and the same thing happens. I can no longer go into the bios because hitting "Del" results in the same black screen. The process goes on in the background (because unraid web gui does come up if I wait long enough). But I have no display. I tried hdmi as well, which displays nothing. And vga displays a faulty signal (according to a monitor). The only solution to this is to clear cmos and start over. I eveb tried this without ever plugging a monitor in at all after resetting cmos, so that's not it. So in a nutshell, legacy booting with onboard video oprom set to uefi completely breaks vga display, requiring a cmos clear. Legacy booting with bios set to pci and, pci default set to onboard and onboard video enabled, ikvm works up until modprobe. Uefi booting with bios set to pci and onboard video enabled (no option for default pci), ikvm works right up until modprobe. So I'm going with the final option for now, at least I can see to boot process and get into bios, and utilize hw transcode. But, it irks me that with uefi boot, the option for default pci is not there. I'm not sure what will happen when I plug in another gpu for passthrough. It will perhaps switch to that for output and make me lose ikvm for boot process? Who knows. In any case, this board looks awesome on paper, but the bios and the settings (and the bugs) are incredibly annoying and time consuming to try and figure out. I wish there were more options for affordable server boards with ipmi/ikvm.