|
Bugzilla – Full Text Bug Listing |
| Summary: | libzypp unexpectedly calls mkinitrd | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.0 | Reporter: | Peter Poeml <poeml> |
| Component: | Kernel | Assignee: | Forgotten User ZhJd0F0L3x <forgotten_ZhJd0F0L3x> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | ||
| Version: | Beta 1 | ||
| Target Milestone: | Future/Later | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
the package suspend contains /usr/sbin/resume. This needs to be put in the initrd. The /usr/sbin/resume in the initrd must match the /usr/sbin/s2{disk,both} in the installed system. Since we don't know the version of resume, we have to rebuild the initrds. All of them.
So it's not a bug, it's a feature.
As the suspend package tends to be pulled into the system in various
systems, and it hits me again and again, may I propose some alternative
solution that works around the issue?
* make it configurable (i.e. possible to prevent recreation)
* document what's happening. Any user staring at zypper's output
Installing: suspend-0.80.20081103-1.58 [|]
for prolonged time, will start wondering what's happening, start
investigating, et cetera. The %post should print out that it does
something, what it does and why. And how it can be prevented. (If that
kind of output exists, but is swallowed by zypper, then that's another
bug of course. (I fear.))
I can provide a patch to the suspend package for this.
Thanks.
The change works for me: If /var/lib/no_initrd_recreation_by_suspend is found: root@cherry ~ # rpm -Uhv /usr/src/packages/RPMS/ppc/suspend-0.80.20081103-1.ppc.rpm --force Preparing... ########################################### [100%] 1:suspend ########################################### [100%] Skipping recreation of existing initial ramdisks, due to presence of /var/lib/no_initrd_recreation_by_suspend root@cherry ~ # rpm -e suspend Skipping recreation of existing initial ramdisks, due to presence of /var/lib/no_initrd_recreation_by_suspend root@cherry ~ # rpm -Uhv /usr/src/packages/RPMS/ppc/suspend-0.80.20081103-1.ppc.rpm --force Preparing... ########################################### [100%] 1:suspend ########################################### [100%] Skipping recreation of existing initial ramdisks, due to presence of /var/lib/no_initrd_recreation_by_suspend If /var/lib/no_initrd_recreation_by_suspend is not there: root@cherry ~ # rm /var/lib/no_initrd_recreation_by_suspend root@cherry ~ # rpm -Uhv /usr/src/packages/RPMS/ppc/suspend-0.80.20081103-1.ppc.rpm --force Preparing... ########################################### [100%] 1:suspend ########################################### [100%] Recreating all initial ramdiscs. (This could take a while.) Scanning scripts ... Resolve dependencies ... Install symlinks in /lib/mkinitrd/setup ... Install symlinks in /lib/mkinitrd/boot ... Kernel image: /boot/vmlinux-2.6.12.1-1-default Initrd image: /boot/initrd-2.6.12.1-1-default [...] seife@stoetzler:~> rpm -q --changelog suspend|head -3 * Mo Feb 23 2009 poeml@suse.de - provide a way to prevent recreation of initial ramdisks on install/update, and add a note to %post about it (bnc#381276) This is an autogenerated message for OBS integration: This bug (381276) was mentioned in https://build.opensuse.org/request/show/7565 Factory / suspend |
I updated a couple of packages from Factory, and at some point, libzypp hangs after printing the following line, for about 10 minutes. / Installing: suspend-0.80.20080219-20 [100%] I see gzip running in top, and notice that the suspend package's %post apparently has called mkinitrd, which recreates all initrds on my system (which clearly something that I don't want it to do!!) root 23613 0.3 1.3 7796 4252 pts/1 S+ 14:18 0:00 \_ rpm --root / --dbpath /var/lib/rpm -U --percent --force --nodeps -- /var/cache/zypp/packages/factory/ppc/suspend-0.80.20080219-20.ppc.rpm root 23614 0.0 0.4 3416 1392 pts/1 S+ 14:18 0:00 \_ /bin/sh /var/tmp/rpm-tmp.22927 1 root 23615 0.0 0.4 3416 1512 pts/1 S+ 14:18 0:00 \_ /bin/bash /sbin/mkinitrd root 27514 3.0 0.3 3552 1248 pts/1 S+ 14:20 0:01 \_ /bin/bash /sbin/mkinitrd root 29407 1.0 0.1 1956 600 pts/1 S+ 14:20 0:00 \_ cpio -H newc --create root 29408 100 0.2 2080 716 pts/1 R+ 14:20 0:23 \_ gzip -9 Especially as not kernel or mkinitrd package was updated: # zypper update * Building repository 'factory' cache Reading installed packages... The following NEW packages are going to be installed: bundle-lang-common-ar poppler-data yast2-registration yast2-add-on yast2-firewall yast2-online-update opensuse-codecs-installer suseRegister bash-completion yum-basearchonly release-notes-openSUSE gtk2-branding-upstream yast2-control-center-qt yast2-qt-pkg gimp-plugins-python gstreamer-0_10-plugins-base splashy ghostscript-omni suspend uuid-runtime yast2-ncurses-pkg libgstinterfaces-0_10-0 kdelibs3-doc bash-doc ft2demos enscript PolicyKit-doc graphviz-gd libgvfscommon0 libasound2-64bit libgio-fam gvfs libgpod-tools libgluezilla0 perl-doc limal-ca-mgm-perl sane-backends-autoconfig alsa-plugins readline-doc alsa-oss-64bit perl-Crypt-SSLeay yast2-control-center Overall download size: 20.7 M. After the operation, additional 118.0 M will be used. Continue? [YES/no]: y Downloading package bundle-lang-common-ar-11.0-92.noarch, 152.0 K (529.0 K unpacked) * Downloading: bundle-lang-common-ar-11.0-92.noarch.rpm [done (62.0 K/s)] [...] The suspend package has this in %post: # rpm -q suspend --scripts postinstall scriptlet (using /bin/sh): if [ "$YAST_IS_RUNNING" != "instsys" -a \ ! -e /.buildenv -a \ -x /sbin/update-bootloader -a \ -x /sbin/mkinitrd ]; then /sbin/mkinitrd /sbin/update-bootloader --refresh fi I see a few problems with this: 1) is it really needed to run mkinitrd to up date _all_ initrds after updating the suspend package? 2) the user is not informed about the mkinitrd run and zypper gives no indication what it's doing for 10 minutes (that's probably a zypper issue?) 3) recreating _all_ initrds (which is what it did) is dangerous, I don't want that. It is okay for me if it recreates the initrd for the booted kernel, like it would do if I update the kernel... Stefan, I suppose you could have some input on this?