Re: switch_root and /etc/inittab

[Denys Vlasenko]

I'm terribly late for this...

On Tue, Jun 15, 2021 at 4:55 PM Porter, Jeremy
 wrote:
> Thank you for the example--that was helpful to see how this works.
>
> I have initramfs in Linux enabled and I've been using that for a long time. I 
> should be able to use switch_root.
>
> I followed the prior suggestion to skip the inittab and use a script. I put a 
> script in /etc/init.d/rcS:
>
> #!/bin/busybox sh
>
> /bin/busybox echo "Running boot script..."
> /bin/busybox echo "Mounting filesystems..."
> /bin/busybox mount -t devpts devpts /dev/pts
> /bin/busybox mount -t tmpfs tmpfs /dev/shm
> /bin/busybox mount -t proc proc /proc
> /bin/busybox mount -t sysfs sysfs /sys
> /bin/busybox mount -t tmpfs tmpfs /tmp
> /bin/busybox echo "Installing links for busybox..."
> /bin/busybox --install -s
> /bin/busybox echo /sbin/mdev > /proc/sys/kernel/hotplug
> /bin/busybox mdev -s
> /bin/busybox echo "mounting rootfs..."
> /bin/busybox mount -t xfs /dev/vda /mnt
> /bin/busybox echo "Swtiching root"
> exec /sbin/switch_root -c /dev/console /mnt /sbin/init
>
> This runs and gets to switch_root.
>
> It does not switch_root though. It doesn't run the new roots inittab which is 
> present.

If switch_root can't/won't chroot to the new root, it prints an error message.
See for yourself:

// Change to new root directory and verify it's a different fs
xchdir(newroot);
xstat("/", &st);
rootdev = st.st_dev;
xstat(".", &st);
if (st.st_dev == rootdev) {
// Show usage, it says new root must be a mountpoint
bb_show_usage();
}
if (!dry_run && getpid() != 1) {
// Show usage, it says we must be PID 1
bb_show_usage();
}

