Disabling upowerd on a Desktop Linux computer that never actually had a battery.

One of the facts which I’d like to make sure the reader knows, is what, exactly, the process ‘upowerd’ is responsible for on any Linux computer, lest the reader disable something that he or she may really need.

Many computers, including laptops, have batteries. ‘upowerd’ is the Linux process that monitors the battery, or the batteries, in case there is more than one to monitor. If the computer has batteries to monitor, then this process is essential and should not be disabled. But, in certain specific other cases, this process can become a problem, as it recently was on my desktop computer named ‘Phosphene’, which is running Debian 9 / Stretch, which has Plasma 5.8 as its desktop manager, and which will only ever run on A/C power, due to the very way in which its hardware is designed.

Several months ago, I noticed that the ‘North Bridge’ of this computer – an essential chip on its motherboard – was becoming rather hot. And the motherboard in question, the ‘Sabertooth X58′, manufactured in the year 2011, was already famous for the design flaw that causes its North Bridge to become 76.5⁰C hot when idle, which is actually hotter than the GPU on that computer will normally become, when pressed to work hard. Several Months ago, the North Bridge temperature when idle was 80⁰C or even 81⁰C! Whether it’s actually safe for a chip to be that hot is a subject open to opinion. This temperature will not cause an immediate failure, but if the chip is so hot continuously, then its lifespan will become shorter, than what the lifespan of chips is supposed to be, in general.

Therefore, months ago, when I first noticed this, I opened up the tower / desktop computer and examined it, to look for failed cooling fans, etc. There was no such cause for the elevated NB temperature. Not being able to remedy the problem, I just left it that way.

But only yesterday, I noticed that the process ‘upowerd’ was consuming an inordinate amount of CPU time. On the octa-core machine, that process was consuming maybe 1% of available CPU time, which was quite a lot, considering that there should have been nothing for it to do. And, never having noticed this before, it seemed possible to me that ‘upowerd’ may have been consuming 1% of available CPU time (unnoticed), since months ago.

When ‘upowerd’ misbehaves in this way, sometimes this happens, because of hardware signals, such as perhaps, a battery which continuously disconnects and reconnects, etc… Therefore, before a software kludge is attempted, all possibilities need to be followed, to find hardware causes for this behaviour, to which ‘upowerd’ would simply be responding in a normal fashion. Yet, even given hardware reasons to be active, ‘upowerd’ should not be consuming much more than 1% of available CPU time, in case the reader has some situation where this process is consuming, say, 10% of the CPU.

Continue reading Disabling upowerd on a Desktop Linux computer that never actually had a battery.

File System Corruption !

I use a home-computer as my Web-host, which I named ‘Phoenix’. This was actually a computer built in 2008, and is one of the oldest still working for me. So far it has continued to work reliably.

Until several years ago, this computer was actually named ‘Thunderbox’, and was running Kanotix / Thorhammer. But I when I wiped it completely and installed Kanotix / Spitfire on it, I not only renamed it, but rebuilt its software from zero.

What just happened to me today on ‘Phoenix’, is that I fired up a routine K3b -session, in order to back up some music from Audio CDs which I had actually purchased in the 1980s, and that the GUI application showed me a message saying that it could not locate the utility named ‘dvd+rw-tools’ ; I should try installing the package (even though it’s a dependency and was installed.) After I reinstalled that package, K3b told me that it could not locate ‘cdrdao’ (even though it’s a dependency and was installed). I needed to reinstall that as well, after which I explicitly needed to tell K3b to rescan the hard-drive, to find all its back-end utilities again.

Because on this computer I had never customized the back-end utilities which K3b uses – unlike what I had done on ‘Klystron’ – and, because I had never changed the variables in question, this actually points to file-system corruption. I had last used K3b on ‘Phoenix’ several months ago, and with no error messages or warnings. Further, those utilities were among the first packages I ever installed, when I resurrected this computer as ‘Phoenix’, and the idea that the oldest data on the hard drive, would be the first data forgotten, even though never deleted, is also consistent with file-system corruption.

Usually, I’d expect FS corruption to stem from power outages. But we haven’t had a power-outage in a long time, and the last time we did, the Extension 4 File-System on the machine just seemed to repair itself correctly. Because Ext4 is such a tightly-meshed file-system, the report that it has been repaired, can be believed. If it was not repaired on boot, the computer would refuse to boot.

And so, even though this is not typical, I’d say that in this case, the FS corruption is actually secondary, to the fact that the actual Hard-Drive is aging, and has caused some I/O errors. We only get to see I/O error messages, if we’re running something from the command-line; I believe that when we’re running a GUI application, those just stay buried in a system log somewhere.

But what this seems to spell, is that eventually – sooner than later – ‘Phoenix’ will die completely, and this time, there will be no resurrecting her, because the problem will be in the hardware and not in the software.

(Update 1/16/2018 : But. there’s another possible explanation… )

Continue reading File System Corruption !

New Potential in my Galaxy Tab S.

As I wrote in this earlier posting, I believe that my ancient Galaxy Tab S First Generation (Android) tablet has finally bit the dust, due to File System Corruption.

This is not just due to the wonky behavior following the latest hard-boot (during a routine software-update no less), but also because over the years, the amount of free memory on it has become very small, even though I have uninstalled most of the apps that were once installed on it. Typically, failure to reclaim unused space, is one of the earliest signs of FS corruption.

Depending on how one looks at it, visualizing this as a terminally-crashed tablet can have its upside, especially since my needs for a stock Android tablet are met in my ownership of a Pixel C. What this actually means is that I can regard the present installation on the Tab S as expendable, which means that eventually, I’d be able to experiment with it as I wish. For example, I might eventually want to root the Tab S, or install Linux on it…

But one fact which I seem to gather after some reading, is that even to install Linux on Android-capable H/W, does not take place as it does with PCs, where the Linux system is the only running O/S. Instead, Android-capable H/W seems to require that one way or another, we install Linux alongside Android. Thus, unless I get Android working again on the tablet first, I also wouldn’t be able to get Linux working on it.

Further, rooting an Android device does not (necessarily) cause the firmware to be flashed. Instead, if we want to flash the firmware, this is a separate operation which can also be done.

Long story short, whether I’ll ever be able to resurrect that tablet, depends on how it’s partitioned, and in which partitions I suspect the FS corruption has hit.

For example, if I just root, then the data and apps on the ‘/sdcard’ will not even be affected, and if that’s where the FS corruption was, the FS corruption will just stay there. The similar effect would take place, if I was to flash a custom ROM Image on the device, which would affect the ‘/system’ partition and/or the ‘/boot’ partition, but not affect the ‘/sdcard’ .

I would strongly suspect that the FS corruption is on the ‘/sdcard’ , especially since I wasn’t updating the O/S, when the latest crash took place. And what that would seem to suggest, is that my next step should actually be, just to perform a factory reset: The simplest advice sometimes given! That should reset the ‘/sdcard’ , and the ‘/data’ partition, mainly.

If that causes the tablet to become stable again, Then I could proceed next, to root, to install Linux, etc., etc., etc.. Or, I could just recommence with Android, with more reclaimed memory, and with a stable tablet…

Dirk

 

My Galaxy Tab S has just Succumbed to File System Corruption.

One fact which had remained a reality in my life, was that I still owned a Samsung Galaxy Tab S, First Generation (Android Tablet). This mere fact was actually what prompted me to acquire a Pixel C Tablet some time ago, since we must eventually plan for the failure of old technologies.

At the same time I’ve mentioned the subject often, that when a computer is interrupted from running, so that it needs to reboot, but without having been given proper shutdown instructions, or without otherwise having carried out an orderly shutdown, this is known as a Hard Boot, and it can lead to File System Corruption. Actually, every Hard Boot is a File-System Event, which the drivers for the mass-storage device try to resolve to the best of their ability.

The way in which the mass-storage drivers typically repair FS corruption, is just to delete whatever file-fragments, whose meta-data is inconsistent, until the File System is consistent again. In some cases, critical files can end up just missing.

Well it just happened to me today, that my Samsung Tab S underwent a Hard Boot, and that unlike the previous times, this time it led to severe File System Corruption. This has left my Tab S in a state where it cannot be used anymore, and since other Computer Experts do not know about the existence of File System Corruption, I see no way to make that old tablet operational again.

That old tablet, sadly, must now go into my Tablet Graveyard. It has served me well until this morning, but is essentially a lost cause now, just as my Toshiba Thrive was, years ago. May the tablet be remembered for good deeds.

Dirk