This reverts commit 7f2ed354cc8f966de444b8c278c208ea4e13ef75.
When installing a kernel package and a package with a trigger for
update-initramfs in one go, the update of the initramfs is skipped in
some cases.
In a clean chroot, populated with debootstrap for "trixie", run
```
apt install linux-image-amd64 plymouth-theme-mobian
```
Result:
```
[...]
Setting up linux-image-6.12.32-amd64 (6.12.32-1) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-6.12.32-amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-6.12.32-amd64
I: /vmlinuz is now a symlink to boot/vmlinuz-6.12.32-amd64
I: /initrd.img is now a symlink to boot/initrd.img-6.12.32-amd64
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-6.12.32-amd64
Setting up linux-image-amd64 (6.12.32-1) ...
Setting up plymouth-theme-mobian (1.1) ...
update-alternatives: using /usr/share/plymouth/themes/mobian/mobian.plymouth to provide /usr/share/plymouth/themes/default.plymouth (default.plymouth) in auto mode
Processing triggers for libc-bin (2.41-8) ...
Processing triggers for initramfs-tools (0.148.2) ...
update-initramfs: /boot/initrd.img-6.12.32-amd64 has already been updated since Mon Jun 23 06:07:09 2025.
```
The initramfs is updated after setup of the kernel package. It is NOT
updated again after setup of package plymouth-theme-mobian, which is
wrong. The files that are installed by package plymouth-theme-mobian are
missing in the initramfs (and the plymouth splash screen will not work).
This is what happens here:
1. Another package is installed that calls "update-initramfs -u". This
activates the trigger, and we store a timestamp for it.
2. linux-image-6.12.32-amd64 is installed. This calls the
initramfs-tools hook which synchronously builds the initramfs.
3. plymouth-theme-mobian is installed. This activates the trigger
through a triggers control file.
4. The trigger runs and passes the timestamp from (1) through to
update-initramfs. update-initramfs sees the current image is newer
than that, and skips the update.
We correctly handle the case where the trigger is only activated through
`update-initramfs -u`, or only through a triggers control file or direct
invocation of dpkg-trigger. But when both methods are used, this bug is
possible because a timestmap file is present and it is wrong.
So revert the optimised trigger handling until dpkg itself records
timestamps for trigger activation (see bug #1099136).
Closes: #1108204
When installing/upgrading packages (e. g. a kernel and initramfs-tools),
the same initrd is generated twice:
```
$ apt-get install --no-install-recommends -y zstd initramfs-tools linux-image-generic
[...]
Setting up initramfs-tools-core (0.146) ...
Setting up initramfs-tools (0.146) ...
update-initramfs: deferring update (trigger activated)
Setting up linux-image-6.12.20-amd64 (6.12.20-1) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-6.12.20-amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-6.12.20-amd64
I: /vmlinuz is now a symlink to boot/vmlinuz-6.12.20-amd64
I: /initrd.img is now a symlink to boot/initrd.img-6.12.20-amd64
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-6.12.20-amd64
Setting up linux-image-amd64 (6.12.20-1) ...
Processing triggers for initramfs-tools (0.146) ...
update-initramfs: Generating /boot/initrd.img-6.12.20-amd64
```
Remember the timestamp when the dpkg trigger is set in the file
`/run/update-initramfs.dpkg-trigger`. Then only update the initramfs if
it is not newer than the time the trigger was created.
This will solve the example given above:
```
$ apt-get install --no-install-recommends -y zstd initramfs-tools linux-image-generic
[...]
Setting up initramfs-tools-core (0.146) ...
Setting up initramfs-tools (0.146) ...
update-initramfs: deferring update (trigger activated)
Setting up linux-image-6.12.20-amd64 (6.12.20-1) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-6.12.20-amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-6.12.20-amd64
I: /vmlinuz is now a symlink to boot/vmlinuz-6.12.20-amd64
I: /initrd.img is now a symlink to boot/initrd.img-6.12.20-amd64
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-6.12.20-amd64
Setting up linux-image-amd64 (6.12.20-1) ...
Processing triggers for libc-bin (2.41-6) ...
Processing triggers for initramfs-tools (0.146) ...
update-initramfs: /boot/initrd.img-6.12.20-amd64 has already been updated since Tue Mar 25 11:48:49 2025.
```
This approach will not help, when the update-initramfs trigger is set by
another package (e. g. clevis-initramfs). That would need support from
the dpkg trigger (see Debian bug #1099136).
LP: #1466965
When installing/upgrading packages (e. g. a kernel and initramfs-tools),
the same initrd is generated twice:
```
$ apt-get install --no-install-recommends -y zstd initramfs-tools linux-image-generic
[...]
Setting up initramfs-tools-core (0.145) ...
Setting up initramfs-tools (0.145) ...
update-initramfs: deferring update (trigger activated)
Setting up linux-image-6.12.16-amd64 (6.12.16-1) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-6.12.16-amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-6.12.16-amd64
I: /vmlinuz is now a symlink to boot/vmlinuz-6.12.16-amd64
I: /initrd.img is now a symlink to boot/initrd.img-6.12.16-amd64
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-6.12.16-amd64
Setting up linux-image-amd64 (6.12.16-1) ...
Processing triggers for libc-bin (2.40-7) ...
Processing triggers for initramfs-tools (0.145) ...
update-initramfs: Generating /boot/initrd.img-6.12.16-amd64
```
Add a `-s` parameter to `update-initramfs` to set a Unix time stamp
(seconds since 1970) for the update mode. An existing initramfs will
only be updated if it is not newer than the specified Unix time stamp.
This feature is the first step to avoid generating the initrd twice.
LP: #1466965
Since `cp -a` serves as fallback, there's no need to clutter
the output.
Before:
```
$ sudo update-initramfs -u
ln: failed to create hard link '/boot/initrd.img-6.1.0-3-amd64.dpkg-bak' => '/boot/initrd.img-6.1.0-3-amd64': Operation not permitted
update-initramfs: Generating /boot/initrd.img-6.1.0-3-amd64
```
After:
```
$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.1.0-3-amd64
```
Signed-off-by: szubersk <szuberskidamian@gmail.com>
In some old shell versions, string comparisons in [ ... ] could go
wrong if the first argument began with certain characters. It has
been common practice to avoid this problem by prefixing both sides
with 'x'.
bash and dash have not had this problem for well over a decade, so
clean this up.
Further details are at <https://www.shellcheck.net/wiki/SC2268>.
Signed-off-by: Ben Hutchings <benh@debian.org>
update-initramfs used to keep track of which initramfs images it
created and "owned", to avoid overwriting the output of another
coinstalled initramfs generator. As discussed in #765750, this is no
longer a concern and the state checks have been removed.
Now that I'm confident this hasn't caused a regression, also remove
the state updates and the state directory. After this, there is no
turning back: a downgrade will leave update-initramfs owning nothing.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
The direct invocation of update-initramfs in kernel package maintainer
scripts was removed in:
- Debian linux 2.6.39-1, thus in wheezy
- Ubuntu linux 4.15.0-18.19 (I think), thus in bionic
- kernel-package 12.001, thus in Debian squeeze and Ubuntu lucid
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
These all seem to be harmless in practice, as the parameter values
should not contain metacharacters.
In _checkfs_once() *do not* quote $spinner or $force; if these
are empty then we do not want to add arguments for them. Add a
comment to suppress the warning.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
"update-initramfs -c -k all" used to re-create initramfs images if
they had been deleted without using "update-initramfs -d", as it used
the state directory to determine which kernel versions should have
them.
Since commit f39625a "update-initramfs: Make "-k all" take over other
initramfs images", it ignores the state directory and is almost
equivalent to "update-initramfs -u -k all".
Change it to operate on all installed kernel versions. This will
ignore which kernel versions suppressed initramfs generation, but
I think it's reasonable to assume users won't use these options
if they have installed such kernels.
Closes: #926401
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* Don't use angle brackets around parameters
* Show all options in manual page synopses if possible
* Make the usage summary line match the manual page synopsis,
excluding the -h option
* List all options in usage messages
* Refer to manual pages from usage messages
* Include one blank line at start and end of usage messages
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
All warning (non-fatal condition) and error (fatal condition)
messages should be printed to stderr, and should start with a
prefix of "W:" or "E:" respectively.
Also remove the word "ignoring" from some warning messages. It
follows from the fact that they are warnings that the problem is
being ignored.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Sometimes globbing and word splitting is wanted. Therefore explicitly
disable the check for these line.
Signed-off-by: Benjamin Drung <benjamin.drung@cloud.ionos.com>
shellcheck found more issues than SC1074. Address most of these issues.
You can check the shell code by running:
```
shellcheck -e SC1090,SC1091 -s dash hook-functions $(find * -type f
\( -executable ! -name rules -o -regex '.*\.\(post\|pre\).*'
-o -regex "^\(docs\|scripts\)/.*" ! -name '*.md' \))
```
Signed-off-by: Benjamin Drung <benjamin.drung@cloud.ionos.com>
This was never documented, doesn't do anything, and doesn't appear
to be used by any other package. Remove it completely.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Now that we assume ownership of /boot/initrd.img-<version> for all
installed kernel versions, an update or deletion command with "-k all"
should be applied to all such files, even if we didn't create them.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
In Debian, update-initramfs has always refused to overwrite or delete
an initramfs image that it didn't create, unless the -t option is
used. On Ubuntu, this check is apparently disabled. The commit log
doesn't provide much of a clue as to why. Looking at the the state of
Debian and the linux-2.6 package at the time, I think the reasoning
must have been something like:
(1) Multiple initramfs/initrd generators were available and could be
coinstalled. The configuration file /etc/kernel-img.conf specified
which one kernel packages should invoke ("ramdisk" variable).
(2) Packages that hooked into initramfs-tools would always run update-
initramfs if it existed, and it would immediately update the
initramfs, because triggers hadn't yet been invented.
(3) To keep the alternate initramfs generators working, update-
initramfs therefore had to either (a) check the configuration file to
find out whether initramfs-tools was meant to be used, or (b) keep
track of which initramfs images it created and therefore "owned".
At this point, (1) is no longer true; the "ramdisk" variable is not
honoured and the initramfs generator to be invoked is chosen by
installing one of several conflicting packages. I think this means
that (3) no longer follows, and whichever of the automatic initramfs
generator packages is currently installed should be considered to
"own" /boot/initrd.img-<version> for all kernel versions.
This commit only disables the checks. The state directory and the
state updates are retained for now, in case it becomes necessary to
revert this change.
Closes: #765750, #804295
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
This avoids update-initramfs taking an unnecessarily long time if there
is lots of activity on a different filesystem, or even hanging in cases
such as a stale NFS mount.
Based on a patch by Jukka Tastula <poltsy@gmail.com>.
Closes: #882380
LP: #1667512
Signed-off-by: Colin Watson <cjwatson@debian.org>
Bug #783620 involves several machines with root on xfs being upgraded
from wheezy to jessie and then immediately rebooted. In some cases
the initramfs was apparently written to the journal but not committed
during the reboot. As GRUB doesn't replay the journal, it loaded an
empty initramfs and the kernel failed to boot.
There is clearly a bug elsewhere (init system or kernel) that
prevented the filesystem being cleanly shut down. However, there
seems to be a general risk here, so add a 'sync' to mitigate it.
Closes: #783620
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
dpkg does not know how to sort -rc and -trunk suffixes as we want.
Also, we were using the deprecated '>' version operator which will
trigger warnings in newer versions of dpkg.
Closes: #770394, #795837
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
The text in the manual page implies that -b needs an argument
but the usage summaries don't say that.
While we're at it, remove the brackets in '-k [version]', as
these suggest the version argument is optional.
Closes: #762768
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
so redirect the whining from dpkg --compare-versions
to /dev/null to avoid scary (and incorrect) warnings.
LP: #889584
Signed-off-by: Adam Conrad <adconrad@0c3.net>
It install hooks these days, probably needs an accompagning break
to help users..
Signed-off-by: maximilian attems <max@stro.at>
Signed-off-by: Michael Prokop <mika@debian.org>
As is asked by current hooks policy.
This and the flash-kernel new initramfs hooks will allow to axe the
direct flash-kernel invocation in run_bootloader().
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Martin Michlmayr <tbm@cyrius.com>
Reviewed-by: Michael Prokop <mika@debian.org>
Signed-off-by: maximilian attems <max@stro.at>
This reverts commit bc1475ea3ba0cec7ac6f1ef4a76266819478b8f5.
In fact this code is useless for the considered purpose, so really kick.
Signed-off-by: maximilian attems <max@stro.at>
Reviewed-by: Michael Prokop <mika@debian.org>
This reverts commit 59f9c1e2f98d2fd3251f0d3782e4dd1e65bd558c.
The rationale beeing #624702 as a valid use case for min version
handling. We just need to check if that version of linux-2.6 can
possibly support xz.
Acked-by: Michael Prokop <mika@debian.org>
Acked-by: Martin Würtele <martin@wuertele.net>
Signed-off-by: maximilian attems <max@stro.at>
elilo, lilo, and zipl all install post-update hooks for us, so we
don't need call them specifically. Unfortunately, flash-kernel does
not yet, so keep that for a little longer.
Add 'breaks' relations to the versions of these packages that do not
install post-update hooks.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: maximilian attems <max@stro.at>
Reviewed-by: Michael Prokop <mika@debian.org>
Official Debian and Ubuntu kernel packages will invoke us directly as
part of the $ramdisk handling inherited from kernel-package. They
will later run our hook script, as will custom packages made with
'make-kpkg' or the upstream 'make deb-pkg'.
Currently, for official packages we perform an update on the first
invocation (possibly deferred using dpkg triggers) and then ignore the
second. However, the long-term plan is to remove that first
invocation. Therefore, ignore the first invocation and perform the
update on the second.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
[ Use && op, we make the effort to not use -a evaluation. -maks ]
Signed-off-by: maximilian attems <max@stro.at>
Reviewed-by: Michael Prokop <mika@debian.org>
This needs to be expressed in terms of package dependencies,
no point in keeping that old hack. Supporting special initramfs
arch bugs in the time between 2.6.12 and 2.6.15 is not worth.
Nowadays this check succeeds anyway.
Signed-off-by: maximilian attems <max@stro.at>
Reviewed-by: Michael Prokop <mika@debian.org>
Users just sometimes quote the message, it is already useful
to get the error code.
Signed-off-by: maximilian attems <max@stro.at>
Reviewed-by: Michael Prokop <mika@debian.org>
Conform to policy
http://kernel-handbook.alioth.debian.org/ch-update-hooks.html#s-initramfs-hooks
We check that the dir exists to no longer invoke boot loader on our
own for squeeze, but work on partial upgrades from lenny.
The bootloader invocations can be removed postsqueeze.
Signed-off-by: maximilian attems <maks@debian.org>
Brought no gain in code readability and lots of bug reports.
Closes: #588915
Suggested-by: Colin Watson <cjwatson@ubuntu.com>
Signed-off-by: maximilian attems <maks@debian.org>