// Additional sanity checks: we're about to rm -rf /, so be REALLY SURE
// we mean it. I could make this a CONFIG option, but I would get email
// from all the people who WILL destroy their filesystems.
if (stat("/init", &st) != 0 || !S_ISREG(st.st_mode)) {
bb_error_msg_and_die("'%s' is not a regular file", "/init");
}
statfs("/", &stfs); // this never fails
if ((unsigned)stfs.f_type != RAMFS_MAGIC
 && (unsigned)stfs.f_type != TMPFS_MAGIC
) {
bb_simple_error_msg_and_die("root filesystem is not
ramfs/tmpfs");
}

if (!dry_run) {
// Zap everything out of rootdev
delete_contents("/", rootdev);

// Overmount / with newdir and chroot into it
if (mount(".", "/", NULL, MS_MOVE, NULL)) {
// For example, fails when newroot is not a mountpoint
bb_simple_perror_msg_and_die("error moving root");
}
}
xchroot(".");

All error paths have messages. (x-functions (xstat et al) also always
print error messages if they die internally due to errors).

Thus, you should be reaching xchroot().
Then, you should be reaching execv, since it also has error printouts
everywhere else:
if (dry_run) {
// Does NEW_INIT look like it can be executed?
//xstat(argv[0], &st);
//if (!S_ISREG(st.st_mode))
//  bb_perror_msg_and_die("'%s' is not a regular
file", argv[0]);
if (access(argv[0], X_OK) == 0)
return 0;
} else {
// Exec NEW_INIT
execv(argv[0], argv);
}
bb_perror_msg_and_die("can't execute '%s'", argv[0]);


> I get something like this:
>
> [1.262512] XFS (vda): Ending recovery (logdev: internal)
> Swtiching root
>
> Please press Enter to activate this console.
>
> BusyBox v1.33.1 (2021-06-10 08:53:34 EDT) built-in shell (ash)
>
> / # ls

Looks like you are seeing the new init running default
::askfirst:-/bin/sh
action.

Look around the currently mounted root filesystem and
diagnose why /etc/inittab is not there.


> Is there any good way to debug this switch_root?

You can strace it, I guess...
You can also use

exec /sbin/switch_root -c /dev/console /mnt /bin/sh

which would drop you into a shell, and then see around
what files are in the filesystem, try "exec /sbin/init" etc.



> The new root has /etc/inittab like this:
>
> ::sysinit:-/bin/ash
> ::sysinit:/bin/busybox echo "hello from /etc/inittab"

Do you *see* it in the filesystem when you are in the askfirst shell?
E.g. "cat /etc/inittab" shows the file?
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: switch_root and /etc/inittab

[Stefan Seyfried]

On 17.06.21 15:13, Porter, Jeremy wrote:

I've been trying to debug this with the script below. I'm still running into 
problems with this. When I tried to put something after the switch_root it 
never executes.

Of course not.
exec replaces the current executable.
The line after "exec" will only be executed it exec fails for whatever 
reason.

--
Stefan Seyfried

"For a successful technology, reality must take precedence over
 public relations, for nature cannot be fooled." -- Richard Feynman
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: switch_root and /etc/inittab

[tito]

On Thu, 17 Jun 2021 13:13:23 +
"Porter, Jeremy"  wrote:

> I've been trying to debug this with the script below. I'm still running into 
> problems with this. When I tried to put something after the switch_root it 
> never executes. Is there any other good way to debug?
> 
> I did run lsof to see what was open after the boot. I don't see any open 
> files, just the console and tty1-4. I'm not sure if those devices are holding 
> this open and preventing the switch_root or not. I don't think /dev/console 
> is opened until switch_root executes.
> 
> 
> 
> #!/bin/busybox sh
> 
> /bin/busybox echo "Running boot script..."
> /bin/busybox echo "Mounting filesystems..."
> /bin/busybox mount -t devpts devpts /dev/pts
> /bin/busybox mount -t tmpfs tmpfs /dev/shm
> /bin/busybox mount -t proc proc /proc
> /bin/busybox mount -t sysfs sysfs /sys
> /bin/busybox mount -t tmpfs tmpfs /tmp
> /bin/busybox echo "Installing links for busybox..."
> /bin/busybox --install -s
> /bin/busybox echo /sbin/mdev > /proc/sys/kernel/hotplug
> /bin/busybox mdev -s
> /bin/busybox echo "mounting rootfs..."
> /bin/busybox mount -t xfs /dev/vda /mnt
> /bin/busybox echo "Swtiching root"
> /bin/busybox mount --move /sys  /mnt/sys<tried these three lines 
> because others have done this in examples, doesn't seem to matter
> /bin/busybox mount --move /proc /mnt/proc
> /bin/busybox mount --move /dev /mnt/dev
> #exec /sbin/switch_root -c /dev/console /mnt /sbin/init   <this line and 
> the next seem to execute but it goes to another console or hangs
> exec /sbin/switch_root /mnt /sbin/init

Hi,
Just out of curiosity I wonder why you don'y use 
/bin/busybox  switch_root -c /dev/console /mnt /sbin/init 

is sbin in $PATH?
does sbin exist?
is there a link in sbin named switch_root pointing to /bin/busybox?

Just my 2 cents.

P.S.: You should not top-post.

Ciao,
Tito

> /bin/busybox echo "Switched root"   <this never executes
> exec /bin/sh   <-this never executes
> 
> From: Jody Bruchon 
> Sent: Tuesday, June 15, 2021 11:09 AM
> To: Porter, Jeremy 
> Subject: Re: switch_root and /etc/inittab
> 
> I would suggest adding code after the switch_root that indicates that the 
> command fell through. You could, for example, put an echo message then "exec 
> /bin/sh" after it so you're running a shell that's PID 1 and you can 
> experiment. That's what I did. You will be stuck in between init script 
> completion and switch_root, and if you manage to perform the switch_root 
> successfully by hand, you'll see the new root fs pick up and run. This will 
> let you use tools like lsof to see if something is holding a file open or ps 
> to see if some other process is running when you're trying to switch. You 
> have to have no other files open or programs running when you switch, 
> otherwise the old root can't be discarded and the switch will fail. This was 
> the hardest part for me.
> 
> On June 15, 2021 10:55:34 AM EDT, "Porter, Jeremy" 
>  wrote:
> >Thank you for the example--that was helpful to see how this works.
> >
> >I have initramfs in Linux enabled and I've been using that for a long
> >time. I should be able to use switch_root.
> >
> >I followed the prior suggestion to skip the inittab and use a script. I
> >put a script in /etc/init.d/rcS:
> >
> >#!/bin/busybox sh
> >
> >/bin/busybox echo "Running boot script..."
> >/bin/busybox echo "Mounting filesystems..."
> >/bin/busybox mount -t devpts devpts /dev/pts
> >/bin/busybox mount -t tmpfs tmpfs /dev/shm
> >/bin/busybox mount -t proc proc /proc
> >/bin/busybox mount -t sysfs sysfs /sys
> >/bin/busybox mount -t tmpfs tmpfs /tmp
> >/bin/busybox echo "Installing links for busybox..."
> >/bin/busybox --install -s
> >/bin/busybox echo /sbin/mdev > /proc/sys/kernel/hotplug
> >/bin/busybox mdev -s
> >/bin/busybox echo "mounting rootfs..."
> >/bin/busybox mount -t xfs /dev/vda /mnt
> >/bin/busybox echo "Swtiching root"
> >exec /sbin/switch_root -c /dev/console /mnt /sbin/init
> >
> >This runs and gets to switch_root.
> >
> >It does not switch_root though. It doesn't run the new roots inittab
> >which is present.
> >
> >I get something like this:
> >
> >[1.262512] XFS (vda): Ending recovery (logdev: internal)
> >Swtiching root
> >
> >Please press Enter to activate this console.
> >
> >
> >BusyBox v1.33.1 (2021-06-1

Re: switch_root and /etc/inittab

[Porter, Jeremy]

I've been trying to debug this with the script below. I'm still running into 
problems with this. When I tried to put something after the switch_root it 
never executes. Is there any other good way to debug?

I did run lsof to see what was open after the boot. I don't see any open files, 
just the console and tty1-4. I'm not sure if those devices are holding this 
open and preventing the switch_root or not. I don't think /dev/console is 
opened until switch_root executes.



#!/bin/busybox sh

/bin/busybox echo "Running boot script..."
/bin/busybox echo "Mounting filesystems..."
/bin/busybox mount -t devpts devpts /dev/pts
/bin/busybox mount -t tmpfs tmpfs /dev/shm
/bin/busybox mount -t proc proc /proc
/bin/busybox mount -t sysfs sysfs /sys
/bin/busybox mount -t tmpfs tmpfs /tmp
/bin/busybox echo "Installing links for busybox..."
/bin/busybox --install -s
/bin/busybox echo /sbin/mdev > /proc/sys/kernel/hotplug
/bin/busybox mdev -s
/bin/busybox echo "mounting rootfs..."
/bin/busybox mount -t xfs /dev/vda /mnt
/bin/busybox echo "Swtiching root"
/bin/busybox mount --move /sys  /mnt/sys<tried these three lines 
because others have done this in examples, doesn't seem to matter
/bin/busybox mount --move /proc /mnt/proc
/bin/busybox mount --move /dev /mnt/dev
#exec /sbin/switch_root -c /dev/console /mnt /sbin/init   <this line and 
the next seem to execute but it goes to another console or hangs
exec /sbin/switch_root /mnt /sbin/init
/bin/busybox echo "Switched root"   <this never executes
exec /bin/sh   <-this never executes
________
From: Jody Bruchon 
Sent: Tuesday, June 15, 2021 11:09 AM
To: Porter, Jeremy 
Subject: Re: switch_root and /etc/inittab

I would suggest adding code after the switch_root that indicates that the 
command fell through. You could, for example, put an echo message then "exec 
/bin/sh" after it so you're running a shell that's PID 1 and you can 
experiment. That's what I did. You will be stuck in between init script 
completion and switch_root, and if you manage to perform the switch_root 
successfully by hand, you'll see the new root fs pick up and run. This will let 
you use tools like lsof to see if something is holding a file open or ps to see 
if some other process is running when you're trying to switch. You have to have 
no other files open or programs running when you switch, otherwise the old root 
can't be discarded and the switch will fail. This was the hardest part for me.

On June 15, 2021 10:55:34 AM EDT, "Porter, Jeremy" 
 wrote:
>Thank you for the example--that was helpful to see how this works.
>
>I have initramfs in Linux enabled and I've been using that for a long
>time. I should be able to use switch_root.
>
>I followed the prior suggestion to skip the inittab and use a script. I
>put a script in /etc/init.d/rcS:
>
>#!/bin/busybox sh
>
>/bin/busybox echo "Running boot script..."
>/bin/busybox echo "Mounting filesystems..."
>/bin/busybox mount -t devpts devpts /dev/pts
>/bin/busybox mount -t tmpfs tmpfs /dev/shm
>/bin/busybox mount -t proc proc /proc
>/bin/busybox mount -t sysfs sysfs /sys
>/bin/busybox mount -t tmpfs tmpfs /tmp
>/bin/busybox echo "Installing links for busybox..."
>/bin/busybox --install -s
>/bin/busybox echo /sbin/mdev > /proc/sys/kernel/hotplug
>/bin/busybox mdev -s
>/bin/busybox echo "mounting rootfs..."
>/bin/busybox mount -t xfs /dev/vda /mnt
>/bin/busybox echo "Swtiching root"
>exec /sbin/switch_root -c /dev/console /mnt /sbin/init
>
>This runs and gets to switch_root.
>
>It does not switch_root though. It doesn't run the new roots inittab
>which is present.
>
>I get something like this:
>
>[1.262512] XFS (vda): Ending recovery (logdev: internal)
>Swtiching root
>
>Please press Enter to activate this console.
>
>
>BusyBox v1.33.1 (2021-06-10 08:53:34 EDT) built-in shell (ash)
>
>/ # ls
>
>Is there any good way to debug this switch_root?
>
>The new root has /etc/inittab like this:
>
>::sysinit:-/bin/ash
>::sysinit:/bin/busybox echo "hello from /etc/inittab"
>
>At the end of this file there are 12 null characters (^@) that show up
>in VIM after I boot in /etc/inittab. Those are not there initially. I
>can delete them, verify they are gone, and then see them again after
>boot.
>
>I tried following the suggestion of booting directly to the new root by
>adding a kernel command at boot and that did not work.
>
>Kernel panic - not syncing: VFS: Unable to mount root fs on
>unknown-block(0,0)
>
>That image does work because I can mount it. It's the same one I'd
>switch_root too.

Re: switch_root and /etc/inittab

[Porter, Jeremy]

Thank you for the example--that was helpful to see how this works.

I have initramfs in Linux enabled and I've been using that for a long time. I 
should be able to use switch_root.

I followed the prior suggestion to skip the inittab and use a script. I put a 
script in /etc/init.d/rcS:

#!/bin/busybox sh

/bin/busybox echo "Running boot script..."
/bin/busybox echo "Mounting filesystems..."
/bin/busybox mount -t devpts devpts /dev/pts
/bin/busybox mount -t tmpfs tmpfs /dev/shm
/bin/busybox mount -t proc proc /proc
/bin/busybox mount -t sysfs sysfs /sys
/bin/busybox mount -t tmpfs tmpfs /tmp
/bin/busybox echo "Installing links for busybox..."
/bin/busybox --install -s
/bin/busybox echo /sbin/mdev > /proc/sys/kernel/hotplug
/bin/busybox mdev -s
/bin/busybox echo "mounting rootfs..."
/bin/busybox mount -t xfs /dev/vda /mnt
/bin/busybox echo "Swtiching root"
exec /sbin/switch_root -c /dev/console /mnt /sbin/init

This runs and gets to switch_root.

It does not switch_root though. It doesn't run the new roots inittab which is 
present.

I get something like this:

[1.262512] XFS (vda): Ending recovery (logdev: internal)
Swtiching root

Please press Enter to activate this console.


BusyBox v1.33.1 (2021-06-10 08:53:34 EDT) built-in shell (ash)

/ # ls

Is there any good way to debug this switch_root?

The new root has /etc/inittab like this:

::sysinit:-/bin/ash
::sysinit:/bin/busybox echo "hello from /etc/inittab"

At the end of this file there are 12 null characters (^@) that show up in VIM 
after I boot in /etc/inittab. Those are not there initially. I can delete them, 
verify they are gone, and then see them again after boot.

I tried following the suggestion of booting directly to the new root by adding 
a kernel command at boot and that did not work.

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

That image does work because I can mount it. It's the same one I'd switch_root 
too.

That makes me wonder if there is something wrong with the image. It'x XFS and I 
have that in my kernel (I can mount and read it).


I appreciate all the help! Thank you.

Jeremy


From: Jody Bruchon 
Sent: Monday, June 14, 2021 11:44 AM
To: Porter, Jeremy 
Subject: Re: switch_root and /etc/inittab

Hi Jeremy!

I'm attaching the '/init' from my from-scratch Linux environment, the Tritech 
Service System. The public release hasn't been updated for a long time, but it 
still uses the same init system. If you want to see it in action, look here:

https://www.jodybruchon.com/tritech-service-system/<https://urldefense.com/v3/__https://www.jodybruchon.com/tritech-service-system/__;!!KGKeukY!ndVE7hu0zLAhbkrANopCcyPdH0e7avFN9BnGZRFOTP3Z5V8yepQt6t_O7t3LY4LuRyywZR1AYxKY0A$>

This may help you to figure out how to switch_root correctly--it sure took me a 
long time to get it right myself. I believe you can't do it if any files on the 
existing system are open other than the switch_root binary itself, nor can you 
do it if your root isn't ramfs (so use of an initrd is mandatory), because part 
of the process is pivoting the root FS to a mountpoint and then tossing out the 
original tmpfs filesystem completely.

The reason I use switch_root is because ramfs (which initrd always gets 
decompressed into) allows anything that fills the filesystem to crash the 
kernel by attempting to allocate more space than RAM has available, but 
switch_root into a tmpfs instance and you can prevent that from happening, so 
the initrd in mine is just enough stuff to switch over to tmpfs and hand 
control over to the real init system I use (also shell scripts, but using 
BusyBox runit for service controls).

I really hope this helps. Feel free to ask any questions you may have. I'm 
happy to help.

Jody Bruchon

On 2021-06-14 10:35, Porter, Jeremy wrote:
Thanks Ján!

I'm not sure I completely understand though. Doesn't "exec" make it run as PID 
1?

I suppose I need to start /dev/console before switching the root if I'm going 
to use that in the command to redirect there after switch_root.

In my inittab

::sysinit:/bin/busybox mount -t devpts devpts /dev/pts
::sysinit:/bin/busybox mount -t tmpfs tmpfs /dev/shm
::sysinit:/bin/busybox mount -t proc proc /proc
::sysinit:/bin/busybox mount -t sysfs sysfs /sys
::sysinit:/bin/busybox mount -t tmpfs tmpfs /tmp
::sysinit:/bin/busybox --install -s
::sysinit:/bin/busybox echo /sbin/mdev > /proc/sys/kernel/hotplug
::sysinit:/bin/busybox mdev -s
::sysinit:/bin/busybox mount -t xfs /dev/vda /mnt
/dev/console::sysinit:-/bin/ash
::sysinit:/bin/init.sh
::respawn:-/bin/ash

In my init.sh script

#/bin/bash
echo "Swtiching root"
exec /sbin/switch_root -c /dev/console /mnt /sbin/init
echo "Switched root"

This does not switch root either.

I don't quite understand the boot flow

Re: switch_root and /etc/inittab

[Laurent Bercot]

I'm not sure I completely understand though. Doesn't "exec" make it run 
as PID 1?


 Not if the script containing the "exec" does not run as pid 1 in the
first place.

 When busybox init runs, it runs as pid 1, and stays there until
you shutdown the machine. Any script it spawns, even in your
::sysinit lines, will spawn with other pids. So your /bin/init.sh
script is not running as pid 1, so switch_root will fail.

 But I'm not even sure why you want to use switch_root here.
switch_root is only useful when you have to boot on an initramfs;
from what you've said it doesn't appear necessary for your goal.
If you have a rootfs with a functional init, which appears to be the
case, you can just boot qemu on that rootfs and it should work.
(You might need to turn your rootfs into a disk image first, but the
point is that your situation doesn't seem to require an initramfs and
switch_root.)

--
 Laurent

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: switch_root and /etc/inittab

[Porter, Jeremy]

Thanks Ján!

I'm not sure I completely understand though. Doesn't "exec" make it run as PID 
1?

I suppose I need to start /dev/console before switching the root if I'm going 
to use that in the command to redirect there after switch_root.

In my inittab

::sysinit:/bin/busybox mount -t devpts devpts /dev/pts
::sysinit:/bin/busybox mount -t tmpfs tmpfs /dev/shm
::sysinit:/bin/busybox mount -t proc proc /proc
::sysinit:/bin/busybox mount -t sysfs sysfs /sys
::sysinit:/bin/busybox mount -t tmpfs tmpfs /tmp
::sysinit:/bin/busybox --install -s
::sysinit:/bin/busybox echo /sbin/mdev > /proc/sys/kernel/hotplug
::sysinit:/bin/busybox mdev -s
::sysinit:/bin/busybox mount -t xfs /dev/vda /mnt
/dev/console::sysinit:-/bin/ash
::sysinit:/bin/init.sh
::respawn:-/bin/ash

In my init.sh script

#/bin/bash
echo "Swtiching root"
exec /sbin/switch_root -c /dev/console /mnt /sbin/init
echo "Switched root"

This does not switch root either.

I don't quite understand the boot flow. Can you walk through what needs to 
happen here?

Thanks!

Jeremy

From: Ján Sáreník 
Sent: Sunday, June 13, 2021 1:41 AM
To: Porter, Jeremy ; busybox@busybox.net 

Subject: Re: switch_root and /etc/inittab

Hi Jeremy!

On Fri, Jun 11, 2021 at 2:39 PM Porter, Jeremy
 wrote:
>
>
> I'm working on a RISC-V Linux system that uses busybox and switch_root. My 
> goal is to build and include a tool chain (GDB, GCC, etc) into this RISC-V 
> Linux. I figured I could create a non-volatile image and attach that in QEMU, 
> which works fine. What is not working is the "switch_root" portion. I know it 
> needs to run at PID 1 and to use "exec". But that doesn't cut it. It runs, 
> but doesn't switch root. I'll post my inittab files below.
>
> This is the inittab on the initramfs:
>
> ::sysinit:/bin/busybox mount -t devpts devpts /dev/pts
> ::sysinit:/bin/busybox mount -t tmpfs tmpfs /dev/shm
> ::sysinit:/bin/busybox mount -t proc proc /proc
> ::sysinit:/bin/busybox mount -t sysfs sysfs /sys
> ::sysinit:/bin/busybox mount -t tmpfs tmpfs /tmp
> ::sysinit:/bin/busybox --install -s
> ::sysinit:/bin/busybox echo /sbin/mdev > /proc/sys/kernel/hotplug
> ::sysinit:/bin/busybox mdev -s
> ::sysinit:/bin/busybox mount -t xfs /dev/vda /mnt
> /dev/console::sysinit:-/bin/ash

Instead of running the init straight, there is possibility of using an
initial shell script (e.g. init=/my/script.sh in bootloader) and then
this script would contain the lines from inittab (quoted above)
including execing switch_root in the end.

So the boot would look like this (all PID 1 here):
  1. /my/script.sh, execs switch_root /new/root /bin/init
  2. /bin/init (on new root, will read /etc/inittab on new root)

The reason it did not work for you is that init itself was run as PID
1 and it is not a shell so it does not have any `exec ...` syntax
(yet, I mean the busybox init).

> When I run switch_root it executes and just hangs with no console so I added 
> the line:
>
> ::respawn:-/bin/ash
>
> which now returns to console like I want. However, it didn't switch_root 
> after I run:
>
> exec switch_root -c /dev/console /mnt /sbini/init
>
> I am still on the initramfs and I still have the new root on /mnt
>
> I also noticed that switch_root runs this /etc/inittab no matter what -- even 
> if I delete it -- when I run switch_root. I guess I was expected the new file 
> system's inittab to take over and I could just have a few lines to run. The 
> primary function would be to get back to the console with ::respawn:-/bin/ash.
>
> What am I missing?

It can not work in the shell run by that respawn line because that
spawned shell is not PID 1.

Hoping this helps,
best regards, Ján
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: switch_root and /etc/inittab

[Ján Sáreník]

Hi Jeremy!

On Fri, Jun 11, 2021 at 2:39 PM Porter, Jeremy
 wrote:
>
>
> I'm working on a RISC-V Linux system that uses busybox and switch_root. My 
> goal is to build and include a tool chain (GDB, GCC, etc) into this RISC-V 
> Linux. I figured I could create a non-volatile image and attach that in QEMU, 
> which works fine. What is not working is the "switch_root" portion. I know it 
> needs to run at PID 1 and to use "exec". But that doesn't cut it. It runs, 
> but doesn't switch root. I'll post my inittab files below.
>
> This is the inittab on the initramfs:
>
> ::sysinit:/bin/busybox mount -t devpts devpts /dev/pts
> ::sysinit:/bin/busybox mount -t tmpfs tmpfs /dev/shm
> ::sysinit:/bin/busybox mount -t proc proc /proc
> ::sysinit:/bin/busybox mount -t sysfs sysfs /sys
> ::sysinit:/bin/busybox mount -t tmpfs tmpfs /tmp
> ::sysinit:/bin/busybox --install -s
> ::sysinit:/bin/busybox echo /sbin/mdev > /proc/sys/kernel/hotplug
> ::sysinit:/bin/busybox mdev -s
> ::sysinit:/bin/busybox mount -t xfs /dev/vda /mnt
> /dev/console::sysinit:-/bin/ash

Instead of running the init straight, there is possibility of using an
initial shell script (e.g. init=/my/script.sh in bootloader) and then
this script would contain the lines from inittab (quoted above)
including execing switch_root in the end.

So the boot would look like this (all PID 1 here):
  1. /my/script.sh, execs switch_root /new/root /bin/init
  2. /bin/init (on new root, will read /etc/inittab on new root)

The reason it did not work for you is that init itself was run as PID
1 and it is not a shell so it does not have any `exec ...` syntax
(yet, I mean the busybox init).

> When I run switch_root it executes and just hangs with no console so I added 
> the line:
>
> ::respawn:-/bin/ash
>
> which now returns to console like I want. However, it didn't switch_root 
> after I run:
>
> exec switch_root -c /dev/console /mnt /sbini/init
>
> I am still on the initramfs and I still have the new root on /mnt
>
> I also noticed that switch_root runs this /etc/inittab no matter what -- even 
> if I delete it -- when I run switch_root. I guess I was expected the new file 
> system's inittab to take over and I could just have a few lines to run. The 
> primary function would be to get back to the console with ::respawn:-/bin/ash.
>
> What am I missing?

It can not work in the shell run by that respawn line because that
spawned shell is not PID 1.

Hoping this helps,
best regards, Ján
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: switch_root and /etc/inittab

[Brilliantov Kirill Vladimirovich]

On 2021-06-11 12:02:22, Porter, Jeremy wrote:
>  
> which now returns to console like I want. However, it didn't switch_root after
> I run:
> 
> exec switch_root -c /dev/console /mnt /sbini/init

Hello, Jeremy!
`/sbini/init`, are you sure? Or this is a typo and you pass correct path to
init?

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

switch_root and /etc/inittab

[Porter, Jeremy]

I'm working on a RISC-V Linux system that uses busybox and switch_root. My goal 
is to build and include a tool chain (GDB, GCC, etc) into this RISC-V Linux. I 
figured I could create a non-volatile image and attach that in QEMU, which 
works fine. What is not working is the "switch_root" portion. I know it needs 
to run at PID 1 and to use "exec". But that doesn't cut it. It runs, but 
doesn't switch root. I'll post my inittab files below.

This is the inittab on the initramfs:

::sysinit:/bin/busybox mount -t devpts devpts /dev/pts
::sysinit:/bin/busybox mount -t tmpfs tmpfs /dev/shm
::sysinit:/bin/busybox mount -t proc proc /proc
::sysinit:/bin/busybox mount -t sysfs sysfs /sys
::sysinit:/bin/busybox mount -t tmpfs tmpfs /tmp
::sysinit:/bin/busybox --install -s
::sysinit:/bin/busybox echo /sbin/mdev > /proc/sys/kernel/hotplug
::sysinit:/bin/busybox mdev -s
::sysinit:/bin/busybox mount -t xfs /dev/vda /mnt
/dev/console::sysinit:-/bin/ash

When I run switch_root it executes and just hangs with no console so I added 
the line:

::respawn:-/bin/ash

which now returns to console like I want. However, it didn't switch_root after 
I run:

exec switch_root -c /dev/console /mnt /sbini/init

I am still on the initramfs and I still have the new root on /mnt

I also noticed that switch_root runs this /etc/inittab no matter what -- even 
if I delete it -- when I run switch_root. I guess I was expected the new file 
system's inittab to take over and I could just have a few lines to run. The 
primary function would be to get back to the console with ::respawn:-/bin/ash.

What am I missing?



___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox