Hi I built a little script to mount my SDcard @ startup of the phone and install some apps.
here it is:
Code:
sleep 2
busybox mount > /data/mount.txt
busybox ls /dev/block/vold >> /data/mount.txt
busybox mount -t vfat -o rw,dirsync,nosuid,nodev,noexec,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,shortname=mixed,utf8 /dev/block/vold/179:1 /sdcard >> /data/mount.txt
busybox mount >> /data/mount.txt
sleep 3
echo "APPS installation"
if [ -e /sdcard/Apps-install/install.txt ];
then
echo "found file" > /sdcard/Apps-install/install.txt
cd /sdcard/Apps-install
ls *.apk > ./apps.txt
for line in $(cat apps.txt); do install -c -D /sdcard/Apps-install/"$line" /data/app >> /sdcard/Apps-install/install.txt; done
echo "ok" >> /sdcard/Apps-install/install.txt
else
echo "file not found" > /sdcard/Apps-install/install.txt
fi;
sleep 2
echo "Finish"
if [ -e /data/firstboot.sh ];
then
busybox rm -f /data/firstboot.sh;
busybox rm -f /sdcard/Apps-install/apps.txt;
fi;
echo "Restart"
sleep 1
reboot
I'm sure that the code is well executed (as is have data in /data/mount.txt) but the mount of the SD and so every work related to the SD
What is strange is that script work if i execute it after the phone has completely started.
Can someone help please.
Bye
Herc.8)
A Little up for a little help
Hi,
I still need help,
thx by advance
Bye
Herc. 8)
Ok finally found bye myself.
I changed the device: /dev/block/vold/179:1 for /dev/block/mmcblk0p1
That's all.
Bye
Herc. 8)
What's the difference between these two (at least why they use the mount command, remount command, or shell command?)
su
mount -o remount,rw /dev/mtdblock3 /system
rm [whatever i want]
mount -o remount,ro /dev/mtdblock3 /system
and
adb remount
adb shell rm [whatever i want]
The first is a terminal command from the phone. (Only requires the phone)
The second is through adb to the phone. (Involves a properly configured adb, computer, usb cable, and phone)
evilkorn said:
The first is a terminal command from the phone. (Only requires the phone)
The second is through adb to the phone. (Involves a properly configured adb, computer, usb cable, and phone)
Click to expand...
Click to collapse
Wow, so people manage to type out all that craziness on the phone huh.
Thanks!
Anytime. Doubt they do that all the time, it would be easier to just make a script if you have to do that more than once. I just use root explorer, it has a button that mounts /system/ -rw.
I'm not sure about other terminals, but you can create aliases in Better Terminal Emulator
alias rw='mount -o remount,rw /dev/mtdblock3 /system'
alias ro='mount -o remount,ro /dev/mtdblock3 /system'
so now all you have to do is type rw or ro and it executes the full command. Or you can create scripts:
su
mount -o remount,rw /dev/mtdblock3 /system
cd /system/bin
echo "#! /system/bin/sh" | tee ro rw
echo "mount -o remount,rw /dev/mtdblock3 /system" >> rw
echo "mount -o remount,ro /dev/mtdblock3 /system" >> ro
chmod 755 rw ro
Same thing, except it executes the scripts instead of an alias.
For reference, these are my thoughts on the matter.
We have 3 ways to do this:
1. Get hold of SBL, change it and flash it
Currently impossible afaik.
2. Get an init.d bash script to reboot into recovery if key is pressed
Most likely possible taking these 2 assumptions into account:
a) Bash allows to detect a pressed key, something like this:
Code:
_key()
{
local kp
ESC=$'\e'
_KEY=
read -d '' -sn1 _KEY
case $_KEY in
"$ESC")
while read -d '' -sn1 -t1 kp
do
_KEY=$_KEY$kp
case $kp in
[a-zA-NP-Z~]) break;;
esac
done
;;
esac
printf -v "${1:-_KEY}" "%s" "$_KEY"
}
_key x
case $x in
$'\e[15~') reboot recovery ;;
esac
Replacing this key code for one of OB's.
But for this, we need assumption number 2:
b) Key codes mapping is the same for recoveries.
Now, while this is the method of the greatest chance to work, it is also fairly useless. Developers will often break the boot before the init.d scripts are ran. So, this code should be ran before. Hence, the third method.
3. Start a custom service in init.rc (@ ramdisk) that will detect pressed key
This would be the perfect solution as it can't be broken from kernel (zImage) or system changes. However, init.rc has its own programming language (android init language) and there's no way to run this kind of listener.
However, it is possible to run an external script located for example in /system/bin/. These can be both an executable compiled from c (higher chances of working) or a bash scripting like the aforementioned one (lower chances of working since android probably doesn't start a console on boot).
Code for this would be something like:
Code:
service exampleservice /system/bin/exampleservice
user exampleservice
group exampleservice
oneshot
So uh, am I missing anything?
Anyone has other ideas?
a lot of times i heared about pressing "G" and "Power" would boot into some kind of save mode... if thats true i guess its easyer to reprogramm that keycombo to do something else... so does that keycombo anything? i couldnt figure out^^
Sent from my LG-P970 using XDA App
Are others devices has the key combination code in SBL?
I wish I have enough knowledge about android system so i can help...
i04055 said:
Are others devices has the key combination code in SBL?
I wish I have enough knowledge about android system so i can help...
Click to expand...
Click to collapse
Yes there are devices heaving the key-combo in SBL if that answers your question. The "Samsung Galaxy S GT-I9000" e.g. has them there afaik. With that device it was possible flashing the SBL to add a "booting directly into recovery" key-combo...
So I don´t know why there should not be a solution to do the same to the OB but Noejn surely has good reason for telling its impossible.
But hey what about booting into recovery on every system startup and only boot into the system through the recovery? It´s a "quick & dirty" solution even if its possible but better than developing the way we do isn´t it? I´m not sure if its easier to change the startup that way than to add or modify a key-combo but maybe someone here does?
I'm sure (or hope..) someone can, but perhaps we should move this Thread to another part of the Forum so someone with the knowledge how to do this will read it.
d0n22 said:
But hey what about booting into recovery on every system startup and only boot into the system through the recovery? It´s a "quick & dirty" solution even if its possible but better than developing the way we do isn´t it? I´m not sure if its easier to change the startup that way than to add or modify a key-combo but maybe someone here does?
Click to expand...
Click to collapse
Yeah, i prefer that way if poosibble rather than nothing.
But if put it that way, when the phone get bootloop is it still posibbe to boot into recovery?
Sent from my LG-P970 using XDA App
This is how it's done on Xperia X8 phone.
The /system/bin/chargemon is usb-charge daemon that is being hijacked on boot (it's binary is replaced with this script)
Original chargemon is copied into "charger" to keep it's functionality.
Than "sleep 3" waits for any keypress, and checks the dump, if keys were pressed, it launches the recovery binary.
quite simple.
Code:
#!/system/bin/busybox sh
/system/bin/charger
cat /dev/input/event1 > /dev/keycheck&
sleep 3
kill -9 $!
if [ -s /dev/keycheck -o -f /data/local/tmp/xrecovery ]
then
rm -f /data/local/tmp/xrecovery
# remount rootfs rw
mount -o remount,rw rootfs /
# Umount MTDs
umount -l /dev/block/mtdblock1
umount -l /dev/block/mtdblock2
umount -l /dev/block/mtdblock3
# Mount recovery partition
cd /
rm -r /sbin
rm -f etc
tar -xf /system/bin/xrecovery.tar
# Umount /system
umount -l /dev/block/mtdblock0
# chroot
chroot / /init
fi
# remount rootfs rw
mount -o remount,rw rootfs /
chmod 0777 /dev -R
chown 0.2000 /dev/oncrpc -R
cd /
rm init*
rm logo.rle
rm default.prop
tar -xf /system/bin/ramdisk.tar
mkdir -p /minicm
cd /minicm
tar -xf /system/bin/ramdisk.tar
# Umount /system, data and cache
umount -l /dev/block/mtdblock0
umount /dev/block/mtdblock3
umount /dev/block/mtdblock1
rmdir /system /data /cache /mnt
racht said:
This is how it's done on Xperia X8 phone.
The /system/bin/chargemon is usb-charge daemon that is being hijacked on boot (it's binary is replaced with this script)
Original chargemon is copied into "charger" to keep it's functionality.
Than "sleep 3" waits for any keypress, and checks the dump, if keys were pressed, it launches the recovery binary.
quite simple.
Code:
#!/system/bin/busybox sh
/system/bin/charger
cat /dev/input/event1 > /dev/keycheck&
sleep 3
kill -9 $!
if [ -s /dev/keycheck -o -f /data/local/tmp/xrecovery ]
then
rm -f /data/local/tmp/xrecovery
# remount rootfs rw
mount -o remount,rw rootfs /
# Umount MTDs
umount -l /dev/block/mtdblock1
umount -l /dev/block/mtdblock2
umount -l /dev/block/mtdblock3
# Mount recovery partition
cd /
rm -r /sbin
rm -f etc
tar -xf /system/bin/xrecovery.tar
# Umount /system
umount -l /dev/block/mtdblock0
# chroot
chroot / /init
fi
# remount rootfs rw
mount -o remount,rw rootfs /
chmod 0777 /dev -R
chown 0.2000 /dev/oncrpc -R
cd /
rm init*
rm logo.rle
rm default.prop
tar -xf /system/bin/ramdisk.tar
mkdir -p /minicm
cd /minicm
tar -xf /system/bin/ramdisk.tar
# Umount /system, data and cache
umount -l /dev/block/mtdblock0
umount /dev/block/mtdblock3
umount /dev/block/mtdblock1
rmdir /system /data /cache /mnt
Click to expand...
Click to collapse
yeah ，from this we can see what is running before logo screen and we can mod that file
so.. is that mean we can boot to recovery mode same as x8?
racht said:
This is how it's done on Xperia X8 phone.
The /system/bin/chargemon is usb-charge daemon that is being hijacked on boot (it's binary is replaced with this script)
Original chargemon is copied into "charger" to keep it's functionality.
Than "sleep 3" waits for any keypress, and checks the dump, if keys were pressed, it launches the recovery binary.
quite simple.
Code:
#!/system/bin/busybox sh
/system/bin/charger
cat /dev/input/event1 > /dev/keycheck&
sleep 3
kill -9 $!
if [ -s /dev/keycheck -o -f /data/local/tmp/xrecovery ]
then
rm -f /data/local/tmp/xrecovery
# remount rootfs rw
mount -o remount,rw rootfs /
# Umount MTDs
umount -l /dev/block/mtdblock1
umount -l /dev/block/mtdblock2
umount -l /dev/block/mtdblock3
# Mount recovery partition
cd /
rm -r /sbin
rm -f etc
tar -xf /system/bin/xrecovery.tar
# Umount /system
umount -l /dev/block/mtdblock0
# chroot
chroot / /init
fi
# remount rootfs rw
mount -o remount,rw rootfs /
chmod 0777 /dev -R
chown 0.2000 /dev/oncrpc -R
cd /
rm init*
rm logo.rle
rm default.prop
tar -xf /system/bin/ramdisk.tar
mkdir -p /minicm
cd /minicm
tar -xf /system/bin/ramdisk.tar
# Umount /system, data and cache
umount -l /dev/block/mtdblock0
umount /dev/block/mtdblock3
umount /dev/block/mtdblock1
rmdir /system /data /cache /mnt
Click to expand...
Click to collapse
soundes quite promising... have you tried it?
Can this be usefull?
http://forum.xda-developers.com/showthread.php?t=991276
Noejn have you abandoned us ? Or are u planning to take a look at this ? Would be nice if u get OB up and running
recovery
Hi,
has there been any success with booting into recovery mode?
BR,
J
logitec said:
Hi,
has there been any success with booting into recovery mode?
BR,
J
Click to expand...
Click to collapse
No,I try to boot directly into recovery through boot.img,but I get a big "error" form the LG Security Team!
Hijacking a daemon would work if Optimus Black had those binaries. I took a quick glance at a backup and I didn't see chargemon in /system/bin.
Besides, a xRecovery is limited as it's dependent on system files so a /format can't be done which isn't really that "comfy", especially when changing fs.
But yeah, better than nothing. Still, the method you described is only possible in Xperia phones, as far as I know.
I still say injecting a service on the init.rc is the way to go.
However, I can't test this now.
racht said:
This is how it's done on Xperia X8 phone.
The /system/bin/chargemon is usb-charge daemon that is being hijacked on boot (it's binary is replaced with this script)
Original chargemon is copied into "charger" to keep it's functionality.
Than "sleep 3" waits for any keypress, and checks the dump, if keys were pressed, it launches the recovery binary.
quite simple.
Code:
#!/system/bin/busybox sh
/system/bin/charger
cat /dev/input/event1 > /dev/keycheck&
sleep 3
kill -9 $!
if [ -s /dev/keycheck -o -f /data/local/tmp/xrecovery ]
then
rm -f /data/local/tmp/xrecovery
# remount rootfs rw
mount -o remount,rw rootfs /
# Umount MTDs
umount -l /dev/block/mtdblock1
umount -l /dev/block/mtdblock2
umount -l /dev/block/mtdblock3
# Mount recovery partition
cd /
rm -r /sbin
rm -f etc
tar -xf /system/bin/xrecovery.tar
# Umount /system
umount -l /dev/block/mtdblock0
# chroot
chroot / /init
fi
# remount rootfs rw
mount -o remount,rw rootfs /
chmod 0777 /dev -R
chown 0.2000 /dev/oncrpc -R
cd /
rm init*
rm logo.rle
rm default.prop
tar -xf /system/bin/ramdisk.tar
mkdir -p /minicm
cd /minicm
tar -xf /system/bin/ramdisk.tar
# Umount /system, data and cache
umount -l /dev/block/mtdblock0
umount /dev/block/mtdblock3
umount /dev/block/mtdblock1
rmdir /system /data /cache /mnt
Click to expand...
Click to collapse
Good news, I'm getting close.
ok, thank you for everithing
Noejn said:
Good news, I'm getting close.
Click to expand...
Click to collapse
good news indeed^^ im working on it as well but im not feeling like getting close :-\ pls let me know what you did and how you did it as soon as its done... again thank you very much for your efforts!
Sent from my LG-P970 using XDA App
d0n22 said:
good news indeed^^ im working on it as well but im not feeling like getting close :-\ pls let me know what you did and how you did it as soon as its done... again thank you very much for your efforts!
Sent from my LG-P970 using XDA App
Click to expand...
Click to collapse
Well, I've succeed injecting the script on boot.
However, I'm getting some problems on the event0 > keycheck; I don't think at this time of boot /dev entries are up.
But I've already thought of a workaround and I'll test it tomorrow.
I´m thinking, if i compile kernel of ubuntu and install it in recovery partition, not possible then run ubuntu in native mode from sdcard with dualboot?
Hi
i ve got a problem with the whole stuff.
it runs smoothly, but the filesystem is read-only.
it's a img file and script. it makes a chrooted system.
the problem could be the script. may the point where the partitions mounted.
or anywhere. i dont know.
i guess the problem:
#
busybox mknod /dev/block/loop255 b 7 255 > /dev/null 2>&1
busybox losetup /dev/block/loop255 ./ubuntu.img > /dev/null 2>&1
busybox mount /dev/block/loop255 /data/local/mnt > /dev/null 2>&1
#
the last line.
or
#
busybox mount -t proc proc /data/local/mnt/proc > /dev/null 2>&1
busybox mount -t devpts devpts /data/local/mnt/dev/pts > /dev/null 2>&1
busybox mount -t sysfs sysfs /data/local/mnt/sys > /dev/null 2>&1
busybox chroot /data/local/mnt /root/init.sh > /dev/null 2>&1
#
if its not enough to find out
i ll attach the file, but im writing from phone right now
Please help i cant wait xd
i neeed a writable system.
Hey there,
it's known that ext4 with disabled journaling is little faster than default, but it is also less reliable.
This can result in screwed up homescreens and force-closes after reboot/shutdown/battery pull.
I have successfully re-enabled journaling for system and cache partition, but it seems not to work correctly for data partition, at least for me. Can you help?
Code:
echo ..............system Partition...............
/sbin/busybox umount -l /system
/sdcard/tmp/tune2fs -O +has_journal -c 5 -i 5d -m 0 -o journal_data_ordered /dev/block/mmcblk0p1
fsck.ext4 -Dfy /dev/block/mmcblk0p1
/sbin/busybox mount -t ext4 -o nosuid,nodev,noatime,nodiratime,barrier=0,nobh,data=ordered,noauto_da_alloc /dev/block/mmcblk0p1 /system
echo ...............done...............
echo ...............cache Partition...............
/sbin/busybox umount -l /cache
/sdcard/tmp/tune2fs -O +has_journal -c 100 -i 100d -m 0 -o journal_data_writeback /dev/block/mmcblk0p2
fsck.ext4 -Dfy /dev/block/mmcblk0p2
/sbin/busybox mount -t ext4 -o nosuid,nodev,noatime,nodiratime,barrier=0,nobh,data=ordered,noauto_da_alloc /dev/block/mmcblk0p2 /cache
echo ...............done...............
echo ...............data Partition...............
/sbin/busybox umount -l /data
/sdcard/tmp/tune2fs -O +has_journal -c 5 -i 5d -m 0 -o journal_data_ordered /dev/block/mmcblk0p8
fsck.ext4 -Dfy /dev/block/mmcblk0p8
/sbin/busybox mount -t ext4 -o nosuid,nodev,noatime,nodiratime,barrier=0,nobh,data=ordered,noauto_da_alloc /dev/block/mmcblk0p8 /data
sync
echo ...............done...............
Semi-finished:
Flash journaling.zip via CWM to enable back journaling
Download
Download 'terminal emulator' from market and type the following to test if it works.
If 'has_journal' is present then journaling is enabled.
For /system
Code:
/system/bin/tune2fs -l /dev/block/mmcblk0p1 | grep features
For /cache
Code:
/system/bin/tune2fs -l /dev/block/mmcblk0p2 | grep features
For /data
Code:
/system/bin/tune2fs -l /dev/block/mmcblk0p8 | grep features
Please post feedback if it works for you (fully)!
nice good work!
Thanks!
Another easy, though more time consuming, way to re-enable journaling is to let CWM do it by a complete backup and restore.
(You can also switch between ext3 and ext4 by changing the file names in clockworkmod/backup/.../ and of course also in the nandroid.md5 file.)
Please post feedback if it works for you (especially for data partition)