# Trouble obtaining busybox switch_root to function

I'm working with an ingrained ARM Linux system that boots making use of initramfs. (Here is some history from a pair earlier questions, if you are interested.) Until now, many thanks partly to aid obtained below, I can boot the bit using TFTP with an ingrained initramfs. The MMC vehicle driver identifies an SD card having a new origin filesystem, which I can after that place. Nonetheless, I can not get the last action, making use of busybox switch_root to switch over to the filesystem on the SD card, to function.

At the initramfs shell punctual, I assume this need to make the bit button to the new filesystem:

switch_root -c /dev/console /mnt/root /sbin/init.sysvinit


However, it simply makes busybox (to which switch_root is aliased) publish its male web page, similar to this:

/ # switch_root -c /dev/console /mnt/root /sbin/init.sysvinit
BusyBox v1.17.4 (2010-12-08 17:01:07 EST) multi-call binary.

Usage: switch_root [-c /dev/console] NEW_ROOT NEW_INIT [ARGS]

Free initramfs and switch to another root fs:
chroot to NEW_ROOT, delete all in /, move NEW_ROOT to /,
execute NEW_INIT. PID must be 1. NEW_ROOT must be a mountpoint.

Options:

-c DEV  Reopen stdio to DEV after switch


I assume the - c alternative is proper, given that it coincides as what is had in the instance, and also/ dev/console exists.

/ # ls -l /dev
total 0
crw-r--r--    1 0        0           5,   1 Jan  1 00:28 console
brw-r--r--    1 0        0           7,   0 Dec 21  2010 loop0
brw-r--r--    1 0        0         179,   0 Dec 21  2010 mmcblk0
brw-r--r--    1 0        0         179,   1 Dec 21  2010 mmcblk0p1
brw-r--r--    1 0        0         179,   2 Dec 21  2010 mmcblk0p2
brw-r--r--    1 0        0         179,   3 Dec 21  2010 mmcblk0p3
brw-r--r--    1 0        0         179,   4 Dec 21  2010 mmcblk0p4


/ mnt/root additionally exists.

/ # ls /mnt/root
bin         etc         linuxrc     mnt         sys         var
boot        home        lost+found  proc        tmp
dev         lib         media       sbin        usr


The init executable exists:

/ # ls -lh /mnt/root/sbin/
<snip>
lrwxrwxrwx    1 0        0             19 Dec 21  2010 init -> /sbin/init.sysvinit
-rwxr-xr-x    1 0        0          22.8K Dec 21  2010 init.sysvinit


But below is something weird:

/mnt/root/sbin # pwd
/mnt/root/sbin
/mnt/root/sbin # ls -l | grep init.sysvinit
lrwxrwxrwx    1 0        0               19 Dec 21  2010 init -> /sbin/init.sysvinit
-rwxr-xr-x    1 0        0            23364 Dec 21  2010 init.sysvinit
/mnt/root/sbin # ./init.sysvinit
/mnt/root/sbin # /mnt/root/sbin/init.sysvinit


That is entirely mystifying. I'm not exactly sure where I'm failing. I've considered the resource, which goes to http://git.busybox.net/busybox/tree/util-linux/switch_root.c?id=1_17_4

It is not simply the init.sysvinit executable. I can not execute anything from the SD card. As an example:

/mnt/root/bin # ./busybox
/mnt/root/bin # /mnt/root/busybox
/mnt/root/bin # ls -l | grep "2010 busybox"
-rwxr-xr-x    1 0        0           462028 Dec 21  2010 busybox


Anyone have an idea what is awry below? I assumed it could be some trouble with placing the card noexec, yet I think director is the default, and also I attempted passing the director alternative clearly at place without success.

0
2019-05-13 05:46:44
Source Share

The factor that switch_root is not working with the command line is this code in busybox:

    if (st.st_dev == rootdev || getpid() != 1) {
// Show usage, it says new root must be a mountpoint
// and we must be PID 1
bb_show_usage();
}


You are not PID 1, so you are dropping however right into this bb_show_usage. The effects is that the switch_root command in your initramfs init manuscript needs to run switch_root with exec. i.e.

exec switch_root ...


The various other concern with your "not located" mistakes is most likely due to the fact that the common collections required by the executables are not located, due to the fact that the initramfs root filesystem does not have them. If you can get switch_root to collaborate with exec, after that is most likely the "not located" mistake will certainly vanish.

0
2019-05-17 19:56:19
Source