Filesystem is full ( /: )

Vib3 said:
ncdu helped nicely to getter better image of files in folders.
It said that my /rescue folder is 440.5MB.
/rescue folder is full on files:

Should they be rather links and whats the best way to make them links ?

If you add -i to the ls command, you'll notice that they all have the same inode number -- they're all hardlinked to one single file. Everything under /rescue is actually one massive crunchgen binary that does different things depending on the name that it is called by. IOW, everything is normal here.

/rescue has all the tools you should need to rescue a system that won't boot, and/or that doesn't have /usr/bin available, or even one that doesn't have /bin available.
 
Vib3 said:
Code:
%find -x / -size +10000 -exec du -h {} \][/quote]

Something is very wrong here -- you have only two files that are >5MB, but you're using 481MB on the / filesystem. Have you tried that fsck from single-user mode yet?
 
phoenix said:
Also, you may want to boot into single-user mode, and check the size of / without any other filesystems mounted. Run du from there. It may be that there's something in /var (the mountpoint directory not the mounted filesystem) or /usr.

Yes, it was the /var/db directory that was over 350M. Directory removed. Case closed -> Solved.

Thanks for everyone! :)
 
I am very glad you got it solved, but that fix makes little sense. Based on your first post, /var has its own filesystem. Why was /var/db infringing on /'s space in your case?

---

edit: I think I see what you mean. In multiuser mode, you had /var mounted on top of a /var that already contained lots of files. Right?
 
I'm sure the actual and useful /var/db/pkg was on the mounted /var, not the /var directory it was mounted on.
 
DutchDaemon said:
I'm sure the actual and useful /var/db/pkg was on the mounted /var, not the /var directory it was mounted on.

Yes.
Package information was on /var partition not on / partition,
so its ok :)
 
phoenix said:
Also, you may want to boot into single-user mode, and check the size of / without any other filesystems mounted. Run du from there. It may be that there's something in /var (the mountpoint directory not the mounted filesystem) or /usr.

DutchDaemon said:
I'm sure the actual and useful /var/db/pkg was on the mounted /var, not the /var directory it was mounted on.

I'm confused. Is it like having 2 /var's (one is mountpoint dir and another is mountpoint fs)? But that's not possible.
 
Sure it is. In fact, it happens all the time. Do you have a separate /var partition on your system? Then it's mounted on a directory in the root partition called /var, which gets overlayed (overlaid?) by the mounted /var. Put some files on that underlying /var, and your disk statistics look all weird. Same goes for /tmp, /usr, and other typical mountpoints. If you want to check this, boot into single-user mode and check what's in /usr, /var and /tmp. Won't be too much .. but they do exist as legitimate directories.
 
Oh okay. I've always treated it as one and only one entity (directory /var mounted as /var file system). As in whatever that gets dumped in /var, will never affect the root partition. Thanks for the tip.
 
sixtydoses said:
directory /var mounted as /var file system
If you have an independent /var partition, the device behind it - e.g. /dev/ad0s1e - is mounted on a directory (the mount-point) called /var, created* under the root partition /.
If you have no independent partition, files will be stored in the /var directory, under the root partition.

Check /etc/fstab and everything will become clear.


* actually, it's not "created", but simply extracted from the base distribution during the setup.
 
Beastie said:
e.g. /dev/ad0s1e - is mounted on a directory (the mount-point) called /var, created* under the root partition /.

Yea. That's what causes the confusion. A dedicated device /dev/ad0s1e for /var shouldn't interfere /dev/ad0s1a for /.
 
With a separate /var partition, the /var directory (i.e. the mount-point) will be the only thing stored on the root partition (e.g. /dev/ad0s1a).
However, if you unmount the partition and copy/move files to /var, they will be stored on the root partition, obviously.
 
sixtydoses said:
Yea. That's what causes the confusion. A dedicated device /dev/ad0s1e for /var shouldn't interfere /dev/ad0s1a for /.

It's actually not uncommon to have a /var/log partition on a /var partition on a / partition ... so long as you mount them in the right order, it will work fine.
 
SirDice said:
My /boot/kernel only contains about 30MB, I'm wondering why yours has 125MB?

