This week I got myself a new laptop, a Thinkpad T540p. One of the features it has is that the battery’s life can be prolonged by setting custom charging thresholds.

The start charge threshold tells the battery to start charging only when the charge drops bellow that limit, and the stop charge threshold tells the battery to stop the charging when the upper limit is reached. I set the start threshold to 40% and the stop threshold to 70%. I think this should be good enough for me as I mainly use my laptop at home where it’s always plugged in.

After a bit of a digging around, I managed to get it working under Fedora 21.

The main thing to know is that there is tp_smapi for older Thinkpad’s, and tpacpi-bat for the newer ones. I have a T540p so it’s the latter for me.

There is also tlp, but at the moment I couldn’t get it to work completely because it has no packages for Fedora 21 yet. Fedora 20/19 should be OK though, and for those I would probably go with tlp.

After git cloning the repository, run the install perl script, and if all went OK, set the start threshold like:

./tpacpi-bat -s ST 1 40

and the stop threshold:

./tpacpi-bat -s SP 1 70

Where 1 is the battery number, starting from 1, and 40 and 70 are the start and the stop thresholds in percentage.

These settings should remain after a reboot, but what I noticed is that they are gone after taking out and putting the battery back in. When I tried to set the threshold parameters again, I couldn’t do it as the system was complaining about the missing acpi_call kernel module. I re-run the perl install script from tpacpi-bat and got it working again.

I’ll be on the lookout for the tlp packages for Fedora 21, that looks like it would work nicer than this.

Now the only last bit I’m missing is the battery cycle count, but seems current kernels don’t support it yet.

This one was a bit weird and needed some figuring out. Xdebug profiler output files were not being generated in the /tmp directory.

I wanted to do some profiling with xdebug. I set all the necessary configuration settings in my php.ini, restarted apache, confirmed xdebug is present and configured correctly with php -i | grep xdebug, appended ?XDEBUG_PROFILE=1 aaaand! Nothing. Nothing in /tmp, the default profiler output directory. Double checked paths, permissions, nope, nothing. No profiler files were generated.

find /tmp -name "cachegrind*"

listed the files in

/tmp/systemd-httpd.service-X9iE20R/tmp/

What the?

Apparently systemd services in Fedora can have this setting called PrivateTmp and services with this setting set to true are started with a private /tmp directory. Something something security.

Well then. I created a /var/log/xdebug directory, changed the owner to apache and set the xdebug.profiler_output_dir to that new directory and all is well again.

Hey, I learned something new today.

I am running Fedora 17 on my laptop, and yesterday there were some packages to update. Nothing unusual, updates on Fedora are quite frequent and, up until yesterday, there was not a single problem I remember with any update. And it was a small update, four packages in total. What could possibly go wrong, right?

After a reboot an odd thing happened. My laptop did not automatically connect to the wifi. Huh. So I clicked on the little network manager icon to pick the wifi. The list of scanned wifis was empty. Not a single network on the list. Then I did all the usual things one could do in a situation like this - turn on/off the wifi via the network manager, turn on/off the wifi via the keyboard shortcut, reboot the laptop a couple of times. Still nothing. At this point I started panicking.

I started suspecting the update. But I have no idea what packages were actually updated, what those packages do, or how I could see what packages were updated. After a bit of a googling from my phone, the answer was yum history. Apparently, this command will list recent changes to the system done by yum. Each change has a Transaction ID. More information about each change can be get with yum history info TID, where TID would be the transaction ID of the change you’re after. That will nicely list when did the change occur, which user made the changes, and what packages were affected in what way by that change.

One package caught my eye, called crda. It was updated from version 1.1.2 to 1.1.3. Google told me that crda has something to do with wireless. So, that was probably the culprit of my broken wireless. I started searching for possible bugs for this, or maybe even a workaround or a fix, but to no avail. I am not really good at debugging things like this, so I started looking for a way to somehow revert the update to this package and hopefully fix my wireless problems.

Yet again Google was involved and yet again yum history came to rescue. Apparently, besides tracking changes to the packages, it can also undo these changes: yum history undo TID, where TID is the ID of the transaction you want undone. It will try to undo changes to all packages, and in my case, it failed to undo some (hi Java!), but the crda package was reverted back to version 1.1.2 and after another reboot, the wireless was up and running once again, like nothing happened.

Yey for yum!

I have submitted a bug to Fedora’s bugzilla to hopefully figure out what went wrong and help the developers find a fix for this.

Decided today to upgrade my laptop to Fedora 16, which was released a few days ago. I first switched to Fedora (with XFCE as the desktop environment) from Ubuntu in August, I think. An excellent decision as it is working really great for me. XFCE is also great, really happy that I made this switch.

Anyway, the upgrade from Fedora 15 to 16 went smoothly (although a bit slow, thanks to my shitty internet connection), using the PreUpgrade script/process. I was a bit sceptical about doing an upgrade and not a cleanstall, but gave it a shot after all (note: every time I tried a dist-upgrade with Ubuntu it failed miserably). PreUpgrade was downloading stuff for a bunch of hours and (about) an hour of installing them, the upgrade was… Done. Fedora 16 just booted up and I was using my laptop just as before.

I did the post upgrade steps from the above linked article, but the yum distro-sync step failed; it was complaining something about a “Transaction Check Error” for a libdvdcss package. I simply disabled the rpm.livna.org software source, re-run the distro-sync, it did it’s thing and then re-enabled the source.

The second thing that “wasn’t working” is that Apache and MySQL were not starting on bootup, so I ran chkconfig for both of ‘em:

$ chkconfig --levels 235 mysqld on
$ chkconfig --levels 235 httpd on

Lastly, grub was upgraded to grub2. It was working fine, just that it was showing the grub menu on startup, which is a bit silly given that I’m running only one OS on this machine. Anyway, added the following lines to /etc/default/grub:

GRUB_DISABLE_RECOVERY=true
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=0 # I actually edited this line, from 5 to 0

and ran:

$ grub2-mkconfig -o /boot/grub2/grub.cfg

I also thought for a while that there was an issue with my wifi, that it’s dropping connection randomly, but it only happened once, so I don’t know what to do with it.

Happy hackin’!