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

["cedric.hombourger@siemens.com" <cedric.hombourger@siemens.com>]

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).

> Felix
>
>> Jan
>>