Rooting Google Pixel XL (N2G47O – May 2017 update)

First, do the usual stuff (unlock bootloader, enable usb debugging, verify that adb and fastboot work,…)

Download TWRP bootable image from here, and boot it via fastboot:

fastboot boot /path/to/twrp-blahblah.img

TWRP will ask you for your devices password, so enter it. Then download the lastest version of SuperSU from here, and push it to the device:

adb push SR3-SuperSU..blahblah...zip /sdcard/supersu.zip

Since the bootloader verifies the signatures via dm-verify, you need to sign them. Download the ‘VerifiedBootSigner’ tool from here, and push it to the device (same command as before, just a different zip filename).

adb push VerifiedBootSigner-v3.zip /sdcard/vbs.zip

Then, using the TWRP gui on the phone, pick ‘install’, and first install the SuperSU zip (supersu.zip), and immediately after that (without rebooting, just go back after the SuperSU install is finished) install the VerifiedBootSigner (vbs.zip) package.

After doing all that, do a system reboot. My phone did another reboot (only once) on the loading screen, but after that I got a rooted system (and finally was able to install the AdAway hosts file).

If anything fails, dowload the factory image, and reinstall the system from there. If you remove the ‘-w’ flag from ‘flash-all.sh’, you can do that without losing your data.

Removing SIM PIN using AT commands

Ever needed to use a sim card/modem in a headless device which doesnt support a PIN code? (cheap chinese gsm-enabled sensors, I’m looking at you!) You can remove it with a simple AT command:

#verify pin is enabled:
AT+CPIN?
 +CPIN: SIM PIN

#disable pin:
AT+CLCK="SC",0,"<PIN>"
 OK

#(eg: AT+CLCK="SC",0,"1234")

#verify:
AT+CPIN?
 +CPIN: READY

After that, the SIM card will work without a PIN code (yes, yes, security, I know, I know, but with prepaid cards, who cares)

Sound pitch fix with fast-forward in mplayer

Have you ever watched a video on Youtube using a faster play speed (1.25x, 1.5x,..) and the sound seemed “the same but faster”. Ever did the same (using [ and ] keys) in mplayer, and all the voices were higher (high-pitched), and hard to listen and understand? There’s a filter in mplayer that fixes that and it’s called scaletempo.

mplayer -af scaletempo /foo/video.mp4

Now you can change the playback speed without the annoying pitch changes!

Enabling SSH on a fresh Raspbian Jessie image

This post is mostly a reminder for myself, because I will probably forget this (again) soon.

Sometimes you want to use a RaspberryPi as a headless machine, so first you download the newest Rasbian image, ‘dd’ it to the SD card, insert the SD card into your RaspberryPi, connect the ethernet and power cables, check the IP in your DHCP server logs, run ‘ssh <ip>‘ and..

..connection refused!

I have no idea why, but the ssh server is disabled by default (probably a security feature, since the default password is easy to guess, but still..). Then you start googling, and first couple of links all say that you need to connect the keyboard, display, log in localy, etc. etc. But you’re lazy, and want to do it directly on the PC when you write the image to the SD card. So the easiest way is, after you’re done with ‘dd’-ing, you mount the first partition (a smaller, FAT partition containing the boot files), and just create an empty ‘ssh’ file (with eg: touch ssh) in that folder.

If you also wish to enable wifi (which is enabled by default, but no configurations are stored), you also need to mount the second (ext4) partition, containing the full system – there you can edit ‘./etc/wpa_supplicant/wpa_supplicant.conf‘ file, and add your wireless configuration

After that, sync, umount, insert the card, connect all the cables, and it works!

Mounting VirtualBox VDI images (and similar formats)

Sometimes you have a .vdi (or .vmdk or similar) virtual machine disk image, and you wish to access files inside, without starting the virtual machine itself and copying files via network or some ‘guest additions’ tools provided by the virtualization software.

To do this, you need nbd support enabled in the kernel (and module inserted) and qemu installed (which is actually another virtualization software, but we need it for the qemu-nbd utility).

In some distributions, the nbd module is enabled by default, on some you have to enable it when compiling the kernel sources.

  │ Symbol: BLK_DEV_NBD [=m]
  │ Type  : tristate
  │ Prompt: Network block device support
  │   Location:
  │     -> Device Drivers
  │       -> Block devices (BLK_DEV [=y])
  │   Defined at drivers/block/Kconfig:276
  │   Depends on: BLK_DEV [=y] && NET [=y]

Due to some weird reasons, the nbd module by default supports zero (0) partitions inside a block device:

# modinfo nbd
filename:       /lib/modules/4.9.6-gentoo-r1/kernel/drivers/block/nbd.ko
license:        GPL
description:    Network Block Device
depends:        
intree:         Y
vermagic:       4.9.6-gentoo-r1 SMP mod_unload 
parm:           nbds_max:number of network block devices to initialize (default: 16) (int)
parm:           max_part:number of partitions per device (default: 0) (int)

So when inserting the module, set the parameter to a larger number (eg. 4 or 16 or whatever)

modprobe nbd max_part=16

After that, you use the qemu-nbd utility to ‘connect’  the vdi image to the nbd block device (qemu-nbd actually works as a block device server), mount the partition, do stuff, umount the partition, and disconnect the qemu-nbd:

#connect the device:
qemu-nbd -c /dev/nbd0 /path/foo.vdi
#partitions appear as /dev/nbd0p1, /dev/nbd0p2...
mount /dev/nbd0p1 /mnt
#do stuff
umount /mnt
#and now disconnect the device:
qemu-nbd -d /dev/nbd0

 

Checking how much data still needs to be written when sync-ing on Linux

Sometimes on Linux, when you copy alot of data to a slow USB flash drive, the operation is “done” in a second, but when you umount the drive (or run ‘sync’) it takes forever to write the cache to the actual device.

So, how to check the status (how much time is left, how much does it still need to write)?

The answer hides in /proc/meminfo. Specifically the “Dirty” and “Writeback” lines in that virtual file. Very simplified, the “Dirty” value tells you how much data is waiting in cache, and the “Writeback” tells you how much data is being currently written to the device (chunk size).

You can check both values in semi-realtime with the following command:

watch "egrep -e '(Dirty:|Writeback:)' /proc/meminfo"