Apple fix low battery warning in iOS Facetime

Noticed this since at least iOS 14 that FaceTime does not warn about low battery when using it in landscape mode. None of the instructions appear (at 20% or 10%). It has not been fixed in the several updates of iOS version 14 and now iOS 15 has already reached 15.2 and the bug still exists! Fix this Apple, this isn't something that is  difficult to fix.

Wemo WSP080 smart plug - how to reset

Playing around with a Wemo WSP080 smart plug (connected in a HomeAssistant+HomeKit Integration on a RaspberryPi Zero W(see note below) and iPhone/Home application for control) recently required a reset as it was not being detected. With just a single button and no documentation in package to reset it, I looked for the procedure on Belkin website. Tried the steps a few times but was unsuccessful. After multiple tries, finally discovered that the documentation has a typo. Here is the correct process:

How to factory restore your Wemo Smart Plug
Step 1: Unplug any devices from your Wemo and then unplug it from the power outlet.

Step 2:  Wait 5 seconds and then hold down the power button on the top of the unit and plug it back in.

Step 3:  Continue to hold the power button down until the status light begins flashing turns solid orange rapidly.  This will take about 5 seconds.

Step 4: Once the status light begins flashing turns solid orange rapidly, release the power button.  Your Wemo will perform a factory restore and reboot.  When the factory restore is complete, the status light will flash orange and white.

Note: It is not recommended to install HomeAssistant on a RaspberryPi Zero W. The installation process requires editing some files on the microSD card so that it can connect to the wireless network when it boots. After booting, it might take up to an hour before it gets ready for you to continue with the configuration in the browser. I suggest to use RaspberryPi 3 or later for the installation.

Upgrading to Debian 11 (bullseye) - sources.list

Debian GNU/Linux 11 (bullseye) was released 14 August 2021. I have upgraded 3 servers to the latest  version and the upgrade experience has been quite smooth. The one thing which is missing from the Debian upgrade instructions is the security updates line for bullseye in sources.list. Normally, you would have the following line in your /etc/apt/sources.list

deb http://security.debian.org/debian-security stretch/updates main

Change it to the following before doing apt update:

deb http://security.debian.org/debian-security bullseye-security main

Ref: Debian 11 Errata

Reduce /boot usage by decreasing initrd image size

 I had noticed that every time there was a new kernel being installed on my Asus EeeBox PC EB1033, it always failed due to lack of free disk space on /boot. The /boot partition is 232 MB in size and it couldn't fit 3 versions of the kernel (Ubuntu 18.04.5 LTS). Earlier, I had used the easy way out of manually uninstalling the older unused kernel and then installing the newer one. In normal circumstances, the newer kernel should get installed and then an apt autoremove should uninstall the oldest kernel (2 kernels are kept). When I noticed that the initrd image files on my Debian Unstable desktop were just 11 MB, I sat down and fixed the issue.

The main problem was that the kernel's initrd image file in /boot was being generated during the install process with all possible modules, even the ones which the hardware or I didn't need.

Before you make any changes, get a list of the modules which are currently loaded on your running system using:

$> sudo lsmod > modulesLoaded.before

and backup your configuration files

$> tar cf initramfs-tools.tar /etc/initramfs-tools

The main changes that are required are in /etc/initrd-tools/initramfs.conf. But as suggested in initramfs.conf manual, the changes will be done in /etc/initrd-tools/conf.d/ directory.

Size of initrd image files before changes

eeepc@eeepc:~$ ls -lh /boot/initrd.img-4.15.0-15*
-rw-r--r-- 1 root root 63M Aug 22 20:42 /boot/initrd.img-4.15.0-153-generic
-rw-r--r-- 1 root root 63M Aug 22 20:43 /boot/initrd.img-4.15.0-154-generic

After adding file loadmods in /etc/initrd-tools/conf.d/  with content MODULES=dep (default is most):

eeepc@eeepc:~$ sudo update-initramfs -u -k 4.15.0-154-generic
eeepc@eeepc:~$ ls -lh /boot/initrd.img-4.15.0-15*
-rw-r--r-- 1 root root 63M Aug 22 20:42 /boot/initrd.img-4.15.0-153-generic
-rw-r--r-- 1 root root 31M Aug 22 20:47 /boot/initrd.img-4.15.0-154-generic

After adding file compression in /etc/initrd-tools/conf.d/ with content COMPRESS=xz (default is gzip)

eeepc@eeepc:~$ sudo update-initramfs -u -k 4.15.0-154-generic
eeepc@eeepc:~$ ls -lh /boot/initrd.img-4.15.0-15*
-rw-r--r-- 1 root root 63M Aug 22 20:42 /boot/initrd.img-4.15.0-153-generic
-rw-r--r-- 1 root root 20M Aug 22 20:50 /boot/initrd.img-4.15.0-154-generic

That gives us a total reduction of 43 MB (68.25%) by using just two options.

Run sudo update-grub to apply changes and restart using the new kernel and compare the list of modules loaded with the original list that we saved before making changes. Check hardware functionality, e.g. video, networking, sound, etc. If you want to load some modules which you need (e.g. msdos, ntfs, etc.), just add the list to /etc/initrd-tools/modules file.

To regenerate the initrd image file for all kernels, use the following command:

sudo update-initramfs -u -k all && sudo update grub

Reference and files:

1. initramfs-tools.conf manual
2. /etc/initramfs-tools/conf.d/ directory
3. /etc/initramfs-tools/modules file

EEEPC fan and sensor data

Recently I had done a fan tuneup for my Asus EeeBox PC EB 1033 and it had been performing quite well with almost no fan noise audible from 8-10 feet. However, while watching an old video the screen suddenly went black and after a few seconds the TV indicated no signal on the input! On checking, I noticed that the PC had shutdown and its case felt quite hot. I started it up again and checked the syslog. It showed multiple occurrences of "CPU0: Core temperature above threshold, cpu clock throttled (total events = 3354588)" and sensors command output showed that CPU temperature was rising.

I shut down the PC and opened it up. Components were still hot, so I cooled them down by blowing compressed air on them. Then I checked the fan and it was difficult to rotate it. Last time I had put some WD-40 on the spindle and it wasn't a good idea. This time I cleaned up the fan spindle and put some lithium grease on it and it was rotating normally again. After the second fan tuneup, the PC was running with normal CPU temperatures (around 50°C). Phew! Critical issue handled.

One thing that I noticed was that the "cpu_fan" indicated 0 RPM speed even though I knew it was running normally. The EeeBox PC EB1033 has an nct6776 chip which does the sensing and even though the modules nct6776 and coretemp were loaded in the kernel, sensors command showed the following:

 ~$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Core 0:       +48.0°C  (crit = +100.0°C)
Core 1:       +48.0°C  (crit = +100.0°C)

asus-isa-0000
Adapter: ISA adapter
cpu_fan:        0 RPM

 Perusing multiple posts regarding lm-sensors behaviour for ASUS motherboards for reporting sensors data, I finally found a post about showing all fans' sensors data. All that was required was adding the following line in /etc/default/grub and then running update-grub.

# This allows fan usage to be read by lm-sensors
GRUB_CMDLINE_LINUX="acpi_enforce_resources=lax" 

The output of sensors command after rebooting the machine:

~$ sensors
asus-isa-0000
Adapter: ISA adapter
cpu_fan:        0 RPM

coretemp-isa-0000
Adapter: ISA adapter
Core 0:       +49.0°C  (crit = +100.0°C)
Core 1:       +50.0°C  (crit = +100.0°C)

nct6776-isa-0290
Adapter: ISA adapter
Vcore:          +1.21 V  (min =  +0.00 V, max =  +1.74 V)
in1:            +1.57 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
AVCC:           +3.39 V  (min =  +2.98 V, max =  +3.63 V)
+3.3V:          +3.38 V  (min =  +2.98 V, max =  +3.63 V)
in4:            +1.83 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in5:            +0.00 V  (min =  +0.00 V, max =  +0.00 V)
in6:            +0.66 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
3VSB:           +3.33 V  (min =  +2.98 V, max =  +3.63 V)
Vbat:           +3.33 V  (min =  +2.70 V, max =  +3.63 V)
CPU Fan:       3835 RPM  (min =    0 RPM)
SYSTIN:         +55.0°C  (high =  +0.0°C, hyst =  +0.0°C)  ALARM  sensor = thermistor
CPUTIN:         +55.0°C  (high = +98.0°C, hyst = +75.0°C)  sensor = thermistor
AUXTIN:         +45.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor = thermistor
PCH_CHIP_TEMP:   +0.0°C  
PCH_CPU_TEMP:    +0.0°C  
PCH_MCH_TEMP:    +0.0°C  
cpu0_vid:      +0.000 V
intrusion0:    ALARM
intrusion1:    OK
beep_enable:   disabled 

Voila! Now I can better monitor the PC hardware in case of abnormal behaviour.

Package required: lm-sensors

NetBackup 9.1 and new services user

Veritas NetBackup® 9.1 was released earlier this month with several new features like full support for backup and restore of Kubernetes, backup anomaly detection using AI/ML, non-privileged user for NetBackup services, etc. You can read about the new features in detail in the NetBackup 9.1 Release Notes guide.

Before an upgrade, it is recommended to perform a catalog backup. The catalog backup generates a DR package and a DR file. In case you are duplicating your catalog backups, which you should, and during the catalog backup if your duplication/SLPs are disabled, the duplication jobs will fail after the upgrade with status: (9202) The service user account does not have the write permissions on the specified path. 

This happens even if you have setup the permissions for the new non-privileged user for NetBackup services properly. Reason being that before upgrade, the catalog backup process created files with root:root privileges and after upgrade, the duplication job tries to update the DR file (.drpkg) with non-privileged credentials and it fails.

Solution: After upgrade, before enabling duplication jobs/SLPs, change ownership of DR file in recovery location to new non-privileged user's username.

Noisy EEPC fan

I have an Asus Eee Box PC 1033 connected to my TV via HDMI and it runs Kodi. Even though I do clean this mini PC regularly, it was making a loud hum since the last couple of days. Thinking it might be getting too hot, I checked the temperature using sensors command it showed normal temperatures.

~$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Core 0:       +49.0°C  (crit = +100.0°C)
Core 1:       +49.0°C  (crit = +100.0°C)

Then I opened up the cover and booted it. Right from the start, the hum was there and as temperature doesn't go up that fast, I focused on the heat sink and cooling fan assembly. I unscrewed the 7 screws (2 each for heat source of the heat-sink, and 3 for fan housing). The fan was a DC Brushless Model KSB0505HB - found in many laptops. After removing the cover on the fan and removing the rotating blades, all that was required was cleaning the axle of the blades and adding some lubrication to it. 

Closed up the fan cover, and screwed the heat sink and fan assembly back in its place. After booting the PC, the hum of the fan was back to normal levels and temperatures were a bit down too as I took the opportunity to put some new thermal paste on CPU and GPU chip.

In case you want to do similar job to your PC fans, a quick YouTube search and review of those videos will help you.