Release Engineering

This project is intented for all release related issues (isos, installer, etc), under the umbrella of the ArchLinux Release Engineers
Tasklist

FS#13105 - don't run mkinitcpio needlessly: [PATCH] setup split kernel install process to speedup installation

Attached to Project: Release Engineering
Opened by Gerardo Exequiel Pozzi (djgera) - Tuesday, 03 February 2009, 00:18 GMT
Last edited by Gerardo Exequiel Pozzi (djgera) - Monday, 26 November 2012, 04:39 GMT
Task Type Feature Request
Category AIF
Status Closed
Assigned To Tobias Powalowski (tpowa)
Aaron Griffin (phrakture)
Gerhard Brauer (GerBra)
Dieter Plaetinck (Dieter_be)
Architecture All
Severity Very Low
Priority Normal
Reported Version 2009.01-beta
Due in Version 2011.01.whatever
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Hi

Intro:
kernel26 install process is very slow compared to all packages installation, because the mkinitcpio step. But this step is repeated one more time at the "configure system" phase.

My solution:
I modified the setup script to speedup the installation process. This skip the kernel scriptlet at the "install packages" phase,
then only at run_mkinitcpio() is executed.

I added "depmod" at run_mkinitcpio() to respect the scriptlet process.

The patch is attached.
This task depends upon

Closed by  Gerardo Exequiel Pozzi (djgera)
Monday, 26 November 2012, 04:39 GMT
Reason for closing:  Deferred
Comment by Gerardo Exequiel Pozzi (djgera) - Friday, 06 February 2009, 18:14 GMT
Oops, please IGNORE the first patch, it contains hardcoded /mnt and missing $DESTDIR when looking for mkinitcpio config for obtain the kernel version of installed system. (If not have this, for example it fails when install the system with a "2009.02-FTP" that have kernel 2.6.28-ARCH, and the upstream kernel is 2.6.29-ARCH)

Patch is attached to fix this.

I tested it and worked fine :) Now Arch Linux install more fast :P
Comment by Gerhard Brauer (GerBra) - Monday, 09 February 2009, 13:48 GMT
I don't want to make any changes to the "old" installer other than showstopper bugfixes.
Next installer will be aif (in nothing big happened), so we should see how aif handle this thing, and if aif could benefit from this patch.
@Dieter: assign this also to you, so you get informed.
Comment by Dieter Plaetinck (Dieter_be) - Monday, 09 February 2009, 18:53 GMT
This is one of the points of aif's TODO list :) . Doing mkinitcpio twice makes it unnecesarily longer indeed. I reopened and assigned to AIF.

Gerardo, I like your patch, it's a bit hacky but it's a good starting point.
Have a look at http://github.com/Dieterbe/aif/blob/e9c113324dfa3f40206a280f99aa47e4d731debf/src/core/libs/lib-software.sh (installpkg function)
Also check out the run_background , follow_progress functions etc whith allow you to do a cleaner implementation

Btw, instead of putting the "lowlevel" logic in run_mkinitcpio, wouldn't it be much easier+cleaner to just (re)install the kernel on the target system?
Comment by Gerardo Exequiel Pozzi (djgera) - Wednesday, 11 February 2009, 21:19 GMT
hehe :) Yes it's a bit trick

OK, in the next days, i will testing AIF and send patches that from my point of view would be interested.
Comment by Dieter Plaetinck (Dieter_be) - Wednesday, 11 February 2009, 21:20 GMT
keep in mind to patch against the experimental branch. it's the bleeding edge :) (and right now it's quite stable btw)
Comment by Dieter Plaetinck (Dieter_be) - Sunday, 15 February 2009, 12:10 GMT
Tobias/Aaron, what do you guys think of this?
I'm thinking about something like this:
- during package installation: do not install kernel26 at all, or install it with --noscriptlet (do any packages depend on kernel26? are there any scriptlets other then mkinitcpio?)
- after configuring the system: install kernel26 normally.
Comment by Tobias Powalowski (tpowa) - Monday, 16 February 2009, 06:30 GMT
well, if it doesn't affect installation of binary addon modules it would be fine.
Comment by Dieter Plaetinck (Dieter_be) - Monday, 16 February 2009, 19:08 GMT
Wait, let me rephrase :)

I know _shit_ about the packaging of the kernel/modules, what happens during installation and what I safely can and can't do.

What I do know is that at a certain point during installation all packages get installed to the target the system including the kernel, at which point mkinitcpio is executed.
Later, after the "configure system" step the user *may* have changed his mkinitcpio.conf so we run mkinitcpio again.

Sure we could md5sum mkinitcpio.conf and only run mkinitcpio a 2nd time if the file has changed, but shouldn't it be possible to only run once? (eg after the configure system)
There are several ideas posted on this page.

Please tell me your thoughts, and just tell me what I should do :)
Comment by Gerhard Brauer (GerBra) - Monday, 16 February 2009, 19:17 GMT
My 2ct: Leave it as it is. It's proofed (pacman does the right job with the kernel). Hacking therein makes the package installation maybe a little faster, but: 1,2 minutes - who cares? Hey, installation is something user will hopefully not do often....
Comment by Tobias Powalowski (tpowa) - Monday, 16 February 2009, 19:21 GMT
just an other thing, people may want to skip steps in setup, so mkinitcpio should be run at least during package installation.
Comment by Dieter Plaetinck (Dieter_be) - Monday, 16 February 2009, 19:31 GMT
Tobias, sure they can skip steps, but as long as they exit the installer in a reasonable way (eg don't crash it) we can always put a little check at the end that does a mkinitcpio if it hasn't happened yet.
Comment by Dieter Plaetinck (Dieter_be) - Sunday, 12 December 2010, 15:59 GMT
We might get the "only run once" thing working, but I wouldn't feel very confident in the long term.
It would have been nice, but it's not worth it.
For now, I think the md5sum on mkinitcpio.conf is a good compromise between benefit and code complexity. This should be trivial to patch.

Dieter
Comment by Dieter Plaetinck (Dieter_be) - Wednesday, 29 December 2010, 18:38 GMT
are there any other (config) files initcpio depends on? what about /usr/lib/locale/locale-archive? (generated by locale-gen)

Loading...