Bug 966057 - RPM packages don't regenerate initrd on removal
RPM packages don't regenerate initrd on removal
Status: CONFIRMED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem
Current
All Other
: P2 - High : Major (vote)
: ---
Assigned To: Fabian Vogt
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-10 14:34 UTC by Fabian Vogt
Modified: 2020-05-29 13:59 UTC (History)
10 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Fabian Vogt 2016-02-10 14:34:03 UTC
Currently there are two macros in /etc/rpm/macros.initrd:

%regenerate_initrd_post, to be called in the %post and %postun sections
and %regenerate_initrd_posttrans, to be called in %posttrans.

%regenerate_initrd_post simply sets a flag that the initrd has to be rebuilt after the transaction. The posttrans macros takes care of that.

Now, that works fine for installation (%post -> %posttrans) and upgrades (%postun -> %post -> %posttrans), but on removal, %posttrans is never run.

How could that be implemented properly?
Comment 1 Michael Andres 2016-02-15 13:12:08 UTC
Unfortunately rpm has nothing like a %postuntrans script, so there's no 'final' trigger for deleted packages after the %postun.

What you can try is to execute the action immediately, if '%postun 0' (on final delete) was called (and no trigger has been placed by now). If the 1st arg is not 0 (upgrade), the newly installed packages %posttrans will do the job.

Not perfect, but maybe better than nothing.
Comment 2 Fabian Vogt 2016-02-16 16:26:36 UTC
(In reply to Michael Andres from comment #1)
> Unfortunately rpm has nothing like a %postuntrans script, so there's no
> 'final' trigger for deleted packages after the %postun.
The issue with a %postuntrans is that the script can't depend on anything, literally. It could be that someone ran "zypper rm glibc" or similiar, so practically any script would fail. Even the script interpreter might be gone...

> What you can try is to execute the action immediately, if '%postun 0' (on
> final delete) was called (and no trigger has been placed by now). If the 1st
> arg is not 0 (upgrade), the newly installed packages %posttrans will do the
> job.
> 
> Not perfect, but maybe better than nothing.

Definitely better than nothing and also what I did for plymouth in my home repo.
Issue is that this can cause mkinitrd to run multiple times during a transaction and it also looks like it's stuck somewhere as it stays at a certain percentage for quite a while, depending on how many kernels are in /boot.
Comment 3 Michael Schröder 2016-02-24 12:37:46 UTC
Reassigned to suse-module-tools maintainer.
Comment 4 Fabian Vogt 2018-04-25 11:31:57 UTC
Ping.
Comment 5 Martin Wilck 2018-11-14 23:11:25 UTC
Sorry, this was buried under lots of other stuff.

Anyway, I fail to see a problem that needs a general solution. How many packages are there that need to rebuild the initrd when they're uninstalled? And how often does this happen in practice?

Honestly, I believe that we have too many packages that use %regenerate_initrd_post. Rebuilding the intird is always risky business. 
Normally, when you do package management operations (except system installation and offline upgrade), you have booted the system successfully with the existing initrd. Replacing it has a non-zero risk of breaking the system; perhaps so badly that it won't boot any more.

When uninstalling, it may actually be beneficial _not_ to rebuild the initrd in many cases.

Thinking about it, IMO it'd be good policy to regenerate the initrd only when (un)installing or upgrading the kernel, or (relevant) kernel modules. In other cases it'd be sufficient to have the user rebuild the initrd if she so desires.

But I'm digressing.

Plymouth is special because AFAIK it needs code in the root file system to cause plymouth to *quit* and release the console. For most other packages, I believe that keeping them in the intird would be ok even if it was uninstalled. People who have multipath or lvm in the initrd because they boot from it, and then uninstall these packages - well, they shoot themselves in the foot deliberately.

Even for plymouth, it might be sufficient to simply print a warning. Users who uninstall a basic package such as plymouth should know what they're doing.

Even if I saw the need, I still wouldn't know what to do about it in suse-module-tools. AFAICS there's no way to figure out during %postun whether or not certain %posttrans script is going to be run later. If you really want, you can write explicit code in your package: 

%postun
if [ $1 -eq 0 ]; then
     [ -x /sbin/mkinitrd_setup ] && /sbin/mkinitrd_setup
     [ -x /sbin/mkinitd ] && /sbin/mkinitrd
fi

Given that this affects only a few packages, I don't think that it makes sense to provide a general macro for it.
Comment 6 Martin Wilck 2019-01-10 00:43:25 UTC
Is this ok for you?
Comment 7 Fabian Vogt 2019-01-10 08:20:57 UTC
I think it's now possible with rpm 4.13 to emulate %postuntrans with %transfiletriggerpostun.

A %filetriggerpostun can be added generically for /usr/lib/dracut for packages (but you say that it's not actually necessary) and explicitly for /usr/lib/plymouth/plymouth-generate-initrd as well. It just creates the initrd regeneration trigger file.

In %transfiletriggerpostun with the same matching rules it can than test for the file and regenerate as usual.

@mls: Would that work?
Comment 8 Fabian Vogt 2020-01-24 12:22:32 UTC
What I learned in the last couple months is that transfiletriggers are not implemented in libzypp, so the idea of my last comment will not work here.

So implementing the option in comment 5 is probably the best one until libzypp works properly.

Reassigning to plymouth maintainer to apply this change.
Comment 9 Cliff Zhao 2020-05-27 13:28:44 UTC
Hi Fabian:

Thanks for catching this problem.
and I notice that you reported this bug as comment0. So I will only discuss with you about this basic problem. and after so many discussions here, if you feels this bug disappear, please close it. if you still want to fix the original problem, please find the right assignee.

and for the Plymouth, if you find anything not good, please open new bug and share me the your reproduce steps and the expect result from the user perspective of view.

If you don't have user level test case, I think I can not guarantee that I will agree to do it.

Thank you for the cooperation and your understanding!
Comment 10 Fabian Vogt 2020-05-29 13:59:02 UTC
(In reply to Cliff Zhao from comment #9)
> Hi Fabian:
> 
> Thanks for catching this problem.
> and I notice that you reported this bug as comment0. So I will only discuss
> with you about this basic problem. and after so many discussions here, if
> you feels this bug disappear, please close it. if you still want to fix the
> original problem, please find the right assignee.

It still exists.

> and for the Plymouth, if you find anything not good, please open new bug and
> share me the your reproduce steps and the expect result from the user
> perspective of view.
>
> If you don't have user level test case, I think I can not guarantee that I
> will agree to do it.

Steps to reproduce the issue:

Install a system with plymouth. After it's booted, zypper rm libply* and reboot again. You'll notice that it still shows the splash screen, which can break the system boot completely.

Comment 5 has the right information to fix this.