cybrnook

Sure, but there is still a problem. This is a good disc to use to expose it.

Sicario: Day of the soldado If you have a movie store near you that rents.

That's what I am waiting on too. Model motherboards, serial number ranges, want to see it in action, what's it's signature on a network, what to look for, etc...

Any luck?

I notice the same behavior 🙂 seems almost like "burps" of high CPU, then it goes back to %50 until it burps again.

@johnnie.black In their detailed breakdown, which is linked in the article I linked above, there is what I believe to be a good summary: "Bottom line, if this Supermicro attack vector is to the BMC, then the Bloomberg story is no bigger than the Dell EMC PowerEdge iDRACula story or any others. Saying there is a vulnerability in a BMC is like saying the sun is hot." and "First and foremost, I think we need to call for an immediate SEC investigation around anyone who has recently taken short positions or sold shares in Supermicro. With the accompanying Supermicro stock price hit that was foreseeable prior to the story, if anyone knew the story would be published, and acted on that non-public or classified information, the SEC needs to take action. There seems to have been over 20 people that knew about this." "Further, with public companies making statements on the impact, unless there is a valid national security/ classified reason that they gave the responses they did, there is a mismatch. Apple and Amazon did not say “no comment” they called Bloomberg’s account false. The SEC needs to investigate here as well to see if these were publicly misleading statements."

Seems he slightly disagrees https://www.servethehome.com/yossi-appleboum-disagrees-bloomberg-is-positioning-his-research-against-supermicro/

That's how it's appearing. And seems that instead of copying, we could fix it by adding more PATH directories as well, though untested.

I think it's an Alpine Linux and Java related issue.

Nothing special, I am not as picky. I just use the default Fast 1080p 30fps as that's good enough for me.

Strange, I still see the same failure if I use MakeMKV to convert to mkv format. HOWEVER, that's not what I did last night. I use MakeMKV to "Backup" my disc's (whole disc, removing encryption), and then I use HandBrake to convert for me since it generates an equal quality video at a fraction of the size. Try "Backup", and see if that works now. If it does, use Handbrake to then encode it to mp4. (Chapter 354 I believe)

Looking at the playlist file you are parsing 00095.mpls, is it Sicario? I ran it last night, and it went fine after the change. Your errors almost look like a firewall type issue between your unraid server and elsewhere.

You have to be doing something wrong, your command shouldn't be interpreted as "sh" (I suspect your are trying to copy/paste the command?)..... /tmp # which cp /bin/cp /tmp # cp -p /usr/lib/jvm/java-1.8-openjdk/jre/lib/amd64/jli/libjli.so /lib /tmp # ls -l /lib/libjli.so -rwxr-xr-x 1 root root 55320 Jun 13 14:46 /lib/libjli.so /tmp # ldd /usr/bin/java /lib/ld-musl-x86_64.so.1 (0x149e9e174000) libjli.so => /lib/libjli.so (0x149e9dd64000) libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x149e9e174000) libz.so.1 => /lib/libz.so.1 (0x149e9db4d000) /tmp # And YES, the change does retain after a container restart 🙂

Sorry, type this command manually: cp -p /usr/lib/jvm/java-1.8-openjdk/jre/lib/amd64/jli/libjli.so /lib Respect there is a space between libjli.so and /lib

Either option is going to be within the container os itself. I would recommend this for now: CONFIRMED: This fixed it, and ripping works again - no segfault: /usr/bin # cp -p /usr/lib/jvm/java-1.8-openjdk/jre/lib/amd64/jli/libjli.so /lib I am not sure if it will be persistent through container reboots yet, haven't tried. You can click on your container icon and there is a terminal option to get you there. I wanted to submit a pr, but I think this will need to be handled in the base Alpine os that's being used for the container. So Djoss will need to get it.

Also seeing the java segfault: Other users seem to relate this to the JAVA version: https://www.makemkv.com/forum/viewtopic.php?f=3&t=17268 I know unrelated, but there is a broken symlink in /usr/bin as well: appletviewer -> ../lib/jvm/default-jvm/bin/appletviewer Maybe this helps, perhaps a compile error? (https://github.com/docker-library/openjdk/issues/77): /usr/bin # ldd java /lib/ld-musl-x86_64.so.1 (0x1483185c6000) Error loading shared library libjli.so: No such file or directory (needed by java) libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x1483185c6000) Error relocating java: JLI_Launch: symbol not found /usr/bin # whoami root CONFIRMED: This fixed the backup issue, and ripping works again - no segfault: /usr/bin # cp -p /usr/lib/jvm/java-1.8-openjdk/jre/lib/amd64/jli/libjli.so /lib /usr/bin # ldd java /lib/ld-musl-x86_64.so.1 (0x1479396b8000) libjli.so => /lib/libjli.so (0x1479392a8000) libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x1479396b8000) libz.so.1 => /lib/libz.so.1 (0x147939091000) However, the more permanent fix I think is to add the proper path variables as suggested by "echa" in the link above.

Too early to tell. Something like this feels more like a focused attack, and may not represent SM as a whole, but perhaps some compromised links in the supply chain. I doubt this is at the consumer board level. All my boards right now are SM, and I have no plans to change atm.

You would have to believe though that prior to publishing this article, it would have had to pass the editor as well as receive approval that the sources were valid, right?

Haven't tested yet, hope to do so this weekend. Didn't realize you were interfacing with the program itself through the setup scripts. I thought you were just appending into the standard app with additional functionality. Meaning autoripper would work, but GUI driven wouldn't. Great news then! Thanks, and look forward to testing my friend. (Sorry for assuming)

@DJoss Thanks for all your help, and patience with everyone in the forums. It is appreciated. I just wanted to circle back on that UMASK for backup mode issue. I saw the commit update you did against the autoripper, nice job. I did want to point out that the container has the same issue when using Backup Disc from within the GUI itself, wasn't just using autoripper. Not sure if there is/was anything you can do about that.

You don't HAVE to buy a key. But in that case, if you do stick with the BETA key, you will have gaps in time where the current key expires, and Mike hasn't posted a new one yet. Normally about a week or two in between. If you get tired of that, buy a key, then follow DJoss's instructions on changing from BETA key to UNSET and then add your key in the GUI.

https://www.makemkv.com/forum/viewtopic.php?t=1053 I bought Key a while ago, good to support the development

Also confirmed no longer needed on X10SRH-CLN4F

+1 If you test, let me know please.

Thank you very much.