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?
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.
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
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.
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.
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?
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?
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.
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.
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:
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.