You definitely shouldn't have hardware problems, so there's one stress off your mind at least. Now just recovery.

Assuming you didn't do anything to drastic, you've probably only broken the EFI. This is not he wrost case by far. I would do the following:

• make a Linux live USB, as suggested in the other comments.
• boot up and inspect your disks and the current partition layout.
• double check that your windows drive (NTFS partition) at least exists, bonus points if you can access it, don't stress yet if you cannot.
• given you were going to overwrite fedora, I would delete those partitions, and the opens use ones if they exist as well, and start with a blank segment of disk to work from.
• (optional) expand your boot partition to 500MB/1GB. Small cost really, and will save you future pain if you're exploring other distros. You may have to move the windows partition to do this, this is usually safe enough to do with a GUI partition manager (gparted), perhaps riskier on CLI. Just take it slow and be sure with the steps. Check data access after it's done.
• go back through the install process for opensuse, it should be able to automatically create all the needed partitions with the empty space you have left on the disk.
• boot opensuse, rejoice.
• make a windows boot drive, boot into that and perform a recovery. Note that this might break grub, depending how Microsoft is feeling that day. Second worst case is that you'll have to redo your boot ordering. Worst case is that you'll have to hope back into a live USB and regenerate grub.

Unfortunately, I think we've all had that panic (plugging a monitor into the motherboard and not the GPU). welcome to the club!

Can you get into the BIOS/UEFI menu? Typically by pressing [DEL] or [F12] in the first few seconds of boot. From there, there's generally a menu to either select to order (put the USB drive at the top of the list), or on fancier menus, the "Save and exit" page may even have a "Boot device [USB]" button.

The EFI partition is a section of your harddrive.that contains bootable binaries(?). In UEFI mode, your motherboard scans all harddrives EFI partitions. I believe they are always FAT32, marked with a "boot" flag, and essentially contains folders for each OS bootloader.

I'm simplifying quite a bit I suspect, but that's the gist of it.

Your harddrive will be in either MBR or GPT mode, selected when you or your first OS made the partition table. Any modern system should have picked GPT, and I don't think windows uses MBR anymore either. Bit fuzzy on that one.

The "architecture" as you describe it is a partition format, or how the data is "physically" arranged on that section of the disk; fat32, NTFS, ext4, btrfs, etc. Skipping over a heap of context, This is something that is specific to each partition, and is selected more out of convention or preference than anything else. There are a few exceptions, but in general, your boot drive will be fat32 (as above), windows generally will use NTFS for its main partition (other special partitions may use other formats), Linux may use many different formats, but by general convention it would be ext4 (this is a very sweeping statement, but I think its a good place to start).

I think the other takeaway here is that it was found in a section marked "unsafe". At the very least, that's a useful tool for the Devs to isolate potential problem areas. Comparing that to a pure C codebase where the problem could be anywhere.

Is this not the equivalent of asking someone on the street to pay for a fence for your property so you don't have to look at them?

They made an init system called systemd, and it worked way better than anything prior.

Then they realised that to have a functional and maintainable system, you need a bunch of other system level tooling to be in and around about the same layer as the unit system (time sync, base network, disk mounting, etc.). All of these other things got spun off as daemon projects, for example "systemd-timesyncd". And all got good and consistent command line tooling that made things relatively convenient.

The downside is now power-users saw systems taking over their computer and "violating the Unix philosophy". I would argue that at some level, it doesn't. They've made a suite of relatively independent tools all part of the same group with the purpose of managing the system. It gets things running, it gets users logged in and out, it tells you what when wrong, and it will restart things if it can. System management, do one thing and do it well.

I think the fact is that managing a modern system in a way that "just works" is complicated challenge. Many people either haven't run Ubuntu 9, and done a software update, or have repressed a lot of those memories.

Is it perfect: no. Is it the best model we have so far: I would say so.

We have similar kinda of boxes in Australia, usually they are monitoring stations for the energy infrastructure provider. Can be cellular or long range radio links.

Start using and efistub and never worry about boot loaders again!

You need to get little bud a new shirts every few months with an extra spiderman pointing each time!

If you execute a parent, you end up with living or zombie children that you need to find and put down.

"Aircons don't work without power, or for people with no access to power"

Easy. Pico Henry. Not sure why chemists are so concerned with such a small amount of magnetism though...

Linux has native AMD drivers, no need for anything extra!

we were hacked.

How?

The remote code execution step of our toolchain was used to run remote code.

Also a good spot for sunglasses!

I think you might be underestimating uptake. Google suggests upwards of 50% usage. Also I'm fairly certain that a lot of residential infrastructure has been slowly moving to IPv6 in Australia at least. Not an overnight process, but it's happening. Over here we have a lot of newer mobile plans offering IPv6 as well.

I think a big holdback is that a lot of larger corporations will still use IPv4/NAT setups at the top level, even if all of the hardware in the network supports it. "If it's not broke don't fix it." The result is huge amounts of daily traffic coming from these institutions being IPv4 by default, with all devices in WiFi, etc, being lumped into the same group.

Not sure about mpv, but I use a gstreamer pipeline to tender cameras to the raw KMS terminal display. It works much more reliably (I.e. Predictable loading times and no stutter) compared to loading a DE first. Noting that it was on a low power RPI.

Puppy Linux might be an option if that project is still going.

They're using FPGAs.

The people here talking about a display server (x11/Wayland) are missing your point I think. If you put a display server on this "box" then it will become a normal server, not a headless one. At that point, you may as well run a full VM and have the output go wherever you want, etc. I'm not sure what the equivalent is in the docker world, but I'm pretty sure that's not what you're asking for.

Is it possible for you to get SSH running on this "server"? If so, you may be able to set it up with an SSH client on the host PC (the laptop?) that is full screen on the CRT/HDMI output?

Maybe I'm misunderstanding as well though. Any headless server I've used in Linux will still give you a TTY on the display. Do you not get that? Someone else mentioned Getty, which is likely the service that is managing that. You should be able to configure Getty to give you a specific tty (e.g. tty9) on a specific output, then configure it either to autologin or to run a script on that tty.