[vox-tech] debian virtual install
ME
vox-tech@lists.lugod.org
Mon, 24 Jun 2002 15:43:35 -0700 (PDT)
On Mon, 24 Jun 2002 msimons@moria.simons-clan.com wrote:
> 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.
It was primarily not the extraction, it was the archival - not all files
were archived as they should have been. Some device special files had
problems. Demand-dial fifos were not copied, and some other in-use open
devices were uncopied. This was 2-3+ years ago with Debian 2.2r0 with
whatever tar was packaged with it. I'll see if I can find those CD-ROMs
and try another run...
> 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 .
"-a" is better than -p since -a is ~ -dp
> 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.
Yep, I used this when I did mine ages ago. I actually made my tar archive
command about 3-4 lines long with all of the option I was trying to use
when maing the archive into the tarball.
> > 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
This (use of mount with -loop) *is* a better practice. You are entirely
correct. Mount did not have the -loop option when I started using losetup
wayyy back when and I can never seem to remember is even exists when I
could use it.
> > 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...
Oh, no... proc worked fine in chroot, but not for updates - especially
where services were concerned. This is actually something I have verified
in Debain 3.0 (x86). From a proper chroot, it would fail to update some of
the packages, but when I used a machine with NFS root, it was just fine.
Here is an example.... Say you are running X and a new version of X server
is updated. Obviously if you are silly and say you want to stop the
presently running X Server from the chrooted env, unhappy things may
result. This is a very poor example since it does at least *ask* if you
want to restart with the new server...
> ...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 ;)
Problems with multiple roots sharing the same /proc when using dselect or
dpkg updates include missing lock files use by packages being updated.
Example: no need to stop "App XYZ" because there is no lockfile for it -
even if we can see the PID when we grep for it. Results in a possible
attempt to start a second instance of the services which may fail- upon
failure, exist status != 0, and installation script may count as "Fail".
Worse, a second instance continues to run and does not exit as it should
- leaving the second instance to possibly grab control of the socket when
available (on the nightly log rotation for the service that it knows is
running on the real root) and then the "real" service not starting up as
would be expected.
Running the updates all from my private IP NC with rw access to the root
has never had problems with any upgrades - no complaints from me on that.
]:>
I'll see if I can get some free time here and grab the old debian 2.0r0
disk, install a base and then boot from the CD and use tar to archive the
whole base system (minus /proc and /tmp) and then extract it to see where
the diffs were. I recall I was able to boot into the new tree, but some
apps would not run and some services did not start.
-ME
(The other-other mike that goes by ME since there are too many Mikes out
there at least one of which (the mike I am responding to) who has
excellently powerful foo. :-)
-----BEGIN GEEK CODE BLOCK-----
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?
------END GEEK CODE BLOCK------
decode: http://www.ebb.org/ungeek/ about: http://www.geekcode.com/geek.html