Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

No more boot loader: Please use the kernel instead

pretalx.com

Post reply on HN
Print view View original

351–360 of 460 posts

Re: No more boot loader: Please use the kernel instead

#351

Post by abofh »

1oooqooq wrote: post #321

I will translate the doublespeak from redhat, which is similar to how they started to push systemd (really). > [grub] features create complexity that is difficult to maintain, and that both duplicate and lag behind the Linux kernel while also creating numerous security holes. No mention of the alternatives. No mention how useful are those features. Handwaiving "security" arguments. > Loaded by the EFI stub All the ta…

To be fair, it's similar because it's the problem people wanted solved - start this thing at boot, if it dies, restart it. I know rcS.d didn't handle the 'restart it', but even for the lowliest desktop user, if they've installed a daemon, and configured it to start, it more or less implies they'd like it to keep running.

Systemctl looks a lot like a modern init on another OS because a modern init on any OS looks a lot the same. Whether it should spawn 1800 subprojects is a different debate, but I for one am much happier maintaining trivial .ini like files than trying to teach the new engineer bash.

Re: No more boot loader: Please use the kernel instead

#352

Post by kbolino »

lproven wrote: post #316
medstrom wrote: post #110

Earlier quoted context omitted.

You're talking about something like ZFS, and I get that they can't just compile it in, but a distro can still ship the module, if I'm not mistaken. ...But to load it at boot time it absolutely must be done through an initramfs. Is that right?

> ...But to load it at boot time it absolutely must be done through an initramfs. Is that right? No, not AFAICS; it is incorrect. On UEFI the system boots from a FAT32 partition. Put the kernel directly on that FAT32 partition, and any necessary modules such as ZFS, and the kernel can load the ZFS module from FAT32 and then mount root directly without any need for an initramfs. This is how systemd-boot works. I am no…

If you can size the EFI partition yourself, or it's already big enough (e.g. you didn't install Windows first), then yes this makes more sense.

Re: No more boot loader: Please use the kernel instead

#353

Post by [deleted] »

FeepingCreature wrote: post #251
kbolino wrote: post #81

Earlier quoted context omitted.

Given the reason why "out-of-tree modules" exist, there's really no way to eliminate initramfs or something like it entirely in the general case. It might be possible to speed up the process of building the image (as long as the results are not "redistributed"), but this is a licensing and legal problem, not a technical one. FreeBSD is under a much more permissive non-copyleft license and so can legally bundle things…

You could probably build a "virtual initramfs": - linux tells the bootloader what folder the modules live - bootloader just puts them all in memory - linux just picks what it needs. That's all the initramfs is anyways. The point is there's no reason to prebuild an image from inside Linux, you can just have grub assemble a simple fs on the fly.

[deleted]

Re: No more boot loader: Please use the kernel instead

#354

Post by DEADMINCE »

worthless-trash wrote: post #350
DEADMINCE wrote: post #227

Earlier quoted context omitted.

> Is this 'couldn't' a self imposed requirement or a technical one I can't think of ? Probably not technical. There is another element, obtaining a HDD encryption key from the TPM. The idea that the HDD is encrypted outside of my laptop and nothing can boot on my laptop that isn't my signed OS to read it. Thinking about it I probably could do everything in the kernel directly - why not? Well, because it would be extr…

