[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [D-I] Supporting 2.6.14 kernels in base-installer



On Mon, Nov 14, 2005 at 02:54:10PM -0500, Joey Hess wrote:
> Frans Pop wrote:
> > Both initrd generators have limitations in what they currently support. We 
> > may have to either always install both, or include logic that 
> > pre-installs one or the other depending on the situation.
> 
> Based on http://wiki.debian.org/InitrdReplacementOptions I didn't see
> any items that were only supported by one or the other that seemed
> immediatly relevant to d-i. Did I miss some?
> 
> IMHO, and based on similar experience with lilo/grub, making d-i fully
> support two alternate programs for doing something has strong negative
> effects on complexity, maintainability, and usability. It fragements
> developer time and makes us have to deal with a much more complex
> system. So I'd really like to see d-i only support one of the two tools by
> default, and if neither is able to support all the things supported by
> initrd-tools that would be a significant reversion that should be fixed.

Ok, but who will chose which will be the default one ? The d-i team, or the
kernel team ? And what about the cases where the choice happens to be
dependent on the architecture used ? 

> This is orthagonal to the kernel packaging supporting use of either
> tool outside d-i, which looks to be at the same time both generally
> useful and a nice way to have postponed making a decision.

Mmm, i don't get you here ? you mean that d-i will support one of the tool,
and that the user can then remake the choice at kernel install time ?

> > The dependency on sysfs and udev will make it practically impossible to 
> > install a 2.6 kernel when running the installer with 2.4. We should 
> > probably check for this in base-installer and make sure the option is not 
> > presented to the user.
> 
> BTW, is there an a upgrade path for users of sarge with the 2.4 kernel
> to upgrade directly to etch with 2.6? It seems to fail due to that
> requirement.

This will fail because of udev anyway, so this is not worse, but i suppose
initramfs-tools in most mode is the way to go for that.

Friendly,

Sven Luther



Reply to: