Bug 20111 - partway through upgrade from Mga5 to Mga6 "Error: 'script' failed for glibc-6:2.22-21.mga6.i586...."
Summary: partway through upgrade from Mga5 to Mga6 "Error: 'script' failed for glibc-6...
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
: release_blocker normal
Target Milestone: ---
Assignee: Base system maintainers
QA Contact:
URL:
Whiteboard:
Keywords: 6sta2
: 20517 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-01-13 11:19 CET by Marja van Waes
Modified: 2017-04-26 11:12 CEST (History)
14 users (show)

See Also:
Source RPM: ncurses, glibc
CVE:
Status comment: Should be fixed with glibc-2.22-24.mga6, to be tested on next set of ISOs


Attachments
5.1 to mga6 sta report.bug.xz (224.39 KB, application/x-xz)
2017-01-21 02:11 CET, ben mcmonagle
Details
M5.1 upgrade x86_64 report.bug (202.59 KB, application/x-xz)
2017-03-04 09:11 CET, ben mcmonagle
Details
M5.1 upgrade i586 report.bug (224.78 KB, application/x-xz)
2017-03-04 09:12 CET, ben mcmonagle
Details

Description Marja van Waes 2017-01-13 11:19:01 CET
+++ This bug was initially created as a clone of Bug #18890 +++

But that report is too large and it's about a different package for which a similar issue got fixed, so cloning that report.

see Ben's attachment 8850 [details]

[marja@localhost Downloads]$ xzcat 18890report.bug.xz | grep DrakX
* second stage install running (DrakX v17.68)
[marja@localhost Downloads]$ xzcat 18890report.bug.xz | grep script | grep failed
* urpmi error: ERROR: 'script' failed for glibc-6:2.22-21.mga6.i586
* urpmi error: ERROR: 'script' failed for glibc-6:2.22-21.mga6.i586
%triggerin(systemd-217-11.2.mga5.i586) scriptlet failed, exit status 127
%triggerin(postfix-1:2.10.3-5.mga5.i586) scriptlet failed, exit status 127
[marja@localhost Downloads]$

Btw, do those two scriplet failures need bug reports?
Comment 1 David Walser 2017-01-13 11:29:09 CET
The exit status 127 means command not found, and those two are the ones in the picture showing as "glibc" because they are triggerin's on glibc.  It seems nonsensical that it's erroring, as those triggers come from the packages that provide the command that they're calling.

%triggerin -- glibc setup nss_ldap nss_db nss_wins nss_mdns
# Generate chroot jails on the fly when needed things are installed/upgraded
%{_sbindir}/postfix-chroot.sh -q update

%triggerin -- glibc
# reexec daemon on self or glibc update to avoid busy / on shutdown
# trigger is executed on both self and target install so no need to have
# extra own post
if [ $1 -ge 2 -o $2 -ge 2 ] ; then
        %{_bindir}/systemctl daemon-reexec 2>&1 || :
fi
Comment 2 Marja van Waes 2017-01-13 11:44:34 CET
(In reply to Marja van Waes from comment #0)

> 
> Btw, do those two scriplet failures need bug reports?

(In reply to David Walser from comment #1)
> The exit status 127 means command not found, and those two are the ones in
> the picture showing as "glibc" because they are triggerin's on glibc.  It
> seems nonsensical that it's erroring, as those triggers come from the
> packages that provide the command that they're calling.
> 

Sorry, I should have given more information about those scriptlets, it has to do with libtinfo.so.6 

It's in
* install.log :

ncurses-6.0-7.mga6.i586
bash-4.3-48.3.mga6.i586
grep-2.27-1.mga6.i586
/etc/nsswitch.conf created as /etc/nsswitch.conf.rpmnew
/bin/sh: error while loading shared libraries: libtinfo.so.6: cannot open shared object file: No such file or directory
%triggerin(systemd-217-11.2.mga5.i586) scriptlet failed, exit status 127
/bin/sh: error while loading shared libraries: libtinfo.so.6: cannot open shared object file: No such file or directory
%triggerin(postfix-1:2.10.3-5.mga5.i586) scriptlet failed, exit status 127
glibc-2.22-21.mga6.i586
libncurses6-6.0-7.mga6.i586

(Sorry for mixing issues in this report about glibc's failing script)
Comment 3 David Walser 2017-01-13 11:50:50 CET
What do you mean mixing issues?  The failing scriplets referencing glibc are what this bug is about.
Comment 4 David Walser 2017-01-13 11:58:17 CET
So of course these other packages require libncurses6 which has libtinfo.so.6, but libncurses6 explicitly required ncurses, which was causing a circular dependency, which is why it wasn't installed.  I removed that explicit requires (ncurses is required by basesystem-minimal so it'll get installed anyway) to hopefully break the cycle so that urpmi will install the packages in the correct order.
Comment 5 Nicolas Lécureuil 2017-01-20 11:05:37 CET
what about this bug ?
Comment 6 Rémi Verschelde 2017-01-20 11:12:53 CET
(In reply to Nicolas Lécureuil from comment #5)
> what about this bug ?

See the status comment:

> Might have been fixed in ncurses, needs testing again in the next ISO build
Comment 7 Nicolas Lécureuil 2017-01-20 11:17:21 CET
new ISO build is available ;)
Comment 8 Charles Edwards 2017-01-20 20:54:14 CET
Bug is still active on Mga5 to Mga upgrades.

Have done 3 this morning and in all 3 the glibc script error occured.
Comment 9 Marja van Waes 2017-01-20 21:42:27 CET
(In reply to Charles Edwards from comment #8)
> Bug is still active on Mga5 to Mga upgrades.
> 
> Have done 3 this morning and in all 3 the glibc script error occured.

:-(

Please attach the matching /root/drakx/report.bug (please compress with xz) from one of those upgrades.
Comment 10 Charles Edwards 2017-01-20 22:15:54 CET
(In reply to Marja van Waes from comment #9)
> (In reply to Charles Edwards from comment #8)
> > Bug is still active on Mga5 to Mga upgrades.
> > 
> > Have done 3 this morning and in all 3 the glibc script error occured.
> 
> :-(
> 
> Please attach the matching /root/drakx/report.bug (please compress with xz)
> from one of those upgrades.

Currently doing a 3260 pkg Mga5 install and will attach report.bug when I run the Mga6 upgrade on it.
Comment 11 ben mcmonagle 2017-01-21 02:11:39 CET
Created attachment 8876 [details]
5.1 to mga6 sta report.bug.xz
Comment 12 ben mcmonagle 2017-01-21 02:16:15 CET
oops. meant to add: 

Mageia-6-sta2-x86_64-DVD.iso
DATE.txt: Thu Jan 19 18:05:31 CET 2017
MD5SUM: 5b7896ef586f6c36448f28c38524a096
Comment 13 papoteur 2017-01-21 13:48:38 CET
No notice of this error on 32bits installation, without net updates at end.
Comment 14 Marja van Waes 2017-01-21 22:27:08 CET
(In reply to papoteur from comment #13)
> No notice of this error on 32bits installation, without net updates at end.

It only occurs when upgrading from Mga5 to Mga6

(In reply to ben mcmonagle from comment #11)
> Created attachment 8876 [details]
> 5.1 to mga6 sta report.bug.xz

[marja@localhost Downloads]$ xzcat 20111report.bug.xz |grep DrakX
* second stage install running (DrakX v17.71)
[marja@localhost Downloads]$ xzcat 20111report.bug.xz |grep script | grep failed
* urpmi error: ERROR: 'script' failed for glibc-6:2.22-21.mga6.x86_64
* urpmi error: ERROR: 'script' failed for glibc-6:2.22-21.mga6.x86_64
* urpmi error: ERROR: 'script' failed for dkms-broadcom-wl-6.30.223.271-45.mga6.nonfree.x86_64
%triggerin(postfix-1:2.10.3-5.mga5.x86_64) scriptlet failed, exit status 127
%triggerin(systemd-217-11.2.mga5.x86_64) scriptlet failed, exit status 127
%post(dkms-broadcom-wl-6.30.223.271-45.mga6.nonfree.x86_64) scriptlet failed, exit status 1
[marja@localhost Downloads]$ 

(a separate bug report is needed for the dkms-broadcom-wl scriptlet failure)

and here's the part about the libtinfo.so.6 errors:

setup-2.7.24-1.mga6.noarch
filesystem-2.1.9-28.mga6.x86_64
grep-2.27-1.mga6.x86_64
bash-4.3-48.3.mga6.x86_64
/etc/nsswitch.conf created as /etc/nsswitch.conf.rpmnew
/bin/sh: error while loading shared libraries: libtinfo.so.6: cannot open shared object file: No such file or directory
%triggerin(postfix-1:2.10.3-5.mga5.x86_64) scriptlet failed, exit status 127
/bin/sh: error while loading shared libraries: libtinfo.so.6: cannot open shared object file: No such file or directory
%triggerin(systemd-217-11.2.mga5.x86_64) scriptlet failed, exit status 127
glibc-2.22-21.mga6.x86_64
lib64pcre1-8.40-1.mga6.x86_64
libstdc++6-5.4.0-1.mga6.x86_64
libgcc1-5.4.0-1.mga6.x86_64
lib64ncurses6-6.0-8.mga6.x86_64
Comment 15 Marja van Waes 2017-01-21 22:41:06 CET
(In reply to Marja van Waes from comment #14)

> (a separate bug report is needed for the dkms-broadcom-wl scriptlet failure)

that's bug 20155
Comment 16 Neal Gompa 2017-02-20 18:14:08 CET
This might be one of those situations where we need "OrderWithRequires".

From RPM 4.9.0 release notes[1]:

"Packages can now supply extra transaction ordering hints via new OrderWithRequires tag. This follows Requires tag syntax, but does not generate actual dependencies. Only if the involved packages are present in the same transaction, the ordering hints are treated as if they were Requires when calculating the transaction order."

Does urpmi support this clause? If not, can we backport support for it into mga5 urpmi?

[1]: http://rpm.org/wiki/Releases/4.9.0
Comment 17 Neal Gompa 2017-02-20 18:29:51 CET
(In reply to Neal Gompa from comment #16)
> 
> Does urpmi support this clause? If not, can we backport support for it into
> mga5 urpmi?
> 

Actually, urpmi should not care about this, as RPM is the one that processes this for transaction ordering. As long as the transaction doesn't get inappropriately chunked by urpmi, it should work.
Comment 18 Thierry Vignaud 2017-02-22 17:30:22 CET
The issue often is not the lack of ordering hints...
It's often the existence of too much ordering hints which conflicts between themselves.
As such librpm has to break the deps cycle and do so randomly in order to have some kind of ordering as a perfect ordering isn't possible when deps tags conflicts.

One can use "urpmi --debug-librpm --deploops" in order to debug such situations...

I've often fixed upgrades for previous releases by actually breaking deps loops...

It's best debugging the issue before randomly adding even more requires/conflicts/...
Comment 19 Nicolas Lécureuil 2017-02-22 17:35:50 CET
if i install a mga5 and use urpmi --debug-librpm --deploops  to update to mga6 it helps enough ?
Comment 20 Thierry Vignaud 2017-02-22 17:41:00 CET
Yeah you could test that with a sufficiently filled enough chroot.
eg:
DIR=T
urpmi.addmedia --urpmi-root $DIR ...mga5...
urpmi --auto --urpmi-root $DIR basesystem task-gnome task-kde4 task-x11 task-plasma5

urpmi.removemedia -a --urpmi-root $DIR
urpmi.addmedia --urpmi-root $DIR ...mga6...
urpmi --auto --auto-select --urpmi-root $DIR --debug -vv --debug-librpm --deploops 2>&1|tee -a LOG.mga6
Comment 21 ben mcmonagle 2017-02-25 07:10:19 CET
still valid for 

Mageia-6-sta2-x86_64-DVD.iso
DATE: Wed Feb 22 15:48:28 CET 2017
Comment 22 Nicolas Lécureuil 2017-02-26 23:28:59 CET
just started to create a mga5 chroot for testing purposes.
Comment 23 ben mcmonagle 2017-03-03 10:35:05 CET
good news,

Mageia-6-sta2-x86_64-DVD.iso
DATE.txt: Tue Feb 28 22:03:40 CET 2017

upgrade completed with no issue.

will check i586 tomorrow
Comment 24 ben mcmonagle 2017-03-04 09:11:39 CET
Created attachment 9016 [details]
M5.1 upgrade x86_64   report.bug
Comment 25 ben mcmonagle 2017-03-04 09:12:32 CET
Created attachment 9017 [details]
M5.1 upgrade i586 report.bug
Comment 26 ben mcmonagle 2017-03-04 09:14:49 CET
Re-did upgrade x86_64 to be sure, and it resulted in `script' error - attached
Comment 27 Rémi Verschelde 2017-03-06 10:32:44 CET
In attachment 9016 [details] (x86_64) I see:

* urpmi error: ERROR: 'script' failed for vcdimager-0.7.24-10.mga6.x86_64
^ That one is bug 20386. So this bug (20111) seems to be fixed / not triggered on x86_64.

-------------------------

In attachment 9017 [details] (i586), I see:

* urpmi error: ERROR: 'script' failed for glibc-6:2.22-21.mga6.i586
* urpmi error: ERROR: 'script' failed for glibc-6:2.22-21.mga6.i586

* urpmi error: ERROR: 'script' failed for dkms-broadcom-wl-6.30.223.271-45.mga6.nonfree.i586
^ That one is bug 20155.

Related script errors:

* sddm not installed, %triggerin(postfix-1:2.10.3-5.mga5.i586) scriptlet failed, exit status 127

/bin/sh: error while loading shared libraries: libtinfo.so.6: cannot open shared object file: No such file or directory
%triggerin(postfix-1:2.10.3-5.mga5.i586) scriptlet failed, exit status 127

/bin/sh: error while loading shared libraries: libtinfo.so.6: cannot open shared object file: No such file or directory
%triggerin(systemd-217-11.2.mga5.i586) scriptlet failed, exit status 127
Comment 28 David Walser 2017-03-18 22:53:58 CET
*** Bug 20517 has been marked as a duplicate of this bug. ***
Comment 29 Nicolas Lécureuil 2017-03-20 13:47:38 CET
I just tested upgrade from mga5 to 6 and i don't have this error.

I have one but for flash but because it failed to download flash.

i will open a bugreport later today about this.
Comment 30 Marja van Waes 2017-03-27 08:46:34 CEST
I'm wondering whether wilcal hit this in bug 20579, when upgrading, using the QA 6RC iso. He reported:

     error 'script' failed for glib-6:2.22-21.mga6.x86_64
Comment 31 ben mcmonagle 2017-03-28 01:51:26 CEST
(In reply to Marja van Waes from comment #30)
> I'm wondering whether wilcal hit this in bug 20579, when upgrading, using
> the QA 6RC iso. He reported:
> 
>      error 'script' failed for glib-6:2.22-21.mga6.x86_64

it is likely.

I have run an upgrade with i586 and the issue is still apparent.
iso build: Thu Mar 23 22:42:39 CET 2017

One other has reported (partially) on the pad https://pad.riseup.net/p/mageia6-rc
of the issue with i586.

I am reluctant to run an x86_64 upgrade to confirm the issue there.
However. if you require that I do , just ask.
Comment 32 Marja van Waes 2017-03-28 08:18:04 CEST
(In reply to ben mcmonagle from comment #31)
> (In reply to Marja van Waes from comment #30)
> > I'm wondering whether wilcal hit this in bug 20579, when upgrading, using
> > the QA 6RC iso. He reported:
> > 
> >      error 'script' failed for glib-6:2.22-21.mga6.x86_64
> 
> it is likely.

Indeed... a glib package doesn't even exist
> 
> I have run an upgrade with i586 and the issue is still apparent.
> iso build: Thu Mar 23 22:42:39 CET 2017
> 
> One other has reported (partially) on the pad
> https://pad.riseup.net/p/mageia6-rc
> of the issue with i586.
> 
> I am reluctant to run an x86_64 upgrade to confirm the issue there.
> However. if you require that I do , just ask.

No, wilcal's test already proved that this bug is valid for x86_64, too.

I won't close his bug as duplicate, because he mentioned some more errors.
Comment 33 Rémi Verschelde 2017-03-28 08:39:08 CEST
I've set up a big chroot following the instructions in comment 20, with these packages: basesystem task-gnome task-kde4 task-x11 task-cinnamon task-mate task-lxde task-xfce

After a while the upgrade failed (log is 30 MB uncompressed) due to Cauldron mirror issues (new llvm from yesterday changed on my hdlists during upgrade), but it already shows quite a few issues which might be interesting to debug:

http://remi.verschelde.fr/files/misc/LOG_mga5_to_mga6_chroot_upgrade.xz

Note that it was from a Cauldron host, using the urpmi-8.106-2.mga6 from core/updates_testing.

----------------------

Here's the part about glibc 'script' failure:

```
D: %post(glibc-6:2.22-22.mga6.x86_64): scriptlet start
fdio:       1 writes,     1688 total bytes in 0.000024 secs
D: %post(glibc-6:2.22-22.mga6.x86_64): execv(/usr/sbin/glibc-post-wrapper) pid 17649
D: %post(glibc-6:2.22-22.mga6.x86_64): waitpid(17649) rc 17649 status 0
D: Plugin: calling hook scriptlet_post in syslog plugin
D: %triggerin(systemd-217-11.2.mga5.x86_64): scriptlet start
fdio:       2 writes,      246 total bytes in 0.000014 secs
D: %triggerin(systemd-217-11.2.mga5.x86_64): execv(/bin/sh) pid 17664
/bin/sh: error while loading shared libraries: libtinfo.so.6: cannot open shared object file: No such file or directory
D: %triggerin(systemd-217-11.2.mga5.x86_64): waitpid(17664) rc 17664 status 7f00
attention : %triggerin(systemd-217-11.2.mga5.x86_64) scriptlet échoué, état de sortie 127
D: Plugin: calling hook scriptlet_post in syslog plugin
ERROR: 'script' failed for glibc-6:2.22-22.mga6.x86_64
```
Comment 34 Nicolas Lécureuil 2017-04-01 11:48:50 CEST
reproduced today with RC pretesting isos
Comment 35 Nicolas Lécureuil 2017-04-01 12:23:59 CEST
using the dvd i got the error but using urpmi --auto --auto-select --debug -vv --debug-librpm --deploops 2>&1|tee -a LOG.mga6 from mga5 and with dvd as update media it works.


i don't understand :/
Comment 36 Rémi Verschelde 2017-04-04 10:56:21 CEST
(In reply to Nicolas Lécureuil from comment #35)
> using the dvd i got the error but using urpmi --auto --auto-select --debug
> -vv --debug-librpm --deploops 2>&1|tee -a LOG.mga6 from mga5 and with dvd as
> update media it works.
> 
> 
> i don't understand :/

This might be because Cauldron has urpmi-8.106-2.mga6 which can proceed 50 packages per transaction, while the RC pretesting ISOs still had -1.mga6 which was limited to 8. -2.mga6 was since moved to core/release, so we can hope that the next set of ISOs will no longer trigger the bug.
Comment 37 Rémi Verschelde 2017-04-04 11:51:49 CEST
Nicolas says that pretesting ISOs have urpmi-8.106-2.mga6 too, so that's not fixed yet.
Comment 38 ben mcmonagle 2017-04-09 07:21:57 CEST
valid for:


Mageia-6-rc-i586-DVD.iso
Fri Apr  7 23:11:51 CEST 2017
Comment 39 Rémi Verschelde 2017-04-10 12:16:11 CEST
(In reply to Nicolas Lecureuil from comment #35)
> using the dvd i got the error but using urpmi --auto --auto-select --debug
> -vv --debug-librpm --deploops 2>&1|tee -a LOG.mga6 from mga5 and with dvd as
> update media it works.

Thierry, any idea how we could debug this further if it only happens when running the install from the DVD?
Comment 40 Martin Whitaker 2017-04-14 23:01:39 CEST
Well, the problem is that the circular dependency is still there:

% urpmq -d glibc
bash
bash-completion
dash-static
filesystem
glibc
grep
lib64ffi6
lib64glib2.0_0
lib64ncurses6
lib64pcre1
libgcc1
libstdc++6
pkgconfig
run-parts
setup

And as can be seen in comment 2, the problem occurs when urpmi chooses to install in this order:

ncurses-6.0-7.mga6.i586
bash-4.3-48.3.mga6.i586
grep-2.27-1.mga6.i586
glibc-2.22-21.mga6.i586
libncurses6-6.0-7.mga6.i586

The new version of bash uses libtinfo.so.6, which isn't present until libncurses6 is installed. So any attempt to run /bin/sh between installing the new version of bash and installing the new version of libncurses will fail. And running a scriptlet uses /bin/sh...
Comment 41 David Walser 2017-04-15 16:18:59 CEST
Thanks Martin, that helps.  The scriplets I pasted in Comment 1 (in systemd and postfix) probably need to be rewritten in lua then, so that bash isn't required at that point.

We also still have a circular dep as libncurses6 requires glibc which requires(post) bash which requires libncurses6, so %post in glibc at least should probably also be rewritten in lua.  I see glibc has Requires(post): dash-static, which may have been an attempt to get around that, but as only bash provides /bin/sh, that doesn't work.

Also glibc requires(post) grep which requires libpcre1 which requires glibc, so if the grepping in glibc's %post could be done in straight lua rather than calling out to grep, that would be good too.
Comment 42 Dave Hodgins 2017-04-20 21:06:27 CEST
Any progress on this one? It's a release blocker for the classic iso images.
Comment 43 Martin Whitaker 2017-04-22 20:41:34 CEST
(In reply to David Walser from comment #41)
> Thanks Martin, that helps.  The scriplets I pasted in Comment 1 (in systemd
> and postfix) probably need to be rewritten in lua then, so that bash isn't
> required at that point.

Alternatively, couldn't you fix this by replacing '%triggerin' with '%triggerin -p /bin/dash.static'.

> We also still have a circular dep as libncurses6 requires glibc which
> requires(post) bash which requires libncurses6, so %post in glibc at least
> should probably also be rewritten in lua.  I see glibc has Requires(post):
> dash-static, which may have been an attempt to get around that, but as only
> bash provides /bin/sh, that doesn't work.

%post in glibc uses /usr/sbin/glibc-post-wrapper, which in turn uses /bin/dash.static. I think the dependency on /bin/sh comes from the %transfiletriggerin clauses. And adding '-p /bin/dash.static' to these clauses does appear to remove the dependency.
Comment 44 Rémi Verschelde 2017-04-25 22:38:00 CEST
That sounds pretty good Martin. If you've tested it already, could you commit that change as it would fix this bug (AFAIU) which is the most blocking for upgrades uusing RC ISOs?

Might be worth adding a "# FIXME: Port to use lua" comment if we want to do that in the future.
Comment 45 Martin Whitaker 2017-04-26 00:04:39 CEST
OK, done. I've tested it locally and it doesn't seem to have broken anything...

This may be enough to fix this bug. If not, we can try doing the same for the file triggers David identified in comment 1.
Comment 46 Rémi Verschelde 2017-04-26 11:12:41 CEST
Martin's fixed has been submitted, so the QA team will be able to check this again in the next set of ISOs.

Note You need to log in before you can comment on or make changes to this bug.