I’m running Leap 42.2 on my Dell XPS 13 9350 laptop, and have been for a while. I generally hibernate the machine at the end of the day, and start it again in the morning. Yesterday I shut it down completely. When I turned it on today, the desktop was taking some time to start (things were black, then a desktop icon, then I started pressing random keys and eventually the rest popped up). I began to open some programs, but half wouldn’t appear. They’d load (icon with spinning ring on the taskbar), and then that would disappear and they wouldn’t pop up. Also, some of my hotkeys were doing things they weren’t assigned to do (I double checked the shortcut entry and nothing changed.)
So things were clearly out of whack, so I rebooted the machine and it would boot into the TTY screen. Normally, that screen flashes for a second, and then KDE shows up with its login screen. Not anymore. I tried logging on and doing ‘init 5’, and it would go through the process of trying to start up (green logo with three moving dots), but then dump me back into TTY. I renamed my ~/.kde4 to see if it would do anything different, but it didn’t upon next boot, so I renamed it back.
So basically, things are weird and I don’t remember doing anything new to the machine. Of course, it has surely updated in the last few days, so perhaps that is somehow responsible? I’m not a complete linux noob, but I’m not an expert either, so any ideas would be very much appreciated.
Please let me know what I can try, or what information I can show here to help me troubleshoot this issue.
If you are running a standard openSUSE 42.2 installation with KDE as desktop then you should have KDE5 (plasma5, frameworks5, …) which store their configurations in “~/.config/” and “~/.local/share/”.
You could start testing by renaming those two directories. BUT BEWARE: “~/.config/” and “~/.local/share/” contain configuration files for a lot of applications. So don’t delete them.
If the test results in a usable KDE desktop then you can move the rest of the configuration files back into the newly created “~/.config/” and “~/.local/share/”.
I renamed those two directories, ran ‘init 5’, and got the same result. The green logo appears and the three green dots move, and then I’m dumped back into the TTY screen. But thank you for the suggestion.
Fraser,
I attempted to create a new user, but I got an error stating there was no space left on the device. I get the same error when I use ‘sudo’. For sudo, it gives the warning about the lack of space, but then says it will read sudo anyway and runs. For the useradd command, it lets me run it and type in a new user name, but then I get the error regarding lack of space and it fails. I of course can’t say for sure, but I get the feeling that a new user won’t solve the issue, as it doesn’t even load the KDE login screen, which of course happens before I try to login with my user name.
The fact that it thinks there is no space (which there definitely is) must have to do with it mounting in a read-only mode. I’ve seen a similar error on another machine earlier this week, and I ended up reinstalling SUSE on the root partition (I keep separate /home partitions). I can always do this, but I’d rather avoid it since I’ll lose some of my machine configuration that I’ve done to the root sections of the OS.
I have had this happen to me. I am guessing it is the btrfs snapshots have locked your system up. If you are running btrfs your root partition should be more like 40GB to prevent any issues.
When you get to your console prompt. Login as root.
type:
df -h
The root partition is probably at 100%
Next, list the snapshots in Snapper:
snapper -c root list
Delete one or more snapshots from Snapper. Replace “#” with a specific snapshot number. I starte from the highest and work my way down.
snapper -c root delete #
I am not 100% sure that this is the issue but that is what it sounds like to me.
You were spot on. I can’t believe I didn’t think to check to see if the filesystem WAS actually full or not. Those snapshots really snuck up on me. Is there a way to prevent them from sticking around for so long? I chose btrfs because it was recommended to me, but now I feel like I should have just went with ext4.
I also went with xfs for my /home partition, but after installing some stuff, I realized it made it too big. But with xfs, you can’t directly shrink partitions… You have to back up the data somewhere else, and delete and recreate the partition. Pain in the ass, and I’ve yet to get around to it. Guess I’ll be doing that sooner rather than later.
PS: Is there a way for me to marked this thread as solved?
you should check your snapper config /etc/snapper/root and reduce key parameters
new quota system has proven very good at cleanup, but maybe you dont have it enabled.
helpful to add alias space=‘sudo btrfs filesystem usage -h /’ to .bashrc and check from time to time.
config file and reduced SPACE_LIMIT from 0.5 to 0.2.
Also, in my previous post I said “I realized it made it too big”, but I really meant to say, “I realized I made it too big.” Not a big difference in the end, but I was choosing my partition sizes and filesystems and I made my /home partition too big. Not a good idea when using xfs.
So my main issue is solved (thanks, all!), but now I have a side-effect. My root partition is mounting as read-only each time I boot. I can change it to rw once it’s booted, but that’s obviously not ideal. I assume that the btrfs filesystem is flagged somewhere as being in trouble, causing it to mount as read-only at boot for safety purposes. I’m going to try to run ‘btrfs check /’ from a live usb drive (since I can’t do it while it’s mounted) to see if that helps. Of course, I assume instead of ‘/’ I’ll have to put in ‘/dev/sda6’, or maybe mount it somewhere and put in that path. Whatever it ends up being, if it works I’ll post it here for future SUSE’ers to find.
On 05/07/2017 10:16 AM, ndc33 wrote:
>
> you should check your snapper config /etc/snapper/root and reduce key
> parameters
> new quota system has proven very good at cleanup, but maybe you dont
> have it enabled.
> helpful to add alias space=‘sudo btrfs filesystem usage -h /’ to .bashrc
> and check from time to time.
>
>
The better place for custom aliases is in your ~/.alias file, that way
you won’t lose them if bash is upgraded with changes to .bashrc.
–
Ken
linux since 1994
S.u.S.E./openSUSE since 1996
be careful not to use check --repair unless all else fails (start with online scrub). best to read this: btrfs recovery https://en.opensuse.org/SDB:BTRFS
I’m glad it worked for you. I am still using BTRFS on root for my primary machine. I have no issues with it otherwise. I don’t know why your root is mounting as read-only as a side effect. That’s odd but after a little reading about your read-only issue. It sounds like the filesystem may have been “corrupted” maybe due to it filling up. I don’t know. It also appears that it will often take care of itself after a reboot or running “fsck” in safe mode. Personally, I haven’t had this as an issue before.
I have totally borked an install more than once because I tinkered too much so I just took that as an opportunity to do a fresh install. I’m sure that is not what you want to do but it is a last resort option.
If it helps at all, for systems with lesser storage space, I tend to just use xfs for both root and /home partitions. I’m sure ext4 would work just as well. I’m not as well versed in file systems but I do know that xfs works well and if there is a performance drop as root, I, nor the users I set up with openSUSE and xfs on both have made any complaint about it. They do remark how much faster this “Linux thing” is.
