151–160 of 460 posts
Earlier quoted context omitted.
It could kexec other kernels but probably won't be able to jump to other OS bootloaders after it already called ExitBootServices.
Theoretically, couldn't it just write to a "boot this image next time" field (is the legacy MBR area available?) and trigger a reboot?
Earlier quoted context omitted.
The Linux kernel does not require an initramfs. You can build a kernel with everything compiled in; with no modules needed at all. Initramfs is used for generic kernels where you don't know beforehand which features will be required. This allows you to avoid wasting RAM on features you don't use. But it is optional.
What's the reason it doesn't load those modules from the regular filesystem? That's what FreeBSD does, and seems to work well enough?
I personally think they're moving in the wrong direction. I'd rather have "NMIRFS" (no more initramfs). Eg, a smarter bootloader that understands all bootable filesystems and cooperates with the kernel to pre-load modules needed for boot and obviates the need for initramfs. FreeBSD's loader does this, and its so much easier to deal with. Eg, it understands ZFS, and can pre-load storage driver modules and zfs.ko for t…
And if this bit is closed source, and something doesn't work, you don't have a recourse.
Except that doesn't work in the real world, where encrypted and authenticated boot disks are increasingly common. So you'll need a significant amount of code that isn't the permanently-resident kernel that has enough device support to access keys and decrypt and authenticate what holds the kernel that will launch the OS. IOW, you'll just have to reinvent a bootloader anyway. Or you can address the problems with GRUB,…
I've thought about something like this before, but I have so many questions on just the basic premise... First: Linux could already be booted directly from the UEFI manager. You don't need GRUB at all. So why a new scheme - why weren't they just doing that? Second (and third, etc.): If I have multiple Linux installations along with a Windows installation, wouldn't this mean one of them now has to be the one acting as…
Booting linux directly just boots you into that install. It doesn't give you a boot menu or any of the other functionality GRUB provides. This project is basically proposing building that in a small initramfs userland instead (which has the advantage of requiring much less effort and code duplication). It's functionally very similar to GRUB, including with regard to your last point: generally speaking at the moment o…
I indeed understood that part, but their motivation for this was security. If you want security, you should want to boot directly into the kernel. And if you're the occasional user who has multiple OSes installed in parallel... you can just add more kernels from your dual-boot installs directly to the UEFI screen; there's really no need to go through any form of intermediate stage, whether kernel-based or boot-loader-based.
What I'm trying to say is: as cool as this is from a technical standpoint, I just don't understand the root of the premise or motivation here whose optimal solution is this approach. Whom is RedHat trying to please with this? The small fraction of users who dual-boot Linux, or the rest of the users who just have a single install? And what problem are they actually trying to solve -- security, performance, or something else? Because the optimal solution to the first two doesn't feel like this one, unless they're targeting a niche use case I'm not seeing? e.g., do they have lots of enterprise users that boot off a network, but whom would rather have a local Linux install whose sole job is to boot that...?
Earlier quoted context omitted.
The Linux kernel does not require an initramfs. You can build a kernel with everything compiled in; with no modules needed at all. Initramfs is used for generic kernels where you don't know beforehand which features will be required. This allows you to avoid wasting RAM on features you don't use. But it is optional.
Is anyone really wanting to get back into the business of building their own kernels? I started using Linux heavily in '92, and I've built a lot of kernels, and am quite happy to not be building them anymore.
Though I only do it for my ARM based devices currently.
And if you're not throwing away build artifacts after each build, then getting stable updates is just a `git pull` and incremental make, which is usually very quick.
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? Yes, because it cannot be part of the kernel image, or it would be illegal (a violation of the GPL license) to distribute that kernel. Therefore, it must be a module, and that module has to live somewhere and be loaded by something. If root is on ZFS, this must therefore live in an initramfs and be loaded by it so that the i…
Earlier quoted context omitted.
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…
> instead of immediately loading the System A userland I mean, it kind of is loading the System A userland. At least the initramfs of it. AFAICT in the proposal the bootloader would now be a regular userland program living in the initramfs. I get the impression that the eventual goal would be to make this bootloader program into the "init(8) but for the initramfs phase of boot" — i.e. rather than there being a tool l…
I’m fairly technical but I have to say grasping the field of partitions , booting, boot loaders grub uefi its alternatives and the various combinations thereof in Linux defeated me. When learning something I try to find the simple path, a reliable minimum that gets to the goal. I never found it. Complexity is the word that comes to mind.