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?
(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
(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. :-)
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
(it's the same with dkms-broadcom)
CC: (none) => doktor5000Summary: delay dkms-virtualbox compilation after boot => delay dkms-foo compilation after bootSource RPM: dkms-virtualbox => dkms
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 => ASSIGNEDAssignee: bugsquad => doktor5000
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.
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
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.
Keywords: NEEDINFO => (none)CC: (none) => sander.lepik
Well, on Mageia 2 and Cauldron a kernel install now triggers dkms build so it does not need to be rebuilt during boot.
So marking as resolved then. FWIW, my query on dksm-devel ml yielded no replies.
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED