Re: [PATCH] debianize: handle .triggers and .service files

["MOESSBAUER, Felix" <felix.moessbauer@siemens.com>]

On Wed, 2023-11-15 at 08:57 +0000, Hombourger, Cedric (DI SW CAS ES LI)
wrote:
> On 11/15/23 09:43, MOESSBAUER, Felix (T CED INW-CN) wrote:
> > On Wed, 2023-11-15 at 09:36 +0100, Jan Kiszka wrote:
> > > On 14.11.23 21:22, 'MOESSBAUER, Felix' via isar-users wrote:
> > > > On Tue, 2023-11-14 at 20:54 +0100, 'Cedric Hombourger' via
> > > > isar-
> > > > users
> > > > wrote:
> > > > > Some packages need to update/rebuild the initramfs and this
> > > > > is
> > > > > particularly
> > > > > slow on Debian systems (which are not using more modern
> > > > > technologies
> > > > > such
> > > > > as dracut or mkosi). Instead of having each package call
> > > > > update-
> > > > > initramfs,
> > > > > use a trigger instead to have dpkg defer that call to the
> > > > > very
> > > > > end of
> > > > > the
> > > > > transaction. Many packages also failed to rebuild the
> > > > > initramfs
> > > > > when
> > > > > the
> > > > > package gets removed. Demonstrate use with initramfs-fsck-
> > > > > hook-
> > > > > ext4.
> > > > Hi Cedric,
> Hi Felix
> > > > thanks for bringing this up. Especially on non x86 builds the
> > > > update-
> > > > initramfs can take really long due to the emulation.
> > > > 
> > > > I also played around with disabling the initrd update during
> > > > image
> > > > building of images with a custom initramfs (where the one from
> > > > the
> > > > rootfs is anyways not used). However the issue is, that the
> > > > config
> > > > change needs to be made in /etc/initramfs-tools/update-
> > > > initramfs.conf,
> > > > which is shipped by initramfs-tools (no conf.d style
> > > > supported). By
> > > > that, we would need to add this package to the default set of
> > > > packages
> > > > which I also dislike.
> I am wondering if we should provide a pseudo replacement for
> initramfs-tools in images where we will end-up using an initramfs
> from
> an 'inherit initramfs' recipe
> > > > What I don't understand is how the initrd trigger should help.
> > > > The
> > > > /usr/sbin/update-initramfs internally already detects the
> > > > invocation
> > > > via dpkg and dispatches to the trigger, so manually adding this
> > > > is
> > > > nice
> > > > syntax wise, but does not make a difference in performance.
> > > > 
> > > > Ideally, we don't update the initrd at all during package
> > > > install,
> > > > but
> > > > just generate it at do_rootfs_postprocess.
> > > > 
> > > There is actually an issue already in Debian itself which I
> > > started
> > > to
> > > examine during Debconf but was distracted: If you install a
> > > minimal
> > > rootfs with kernel, that will already run the initramfs
> > > generation
> > > twice, although it should do it once only. That said, anything on
> > > top
> > > may be related to missing proper usage of triggers.
> > Ok... can you provide a link to the issue?
> > 
> > Regarding the triggers: The triggers itself work properly, but they
> > are
> > called once per apt install/remove invocation, and as we have
> > multiple
> > apt calls in ISAR (within a single build), also the triggers are
> > called
> > multiple times. We really need to fully disable the initramfs
> > generation and call it manually at the end of the rootfs install.
> 
> Agreed. There are however (and IMO) two sides of the story:
> 
> (1) encouraging people to use debhelper and best practices when they
> create Debian packages (with or without dpkg-raw). I have downstream
> users relying on the package feeds we generate from Isar and who
> either
> pull packages from an Isar build or from a running system (for those,
> packages we provide should meet Debian standards)
> 
> (2) improving the Isar image generation pipeline
> 
> Our Isar-based DISTRO switched to triggers quite a while ago and it
> was
> definitely a technical debt from our part not to submit that dpkg-raw
> enhancement earlier. I seem to recall that when we had started with
> buster, update-initramfs did not check if it was running in
> maintainer
> context and would not defer the update of the initramfs to the very
> end
> of the apt transaction. As such it is very likely that this proposed
> change does not improve build-times but I hope we would agree that it
> would result in initrd package recipes ship proper maintainer scripts
> (most that I have seen were only taking care of the postinst step).

Yes. I fully agree that this patch makes sense and we should include
it. This discussion should also not delay the integration.

Reviewed-by: Felix Moessbauer <felix.moessbauer@siemens.com>

Apart from that, I would be happy if we could solve the performance
issue on a broader scope. But this will need time to work on the
required changes and likely also more discussions with upstream debian.

Felix

> 
> > Felix
> > 
> > > Jan
> > > 
>