[Vmdebootstrap-devel] Bug#801214: Unapplying (Debian Bug #801214)

[Christian Seiler]

Hello,

On 11/20/2015 11:41 PM, Neil Williams wrote:
>> I don't understand what you are saying here. Is there any problem
>> with the patch I've provided?
> 
> Yes, your patch is absolutely the wrong approach. It is inappropriate
> for vmdebootstrap to call triggers directly, that's a job for dpkg and
> the maintainer scripts of the packages being installed, not the tool
> passing a list of packages to dpkg.
> 
> If the kernel is upgraded inside the VM, having the triggers in
> vmdebootstrap does not help anyone - something *in a package* installed
> into the VM (i.e. dracut or something related to dracut) *must* handle
> kernel upgrades and therefore vmdebootstrap must rely on dracut doing
> that correctly, not subvert the trigger mechanism.

But dracut already handles that correctly, this is not what this patch
was about! There are two mechanisms both dracut and initramfs-tools
hook into other packages so that the initrd is regenerated:

 - /etc/kernel/postinst.d/{dracut,initramfs-tools}

   This is called from each kernel images postinst to make sure that
   the initrd is updated. Each package installs a script [1], [2] there
   that ensures that for the newly installed kernel an initramfs is
   created/updated.

 - The dpkg trigger update-initramfs

   Both packages install an interest trigger [3], [4] with the name
   'update-initramfs'. The respective postinst scripts [5], [6] make
   sure that the initrds are properly regenerated when the trigger is
   called.

   A number of other packages activate that trigger via the standard
   dpkg mechanism for that. [7] (Quite a few other packages still call
   update-initramfs directly in postinst, which I see as a bug in those
   packages.)

[1] http://sources.debian.net/src/initramfs-tools/0.120/kernel/postinst.d/initramfs-tools/
[2] http://sources.debian.net/src/dracut/043-4/debian/kernel/postinst.d/dracut/
[3] http://sources.debian.net/src/initramfs-tools/0.120/debian/initramfs-tools.triggers/
[4] http://sources.debian.net/src/dracut/043-4/debian/dracut.triggers/
[5] http://sources.debian.net/src/initramfs-tools/0.120/debian/initramfs-tools.postinst/
[6] http://sources.debian.net/src/dracut/043-4/debian/dracut.postinst/
[7] https://codesearch.debian.net/results/activate%20update-initramfs/page_0

The '/usr/sbin/update-initramfs' binary is just a script that is
specific to initramfs-tools, it's not something generic.

> Build tools must not call triggers in dpkg directly, that is just
> setting the user up for a fall later.

But what will go wrong here? My patch does the same thing as
vmdebootstrap did beforehand, but just much more generically and not
tied to the initrd implementation.

> The execution of the trigger must
> be dependent on a package installed inside the system and the
> dependencies of the relevant packages must ensure that this support
> exists.

But that is already the case! If I install xen-tools or ntfs-3g on a
system, the initrd will be regenerated afterwards via the dpkg trigger,
regardless of whether it's dracut or initramfs-tools. Same with
upgrading a kernel (not via the dpkg trigger but via the
/etc/kernel/postinst.d mechanism). That already works perfectly fine
with both packages!

I think there is some confusion here on your part. The only reason as
to why the update-initramfs call in vmdebootstrap even makes sense is
because vmdebootstrap customizes some parts of the image after package
installation (/etc/fstab, udev rules, potentially the user-provided
customization script, etc.) that require a regeneration of the initrd,
because the initial initrd is the one generated at debootstrap time
with the default parameters.

Otherwise, package installation would already suffice to properly
generate the initramfs and you could completely strip out the call to
update-initramfs in vmdebootstrap and let dpkg do all the work. But
that won't work, because the packages are all installed during the
debootstrap phase, so that dpkg run is too early.

>>> The correct fix is as it was
>>> originally - letting the call to /usr/sbin/update-initramfs use the
>>> trigger support it already knows.  
>>
>> What trigger support? /usr/sbin/update-initramfs-tools is owned
>> by the initramfs-tools package and dracut doesn't provide that
>> tool - currently, vmdebootstrap does nothing if dracut is used
>> for the initramfs (update-initramfs doesn't exist, therefore
>> vmdebootstrap won't call anything).
> 
> So dracut needs to be fixed to update the initramfs when any process
> causes dpkg to run the relevant triggers

It already does that, see above. See above and the part of my previous
email you are quoting. /usr/sbin/update-initramfs is NOT something
generic in Debian, it's something specific to initramfs-tools and is
owned by that package. There are proper ways to hook initrd-generating
things up (see the beginning of this email), and dracut does all that
properly.

> special snowflake support in
> vmdebootstrap is unwarranted and counter-productive.

Which is precisely why I want you to go away from supporting a specific
implementation and rather use a generic dpkg mechanism. My patch
replaces a package-specific mechanism from vmdebootstrap with something
generic - not the other way around.

> Changes like that
> would have to be applied to more than just vmdebootstrap

vmdebootstrap is special here because it's not installed IN the VM
image that it builds, but has a need to cause the VM image to
regenerate the initramfs. The vast majority of other packages that
require regeneration of the initramfs are installed together with
dracut or initramfs-tools (because they're required on that specific
system. such as ntfs-3g) and thus SHOULD have a dpkg trigger
'activate update-initramfs', as in [7].

> and the whole
> point of triggers is to not require tools to do that.

Yes, exactly, which is NOT what vmdebootstrap currently does, because
it calls a package-specific binary directly.

Regards,
Christian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/vmdebootstrap-devel/attachments/20151121/3ca9865a/attachment.sig>