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

Re: Reseed Help



ray@aarden.us wrote:
> I am trying to implement the preseed information contained on:
> http://users.telenet.be/mydotcom/howto/linux/autoinventory.htm
>
> In the section "debian installer preseed file' there is a command
> sequence:
>   TARGET="/root/inventory"
>   debconf-get-selections --installer > $TARGET/$TARGET/list_packages_installer
>   debconf-get-selections > $TARGET/list_packages

That section is derived from the official documentation here:

  http://www.debian.org/releases/stable/i386/apbs03.html.en

> 1)  From the description, it sounds like list_packages_installer can be
> used as a preseed file.  How do I tell the installer what the preseed
> file name is or is it the above as a default?

That is documented here:

  http://www.debian.org/releases/stable/i386/apbs01.html.en

And here:

  http://www.debian.org/releases/stable/i386/apbs02.html.en

There are several different options and possibilities.  I won't repeat
them here.  I think if you read through that documentation it will
answer many of your questions.  If not then keep asking questions.

> The page states:
> "list_packages_installer will contain the options relevant to the
> debian-installer : the base system configuration. list_packages will be
> more elaborate and contains also the choices you've made during package
> installation. This can be used to re-install packages with the same
> options as on your model. It is not recommended to use these files
> directly as preseed files, but you can use the data in it to populate a
> preseed file with sensible questions and answers."

Yes.

> 2) Does this mean that neither list_packages_installer and
> list_packages should not be used as preseed files?  If not, the
> directions say to use the info to populate a preseed file with
> "sensible questions and answers".

The biggest problem I see is that those files generated from
debconf-get-selections are machine generated output.  They are all
jammed together with no comments and no logical ordering.  Therefore
they are hard to maintain.  Therefore it is usually best to use them
as information to populate your own human generated files.  The files
you generate would ideally have comments and paragraphs organizing
them such as to make them maintainable.

> I was hoping the above would provide an installer preseed file, but
> it seems there is another file necessary?  I have not found what
> needs to go in a preseed file so I don't know how to use the data in
> the two files above to make a preseed.  Is there a way to
> automatically build a preseed file?

You can use that output to automatically build a preseed file.  But it
is hard to read and hard to modify later.  I started out that way but
then during the process of making changes I continually refined the
preseed file to produce exactly what I wanted.

There are a number of example preseed files posted around the net.
The problem is that preseed files by their very nature are site
specific information.  For example I set up hostnames, domain names,
disk partitions, locales, users, passwords, apt repositories, mirror
settings, installed packages, and generally make lots of installation
decisions.  Each and every one of those is a site specific choice.
Looking through my files if I were to remove or make those answers
neutral and generic there wouldn't be anything left to show!

> I am looking for a method to reproduce specific builds and define a
> basis for modifications.  I would like to use the computer to automate
> these tasks so I don't [continually] make mistakes that I must recover
> from, or at least simplify the recovery process.  I am looking for
> automation but it looks like I need understanding first.  I have been
> reading about preseeding for three weeks and thought I had an idea.  Now
> it looks like I am still missing something.

It can be a confusing thing trying to figure this out.  All you see
are an endless number of variables that can be set this way or that
way.  If you had a flowchart these decision points would all make
sense.  But initially you don't know the flow and so they are all just
a jumble of variables.  But don't despair.  It really isn't that bad.
Take each piece by itself and slowly work through things and it
suddenly all makes sense.

> How to I build a preseed file from an existing system?  This is a new,
> minimal system, just enough to form a basis to build a workstation step
> by recoverable step.

The way I did it for myself was to work through an installation once
and then use the output of debconf-get-selections to set up *just a
few* of the variables in a preseed file.  Then I installed again and
observed that those questions were answered automatically and were not
asked that time.  But other questions were asked.  I added those
variables to the preseed file and then repeated a test installation.
I again observed that those were not asked and moved through to the
next set of questions.

The trick for me was to do a little bit at a time.  Instead of trying
to create the entire preseed file all at once, complete, 100%, instead
I worked on just a small piece of it at a time.  By working through
the installation section by section the smaller pieces all made
sense.  I would frequently find one question which would give me
trouble.  I would search through the web and the preseed documentation
looking for that pariticular detail by itself.  Find it.  Fix it.
Then move on to another.  That process worked easily.

So my advice is not to try to do the entire set of possible variables
all at one time.  Instead start *somewhere* on one specific part of
the installation.  Create a file with just those variables.  Then try
it.  Then add to the file with the next section.

During the process of developing the preseed file expect to do test
installations repeatedly.  It is time invested in the future.  It will
take some time initially doing this again and again.  But it pays off
in the future when everything is automated.  Then you will simply make
a small change to the preseed file and the installation will be fully
automated.

On my hardware it takes about five minutes for a test install of a
small-ish system and about 8-10 minutes for a full desktop
installation with a lot of packages.  The speed is hardware dependent.
I usually use a real machine since that is fastest.  It is about twice
that time to install on a local kvm based virtual machine.  I have set
up local network mirrors and am using PXE boot installation over the
network.  It was much, much slower when doing all of the installation
from cdrom media.  People usually start out using cdroms or usb media
and then if they do it a lot they move to a PXE boot to avoid handling
any physical media.  But do it step by step.  Trying to do
*everything* all at once is too much for the brain to handle.

Okay, that was all good advice if I do say so myself.  But it doesn't
get you moving along one step at a time.  Starting off at *one*
variable I might pick the timezone.  It always needs to be answered,
is specific for every site, and is almost always the same for every
site.  I have this in my preseed file:

  # Select which update services to use; define the mirrors to be used.
  #d-i apt-setup/services-select multiselect security
  #d-i apt-setup/security_host string security.debian.org
  # Set to use the local mirrors.
  d-i apt-setup/services-select multiselect security
  d-i apt-setup/security_host string localwww.example.com/security.debian.org

  ### Mirror settings
  d-i mirror/country string manual
  d-i mirror/http/hostname string localwww.example.com
  d-i mirror/http/directory string /debian
  d-i mirror/http/proxy string

Here I am pointing to my own local mirror.  It would either point to
your local mirror or to the upstream archive.  The upstream archive is
probably the best default but I am installing repeatedly and want the
speed of local files and also do not want to hit the upstream
fileservers so hard.  For repeated installs at the least apt-cacher-ng
could be used to cache the packages for a much faster local mirror.
So maybe the above would be using port 3142 for a apt-cacher-ng cache:

  d-i mirror/http/hostname string localwww.example.com
  d-i apt-setup/security_host string http://localwww.example.com:3142/security.debian.org

  d-i mirror/country string manual
  d-i mirror/http/hostname string localwww.example.com:3142/ftp.us.debian.org
  d-i mirror/http/directory string /debian
  d-i mirror/http/proxy string

Or something pretty close to the above.  Put that in your preseed file
and then try an install again.  If your preseed file is being read
(see the first URL above that I referenced if it isn't) then it will
automatically answer that question the way you have specified.  You
don't even need to complete the installation.  Just go far enough to
observe that it didn't ask you that question.  Then stop and pick the
next useful thing to answer.

Now here is a confusing gotcha.  There are some questions that are
asked very early.  See the

  http://www.debian.org/releases/stable/i386/apbs01.html.en

documentation for those but basically these are the ones that I always
want to preseed but need to work harder to get them set.

  debian-installer/locale
  console-keymaps-at/keymap
  netcfg/choose_interface

I use a network installation so that I can set those early.  (But
setting up a network boot is a whole different not completely trivial
topic.  But very useful!)  You can set them on the boot parameters
command line.  You can modify the netinst image to include those in a
preseed file there.  But those get asked very early and often before
the network preseed file has been processed.  This often confuses
people who are trying to set them and not having any effect.

Hope this helps!

Bob

Attachment: signature.asc
Description: Digital signature


Reply to: