Wednesday, 31 January 2018

Overheating Intel Nehalem/Westmere Laptop

If you are using Intel {Nehalem} processor running Samsung motherboard, you may face overheating problem and 'catastrophic shutdown': a term which is scary and in reality, it can be. Loss of data and corrupted filesystems or (hopefully you have backed up last week) corrupted hard drive.

There maybe a easy solution such as disabling turbo boost in the Bios. (Unfortunately, Samsung RF410 doesn't have such easy solution.)

*Digression* If you are booting Windows 10, you can change the 'power options' setting to 'power saver' or 'balanced' mode. Further tweaks include going to 'change advanced power settings' > 'Processor power management':
1) set 'Maximum processor frequency' to a value such as 2000 Mhz (or any value that is lower than your maximum frequency) and,

NB: Do ensure your 'Minimum processor state' is set at 50% or higher if you are running heavy duty program.

2) under 'System cooling policy' select 'passive' for both 'On battery' and 'Plugged in'.

Great, enough for Windows, it is a small digression here to talk about it. Now we shall focus on GNU/Linux, in particular, Fedora 27.

*Lesson Proper* To turn off Turbo boost albeit a temporary solution as the Bios reset it each boot-up, we can run the following as root:

sudo -i
echo 0 > /sys/devices/system/cpu/cpufreq/boost
exit

Alternatively, we can change the Model Specific Register (msr) by:

1) installing 'msr-tools',

sudo dnf install msr-tools

2) enabling the module 'msr' editing the 'turbo' register :

sudo dnf install msr-tools
modprobe msr

3) checking the value of the register individually, a return of '1' means turbo boost disabled and '0' means turbo boost enabled using option '-p#' where #=0,.., number of core - 1:

sudo rdmsr -p0 0x1a0 -f 38:38 
sudo rdmsr -p1 0x1a0 -f 38:38
sudo rdmsr -p2 0x1a0 -f 38:38
sudo rdmsr -p3 0x1a0 -f 38:38

or collectively:

sudo rdmsr -a 0x1a0 -f 38:38

or a return of '4000850081' and '850081' respectively using the following:

sudo rdmsr -x 0x1a0


NB: you may refer the man page of rdmsr online
http://manpages.ubuntu.com/manpages/trusty/man1/rdmsr.1.html

NB: you can refer to Table 2-14 representing "MSRs in Processors Based on Intel® Microarchitecture Code Name Nehalem",  search under 'register address' the 'hex' value of '1A0H' Intel Nehalem Model-Specific Registers (MSRS) and search under 'Register Name' the decimal value of '38', you see 'Bit Description' having the string value of 'Turbo Mode Disable (R/W)' => hence '1' : Disabled; '0' : Enabled
https://software.intel.com/sites/default/files/managed/22/0d/335592-sdm-vol-4.pdf

4) editing the value of the register by pointing the register '0x1a0' to the value '0x4000850081' collectively:

sudo wrmsr -a 0x1a0 0x4000850081

 or individually disable turbo boost on the 1st and 3rd core:

sudo wrmsr -p0 0x1a0 0x4000850081
sudo wrmsr -p2 0x1a0 0x4000850081

NB: you may refer to the man page of wrmsr online
http://manpages.ubuntu.com/manpages/xenial/man1/wrmsr.1.html

5) verify the value at register '0x1a0' which should return '4000850081':

sudo rdmsr -x 0x1a0
 
6) Alternatively, we can verify the 'turbo boost' mode is disabled using 'cpupower' by installing 'cpupower' and checking using option 'cpupower-frequency-info':

sudo dnf install cpupower
cpupower -c all frequency-info

7) Another useful feature of 'cpupower'  is switching of power governor to 'conservative' mode using 'cpupower-frequency-set' option:

cpupower -c all frequency-set -g conservative

8) Alternatively editing sysfs /sys/devices/system/cpu directory:

echo conservative > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor 

9) Setting up a udev rule for permanent setting of 'conservative governor:

i) creating /etc/udev/rules.d/50-scaling-governor.rules with the content:

SUBSYSTEM=="module", ACTION=="add", KERNEL=="acpi_cpufreq", RUN+=" sudo /bin/sh -c ' echo conservative > /sys/devices/system/cpu/cpufreq/policy*/scaling_governor ' "

ii) changing /etc/udev/udev.conf from 'info' to 'debug'

udev_log="debug"

iii) creating /etc/dracut.conf.d/99-udev.conf, noting the style of the text in 'man dracut.conf'

install_optional_items+=" /etc/udev/udev.conf "

iv) update initramfs image using the following for Fedora:

sudo dracut --force

10) To verify the temperature we can use 'lm_sensors' to check the temperature by installing 'lm_sensors-sensord' and 'lm_sensors-libs' and run 'sensors':

sudo dnf install lm_sensors-sensord lm_sensors-libs
sensors 

11) Alternatively, we can check the temperature of the physical processor cores using sysfs /sys/class/thermal directory:

cat /sys/class/thermal/thermal_zone*/temp

The above is hopefully enough to trouble shoot your laptop if you are running Intel Core architecture or Intel Nehalem architecture.

For Sandy bridge and above processor, you are likely to find good company in Thermald for intel_pstate management. For more info, you can refer to the ArchWiki article on "CPU frequency scaling" which has mentioned tools like 'thermald', 'cpupower' and 'i7z'.
https://wiki.archlinux.org/index.php/CPU_frequency_scaling

Follow my blog with Bloglovin

Changing Username on Debian sysvinit or systemd

Sometimes we feel there is a need to change our username on the GNU/Linux for many different reason. It may be easy or difficult depending on your approach.

The easy way out is to boot into recovery as a 'admin priviledged' user and use 'usermod' and 'groupmod' command:

1) usermod -l newusername oldusername
2) groupmod -n newusername oldusername
3) usermod -d /home/newusername  -m newusername

The difficult way (or rather more tedious approach) is to use 'vipw' command:
1) vipw -p (replace "oldusername" with "newusername" and "/home/oldusername" with "/home/newusername")
2) vipw -s (replace "oldusername" with "newusername")
3) vigr -g (replace all entries "oldusername" with "newusername")
4) vigr -s (replace all entries "oldusername" with "newusername")




Tuesday, 23 January 2018

Fixing time on sysvinit and systemd

If you have a system that boot using different GNU/Linux init systems such as sysvinit (aka System 5) and systemd (aka System 500) in addition to proprietary Windows system, you may face incorrect time display on one of the aforementioned system. The difference in time display is dependent on the time difference of your location and the UTC time. Further complication may result from concept like Daylight Saving Time (DST).

If the Bios is set to localtime, you may fix it in systemd boot system using 'timedatectl' command like:
sudo timedatectl set-local-rtc 1

However, if you are using sysvinit and Bios is using localtime, you can set inform the system that local time is being used using 'hwclock' command like:
sudo hwclock --localtime

or to synchronize the hardware clock with system time and inform the system using:
sudo hwclock --systohc --localtime

If Bios is using UTC time, you may revert the change with 'timedatectl' like:
sudo timedatectl set-local-rtc 0

or with 'hwclock' like:

sudo hwclock --utc

or in Windows, we correct time by creating *.reg file to inform system that the hardware clock is using UTC with the following contents:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation] "RealTimeIsUniversal"=dword:00000001


To import the contents into registry, we double click it. Should the registry edit doesn't respond to it on a x86_64 computer, we change the word 'dword' to 'qword' as follows:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation] "RealTimeIsUniversal"=qword:00000001

Should you ever switch between Windows and Linux system, the above command shall help to correct the time change.

Follow my blog with Bloglovin

Sunday, 14 January 2018

Unifi Webgui Repair

Chances are if you run the following setup to harden the Ubiquiti Unifi setup after following instructions at Ubiquiti forum, you are likely to run into problem after each update.

The forum article to harden Unifi setup is here "Linux  Unifi Controller default Debian setup is grossly insecure:

https://community.ubnt.com/t5/UniFi-Feature-Requests/Linux-Unifi-Controller-default-Debian-setup-is-grossly-insecure/idi-p/1752863 

The steps include the following:
1) systemctl stop unifi
2) groupadd unifi
3) useradd -g unifi -s /bin/false -d /dev/null unifi
4) chown -R unifi:unifi /var/log/unifi /var/lib/unifi
5) rm -rf /var/run/unifi
6) cat > /etc/systemd/system/unifi.service.d/security.conf <<EOF
[Service]
RuntimeDirectory=unifi
User=unifi
Group=unifi
PrivateTmp=true
PrivateDevices=true
ProtectSystem=full
ProtectHome=true
NoNewPrivileges=true
EOF
7) systemctl daemon-reload
8) systemctl start unifi


If you run Fail2ban, it probably shows an error and you need to edit the logpath in /etc/fail2ban/jail.local under [ubiquiti] with the 'logpath = /var/log/unifi/server.log'. The Unifi Webgui may fail to run too (but this is likely an isolated issue).
 
Error message that unifi fail to make links to default path to /usr/lib/unifi/data, /usr/lib/unifi/logs, /usr/lib/unifi/run: 

