I am trying to run Link2SD (Motorola Droid with Bugless Beast: GPA17)and Chevy No 1 1Ghz Lv kernel)
Link2SD attempts to mount the partition at boot using /etc/install-recovery.sh but it is not working (M boot loop, kernel panic, then boots)
Trying to debug this, I modified the install-recovery.sh by adding the word TEST to the first line of the LOG:
LOG=/data/link2sd-install-recovery.log
echo "$(date) TEST mounting..." > $LOG
...
I do not see a log file with that name but there are two other log files (/data/link2sd-debuggerd.log & /data/link2sd-boot-receiver.log). In neither of these, do I see my trace statement.
So, are there additional steps that I need to perform in order to modify the script and have it run?
Thanks!
Related
It seems that all Xperia Kernels that stem back to the DoomLord kernel start the init.d execution twice. While you may think "better twice than never" the nearly parallel execution of scripts can create problems if they concurrently manipulate CPU related tables - or fail to do so due to security mechanisms built in. I was hunting the problem that cpu-clock manipulation from init.d did not work for the scripts generated by System Tuner - finally resulting in this finding.
I checked for sirkay 587c and 587d and for fly-kernel 0.8 as the latest of their breed, quite sure nobody has ever cared about this quirk.
The duplicate execution could be tracked back to the init.rc entries:
Code:
[COLOR=SeaGreen]#DooMLoRD: init.d scripts support
start sysinitsupport
class_start core
class_start main
#DooMLoRD: new init.d scripts support
service sysinitsupport /sbin/sysinitsupport.sh
class main
disabled
oneshot[/COLOR]
Which does:
Code:
#!/sbin/sh
# DooMLoRD: init.d support script (v1)
# [START] setting up
echo "[START] remounting system" > /data/local/tmp/sysinitsupportlog.txt
/sbin/busybox mount -o remount,rw /system >> /data/local/tmp/sysinitsupportlog.txt
# make init.d directory
echo "
[*] make init.d directory" >> /data/local/tmp/sysinitsupportlog.txt
/sbin/busybox mkdir -p /system/etc/init.d >> /data/local/tmp/sysinitsupportlog.txt
# correcting permissions of files in init.d directory
echo "
[*] correcting permissions of files in init.d directory" >> /data/local/tmp/sysinitsupportlog.txt
/sbin/busybox chmod 777 /system/etc/init.d/*
# [COLOR=DarkOrchid]make [/COLOR]init.d directory
echo "
[*] [COLOR=DarkOrchid]make [/COLOR]init.d directory" >> /data/local/tmp/sysinitsupportlog.txt
[COLOR=Red]/system/bin/logwrapper /sbin/busybox run-parts /system/etc/init.d[/COLOR]
# [DONE] all done exiting
echo "[DONE] all done exiting" >> /data/local/tmp/sysinitsupportlog.txt
And later also in init.rc:
Code:
[COLOR=SeaGreen]#DooMLoRD: run my mods
service mymods /sbin/execute_mods.sh
class main
oneshot[/COLOR]
Which then does:
Code:
#!/sbin/sh
# starting
echo "[ START ]" > /data/local/tmp/log_doom-mods.log
echo "" >> /data/local/tmp/log_doom-mods.log
[COLOR=Red]# execute tweaks
/system/bin/logwrapper /sbin/busybox run-parts /etc/init.d[/COLOR]
# execute FPS limit remove
/sbin/mount -t debugfs debugfs /sys/kernel/debug
/sbin/echo '0' > /sys/kernel/debug/msm_fb/0/vsync_enable
/sbin/umount /sys/kernel/debug
echo "FPS limit successfully removed " >> /data/local/tmp/log_doom-mods.log
# DONE
echo "" >> /data/local/tmp/log_doom-mods.log
echo "[ DONE ]" >> /data/local/tmp/log_doom-mods.log
You see that the execution of
Code:
[COLOR=Red]/system/bin/logwrapper /sbin/busybox run-parts /etc/init.d[/COLOR]
is actually done twice - from sysinitsupport.sh first and then again from execute_mods.sh
Also mind that the log-entry in the first is leading in the wrong direction (copy error from above). It should better read "execute init.d directory"
The related logs are found in \data\local\tmp.
You can check yourself with this little script in \etc\init.d:
Code:
#!/system/bin/sh
echo [] > /data/local/tmp/$PPID-exec-done
echo $PPID "init.d executed" >> /data/local/tmp/$PPID-exec-done
date >> /data/local/tmp/$PPID-exec-done
Mind the $PPID which is the parent PID of the executing command (the busybox "run-parts"). Per boot you should just get 1 file <PPID>-exec-done containing the timestamp if you get 2 then you know why...
I have attached the script wrapped in a zip file. Unpack it, copy to \etc\init.d (or if not sym-linked to \system\etc\init.d) and change attributes to "777". Reboot and look what you get in \data\local\tmp.
Once you know, remove the script again and delete the created files in \data\local\tmp.
Mind that the scripts referenced from init.rc are copied over again from the kernel part so any change of the scripts in the \system\sbin folder is useless. The kernel has to fix that, no way out here.
I've been looking into this issue as well with the help of dk_zero_cool (mounts2sd amongst other things) as no matter what I tried I could not get m2sd to run in anything other than Safe Mode because init.d was being run as a service and not being executed in full before the init continued. So far I have edited init.rc to remove the second instance you quote above, and edited the first instance to:
Code:
exec /sbin/sysinitsupport.sh
so it executes rather than running a service. I then edited sysinitsupport.sh to contain just this:
Code:
#!/system/bin/sh
export PATH=/sbin:/system/sbin:/system/bin:/system/xbin
/system/bin/logwrapper busybox run-parts /system/etc/init.d
and also removed the line in execute_mods.sh that relates to init.d, so now theoretically the only thing that should happen in relation to init.d is that the exec command runs sysinitsupport.sh which in turn runs the init.d scripts before anything else in init.rc happens. IN THEORY!!! Because even with all of that done (and I have searched through the whole ramdisk, plus looked at the git for the init binary used in the Lupus ICS kernel I am using to make sure I haven't missed anything) the m2sd init.d script is still running in Safe Mode because it is detecting /system/bin/servicemanager running at the point it tries to execute. So something somewhere is still starting before the execution of init.d. I even tried with the init binary from the latest CM9 build for the Ray to rule out something wrong in there too.
I have sent all my files to dk_zero_cool to see if he can shed any further light on what else may be wrong. I have checked four different Ray kernels and they all use the same DoomLord methods so I doubt whether there are any Ray kernels that are running init.d correctly. It would be great to find a fix for this. Hope more people chip in!
Thanks for opening the discussion
As I understood, you have made some changes in the kernel assembly (not the code) to circumvent the effects you have outlined. I admit that I have not fully understood YOUR concern - but for my double execution of the "run-parts" the deactivation of the relevant line in either of the 2 scripts should do it, or not?
Is your concern related to the situation that init.d cannot do "everything" at the time it is executing and so it cannot achieve what some scripts intend to?
I am far too little educated in the details of kernel execution privileges so cannot further comment on that
Yeah, pretty much - to avoid possible issues with the m2sd script moving stuff around while something else is trying to make use of it the first thing it does is check if servicemanager is running, and if it is it disables the ability to move things like /data and dalvik-cache to sd-ext. The changes that we made in the scripts SHOULD have changed the init.d implementation from it running as a service whilst the rest of the init process carried on, to being executed as a command allowing any init.d scripts to be executed prior to any other service being started - as I understand it this is how init.d was intended to be used (ie the user scripts in /etc/init.d are run fully before anything else). However as I said, even with these changes and everything else relating to init.d having been removed something is still starting servicemanager, and until the source of that can be isolated scripts like m2sd cannot run fully/safely.
I guess the strategy to check on servicemanager is not right here. This is a process that starts several services and should not depend on anything in the init.d. So if you say that the boot sequence would have init.d completed BEFORE any service is started via servicemanager - THEN this could be a flaw in the kernel.
However is that really true? Is there no option to check if certain "dangerous" (for your move purposes) services are active already instead of checking on the servicemanager? I had found a nice overview on the Linux boot process here and I think that somewhere as part of the various init.x excuted scripts the servicemanager simply MUST be started - init.d is just a part of init - and for sure not the first part of it.
Off Topic:
I wonder where I can get some more insight in the Xperia Kernels and how they are assembled - especially which trace of that is noticeable in the filesystem. I noticed that the ICS Kernel have roughly 340MB for the user space while the JB Kernel has 360MB. Device should have 512 MB RAM, then some MB go away for radio and possibly video buffer, but his should be the same for all (accross ICS/JB). So what kind of memory tweaking makes this 20MB difference? I have not found a good place to discuss this - where could I go to?
tobbbie said:
It seems that all Xperia Kernels that stem back to the DoomLord kernel start the init.d execution twice. While you may think "better twice than never" the nearly parallel execution of scripts can create problems if they concurrently manipulate CPU related tables - or fail to do so due to security mechanisms built in. I was hunting the problem that cpu-clock manipulation from init.d did not work for the scripts generated by System Tuner - finally resulting in this finding.
Click to expand...
Click to collapse
How about Radeon kernel? Is there an issue like you said?
Sent from my ST18i using Tapatalk 2
frogerra said:
How about Radeon kernel? Is there an issue like you said?
Sent from my ST18i using Tapatalk 2
Click to expand...
Click to collapse
Just try out (see the guide on 01test.zip) - nothing you can harm doing that.
kernel behaviour trick
I noticed some kernels (GB and ICS) do overwrite settings from /etc/init.d ....
So if you make an init.d script with specific cpu values, or VM settings...some kernel overwrite these with their compiled/preferred values "after" init.d scripts are executed. This way it looks as if your script is not completely accepted by the rom...but the truth is that the kernel applies its own preferred values afterwards.
Thats why my init.d script contains a wait of 60 seconds in the beginning of the scripts......how ? add:
sleep 60
So your script looks like this (example):
#!/system/bin/sh
# this init.d script is for when you apply doomlord kernel supplied with repack 2013
sleep 60
That will run your init.d goodies after one minute.
As you see I'm working on a revived repack4pda 2013 (GB) , which will be released soon in repack4pda thread.
Br.
Michel
I guess that these kernels may be doing the same what you are proposing - just sleep the shell process before action starts. So you need to lookup the call tree from the init process along the various init.*.rc scripts if this is the case. For duplicate execution of init.d content any timed scripts willl not help - the duplicate execution will just happen later as the same script will pause the same amount of time.
Not sure if the init process script execution is synchronous or not - so if you create scripts which sleep, the final signal for "boot completed" may just also delay and the whole boot process may take longer by that sleep time. As well would you just stack the delays after each other and so nothing is gained finally. Synchronous execution would make it impossible that a part of the init process could postpone beyond boot completed.
It may differ if you run the scripts via the "exec" command or let it execute via the servicemanager. I guess the latter may run them asynchronously - not sure here as well.
Alright so I have achieved Dual Boot :victory:
THIS IS NOT KEXEC .
It's a simple hack or probably an elegant one.
We can probably achieve multiboot but that is not important.
There are some other things which will be ironed out but thats for later.
Thread Rules :
No Thank you or How Do I do it or nooby questions.
This thread is exclusively for Developers, Enthusiasts and/or Professionals.
Knowledge of Linux and Terminal is MANDATORY.
Dual Partitioned SD card. Second partition preferably
Linux Installed on your computer.
Rubbish posts will be removed .
Save some pride by not being a n00b.
Currently I have planned two types in my mind.
Type 1: Dual Booting ROMs with Same Boot Images - Completed
This hack works across ROMs which use same kernel with same ramdisk... ICS ROMs series , LXP ROMs who use the LXP kernels.. If there is even slight difference in the ramdisk (esp. the init.rc) ,you wont be able to boot ROMs.
Type 2: Dual Booting ROMs with Same kernels but different Ramdisks- Therotically completed.
Post 1: Intro
Post 2: Prepare SD Card and Images
Post 3: Prepare Ramdisk and ROM Installations
Post 4: Installation and switching ROMs
Post 5:Ramdisk Mod
Post 6 : Multiple Mounts/ MultiBoot
Post 7: FAQ
Problems :
Partitioning SD card is annoying and not fruitful
Second SD card partition might be used as second SD card on First ROM.
Solution"
Use loop Images.
I WOULD RECOMMEND USING ANY LINUX DISTRO FOR MAKING A LOOP IMAGE. Because LINUX !!!
Preparation:
Dump Images and formatting.
Make dump images
Code:
dd if=/dev/zero of=system.kdpr bs=4096 count=100000
Will you give you 400 MB image
Code:
dd if=/dev/zero of=data.kdpr bs=4096 count=200000
Will you give you 800 MB image.
Mount Images (as root)
Code:
losetup /dev/loop0 system.kdpr
Code:
losetup /dev/loop1 data.kdpr
Format images(as root)
Code:
sudo mkfs.ext4 -T ext4 -b 4096 -m 0 -J size=4 -O ^huge_file,^has_journal,^resize_inode,^ext_attr /dev/loop0
sudo mkfs.ext4 -T ext4 -b 4096 -m 0 -J size=4 -O ^huge_file,^has_journal,^resize_inode,^ext_attr /dev/loop1
tune2fs -c 100 -i 100d -m 0 /dev/loop0
tune2fs -c 100 -i 100d -m 0 /dev/loop1
You have two ext4 formatted images system.kdpr and data.kdpr ready.
Copy those images to sd-ext folder.You can mount /dev/mmcblk0p2 on a folder and directly push these images via adb push
OR copy images to SD card and copy to second partition.
Either way the system.kdpr and data.kdpr should be in root of the second SD card partition.
Assuming you have mounted second sd card partition on /data/sd-ext.
Run this command
Code:
touch flag_kdpr
The Images are now ready and loaded :victory:
Now is the time to hack the boot image.
Unpack Boot image and navigate to ramdisk folder
Navigate to the lines in init.rc where partitions are mounted .
Comment off or remove the lines mounting system and data
For stock ICS it is in init.semc.rc
Code:
#mount yaffs2 [email protected] /system
#mount yaffs2 [email protected] /system rw remount
#mount yaffs2 [email protected] /data nosuid node
v
add a line
Code:
exec /sbin/mount_fs.sh
now create a bash script named mount_fs.sh as follows
Bash:
#!/sbin/sh
mount /dev/block/mmcblk0p2 /res/sdext
flag_boot=`cat /res/sdext/flag_kdpr`
if [ ${flag_boot} -eq 1 ]
then
mount /res/sdext/system.kdpr /system
mount -o remount,rw /res/sdext/system.kdpr /system
mount /res/sdext/data.kdpr /data
else
mount /dev/block/mtdblock0 /system
mount -o rw,remount /system
mount /dev/block/mtdblock1 /data
fi
make a folder named /res/sdext or choose mount point of your choice
We will be controlling the mount point and boot via the file flag_kdpr.
Using this flag we can also achieve MultiBoot
Repack the boot image.
Installing Secondary ROM
Open the zip and extract the updater script .
Remove the lines for mounting/formatting system and data.
Repack the zip
Mount sd-ext
Run these commands in terminal
Code:
mount /sd-ext/system.kdpr /system
mount /sd-ext/data.kdpr /data
Install the zip ROM.
ROM will be installed in the dump images.
Booting to secondary ROM:
In the recovery or first ROM run this command
Code:
echo 1 > /sd-ext/flag_kdpr
OR
Code:
echo 1 > /res/sdext/flag_kdpr
and reboot
Booting to primary ROM:
In the recovery or first ROM run this command
Code:
echo 0 > /sd-ext/flag_kdpr
OR
Code:
echo 0 > /res/sdext/flag_kdpr
and reboot
Stage 2 : Ramdisk Mod .
This is actually theoretical, but it should work anyway. @nobodyAtall 's recovery for locked bootloader works in a similar fashion.
This is for LXP+ kernels or kernels who use init.sh to load the ramdisk archives.
Steps .
Preparation :
SD Card
Add a folder named ramdisk in root of second SD card
Code:
mkdir ramdisk
Add ramdisks in this folder
Add a flag for ramdisk
Code:
touch flag_ramdisk
Make a script mount ramdisk.sh
Bash:
#!/sbin/busybox sh
flag_ramdisk=`cat /sdext/flag_ramdisk`
if [ ${flag_ramdisk} -eq 1 ]
then
busybox cpio -i < /sdext/ramdisk/abc_ramdisk.cpio
elif [ ${flag_ramdisk} -eq 2 ]
then
busybox cpio -i < /sdext/ramdisk/pqr_ramdisk.cpio
else
busybox cpio -i < /sbin/ramdisky.cpio
fi
Ramdisk of Primary kernel
Edit init.sh
create directory
Code:
mkdir -m 755 -p /sdext
Mount second SD card partition before loading the ramdisk
Code:
mount /dev/block/mmcblk0p2 /sdext
Comment or delete the line loading kernel.
Replace/add with
Code:
busybox sh /sdext/ramdisk.sh
Unmount Second sd card
Ramdisk will "theoretically" load.
Handling Multiple Ramdisks and Multiple Mounts.
Multiple Ramdisk mod is useful when.
You have to test a new ramdisk
You have to run alternative ROM on a same kernel(e.g MIUI)
Load custom recovery for alternative mount points (CM12 ,Secondary ROM)
Dual/Multi ROM is useful for
Alpha/Beta testing
For the lulz
Both of these mods are independent of each other.
You can use Primary Ramdisk with Ramdisk mod and Secondary Ramdisks with mount mods
Multi Boot is similarly implemented. Except you need lot of space in second partition ,each around 1-1.5 GB per system-data combo.
Some "friendlier" ways to dual Boot.
Method 1
Noob Friendly Instructions for Dual Boot.
I have done most of the heavy lifting
You need to flash the kernels above first.
Currently only Radium is supported for primary ROM.
But you can install ANY ICS ROM as secondary.
Requirements :
Basic Notepad Skills.
Dual Partition SD card Exceeding 1.2GB atleast.
Battery % atleast above 70%
Patience
Download
https://www.mediafire.com/folder/aiv828ivuumrk/Dual_Boot_Zips
Download all zips in this folder.
Definition
Dual_Boot_Install_400.zip : 400MB system + 400 MB data
Dual_Boot_Install_600.zip : 400 MB system + 600 MB data
Dual_Boot_Install_800.zip : 400 MB system +800 MB data
Mount.zip : To Mount The secondary system/data before installing ROMs
prim.zip : Boot to Primary ROM
sec.zip :Boot to Secondary ROM
Setup Dual Boot:
Go to recovery
Go to mounts & storage
Format sd-ext
Flash any ONE of the Dual_Boot_Install_Zips
Patience part comes here. Depending on how your SD card is ,it takes 5-10 minutes to copy.
ROM Preparation
Extract the updater script of your ROM zip in your desktop.
Open it in notepad++
Delete the lines mounting and formatting system and userdata like these
unmount("/system");
format("MTD", "system");
mount("MTD", "system", "/system");
Click to expand...
Click to collapse
Copy back the updater script in the ROM folder
Copy ROM to SD card
ROM installation:
Run Mount.zip
Run The ROM installer
Finished
Before Installing Zips below ,Make sure sd-ext is NOT mounted in mounts and storage.
Booting to primary ROM
Run the primary.zip in recovery OR
OR
mount sd-ext and run
Code:
echo 0 > /sd-ext/flag_kdpr
in adb shell
Booting to secondary ROM
Run the secondary.zip in recovery.
OR
mount sd-ext and run
Code:
echo 1 > /sd-ext/flag_kdpr
in adb shell
Those huge blank images can be fit in such a small zip file. There is no data so it can be compressed to the Max.
Method 2
Even more easier Dual ROM installation. This type of stuff can only be achieved on the Zero Layout
Noob Friendly Instructions for Dual Boot.
Requirements :
Dual Partition SD card Exceeding 1.2GB atleast.
Battery % atleast above 70%
Patience
Download
https://www.mediafire.com/folder/aiv828ivuumrk/Dual_Boot_Zips
Download all zips in this folder.
Definition
Dual_Boot_Install_400.zip : 400MB system + 400 MB data
Dual_Boot_Install_600.zip : 400 MB system + 600 MB data
Dual_Boot_Install_800.zip : 400 MB system +800 MB data
Mount.zip : To Mount The secondary system/data before installing ROMs
prim.zip : Boot to Primary ROM
sec.zip :Boot to Secondary ROM
clone2.zip :cloning Primary ROM to Secondary ROM
Setup Dual Boot:
Go to recovery
Go to mounts & storage
Format sd-ext
Flash any ONE of the Dual_Boot_Install_Zips
Patience part comes here. Depending on how your SD card is ,it takes 5-10 minutes to copy.
ROM INSTALLATION :
Install Secondary ROM as you install any ROM
Finish installation
Don't reboot.
Mount sd-ext in mounts and storage
Flash clone2.zip
[optional]Watch Anime
After installation finished
Install Primary ROM.
Finish Installation
Clone Zip basically clones your running ROM as secondary ROM. This stuff beats nandroid backup !!
Booting to primary ROM
Run the primary.zip in recovery OR
OR
mount sd-ext and run
Code:
echo 0 > /sd-ext/flag_kdpr
in adb shell
Booting to secondary ROM
Run the secondary.zip in recovery.
OR
mount sd-ext and run
Code:
echo 1 > /sd-ext/flag_kdpr
in adb shell
Those huge blank images can be fit in such a small zip file. There is no data so it can be compressed to the Max.
Lagfix after a while.
After 5-7 boots , Secondary ROM starts lagging.
fsck is needed to be performed from the reccovery to fix lag.
Commands :
Code:
e2fsck /res/sdext/data.kdpr
e2fsck /res/sdext/system.kdpr
Or just add it to mount scripts before mounting.
@karandpr,is there any possibility to dualboot some roms with different kernel layout or version (like multiboot on newer phone)?
ryanrinaldhi said:
@karandpr,is there any possibility to dualboot some roms with different kernel layout or version (like multiboot on newer phone)?
Click to expand...
Click to collapse
Nope. On fly layout change is impossible.
Even when you change layout ,you need a fastboot erase ,or the consequences can be weird.
Version change is possible.
anonymous had a kernel which can boot ICS , CM9 ,CM 10 & MIUI JB.
Multiboot off his hybrid kernel is very possible.
I am exploring the possibility of Kitkat and lollipop since both are versions 3.4 . Not sure if it can happen but worth a risk.
Hi,
I'm trying to run a custom init.d script on my HTC One (m7) which is running on Cyanogemod 12.1 (The problem existed already in 12.0). The problem is that none of the scripts are executed at boot time.
Looking at the "init.cm.rc" script i found the following snippets that look like the "sysinit" command should be triggered at boot time.
Code:
[...]
on post-fs-data
[...]
# Run sysinit
start sysinit
[...]
# sysinit (/system/etc/init.d)
service sysinit /system/bin/sysinit
user root
oneshot
disabled
I even tried removing the "disabled" parameter but the "sysinit" command is still not executed at boot time.
If I run the "sysinit" command on a root shell the scripts are executed as the should.
Anybody an idea what I'm missing?
Thanks in advance!
Hi.
I am also running CM12.1 on a w7dsn device, and init.d wasn't working. I was able to get it running by using the init.sh script as described here:
http://techtrickz.com/how-to/fix-xposed-framework-installation-issue-on-nexus-6/
I've just downloaded the script and run it from my sdcard, no other steps are necessary.
lfom said:
Hi.
I am also running CM12.1 on a w7dsn device, and init.d wasn't working. I was able to get it running by using the init.sh script as described here:
http://techtrickz.com/how-to/fix-xposed-framework-installation-issue-on-nexus-6/
I've just downloaded the script and run it from my sdcard, no other steps are necessary.
Click to expand...
Click to collapse
I am trying to get init.d working on d2vzw, and no luck. The script you linked to works by replacing /system/etc/install-recovery.sh, but my build has no such file. What a drag with CM...
galets said:
I am trying to get init.d working on d2vzw, and no luck. The script you linked to works by replacing /system/etc/install-recovery.sh, but my build has no such file. What a drag with CM...
Click to expand...
Click to collapse
Mine didn't have either, but after installing the script (and creating install-recovery.sh) then my scripts in init.d started to be run after every boot.
You must turn off selinux in order for init.d to work
Sent from my LG-LS980 using XDA Free mobile app
I'm using CyanogenMod 12.1 ROM on my phone, to enable the init.d you have to remove the /system/bin/sysinit then recreate the similar filename with the same content and permissions (755, root, shell).
Code:
#!/system/bin/sh
export PATH=/sbin:/system/sbin:/system/bin:/system/xbin
run-parts /system/etc/init.d
Was it the init.rc from the boot.img initrd, or the one from the rootfs /boot.img?
Just change the permissions of all files in /etc/init.d folder to 755.
Also if you use the /data/local/userinit.sh change that to 755.
Leave the /system/bin/sysinit file as it is.
Code:
#!/system/bin/sh
export PATH=/sbin:/system/sbin:/system/bin:/system/xbin
for i in /system/etc/init.d/*; do
if [ -x $i ]; then
/system/bin/log -t sysinit Running $i
$i
fi
done
Cheers
Hi,
I've followed this how-to: http://forum.xda-developers.com/showthread.php?t=1933849 to enable init.d support on my phone (GT-S5570i, Android 2.3.6, stock rom)
I have installed BusyBox (standard install, not smart install), then, after installing and launch Uni-init, i get "SUCCESS ! You have init.d support !"
Well, so I went into init.d folder and I manually launch the script "00test" to see if I am able to run scripts on my phone: ok: inside /data folder i see the test.log file! Then I delete this test file to see if my phone is really able to execute this script from the init.d folder at the boot.
Well, after reboot I go in /data but I don't see any test.log file.
Why? Uni-init told me that I have init.d support, but this don't seems true. The permissions on init.d folder and scripts are ok (rwxr-xr-x). I've also tried to change the ownership to 0 (root) and to 1000 (system) to the test script, and I've also tried another init.d activator, this one: http://download.apks.org/?apkid=com.broodplank.initdtoggler&ver=1.3&server=apk-s#.VbluDvldLcc bot no luck again.
Then I've found this solution: http://forum.xda-developers.com/showthread.php?t=2725680 which, differently from the other solutions, has inserted the runinit script inside /bin. Well: so I rebooted again, but the init scripts aren't still able to run at boot.
If i start the runinit script from a shell window, ok: scripts from init.d folder are properly executed, but again, when I boot my phone, these scripts aren't executed. Maybe I should tell to some system files to execute runinit at the boot time? I miss something?
Many thanks.
In another discussion I've read the following statement:
- the boot process calls install-recovery.sh while executing init.rc
- the install-recovery.sh calls sysinit script
- the sysinit script runs /system/etc/init.d/* in order
Click to expand...
Click to collapse
But I've found that my init.rc exclude the install-recovery.sh script:
Code:
#service flash_recovery /system/etc/install-recovery.sh
# oneshot
So, I don't have any chance to implement the init.d solution?
Hi guys. Does any of you know how to push su.d directory into su folder? I mean I need radio.sh script in su/su.d to get root call sms manager working. Every time I try it disappears after reboot.
Rooted rom 34.3.A.0.217 with TWRP.
Anyone?
It's late though, but for the guidance of other noobs like me. /su/su.d/ can't be flashed in recovery because this isn't available. For system-less roots, binaries/libraries required to start supersu daemon and to manage root permissions, don't reside in /system/bin but in /data/su.img while (at least) two files reside in boot.img i.e. boot.img/ramdisk/init.supersu.rc and boot.img/ramdisk/sbin/.*daemonsu*.sh. When ROM boots, init.supersu.rc mounts /data/su.img on /su directory and calls /sbin/*daemonsu*.sh for initial setup which starts /su/bin/daemonsu and other se-linux related stuff and then executes any scripts found in /su/su.d/ and /system/su.d.
You can find this:
Code:
mido:/ # mount | grep loop
/dev/block/loop0 on /su type ext4 (rw,seclabel,noatime,data=ordered)
So, the init.d scripts placed in /su/su.d actually reside in /data/su.img which isn't mounted in recovery mode and anything flashed to /su/su.d goes to volatile rootfs which is gone on reboot. Either mount su.img in recovery, or place this script while ROM is running or instead flash to /system/su.d which is permanent filesystem unlike rootfs (which lives in RAM). And finally don't forget to set permissions to 0700 as advised here. Another thing, mostly init.d scripts don't work with .sh extension. Avoid this too.