Todd Maurice wrote: > I was able to find the solution (for now). > > The problem was that the directory was not set correctly. /usr/ won't work but /home/user will. However this solution is no explanation. I wouldn't want to clone into /usr anyway and so think /home/something is better. But there should be no difference and without some explanation this seems like a snag that will hit again. > I agree that script would be easier overall, it's just I am a bit > shaky on how to start. Create a script and have it do all of the work. #!/bin/sh git clone https://github.com/project /home/user/folder cd /home/user/folder dowhatever exit 0 > Let me check if I understood your syntax correctly. > > "wget -O/target/var/tmp/bootstrap" > This creates a file called bootstrap in the selected directory? Yes. See the man page for wget. The -O is the output file option. > "http://despair.proulx.com/medley/medley-bootstrap;"; > Location from where wget should fetch the script? Yes. That is a server on my private LAN. I simply locate the script where it can be pulled from the network. I wget that location and place it in the target's /var/tmp directory. On Debian and many Unix-like systems the /tmp directory is purged on reboot. The contents of /var/tmp are not and persist across reboots. The system is going to reboot at the end of the installation. Any file in /tmp will be removed when the system reboots at the end of the installation. But I wanted to inspect the contents of the script and in the script I write information and debug information out to /var/tmp so that the files will intentionally remain behind after a reboot for me to inspect and debug. That is the only reason I saved the file to /var/tmp. In hindsight saving the file to /root/bootstrap would perhaps be a better choice. But since this is at system installation time there aren't any other users on the system so it doesn't really matter. > "in-target sh /var/tmp/bootstrap" > No idea what this does. Auto start? This executes the script inside the target environment. The previous snippet copied the script from the net to the local target. This part is what causes the script to run. "in-target" means chroot'd into the target. Meaning that paths are relative to the target root and not the debian-installer root. Meaning that chroot'd inside the target you can run normal installer commands such as dpkg, apt-get, aptitude, and so forth just as if you were logged into the system normally. If the wget had been operated inside the target with in-target then the -O path would have been /var/tmp/bootstrap instead of /target/var/tmp/bootstrap with the leading prefix "/target" part. But it wasn't necessary for wget since the command is available in the debian-installer environment. I arbitrarily chose to run it in the d-i environment. But in order to operate commands such as git you will need to operate it in-target. It will need to have access to shared libs and sub-commands and other things that have been installed in the target environment and not the debian-installer environment. Therefore you will want to run the script in-target so that all of its commands are in-target too. The "in-target" causes the command to be run chroot'd to the /target directory path. The "sh" part is /bin/sh and causes the script to be run by "sh /var/tmp/bootstrap" the same as any other shell script. Alternatively I could have added commands to "chmod a+x /var/tmp/bootstrap" so that the script was executable. Then I could have simply called "in-target /var/tmp/bootstrap" without the "sh" part and because it is executable it would have been executed. But adding that chmod a+x added another command to that already long d-i command line. Since I know it is a shell script simply invoking it with "sh scriptfilepath" seemed simplest. This does mean that if I were to convert the bootstrap script over to another language such as perl, python, ruby, or some such that I would need to also change the d-i preseed configuration. But me changing that from shell to something else is extremely unlikely since the shell is perfectly suited to this task. And so I ran it "sh scriptfilepath" to keep things simple. Bob
Attachment:
signature.asc
Description: Digital signature