Cross Dressing Architecture: Which CPU Do I Wear?

I’m going to make this a quick post because it’s late and I am just trying to get something done… I’m cross compiling a kernel for a small device. The problem is that my work station is an i7 running 64 bit Gentoo. The target is a Via C7 and while I could probably do everything in 64 bit on the device I don’t necessarily want to double my memory register widths on a device that is cramped for memory. Gentoo has an awesome tool called crossdev that automatically built the toolchain for my target device.

The problem now is that I can’t fool make. It knows something is wrong with what I am doing. I even decided to chroot in to a i686 only environment  Make still freaked out that I was being crazy trying to compile code. The error was, “CPU you selected does not support x86-64 instruction set”! I’ve searched around the internet and no one had an immediate solution. Of course… I got to thinking… I’ll alter the Makefile to set the arch… changed some uname -m to echo i686′s here some ARCH=${ARCH} to ARCH=i686′s there… Still it wouldn’t compile! Even -m32 didn’t work. Make knew something was up and I realized that the make binary was doing this check.

The solution was really simple… It’s something I did long ago to compile a 32bit kernel. Most distros ship with arch and setarch. The arch command tells you what you’re running. The setarch command sets your arch to anything you want! I want i686! Everything compiled great after and we all had tea and scones.

Share on Facebook

Jelly Bean OTA For Galaxy Nexus: No Wipe, Just Candy

Jelly Bean 4.2 came out today for the Galaxy Nexus. Many will get the OTA, many will have to wait. If you don’t want to wait, if you don’t want to root, if you don’t want to unlock, if you don’t want to wipe… Then the following can be followed at your own risk. The details are simple and they worked for my phone. I can’t guarantee they’ll work for your phone. My phone was a yakju and I loaded the takju image on it a long, long time ago. That process requires a wipe, but let’s proceed to the current process. You need a few things. The Android Platform Tools that has the  adb in them and the new OTA update.

Links:

1. http://dev.ided.us/L7z4 (short link to Android SDK)
2. http://dev.ided.us/ylPj (short link to the Android OTA for the takju GSM phone)

Directions (see warning below):

1. Follow the setup guide for the Android SDK
2. Download the client
3. Power off your Galaxy Nexus
4. Holding the volume buttons and press and hold the power should bring you to the Fastboot menu (note if you’re in the Odin menu then you need to press power to exit and restart at step 3)
5. Use the volume up/down to navigate to “Recovery mode” and press power to select bringing you to a dead android with a red exclaimation trigon
6. Press volume up and then press power at the same time which is important because if you’re timing is wrong you just need to repeat this step until you get your rhythm
7. A blue menu should appear using the volume up/down to navigate again highlight “apply update from ADB” and press power to select it
8. The device will ask you to run adb sideload filename (note that older version of adb don’t support sideload so go to step 1 and back to this step if you need to
9. From here the platform specifics are different but I run Linux and from the folder platform-tools in the Android sdk I issued “./adb devices”
10. This will restart/start the adb daemon and if you upgraded the sdk it will also kill the adb daemon if it’s out of date
11. Once you see your device in the list proceed
12. The final command is “./adb sideload e587de13bf8a.signed-takju-JOP40C-from-JZO54K.e587de13.zip” causing the phone file to be uploaded and the update to proceed
13. The phone will take around five minutes to apply the update and the subsequent reboot will take longer than usual but after you’re running Android 4.2
14. Enjoy!

Warning: Remember following these steps can brick your phone. I personally have accidentally bricked my HTC Hero following guides like these. Proceed with caution and when in doubt just wait for the OTA. I take no responsibility for the instructions I’ve put up if it breaks your phone.

Update: I had two links today. The http://dev.ided.us/rayb link will download the original Nexus 7 (wifi only) image. This image is reputed to only work with the original Nexus 7. The instructions should work for both the Galaxy Nexus and the Nexus 7. I didn’t have a Nexus 7 to try this out on.

Share on Facebook

Truncate: Your Proble

I had a really stupid problem. I needed to truncate a file in place and my distribution didn’t provide this. At least it didn’t provide this when the system was created. I’m using Gentoo and the machine I am working on was put in place almost five years ago.

The nitty gritty is that we’re using Bacula as our backup solution. Occasionally Bacula stops responding and we have to restart the service. When this happens any backup that wasn’t completed and committed to the catalogue results in a corrupted volume. Our volumes are file based and are a couple hundred gigabytes. The solution I came up with so long ago was to simply dd the amount of data the catalogue thought the volume should be and copy it back over the source. Kind of like traveling back through time to a place where the backup software was happy. The problem with this method is that the we end up copying basically most of the data, minus the amount of data added from the incomplete backup, and then copying it back again. The system must then guarantee that the maximum size of the volume must be available for the copy, ie there must always be a couple hundred gigs free to complete this repair.

The best solution would be to truncate the file in place. A proper truncate command shouldn’t have to copy any parts of the file and simply inform the file system that the file ends abruptly at x bytes and be relatively instant vs io intensive. The good guys at the Gentoo forums recommend back in 2005… to simply compile the FreeBSD version. That probably resolved everyone’s problems or confused people who don’t know how to simply compile files. The problem I have is that now I have a rogue executable on the machine in the system’s bin directory or whatever the heck I will end up putting it. You can’t really trust a systems admin with corners. Therefore I created an ebuild for this file so that I could put it in the package management system on Gentoo, called Portage. If a systems administrator who is not me needs to figure out where the file came from our where the packages files are located they can now use the Portage system to figure this information out.

The newest version of coreutils just has this included. I didn’t know that until after I tried to install my new ebuild on a system with a more recent update of Gentoo. Because this is an ugly hack since the correct answer is to just update the software on the machine I didn’t go back and grab a GNU version of truncate. The provides an answer to my problem but maybe someone else’s.

If you’re not running Gentoo then you can follow my easy simple compiling directions.

1. Grab the source from FreeBSD or here
2. Copy it to your *inx system that doesn’t ship with truncate
3. Run the command gcc -o truncate truncate-9999.c (if you’re using something other than gcc you could try replacing the gcc command with your c compiling, e.g. gcc, cc, icc…
4. Test truncate out to make sure that the BSD c library isn’t too divergent from the GNU library or whatever c library you compiled for

If you’re running Gentoo then just create an over lay with my ebuild from here.

Share on Facebook