Bug 2499

Summary:	delay dkms-foo compilation after boot
Product:	Mageia	Reporter:	Jerome Quelin <jquelin>
Component:	RPM Packages	Assignee:	Florian Hubold <doktor5000>
Status:	RESOLVED FIXED	QA Contact:
Severity:	enhancement
Priority:	Normal	CC:	davidwhodgins, doktor5000, mageia, tmb
Version:	Cauldron
Target Milestone:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Source RPM:	dkms	CVE:
Status comment:

Description Jerome Quelin 2011-08-23 16:02:17 CEST

when rebooting for whatever reason, with a new kernel, it takes time to compile dkms-virtualbox - and during that time, boot is halted. and most of the time, this is useless: i'm using virtualbox from time to time - but very seldom. which means that i'm paying a cost at every boot for sthg that i'm not really using.

what would it cost to delay the dkms-virtualbox compilation to after boot is complete, or maybe just before starting virtualbox itself?

Comment 1 Thomas Backlund 2011-08-23 21:01:17 CEST

(In reply to comment #0)

> which means that i'm paying a cost at every boot for sthg that i'm not really
> using.

Not at every boot, only if kernel is updated.

> 
> what would it cost to delay the dkms-virtualbox compilation to after boot is
> complete, or maybe just before starting virtualbox itself?

A rewrite/patching of dkms to add support for user selected delayed builds, 
but problem is how to make it rock solid.

CC: (none) => tmb

Comment 2 Jerome Quelin 2011-08-24 09:40:37 CEST

(In reply to comment #1)
> Not at every boot, only if kernel is updated.

i know, but given that i reboot my laptop only every month or so, it really means at every boot. :-)

Comment 3 Dave Hodgins 2011-08-25 05:34:15 CEST

In the meantime, as a workaround, edit /etc/sysconfig/system and add a line with
DKMS_ONBOOT=no

That will stop /etc/rc.d/init.d/mandrake_everytime from calling
/usr/sbin/dkms_autoinstaller, which you could run at your
leisure, before starting the vbox services.

CC: (none) => davidwhodgins

Comment 4 Manuel Hiebel 2011-10-30 00:59:14 CEST

(it's the same with dkms-broadcom)

CC: (none) => doktor5000
Summary: delay dkms-virtualbox compilation after boot => delay dkms-foo compilation after boot
Source RPM: dkms-virtualbox => dkms

Comment 5 Florian Hubold 2011-10-30 15:32:53 CET

Is it really worth the hassle if all you gain is 1 or 2 minutes during boot once in a month, if there is a workaround and the current system is working fine and is stable?

All you would save is maybe like 25 minutes in a whole year, if taking 12 kernel updates during one year as worst-case scenario. Compared to the time this gonna take to implement i'd say the costs (and associated risks) are higher than the advantages.

I'll ask on dkms-devel mailing list about this, though.
Maybe there is an easy way to do this.

Status: NEW => ASSIGNED
Assignee: bugsquad => doktor5000

Comment 6 Thomas Backlund 2011-10-30 15:39:03 CET

Or maybe we should think on it from the other side...

Have a new kernel install trigger the dkms rebuild directly, 
maybe shielded by a sysconfig flag to disable the function if needed.

Comment 7 Marja Van Waes 2012-05-26 13:08:01 CEST

Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

Comment 8 Jerome Quelin 2012-05-27 09:34:24 CEST

this is an enhancement request, so even if mageia 2 doesn't have it, it should stay assigned to cauldron since it won't land in mageia 2 at all.

Sander Lepik 2012-05-27 10:06:08 CEST

Keywords: NEEDINFO => (none)
CC: (none) => sander.lepik

Comment 9 Thomas Backlund 2012-05-27 10:38:34 CEST

Well, 

on Mageia 2 and Cauldron a kernel install now triggers dkms build so it does not need to be rebuilt during boot.

Comment 10 Florian Hubold 2012-08-12 16:15:21 CEST

So marking as resolved then. FWIW, my query on dksm-devel ml yielded no replies.

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED