On 2019/08/04 09:13, Stasiek Michalski wrote:
Besides, some of the limitations that come with the spec (although aren't present in grub implementation in Fedora/RHEL)
Why not? Should we be using that version?
are the lack of subdirectories for boot entries as well as the lack of ability of booting linuz/initrd from non-boot partitions. openSUSE by default has boot partition set to /boot/efi, and keeps the kernel and initrd in /boot, which prevents bls compatible software
"bls-compatible?"
(namely systemd-boot) from working. This happens due to systemd-boot not mounting anything but the boot partition, while GRUB just mounts everything as it exists, slowing down the boot process, but allowing booting from each and every one of the devices present in the system.
For speed, would it be impossible to only load the kernel you want to boot from using lilo? I use lilo and go from boot to multi-user prompt in about 20-25s. I'm not using an SSD, but a 3-disk RAID 5 for boot (HW RAID).
Why does openSUSE have boot partition mounted to /boot/efi? Snapshots. We can't have kernel and initrd in snapshots if the boot partition is FAT-like, so the /boot is mounted as a btrfs submodule, while /boot/efi is a FAT-like partition which can be used by EFI.
--- Nothing supports snapshot except btrfs? FWIW, I can probably backup and restore my boot partition in less time than it would take someone to restore a snapshot (boot is only 206M used), root 3.2G and /usr 12G), though I certainly don't have snapshot granularity. from kernel unpack + hardware probe to mount of root: 6.2s /boot -> mount of root is 6.204s; init stars at 6.25s init @ 6.25s /usr mounted @ 6.88s module loading from disk network cards init xfs mount of 48TB storage (192TB as RAID10)12.98-13.42s then 6s for the server services to come up to multi-user login prompt.
A way to make systemd-boot work with existing structure would be to copy current initrd and linuz to /boot/efi on every new kernel install alongside a new bls entry file. It would finally justify the recommended size of the partition and make a giant mess of the filesystem stucture.
A good question here is if we need kernels covered under snapshots, the older kernels along with initrd assigned to them are already accessible from GRUB either way.
LCP [Stasiek] https://lcp.world
--- Without initrd, your kernels could be alot smaller. I seemto remember going through a disk analysis sometime back on the opensuse list, and kernel+initrd took about 20M more/version. My kernels run about 6.9m in 4.17 and 7.5m in 5.2.4. with my lib/modules taking from 21M->29M for 4.17->5.24, but I modularize just about every possible kernel option that I might want to try. With, I think wicked, it could be adapted to build a bootable kernel for customers that wanted it (no ramdisk required). 'sgi' and other unix vendors did that for their customers 20 years ago -- provided a script to make a direct-bootable kernel without a bunch of extra HW options, so I'm pretty sure it would be doable today.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org