Thanks, will do that (although I could swear that there is no preinit.d in /programs0, I'll find out when I get there) as soon as this disk check is finished.

Boy, fsck -fay /dev/hda4 sure is taking a long time.

I am admittedly behind on these efforts to create a standard partition layout and painless 3rd-party app installs, but I don't understand this /programs0 stuff. Why don't we use /usr/local as the standard mount point like the rest of the UNIX-using world? I think this /programs0 /programs1 stuff is really confusing. Especially for those of us who *don't* want 3rd-party apps on our music partitions.

Yeah, like I said. There is no preinit.d in either /programs0 or in /etc.

empeg:/empeg/bin# cd /programs0
empeg:/programs0# ls
lost+found
empeg:/programs0# mv preinit.d /etc/
mv: preinit.d: No such file or directory
empeg:/programs0# ro
empeg:/programs0#

Since you've rebooted, /dev/hda2 has been mounted on /programs0, and the contents of /dev/hda2 have thus obscured the contents of /programs0/ (the directory on the root parrition).

Try:
umount /programs0
ls /programs0

and you will probably see preinit.d
So, after having done this,

rw
cd /programs0
mv preinit.d /etc/
cd /
./mkprgpt


Yeah, you're right...even with the script, it still takes a willingness to learn and understand a smattering or more of linux principles and commands. I want to get this down to point and click.

How to deal with 2 drives?

/usr/local0
/usr/local1
??

/usr/local/drive0
/usr/local/drive1

??

Maybe /opt0 and /opt1 ?

My main reasons for using /programs0 and /programs1 were;
Make them easily available from the / partition.
Make it obvious which patition is on which drive.
Make it obvious what the partitions are for non- linux/unix users, who make up the majority of mortals here.
The empeg is hardly a typcial unix/linux system - so standards weren't a major concern.


That being said - when we get to point and click installation via JEmplode or any other package, those points become moot. But we needed a start point to get more people using 3rd party apps to start driving this stuff, and my script provided that.

Now is the time to be having this debate though. We need to standardise stuff like this before point and click for the masses is implemented. We also need to ensure that migration is painless. (not too tricky)

Sorry. I went to bed early and have been working on a real bugbear of a problem at work, thus my silentness during all of this.

In general, the correct procedure for doing this is simply:

mkdir /programs0

mkdir /programs1

mke2fs /dev/hda2

mke2fs /dev/hdc2

mount /dev/hda2 /programs0

mount /dev/hdc2 /programs1

You can leave off the /programs1 and /dev/hdc2 stuff if you have only one drive.

The reason I didn't include those instructions is because I assumed that genixia's script already did it and I didn't want everything to change all of a sudden for people not using it. (Maybe that's not a good reason.)

However, I'll go back and include those instructions on my web page ASAP.

I think /programs{0,1} is fine. As you imply, all ``standards'' are down the toilet now anyway, since we're avoiding /etc for configuration scripts. It's not like knowledge of that sort of preexisting knowledge is really going to help anyone anyway, and for the rest, hopefully, they'll never see it.

Try:
umount /programs0
ls /programs0

and you will probably see preinit.d
So, after having done this,

rw
cd /programs0
mv preinit.d /etc/
cd /
./mkprgpt

This worked. Thanks.

However, now every time I use the Hijack/CharcoalGray XML web interface to set RW and RO, the player segfaults like crazy in an infintite loop (as described earlier in this thread).

Hmm..I hate to use these 2 words together, but.... bug.....hijack.

Let me look at this a bit, see if I can work out what's going on.

Might have something to do with the ``mount'' command with no options no longer reporting correctly. Can we talk to him and see if he can use /proc/mounts instead? (I don't use the web interface.)

FYI, the Hijack I'm running is jaharkes modified version that has the fix which will make it work better with the GPSapp. Dunno if that has any bearing.

How to deal with 2 drives?
/usr/local0
/usr/local1
??
/usr/local/drive0
/usr/local/drive1

How to deal with 2 drives?

/usr/local0
/usr/local1
??
/usr/local/drive0
/usr/local/drive1


Nope...

The ideal situation as I see it is /usr/local containing symlinks to /drive0/emptriv, /drive1/gpsapp, or whatever. So the install program would install them to a user-chosen path, then create a link in /usr/local.

That way, those who choose to install on the music partitions and those (like me) who install to the spare 32mb partition can both have our programs available under /usr/local. The physical location is abstracted.

It shouldn't. Beyond having hijack exec /sbin/hijack instead of /sbin/init, it's all pretty basic userland stuff. But if you want to be sure, you could try just installing a normal Hijack kernel temporarily.

I'd argue that /opt makes more sense here than /usr/local, but a good idea nonetheless.

My main reasoning for this is that if the empeg guys ever decided that we needed a separate /usr filesystem (unlikely but possible), then preinit would have to mount /usr in addition, which could be a bad thing. Having an immediate subdirectory of / obviates that possibility.

By the way. I now get "EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended" twice when I do RWP.

What commands do I execute to fix this for the new programs partitions? It's not in the FAQ.

I think I figured it out. Do what's in the FAQ, except replace "4" with "2".

Yeah, that seemed to work.

Hey - you're learning

Okay, I think I got preinit and GPSapp installed. Finally. Thanks, everyone, for all your help. Now to interface my Rand Mcnally unit to the player (I'll take those questions to another thread).

Jaharkes, your installation instructions in the readme need clarification. For example, you don't say that you need "incar" uploaded to /programs0, though I gleaned that this would be necessary so I did that and it seems to work. You also did not say that you need to chmod 755 all the files, which I also gleaned would be necessary. And to run the hack_init, you did not say it has to be ./hack_init in order to work. And I don't know if hack_init sets the drives back to read only, but its onscreen prompt says to reboot. If I had rebooted when it said to, and hadn't done an RO, I'll bet I would have been in trouble, huh?

Also, my player is in home mode but I still see GPS in the Hijack menu. Does that mean the "incar" test in the M50gpsapp script didn't work?

Also, my player is in home mode but I still see GPS in the Hijack menu. Does that mean the "incar" test in the M50gpsapp script didn't work?

More info. Serial port when booting says:

player.cpp : 385:empeg-car 2.00-beta13 2002/07/24.
: command not foundd/M50gpsapp:
: command not foundd/M50gpsapp:
: command not foundd/M50gpsapp: exit
: command not foundd/M50gpsapp:
GPS app started

Yeah, I'm down with /opt/ too. The empeg installer could drop a symlink from /opt/appname to wherever it puts the actual subdirectory. Then the preinit scripts don't need to be custom, they can all go after /opt/appname/name_of_binary. IWBNI the installer provided good "default" places to put the apps in a dropdown box. I suggest the following:

/drive0/appname (default, since a lot of people seem to want to use the music partitions)
/drive1/appname (for those who ran out of space on /drive0)
/usr/local/appname (my preference, since I have a separate /usr partition)

For those with a non-standard location where they want to physically put the directory, they could just type that in or put it in the installer's INI file or something.

Tony, is that you I see volunteering to write a GPS FAQ after you're done with all this stuff?

Tony, is the next Empeg meet going to have a prize for "most followups to oneself on the BBS", or something? I think you'd be the front runner?

No offence meant - do keep following-up yourself with new information, etc. It's just that I noticed you replying to yourself in three different branches of this thread at the same time. Hmm, I think I've discovered your secret - all the sub-Tony instances that you use to keep people pointed at the FAQ have lost their synchronisation and are replying to each other. Even more strangely, @O#o$@#e@P#@,.$%%xaUu--\

+++
NO CARRIER

Looks like a buffer overrun in notify.c

If my analysis is correct, this should only happen when you have used ftp or web inteface to both remount drives rw and then ro. If you use serial/telnet to run rw, rwm, rwp, then an ftp/web ro command will be fine. And if you use ftp/web to set rw, then a serial/telnet ro will also work. And all paritions need to be rw for the site ro to fail, ie if you ftp/web site rw, then serial/telnet rom, then ftp/web site ro will be okay.

The reason for all of this is because hijack's ftp/web remount commands use some performance-enhancing flags, whereas the binary utilities don't. These flags increase the amount of data read into the buffer, as does the fact that we've added 2 partitions, and once that data hits >256 byte we're in trouble. This theory is supported by the charactor count of /proc/mounts after an ftp site rw, which returns 268 bytes.

So I'm currently building a modified HJ299 with a larger buffer to see if that fixes it.

If my analysis is correct, this should only happen when you have used ftp or web inteface to both remount drives rw and then ro.

Correct. Nice catch.

So I'm currently building a modified HJ299 with a larger buffer to see if that fixes it.

You rock. I also need Jaharke's fixes for the GPSapp in it, too, though.

If the fixes for GPSapp amount to just making the player start without grabbing the serial port (and I don't know that that's true), you might be able to get it to work by using a blocking script in preinit that calls the player with -s-.

No the hijack kernel patch actually involves resetting the knob-press timer to 0 when we enter a userland application. It avoids switching between mp3/aux/tuner about 1-2 secs. after the moment application is selected.

Then nevermind.

BTW, if someone would like to ``donate'' a GPS receiver, I might keep more up to date with such things.

I'm considering what to do with my Trimble SV6 at the moment. It's missing an antenna. (I stuck it on my Oncore)

I think bgmicro still have some...did the other day.

Yep, that appears to be the problem.

Try hijack299-jh1-mount fix

I'll ask Mark to include that mount fix in the next HJ.