SOLVED - Re: No Desktop every 2nd boot

HighFive · April 29, 2016, 02:35:11 PM

I had a similar problem where Sparky wouldn't boot into the X desktop.

I found that it was due to the / partition had run out of disk space. The problem was that /var/cache/apt was full. I manually deleted all of the files from the apt cache and then it booted up just fine into X.

Edit: Within 2 hours after "fixing" the problem the / (root) partition has run out of space again. Seems like there is a serious memory leak somewhere.

Here's an image of the Disk Analyzer before the desktop crashed:

http://i.imgur.com/90lyYlA.jpg

pavroo · April 30, 2016, 12:36:25 AM

Your root partition is full 21.8 GB - 100% in use.
Uninstall something or move out some files from home directory if you have not a separated home partition.

paxmark1 · April 30, 2016, 12:43:19 AM

HighFive - I did not realize you had taken over a semi-old post. It is better to start a new post. So, some of the comments are to the previous posters, but they would are valid.

1. It is much easier to look at command line output than gui screenshots. Ctl-Shift-C to copy from a terminal and then markup correctly in the text of the message. pastebin commands also work and are the way to give this output in irc. I was not able to readily get any useful data from your screenshot.

2. "ncdu" is the more elegant version of du. It also has a "y/n" option for deleting via typing "d" It is good for finding what is large in /var (or whatever, but for me and a too small / - my size problems are usually in /var). apt-get autoclean is the more conservative way of removing packages and apt-get clean the more aggressive way. aptitude has versions of clean and autoclean also.

3. Certain repetitive errors in systemd can fill up your systemd journal. Investigate with ncdu. If if looks like your journal is "ballooning", there are options in journalctl to look at size. "journalctl --disk-usage" "man journalctl"

For a quick fix of the journal getting too large - journalctl --vacuum-size= can be used. "man journalctl" --vacuum-size=, --vacuum-time=, --vacuum-files= section

To permanently make the journal size smaller - read in "man journald.conf" The "SystemMaxUse=, SystemKeepFree=, SystemMaxFileSize=, SystemMaxFiles=, RuntimeMaxUse=, RuntimeKeepFree=, RuntimeMaxFileSize=, RuntimeMaxFiles=" section.

4. How big is your root "/" system - df will give you that output. Are you using LVM?

5. This is not 1999. There is imho not even one reason to use lilo these days. I do not miss "hal" either. They are deprecated for maybe a decade - others would use much stronger language.

6.. Do LMDE, Sparky and Ubuntu share the same /home ? If so, your "dot files" (.abcetc) could be fighting between the distros.

7. journalctl -b -0 will give you all your logs from your present boot. journalctl -b -1 the previous boot. There might be some clues there. You can run that in Ubuntu, lmde and Sparky. journalctl can use grep in a pipe - very uselful.

"8. 8. 8. I forgot what 8 was for but 9 was for the lost god and 10 was for everything, everything, everything" (Violent femmes - one of my favourite albums from 1984. Sorry about that.)

I have not triple booted in more than a decade. Windows98, Mandrake-Mandriva linux and FreeBSD and that was not easy.

HighFive · May 02, 2016, 07:06:27 PM

Quote from: paxmark1 on April 30, 2016, 12:43:19 AM
HighFive - I did not realize you had taken over a semi-old post. It is better to start a new post. So, some of the comments are to the previous posters, but they would are valid.

Sorry about that, since my problem was similar I thought I would just add my experience to this thread.

Should I start a new thread for further discussion?

I'll wait for an answer before I add more comments.

paxmark1 · May 03, 2016, 03:23:24 AM

paxmark1 is not a moderator. I mentioned it for posting in the future. Some sites are more flexible. Search on the web "necropost"

But, unless a moderator tells you otherwise, just continue.

from wikipedia

QuoteNecroposting

A necropost is a message that revives (as in necromancy) an arbitrarily old thread, causing it to appear above newer and more active threads. This practice is generally seen as a breach of netiquette on most forums. Because old threads are not usually locked from further posting, necroposting is common for newer users and in cases where the date of previous posts is not apparent.

