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
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
|
Details
Description:
During installation (at end of configuration), mkinitcpio give an error due to missing expected file /etc/mkinitcpio.d/linux.preset Additional info: archlinux-2011.08.19-netinstall-i686.iso kernel26-lts 2.6.32.50-1 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
Monday, 26 November 2012, 04:47 GMT
Reason for closing: Deferred
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.
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
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.
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.
So AIF shouldn't be expected to deal with anything more than those two kernels.
https://github.com/Dieterbe/aif/commit/d9ae3f5fafdb5b890312d6c50e9ebb7072a82a64
can anyone test this works with the LTS kernel? kthx (using any testbuild built after right now)
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?