[General Topics] S0AndS0:
Working on the guide and related questions today. Likely all day.

You're welcome; I work hard so others need not meet friction.

It would be nice to know how you're usage and device differs from the guide and other user experiences; so if ya the time and initiative can ya please post about it?

UPDATES to comments bellow

Ok did some digging around in my old notes that I keep from old fails and some of the info I've to drop is:

When dealing with the appending errors on a read only file system (tis what my myTouch 3Gs uses too) sometimes the only way to try a second install attempt is; running a restore from a point in time before your device met Debian Kit. This is do to some of the funny ways that root and sudo and su are handles across the OS; for instance if I edit something with ROM Tool Box that resides on my linux partition and then try to open that file on the Linux side, I receive permission errors until I've changed the ownership and permissions back to what they where before I touched it with an app on android that requires/uses its own calls for supper user; kinda funky but it's possible if ya fiddle round with permissions either in the app that I use or using commands like chown and chmod(sp?) on the linux side to get things on a read only file system to still read and write when the correct owner makes the request.

The other issue you might be running into is "Kernel capabilities" like we've been talking in the other posts, about the Kernel support for hard float verse soft float, there are other features that are available to certain kernel users some of which are required for some Linux distributions to run on Android... For me I usually run with a "Clean GB" or "Shadow knightly(sp?)" Kernel that supports loop and chmod amongst the host of other things that a Kernel does.

try a search like

Samsung s3 root Linux compatible kernel -"how to root"

which gave me info leading me to believe that "loop device" is a feature that you'll want to be looking for in either the rom or the kernel that you run on the Android side of things. CM10 looks to be one of the ones that might just support it if things are set up correctly.

On the scripting side of things. Its all good, I'm a bit fresh myself to the bash thing, I've scripted for a long time in other languages hear and there when the need and education considered but I'll be diving in (have been diving deep into it actually) in order to get solutions rolling out in an easy to execute form. It's a steep curve of learning if you look straits up at it but if you spiral round an issue, problem, or task; a solution can usually be hypothesized and if a hypothesis can be organized in how it should be executed then the task can be broken down into much more manipulable chunks, its surprising the first few times you give yourself an "ah ha" moment when ya discover that the whole scripting thing isn't as hard as it looks but eventually (if you're persistent and don't get frustrated at the words and terms that don't make sense yet:p) because really it's just a way of structuring thoughts so a computer can carry the burden of repetitive tasks.

The other thing ya might try is within the boot script are directions involving "pivot-rooted" command that might allow you a workaround. Saw some info to it and it sounded like it might work for some.

Thank you.

Made the edits to the split document, yours works way better at installing a bunch of things :)

As far as armel v armhf ... I'm still reading up on it, lots of other reading; but I use all the comments I receive as "search seeds" for when I'm taking breaks from other tasks.

UPDATES Responses to comments from today

Greetings from across the net :D

I'm glad that you are able to make use of this guide. If you feel up to it I would appreciate translation from English to French because I see no reason to keep this in the hands of one language, this should be everywhere for anyone to use (though I understand that that would be a huge task as the guide is still under construction and it would be a pain to keep up with all the minor updates).

In relation with the size of ISO; are you referring to the Debian Kit or Limbo methods? Either way its good to know it's useful.

