+++ This bug was initially created as a clone of Bug #20111 +++ Which is about a different "'script' failed" issue, but this issue emerged in it. https://bugs.mageia.org/show_bug.cgi?id=20111#c14 (In reply to Marja van Waes from comment #14) > (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) > IINM this is the needed part from the logs: dkms-minimal-2.0.19-37.mga6.noarch dkms-2.0.19-37.mga6.noarch + /usr/sbin/dkms --rpm_safe_upgrade add -m broadcom-wl -v 6.30.223.271-45.mga6.nonfree + /usr/sbin/dkms --rpm_safe_upgrade build -m broadcom-wl -v 6.30.223.271-45.mga6.nonfree Error! Your kernel devel files for kernel 4.9.2-desktop-1.mga6 cannot be found at /lib/modules/4.9.2-desktop-1.mga6/build or /lib/modules/4.9.2-desktop-1.mga6/source. %post(dkms-broadcom-wl-6.30.223.271-45.mga6.nonfree.x86_64) scriptlet failed, exit status 1 dkms-broadcom-wl-6.30.223.271-45.mga6.nonfree.x86_64
Summary: [6sta2]partway through upgrade from Mga5 to Mga6 ERROR: 'script' failed for dkms-broadcom-wl-6.30.223.271-45.mga6.nonfree.x86_64" => partway through upgrade from Mga5 to Mga6 ERROR: 'script' failed for dkms-broadcom-wl-6.30.223.271-45.mga6.nonfree.x86_64"
Can this issue still be reproduced using current sta2 ISOs for an upgrade?
Created attachment 9032 [details] upgrade of 5.1 to m6-sta2 i586
This is happening because the installer is running kernel 4.9.3 but is installing kernel 4.9.13. The dkms build called by the postinstall script will only succeed if the kernel versions are the same. @Ben, was this the final sta2 ISO? I see kernel 4.9.4 when I run that (which doesn't help of course - I'm just curious about the discrepancy).
CC: (none) => mageia
(In reply to Martin Whitaker from comment #3) > > @Ben, was this the final sta2 ISO? I see kernel 4.9.4 when I run that (which > doesn't help of course - I'm just curious about the discrepancy). Yes > This is happening because the installer is running kernel 4.9.3 but is > installing kernel 4.9.13. The dkms build called by the postinstall script > will only succeed if the kernel versions are the same. ok. after upgrade wifi is not working. drakroam is unable to correct/connect so cannot configure. (cannot find network) running configure network from MCC does work. but need to change network encryption from open to correct pre shared key option. password is already entered. does not need to add any packages to complete network connection.
(In reply to ben mcmonagle from comment #4) > after upgrade wifi is not working. > drakroam is unable to correct/connect so cannot configure. (cannot find > network) > running configure network from MCC does work. but need to change network > encryption from open to correct pre shared key option. > password is already entered. > does not need to add any packages to complete network connection. If the dkms build fails during installation, it should get rerun automatically when you first boot the upgraded system (although this may be unreliable at the moment due to bug 17194). But maybe there's something the post-install script should do after the dkms build that didn't happen because the dkms build failed.
Might be a duplicate of bug 20347, or the other way around.
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=20347
(In reply to Martin Whitaker from comment #3) Note than we can check for the DURING_INSTALL variable and then do nothing in order to prevent such error. And/or prevent the scriptlet to ever fail
(In reply to Thierry Vignaud from comment #7) > (In reply to Martin Whitaker from comment #3) > Note than we can check for the DURING_INSTALL variable and then do nothing > in order to prevent such error. > And/or prevent the scriptlet to ever fail Yeah, I have some ideas of how to make dkms build against installed kernel... something like check for DURING_INSTALL, check uname -r based of installed kernel-*-latest or something, pass that to dkms like the kmod-* does their builds (or have kernel rpm write its uname -r to /etc/<something> and parse that in dkms posttrans) I only want to trigger the build for latest installed kernel to not prolong install time if they have lots of kernels installed. Or do all of that in installer, and have dkms-* not do anything in case of DURING_INSTALL or provide "empty" nvidia*-kernel-desktop-latest packages that do the specific dkms calls
(In reply to Rémi Verschelde from comment #6) > Might be a duplicate of bug 20347, or the other way around. you're right, I'll close that one
Keywords: 6sta2 => 6RCHardware: x86_64 => AllSource RPM: broadcom-wl => broadcom-wl-6.30.223.271-45.mga6
*** Bug 20347 has been marked as a duplicate of this bug. ***
(In reply to Thomas Backlund from comment #8) > Yeah, I have some ideas of how to make dkms build against installed kernel... Do we gain much by building the drivers during installation? They won't be used until the first boot, so why not leave it until then? In other words, skip the 'dkms build' and 'dkms install' in postinstall if DURING_INSTALL is set.
(In reply to Martin Whitaker from comment #11) > (In reply to Thomas Backlund from comment #8) > > Yeah, I have some ideas of how to make dkms build against installed kernel... > > Do we gain much by building the drivers during installation? They won't be > used until the first boot, so why not leave it until then? In other words, > skip the 'dkms build' and 'dkms install' in postinstall if DURING_INSTALL is > set. the first boot after an upgrade for me is about 5 minutes. see also comment #5. TBH, dkms build and or install during reboot would be fine, if the wifi configuration and password is retained.
(In reply to Martin Whitaker from comment #11) > (In reply to Thomas Backlund from comment #8) > > Yeah, I have some ideas of how to make dkms build against installed kernel... > > Do we gain much by building the drivers during installation? They won't be > used until the first boot, so why not leave it until then? In other words, > skip the 'dkms build' and 'dkms install' in postinstall if DURING_INSTALL is > set. Yeah, we gain "user friendly info" :) I've seen reports that for some users a dkms build can take ~15 minutes, wich means they are staring on a boot screen thinking "something is wrong" and go press the reset button... If we do it during install, we can pop up a window saying "rebuilding dkms drivers for first boot" or someting like that... Anyway, with currently building kernel-4.9.19-1, nvidia-current-375.39-2, nvidia340-340.102-2, nvidia304-304.135-2 the dkms build wont be triggered anymore during classical install... So now if we want to build dkms at end of install, we need installer to do: /usr/sbin/dkms_autoinstaller start %{kversion}-$kernel_flavour-%{buildrpmrel}
(In reply to Thomas Backlund from comment #13) > Yeah, we gain "user friendly info" :) > > I've seen reports that for some users a dkms build can take ~15 minutes, > wich means they are staring on a boot screen thinking "something is wrong" > and go press the reset button... Yes, I'd thought of that, but we have the same problem on first boot after a kernel update or when booting a Live DVD with proprietary drivers enabled. > If we do it during install, we can pop up a window saying "rebuilding dkms > drivers for first boot" or someting like that... Is it possible to get plymouth to display a message like this if a dkms build is triggered?
(In reply to Martin Whitaker from comment #14) ... > > Yes, I'd thought of that, but we have the same problem on first boot after a > kernel update or when booting a Live DVD with proprietary drivers enabled. > installing a kernel update trigger dkms build with posttrans: /usr/sbin/dkms_autoinstaller start %{kversion}-$kernel_flavour-%{buildrpmrel} so its built when they reboot > > Is it possible to get plymouth to display a message like this if a dkms > build is triggered? Maybe, I havent tried ..
(In reply to Thomas Backlund from comment #15) > so its built when they reboot *already built* ...
@Thomas: I've seen dkms packages rebuilt to add some logic to prevent such failures during installation, but dkms-broadcom-wl was not part of them, was it?
Summary: partway through upgrade from Mga5 to Mga6 ERROR: 'script' failed for dkms-broadcom-wl-6.30.223.271-45.mga6.nonfree.x86_64" => Upgrade from 5 to 6, ERROR: 'script' failed for dkms-broadcom-wl-6.30.223.271-45.mga6.nonfree.x86_64
(In reply to Rémi Verschelde from comment #17) > @Thomas: I've seen dkms packages rebuilt to add some logic to prevent such > failures during installation, but dkms-broadcom-wl was not part of them, was > it? Ping. Do we want the same fix applied for dkms-broadcom-wl, or a different solution?
Fixed in broadcom-wl-6.30.223.271-46.mga6
Resolution: (none) => FIXEDStatus: NEW => RESOLVED