Database Develop

[Q] One-Click Root/Custom ROM

Just wondering if anyone is working on a one-click root or custom ROM (obviously, for a donation!!!) for the NC? I am going to take the time to root this weekend, but would obviously love to just DL something and flash it.

Well, one click isn't really one click. There are lots of other clicks involved, turn on computer clicks, go to download page clicks, download clicks, then load on SD card clicks or Start - Run - cmd clicks, then the closing windows clicks.
What I believe you should have been asking, without the sugarcoating of the "one-click" phrase, is: "If it isn't too much trouble, can I use your third Genie wish after you've rubbed the lamp? I'll donate, of course, not that it would matter because I can only assume one of those first two wishes was an insane amount of money"

devis said:
Well, one click isn't really one click. There are lots of other clicks involved, turn on computer clicks, go to download page clicks, download clicks, then load on SD card clicks or Start - Run - cmd clicks, then the closing windows clicks.
What I believe you should have been asking, without the sugarcoating of the "one-click" phrase, is: "If it isn't too much trouble, can I use your third Genie wish after you've rubbed the lamp? I'll donate, of course, not that it would matter because I can only assume one of those first two wishes was an insane amount of money"
Click to expand...
Click to collapse
Precisely, what you said!!!! lol. Believe me, I try...

coldbeverage said:
Precisely, what you said!!!! lol. Believe me, I try...
Click to expand...
Click to collapse
Glad you enjoyed reading it as much as I did writing it
Now... that out of the way, and in all seriousness, can I use that third wish from someone?

devis said:
Glad you enjoyed reading it as much as I did writing it
Now... that out of the way, and in all seriousness, can I use that third wish from someone?
Click to expand...
Click to collapse
I'll have more time to mess with this after this week is over. On my todo list is trying the BN kernel's video console support so we can at least write a message to the screen when Nooter is done rooting, and copying over superuser.apk and su and maybe Astro for starting out.
With the above we could have an almost-1-click root if someone could make the card writing process easier. It would be nice if we had a Linux boot CD or boot USB image that can reformat the card (check that it's a USB device first and ask the user!) to make the boot partition the whole disk automatically. Or someone could verify the rumor that HP's USB bootdisk maker formats the drive correctly.
I'm not the guy to do a 1-click root; exploits aren't my thing, but my goal is to make Nooter easy enough that we don't need to go that route.

My apologies if this has been covered....but with my eken slate, we use an update.zip file....the device automatically does a restore with this file if its present on the sd card

Until someone actually does a custom rom roll, it's unlikely that you're going to see one-click root. Since B&N decided to hide the Android menus that would allow us to side-load Apps, we have to boot from the SD image as part of the process.
I will look into making things a little easier though by adding a few items to the list of things that nooter does:
+ Install ADW and/or Zeam.
+ Install android.hardware.touchscreen.multitouch.xml to enable multi-touch on Android applications that support it.
+ Enable the installation of Non-Market Apps.
I personally took a shortcut when it came to rooting my personal Nook Color. Others may want to use this method as well.
(1) Write the nooter image to SD:
# dd if=nooter_sdcard_40mb.img of=/dev/<sdcard>
(2) Make sure that the Nook Color is powered off.
(3) Install the SD card with nooter written to it in the Nook Color
(4) Connect the Nook Color via USB to your computer. (Linux in my case). The Nook Color will power on all by its lonesome when it is connected to the USB.
(5) Wait a few minutes for nooter to do its thing. Seriously folks. Trying to time this down to seconds until you power the Nook Color off at this step is way overkill. Look at your watch. Add 5 minutes to whatever time it is. When 5 minutes have passed, you can safely go to step 6.
(6) Hold down the power button on your Nook Color for what seems like forever. You can count this one in seconds but, make sure that it has powered down. Without something on the screen, that is difficult to tell that it has powered down. I just timed it and an 8-10second continuous hold of the power button powered the Nook Color off. To be safe, lets say you hold it for 15 seconds.
(7) Remove the SD card from your Nook Color.
(8) Power your Nook Color Back on. (Hold the power button until you see the screen turn on. Duh!)
At this point, your Nook Color is should be rooted.
I then followed the instructions at nookdevs.com/NookColor_Rooting to use ADB to enable multi-touch and Non-Market Apps.

Thanks. I am just an IT lawyer who's only been at this android stuff since August so much to learn (for instance, figuring out what you wrote below.....I do try to learn and not constantly ask on here though)!!!!
johnopsec said:
Until someone actually does a custom rom roll, it's unlikely that you're going to see one-click root. Since B&N decided to hide the Android menus that would allow us to side-load Apps, we have to boot from the SD image as part of the process.
I will look into making things a little easier though by adding a few items to the list of things that nooter does:
+ Install ADW and/or Zeam.
+ Install android.hardware.touchscreen.multitouch.xml to enable multi-touch on Android applications that support it.
+ Enable the installation of Non-Market Apps.
I personally took a shortcut when it came to rooting my personal Nook Color. Others may want to use this method as well.
(1) Write the nooter image to SD:
# dd if=nooter_sdcard_40mb.img of=/dev/<sdcard>
(2) Make sure that the Nook Color is powered off.
(3) Install the SD card with nooter written to it in the Nook Color
(4) Connect the Nook Color via USB to your computer. (Linux in my case). The Nook Color will power on all by its lonesome when it is connected to the USB.
(5) Wait a few minutes for nooter to do its thing. Seriously folks. Trying to time this down to seconds until you power the Nook Color off at this step is way overkill. Look at your watch. Add 5 minutes to whatever time it is. When 5 minutes have passed, you can safely go to step 6.
(6) Hold down the power button on your Nook Color for what seems like forever. You can count this one in seconds but, make sure that it has powered down. Without something on the screen, that is difficult to tell that it has powered down. I just timed it and an 8-10second continuous hold of the power button powered the Nook Color off. To be safe, lets say you hold it for 15 seconds.
(7) Remove the SD card from your Nook Color.
(8) Power your Nook Color Back on. (Hold the power button until you see the screen turn on. Duh!)
At this point, your Nook Color is should be rooted.
I then followed the instructions at nookdevs.com/NookColor_Rooting to use ADB to enable multi-touch and Non-Market Apps.
Click to expand...
Click to collapse

coldbeverage said:
Thanks. I am just an IT lawyer who's only been at this android stuff since August so much to learn (for instance, figuring out what you wrote below.....I do try to learn and not constantly ask on here though)!!!!
Click to expand...
Click to collapse
No problem. Just so nobody is confused about anything I posted above: I take absolutely no credit for anything (especially nooter) in my post. I simply wrote down the steps I took using OTHER PEOPLES ideas and code.

Your simple instructions are pefect! The only thing I would add is for the Windows users to use WinImage on step 1.
Rooting really is easy; it is getting the ADB drivers to work properly (for us Windows users) that is the difficult step. If you can modify nooter to add the extra steps of writing the file to allow .apk installation; installing Astro or other file explorer; installing a launcher (Zeam seems to be a good choice); and maybe SlideME as a Market until the Google Market is figured out - I think the rooting process couldn't be much easier given the nature of the device!
johnopsec said:
Until someone actually does a custom rom roll, it's unlikely that you're going to see one-click root. Since B&N decided to hide the Android menus that would allow us to side-load Apps, we have to boot from the SD image as part of the process.
I will look into making things a little easier though by adding a few items to the list of things that nooter does:
+ Install ADW and/or Zeam.
+ Install android.hardware.touchscreen.multitouch.xml to enable multi-touch on Android applications that support it.
+ Enable the installation of Non-Market Apps.
I personally took a shortcut when it came to rooting my personal Nook Color. Others may want to use this method as well.
(1) Write the nooter image to SD:
# dd if=nooter_sdcard_40mb.img of=/dev/<sdcard>
(2) Make sure that the Nook Color is powered off.
(3) Install the SD card with nooter written to it in the Nook Color
(4) Connect the Nook Color via USB to your computer. (Linux in my case). The Nook Color will power on all by its lonesome when it is connected to the USB.
(5) Wait a few minutes for nooter to do its thing. Seriously folks. Trying to time this down to seconds until you power the Nook Color off at this step is way overkill. Look at your watch. Add 5 minutes to whatever time it is. When 5 minutes have passed, you can safely go to step 6.
(6) Hold down the power button on your Nook Color for what seems like forever. You can count this one in seconds but, make sure that it has powered down. Without something on the screen, that is difficult to tell that it has powered down. I just timed it and an 8-10second continuous hold of the power button powered the Nook Color off. To be safe, lets say you hold it for 15 seconds.
(7) Remove the SD card from your Nook Color.
(8) Power your Nook Color Back on. (Hold the power button until you see the screen turn on. Duh!)
At this point, your Nook Color is should be rooted.
I then followed the instructions at nookdevs.com/NookColor_Rooting to use ADB to enable multi-touch and Non-Market Apps.
Click to expand...
Click to collapse

jasoraso said:
Your simple instructions are pefect! The only thing I would add is for the Windows users to use WinImage on step 1.
Rooting really is easy; it is getting the ADB drivers to work properly (for us Windows users) that is the difficult step. If you can modify nooter to add the extra steps of writing the file to allow .apk installation; installing Astro or other file explorer; installing a launcher (Zeam seems to be a good choice); and maybe SlideME as a Market until the Google Market is figured out - I think the rooting process couldn't be much easier given the nature of the device!
Click to expand...
Click to collapse
^ This.
Thats the main reason I am holding out on rooting... That and I want to see how far it goes before the market place comes out unless an easy solution like this comes out. While I like the updates here, I am also not in a huge needs for a large phone... but still Great work so far!!!

johnopsec said:
No problem. Just so nobody is confused about anything I posted above: I take absolutely no credit for anything (especially nooter) in my post. I simply wrote down the steps I took using OTHER PEOPLES ideas and code.
Click to expand...
Click to collapse
Lol. I just meant that I try to help you guys, but I have so much to learn on actually doing the stuff you do. Everyone is sharing there stuff on here openly. All good.

I am going to try to teach myself how to use ADB. Kinda nervous though.
jasoraso said:
Your simple instructions are pefect! The only thing I would add is for the Windows users to use WinImage on step 1.
Rooting really is easy; it is getting the ADB drivers to work properly (for us Windows users) that is the difficult step. If you can modify nooter to add the extra steps of writing the file to allow .apk installation; installing Astro or other file explorer; installing a launcher (Zeam seems to be a good choice); and maybe SlideME as a Market until the Google Market is figured out - I think the rooting process couldn't be much easier given the nature of the device!
Click to expand...
Click to collapse

coldbeverage said:
I am going to try to teach myself how to use ADB. Kinda nervous though.
Click to expand...
Click to collapse
No kidding, that is whaat ij aam strugglliing with. Thhaatt and tthe stupid keyybboard!

pokey9000 said:
With the above we could have an almost-1-click root if someone could make the card writing process easier. It would be nice if we had a Linux boot CD or boot USB image that can reformat the card (check that it's a USB device first and ask the user!) to make the boot partition the whole disk automatically. Or someone could verify the rumor that HP's USB bootdisk maker formats the drive correctly.
Click to expand...
Click to collapse
I was messing around with UNetBootin, which is similar to the HP USB formatter. It is designed to take linux ISOs and format them as bootable. But I don't know what specialized format Nooter uses. I didn't get far on this front.
It seems windows users are having trouble with windows drivers needed to get USB ADB working. An alternative is to enable ADB over IP. Leaving this open persistantly is a security hole, but it may be appropriate for initial setup.

PHiZ said:
I was messing around with UNetBootin, which is similar to the HP USB formatter. It is designed to take linux ISOs and format them as bootable. But I don't know what specialized format Nooter uses. I didn't get far on this front.
It seems windows users are having trouble with windows drivers needed to get USB ADB working. An alternative is to enable ADB over IP. Leaving this open persistantly is a security hole, but it may be appropriate for initial setup.
Click to expand...
Click to collapse
Getting the OMAP to boot off of SD requires a few things:
-the OMAP wired to boot from SD
-an SD card with a specific disk geometry as reported by the partition table
-a FAT16 or 32 filesystem on the first partition
-a first and second stage bootloader (MLO and u-boot.bin) in the FAT filesystem
The hardest part of getting Nooter installed correctly is creating that special partition table, and so I released it as a raw dump of an SD formatted using that scheme to only a 40MB image. The theory I've heard is that for maximum BIOS compatibility the HP USB formatter tool generates this same sort of geometry, after which you just need to drag and drop the four Nooter files onto the drive. I haven't had a chance to try this yet though.
edit: I'll be damned, it does work! Just format using hpusbfw.exe (Google it) with "quick format" checked and "create a dos startup disk" unchecked. Then copy MLO, u-boot.bin, uImage, and uRamdisk over. That's it. Plus you wind up with a FAT32 partition that takes up your whole disk, not just 40MB.

pokey9000 said:
Getting the OMAP to boot off of SD requires a few things:
-the OMAP wired to boot from SD
-an SD card with a specific disk geometry as reported by the partition table
-a FAT16 or 32 filesystem on the first partition
-a first and second stage bootloader (MLO and u-boot.bin) in the FAT filesystem
The hardest part of getting Nooter installed correctly is creating that special partition table, and so I released it as a raw dump of an SD formatted using that scheme to only a 40MB image. The theory I've heard is that for maximum BIOS compatibility the HP USB formatter tool generates this same sort of geometry, after which you just need to drag and drop the four Nooter files onto the drive. I haven't had a chance to try this yet though.
edit: I'll be damned, it does work! Just format using hpusbfw.exe (Google it) with "quick format" checked and "create a dos startup disk" unchecked. Then copy MLO, u-boot.bin, uImage, and uRamdisk over. That's it. Plus you wind up with a FAT32 partition that takes up your whole disk, not just 40MB.
Click to expand...
Click to collapse
Sounds like we may be getting close to a custom rom....????
Is the uImage the ROM? or is it all 4 pieces

Sorry if I am misunderstanding this pokey since I am a total noob. I too have been holding out on rooting hoping for an easier solution (I do not even know how to navigate to directories in terminal) I believe you are implying that the NC can be rooted using this method and is in fact much easier to accomplish. You said that you had to copy over those 4 files once you format the card. Where can one obtain those files?
Thanks man for all your dedication and hard work!

sudermatt said:
Sounds like we may be getting close to a custom rom....????
Is the uImage the ROM? or is it all 4 pieces
Click to expand...
Click to collapse
MLO - first stage bootloader. The OMAP's built in ROM looks for this on the SD and runs it. MLO then looks for u-boot.bin and runs it if it can find it on the card. It's like the Nook's boot sector.
u-boot.bin - second stage bootloader. This is responsible for figuring out how to get Linux and the ramdisk in memory. This copy loads up uImage and uRamdisk from microsd and starts running the kernel. This is similar but not the exact same as the one on the internal flash.
uImage - The Linux kernel. This copy is built specifically for Nooter.
uRamdisk - a Linux filesystem that gets loaded into RAM. Contains the Nooter script, disk utilities for performing the root, and other bits and pieces that let you log in over USB and get a shell.
This really has nothing to do with a custom ROM, it's just an easier way to install Nooter.

th3c1am said:
Sorry if I am misunderstanding this pokey since I am a total noob. I too have been holding out on rooting hoping for an easier solution (I do not even know how to navigate to directories in terminal) I believe you are implying that the NC can be rooted using this method and is in fact much easier to accomplish. You said that you had to copy over those 4 files once you format the card. Where can one obtain those files?
Thanks man for all your dedication and hard work!
Click to expand...
Click to collapse
If you have a card with Nooter on it, you could mount it on a PC and pull all 4 files off. Using the HP utility is an easier option for people who want to root under Windows and are having trouble with the disk utilities. When I get a chance I'll post the files separately.

[MOD] Full Ubuntu on the Atrix (now fully automated: 4.1.26/4.1.52)

----- Announcements -----
Closed in favour of this thread.
As noted in the poll, interest is high enough in a union filesystem that it will be the next thing investigated. Unfortunately, anybody who wants to move from any version 1.x or earlier of this script will probably need to re-install everything for version 2.x, as the way the target filesystem is designed is going to change dramatically. Sorry.
There's a typo that jdkramar found, but I expect that most of you won't hit it (unless you've modified your /etc/sudoers), and those that will know enough to fix the script.
----- Your regularly scheduled post below. -----
For those users who have requested a full Linux on their Android device, I now present a relatively easily upgradable Ubuntu on the Motorola Atrix. It's not perfect, but it's surprisingly good.
There are a number of problems we have with the webtop environment that we would like to address in order to have "proper" Ubuntu, including (additional explanation below about each of these points):
The restrictiveness of the environment Motorola's set up (easy to bypass).
A lack of disk space to do anything (only having ~80 MB free really hurts).
An unwillingness to create a third Linux-based environment.
A non-functional apt/aptitude (easy to fix).
Note: This is different than the "webtop over HDMI sans dock" effort. If you're looking for that, please look at this other thread instead. Although unrelated, they shouldn't conflict with each other.
Caveats:
You will be hacking your device. The base script that modifies your device has been reasonably well tested and operates with a decent level of paranoia, so it is highly unlikely that the script will break anything. However, any software you install after you have access to a full Ubuntu presents a very real chance that you will either soft-brick your device or get it into an infinite reboot loop, particularly if you don't know what you're doing. Having a decent knowledge of Unix/Linux is recommended if you wish to proceed. You take full responsibility for what may happen to your device if you execute this script.
You'll need a rooted Atrix in order to do this*, although I doubt anyone's surprised about that. The attached setup script takes care of the steps in post #4, but you should note a few things:
Before you execute the script:
In response to the request that threads indicate whether or not this will work on any Motorola Atrix, it should. If you'd like verification, send me the output of "/usr/bin/dpkg-query -l" on your Atrix's unmodified Ubuntu, and I can double-check. So far, this is verified to work on:
AT&T (me! )
Bell
The script will create a 1 GB filesystem file in /data, so you'll need to have at least that much free space there.
Before running the install script, you'll need to have seven or less apps in the Media area. You can check this by going to Settings → Applications → Manage applications, then checking the Media area tab. The number of apps there will need to be seven or less. If you have more than that, temporarily uninstall apps or move them back to the phone (you can move them back after the script runs and reboots).
While you execute the script:
When the script asks question, it offers reasonably "sane" options by default (although it does try to be safe).
Resetting a filesystem file means that it will use the file that's already there, but set it back to match your original /osh partition. It's generally quite a bit faster than deleting it and recreating it, but deleting it is sometimes the right decision (like if you want to change its size).
The script asks about your MAC (mandatory access control) files because it can't be sure that you haven't altered your original files to your taste. If you have no idea what that sentence just said, pick either the very permissive or somewhat permissive MAC configuration files (the former should cause you fewer headaches).
If you haven't altered your AWN configuration (the tray at the bottom), I suggest you install the modified app launcher configuration (which is the default). If you have altered the configuration, the script won't ask, assuming that you'd like to keep your current one.
Since the setup script downloads Ubuntu packages on the fly (it made more sense than trying to have a giant archive with all of the packages embedded in it), the quality of your connection may result in the script dying partway through. If this happens, you should just be able to restart the script; it'll start again from the beginning, but nothing bad should happen as a result. If enough people report problems with downloading packages, I'll look into a workaround.
After you execute the script:
I've seen a couple of instances where on the first reboot to the alternate /osh partition where MotoBlur thinks that the SIM card has changed. Another reboot fixes this.
For those users who have used a previous version of the script, an upgrade script(s) are included to bring you up to the current level of what's automated.
For those users who have used a previous version of the script and made changes after that, the upgrade script(s) should be able to handle those changes gracefully.
If you want to uninstall:
Using adb with root access:
adb shell
su
cd /system/bin
mv mountosh mountosh.new
mv mountosh.orig mountosh
cd /data
rm ubuntu.disk
cd /home/adas/.gconf/apps/avant-window-manager
rm -r window_navigator
reboot
Once installation is complete, you can start playing with synaptic to install packages. You may need to be careful upgrading any of the -mot/~mot versioned packages, as that can break functionality. I'm still compiling a list of which packages can be upgraded versus which can be left alone (listed below).
Here's a brief runthrough of the type of operations you can do afterwards. Upon rebooting, the webtop screen now looks like this (note the altered set of icons in the tray):
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Running synaptic brings up a list of available packages:
If we're looking for a decent image viewer, eog should do the trick:
Once we install it, Nautilus (the file manager) now has an interesting option in the menu for pictures, Open with "Image Viewer":
Selecting that brings up what you would expect (moved off to the side so that it doesn't take up the entire desktop):
I haven't yet tested upgrading to Ubuntu 9.10 yet (let alone Ubuntu 10.x), but everything else looks to work fine, with the usual caveats. Further updates to come as they're available!
Changelog:
1.0.6: "By default, Wget will assume a value of 10 seconds." my foot!
1.0.5: More fixes:
Having a space in the directory structure should no longer be disruptive to the script's behaviour.
Questions are now case-insensitive.
More tweaks to the somewhat permissive TOMOYO configuration files.
If the LXTerminal binary has been deleted (as appears to be the case on Bell), it is now re-installed.
The built-in package tester is now more resilient. It supports 1.4.26 and 1.4.52 properly.
The script now asks whether the dock should just be blown away with the replacement, rather than trying to make assumptions.
1.0.4: Quite a few fixes:
Rename upgrade scripts, so that people get less confused (hopefully!).
Tweak the check for whether it's already running from the filesystem file, since the earlier check didn't actually work (doh!).
/osh/data doesn't exist by default, so have the script stop assuming that.
Tweak the pulseaudio re-install so that it's a bit more reliable.
The expected list of packages to manipulate doesn't work for 4.1.26. Set it to the 4.1.26 numbers for now, and re-factor for 4.1.52 with the next revision.
Reroute /bin/ps' stderr to /dev/null so that it doesn't pollute stdout.
The set of unmount instructions at the end need to be split up, since you can rightfully get to the end while skipping some of the mount instructions.
Prior to attempting to alter /system, ensure that it's mounted read/write.
1.0.3: Not everybody runs batch files from the command line, so add a "pause" at the end so that users can see what happened.
1.0.2: Apparently, relying on the score that aptitude returns as the check for whether or not it's okay to auto-fix things is too unreliable. So, instead, opt for the (somewhat riskier, but should be reasonable) check of the number of packages to remove/install/upgrade/downgrade. The check can be made package-specific if need be, but I'd rather have a script that I can re-use later for other upgrades if I need it.
1.0.1: If the package management auto-fix doesn't go through, it's not likely that the script will be able to install gksu or synaptic either, so those steps need to be fixed.
1.0: The "very permissive" MAC option was broken. That's now been fixed, along with completing the automation of the entire process.
0.7.2: Added a check for having a free loop device, and also re-added a "very permissive" MAC option.
0.7.1: Removing /sbin/tomoyo-init appears to cause the X environment not to load at all, so disallow that option for now.
0.7: In addition to making it slightly more user-friendly (by adding questions for when the script isn't sure how to handle a situation), it now handles through to the initial dpkg installation.
0.5.2: Dump rsync's output to /tmp/rsync.out since it takes a really long time, allowing for users to tail the output if they know how. Also, run adb kill-server at the end of the script so that the adb daemon doesn't continue to run (which makes it really annoying to try and delete the directory).
0.5.1: 0.5 had a bug where it tried to check for a return from psneuter, which kills the adb connection (so no return value could be obtained). Instead, use whoami to verify whether or not psneuter succeeded in running.
0.5: The attached script should handle up through to the rsync phase automatically. There's a considerable amount of error checking, so it should be safe to use (I've uploaded a version of the script that should take you as far as the mountosh swapping, which means that you'll now be using a different Ubuntu partition than the default).
* This is a technicality, since the script hacks your device to be able to run commands over ADB as root.
----- Donation notes -----
If you want to donate, rather than to me, why not donate to the Japanese earthquake/tsunami relief effort instead? Here are a couple of (non-attributed) pointers if you don't know where else to look:
International Federation of Red Cross and Red Crescent Societies: no minimum; USD, CHF, EUR; Visa/MC
American Red Cross: $10 minimum (ouch); USD; Visa/MC/AmEx/Discover/Amazon
Canadian Red Cross: no minimum (?); CAD; Visa/MC/AmEx/PayPal

In regards to the above list, a bit of explanation:
The restrictiveness of the environment Motorola's set up (easy to bypass).
As shown in the above steps, renaming and/or removing /sbin/tomoyo-init is all it takes to disable TOMOYO Linux. Leaving it in place isn't necessarily a bad idea, since it means that any of the standard entry points into an Atrix are reasonably locked down. The TOMOYO configuration file that I'll shortly be attaching leaves certain executables completely unlocked (those that need to be able to run anything), but finding out what's hitting up against the limits is a simple matter of setting everything to run_level 2 and checking dmesg.
A lack of disk space to do anything (only having ~80 MB free really hurts).
As I note above, 1 GB isn't much either. On the other hand, what I'm going to look into when I have that mythical thing called free time is to use my internal contacts to get a copy of the kernel source code and then see if I can build myself a FUSE module. At that point, I should be able to pull off a union mount, which should help dramatically.
We haven't figured out how to repartition the Atrix's partition scheme, so we don't have much flexibility on making the existing partition larger. Creating a filesystem file in the Internal Storage would be nice, but a) that partition (p18) isn't available when mountosh runs, and b) it'd make it difficult, if not impossible, to cleanly USB mount the partition. Creating a partition on the SD card would be nice, but a) mmcblk1 isn't available when mountosh runs either, and b) there would be similar constraints if a user ever wanted to pull the SD card.
An unwillingness to create a third Linux-based environment.
I respect what the people who are trying to create a "clean" chrooted environment are trying to do, but it feels to me that there's the whole "throwing the baby out with the bathwater" aspect here, since there really isn't that much more to do beyond what Motorola's provided. Besides of which, some of what Motorola has done with their environment isn't possible to duplicate without taking the files (like the aiw (Android In Window) package). So I would prefer to take the approach of taking the chains off the existing system.
A non-functional apt/aptitude (easy to fix).
Not much to say here, right?
The script builds a larger disk using /data as its home. The primary advantage is that we have access to it at the right point during boot. The primary disadvantage is that we don't have anywhere as much as we'd like to have (since /data is 2 GB total). But, you work with what you've got!

Known package issues:
Be careful upgrading any of the -mot/~mot packages, as that can break functionality. I'm still compiling a list of which packages can be upgraded versus which can be left alone.
Can be upgraded with loss of functionality:
libnautilus-extension1-1:2.26.2-0ubuntu1-mot1
nautilus-1:2.26.2-0ubuntu1-mot1
nautilus-data-1:2.26.2-0ubuntu1-mot1
Upgrading these packages plus at least one additional package I've not yet fully identified breaks viewing mountable storage and the ability to unmount it.
xserver-xorg-core-2:1.6.0-0ubuntu14
Using the stock xserver-xorg-core 2:1.6.0-0ubuntu14 that's already installed without recovering /usr/bin/Xorg appears to lead to a loss of the status bar at the top. This particular issue is now handled by the script.
Cannot be upgraded:
gtk2-engines-1:2.18.1-0ubuntu1~mot1
This breaks aiw (Android In Window) so that there's no frame around the window and it can no longer be manipulated in any way.
xscreensaver-5.10-6-motorola1?
xscreensaver-data-5.10-6-motorola1?
xscreensaver-data-extra-5.10-6-motorola1?
This will likely break displaying aiw (Android In Window) as the unlocking mechanism for the screensaver. Still needs to be tested.

Archived notes:
The below steps are performed by the script in the first post, but in case you really wanted to know what's going on behind the scenes....
----- The setup script takes care of steps starting here. -----
From here on until noted otherwise, all commands are assumed to be run as root (so you either are root, or you're calling every command via sudo).
First, we should make sure that there's enough free space on the device:
/bin/df -h /data
There should be at least 1.0G under the Used column. If not, you won't have enough to create a decent disk. If so, then you can keep going:
/bin/dd if=/dev/zero of=/data/ubuntu.disk bs=1024 count=1048576
/sbin/losetup /dev/block/loop7 /data/ubuntu.disk
/sbin/mkfs -t ext3 -m 1 -b 2048 /dev/block/loop7
mkdir /tmp/osh
/bin/mount -t ext3 /dev/block/loop7 /tmp/osh
At this point, we've created a 1 GB disk file (1,024×1,024=1,048,576), formatted it as ext3, and mounted it in /tmp/osh. The next step is that we need to grab a copy of rsync so that we can perform our copy. I'll assume that rync is in /mnt/sdcard-ext for now:
mkdir /tmp/deb
/usr/bin/dpkg-deb -x /mnt/sdcard-ext/rsync* /tmp/deb
/tmp/deb/usr/bin/rsync -avx /osh/ /tmp/osh/
And now we have a duplicate of our /osh partition, but with more space this time (1 GB instead of 756 MB, which isn't great, but is a hell of a lot better). And, we know how to intercept the point in init.rc where /osh is mounted so that we can redirect it. Put the following into a file named mountosh.new, then copy it to /mnt/sdcard-ext. Here's the file:
Code:
#!/system/bin/sh
# Run mountosh.orig
/system/bin/mountosh.orig "[email protected]"
# Then, mount the filesystem file over the existing /osh
# partition.
/sbin/losetup /dev/block/loop7 /data/ubuntu.disk
/system/bin/mount -t ext3 /dev/block/loop7 /osh
After that:
mv /system/bin/mountosh /system/bin/mountosh.orig
cp /mnt/sdcard-ext/mountosh.new /system/bin/mountosh
chmod 0755 /system/bin/mountosh
chown 0 /system/bin/mountosh
chgrp 2000 /system/bin/mountosh
You can now reboot your device, and you should now boot into the new partition we've just created.
----- The 0.5 version of the setup script performs up through here. -----
Here, an interesting question pops up: do you want mandatory access control (MAC) in place? In my case, I don't have a problem with it, so I can provide updated TOMOYO configuration files that reflect that. If you would prefer to disable it completely, run the following commands:
rm osh/etc/tomoyo/exception_policy.conf
touch osh/etc/tomoyo/exception_policy.conf
rm osh/etc/tomoyo/domain_policy.conf
touch osh/etc/tomoyo/domain_policy.conf
and then reboot your device again. This configures TOMOYO so that it monitors nothing.
Next, we go through and install a series of packages which are either loaded in a broken state (because Motorola force-installed conflicting packages afterward) or packages which are expected to be present. Some of these packages have specific paths listed afterward; if there are, then those files need to be backed up before package reinstallation, then restored afterward. This is important.
coreutils
cpio
dbus
/etc/init.d/dbus
dbus-x11
/etc/X11/Xsession.d/75dbus_dbus-launch
dhcp3-client
findutils
gpgv
pulseaudio
/etc/pulse/daemon.conf
/etc/pulse/default.pa
udev
/etc/init.d/udev
xserver-xorg-core
/usr/bin/Xorg
You'll need to install each package with:
dpkg -i --root=/osh --force-overwrite <package>
At this point, we can now update the list of APT sources so that we can start querying the public Ubuntu depots. Edit your /etc/apt/sources.list to have these entries:
Code:
deb http://ports.ubuntu.com jaunty main universe multiverse restricted
deb http://ports.ubuntu.com jaunty-security main universe multiverse restricted
deb http://ports.ubuntu.com jaunty-updates main universe multiverse restricted
I would also recommend that you add this line to the bottom of your /etc/apt/apt.conf.d/05aptitude file, since the reality of the situation is that we still don't have much space (it'll turn off auto-installing packages that aren't necessary but are recommended):
Code:
Apt::Install-Recommends "false";
At this point, you should be able to run the following with no problems:
apt-get update
----- The 0.7 version of the setup script performs up through here. -----
If this succeeds, we can move on to running aptitude:
aptitude
It will complain that a number of package installations are broken. This is expected, as that's how Motorola built out the distribution. The current script executes the "default" solution, which at the time of writing is four uninstallations, one downgrade, and ten installs. Also make sure that no "unnecessary" packages are uninstalled, since some of them are actually necessary.
We can then install gksu and aptitude so that we have graphical access to the package repositories from aptitude.
----- The 1.0 version of the setup script performs up through here. -----

You my friend are incredibly good. This is insane
Edit: removed huge quote...

Might be a good idea to not quote the entire massive post.
Looking forward to seeing where this goes... How well does it run?

This is great. Can't wait to try it monday. Keep up the good work.
Sent from my MB860 using XDA Premium App

how does this perform vs the included webtop mode?

CC Lemon said:
Looking forward to seeing where this goes... How well does it run?
Click to expand...
Click to collapse
lasersocks said:
how does this perform vs the included webtop mode?
Click to expand...
Click to collapse
It is the included webtop mode - it's just a matter of pulling off some of the restrictions that Motorola put on it. I should probably tweak it just a bit more to where I'm happy with it, and then I'll be able to start making suggestions on what to install. One of the things that people would probably want most is synaptic (graphical package manager), for example, and I should just have a script that installs it for people.

if you get this working, can you make a video please? would be nice to see how it is.

pure genius

can u post a video about your work ? =)

Very good work! You should join the irc sometime.
freenode
#moto-atrix

Now with more scripting!
I've added a version 0.5 of a setup script that automates some of what happens (I've denoted how far in the process it performs right now). It should print out a user-friendly version of what it's doing, in addition to what it's failing on if it fails. Appropriate notes added in the first post as well.

Sogarth said:
Now with more scripting!
I've added a version 0.5 of a setup script that automates some of what happens (I've denoted how far in the process it performs right now). It should print out a user-friendly version of what it's doing, in addition to what it's failing on if it fails. Appropriate notes added in the first post as well.
Click to expand...
Click to collapse
I'll try again. Got up until mounting new partition. Created mountosh.new copied over to phone rebooted. Didn't mount. Didn't have anything in /sbin dir. Like losetup.
Back to .sbf now. Going to try script and give it another go.

I cant wait for my Atrix I'm getting more and more excited every day seeing whats happening here
Thanks a lot for this, especially that I'm not very advanced linux user
Does the usb mice and keyboard work properly? Or other usb-stuff?

dicksteele said:
I'll try again. Got up until mounting new partition. Created mountosh.new copied over to phone rebooted. Didn't mount. Didn't have anything in /sbin dir. Like losetup.
Back to .sbf now. Going to try script and give it another go.
Click to expand...
Click to collapse
Hmm... that's really, really strange.
Edit ubuntu.bad and comment out the reboot line, then. Should just be a matter of adding rem at the beginning of that line.
Also, you shouldn't have to use the sbf. Using the soft brick recovery instructions should be enough, since all you would need to do would be to rename mountosh to mountosh.new, then rename mountosh.orig back to mountosh to get the original state back.

Sogarth said:
Now with more scripting!
I've added a version 0.5 of a setup script that automates some of what happens (I've denoted how far in the process it performs right now). It should print out a user-friendly version of what it's doing, in addition to what it's failing on if it fails. Appropriate notes added in the first post as well.
Click to expand...
Click to collapse
Shouldn't for /f "tokens=*" %%l in ('%~dp0adb.exe shell "chmod 6755 /tmp/psneuter > /dev/null 2>&1 && echo PASS"') do set retval=%%l
be chmod 0755 ? Getting error can't execute psneuter. First I thought it was because I already had one in tmp from AROOT. Trying again now.

Sogarth said:
Hmm... that's really, really strange.
Edit ubuntu.bad and comment out the reboot line, then. Should just be a matter of adding rem at the beginning of that line.
Also, you shouldn't have to use the sbf. Using the soft brick recovery instructions should be enough, since all you would need to do would be to rename mountosh to mountosh.new, then rename mountosh.orig back to mountosh to get the original state back.
Click to expand...
Click to collapse
I was running Gingerblur. Wanted to start fresh. And it wasn't from running batch file. It was before you creating batch. Tried from first post instructions. No biggie. I'm having fun !!!

dicksteele said:
Shouldn't for /f "tokens=*" %%l in ('%~dp0adb.exe shell "chmod 6755 /tmp/psneuter > /dev/null 2>&1 && echo PASS"') do set retval=%%l
be chmod 0755 ? Getting error can't execute psneuter. First I thought it was because I already had one in tmp from AROOT. Trying again now.
Click to expand...
Click to collapse
No, it's actually chmod 6755 since it's setting u+s. What's a bug in there (and I'm about to upload a fixed version) is that /tmp/psneuter actually kills the connection immediately, so it can never return "PASS". I added in a user check afterward instead.
A fixed 0.5.1 uploaded.

[Q] encryption, ext2/4, and "filesystem too large to mount safely" error fix?

[Q] encryption, ext2/4, and "filesystem too large to mount safely" error fix?
Hello again,
With my Droid 3 (thanks to Minimoto) again working great, I've turned my attention back to encrypting some of my data on the external SD card. I had used "LUKS Manager" some time ago so that seemed the logical place to start.
Okay, the short *short* version is: What does the error message (from dmesg output) "EXT4-fs (dm-4): filesystem too large to mount safely on this system" mean and how do I fix it or work around it?
The details:
I have a 32 GB SD card with a normal ~20 GB FAT partition that Android sees and uses just fine. On my laptop I created an ext4 file system on the second partition (the remaining ~12 GB of space). Android does not see or use this, but from a terminal I *can* mount it without problems. I chose to mount /dev/block/mmcblk0p2 (external SD partition 2) at /mnt/sdcard-ext-p2. Just FYI, but I wrote a short script and put it at /etc/init.d/03mount_sdpart2 to mount this second partition at the correct mount point and it works fine. Even after a reboot the script runs without problems and now I always have my new ext4 file system present.
The reason for creating the ext4 file system is because FAT does not support files larger than 4 GB and therefore my encrypted volume cannot be larger than 4 GB *if* I create that volume on a FAT file system. With the new ext4 file system, now using the LUKS Manager app, I created a new volume at the above mount point with a size of approximately 11.25 GB. This worked fine, too. The last step, however, actually mounting this encrypted volume, keeps failing. It was supposed to be mounted at /mnt/sdcard/LUKS. Unfortunately, LUKS Manager did not produce much in the way of information about why it had failed.
A quick note about file sizes: If I use an app like "ES File Explorer" and go to /mnt/sdcard-ext-p2 where the large volume file exists, ES says the volume file has a size of -805306366 bytes, obviously wrong. Fortunately, if I use the terminal and look at the file size with "ls -l" it has the correct size. Furthermore, after I opened the volume below using lm.cryptsetup I can use its "status" command and after converting the values from sectors (each sector is 512 bytes) it also displays the correct size of the encrypted volume.
So, back to the terminal where I decided to do the steps manually and see where it failed. For the most part, I used different device and directory names than what LUKS Manager would have used, mostly to be sure I wouldn't accidentally conflict with another process/app. The 'lm.cryptsetup' binary is provided by LUKS Manager and placed in /system/bin. I have the version of busybox that, I assume, ships with Minimoto which is busybox v1.20.0. This is where the 'losetup' I am using comes from.
Concerning loopback devices: LUKS Manager defaults to using/creating high numbered loopback devices, 300 for the first volume created. On Android the loop devices are created in /dev/block, but some tools don't seem to look there. In particular, lm.cryptsetup complains about not being able to find a free loopback device and 'losetup -f' (which displays the next free/available loopback device) always refers to devices in /dev regardless of where they really are. Making symlinks such as "ln -s /dev/block/loop0 /dev/loop0" for each of the currently present loop devs (0 through 7, and 300) fixes both of these problems. That said, whatever manner LUKS Manager uses to execute the underlying tools works properly with the loop devs being located in /dev/block. This can be verified by using "lm.cryptsetup status <crypt_dev>" and the status output shows that it is correctly attached to, for example, /dev/block/loop300. Making these symlinks is more of a convenience/fix for when one is working directly on the command line.
Where, before, 'losetup -f' indicated that /dev/loop0 was free (even though it did not exist), after making the symlinks the same command indicates that /dev/loop4 is the next free loop. On my phone, at that moment in time, that was the correct answer. loop4 also makes sense because I have four apps that I have "moved to SD" and for each app that you do this one loopback device is used (so loop0 - loop3 were used by apps "moved" from main internal storage). Creating these symlinks also made lm.cryptsetup stop complaining/erroring about not being able to find a free loop dev. Finally, running "losetup" without arguments is supposed to list the used loop devs and what is using them. Before making the symlinks is produced no output, and now, after the symlinks, it displays:
Code:
/dev/loop0: 0 /mnt/secure/asec/blah_appA.asec
/dev/loop1: 0 /mnt/secure/asec/blah_appB.asec
/dev/loop2: 0 /mnt/secure/asec/blah_appC.asec
/dev/loop3: 0 /mnt/secure/asec/blah_appD.asec
/dev/loop5: 0 /ss/safestrap/rom-slot2/cache.img
/dev/loop6: 0 /ss/safestrap/rom-slot2/userdata.img
/dev/loop7: 0 /ss/safestrap/rom-slot2/system.img
As you can see, loop4 is missing/available. Also, rom-slot2 is correct as it is where I opted to install Minimoto, rom-slot1 currently containing CM 10.1.
With the loop device issues taken care of, the steps I performed are as follows:
Code:
$ su
# lm.cryptsetup luksOpen /mnt/sdcard-ext-p2/MyCrypto.vol MyCrypto
<type in passphrase>
# ls /dev/mapper
MyCrypto control
# mkdir /mnt/sdcard/luks-tst
# mount /dev/mapper/MyCrypto /mnt/sdcard/luks-tst
mount: mounting /dev/mapper/MyCrypto of /mnt/sdcard/luks-tst failed: File too large
# dmesg | tail -2
[20665.748504] EXT4-fs (dm-4): filesystem too large to mount safely on this system
[20665.750732] EXT4-fs (dm-4): filesystem too large to mount safely on this system
You can see from the above block my commands and the output, especially errors, that followed. Clearly, the file is "too large"... but how? The whole point of this extra partition and ext4 file system stuff was specifically to get around the FAT 4GB file size limitation. Unfortunately, while these errors tell me that something is too large, what *part* is too large? Is the 11.25 GB volume *container* too large, or the ext2/4 file system that exists inside the volume? And if either is too large, what is the maximum size I can make them? I did try adding "-t ext2" and "-t ext4" to the mount command, but neither one changed the outcome nor did they change the messages that were output.
The 'mount' binary (like most others) is provided by busybox, so it could possibly be part of the problem. However, the last two errors above come from the kernel log (via dmesg) which means that at least part of the issue is the kernel, maybe the file system modules. I also checked the logcat output, just in case, but it did not contain anything related or useful. Minimoto 1.7 is using kernel version 2.6.35.7 and perhaps it has some maximum size issues I am unaware of. With the exception of my Droid 3, I haven't used a 2.6.x Linux kernel in a very long time.
I've searched around here as well as the fairly small LUKS Manager message board and the Net at large, but I haven't been able to find the answers I'm looking for. Any ideas as to what I might have done wrong, or something I haven't done but should? I'm not sure how to proceed. Just to be perfectly safe, I did try rebooting but it made no difference.
--John Gruenenfelder

Re: [Q] encryption, ext2/4, and "filesystem too large to mount safely" error fix?
Could it be that your mount point is within the FAT fs, what about creating a new mount point at say /mnt/LUKS
Sent from my XT860 using xda premium

Re: [Q] encryption, ext2/4, and "filesystem too large to mount safely" error fix?
I tried using /mnt/LUKS (instead of the previous /mnt/sdcard/LUKS) as the mount point, but nothing changed. The "filesystem is too large..." messages still appeared.
I don't know why there are two such messages separated by about 2/1000th of a second in the dmesg output even though I issued just one command. It was the same way in my first post.
If I recall, the original reason for putting the mount point under /mnt/sdcard was so that most apps could see/use the new area without having any extra knowledge.
--Sent from my DROID3 using xda app-developers app

[DUAL-BOOT][RECOVERY] Ouya Boot Menu for Support of Kernel Image Chain-loading

Hello everyone! Just like others here, I've been somewhat spooked by our inability to enter Ouya's Recovery partition at the earliest stage of booting, meaning a bad flash of the Boot partition would leave the device inoperable. When I heard that Ouya's stock firmware updates were possibly bricking a few units out there, I decided to block updates on mine and see if I could transform the Boot partition such that it would become a logical extension of the bootloader. What I ended up with is something close to the "Ouya Safe Recovery" project, where a user should only need to flash Boot one additional time, along with chain-loading support as well.
Chain-loading in this case refers to the booting of ROM kernel images that reside as regular IMG files under the /sdcard and/or /system filesystems. With this capability it is possible to choose an image to run when the Ouya turns on. As an example, one may wish to set up a 2nd/test kernel+ramdisk image to use with your installed ROM, or he may wish to run Tuomas Kulve's Debian project from time-to-time without having to set up the USB cable for Fastboot mode. When dealing with distinctly different ROMs (not just alternate kernels), only one of them may install to the Ouya's built-in storage (e.g., /system); others must have been designed/created to use external storage.
An image for the Recovery partition is available along with the Boot. The former may be helpful if you wish to try out the boot menu before performing the flash of the Boot partition, or are generally okay with bouncing to Recovery before invoking a chain-load. Either of these may be tested from Fastboot mode, but do note that a successful chain-load requires that the image actually be flashed to the Ouya. (Otherwise it just reboots.) The ClockworkMod (CWM) recovery application is available on both images and is accessible from the boot menu.
Additional Information
There are a few things to consider when deciding if this approach makes sense for you:
- Users of the "Ouya Safe Recovery" project may want to stay put unless the dual-boot aspect is of interest. If so then it would be cleanest to choose my Boot image; the Recovery partition (your ROM image) could be left alone.
- The images here are not compatible with Ouya's stock firmware, due to the auto-update nature of Ouya's ROM. Either your flashed Boot image would get overwritten, or an installed non-Ouya Recovery might cause that update to hang. Therefore, you should be prepared to switch to one of the ROMs here at XDA. If you're currently on stock and don't want to switch right away, that's fine; we'll go over how to block updates for the time being.
- The Ouya CM10 ROM is nice in that it provides the IMG file separately, allowing us to handle it as we wish. However, the other ROMs end up placing their boot.img in the main ZIP. This is standard practice for other devices, but we need to be careful ensuring our Boot partition doesn't get reflashed as part of the ROM installation. Therefore, it would be necessary to investigate repackaging the ROM with an alternate updater-script prior to installation. See my StockPlus post on page 2 for more. (This shouldn't affect those who've opted for my Recovery image.)
This feature is based on CWM's initial ramdisk, and includes a new boot menu application that comes up prior to CWM itself. Basically, CWM shows up later if the menu application exits for any reason. The Ouya stock kernel (561) has also been compiled with HDMI's copy protection turned off, and includes two patch sets:
- KExec-HardBoot is the key to chain-loading on our platform. It overcomes standard KExec's lack of hardware reset (and thus failed execution) by triggering a reboot in the middle of the preparation of the new kernel. This ingenious system has been developed by Tasssadar and others over in the Nexus forums. (Be sure to enable CONFIG_TEGRA_HARDBOOT_RECOVERY if interested in compiling a Recovery kernel.)
- HDMI visual stability has been improved with a little hack of mine: a significant relaxing of a timer in the driver. (The latest Android source has corrected the instability with a significant design change, but my hack seems fine enough for this project.) Also picked up specific Android fixes in the area of Framebuffer double-buffering, as that needs to be working for CWM usability.
Installation
If you're on Ouya's stock firmware, then you should make sure that any future updates do not get applied. There is a project here ("Mod Collection For Ouya") that should help. I personally side-loaded the Baxy custom launcher to avoid Ouya's update environment. It is also likely necessary to stay out of the Ouya/Discover store if going the custom launcher route as I believe the store app can trigger an update.
At this point you can download your chosen image (Boot or Recovery) and unzip to get the IMG file. Boot your Ouya to a working Root/BusyBox environment (ROM or Recovery), and then transfer the IMG to the Ouya. (An example using ADB would be "adb push boot102513.img /sdcard/boot102513.img".)
Bring up the Ouya command prompt (e.g., "adb shell") and run these commands to get started:
su [command not present on CWM - that's okay]
cd /dev/block/platform/sdhci-tegra.3/by-name
ls
You should see the various 3-letter partition names from that last command. Your command prompt should also contain the "#" character to denote root-level access. This next step will save off your current ROM image, both because we may end up overwriting it, and because the saved file will end up as your main bootable kernel for the chain-loader. Run:
cat LNX > /sdcard/kernel.img
(If configured for "Ouya Safe Recovery," then replace the preceding "LNX" with "SOS".)
We are near the flashing stage. Check to make sure your Ouya has a reliable source of power, preferrably from an uninterruptable power supply. Recall that a bad flash of my boot image can leave the device inoperable, but I feel the risk is very low provided the following directions are heeded. Fortunately the flash process only takes a few seconds.
For the Boot image option, verify by running:
md5sum /sdcard/boot102513.img
Do not proceed unless you get "e4b1b1ad553e55ad0b2ce3fb8f5bf623".
Again for the Boot image option, flash to the Ouya by running:
dd if=/sdcard/boot102513.img of=LNX
For the Recovery image option, verify by running:
md5sum /sdcard/rcvy102513.img
Do not proceed unless you get "dda0811a7e8e82a7d4ad3fa4c3ae35e4".
Again for the Recovery image option, flash to the Ouya by running:
dd if=/sdcard/rcvy102513.img of=SOS
You may optionally verify (post-flash) by running "md5sum" on the partition name. Finish up with these commands:
sync
reboot
Usage / Configuration
The menu should come up, defaulting to "kernel.img" for the Boot image and "CWM" for Recovery. That default will then launch after ten seconds of inactivity. You may also briefly press the Ouya power button during the wait to advance through the options. The option list is 1) kernel.img, 2) kernelA1.img, 3) kernelA2.img, 4) CWM, and 5) Recovery Partition.
The defaults from above should be fine for most everyone, but it is possible to fine-tune them. An optional configuration file (/sdcard/bootmenu_b.cfg for Boot, /sdcard/bootmenu_r.cfg for Recovery) may be established to specify the default menu entry as well as the inactivity timeout. As an example, the following command would make Recovery start kernelA1.img after five seconds:
echo "2 5" > /sdcard/bootmenu_r.cfg
It is hoped that the menu would never hang. If it does, then waiting a full minute should allow CWM to start. Otherwise, it may be necessary to attach a wired/USB keyboard and type in the Alt-SysRq-X sequence, similar to Ctrl-Alt-Delete on a PC. The sequence might have to be done early on in the menu startup process, and should blink the Ouya light and place it in Fastboot mode.
The menu may unexpectedly place you in CWM, which would indicate an issue with a chain-load. The reason may be due to a missing or corrupt IMG file. Otherwise you should be able to determine why by checking /tmp/bootmenu.log against the attached source code.
---
I hope this project will be of help to others!
An additional support forum that everyone should be able to post at is available: http://forum.xda-developers.com/showthread.php?t=2450711.

