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

BW-userx · 12-17-2018, 01:55 PM

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

Code:

$ cat /mnt/userx/SizeUsed
Filesystem 1K-blocks Used Available Use% Mounted on 
/dev/root  43451896 41551976  0     100% / 
devtmpfs 8179872 0 8179872           0% /dev 
tmpfs 32768 1356 31412 5%   /run 
tmpfs 8183428 0 8183428 0% /dev/shm
 cgroup_root 8192 0 8192 0%  /sys/fs/cgroup 
/dev/sda7 20905564 9173888 10646596 47% /home
 /dev/sdb1 60307532 14442168 42772168 26% /media/projects
 /dev/sdb2 382968916 198582032 164863508 55%  /media/data1

for the daily double, what is /dev/root ?

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

Richard Cranium · 12-17-2018, 02:40 PM

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

bassmadrigal · 12-17-2018, 02:49 PM

Quote:

Originally Posted by BW-userx

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

Code:

$ cat /mnt/userx/SizeUsed
Filesystem 1K-blocks Used Available Use% Mounted on 
/dev/root  43451896 41551976  0     100% / 
devtmpfs 8179872 0 8179872           0% /dev 
tmpfs 32768 1356 31412 5%   /run 
tmpfs 8183428 0 8183428 0% /dev/shm
 cgroup_root 8192 0 8192 0%  /sys/fs/cgroup 
/dev/sda7 20905564 9173888 10646596 47% /home
 /dev/sdb1 60307532 14442168 42772168 26% /media/projects
 /dev/sdb2 382968916 198582032 164863508 55%  /media/data1

for the daily double, what is /dev/root ?

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

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.)

Code:

du -hxd 1 / | sort -h

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.

BW-userx · 12-17-2018, 02:51 PM

Quote:

Originally Posted by Richard Cranium

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

thanks

Code:

$ ls -l --block-size=M  /mnt/var/log
total 26786M
drwxr-xr-x 2 root root      1M Apr 13  2018 ConsoleKit
-rw-r--r-- 1 root userx     1M Dec 17 08:04 Xorg.0.log
-rw-r--r-- 1 root userx     1M Dec 17 08:03 Xorg.0.log.old
-rw------- 1 root root      1M Nov 28 11:06 btmp
-rw-r----- 1 root root      1M Dec 17 08:02 cron
drwxr-xr-x 2 root root      1M Dec  7 18:58 cups
-rw-r----- 1 root root      2M Dec 17 08:02 debug
-rw-r----- 1 root root      1M Dec 17 08:02 dmesg
-rw-r--r-- 1 root root      1M Dec 17 08:02 faillog
drwxr-xr-x 2 root root      1M Nov 14 08:53 httpd
drwxr-xr-x 2   49    49     1M Sep 20 21:29 icecream
drwxr-xr-x 2 root root      1M Apr 13  2018 iptraf-ng
-rw-r--r-- 1 root root      1M Nov 29 06:35 kdm.log
-rw-r--r-- 1 root root      1M Dec 17 08:02 lastlog
-rw-r----- 1 root root      1M Dec 17 07:58 lxdm.log
-rw-r----- 1 root root      1M Dec 17 07:58 lxdm.log.old
-rw-r----- 1 root root      0M Jun 29  2016 maillog
-rw-r----- 1 root root     12M Dec 17 08:09 messages
drwxr-xr-x 2 root root      1M Nov 15 12:05 nfsd
lrwxrwxrwx 1 root root      1M Nov 15 16:43 packages -> ../lib/pkgtools/packages
drwxr-xr-x 4 root root      1M Sep  6 17:16 pkgtools
-rw-r--r-- 1 root root      1M Dec 17 09:41 pm-powersave.log
lrwxrwxrwx 1 root root      1M Nov 15 16:43 removed_packages -> pkgtools/removed_packages
lrwxrwxrwx 1 root root      1M Nov 15 16:43 removed_scripts -> pkgtools/removed_scripts
drwxr-xr-x 2 root root      1M Nov 26 16:11 sa
drwxr-xr-x 2 root root      1M Nov 28 14:04 samba
lrwxrwxrwx 1 root root      1M Nov 15 16:43 scripts -> ../lib/pkgtools/scripts
-rw-r----- 1 root root      2M Dec 17 08:09 secure
lrwxrwxrwx 1 root root      1M Nov 15 16:43 setup -> ../lib/pkgtools/setup
-rw-r----- 1 root root      0M Jun 29  2016 spooler
-rw-r----- 1 root root  26771M Dec 17 08:09 syslog
-rw------- 1 root root      1M Nov 24 12:02 tallylog
drwxr-xr-x 2   10 root      1M Nov 15 17:29 uucp
-rw-r--r-- 1 root root      1M Dec 17 08:09 wpa_supplicant.log
-rw-rw-r-- 1 root dbus      2M Dec 17 08:09 wtmp

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

BW-userx · 12-17-2018, 03:02 PM

Quote:

Originally Posted by bassmadrigal

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.)

Code:

du -hxd 1 / | sort -h

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.

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

Code:

..........
4.0K    /.cache
4.0K    /.dbus
4.0K    /root
4.0K    /srv
16K     /lost+found
44K     /mnt
68K     /media
260K    /tmp
14M     /bin
24M     /boot
26M     /sbin
27M     /lib64
31M     /etc
301M    /opt
364M    /var
671M    /lib
12G     /usr
13G

bassmadrigal · 12-17-2018, 03:14 PM

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.

Richard Cranium · 12-17-2018, 03:31 PM

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.

BW-userx · 12-17-2018, 04:28 PM

Quote:

Originally Posted by bassmadrigal

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.

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.

BW-userx · 12-17-2018, 04:30 PM

Quote:

Originally Posted by Richard Cranium

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.

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.

BW-userx · 12-17-2018, 04:53 PM

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

Code:

Dec 17 16:49:18 SlackOLatern kernel: [ 6761.755134] CPU2: Package temperature above threshold, cpu clock throttled (total events = 1306461)
Dec 17 16:49:18 SlackOLatern kernel: [ 6761.755135] CPU3: Package temperature above threshold, cpu clock throttled (total events = 1306461)
Dec 17 16:49:18 SlackOLatern kernel: [ 6761.755137] CPU5: Package temperature above threshold, cpu clock throttled (total events = 1306461)
Dec 17 16:49:18 SlackOLatern kernel: [ 6761.755139] CPU4: Package temperature above threshold, cpu clock throttled (total events = 1306461)
Dec 17 16:49:18 SlackOLatern kernel: [ 6761.755141] CPU7: Package temperature above threshold, cpu clock throttled (total events = 1306461)
Dec 17 16:49:18 SlackOLatern kernel: [ 6761.755142] CPU6: Package temperature above threshold, cpu clock throttled (total events = 1306461)
Dec 17 16:49:18 SlackOLatern kernel: [ 6761.755146] CPU0: Package temperature above threshold, cpu clock throttled (total events = 1306461)
Dec 17 16:49:19 SlackOLatern kernel: [ 6762.616105] CPU7: Core temperature above threshold, cpu clock throttled (total events = 517031)
Dec 17 16:49:19 SlackOLatern kernel: [ 6762.616106] CPU6: Core temperature above threshold, cpu clock throttled (total events = 517031)

bassmadrigal · 12-17-2018, 05:49 PM

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.

BW-userx · 12-17-2018, 06:00 PM

Quote:

Originally Posted by bassmadrigal

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.

Code:

....
............
..................              
ove threshold, cpu clock throttled (total events = 1452333)
Dec 17 16:59:18 SlackOLatern kernel: [ 7361.754416] CPU4: Package temperature ab              
ove threshold, cpu clock throttled (total events = 1452333)
Dec 17 17:04:19 SlackOLatern kernel: [ 7662.837951] CPU6: Core temperature above              
 threshold, cpu clock throttled (total events = 615739)
Dec 17 17:04:19 SlackOLatern kernel: [ 7662.837953] CPU7: Core temperature above              
 threshold, cpu clock throttled (total events = 615739)
Dec 17 17:09:41 SlackOLatern kernel: [    0.440277] ENERGY_PERF_BIAS: Set to 'no              
rmal', was 'performance'
Dec 17 17:09:41 SlackOLatern kernel: [    0.440407] ENERGY_PERF_BIAS: View and u              
pdate with x86_energy_perf_policy(8)
Dec 17 17:09:41 SlackOLatern kernel: [    0.460438] mtrr: your CPUs had inconsis              
tent variable MTRR settings
Dec 17 17:09:41 SlackOLatern kernel: [    1.534645] OCFS2 User DLM kernel interf              
ace loaded
Dec 17 17:09:41 SlackOLatern kernel: [    1.568222] Loading Adaptec I2O RAID: Ve              
rsion 2.4 Build 5go
Dec 17 17:09:41 SlackOLatern kernel: [    1.569887] GDT-HA: Storage RAID Control              
ler Driver. Version: 3.05
Dec 17 17:09:41 SlackOLatern kernel: [    1.570041] 3ware Storage Controller dev              
ice driver for Linux v1.26.02.003.
Dec 17 17:09:41 SlackOLatern kernel: [    1.570180] 3ware 9000 Storage Controlle              
r device driver for Linux v2.26.02.014.
Dec 17 17:09:41 SlackOLatern kernel: [    1.906682] ata1.00: supports DRM functi              
ons and may not be fully accessible
Dec 17 17:09:41 SlackOLatern kernel: [    1.910534] ata1.00: supports DRM functi              
ons and may not be fully accessible
Dec 17 17:09:41 SlackOLatern kernel: [    4.932498] ata2.00: supports DRM functi              
ons and may not be fully accessible
Dec 17 17:09:41 SlackOLatern kernel: [    4.938038] ata2.00: supports DRM functi              
ons and may not be fully accessible
Dec 17 17:09:41 SlackOLatern kernel: [    6.751746] ACPI: Deprecated procfs I/F               
for AC is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared
Dec 17 17:09:41 SlackOLatern kernel: [    6.774164] ACPI Warning: SystemIO range              
 0x0000000000000428-0x000000000000042F conflicts with OpRegion 0x000000000000040              
0-0x000000000000047F (\PMIO) (20180810/utaddress-213)
Dec 17 17:09:41 SlackOLatern kernel: [    6.774683] ACPI Warning: SystemIO range              
 0x0000000000000540-0x000000000000054F conflicts with OpRegion 0x000000000000050              
0-0x0000000000000563 (\GPIO) (20180810/utaddress-213)
Dec 17 17:09:41 SlackOLatern kernel: [    6.775314] ACPI Warning: SystemIO range              
 0x0000000000000530-0x000000000000053F conflicts with OpRegion 0x000000000000050              
0-0x0000000000000563 (\GPIO) (20180810/utaddress-213)
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@Dec 17 17:09:41 SlackOLatern kernel: [    0.440277] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'

if you push the scroll bar, you'll see it goes far to the right on the last line.

Richard Cranium · 12-17-2018, 10:50 PM

Quote:

Originally Posted by BW-userx

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.

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.

Richard Cranium · 12-17-2018, 10:53 PM

Quote:

Originally Posted by BW-userx

look down at the bottom more for ^@ and lots of them, what do they mean? I have no idea.

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

BW-userx · 12-18-2018, 07:44 AM

Quote:

Originally Posted by Richard Cranium

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.