Just to be clear, this is signing for validation not encryption of the contents. I wrote a guide on this topic of ensure platform integrity of system level (See https://wmealing.github.io/tpm-pcr07.html ) its not too hard.

> Just to be clear, this is signing for validation

Yup. I was just referencing wanting to obtain keys from the TPM to decrypt a partition. This is useful for me to have the following setup:

- Laptop turned on, no keys pressed, boots into super locked down guest OS.

- Laptop turned on, certain key pressed within 2 seconds, boot into 'hidden' OS.

- In both cases, HDD is encrypted, decrypted automatically via retrieving keys stored in the TPM. This means the harddrive cannot be read outside of that particular laptop, unless keys are extracted from the TPM.

- Bootloader signed with own key, any and all existing keys wiped, so laptop cannot be booted with any external OS.

How would I recreate that setup with nmbl?

That's a good link by the way, thanks - saved.

Re: No more boot loader: Please use the kernel instead

#355

Post by gray_-_wolf »

jchw wrote: post #140
bityard wrote: post #108

Earlier quoted context omitted.

Let's say I have a dual-boot system with two totally independent OSes, Systems A and B. It is powered down. I want to boot into System B but the EFI is configured to boot into System A by default. Am I correct in understanding that the offered solution here is to first boot into System A, find some well-hidden EFI configuration utility (which varies from OS to OS, if it even exists), and then tell EFI to boot into Sy…

Sort of, except it's automated. Basically, System A's kernel boots. But, instead of immediately loading the System A userland, it loads a boot menu of systems that it reads from UEFI NVRAM and presents it to the user. So you select System B from the list, the menu sets BootNext in NVRAM and issues a reboot. In practice, the main UX difference is that it takes a bit longer and you'll see the UEFI vendor splash screen…

I wonder if I have ever had a laptop where the UEFI worked correctly and without bugs. It always required some workaround somewhere to get stuff working.

Re: No more boot loader: Please use the kernel instead

#356

Post by prmoustache »

korhojoa wrote: post #305
prmoustache wrote: post #289

Earlier quoted context omitted.

Most mainboards comes with an integrated gpu though? If you use that one for the host OS, it is easy to pass the discrete through no?

Consumer motherboards haven't had gpus for a while now (IPMI usually comes with one, so servers do), they're built in to the CPU (if they are, not all cpus have them). These can't usually be easily allocated to a vm.

I clicked randomly on a number of motherboards sold by the 2 brands that came to my mind, Asrock and Gigabyte, and all of them advertised hdmi and usb-c graphics output so I am surprised by your declaration that consumer motherboards don't have GPU. If I am not mistaken on AMD Ryzen architecture it comes down to choosing a CPU with a G or 3D suffix which states they have an integrated GPU.

Re: No more boot loader: Please use the kernel instead

#357

Post by prmoustache »

lolinder wrote: post #346
prmoustache wrote: post #315

Earlier quoted context omitted.

My experience when I had a dual boot in the late 90's was that rebooting is such an interruption that you never become fully comfortable on one of the OS. You just stick to the OS you are used to and never really do the switch. While if don't dual boot you can switch completely to another OS and only use VM or remote desktop for the handful of use cases when you aren't ready yet (and then end ip abandoning them compl…

> the late 90's was that rebooting is such an interruption that you never become fully comfortable on one of the OS Keep in mind that booting takes a tiny fraction of the time today that it did in the 90s.

Regardless if it takes 20 seconds or 2 minutes it is still an interruption.

Re: No more boot loader: Please use the kernel instead

#358

Post by E39M5S62 »

account42 wrote: post #304
E39M5S62 wrote: post #188

It's nice to see more people embracing the capabilities of UEFI and Linux. ZFSBootMenu has been shipping an EFI application (really, a UKI masquerading as one) for almost four years now - https://docs.zfsbootmenu.org/en/v2.3.x/ . The neat part is that the first stage kernel boots in roughly 1.5 to 2 seconds. It's not really appreciably slower than other boot methods while at the same time exposing a substantial amoun…

> The neat part is that the first stage kernel boots in roughly 1.5 to 2 seconds. It's not really appreciably slower than other boot methods while at the same time exposing a substantial amount of pre-boot functionality. That sounds 1.5 to 2 seconds slower than just having efistub in your main kernel image, which honestly is a LOT. Of course not possible with problematic drivers like ZFS but then you don't have to us…

Yes, and then your main kernel image is no longer on ZFS and you lose the ability to reliably roll back your root dataset. Everything is a trade off. I reboot my workstation once a week for a kernel upgrade, so an extra 2 seconds of boot time isn't even a consideration.

Re: No more boot loader: Please use the kernel instead

#359

Post by eyeris »

prmoustache wrote: post #356
korhojoa wrote: post #305

Earlier quoted context omitted.

Consumer motherboards haven't had gpus for a while now (IPMI usually comes with one, so servers do), they're built in to the CPU (if they are, not all cpus have them). These can't usually be easily allocated to a vm.

I clicked randomly on a number of motherboards sold by the 2 brands that came to my mind, Asrock and Gigabyte, and all of them advertised hdmi and usb-c graphics output so I am surprised by your declaration that consumer motherboards don't have GPU. If I am not mistaken on AMD Ryzen architecture it comes down to choosing a CPU with a G or 3D suffix which states they have an integrated GPU.

It really still is the case that most if not all consumer motherboards don’t have built in graphics. For the most part especially on the intel side, they’ve relied on the iGPU in the CPU for output for probably 10 years now

Re: No more boot loader: Please use the kernel instead

#360

Post by [deleted] »

ack_complete wrote: post #219
zamadatix wrote: post #69

Earlier quoted context omitted.

I'm not sure I experienced the same with the Windows boot loader so maybe that behavior was something case specific instead of intended?

Not sure, there might have been a fast path if you were booting to another Windows 10 install. The old legacy Windows Boot Manager also doesn't have the issue since it's much simpler and it executes in faux text mode before the OS boots.

[deleted]
Post reply on HN