Re: ext3 root partition with kernel-image packages
On Tue, 7 May 2002, Michael Stone wrote:
> On Wed, May 08, 2002 at 12:23:34AM +0200, Tomas Pospisek's MailLists wrote:
> > On Mon, 6 May 2002, Michael Stone wrote:
> > > The specific mechanism isn't the hideous part. The hideous part is the
> > > suggestion that the rootfs type be somehow hardcoded into a new
> > > (debian-specific) mechanism in the initrd. That's not the current case,
> > > nor should it be. If that's not what that bug report was mean to
> > > suggest, and the only point of the bug report was to switch from change
> > > root to pivot_root, I don't understand how it's at all relevant to the
> > > ext3 problem.
> >
> > Hmmm ... have you checked my followup to the bugreport in question? IMHO
> > it's quite clear from it. But I may err.
> > *t
>
> Hmm...did you read what I said? I objected to hard coding the fs type
> into the initrd (specifically, into the scripts run by the initrd.) So
> how does your followup address that concern? (For reference, the
> applicable part of your patch follows)
>
> +# we want to have root mounted as ext3
> +# we mount it to /sysroot
> +mount -n -t ext3 /dev/hda5 /sysroot
> +# we move root away from below of us to /sysroot/initrd
> +pivot_root /sysroot /sysroot/initrd
Yup. It's a proof of concept. It's not integrated in initrd. Right now
it's for people who are using an image with ext2 in kernel and ext3
in module (problem situation) and want to have a solution. If you check
the various FAQs and HOWTOs you'll see that none of the relevant authors
got it right. There is an aparent lack of correct info on the web. That's
why I did this - I wanted to fill the gap so people find the relevant info
and can refer ot it. If you check further you'll see that I had tried to
provide the solution through /etc/mkinitrd/scripts (it works but it fails
to free the cramfs image). From that point on Herbert, if ever he uses
some parts of my solution has at least two possibilities to continue:
a) linuxrc checks if we're in the "problem situation" and calls the script
in question (or the script checks that itself)
b) you extend the presented solution into a generic one. First you check
if the situation meets your criteria (i.e. fs in kernel, but extended
fs on disk, extended fs driver available as module) and then you
proceed with the pivot root solution and mounting with the driver in
question.
Does that make sense?
*t
----------------------------------------------------------------------------
Tomas Pospisek
SourcePole - Linux & Open Source Solutions
http://sourcepole.ch
Elestastrasse 18, 7310 Bad Ragaz, Switzerland
Tel: +41 (81) 330 77 11
----------------------------------------------------------------------------
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: