[Bug 1100885] New: initrd is regenerated after each relevant package instead of once
http://bugzilla.suse.com/show_bug.cgi?id=1100885 Bug ID: 1100885 Summary: initrd is regenerated after each relevant package instead of once Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Upgrade Problems Assignee: bnc-team-screening@forge.provo.novell.com Reporter: msvec@suse.com QA Contact: jsrain@suse.com CC: ma@suse.com, mls@suse.com Found By: --- Blocker: --- Just did zypper dup from 42.3 to 15.0 and noticed that initrd is generated upon each kernel or kmp install/remove instead of once at the end. It makes the upgrade process take ages. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1100885 http://bugzilla.suse.com/show_bug.cgi?id=1100885#c1 --- Comment #1 from Michael Andres <ma@suse.com> --- This is a packaging issue, not a zypp one. Packages may generate the initrd in their %posttrans and should avoid regenerating an already up-to-date initrd. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1100885 Michal Svec <msvec@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |msvec@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1100885 http://bugzilla.suse.com/show_bug.cgi?id=1100885#c3 --- Comment #3 from Michal Svec <msvec@suse.com> --- (In reply to Michael Andres from comment #1)
This is a packaging issue, not a zypp one. Packages may generate the initrd in their %posttrans and should avoid regenerating an already up-to-date initrd.
Well, I can't tell whether the resp. packages don't do it in their $posttrans or whether all the %posttrans'es weren't queued to be run once at the end. I just spotted that initrd was created multiple times in the middle of the upgrade process. Maybe it can be found in the logs (see attached). -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1100885 http://bugzilla.suse.com/show_bug.cgi?id=1100885#c4 --- Comment #4 from Michael Andres <ma@suse.com> ---
# 2018-07-11 14:09:58 drm-kmp-default-4.9.33_k4.4.126_48-13.3.x86_64 removed ok # Creating initrd: /boot/initrd-4.4.132-53-default # dracut: Executing: /usr/bin/dracut --logfile /var/log/YaST2/mkinitrd.log --force /boot/initrd-4.4.132-53-default 4.4.132-53-default # Creating initrd: /boot/initrd-4.4.138-59-default # dracut: Executing: /usr/bin/dracut --logfile /var/log/YaST2/mkinitrd.log --force /boot/initrd-4.4.138-59-default 4.4.138-59-default
# 2018-07-11 14:12:02 drm-kmp-default-4.9.33_k4.4.120_45-10.2.x86_64 removed ok # Creating initrd: /boot/initrd-4.4.132-53-default # dracut: Executing: /usr/bin/dracut --logfile /var/log/YaST2/mkinitrd.log --force /boot/initrd-4.4.132-53-default 4.4.132-53-default # Creating initrd: /boot/initrd-4.4.138-59-default # dracut: Executing: /usr/bin/dracut --logfile /var/log/YaST2/mkinitrd.log --force /boot/initrd-4.4.138-59-default 4.4.138-59-default
# 2018-07-11 14:13:45 drm-kmp-default-4.9.33_k4.4.79_4-5.2.x86_64 removed ok # Creating initrd: /boot/initrd-4.4.132-53-default # dracut: Executing: /usr/bin/dracut --logfile /var/log/YaST2/mkinitrd.log --force /boot/initrd-4.4.132-53-default 4.4.132-53-default # Creating initrd: /boot/initrd-4.4.138-59-default # dracut: Executing: /usr/bin/dracut --logfile /var/log/YaST2/mkinitrd.log --force /boot/initrd-4.4.138-59-default 4.4.138-59-default
# 2018-07-11 14:23:01 kernel-default-4.12.14-lp150.12.4.1.x86_64.rpm installed ok # Creating initrd: /boot/initrd-4.12.14-lp150.12.4-default # dracut: Executing: /usr/bin/dracut --logfile /var/log/YaST2/mkinitrd.log --force /boot/initrd-4.12.14-lp150.12.4-default 4.12.14-lp150.12.4-default
The history shows 3 drm-kmp-default removals and 1 kernel-default install creating initrds. (The drm-kmp-default removal lasts about 9 min. in total. So it's indeed quite slow) The package maintainers should know if this is unavoidable.
# 2018-07-11 14:47:58 Output of coreutils-8.29-lp150.2.2.x86_64.rpm %posttrans script: # Creating initrd: /boot/initrd-4.12.14-lp150.12.4-default # dracut: Executing: /usr/bin/dracut --logfile /var/log/YaST2/mkinitrd.log --force /boot/initrd-4.12.14-lp150.12.4-default 4.12.14-lp150.12.4-default # Creating initrd: /boot/initrd-4.4.132-53-default # dracut: Executing: /usr/bin/dracut --logfile /var/log/YaST2/mkinitrd.log --force /boot/initrd-4.4.132-53-default 4.4.132-53-default # Creating initrd: /boot/initrd-4.4.138-59-default # dracut: Executing: /usr/bin/dracut --logfile /var/log/YaST2/mkinitrd.log --force /boot/initrd-4.4.138-59-default 4.4.138-59-default
Within the %posttrans phase each initrd is created once (again). -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1100885 Michal Svec <msvec@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tiwai@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1100885 http://bugzilla.suse.com/show_bug.cgi?id=1100885#c5 --- Comment #5 from Takashi Iwai <tiwai@suse.com> --- This is intended behavior, AFAIK. We want to stay in a safer side and avoid the possible worst case -- no initrd but kernel installed. Hence, when a kernel package is installed, the initrd is generated instantly at its %post. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1100885 http://bugzilla.suse.com/show_bug.cgi?id=1100885#c7 --- Comment #7 from Daniel Molkentin <daniel.molkentin@suse.com> --- After talking to some people, it may seem that we can fix this, albeit not in the short term. Keeping this open as a tracking bug. General idea is to have the user decide: 1. whether to opt for safety (i.e. be sure that the system will always boot even when zypper is interrupted). This means keeping mkinitrd after every single package that touches the kernel or dracut 2. whether to go for speed, i.e. delay mkinitrd until zypper is done installing all updates and then have zypper run mkinird. However, I do not see a way to have both. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1100885 Daniel Molkentin <daniel.molkentin@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|daniel.molkentin@suse.com |dracut-maintainers@suse.de -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1100885 http://bugzilla.suse.com/show_bug.cgi?id=1100885#c8 Daniel Molkentin <daniel.molkentin@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |daniel.molkentin@suse.com Resolution|--- |WONTFIX --- Comment #8 from Daniel Molkentin <daniel.molkentin@suse.com> --- I will close this as WONTFIX for now. If there is a scenario where we don't have to trade user experience against an unbootable system, we can revisit this. -- You are receiving this mail because: You are on the CC list for the bug.
participants (2)
-
bugzilla_noreply＠novell.com -
bugzilla_noreply＠suse.com