Wow, really great. Thanks a lot for your effort
Gesendet von meinem One X+ mit Tapatalk

nchantmnt said:
Wow, really great. Thanks a lot for your effort
Click to expand...
Click to collapse
My pleasure, nchantmnt. Hope your new Ouya is helping you feel at home!

Yes im happy it already arrived, but after a second miscarriage and lots of stress because of a lawsuit with our neighbour i didn't have time nor nerves to play or code. Seriously this year sucks
Gesendet von meinem One X+ mit Tapatalk

nchantmnt said:
Yes im happy it already arrived, but after a second miscarriage and lots of stress because of a lawsuit with our neighbour i didn't have time nor nerves to play or code. Seriously this year sucks
Click to expand...
Click to collapse
Gosh, I'm very sorry to hear that. Do think ahead to the upcoming holiday season, and may it be a time to reflect and anticipate a fruitful 2014.

@Hal9k+1 - THANK YOU!
I was so nervous flashing CWM and StockPlus as there is no real way to fix things if something goes wrong. This should give people more confidence when flashing their Ouya.
I understand the process using ADB...my question is: can this be used from CWM somehow?
PS. I assume new kernel will always be flashable from CWM, the hack does not require 561 specifically.

Ipse_Tase said:
I understand the process using ADB...my question is: can this be used from CWM somehow?
Click to expand...
Click to collapse
Hi Ipse_Tase - I do hope the feature will be helpful to you and others.
As I think about your question, I suppose I could have have created a ZIP that would have been installed by CWM. Similarly I could have worked through some form of installation shell script. But for an important operation such as flashing, I prefer the one-at-a-time approach of the interactive shell.
Note that CWM does have an ADB service running with it. Your Ouya would show up as a different device while in CWM, so you'd need to enter Device Manager (Windows) and point the unknown device to the same ADB driver as used for the main ROM.
Alternatively you could skip ADB for this Ouya Boot Menu installation and set up an SSH server on your main ROM. I personally have installed "SSH Server" (Ice Cold Apps). I recall two screens to set up (does require the trackpad in cases), where I enabled automatic start on both, and also set the port number to 2222. After an Ouya reboot I had SSH/SCP capability and could use PuTTY/pscp from Windows.

Hal9k+1...fast reply, thank you.
Just to put my ever-so-senile brain at ease: so I run StockPlus 519r1, and WHILE in the ROM, I start ADB and follow your instructions .
OR...I enter CWM, make sure I get the right ADB drivers installed for THAT instance and go from there.
For a developer, I'm sure it's easier and more familiar to run ADB commands - for people like me (5%-over-the average-user) a CVM option to flash a zip and do all this would be more in-line with the abilities to hack.
I have rooted 4-5 devices so far and the only time I type any ADB commands is at root/unlock time - sometimes not even then (Nexus 4 and the Root Toolkit).
So if you ever consider creating a recovery flashable file, it would help many. Probably not me, as by then I would have done the ADB trick

Sounds like great work! I was hoping to implement something like this myself, but I haven't made any more time for OUYA-related development in a while (due to positive life events/busyness)
I will definitely take a look at your work when I have time!
~Troop

Ipse_Tase said:
Hal9k+1...fast reply, thank you.
Just to put my ever-so-senile brain at ease: so I run StockPlus 519r1, and WHILE in the ROM, I start ADB and follow your instructions .
OR...I enter CWM, make sure I get the right ADB drivers installed for THAT instance and go from there.
Click to expand...
Click to collapse
You got it! You don't need to worry about booting to the other partition prior to flashing. That is a given partition (LNX/SOS) is no longer being accessed once the image is booted. For CWM's ADB, you'd simply point Windows to the same INF file that you originally used. Hope this helps.

StockPlus Installation
Well, I finally retired this old stock 393 ROM I was on, and moved to StockPlus 519r2. I was not able to install it the normal way given my Boot image is in place here. So I ended up modifying "updater-script" under META-INF/com/google/android, and then repackaged prior to running the install procedure. I'm attaching my changed version in case it helps anyone, and please note that it makes StockPlus the main image (kernel.img).
(You'll need to right-click to save the attachment. Once done it will need to be renamed such that it does not include the ".txt" suffix.)
The Windows "7-Zip" utility is helpful for packaging. You may start by right-clicking the downloaded ZIP, then 7-Zip --> Extract to "OUYA_[...]". Enter the newly created directory, get to the updater-script, and replace it with mine. Now back up to the area with META-INF, system, and boot.img, still in the new directory. Select all three under Windows (Ctrl+Click), right click that area, and then 7-Zip --> Add to "OUYA_[...].zip". Be sure this new ZIP is the one that makes it to the Ouya.

Still haven't tried this out yet, but I hope to soon.
I missed out on news over the holidays though and just noticed this:
Announcing Ubuntu and Android dual boot developer preview
http://developer.ubuntu.com/2013/12/announcing-ubuntu-and-android-dual-boot-developer-preview/
I'm curious of their dual boot implementation and how it compares and if we can synergize with their approach, but haven't looked into the details of how theirs works yet (its sounds like it uses a custom recovery image, and they have the ability to trigger it to reboot into Ubuntu from an Android app and vice versa, which is cool)
It'd be awesome to be able to multi-boot an Ouya ROM, an Android ROM (CyanogenMod), and Ubuntu with that kind of ease.
EDIT: This may be more our speed though: (MultiROM)
http://forum.xda-developers.com/showthread.php?t=2011403
(did you pull anything from there? Sounds like they have a modified TWRP that can flash zips to the other ROM slots, which is something I was also hoping to implement)
~Troop

Thanks, Trooper. Good to see Ubuntu moving further along in the mobile world.
I briefly looked at MultiROM since it originated from the KExec-HardBoot work, but decided not to go in that direction. The main reason is that I decided not to pursue the setup/learning of an Android build environment, but also because it wasn't clear how I'd deal with our lack of a touchscreen and lack of volume up/down buttons. I ended up creating a small application that fits within Ouya's CWM framework and starts up before CWM itself; it monitors the power button for click events and writes to the framebuffer memory region using regular Linux calls.
I'm not too concerned about the dual-boot aspect of this new Ubuntu, but the lack of touchscreen could be a hindrance if mouse/keyboard were not a viable substitute. Whether this Ubuntu is designed to work from external storage is another question, since our /system and /data would be occupied by Android. But in general I think we could boot it from my framework, and if my Boot image were selected over the Recovery one, then the Ubuntu kernel could reside in Recovery and also be bootable from the Android side with the "reboot recovery" command.
Best of luck, and hope you'll have a chance to try it all!

accidental post please delete

[Guide][SM-T500/T505] Galaxy Tab A7 10.4 - Creating more space (no root)

Hi
Since no one reads this bit of the OP, let's get to it. Credit to Cloudxddd for posting the sd card fix in another thread.
Enable ADB shell
On your Tablet:
Open the settings app
Scroll down to 'About tablet'
Select 'Software information'
Continuously tap on 'Build number' over and over until at the bottom of the screen you see a toast saying "Developer mode has been enabled"
Go back to the main settings page and scroll down, select the new 'Developer options' button
Enable 'USB debugging' (press OK to confirm)
On Ubuntu:
Install ADB: sudo apt install adb
Plug your tablet into your PC via USB
Start ADB and check your device is connected: adb devices (if more than one device is listed, unplug your second android phone/tablet
You may need to approve the connection on your tablet
Run ADB shell: adb shell
Remove stock apps (bloatware)
In ADB shell (see above):
List the apps installed: pm list packages
Removing some apps will cause your tablet to brick (fixed by doing a factory reset from the recovery menu), so be careful
Search APK Mirror for the package name if you don't know what app you're looking at
To uninstall an app from your user but keep it on the device: pm uninstall -k --user 0 <packagename>
Reboot the device to ensure it can boot successfully: reboot
Reply below with the apps you removed and whether it was successful / safe
Reinstall that app: cmd package install-existing <package name> (or do a factory reset if it failed)
Completely remove the app and reclaim the space if you're certain it can be removed safely: pm uninstall <packagename>
Reboot the device to ensure it can boot successfully: reboot
Note: Some apps reinstall when you reboot.
Apps that might be safe to remove - Please reply with updates
Package nameApp nameSafe to remove?com.samsung.android.video
Samsung video playerYescom.samsung.android.app.dofviewer
com.samsung.android.app.siofviewer
Samsung live focus?
com.samsung.android.app.dressroom
Samsung wallpapers?
com.sec.android.widgetapp.webmanualSamsung user manualYescom.samsung.android.allshare.service.mediashareSamsung nearby service?com.samsung.android.app.clockpackSamsung clock style?com.google.android.apps.youtube.musicYoutube musicYescom.sec.android.app.bluetoothtestSamsung bluetooth test?
com.samsung.app.newtrimSamsung video trimmer?com.samsung.android.app.shareliveSamsung quick share?
com.samsung.android.scloudSamsung cloud?
com.samsung.android.stickercenterSamsung sticker center?
com.android.chromeGoogle chrome?com.google.android.apps.mapsGoogle maps?
com.google.android.apps.docsGoogle docs?
com.sec.android.gallery3dSamsung gallery?com.google.android.apps.tachyonGoogle DuoYescom.sec.android.app.soundaliveSamsung soundalive?com.microsoft.skydriveMicrosoft onedriveYescom.netflix.mediaclient
com.netflix.partner.activationNetflixYescom.google.android.youtubeYoutubeYescom.google.android.videosGoogle play movies and tvYes
Enable apps to SD
In ADB shell (see above):
List disks: sm list-disks
Partition the disk to be used entirely for apps to SD: sm parition <DISK> private
Partition a percentage of the disk to be used for apps to SD: sm partition <DISK> mixed <number>
Reboot: reboot
Open the 'Settings' app and and select 'Apps'
Select an app
Tap 'Storage'
Tap 'Change' to move it to the SD card (if the app supports this)

Thanks for this! will try today!

.

Hi,
Thanks for sharing. It does delete...but everytime i reboot it comes back...

lukyjay said:
Hi
Since no one reads this bit of the OP, let's get to it. Credit to Cloudxddd for posting the sd card fix in another thread.
Enable ADB shell
On your Tablet:
Open the settings app
Scroll down to 'About tablet'
Select 'Software information'
Continuously tap on 'Build number' over and over until at the bottom of the screen you see a toast saying "Developer mode has been enabled"
Go back to the main settings page and scroll down, select the new 'Developer options' button
Enable 'USB debugging' (press OK to confirm)
On Ubuntu:
Install ADB: sudo apt install adb
Plug your tablet into your PC via USB
Start ADB and check your device is connected: adb devices (if more than one device is listed, unplug your second android phone/tablet
You may need to approve the connection on your tablet
Run ADB shell: adb shell
Remove stock apps (bloatware)
In ADB shell (see above):
List the apps installed: pm list packages
Removing some apps will cause your tablet to brick (fixed by doing a factory reset from the recovery menu), so be careful
Search APK Mirror for the package name if you don't know what app you're looking at
To uninstall an app from your user but keep it on the device: pm uninstall -k --user 0 <packagename>
Reboot the device to ensure it can boot successfully: reboot
Reply below with the apps you removed and whether it was successful / safe
Reinstall that app: cmd package install-existing <package name> (or do a factory reset if it failed)
Completely remove the app and reclaim the space if you're certain it can be removed safely: pm uninstall <packagename>
Reboot the device to ensure it can boot successfully: reboot
Note: Some apps reinstall when you reboot.
Apps that might be safe to remove - Please reply with updates
Package nameApp nameSafe to remove?com.samsung.android.video
Samsung video playerYescom.samsung.android.app.dofviewer
com.samsung.android.app.siofviewer
Samsung live focus?
com.samsung.android.app.dressroom
Samsung wallpapers?
com.sec.android.widgetapp.webmanualSamsung user manualYescom.samsung.android.allshare.service.mediashareSamsung nearby service?com.samsung.android.app.clockpackSamsung clock style?com.google.android.apps.youtube.musicYoutube musicYescom.sec.android.app.bluetoothtestSamsung bluetooth test?
com.samsung.app.newtrimSamsung video trimmer?com.samsung.android.app.shareliveSamsung quick share?
com.samsung.android.scloudSamsung cloud?
com.samsung.android.stickercenterSamsung sticker center?
com.android.chromeGoogle chrome?com.google.android.apps.mapsGoogle maps?
com.google.android.apps.docsGoogle docs?
com.sec.android.gallery3dSamsung gallery?com.google.android.apps.tachyonGoogle DuoYescom.sec.android.app.soundaliveSamsung soundalive?com.microsoft.skydriveMicrosoft onedriveYescom.netflix.mediaclient
com.netflix.partner.activationNetflixYescom.google.android.youtubeYoutubeYescom.google.android.videosGoogle play movies and tvYes
Enable apps to SD
In ADB shell (see above):
List disks: sm list-disks
Partition the disk to be used entirely for apps to SD: sm parition <DISK> private
Partition a percentage of the disk to be used for apps to SD: sm partition <DISK> mixed <number>
Reboot: reboot
Open the 'Settings' app and and select 'Apps'
Select an app
Tap 'Storage'
Tap 'Change' to move it to the SD card (if the app supports this)
Click to expand...
Click to collapse
I've tried enable apps to sd . I've done everything as above and all seems to work but I still can't transfer any apps to sd card .

Johnseventythree said:
I've tried enable apps to sd . I've done everything as above and all seems to work but I still can't transfer any apps to sd card .
Click to expand...
Click to collapse
Yep, same. I split the card 50/50. After a reboot, the actual card even showed as only half the size. But there was just no button at all in any app´s storage settings. And I know what to look for! Because my thine actually has that exact button. To me this looks like Samsung just flat out disabled the feature.

I just hope someone comes up with an answer to samsungs mess up as the tablet is good . Would rooting the tablet make it so I could save apps to the sd card .

I did this on my Windows laptop. ADB wouldn't recognize the tablet until I downloaded the drivers from Samsung and installed them. I hadn't had to install anything other than the Google drivers until now.

grabber5.0 said:
I did this on my Windows laptop. ADB wouldn't recognize the tablet until I downloaded the drivers from Samsung and installed them. I hadn't had to install anything other than the Google drivers until now.
Click to expand...
Click to collapse
Oh rite could you possibly post a link to the drivers please. When I open ADB it shows the serial number of my table so I just thought all was OK but maybe installing the official drivers from samsung will solve this issue . Thanks mate .

Johnseventythree said:
Oh rite could you possibly post a link to the drivers please. When I open ADB it shows the serial number of my table so I just thought all was OK but maybe installing the official drivers from samsung will solve this issue . Thanks mate .
Click to expand...
Click to collapse
Here is the link for the Samsung USB drivers: https://developer.samsung.com/mobile/android-usb-driver.html
Without the drivers, ADB does not show the device at all, so I think you're fine.

grabber5.0 said:
Here is the link for the Samsung USB drivers: https://developer.samsung.com/mobile/android-usb-driver.html
Without the drivers, ADB does not show the device at all, so I think you're fine.
Click to expand...
Click to collapse
Oh right well I've done everything it says and nothing has changed I still don't have the option to save apps to memory card . I'll try the drivers and thankyou for the link . Why samsung has done this is beyond me ..

lukyjay said:
Hi
Since no one reads this bit of the OP, let's get to it. Credit to Cloudxddd for posting the sd card fix in another thread.
Enable ADB shell
On your Tablet:
Open the settings app
Scroll down to 'About tablet'
Select 'Software information'
Continuously tap on 'Build number' over and over until at the bottom of the screen you see a toast saying "Developer mode has been enabled"
Go back to the main settings page and scroll down, select the new 'Developer options' button
Enable 'USB debugging' (press OK to confirm)
On Ubuntu:
Install ADB: sudo apt install adb
Plug your tablet into your PC via USB
Start ADB and check your device is connected: adb devices (if more than one device is listed, unplug your second android phone/tablet
You may need to approve the connection on your tablet
Run ADB shell: adb shell
Remove stock apps (bloatware)
In ADB shell (see above):
List the apps installed: pm list packages
Removing some apps will cause your tablet to brick (fixed by doing a factory reset from the recovery menu), so be careful
Search APK Mirror for the package name if you don't know what app you're looking at
To uninstall an app from your user but keep it on the device: pm uninstall -k --user 0 <packagename>
Reboot the device to ensure it can boot successfully: reboot
Reply below with the apps you removed and whether it was successful / safe
Reinstall that app: cmd package install-existing <package name> (or do a factory reset if it failed)
Completely remove the app and reclaim the space if you're certain it can be removed safely: pm uninstall <packagename>
Reboot the device to ensure it can boot successfully: reboot
Note: Some apps reinstall when you reboot.
Apps that might be safe to remove - Please reply with updates
Package nameApp nameSafe to remove?com.samsung.android.video
Samsung video playerYescom.samsung.android.app.dofviewer
com.samsung.android.app.siofviewer
Samsung live focus?
com.samsung.android.app.dressroom
Samsung wallpapers?
com.sec.android.widgetapp.webmanualSamsung user manualYescom.samsung.android.allshare.service.mediashareSamsung nearby service?com.samsung.android.app.clockpackSamsung clock style?com.google.android.apps.youtube.musicYoutube musicYescom.sec.android.app.bluetoothtestSamsung bluetooth test?
com.samsung.app.newtrimSamsung video trimmer?com.samsung.android.app.shareliveSamsung quick share?
com.samsung.android.scloudSamsung cloud?
com.samsung.android.stickercenterSamsung sticker center?
com.android.chromeGoogle chrome?com.google.android.apps.mapsGoogle maps?
com.google.android.apps.docsGoogle docs?
com.sec.android.gallery3dSamsung gallery?com.google.android.apps.tachyonGoogle DuoYescom.sec.android.app.soundaliveSamsung soundalive?com.microsoft.skydriveMicrosoft onedriveYescom.netflix.mediaclient
com.netflix.partner.activationNetflixYescom.google.android.youtubeYoutubeYescom.google.android.videosGoogle play movies and tvYes
Enable apps to SD
In ADB shell (see above):
List disks: sm list-disks
Partition the disk to be used entirely for apps to SD: sm parition <DISK> private
Partition a percentage of the disk to be used for apps to SD: sm partition <DISK> mixed <number>
Reboot: reboot
Open the 'Settings' app and and select 'Apps'
Select an app
Tap 'Storage'
Tap 'Change' to move it to the SD card (if the app supports this)
Click to expand...
Click to collapse
Brilliant! I almost quit initially but then realized you spelled partition wrong.
List disks: sm list-disks
Partition the disk to be used entirely for apps to SD: sm parition <DISK> private
Partition a percentage of the disk to be used for apps to SD: sm partition <DISK> mixed <number>
But after that it still didn’t work. But I heard Rona cheering me on. Dug into the crates of Google and found this and it worked! I used AppMgr III to move the apps. I was able to move Amazon successfully.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}

mydjtl said:
Brilliant! I almost quit initially but then realized you spelled partition wrong.
List disks: sm list-disks
Partition the disk to be used entirely for apps to SD: sm parition <DISK> private
Partition a percentage of the disk to be used for apps to SD: sm partition <DISK> mixed <number>
But after that it still didn’t work. But I heard Rona cheering me on. Dug into the crates of Google and found this and it worked! I used AppMgr III to move the apps. I was able to move Amazon successfully.
View attachment 5217751
Click to expand...
Click to collapse
mydjtl said:
Brilliant! I almost quit initially but then realized you spelled partition wrong.
List disks: sm list-disks
Partition the disk to be used entirely for apps to SD: sm parition <DISK> private
Partition a percentage of the disk to be used for apps to SD: sm partition <DISK> mixed <number>
But after that it still didn’t work. But I heard Rona cheering me on. Dug into the crates of Google and found this and it worked! I used AppMgr III to move the apps. I was able to move Amazon successfully.
View attachment 5217751
Click to expand...
Click to collapse
Amazing it worked flawlessly thankyou so much my daughters tablet has space again and she's not lost any of her apps . Respect to ya ....

mydjtl said:
Brilliant! I almost quit initially but then realized you spelled partition wrong.
List disks: sm list-disks
Partition the disk to be used entirely for apps to SD: sm parition <DISK> private
Partition a percentage of the disk to be used for apps to SD: sm partition <DISK> mixed <number>
But after that it still didn’t work. But I heard Rona cheering me on. Dug into the crates of Google and found this and it worked! I used AppMgr III to move the apps. I was able to move Amazon successfully.
View attachment 5217751
Click to expand...
Click to collapse
I followed these steps, and everything seems to work. Only some apps can be moved to the SD card, but that's not surprising.
However, after rebooting, Android decides that the app data is corrupted, and forces me into safe mode, from which a factory reset is the only solution.
So this only works for me if I never reset or power off the device.
Have to say, I'm never buying Samsung again. I've just had so many issues with this device. Even trivial stuff, like not being able to connect to Wifi via WPS when setting up the device (or when doing a factory reset)
After rebooting, I the tablet doesn't restart - it boots into Android Recovery, and the rescue summary shows I get NullPointerException: Attempt to invoke virtual method WindowManagerService.detectSafeMode() on a null object reference.

according to me, this method doesn't seem to work. i've got a 64gb microsd, followed the steps as indicated, after reboot the sd card shows up as "corrupted" and everytime a format is needed. unfortunately, moving apps to sd seems to be not possible. such a shame since the tab s7 can do it and this one not. hope that with android 11 update (if ever there will be) they enable this feature.

kitamurt said:
according to me, this method doesn't seem to work. i've got a 64gb microsd, followed the steps as indicated, after reboot the sd card shows up as "corrupted" and everytime a format is needed. unfortunately, moving apps to sd seems to be not possible. such a shame since the tab s7 can do it and this one not. hope that with android 11 update (if ever there will be) they enable this feature.
Click to expand...
Click to collapse
for me it works !
did you understand how adoptable storage works ??? no, then read this!
'adoptable-storage' tag wiki
Q&A for enthusiasts and power users of the Android operating system
android.stackexchange.com
i did the following and it works for me:
1. format your inserted SD-Card in the Tab A7 and dismount the SD-card after formatting
2. enable USB-debugging and connect with adb console to Tab A7
3. enter the following commands
Code:
adb shell
sm list-disks adoptable
i got the result
Code:
disk:179,32
my SD-card is 128GB size and i want 32GB (25% of total SD-Card)
for use as internal adopted storage
therefore i want 96GB (75% of total SD-Card) as external SD-card
to do this use the following commands (as adviced in posting #12)
Code:
sm set-force-adoptable true
sm partition disk:179,32 mixed 75
sm set-force-adoptable false
then i rebooted my Tab A7 and mounted the external SD-card (which shows 86,9GB)
the internal storage shows two items
1. internal storage 32GB
2. SD-Card adopted storage ( it doesnt tell you the adopted storage size but
it says 100GB used out of 128GB) which means 28GB are free for further usage,
at this point i have moved already all apps which are moveable to external storage.
i use the app "AppMgr III" as App 2 sd - utility
there are no errors or other problems after rebooting or during normal use.
it just works
hth
tiwag

tiwag said:
for me it works !
did you understand how adoptable storage works ??? no, then read this!
'adoptable-storage' tag wiki
Q&A for enthusiasts and power users of the Android operating system
android.stackexchange.com
i did the following and it works for me:
1. format your inserted SD-Card in the Tab A7 and dismount the SD-card after formatting
2. enable USB-debugging and connect with adb console to Tab A7
3. enter the following commands
Code:
adb shell
sm list-disks adoptable
i got the result
Code:
disk:179,32
my SD-card is 128GB size and i want 32GB (25% of total SD-Card)
for use as internal adopted storage
therefore i want 96GB (75% of total SD-Card) as external SD-card
to do this use the following commands (as adviced in posting #12)
Code:
sm set-force-adoptable true
sm partition disk:179,32 mixed 75
sm set-force-adoptable false
then i rebooted my Tab A7 and mounted the external SD-card (which shows 86,9GB)
the internal storage shows two items
1. internal storage 32GB
2. SD-Card adopted storage ( it doesnt tell you the adopted storage size but
it says 100GB used out of 128GB) which means 28GB are free for further usage,
at this point i have moved already all apps which are moveable to external storage.
View attachment 5261485
i use the app "AppMgr III" as App 2 sd - utility
there are no errors or other problems after rebooting or during normal use.
it just works
hth
tiwag
Click to expand...
Click to collapse
thx, found out that the sd card was not working correctly. tried with another one and worked flawlessly!
update: the method seems to be very unstable, if compared to app installed on internal memory. anytime i try to run an app, it's ok for 10-15 minutes, then suddenly blocks and reboots. this happens everytime and once rebooted, it will show that apps are not installed on ext sdcard; temporary fix when rebooted again, but it's very bothering.

FYI those methods work but are limited as you can't move certain apps or can't move their data sometimes.
If you're looking for even more space, I'd recommend App2sd (by Vicky Bonick, NOT the appMgr iii automatisation thing). You'll have to format your sd card with two partitions :
- one FAT32, that will be used as a "standard" sd card, visible by the device and all
- one F2FS, that will be used to link apps to sd card and will be invisible to most of the apps.
when asked to provide su.dpost-fs-data.d/service.d adress I used :
Code:
/data/adb/service.d
But, yes it requires root access. I'm still giving it a try but so far this is the only method that I've managed to move stuff like Genshin impact and its 8GB of data that somewhat disappear into thin air using other methods.
EDIT : after messing around for a few hours. This method is still not perfect ... I have troubles moving some obb files with it. But it's still worth a shot

tiwag said:
for me it works !
there are no errors or other problems after rebooting or during normal use.
it just works
hth
tiwag
Click to expand...
Click to collapse
Thanks, followed your guide and initially it worked correctly.
I also rebooted the table and it still worked.
However now (after a shutdown) the SD card is recognized as corrupt / damaged (translated).
It is still part of the adoptable storage.
I earlier reported it didn't work anymore after a reboot.
However checking a few days later it works again.
I guess it ran out of battery and rebooted.....
Thanks.

It works great on my SM-T500. I was able to use my 64GB SD Card as Device Storage. I was able to move Asphalt 8 game from Internal Storage to SD Card