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

initrd/initramfs: we discussed enough, let's take some action now :)



Hi all,

Ok, now that linux-2.6.13-1 has been uploaded to experimental, and despite the
abysmal situation of the experimental autobuilders and ways to grab logs,
it is time to finalize the story about the initrd stuff.

My position on this is as follow, and i have hinted it in previous posts,
let's see where it makes sense and where it is flakey.

I propose at first that we create a virtual package : linux-initrd, which
would be provided by the initrd creation tools (currently initrd-tools, yaird
and initramfs-tools).

Then we can modify the 2.6.13 control.images.in to show :

  Depends: yaird | initramfs-tools | kernel-initrd , module-init-tools (>= 0.9.13)
  Conflicts: hotplug (<< 0.0.20040105-1), initrd-tools

Not sure about the initrd-tools conflict, since it will stop initrd-tools and
2.6.13 kernels to be installed simultaneously, so it should be dropped maybe.

The third step is to modify each of the initrd generating tools to reply to
the following two arguments :

  --supported-target-version <version>
  --supported-host-version <version>

Which would return true or false when queried about the kernel cases it
supports. The -host-version is the kernel version being run on when creating
the initrd, and the -target-version is the version of the to-be installed
kernel.

Currently we have :

			target			host
  initrd-tools : 	< 2.6.13		?
  initramfs-tools :	>= 2.6.12		?
  yaird	:		>= 2.6.8		>= 2.6.?

The last step of the plan is to have kernel-package postinst modified to
support the following :

  mkimage: is now a list of initrd tools.

The make-kpkg command, at image installation time, goes through the list of
mkimage programs in order, and tests : 

  1) if the tool is present.
  2) if it is able to run with the currently running kernel (with a
  --supported-host-version call)
  3) if it is able to install the target kernel (with a
  --supported-target-version call).

Once the list is weeded of the tools which don't comply to the above, we
either run the one left with the more precedence, as selected by the user, or
inform the user that there is trouble with the list he provided, and please
fix it.

This is backward compatible with the current format (mkimage accepting a single
value), and we add some trouble checking to know things don't happen badly.

What do you think about it ? Comments ? things i missed ? etc ...

Friendly,

Sven Luther






Reply to: