11-12 should be well tested. 12-13 should be well tested. 11-13 may work, but you may be the tester.

I’d step through one at a time.

Bummer. You could get a cheap IoT light bulb/smart plug and ping it in a script, when it times out, start the shutdown. Could be a fun project.

Some (most?) UPSs have a way for them to communicate to the PC so that the PC can automatically cleanly shutdown. You should look into that if its available on your UPS.

Good luck!

Should be fine, the UUIDs are specified in the filesystem’s themselves. They shouldn’t change unless your filesystems get corrupted.

Upgrade away, should all work fairly flawlessly.

Yeah, it prevents booting on that motherboard, but they can just yank your disks and boot it on another motherboard.

Normally, a good bios password implementation shouldn’t reset with CMOS battery, but for yours it seems it does.

Bios passwords dont provide security at all. At most, mild theft prevention (that is trivially bypassed). If you want security, disk encryption is what you want.

Replace your CMOS battery, NTP is good to, but you really don’t want your CMOS freaking out.

Whats your goal? Your current network works presumably, what are you trying to achieve by upgrading? Faster network? Reliability? Expansion options?

Our AI meeting generator has sent you a meeting suggestion with an OP who matches your interests. Don’t miss an opportunity - accept requests!

Ctrl-alt-Fnumber until you get to a tty shell. Login, run journalctl - f. Ctrl-alt-Fnumber until you get back to login screen, and login. Go back to tty and see what errors got logged.

If you have ssh enabled you can also ssh in and run the journalctl cmd. You’ll have to try different F number keys, I dont remember which ones get you a tty and which gets you the login. Start at F1 and move across, but wait a bit, sometimes it can take a while to spawn the TTY.

Conceptually, not a problem. Windows 11 runs on top of HyperV with no performance issues. In reality, I think you will spend a lot of time, hit lots of weird edge cases and performance issues, especially with trying to get the Linux and windows hosts to coexist nicely.

That said, I’d love to watch you try :)

Thats hot. And I am going to assume this is canon from now on.

Ok furry artists, you know what to do, I wanna see the filthiest Visa x MasterCard art you can dream off. Payment process me baby

https://www.rancher.com/ - If you want a pure docker OS.

But really, almost all of the mainstream OS’s will run docker just fine. Pick the one you are comfortable with.

Oh, well, if it requires a password that is pretty much solved. The original commentor made it seem a lot less hands on.

I was under the impression that the shim let OS’s boot all the way up, and that it was just a standard part of the boot process, I was suggesting instead that the signed binary only let’s you add a new key, which you can then use to boot without the shim.

Doesnt help when the key expires though.

Thanks for the additional info, greatly appreciated.

Having read up a bit more on mokutil, seems that it doesnt enroll the key by itself, but gets the uefi firmware to prompt the user to add the key at next boot. Which in theory gets around the malware risk, although given how many people auto-click accept, maybe not.

The other way keys could be securely installed would be for the distros to produce a uefi “addmykey” binary, with their keys baked in to the binary. They then get that signed by the MS key, which would allow that image to boot and setup the key without ever disabling secureboot. You wouldnt need to have a trusted PC either, as if the binary was tampered, it wouldn’t boot.

100% agree on the risk profile though, far too many people think they are more important than they really are. Realistically, most of us aren’t worth the effort to individually break into our computers.

I personally dont think MS did it out of maliciousness, more indifference. They wanted the security benefits, and didn’t care what it cost others. But we’ll likely never know what their true intent was.

I dont know how the bazzite script does it, but any tool that can be executed from userspace that could add keys could just as easily be abused by malware to add their own signing keys, which completely defeats the purpose. Edit: see princessnorah’s comments below for more details, but it is a lot more hands on, which prevents malware abusing it.

In an ideal world, Redhat, Canonical, Suse etc could have gotten their verification keys built into every motherboard, but that still cuts out the Arch/Gentoo/flavour-of-the-month crowd. And also increases the risk that a signing key gets leaked and abused by malware.

Its just not an easy problem to solve.

That should exactly fix the problem.

The real issue is that by default, if secure boot is enabled, you won’t be able to boot up into bazzite or whatever in order to run that command.

So the user experience will be worse now, because instead of just installing and running, Linux users have to disable secure boot, boot and install their distro, run that enroll command, and then reenable secureboot. And lots of people are going to give up at step 1, and leave secureboot off.

As you’ve described it, and from what I have read, its very similar to how tailscale negotiates its connections.

Does seem to be unique to Plex though.

I get how that could work, but what services actually do that? Homeassistant can, but that needs to be setup explicitly for it to work.