chroot cp/mv commands in a bash script

[VastOne]

During the VSIDO installation process, at the very end, chroot takes over and installs grub and systemd-sysv and updates apt.  All of this works perfectly and I love the process. It looks like this

Code Select Expand


#!/bin/bash
chroot /TARGET grub-install --force --no-floppy "$GRUBLOC"
chroot /TARGET update-grub
chroot /TARGET apt-get update > /dev/null 2>&1
chroot /TARGET apt-get -y install systemd-sysv > /dev/null 2>&1
chroot /TARGET cp -fv /etc/skel/.fluxbox/menu1 /home/$TARGETUSER*/.fluxbox/menu
chroot /TARGET cp -fv /etc/skel/.fluxbox/startup1 /home/$TARGETUSER*/.fluxbox/startup
exit 0

Notice the last two lines that consist of the cp command to make changes to the users home directory.  These lines fail in the script.  However if I

Code Select Expand


sudo su
chroot /TARGET
cp -fv /etc/skel/.fluxbox/menu1 /home/$TARGETUSER*/.fluxbox/menu
chroot /TARGET cp -fv /etc/skel/.fluxbox/startup1 /home/$TARGETUSER*/.fluxbox/startup

These commands work perfectly.  This is a puzzle that has me perplexed... I am sure it is a syntax issue but there is nothing logging that indicates failure

@aibo and anyone who wants to reproduce this... Right after an install while still on the LiveCD, you can chroot all you want to the /TARGET build directory

You would have to add the above lines of code to /usr/bin/remastersys-install to effectively duplicate the failure

I set up an install in a Virtual Box and then make the changes and try installations over and over... Nothing I have tried has successfully ran from the script but has run perfectly from a terminal chroot into /TARGET

[hakerdefo]

That's probably because a program like cp in this instance can break out of a chroot jail if it can gain root privilege and change its CWD to the real root directory. But without root privilege it can't. So just copy the necessary files in '/etc/skel' from real system into the '/etc/skel' of chroot jail before you chroot. For example,

Code Select Expand


cp /etc/skel/.fluxbox/menu1 /path/to/chroot/etc/skel
cp /etc/skel/.fluxbox/startup1 /path/to/chroot/etc/skel

Cheers!!!

[VastOne]

Are you saying that piping into chroot (chroot /TARGET) at the beginning of each line does not 'see' it's own /etc/skel instances?

There is an /etc/skel in /TARGET already and I have tried commands like:

Code Select Expand

chroot /TARGET cp -fv $TARGET/etc/skel/.fluxbox/startup1 /home/$TARGETUSER*/.fluxbox/startup

that failed.  I am not understanding what you are saying needs to be done in the jail.. would you elaborate please?

Thanks

[hakerdefo]

VastOne I'm assuming you are using some kind of bash script for install process. If you are willing to experiment there is an easier way to create-enter-exit a chroot jail. For this you will need the following bash script on the system. We will call it 'chroot_jail'. In this script only thing you have to define is the path to the chroot jail. For example 'CHROOT=/home/chroot-jail'. This script by default will copy the file '/etc/resolv.conf' and '/etc/skel/' directory from system to chroot jail. You can copy other files-directories to the chroot jail as per needs by placing their respective 'cp' commands at the beginning of the function 'start()' in the script. After making necessary changes save the script somewhere in $PATH and 'chmod 755' it.

Code Select Expand


#!/bin/bash

#define the chroot jail path
CHROOT=

start() {

   cp --dereference /etc/resolv.conf ${CHROOT}/etc/
   cp --recursive /etc/skel/ ${CHROOT}/etc/

   mount -o bind /proc ${CHROOT}/proc
   mount -o bind /proc/bus/usb ${CHROOT}/proc/bus/usb
   mount -o bind /dev ${CHROOT}/dev
   mount -o bind /dev/pts ${CHROOT}/dev/pts
   mount -o bind /dev/shm ${CHROOT}/dev/shm
   mount -o bind /sys ${CHROOT}/sys

   chroot ${CHROOT} /bin/bash

}

stop() {

   umount -f ${CHROOT}/proc/bus/usb >/dev/null
   umount -f ${CHROOT}/proc >/dev/null &
   umount -f ${CHROOT}/dev/pts >/dev/null
   umount -f ${CHROOT}/dev/shm >/dev/null
   umount -f ${CHROOT}/dev >/dev/null &
   umount -f ${CHROOT}/sys >/dev/null &

}

if [ "$1" == "start" ]
then
   start
elif [ "$1" == "stop" ]
then
   stop
else
   exit 1
fi



Now whenever you need to enter into the chroot environment in your install script all you need to do is add the following line,

Code Select Expand


chroot_jail start

This would enter you into the chrooted environment. After this you won't have to do  'chroot /TARGET' before every command. The following would be good enough,

Code Select Expand


grub-install --force --no-floppy "$GRUBLOC"
update-grub
apt-get update > /dev/null 2>&1
apt-get -y install systemd-sysv > /dev/null 2>&1
cp -fv /etc/skel/.fluxbox/menu1 /home/$TARGETUSER*/.fluxbox/menu
cp -fv /etc/skel/.fluxbox/startup1 /home/$TARGETUSER*/.fluxbox/startup

And when you need to exit the chroot environment in your install script you just add this line,

Code Select Expand


chroot_jail stop

This way your install script will be easy to read-maintain-debug. Try this and see whether this makes any difference to the 'cp' problem you mentioned. This is absolutely untested but I guess there won't be any harm in you trying this fresh approach.
Cheers!!!

[hakerdefo]

@VastOne To sum up my first reply, run following command from a terminal chroot into /TARGET

Code Select Expand

which cp
It will return the complete path to the cp. For example if it gives,

Code Select Expand

/path/to/cp
Then in your script replace 'cp' with '/path/to/cp' and test the script.
EDIT: Forgot this. Another thing you should check is '$TARGETUSER*' variable. For some reasons it might not be expanding in your script.
Cheers!!!

[VastOne]

I am working on this again now hakerdefo, I will keep you posted on this as well...

Needed a breather for a while

[hakerdefo]

Taking time-out from seemingly difficult problems gives you a new perspective to tackle them. There will be a solution cause there always is one!
Cheers!!!