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

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



On Tue, Nov 15, 2005 at 10:24:41AM +0000, Colin Watson wrote:
> On Mon, Nov 14, 2005 at 04:15:36PM -0500, Joey Hess wrote:
> > Jonas Smedegaard wrote:
> > > I don't understand what "temporary hardcoding of root partition"
> > > actually means.
> > > 
> > > Yaird looks at /etc/fstab for the root partion.

Jonas, does it actually know how to look into /target/etc/fstab and not
/etc/fstab ? 

> > d-i currently does this before installing mkinitrd-tools:
> > 
> >                 # Temporarily hardcode the root partition.
> >                 rootpart_devfs=$(mount | grep "on /target " | cut -d' ' -f1)
> >                 rootpartfs=$(mount | grep "on /target " | cut -d' ' -f5)
> >                 rootpart=$(mapdevfs $rootpart_devfs)
> >                 if [ -f $mkinitrdconf ]; then
> >                         sed -e "s#^ROOT=.*#ROOT='$rootpart $rootpartfs'#" < $mkinitrdconf > $mkinitrdconf.new &&
> >                                 mv $mkinitrdconf.new $mkinitrdconf
> >                 else
> >                         echo "ROOT='$rootpart $rootpartfs'" >> $mkinitrdconf
> >                 fi
> > 
> > Appacently Colin has already checked that initramfs-tools doesn't
> > need such a hack,
> 
> Right; Jeff Bailey has been very clear to me that it can work it out
> based on what it's told by the bootloader.
> 
> Some lilo modifications may be needed at some point to pass the root
> filesystem as a device name rather than in lilo's hex-encoded
> major/minor form (which I'm told will eventually break due to kernel
> changes, and probably doesn't work so well for wacky block devices even
> now), either by changing lilo directly to do that or just by making
> lilo-installer override it by adding root= to the kernel command line in
> append=. initramfs-tools does handle lilo's current syntax for the
> moment, though.

What about the wide variety of non-x86 boot loaders ? What about the prep
case, where you cannot set default args appart from the kernel command line ? 

I still think that having the ramdisk content hardcode the root path
(overridable on the command line) is a more secure way of doing this.

Friendly,

Sven Luther



Reply to: