Release Engineering

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

FS#27592 - kernel26-lts /linux-lts mkinticpio config

Attached to Project: Release Engineering
Opened by Ben Hormann (Ben H) - Friday, 16 December 2011, 10:23 GMT
Last edited by Gerardo Exequiel Pozzi (djgera) - Monday, 26 November 2012, 04:47 GMT
Task Type Bug Report
Category AIF
Status Closed
Assigned To Dieter Plaetinck (Dieter_be)
Architecture All
Severity Low
Priority Normal
Reported Version testbuild (specify!)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No


During installation (at end of configuration), mkinitcpio give an error due to missing expected file /etc/mkinitcpio.d/linux.preset

Additional info:
mkinitcpio 0.8.0-3

Steps to reproduce:
New arch installation with kernel26-lts and without linux. After configuration, mkinitcpio attempts to create the initfs images but give error.

/etc/mkinitcpio.d/kernel26.preset could be renamed to linux.preset in the kernel26-lts package. But mkinitcpio should find the kernel26-lts.preset, so the problem really seems to be with the install script specifying a specific preset.

(or is there something I've missed? I copied kernel26.preset to linux.preset for now. Is it likely that linux.preset will be needed again post installation?)
This task depends upon

Closed by  Gerardo Exequiel Pozzi (djgera)
Monday, 26 November 2012, 04:47 GMT
Reason for closing:  Deferred
Comment by Ionut Biru (wonder) - Friday, 16 December 2011, 10:43 GMT
this is a bug in AIF. it makes the assumption that only a kernel exists in the repo and tries to rerun mkinitcpio -p linux after Configure
Comment by Dieter Plaetinck (Dieter_be) - Friday, 16 December 2011, 11:01 GMT
so, aif needs to run `mkinitcpio -p kernel26` in this case?
and how will the mkinitcpio preset be called when the LTS kernels are also 3.x ? linux-lts ? maybe we can update the naming of the LTS stuff to also use `linux` instead of `kernel26`, we don't need to wait for the lts kernel to be actually 3.x for that. it would be more consistent and will need to happen at some point anyway. and then i only need to unbreak aif once. instead of once now and another time when the actual rename happens in a few months.
Comment by Ionut Biru (wonder) - Friday, 16 December 2011, 11:56 GMT
in that case should run mkinitcpio -p kernel26-lts because the preset name is kernel26-lts.preset (/etc/mkinitcpio.d/).

if i recall, the maintainer wants to rename that kernel when 2.6.32 is dropped from long term release and updated to a newer version but don't know when this will happen
Comment by Ben Hormann (Ben H) - Friday, 16 December 2011, 12:15 GMT
Sorry, my mistake. It needs to be mkinitcpio -p kernel26-lts.
But I wouldn't bother changing it till just now if you know it will be renamed soon. If I a newbie like me can work around it then so can anyone else that knows they actually need the lts kernel.
Does the lts kernel go through the testing repos, because I don't see any...? I'm not really wanting to use 3.x anyway, no good reason.
Comment by Dieter Plaetinck (Dieter_be) - Friday, 16 December 2011, 12:31 GMT
can multiple kernel packages be installed at the same time?
if not, we can be sure there will only be 1 preset (other than example.preset), and
AIF chould just do something like:
preset=$(basename $(ls -1 /etc/mkinitcpio.d/ | grep -v example\.preset) .preset)
mkinitcpio -p $preset

or to be more robust (i.e. mkinitcpio could in the future contain more presets, or the example might not be named example.preset, or if/when we support multiple kernels), AIF could ls -l /etc/mkinitcpio.d/, filter out examples, and if there's more than one, give the user a list and let him choose.
Or, at the point AIF wants to re-invoke mkinitcpio, we should somehow inspect which kernel was last installed in the system, and use the corresponding mkinitcpio preset. But I'm not sure what is the best way to do that.
Either way, I don't want to hardcode any more preset names in AIF, there should be a more reliable way.
Comment by Ben Hormann (Ben H) - Friday, 16 December 2011, 12:58 GMT
I doubt you can select more than two kernels, but I'm fairly sure I managed to forget to unselect the normal kernel last time I tried (earlier this year) and ended up with both.
So AIF shouldn't be expected to deal with anything more than those two kernels.
Comment by Dieter Plaetinck (Dieter_be) - Monday, 26 December 2011, 18:00 GMT
so i implemented the way i described before, making aif compatible with scenarios of $any_kernel or even multiple different kernels
can anyone test this works with the LTS kernel? kthx (using any testbuild built after right now)
Comment by Tom Gundersen (tomegun) - Saturday, 10 March 2012, 11:35 GMT
An option here is to make your life easier by simply not calling mkinitcpio manually.

Two options:

1) make sure the default mkinitcpio works in all cases, and let the users optimize it after booting into the real system.
2) drop the user into the chroot after installation where they can do things like configure their mkinitcpio, and other post-install operations/tweaks that must be done before a reboot.
3) (much bigger change): install the kernel (and hence get the autogenerated initramfs) after the user has configured his/her mkinitcpio.conf. This means having two stages of installing packages, maybe other things also make sense to split until after configuration?