Telnet not working on redone hack

[ReidWings]

I am currently hacking a 240 S2 unit running 7.2.2b and have run into some trouble. I don't use it that often to stream so I usually let it unhack when the tivo updates software and just rehack it afterwards. I have done this numerous times successfully and had never had trouble re-doing it all in a short time.

However, today I am having some difficulty re-doing my hack. I cannot seem to access my tivo remotely in any way (telnet, ftp). Here's what I did:

1. Ran Bootpage, found root was hda7
2. DD'd killhdinitrd kernel (3.1.5) to disk2s6
3. Edited IP tables
4. Added rc.sysinit.author files and some various other files to the /bin and /var directories

My tivo boots and works fine normally. However, I cannot access it via telnet. Here is what I have listed in my rc.sysinit.author file:

tnlited 23 /bin/bash -login &

echo -ne "\x14\x40\x00\x24" | dd conv=notrunc of=tivoapp bs=1 seek=3233124

/var/tivoftpd &

/bin/mfs_ftp.tcl

# Call the Tivo Package Manager Startup Scripts
/etc/rc.d/rc.sysinit.tpm

PATH=/var/hack/bin:/sbin:/bin:/tivobin:/tvbin:.
TIVO_ROOT=
MFS_DEVICE=/dev/hda10
IGNOREEOF=1000
export PATH TIVO_ROOT MFS_DEVICE IGNOREEOF

Note I also added mfs_ftp and tivoftpd into the directories listed in the code and cannot use these either.

Anyone have any ideas why I am having trouble? I am missing something obvious? Or is there some reason my rc.sysinit.author file wouldn't be loading? This is especially strange given this is exactly what I have done in the past and it has worked fine.

Thanks for the help!

[ScanMan]

I don't know if you included the entire .author file but you need as the 1st line:

#!/bin/bash

[ocntscha]

Anyone have any ideas why I am having trouble? I am missing something obvious? Or is there some reason my rc.sysinit.author file wouldn't be loading? This is especially strange given this is exactly what I have done in the past and it has worked fine.

Thanks for the help!
Did you maybe forget to make rc.sysinit.author executable?

As far as #!/bin/bash needing to be at the top of the file, I know it goes against the conventional way of doing it here but if you think about it really makes more sense not to have that line. Whats the point in starting an additional shell soley to run the commands in rc.sysinit.author? Look at any of the other rc scripts besides rc.sysinit, none of them have that at the top.

[ReidWings]

Thanks for all the help--I forgot to make it executable...I'm an *****. :) Thanks!

[ScanMan]

Look at any of the other rc scripts besides rc.sysinit, none of them have that at the top.Good point; never noticed that. I guess I just followed convention b/c I had pretty much always seen that line in there. Thanks for the clarification.

[Jamie]

As far as #!/bin/bash needing to be at the top of the file, I know it goes against the conventional way of doing it here but if you think about it really makes more sense not to have that line. Whats the point in starting an additional shell soley to run the commands in rc.sysinit.author? Look at any of the other rc scripts besides rc.sysinit, none of them have that at the top.It runs in a sub-shell either way. If you doubt this, here's an easy experiment to run:

bash-2.02# cat > foo
echo "my pid: $$"
grep -i ppid /proc/$$/status
bash-2.02# chmod +x foo
bash-2.02# ./foo
my pid: 1796
PPid: 1739
bash-2.02# ./foo
my pid: 1798
PPid: 1739Note that "my pid" changes each time you run the script. PPid (the parent pid) is constant, and is the pid of the interactive bash.

Try the experiment again with the pound bang line at the top, and you'll see there is no difference.

If you *really" want to know what is happening, strace the bash that runs your script. For example: "strace -f bash -c ./foo >& log". Try it with and without the pound bang line and compare.

[ocntscha]

It runs in a sub-shell either way. If you doubt thisSince your the one saying it, I don't doubt it. Sigh. I had actually conducted a similiar experiment to yours just before posting that to prove to myself a sub shell does always get started when #!/bin/bash is at the top of the file. It didn't even occur to me to test what you just pointed out. Thanks.

I might look at that some more later Jamie. The actual point was that you don't need the #!/bin/bash at the top of the file. That much I did know. I obviously should have just left it at that and refrained from attempting to explain why or why not.

At the moment though I'm busy fighting to get myself an up to date build of Tivoserver running on Linux. I'm tired of all the MS Windows weenies merrily playing along with their latest versions of Tivoserver while I'm sitting on the sidelines because I run it on Linux. That just isn't right. Btux. Btux. Are you listening??

[ocntscha]

Well I got my Tivoserver going on Linux so I came and looked at this again. You are undoubtedly right. Interactive, non-interactive, doesn't matter, I did a little more experimenting..

[schaefer@penguin what]$ ls -l
total 8
-rwxrwxr-x 1 schaefer schaefer 52 May 13 18:09 A*
-rwxrwxr-x 1 schaefer schaefer 23 May 13 18:08 B*
[schaefer@penguin what]$ cat A
#!/bin/bash
echo my pid is $$
./B
echo my pid is $$
[schaefer@penguin what]$ cat B
echo in B my pid is $$
[schaefer@penguin what]$ ./A
my pid is 27832
in B my pid is 27833
my pid is 27832

And then a little lightbulb went off in my head and it totally dawned on me what exactly the source ( . ) command does..

[schaefer@penguin what]$ ls -l
total 8
-rwxrwxr-x 1 schaefer schaefer 54 May 13 18:11 A*
-rwxrwxr-x 1 schaefer schaefer 23 May 13 18:08 B*
[schaefer@penguin what]$ cat A
#!/bin/bash
echo my pid is $$
. ./B
echo my pid is $$
[schaefer@penguin what]$ cat B
echo in B my pid is $$
[schaefer@penguin what]$ ./A
my pid is 27861
in B my pid is 27861
my pid is 27861
[schaefer@penguin what]$

Good stuff Jamie. I like the way you made your file with just cat > foo and then entered some text, never done that before. And I looked at strace too, quite interesting, but a little more than I needed right now.

[Jamie]

And I looked at strace too, quite interesting, but a little more than I needed right now.I learned something by stracing this example: It seems that bash forks a new process, then tries to execve the program (./foo). The execve fails since the file doesn't have a pound bang line, so the forked bash goes ahead and reads and interprets the file itself. So you were sort of right originally: you got a new process (via fork), but you don't really exec a new shell: you use a clone (fork) of the original.

[ocntscha]

I just thought of another possibility and went and looked on my Tivo at rc.sysinit. Sure enough it sources all the script files, so actually they do all run in the same shell, here's the relative fragment..

if [ -f $ScriptFragmentFile ]; then
if [ "$DebugStartupScripts" = "true" ]; then
echo "About to invoke $ScriptFragmentFile"
fi
source $ScriptFragmentFile
else

EDIT..
except for rc.sysinit.author, that actually does get ran, not sourced, from within /etc/rc.d/StageG_PostApplication/rc.Sequence_100.InvokeLateStressDiags.sh

[Jamie]

EDIT..
except for rc.sysinit.author, that actually does get ran, not sourced, from within /etc/rc.d/StageG_PostApplication/rc.Sequence_100.InvokeLateStressDiags.shRight. So it's probably technically better to include the pound bang line in rc.sysinit.author. Otherwise, you are depending on an (undocumented?) feature of bash that might change in the future.

Edit: Actually, it is documented, so your choice whether you want a pound bang line or not:If this execution fails because the file is not in executable format, and the file is not a directory, it is assumed to be a shell script, a file containing shell commands. A subshell is spawned to execute it. This subshell reinitializes itself, so that the effect is as if a new shell had been invoked to handle the script, with the exception that the locations of commands remembered by the parent (see hash below under SHELL BUILTIN COMMANDS) are retained by the child.