Re: [D-I] Supporting 2.6.14 kernels in base-installer
On Sat, Nov 12, 2005 at 11:42:26PM +0100, Frans Pop wrote:
> I've taken a first look at what is involved in supporting installation of
> 2.6.14 kernels in Debian Installer _for the installed system_.
>
> Note: This is a separate issue from running the installer with a 2.6.14
> kernel.
>
> During kernel installation sysfs needs to be mounted on /target (at least
> for yaird).
> This is currently breaking installations for unstable (and will break
> network based base installations for beta1 and daily builds when 2.6.14
> migrates to testing).
> /target/proc is currently mounted by apt-install, so this probably needs
> to be added there (only for 2.6 kernels).
You mean mounting /sys inside the chroot ? Jonas/Erik, can you comment on
this, will it work ?
> The following packages are currently pulled in as dependencies by the
> 2.6.14 kernel:
> - yaird
> - perl (3.3 MB)
> - perl-modules (2.2 MB)
> - libhtml-template-perl
> - libparse-recdescent-perl
> These requirements look quite heavy to me and may be a problem for the
> netinst.
That is less than 6MB of stuff, hardly "heavy". A single kernel flavour is
double that for example.
Also, we have perl-base in base, or used to at least, would yaird not be able
to depend on perl-base only ? Or did we do away perl-base since then ?
> If we would install initramfs-tools, we would need:
> - busybox
> - klibc-utils
> - mklibs-copy
> - udev
> This looks a lot lighter, but the dependency on udev probably means some
> manipulation of /target/dev will be required. Using udev in d-i itself
> may make that easier.
We need some udev-basede solution in the ramdisk for 2.6.14 kernels anyway.
> 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.
Both should be installed into the netinst, and we should have a
ramdisk-tool.udeb or a part of base-installer, which would default to one of
them we chose as default at high priority, or ask the user at medium priority,
a bit like what happens for grub vs lilo.
Given the knowledge we have in d-i, we could even make the default dependent
on the root choices made in the partman phase, and maybe even make it
dynamically. We could implement jonas's probing proposal even though k-p
doesn't use it, but ramdisk-tool.udeb could make use of it.
> 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?
Probably not, it depends on the tool even, i will let Maximilian and
Jonas/Erik comment on this.
I am not sure that keeping this and kernel-installer as part of base-config
will be the most configurable and modular way of handling this step though.
> 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
Running the installer with 2.4 is something we dearly hope to get away from
for etch, but this is in any case not a problem, since the ramdisk-tool all
support the --supported-(host|target)-version, which means you can probe them
for the supported kernels (both host and target) and automatically wed out the
kernels proposed for installation.
> probably check for this in base-installer and make sure the option is not
> presented to the user.
Indeed.
Friendly,
Sven Luther
Reply to: