I'm writing a bash script to change my rootfs to another one, on a SD card.The steps are roughly:mount /dev/hda1 /new-rootcd /new-rootpivot_root . old-rootexec chroot . sh <dev/console >dev/console 2>&1umount /old-rootThis works as expected in an interactive mode but not in a script as the interpreters runs in the old-root, I cannot unmount it.So, I tried using an intermediate script in which one I kill the parent like this:# parentexec chroot sd_card_fs sh -c script.sh# soncat script.sh...  kill -9 $PPID  umount /old-root  ...This doesn't work as the son suicides, killing its parent and I find this solution somehow dirty.So my questions:Is there a cleaner way than invoking another script to do the job ? If not, how can I fix it ?I really want to minimize, as much as possible the human interaction so calling a script, waiting for it to finish to launch another one is a no go unless there is no other solution.
umount root in a script
shell script;chroot
But that last command in the parent script replaces it with the son.  That's what exec does.  You should not have any parent process you could kill.Such scripts can only work when the script is PID 1, so that there are no other processes[*].  You must have booted with init=/bin/bash.  Remember to invoke your script by using exec, so it replaces PID 1.Do not use lazy unmount, it means you won't see error messages.I'm 99% confident your lazy unmount hadn't finished.  I'm not sure how to test this, other than if you use ext4 or ext3, file -s /dev/$ROOT_DEV should show needs journal recovery (i.e. has not been cleanly unmounted).I would expect your first attempt to work if you remove the kill and follow the bolded instructions above.  I might have missed something though.[*] or, you would need to tell init to re-exec itself, after arranging for the path it exec's to be on the target filesystem.  But that sounds like a terrible idea to me.  Just keep things simple.