rbroberts

Well, it looks like my metadata.db was corrupted but in such a way that I wasn't seeing any errors, just an empty library. The good news, I've just successfully confirmed that my CrashPlanPro subscription is actually handy 🙂 I pulled in a backup from a few weeks ago and my library is back. I picked the backup somewhat at random, after a recent book purchase, but probably before some other imports, so I'll have to pull a more recent one if I can find a good one.

This is weird... my library has disappeared within calibre. My books are, of course, all still there on disk and my configuration points to the right place, but calibre is showing me a completely empty library. I've certainly done a couple of routine updates of the docker image and, in fact, also upgrade unraid from 7.0.0 to 7.0.1. I'm not sure how to recover from this as I'm not quite clear on what got lost right now. I'd very much like to avoid simply reimporting a few hundred books and losing all my read status information. I do have external backups I can go to, but I need to understand what's missing so I can find the backups that contain the missing info. I can, from the calibre console (i.e., launch the console from the unraid web page) see that the library is right where it's supposed to be. Any ideas on what calibre is looking for and not finding to make it show me an empty library?

Well, there's a couple of pm2 files to be found root@Tower:/boot/config# find /usr/local -type f -name pm2 /usr/local/unraid-api/node_modules/pm2/pm2 /usr/local/unraid-api/node_modules/pm2/lib/templates/logrotate.d/pm2 /usr/local/unraid-api/node_modules/pm2/bin/pm2 of which the first looks most promising based on it's content as a bash script. But this looks wrong since node doesn't live where this script wants to find it. root@Tower:/boot/config# cat /usr/local/unraid-api/node_modules/pm2/pm2 #!/bin/bash DIR="$(dirname "$(readlink -f "$0")")" $DIR/node/bin/node $DIR/bin/pm2 $@ Based on root@Tower:/boot/config# find /usr/local -type f -name node /usr/local/node/bin/node I suspect the problem is the readlink. There is a symlink from /usr/local/bin/pm2, but trying to use that to start things root@Tower:/usr/local/bin# /usr/local/bin/pm2 start /usr/local/unraid-api/ecosystem.config.json --update-env /usr/bin/env: ‘node’: No such file or directory but that can be fixed by adding /usr/local/node to PATH export PATH=$PATH:/usr/local/node After which /usr/local/bin/pm2 start /usr/local/unraid-api/ecosystem.config.json --update-env will get things started. Note that this is not the same as the original attempt as /usr/local/bin/pm2 is a node script and it bypasses any funkiness with readlink. I'm not sure what the canonical way to get unraid-connect started is, but this seems to work.

With unraid 7.0.0 most of the above worked, and I could manually get unraid connect to run. But with 7.0.1, something has gone horribly wrong. After uninstalling and reinstalling the plugin, everything in /usr/local/unraid-api/node_modules/.bin/ points to something under /home/runner which doesn't exist. I'm not sure how to proceed, though I'll try to dig as soon as I have time.

Just happened to me today. I had removed two of my four cache SSDs (they're Samsung 870 EVOs that are going out for warranty repair/replacement). I did them one at a time, and was stopping the array just to reduce the cache size to 2 disks when it hung for over an hour. I had walked away and came back to find it in that state. Opening a web terminal and unmounting /var/lib/docker did the trick, so this has the same symptoms as the original, but I'm on Unraid 6.12.6.

And after rolling forward a few times, eventually ending on the latest, it's all working. No idea what went wrong the first time, but the problem has just gone away on its own.

Well, I rolled back to ╭――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――╮ │ │ │ Application: CrashPlan for Small Business │ │ Application Version: 10.4.1 │ │ Docker Image Version: 22.12.2 │ │ Docker Image Platform: linux/amd64 │ │ │ ╰――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――╯ And this works both with Host and Bridge for networking. I'll try rolling forward step by step and see if it works.

I didn't see anything listed as a definitive solution to this, but I'm having the same problem. My lead up to the problem is a little different in that I managed to trash my cache drive completely and have been reinstalling from scratch. That got me my old config and the latest container; not sure what version I was on before. However, at this point, I can't log into the local WebUI either, same message. It is running and is connected to CrashPlan.com and successfully connected last night as checked on crashplan.com. But even after nearly 24 hours, the WebUI still says it's upgrading and won't let me in. The log is below, I'm not sure where to look to fix this. [cont-init ] 10-vnc-password.sh: executing... [cont-init ] 10-vnc-password.sh: terminated successfully. [cont-init ] 10-web-data.sh: executing... [cont-init ] 10-web-data.sh: terminated successfully. [cont-init ] 10-x11-unix.sh: executing... [cont-init ] 10-x11-unix.sh: terminated successfully. [cont-init ] 10-xdg-runtime-dir.sh: executing... [cont-init ] 10-xdg-runtime-dir.sh: terminated successfully. [cont-init ] 15-cjk-font.sh: executing... [cont-init ] 15-cjk-font.sh: terminated successfully. [cont-init ] 15-install-pkgs.sh: executing... [cont-init ] 15-install-pkgs.sh: terminated successfully. [cont-init ] 55-crashplan-pro.sh: executing... [cont-init ] 55-crashplan-pro.sh: running the CrashPlan for Small Business version [cont-init ] 55-crashplan-pro.sh: terminated successfully. [cont-init ] 55-validate_max_mem.sh: executing... [cont-init ] 55-validate_max_mem.sh: terminated successfully. [cont-init ] 85-take-config-ownership.sh: executing... [cont-init ] 85-take-config-ownership.sh: terminated successfully. [cont-init ] 89-info.sh: executing... ╭――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――╮ │ │ │ Application: CrashPlan │ │ Application Version: 11.2.0 │ │ Docker Image Version: 23.12.1 │ │ Docker Image Platform: linux/amd64 │ │ │ ╰――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――╯ [cont-init ] 89-info.sh: terminated successfully. [cont-init ] all container initialization scripts executed. [init ] giving control to process supervisor. [supervisor ] loading services... [supervisor ] loading service 'default'... [supervisor ] loading service 'app'... [supervisor ] loading service 'gui'... [supervisor ] loading service 'certsmonitor'... [supervisor ] service 'certsmonitor' is disabled. [supervisor ] loading service 'nginx'... [supervisor ] loading service 'xvnc'... [supervisor ] loading service 'openbox'... [supervisor ] loading service 'CrashPlanEngine'... [supervisor ] loading service 'logmonitor'... [supervisor ] loading service 'logrotate'... [supervisor ] all services loaded. [supervisor ] starting services... [supervisor ] starting service 'xvnc'... [xvnc ] Xvnc TigerVNC 1.13.1 - built Nov 17 2023 22:53:44 [xvnc ] Copyright (C) 1999-2022 TigerVNC Team and many others (see README.rst) [xvnc ] See https://www.tigervnc.org for information on TigerVNC. [xvnc ] Underlying X server release 12014000 [xvnc ] Sun Dec 17 13:58:14 2023 [xvnc ] vncext: VNC extension running! [xvnc ] vncext: Listening for VNC connections on /tmp/vnc.sock (mode 0660) [xvnc ] vncext: Listening for VNC connections on all interface(s), port 5900 [xvnc ] vncext: created VNC server for screen 0 [supervisor ] starting service 'nginx'... [nginx ] Listening for HTTP connections on port 5800. [supervisor ] starting service 'openbox'... [supervisor ] starting service 'CrashPlanEngine'... [supervisor ] starting service 'app'... [supervisor ] starting service 'logmonitor'... [logmonitor ] Monitoring log file: /config/log/service.log.0 [logmonitor ] Monitoring status file: /config/log/app.log [supervisor ] all services started. [xvnc ] Sun Dec 17 14:01:00 2023 [xvnc ] Connections: accepted: /tmp/vnc.sock [xvnc ] SConnection: Client needs protocol version 3.8 [xvnc ] SConnection: Client requests security type None(1) [xvnc ] VNCSConnST: Server default pixel format depth 24 (32bpp) little-endian rgb888 [xvnc ] VNCSConnST: Client pixel format depth 24 (32bpp) little-endian bgr888 [xvnc ] ComparingUpdateTracker: 0 pixels in / 0 pixels out [xvnc ] ComparingUpdateTracker: (1:-nan ratio) [xvnc ] Sun Dec 17 14:02:51 2023 [xvnc ] VNCSConnST: closing /tmp/vnc.sock: Clean disconnection [xvnc ] EncodeManager: Framebuffer updates: 276 [xvnc ] EncodeManager: Tight: [xvnc ] EncodeManager: Solid: 358 rects, 6.95102 Mpixels [xvnc ] EncodeManager: 5.59375 KiB (1:4854.82 ratio) [xvnc ] EncodeManager: Bitmap RLE: 9 rects, 22.649 kpixels [xvnc ] EncodeManager: 303 B (1:299.353 ratio) [xvnc ] EncodeManager: Indexed RLE: 163 rects, 119.039 kpixels [xvnc ] EncodeManager: 16.9863 KiB (1:27.4872 ratio) [xvnc ] EncodeManager: Tight (JPEG): [xvnc ] EncodeManager: Full Colour: 121 rects, 393.092 kpixels [xvnc ] EncodeManager: 227.301 KiB (1:6.76167 ratio) [xvnc ] EncodeManager: Total: 651 rects, 7.4858 Mpixels [xvnc ] EncodeManager: 250.177 KiB (1:116.914 ratio) [xvnc ] Connections: closed: /tmp/vnc.sock [xvnc ] ComparingUpdateTracker: 6.28056 Mpixels in / 4.15748 Mpixels out [xvnc ] ComparingUpdateTracker: (1:1.51067 ratio)

Ugh. I realize now that I created the new account with a different email.

Is there a way to get a JRE installed with the MakeMKV docker? This comes up because of Lionsgate blurays.... Ugly details are here: But the main point is that Lionsgate obfuscates the correct playlist. When a JRE is present, MakeMKV can often figure out the correct playlist and flag it. I recently ran into this. Right now, the workaround is to rip on a host where I do have a JRE and then transfer the files to my unraid Plex server. But it would be nice to not have to remember "oh, this is a Lionsgate disc...."

More searching and I stumbled across this I suspect I need to do the same thing but, near as I can tell, ther is no equivalent setting in my BIOS 😞

Because I can't quite leave this alone, I kept poking. It looks like this is because of the VGA card I selected, or at least where in the box it is. My motherboard is a Supermicro X9dai, 2 Xeon E5-2695, 512 GB RAM. This board has no onboard video. I have three GPUs installed; alas, I have no control over which GPU the motherboard decides to pick, it seems to pick the lowest slot number and I can't override that. Two of the GPUs are nvidia GTX 1060, one is a GT 710. I had planned on setting up the GT 710 as the video for unraid and using the other two for the dockers. But the 710 is in a higher numbered slot and the spacing on the M/B is such that I can't put it into a lower slot. I had been using the nvidia module in unraid because I had dockers that were using the GPUs. That's no longer true, so I removed it and rebooted. Alas, that didn't seem to matter. To have full access to all the PCIe slots, you must have both CPUs installed, which I do. If I used the GTX 1060 at 03:00:00, it works. This is the one that unraid has also selected as the primary. If I select the GTX at 82:00:00, the VM starts, but hangs someplace before the network starts and there is no logging to figure out what's happening. If I select the GT 710 at address 04:00:00 and the GTX 1060 at address 82:00:00, then both cards work. Now the part that confuses me is that I believe physical CPU0 controls three of the slots, and physical CPU1 controls the other three. The VM has assigned cores from both physical CPUs. But it doesn't seem to matter if I pick cores only from physical CPU0 or physical CPU1, it still won't access that card at 82:00:00 until it also is accessing the card at 04:00:00. And it really is that card; If I give the VM both of the 1060s, it still hangs and I can't connect. It also seems to be important that the GT 710 is the first GPU. I also get an error when swapping things around. It pops up once when trying to start the VM, then the second attempt to start the VM is fine. 2021-12-29 21:04:48.813+0000: 20242: error : qemuProcessReportLogError:2097 : internal error: qemu unexpectedly closed the monitor: 2021-12-29T21:04:48.770188Z qemu-system-x86_64: -device pcie-pci-bridge,id=pci.8,bus=pci.1,addr=0x0: Bus 'pci.1' not found There really seems to be something stateful about the changes, meaning it seems to remember not just what the current setting is, but something about previous settings. After the last hour of messing with this, my UEFI VM is, in fact, booting, but it's lost its network connection; connecting now via VNC, it has no network devices. I've spent most of today going through permutations, but I don't really understand QEMU enough to read through the configs and understand what I'm looking at to figure out what got changed between these iterations and what it means. I've got a configuration that I can make work, and think I'm going to call it quits 😕

Well, the only thing I'm certain of at this point, is that attempting a GPU passthrough is the kiss of death to your VM. The vdisk is still usable, but something ends up scrambled in the XML. I may try this one more time with a before and after snapshot of the XML to see what gets broken there.

I have an Ubuntu 20.04 VM I use for image processing. It would benefit from GPU passthrough and I have two GPUs just sitting in the machine doing nothing right now.... I've seen a number of trouble reports on getting the GPU passthrough to work correctly with 6.9 (I'm running 6.9.2), but thought I would give it a shot. I was not particularly surprised when the VM didn't seem to boot; I couldn't ssh into the host. Then a normal shutdown of the VM failed, so I had to do a force stop. I removed the GPU passthrough and rebooted, planning to check the host logs. But... it never came up. Connecting via VNC, I saw only "no bootable device". The obvious check, that the vdisk is still configured, was the first thing I did. It is, and the file is there. It's not a horrible loss if I have to rebuild from scratch; the software for image processing lives on that VM, but the data lives in the array. But I'd like to understand what exactly happened here and how to recover, not the least of which is because without logging to to check the host logs, I don't see how I can diagnose what failed with the GPU passthrough.

Yes, jlesage/makemkv:v1.18.1 does work!