slack-current: Boot looping now. : size 100% used, I just ....
 

I have no idea. I updated it yesterday, I have been experiencing lockups, but I have 4 distros on this laptop, and have been running a script that pushes the CPU temps to max. after a while it locks up, I have a different MB, then the original one, that I had no issues with running scripts for re sampling that cause it to run ht, it is an HP and it runs hot because it is an HP.

Anyways, I was in Slack current just piddling around. Then suddenly my terminals stopped working, Eterm, I could not start another one, I tried stratig xterm, nothing, I glanced over at my temps it I was running at 98C with noting that should be making it 98C, I could not get a terminal opened to check ps or top, so I switched ttys, logged in, and top, looked nothing running at 100 or more %, figured I'd just reboot, and see what happens, it got stuck at turning off swap, which I do not have one.

Somewhere in there it started flashing black screen, and writing on the screen, so ended up hard shutting it down by holding my power button until it shut off, then opened up my laptop, redid the heat goop on the gpu. And cpu. Started it back up in slack, and it went into a boot loop.

I got a go back and do it again to see the specifics I suppose. Because I didn't sit there long enoguht to watch it and take them in. I just shut down, and rebooted into VOID to see if I am / was getting the same issue. and no I am not, because I am able to write this.

Mod

back, I just looked and it is the lxdm and a no space left issue????? I just added another 10GB onto / today because it was alrady up to 25+GB and running out at 30GB, Now It has 42.23 GB on / (root) and gparted says 40.9 used.

df when I was on slack said
for the daily double, what is /dev/root ?

/tmp is empty, it gets cleaned out on shut down.

Consider looking inside /var/log to see what's big.

Are you sure /tmp/ was cleaned out this time? If the shutdown procedure couldn't function completely because of a lack of space, it's possible not all of the scripts were run.

Anyway, it's time to go through and see what's taking up your space. I would imagine a good chunk of it would be caches for your SBo utility (I can't remember what you use, either sboui or sbotools) and probably slackpkg. You'll want to find out where your SBo utility stores the source downloads and slackpkg stores its in either /var/cache/packages/ or /var/lib/slackpkg/.

Beyond those two, you can use various disk usage GUIs (I tend to use the one included in krusader) or you can use the du command line program. If you run the following, it will provide you a sorted list by size (smallest to largest) of the folders in your root partition. (The -h prints human readable sizes, the -x prevents it from going onto other mounted partitions, and the -d tells it to keep the output at 1 directory deep... otherwise your prompt gets overrun with the output of all directories and the output gets confusing. The -h on the sort allows it to sort by human readable sizes.)

From there, you can see if any folders stick out as unexpectedly large. I'd expect /usr/ to be large, but if /var/ is large, you likely have some caches of programs that can be cleaned out or some logs that are quite full.

thanks
that syslog looks rather large. Dang I've never experienced that before. 26GB log file.

yes /tmp is and was empty, I seen it emptying out before it locked up on a unmount swap (?) swap something, and I do not have a swap file, or partition on slack, or any of my distros that I added, anyways.

I did find it. it was a 26GB syslog file, I deleted it and I'm back down to 14.27GB / root partition.

I do wonder if that is what was causing my lock ups. Because I still have mouse, and keyboard. I was the open windows I could not gain focus on any longer. I guess I'll find out soon.

just for FYI

Well, you definitely have something filling that logfile up, I would try and move it to a different location so you can have a chance to look through it (and possibly fix whatever is causing the log spam) rather than just deleting it.

And you may want to look into tweaking /etc/logrotate.conf to minimize the chance of this happening in the future.

EDIT: I was too slow in responding for you to try and save the logfile to see what was causing the issue.

As soon as your root filesystem filled up, you wouldn't be able to write anything in /tmp (since it's on the same mount point). Really, once you've used all of your disk space, all bets are off. Unix/linux assumes that there is always room to write something, somewhere; especially in your home directory and /tmp.

That's one reason why I use LVM and put /tmp and /var/log on different logical volumes from the rest of the system.

yeah, I kind of figured that I'd delete this one because even using cat | less and it was still way too much to comb through, then wait and look later. I will take a look at /etc/logrotate.conf , thanks for the info on that.

I don't know LVM, but I know one can still mount the entire file system separately. One partition for each dir if they want to without LVM.

I'd venture to say it is my CPU temp throttling messages, due to lots of resampling, and syslog not being in logrotate.conf

Is your CPU really at 98C? That's over 200F and is *extremely* high for a processor! I would be really worried about burning out my CPU or causing it to fail really early. Personally, I would be shutting down my computer if I saw temps over 60C. I try to have peak temps at 45C or lower. My normal temps are in the low 30s.

NOTE: The above are for CPUs, GPUs tend to run about 5C-15C hotter.

LAPTOP HP it's always ran that hot, and has been throttled down due to it, without innodent , I did burn out my ATI chip using blenderCLI and the ATI chip for rendering, and I watched the heat temps for the GPU on this laptop, then one day I opened a movie off right click in the file manager, that blew up my ATI chip. then everything went dark.

I got a brand new used MO off ebay, which is the one I am using now, a/ATI chip , when I changed it out, I seen just how clogged up my fan exit port was, the fins were clogged really good, even though it felt lke good air flow. SO I figued I fried it due to that. but now I got it cleaned out, and it is now locking up on me.


just a minute ago it happened again, but not a hard lockdown, slowly, the responce time in open windows will go away then stop , I can still move my mouse around, and switch ttys. it is the windows get like they are out of memory to do anything.

Just happened a minute ago.

sO I looked at the syslog, seen it logging the temp thing, then I get this long well, I guress I'll post it now, I went to VOID Linux to see if I can reproduce this effect with re sampling and my temps to see If void locks up too.

Document not valid UTF-8

look down at the bottom more for ^@ and lots of them, what do they mean? I have no idea.
if you push the scroll bar, you'll see it goes far to the right on the last line.

Yep, I used to do that. Kept a piece of paper with my partition layouts (since I RAID1 most of my stuff) in case I had to replace a disk.

It's just a hell of a lot easier to do that with LVM (along with other bennies). I don't have to correctly guess the size that I'll need for my logical volumes since I can always extend them (can't easily do that with partitions). I'd talk about the other bennies, but that's wildly OT.

NUL (ascii 0). Odd that a C library would actually print those out; normally used for end-of-string for a C string.

Funny quirk in Slack Current? I am in VOiD right now trying to reproduce the lock up I get in Slack Current (now) by re sampling until it locks up. Last night I ran it for a hour or two in VOiD and nothing, no Lock up.

Seeing that NULL ^@ in the file tosses a wonder if there is something else going on, is it just Slack Current, because it is Current, (unstable) so it can be a quirk that has popped up. it adds to the many questions why is my laptop now freezing up and not completely, just parts of it.

Running hot like that for hours is a norm with this laptop, and without lock up issues.