Related
A few weeks ago my SD card went bad on me. I have been using Gingershedbread as my ROM and see there are some updates, however, since I don't have an SD card, the "normal" method of loading the zip onto the SD card obviously won't work for me.
My question is: Is there a way to flash a ROM zip from a pc (windows) to my phone without an SD card? I know you can put the zip on the data partition, then use "recovery --update_package=DATA:rom.zip" (through adb), however, when trying to copy the rom I get a message saying that there is no space left.
As of now, the only thing I know of is to do a full wipe and factory reset, then push the ROM zip to my phone, but I don't necessarily want to do this every time.
I have also tried fastboot and using mkyaffs2image to create a system.img from the ROM's system folder in the zip file, but I am not doing something right.
I run "mkyaffs2image c:\rom\system\ c:\system.img"
then with my phone in fastboot, I "fastboot flash system c:\system.img"
and "fastboot flash boot c:\rom\boot.img".
I restart the phone in recovery mode, load gapps and xtrCache, but then it reboots, sits on black screen for a few seconds, then reboots into recovery.
I have tried erasing system and boot first, but that didn't seem to help.
I first tried just flashing system.img, but that didn't work.
Not sure what I am doing wrong. Is there a way to take a ROM zip and create a system.img and boot.img that can be flashed through fastboot without an SD card? OR, is it possible to flash a ROM zip without transferring the file to my phone first? Any help would be appreciated.
I don't think that there is an answer to your question which is both complete and also short.
So, here goes with the long answer.
First, a yaffs2 image file (e.g. system.img) is not compressed, so it is quite large - for things like the HTC factory/stock ROMs, it can be bigger than the cache partition. I don't know if the cache partition is actually used when you push things with fastboot, but experimentally, I have run into the problem that when attempting to do a
Code:
fastboot flash system my-yaffs2-system.img
fastboot gives you get an error about being out of room.
Second, and more importantly, the file modes (permissions) and user:group ownership of files in the /system mount point are extremely critical to proper operation of Android. If you have files sitting on a Windoze machine filesystem (either FAT32 or NTFS), all this information will be lost even before you create your "yaffs2" image file. (Not only that, but all symbolic links will be missing, too). This is why you observe that ROM files have instructions in their "update-script" (or "updater-script") command files for setting file & directory ownership, file permission modes, creating symlinks, et cetera.
Third - even if you use a linux OS to unpack yaffs2 images, and run as root when you are doing so, a lot of the "unyaffs" programs that are lying around do not even bother to extract things like user:group ownership or file modes - so you are basically screwed as soon as you unpack a yaffs2 image file on a PC, no matter whether it is Windows or Linux/Unix/OS-X.
Fourth, I am not sure that it is even a good idea in the first place to be "flashing" yaffs2 images. The "fastboot flash" command merely writes whatever you pass to it as a long linear blob of bytes, and there is no evidence to suggest that the yaffs formatting used in the archive is the same formatting used by the kernel. When "Nandroid" runs to restore a system.img or data.img file onto the phone, it does not write the image as a linear blob of bytes: it actually mounts the filesystem in question, cleans it up with a "rm -rf *" command, and then manually unpacks the yaffs2 image file into the mounted file system, one file at a time. (Fortunately in this case, it actually restores things like symlinks, file permissions, and file/directory user:group ownership information). This insures that the low-level yaffs2 formatting is *identical* to what the kernel expects, because it is the kernel that creates it.
There is a solution, but it is tedious enough that you really ought to ask the question, "Why don't I go out and buy a replacement SD card for 10 bucks instead of wasting a huge amount of time?"
Here's the solution:
You mount /system, clean it up manually, use adb to push the files recursively from wherever you have them stored on your PC, and then afterwards you run a custom (signed) installer .zip file which has been modified so that it only contains the "symlink" and permission-setting commands - you delete the "format" and "extract" commands from that command file, since you have manually put all the files into /system. Either that or you manually adjust the permissions and user:group ownership information by hand.
Obviously, since you don't have an /sdcard any longer, you will need to put this flashable, custom .zip file in /cache, and then create a one-line command file at /cache/recovery/command that points at the flashable .zip file in /cache. (This is the way the the OTAs work, and also how ROM Manager is able to customize the recovery when it boots).
Is this a lot of work? Yeah, you betcha.
It seems like running down to wally world to get a cheap SD card might be a little more fun.
Thanks for the info. I figured getting a new SD would be the best solution.
I knew about the symlink and file permission stuff and was trying to flash a system img then run a zip to ser that info., but couldn't get it to work. Sounds like using fastboot might be a bad idea.
For now I think I will just have to find a rom and stick with it for a while.
I am nearing an upgrade for a new phone and looking at the Thunderbolt, which comes with an SD so I don't want to buy one just yet.
Thanks for your help.
Sent from my ERIS GSBv2.1 using XDA App
kgunnIT said:
then run a zip to ser that info., but couldn't get it to work.
Click to expand...
Click to collapse
If you know how to sign ROMs, it's really not a hard hack to launch an installer of the type you mention.
And, now that I've just said that, I think I have another, simpler, idea.
But first:
[SIZE=+2]How To Launch a (smallish) .zip-based Flash That's Not On the SD Card.[/SIZE]
All of the recoveries - both the stock and custom recoveries - look for a "command" file when they first start up.
It literally is named "command", i.e.: /cache/recovery/command
... and it is a simple text file with as few as one line(s) in it.
Here is an example from the most recent OTA of the contents of /cache/recovery/command:
Code:
--update_package=CACHE:8e3b63f96149.OTA_Desire_C_Verizon_WWE_2.37.605.4_2.36.605.1_release.zip
basically, it's just a single line with the following format:
--update_package=CACHE:filename.zip
So, if you are trying to get an installer to run without an SD card, you would:
1) Boot to Amon_RA
2) Wipe the cache if necessary (wipe -> wipe data/factory reset also clears /cache)
3) Push your zip file to cache:
Code:
adb push mycustominstall.zip /cache/
4) Create a command file (say, named "command.txt") with the contents:
Code:
--update_package=CACHE:mycustominstall.zip
5) Push it to the phone:
Code:
adb push command.txt /cache/recovery/command
6) reboot directly back into recovery with
Code:
adb shell reboot recovery
When the recovery boots up again, it will immediately start unpacking your "mycustominstall.zip" file.
After I thought this all the way through, I realized, though: a lot of the ROM files are only about 100 MB, and cache is about 128 Mb, so
.... wait for it .....
... wait for it ....
it might be a worthwhile experiment to just push an untouched ROM file right to cache and then use that ROM file's name in your "command" file.
So long as /sbin/recovery does not unpack files to /cache (I can't remember if it does this or not!), you could use original ROM files -- just what you wanted originally. If it unpacks things to cache, though, it will only get part way through the install and fail.
It's worth a shot; if it fails, you'll have a mess that is no worse to clean up than what you've presently got. (If it fails, to be on the safe side it might be wise to go in using adb and clean things up in /cache a little bit so that the next recovery boot has some wiggle room in /cache - e.g. "adb shell rm -rf /cache/*" )
bftb0
bftb0 said:
If you know how to sign ROMs, it's really not a hard hack to launch an installer of the type you mention.
And, now that I've just said that, I think I have another, simpler, idea.
But first:
[SIZE=+2]How To Launch a (smallish) .zip-based Flash That's Not On the SD Card.[/SIZE]
All of the recoveries - both the stock and custom recoveries - look for a "command" file when they first start up.
It literally is named "command", i.e.: /cache/recovery/command
... and it is a simple text file with as few as one line(s) in it.
Here is an example from the most recent OTA of the contents of /cache/recovery/command:
Code:
--update_package=CACHE:8e3b63f96149.OTA_Desire_C_Verizon_WWE_2.37.605.4_2.36.605.1_release.zip
basically, it's just a single line with the following format:
--update_package=CACHE:filename.zip
So, if you are trying to get an installer to run without an SD card, you would:
1) Boot to Amon_RA
2) Wipe the cache if necessary (wipe -> wipe data/factory reset also clears /cache)
3) Push your zip file to cache:
Code:
adb push mycustominstall.zip /cache/
4) Create a command file (say, named "command.txt") with the contents:
Code:
--update_package=CACHE:mycustominstall.zip
5) Push it to the phone:
Code:
adb push command.txt /cache/recovery/command
6) reboot directly back into recovery with
Code:
adb shell reboot recovery
When the recovery boots up again, it will immediately start unpacking your "mycustominstall.zip" file.
After I thought this all the way through, I realized, though: a lot of the ROM files are only about 100 MB, and cache is about 128 Mb, so
.... wait for it .....
... wait for it ....
it might be a worthwhile experiment to just push an untouched ROM file right to cache and then use that ROM file's name in your "command" file.
So long as /sbin/recovery does not unpack files to /cache (I can't remember if it does this or not!), you could use original ROM files -- just what you wanted originally. If it unpacks things to cache, though, it will only get part way through the install and fail.
It's worth a shot; if it fails, you'll have a mess that is no worse to clean up than what you've presently got. (If it fails, to be on the safe side it might be wise to go in using adb and clean things up in /cache a little bit so that the next recovery boot has some wiggle room in /cache - e.g. "adb shell rm -rf /cache/*" )
bftb0
Click to expand...
Click to collapse
You always find the one thousand and ONETH way to skin a cat. Hehehehe...
Thankyou so much for this this alowed me to flash a rom on my phone which can't detect any sd cards and i stupidly wiped it before relising the sd card wasnt being detected!
sum_guy55 said:
Thankyou so much for this this alowed me to flash a rom on my phone which can't detect any sd cards and i stupidly wiped it before relising the sd card wasnt being detected!
Click to expand...
Click to collapse
very good, sum_guy55!
At least all that typing wasn' t in vain.
Out of curiosity, how big was the ROM file you used?
bftb0
Been meaning to post this:
Thanks for your posts roirraW "edor" ehT and bftb0 for posting this. I also was able to clear the cache and push the ROM and update.
However, I have xtrCMCache2cache on my phone, so the dalvik-cache was moved from /data/ to /cache/. After doing a wipe of dalvik-cache from Amon recovery, the folder in /cache/ was not emptied out. I went ahead and cleaned it manually, which freed up enough space to push the ROM.
Is this behavior expected using cache2cache and wiping dalvik-cache from recovery? I guess it would be since the dalvik-cache was moved.
Anyway, after clearing the dalvik folder, I was able to push GSBv2.4 to my phone, as well as gapps and xtrCMCache2cache, a total of almost 80 MB. Rebooted and all was well.
Thanks again for your help.
kgunnIT said:
Been meaning to post this:
Thanks for your posts roirraW "edor" ehT and bftb0 for posting this. I also was able to clear the cache and push the ROM and update.
However, I have xtrCMCache2cache on my phone, so the dalvik-cache was moved from /data/ to /cache/. After doing a wipe of dalvik-cache from Amon recovery, the folder in /cache/ was not emptied out. I went ahead and cleaned it manually, which freed up enough space to push the ROM.
Is this behavior expected using cache2cache and wiping dalvik-cache from recovery? I guess it would be since the dalvik-cache was moved.
Anyway, after clearing the dalvik folder, I was able to push GSBv2.4 to my phone, as well as gapps and xtrCMCache2cache, a total of almost 80 MB. Rebooted and all was well.
Thanks again for your help.
Click to expand...
Click to collapse
It was all bftb0. Interesting, I had once asked if cache was definitely wiped from Amon after it was moved. The consensus was that it should. I shall be anticipating some light shed on this.
Sent from my Gingerbread Eris via Tapatalk
Well, Amon_RA has no idea whether you are using cache2cache; I suppose we would need to look at the code to figure out how it behaves.
If it mounts /data and then does something like
rm -rf /data/dalvik-cache
there is a chance that the symbolic link is not followed, which would explain what kgunnIT observed.
Normally, if you are flashing a new ROM in a full-wipe fashion, the " wipe data/factory reset" menu option clears both /data and /cache, so in that case it is irrelevant that the "wipe dalvik-cache" is a no-op.
If you are overflashing, it's not obvious that you need to wipe the dalvik-cache... at least for the market apps normally stored in /data/app, although it seems like it would be a good idea to do so, as the system apps could be changing.
Note that even when cache2cache is not in use, the Amon_RA menu item "wipe dalvik-cache" never works as intended for froyo & gingerbread ROMs - the system apps have their dalvik-cache stored in /cache, and this never gets touched by Amon_RA with that menu operation.
BTW... for what it's worth, the ClockworkMod recoveryhas a menu entry for wiping only the cache.
bftb0
bftb0 said:
BTW... for what it's worth, the ClockworkMod recoveryhas a menu entry for wiping only the cache.
bftb0
Click to expand...
Click to collapse
Does ClockworkMod recovery work ok on the Droid Eris? I was going to load it on, but saw some people posting that it bricked their phones, so now I am skeptical. I will do more research and see if this is something I want to do. Thanks for your insight.
kgunnIT said:
Does ClockworkMod recovery work ok on the Droid Eris? I was going to load it on, but saw some people posting that it bricked their phones, so now I am skeptical. I will do more research and see if this is something I want to do. Thanks for your insight.
Click to expand...
Click to collapse
There is a version of Amon_RA (the trackball-optional version) that also allows you to format cache. You can find out more about it here: http://androidforums.com/eris-all-t...2-custom-recovery-trackball-not-required.html
That said, if you have ROM Manager, you can have Clockwork Recovery start as a stub within Amon_RA just from ROM Manager (the first option copies a file called update.zip to the root of your SD card, and the second, "Reboot into Recovery", starts Amon_RA with a script to flash update.zip, which starts Clockwork.) In fact, once update.zip is on the SD card, you can start Amon_RA as you always do, go to the Flash a zip from SD card menu, choose update .zip, and it will start Clockwork, if you want to do it that way. However, the drawback to this is that you can't go back to Amon_RA without shutting down the phone and then restarting in Recovery again, so I just find it easier to use the trackball-optional version of Amon_RA.
I think every person who has bricked their Eris while running Clockwork was running Clockwork Recovery as their main recovery image, and not in the way that I described in the last paragraph. (Though don't hold me to that ...)
kgunnIT said:
Does ClockworkMod recovery work ok on the Droid Eris? I was going to load it on, but saw some people posting that it bricked their phones, so now I am skeptical. I will do more research and see if this is something I want to do. Thanks for your insight.
Click to expand...
Click to collapse
I've been using it through ROM Manager since last August or so, I use it all the time.
I setup my touchpad to dual boot webOS or CynogenMod7. Now I've replaced CM7 with MIUI. And regardless, 'cynogenmod' and 'miui' are Greek to my wife. Is there a way that I can change the 'cynogenmod' menu option in moboot so that it says 'Android' instead?
I don't know about changing the labels, but I know the package called cyboot in preware will let you change the default and timeout.
cu_shane said:
I setup my touchpad to dual boot webOS or CynogenMod7. Now I've replaced CM7 with MIUI. And regardless, 'cynogenmod' and 'miui' are Greek to my wife. Is there a way that I can change the 'cynogenmod' menu option in moboot so that it says 'Android' instead?
Click to expand...
Click to collapse
using either webos (xecutah) or android (term emulator) mount (boot partition is partition 13 in dev/block/ in android) or remount ( webos using xterm the command is mount -o remount,rw /boot)
once you mounted boot with rw privs just rename uImage extension (uImage.cyanogenmod to uImage.Android) then unmount (using umount) or remount ro (mount -o remount,ro /boot)
moboot will the show the differences,just remember to change your moboot.default to whatever name you chose)
quarlow said:
I don't know about changing the labels, but I know the package called cyboot in preware will let you change the default and timeout.
Click to expand...
Click to collapse
Thanks!!! This helped me out a ton!
Tagging this one for later, I will be doing the same.
In my case just for myself as I like to customize the device a bit more than most people probably care about.
Know this is an old thread, but I thought I could mention you can change the labels easily in webOS, instead of with terminal commands in android. Using Internalz Pro (preware package) with master mode enabled you can just rename them. Navigate to /boot/ and rename the file extension. Wit TWRP and a solid CM9 build I went to revisit this, and thought I would share.
Be Advised: if you use CyBoot Preware to set the next boot option to Andriod, CM9 a0 and a0.5 doesn't clear the /Boot/moboot.next file on sucsessful launch. The result is you cannot get MoBoot options back as it keeps going straight to CM9.
In one case, reinstall of MoBoot from ACMEinstaller2 couldn't clear the file either.
** This is only needed for those that tried to apply the update and it failed. **
So I saw a tweet from our friends at WebOS Internals that people were having issues upgrading their Touchpads to WebOS 3.0.5 with Android (CM) installed. Their suggestion was to run the Android Removal utility from PreWare and reinstall after the upgrade. I didn't want to go through a reinstall of CM so I came up with the follow instructions. It worked well for me, I hope it works for you...
** As with anything you do to your device, this is done at your own risk. **
These instructions are for Windows but you should be able to easily adapt this to your OS of choice. You will need to have Palm/HP's novacom drivers installed.
Boot the Touchpad into WebOS and attach your Touchpad to your via USB in Charge only mode.
Run ->
Code:
"C:\Program Files\Palm, Inc\terminal\novaterm.bat"
From the menu File --> Connect and Accept the little pop-up.
Run these commands at the shell prompt to create a new directory on the /media partition, copy your uImages to the /media partition, remount /boot and delete the Android related uImage files from /boot. You may have an error deleting one of the files if you don't have CWM or TWRP installed.
Code:
mkdir /media/internal/uimage
cp /boot/uImage.* /media/internal/uimage/
mount -o remount,rw /boot
rm /boot/uImage.CyanogenMod
rm /boot/uImage.ClockworkMod
rm /boot/uImage.TWRP
Do the update via the WebOS System Updates app. Once the update is complete do the following:
In NovaCom do File --> Connect again.
At the shell prompt execute the following:
Code:
mount -o remount,rw /boot
cp /media/internal/uimage/uImage.CyanogenMod /boot
cp /media/internal/uimage/uImage.ClockworkMod /boot
cp /media/internal/uimage/uImage.TWRP /boot
That should do it. Once you reboot your TouchPad you should be able to get into CM/Android.
Nice post+ I will be testing this out Tom
I updated to 3.0.5, and it would not boot back into CM7 (reboot spin), so I went into recovery mode, and re-flashed the CM7 3.5 Alpha zip file, and it all worked for me.
Just did this on my touchpad, worked like a charm. Thanks!
Thanks nice information
I updated webos and had no issues. You should probably make a nandroid beforehand just incase you have to doctor. You can always restore after you put mboot and cm back on. I have mboot 0.3.5 too.
Sent from my GT-i9100 using Tapatalk
Worked great, thx for the info
Good info!!
Thanks
Personally I upgraded before seeing this and I only removed uimage.TWRP and it worked for me. (I also uninstalled UberKernel as a precaution)
Did this and it updated it but now I can't get into moboot any suggestions?
i get read only file system on first mkdir command
can;t proceed
lvpre said:
I updated webos and had no issues. You should probably make a nandroid beforehand just incase you have to doctor. You can always restore after you put mboot and cm back on. I have mboot 0.3.5 too.
Sent from my GT-i9100 using Tapatalk
Click to expand...
Click to collapse
I guess I was one of the lucky ones too because I didn't have any problems updating webos either. I did the system update from the app in webos to go from 3.0.2 to 3.0.5 and when it was done it rebooted into webos and said the update was successful. Once I powered it off and back on moboot was intact and cm7 booted normally. This thread was my backup cause I was definitely crossing my fingers lol. Now I'm off to get alpha 2!
Followed your instructions, performed the update over CM9 a2.
All is good, thank you.
With CM9 A2 released I finally took the plunge and left CM7.
I uninstalled uberkernal in webos, used webosdoctor to upgrade to 3.0.5 without any issues, and then loaded up CM9 with the latest gapps, CWM, and moboot.
I was running Bricked Kang but installed the new build of cherry but now the old bricked rom's kernal is still a boot option, how can i remove this kernal from my touchpad and delete the entry in moboot?
I had the Bricked installed myself, and decided to go back to the stock CM9 kernel (since I was having FC issues with certain apps).
Here's what I did:
Open up Terminal Emulator
Type the following:
Code:
su <enter>
mount -t remount,rw /boot <enter>
cd /boot <enter>
rm uImage.CM <tab> <enter> (press Tab until the CM-Bricked is filled in)
echo "CyanogenMod" > moboot.default <enter> (this will set you back to defaulting CyanogenMod. If you want another, use the name of the uImage.<whatever> for Cherry (just put everything after the uImage. part)
reboot <enter>
That'll remove the Bricked Kernel from your boot options, and set your default to Cherry (or in my example, CyanogenMod). Make sure you have the proper Wifi modules installed from your Cherry install, and you should be good to go.
Hope that helps, mate.
I'm having the same problem and that proposed solution did not work...I got a Read only file error...thanks, though...
You have to make sure you mount the /boot partition before you try and do the changed. If it isn't mounted, you get that error.
Sent from my cm_tenderloin using xda premium
ve6ay said:
You have to make sure you mount the /boot partition before you try and do the changed. If it isn't mounted, you get that error.
Sent from my cm_tenderloin using xda premium
Click to expand...
Click to collapse
Could you elaborate on how to do that please? The CM_Bricked thing has been bothering me as well.
Thanks in advance!
I had the exact problem and instead of playing around with the instructions I just went to a backup I had before the install.
It worked like a charm for me. If you have a recent backup on CWM don't hesitate to use it .
Hi.
First, a disclaimer... I will not be responsible for you messing this up and bricking your device. I am only outlining a guide which I figured out and used to get my TP setup the way I wanted. DO NOT come to me for support, as I am not a dev and really have no time to save anyone from their doom...
I used RootExplorer (Paid App -
https://market.android.com/details?...sImNvbS5zcGVlZHNvZnR3YXJlLnJvb3RleHBsb3JlciJd) to do the steps outlined below. You may use any file manager of your choice, granted that it gives you root access with read/write access to /boot folder. Please make sure you backup anything you plan on changing by making copies and moving them to a safe location... Don't way I did not warn you... ^_^
With that said... I hope this helps some one... ^_^
I have just figured this thing out and soon after noticed that there is a thread with a video showing the methods to remove the extra UImage from the moboot boot menu.
The video shown here http://forum.xda-developers.com/showthread.php?t=1511050 is a great way to remove the redundant UImages from the list except I figured out a easier method and also a way to choose the default OS (WebOS or CM or CN) to load when TP boots, which the video does not get into.
Once I updated to the latest CM9 V2, I rebooted and my TP wanted to boot into the Bricked_Kernel which I did not want. I would, in this case as many of you, scroll (within 3 seconds) to the right entry to boot or else, I would be needing to reboot again.
So here is what I did.
Boot into your Rom (CM9 in my case)
Install RootExplorer from the market.
Launch RootExplorer. You will be asked to grant SU. Press Yes.
Navigate into /boot folder.
Click on the Mount R/W. This will change to Mount R/O. Now you have read and write (important) access to the contents of this folder.
Find the entry UImage.Bricked_Kernel (It might be UImage.ClassicNerd or something else).
Long press the UImage you want to delete (or modify).
Delete (rename, if you want to keep it for some reason) the UImage of the old kernel
Click on the Mount R/O to set the folder for read only access before you exit.
Now when you reboot, you will notice that the MoBoot menu is missing the entry for the extra kernel that was there before. The problem now is that the default boot selection has been set to WebOS. This is because the device is looking for the missing default entry in the boot menu. So it's just going to the top of the list. If this is what you want, you can stop here but if this is not the OS you want to load by default, follow the next few steps.
Launch RootExplorer
Navigate into /boot
Click on the Mount R/W to set write access.
Find the entry moboot.default
Long press moboot.default and choose Open in Test Editor.
The entry in this text file will show the OS that MoBoot will choose to load by default. Mine had an entry "Bricked_Kernel"
Delete the entry in this file and retype the OS of your choice. Mine was "CyanogenMod" (without the "").
Exit. You will be told that RootExplorer made a moboot.default.bak was created for safety. If you are using other file explorers you might not get the automatic backup. So please make a back up of this file before you change the entry.
Click Mount R/O to set the permissions to read only before exiting.
Reboot.
Now you will see that the MoBoot has the right OS as the default OS.
For those of you that desire to make the WebOS as the default OS you can type WebOS in the moboot.default. Well, good luck.
PLEASE DO NOT CHANGE FILES IN THE /BOOT IF YOU ARE NOT SURE WHAT YOU ARE DOING!!! Only follow this guide if you are comfortable doing so!!!
Good stuff, man.
The major difference between my tutorial and yours is that Root Explorer is a paid app, whereas my tutorial uses ES File Explorer which is free.
If you have Root Explorer though, this is definitely easier.
Choosing Default OS
Or plug in the device to computer and type:
adb shell [enter]
mount -o remount,rw /boot [enter]
ls | grep uImage [enter]
sample output:
Code:
uImage-2.6.35-palm-tenderloin
uImage.ClockworkMod
uImage.CyanogenMod
uImage.moboot
uImage.webOS
echo "CyanogenMod" > /boot/moboot.default [enter]
exit [enter]
done
nomadman said:
Choosing Default OS
Or plug in the device to computer and type:
adb shell [enter]
mount -o remount,rw /boot [enter]
ls | grep uImage [enter]
sample output:
Code:
uImage-2.6.35-palm-tenderloin
uImage.ClockworkMod
uImage.CyanogenMod
uImage.moboot
uImage.webOS
echo "CyanogenMod" > /boot/moboot.default [enter]
exit [enter]
done
Click to expand...
Click to collapse
The thing is... even though I am not a total noob when it comes to using ADB commands, it's usually not the most convenient to have to deal with connecting TP to a PC, putting it in USB mode, Command Prompt, etc... a lot of steps... What I described can be done within the TP... which was my case...
cvcduty said:
The thing is... even though I am not a total noob when it comes to using ADB commands, it's usually not the most convenient to have to deal with connecting TP to a PC, putting it in USB mode, Command Prompt, etc... a lot of steps... What I described can be done within the TP... which was my case...
Click to expand...
Click to collapse
well there's more than one way to skin a robot. i personally think it's even easier running the commands in android terminal than plugging into a pc.
what if i dont have the moboot default file?
phonetec said:
what if i dont have the moboot default file?
Click to expand...
Click to collapse
Ok... can you describe your situation with bit more detail?
Are you running CM9? Or any other ICS or GB custom rom?
How did you install your android rom?
I am not aware (since I am not a dev and no where near an expert on the matter) a way to install Android other than the CM7 or CM9 method using MoBoot to push the files to TP...
So if you can outline some details of your situation, I hope someone can shed some light for you...
im running cm9 alpha 2, installed using cwm, after using acmeinstall of cm7, it defaults to webOS when i boot up and I hate it
phonetec said:
im running cm9 alpha 2, installed using cwm, after using acmeinstall of cm7, it defaults to webOS when i boot up and I hate it
Click to expand...
Click to collapse
So if you don't have Moboot in your system anymore, I think you can push it to the TP via cminstall and get the OS chooser back.
How do you get into CWM? Do you see any UImage.Clockworkmod, UImage.Cyanogemod, etc? Are you missing moboot.default? I wonder if you can just create the moboot.default file with the CyanogeMod as it's content and see if MoBoot will read the file...
cvcduty said:
So if you don't have Moboot in your system anymore, I think you can push it to the TP via cminstall and get the OS chooser back.
How do you get into CWM? Do you see any UImage.Clockworkmod, UImage.Cyanogemod, etc? Are you missing moboot.default? I wonder if you can just create the moboot.default file with the CyanogeMod as it's content and see if MoBoot will read the file...
Click to expand...
Click to collapse
i still have moboot injstalled, but when I go in /boot I dont have a file called moboot.default
phonetec said:
i still have moboot injstalled, but when I go in /boot I dont have a file called moboot.default
Click to expand...
Click to collapse
I think if moboot is still installed, it's probably looking for the moboot.default file but since in your case, it's missing, it's booting what ever is on the top of the list of the UImages. I think you can simply create a text file and name it moboot.default in the /boot directory. As the content of the text file put CyanogenMod. Change the permissions of this file once it's placed in the /boot directory to rw_r__r__ (same as other files in the folder). Change the folder to R/O and reboot... I think it will work.
Worst case I guess you will have to push moboot via pc again...
Good luck...
yeah...that did not work....oh well, I have to send it to HP for repair anyway so i'm not going to worry too much about it
phonetec said:
yeah...that did not work....oh well, I have to send it to HP for repair anyway so i'm not going to worry too much about it
Click to expand...
Click to collapse
wait... you said you used the cm7 acmeinstaller? You shouldn't be using that if you installed cm9.
Sent from my HP Touchpad with CM9!
itsDefying said:
wait... you said you used the cm7 acmeinstaller? You shouldn't be using that if you installed cm9.
Sent from my HP Touchpad with CM9!
Click to expand...
Click to collapse
Good catch. I missed that one. He should have used the new moboot. If he used CM7 acmeinstaller he probably meant he also used the old moboot also.
Why not just edit the boot via CyBoot? Just about to try it myself.....
http://www.webosnation.com/cyboot
Well, it works after a fashion. Boot into WebOS, open up PreWare, install CyBoot. Launch it, and change the default boot to Android. Reboot, and the correct CyanogenMod entry is selected by default, but it doesn't autoboot - waits for you to hit the home key. Still, better than scrabbling for the volume key and a relatively quick way to (semi) fix the issue if you don't have RootExplorer.
dirtyfrog said:
Why not just edit the boot via CyBoot? Just about to try it myself.....
http://www.webosnation.com/cyboot
Well, it works after a fashion. Boot into WebOS, open up PreWare, install CyBoot. Launch it, and change the default boot to Android. Reboot, and the correct CyanogenMod entry is selected by default, but it doesn't autoboot - waits for you to hit the home key. Still, better than scrabbling for the volume key and a relatively quick way to (semi) fix the issue if you don't have RootExplorer.
Click to expand...
Click to collapse
Very good point. As some one said, there is more then one way to skin a cat.
I found that if you use terminal emulator and entering the following is the easiest way to set the default.
su
cd /boot
mount -o rw,remount /boot
echo CyanogenMod > moboot.default
Follow this entry exactly with the spaces them reboot, it will set your default to CyanogenMod. If you want to use another default just replace CyanogenMod with whatever you are using.
This is fast and easy.
Thank me if this helps.
travisross69 said:
I found that if you use terminal emulator and entering the following is the easiest way to set the default.
su
cd /boot
mount -o rw,remount /boot
echo CyanogenMod > moboot.default
Follow this entry exactly with the spaces them reboot, it will set your default to CyanogenMod. If you want to use another default just replace CyanogenMod with whatever you are using.
This is fast and easy.
Thank me if this helps.
Click to expand...
Click to collapse
That's perfect! The point is for people to able to fix this easily on the fly. So if you don't have access to Rootexplorer, this method can be used to change the default OS the TP would load at reboot. Thanks.