Mods Does absence of Init.d cause Boot-Loop for Link2SD? [Root only]

[HolmesSherlock]

• What is Link2SD?
  
  Link2SD is an app for Android 2.0+ users on their phone to move applications to the SD card by dual-partitioning the card. First partition gets mounted as external SD and remains available for general use, while the second partition (preferably formatted with an *NIX type file-system, e.g. ext2, ext3, ext4 etc.) holds executable(.apk), data, dalvik-cache(.dex) and library files(.so) for linked/moved application.
  
  Link2SD mounts the second partition of your SD card as /data/sdext2 and makes OS mounts it at boot time. When you select an application and press "Create Link" button you can select which files of the application will be linked and moved to SD card. Apk, dex and lib files can be moved and you can select all three or any two of three or even only one of them. Depending on what you select, Link2SD moves apk file, dalvik-cache (.dex) file and lib files (.so) to SD card's second partition and creates symbolic links in original directories. Phone must be Rooted, of course.

• How does mounting of second SD partition work?
  
  After the partitioned SD card is put in the phone, Link2SD asks you to select the file-system of the second partition on SD, just chose the one you used. Once /system/etc/init.d/11link2sd script is created, you have to restart the phone.

• What is init.d support and why is it needed?
  
  init.d directory is the container of start-up scripts in a *NIX type system. These scripts are execute during system boot.
  
  Link2SD relies on the execution of /system/etc/init.d/11link2sd script which, in turn, mounts the second partition of SD card as /data/sdext2.

• What is the Boot-Loop problem?
  
  The SD card storage is dual-partitioned and put in the phone. Then, Link2SD generates mount script for the second partition of SD card and phone needs to be re-started. Some phones, e.g. Sony Xperia-L runs into infinite boot-sequence a.k.a. boot-loop. In this state, phone boot sequence starts, manufacturer logo is displayed proceeds for a few seconds and restarts. Only solution is to long press the power button or taking out the battery to switch the phone off.
  
  Interestingly, if the dual-partitioned SD card is taken out and the phone is booted without SD card inserted, it boots normally.

• What did I do with my Xperia-L so that it started boot-looping?
  
  1. Rooted Xperia using Rootkit method. It leaved /system/etc/install_recovery.sh and /system/etc/init.d/00stop_ric scripts on the phone's file-system. (Script code listed below). I am using the rooted phone for months without any trouble.
  2. Using an un-partitioned 32GB microSD card, formatted with FAT32, in the phone.
  3. Deciding to give a try to Link2SD, I dual-partitioned the SD using Minitool Partition Manager. First partition was formatted with FAT32 while the second one was formatted with ext4. Sizes of partitions were around ~25GB and ~4.5GB respectively.
  4. Installed Link2SD on phone.
  5. Switched the phone OFF.
  6. Put the dual-partitioned SD back in the phone slot.
  7. Switched the phone ON.
  8. Opened Link2SD app.
  9. Link2SD immediately recognized the second partiton, asking me for its file-system type.
  10. Selected ext4 from the list.
  11. Link2SD generated the mount script and prompted for restart.
  12. Restarted the phone.
  13. Boot-Loop!!!
  14. Switched the phone OFF by taking out battery.
  15. Took the dual-partitioned memory card out.
  16. Switched the phone ON.
  17. Phone starts normally!!!

• How did I solve the problem?
  
  1. I installed Init.d Toggler app as described here.
  2. As described here, I experienced the problem of first partition not being mounted. The error was related to SD Card being empty or the file-system damaged.
  3. I re-formatted the first partition of SD with NTFS.
  4. Installed Paragon exFAT, NTFS & HFS+ app.
  5. Now, the first partition got mounted.

• What does Init.d Toggler do?
  
  1. Appends the following command at the end of /system/etc/install_recovery.sh: /system/bin/sysinit
  2. Creates /system/bin/sysinit script.
  3. Creates /system/etc/init.d directory to put the start-up scripts in.

• Does REALLY lack of init.d support cause boot-loop problem?
  
  As the Init.d Toggler solution says,
  
  

  One of the requeriments to use the Link2SD is the support to init.d scripts. Most of the custom roms support this, but not the stock one, giving a boot loop.

I doubt that to be the "real" problem underlying the hood. Why?

1. How come lack of init.d support cause the mount script /system/etc/init.d/11link2sd malfunction? At most, what could have happened is, it would NOT mount the second partition, that's it. Right? But, isn't it surprising to crash or the like during boot?
2. As stated, even prior to installing Link2SD, there always existed /system/etc/init.d/00stop_ric, which contains almost similar set of commands as that of mount script /system/etc/init.d/11link2sd created by Link2SD. It used to work like a charm. I guess, because of init.d support not being there in stock ROM, the script had never been executed before I used Init.d Toggler.
3. Had the lack of init.d support been the reason of boot-loop, how did the phone manage itself to boot normally with the dual partitioned SD card taken out? Please note that, the mount script was still residing in init.d directory.
4. To be noted that, Xperia L (Stock ROM) boots fine with a dual-partitioned SD card put in, though it never mounts the second partition.

At this point, can anyone help me investigate the root-cause behind the boot-loop problem? Can anyone come up with any idea or satisfactory answer to the query? Does anyone have any idea on how to approach the issue at hand?

• Please find the relevant scripts below.

00stop_ric

#!/system/bin/sh
/system/xbin/busybox pkill /sbin/ric
mount -o remount,rw /
rm /sbin/ric
mount -o remount,ro /
/system/xbin/busybox pkill /sbin/ric

11link2sd

#!/system/bin/sh
#added by link2sd
LOG=/data/link2sd-11link2sd.log
echo "$(date) mounting..." > $LOG
sleep 2
mount -t ext4 -o rw /dev/block/vold/179:34 /data/sdext2 1>>$LOG 2>>$LOG

mount -t ext4 -o rw /dev/block/mmcblk1p2 /data/sdext2 1>>$LOG 2>>$LOG

mount >> $LOG
echo "$(date) mount finished" >> $LOG

install-recovery

#!/system/bin/sh

# If you're implementing this in a custom kernel/firmware,
# I suggest you use a different script name, and add a service
# to launch it from init.rc

# Launches SuperSU in daemon mode only on Android 4.3+.
# Nothing will happen on 4.2.x or older, unless SELinux+Enforcing.
# If you want to force loading the daemon, use "--daemon" instead

/system/xbin/daemonsu --auto-daemon &

# Some apps like to run stuff from this script as well, that will 
# obviously break root - in your code, just search this file
# for "install-recovery-2.sh", and if present, write there instead.

/system/bin/sysinit

sysinit

#!/system/bin/sh

export PATH=/sbin:/system/sbin:/system/bin:/system/xbin
/system/bin/logwrapper /system/xbin/run-parts /system/etc/init.d

link2sd-11link2sd

Wed Jul 23 16:23:57 IST 2014 mounting...
mount: Device or resource busy
mount: Device or resource busy
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
tmpfs /mnt/secure tmpfs rw,relatime,mode=700 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,relatime,data=ordered 0 0
/dev/block/platform/msm_sdcc.1/by-name/userdata /data ext4 rw,nosuid,nodev,relatime,noauto_da_alloc,data=ordered 0 0
/dev/block/platform/msm_sdcc.1/by-name/cache /cache ext4 rw,nosuid,nodev,relatime,data=ordered 0 0
/dev/block/platform/msm_sdcc.1/by-name/persist /persist ext4 rw,nosuid,nodev,relatime,data=ordered 0 0
/dev/block/platform/msm_sdcc.1/by-name/ftmd /ftmd ext4 rw,nosuid,nodev,relatime,data=ordered 0 0
/dev/block/platform/msm_sdcc.1/by-name/LTALabel /lta-label ext4 rw,nosuid,nodev,relatime,data=ordered 0 0
/dev/block/platform/msm_sdcc.1/by-name/ftma /ftma ext4 ro,relatime,nobarrier,data=ordered 0 0
/dev/block/platform/msm_sdcc.1/by-name/modem /firmware vfat ro,relatime,uid=1000,gid=1000,fmask=0337,dmask=0227,codepage=cp437,iocharset=iso8859-1,shortname=lower,errors=remount-ro 0 0
/dev/block/mmcblk1p1 /storage/sdcard1 fuseblk rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096 0 0
/dev/block/vold/179:34 /data/sdext2 ext4 rw,relatime,data=ordered 0 0
/dev/block/vold/259:0 /storage/sdcard0 vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
/dev/block/vold/259:0 /mnt/secure/asec vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
tmpfs /storage/sdcard0/.android_secure tmpfs ro,relatime,size=0k,mode=000 0 0
/dev/block/dm-0 /mnt/asec/uk.co.aifactory.chessfree-2 ext4 ro,dirsync,nosuid,nodev,noatime 0 0
/dev/block/dm-1 /mnt/asec/com.wave18.adbwireless-1 ext4 ro,dirsync,nosuid,nodev,noatime 0 0
/dev/block/dm-2 /mnt/asec/com.rerware.android.MyBackupRoot-1 ext4 ro,dirsync,nosuid,nodev,noatime 0 0
/dev/block/dm-3 /mnt/asec/com.rootuninstaller.free-2 ext4 ro,dirsync,nosuid,nodev,noatime 0 0
Wed Jul 23 16:23:59 IST 2014 mount finished

 

[scary alien]

Welcome to our AndroidForums, HolmesSherlock .

Interesting thread....

I don't follow all the ins and outs of what is going on, but I do have some comments and suggests from a purely Unix and/or debugging viewpoint.

You're on the right track by capturing log and status messages in your 11link2sd script, but I think you might also need to do something similar in the 00stop_ric script.

I found at least two interesting threads about stopping the ric daemon and the issues related to that:

See the last part of this thread on stackoverflow: Read only file system on Android - Stack Overflow

I found this article from google, and thought I'd add the steps necessary on a Sony Xperia Z (4.2.2).

The Sony has a watchdog process which detects when you've changed ro to rw on / and /system (these are the only ones I was trying to modify) and possibly others.

The following was what I ran to perform the changes I was trying to achieve. I pasted these into a window, because removing the execute bit from /sbin/ric needs to be done quickly in order to stop it restarting itself. (I tried stop ric; this doesn't work - although it worked on a previous version of android on the phone).

pkill -9 ric; mount -o rw,remount -t rootfs /
chmod 640 /sbin/ric
mount -o rw,remount /system

I modified the hosts file here, so this is the place you make the changes you need to the filesystem. To leave things the way we found them, do this:

mount -o ro,remount /system
chmod 750 /sbin/ric
mount -o ro,remount -t rootfs /

At which point ric should automatically restart. (It restarted for me automatically.)

And there is also this thread on XDA: [LB] The definitive root Remount-Reboot fix! - Pg. 12 | Xperia Z | XDA Forum that might shed some light on the ric thing.

It sounds like the boot loop might be being caused by some hung process (i.e., a mount perhaps?) or otherwise that the booting process can't get past.

Perhaps adding more logging (i.e., echo "HolmesSherlock trace: about to remount /system in rw mode", etc.) in several key places in your script(s) and viewing the log files after the boot loop occurs will help pinpoint where and what the issue actually is.

Cheers and best of luck!

 

[HolmesSherlock]

Welcome to our AndroidForums, HolmesSherlock .
I don't follow all the ins and outs of what is going on, ...

Because of my post count being low, I am not being able to add links. Otherwise, it could have been clearer to you, I guess.

It sounds like the boot loop might be being caused by some hung process (i.e., a mount perhaps?) or otherwise that the booting process can't get past.

But can you explain why the phone boots normally when SD card is taken out? Please follow step# 13-17

 

[scary alien]

Because of my post count being low, I am not being able to add links. Otherwise, it could have been clearer to you, I guess.

LOL, no, you're explaining things just fine :thumbup: . There's just a lot going on and being described (I've never used links2sd, so I'm just having to follow the pieces ).

Go ahead and post/paste your links and I'll fix them for you (though I think you should be able to post links now, I believe).

But can you explain why the phone boots normally when SD card is taken out? Please follow step# 13-17

The only thing I can think of was what I was trying to allude to: i.e., that there's probably one of the commands--perhaps one of the mount commands? :dontknow:--that is never "finishing" and causing the bootloop (or hanging?).

That's why I suggested throwing in some more places where you're logging information about what action (command) is about to be taken--that'll end-up telling you how far in the script or where it might have succeeded or hung.

You could also throw a nohup cat /proc/kmsg >> /data/kernel-msgs.log & somewhere at the start of your earliest script and capture the kernel messages.

I would "seed" the log file with an echo "HolmesSherlock: starting kernel msg capture $(date)" >> /data/kernel-msgs.log so that you'll be able to see and differentiate between booting sessions (be sure to use the ">>" append redirection). Put that statement right before the one above that actually does the kernel message capturing.

Does that make sense?

Hope that helps!

 

[HolmesSherlock]

Go ahead and post/paste your links and I'll fix them for you (though I think you should be able to post links now, I believe).

Original post modified with links at appropriate points.

The only thing I can think of was what I was trying to allude to: i.e., that there's probably one of the commands--perhaps one of the mount commands? :dontknow:--that is never "finishing" and causing the bootloop (or hanging?).

I doubt so, too.

That's why I suggested throwing in some more places where you're logging information about what action (command) is about to be taken--that'll end-up telling you how far in the script or where it might have succeeded or hung.

Injecting those logging statements now will not help us much. Because, with that Init.d Toggler solution, my phone is booting fine.

Should I want to get some insight, I need to reproduce the problem by deleting/commenting the last statement below in /system/etc/init.d/install_recovery.sh

/system/bin/sysinit

Because, sysinit script contains run-parts command which is responsible for the execution of init.d script.

sysinit

#!/system/bin/sh

export PATH=/sbin:/system/sbin:/system/bin:/system/xbin
/system/bin/logwrapper /system/xbin/run-parts /system/etc/init.d

If I roll it back, it'll start boot-looping again. That's OK. Only point I fear about is if it doesn't boot correctly in case of SD card being taken out. Though it should not be a disaster if I have understood the side-effects of Init.d Toggler correctly.

 

[zygd]

The issue is more complicated with link2sd. If there is no init.d (root achieved with something different than getroot / rootkit for Xperia) the link2sd creates booting script on different level than init.d - don't remember where exactly, I had kingroot and there wasn't init.d folder. But if there is init.d folder, link2sd will create 11link2sd script in init.d folder and boot loop is ready.
The mysterious thing with ric deamon is that the phone will recreate it each time phone is booting so You need 00stop_ric in init.d for all time (even if we delete /sbin/ric it will reappear next time).