07/17/2013, 02:52 PM
I'm new here. Recently picked up an HP Touchpad for fiddling around and stuff. No experience with WebOS devices until now, plenty of experience with Linux, especially of the doing-stuff-from-the-command-line variety. My apologies if this question is better suited for another subboard.
Long story short, I modified a file the md5 hashsum of which is stored in the /md5sums.gz file, before I knew of this whole /md5sums.gz thing. Near as I can tell, this prevents the system from booting. It boots enough that I can get a novacom/novaterm connection going over usb, and it charges, but visually it never gets past the non-glowing HP circle logo.
I have the exact code (it was a plaintext file) that was inside the file before I modified it, but not the exact characters (I suspect some of the whitespace got copy-pasted to where I was saving it wrongly) so even after undoing the edit I have been unable to get the file back to matching the original's MD5 hash.
I also tried unpacking the /md5sums.gz file with gzip (on computer), editing the hash for the relevant file, packing it up again (tried with both gzip on computer and the one on-device), hoping that it would notice the hashes now matched again, and would boot properly.
However, it does not. I'm looking for ideas on how else to try to fix this without doctoring (or even ideas on which logs would have the relevant information - I found some logs in /var/log/, but at a skim none of them seemed to have anything relevant, but I may have missed it). Worst case scenario I can doctor the thing, but I find the "screw it and start over" route unappealing vs. the "figure out what went wrong and manually fix it" route.
On the topic of WebOS Doctor though, I have also been unable to figure out by googling how to get at the archive that WebOS Doctor uses to store the files that get flashed onto the device - I would be interested in knowing how to do that because then I should be able to extract the original copy of the file I modified, which would presumably have the correct md5 hashsum, and then I could maybe restore that and the original /md5sums.gz and perhaps that would fix the problem.
--- Details/Technicalities for those interested ---
The Touchpad in question also has Android installed. I can boot just fine into Android, the clockworkmod recovery, or the webos recovery. It's just the WebOS part that's not booting.
The file I had the bright idea to tweak was /etc/event.d/LunaSysMgr. Note: I am well aware of the seriousness of tweaking /etc/event.d/ files and that it can make things not boot if you screw up. The real problem came from the fact that the way I backed up the file might have messed things up (I accidentally clobbered the on-device copy so I had to copy-paste it from a previous 'cat' command's output, and the terminal I was using at the time converted the tabs into 8 spaces each. Consequently, even after deleting the line I added, the hashsum doesn't match. I believe it is this that is messing up the boot, rather than my initial change.
As for why and how I modified /etc/event.d/LunaSysMgr: I have this thing where any modification I do on a device, I try to do from on-device without other computers or devices if it seems possible. I'm spoiled by the Nokia N900 where that is virtually always doable. So I was attempting to install one of the virtual keyboard layout patches. As you all presumably know, those patches are applied to the binary /usr/bin/LunaSysMgr, and then the patched LunaSysMgr is copied over the stock one. Which is impossible unless LunaSysMgr itself is stopped, which you can't (near as I can tell) stop from on-board the device without the device freezing). I initially tried commands like "/sbin/initctl stop LunaSysMgr && cp /path/to/LunaSysMgr.patched /usr/bin/LunaSysMgr && /sbin/initctl start LunaSysMgr" from wterm. This still froze the device and failed to copy the patched binary over, let alone restart LunaSysMgr, suggesting that when LunaSysMgr is killed, whatever shell command wterm was executing goes with it too.
After realizing that that didn't work, I decided to find a boot or shutdown script that would be executed at a moment when LunaSysMgr wasn't running. I settled on /etc/event.d/LunaSysMgr because it seemed as good a place to try as any, and inserted the line "cp /path/to/LunaSysMgr.patched /usr/bin/LunaSysMgr" (with a tab at the beginning of that line) (and altered nothing else).