I am fairly tech-savvy which means I try to figure out what is going on and these guides fail to explain that.
So here goes, the TL;DR version to root your HTC Sensation XE and replace the bootloader to make backups or replace the OS.
We start by replacing the bootloader so we can install custom things, including the root access.
- Step 1: Unlock your phone; this is called switching S-ON to S-OFF. I speculate this allows write access to parts of the phone. Follow the HTC instructions here: http://developer.htc.com
- Step 2: Use 'juopunutbear' to unlock and replace the stock bootloader with a version that can be replaced. Yes, the 'trick' with the wire is required: it probably triggers a reset of one of the security mechanisms to cheat your way into the bootloader.
- Step 3: At this point the bootloader can be replaced. Write your preferred bootloader image from your computer to your phone in the 'fastboot' mode using 'fastboot flash recovery myrecovery.img; see http://forum.xda-developers.com/showthread.php?t=1864053 and search for the 'Flash the Recovery' section which has a link to an image and the exact command for it./li>
Your HTC Sensation XE now can install custom firmware including the root access. How this can be done is future work.
sudo apt-add-repository ppa:ubuntu-x-swat/x-updates sudo apt-get update sudo apt-get install nvidia-currentPatch (by hand if you have to) the following 2 files:
/usr/src/nvidia-current-304.64/conftest.sh /usr/src/nvidia-current-304.64/nv-mmap.cThese patches are based on 310.xx but can be used for manual modification:
--- conftest.sh.dist 2012-10-11 19:18:22.704848496 -0400 +++ conftest.sh 2012-10-12 20:35:55.707213868 -0400 @@ -20,6 +20,7 @@ ISYSTEM=`$CC -print-file-name=include 2> /dev/null` SOURCES=$4 HEADERS=$SOURCES/include +HEADERSA=$SOURCES/include/uapi OUTPUT=$5 XEN_PRESENT=1 @@ -118,7 +119,7 @@ fi fi - CFLAGS="$CFLAGS $OUTPUT_CFLAGS -I$HEADERS $AUTOCONF_CFLAGS" + CFLAGS="$CFLAGS $OUTPUT_CFLAGS -I$HEADERS -I$HEADERSA $AUTOCONF_CFLAGS" test_xen @@ -146,10 +147,10 @@ fi fi - CFLAGS="$BASE_CFLAGS $MACH_CFLAGS $OUTPUT_CFLAGS -I$HEADERS $AUTOCONF_CFLAGS" + CFLAGS="$BASE_CFLAGS $MACH_CFLAGS $OUTPUT_CFLAGS -I$HEADERS -I$HEADERSA $AUTOCONF_CFLAGS" if [ "$ARCH" = "i386" -o "$ARCH" = "x86_64" ]; then - CFLAGS="$CFLAGS -I$SOURCES/arch/x86/include -I$OUTPUT/arch/x86/include/generated" + CFLAGS="$CFLAGS -I$SOURCES/arch/x86/include -I$SOURCES/arch/x86/include/uapi -I$OUTPUT/arch/x86/include/generated -I$OUTPUT/arch/x86/include/generated/uapi" elif [ "$ARCH" = "arm" ]; then CFLAGS="$CFLAGS -I$SOURCES/arch/arm/include -I$OUTPUT/arch/arm/include/generated" fi
--- nv-mmap.c.dist 2012-08-08 22:52:53.000000000 -0400 +++ nv-mmap.c 2012-08-14 23:52:41.257235863 -0400 @@ -450,7 +450,7 @@ NV_PRINT_AT(NV_DBG_MEMINFO, at); nv_vm_list_page_count(&at->page_table[i], pages); - vma->vm_flags |= (VM_IO | VM_LOCKED | VM_RESERVED); + vma->vm_flags |= (VM_IO | VM_LOCKED | (VM_DONTEXPAND | VM_DONTDUMP));Patches are taken from here After patching, the NVidia kernel module will not be built unless you install a new kernel or force an update using DKMS. To rebuild the kernel module for your currently running kernel, run this:
sudo dkms autoinstall -k $(uname -r)
Use the standard build guide from the OpenElec wiki. After cloning the GIT repository, modify the lirc build script to build the correct module.
Open 'packages/sysutils/remote/lirc/build' and replace the following line for the userspace driver:
Update: I tried various things but for some reason I could not get the alsa support to be simply added to the standard build (this seems to be a bug in LIRC which should have been fixed upstream). You can try adding the line instead of replacing it (note the trailing slash!)
All done: now start the system build as you normally should:
PROJECT=Generic make release
Sit back and wait; on a Core2Duo system the build takes several hours and close to 9GB of space. Follow the guides to modify the lirc config in userspace, or modify the 'install' script to install the correct configuration into the read-only system build.
Updates Break LIRC!Your custom built OpenELEC will attempt to update itself with standard releases. You can disable automatic updates or place the LIRC binaries on the '/storage' mount where they will survive updates; just make sure you call the correct binaries. Note that this will only allow you to have updates as long as the binary compatability of OpenELEC does not change. It seems plausible that this will remain as such at least between large updates but if you want to be really sure you should switch to manual updates to prevent sudden breakage...
Audio SetupSome notes to set up the audio capture correctly as these seem to be scattered over the internet. First off, mute the capture for all inputs but the jack you connected the receiver to so only the correct input is enabled. On OpenELEC it seems like all inputs are muted by default so you only need to unmute the correct input from within '/storage/.config/autostart.sh':
# Select the correct input channel amixer set "Capture",0 cap # Set the volume of the capture amixer set "Capture",0 20In case you wonder which channel is the correct one or how loud it should be, use 'arecord'. You most likely will not have this program on OpenELEC but it is in fact identical to 'aplay': create a symlink to 'aplay' called 'arecord' and you are good to go.
Use 'arecord' to display the volume of the incoming signal (using the builtin VU), tweak to whatever your system needs:
arecord -vv -D hw:0 -c2 -r48000,l -f S16 > /dev/null
I experimented with the recording amplification until I had a near zero output when idle (2 to 3% on the VU) and 30% to 35% peak volume when holding a button down.
At first I had the volume tweaked so input would trigger 10% on the VU. At this point 'irrecord' seemed to work but it failed on the 'Toggle Bit' detection where you have to push a button as often as possible. Increasing the volume solved this (and simply opening the volume up to the max will break it again - calibrate it properly or 'irrecord' will fail!).
And for reference, this is how I start lircd from 'autostart.sh' in OpenELEC:
/storage/.bin/lircd --driver=audio_alsa --output=/var/run/lirc/lircd --pidfile=/var/run/lirc/lircd.pid -d hw@48000,l /storage/.config/lircd.conf
You could add '--uinput' to generate Linux input events besides standard lirc events. This effectively means the XBMC would not use LIRC events but something like keyboard strokes. It depends on personal preference but I still use the old fashioned LIRC events.
While test-driving XBMC 12 during the pre-beta phase I noticed how I could use AirPlay with iTunes under Windows to get sound from my crappy laptop speakers to the home cinema setup powered by XBMC.
Thinking this should also be possible from within Ubuntu Linux sent me on a goose chase that seemed to end up nowhere.
From the 'paprefs' utility, you can actually connect with the AirPlay capabilities of XBMC. But instead of sharing sound, you in-sta crash or hang XBMC. Even better, since this functionality is managed by PulseAudio, merely logging in on Ubuntu will hang XBMC as PulseAudio keeps connecting.
I read multiple stories how this is a RAOP (I assume this is the Linuxy name for AirPlay) issue where UDP should be used but TCP is preferred or something. Looking at the libshairplay website (which seems to be used by PA), it says UDP is supposed to be working for quite some time now. I gave up on this.
Next up is sharing local audio using UPnP: paprefs => 'Network Server' => 'Make local sound devices available as DNLA/UPnP Media Server'. Fire up XBMC, search for audio using UPnP aaaaaand.... nothing.
It turns out that enabling this option only loads a module which creates an HTTP audio sink. Put another way: the audio from your sound card is shared on the network, it is just not advertised so nothing can find it.
This is the point where you need Rygel. While the description tells you about transcoding media for Xboxes and PlayStations, the core of Rygel is a UPnP media server. You need this functionality to advertise the audio sources to the local network.
If you now start Rygel (3) by typing 'rygel' you will get a listing for any found media, Rythmbox music collection (if its running) and the internal sound cards (1).
But all is not well yet: when you point XBMC to the internal sound card (or the special DNLA device if you enabled it in 'paprefs') XBMC will crash: http://trac.xbmc.org/ticket/13579
Hopefully this bug will get fixed soon but in the meantime it leaves us without streaming audio. Luckily there is another solution in the form of the GstLaunch (2) plugin for Rygel. Do note that this is another package seperate from Rygel itself (it took me 10 minutes to figure out why the plugin was seemingly awol when it was in fact not installed).
The GstLauncher plugin allows you to connect a GStreamer pipeline to the network as a UPnP source. While this in theory opens up loads of fun stuff to play with, it can also be used to generate audio streams from the internal sound card for XBMC.
Open up your rygel.conf (I removed the one in ~/.config/rygel.conf and put everything in /etc/rygel.conf) and put the following in there (comment the existing GstLaunch section):
pulseaudioflac-title=FLAC on @HOSTNAME@
pulseaudioflac-launch=pulsesrc device=upnp.monitor ! flacenc quality=8
pulseaudiomp3-title=MP3 on @HOSTNAME@
pulseaudiomp3-launch=pulsesrc device=upnp.monitor ! lamemp3enc target=quality quality=6
pulseaudiopcm-title=PCM on @HOSTNAME@
pulseaudiopcm-launch=pulsesrc device=upnp.monitor ! wavenc
Feel free to cut this list down to just the formats you want (do not forget to modify launch-items accordingly). MP3 is lossy and as such lowers audio quality and has a high latency. FLAC is losless and should have low latency but XBMC refuses to play the FLAC stream. It complains about the -lack of- metadata and similar issues have been solved in GStreamer 0.11 while I am using 0.10. I assume a newer Ubuntu will fix this. Finally PCM is uncompressed wave but requires the most bandwidth - I am using this option.
You will end up with something like this:
++=> (1) PulseAudio => HTTP stream from internal audio ++
Ubuntu ++=> (2) Rygel => HTTP audio stream from GstLaunch ++=> network => XBMC
++=> (3) Rygel UPnP server ++
Note that (1) would be the preferred option as its built into Ubuntu but currently does not work in XBMC.
Start Rygel and find the GstLaunch entry in the UPnP listing. Pick one of the streams to start listening, enjoy!
I had to perform this emergency procedure every now and then and I seem to reinvent the wheel every time so I reckoned it was time to document it.
This time, its a failing master drive in a simple home server - without a RAID. The SMART monitoring has not yet caught on but the self-tests fail and some files are read-only as writes to the drive fail. Also the logs are full with SATA errors like:
Apr 29 10:23:57 rivenscryr smartd: Device: /dev/sda, 18 Currently unreadable (pending) sectors
To save the installation and all the files, I want to clone or backup the entire root filesystem (which is ext3, but that is not relevant) to a new drive (formatted ext4) in another machine. The reason to do this between machines can be numerous: perhaps you are migrating a live machine or (in this case) perhaps you worry that the current drive may fail when you power-cycle the system when the replacement drive is installed.
Backup/Clone Over Network Recipe
- Mount the root filesystem of the original machine on another location in order to have a clean copy:
mkdir /mnt/rootfs && mount / /mnt/rootfs -o bindCheck if it worked by listing the '/mnt/rootfs/' folder. Note that '/mnt/rootfs/proc' will be empty and 'dev' will be empty or very sparse.
- Use netcat and tar on the receiving machine (my case: random system with Ubuntu on USB stick and new HDD plugged in) to receive and write the data.
nc -l 7777 | tar -xz -C /mnt/targetdir
[li]Use tar and netcat on the original machine to stream-copy the root filesystem over the network.
[color=red]Big fat warning:[/color] My cloning is done on an internal, trusted network. You **will be cloning using an unsecured stream** over this network.
tar -czp --atime-preserve --numeric-owner --xattrs --recursion /mnt/rootfs | nc remotehost 7777Heres what all these options do:
[li]-c: Create a new archive
[li]-z: Use GZip compression to speed up the transfer
[li]-p: Preserve file permissions
[li]--atime-preserve: Do not update the accessed timestamp
[li]--numeric-owner: Copy using numeric ids only - usefull when cloning into a foreign system
[li]--xattrs: Include ACL attributes and SElinux attributes
[li]--recursion: Recurse down into sub-folders
[li]--ignore-failed-read: Useful when a drive is heavily damaged and you only care to extract as much data as possible. Note: do not enable this by default as you might end up with an unusable clone if some files are missing. (Aka, this is a last resort option for non-functional clones)