Problem:

> If I boot from a generic tomsrtbt-1.7.118 floppy, mount /dev/hda2 /mnt
> (the partition has about 140 MB free, the tomsrtbt-1.7.118 is freshly
> untarred.) I get a message that that there are -13 sectors available,
> and the build fails.

ext2fs, I assume?  It can't be unpacked/rebuilt from DOS-fs.

> cd /mnt/tmp/tomsrtbt-1.7.118
> ./unpack.s
> ./2/usr/doc/buildit.s

Try,
        cd /mnt/tmp/tomsrtbt-1.7.118
        mkdir tmp
        cd tmp                  # making sure to start in an empty spot
        unpack.s /dev/fd0u1722  # Must have an operand...
                                # Could be unpack.s ../tomsrtbt.raw, also
        2/usr/doc/buildit.s

I think doing it under the clean directory will solve the problem.  But I
*do* want to figure out what is going wrong for you.  I have had sporadic
reports of this, and I can't reproduce it.  My theory is that somehow it
isn't unpacking correctly under some circumstances, and it has leftover
extra files, or that some users are doing something differently than me...
I can do what I just described and it does *not* run out of space, it will
rebuild just fine, so I am missing something...  I will re-do this for the
next version so that unpack.s will make a brand new directory in all 
cases.  I need to play with it more and see if I can get it to fail this
way...
        
> However, if I try and replace 2/bin/cpio with another cpio (5k larger), I
> get the message

bin/cpio and bin/tar and bin/pax are the same file, hardlinks, you know.

If you just replace cpio, you STILL have the file there...

>   -169 (or -168) sectors available, build failed
> 
> no matter what else I delete from 2/bin.  For example, I tried removing
> tar and fsck.msdos and the build still failed.  This can't possibly be
> right.  My guess is some size calculation is not starting from scratch.

No, it is just that you didn't also delete pax, so you havn't cleared out
any space from cpio and tar.  Use "ls" to see if a file has hard links...
"ls -l" shows how many hard links exist for the file... "ls -i" will show
you the inode numbers if you have to figure out what names refer to the
file...  The size calculation always starts from scratch.

-Tom

Reply via email to