The bootloader is one of the weirdest and scariest things to change in Linux.

Nice work, but please allow me to remind you that the rule for speaking in situations like this is extremely simple, applicable to every context whether live or recorded: always, Always, ALWAYS, ***ALWAYS*** REPEAT THE AUDIENCE QUESTION BEFORE RESPONDING.

Two questions: Can I create two /boot partitions (on different physical drives) with the same UKI on each, and that way if one drive dies, the other one will still let the machine boot? Is PXE booting this kind of thing possible? Normally you template a kernel cmdline but it's inside the UKI?

I mean sure, when i first know anything about OS in general i always had the same unanswered question "Why don't we just boot straight into the OS itself?"

@gormless-idiot

13 күн бұрын

Looks like my comment got deleted but you can already do that with an EFI stub

@tibbydudeza

11 күн бұрын

To load a custom OS setup - in the old days of Intel servers there were different approaches to incorporate multi CPU's and memory into a server which Microsoft did not support in NT. That was before Intel/AMD standardized these concepts. Each vendor like SGI and others supplied their own kernel addons so that Windows NT could start up and initialize the hardware properly.

@study9003

10 күн бұрын

Its just the standard begin like this , but dont think the uki is not like bootloader , its the same as the bootloader but its just tiny and contains the initramfs and the kernel in it , so you boot directlly , but there is the stub thing wich is the magic happen

I don't understand the use-case here. systemd boot already exists, it can already boot UKI images. Even better, you can sign the UKI and not rely on SB Shims. Sooo, why do we need this tool?

@dustycarrier4413

8 күн бұрын

There is no point. It's not even using the kernel anymore than using SystemD Boot or GRUB is. It being in the kernel codebase is meaningless.

I was expecting this to replace UEFI too, as that is extremely complex too. For a virtual machine, could you not use something like CoreBoot? Or given that you know most of the state of the virtual machine manager, you could boot straight into the kernel.

@user-yf3et2rs9i

21 күн бұрын

I see all of what you indicated to be a somewhat radical concept. Wintel a.k.a. the Windows authorities do not encourage this at all with their software, or more to the point how OEMs help delegate BIOS frameworks in their hardware. Given genuine crypto concerns regarding computer and network security, this improvement alone makes a real case for moving to forcing them to allow all operating systems on personal computers within the realm of private area networks, without individuals having to change numerous settings in BIOS and hope that the responsible OEM or manufacturer supports their operating system preference.

@BobHannent

19 күн бұрын

You'd have to convince all the hardware vendors to distribute something else that's in opposition to Windows, that's not likely to happen.

putting SHIM in the boot stack and talking about security is like giving the keys to the vault to a thief and calling it protection. Anyone who understands security knows that SHIM is the ultimate joke in the security world

@rapamune

17 күн бұрын

Can you elaborate for people who do not know about the disadvantages to a SHIM approach, and what an alternative would be?

@PragandSens

15 күн бұрын

some microsoft haterboi here, secure boot its actually secure, it introduces the concept of chain of trust, nmbl minimizes the surface area... dude comeon

@RaphaelBastosakaCoffnix

15 күн бұрын

@@PragandSens Relying on SHIM is a bad joke-you're trusting a closed-source giant like Microsoft to secure an open-source Linux system. This dependency increases your attack surface, complicates updates, and ultimately undermines the whole idea of Secure Boot. If Microsoft's keys get compromised, your trust chain collapses. It's laughable to see open-source advocates leaning on the very entity that historically opposed them. Ditch SHIM and secure your system properly.

@RaphaelBastosakaCoffnix

15 күн бұрын

@@rapamune If your hardware can't store its own keys, using SHIM is prohibitive-upgrade your hardware immediately.

@thialfi2289

15 күн бұрын

@@rapamune I am very much not an expert on this but I'll attempt to explain it how I understand it. Because Windows is installed everywhere the Microsoft secure boot keys are installed in basically every UEFI so that they will automatically boot into Windows but pretty much nothing else (at least with secure boot enabled). If you want to be protected by secure boot when running another OS you have two options: use your own keys (will no longer boot into windows) or use a bootloader that is also signed by Microsoft's keys such as shim. Then when booting up you can choose between windows and shim and shim will then allow you to boot into a pre-approved application. One disadvantage of using shim is that you are still using Microsofts secure boot keys. This means that you have left a door into your system for any software signed by the Microsoft keys and you are trusting them to keep the keys safe. If you don't plan on dual booting with windows, it's easy enough to setup your own secure boot keys using tools like sbctl and removes the risk of someone trying to boot your system with software you haven't personally approved. Personally I don't think this is worth worrying that much about since 1 - if you are an interesting enough target that someone is putting this effort into breaking into your system they will find something that works and 2 - if they have that level of access to your system there are almost certainly easier approaches they can take to get access to whatever information they want. I'd only worry about it if you're super security conscious but if you are then you definitely shouldn't be taking advice from me.

Would this make it easier to have distros run OOB on arm SBCs? Now they need to be customized and released by SBC vendors. Or is that a completely separate issue?

@jmennius

10 күн бұрын

It is completely separate because the issue is with HW configuration discovery - something that is handled with ACPI on x86 but it is not present on ARM, so you have to have a device tree telling the kernel all about available devices.

@jylpah

8 күн бұрын

@@jmennius This is btw my #1 reason to avoid ARMs and stick with x86.

I still don't see how this will help anything. The only thing i see this as is a in kernel GRUB rewrite that's supposed to be lightweight but once you use this on real hardware that's full of bugs on the hardware and UEFI level you will see this project become just as bloated as GRUB because otherwise it will just not work on many configurations. I hope I'm wrong and I just completely misunderstood this from this short video but that's how i see it. I'll check this out again once it's tested on actual hardware. So gummiboot it is for now

@study9003

10 күн бұрын

I didnt see the video actually , but i have using UKI mounths now , its really good thing , you eliminate thd grub thing you just boot directlly from the firmware , i dont see possible bugs unless its a kernel bug , in that case grub it self wouldnot boot it , and the stub thing is light , and the uki simplify the proccess of using secure boot if you want , and also in archlinux for example it gived you the a simple choise to add a splasb screen at boot , for the systemd thing , dont usd it ! really ، if you using mkinitcoio/dracut , thier capable of making uki without the systemd bloat , finally to boot it you create an efi entry using efibootmgr

Pre-Linux/x86 the boot loader was very minimal and the main goal was to get the kernel in and running with as little additional code as possible. Examine retro hardware boot processes for details.

Typically if it's an idea from red hat, I'm not thrilled about it. At least not until workers own the company. Which isn't likely with IBM owning red hat.

Very welcome idea!

This would be based if it allowed to update/reload something like android system linux kernel at runtime.

@necromancygood

5 күн бұрын

Kexec exists

This is so obvious it hurts. Why is my OS not bringing up the System that Operates my hardware?

@gormless-idiot

14 күн бұрын

Because the kernel isn't the operating system. There's no practical advantage to putting a bootloader into the kernel unless you're trying to turn the kernel itself into the OS.

The bootloader still exists, it's just in the UEFI now

Still too complex: boot directly into Poettering, erm, systemd. The system _manager_ is the _system_, don't fuzz around with a kernel.

Make an alternative to ventoy and build on grub-emu with advanced functionality (like sounds and animations) people who rice will go nuts, and not just linux users, people doing windows sysadmin / sys-ops too.

Yes but what about dual booting? I mean, its bad enough that Grub has disabled OS prober, and you have to do complicated horseshit to dualboot using systemd-boot. This will only give one more annoyance for potential new linux users not to use linux in the first place in fear of not being able to use another OS of their choice, even if that so happens to be windows.

"Please stop using a bootloader. Please instead use our TotallyNotABootloaderTM" aahh presentation

Please replace the sysvinit instead

@MrAlanCristhian

16 күн бұрын

You saying that we shold replace the kernel with systemD? - distro developers

@IanMonroe

14 күн бұрын

done

Replace systemd.Please..

@gormless-idiot

14 күн бұрын

It's called OpenRC bro you just gotta use Gentoo

This will only be used to make approved OS Kernels sanctioned by EFI Key holders.

@IanMonroe

14 күн бұрын

it's still using the shim, why would it be different

Awesome presentation, but you deserve better audience. What the hell is wrong with these people, constantly coughing, smashing doors or farting. What is wrong with them? At least have some decency and respect the presenter … Jeez

@IgnoreMyChan

20 күн бұрын

No, this is fully to blame on the organization of the venue. The sounds you hear are 'normal people noises' that you'd also hear at other talks, movies or theaters. The problem is the mic placement and that it had to be way to sensitive to make the speaker audible. In that regard, It also always amazes me how they can fck up the Q&A portion of these recordings every time. You can't hear any of the questions.

Why are redhat employees hell bent on destroying Linux? 😢

lol this is pure insanity

bloat, just use efistub and use uefi as the bootloader.