Problems with Heimdall

One of the stranger technical adventures I have been on lately was updating the modem on my Note 3 with Heimdall. A wonderful cross platform flashing utility for Samsung phones. The idea is simple. You put the phone in download buy holding down the power, volume down, and the center button, and the phone boots into download. Next the you issue heidall detect as root. It should look something like this:

~$ sudo heimdall detect
Device detected

OK, cool so I went on to the next step.

~$ sudo heimdall flash –APNHLOS ~/Downloads/CP_N900TUVUFOL1_MODEM/NON-HLOS.bin --MDM ~/Downloads/CP_N900TUVUFOL1_MODEM/modem.bin

This one is the big one because if it messes up you will be install a stock rom to fix it. I got a protocol error the first time.

Initialising protocol...
ERROR: Protocol initialisation failed!

I thought something else a had control of the usb port. Got on the net and started poking around. The answer showed up here. Cool, so I create /etc/udev/rules.d/79-samsung.rules with vi. In the file is one line ATTRS{idVendor}=="04e8", ENV{ID_MM_DEVICE_IGNORE}="1". Close the file, reboot. I run the flash command again and get this:

Downloading device's PIT file...
PIT file download successful.

ERROR: Partition "MDM" does not exist in the specified PIT.
Ending session...
Rebooting device...
Releasing device interface...
Re-attaching kernel driver...

So what's next you ask. Well since Heimdall looks at the PIT file, we have to too, to know what's going on.

~$ sudo heimdall print-pit --verbose –no-reboot

.

.

.

--- Entry #0 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 1
Attributes: 5 (Read/Write)
Update Attributes: 1 (FOTA)
Partition Block Size/Offset: 8192
Partition Block Count: 30720
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: APNHLOS
Flash Filename: NON-HLOS.bin
FOTA Filename:


--- Entry #1 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 2
Attributes: 5 (Read/Write)
Update Attributes: 1 (FOTA)
Partition Block Size/Offset: 38912
Partition Block Count: 117632
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: MODEM
Flash Filename: modem.bin
FOTA Filename:

AH, Ha, The partition call MODEM. It also appears we have a new G3 modem installed and the older G4 uninstalled the phone is still booting, so, Bonus!

~$ sudo heimdall flash --APNHLOS ~/Downloads/CP_N900TUVUFOL1_MODEM/NON-HLOS.bin --MODEM ~/Downloads/CP_N900TUVUFOL1_MODEM/modem.bin

And this kids, is what the magic looks like when it works…

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...
Claiming interface...
Attempt failed. Detaching driver...
Claiming interface again...
Setting up interface...

Initialising protocol...
Protocol initialisation successful.

Beginning session...

Some devices may take up to 2 minutes to respond.
Please be patient!

Session begun.

Downloading device's PIT file...
PIT file download successful.

Uploading APNHLOS
100%
APNHLOS upload successful

Uploading MODEM
100%
MODEM upload successful

Ending session...
Rebooting device...
Releasing device interface...
Re-attaching kernel driver...

One line shell script that saved me a lot of work

    Even though I have not been writing about my adventures does not mean they have not been happening. It means I have not been writing. One of the issues that I have been dealing with has to do with plasma-desk deciding it needed 100% of 1 of 8 threads in my laptop. This would have been okay except for the fact it made everything take forever. After googling around for awhile, I found, much to my dismay that it could be cause by any plasmoid. (KDE comes up with such great names.) After ripping all the plasmoids out, I put them in one at a time very gently. I checked each time to make sure that the cpu was not going crazy. It turned out to be the network command and control, and the network monitor plasmoids. So this solved part of the problem.

    Other strange thing were happening with my machine.  There is a really awesome music play KDE has called Amarok. The coolest thing it does is store the location of all my music files, album covers and stats on the music in a Mariadb database. Everytime I cranked up Amarok the entire GUI would crash.  Even the Nvidia driver would have to come back up.  Also, the stable version of chrome  would cause the same problems.

    I have to admit that I like playing with less that stable software on my personal boxes. Side note:  I load CentOS 7 on an HP R4000 with Ntopng and locked down according to the NSA. To include Aide setup on it. I put it out in the dmz to find out what was happening my garden gate, so to speak.  Oh, the point, the R4000 is a single processor 64-bit machine, maxed out at 2 GiB of memory. Everytime I reboot it, I get a warning saying that CentOS does not support the R4000.  The moral  here, is don't believe everything you read.

    So, I was installing test versions of KDE4. I really, wanted to play with 4.13 or 4.14. I did not think the @kde-testing repo was that unstable. I was wrong! I have spent the last weekend ripping out the testing stuff and replacing it with updates. After doing some research on yum, I came up with this script and an example of the output:

yum list installed | sort

tix.x86_64                            1:8.4.3-11.fc20                @anaconda
tk.x86_64                             1:8.5.14-1.fc20                @anaconda
tk-devel.x86_64                     1:8.5.14-1.fc20                @fedora
tkinter.x86_64                        2.7.5-13.fc20                installed
tmpwatch.x86_64                  2.11-4.fc20                            @anaconda
tomcat-el-2.2-api.noarch        7.0.47-1.fc20                @fedora
tomcat-jsp-2.2-api.noarch                7.0.47-1.fc20                @fedora

OK, this was cool, but I only needed the first column. So back to google for a sed script. The second iteration looks like this:

yum list installed | grep kde-test |sed 's/\ / /'|awk '{print $1}'  and the output

dragon.x86_64
granatier.x86_64
jovie-libs.x86_64
juk.x86_64
kaccessible.x86_64
kaccessible-libs.x86_64
kactivities.x86_64
kactivities-libs.x86_64
kactivities-nepomuk.x86_64
kajongg.noarch
kanagram.x86_64
kanagram-libs.x86_64
kapman.x86_64

So my first attempt for a complete script failed,

yum list installed | grep kde-test |sed 's/\ / /'|awk '{print $1}' | sudo yum reinstall 

I got an error stating that reinstall had to follow by an item or list.

    Being the kind person I am, I have a presents on Facebook and Twitter. I hate them both. I decide that the easiest way to prevent have to go on either one of them was to cron some shell scripts of random commentary. While I was writing the shell script for Facebook I had to execute a command inside a shell script. That is when I discovered `command`.  I remember that, and this is the complete script
   
sudo yum reinstall `yum list installed | grep kde-test |sed 's/\ / /'|awk '{print $1}'` -y

LUKS not Mounting

I've had my share of problem with linux installations before, but the worst are always on my laptop. I did an update using Fedora's new updating tool dnf, and I kept getting scriptlet failures. This was ok after a couple of man pages and rebuilding the rpm data base all was good, at least I thought. I didn't realize anything was a miss until my GUI stopped functioning. So, after a little frustration with no keyboard or mouse, I got to the laptop reboot.

As the laptop came backup, it got stuck on mounting the LUKS partitions. See all my partitions are encrypted besides /boot and /boot/efi. So, no /, no /home, no /var and no swap, nothing was mounting. I pulled out my cell phone and started searching the net for possible solutions. The updates with the scriptlets not running was cause by a miss configured SELinux I found. I found nothing that related to my problem, but I did find a similar description of the situation dealing with thin LVM installations. The work around was to boot the machine with a cd mount the file system and chroot it.

chroot /mnt/sysimage/ /bin/bash, then run dracut -f, exit and reboot. SELinux would have to relabel the partitions and all would be as good as new. Not!

The reason this problem existed was because dracut was never able to update the initramfs with the scriptlet that never ran. Second, dracut if you don't specify the kernel you want the initramfs build for, dracut will build it for the running one.

 Yes, you guessed it first time around, the initramfs was built for the kernel on the install dvd for Fedora 20. After more man pages, and pulling what little hair I have left out, I found the answer. It is “dracut –kver (kernel version) –force”. The command will build the correct initramfs and since it's forced, you will not get any warnings about over writing the old one.

Strange Problem Solved

Yesterday I was checking out somethings about my laptops processor, and noticed that Intel had downloads for Linux.  Specifically, microcode for a whole gaggle of i7 processors. 

I had gotten my laptop, a Y500, about 10 months ago. The first thing I did was rip Windows 8 out by the roots. Then calmly loaded Fedora 19. I was happy for about a day. Then this strange ever present issue would rear it ugly head at the worst times. The keyboard would go completely insane, and start typing by itself. It would also cause windows to open or close and Libreoffice to do all kinds of weird things. Lenovo's tech support was near useless, none of them had dealt with any form of Linux before. I called the tech support about this issue 3 times. The first 2 times I got blown off. The last a guy tried to help, but it was trying to repair the virtualized Windows 7 I have running on kvm/qemu.  Another story.  I pointed out that once he fixed the Windows side, the Linux side would still have the problem.  As you can guess, replacing the drivers in Windows and having a one year warrenty didn't help the situation at all. 

The fix it turns out was loading the latest version of the microcode in the processor. This task is easier said than done. 

The latest microcode can be downloaded here. After the tar/gzip file is downloaded you have to extract it with tar -zxvf <filename>. What you have after the extraction is a file called microcode.dat. microcode.dat need to be converted ucode. The powers that be were kind enough to provide the right tool for the job. intel-microcode2ucode is the program with no help, and no man page. The command is intel-microcode2ucode microcode.dat that creates a folder named intel-ucode with the working microcode inside of it. Now you can move the microcode to /lib/firmware/intel-ucode/ where the kernel will load the processor.

 I did a lot of research and found that microcode_ctl no longer loads the processor and the processor needs to be loaded with the new microcode every time the computer is started. If the microcode is corrupted then the processor will revert back to it's original microcode.

Instructions: How to use “adb sideload” in Linux

This guild was written because I could not find a linux version a 'How to use "adb sideload"'. I wanted to load Android 4.4 without having to root my Nexus 7 2012.  I found a Windows version here.

One word of warning: If you don't understand this guild don't do it. I'm also not responsible for you bricking your Nexus or any other device.

1.  First, you need to install the latest Android SDK. [Android SDK]

• This isn’t a guide on how to get the SDK installed or basic adb. There is a rule that needs to be added to udev for the Nexus 7. 
• ATTR{idVendor}=="18d1", ATTR{idProduct}=="d001", SYMLINK+="android_sideload", MODE="0666"
  

2.  Plug in your device to your Linux machine.  Make sure USB Debugging is enabled.

3.  To test that you have adb up and running, and that your device is recognized, open a command prompt.

4. Type the following”

"adb devices" in root. I found I was getting a "error: insufficient permissions for device" error trying to do the sideload as a normal user. Starting adb-server in root prevents this.

5.  You should get a serial number followed by “device.”

015d182f9a0aac28    device

6. If you see something along those lines, your adb is working properly, for now.

7.  Download the update.zip from Google to your PC that you would like to install on your Nexus.

8.  The file can be in any folder as long as adb is in the PATH

9.  Type the following:

• adb reboot bootloader

10.  Your device will now reboot to the bootloader.

11.  Use Volume Down on your device to until you see “Recovery.”

12.  Select it with the Power button.

13.  Your device will boot to an Android logo with a exclamation mark.

14.  To jump past this, press Volume Up and Power at the same time.

• This is not as easy as it sounds. It took me three times to do it right.

15.  You will now be in stock recovery.

16.  With Volume Down, highlight “apply update from ADB.” Press Power to choose it.

17.  Back to your PC, type the following command:

adb sideload <filename of update.zip>

• I rename update files to something simple when I get them. I renamed the Android 4.4 update to KRT16S.zip , so my command was “adb sideload KRT16S.zip ”

18.  If your adb is working properly, you should see the file transfer to your device in adb.

19.  Once that finishes, your device will begin to update.

20.  Once it has finished, simply reboot and enjoy the update.