Re: 2.6.13, experimental and 2.6.14-rc ...
On Thu, Oct 06, 2005 at 09:21:11AM -0500, Manoj Srivastava wrote:
> On Wed, 5 Oct 2005 18:25:40 +0200, Sven Luther <sven.luther@wanadoo.fr> said:
>
> > On Wed, Oct 05, 2005 at 12:12:10PM -0400, Joey Hess wrote:
> >> d-i contains code to install and set up initrd-tools. The
> >> likelyhood of yaird or initramfs-tools working everywhere with no
> >> d-i changes is zero.
>
> > Ah, ...
>
> > Well, ideally i believe it would be the responsability of the kernel
> > package to set that up, but this is probably not going to happen
> > until we get ride of kernel-package or rewrite it to some extent.
>
> Way to go about setting up cooperative changes. Why am I not
> surprised?
Bah, sorry for the maybe too agressive wording, it wasn't meant so, and see my
other message about this.
> The only reason we have images that are marked "initrd" is
> the possibility that the kernel may not have the driver for the root
> file system compiled in, and would need an initial root file system
> somehow. If the various options -- creating initrd or initramfs --
> can be selected by each user on the target machine at install time,
> and would all work equally well, one can just try each of the init
> image creation tools in succession.
Well, see below. ...
> As far as I can see, there is no special config option
> required to distinguish between initrd and initramfs, so that is not
> a concern.
... you are (i believe) facing a common miscomprehension. There are two issues
at hand here :
1) the actual initrd format (either ext2 as used in 2.4 kernels in the
paste, cramfs or initramfs).
2) the program used to fill said initrd with actual content.
initrd-tool can do either ext2 or cramfs, but not really initramfs, altough i
believe you can override it with the right invocation to cpio used with the
right option of initrd-tools. it defaults to ext2 on 2.4 kernels and cramfs on
2.6 ones, i believe.
initramfs-tools and yaird default to initramfs format, but could probably
generate cramfs or ext2 just as well.
The content creation is different both in implementation and in philosophy,
initramfs-tools and initrd-tools share the same implementation based on a
shell script (mkinitrd), and the philosophy of trying to put as much as
possible in the initrd, in hopes to survive hardware modifications. Yaird on
the other hand uses some perl scripts (i believe), with some external config
files, and as the philosophy of putting only the strict minimum into the
initrd.
One could add a fourth initrd creation tool into the mix, namely
debian-installer, which with a few modifications, could easily enough be made
to pivot_root into the real system post hardware detection.
> I have not seen any differences in the naming conventions of
> the init images produced, so the naming of the destination of the
> init image is not an issue either.
Indeed.
> > Now, i installed yaird, and the only modification i had to do to my
> > /etc/kernel-img.conf was to set the mkinitrd-hook, or whatever this
> > one was called to point to yaird instead of mkinitrd, and it worked
> > out of the box, and since a solution using this would use an
> > automatically replacement solution, i think there should be no major
> > problem for yaird at least, not sure about initramfs-tools though.
>
> Jonas> This seems to be the same for initramfs-tools:
> Jonas> ramdisk = /usr/sbin/mkinitramfs
> Jonas> I have not tested how that works with LVM and mdadm.
>
> So, if there is an explicit value, use that, or else fall back
> through any of mkinitrd, mkinitramfs, or yaird, which happen to be
> installed.
What about delegating the initrd creation to the /etc/kernel/postinst.d
script, and have make-kpkg include such a versioned post-inst script into the
kernel image ?
Friendly,
Sven Luther
Reply to: