KDE not starting after running Partioner.

English Install/Boot/Login
1

Because of the Dropbox change, I have had to amend my /home partition to ext4. I backed it up, ran Partitioner from yast (in command mode), reload the /home directory and restarted. Despite the fact that everything appeared to hunky-dory before I rebooted, KDE failed to load. The startup routine switched to the normal session where you would expect KDE to start (the one you’d access via ctl-alt-f7) but then it hung. The KDE screens failed to appear.

However, I can logon in command mode in the session I access via ctl-alt-f1. This seems to work perfectly, if command mode is what I want, except that, when I log on as my normal user it tells me “”login: write last log failed: No space left on device”. But df tells me that /home is only 34% full, so it seems, at least superficially, that the problem does not lie with /home. But I can’t think of anywhere else that the problem could lie. (I don’t get this message when I log on as root btw.)

My machine is currently cycling between session 7 and session 1, which makes investigation difficult, but it is nonetheless possible. So where should I look? And any suggestions as to what I should do?

2

Check permissions. In particular, check whether you own your own home directory.

3

It is perhaps trying to write last log to “/var/log/wtmp”. Check the permissions there, too.

4

May to explain what the planned action was: https://forums.opensuse.org/showthread.php/534318-Creating-and-moving-home-to-an-EXT4-partition?p=2890099#post2890099

When this was indeed executed as the OP and I planned to do, then /home is populated as before without change of any ownership/permissions.

@johngwalker, You could check from the CLI login if your home directory is there

ls -l /home

and if it, at first sight, contains what it should.

You say that you expect KDE to start, but IMHO you should first see a GUI login, not a desktop, on logical screen 7. Can you please explain?

Also, when your system switches all the time between logical screens 1 and 7 (never experienced such a thing), you could boot into run-level 3 to have a more stable environment to work on the problem.

5

This is read-only for anyone not root or in the group utmp. Should this be changed? It’s not anything I should have altered.

6

Thanks, Hank.

i checked the contents of /home before I signed off the reloading. It contains what it should (three user home directories). I’ve just checked permissions and the home directory permissions look okay.

Pleas remind me how to boot into run level 3. I’ve done this before but a very long time ago

7

On the grub menu entry, hit ‘e’. That should give you an edit screen. Scroll down until you find a line that begins “linux” (or might be “linuxefi”). Then append " 3" to the end of that line. Then CTRL-X should continue the boot to run level 3.

8

I hope my description fits (haven’t done this either for a long time and Grubs change).

When the Grub screen shows hit e. That should offer you something to look at… Go down to the line starting with linux or efilinux or so and hit the End key to go to the end (the line might be wrapped, thus the end might be lower then you expect at first sight). the enter 3 (maybe <space>3). Then look for the action to contunue booting, must be explained somewhere on the screen.

TO LATE. And nrickert’s descriptions is much better then mine.

9

I did this. But before doing this I ran sudo reboot from my user account, and it told me that there was no room to write on a file in /var. However, after the usual pause the PC rebooted and I was able to do the above (and thanks to hcvv for his contribution).

as soon as I got back in I ran df -h, and sure enough that says /var has all 40G used. What is going on?

10

That’s something for you to investigate.

Here, “/var” uses less than 1G. Maybe there are some coredumps.

You can perhaps use “du /var” to find where the space has gone.

11

Thanks nrickert.

That gave me a very long list of files, none of which stands out as being overly big. And it gives a lot of files whose size in zero.

What does stand out from the df -h output though, is the whole range of partitions thatbare 100% full. In fact, the only ones that aren’t temps or devtmpfs are /boot/df i and /home. This makes me wonder whether, when using Partitioner, I accidentally resized the /home partition and reduced the others.

Is this possible and is there some way to check this? And if I have done this, what is the easiest way to fix it?

12

You are looking for where most of the space has gone.

Try this way.


cd /var
du -s *

That should just tell you the amount of space in each subdirectory.

Look for directories that are surpisingly large. The “cd” into such a directory, and repeat the “du -s *”.

Work you way down until you find likely cultprits.

13

Isn’t this just another case of too many saved BTRFS snapshots?

14

we understand that it is difficult now to do copy/paste from the screen, but this means we depend very much about your exact description. Thus when you in post #9 says that /var fills up to 100% and you now tell that there are more, that is very confusing.

Also, you can probby connect a USB memory stich to the system, mount that e.g. at /mnt and then do things like

fdisk -l >/mnt/fdisk-list

And then later mount it on the system where you make thse postings to list it and do the copy/paste.

I do not think you changed the size of other partitions., but an fdisk -l will show. Also it might be good to tell which filesystems are at 100%. Also the suggesteion of @mrmazda is to be checked.

15

I have to confess that I have never mounted a USB stick in command mode before. I have been googling like mad and found lots of help, but everything I have tried ends in failure. Every time it tells me that I have selected the wrong file system type.

My Windows laptop tells me my USB stick uses FAT32. When I google what to do on the /mount the web sites say use **-t vfat **or -t msdos. Either should work, I’m told, but neither does.

I tried mounting the removable disk that I used to tar the /home directory. This was originally mounted via KDE but I’ve used it to run **tar **in command mode, both to create the archive and reload /home. Windows tells me it’s format is NTFS, but when I try to mount it I’m told it doesn’t have a valid NTFS

The commands I’ve tried for the USB stickare

mount -t vfat /dev/sdb/ /run/media

and

mount -t msdos /dev/sdb /run/media

and for the backup disk

mount -t ntfs /dev/sdb/ run/media

I’ve checked that /dev/sdb is the correct device by unplugging it. When there is something plugged in I get the fs errors. When there is nothing plugged in it tells me there is no such file or directory.

i am now tearing my hair out. I know I must be making a simple error, but after several hours trying I just can’t see it.

16

I would try without any fs type to see if mount can find out itself what it is e(it is heuristic, but often works).

But I would never mount at /run/media. It would block all that is in there now!.

Just use /mnt.

17

Maybe it would help to read VFAT - LQWiki now, and when you wish to manually mount removable media, examine what the kernel reports right after physically attaching:

blkid
18

Normally a file system resides on a partition on the device not on the raw device. So maybe try /dev/sdb1

fdisk -l should list any partitions present

19

And that is also a very good one!!!

20

Thanks for the replies. They were amazingly helpful.

blkid was the command I was looking for, and yes, gogalthorp was right: I should be using /dev/sdb1. The stick is now mounted!

It’s now vey late and I’ve had a busy day. I will post the output from the various diagnostic tomorrow morning, when I’m less tired and less likely to make a silly mistake.

once again, thank you all.