l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
August 5: Social gathering
Next Installfest:
Latest News:
Jul. 4: July, August and September: Security, Photography and Programming for Kids
Page last updated:
2002 Jun 24 14:58

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] debian virtual install
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] debian virtual install

I serve NFS root to about 80 netbooting NCs running Linux. They also use
Debian for their exported roots. What you mention as a problem for getting
a base install to the machines is something I encountered before.

1) Use of tar has been less than effective when copying over all of the
base files to a tarballo and then later extrating them into a new tree. It
has (historically) always been a problem for me (bugs in tar and dealing
with odd dev files mostly.) (Yes, I used many diff flags to make sure
ownership, privs, and dev special files get copied, but there were always
problematic files.)

2) Use of multiple partitions and then re-export of these partitions
(/usr, /usr/local /var) over a new "/" to "conserve disk space" is a bad
idea as registered compenents are at risk when one dpkg update updates the
"/etc/ file (if any) and "/" files (if any=) in one tree, but not in
others. You end up with a two db sharing one space and each with write
access to the other.

3) Exporting your own root is not the most secure idea - even with read
only access.

The method I used was as follows:
Install a base debian system onto a machine with just what is needed
(200-300 Mb was more than enough)

On that same machine, make sure I have a kernel with loopback support:
# dd if=/dev/zero of=/tmp/debian.base.image.ext2
# losetup /dev/loop0 /tmp/debian.base.image.ext2
# mkfs -t ext2 /dev/loop0
# mkdir /tmp/base
# mount -t ext2 /dev/loop0 /tmp/base
# cd /
# for i in * ; do ( if [ "$i" != "tmp" ] && [ "$i" != "proc" ; then \
( cp -aR "$i" /tmp/base ) fi ) ; done
# mkdir /tmp/base/tmp /tmp/base/proc

(now look through places like /var/lock (etc...) to get rid of that stuff
(locks etc) for things that are not running in that copied space (many
programs will chekc to see if the lock listed for them is not valid due to
the PID not existing and then gracefuly remove the lock file and move on,
but I like to be safe.) An alternative is to boot from another disk, and
have another running OS do the above after mounting the local HD in a new
mountpoint (and making the dirs/paths above reflect the new local HD
mount) so there is nothing running on the root of the system being

(You will also want to modify your /etc/fstab in the archived root)

(I have found "cp -aR" to never fail to copy the files as I expect. the
"R" instead of "r" is to make sure device special files are copied as
device special files. ownership/privs work.)

# sync
# umount /tmp/base

Now you can copy the image (/tmp/debian.base.image.ext2) over to the
server, and mount the image and then "cp -aR" all of its contents to the
new root.

Then, you can cd to the new root and chroot and then run dselect or do
the dpkg thing. (There are some packages that will complain and not
install happily in a chrooted env. You may want to remove lilo from this
tree, and note that tools that use /proc wont like this env.)

As an alternative, you can export that new tree with NFS as "rw" to a
single IP address (on a private network - preferrably) and then run your
package installer from the NFS root machine to configure everything.

In my setup, I have the NFS root exported with "ro" access to all of the
machines. This takes a bit of work, since many linux distro apps assume
the user has write acces somewhere. Though it is possible to have it all
be ro, I tool the easy way out and created a custom boot script to start
before any others that creates a ramdisk and whatnot for the user to write
stuff (like tmp files and process locks).

The above is not the *only* way to do this, it is just *one* way that I
have found works for me. If/when tar works with all of the files and
everything is perfect, then tar is much faster and more efficient. I have
been burned too many times with tar for creating new root trees to start
that path and choose to use the above since it has never failed me yet
and is all done in Linux with "standard" tools.


Version: 3.12
GCS/CM$/IT$/LS$/S/O$ !d--(++) !s !a+++(-----) C++$(++++) U++++$(+$) P+$>+++ 
L+++$(++) E W+++$(+) N+ o K w+$>++>+++ O-@ M+$ V-$>- !PS !PE Y+ !PGP
t@-(++) 5+@ X@ R- tv- b++ DI+++ D+ G--@ e+>++>++++ h(++)>+ r*>? z?
decode: http://www.ebb.org/ungeek/ about: http://www.geekcode.com/geek.html

On Mon, 24 Jun 2002, Gabriel Rosa wrote:
> From a quick read, this looks like an application server (ie, all nodes
> do is get an exported display, and the bin runs on a central server).
> What I want is NFS root (there's a howto on it, but my question was more on
> how to get the base OS installed), since I want to have each diskless machine
> run it's own binary.
> I think Mike's suggestion of using vmware then chroot is close to what I
> had previously considered.
> thanks for the idea though,
> -Gabe

vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Sunset Systems
Who graciously hosts our website & mailing lists!