Re: What's the purpose of initrd.img{,.old} and vmlinuz{,.old} symlinks in the root dir?
On Sun 01 Mar 2020 at 15:09:34 (+0100), Mikhail Morfikov wrote:
> On 01/03/2020 02:15, David Wright wrote:
> > They're a convenience. If you want them kept in /boot, then edit
> > /etc/kernel-img.conf and linux-update-symlinks will recreate them
> > there when the kernel is updated. Ditto if you want them removed.
> I didn't know there's even such an option. But yes, it creates links
> in /boot/ now.
Excellent.
> >> Also, I'm trying to configure refind EFI boot manager, and
> >> basically I don't want to change its config file with each kernel
> >> update (the numbers in the file names change).
> >
> > I'm not familiar with that, but one of the reasons there are links
> > in root is for that very reason: their names don't change.
> That's why I need those links in /boot/ , so refind would easily pick
> them up.
>
> > You don't say why *you* think it's better to create links in /boot,
> > so I'm not sure why we're expected to think so too. But if you want
> > them in both places, I think you have to maintain them in the other
> > location yourself.
> I thought it was obvious, but I write it again to be clear. I'm using
> LUKSv2+LVM setup and (so far) syslinux/extlinux as a bootloader in
> MBR/MS-DOS partition layout (this will change to refind + EFI soon).
Yes, as I said, I don't know anything about their capabilities.
I've read here that Grub can decrypt LUKS, but currently only v1,
at least in buster, so no help to you.
> So my machine is encrypted entirely, and only the /boot/ (and future
> ESP) partition remains unencrypted. When my system creates the links
> to the initrd and kernel in / , they're useless since you have to
> decrypt the root partition in order to get to those links, and in
> order to decrypt the partition, you have to load the kernel first,
> but when you load the kernel, you don't need the links anymore... So
> as you can see the better place for the links is in /boot/ and not
> in / , at least in the case of fully encrypted installation setups.
In your case, that sounds sensible. Hence the option I described, I guess.
Cheers,
David.
Reply to: