Package: rootstrap
Version: 0.3.21-1
Severity: minor
I'm afraid this bug report contains multiple minor bug reports and
enhancement requests. If you'd like me to split it up into a number of
minor and wishlist bug reports, feel free to write back and I'll take
care of it.
I have been trying to wrap my head around rootstrap from time to time
but always failing. There's a bunch of things one needs to understand
about UML and about how Debian is installed in order to succeed, and I
was having trouble with the UML stuff in particular. I'm just trying
to get pbuilder-uml to work here, and didn't want to spend a lot of
time on understanding rootstrap. Well, now I delved into it anyway.
Here are my impressions -- hopefully other newcomers will find it
easier to get started if even some of these problems I stumbled into
could be straightened out or at least made a little bit less puzzling.
Again, sorry if this is not formatted in a way which makes sense to
you. I'd be tempted to split this into a dozen tiny bug reports, but
then some developers would be upset about that approach, too. Please
let me know how you prefer this feedback and I'll try to massage it
into a format which is convenient for you.
Attached is a documentation patch which attempts to fix some of these
issues. I have marked those sub-bugs with "Tags: patch".
/* era */
Subject: Requires /etc/rootstrap/rootstrap.conf, even if empty [#1]
I experimentally removed /etc/rootstrap/rootstrap.conf. This results
in the following error:
bash$ rootstrap root_fs
Traceback (most recent call last):
File "/usr/bin/rootstrap", line 34, in ?
config.readfp(open('/etc/rootstrap/rootstrap.conf'))
IOError: [Errno 2] No such file or directory: '/etc/rootstrap/rootstrap.conf'
Does it really make sense to require this file to exist? I wanted to
experiment with a minimal rootstrap.conf and I didn't want to be root,
so I figured I'd just rename the site-wide config file and let my
../rootstrap.conf contain my entire experimental config. Alas, this is
not possible, although the workaround is simple; create an empty
/etc/rootstrap/rootstrap.conf.
An alternative to making this file completely optional would be to
ship a really minimal rootstrap.conf which only specifies the absolute
minimum required options. This would make it much easier to create an
experimental per-user config.
Sub-cases:
[global] section required [#1.1]
[global]::initialsize required [#1.2]
[global]::modules required [#1.3]
No warning if PATH is not set [#1.4]
fstype directive required [#1.5]
Subject: [global] section required [#1.1]
If the file /etc/rootstrap/rootstrap.conf exists but is empty, I get
an error about not having a [global] section. Maybe this requirement
should be relaxed, too -- require the [global] section heading only if
the file is non-empty, perhaps. Otherwise, assume some reasonable
defaults (and document them ...)
Subject: [global]::initialsize required [#1.2]
If I have an empty [global] section, I get an error about not having
any initialsize directive:
bash$ rootstrap root_fs
Traceback (most recent call last):
File "/usr/bin/rootstrap", line 50, in ?
imagesize = config.getint('global', 'initialsize')
File "/usr/lib/python2.3/ConfigParser.py", line 315, in getint
return self._get(section, int, option)
File "/usr/lib/python2.3/ConfigParser.py", line 312, in _get
return conv(self.get(section, option))
File "/usr/lib/python2.3/ConfigParser.py", line 513, in get
raise NoOptionError(option, section)
ConfigParser.NoOptionError: No option 'initialsize' in section: 'global'
Perhaps some default could be assumed (say, 2048, which is allegedly
large enough for even the largest pbuilder-uml package builds).
Subject: [global]::modules required [#1.3]
If I have an empty [global] section, I get an error about not having
any modules directive, way into the creation of a file system.
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (hostfs filesystem) readonly.
Mounted devfs on /dev
builder running...
Traceback (most recent call last):
File "/usr/lib/rootstrap/builder", line 60, in ?
for module in config.get('global', 'modules').split():
File "/usr/lib/python2.3/ConfigParser.py", line 513, in get
raise NoOptionError(option, section)
ConfigParser.NoOptionError: No option 'modules' in section: 'global'
Kernel panic: Attempted to kill init!
Adding an empty modules= fixes this. Perhaps this should be assumed to
be the default if no modules are specified.
Subject: No warning if PATH is not set [#1.4]
The documentation does not really document PATH, but mentions that it
is mandatory. However, if it is omitted, no warning is issued until
very late into the debian module, after you've spent on the order of
fifteen minutes downloading all packages (lots longer if you don't
have a fast local mirror!)
I: Extracting textutils...
I: Extracting util-linux...
I: Extracting whiptail...
I: Extracting mbr...
I: Installing core packages...
dpkg: dpkg - error: PATH is not set.
W: Failure trying to run: chroot /tmp/target dpkg --force-depends --install
/var/cache/apt/archives/base-files_3.0.2_i386.deb
/var/cache/apt/archives/base-passwd_3.4.1_i386.deb
umount: /tmp/target/dev/pts: not found
umount: /tmp/target/dev/shm: not found
umount: /tmp/target/proc/bus/usb: not found
Traceback (most recent call last):
File "/usr/lib/rootstrap/builder", line 66, in ?
dispatch(module, modulevars)
File "/usr/lib/rootstrap/builder", line 44, in dispatch
raise "rootstrap: Module '%s' failed, status: %d" % (module,status)
rootstrap: Module 'debian' failed, status: 1
Kernel panic: Attempted to kill init!
<6>SysRq : Show Regs
Up to that point, things seem to work OK without a PATH, apparently
because it is inherited from the shell where I invoked rootstrap.
(Indeed, unsetting it in the shell before running rootstrap results in
an error message immediately. It could be slightly clearer, though.)
bash$ unset PATH
bash$ /usr/bin/rootstrap root_fs
Traceback (most recent call last):
File "/usr/bin/rootstrap", line 47, in ?
os.environ['PATH'] += ':/sbin:/usr/sbin'
File "/usr/lib/python2.3/UserDict.py", line 19, in __getitem__
def __getitem__(self, key): return self.data[key]
KeyError: 'PATH'
Perhaps a default PATH should be supplied if one is not set in the
configuration file, or the invoking program's PATH used. Either way,
some explicit documentation would be welcome.
Subject: fstype directive required [#1.5]
If fstype is unset, there is no warning until you get to the mkfs
module:
Using rootstrap module mkfs from:
/usr/lib/rootstrap/modules/mkfs
/usr/lib/rootstrap/modules/mkfs: line 4: [: too many arguments
/usr/lib/rootstrap/modules/mkfs: line 8: mkfs.: command not found
Traceback (most recent call last):
File "/usr/lib/rootstrap/builder", line 66, in ?
dispatch(module, modulevars)
File "/usr/lib/rootstrap/builder", line 44, in dispatch
raise "rootstrap: Module '%s' failed, status: %d" % (module,status)
rootstrap: Module 'mkfs' failed, status: 127
Kernel panic: Attempted to kill init!
Inspection of /usr/lib/rootstrap/modules/mkfs reveals that it requires
fstype to be present. This should probably default to ext2 if unset
instead of producing this rather cryptic error message. Alternatively,
rootstrap should check for this mandatory parameter, and produce a
human-readable error message, ideally at startup.
Subject: Documentation says RFC822 format but reality is different [#2]
Tags: patch
The manual page specifies that the rootstrap.conf file should be in
RFC822 format with keyword, colon, value. But the rootstrap.conf which
ships within the package does not obey this format; instead, it's
keyword equals value.
Experimentally, I have deduced that both formats are in fact valid.
Nevertheless, this discrepancy is somewhat confusing. At least it
would be helpful to update the documentation to mention the existence
of an alternative format; perhaps the RFC822 alternative should even
be demoted to undocumented, since the de facto standard format appears
to be good enough for everyone. (This is what I have done in the patch.)
Subject: Unclear if host IP etc are declarative or descriptive [#3]
Severity: wishlist
Tags: patch
Figuring out if an interface or IP address directive is for the host
running UML or for the UML virtual machine is a bit of a trial and
error exercise. These things are fairly well explained in the UML user
documentation, though. Nevertheless, some clarifications would be
welcome. (See the attached patch for some suggestions. I hope I have
understood these things correctly.)
Subject: Undocumented [network] directives [#4]
Tags: patch
hostname, nameserver, domain, slirp are in the configuration file but
are not documented.
The available alternatives for the transport directive are not listed.
Apparently, they are tuntap, slirp, and daemon.
The control and data directives for the daemon transport are used in
the config file (albeit commented out) but are not documented. (I'm
not sure if the data directive is actually used for anything.)
Incidentally, I commented out the host directive, and everything still
worked, although the documentation says it's a mandatory parameter.
I guess I was lucky (and/or the default used by my transport just
happened to make sense).
(The attached patch attempts to fix some, but not all of these issues.)
Subject: Undocumented modules [#5]
mkfs, mount, uml, umount are in the configuration file but are not
documented anywhere.
Additionally, base-config, docpurge, localepurge, mkisofs, tasksel are
shipped in /usr/lib/rootstrap/modules but are not documented anywhere.
As a maintainability enhancement, what if the individual modules could
contain their own little SGML snippets which would be pulled into the
main document at build time?
(The patch I made contains a few additions in the SEE ALSO section
which perhaps rectify this.)
Subject: network and debian robustness checks [#6]
It would have saved me a lot of aggravation if the following simple
checks had been in place:
network: check that the host_if interface exists on the host
debian: check that you can ping the host from within the UML VM
debian: check that you can ping the mirror host from within the UML VM
The final error in particular was pretty pesky to figure out. You just
get a rather bland message from wget (from way inside debootstrap)
about not being able to download the first Release file when
networking is not correctly set up.
--- rootstrap-0.3.21/rootstrap.sgml 2003-09-18 05:03:03.000000000 +0300
+++ new/rootstrap.sgml 2005-02-08 17:12:31.000000000 +0200
@@ -124,8 +124,9 @@
<para>
The configuration file consists of sections, starting with a
- "[section]" header, followed by "option: value" entries, with
- continuations and such in the style of RFC 822.
+ "[section]" header, followed by "option=value" entries.
+ Long values are allowed to span multiple lines if
+ each continued line is indented with whitespace.
</para>
<para>
@@ -162,8 +163,23 @@
<term>fstype</term>
<listitem>
<para>
- The type of filesystem to create (ext2, ext3, reiserfs,
- etc.)
+ The type of filesystem to create
+ (ext2, ext3, reiserfs, etc.)
+ </para>
+ <para>
+ This parameter is mandatory.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>PATH</term>
+ <listitem>
+ <para>
+ The PATH environment variable to pass to modules.
+ </para>
+ <para>
+ This parameter is mandatory.
</para>
</listitem>
</varlistentry>
@@ -178,6 +194,9 @@
It will be created sparsely, so additional space is not
entirely allocated until it is used.
</para>
+ <para>
+ This parameter is mandatory.
+ </para>
</listitem>
</varlistentry>
@@ -190,6 +209,9 @@
possible, to adjust the amount of free space to
approximately this amount.
</para>
+ <para>
+ This parameter is optional.
+ </para>
</listitem>
</varlistentry>
@@ -203,6 +225,9 @@
variables based on the options set in the corresponding
section of the configuration file.
</para>
+ <para>
+ This parameter is mandatory.
+ </para>
</listitem>
</varlistentry>
@@ -226,8 +251,10 @@
<term>interface</term>
<listitem>
<para>
- The name of the UML network interface to configure,
- typically "eth0". This parameter is mandatory.
+ The name of the network interface to configure
+ inside the UML virtual machine,
+ typically "eth0".
+ This parameter is mandatory.
</para>
</listitem>
</varlistentry>
@@ -236,9 +263,10 @@
<term>host</term>
<listitem>
<para>
- The IP address of the host side of the interface (the
- host on which rootstrap is run). This parameter is
- mandatory.
+ The IP address of the host side of the interface
+ (the host on which rootstrap is run),
+ as visible to the UML virtual machine.
+ This parameter is mandatory.
</para>
</listitem>
</varlistentry>
@@ -258,7 +286,9 @@
<listitem>
<para>
The type of virtual networking interface to be used.
- Typically "tuntap". This parameter is mandatory.
+ Typically "tuntap".
+ Other available transports are "slirp" and "daemon".
+ This parameter is mandatory.
</para>
</listitem>
</varlistentry>
@@ -274,6 +304,16 @@
</varlistentry>
<varlistentry>
+ <term>hostname</term>
+ <listitem>
+ <para>
+ The host name to use for the created UML virtual machine.
+ This parameter is optional.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
<term>gateway</term>
<listitem>
<para>
@@ -283,6 +323,17 @@
</listitem>
</varlistentry>
+ <varlistentry>
+ <term>nameserver</term>
+ <listitem>
+ <para>
+ The DNS server to use for domain name resolution inside
+ the UML virtual machine. This parameter is optional, but
+ useful if you do not have a name server running on the host.
+ </para>
+ </listitem>
+ </varlistentry>
+
</variablelist>
</refsect2>
@@ -446,6 +497,28 @@
</refsect1>
<refsect1>
+ <title>SEE ALSO</title>
+
+ <para>
+ <citerefentry>
+ <refentrytitle>debootstrap</refentrytitle><manvolnum>8</manvolnum>
+ </citerefentry>,
+ <citerefentry>
+ <refentrytitle>linux</refentrytitle><manvolnum>1</manvolnum>
+ </citerefentry>;
+ locally installed User-Mode Linux documentation or
+ <ulink url="http://user-mode-linux.sourceforge.net/";>
+ http://user-mode-linux.sourceforge.net/</ulink>
+
+ <para>
+ Additional rootstrap modules can be installed in several locations
+ (see FILES above)
+ and may contain additional documentation.
+ </para>
+
+ </refsect1>
+
+ <refsect1>
<title>AUTHOR</title>
<para>Rootstrap was written by &dhusername; &dhemail;</para>
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.27-1-686-smp
Locale: LANG=C, LC_CTYPE=C
Versions of packages rootstrap depends on:
ii debootstrap 0.2.45 Bootstrap a basic Debian system
ii dpkg 1.10.23 Package maintenance system for Deb
ii python 2.3.4-4 An interactive high-level object-o
ii user-mode-linux 2.4.26-3um-1 User-mode Linux (kernel)
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
