Description of problem: Ran a network install, picked all package groups and after package installs had a pop up with numerous "ERROR:'script' failed for" messages without rpm name Two did show up, systemd_227-2.mga6 and pm-fallback-policy-0.1-14.mga5 remaining 100+ failures did not Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. pull all-nonfree.rdz, all.rdz, vmlinuz from http://mirrors.kernel.org/mageia/distrib/cauldron/x86_64/isolinux/x86_64/ 2. create network stanza in /boot/grub/menu.lst with something like title Network_install kernel (hd0,7)/vmlinuz root=/dev/ram3 ramdisk_size=32000 noresume vga=791 initrd (hd0,7)/all--nonfree.rdz 3. re-boot pick Network_install 4. During package selection phase. pick all package groups. I would suggest the package installer create a log in /root/ Reproducible: Steps to Reproduce:
If you still have a report.bug.xz from when it went wrong, then please attach it. Or would you have time to reproduce the problem, and get the needed report.bug? https://wiki.mageia.org/en/Triage_guide#Traditional_installer
CC: (none) => marja11, thierry.vignaudKeywords: (none) => NEEDINFO
Probably these ones: https://ml.mageia.org/l/arc/dev/2015-11/msg00360.html During the Mageia 5 development cycle, these errors would show the wrong package name, and now I guess they aren't showing a name at all.
Created attachment 7236 [details] report.bug.xz
attached report.bug.xz
Keywords: NEEDINFO => (none)
Looking through report.bug it might be better to use gdisk instead of fdisk. That way you can see the code/flags. gdisk snippet follows: Number Start (sector) End (sector) Size Code Name 1 2048 83888127 40.0 GiB 0700 mga5 2 83888128 171864063 42.0 GiB 0700 mga4 3 171864064 257384447 40.8 GiB 0700 mga5 4 257384448 342192127 40.4 GiB 0700 cauldron 5 342192128 387309567 21.5 GiB 0700 local 6 387309568 434296831 22.4 GiB 0700 accounts 7 434296832 558874623 59.4 GiB 0700 misc 8 558874624 712286207 73.2 GiB 0700 spare 9 712286208 1471924223 362.2 GiB 0700 vmguest fdisk snippet Device Start End Sectors Size Type /dev/sda1 2048 83888127 83886080 40G Microsoft basic data /dev/sda2 83888128 171864063 87975936 42G Microsoft basic data /dev/sda3 171864064 257384447 85520384 40.8G Microsoft basic data /dev/sda4 257384448 342192127 84807680 40.5G Microsoft basic data /dev/sda5 342192128 387309567 45117440 21.5G Microsoft basic data /dev/sda6 387309568 434296831 46987264 22.4G Microsoft basic data /dev/sda7 434296832 558874623 124577792 59.4G Microsoft basic data /dev/sda8 558874624 712286207 153411584 73.2G Microsoft basic data /dev/sda9 712286208 1471924223 759638016 362.2G Microsoft basic data
Same issue seen here using boot-nonfree.iso installing from local disk. Although I ended up with a bootable system, I couldn't log into my selected DE (Cinnamon) until I forcibly reinstalled one of packages that failed to install. (In reply to Bit Twister from comment #0) > I would suggest the package installer create a log in /root/ See /root/drakx/install.log (In reply to David Walser from comment #2) > Probably these ones: > https://ml.mageia.org/l/arc/dev/2015-11/msg00360.html Looks like it: # grep failed /root/drakx/install.log | wc -l 108 # grep failed /root/drakx/install.log | sort -u %post(pm-fallback-policy-0.1-14.mga5.noarch) scriptlet failed, exit status 1 %triggerin(desktop-common-data-1:3.10-2.mga6.noarch) scriptlet failed, exit status 127 %triggerin(desktop-file-utils-0.22-9.mga6.x86_64) scriptlet failed, exit status 127 %triggerin(fontconfig-2.11.94-1.mga6.x86_64) scriptlet failed, exit status 127 %triggerin(GConf2-3.2.6-13.mga6.x86_64) scriptlet failed, exit status 127 %triggerin(glib2.0-common-2.47.3-1.mga6.x86_64) scriptlet failed, exit status 127 %triggerin(man-db-2.7.5-1.mga6.x86_64) scriptlet failed, exit status 127 %triggerin(shared-mime-info-1.5-1.mga6.x86_64) scriptlet failed, exit status 127 %triggerin(systemd-227-2.mga6.x86_64) scriptlet failed, exit status 1 %triggerin(systemd-227-2.mga6.x86_64) scriptlet failed, exit status 127
CC: (none) => mageia
Hello, I have similar errors with an already installed cauldron, when trying to install some packages or updating. The installation didn't end. I need ^C. # LANGUAGE=C urpmi --auto-update --auto-select medium "Core Release" is up-to-date medium "Core Updates" is up-to-date medium "Nonfree Release" is up-to-date medium "Nonfree Updates" is up-to-date medium "core_src" is up-to-date To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "Core Release") abiword 3.0.1 6.mga6 x86_64 acpid 2.0.25 2.mga6 x86_64 cpupower 4.3.0 5.mga6 x86_64 [...] virtualbox-guest-additions 5.0.10 5.mga6 x86_64 wayland-protocols-devel 1.0 1.mga6 noarch x11-driver-input-wacom 0.32.0 1.mga6 x86_64 x11-driver-video-vboxvideo 5.0.10 5.mga6 x86_64 106MB of additional disk space will be used. 204MB of packages will be retrieved. Proceed with the installation of the 181 packages? (Y/n) y http://mirrors.mageia.org/api/mageia.cauldron.x86_64.list: media/core/release/lib64glib2.0-devel-2.47.3-1.mga6.x86_64.rpm http://mirrors.mageia.org/api/mageia.cauldron.x86_64.list: media/core/release/libgcc1-5.3.0-2.mga6.x86_64.rpm http://mirrors.mageia.org/api/mageia.cauldron.x86_64.list: media/core/release/lib64glib2.0_0-2.47.3-1.mga6.x86_64.rpm http://mirrors.mageia.org/api/mageia.cauldron.x86_64.list: media/core/release/lib64krb53-1.14-1.mga6.x86_64.rpm http://mirrors.mageia.org/api/mageia.cauldron.x86_64.list: media/core/release/lib64cups2-2.1.1-1.mga6.x86_64.rpm http://mirrors.mageia.org/api/mageia.cauldron.x86_64.list: media/core/release/gcc-5.3.0-2.mga6.x86_64.rpm http://mirrors.mageia.org/api/mageia.cauldron.x86_64.list: media/core/release/krb5-1.14-1.mga6.x86_64.rpm http://mirrors.mageia.org/api/mageia.cauldron.x86_64.list: media/core/release/gcc-cpp-5.3.0-2.mga6.x86_64.rpm http://mirrors.mageia.org/api/mageia.cauldron.x86_64.list: media/core/release/lib64gio2.0_0-2.47.3-1.mga6.x86_64.rpm http://mirrors.mageia.org/api/mageia.cauldron.x86_64.list: media/core/release/libstdc++-devel-5.3.0-2.mga6.x86_64.rpm http://mirrors.mageia.org/api/mageia.cauldron.x86_64.list: media/core/release/gcc-c++-5.3.0-2.mga6.x86_64.rpm http://mirrors.mageia.org/api/mageia.cauldron.x86_64.list: media/core/release/libstdc++6-5.3.0-2.mga6.x86_64.rpm http://mirrors.mageia.org/api/mageia.cauldron.x86_64.list: media/core/release/glib2.0-common-2.47.3-1.mga6.x86_64.rpm http://mirrors.mageia.org/api/mageia.cauldron.x86_64.list: media/core/release/glib-gettextize-2.47.3-1.mga6.x86_64.rpm installing glib2.0-common-2.47.3-1.mga6.x86_64.rpm libstdc++6-5.3.0-2.mga6.x86_64.rpm gcc-c++-5.3.0-2.mga6.x86_64.rpm glib-gettextize-2.47.3-1.mga6.x86_64.rpm libstdc++-devel-5.3.0-2.mga6.x86_64.rpm lib64gio2.0_0-2.47.3-1.mga6.x86_64.rpm krb5-1.14-1.mga6.x86_64.rpm gcc-5.3.0-2.mga6.x86_64.rpm lib64cups2-2.1.1-1.mga6.x86_64.rpm gcc-cpp-5.3.0-2.mga6.x86_64.rpm lib64glib2.0_0-2.47.3-1.mga6.x86_64.rpm lib64glib2.0-devel-2.47.3-1.mga6.x86_64.rpm libgcc1-5.3.0-2.mga6.x86_64.rpm lib64krb53-1.14-1.mga6.x86_64.rpm from /var/cache/urpmi/rpms Preparing... ##################################### 1/181: lib64glib2.0_0 ##################################### 2/181: lib64gio2.0_0 ##################################### 3/181: glib2.0-common ##################################### 4/181: gcc-cpp ##################################### 5/181: krb5 ##################################### 6/181: lib64krb53 ##################################### 7/181: glib-gettextize ##################################### 8/181: libgcc1 ##################################### 9/181: libstdc++6 ##################################### 10/181: libstdc++-devel ##################################### 11/181: gcc ##################################### 12/181: gcc-c++ ##################################### 13/181: lib64cups2 ##################################### 14/181: lib64glib2.0-devel ##################################### 1/14: removing lib64glib2.0-devel-2.47.1-1.mga6.x86_64 ##################################### 2/14: removing lib64cups2-2.1.0-3.mga6.x86_64 ##################################### 3/14: removing gcc-c++-5.2.1-0.20151110.1.mga6.x86_64 ##################################### 4/14: removing gcc-5.2.1-0.20151110.1.mga6.x86_64 ##################################### 5/14: removing glib2.0-common-2.47.1-1.mga6.x86_64 ##################################### 6/14: removing libstdc++-devel-5.2.1-0.20151110.1.mga6.x86_64 ##################################### 7/14: removing libgcc1-5.2.1-0.20151110.1.mga6.x86_64 ##################################### 8/14: removing libstdc++6-5.2.1-0.20151110.1.mga6.x86_64 ##################################### 9/14: removing glib-gettextize-2.47.1-1.mga6.x86_64 ##################################### 10/14: removing lib64gio2.0_0-2.47.1-1.mga6.x86_64 ##################################### 11/14: removing lib64krb53-1.12.2-12.mga6.x86_64 ##################################### 12/14: removing krb5-1.12.2-12.mga6.x86_64 ##################################### 13/14: removing lib64glib2.0_0-2.47.1-1.mga6.x86_64 ##################################### 14/14: removing gcc-cpp-5.2.1-0.20151110.1.mga6.x86_64 ##################################### ^Cwarning: %triggerin(man-db-2.7.5-1.mga6.x86_64) scriptlet failed, signal 2 ERROR: 'script' failed for
CC: (none) => yves.brungard_mageia
As far as I understand the individual script errors have to be fixed individually in the appropriate packages. Keeping this bug report for the fact that the installer wouldn't give the package names, though.
Assignee: bugsquad => thierry.vignaud
From http://www.rpm.org/wiki/FileTriggers: > Triggers with priority greater than 100000 will be executed before standard > scriptlets and the other triggers will be executed after standard scriptlets. > If you don't specify priority, the default priority is 1000000. I'm wondering if this documentation is correct or not. Once it talks about 100.000, another time about 1.000.000. Maybe the ldconfig glibc trigger should be priority 2.000.000?
CC: (none) => olav
CC: (none) => linux
(In reply to Samuel VERSCHELDE from comment #8) > As far as I understand the individual script errors have to be fixed > individually in the appropriate packages. Yes. and while there the dev/packager might consider a systemctl stop ... systemctl start ... instead of a systemctl start in the event the service is already running. That would prevent a incorrect/invalid/false trigger event. Better yet, maybe a macro that checks if active, then stop/start. That way install package will not start services which the system admin has stopped. > Keeping this bug report for the fact that the installer wouldn't give the > package names, though. Thank you. :)
CC: (none) => doktor5000
*** Bug 17236 has been marked as a duplicate of this bug. ***
CC: (none) => tarazed25
(In reply to Olav Vitters from comment #9) > I'm wondering if this documentation is correct or not. Once it talks about > 100.000, another time about 1.000.000. Maybe the ldconfig glibc trigger > should be priority 2.000.000? Well, that doesn't matter: ldconfig would still be run once per transaction so eg mandb wouldn't fail on every transaction Anyways, this can be tested with "urpmi --root T --debug-librpm"
How to debug these commands from the Live USB? E.g. if I choose "install" option from the live USB, how do I get it to log the installation of packages and which triggers it is execution + timestamps? I now have an empty slow HDD so I could now try getting a log of this.
Created attachment 7289 [details] drakinstaller report
see above attachment 7289 [details] I used the cauldron boot.iso. It took 3 attempts, I suspect the first two failed attempts were mirror issues. I had the same behaviour, many, many failed scripts, only a few of which had a name, most were blank. I was able to log in to x, but the desktop was sparse, and I could not open/start any program. Switching to tty2, I could use rpm and urpmi and mcc. rpm -VA showed pages of package issues. I removed and installed drakconf, but I could only start it in text, never in x.
Attachment 7289 mime type: text/plain => application/x-xz
From that attachment: /var/tmp/rpm-tmp.RQ0qEh: 1: /var/tmp/rpm-tmp.RQ0qEh: fc-cache: not found %triggerin(fontconfig-2.11.94-1.mga6.x86_64) scriptlet failed, exit status 127 /var/tmp/rpm-tmp.IHDfbK: 1: /var/tmp/rpm-tmp.IHDfbK: /usr/bin/gio-querymodules-64: not found %triggerin(glib2.0-common-2.47.4-1.mga6.x86_64) scriptlet failed, exit status 127 %triggerin(desktop-file-utils-0.22-9.mga6.x86_64) scriptlet failed, exit status 127 /var/tmp/rpm-tmp.P1cnXc: 1: /var/tmp/rpm-tmp.P1cnXc: update-menus: not found %triggerin(desktop-common-data-1:3.10-2.mga6.noarch) scriptlet failed, exit status 127 /var/tmp/rpm-tmp.VgqUqW: 1: /var/tmp/rpm-tmp.VgqUqW: /usr/bin/mandb: not found %triggerin(man-db-2.7.5-1.mga6.x86_64) scriptlet failed, exit status 127
Maybe it doesn't run these from the chroot?
Please try with glibc-2.22-13.mga6
(In reply to Thierry Vignaud from comment #18) > Please try with glibc-2.22-13.mga6 Unfortunately not. I just tried a fresh install with all package categories selected and got the usual full screen of ERRORs with no package names, followed by a screen saying that 198 transactions failed install for various reasons, mostly conflicts.The install would not complete, but dropped me back to repository selection. I have the files from /root/drakx (install.log, ddebug.log) if needed.
CC: (none) => ftg
Thierry: I think my earlier guess about ldconfig was wrong (or maybe there's two problems?) There are two filetriggers in glib2.0-common: # automatic gschema compilation on rpm installs/removals %transfiletriggerin -n %{name}-common -- %_datadir/glib-2.0/schemas/ if [ -x /usr/bin/glib-compile-schemas ]; then /usr/bin/glib-compile-schemas --allow-any-name %_datadir/glib-2.0/schemas/ fi # automatic update of gio module cache %transfiletriggerin -n %{name}-common -- %{_libdir}/gio/modules/ %{_bindir}/gio-querymodules-%{__isa_bits} %{_libdir}/gio/modules In the report.bug log there are various "command not found" errors, e.g.: /var/tmp/rpm-tmp.dZUQPH: 1: /var/tmp/rpm-tmp.dZUQPH: /usr/bin/gio-querymodules-64: not found However, there are no errors _at all_ regarding /usr/bin/glib-compile-schemas. The report.bug also mentions the installer calls ldconfig a few times. As the glib2.0-common checks for the program before executing and there are no errors that it couldn't execute, that's why I think it is not running it from the chroot. The paths are basically wrong.
Severity: major => enhancement
(In reply to Thierry Vignaud from comment #18) > Please try with glibc-2.22-13.mga6 Used Dec 22 01:56 boot.iso clean VirtualBox install. Problem still there.
When i run the installer i get the following message before the gui installer runs (typed from VirtualBox) : Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/%{ <-- HERE ARCH}/ at /usr/lib/libDrakX/install/media.pm line 83. Ignore the following Glib::Object::Introspection & Gtk3 warnings Too late to run INIT block at /usr/lib/perl5/vendor_perl/5.22.1/x86_64-linux-thread-multi/Glib/Object/Introspection.pm line 257.
Forgot one line: Subroutine Gtk3::main redefined at /usr/lib/perl5/vendor_perl/5.22.0/Gtk3.pm line 525.
(In reply to psyca from comment #22) > When i run the installer i get the following message before the gui > installer runs (typed from VirtualBox) : > > Unescaped left brace in regex is deprecated, passed through in regex; marked > by <-- HERE in m/%{ <-- HERE ARCH}/ at /usr/lib/libDrakX/install/media.pm > line 83. > Ignore the following Glib::Object::Introspection & Gtk3 warnings > Too late to run INIT block at > /usr/lib/perl5/vendor_perl/5.22.1/x86_64-linux-thread-multi/Glib/Object/ > Introspection.pm line 257. Old stuff, never fixed from some perl upgrade from years back.
Whiteboard: (none) => 6dev1
Dispite what I understand when looking at rpmlib code, sadly, the current filetriggers doesn't honour rpm's chroot. Thus it works fine with urpmi for online updates. But not with the drakx installer which installs packages in a chroot or with urpmi when using a chroot. Example: we've a ldconfig file trigger in glibc package: $ rpm -q --filetriggers glibc transfiletriggerin scriptlet (using /bin/sh) -- /lib/, /lib64/ grep -F '.so.' | ldconfig -X transfiletriggerin scriptlet (using /bin/sh) -- /etc/ld.so.conf.d/ ldconfig -X Let's test in a chroot with and without /sbin/ldconfig out of the chroot: mkdir TL2 mv /sbin/ldconfig{,.tv}; urpmi --no-recommends --root TL2 basesystem-minimal 2>&1|tee LOG.chroot2 mkdir TL1 mv /sbin/ldconfig{.tv,}; urpmi --no-recommends --root TL1 basesystem-minimal 2>&1|tee LOG.chroot1 diff -u LOG.chroot?|grep -1 ldconfig >ldconf.diff
Source RPM: (none) => rpmStatus: NEW => ASSIGNED
Fixed in rpm-4.13.0-0.rc1.16.mga6 (& then in drakx-installer-stage2-17.13-2.mga6 which is rebuild with fixed rpm)
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED
clean network install using 01-Feb-2016 21:58 vmlinuz, all.rdz files. Still had a blank script names,
Resolution: FIXED => (none)Status: RESOLVED => REOPENED
Summary: numerous ERROR: 'script' failed for messages without rpm name => urpmi doesn't identify trigger errors (numerous ERROR: 'script' failed for messages without rpm name)Source RPM: rpm => urpmi, rpm
(In reply to Bit Twister from comment #27) > clean network install using 01-Feb-2016 21:58 vmlinuz, all.rdz files. > > Still had a blank script names, Please provide proper details. This isn't good enough. You're reopening a bugreport that seemingly had nothing to do with you issue. This bugreport was about scripts not being started in a chroot. It was verified to be fixed. If there is some other issue, then file a _new_ bugreport with _clear_ details so something can actually be done!
Status: REOPENED => RESOLVEDResolution: (none) => FIXEDSummary: urpmi doesn't identify trigger errors (numerous ERROR: 'script' failed for messages without rpm name) => rpm filetrigger scripts are run outside of the chroot
(In reply to Olav Vitters from comment #28) > (In reply to Bit Twister from comment #27) > > clean network install using 01-Feb-2016 21:58 vmlinuz, all.rdz files. > > > > Still had a blank script names, > > Please provide proper details. I am sorry that you seem to have your panties in a twist. Might I suggest trying a clean pair. I have provided all the required "proper details" > This isn't good enough. Well, that would be _your_ _issue_ and not my _problem_. > You're reopening a bugreport that seemingly had nothing to do with you issue. I disagree. My _problem_ was stated in the original Summary: and in the Description section. > This bugreport was about scripts not being started in a chroot. I disagree. The investigation of my problem has indicated several scripts create failure messages which need to be resolved plus the problem you have indicated has been resolved. > It was verified to be fixed. Well, obviously that is not true at the time I reopened the bug report. I followed the same test procedure and had the same _problem_. > If there is some other issue, then file a _new_ bugreport with > _clear_ details so something can actually be done! Frap. Seems I can not please anyone at any time. I have people jumping on my ass about not using the bug reporting system to if full advantage, too much detail in steps to reproduce, you bitching I am not providing enough information,.... and I know for a fact I would get chewed out again for opening the same exact _problem_ report if I can reproduce the problem. Trust me. I started out as a Hardware Engineer's Aide building hardware from from schematics, debugging their design mistakes. Next job was designing interface hardware to test cards from production lines and write software to tell the repair tech which ic was bad on the card or what area they had to look at. Moved on to Software Quality assurance. Got tired manually running test plans, wrote an interpret to automatically test the software. After that worked my way up through software coder, designer, system designer, system analyst. Rest of the time I was help desk and maintenance programmer for several mission critical applications in the IT department. I can tell you for a fact. YOU should have opened a bug report about the chroot problem and not high jack _my_ _problem_ report and marked it Resolved. Your remark about "Please provide proper details. This isn't good enough." would seem to indicate you have an _issue_ with Thierry Vignaud. Being the methodical dev I believe Thierry to be, I assumed the proper procedure was followed by proving the _problem_ was producible, corrected the problem, tested it, checked in the changes, reran the install procedure and verified my _problem_ was indeed fixed, then marked my _problem_ resolved. Since I received the resolved notice, I then followed the same test procedure again and it failed with the same _problem_. The same screen with the title "ERROR:'script' failed for" was still blank for numerous errors. I suggest you take _your_ lack of _information_ _issue_ up with Thierry. If Thierry decided "ERROR:'script' failed for" was good enough title for the screen name then you need to talk to Thierry. Or better yet, get together with development team leaders and suggest some rule that all screens should have descriptive titles, preferably containing application name[-module name] which would a great help who, what, where for everyone involved in reporting, triage, repair, test process. Think about it, less than 2 minutes of dev time to add app[-module] to screens or report output and same test time to check it when dev is testing whatever bugreport is being squashed. Big win for everyone.
I didn't highjack this bugreport. I provided analysis for why these script errors occurred and tv wrote a brilliant patch. Thierry marked it as fixed. You did _NOT_ speak up at all during all the analysis, nor when the bugreport was marked as fixed. You seem entitled to think you know what I think about Thierry. He's awesome, sometimes we have misunderstandings. In this bugreport he fixed the chroot problem I thought occurred. As explained in the comment I wrote to you. Reread comment 25. There was a problem that the filetriggers running outside of the chroot. That is what work was done in this bugreport and the reason that _Thierry_closed_it_. Instead of complaining and driving wedges, maybe look at your reading skills? At the moment it seems Thierry and me are paid by you? You write a bugreport; ignore everything and then when it is fixed ignore everything that happened and what people said. If that leads to a miscommunication, obviously go out in full force and blame everyone except yourself. Yeah, originally you wanted something else and some other problem was fixed. Keep this open will make it confusing what it is about. In case you wonder: If I reply to you I don't have a problem with either you, nor with unrelated people. E.g. I don't have a problem with Linus Torvalds. Again, Thierry clearly mentioned everything.