| From: Giles Orr via talk <talk@gtalug.org> | | - I think raw GRUB still works from a single .conf file that can be | edited by hand. The problem you're seeing is that most distros have | built out a complex system to construct and replace that .conf file | whenever a new kernel arrives. The assumption is of course that mere | mortals shouldn't be touching that config. I learned a lot about | GRUB2 configuration at one time, but I don't mess with Fedora's GRUB | config system.
Yes. Fedora follows a proposed standard. I discovered this in boilerplate comments in Fedora's grub.cfg, albeit with an obsolete URL (I submitted a bugzilla about this). <https://systemd.io/BOOT_LOADER_SPECIFICATION/> | - Nicholas mentioned the in-place replacement of kernels: I think(?) I don't think so. But maybe. | I've seen that behaviour on Debian with same-version kernels with | security updates, but I don't think I've ever seen it for any reason | on Fedora. Are you talking about on-the-fly kernel updates? kexec? kGraft/kpatch/ksplice? <https://en.wikipedia.org/wiki/Kexec> They've always seemed scary. | - if you have a separate /boot/ partition (very likely these days) and | you're never deleting kernels, you stand a good chance of over-filling | that partition and getting into trouble, particularly on Fedora which | likes to push a new kernel every couple weeks. You'll want to keep an | eye on the space remaining in /boot/ and delete some of the newer | kernels you don't need by hand. Good point. I see no point in a separate /boot so I never configure one. Is there a point? Does /boot have enough to fsck / before mounting it? /boot/efi is the ESP (EFI System Partition), a dedicated FAT partition that is required by UEFI. Generally kernels are not placed there. So it doesn't grow that much. If you did put the kernel+intramdisk in the ESP, you could probably boot Linux via UEFI without the aid of GRUB. I don't know of distros that do this. It's kind of tempting to cut out a whole layer of complexity. (You may have discussed this on your blog -- I don't remember.) --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
