The other day when I went to start up my MythTV system I got a error that reads
"xsession: warning: unable to write to /tmp x session may exit with an error". I did some searching and found that /dev/sda1 is filled. The auto installer made it 4.7 GB and when I was looking for a solution people said it should be at least 7 GB.

I tried apt-get clean, then apt-get autoclean, it said I should run apt-get update and it just told me to run it again.

I downloaded GParted to try to resize the partitions, but the GUI failed to boot because of a video drivers error. I decided to just reinstall, but first I was going to try to boot to Knoppix 4.0.2(what I had lying around) to back my files. That did boot right either for some reason.

I just gave up and decided to reinstall from scratch but make /dev/sda1 much larger this time. When I went to partition the hard drive it said I didn't have write permission.

Is there a few files from /dev/sda1 that I can safely delete to get it to boot right again? Or how can I resize /dev/sda1? Or how can I do a fresh nstall with /dev/sda1 larger that 4.7 GB?

p.s. I'll be away this weekend so I may not be able to quickly reply.

You don't mention what version of Knoomyth you are running.

There was a logfile roatation problem in some of the earlier versions. it caused the / partition to fillup eventually.

You should be able to look around there as it sounds like you have a similar problem.

The logs that filled most as I remember were the mysql log.

Look for logrotate in here might give you some ideas.

The root partitions on my 4 KnoppMyth systems are 4.7Gb. No problem with that size, usually hangs around 55% full.

What device did you try to fdisk? Sounds like you may be trying to fdisk the CD-ROM, or that old version of Knoppix has a problem with your SATA controller.

Before you give up on your current installation, take a look through all the files in /var/log, and check your /home/mythtv/.xsession-errors log. A reboot should remove everything from /tmp except directories(?), but check that too.

I agree with slowtolearn, don't give up on your installation just yet. I've had a similar problem several times when my machine loses power and doesn't shutdown properly.

I'm pretty sure it is /home/mythtv/.xsession-errors that chews up the partition and causes X to barf. Increasing the partition may not change things; the file will likely grow and chew up more space. Just remove that file and you'll be good to go.

If all else fails, try "du -s *" to see disk usage from a given directory. You should be able to find the culprit pretty quick...

Chris

My favorite idiom for this is:

This produces an ordered list of the directories which are using the most space. The ordering is such that what is left on you console is biggest stuff and you can scroll backwards to see lesser. Sometimes I use:

But that's a lot more work to type.

I have to go with Chris and slowtolearn. I'm no Myth or X expert, but I've been around UNIX for years and Linux almost as long; I've never seen a full root partition error that couldn't be cleaned up. -- Don't panic.

picking up on Chris's advice, do the du -s as root, (so you have the permissions to read everything) and do it from the / directory. For reference Here's what I have; Note, I add a 'k' to the du -s, so the results are printed in kbytes. (it's just a preference.)



Look for the largest directory, (ignoring /myth /sys and /proc which are not part of the root partition. ) My numbers above are from a nearly clean R5F1. if you have any directories that are dramatically larger it might be a lead.
cd into the largest directory and repeat the 'du -sk *' keep iterating until you find your culprit.

If you find the bad file and don't know what it is get advice on removal procedures -- Sometimes rm -ing a file can make cleanup harder.

Assuming the .xsession-errors file is the culprit, Adding something like the following to the end of /etc/logrotate.conf should help. I'm just reading the man page and I have not put this into practice.


It would be good idea to see what errors are filling the log and possibly fixing that as well.

_________________
Mike
My Hardware Profile

Hi,
I have been down this road several times (good practice) and what seems to occur for me because I often use a small drive is that record space or inodes end up being all used up. This will of course cause errors to be generated at a fairly rapid rate and the log will fill up. Try checking the /var/log/mythtv/mythbackend.log for size. If you find it is quite large, simply as root make it smaller by a gig or so. # echo " " > /var/log/mythtv/mythbackend.log will clear it and also check the /myth/tv for some recording that is excessive and do the same to it.

The log rotate only runs once a day or so and when something goes astray with the backend processes, one ends up with a filled up root. The last time it happened to me, my kids decided to record a couple of hours of snow and I only had room for an hour.

Once you clean up the files you should be able to restart xserver without issue.

Mike

Measure twice, cut once.

Don't guess about where the space is being used. Run one of the du diagnostics and look where it tells you. The one I gave has the benefit of getting all the info in one pass, rather than requiring that you keep running du -s at each directory level, but it really doesn't matter which one you use.

What does matter is that you don't guess, but rather get the facts, then you can figure out what to do.

Hi,
As usual tjc, you are quite correct. I did mention to check the size of the /var/log/mythtv/mythbackend.log but I did not say how ls -al /var/log/mythtv/mythbackend.log* would show all the logs for comparison and whether or not it was the bad guy. If it was the problem and it was reduced in size, then the xserver should be able to be restarted and the recordings should be able to be reviewed in a normal manner and treated appropriately.

It is always the first place I look after having been there a few times

Mike

Version R5F1


GParted wouldn't boot far enough to let be start doing something.


I did this originally and got




This is what I get

I'm not sure if any of these are abnormally big.

Look more closely at /var that looks a bit large... Mine is only 1/10th that size...

OBTW - I think you were confusing du -k and df -k based on the file system summaries posted.

OK this is what I get for df -k


And your right about /var, what do I do now? Heres whats inside.

Running:

should show you which logfile has gotten gigantic..

You probably should take a quick look inside of that file too, to see what it's unhappy about...

Heres what I get

I'm going to assume it's mythfrontend.log. How do I look inside? I thought I had an idea on how to but it didn't work.