On Thu, 17 Jun 2021 13:13:23 +0000 "Porter, Jeremy" <porter....@buckeyemail.osu.edu> 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 <j...@jodybruchon.com> > Sent: Tuesday, June 15, 2021 11:09 AM > To: Porter, Jeremy <porter....@buckeyemail.osu.edu> > 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" > <porter....@buckeyemail.osu.edu> 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. > > > >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 <j...@jodybruchon.com> > >Sent: Monday, June 14, 2021 11:44 AM > >To: Porter, Jeremy <porter....@buckeyemail.osu.edu> > >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://urldefense.com/v3/__https://www.jodybruchon.com/tritech-service-system/__;!!KGKeukY!iu9rOfE-M1YEFnDFSvZ7CSMqOmv79MLQWgH7E-2HgCccG3GMZy3Y_aLwr_WYic6mi5erCb4x_t5V9A$ > > > ><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. Can you walk through what needs > >to happen here? > > > >Thanks! > > > >Jeremy > >________________________________ > >From: Ján Sáreník <jajom...@gmail.com><mailto:jajom...@gmail.com> > >Sent: Sunday, June 13, 2021 1:41 AM > >To: Porter, Jeremy > ><porter....@buckeyemail.osu.edu><mailto:porter....@buckeyemail.osu.edu>; > >busybox@busybox.net<mailto:busybox@busybox.net> > ><busybox@busybox.net><mailto:busybox@busybox.net> > >Subject: Re: switch_root and /etc/inittab > > > >Hi Jeremy! > > > >On Fri, Jun 11, 2021 at 2:39 PM Porter, Jeremy > ><porter....@buckeyemail.osu.edu><mailto:porter....@buckeyemail.osu.edu> > >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<mailto:busybox@busybox.net> > >https://urldefense.com/v3/__http://lists.busybox.net/mailman/listinfo/busybox__;!!KGKeukY!iu9rOfE-M1YEFnDFSvZ7CSMqOmv79MLQWgH7E-2HgCccG3GMZy3Y_aLwr_WYic6mi5erCb5Hre2lcw$ > > > ><https://urldefense.com/v3/__http://lists.busybox.net/mailman/listinfo/busybox__;!!KGKeukY!ndVE7hu0zLAhbkrANopCcyPdH0e7avFN9BnGZRFOTP3Z5V8yepQt6t_O7t3LY4LuRyywZR1PpEnNFQ$> > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
