Ubuntu 18.04 on ThinkPad P50 (Part 1)

I am moving to a ThinkPad P50 from my W530 and decided to document the steps of preparing a 18.04 box which complies with our corporate policies. The first step is to enter firmware setup and go through the setting, then boot into a 18.04 LiveUSB and erase the preinstalled closed source OS. What follows is the custom LUKS/LVM disk setup done before running the installer, then running the installer itself, finally, a few extra steps which in themselves are simple but will cause head-scratching if skipped...

LUKS/LVM setup from the terminal

The terminal history should be self-explanatory for those who have followed up earlier posts, so rather than explaining each and every command in detail, I decided to just dump the exact commands and their output that was used to prepare the disk before running the installer.

To run a command as administrator (user "root"), use "sudo ".
See "man sudo_root" for details.

ubuntu@ubuntu:~$ sudo gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.3

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): p
Disk /dev/sda: 1000215216 sectors, 476.9 GiB
Model: SAMSUNG MZNLN512
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 126AD2BA-4B0A-45B8-97D0-845A43DDD3C7
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 1000215182
Partitions will be aligned on 2048-sector boundaries
Total free space is 2669 sectors (1.3 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          264191   128.0 MiB   EF00  EFI system partition
   2          264192         2099199   896.0 MiB   8300  BOOT
   3         2099200      1000214527   475.9 GiB   8300  SYSTEM

Command (? for help): q
ubuntu@ubuntu:~$ cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1      1466539 iterations per second for 256-bit key
PBKDF2-sha256    1688528 iterations per second for 256-bit key
PBKDF2-sha512    1322290 iterations per second for 256-bit key
PBKDF2-ripemd160 1052787 iterations per second for 256-bit key
PBKDF2-whirlpool  771011 iterations per second for 256-bit key
argon2i       6 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id      6 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
#     Algorithm | Key |  Encryption |  Decryption
        aes-cbc   128b  1033.7 MiB/s  3213.1 MiB/s
    serpent-cbc   128b    86.0 MiB/s   660.5 MiB/s
    twofish-cbc   128b   191.6 MiB/s   359.0 MiB/s
        aes-cbc   256b   801.6 MiB/s  2593.6 MiB/s
    serpent-cbc   256b    87.3 MiB/s   659.5 MiB/s
    twofish-cbc   256b   193.8 MiB/s   359.4 MiB/s
        aes-xts   256b  1959.5 MiB/s  1959.9 MiB/s
    serpent-xts   256b   635.3 MiB/s   651.2 MiB/s
    twofish-xts   256b   352.8 MiB/s   354.6 MiB/s
        aes-xts   512b  1819.2 MiB/s  1823.0 MiB/s
    serpent-xts   512b   638.8 MiB/s   650.9 MiB/s
    twofish-xts   512b   353.7 MiB/s   355.1 MiB/s

ubuntu@ubuntu:~$ sudo cryptsetup -c aes-xts-plain64 -s 512 -h sha512 luksFormat /dev/sda3

WARNING!
========
This will overwrite data on /dev/sda3 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter passphrase for /dev/sda3: 
Verify passphrase: 
ubuntu@ubuntu:~$ sudo cryptsetup luksOpen /dev/sda3 sda3_crypt
Enter passphrase for /dev/sda3: 
ubuntu@ubuntu:~$ ll /dev/mapper
total 0
drwxr-xr-x  2 root root      80 Apr 26 18:02 ./
drwxr-xr-x 21 root root    4520 Apr 26 18:02 ../
crw-------  1 root root 10, 236 Apr 26 17:44 control
lrwxrwxrwx  1 root root       7 Apr 26 18:02 sda3_crypt -> ../dm-0
ubuntu@ubuntu:~$ sudo pvcreate /dev/mapper/sda3_crypt 
  Physical volume "/dev/mapper/sda3_crypt" successfully created.
ubuntu@ubuntu:~$ sudo vg
vgcfgbackup    vgconvert      vgextend       vgmknodes      vgs
vgcfgrestore   vgcreate       vgimport       vgreduce       vgscan
vgchange       vgdisplay      vgimportclone  vgremove       vgsplit
vgck           vgexport       vgmerge        vgrename       
ubuntu@ubuntu:~$ sudo vgcreate system /dev/mapper/sda3_crypt
  Volume group "system" successfully created
ubuntu@ubuntu:~$ sudo lvcreate -n root -L 32G system
  Logical volume "root" created.
ubuntu@ubuntu:~$ ll /dev/mapper
total 0
drwxr-xr-x  2 root root     100 Apr 26 18:16 ./
drwxr-xr-x 22 root root    4560 Apr 26 18:16 ../
crw-------  1 root root 10, 236 Apr 26 17:44 control
lrwxrwxrwx  1 root root       7 Apr 26 18:16 sda3_crypt -> ../dm-0
lrwxrwxrwx  1 root root       7 Apr 26 18:16 system-root -> ../dm-1
ubuntu@ubuntu:~$ sudo lvcreate -n home -l 100%FREE system
  Logical volume "home" created.
ubuntu@ubuntu:~$ ll /dev/mapper
total 0
drwxr-xr-x  2 root root     120 Apr 26 18:16 ./
drwxr-xr-x 22 root root    4580 Apr 26 18:16 ../
crw-------  1 root root 10, 236 Apr 26 17:44 control
lrwxrwxrwx  1 root root       7 Apr 26 18:16 sda3_crypt -> ../dm-0
lrwxrwxrwx  1 root root       7 Apr 26 18:16 system-home -> ../dm-2
lrwxrwxrwx  1 root root       7 Apr 26 18:16 system-root -> ../dm-1

Running the installer

Once with the steps above, run the installer, and select partitioning option "something else". Just map code>BOOT, code>ROOT and code>HOME to the appropriate partition and logical volumes. Once the installer has run to completion, do not reboot, but return to the terminal.

Post installation steps

Unfortunately, installing Ubuntu this way would leave you with an unbootable system. The kernel itself and the initial ramdisk are located in the unencrypted BOOT partition. The initial ramdisk needs to be rebuilt in a way that it will be able to open the encryted LUKS volume and mount the logical volumes within it, the installer currently does not do that for us. The missing steps are editing one line in two files each, then running one command. The list of commands below puts these steps into context, starting with mounting the required file systems and entering a chroot from within which the few steps have to be carried out.

ubuntu@ubuntu:~$ sudo mount /dev/mapper/system-root /mnt
ubuntu@ubuntu:~$ sudo mount /dev/sda2 /mnt/boot
ubuntu@ubuntu:~$ sudo mount --bind /dev /mnt/dev
ubuntu@ubuntu:~$ sudo chroot /mnt
root@ubuntu:/# mount -t proc proc /proc
root@ubuntu:/# mount -t sysfs sys /sys
root@ubuntu:/# mount -t devpts devtps /dev/pts            
root@ubuntu:/# blkid /dev/sda3
/dev/sda3: UUID="01c3aa4e-5ed1-4ed7-9394-9c2ef3d85922" TYPE="crypto_LUKS" PARTLABEL="SYSTEM" PARTUUID="8b5f0ba1-c0e3-4072-91c3-b9c79ec4d8a8"
root@ubuntu:/# nano /etc/crypttab
root@ubuntu:/# cat /etc/crypttab
sda3_crypt UUID=01c3aa4e-5ed1-4ed7-9394-9c2ef3d85922 none luks,discard
             
root@ubuntu:/# nano /etc/cryptsetup-initramfs/conf-hook # set CRYPTSETUP=Y
root@ubuntu:/# grep ^CRYPTSETUP=  /etc/cryptsetup-initramfs/conf-hook
CRYPTSETUP=y
root@ubuntu:/# update-initramfs -c -k all
update-initramfs: Generating /boot/initrd.img-4.18.0-18-generic
W: Possible missing firmware /lib/firmware/nvidia/gv100/sec2/sig.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/sec2/image.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/sec2/desc.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/nvdec/scrubber.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/sw_method_init.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/sw_bundle_init.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/sw_nonctx.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/sw_ctx.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/gpccs_sig.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/gpccs_data.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/gpccs_inst.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/gpccs_bl.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/fecs_sig.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/fecs_data.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/fecs_inst.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/fecs_bl.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/acr/ucode_unload.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/acr/ucode_load.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/acr/unload_bl.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/acr/bl.bin for module nouveau
update-initramfs: Generating /boot/initrd.img-4.18.0-15-generic
W: Possible missing firmware /lib/firmware/nvidia/gv100/sec2/sig.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/sec2/image.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/sec2/desc.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/nvdec/scrubber.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/sw_method_init.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/sw_bundle_init.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/sw_nonctx.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/sw_ctx.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/gpccs_sig.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/gpccs_data.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/gpccs_inst.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/gpccs_bl.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/fecs_sig.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/fecs_data.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/fecs_inst.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/fecs_bl.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/acr/ucode_unload.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/acr/ucode_load.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/acr/unload_bl.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/acr/bl.bin for module nouveau
root@ubuntu:/# # ignore the warnings above
root@ubuntu:/# exit
exit
ubuntu@ubuntu:~$ # done

Once done, the system can be rebooted and the first steps of configuring the freshly installed Ubuntu 18.04 can be processed. These will be covered in the upcoming posts.

Java Web Start with IBM Java 8 on Ubuntu Linux

Java Web Start

Java Web Start is a framework that allows running java application straight from the network, however, unline applets, these application do not run inside your browser. Java Web Start applications run in a sandbox similar to Java applets, but do not rely on browser plug-ins. A JNLP (which stands for Java Network Launch Protocol) launcher file allows launching an application on the client desktop using resources (e.g. jar files) hosted on a web servers.

From the command line

The launcher file (or a URL pointing to the it) is passed to the javaws command. Subtle details like signatures, permissions (java.policy) and java security settings (ControlPanel) need to be correctly configured.

Using a Java Runtime that is not part of the Linux distro, or not even installed via the package manager is not complicated. Just make sure you invoke the correct javaws binary via symlinks/alternatives or just specifying the file path of the binary rather than relying on the PATH environment variable.

From the GUI

Rather than tinkering with system global settings, I just created a desktop launcher file ~/.local/share/applications/ibmjava8-javaws.desktop with the following content:

[Desktop Entry]
Name=IBM Java8 Java Web Start
Comment=IBM Java8 Java Web Start
Exec=/usr/lib/jvm/java-ibm-x86_64-80/jre/bin/javaws %u
Terminal=false
Type=Application
Icon=javaws
Categories=Application;Network;
MimeType=application/x-java-jnlp-file;
NoDisplay=true

Once done, I downloaded a .jnlp file, saved it to /tmp, right clicked it in nautilus file manager, and ensured it will be opened via the freshly created desktop laucher for IBM Java8 by default.

From the browser

After carrying out the previous steps, clicking a link to a .jnlp file on a web page will - depending on your browser settings - just launch Java Web Start (which will typically show signer information and prompt you for confirmation) or offer you to either save the file to disk to open it via IBM Java8 Java Web Start. That is all it takes.

Ubuntu 14.04 on Lenovo ideapad 100-14IBY (Part 3)

This is the third post on the same topic, part 1 covers hardware details and issues I encountered with the ideapad while part 2 covers the main steps to resolve the most critical issues. This post covers further improvement to the WiFi stability issue.

WiFi stability improvements

The RTL8723be was always disconnecting after a few minutes of operation in the beginning. This issue has been largely improved by disabling hardware encryption, as described in the previous post. Due to the lack of time for more extensive testing, I settled with these settings and asked for a week of test drive. Feedback was that after the WiFi card still disconnected after a couple of hours.

I intuited that the network disconnect could have probably been experienced after a longer period of network inactivity (having left the ideapad on it's own), which led me to the dig into settings around power management of the WiFi card.

Having read up on the topic and after initial trial and error I settled with adding two further module parameters, one for disallowing the firmware to control link power saving, and another one for disabling link power saving in general.

echo "options rtl8723be swenc=1 fwlps=0 ips=0" | sudo tee /etc/modprobe.d/rtl8723be.conf

sudo modprobe -rv rtl8723be
sudo modprobe -v rtl8723be
# confirm parameter values under /sys/module/rtl8192be/parameters

Feedback so far confirmed the current configuration is not prone to getting disconnected. After the holidays I will attempt to narrow down the set of required parameters, first by re-enabling hardware encryption, then experimenting with the two new parameters.

Ubuntu 14.04 on Lenovo ideapad 100-14IBY (Part 2)

Following up on the first part, this post will cover issues I experience after installing Ubuntu 14.04 and the steps I took to investigate them. The following issues immediately caught my attention:

• WiFi connection dropped - no WiFi until reboot
• Returning from flight mode leaves WiFi disabled - or at least unusable
• Suspend/resume does not work - stuck at a black screen
• Reboot and shutdown need the physical power button to be pressed
• Brightness control buttons inverted - "up" will dim the backlight and vice versa

WiFi stability issues

The lspci output from the first part shows that the ideapad is equipped with a RTL8723be WiFi card. Googling revealed others has similar issues which could be dodged or at least significantly improved by disabling hardware encryption.

cat <<EOF | sudo tee /etc/modprobe.d/rtl8723be.conf
options rtl8723be swenc=1
EOF

In order for the changes to take effect, one either has to reboot or remove and then probe the kernel module. With this change applied, WiFi seemed much more stable, entering and returning from flight mode worked just fine, and occasional WiFi issues could be simply resolved disconnecting and reconnecting, although rather infrequently toggling flight mode or removing and probing the module were needed. In addition to this, I disabled IPv6 for our local WiFi connection. The results were good enough so I moved on to the next topic.

Inverted back-light control buttons

Googling revealed other have experienced this issue before me, however, the common suggestions of using acpi_osi=Linux acpi_backlight=vendor boot parameters did not help, nor did any element of the superset of these two parameters. The only side effect was constantly maximum brightness, which cannot be changed with the buttons at all. On the Lenovo support forum I read that people using Windows experienced the same until new Lenovo provided drivers were installed... As I was running out of time, I decided to categorize this as a minor cosmetic issue and removed those boot parameters.

It is worth to note that after installation I had just about an hour to work with the ideapad which then I left the with the owner and had to continue my investigation at home, reading and googling, without access to the hardware. Therefore I quickly skipped to the next topic.

Suspend/resume, reboot and shutdown issues

It was rather obvious from the beginning that all issues around changing the power state have a common root cause. I assumed a faulty or non-standard ACPI implementation might be the root cause. I entered firmware setup and carefully reviewed the settings but did not find any obvious configuration option which might be related. I experimented with disabling virtualization support and thermal management capabilities but did not see any improvement.

Assuming the ACPI implementation of the ideapad wants to be smart and compensate some broken Windows versions, I attempted to fix the issue by experimenting with acpi_osi settings.

The ACPI _OSI call

It is not unheard of that BIOS/firmware bugs cause reboot problems. ACPI offers a way for the firmware to query which operating system [version] is running - and this feature is frequent used by vendors with good intention to work around specific operating system bugs but in long term this practice translated to the proliferation of non-standard OS implementations and wrongly applied ACPI quirks.

It is documented in the ACPI BIOS Guideline for Linux that by default the Linux kernel since version 2.6.23 no longer returns true for _OSI("Linux")ACPI invocations, effectively lying to the firmware in order to discourage vendors from applying Linux specific quirks as opposed to strictly following the standards. At the same time, the Linux kernel also returns true when _OSI is invoked with any known Windows OS string. This behaviour can be controlled via the acpi_osi parameter already mentioned before.

Other sources recommend to use acpi_osi=Linux in combination with acpi_osi='!Windows 2012' for UEFI based laptops. I have experimented with many variations, selectively enabling and disabling OS strings for individual Windows version. Unfortunately, this did not resolve the issue.

Update something

The ideapad came with firmware version CCCN12WW(V1.01) released on 03/23/2015 as confirmed via sudo dmidecode, and the most recent firmware found on the Lenovo support site is CCCN18WW (V2.04) released on 11/27/2015. While it would be a logical next step to update the firmware, Lenovo only provides a Windows executable, no way to flash the update from Linux or to prepare bootable media for flashing. The rules I have set for myself does not allow using windows based tools, so I had to stay with firmware v1.01. I believe it is rather strange that the ideapad is shipped with FreeDOS but no firmware update can be run anything other than Windows 7 or newer releases.

What I could update was the Linux kernel. The default HWE kernel these days is 3.19.0-37-generic #42~14.04.1-Ubuntu, and I installed linux-image-4.2.0-19-generic which is the Ubuntu 15.10 kernel. This update did also did not change the ACPI issue.

Firmware developers and counter-intuitive decisions

Eventually, the ACPI issue could be resolved by experimenting in the firmware settings on pure trial and error basis. The ideapad came with FreeDOS, and was configured to support BIOS/CSM mode as a fallback if UEFI boot failed. This I quickly disabled legacy mode right after installing Ubuntu. Also, UEFI Secure Boot was disabled by default which I found reasonable as I do not fancy Microsoft's practices of trying to hinder the installation of alternative operating systems.

In the "Exit" menu of the firmware setup, right under "Load Defaults" there is an parameter called "OS Optimized Defaults" which was set to "Other OS". The other option is "Windows 8 64-bit". This is only used when someone activates "Load Defaults" and as I would expects, it enables Secure Boot, sets UEFI only boot mode and some other settings found on the setup screens.

Just for the fun of it, I changed the "OS Optimized Defaults" to "Win8 64bit" and loaded defaults. As expected, it activated Secure Boot but did not change any of the other values on the setup screens. I was surprised to see that this completely fixed the ACPI issues. I returned to the firmware setup screen, disabled Secure Boot, changed "OS Optimized Defaults" back to "Other OS" - but did not load defaults. After booting Ubuntu, I confirmed that suspend, resume, reboot and shutdown work well. My conclusion is that loading Windows 8 64-bit optimized defaults also changed firmware settings which are not exposed on the setup screen. This is a very counter-intuitive practice as loading default firmware setup values should not do anything else than loading defaults for the values exposed on the setup screens.

Closing notes

With all major issues addressed, I released the ideapad for production use. I made the owner aware of the inverted backlight controls buttons and told to provide feedback if any WiFi stability issues occur during field use. The remaining glitches will be addressed subsequent posts.

Ubuntu 14.04 on Lenovo ideapad 100-14IBY

The first laptop which I really liked was an IBM t60p ThinkPad manufactured in 2006. It served me well for years but was retired some time ago and my father inherited it - predominantly for light office use. A few days ago, the graphics chip gave up and we needed an urgent, low cost replacement that fits his needs. The goal is simple: get a fully functional notebook for office use with 4G of RAM, the cheapest available disk and without OEM Windows. The stock disk would be replaced by the after market 120GB SSD from the t60p and Ubuntu 14.04 would be installed anyway, since this is the OS my father already got familiar with. The rules are simple as well: buy, install & configure the notebook, the use of windows or any windows based tools is strictly prohibited.

Enter Lenovo 100 80MH003AHV

For around 250 USD excluding VAT, this ultrabook includes 4G of RAM, a strong enough Intel Pentium Quad-Core N3540, 500GB HDD, and is shipped with FreeDOS. I have googled for any information specific to this model and Ubuntu or Linux in general, but did not find anything useful, which is not a good sign of ultrabooks in this price range... so I was prepared for surprises.

The Levono 100 is available in different models / machine-types, and 80MH003AHV relates to 100-14IBY. The hardware maintenance manual can be downloaded from the official support site.

The first surprise came right after unboxing. The plastic case did not feel very robust, but still much force was needed to open it even after all screws have been removed. Once has to be careful to apply enough but not too much force. The next surprise was the sticker seal I found on the screw that attached the HDD to the motherboard. This could possibly mean that the HDD cannot be upgreaded without voiding warranty, which is not a fair practice. I was handy enough to remove the sticker without damaging it.

Unfortunately, I realized that the SSD was password protected and although I knew the password, it could not unlock the disk. This phenomenon I have observed before - my conclusion was that that the t60p and other ThinkPads of the same era transform the HDD password provided on the BIOS Setup screen before sending it to the HDD via ATA Security commands, which, even when the password is known, makes it impossible to access the drive from notebooks of other vendors or even other generations of ThinkPads. The password has to be removed on a ThinkPad that was manufactured in the same era as the one which was used to set the password. The SSD password topic was put on hold over the weekend and on Monday, I used a t60p I borrowed from a colleague to unset the password.

Let us get back to the ideapad - I created an EFI-bootable USB key with Ubuntu 14.04, and inserted it while the computer was still powered off, then I connected the power cord and used a paper clip to push the "Novo button". This button started the computer but enter the BIOS/UEFI menu instead of launching the operating system on the HDD. I took a look at the firmware settings (which many incorrectly still refer to as BIOS setup screen) but did not see any hard reason to change any setting, so I stayed with the defaults for the initial boot.

The first boot: Ubuntu 14.04 from USB

Ubuntu booted without major hiccups, and first commands I ran was lspic and sudo dmidecode to get more information about what the ideapad contains under the hood.

00:00.0 Host bridge: Intel Corporation ValleyView SSA-CUnit (rev 0e)
00:02.0 VGA compatible controller: Intel Corporation ValleyView Gen7 (rev 0e)
00:13.0 SATA controller: Intel Corporation ValleyView 6-Port SATA AHCI Controller (rev 0e)
00:14.0 USB controller: Intel Corporation ValleyView USB xHCI Host Controller (rev 0e)
00:1a.0 Encryption controller: Intel Corporation ValleyView SEC (rev 0e)
00:1b.0 Audio device: Intel Corporation ValleyView High Definition Audio Controller (rev 0e)
00:1c.0 PCI bridge: Intel Corporation ValleyView PCI Express Root Port (rev 0e)
00:1c.1 PCI bridge: Intel Corporation ValleyView PCI Express Root Port (rev 0e)
00:1c.2 PCI bridge: Intel Corporation ValleyView PCI Express Root Port (rev 0e)
00:1c.3 PCI bridge: Intel Corporation ValleyView PCI Express Root Port (rev 0e)
00:1d.0 USB controller: Intel Corporation ValleyView USB Enhanced Host Controller (rev 0e)
00:1f.0 ISA bridge: Intel Corporation ValleyView Power Control Unit (rev 0e)
00:1f.3 SMBus: Intel Corporation ValleyView SMBus Controller (rev 0e)
02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5229 PCI Express Card Reader (rev 01)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 0a)
04:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8723BE PCIe Wireless Network Adapter

The next step was to verify if the system booted in UEFI mode or legacy BIOS mode. Checking /sys/firmware/efi/ quickly revealed we are in UEFI mode.

I intentionally did not even attempt to boot the HDD even once, as I wanted to take a backup of the factory HDD image the computer came with. I quickly configured WiFi and installed partimage after enabling the "universe" repository component and took a full backup of /dev/sda, a 500GB rotating disk with MBR partition table containing a single FAT partition which was basically empty.

Before downloading partimage I quickly verified internet connectivity, but during the repo update and package download the WiFi connection seemed unreliable. After a few minutes I completely lost connection and had to fall back to wired connection - this issue did not surprise me that much.

I manually configured the disk via gdisk, created a 32MB EFI system partition, swap and separate ext4 partitions for /root and /home. I created the partitions in a way they would only occupy the first 120GB of the disk so I can simply clone it onto the SSD once the HDD password issue is resolved. Once done, I installed Ubuntu which went fine, the only strange issue i experienced that the system did not automatically reboot itself and was stuck at a blank screen so I had to keep the power button pressed for a few seconds to force a reboot.

In the next post on this topic, I will list the issues I experienced, the systematic approach I applied to investigate and overcome those and of course the resolution itself will also be provided shortly...

Lenovo S650 update to VibeUI 2.0 1439

This post is a follow up on my older posts on Lenovo VibeUI KitKat ROM. I settled with version VibeUI 1.5 (1427) for about a year, in spite of hte following issues:

1. Waze always had a dark overlay on the map during navigation with eventual flickering, to the extent that is was completely unusable for navigation as the map was hardly visible. I am not aware of any workaround for this issue, other than using alternative navigation software.
2. Google Maps navigation is always crashing after a few minutes. The issue was narrowed down to affect newer versions, and downgrading to 8.0.0 proved to be a stable temporal workaround.
3. Security - in more particular, the lack of regular security updates and recently disclosed android related vulnerabilities frightened me at this stage.

Lenovo published a firmware update for S650 smartphones on the 25th of September last year, but at I did not see a compelling reason to install it right away, I was rather waiting for subsequent updates but they did not come. I decided to upgrade and yesterday night I found time for it.

The upgrade procedure

I cleaned up both internal and external storage, and made sure the following files are present to the external storage:

• VIBEUI_V2.0_1439_7.3.1_ST_S650_WC52.zip from vibeui.com
• 5-31_GApps_Minimal_4.4.2_signed.zip which I already had from my last download
• superuser.zip - com.koushikdutta.superuser which I also already downloaded earlier.

I took a backup of my call logs and text messages, copied important data to my computer, then booted into recovery and created a full TWRP backup. Read my previous posts for details on this step.

After wiping data, cache and dalvik cache partitions I installed the update from within TWRP recovery, then immediately applied superuser.zip. Before reboot, I opened a terminal from within TWRP, and manually mounted the system partition and deleted Chinese apps that I do not need:

mkdir /tmp/s
mount -t ext4 /dev/block/mmcblk0p5 /tmp/s
# change directory to /tmp/s/vendor/operator/app/ via TWRP menu as the built in terminal 
# does not allow you to do that
mv Len* .. # move LenovoPhonemgr.apk which I decided to keep this time
rm *.apk 
mv ../Len* . # move back the app
# change to /tmp/s/priv-app/ via TWRP
rm GameWorld_Phone.apk Youyue.apk
# change to /
umount /tmp/s

Once this was done, but before installing the google apps package, I rebooted the phone, and chose English language in the setup wizard. This was a bit tricky due to the many pop-ups, but still much easier without the Google setup wizard, which would have been run in Chinese had I installed Google Apps in one shot. After language selection and initial setup, I went back to recovery and installed google apps minimal. After booting the system the google setup wizard was greeting me in English...

Later I restored my call logs and text messages as well as application data of some of my key apps. This I had to do manually via and adb shell as Super Backup failed to restore application data even with root privileges granted. My approach was to do some setup of the critical apps manually, so the data files are were created by the app itself with appropriate permissions and ownership, then I overwrote the content of the necessary files with cat $BACKUP > $DATAFILE.

First impressions

Both Google Maps and Waze works fine with this app. I got used to the previous ROM and found stock theme and UI changes annoying. I quickly tailored the theme and launcher according to my preferences.

The Goolge Apps minimal package was outdated, which gave me some application crashed before and during updated, but once the new version of Google packages were installed, everything worked fine.

Unfortunately, according to Stagefright Detector the new version is even a bit more vulnerable than the previous one.

Stagefright

As mentioned above, this new ROM contains one more Statefright related vulnerability compared to VibeUI 1.5, and Lenovo does offer security patches, but not for this phone.

As a countermeasure, I disabled automatic retrieval of multimedia message, from the mail messaging app as recommended here and revoked MMS permissions from any other application. Of course I would be happier if Lenovo provided security updates regularly and more consistently across reasonably new mobile devices.

Firefox 37 and corporate intranet

After a recent update on Ubuntu 14.04.2 LTS, no connection to the beloved corporate expense reimbursement application could be established any more. Of course I realised this situation at a time when I urgently needed to use that application.

Background

Long time ago I have installed the Firefox extension SSL Version Control which allows me to use stronger encryption by defaults, while enables lowering the security level easily if needed. I quickly realised that requiring TLS 1.2 everywhere was not be a workable practice, so I settled with TLS 1.0 back then to get rid of at least SSLv3. Google for POODLE to learn more about the reasons.

I still needed to occasionally allow SSLv3 from time to time in order to be able to use corporate web applications hosted on improperly configured servers - this is the reality of a huge US based enterprise in 2015, no comment.

In Firefox 34 (released in December 2014), SSLv3 was disabled by default, but could be easily enabled by end user either via the extension referred above or changing property security.tls.version.min in about:config as explained here.

Firefox 37, released right before April Fool's Day 2015, disabled insecure TLS version fallback as a security improvement. This means that nor the extension, nor setting the above mentioned configuration property to 0 would allow me any more connect to sites via SSLv3. It is suggested to set another property, security.tls.version.fallback-limit to 1 and file a bug noting the URL of the site where this is needed.

Obviously, I did not submit a but report to Mozilla with a link to our intranet expense reimbursement application. Apparently, setting fallback limit to 1 or 0 did do the magic. Needless to say at that point I was a bit annoyed and under time pressure.

The solution

To make the long story short, Firefox 37 by default does not even respect user-configurable whitelisting, but uses a hardcoded list of hosts. Disabling the use of the compiled-in whitelist allows the end user to provide a custom list of hosts where insecure TLS version fallback should be allowed.See bugs 1114816 and 1084025 for details.

I ended up with disabling the SSL Version Control extension and manually tweaking TLS fallback related properties as shown below.

security.tls.version.max = 3 # default value
security.tls.version.min = 1
security.tls.insecure_fallback_hosts = w3.***.com
security.tls.insecure_fallback_hosts.use_static_list = false
security.tls.version.fallback-limit = 1

Update: Two days ago, the host running the corporate expense reimbursement application was reconfigured to support TLS 1.0 (but not any newer version). The configuration properties above have been updated to reflect this change.