Bug 20155 - Upgrade from 5 to 6, ERROR: 'script' failed for dkms-broadcom-wl-6.30.223.271-45.mga6.nonfree.x86_64
Summary: Upgrade from 5 to 6, ERROR: 'script' failed for dkms-broadcom-wl-6.30.223.271...
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
: release_blocker normal
Target Milestone: ---
Assignee: Kernel and Drivers maintainers
QA Contact:
URL:
Whiteboard:
Keywords: 6RC
: 20347 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-01-21 22:39 CET by Marja van Waes
Modified: 2017-04-26 20:29 CEST (History)
11 users (show)

See Also:
Source RPM: broadcom-wl-6.30.223.271-45.mga6
CVE:
Status comment:


Attachments
upgrade of 5.1 to m6-sta2 i586 (224.78 KB, application/octet-stream)
2017-03-06 20:26 CET, ben mcmonagle
Details

Description Marja van Waes 2017-01-21 22:39:17 CET
+++ 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
Comment 1 Rémi Verschelde 2017-03-06 10:23:17 CET
Can this issue still be reproduced using current sta2 ISOs for an upgrade?
Comment 2 ben mcmonagle 2017-03-06 20:26:43 CET
Created attachment 9032 [details]
upgrade of 5.1 to m6-sta2 i586
Comment 3 Martin Whitaker 2017-03-12 12:39:54 CET
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).
Comment 4 ben mcmonagle 2017-03-12 19:58:43 CET
(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.
Comment 5 Martin Whitaker 2017-03-12 20:52:42 CET
(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.
Comment 6 Rémi Verschelde 2017-03-29 08:37:43 CEST
Might be a duplicate of bug 20347, or the other way around.
Comment 7 Thierry Vignaud 2017-03-29 10:28:13 CEST
(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
Comment 8 Thomas Backlund 2017-03-29 10:55:17 CEST
(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
Comment 9 Marja van Waes 2017-03-29 11:39:38 CEST
(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
Comment 10 Marja van Waes 2017-03-29 11:40:17 CEST
*** Bug 20347 has been marked as a duplicate of this bug. ***
Comment 11 Martin Whitaker 2017-03-29 21:23:10 CEST
(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.
Comment 12 ben mcmonagle 2017-03-29 21:42:22 CEST
(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.
Comment 13 Thomas Backlund 2017-03-30 13:02:01 CEST
(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}
Comment 14 Martin Whitaker 2017-03-30 19:51:57 CEST
(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?
Comment 15 Thomas Backlund 2017-03-30 20:04:10 CEST
(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 ..
Comment 16 Thomas Backlund 2017-03-30 20:05:51 CEST
(In reply to Thomas Backlund from comment #15)


> so its built when they reboot

*already built* ...
Comment 17 Rémi Verschelde 2017-04-04 10:16:11 CEST
@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?
Comment 18 Rémi Verschelde 2017-04-26 11:33:19 CEST
(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?
Comment 19 Thomas Backlund 2017-04-26 20:29:53 CEST
Fixed in broadcom-wl-6.30.223.271-46.mga6

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