Have you installed ncdu and used it to look around your /var Have you looked at your journal sizes and looked at your journal output via journalctl. Please post code and not screen shots.

journalctl and man pages helped me to fix a very bad situation for a new install of mine today.

Code Select

inxi -Dp                                                                                                                                                                                                                
Drives:    HDD Total Size: 144.2GB (35.5% used) ID-1: /dev/sda model: ADATA_SX900 size: 128.0GB
           ID-2: USB /dev/sdb model: STORAGE_DEVICE size: 16.1GB                                                                                                                                                                             
Partition: ID-1: / size: 9.7G used: 8.3G (91%) fs: ext4 dev: /dev/sda1                                                                                                                                                                       
           ID-2: /home size: 108G used: 40G (39%) fs: ext4 dev: /dev/sda2                                                                                                                                                                    
           ID-3: /media/paxmark/sdhc size: 14G used: 34M (1%) fs: ext4 dev: /dev/sdb1

and after "cd /var" and then typing "ncdu"

Code Select

-- /var ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
. 845.5 MiB [##########] /cache
. 319.7 MiB [###       ] /log
. 239.6 MiB [##        ] /lib
   13.0 MiB [          ] /backups
.   7.1 MiB [          ] /tmp
.  32.0 KiB [          ] /spool
e   4.0 KiB [          ] /opt
e   4.0 KiB [          ] /mail
e   4.0 KiB [          ] /local

Just hit the # button to enclose code.

Video on ncdu Not great, but o.k. It show you how to use ncurses based programs.
https://www.youtube.com/watch?v=GMcac8pS1yE

HighFive · May 03, 2016, 05:52:43 PM

I installed ncdu.

While doing the following tests I was running LMDE2.

Here is a ncdu scan of Sparky's /var directory:

Code Select


--- /media/jcig/14-sparkyroot/var --------------------------------------------------------------------------------------
.  12.9GiB [######### ] /log
. 369.4MiB [          ] /cache
. 359.0MiB [          ] /lib
    2.8MiB [          ] /backups
. 208.0KiB [          ] /tmp
.  64.0KiB [          ] /spool
e   4.0KiB [          ] /opt
e   4.0KiB [          ] /mail
e   4.0KiB [          ] /local
    4.0KiB [          ] /games
@   0.0  B [          ]  lock
@   0.0  B [          ]  run

As you can see, the /var/log directory is huge.

Looking into /var/log, I get:

Code Select


--- /media/jcig/14-sparkyroot/var/log ----------------------------------------------------------------------------------
                        /..                                                                                             
    4.3GiB [##########]  syslog
    4.3GiB [######### ]  kern.log
    4.3GiB [######### ]  messages

So, you can see that something is loading up those logs.

Here's the first several lines of the syslog.

Apr 29 12:04:04 sparky rsyslogd: [origin software="rsyslogd" swVersion="8.16.0" x-pid="693" x-info="http://www.rsyslog.com"] start
Apr 29 12:04:04 sparky systemd-modules-load[209]: Inserted module 'lp'
Apr 29 12:04:04 sparky systemd[1]: Started Remount Root and Kernel File Systems.
Apr 29 12:04:04 sparky systemd-modules-load[209]: Inserted module 'ppdev'
Apr 29 12:04:04 sparky systemd-modules-load[209]: Inserted module 'parport_pc'
Apr 29 12:04:04 sparky systemd[1]: Starting udev Coldplug all Devices...
Apr 29 12:04:04 sparky systemd[1]: Starting Flush Journal to Persistent Storage...
Apr 29 12:04:04 sparky systemd[1]: Starting Load/Save Random Seed...
Apr 29 12:04:04 sparky systemd[1]: Started Flush Journal to Persistent Storage.
Apr 29 12:04:04 sparky systemd[1]: Started udev Coldplug all Devices.
Apr 29 12:04:04 sparky systemd[1]: Started Load/Save Random Seed.
Apr 29 12:04:04 sparky systemd-modules-load[209]: Inserted module 'ecryptfs'
Apr 29 12:04:04 sparky systemd[1]: Started Create Static Device Nodes in /dev.
Apr 29 12:04:04 sparky systemd[1]: Starting udev Kernel Device Manager...
Apr 29 12:04:04 sparky systemd-modules-load[209]: Inserted module 'loop'
Apr 29 12:04:04 sparky systemd[1]: Started Load Kernel Modules.
Apr 29 12:04:04 sparky systemd[1]: Starting Apply Kernel Variables...
Apr 29 12:04:04 sparky systemd[1]: Started Apply Kernel Variables.
Apr 29 12:04:04 sparky keyboard-setup.sh[191]: Setting up keyboard layout...done.
Apr 29 12:04:04 sparky systemd[1]: Started Set the console keyboard layout.
Apr 29 12:04:04 sparky systemd[1]: Reached target Local File Systems (Pre).
Apr 29 12:04:04 sparky systemd[1]: Started udev Kernel Device Manager.
Apr 29 12:04:04 sparky systemd[1]: Starting Show Plymouth Boot Screen...
Apr 29 12:04:04 sparky systemd[1]: Started Show Plymouth Boot Screen.
Apr 29 12:04:04 sparky systemd[1]: Started Forward Password Requests to Plymouth Directory Watch.
Apr 29 12:04:04 sparky kernel: [ 16.596755] ACPI Error: No handler or method for GPE 04, disabling event (20160108/evgpe-790)
Apr 29 12:04:04 sparky kernel: [ 16.596763] ACPI Error: No handler or method for GPE 05, disabling event (20160108/evgpe-790)
[The rest of the log is similar to these last two lines.]

Here's the kern.log ...

Apr 29 12:04:04 sparky kernel: [ 16.596755] ACPI Error: No handler or method for GPE 04, disabling event (20160108/evgpe-790)
Apr 29 12:04:04 sparky kernel: [ 16.596763] ACPI Error: No handler or method for GPE 05, disabling event (20160108/evgpe-790)
[Same thing here, the rest of the log is similar to these two lines.]

And the same lines are in the 'messages' log.

After deleting those three logs, here's a new ncdu scan:

Code Select


--- /media/jcig/14-sparkyroot/var --------------------------------------------------------------------------------------
. 369.4MiB [##########] /cache                                                                                          
. 359.0MiB [######### ] /lib
.   3.4MiB [          ] /log
    2.8MiB [          ] /backups
. 208.0KiB [          ] /tmp
.  64.0KiB [          ] /spool
e   4.0KiB [          ] /opt
e   4.0KiB [          ] /mail
e   4.0KiB [          ] /local
    4.0KiB [          ] /games
@   0.0  B [          ]  lock
@   0.0  B [          ]  run

/var/log is now only 3.4 MiB.

Then I rebooted into Sparky.

I was able to boot up and log into an X session. But within 5 minutes the kern.log,
syslog, and the messages logs were all up to 2.9GB each. I took screenshots
of the logs increasing in size. By this time I was trying to reboot, but Sparky
locked up, and I had to do an Alt>PrintScreen>B to reboot the computer.

I don't know what's causing this, but something is causing the logs to grow so fast that it's impossible to troubleshoot it from inside Sparky.

The specs on my computer can be viewed here: https://www.dropbox.com/home?preview=X140e_specs.txt

paxmark1 · May 04, 2016, 02:02:57 AM

googleing "ACPI Error: No handler or method for GPE 04, disabling event (20160108/evgpe-790"

https://bbs.archlinux.org/viewtopic.php?id=211365 April14

upstream https://bugzilla.kernel.org/show_bug.cgi?id=114811 :Note - April 16th in Siduction - Debian unstable for first poster. Timeline would be about right for it to hit you in Debian testing.

You can search more on your own. What is your kernel _ posting the output of inxi would show that.

BUT the easiest and fastest way to check this out would be to reboot and when grub appears go to advanced options and see if the problem continues with an older kernel.

Also you can search the Debian BTS to see the status in Debian.

peace out

HighFive · May 04, 2016, 07:01:08 PM

Quote from: paxmark1 on May 04, 2016, 02:02:57 AM
googleing "ACPI Error: No handler or method for GPE 04, disabling event (20160108/evgpe-790"

https://bbs.archlinux.org/viewtopic.php?id=211365 April14

upstream https://bugzilla.kernel.org/show_bug.cgi?id=114811 :Note - April 16th in Siduction - Debian unstable for first poster. Timeline would be about right for it to hit you in Debian testing.

You can search more on your own. What is your kernel _ posting the output of inxi would show that.

BUT the easiest and fastest way to check this out would be to reboot and when grub appears go to advanced options and see if the problem continues with an older kernel.

Also you can search the Debian BTS to see the status in Debian.

peace out

Thank you, paxmark1 for your help and troubleshooting lessons.

Here's the inxi output:

Code Select


jcig@lmde2m ~ $ inxi -Cb
System:    Host: lmde2m Kernel: 3.16.0-4-amd64 x86_64 (64 bit) Desktop: MATE 1.14.0  
           Distro: LinuxMint 2 betsy 
Machine:   System: LENOVO product: 20BLCTO1WW v: ThinkPad X140e
           Mobo: LENOVO model: 20BLCTO1WW Bios: LENOVO v: GSET60WW (2.05 ) date: 04/25/2014
CPU:       Quad core AMD A4-5000 APU with Radeon HD Graphics (-MCP-) cache: 8192 KB 
           Clock Speeds: 1: 800 MHz 2: 1500 MHz 3: 800 MHz 4: 800 MHz
Graphics:  Card: Advanced Micro Devices [AMD/ATI] Kabini [Radeon HD 8330]
           Display Server: X.Org 1.16.4 drivers: ati,radeon (unloaded: fbdev,vesa)
           Resolution: 1366x768@60.02hz
           GLX Renderer: Gallium 0.4 on AMD KABINI GLX Version: 3.0 Mesa 10.3.2
Network:   Card-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller driver: r8169
           Card-2: Broadcom BCM43228 802.11a/b/g/n driver: wl
Drives:    HDD Total Size: 500.1GB (6.1% used) 
Info:      Processes: 183 Uptime: 1 day Memory: 1168.6/3165.8MB Client: Shell (bash) inxi: 2.1.28 
jcig@lmde2m ~ $

I'll check out the kernels later.

Thanks for your help,
Cheers

paxmark1 · May 05, 2016, 01:13:00 AM

Yes, I see you have an AMD processor as in arch and bugzilla posts. So using a 4.3 kernel (if you still have it) would help diagnose and the "modprobe.blacklist=sp5100_tco" might fix.

I am not telling you to do this. I merely skim the surface of issues that do not affect me. Enjoy.

HighFive · May 05, 2016, 01:23:59 AM

Problem is, I don't know how I could do this. If I boot up Sparky, by the time I could even check out the kernels available, the "/" partition would be 100% full and the system would become unusable. It's way beyond my expertise and patience to ssh into the OS and try to fix it. So, I guess Sparky is out for me, at least for a while. :(

Wombat · May 05, 2016, 03:31:45 AM

You need to boot using any live disk and delete the contents of the log file that is filling up -- the file's name could enable you to identify your specific problem.
If it is uvcdynctrl-udev.log then it could be an attached web cam.

HighFive · May 05, 2016, 07:41:25 PM

I still had a 4.2 kernel installed, booted that up and everything's okay now.

HighFive · May 11, 2016, 06:01:30 PM

Did a system update today. I noticed that "linux-image-4.5.0-2-amd64:amd64" was installed. During the reboot I selected that kernel (instead of the 4.2 kernel) to see what would happen. The problem of the system logs ballooning seems to be fixed. It's been running on that kernel now for 48 minutes, no problems so far. This is just wonderful, within days a serious problem is fixed and a new kernel released!

How long would it take M$ to do that?

By the way, I have no ill feelings at all towards Sparky for this hiccup. That's just the way it goes. :)

paxmark1 · May 12, 2016, 12:42:07 AM

Please mark as SOLVED: via editing the subject line if you believe it solved.

https://bugzilla.kernel.org/show_bug.cgi?id=114811 has it listed as solved. Peace out.

HighFive · May 12, 2016, 01:24:24 AM

I cannot change the original post.