The recent #UEFI#vulnerability - the decoder for the #boot#logo image is buggy, so you can fashion an image that will get full pre-secure-boot control of the machine at the #firmware level - seems to be getting way too much credit. Am I wrong here?
To be able to drop your specially-constructed image in the EFI system partition on a Linux machine, you need root privileges. So you need a chained remote-root vulnerability first.
:boost_requested: :boost_animated: :boost_ok: #FollowerPower: Anyone with #Linux - #boot|ing #KnowHow able and willing to take a look why my current build of OS/1337 doesn't boot?
It's a 1440kB 3,5" #Floppy image and should work just fine in #VirtualBox / #QEMU / #KVM / #vmware but it's stuck after loading #Linux (bzImage) and the remaining files (rootfs.cpio.xz)...
The cleaning up of /boot will in future be handled by our configuration tool Tomte in TUXEDO OS, although you can of course decide whether Tomte should take over this task.
For anyone woundering "why do you use the latest @linux#Kernel release?"
Well, I want OS/1337 to be basically 'rolling release' in that I can't be bothered #backporting stuff and I just want to pull the #releases straight from said projects.
Okay, I've not listed #syslinux & #mkdosfs and #dd which I used in making the #Floppy image but those basically don't really change much at all. We all know how #FAT12 works...
Currently I just need to find out what went wrong and see how I can make OS/1337 go brrrrrr.
So if anyone has any ideas, please feel free to contact me: https://mstdn.social/@kkarhan/111409592616485280
Also #boosts appreciated!
:boost_ok: :boost_requested: :boost_animated:
Day has already started of VERY good: Steam Deck doesn't want to boot anymore 🙄 - It is just stuck at the verify installation step...
I guess it is because of the last beta update I downloaded a few days ago.