unifi.init[1630]: ln: failed to create symbolic link '/usr/lib/unifi/data': Read-only file system
unifi.init[1630]: chown: cannot access '/usr/lib/unifi/data': No such file or directory
unifi.init[1630]: ln: failed to create symbolic link '/usr/lib/unifi/logs': Read-only file system
unifi.init[1630]: chown: cannot access '/usr/lib/unifi/logs': No such file or directory
unifi.init[1630]: ln: failed to create symbolic link '/usr/lib/unifi/run': Read-only file system
unifi.init[1630]: chown: cannot access '/usr/lib/unifi/run': No such file or directory

unifi[1726]: log4j:ERROR setFile(null,true) call failed.
unifi[1726]: java.io.FileNotFoundException: logs/server.log (No such file or directory)

Run the following commands to link the /var/*/unifi folders to /usr/lib/unifi/* folders:

sudo ln -s /var/log/unifi/ /usr/lib/unifi/logs
sudo ln -s /var/lib/unifi/ /usr/lib/unifi/data
sudo ln -s /var/run/unifi/ /usr/lib/unifi/run

The following error now appears because of the symlink made above using 'ln -s'.

unifi.init[9175]: rm: cannot remove '/usr/lib/unifi/data': Read-only file system
unifi.init[9175]: chown: changing ownership of '/usr/lib/unifi/data': Read-only file system 
unifi.init[9175]: rm: cannot remove '/usr/lib/unifi/logs': Read-only file system
 unifi.init[9175]: chown: changing ownership of '/usr/lib/unifi/logs': Read-only file system
unifi.init[9175]: rm: cannot remove '/usr/lib/unifi/run': Read-only file system
unifi.init[9175]: chown: changing ownership of '/usr/lib/unifi/run': Read-only file system

If the Webgui is not up, it turns out that mongodb.service is not active.


Hence, run :
systemctl restart mongodb.service

If there is problem in setting up the access permissions of the folders or files: it is good to set stricter permission at the downstream level. For example, setting /usr/lib/unifi to 755 where owner has 'rwx' permission, user belongs to a group has 'rw-' permissions and other users not in the group has 'rw-' permission. On the other hand the symlink target of /usr/lib/unifi/data and /usr/lib/unifi/logs may have another set of access permissions, such as setting /var/lib/unifi and /var/log/unifi to 700 where only owner has 'rwx' permission. Going downstream, the permissions settings of /var/log/unifi/server.log may have stricter permissions of 600 where the user has only 'rw-' permissions.

NB: 'r' stands for read access, 'w' stands for write access, and 'x' stands for execute access.

Update 20 March 2018:

With the latest update to 5.7.20-10627:
There is a bug reading  " Cannot open PID file /var/run/unifi.pid ". I managed to fix it by editing  /usr/lib/unifi/bin/unifi.init, specifically changing the following line of PIDFILE:

#originally PIDFILE is directly placed directly under /var/run
#PIDFILE="/var/run/${NAME}.pid"
#now it is edited to include under another layer under ${NAME}
PIDFILE="/var/run/${NAME}/${NAME}.pid"


Follow my blog with Bloglovin

Monday, 1 January 2018

Repairing Fedora Grub using Fedora Live USB

First, Prepare the Fedora Workstation Live CD using Fedora Media Writer.

Next, run the Workstation Live CD and run the console.

Then, enter the following commands if you are running the separate boot and root partition:

1) sudo mount /dev/sdaX /mnt

Note: sdaX is the root partition

2) sudo mount /dev/sdaW /mnt/boot

Note: sdaW is the boot partition

The following files are essential for running the essential processes for repairing grub and shall be mounted:

3) sudo mount --bind /dev /mnt/dev

4) sudo mount --bind /proc /mnt/proc

5) sudo mount --bind /sys /mnt/sys

6) sudo mount --bind /var/run /mnt/var/run

Now, you are ready to go into the Fedora partitions to repair the grub files. The path should be changed to root user from liveuser> to root>:

7) sudo chroot /mnt

If you are running dual boot Windows and Fedora system, the following command will replace the Metro Interface:

8) grub2-install /dev/sda

With a dual-boot or multi-boot systems, the following command probe for operating systems installed on your harddrive:

9) grub2-mkconfig -o /boot/grub/grub.cfg

Now, we should be done with the repair and can proceed to unmount the boot and root partitions and other files.

10) exit

11) sudo umount /mnt/var/run

12) sudo umount /mnt/sys

13) sudo umount /mnt/proc

14) sudo umount /mnt/dev

15) sudo umount /mnt/boot

16) sudo umount /mnt

Finally, we can shutdown and restart to see if it is successful. Sometimes if there is any error message along the way, we need to run this process twice.


Follow my blog with Bloglovin

Experimenting with Archlinux on Legacy Bios system

nano /etc/wpa_suppplicant/wpa_supplicant.conf    ctrl_interface=/run/wpa_supplicant    update_config=1 wpa_supplicant -B -i wlan0 -c /e...