Source Removal after ch9?

Bill Maltby - LFS Related lfsbill at
Wed Nov 13 10:00:22 PST 2002

On Wed, 13 Nov 2002, chris.danx wrote:

Chris, I'm getting two of your posts each time. Tell your mailer to just
reply to the "Reply-to" only and I think that will stop it.

>Bill Maltby - LFS Related wrote:
>> And just as a note, I remove each source directory immediately after a
>> successful install of that package, *except* for the linux sources. 
>I was doing that, but then realised I should wait until the end and see 
>what happened, and went back and installed some packages over (which 
>seems to have caused a bit of fragmentation on the partition, because 
>the libs built after filled the spaces the sources left and it's all a 
>bit messed up).

You need not worry too much about this. Some fragmentation is unavoidable
when doing the builds. But since your accesses into these areas will not
be purely (mostly) sequential, the performance hit should be minimal. If
you want to avoid it totally, make a second partition and copy everything
from the build partition to the new empty one when you are all done.
Adjust the *new* /etc/fstab, lilo.conf and any other stuff you may have
put the partition ID into. Run lilo and reboot. I suggest *not* cleaning
the build partition or removing lilo's references to it until you *know*
all is good. If you want the new partition to be your boot... well you
know what to do - man lilo, and so on.

>Right now I'm having a problem with my lfs partition so perhaps I goofed
>up somewhere.  It complains about inode count being 16 when it should be
>17 (all the flippin time).  It fixes it, then goes on about it's
>business then when I reboot it moans again. :(
>I unmounted the partition from suse, did "fsck -c -f -v /dev/hdb4", then 
>found on SuSE fsck found the same error.  It has fixed it, but I haven't 
>rebooted yet.  Could it be a bad block?

Not likely. If it is a bad block(s), there will be message about I/O
errors, timeouts and such on the console and in /var/log/kern.log or
sys.log. IDE tends to repair those things by automatically assigning
alternates, so that *could* be the cause until it gets them reassigned,
but you should still see some messages.

Unclean shutdowns can cause what you are seeing. Man badblocks. You can
use this to run a non-destructive read-only test on the partition. There
is another cause, besides unclean shutdowns, but I can't recall what it is
right now. Try manually mounting, writing something into the area and
unmounting and fscking. If there is no error after that, it is probably
unclean shutdown doing it. Hmmm... I wonder if manually entering the block
count incorrectly when e2mkfs'ing the partition could lead to that? Or
having a partition size that does not support an even multiple of your
selected block size (like if your partition would hold 1,001 1K blocks and
you told e2mkfs to use 4K blocks).

>I've removed every source directory except the linux sources and 
>mod-utils, and did
>tar -cvpf lfs-backup.tar *
>from /mnt/lfs and am now bzip2'ing it.  I was gonna copy the .tar.bz2 
>file to suse, format the lfs partition and extract the .tar.bz2 file 
>over it.  Will that make all the files on /mnt/lfs more or less 
>contiguous?  That's my primary reason for doing it, but I also want to 
>see if the inode problem goes away.

Yes it will make it contiguous. Check your partition info when you redo
the partition and make sure it has multiples of 2/4/8 blocks (1K/2K/4K
block sizes). Depending on partition size, block size will default to 1K
or 4K (could be 2K, but I haven't seen that default). You can manually
override it. Also, you can use the -c parameter on mke2fs to do the
read-only block check (or you can specifiy exhaustive write test - man
e2fsck and badblocks).

>[oh, the bz2 is finished :)  The drive is 340Megs compressed!  With 
>untarred sources and obj files it was 1.5Gbs untarred and 1.1Gbs tarred]

You may want to change the blocksize if you are concerned about wasted
space. Allow a few attempts because when you increase blocksize, number of
i-nodes needed drops and the inverse happens also. Use the -m parameter on
the e2mkfs to minimize the reserved blocks.

>Could the inode problem be connected to another report fsck gives?  It 
>says the lfs partition wasn't cleanly umounted after reboot and does an 
>fsck (reboot from SuSE; where the partition is still mounted on boot, 
>could suse be umounting it improperly?).  Why is that?

Could be related. When you boot *out* of your host, it can not unmount any
partitions that have processes active on them. So if you are in $LFS when
you issue the reboot, a process may still be active on that partition.

>> He, he! I just thought - high confidence is when I make most of my
>> mistakes!  :-/
>Isn't it always :)

Bill Maltby
billm at

Unsubscribe: send email to listar at
and put 'unsubscribe lfs-support' in the subject header of the message

More information about the lfs-support mailing list