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

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



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 14 Nov 2005 14:54:10 -0500
Joey Hess <joeyh@debian.org> 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?

Initramfs-tools May produce too big images for some arches. This needs
to be verified and documented (Sven seems most knowledgable about this).

Yaird needs sysfs on running system so cannot be used from a 2.4
system. This may not be an issue to d-i.

Yaird does not support custom hooks. This is probably not a problem for
d-i.

None of the new tools support all of the more exotic features, it
seems. This also probably is irrelevant for d-i.


> 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.

I don't know how hard it will be to make yaird depend on perl-base
rather than perl.

Lightening the dependencies of initramfs-tools has been claimed to
be easy, I believe. If the possible problem of too big images can be
solved as well, it seems like we have a winner.

I would certainly prefer d-i to provide both tools, but understand the
argument of keeping d-i simple.


> > Currently we modify the configuration of initrd-tools:
> > - temporary hardcoding of root partition
> > - default resume partition
> > Would we need to do the same for the new initrd generators?
> 
> I wish my memory was better; I briefly removed the roor partition
> hardcoding a few weeks ago, watched initrd-tools break some way, and
> put it back, but I forget how they broke. Anyway, if the new tools
> don't break right away, whatever the issue is that I'm forgetting
> doesn't apply and root partition hardcoding isn't needed.

I don't understand what "temporary hardcoding of root partition"
actually means.

Yaird looks at /etc/fstab for the root partion.


> 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.

initramfs-tools supports this, I believe. Main problem there seems to
be to have it available for all arches.


 - Jonas

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDePScn7DbMsAkQLgRAuvrAJ91PEMX6ICgu9dNtabNWFfUMsPBsgCfUlED
G3Eyb+hNC5h5rwRF6/aPyKU=
=qavN
-----END PGP SIGNATURE-----



Reply to: