!!Where is my 2G? - THANKS

[Matthew Kuiken]

Brian Astill wrote:
<snip>

> All is not yet _completely_ over.  There is still 2G floating 
> somewhere on hda2 - I had 1.8G free, moved 3.9G - but still have 
> only 3.3G free!
> /dev/hda2             11661852   7792368   3277088  71% /
> /dev/hdb7             11258648   3908832   6777904  37% /home
> and for some reason, my son's directory shows up as it should 
> under /home (in your file manager of choice) - but if I look 
> at /mnt/hdb7 it shows only my directory.  Odd?
> 
> BUT it IS now a workable system, so thanks, everyone.

I think that this, coupled with a couple of comments from your other 
emails can shed some light on this situation.

I believe that a lot of your problems stem from a misunderstanding about 
how mount works.  In order to mount anything, a directory must exist in 
the current root file system that will be replaced by the new drive as 
it is mounted.  If nothing is mounted to that directory, then when you 
cd into the directory, you stay on the current disk, still within the 
bounds of the file system.  Any files you create or copy will be on this 
file system.  Once you mount a drive to that directory, the access 
changes.  When you cd to that directory after having mounted the other 
disk, you are actually changing to the root directory of the mounted drive.


 > The only odd thing is that baobab lists BOTH /home and  /mnt/hdb7
 > as if they are separate items, thereby falsely reporting the
 > total size.  No other output indicates any problem.

I believe that these are two separate things.  When you tried to copy 
onto hdb7 while it was not mounted, you probably thought that it was 
mounted to /mnt/hdb7.  Since this directory exists within the hda2 file 
system, the files were copied there as you directed mc to do.

The reason your son's directory does not show up in this location is 
because these are the files created during the copy that was aborted for 
lack of hard drive space.  Again, make sure you have backups, and you 
should be able to delete everything under /mnt/hdb7.

To ensure that this is the case before you delete those files, The 
output of the mount command will list all the directories that have file 
systems mounted to them. The command 'mount | grep hdb7' should only 
return one line of the form:
/dev/hdb7 on /home type ext3 (rw)
If there is a line like this:
/dev/xxxx on /mnt/hdb7 type ext3 (rw)
Then something is mounted at /mnt/hdb7, and it is not really safe to 
delete it.  I believe that you will find nothing mounted there.  If this 
is the case, deleting these files should recover your 2G.


 >
 > "Where is my 2G? - MC" describes the original cause of the present
 > situation.
 >
 > I hoped that a reboot would "free up" hda2, but when I logged on
 > Dapper complained that it had no space to write to the
 > authentication file.  OK - a bit clumsy, but OK.
 > So, using Freesbie live CD, I copied the contents of /home
 > to /mnt/hdb7, deleted the /home on hda2, and edited /etc/fstab to
 > point /home to /dev/hdb7, then rebooted.
 > Dapper then complained I did not have a home directory!  THAT
 > should not happen!
 > Clearly, Dapper did NOT look at /etc/fstab until AFTER login!
 > The proof of this came when I copied all the hidden (dot) files
 > from /home to /dev/hdb7 to /home on hda2.  In that condition, on
 > reboot I had the setup I wanted AND when I looked at /home it
 > listed all the hidden AND unhidden data which was on hdb7!
 > IMHO, That indicates a BUG.  Dapper should look at /etc/fstab
 > BEFORE login, NOT after!
 >
 > Perhaps there is a workaround?
 >

To explain all of this, in the context of the above, Dapper did look for 
the home directory, and gave you the correct error, that home did not 
exist.  There was also an earlier error during the boot process that you 
did not notice.  This was the error that happened while the fstab was 
processed.  Since the directory /home did not exist at this point on the 
root file system, mount could not mount /dev/hdb7 to that directory. 
This error would have scrolled by very quickly during the boot sequence, 
and may not have even been shown to you because of usplash.  It would 
have shown up in a call to dmesg, though.

At the end of all of this explanation is one more admonishment.  This is 
not a bug in Dapper/Ubuntu.  It is a misunderstanding about how the 
tools of your operating system work.  I would recommend regular backups, 
lots of research when doing something like this in the future, and 
perhaps even asking the list when you feel that you have assembled a 
proper set of steps to accomplish a complex procedure to see if anyone 
has any suggestions on how to avoid problems.

-Matt