Including git commands in preseed

[Todd Maurice]

I'm working on i386, Debian testing net install, in VirtualBox, through "auto url=".

I would like for the preseed to do the following.

apt-get update &&
apt-get dist-upgrade -y
clone https://github.com/project
cd /folder/
git checkout project

I tried this scheme but when I logon there is no folder named "project" meaning clone command was not successful.

d-i preseed/late_command string apt-get update && apt-get dist-upgrade -y
d-i preseed/late_command string in-target git clone https://github.com/project

I would rather use preseed than a script.

Thanks for the help.

[Todd Maurice]

Some text was missing in the previous message, sorry about that.

---------------------------------------------------------------------------------------------------------------

I'm working on i386, Debian testing net install, in VirtualBox, through "auto url=".

I would like for the preseed to do the following.

***apt-get update &&
**apt-get dist-upgrade -y
**clone https://github.com/project
**cd /folder/
**git checkout project

[Zenaan Harkness]

On 1/9/14, Todd Maurice <toddm...@outlook.com> wrote:
> Some text was missing in the previous message, sorry about that.
>

> I'm working on i386, Debian testing net install, in VirtualBox, through
> "auto url=".
>
> I would like for the preseed to do the following.
>
> ***apt-get update &&
> **apt-get dist-upgrade -y
> **clone https://github.com/project

I'm not familiar with preseed, but do have some minimal git experience.

If that's meant to be a git command, it should be preceded by "git ", ie:
git clone https://github.com/project.git output-folder-name.git

> **cd /folder/
> **git checkout project

By default, when you "git clone", a checkout happens automatically.

It looks to me like you need to read a git tutorial. For a few years
now, there is excellent git documentation out there, and plenty of it.

Check out:
http://gitscm.com/

Good luck
Zenaan


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/CAOsGNSS=5zzh8xNafdetMpDRXJS7K...@mail.gmail.com

[Todd Maurice]

Thank you Zenaan for the link.

You are right, I am very inexperienced when it comes to git however the command used with the preseed was
"git clone https://github.com/project" (d-i preseed/late_command string in-target git clone https://github.com/project). I just forgot to type it in the email :)

The problem is that when ran through preseed, there is no project directory. If I enter the command manually, all good, project folder is created.

[Eero Volotinen]

2014/1/8 Todd Maurice <toddm...@outlook.com>

I'm working on i386, Debian testing net install, in VirtualBox, through "auto url=".

clone https://github.com/project

 git clone https://github.com/project 

 

--

Eero 

[Todd Maurice]

For whatever reason "d-i preseed/late_command string in-target git clone https://github.com/adrelanos/Whonix", like Eero suggested, doesn't work. No folder is created.

I did find the solution though.

You need to set the target directory and it works then.
d-i preseed/late_command string in-target git clone https://github.com/project /root/project


The directory needs to be defined. If not, like with the option below, it won't work.
d-i preseed/late_command string in-target git clone https://github.com/project /root

[Todd Maurice]

OK, new problem.

If choose to install in user (/usr/ or /user/ as opposed to /root/) no directory is created.

Command used:
d-i preseed/late_command string in-target git clone https://github.com/project /usr/project

Any idea how to make the cloning work in /usr/?

[Bob Proulx]

Just to check but git isn't a standard command normally installed.
Have you ensured that git is installed at that time? Would you be
able to tell if the command was not found?

d-i pkgsel/include string git

Rather than try to do commands inline it is much easier to load them
into a script and then pull the script. Here is a live example that I
am currently using.

d-i preseed/late_command string wget -O/target/var/tmp/bootstrap http://despair.proulx.com/medley/medley-bootstrap; in-target sh /var/tmp/bootstrap

Using a script makes things much easier.

Bob

[Todd Maurice]

I have included git install in the preseed (d-i pkgsel/include string git). After I log on, running "git" offers a list of available git commands (bisect, branch,.....tag) so the installation that way is successful.

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.

Command:
d-i preseed/late_command string in-target git clone https://github.com/project /home/user/folder

for cd /folder I will probably have to use script (cd folder) and start it with source ./scriptnamew. Just sh ./ doesn't work for changing directories.

I agree that script would be easier overall, it's just I am a bit shaky on how to start.

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?

"http://despair.proulx.com/medley/medley-bootstrap;"
Location from where wget should fetch the script?

"in-target sh /var/tmp/bootstrap"
No idea what this does. Auto start?

[Bob Proulx]

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

[Todd Maurice]

Thanks for the detailed answer Bob. I tried different things gathered from the Internet, even copying your exact command, but to no avail.


"d-i preseed/late_command string wget -O/target/var/tmp/bootstrap http://file; in-target sh /var/tmp/bootstrap"
Error 127. I believe the problem is that wget needs in-target, as in "wget in -target -O". I'm doing this on Jessie.

"d-i preseed/late_command string in-target wget -O /var/tmp/bootstrap http://file; in-target sh /var/tmp/bootstrap"
Stops (hangs, freezes, does not continue) at 16% during the preseed part of the installation (script is 1kb and I left the install process running at 16% for an hour).

"d-i preseed/late_command string in-target wget -O /var/tmp/bootstrap http://file;"
Downloads the file but does not start it automatically (logical regarding the command).

"d-i preseed/late_command string in-target wget -O /var/tmp/bootstrap http://file; sh /var/tmp/bootstrap;"
Works if I write it in terminal (wget part, after installation of course) but as part of the preseed, it says "failed with exit code 2". Logical since "in-target" is missing

"d-i preseed/late_command string in-target wget -O etc/postInstall.sh http://file;chmod 700 /target/etc/postInstall.sh"
Downloads the file but does not start it automatically.

"d-i preseed/late_command string in-target wget -O root/script.sh https://raw.github.com/drgdel/test/master/test; chmod 700 /target/root/script.sh; in-target sh /root/script.sh"
Stops (hangs, freezes, does not continue) at 16% during the preseed part of the installation (script is 1kb and I left the install process running at 16% for an hour).

"d-i preseed/late_command string wget -O /target/root/late_command.sh  https://raw.github.com/drgdel/test/master/test; \
in-target chmod 755 /root/late_command.sh; in-target /root/late_command.sh"
Error 127.

I'm open any new suggestions that would enable me to wget the script and then make it run automatically as I login.

[Bob Proulx]

Todd Maurice wrote:
> "d-i preseed/late_command string wget -O/target/var/tmp/bootstrap http://file; in-target sh /var/tmp/bootstrap"

The example I gave was verbatim what I am using and is what works for me.

The above uses a different URL and one that doesn't look valid to
me. Is that a literal "http://file" there? That isn't a valid URL
even for an local network.

> Error 127. I believe the problem is that wget needs in-target, as in "wget in -target -O". I'm doing this on Jessie.

"in-target" is for the late_command part not the wget part. The wget
is in the debian-installer environment and so will work from the
initrd boot.

You could run wget from the target environment. You would need to add
wget to the installation package list so as to ensure that it is
installed in your target system. Otherwise I think it isn't installed
by default. Not sure.

Regardless "wget in -target -O" isn't a valid set of options for wget.
As far as wget is concerned it is only running, reading from the
network, writing to the file designated by -O. That write path file
name will either be /target/somethingsomething for a d-i initrd
environment installation, or it will be -O/somethingsomething without
the /target part if it is operating inside the chroot target.

> "d-i preseed/late_command string in-target wget -O /var/tmp/bootstrap http://file; in-target sh /var/tmp/bootstrap"
> Stops (hangs, freezes, does not continue) at 16% during the preseed part of the installation (script is 1kb and I left the install process running at 16% for an hour).

Note that a script error in the late_command can hang things. Since
it hung there I can only assume that it is waiting for something.
Such as a command waiting to read stdin. (The first thought that came
to mind was a grep that was reading stdin because I have seen that
several times before. But only you know what is in your script.)

> "d-i preseed/late_command string in-target wget -O /var/tmp/bootstrap http://file;"
> Downloads the file but does not start it automatically (logical regarding the command).

Great. If that works then wget is definitely already getting
installed in your target environment. And somehow "http://file" is
working for you by some method I can't fathom.

> "d-i preseed/late_command string in-target wget -O /var/tmp/bootstrap http://file; sh /var/tmp/bootstrap;"
> Works if I write it in terminal (wget part, after installation of course) but as part of the preseed, it says "failed with exit code 2". Logical since "in-target" is missing

I believe the in-target stops at the ';' and therefore you need a
second one after that before the "sh" command.

> "d-i preseed/late_command string in-target wget -O etc/postInstall.sh http://file;chmod 700 /target/etc/postInstall.sh"
> Downloads the file but does not start it automatically.
>
> "d-i preseed/late_command string in-target wget -O root/script.sh https://raw.github.com/drgdel/test/master/test; chmod 700 /target/root/script.sh; in-target sh /root/script.sh"
> Stops (hangs, freezes, does not continue) at 16% during the preseed part of the installation (script is 1kb and I left the install process running at 16% for an hour).

Reinforces that there is a hang in the script.

> "d-i preseed/late_command string wget -O /target/root/late_command.sh https://raw.github.com/drgdel/test/master/test; \
> in-target chmod 755 /root/late_command.sh; in-target /root/late_command.sh"
> Error 127.
>
> I'm open any new suggestions that would enable me to wget the script and then make it run automatically as I login.

Make your script extremely simple for the test. Just to verify that
it is running. Then make it more complex as needed one step at a
time. Along the way you will find out what is causing the hang.

At the top of the script I would redirect all output to a log file
that you can examine later. I would redirect input from /dev/null so
that it won't hang waiting for keyboard input.

#!/bin/sh
exec </dev/null >/var/tmp/bootstrap.out 2>&1
echo "Begin script"
dostuffhere
echo "End script"
exit 0

I think it likely that simply redirecting all input from /dev/null
will cause the hang to fall through. Because I will guess that some
command is stopped waiting for your input. It will now get EOF and
likely continue. But then you should be able to see it in the
redirected output and fix it.

Bob

[Todd Maurice]

Sorry for the confusion, http://file indicates the actual URL fo the file.

My simple test script is located at https://raw.github.com/drgdel/a/master/1
Content:
#!/bin/bash
echo Hello World

Preseed entry take 1:
d-i preseed/late_command string in-target wget -O /var/tmp/hello https://raw.github.com/drgdel/a/master/1; in-target sh /var/tmp/hello

The installation downloaded the script but there is no auto run (no matter if I log as root or user).

Typing
sh /var/tmp/hello

when logged, runs the script.

There seems to be some progress since when using the same preseed line with a more complex script (check my last email) the install got stuck at 16% but still no auto-launch.

Preseed entry take 2:
d-i preseed/late_command string in-target wget -O root/script.sh https://raw.github.com/drgdel/a/master/1; chmod 700 /target/root/script.sh; in-target sh /root/script.sh

The installation downloaded the script but there is no auto run (no matter if I log as root or user).

Typing
sh ./script.sh

when logged, runs the script.

There seems to be some progress since when using the same preseed line with a more complex script (check my last email) the install got stuck at 16% but still no auto-launch.

I tried the preseed entry take 2 with your suggested script (same syntax just changed 1 for 2 in the ).
d-i preseed/late_command string in-target wget -O root/script.sh https://raw.github.com/drgdel/a/master/2; chmod 700 /target/root/script.sh; in-target sh /root/script.sh

https://raw.github.com/drgdel/a/master/2
Content:

#!/bin/sh
exec </dev/null >/var/tmp/bootstrap.out 2>&1

echo Hello World
exit 0

It created a file containing the text Hello World. No autorun.

I tried your command, verbatim (aside from URL) on Weezy and Jessie but again error 127.

d-i preseed/late_command string wget -O/target/var/tmp/bootstrap https://raw.github.com/drgdel/a/master/1; in-target sh /var/tmp/bootstrap


So while there is a problem with the script, I can't get even a simple one to boot automatically.

[Bob Proulx]

Todd Maurice wrote:
> #!/bin/bash
> echo Hello World

That output show should up in vt 4. Use Alt-F4 at installation time
to see the output there.

I would make the output more visible. I would make it LOUD.

#!/bin/bash
echo ================================================================
echo ================================================================
echo Hello World
echo ================================================================
echo ================================================================

> Preseed entry take 1:
> d-i preseed/late_command string in-target wget -O /var/tmp/hello https://raw.github.com/drgdel/a/master/1; in-target sh /var/tmp/hello
>
> The installation downloaded the script but there is no auto run (no
> matter if I log as root or user).

Stop. What? You say, "no matter if I log as root or user". What and
when are you talking about there? The late_command runs at
installation time. At installation time there is no ability to log
into the machine as either root or user. There are additional VTs
such as Alt-F2 and Alt-F3, press Enter to get a console, for terminals
to be used during the installation. But that is root only. There
isn't a way to log in as a user at that time.

I think that is a clue that you are doing something completely different!

> Typing
> sh /var/tmp/hello
>
> when logged, runs the script.

Yes. That is *after* the installation because files in /var/tmp
persist after the reboot.

> I tried the preseed entry take 2 with your suggested script (same
> syntax just changed 1 for 2 in the ).

> d-i preseed/late_command string in-target wget -O root/script.sh https://raw.github.com/drgdel/a/master/2; chmod 700 /target/root/script.sh; in-target sh /root/script.sh
>
> https://raw.github.com/drgdel/a/master/2
> Content:
> #!/bin/sh
> exec </dev/null >/var/tmp/bootstrap.out 2>&1
> echo Hello World
> exit 0
>
> It created a file containing the text Hello World. No autorun.

You have stated a conflict. You said it created the file
/var/tmp/bootstrap.out with the contents "Hello World". That means
that it ran. But then you said it didn't run. Those two statements
conflict.

Please say *exactly* what you mean by "autorun" because I think there
lies the confusion.

The late_command runs at debian-installer time. It runs during the
installation of the system. That's it. It never runs again after
that point. If it ran during installation then the task was done.

> So while there is a problem with the script, I can't get even a
> simple one to boot automatically.

Again, "boot automatically"?? What is this? You appear to be talking
about something completely different from a preseed late_command
running at installation time.

The late_command runs during the system installation time. It runs
once only. (On my system the debian-installer says 27% at the time
that it runs. But that is no matter.) If the late_command hangs and
does not complete then the debian-installer will be blocked waiting
for it to complete. The d-i cannot proceed until the late_command
exits.

After that point in the installation the d-i will continue on with the
installation. Eventually d-i will ask to reboot the system (asking
can be preseeded away) and the system will reboot. After the reboot
you can log in either as root or as the first user created during the
installation. There is no execution of late_command again at any
point after it was run the one time during installation before the
first reboot.

Perhaps what you are trying to do could be more easily accomplished by
creating a package of it and then installing the package?

Bob

[Todd Maurice]

Hm, it seems I haven't clearly clarified what I want to do.

I'm using preseed file (through "auto url=" option) to install Debian Jessie in a VM. I would like to configure preseed in such way that it accomplishes two things.

1. It downloads a script from github (we figured out that part)
2. Starts the downloaded script when I log ("debian login") for the first time on the freshly installed system.

I have successfully accomplished 1. (download) but not 2. (autorun).

Thanks for your patience.

[Bob Proulx]

Todd Maurice wrote:
> Hm, it seems I haven't clearly clarified what I want to do.
>
> I'm using preseed file (through "auto url=" option) to install
> Debian Jessie in a VM.

Sounds good. Many of us do this all of the time. Works.

> I would like to configure preseed in such way that it accomplishes
> two things.

> 1. It downloads a script from github (we figured out that part)

Good.

> 2. Starts the downloaded script when I log ("debian login") for the
> first time on the freshly installed system.

The above is conflicting information. The words above. This part:

when I log ("debian login") for the first time

What does that mean to you? Do you mean when you log into the system
at the login prompt? That is confusingly written but that is how I
translate it when I read it. If so then that is NOT what late_command
does. It will NEVER do what you are asking because that is not what
late_command does.

Previously you wrote:
no auto run (no matter if I log as root or user)

But late_command runs at installation time not at login time. If you
are logging in to the system then late_command has already been run
once before the system was rebooted.

And you wrote:
It created a file containing the text Hello World. No autorun.

You said it created the file containing the output of your script.
That confirms that that the late_command WAS RUN successfully at
INSTALLATION TIME. If it were not then you would not have seen the
output of the script in the file. You claimed that the output was in
the file therefore the script *was* autorun.

> I have successfully accomplished 1. (download) but not 2. (autorun).

After carefully reading this entire thread again I believe it is
automatically running at installation time. It is all working
correctly. As far as I can read this just isn't what you are wanting
it to do.

Please say again what you are wanting to do.

Bob

[Igor Cicimov]

What he wants I guess is use the preseed to add the git commands, or a script or what ever, in the users ~/.bashrc file (assuming the users default shell is bash) during installation which will then run upon users login when the freshly installed system reboots.

[Todd Maurice]

> What does that mean to you? Do you mean when you log into the system

> at the login prompt? That is confusingly written but that is how I
> translate it when I read it. If so then that is NOT what late_command
> does. It will NEVER do what you are asking because that is not what
> late_command does.

Igor explained it better than I could. Coming from Windows I was thinking "autorun" as the script writing "Hello World" on the screen when I log in as user.

> use the preseed to add a script during installation which will then run upon users login when > the freshly installed system reboots.

I have been using Hello World script to reduce problems that might arise from using a complex script but later I would like to use this setup for autologin.

#!/bin/bash
sed -i '54d' /etc/inittab
echo "1:2345:respawn:/bin/login -f user tty1 </dev/tty1 >/dev/tty1 2>&1" >> /etc/inittab

[Andrei POPESCU]

On Lu, 20 ian 14, 18:09:59, Todd Maurice wrote:
>
> I have been using Hello World script to reduce problems that might
> arise from using a complex script but later I would like to use this
> setup for autologin.

Uhh, another case of XY problem
http://meta.stackoverflow.com/questions/66377/what-is-the-xy-problem

> #!/bin/bash
> sed -i '54d' /etc/inittab
> echo "1:2345:respawn:/bin/login -f user tty1 </dev/tty1 >/dev/tty1 2>&1" >> /etc/inittab

To accomplish what you want I would change /etc/inittab with a
late_command, *but* the commands above are not really safe:

1. you rely on the specific format of /etc/inittab
2. your script is not indempotent, just think what happens if you run it
several times
3. sed can do the change in one go ;)

This should work (all in one line):

sed -i -e 's,1:2345:respawn:\/sbin\/getty 38400 tty1,1:2345:respawn:\/bin/login -f user tty1 <\/dev\/tty1 >\/dev\/tty1 2>&>1,' /etc/inittab

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt

[Bob Proulx]

Andrei POPESCU wrote:
> Todd Maurice wrote:
> > I have been using Hello World script to reduce problems that might
> > arise from using a complex script but later I would like to use this
> > setup for autologin.
>
> Uhh, another case of XY problem
> http://meta.stackoverflow.com/questions/66377/what-is-the-xy-problem

Ugh, yes, another good case of the XY problem. Sigh.

To make this thread easier to find by search engines I will mention
that this would be a Linux text console kiosk mode.

> > #!/bin/bash
> > sed -i '54d' /etc/inittab
> > echo "1:2345:respawn:/bin/login -f user tty1 </dev/tty1 >/dev/tty1 2>&1" >> /etc/inittab
>
> To accomplish what you want I would change /etc/inittab with a
> late_command, *but* the commands above are not really safe:
>
> 1. you rely on the specific format of /etc/inittab
> 2. your script is not indempotent, just think what happens if you run it
> several times
> 3. sed can do the change in one go ;)
>
> This should work (all in one line):
>
> sed -i -e 's,1:2345:respawn:\/sbin\/getty 38400 tty1,1:2345:respawn:\/bin/login -f user tty1 <\/dev\/tty1 >\/dev\/tty1 2>&>1,' /etc/inittab

The above may have had some mailer munging. I see two simple typos.
The '&' is special to sed and is lost in the resulting line. It needs
to be escaped with \&. Also not a problem but since '/' is avoided as
the sed substitute character it means that they don't need to be
escaped in the string and one of them had been missed anyway.

As a matter of preference I would continue to use getty for this and
have it set up the tty state. Then it can call /bin/login. Therefore
I would still continue to use getty. This works in Wheezy 7 but not
in the old Squeeze 6. (Note that getty -a username is new in Wheezy 7
and doesn't exist in Squeeze 6.) Then the redirections are no longer
needed. It is just a small amount simpler then.

I tested this and it worked for me on a Wheezy 7 install.

sed -i 's,1:2345:respawn:/sbin/getty .*tty1 *$,1:2345:respawn:/sbin/getty -a USERNAME 38400 tty1,' /tmp/inittab

Change /tmp/inittab to /etc/inittab which I left intentionally so that
it couldn't do harm by a stray paste.

I will mention that in Wheezy 7 the getty annoyingly to those of us
who care about boot errors automatically clears the boot screen unless
the --noclear option is given. You might want it. YMMV.

1:2345:respawn:/sbin/getty --noclear -a USERNAME 38400 tty1

Bob

[Andrei POPESCU]

On Ma, 21 ian 14, 15:27:00, Bob Proulx wrote:
>
> The above may have had some mailer munging. I see two simple typos.
> The '&' is special to sed and is lost in the resulting line. It needs
> to be escaped with \&. Also not a problem but since '/' is avoided as
> the sed substitute character it means that they don't need to be
> escaped in the string and one of them had been missed anyway.

Thanks for checking! While I use sed occasionally I'm definitely not
familiar with it. The part about escaping the '/' I suspected, but
didn't bother to look it up, as I choose ',' mostly for readability.

[Todd Maurice]

d-i preseed/late_command string in-target sed -i 's,1:2345:respawn:/sbin/getty .*tty1 *$,1:2345:respawn:/sbin/getty -a user 38400 tty1,' /etc/inittab;

Works like a charm on Wheezy! Thank you everybody and a special thanks to Bob for the working code!