Never had a problem creating fresh copies of tomsrtbt on this: RH5.1 + Kernel 2.0.36 df -v Filesystem 1024-blocks Used Available Capacity Mounted on /dev/sda1 101075 37228 58628 39% / /dev/sda3 4098191 464465 3421668 12% /usr /dev/sda4 4314827 2411263 1680261 59% /var /dev/sdb1 3043987 485433 2401119 17% /opt /dev/sdb2 5538223 30955 5220508 1% /export I assume it builds the loopback partition in the root partition on /dev/ram2 ..... Admitted I slightly mod the tomsrtbt build for local needs by stripping some of the drivers and adding others, but it's still nearly full. Given that tomsrtbt builds on the root partition? ( Is that always correct Tom ? ) and good practice should dictate never having a huge root partition so that recovery is faster itself, the problem you describe should hardly ever occur ? Ted Rule, Flextech Television "Ed G." <[EMAIL PROTECTED]> on 20/04/99 03:28:04 Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: (bcc: Ted Rule/160GPS/Flextech/UK) Subject: [tomsrtbt] Tomsrtbt doesn't build correctly on loopback partition I wrote earlier about tomsrtbt refusing to build because of insufficient disk space even when there should have been enough (e.g., doing a buildit.s immediately after a pristine install and still coming up short). >From what I have seen I am beginning to suspect that tomsrtbt will not build correctly on a loopback partition. Has anyone successfully built tomsrtbt 1.7.118 on a loopback partition? On my system, tomsrtbt will only build in a small (< 15 MB) linux partition. Tomsrtbt did *not* build in my large linux partition (~10 GB) nor in any of the loopback partitions I created either on my linux box, my old 486 running Windows 95, or my girlfriend's Win 98 system. >From what I have seen cpio appears to be the culprit. It does not reproduce hard links correctly, sometimes replacing a hard link with another copy of the file itself. Take a look at what happens to the manual pages for date, false and pwd, which along with 23 other files are all linked to the the manual page for Debian's busybox. This diff compares the usr.cpio supplied on a stock tomsrtbt with a usr.cpio created in a loopback partition: -rw-r--r-- 27 root root 0 Nov 25 13:38 usr/man/date --- > -rw-r--r-- 27 root root 1953 Nov 25 13:38 usr/man/date 199c199 < -rw-r--r-- 27 root root 0 Nov 25 13:38 usr/man/false --- > -rw-r--r-- 27 root root 1953 Nov 25 13:38 usr/man/false 201c201 < -rw-r--r-- 27 root root 0 Nov 25 13:38 usr/man/pwd --- > -rw-r--r-- 27 root root 1953 Nov 25 13:38 usr/man/pwd 205c205 Here are the results of some testing I did to see the effect of varying the cpio I used as well as the partition type (loopback, small native, large native). usr.cpio supplied on stock tomsrtbt 1.7.188: 4515 blocks usr.cpio created by gnu cpio on a small linux partition: 5602 blocks usr.cpio created by gnu cpio on a loopback partition: 5602 usr.cpio created by tomsrtbt cpio (pax, really) on a loopback partition: 4626 blocks usr.cpio created by tomsrtbt cpio on a small linux partition: 4515 blocks usr.cpio created by tomsrtbt cpio on a large linux partition (~10GB): 4715 blocks My conclusions are that: 1. the cpio supplied on tomsrtbt will only work correctly in a small partition. This may or may not be related to the fact that cpio represents inodes (used to keep track of hard links) as 16 bit integers and truncates inode numbers greater than 65535. On a stock e2fs file system, this would mean file systems larger than 240 megabytes would have their inodes truncated. 2. the cpio supplied on tomsrtbt drops hard links on loopback partitions. 3. gnu cpio fails to reproduce hard links accurately whether in a loopback or normal partition.
