[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: update-initramfs



On Wed 12 Apr 2023 at 07:50:33 (-0400), The Wanderer wrote:
> On 2023-04-12 at 07:44, Michel Verdier wrote:
> > Le 12 avril 2023 The Wanderer a écrit :
> > 
> >> Without anything more, wouldn't that just result in an extra
> >> GRUB-menu entry pointing to the same copy of the kernel/etc.?
> > 
> > Of course he can change menuentry to point to another kernel/initram
> 
> From what I understand matters, the problem is that after he creates the
> copy of the initrd, update-initramfs (as run by update-grub) fails,
> because the underlying files which it thinks would be needed by an
> initrd with the filename that the copy has don't exist.
> 
> >> As I think I understand matters, the goal is to have a duplicate
> >> copy of the kernel/etc. *and* a separate GRUB menu entry pointing
> >> to it, so that if something blows away or otherwise messes up the
> >> original the duplicate is still around to serve as a fallback.
> > 
> > Yes if he points menuentry to the backup he got this fallback.

By my reckoning, the "fallbacks" in this context are old kernel
versions, kept in case the newer version of the kernel doesn't work.

> The question would therefore be how to have the backup copy without
> resulting in this update-initramfs failure happening.

But in what other situation would you make backups, and then store
them all mixed in with the active versions?

> About the only possibility I can think of would be to *also* copy the
> respective underlying files, so that they are available under the name
> update-initramfs expects to see. That would probably make the backup -
> and the process of creating it - noticeably more unwieldy, however.

But why ever /process/ backup copies? Surely you just repeat backing
up the latest updates whenever you've ascertained that they're good.
If you place the backups under a different, non-active directory, then
they won't get accidentally seen by update-initramfs and tampered with.

> And it's entirely possible that there's some aspect of the process I'm
> not seeing which would mean that that wouldn't work.

The only minor difference I see from a typical backup scenario is
that you probably want this set of backups to be quickly available
for the Grub menu to read. Whether that means being included /in
the menu/ is moot. I would maintain that this failure mode is rare
enough for a reasonable penalty of having to type a few characters
editing the Grub menu.

The last time I booted a kernel that was on a different partition
from my installed Grub, it took no more than typing 23 characters
and a load of rubouts. (That was after installing bookworm RC1.)

Cheers,
David.


Reply to: