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 ;) _______________________________________________ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech