Help! screwed-up root partition

[Doug-11]

I've screwed up in trying to install and use a 1.5TB external HD on my
2008.1 MDV.

Thinking I was writing to the new HD, I wrote some stuff which evidently
went into the / partition (only 3.5G) instead - how I was able to do
this as user I don't know - and filled it up. I moved this out (again as
user and not realising it was in /).

Now 'df' shows the / partition as 100% full and I get warning messages
on boot about inadequate space in the partition.
However, the directories in the / partition (/bin, /dev, /etc, /initrd,
/.kde, /lib, /media, /mnt, /opt, /proc, /root, /sbin, /sys - the rest
have their own partitions) only account for about 10% of the partition
space.

How do I find out where the other 90%'s gone? How do I free it up again?


Doug

[Sander Lepik-2]

Hey,

you should go recursive.. It seems you have access to that partition, so
do this:

# cd /_partition
# df -sh *
# cd biggest_result_from_above_command
# df -sh *
etc
etc

sorry for bad english, hope it helps

--
Sander



Doug kirjutas:

> I've screwed up in trying to install and use a 1.5TB external HD on my
> 2008.1 MDV.
>
> Thinking I was writing to the new HD, I wrote some stuff which
> evidently went into the / partition (only 3.5G) instead - how I was
> able to do this as user I don't know - and filled it up. I moved this
> out (again as user and not realising it was in /).
>
> Now 'df' shows the / partition as 100% full and I get warning messages
> on boot about inadequate space in the partition.
> However, the directories in the / partition (/bin, /dev, /etc,
> /initrd, /.kde, /lib, /media, /mnt, /opt, /proc, /root, /sbin, /sys -
> the rest have their own partitions) only account for about 10% of the
> partition space.
>
> How do I find out where the other 90%'s gone? How do I free it up again?
>
>
> Doug
>

[Doug-11]

Tander Lepik wrote:

> Hey,
>
> you should go recursive.. It seems you have access to that partition,
> so do this:
>
> # cd /_partition
> # df -sh *
> # cd biggest_result_from_above_command
> # df -sh *
> etc
> <snip>

> Doug kirjutas:
>> <snip> Now 'df' shows the / partition as 100% full and I get warning
>> messages on boot about inadequate space in the partition.
Thanks for the suggestion, but '-s' is not an option recognised for 'df'
on my system.

The output from 'df' is as follows:
Filesystem            Size  Used Avail Use% Mounted on
/dev/hda5             3.5G  3.5G   24K 100% /
/dev/hda1              92M   26M   61M  31% /boot
/dev/hda10             67G  4.1G   63G   7% /copies
/dev/hda6              40G   31G  9.0G  78% /home
/dev/hda11             20G   15G  5.0G  75% /photos
/dev/sdb1             1.4T   15G  1.4T   2% /photos_and_backups
/dev/hda9             9.8G   35M  9.8G   1% /tmp
/dev/hda7              40G  6.1G   33G  16% /usr
/dev/hda8             9.8G  248M  9.6G   3% /var

As you see,  partition /dev/hda5  mounted on / is  supposedly 100% full.
However, 'ls -aghS /' gives this result:

total 28K
drwxr-xr-x  14 root  16K 2009-07-07 13:26 dev/
drwxr-xr-x 115 root 7.6K 2009-07-07 14:55 etc/
drwxr-xr-x   2 root 5.6K 2009-03-07 11:28 sbin/
drwxr-xr-x  15 root 5.0K 2009-07-07 13:25 lib/
drwxr-xr-x   4 root 3.0K 2009-07-07 13:26 boot/
drwxr-xr-x   2 root 2.8K 2008-08-28 18:10 bin/
drwxrwxrwx  48 root 1.7K 2009-07-06 22:06 photos/
drwxrwxrwt  17 root 1.1K 2009-07-07 15:56 tmp/
drwx------  20 root 1008 2009-07-07 15:35 root/
drwxr-xr-x  25 root  672 2009-07-07 13:25 ./
drwxr-xr-x  25 root  672 2009-07-07 13:25 ../
drwxr-xr-x  19 root  464 2008-06-02 09:22 var/
drwxr-xr-x  15 root  368 2008-06-06 17:16 usr/
drwxr-xr-x   9 root  280 2009-07-07 13:26 media/
drwxr-xr-x   6 root  160 2008-05-31 12:11 home/
drwxr-xr-x   6 root  152 2009-02-12 15:15 opt/
drwxrwxrwx   6 root  144 2009-07-07 14:10 photos_and_backups/
drwxrwxrwx   5 root  112 2009-07-07 15:14 copies/
drwxr-xr-x   2 root   80 2008-06-02 18:11 initrd/
drwx------   3 root   72 2008-05-31 11:31 .kde/
drwxr-xr-x   2 root   48 2008-03-19 13:21 mnt/
lrwxrwxrwx   1 root   44 2008-07-16 15:35 liblibvixAllProducts.so ->
/usr/lib/vmware-vix/lib/libvixAllProducts.so*
-rw-r--r--   1 root    0 2009-07-07 13:25 .autofsck
dr-xr-xr-x 158 root    0 2009-07-07 13:24 proc/
drwxr-xr-x  12 root    0 2009-07-07 13:24 sys/
 
from which you see that less than 100K of / is actually being used.

Where is the rest tied up?

Doug

[Eugeni Dodonov]

Doug wrote:

> Tander Lepik wrote:
>> Hey,
>>
>> you should go recursive.. It seems you have access to that partition,
>> so do this:
>>
>> # cd /_partition
>> # df -sh *
>> # cd biggest_result_from_above_command
>> # df -sh *

I think it should be 'du' instead of 'df'.

--
Eugeni Dodonov

[Thomas Backlund]

Doug skrev:
> from which you see that less than 100K of / is actually being used.
>
> Where is the rest tied up?

It might be some stale inodes not getting released...

Try to reboot ...

--
Thomas

[Jim Beard-3]

Doug wrote:
> Now 'df' shows the / partition as 100% full and I get warning messages
> on boot about inadequate space in the partition.
> However, the directories in the / partition (/bin, /dev, /etc, /initrd,
> /.kde, /lib, /media, /mnt, /opt, /proc, /root, /sbin, /sys - the rest
> have their own partitions) only account for about 10% of the partition
> space.
>
> How do I find out where the other 90%'s gone? How do I free it up again?

Perhaps you have mounted / on top of (and there by hidden) a
mounted partition?

I would suggest booting with a rescue disk or One disk and with
all partitions unmounted check each partition.

Cheers!

jim b.

--
UNIX is not user unfriendly; it merely
      expects users to be computer-friendly.

[Doug-11]

Jim Beard wrote:

> Doug wrote:
>> Now 'df' shows the / partition as 100% full and I get warning
>> messages on boot about inadequate space in the partition.
>> However, the directories in the / partition (/bin, /dev, /etc,
>> /initrd, /.kde, /lib, /media, /mnt, /opt, /proc, /root, /sbin, /sys -
>> the rest have their own partitions) only account for about 10% of the
>> partition space.
>>
>> How do I find out where the other 90%'s gone? How do I free it up again?
>
> Perhaps you have mounted / on top of (and there by hidden) a mounted
> partition?
>
> I would suggest booting with a rescue disk or One disk and with all
> partitions unmounted check each partition.
>
> Cheers!
>
> jim b.
>

Thanks Jim, Thomas, Eugeni.

(1) unfortunately 'du' doesn't give any more useful information
(2) the mess is there after re-booting (although when the error first
appeared, MCC seemed to have lost the mount points for all the
partitions. At least that was corrected by re-booting)
(3) booting with a rescue disk looks the next option - I was afraid that
was coming. I can also have a look with 'qparted'.

If the worst comes to the worst and it's still not apparent where the
fault lies, would it be possible to copy the / directories elsewhere;
wipe /dev/hda5 and copy them back to /dev/hda5?
That is, with all partitions unmounted, using 'cp' I assume , rather
than 'dd', which I guess would simply perpetuate the error.
Or is that completely no go?

Doug

[ed-81]

Doug wrote:

> Jim Beard wrote:
>> Doug wrote:
>>> Now 'df' shows the / partition as 100% full and I get warning
>>> messages on boot about inadequate space in the partition.
>>> However, the directories in the / partition (/bin, /dev, /etc,
>>> /initrd, /.kde, /lib, /media, /mnt, /opt, /proc, /root, /sbin, /sys
>>> - the rest have their own partitions) only account for about 10% of
>>> the partition space.
>>>
>>> How do I find out where the other 90%'s gone? How do I free it up
>>> again?
>>
>> Perhaps you have mounted / on top of (and there by hidden) a mounted
>> partition?
>>
>> I would suggest booting with a rescue disk or One disk and with all
>> partitions unmounted check each partition.
>>
>> Cheers!
>>
>> jim b.
>>
> Thanks Jim, Thomas, Eugeni.
>
> (1) unfortunately 'du' doesn't give any more useful information
> (2) the mess is there after re-booting (although when the error first
> appeared, MCC seemed to have lost the mount points for all the
> partitions. At least that was corrected by re-booting)
> (3) booting with a rescue disk looks the next option - I was afraid
> that was coming. I can also have a look with 'qparted'.
>
> If the worst comes to the worst and it's still not apparent where the
> fault lies, would it be possible to copy the / directories elsewhere;
> wipe /dev/hda5 and copy them back to /dev/hda5?
> That is, with all partitions unmounted, using 'cp' I assume , rather
> than 'dd', which I guess would simply perpetuate the error.
> Or is that completely no go?
>
> Doug
>

post the output of "cat /etc/fstab" and "cat /etc/mtab"
my bet is you have somehow gotten something mounted over something else,
hiding whatever is under the original mountpoint on the drive.
booting with a boot disk or live version [knoptix anyone? or the qparted
boot disk] should at least give you a look at what is there without
doing any damage.

[Doug-11]

ed wrote:

> Doug wrote:
>> Jim Beard wrote:
>>> Doug wrote:
>>>> Now 'df' shows the / partition as 100% full and I get warning
>>>> messages on boot about inadequate space in the partition.
>>>> However, the directories in the / partition (/bin, /dev, /etc,
>>>> /initrd, /.kde, /lib, /media, /mnt, /opt, /proc, /root, /sbin, /sys
>>>> - the rest have their own partitions) only account for about 10% of
>>>> the partition space.
>>>>
>>>> How do I find out where the other 90%'s gone? How do I free it up
>>>> again?
>>>
>>> Perhaps you have mounted / on top of (and there by hidden) a mounted
>>> partition?
>>>
>>> I would suggest booting with a rescue disk or One disk and with all
>>> partitions unmounted check each partition.
>>>
>>> Cheers!
>>>
>>> jim b.
>>>
>> Thanks Jim, Thomas, Eugeni.
>>
>> (1) unfortunately 'du' doesn't give any more useful information
>> (2) the mess is there after re-booting (although when the error first
>> appeared, MCC seemed to have lost the mount points for all the
>> partitions. At least that was corrected by re-booting)
>> (3) booting with a rescue disk looks the next option - I was afraid
>> that was coming. I can also have a look with 'qparted'.
>>
>> If the worst comes to the worst and it's still not apparent where the
>> fault lies, would it be possible to copy the / directories elsewhere;
>> wipe /dev/hda5 and copy them back to /dev/hda5?
>> That is, with all partitions unmounted, using 'cp' I assume , rather
>> than 'dd', which I guess would simply perpetuate the error.
>> Or is that completely no go?
>>
>> Doug
>>
> post the output of "cat /etc/fstab" and "cat /etc/mtab"
> my bet is you have somehow gotten something mounted over something
> else, hiding whatever is under the original mountpoint on the drive.
> booting with a boot disk or live version [knoptix anyone? or the
> qparted boot disk] should at least give you a look at what is there
> without doing any damage.
>

/etc/fstab:
# Entry for /dev/hda5 :
UUID=96c90828-c5ec-44b1-8c60-17ab9bdf61d8 / reiserfs
notail,relatime,user_xattr 1 1
# Entry for /dev/hda1 :
UUID=e92a2d5c-0f7a-4f65-81b0-353b34bdac34 /boot ext3 relatime 1 2
# Entry for /dev/hda10 :
UUID=1e2efe63-612e-4faf-ac49-ccc2dbfc0ae8 /copies reiserfs
notail,relatime,user_xattr 1 2
# Entry for /dev/hda6 :
UUID=a09033e9-021c-490e-aa0b-cb32263f520f /home reiserfs
notail,relatime,user_xattr 1 2
/dev/cdrom /media/cdrom iso9660
umask=0,users,iocharset=utf8,noauto,ro,exec 0 0
/dev/cdrom1 /media/cdrom1 iso9660
umask=0,user,iocharset=utf8,noauto,exec 0 0
/dev/fd0 /media/floppy auto
umask=0,users,iocharset=utf8,noauto,exec,flush 0 0
# Entry for /dev/hda11 :
UUID=9fe8a950-0515-4f08-9a49-f13a83c5af72 /photos reiserfs
notail,relatime,user_xattr 1 2
# Entry for /dev/sdf1 :
UUID=d4495f0b-e2d0-4a1f-8a55-dafebff3810c /photos_and_backups reiserfs
defaults 0 0
none /proc proc defaults 0 0
# Entry for /dev/hda9 :
UUID=d01efacd-5a03-48e3-90d7-ee12fcbdc2e7 /tmp reiserfs
notail,relatime,user_xattr 1 2
# Entry for /dev/hda7 :
UUID=daa7fd81-3852-4b3c-b0fe-ca159e211b37 /usr reiserfs
notail,relatime,user_xattr 1 2
# Entry for /dev/hda8 :
UUID=73dd9cbe-daeb-4cec-a950-0b81a5a24837 /var reiserfs
notail,relatime,user_xattr 1 2
# Entry for /dev/hda3 :
UUID=47af315c-51b1-46ad-86cf-1ffe5ee132bb swap swap defaults 0 0

/etc/mtab:

/dev/hda5 / reiserfs rw,relatime,notail,user_xattr 0 0
none /proc proc rw 0 0
/dev/hda1 /boot ext3 rw,relatime 0 0
/dev/hda10 /copies reiserfs rw,relatime,notail,user_xattr 0 0
/dev/hda6 /home reiserfs rw,relatime,notail,user_xattr 0 0
/dev/hda11 /photos reiserfs rw,relatime,notail,user_xattr 0 0
/dev/sdb1 /photos_and_backups reiserfs rw 0 0
/dev/hda9 /tmp reiserfs rw,relatime,notail,user_xattr 0 0
/dev/hda7 /usr reiserfs rw,relatime,notail,user_xattr 0 0
/dev/hda8 /var reiserfs rw,relatime,notail,user_xattr 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0
none /sys/fs/fuse/connections fusectl rw 0 0
none /proc/fs/vmblock/mountPoint vmblock rw 0 0
/dev/sdg1 /media/disk reiserfs rw,nosuid,nodev,uhelper=hal 0 0
/dev/sda1 /media/disk-2 reiserfs rw,nosuid,nodev,uhelper=hal 0 0


The 1.5TB HD was originally /dev/sdf1 as in fstab but is now /dev/sdb1
as in mtab

Doug

[Renaud (Ron) Olgiati]

On Wednesday 08 July 2009, my mailbox was graced by a missive
 from Doug <doug_bainbridge@...> who wrote:

> (3) booting with a rescue disk looks the next option - I was afraid that
> was coming. I can also have a look with 'qparted'.

Boot your Knoppix disk, launch Konqueror in "file size view" mode, look for
the big one file, and delete ?
 
Cheers,
 
Ron.
--
                       No discipline is ever requisite
                      to force attendance upon lectures
                    which are really worth the attending.
                                            -- Adam Smith
                                   
                   -- http://www.olgiati-in-paraguay.org --

[Anssi Hannula-3]

Doug wrote:

> Tander Lepik wrote:
>> Hey,
>>
>> you should go recursive.. It seems you have access to that partition,
>> so do this:
>>
>> # cd /_partition
>> # df -sh *
>> # cd biggest_result_from_above_command
>> # df -sh *
>> etc
>> <snip>
>
>> Doug kirjutas:
>>> <snip> Now 'df' shows the / partition as 100% full and I get warning
>>> messages on boot about inadequate space in the partition.
> Thanks for the suggestion, but '-s' is not an option recognised for 'df'
> on my system.
>
> The output from 'df' is as follows:
> Filesystem            Size  Used Avail Use% Mounted on
> /dev/hda5             3.5G  3.5G   24K 100% /

[...]
> As you see,  partition /dev/hda5  mounted on / is  supposedly 100% full.
> However, 'ls -aghS /' gives this result:
>
> total 28K
> drwxr-xr-x  14 root  16K 2009-07-07 13:26 dev/
[...]
>
> from which you see that less than 100K of / is actually being used.

ls doesn't show the total sizes of directories recursively. Use e.g.
du -sxh /*
to show how much each directory takes space (note that this is slow).

--
Anssi Hannula

--
Anssi Hannula

[Doug-11]

Anssi Hannula wrote:

> Doug wrote:
>  
>> Tander Lepik wrote:
>>    
>>> Hey,
>>>
>>> you should go recursive.. It seems you have access to that partition,
>>> so do this:
>>>
>>> # cd /_partition
>>> # df -sh *
>>> # cd biggest_result_from_above_command
>>> # df -sh *
>>> etc
>>> <snip>
>>>      
>>> Doug kirjutas:
>>>      
>>>> <snip> Now 'df' shows the / partition as 100% full and I get warning
>>>> messages on boot about inadequate space in the partition.
>>>>        
>> Thanks for the suggestion, but '-s' is not an option recognised for 'df'
>> on my system.
>>
>> The output from 'df' is as follows:
>> Filesystem            Size  Used Avail Use% Mounted on
>> /dev/hda5             3.5G  3.5G   24K 100% /
>>    
> [...]
>  
>> As you see,  partition /dev/hda5  mounted on / is  supposedly 100% full.
>> However, 'ls -aghS /' gives this result:
>>
>> total 28K
>> drwxr-xr-x  14 root  16K 2009-07-07 13:26 dev/
>>    
> [...]
>  
>> from which you see that less than 100K of / is actually being used.
>>    
>
> ls doesn't show the total sizes of directories recursively. Use e.g.
> du -sxh /*
> to show how much each directory takes space (note that this is slow).
>  

6.7M    /bin............................................*
21M    /boot
6.0G    /copies
152K    /dev............................................*
89M    /etc...............................................*
30G    /home
4.0K    /initrd...........................................*
131M    /lib..............................................*
0    /liblibvixAllProducts.so......................*
9.0K    /media...........................................*
0    /mnt....................................................*
42M    /opt................................................*
15G    /photos
30G    /photos_and_backups
0    /proc...................................................*
7.4M    /root..............................................*
9.1M    /sbin...............................................*
0    /sys......................................................*
2.9M    /tmp
6.1G    /usr
218M    /var

I've starred the dirs in / on /dev/hda5 - nothing obvious that I can
see. The rest have their own partitions.

Doug

[Doug-11]

ed wrote:

> Doug wrote:
>> Jim Beard wrote:
>>> Doug wrote:
>>>> Now 'df' shows the / partition as 100% full and I get warning
>>>> messages on boot about inadequate space in the partition.
>>>> However, the directories in the / partition (/bin, /dev, /etc,
>>>> /initrd, /.kde, /lib, /media, /mnt, /opt, /proc, /root, /sbin, /sys
>>>> - the rest have their own partitions) only account for about 10% of
>>>> the partition space.
>>>>
>>>> How do I find out where the other 90%'s gone? How do I free it up
>>>> again?
>>>
>>> Perhaps you have mounted / on top of (and there by hidden) a mounted
>>> partition?
>>>
>>> I would suggest booting with a rescue disk or One disk and with all
>>> partitions unmounted check each partition.
>>>
>>> Cheers!
>>>
>>> jim b.
>>>
>> Thanks Jim, Thomas, Eugeni.
>>
>> (1) unfortunately 'du' doesn't give any more useful information
>> (2) the mess is there after re-booting (although when the error first
>> appeared, MCC seemed to have lost the mount points for all the
>> partitions. At least that was corrected by re-booting)
>> (3) booting with a rescue disk looks the next option - I was afraid
>> that was coming. I can also have a look with 'qparted'.
>>
>> If the worst comes to the worst and it's still not apparent where the
>> fault lies, would it be possible to copy the / directories elsewhere;
>> wipe /dev/hda5 and copy them back to /dev/hda5?
>> That is, with all partitions unmounted, using 'cp' I assume , rather
>> than 'dd', which I guess would simply perpetuate the error.
>> Or is that completely no go?
>>
>> Doug
>>
> post the output of "cat /etc/fstab" and "cat /etc/mtab"
> my bet is you have somehow gotten something mounted over something
> else, hiding whatever is under the original mountpoint on the drive.
> booting with a boot disk or live version [knoptix anyone? or the
> qparted boot disk] should at least give you a look at what is there
> without doing any damage.
>

I used gparted-live-cd to look at the /dev/hda5 partition.
There's considerable discrepancy between the sizes of directories in
/hda5 reported by 'du' and by 'gparted'. /dev, /mnt and /proc are all
hugely bigger according to gparted:

du -sxh /* gparted directory

       
       
6.7M 16.4M /bin
0.128M 896.3M /dev
89M 0.45M /etc
0.004M
        /initrd
131M 5.7M /lib
0
        /liblibvixAllProducts.so
0
        /media
0 935.7M /mnt
42M
        /opt
0 921.9M /proc
7.4M 0.0871M /root
9.1M 4.4M /sbin
0 347.5M /sys


The files in /dev and /proc seen in gparted all look reasonably
appropriate, but my eye is very inexpert, so I don't know what to make
of it.

According to gparted /mnt contains a big set of subdirectories: bin,
dev, etc, lib, mnt, proc, ram, sbin, sys, tmp, usr and linuxrc. Some of
them are empty, others contain files partly duplicating the
corresponding / directory. Is this to be expected or has part of the
system got duplicated and mounted on /mnt?

Doug

[Doug-11]

Doug wrote:

> ed wrote:
>> Doug wrote:
>>> Jim Beard wrote:
>>>> Doug wrote:
>>>>> Now 'df' shows the / partition as 100% full and I get warning
>>>>> messages on boot about inadequate space in the partition.
>>>>> However, the directories in the / partition (/bin, /dev, /etc,
>>>>> /initrd, /.kde, /lib, /media, /mnt, /opt, /proc, /root, /sbin,
>>>>> /sys - the rest have their own partitions) only account for about
>>>>> 10% of the partition space.
>>>>>
>>>>> How do I find out where the other 90%'s gone? How do I free it up
>>>>> again?
>>>>
>>>> Perhaps you have mounted / on top of (and there by hidden) a
>>>> mounted partition?
>>>>
>>>> <snip>
>>
>> booting with a boot disk or live version [knoptix anyone? or the
>> qparted boot disk] should at least give you a look at what is there
>> without doing any damage.
>>
> I used gparted-live-cd to look at the /dev/hda5 partition.
> There's considerable discrepancy between the sizes of directories in
> /hda5 reported by 'du' and by 'gparted'. /dev, /mnt and /proc are all
> hugely bigger according to gparted:
>
> du -sxh /*..........gparted................directory  
> 6.7M..................16.4M................... /bin
> 0.128M........... 896.3M.................../dev
> 89M...................0.45M.................../etc
> 0.004M.........................................../initrd
> 131M...................5.7M.................../lib
> 0....................................................../liblibvixAllProducts.so
>
> 0....................................................../media
> 0 .......................935.7M................../mnt
> 42M................................................./opt
> 0........................921.9M................../proc
> 7.4M................0.0871M................. /root
> 9.1M......................4.4M.................. /sbin
> 0........................347.5M.................../sys
>
>
> The files in /dev and /proc seen in gparted all look reasonably
> appropriate, but my eye is very inexpert, so I don't know what to make
> of it.
>
> According to gparted /mnt contains a big set of subdirectories: bin,
> dev, etc, lib, mnt, proc, ram, sbin, sys, tmp, usr and linuxrc. Some
> of them are empty, others contain files partly duplicating the
> corresponding / directory. Is this to be expected or has part of the
> system got duplicated and mounted on /mnt?
>
> Doug
>
>

Sorry for the earlier post - the formatting got lost.

Doug

[Anssi Hannula-3]

Doug wrote:

> Doug wrote:
>> I used gparted-live-cd to look at the /dev/hda5 partition.
>> There's considerable discrepancy between the sizes of directories in
>> /hda5 reported by 'du' and by 'gparted'. /dev, /mnt and /proc are all
>> hugely bigger according to gparted:
>>
>> du -sxh /*..........gparted................directory
>> 6.7M..................16.4M................... /bin
>> 0.128M........... 896.3M.................../dev
>> 89M...................0.45M.................../etc
>> 0.004M.........................................../initrd
>> 131M...................5.7M.................../lib
>> 0....................................................../liblibvixAllProducts.so
>>
>> 0....................................................../media
>> 0 .......................935.7M................../mnt
>> 42M................................................./opt
>> 0........................921.9M................../proc
>> 7.4M................0.0871M................. /root
>> 9.1M......................4.4M.................. /sbin
>> 0........................347.5M.................../sys
>>
>
>> The files in /dev and /proc seen in gparted all look reasonably
>> appropriate, but my eye is very inexpert, so I don't know what to make
>> of it.

It looks like what ed suspected; there are files hidden underneath the
mounts. For example, /proc should be *empty* (when no procfs is mounted
in it;   when procfs is mounted, it still would contain only zero-size
files).

You seem to have tried to copy a procfs filesystem into a real
filesystem by accident. Same for /dev and /sys, they should not contain
regular files when umounted (/dev may contain device files that do not
take space).

>> According to gparted /mnt contains a big set of subdirectories: bin,
>> dev, etc, lib, mnt, proc, ram, sbin, sys, tmp, usr and linuxrc. Some
>> of them are empty, others contain files partly duplicating the
>> corresponding / directory. Is this to be expected or has part of the
>> system got duplicated and mounted on /mnt?

This seems rather strange, as you had no filesystem mounted on /mnt so
any files there shouldn't have been hidden under it.

--
Anssi Hannula

[Doug-11]

Anssi Hannula wrote:

> Doug wrote:
>  
>> Doug wrote:
>>    
>>> I used gparted-live-cd to look at the /dev/hda5 partition.
>>> There's considerable discrepancy between the sizes of directories in
>>> /hda5 reported by 'du' and by 'gparted'. /dev, /mnt and /proc are all
>>> hugely bigger according to gparted:
>>>
>>> du -sxh /*..........gparted................directory
>>> 6.7M..................16.4M................... /bin
>>> 0.128M........... 896.3M.................../dev
>>> 89M...................0.45M.................../etc
>>> 0.004M.........................................../initrd
>>> 131M...................5.7M.................../lib
>>> 0....................................................../liblibvixAllProducts.so
>>>
>>> 0....................................................../media
>>> 0 .......................935.7M................../mnt
>>> 42M................................................./opt
>>> 0........................921.9M................../proc
>>> 7.4M................0.0871M................. /root
>>> 9.1M......................4.4M.................. /sbin
>>> 0........................347.5M.................../sys
>>>
>>>      
>>> The files in /dev and /proc seen in gparted all look reasonably
>>> appropriate, but my eye is very inexpert, so I don't know what to make
>>> of it.
>>>      
>
> It looks like what ed suspected; there are files hidden underneath the
> mounts. For example, /proc should be *empty* (when no procfs is mounted
> in it;   when procfs is mounted, it still would contain only zero-size
> files).
>
> You seem to have tried to copy a procfs filesystem into a real
> filesystem by accident. Same for /dev and /sys, they should not contain
> regular files when umounted (/dev may contain device files that do not
> take space).
>
>  

Would it be safe to delete all the files under /proc, /dev and /sys when
the system is unmounted?
What would be likely to happen on re-booting?

>>> According to gparted /mnt contains a big set of subdirectories: bin,
>>> dev, etc, lib, mnt, proc, ram, sbin, sys, tmp, usr and linuxrc. Some
>>> of them are empty, others contain files partly duplicating the
>>> corresponding / directory. Is this to be expected or has part of the
>>> system got duplicated and mounted on /mnt?
>>>      
>
> This seems rather strange, as you had no filesystem mounted on /mnt so
> any files there shouldn't have been hidden under it.
>
>  

Can I just delete all those filesystems under /mnt in the unmounted system?

Doug

[Thomas Backlund]

Doug skrev:

> Anssi Hannula wrote:
>> Doug wrote:
>>  
>>> Doug wrote:
>>>    
>>>> I used gparted-live-cd to look at the /dev/hda5 partition.
>>>> There's considerable discrepancy between the sizes of directories in
>>>> /hda5 reported by 'du' and by 'gparted'. /dev, /mnt and /proc are all
>>>> hugely bigger according to gparted:
>>>>
>>>> du -sxh /*..........gparted................directory
>>>> 6.7M..................16.4M................... /bin
>>>> 0.128M........... 896.3M.................../dev
>>>> 89M...................0.45M.................../etc
>>>> 0.004M.........................................../initrd
>>>> 131M...................5.7M.................../lib
>>>> 0....................................................../liblibvixAllProducts.so
>>>>
>>>> 0....................................................../media
>>>> 0 .......................935.7M................../mnt
>>>> 42M................................................./opt
>>>> 0........................921.9M................../proc
>>>> 7.4M................0.0871M................. /root
>>>> 9.1M......................4.4M.................. /sbin
>>>> 0........................347.5M.................../sys
>>>>
>>>>      
>>>> The files in /dev and /proc seen in gparted all look reasonably
>>>> appropriate, but my eye is very inexpert, so I don't know what to make
>>>> of it.
>>>>      
>> It looks like what ed suspected; there are files hidden underneath the
>> mounts. For example, /proc should be *empty* (when no procfs is mounted
>> in it;   when procfs is mounted, it still would contain only zero-size
>> files).
>>
>> You seem to have tried to copy a procfs filesystem into a real
>> filesystem by accident. Same for /dev and /sys, they should not contain
>> regular files when umounted (/dev may contain device files that do not
>> take space).
>>
>>  
>
> Would it be safe to delete all the files under /proc, /dev and /sys when
> the system is unmounted?

Yes.

> What would be likely to happen on re-booting?

Theu will get populated correctly by the kernel.., and the system will
still work...

>>>> According to gparted /mnt contains a big set of subdirectories: bin,
>>>> dev, etc, lib, mnt, proc, ram, sbin, sys, tmp, usr and linuxrc. Some
>>>> of them are empty, others contain files partly duplicating the
>>>> corresponding / directory. Is this to be expected or has part of the
>>>> system got duplicated and mounted on /mnt?
>>>>      
>> This seems rather strange, as you had no filesystem mounted on /mnt so
>> any files there shouldn't have been hidden under it.
>>
>>  
> Can I just delete all those filesystems under /mnt in the unmounted system?
>

Check first if it's gparted-live-cd that has mounted /mnt or anything
below it, an if so unmount it...

--
Thomas