I've thought that this would be good for devices that would normally be trashed dew to a broken screen. Did you have to use a USB connection and tell your device what to do with a computer such as with the Android Debug Bridge, or is your device still functional "enough" to run the install process? I as because eventually I'll be working on an "update.zip" (after the install script that I've been putting together is complete that is) that will be installable through the most custom recoveries and hopefully through the USB ADB. Reason One for this; devices with broken hardware for the user interface but are otherwise technically functional otherwise, and Reason Two; because having an USB ADB installable form of Linux would enable us all to use one phone with Linux installed on it to (through a modded cable or one specially purchased on line for this task) then install onto another rooted device... end game for all those reading that really want to know what this means? Well can we say maybe combining all the "one click root" exploits for all known devices into a repository that can be automatically accessed from the device running Linux when a new device is plugged into it, the device that is running Linux will then install the required drivers and packages to make a conection to the target device as though the device running Linux is an actual computer, run a backup of all data that will be wiped when rooting (nan-droid backup to the Linux running device) run the exploit onto the target device and obtain wireless ADB permissions and install the target devices' old settings and apps with a ROM and kernel that looks much like the original, from there it will be a matter of connecting over the wireless ADB connection and installing the rest of the Linux distribution and an auto boot script to start the OS and networking interfaces. This be a stretch goal and a lofty one at that but one that I'll inevitably want to tackle because; One in the right hands with good intentions, a mobile "Skeleton Key" would be darn handy for when I semi-brick one of my devices or when someone I know ends up wanting to get root but not have to work for it; Two in the wrong hands with the worst of intentions something like that could then be expanded into something that interfaces with any device that is insecure... and that is a game leveler right there... not saying to go and make bad choices, I just know that pen-testing is a big part of network security.

On the subject of a full install of Linux to ARM devices.

There are projects out there right now working on that, Ubuntu touch to name one, but many of them are rife with compatibility issues or just not having certain things with in the device accessible just yet. We've actually talked and possibly linked to some information on that already in this thread... I'll have to start compiling a section in the guide for content added because and by the forums that this guide is apart of... that being stated I've actually had some new musings on this subject, thanks mostly to the Raspberry Pi developer communities that I'm always haunting for info on running Linux on the ARM processor.

So I've seen some guides kicking around on building roms, kernels, and update.zips and guides on how to properly sign them so that they run from the boot loader or custom recovery screen; and I've seen install instructions on how to compile custom Debian Raspberry Pi builds for pre-defined hardware (meaning that one would have to know every detail of the hardware of their device before hand) which then runs off an SD card reader on the device; and I've seen ways to run android off the SD card instead of internal memory...

So if one where to wrap these up into one guide it would look something like this

step one learn everything about the device and get drivers/kernel/Linux OS for the; processor, user input hardware, modems/antenna

step two get an android ROM that will run off your SD card instead of internal memory

step three boot android from SD (Note: if you do this part you can't connect your device to a USB connection, just don't do it)

step three wipe out internal operating system (Note: this is a hypothesis and shouldn't be followed, in fact all these steps should be suspect)

step four install to the device's internal memory all the partitions, directories, packages, scripts, pretty much the whole custom built Linux OS that will likely be a branch of raspberry pi and very time incentive because at this point many of the operations would have to be run by you at the command line of a terminal emulator

step five ensure all the permissions for the files are set correctly, because if you don't and you reboot into an operating system that can't read or write to it's self the way that it expects that it should then things just don't work the way they should

step six ensure all system links are in-place, meaning that the operating system will know how to access the parts of itself and the parts of hardware that handle and store data

step seven reboot the device and let it go past the point of no return (meaning past the point of boot loader or custom recovery button combo) and see if it boots

step beyond that debugging and adding features and adding customization

these are just how I would tackle the task of replacing android with Linux on the internal memory of a device. At this point I don't have the ability to commit to something like that just yet, but I keep up on all the happenings around the 'verse that have to do with things like this and I'll likely have more musings that inevitably lead to another guide. Hope some of it helps and some of it inspires.

Yep no problem; I'll keep it coming as I've had a long time to learn how to learn. Neat, I'll be doing that, just found a really good template for checking for files and looping that into a silent if than function, so I'll test some of it out when I get to the Linux install part of the "super scrip" right now I'm working from the middle and spiraling outward in both directions (keeps me fresh on the task) but I'll be adding checks for things like that and hopefully enough alternate methods to try automatically after that until one succeeds with its checks (like the name implies; it'll be super) and installs one of the alternate methods and then continues its happy task of installing all the extras too.

Looking forward to it. This is what the net is for ideally right?/; exchange of information.