Suse login fails due to full system partition

English Install/Boot/Login
#1

I have a problem that I can’t login to SUSE in graphical mode. I get to the login prompt; enter my username and password; SUSE starts to do the login but then crashes back to the login prompt. Looking in /var/log/messages doesn’t tell me anything useful. However, I noticed that my SUSE system partition is full (at 20 GB). So I think this is the culprit that is stopping my login.

Unfortunately, I can’t extend my system partition as it is ext4 (SUSE default) but parted (from SUSE 11.2 live cd) complains that it can’t do anything with ext4.

Any clue how to continue?

I’m using
OpenSUSE11.2 x86_64
KDE 4.3.5
Linux 2.6.31.14-0.1-desktop

#2

delete everything in /tmp

#3

Hum… that saved 95 MB but I still can’t login (and not a long term solution). Perhaps there is something else wrong? I can log in as root but not as user…

edit to add: I can also login as shell prompt as user but not with the GUI

Surely (haha) they couldn’t have made the default file system not editable by the most widely used partition editor?

#4

Ok what is the system used for? You have any large databases? Have you installed everything you can get your hands on? 20 gig should be plenty for most people tunning a desktop.

Have you tun fsck on the partitions?

#5

There must be some other path which is overflowing. Possible candidates are /tmp, /var/log and /var/tmp (amongst others).

Just to be sure - what is the output of

du -h /tmp
grep BOOTUP /etc/sysconfig/cron

?

#6

I’m developing code in C++ and C/Python for modelling of particle accelerators. So the worst sort of code - physics code! But I don’t do anything silly like run batch jobs as root or anything. I haven’t run fsck, I’ll try that now.

–

du -h /tmp/ returns with:


4.0K    /tmp/pulse-ctT9RwKSB1Fe
4.0K    /tmp/.ICE-unix
8.0K    /tmp/.vbox-cr67-ipc
4.0K    /tmp/gpg-Linadu
8.0K    /tmp/.vbox-root-ipc
4.0K    /tmp/.wine-1000/server-806-2a006a
8.0K    /tmp/.wine-1000
4.0K    /tmp/kde-root
4.0K    /tmp/.X11-unix
8.0K    /tmp/ksocket-root
4.0K    /tmp/.wine-0/server-805-4506f
8.0K    /tmp/.wine-0
4.0K    /tmp/ssh-zppno6761
216K    /tmp/

–

grep BOOTUP /etc/sysconfig/cron returns with


CLEAR_TMP_DIRS_AT_BOOTUP="no"

–

FYI, df -h returns with


Filesystem            Size  Used Avail Use% Mounted on
/dev/sda5              20G   20G     0 100% /
udev                  1.5G  240K  1.5G   1% /dev
/dev/sda6             436G  108G  306G  27% /home
/dev/sda1             100M   25M   76M  25% /windows/C
/dev/sda2             466G   26G  440G   6% /windows/D

Plus a couple of CIFS mounts (samba)

#7

fsck returns clean for the /dev/sda5 and /dev/sda6 (my system and home partition)

fsck refuses to look at my ntfs partition, error message is


<blah>
fsck: fsck.ntfs not found
<blah>

Presumably it doesn’t know about ntfs, these are the windows partitions anyway so who cares.

#8

chrisrogers1234 wrote:

>
> I have a problem that I can’t login to SUSE in graphical mode. I get to
> the login prompt; enter my username and password; SUSE starts to do the
> login but then crashes back to the login prompt. Looking in
> /var/log/messages doesn’t tell me anything useful. However, I noticed
> that my SUSE system partition is full (at 20 GB). So I think this is the
> culprit that is stopping my login.
>
> Unfortunately, I can’t extend my system partition as it is ext4 (SUSE
> default) but parted (from SUSE 11.2 live cd) complains that it can’t do
> anything with ext4.
>
> Any clue how to continue?
>
> I’m using
> OpenSUSE11.2 x86_64
> KDE 4.3.5
> Linux 2.6.31.14-0.1-desktop

Check /var/log/ directory for too large files.

–
Viljo

#9

No it will not do a ntfs. You need Windows to fix a Windows file system.

#10

Just as a reminder:

#11

I found the culprit - my backup server failed to mount so my backup script stuck the files in the wrong place. I submitted a bug report to cover the problem (SUSE silently dies on login when system partition is full).

Thanks for your help.

#12

The problem is in your backup script then, you should check that the backup partition is mounted before proceeding.

#13

Well, in my code I don’t let it die silently with no clue for the user as to the cause, even if there is a user error. Saves you guys having to deal with feckless idiots like me if the login gives a polite error message in the first place.

#14

The problem is that a disk full situation has many direct and indirect effects any one of each could prevent the login sequence from completing, and it’s difficult (but perhaps not impossible) for the failing step to identify the bottom cause because it has come through a chain of cooperating processes. That is one of the reasons that root is granted privilege to use up the remaining wiggle room on the disk so as to be able to get in and free up space.

#15

Try this:
du -ha / | grep ‘M:space:]]’ | sort -n -r | more
or even
du -ha / | grep ‘G:space:]]’ | sort -n -r | more

#16

this is a big off topic but I would use less instead of more so:

du -ha / | grep 'M:space:]]' | sort -n -r | less