Re: update-initramfs
On Tue, 11 Apr 2023 Marc Auslander wrote:
On 4/10/2023 11:00 PM, David Wright wrote:
On Mon 10 Apr 2023 at 20:17:11 (-0400), Marc Auslander wrote:
I'm on Buster.
In /boot I keep a copy of the current working linux named by appending
-knowngood to the four files. My idea is that if an update fails, I
have a recent working linux. This is different from vmlinuz.old which
is the previous kernel version. The updates in question are not to
the kernel but to initrd.image of course.
Suddenly, update-initramfs insists in trying to first update
initrd.....-knowngood which of course fails because there are no
underling file with that name. This never happened in the past,
AFAIK. Once it fails it gives up.
There seems no way to force update-initramfs to update the right kernel.
Perhaps check that "all" hasn't been accidentally inserted:
$ grep update /etc/initramfs-tools/update-initramfs.conf
# Configuration file for update-initramfs(8)
# update_initramfs [ yes | all | no ]
# If set to all update-initramfs will update all initramfs
# If set to no disables any update to initramfs beside kernel upgrade
update_initramfs=yes
$
A workaround: change the sort order of the backup initrd files
by adding an appropriate prefix, like backup-knowngood-…
so the "real" ones get updated first.
Cheers,
David.
thanks but that's the first thing I checked - it's yes, not all. But my
backup names contain the current version string.
I'm not sure about the sort order hack. My goal is to have update-grub see
the knowngood as a bootable linux and include it in the boot menu. That's
also why .bak of initrd isn't good enough - I need a complete copy.
Caveat: I don't know WTH I'm doing. Also, I used a bullseye system for
experiments below, not buster.
I read update-initramfs(8) and did a couple experiments, one to
replicate your observations on my bullseye system, and then a variant
of David's version-naming hack.
Results are summarised below, in case you find them interesting.
EXPERIMENT #1
The first experiment simply tried to replicate your observations (as I
understood them). Basically, I added "-kg" suffix to all the files in
/boot corresponding to latest installed kernel, so that I had
unsuffixed copies and "*-kg" ("knowngood") copies, and then tried
# update-initramfs -u
which, as you report, targeted the "*-kg" files (and turned a 28M
initrd.img-*-kg into a 6M file... no longer warranting the suffix
"-kg").
Also (after making fresh "*-kg" copies), I tried
# update-initramfs -u -k all
which went first for the "*-kg" files, trashed the initrd.img-*-kg as
before, but then continued on to update all the other versions.
EXPERIMENT #2
The second experiment is similar to david's suggestion, but alters the
end of the name instead. (I didn't think of using a prefix.)
The manual implies that...
update-initramfs -u
...by default tries to update the "latest" kernel version. The
following result suggests that it determines which files correspond to
that "latest" version by just looking at their filenames.
So basically instead of only adding "-kg" to the files in /boot, I
decremented the last character of uname -r and *then* added "-kg", so
that it wouldn't look like a later version.
# knowngood=( /boot/*-$(uname -r) )
# for ((i=0 ; i<${#knowngood[@]}; i+=1)) ; do cp -a "${knowngood[i]}" "${knowngood[i]/%4/3-kg}" ; done
# ls -l
total 105464
-rw-r--r-- 1 root root 206413 20 déc. 17:56 config-4.19.0-23-amd64
-rw-r--r-- 1 root root 236452 21 janv. 09:35 config-5.10.0-21-amd63-kg
-rw-r--r-- 1 root root 236452 21 janv. 09:35 config-5.10.0-21-amd64
drwxr-xr-x 5 root root 4096 11 avril 01:28 grub
-rw-r--r-- 1 root root 26109076 10 avril 21:59 initrd.img-4.19.0-23-amd64
-rw-r--r-- 1 root root 29199065 10 avril 21:58 initrd.img-5.10.0-21-amd63-kg
-rw-r--r-- 1 root root 29199065 10 avril 21:58 initrd.img-5.10.0-21-amd64
-rw-r--r-- 1 root root 3418327 20 déc. 17:56 System.map-4.19.0-23-amd64
-rw-r--r-- 1 root root 83 21 janv. 09:35 System.map-5.10.0-21-amd63-kg
-rw-r--r-- 1 root root 83 21 janv. 09:35 System.map-5.10.0-21-amd64
-rw-r--r-- 1 root root 5303616 20 déc. 17:56 vmlinuz-4.19.0-23-amd64
-rw-r--r-- 1 root root 7019136 21 janv. 09:35 vmlinuz-5.10.0-21-amd63-kg
-rw-r--r-- 1 root root 7019136 21 janv. 09:35 vmlinuz-5.10.0-21-amd64
# update-initramfs -u
# update-initramfs: Generating /boot/initrd.img-5.10.0-21-amd64
# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.10.0-21-amd63-kg
Found initrd image: /boot/initrd.img-5.10.0-21-amd63-kg
Found linux image: /boot/vmlinuz-5.10.0-21-amd64
Found initrd image: /boot/initrd.img-5.10.0-21-amd64
Found linux image: /boot/vmlinuz-4.19.0-23-amd64
Found initrd image: /boot/initrd.img-4.19.0-23-amd64
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
done
So update-grub didn't seem to complain.
I haven't tried booting yet with my "5.10.0-21-amd63-kg" initrd,
though. I'll leave that to you, if you want to try.
--
Hackers are free people. They are like artists. If they are in a good
mood, they get up in the morning and begin painting their pictures.
-- Vladimir Putin
Reply to: