Description of problem: Error window appears during upgrade to mageia 3 Version-Release number of selected component (if applicable): Mageia-3-beta3-i586-DVD.iso How reproducible: Starting with mga2 install with all updates, upgrade to mageia 3 using the Mageia-3-beta3-i586-DVD.iso Steps to Reproduce: 1. upgrade mageia 2 using Mageia-3-beta3-i586-DVD.iso 2. choose upgrade (do not destroy existing install) 3. except for the partitioning option, use defaults 4. wait for "INSTALLING" stage when this error occurs Workaround: Hit return or continue and the install proceeds Reproducible: Steps to Reproduce:
URL: (none) => http://picpaste.com/4a39d7649f3dec09882e17f55684bd39.png
can you attach your file /root/drakx/upgrade.log (or ddebug.log) I don't remember
Keywords: (none) => NEEDINFOComponent: Release (media or process) => RPM PackagesSource RPM: (none) => ppp
Confirmed here. I'll add some logs when it's done.
Whiteboard: (none) => 3beta3
Created attachment 3633 [details] report.bug.xz report.bug.xz from failed upgrade. Tried to complete the upgrade several times so there may be some repetition but ERROR: 'sript' failed for ppp only showed once.
Keywords: NEEDINFO => (none)
interesting part: <27>[ 830.867847] systemd-tmpfiles[2072]: Failed to open initscripts.conf: No such file or directory <27>[ 833.725800] systemd-tmpfiles[2098]: Failed to open ppp.conf: No such file or directory * installed package ppp-2.4.5-6.mga2.i586 is conflicting with initscripts-9.41-12.mga3.i586 (Conflicts: ppp[<= 2.4.5-7]) * promoting ppp-2.4.5-14.mga3.i586 because of conflict above * selecting ppp-2.4.5-14.mga3.i586 * set_rejected: ppp-2.4.5-6.mga2.i586 * urpmi error: ERROR: 'script' failed for ppp-2.4.5-14.mga3.i586: %post(ppp-2.4.5-14.mga3.i586) scriptlet failed, exit status 1 ppp-2.4.5-14.mga3.i586 file /var/run/ppp/resolv.conf: remove failed: No such file or directory file /var/run/ppp: remove failed: No such file or directory
Priority: Normal => release_blockerCC: (none) => arnaud.patard, johnny, mageia, thierry.vignaudBlocks: (none) => 8016Summary: script fails for ppp during mga2 -> mga3 upgrade => post script fails for ppp during mga2 -> mga3 upgrade
(In reply to Manuel Hiebel from comment #4) > interesting part: > > <27>[ 830.867847] systemd-tmpfiles[2072]: Failed to open initscripts.conf: > No such file or directory > <27>[ 833.725800] systemd-tmpfiles[2098]: Failed to open ppp.conf: No such > file or directory > ... > > * urpmi error: ERROR: 'script' failed for ppp-2.4.5-14.mga3.i586: > > %post(ppp-2.4.5-14.mga3.i586) scriptlet failed, exit status 1 > ppp-2.4.5-14.mga3.i586 ppp postinstall scriptlet is /usr/bin/systemd-tmpfiles --create ppp.conf another interesting part of the log is update order of initscripts, ppp and systemd: xzcat report.bug.xz | grep -n "ERROR: 'script'\|update of initscripts\|update of ppp\|update of systemd" 20450:* trans: scheduling update of initscripts-9.41-12.mga3.i586 20457:* trans: scheduling update of ppp-2.4.5-14.mga3.i586 20458:* urpmi error: ERROR: 'script' failed for ppp-2.4.5-14.mga3.i586: 20553:* trans: scheduling update of systemd-units-195-15.mga3.i586 20638:* trans: scheduling update of systemd-195-15.mga3.i586 systemd is updated after initscripts and ppp, and here is the problem, because initscripts and ppp postinstall scripts run with mga2 systemd-tmpfiles, which only supports absolute path for <program.conf>, and fails to open initscripts.conf and ppp.conf. @Colin All packages that use %_tmpfilescreate *.conf should probably need a Requires(post) systemd >= systemd_version_that_handle_basename_conf to ensure that a recent systemd is installed before the update of these packages. btw, in most of cases couldn't we make %_tmpfilescreate program.conf non fatal (by appending || /usr/bin/true) in case of error ?
CC: (none) => lmenutHardware: i586 => All
That would be "|| :"
Ahh right yeah good catch re the versioned requires. I'm not sure about the "|| :" appending tho'. It's masking a genuine error in that case. I mean if in the old days RPM failed to create the /var/run/foo dir on package installation, would you expect it to be silent about it? Sure these are usually trivial errors but they can still affect a service from running. e.g. I have had several bug reports about people installing something and then saying it doesn't start due to tmpfiles not running properly...
Assigning to me.
Assignee: bugsquad => mageia
CC: (none) => eeeemail
mpage script failed in today's upgrade from beta3 dvd, showed a pop-up error with ppp and mpage. Is this a separate issue or another symptom of the same one? There's nothing obvious in report.bug. https://dl.dropbox.com/u/4147101/mga3b3/report2.bug.xz urpmi error: ERROR: 'script' failed for mpage-2.5.6-5.mga3.i586:
Also a new one of these.. systemd-tmpfiles[2180]: Failed to open httpd.conf: No such file or directory
(In reply to Colin Guthrie from comment #7) ... > I'm not sure about the "|| :" appending tho'. It's masking a genuine error > in that case. hum, I understand, but IIUC it's what happen when there are other commands that run fine after %_tmpfilescreate. urpmi seems to return with error on a script only when the last command fails. eg. in c5, systemd-tmpfiles fails for initscripts and ppp but we have "urpmi error: ERROR: 'script' failed " only for ppp, but not for initscripts because the commands after %_tmpfilescreate don't fail.
(In reply to claire robinson from comment #9) > mpage script failed in today's upgrade from beta3 dvd, showed a pop-up error > with ppp and mpage. > > Is this a separate issue or another symptom of the same one? > > There's nothing obvious in report.bug. > https://dl.dropbox.com/u/4147101/mga3b3/report2.bug.xz > > urpmi error: ERROR: 'script' failed for mpage-2.5.6-5.mga3.i586: I don't understand this error because mpage doesn't have any script. Thierry, an idea?
(In reply to claire robinson from comment #10) > Also a new one of these.. > > systemd-tmpfiles[2180]: Failed to open httpd.conf: No such file or directory same problem as comment 5; apache is updated before systemd. xzcat report2.bug.xz | grep -n "ERROR: 'script'\|update of initscripts\|update of ppp\|update of apache\|update of systemd" 23693:* trans: scheduling update of initscripts-9.41-12.mga3.i586 23703:* trans: scheduling update of ppp-2.4.5-14.mga3.i586 23705:* urpmi error: ERROR: 'script' failed for ppp-2.4.5-14.mga3.i586: 23796:* trans: scheduling update of apache-mod_perl-2.0.7-11.mga3.i586 23840:* trans: scheduling update of apache-2.4.4-1.mga3.i586 23855:* trans: scheduling update of systemd-195-15.mga3.i586 23869:* trans: scheduling update of systemd-units-195-15.mga3.i586 25500:* trans: scheduling update of apache-commons-logging-1.1.1-21.mga3.noarch 25763:* urpmi error: ERROR: 'script' failed for mpage-2.5.6-5.mga3.i586: 26480:* trans: scheduling update of apache-commons-codec-1.7-2.mga3.noarch 26555:* trans: scheduling update of apache-commons-lang-2.6-9.mga3.noarch 27091:* trans: scheduling update of apache-mod_php-5.4.12-2.mga3.i586
Just tested the upgrade on the Mageia-3-beta3-i586-DVD in my VB environment and it still errors. (Just to confirm; this is now VB 4.2.10, still under Scientific Linux 6.3)
CC: (none) => bozonius
Maybe this is interesting? From console 4, I notice the following: http://picpaste.com/830b8de36b83b193eb8c54938ae74a3b.png I suggest that perhaps the installer expects files that don't exist yet? I will examine my installed Mageia 2 environment in a moment...
BTW, my upgraded VM does NOT hang this time. I did not experience the httpd error Claire reports, though, just for the record. And the system comes up in X and the KDE desktop; no errors after reboot.
Back to my M2 VM state: There is no /etc/ppp.conf or /etc/ppp/ppp.conf file (would it be somewhere else? it doesn't seem to come with the M2 ppp). There is, however, an initscripts.conf file in /etc/tmpfiles.d. My M2 configuration should be pretty much what comes with its installer, plus any updates to those packages. I don't recall installing anything else, or modifying my /etc in any way. This VM install was strictly for testing upgrade to M3B3.
(In reply to bozonius from comment #16) > I did not experience the httpd error Claire reports, though, just for the > record. Did you install apache before upgrading?
[colin@jimmy ~]$ urpmf ppp.conf ppp:/usr/lib/tmpfiles.d/ppp.conf This is all to do with the tmpfiles.d config. I've not yet gone through and done a mass-update of the packages using this so the error will obviously still exist until it has been fixed! I will try and do so shortly.
(In reply to claire robinson from comment #18) > (In reply to bozonius from comment #16) > > I did not experience the httpd error Claire reports, though, just for the > > record. > > Did you install apache before upgrading? (DOH!) no. sorry.
FWIW, I'm waiting for my git-svn clone of all packages to perform this update. I hope to be able to do it over the weekend.
I've fixed all the packages calling %tmpfilescreate macro to require a newer systemd such that they should be ordered correctly on upgrade.
And I've now also fixed a whole bunch of other packages that were not using the nice tmpfiles macros but calling it directly.
Hi Colin, what is the status on that one? Thanks.
CC: (none) => pierre-malo.denielou
So this should be fixed now AFAIK. We were waiting for people to test things, but nobody has said much. I'll go ahead and close this as any other occurrence of it will likely be reported outside of this bug.
Status: NEW => RESOLVEDResolution: (none) => FIXED
I'll check it again now with boot.iso. RC DVD's are not yet available.
Not sure if it's the same thing but with upgrade from 3RC DVD ERROR: 'script' failed for firefox-gl-17.0.5-1.mga3.noarch.
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
Obviously, it's a different issue, so please open another bug report
Status: REOPENED => RESOLVEDResolution: (none) => FIXED
(with your /root/drakx/report.bug.xz)
This affects more than ppp Thierry so nothing obvious about it.
The previous bug was ppp post script faillure. Now you've another package that is buggy. that has nothing to do with _this_ bug report which is about ppp faillure.
New bug 9766 created, please find logs there, (why?) although it appears to be the same issue.
Little point asking for tests and then berating the results..
Just to round this off, this bug ultimately did affect several packages as was made obvious in comment 5 and comment 7 but the bug title was not updated to reflect this. Sadly the logs don't provide much information other than "script failed" so it's not immediately obvious to reporters if the problem is the same or something different. Just a bit of a communication breakdown and mismatch of "technical-obviousness" vs. "observable-obviousness". I'm certain no offence was meant by anyone :) Anyway, glad this upgrade issue is fixed :)