Installing Dokdo Project ROM v7.3 on Samsung Galaxy S3 SHW-M440S (Korean 3G version)

The latest Dokdo Project ROMs (which use parts of CM 12) bring Android 5.0 to various smartphones from Korean manufacturers such as Samsung, Pantech, and LG.

Updates for my old Samsung Galaxy S3 ended with Android 4.3, but thanks to this ROM, I can now use Android Lollipop with a phone I bought in 2013. Although the stock ROM for SGS3 doesn't support Bluetooth LE, the Dokdo 7.3.0+ ROM supports Bluetooth and Wifi perfectly!

To install custom ROMs on this phone requires that it be rooted, however. To root the SHW-M440S, I used the cache and recovery images from CF Auto Root, namely CF-Auto-Root-m0skt-m0skt-shwm440s.zip. After extracting cache.img and recovery.img from the zip archive, you need a way to transfer these files to your Samsung phone's internal flash ROM. (It goes without saying that you must have USB debugging mode enabled in the Developer Options)

Enter Heimdall. Most people on Windows OS simply use Samsung's internal tool called Odin to flash their phones. Unfortunately, Odin is software leaked from Samsung and is not officially supported and only runs on Windows. Heimdall, however, is open source and runs on Linux.

First use Heimdall to dump your Samsung phone's existing profile info with the following command:

heimdall download-pit --output filename.pit

Here is some sample output:

$ heimdall download-pit --output shw-m440s.pit

Heimdall v1.4.1

Copyright (c) 2010-2014 Benjamin Dobell, Glass Echidna
http://www.glassechidna.com.au/

This software is provided free of charge. Copying and redistribution is
encouraged.

If you appreciate this software and you would like to support future
development please consider donating:
http://www.glassechidna.com.au/donate/

Initialising connection...
Detecting device...
      Manufacturer: "SAMSUNG"
           Product: "Gadget Serial"

            length: 18
      device class: 2
               S/N: 0
           VID:PID: 04E8:685D
         bcdDevice: 021B
   iMan:iProd:iSer: 1:2:0
          nb confs: 1

interface[0].altsetting[0]: num endpoints = 1
   Class.SubClass.Protocol: 02.02.01
       endpoint[0].address: 83
           max packet size: 0010
          polling interval: 09

interface[1].altsetting[0]: num endpoints = 2
   Class.SubClass.Protocol: 0A.00.00
       endpoint[0].address: 81
           max packet size: 0200
          polling interval: 00
       endpoint[1].address: 02
           max packet size: 0200
          polling interval: 00
Claiming interface...
Attempt failed. Detaching driver...
Claiming interface again...

Next, open the .pit file with a hex editor so you can learn the names of internal partitions (I used emacs in hexl-mode). For the SHW-M440S, the partition names are in ALL CAPS:

RECOVERY, CACHE, BOOT, BACKUP, etc

but I have read that international versions of Samsung phones sometimes use lowercase partition names.

Now that you know the partition names, write the CF Auto Root recovery.img to RECOVERY and cache.img to the CACHE partition using heimdall:

heimdall flash --RECOVERY recovery.img --CACHE cache.img

Your SGS3 should then automatically reboot into recovery mode and a red pirate Android bot will appear in the background as the root exploit is applied. Then the phone's original recovery will be restored and the cache erased before the phone reboots into the stock ROM. You will notice that there will be a new app, SuperSU and that you can now use su in adb shell once you give permission on your phone's touch screen.

Now turn off the phone and go back into Download Mode (Vol down + Home Key + Power). heimdall detect to make sure the SGS3 is being detected:

$ heimdall detect
Device detected

Now that the SGS3 is rooted, it is possible to install a custom recovery that will allow you to install custom ROMs to the phone's internal memory. Download recovery-clockwork-6.0.4.6-i9300.img (the i9300 version works just fine with the SHW-M440S) to your linux box and flash it into the recovery partition using heimdall.

heimdall flash --RECOVERY recovery-clockwork-6.0.4.6-i9300.img


Now reboot into recovery mode (Vol Up + Home + Power) and wipe data, Dalvik cache, cache, and select install from zip if you have saved the custom ROM on an external microSD card. Or you could simply use adb sideload if your phone in recovery mode is connected to a Linux machine via USB cable. I just used sideload to transfer files from my Linux machine to my SGS3:

adb sideload dokdo-7.3.0-OFFICIAL-m0xx.zip
adb sideload dokdo_gapps_5.1.X.zip

I then selected the dokdo ROM for install from zip, followed by the Google apps package gapps.

EFI multiboot for Ubuntu 15.10 Wily and Archlinux

At work I recently had the opportunity to install Ubuntu 15.10 Wily Werewolf (released on Oct 22, 2015) on a company laptop using EFI boot instead of legacy BIOS. Ubuntu installs just fine on post-2011 hardware that has UEFI boot enabled, but note that Ubuntu uses the grub2 bootloader on top of EFI, whereas other Linux distributions use bootctl from systemd-boot or other EFI boot managers.

The company laptop initially had Archlinux installed with an encrypted root inside LVM on a LUKS partition with lots of free space left over for the installation of Ubuntu 15.10. Installing Ubuntu as the second OS on an EFI boot machine ran into two problems:

1. If you choose to install Ubuntu 15.10 into a new LUKS partition on a disk already containing other LUKS partitions, the Debian Installer will erase all other LUKS headers when it creates the new LUKS partition. In fact, this is a known issue and the developer of cryptsetup warns (section 1.2 WARNINGS) against installing Ubuntu with LUKS on a disk that already contains other LUKS partition:

https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions

UBUNTU INSTALLER: In particular the Ubuntu installer seems to be quite willing to kill LUKS containers in several different ways. Those responsible at Ubuntu seem not to care very much (it is very easy to recognize a LUKS container), so treat the process of installing Ubuntu as a severe hazard to any LUKS container you may have...the installer offers to create LUKS partitions in a way that several people mistook for an offer to activate their existing LUKS partition. The installer gives no or an inadequate warning and will destroy your old LUKS header, causing permanent data loss

2. Ubuntu can fail to install grub2 into the ESP (EFI System Partition) if another boot manager has already been installed there. I think this occurs because the path /boot/efi doesn't exist, which can happen if another linux distro (like Archlinux) is first installed and a boot manager like bootctl has created the path /boot/EFI on the ESP. The sole difference is EFI in all-caps or not, but this seemingly-minor issue causes problems for the Ubuntu installer.


Workaround

I therefore strongly recommend that you install Ubuntu as your first OS before installing other Linux distros to create a EFI multiboot system. Archlinux plays well with other EFI boot managers installed to the ESP.

During the installation of Archlinux as the second OS on a EFI boot machine, the ESP will be mounted as /boot (actually /mnt/boot before chrooting into the new system). To install the bootctl boot manager, simply invoke

bootctl install

inside the chroot, which will then install bootctl into the ESP.

I created Archlinux as my default boot entry at /boot/loader/entries/arch.conf :

title Arch
linux /vmlinuz-linux
initrd /intel-ucode.img
initrd /initramfs-linux.img
options cryptdevice=UUID=b332de40-afe8-47d5-9512-bf03da8d13cc:ARCH root=/dev/mapper/ARCH-rootvol quiet rw

The example above includes boot options for opening a LUKS partition and accessing '/' inside LVM.

Now you also need to create an entry for ubuntu so that bootctl will load grub2 menu for 15.10 Wily. Let's call it /boot/loader/entries/ubuntu.conf:

title Ubuntu 15.10
efi /EFI/ubuntu/grubx64.efi

Finally, you need to add the Ubuntu 15.10 entry to /boot/loader/loader.conf:

timeout 10
default arch
ubuntu

Now when you get the to EFI boot menu, you will see entries for both Archlinux and Ubuntu.

How to group chat in Slack through irssi + bitlbee

This tutorial assumes that you already have irssi and bitlbee installed and set up and therefore only details the process of adding the #general channel on a Slack board so you can group chat in the terminal. This tutorial will not go through how to get irssi and bitlbee set up for using XMPP chat services in the terminal, however, as there are already many good sources on the Internet that explain how to do this (Archlinux bitlbee tutorial, Slack tutorial on connecting via XMPP or IRC, etc).

In the bitlbee admin channel (/join &bitlbee), initially adding a slack account is straightforward:

account add jabber userName@myBoardName.xmpp.slack.com [Slack-generated XMPP password]

Note that you can find your Slack-generated XMPP password at myBoardName.slack.com/account/gateways at the bottom of the page with a section that reads "Getting Started: XMPP". This password is different from your main Slack password!

OK, so now you've added your XMPP account for a Slack board. If you do nothing else, you can at least chat with individual users on the board with the /msg userName command, but you won't be able to chat in channels such as #general.

To enable #general in Slack, enter the following from the bitlbee admin channel (all one line):

chat add userName@myBoardName.xmpp.slack.com general@conference.myBoardName.xmpp.slack.com

This step is not clear from the instructions provided by Slack on the .../account/gateways page.

But there is one problem -- unless your default irssi nick matches the one you are using in your Slack board, you will be refused access to #general. You can set your default irssi nick in $HOME/.irssi/config in the following line:

settings = {
  core = { real_name = "My real name"; user_name = "YourUserNameHere"; nick = "YourNick"; };
  "fe-text" = { actlist_sort = "refnum"; };
};

To apply changes, restart irssi. Or you can change your Slack username to match your irssi nick by clicking on Account Settings in the Slack UI.

Some screen shots of irssi + bitlbee in action with a Slack channel (already added).

ipTIME N704M 공유기 펌웨어 버전 9.84 - WAN 포트 감지 문제

문제: 2015-10-06에 배포된 N704 펌웨어 버전 9.84을 설치한 다음 공유기 전원 껏다키면 WAN 포트가 아예 감지되지 않습니다 (WAN LED 점등 되지 않음).

임시 해결: 바로 전 펌웨어 버전인 9.78(2015-08-11)로 다운그레이드 시키고 전원 껐다 키면 WAN 포트가 다시 감지 됩니다.

그래도 ipTIME은 4년이된 제품인 N704M 펌웨어 업그레이드를 계속 내놓는 것은 장하다고 생각합니다! 예를 들어 휴대폰 제조사들은 2년만 지나도 최신 Android으로 업데이트 해주지 않는 경우가 허다 합니다.

Using Emacs within a GNU Screen session

My text editor of choice is Emacs, and it is once of the applications that I automatically launch inside a tab within GNU Screen. One problem, however, is that GNU Screen by default captures Control S (C-s) because this key combo means XOFF (stop sending input to terminal; to re-enable sending input to terminal, press C-q). This is undesirable behavior because C-s is a very important key combo in Emacs.

You can manually turn off flow control in Screen by invoking

C-a :flow off

within the tab running Emacs. I wanted to do this through a script, however, so I added the highlighted line to a bash script that launches Screen and creates several tabs:

# launch a GNU Screen session named 'netbook' in detached mode
screen -AdmS netbook -t SHELL
# create separate tabs in session 'netbook' and launch programs in tabs
screen -S netbook -X screen -t HTOP htop
screen -S netbook -X screen -t CMUS cmus
screen -S netbook -X screen -t IRSSI irssi
screen -S netbook -X screen -t EMACS env TERM=xterm-256color emacs 

# On tab 0, launch SpiderOakONE and dropboxd daemons for cli
screen -S netbook -p 0 -X stuff "cd $HOME/bin^M"
screen -S netbook -p 0 -X stuff "./tty_startup.sh^M"
# turn off flow control in tab 4 so C-s is passed to emacs
screen -S netbook -p 4 -X 'flow off'


Although the highlighted line doesn't generate a syntax error, it actually has no effect! When press C-a f (Control a, f) within the Screen tab running Emacs, I noticed that flow control was actually not being disabled in the GNU Screen tab running Emacs, despite the highlighted command above.

Fortunately, Screen has an automatic flow control mode that is smart enough to figure out when to disable flow control, for example when Emacs is running. To enable it, add the following line to your .screenrc config file:

defflow auto

Now I don't experience any more problems with Screen capturing the C-s key combo.


References:

https://www.gnu.org/software/screen/manual/html_node/Flow-Control-Summary.html

https://bitbucket.org/gojun077/bin-scripts/src/cef6f0a31c087cad85246f494f82a5abea2d0990/screen_netbook.sh?at=d257&fileviewer=file-view-default My GNU Screen launch script

https://github.com/gojun077/jun-dotfiles/blob/master/screenrc My .screenrc file from my personal dotfiles repo