The GENERIC kernel by default compiles debugging symbols which will be big.

in the GENERIC kernel config file, there is the line:
Code:
makeoptions     DEBUG=-g

That increases the /boot/kernel by 67MBytes and if you backup to /boot/kernel.old, it's even bigger.

the way around it is when you build your kernel, put in "-DINSTALL_NODEBUG" after make so it will not install the symbol files, and you don't need to comment out the line in the kernel config.

Code:
make buildkernel KERNCONF=GENERIC -DINSTALL_NODEBUG
make installkernel KERNCONF=GENERIC -DINSTALL_NODEBUG
 
thetrojan01 said:
I solved the problem for me! I had made a new kernel and didn't remove the old one GENERIC in /boot, so, the / it's 108% full because also the new kernel has 'root' as its owner.

It's now 64% full.

Also be careful if Desktop users run firefox as root... This creates big files in your directory. How you can avoid it: that's why there are adduser, su and sudo.
------------

If you made a new kernel, it gets built in /usr/obj/usr/src/sys/GENERIC

When you do the make installkernel

it will move /boot/kernel to /boot/kernel.old

and then install the new kernel in /boot/kernel

the reason when you installed the new kernel is due to the kernel debug symbol files which are 67MB in size as that's enabled by default in the GENERIC config file, this is mentioned in the /usr/src/UPDATING file, 20060118 entry.

As for root, what happens is when you do a upgrade atleast when I download the base install and even running install.sh to install, it first killed my /root symlink to /home/root so that /root is now using the / and then /var which was a symlink to /usr/var for me is now a directory so for the former, all I had to do was:

Code:
rm -rf /root ; ln -sf /home/root /root

and the /var problem can only be fixed in single-user mode since /var has devfs running on it for the named stuff so basically did the same thing for /var in single user mode.
 
Vib3 said:
For me there isnt GENERIC in /boot.
I used freebsd-update.

How do I remove the old kernel ?

Now that I think of it, the base package does not include the kernel as that's part of the kernel set which does create a /boot/kernel/GENERIC, I think what you really want to do if it created the GENERIC is:

Code:
mv /boot/kernel/GENERIC /boot/kernel/kernel

It probably named the kernel as GENERIC so that it won't overwrite the existing kernel file.

If you build the kernel yourself with

Code:
make installkernel KERNCONF=GENERIC

The old kernel and it's modules will already move the contents of /boot/kernel to /boot/kernel.old and the new kernel goes into /boot/kernel. If you wanted to really delete the old kernel, assuming that the new kernel works, then just:

Code:
rm -rf /boot/kernel.old
 
Just to add some more detail - this can also happen if there are files in /mnt:

Code:
# df -h
Filesystem       Size    Used   Avail Capacity  Mounted on
/dev/ipsd0s1a    496M    481M    -25M   105%    /
[...]
# mount /dev/da0p1 /mnt/usbkey
# ls -l /mnt/usbkey
total 4
drwxrwxr-x  2 root  operator  512 Jul 26 21:04 .snap
# umount /mnt/usbkey
# ls -l /mnt/usbkey
total 2
drwxr-xr-x  7 root  wheel  512 Jul 25 02:09 data
# umount /mnt/usbkey
umount: /mnt/usbkey: not a file system root directory
# rm -rf /mnt/usbkey/data
# ls -l /mnt/usbkey
total 0
# df -h
Filesystem       Size    Used   Avail Capacity  Mounted on
/dev/ipsd0s1a    496M    351M    105M    77%    /
[...]

In my case, this happened because files were copied to a mountpoint when the intended device was not mounted. In turn, this happened because the mount command was called from a backup script run from a cronjob. By default, /sbin is NOT in the path used by cron, so unless the path is modified, the full path to /sbin/mount must be provided in the script. If this isn't done, the call to mount fails - and the backup then backs up to the mountpoint directory, rather than the mounted device. If the mountpoint directory is under /mnt, it's on the root filesystem. So, in this case a failed mount results in the backup script filling the root filesystem. Slow claps for the admin involved. *cough*

Thanks to this thread, fixed with 0 downtime.
 
Back
Top