Linux/Android on CDMA Touch Pro -- Now working on Verizon! And with GPS! - Page 281

Flak · #**2801** (**permalink**) 06-11-2010, 08:30 PM

Quote:

Originally Posted by arrrghhh

Well it sounds like you didn't go thru calibration.

You were correct in the diagnosis of the looping X problem, now if you have a ts-calibration file at the root of the SD (or /andboot, where haret.exe is) delete that and boot again. Watch for the calibration screen, it'll have little 4-square boxes. It may time out if you don't do it in time, which may very well be the cause of your issue. Do your best to hit the middle, and if you do it once well you can save that ts-calibration file and re-use it again and again. Hope that helps.

Just want to reiterate that the AIO from 3-31-2010 works. If I just lay the AIO from 5-11-2010 over the 3-31-2010 letting it overwrite everything (I've even moved the ts-calibration file out during this just to make sure something isn't happening to it) I still have the same problems with the screen being unresponsive once the desktop is loaded.

I've tried a clean sd of 5-11-2010 including going through calibration, samething happens. However, here it happens more that the screen goes unresponsive during the google account setup rather then going unresponsive at desktop/home screen.

I've tried building my own using the latest and get the same results as going with a clean sd of 5-11-2010 AIO.

Just to make sure it's not the SD I've tried 6 of them now, ranging in size from 4gb to 16gb all of them are at least class 4 though most are class 6. I've formated in windows, used the hp format tool and gpart. On any of them any andriod build other then AIO 3-31-2010 at some point when the screen goes unresponsive I start to get process hung/process didn't start messages.

**makkonen** · #**2802** (**permalink**) 06-11-2010, 08:41 PM

Quote:

Originally Posted by sfhub

I don't think changing the "/data" version will work for more than the current session at most.

The boot script unconditionally "rm -rf"s the "/data/etc" directory at every boot and repopulates with "/system/etc"

Also I'm not sure which process loads up gps.conf so if you edit on the currently running /data/etc something might need to get rerun for the settings to "take". However, I'm not sure about that, it might be loaded everytime it is needed, in which case changing it on /data/etc would work for the current session until reboot.

You are right... but I am fairly confident that /system/etc/ is on a read only file system, and thus it is impossible to make persistent changes to it. So... I'm not entirely clear on what's going on.

In other news, latest rootfs does not squash the boot loop problem. Looking into it now.

Edit: BUUUUUT... manually fixing the permissions on dbus.conf DOES squash the bootloop problem... even if you do it in the middle of the boot loop over adb. so, fix the command in the rootfs, and it should be done.

GatorsUF · #**2803** (**permalink**) 06-11-2010, 10:10 PM

Is there some good step by step for how to get the latest version running? I know you guys are working hard at it, but I don't understand what exactly I need to do to get the 06-06-10 version running.

peterm20 · #**2804** (**permalink**) 06-11-2010, 11:20 PM

Is anyone getting the boot loop error currently?

If you are could you try the rootfs i posted? Hopefully if this works we could get it committed to the main branch.

**makkonen** · #**2805** (**permalink**) 06-12-2010, 01:02 AM

I am getting it, and I know why. the init is a mess. I was playing around with it earlier tonight, but it put me to sleep, so I didn't get a fix together.

peterm, are you seeing a problem in the boot logs with 'mkdir -m'? I'm noticing that having trouble, as well as chown. I see you switched all the chown to chown/chgrp pairs -- have to see if that fixes things.

I'm also noticing that even though the initramfs claims to load the rootfs as read-only, it's getting written to by commands in the init script, and these persist. I must be missing something there.

Edit: Bleh. Now I can't get it to boot loop. So weird.

Edit2: Oh, right. Gotta delete the cache folder, too, or it won't go into the boot loop. WTF, init script.

Edit3: It does seem your patch fixes the boot loop. The chown commands still throw a bunch of errors, though. Which is really bugging me.

sfhub · #**2806** (**permalink**) 06-12-2010, 02:58 AM

Quote:

Originally Posted by makkonen

You are right... but I am fairly confident that /system/etc/ is on a read only file system, and thus it is impossible to make persistent changes to it. So... I'm not entirely clear on what's going on.

Oh I see, you are worrying that I'm not making the change I think I'm making.

I have /system mounted from an ext2 partition which I change to rw using "mount -o rw,remount /system"

Even not using an ext2 partition, if you want to make changes to system.sqsh you just need to unpack (outside of android on a linux box) with unsquashfs, make changes, and repack with mksquashfs.

**makkonen** · #**2807** (**permalink**) 06-12-2010, 03:01 AM

Oh. Yeah. That'll be persistent.

I just assumed you were saying to do it from within android with the squashfs filesystem -- my mistake. Makes perfect sense now.

Although why /data/etc is wiped on boot is still a little baffling to me. As I mentioned, the whole thing is sort of a mess.

**makkonen** · #**2808** (**permalink**) 06-12-2010, 03:28 AM

New All-in-One posted. Latest xdandroid package, latest rootfs (plus peterm's anti-bootlooping tweaks; Thanks!), latest initramfs, latest kernel. Can't get GPS to work on RAPH500, but works fine on the RHOD400. Could use some feedback on that.

Feels pretty responsive on both systems.

Bless this little RAPH500... its slowness makes the TP2 (an absolute DOG with WinMo 6.5 stock) feel like a world class sprinter in Android. Funny how a change in perspective can do you good. (Of course, still no audio, and the backlight never turns off... so it's still less usable in Android... oh, I made myself sad.)

Tell me what works and what doesn't, and I'll stay on top of it if I can. Cheers, everyone.

peterm20 · #**2809** (**permalink**) 06-12-2010, 11:07 AM

Quote:

Originally Posted by makkonen

I am getting it, and I know why. the init is a mess. I was playing around with it earlier tonight, but it put me to sleep, so I didn't get a fix together.

peterm, are you seeing a problem in the boot logs with 'mkdir -m'? I'm noticing that having trouble, as well as chown. I see you switched all the chown to chown/chgrp pairs -- have to see if that fixes things.

I'm also noticing that even though the initramfs claims to load the rootfs as read-only, it's getting written to by commands in the init script, and these persist. I must be missing something there.

Edit: Bleh. Now I can't get it to boot loop. So weird.

Edit2: Oh, right. Gotta delete the cache folder, too, or it won't go into the boot loop. WTF, init script.

Edit3: It does seem your patch fixes the boot loop. The chown commands still throw a bunch of errors, though. Which is really bugging me.

I posted it on the XDA side too don't know if it will get committed, Im thinking the user 1002 is missing from the /etc/shadow / /etc/passwd files so the chgrp works but chown doesn't.
I'll keep messing with the permissions to see if I can figure out the other errors.

**makkonen** · #**2810** (**permalink**) 06-12-2010, 12:05 PM

I've got commit access to the rootfs, so I can push it upstream... but I'd like to get the rest of the issues sorted before I do. (Perhaps I'm a little too proud of my generally clean commits.

)

if you connect with adb during the bootanimation, chown to 1002 (or 1002:1002) works... I don't know at which point that change is made, and if it's sometime while the init script is running (in which case we can just change the order). Moving the bit about dbus.conf down to the bottom of the file might've worked for me last night -- or I might've just missed the error message and forgot to delete the cache folder, so I just thought it worked. I was a bit tired.