Re: [gentoo-user] UEFI data corruption? [FIXED]

[Mick]

On Sun, 29 Sep 2019 at 13:25, Neil Bothwick <neil@××××××××××.uk> wrote:
>
> On Sun, 29 Sep 2019 11:59:00 +0100, Mick wrote:
>
> > As I understand it, 'bootctl --update' can be used to update
> > systemd-boot boot manager's menu and it is looking for bootable
> > kernels by scanning /efi, /boot, and /boot/efi, or the directory set
> > by passing the '--path' option to it.  Manual addition of bootable
> > kernels must be set via /loader/entries/*.conf (one file per kernel
> > image) and then setting the default kernel to be booted in
> > /loader/loader.conf.  I find all this to be unnecessary complication
> > for maintaining a boot manager manually, compared to using say
> > efibootmgr.  However, it is handy to be able to press 'e' to edit the
> > default entry at boot time, or if new kernels are always stored where
> > expected by the scripts of binary distros.
> >
> > For Peter's use case, OS and kernel resides on secondary disk, the
> > solutions I can think are:
> >
> [snip GRUB bit]
>
> > 2. Use systemd-boot.  Copy each kernel from the secondary disk to
> > /boot/EFI/ creating the corresponding /loader/entries/*.conf, adding
> > the kernel .conf name and the OS root partition's path on the
> > secondary disk.  The root path can also/instead be included in the
> > kernel itself (CONFIG_CMDLINE).
>
> That's not how the systemd boot manager works. It is a bootable image
> which then reads the config from /boot/loader and presents a boot menu.
> As far as the firmware is concerned, it is always booting the same image.

Thanks Neil, I bow to your superior knowledge on systemd-boot - I've
only come across it on binary distros and did not have to interfere
with its settings.  I think we're saying the same thing.  I understand
that using a predictable naming convention for *.conf files will load
the corresponding kernel images in turn, but the default kernel can be
overwritten in loader.conf instead of using a wildcard which will pick
up the first *.conf file in line.  Also, these .conf files will not be
created with 'bootctl --update' unless all requisite OS kernel images
have been stored in the ESP.

> The loader files are analogous to grub.cfg, but a thousand times simpler
> (I may be understating that in my desire to avoid hyperbole). For
> example, loader.conf here is
>
> timeout 3
> default 00-*
>
> This never needs to be modified, it simply boots the first entry after 3
> seconds.

Right, but if the OP wants to boot some other kernel (which happens to
be on his second disk) systemd-boot's image picking up the first
*.conf file won't be of use.  He'll need to select another kernel from
the menu or set this in the loader.conf as a semi-permanent solution.
Please correct as necessary if I got this wrong.


> Incidentally, I use a short shell script to regenerate the menu entries
> after a kernel change, like grub-update but the predictable orders of
> magnitude shorter, so even that is trivial.

Yes, I expect Peter will also need to use some script of sorts if he
wishes to automate this process, or manage it manually.

-- 
Regards,
Mick