[vox-tech] debian virtual install

[vox-tech@lists.lugod.org]

On Mon, Jun 24, 2002 at 12:54:12PM -0700, ME wrote:
> 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.)
[...]
> 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.

  If you are root while making and extracting the tar you should have
no problems.

  Test sample follows... it should be safe to cut and paste the 
whole block.

  If anyone can find differences between cp and tar I would like to 
investigate.

===========
tar -cf d.tar /dev
# tar: Removing leading `/' from member names
# tar: /dev/log: socket ignored
# tar: /dev/gpmctl: socket ignored
tar -xf d.tar
find dev -ls | sed 's/^[ ]*[0-9]*//' > tar.l
rm -r dev
cp -pR /dev .
find dev -ls | sed 's/^[ ]*[0-9]*//' > cp.l
rm -r dev
diff tar.l cp.l
# 5100a5101
# > srw-rw-rw-   1 root     root            0 Jun 24 12:33 dev/log
# 5130a5132
# > srwxrwxrwx   1 root     root            0 Jun 24 12:33 dev/gpmctl
===========

  The sed thing strips off the inode number information... which will
be different from run to run.

  Note that the two differences are unix socket files, these only
exist because a process is holding them in place.  When the process
holding them exits they must be removed and recreated (with a call
to bind(2)) later to be of any value... so they are not a problem.

  People with non-Debian GNU tar binaries might want to test it
out.  I was digging through the Debian source for GNU cpio yesterday 
and I saw dozens of patches applied by the Debian maintainers (with
little comment blocks (date stamps from the 90's) stating that 
a patch had been forwarded to the upstream GNU maintainers).  I would
not be surprised if GNU tar is in a similar state of disrepair.


  If you intend to move the archive across distributions it is probably
best to add the '--numeric-owner' when creating the tar.  So that the
user/group id's owning files don't get shifted around extraction.

# `--numeric-owner'
#      This option will notify `tar' that it should use numeric user and
#      group IDs when creating a `tar' file, rather than names.


> On that same machine, make sure I have a kernel with loopback support:
> # losetup /dev/loop0 /tmp/debian.base.image.ext2
> # mkfs -t ext2 /dev/loop0
> # mkdir /tmp/base
> # mount -t ext2 /dev/loop0 /tmp/base

for what it's worth losetup is optional... (loopback support still required)
  dd if=/dev/zero of=debian.img bs=1M count=512
  mke2fs -b 4096 -i 8192 -F debian.img
  mount -o loop debian.img /mnt


> 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.)

  I have only tinkered with chroot a few times, but I don't remember
having any problems with /proc.  You have to mount /proc inside
the chroot jail to be able to run proc things...

...like so:

root@star:~/chr#
====
ls -l
# total 48
# drwxr-xr-x    2 root     root         4096 Jun 24 14:30 bin
# drwxr-xr-x   11 root     root        24576 Jun 24 14:22 dev
# drwxr-xr-x   86 root     root         4096 Jun 24 14:32 etc
# drwxr-xr-x    2 root     root         4096 Jun 24 14:29 home
# drwxr-xr-x    5 root     root         4096 Jun  9 16:24 lib
# drwxr-xr-x    2 root     root         4096 Jun 24 14:29 proc
# drwxr-xr-x    2 root     root         4096 Jun 16 13:14 sbin
chroot `pwd` bin/bash
ps
Error: /proc must be mounted
  To mount /proc at boot you need an /etc/fstab line like:
      /proc   /proc   proc    defaults
  In the meantime, mount /proc /proc -t proc
mount /proc
ps
#   PID TTY          TIME CMD
#   395 tty2     00:00:00 bash
#   434 tty2     00:00:00 vi
#  1128 tty2     00:00:00 bash
#  1131 tty2     00:00:00 ps
====

  In reality you don't need to be root inside the jail and take along
all the etc, sbin baggage you need to be able to run the mount command.
You can mount the proc filesystem from outside the jail before 
chrooting into it:


root@star:~/chr#
====
cat /proc/mounts
# /dev/root / ext3 rw 0 0
# proc /proc proc rw 0 0
# devpts /dev/pts devpts rw 0 0
# /dev/sda3 /home ext3 rw 0 0
mount -t proc proc /root/chr/proc
cat /proc/mounts
# /dev/root / ext3 rw 0 0
# proc /proc proc rw 0 0
# devpts /dev/pts devpts rw 0 0
# /dev/sda3 /home ext3 rw 0 0
# proc /root/chr/proc proc rw 0 0
chroot `pwd` bin/bash
ps
#   PID TTY          TIME CMD
#   395 tty2     00:00:00 bash
#   434 tty2     00:00:00 vi
#  1143 tty2     00:00:00 bash
#  1144 tty2     00:00:00 ps
cat /proc/mounts
# /dev/root / ext3 rw 0 0
# proc /proc proc rw 0 0
# devpts /dev/pts devpts rw 0 0
# /dev/sda3 /home ext3 rw 0 0
# proc /proc proc rw 0 0
====

  TTFN,
    The other Mike  ;)