hijack: no memory for parsing config.ini; skipped

Error mounting partitions (possibly already mounted)

Remounting first music partition read-only

Remounting second music partition read-only

No secondary hard disk

Press 'q' now to go into development mode. You Have Zero Seconds To Comply...

Starting player

kmalloc: Size (262873) too large

hijack: no memory for parsing config.ini; skipped



[hijack] ERROR: : "no memory"

khttpd: listening on port 80

kftpd: listening on port 21

Starting original player

  player.cpp        : 385:empeg-car 2.00-beta11 2002/02/08.

Prolux 4 empeg car - 2.1434 Feb  7 2002

Vcb: 0x4086d000

Anyone know why I am getting this? Before you ask:

empeg:/empeg/bin# cd /empeg/var

empeg:/empeg/var# ls -la

drwxr-xr-x    2 0        0            4096 Jun  7 17:33 .

drwxr-xr-x    5 0        0            4096 May 29  2001 ..

-rw-r--r--    1 0        0         4832225 Mar 31 03:37 car-emplode-v2.00-beta11.zip

-rw-r--r--    1 0        0             949 Jun  7 17:40 config.ini

-rw-r--r--    1 0        0          717592 Jun  7 17:33 database

-rw-r--r--    1 0        0           22568 Jun  7 17:33 playlists

-rw-r--r--    1 0        0             390 Jun  7 17:33 tags

So my config.ini is definitely not too big. What I have done is that I have created a script to run the player binary with the -s- option i.e.

empeg:/empeg/bin# cd /empeg/bin

empeg:/empeg/bin# cat player

#!/bin/bash



CODE=42



while [ $CODE -eq 42 ]; do



        echo "Starting original player"

        /empeg/bin/player.orig -s- $1 $2 $3 $4 $5 $6

        CODE=$?

        echo "Original player exited with return code" "$CODE"



        if [ $CODE -eq 42 ]; then

                echo "Restarting player..."

        fi

done

The original player binary is simply renamed to player.orig.

Perhaps there is a better way to do this? Everything else works fine, hijack just runs out of room to load the config.ini to parse things. I am also running preinit.d with that little telnetd and the viewer program that attaches to hijack. All I have to do is rename the player.orig back to the original and everything's sweet again so I don't think it's preinit.d.

It appears to be something to do with using the shell to launch the player.

Ideas?

thanks,

As part of the way hijack intercepts and modifies config.ini, so that ONLY the player startup sees the changes, and not "regular" accesses to that file.. Hijack looks for the name "player".

What you are doing might work if you use "player" instead of "player.orig" for the filename, using a different path (directory) to distinguish it for your purposes from your script.

Or it might not.. try it and report back.

But perhaps better than all of that, might be to just edit the "init" program on your machine, and change the name of the "player" file to something else, which would be the name of your script.

That way, the player binary can remain as-is, and everyone will be happier.

Cheers

>But perhaps better than all of that, might be
>to just edit the "init" program on your machine

And a little known secret of the kernel gods is that "vi" makes a fantastic binary file string editor. Just don't change the string length.

-ml

I have the same problem. I use a small executable called player to launch the real player with the -s- option. I could see what was happening and decided that was a bad idea :-(

Modifying the init binary is a great idea, though codewrite is my tool of choice there. After 20 years of wordstar then cua keys, vi is just too much...

However, a modified init would be tricky to have others generate and obviously not redistributable. I could distribute a program that makes the modification but that doesn't sound too friendly either. My plan it to hack kernel to stop the player from messing with the serial port. Probably creating a virtual serial port as messing with major and minor numbers of the devices didn't please the player.

This likely won't happen until summer is over though.

Cheers,

Rex.

Well using the different path method didn't work either. I put the player binary in /bin.

Modding the init binary seemed to break it completely and it won't even run the script now. I have to apply the upgrade to get it back working now... Which will off course wipe all my custom stuff

And yes I kept the length the same. I changed player to playyy making sure the NULL etc was in the same place and renamed my script to playyy.

Hijack ftp should still work, so you can just use FTP to restore the original init.

-ml

Okay, so back to the "is there a better way to do this", the answer is probably "yes".

On startup, the Hijack kernel looks for these files, and executes ONLY the first one it finds:

/sbin/hijack
/sbin/init
/etc/init
/bin/init

Perhaps whatever it is that you are trying to do can be done by replacing "init" with your own (eg. /sbin/hijack), which does whatever and then invokes the "real" /sbin/init

This is usually a better method than trying to replace the player binary, and I had just assumed you have already tried it. n'est-ce pas?

Cheers

Curious:

If Hijack kernel only executes first file it finds per your list, and /sbin/hijack exists as empeg-preinit, then why would modifying /sbin/init lock the player (assuming mod was destructive)?

lothar

It wouldn't, unless something from /sbin/hijack caused /sbin/init to be invoked.

-ml

duh.

I should really think about using my brain once and a while.

The stock init can't start a shell script. You would need an executable wrapper that launches the shell and script.

Cheers,

Rex.

Ahh.. mystery solved.

Did this problem get solved? If so, how? I'd like to be able to run a hijack userland prog that listens to NMEA sentences on the serial port. I've tried renaming the player binary to player.orig and then using a tiny script

#!/bin/bash

/empeg/bin/player.orig -s-

But I get the, out of memory error. I've written all the code, the NMEA parser, the display routines, all I want to do is wrap it up into a nice userland app.

I am currently using a simple executable binary to do this, but get the error.

Once summer is over I will see what I can do about virtualizing the serial port so the player can continue to own 'a' serial port while user apps can hit the real one. Should be a simple kernel hack.

Cheers,

Rex.