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

Re: Chrooted Debian install from base image (was Re: Instalation question: Toshiba TECRA 8000)



on Sun, Apr 07, 2002, Carel Fellinger (cfelling@iae.nl) wrote:
> On Sat, Apr 06, 2002 at 08:52:50PM -0800, Karsten M. Self wrote:
> > This is a draft of a HOWTO I'm working on for doing a chrooted Debian 
> 
> thanks for taking your time to add this usefull document.

Oh, I've only been meaning to for a couple of years now....

Thanks for detailed comments.



> > install.  It's a method I've found useful over the years.
> 
> Yep very handy.  I started using it when I needed woody goodies and
> didn't want to take the risk and do a full upgrade.
> 
> > The one component I _don't_ address here is module configuration for
> > support of networking, sound, etc.  Not sure how best to deal with this.
> 
> Not sure what you're at here, but if it's just module configuration
> why not hint at modconf?

Hmm...'coz I've never used it?

The bits of module configuration I'd like to get at:

  - Identifying what modules you need.  Typically:  controllers,
    filesystems, networking, etc.

  - Making sure the modules are included with your kernel.  My
    understanding is that most Debian kernel images are fairly kitchen
    sink, so the problem is minimized here.  Rolling your own is a
    different story.

  - Getting the modules loaded at boot or when needed for a device /
    function.  This part, frankly, I don't understand particularly well,
    though I manage to limp along by throwing lines into /etc/modules.



> ...
> > As an alternative, it's possible to bypass the installation CD using
> > one of several other methods of getting a base image onto the
> > system.
> 
> It would be nice if you could mention some of the other aproaches,
> like netinstall and give a link to the iso.

This assumes I'm providing general advice.  I'm not.  I'm talking about
chroot installs, and refer to the primary documentation for other
options.  TMTOWTDI



> Oh, and I myself are very carefull in my examples to use a telling
> prompt.  In your code below you stick to `$ ' as prompt even when one
> clearly has to be root for the command to work.  I would suggest to
> use `# ' there and use `###' to begin a comment.  Or maybe even better
> use `TRB: ' as prompt for the commands used while running TRB, and
> switch to `debian: ' once debian is running (chrooted).

I use '$ ' as my root prompt ;-).  IIRC, both TRB and LNX-BBC use '$ '
for their prompt.  '# ' reads too much like a comment to my mind, '$ '
indicates a shell prompt.

I use control directives to display the userid in reverse video when
root, which I find more distinctive than a prompt mod:

    PS1=\[\033]0;\u@\h:\w\007\][\[\033[7m\]\u\[\033[0m\]@\h:\W]$


I probably should make clear that all commands are being run as root.

Your comment on distinguishing boot v/ chroot systems is a good one.


> > 	Performing A chroot Debian Install From A Booted System
> > 	-------------------------------------------------------
> > 
> > The goal is to end up with an upacked tarball of the base system on a
> 
> I was under the impression that woody didn't have such a tarball any more,
> and now that woody is due to be released next week:) it might be wise to
> make this a little bit more future proof.  E.g. debootstrap seems very
> promissing it's merely a sh script so I guess it could work with TRB.
> I merely tried it from a chrooted woody and from its father potato:
> 
>    # apt-get debootstrap
>    # debootstrap --verbose --unpack-tarball /tmp/basedebs.tar woody woody2

I've used dbootstrap and debootstrap off the LNX-BBC with mixed results.
The chroot method seems to work more consistently.


> ...
> > keep on rolling.  Thus it's a "zero downtime" GNU/Linux install.  Also a
> 
> nah, a near zero downtime, you have to reboot once you know:)

/me researches two-kernel-monty procedures again....


> ...
> > Getting Started
> > ---------------
> ...
> > My preference is for separate partitions, in order of preference for
> > creation: /, swap, /boot, /usr, /home, /tmp, /var, and /usr/local.  If
> 
> funny, I would think /boot is far less important to have separate then
> /usr.  But then, I've either small disks or modern motherboards, so no
> 1024 cylinder limit here.  Or do you have other arguments to separate
> / and /boot?

For large disks, /boot can be necessary.  It's also a small partition,
so the space-contstraint argument against divving up a /boot partition
don't wash.  I find it useful to keep things like kernels and boot
blocks mounted ro unless absolutely necessary.


> ...
> > Mount two of your partitions to /mnt/debinst and /mnt/utility.  While
> > you're at it, make sure a /mnt/floppy directory exists. 
> 
> Is this in accordance with FSH (or what ever the beast is named).  I
> remember some discussions a while ago, but missed the final verdict.

This is in accordance with the procedures I describe.  /mnt/floppy is
used on the  boot system, not the chroot image.  Though I prefer /mnt
for floppy, cdrom, and other removeable media mount points.


<...>

> > Configuring The Base System
> > ------------------------------
> > 
> > You've now got a real Debian system, though rather lean, on disk.
> > Chroot into it:
> > 
> >     $ chroot . bin/bash
> 
> One thing I always wondered how to deal with was with preventing
> daemons to start / stop in the chrooted woody, especially as this
> automatically happens when you install a new (version) `daemon'
> packet.  Initially debootstrap uses a trick to prevent daemons from
> really being started.  Might be worth explaining the trick and how it
> can be used later on.

TRB doesn't run daemons ;-)

LNX-BBC runs a minimal set (sshd, if activated).


> ...
> >    - /etc/hostname -- your system's host name -- 2 - 63 characters.
> 
> Maybe worth mentioning that it shouldn't contain the domain part?

Fair 'nuf.


> ...
> > Reboot to confirm your settings.  If your system doesn't come up, you've
> 
> If you go the debootstrap path, you need to install a kernel package
> first.

Um...I thought I did that already...or did I?  Yes, in the paragraph
above, though the process is elided.  Or am I missing something.


> ...
> >       # In theory, the following works, though I had to kick it a few
> >       # times to make it go right:
> > 
> >       $ apt-get dist-upgrade		# This should work.
> >       $ apt-get dselect-upgrade		# This is what I ended up using.
> > 
> >     FIXME:  ...can someone straighten me out on this?
> 
> I'm no expert on the subject, but I thought dselect-upgrade is only usefull
> when you used dselect to select packages and want apt-get to install them.

I'm just commenting on what worked.  It may be that I switched to
'woody' _before_ doing a full install.  This resulted, e.g.:  in Galeon
not installing from testing as it is currently removed, and in unstable,
galeon depends on a version of mozilla-browser not yet released.

A better procedure might be to first install a potato system, then
upgrade to woody, but this seems time consuming.

Point being:

   $ dpkg --get-selections < file
   $ apt-get update
   $ apt-get dist-upgrade

...didn't work as expected.  Still looking for input.

Peace.

-- 
Karsten M. Self <kmself@ix.netcom.com>           http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
   zIWETHEY: Provocative, super smart, and oh yeah, just a little sexy.
     http://z.iwethey.org/forums/

Attachment: pgpYDvhUWbdFe.pgp
Description: PGP signature


Reply to: