rbroberts

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, that's what I did. I'll pull down the standalone version and give it a try. I'm not sure where to find the BIOS event log.

I'm getting a machine check error that looks like a memory error. So I took the array down and had it run memtest86 over the weekend and there were no problems found. But... it keeps happening. The machine is a Supermicro X9DAi, with dual Intel Xeon CPU E5-2695 v2, 512 GB of DDR3 ECC RAM. One obvious question is whether or not the memory controller is hiding the error from memtest86 so that it does happen but I can't find it. Jun 1 04:40:07 Tower root: Fix Common Problems: Error: Machine Check Events detected on your server Jun 1 04:40:07 Tower root: Hardware event. This is not a software error. Jun 1 04:40:07 Tower root: MCE 0 Jun 1 04:40:07 Tower root: CPU 0 BANK 13 TSC 159a9f0821204 Jun 1 04:40:07 Tower root: MISC 900000400040c8c ADDR 42c306000 Jun 1 04:40:07 Tower root: TIME 1622506605 Mon May 31 20:16:45 2021 Jun 1 04:40:07 Tower root: MCG status: Jun 1 04:40:07 Tower root: MCi status: Jun 1 04:40:07 Tower root: Corrected error Jun 1 04:40:07 Tower root: MCi_MISC register valid Jun 1 04:40:07 Tower root: MCi_ADDR register valid Jun 1 04:40:07 Tower root: MCA: MEMORY CONTROLLER MS_CHANNEL0_ERR Jun 1 04:40:07 Tower root: Transaction: Memory scrubbing error Jun 1 04:40:07 Tower root: MemCtrl: Corrected patrol scrub error Jun 1 04:40:07 Tower root: STATUS 8c000046000800c0 MCGSTATUS 0 Jun 1 04:40:07 Tower root: MCGCAP 1000c1d APICID 0 SOCKETID 0 Jun 1 04:40:07 Tower root: MICROCODE 42e Jun 1 04:40:07 Tower root: CPUID Vendor Intel Family 6 Model 62 Jun 1 04:40:07 Tower root: mcelog: warning: 8 bytes ignored in each record Jun 1 04:40:07 Tower root: mcelog: consider an update Jun 1 05:06:58 Tower kernel: mce: [Hardware Error]: Machine check events logged Jun 1 05:06:58 Tower kernel: EDAC sbridge MC1: HANDLING MCE MEMORY ERROR Jun 1 05:06:58 Tower kernel: EDAC sbridge MC1: CPU 12: Machine Check Event: 0 Bank 10: 8c000042000800c1 Jun 1 05:06:58 Tower kernel: EDAC sbridge MC1: TSC 19f1ad61ad6a1 Jun 1 05:06:58 Tower kernel: EDAC sbridge MC1: ADDR 45dcace000 Jun 1 05:06:58 Tower kernel: EDAC sbridge MC1: MISC 90840200020048c Jun 1 05:06:58 Tower kernel: EDAC sbridge MC1: PROCESSOR 0:306e4 TIME 1622538418 SOCKET 1 APIC 20 Jun 1 05:06:58 Tower kernel: EDAC MC1: 1 CE memory scrubbing error on CPU_SrcID#1_Ha#0_Chan#1_DIMM#0 (channel:1 page:0x45dcace offset:0x0 grain:32 syndrome:0x0 - area:DRAM err_code:0008:00c1 socket:1 ha:0 channel_mask:2 rank:255)

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

I'm also getting a "fatal error occurred, program will not exit" while manually scanning a disk. This isn't happening for every disk, and so far, it's just this one, Monster Hunter (2020). Debug log started at Mon May 24 01:31:49 2021 , written by MakeMKV v1.16.3 linux(x64-release) 001005:0000 MakeMKV v1.16.3 linux(x64-release) started 001004:0000 Debug logging enabled, log will be saved as file:///config/MakeMKV_log.txt Using 262272KB for read cache. Network access is ENABLED, CURL version 7.58.0/OpenSSL/1.1.1 (x86_64-pc-linux-gnu) , proxy server not set. 001003:0020 DEBUG: Code 0 at x4I7N2~a46M>:KH-Kp0hI^:29393631 SDF v07e: HL-DT-ST_BD-RE__WH14NS40_1.01_211304042325_K9BD4Q62426 SDF v07e: HL-DT-ST_BD-RE__WH14NS40_1.01_211304042325_K9BD4Q62426 001011:0000 Using LibreDrive mode (v06.2 id=94DE7D3D0ADE) 003007:0000 Using direct disc access mode 005085:0000 Loaded content hash table, will verify integrity of M2TS files. DEBUG: Code 2147483648 at Hk&nzPc`mXELw9{):121264625 001003:0020 DEBUG: Code 0 at Hk&nzPc`mXELw9{):29396966 Found java version=1.8.0.275 path=/usr/bin/java 003344:0000 Using Java runtime from /usr/bin/java Any suggestions on how to proceed? I'm getting a segfault in the server log when running java, at least I think this part of the log is the relevant section May 23 21:24:48 Tower kernel: vethf7c4303: renamed from eth0 May 23 21:24:48 Tower kernel: docker0: port 10(veth8a2b051) entered disabled state May 23 21:24:48 Tower kernel: docker0: port 10(veth8a2b051) entered disabled state May 23 21:24:48 Tower kernel: device veth8a2b051 left promiscuous mode May 23 21:24:48 Tower kernel: docker0: port 10(veth8a2b051) entered disabled state May 23 21:24:57 Tower kernel: docker0: port 10(veth7671832) entered blocking state May 23 21:24:57 Tower kernel: docker0: port 10(veth7671832) entered disabled state May 23 21:24:57 Tower kernel: device veth7671832 entered promiscuous mode May 23 21:24:59 Tower kernel: eth0: renamed from veth7e0d1e6 May 23 21:24:59 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth7671832: link becomes ready May 23 21:24:59 Tower kernel: docker0: port 10(veth7671832) entered blocking state May 23 21:24:59 Tower kernel: docker0: port 10(veth7671832) entered forwarding state May 23 21:25:24 Tower kernel: makemkvcon[37041]: segfault at 8 ip 00000000007ac79b sp 00001489921b1f20 error 4 in makemkvcon[48d000+391000] May 23 21:25:24 Tower kernel: Code: ef 05 41 c6 86 60 01 00 00 00 31 f6 89 7c 24 54 44 89 44 24 64 45 84 c0 0f 84 e7 02 00 00 40 84 f6 b8 00 00 00 00 49 0f 44 c7 <8b> 70 08 48 8b bc 24 90 00 00 00 e8 c5 c2 e9 ff 41 8a b6 60 01 00

Ah, a bit more reading makes it obvious why that's the magic to make this work. Thanks frankman1!

cache should be some physical disk, either a hard drive or ssd. Otherwise, unraid will map it to memory and it all goes away at reboot. I've made that mistake....

While that looks useful, I'm still not clear on why the docker image would balloon when the paths are mapped to actual storage. I was under the impression that the docker image would only grow from things that were not on mapped storage.

How big should this container get? I'm getting warnings about my docker image running out of space and this is the chief offender with the log taking up 19.6 GB. Is that supposed to be the mapped log directory in my config? Because that is mapped to /mnt/cache/appdata/gitlab-ce/log and that directory has files written in the last 20 minutes, as I shut it down, and is only 2.6 GB. I can kill off the docker image and expand it's allocation, I'm just not clear what this is trying to tell me.

Unfortunately, not that I can find. But that did remind me, I have crashplan-pro running and checking there, I do have a backup of the config directory. I guess I forgot that I had actually planned ahead 🙂 But... in the other good news category, I've "discovered" the testdisk utility. After using dd to get a raw image, I've mounted the USB drive in my ubuntu laptop and was able to copy the backup boot sector onto the primary and repair the drive. There's a moderate amount of corruption. Depending on the state of my crashplan-pro backup, I may or may not lose the dockers and VMs.