Re: initrd-tools and booting root on lvm with new kernel
On Thu, Oct 06, 2005 at 06:43:54PM +0200, Maximilian Attems wrote:
> On Thu, Oct 06, 2005 at 05:57:08PM +0200, Sven Luther wrote:
> > On Thu, Oct 06, 2005 at 09:29:06AM -0500, Manoj Srivastava wrote:
> > > On Mon, 3 Oct 2005 13:03:45 +0200, Maximilian Attems
> > > <maks@sternwelten.at> said:
> > >
> > > > naa initramfs-tools are in the archive an working for all arch but
> > > > sparc (klibc ftbfs there with gcc3.4/4.0).
> > >
> > > > the kernel-package does not yet use the initramfs-tools. you need to
> > > > invoke update-initramfs like this: sudo update-initramfs -c -k
> > > > 2.6.13-1-686
> > >
> > > Err. putting
> > > ramdisk = /usr/sbin/mkinitramfs
> > > in /etc/kernel-img.conf does seem to work. Or are you talking about
> > > using mkinitramfs by default? mkinitramfs fails if the kernel version
> > > is not at least 2.6.12, so it can't be used unilaterally.
> >
> > Would a solution to this not to have the kernel provide a
> > /etc/kernel/postinst.d/<version>/kernel.sh script, which would in turn call
> > mkinitramfs or mkyaird (or whatever it is called), or alternatively have
> ..
> the patch that uses mkinitramfs-tools conditionaly in ubuntu is very
> small and easy to integrate.
Do you have a link to it ? And does it support using yaird as alternative ? Or
running initrd 2.4 or pre-2.6.12 kernels ?
> > > I guess we could add a version specific check into the
> > > postinst to default to using yaird or mkinitramfs , if installed, in
> > > preference to mkinitrd, though I am usually hesitant to add in
> > > version dependencies into kernel-package in general, I could be
> > > persuaded that an exception is justified in this case.
> >
> > Would a solution as proposed above be more to your liking :) ?
>
> naa, working with kernel-package is very fine.
The above proposal works with kernel-package just fine.
> my proposal is just to localize changes, so that we clearly know,
> what broke?
>
> releasing a new upstream version and changing the early boot stuff
> in the same time needs to be avoided.
I don't follow you on this.
Friendly,
Sven Luther
Reply to: