KWin crash - KDE Login no longer possible. How to recover without new installation?

hnimmo · January 7, 2015, 12:27pm

On my desktop, I now have OpenSuse 13.2 / KDE 4.11.14, having switched from Gnome.

I was using Yast to update software packages and the Kwin crashed. I am now unable to reach the KDE login screen, the best I can do is reach the Linux login.
(Note: my repos are the ‘standard’ ones plus OBS Libreoffice and GnomeApps)

Does anyone know what I should do to recover this situation, i.e what information I should supply from the command line, what corrections I should make from there?

Miuku · January 7, 2015, 12:28pm

Login as root, zypper ref && zypper up && zypper ve

Most likely some packages were installed but depend on libraries or other files that weren’t properly updated.

It’s possible that rpm database may have been corrupted during the crash as well, so if zypper is unable to install packages, run; rpm --rebuilddb

hnimmo · January 7, 2015, 1:01pm

Not sure if all went well. There was an error message that the debug repo url was wrong. (I have no debug repos in my repo list)

I’m getting many messages that there is ‘no space left on the device’. (I had allocated 12GB for the system, of which about 9.5GB had been used since I last looked, i.e. before installing KDE4)

Miuku · January 7, 2015, 1:02pm

df -h

Should reveal secrets to you about the disk usage. I’m guessing your / (root partition) is full. That would certainly cause all sorts of nasty issues.

hnimmo · January 7, 2015, 1:24pm

My / partition is 100% used. What now? I know that with gparted, I could reduce the size of the /home partition, shift it to the right, and then grow the root partition accordingly. But how does that work from the command line?

Miuku · January 7, 2015, 1:50pm

If you have access to 13.2 LiveCD you can use that to resize the partitions as well - the LiveCD includes gparted (Thank you devs for that). Resizing a live file system unless it’s BTRFS isn’t going to be something I recommend.

It’s possible that there are lots of cached files in the system so you could try zypper clean and then systemctl restart xdm to see if you can get to X - although if it crashed during an update, it’s most likely not going to, also /tmp might have lots of files and /var/log might have insanely large files as well - I would examine those as well.

Is the root partition btrfs? Maybe the snapshots are taking insane amount of space.

hcvv · January 7, 2015, 2:14pm

The first action should not be to enlarge that root partition, but to find out what is filling it up.

Emptying /tmp is one of the first things you could do.

When that is not realy helping, you can use

du -sk /*

to see if one of the directories there is far to large. Then go there to check further downwards

du -sk/suspect-directory/*

How large is that root partition? So we can assess if it is unusual to be full or not.

And of course Miuku’s advice.

hnimmo · January 7, 2015, 2:55pm

Root partition is 12GB. Is that bigger or smaller than recommended?
Root partition is btrfs, home is ext4.
Is it safe to clear out /tmp completely?

hcvv · January 7, 2015, 3:11pm

Smaller, the default is 20GB, but I have less then 6GB used of my 20, thus when you did not
install an execessive number of exxtr software, 12GB should be enough.
Btrfs has the habit of creating snapshots that can fill up your disk, but that does not show in the % used.
It should. I have it cleaned at every boot. On other systems (with a larger memory) I have it as tmpfs and thus cleared at shutdown.

gogalthorp · January 7, 2015, 4:01pm

12 gig is far too small for BTRFS by default BTRFS recommends 40 gig root (ie2Xwhat is recommended for ext4). You can turn snapper off which is the thing that eats up disk space.

malcolmlewis · January 7, 2015, 3:56pm

On Wed 07 Jan 2015 01:16:01 PM CST, hcvv wrote:

hnimmo;2687769 Wrote:
> My / partition is 100% used. What now? I know that with gparted, I
> could reduce the size of the /home partition, shift it to the right,
> and then grow the root partition accordingly. But how does that work
> from the command line?
The first action should not be to enlarge that root partition, but to
find out what is filling it up.

Emptying /tmp is one of the first things you could do.

When that is not realy helping, you can use

Code:

du -sk /*

to see if one of the directories there is far to large. Then go there to
check further downwards

Code:

du -sk/suspect-directory/*

How large is that root partition? So we can assess if it is unusual to
be full or not.

And of course Miuku’s advice.

Hi
Just a note, du on /.snapshot will be missleading on btrfs, and df
command isn’t applicable;

With btrfs and snapper use (as root user, not sudo!);


btrfs filesystem show
btrfs filesystem df /
snapper list |wc -l (just a count of the snapshots)

–
Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
SUSE Linux Enterprise Desktop 12 GNOME 3.10.1 Kernel 3.12.28-4-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

hnimmo · January 7, 2015, 4:29pm

/tmp is cleaned up - gained about 125MB
systemctl restart xdm does not work
The /.snapshots directory seems to be taking about 260MB (assuming the number returned by du is bytes) (But MalcomLewis would not trust this number anyway)
Seems a pity that btrfs was the default for root partition with 20GB on Opensuse 13.2 if it is such a disk space guzzler. I have only a total of 80GB to play with and not much left on /home. One of the major arguments in favour of btrfs is snapper.

Miuku · January 7, 2015, 4:36pm

Malcolm gave you good advice on how to investigate if snapper is using up a lot of space, you might be able to reclaim some from there and finish the zypper update - I would personally just nuke all the old snapshots to reclaim all space possible.

But it looks like your best option is to snag a bit of room from your /home at least temporarily to get the system up and running.

hnimmo · January 7, 2015, 4:55pm

What’s the next step after I have freed up some space (either by nuking the snapshots or by taking some space from /home, or both) ?

‘systemctl restart xdm’ does not work, there is ‘no such file or directory’

Miuku · January 7, 2015, 4:58pm

zypper up should install the remaining packages that weren’t installed properly when your system froze.

Then rebooting the system should bring your GUI back up if all packages are installed successfully and there’s enough room for temporary files. I would move at least 12GB from /home to / so you’d have 30GB there.

wolfi323 · January 7, 2015, 5:18pm

The service is called “display-manager” in 13.2.
So this should restart it:

systemctl restart display-manager

hnimmo · January 7, 2015, 6:58pm

Thanks. That did it, after the zypper up. I am back in business again. Next step will be to increase the size of the root partition, but not to 30GB, since I got complaints before that the /home space was running out and that caused me to shrink the root partition to 12 GB. I guess I should undelete the snapper.

You guys are terrific!

hnimmo · January 7, 2015, 8:59pm

…except that Yast is now broken…

No matter how I configure the repositories, they are returned to a ‘default’ configuration
The Online Updater aborts spontaneously shortly after launching
Yast SW Management aborts spontaneously shortly after launching

Any ideas?

Miuku · January 7, 2015, 9:06pm

You said you had only the default repositories (and perhaps Packman?) added?

If so, you could simply make a backup of all files in /etc/zypp/repos.d/ somewhere safe (just move them away) and use YAST / Repositories / Add / Community Repositories to add them back.

hnimmo · January 7, 2015, 10:11pm

I just deleted the contents of /etc/zypp/repos.d/ and set up my community repositories again using Yast. It worked.

Great work Miuku! Many thanks!