Hi all,

Is there a preferred mount point for the hda2 partition? I noticed that genixia wrote his preinit/3rd party install script to use /programs0, which I find rather... blech... as far as aesthetics go. I'd prefer to mount hda2 as /usr/local, which seems nicer from an historical point of view (i.e. more consistent with your standard linux directory tree). However, I also saw he's got hdc2 mounting on /programs1. Not having a second drive (yet), I don't know if it's partitioned in the same way as hda, but I have my doubts that it is, as it doesn't require a swap partition, dynamic data partition(?), or a root linux partition, either. If it *is* partitioned in the same manner, then I'm not sure where I'd mount an additional developer partition if the first is at /usr/local.

Anyway, the reason I'm asking (before I go and do this) is that I thought that it might be a good idea if there were a standard place to mount hda2 so that developers (which might include me someday) can locate associated files more easily. For example, all the apps could be put into /usr/local/bin, but instead of stuffing every option under the sun into that one single config.ini file, applications could have their own .rc scripts in /usr/local/share. JEmplode could then be extended to look in this directory and act as a linuxconf (err... make that empegconf) of sorts, because it knows where to find all the config files.

Cheers,

Hmmm... I hate to reply to mysolf, but...

I tried mounting hda2 as /usr/local, but when I do, it doesn't appear that it really gets mounted. I thought that that might be because the root filesystem is automatically mounted ro, so by the time hda2 gets around to being mounted, /usr is already locked up tight, and, even though hda2 gets mounted, /usr/local never gets updated, so is always an empty directory. Next thought was to change /etc/fstab to mount / as "default,rw", but that doesn't appear to work, either -- the root filesystem is mounted ro matter what the contents of /etc/fstab. (Now I can't seem to get *anything* to mount! )

Is this something that could be fixed by hijack? Am I missing a clue to how mounts work?

Am I missing a clue to how mounts work?

On a standard Linux system, filesystems listed in /etc/fstab are mounted by a startup script, which runs mount -a. On an empeg there is no startup script; init and the player just mount the filesystems they know about. The listings in /etc/fstab are just there to keep tools such as df happy.

Mounting the root filesystem (read-only) is done by the kernel before init is started (err, obviously; the kernel couldn't run init otherwise!).

If you want /dev/hda2 mounted as /usr/local automatically, you'll have to do it yourself in a non-Empeg-supplied init script.

Peter

In reply to:

---

I tried mounting hda2 as /usr/local, but when I do, it doesn't appear that it really gets mounted.

---

You do have a /usr/local directory to mount it on, right? (I think you do, from my reading of your post).

Are you trying to mount it from a shell, or from a preinit script? Are you getting any error messages? Does mount -v -l agree with what you see? Is /hda2 already mounted somewhere else? You're not assuming that the default init does "mount -a" (it doesn't), are you?

It shouldn't matter whether the /usr filesystem is writable or not. IIRC, as mounting a filesystem doesn't write anything (except in memory in the kernel).

mount or mount -v never shows me any mounts other than the root (/dev/hda5) on my empeg. I'm not sure why this is. Try cat /proc/mounts and you should see all the mounted drives.

As for the 2 drive issue - both drives in my 60GB were partitioned the same. I assume that the same image is initially on both drives, although it'd be nice to get confirmation of this from Peter or one of the other Empeg guys. It'd also be good to get confirmation that /dev/hda2 is currently unused on Mk1 models.

Yeah, "/programs0" is....bleuch. But it is obvious, something that /usr/local is not, and I'm trying to make using 3rd party apps easier for everyone - especially those who don't necessarily know much unix/linux, as they are going to be the ones having the most trouble with it. But if someone comes up with an alternative that eveyone else prefers to /programs0 then I'll go with it .

I forgot that mount won't tell you what's mounted (it relies on /etc/mtab, not /proc/mounts). But you worked that out.

If you can happily mount onto /programs0, there's nothing to stop you symlinking /usr/local to it. Hmm, is it possible that /usr/local is already a symlink on your player? Mount might not like that.

On a standard Linux system, filesystems listed in /etc/fstab are mounted by a startup script, which runs mount -a. On an empeg there is no startup script; init and the player just mount the filesystems they know about. The listings in /etc/fstab are just there to keep tools such as df happy.

Ah, that was the clue I was missing.

If you want /dev/hda2 mounted as /usr/local automatically, you'll have to do it yourself in a non-Empeg-supplied init script.

Yes, I tried doing that. I had an M99mounthda2 pre-init script, but it didn't work for me. Possibly because I didn't have it exit, though that may not matter. I'll poke around a bit more when I get home.

I currently have everything sitting on /drive0, because I couldn't even get it to mount on /progams0.

Edit: Ah, I see that the pre-init script should have been named with an N, instead of an M. Now I've fixed that, mounting /usr/local has no problems. I feel accomplished.

You do have a /usr/local directory to mount it on, right? (I think you do, from my reading of your post).

Yep.

Are you trying to mount it from a shell, or from a preinit script? [...] You're not assuming that the default init does "mount -a" (it doesn't), are you?

I tried from a shell, where it worked, then from a pre-init script, which didn't. It was this last assumption that I wasn't aware of. Now that you and Peter have jogged my memory, though, I didn't have my mount preinit script ahead of my empacman preinit script. That'll fix one problem.

Thanks,

As for the 2 drive issue - both drives in my 60GB were partitioned the same. I assume that the same image is initially on both drives, although it'd be nice to get confirmation of this from Peter or one of the other Empeg guys.

I suppose that makes sense if you're writing a tool to partition drives on the empeg -- you don't have to decide if the drive you're formatting is a primary or secondary disk. On the flip side, it means a dozen fewer songs!

Yeah, "/programs0" is....bleuch. But it is obvious, something that /usr/local is not, and I'm trying to make using 3rd party apps easier for everyone - especially those who don't necessarily know much unix/linux, as they are going to be the ones having the most trouble with it. But if someone comes up with an alternative that eveyone else prefers to /programs0 then I'll go with it.

Well, /usr/local would be obvious to linux people, at least. If not /usr/local, I'd still like to push for a "/usr/local"-looking structure within /programs0, though -- bin, lib, share. That way people could distribute their programs with an install script, or share things like font files.

It would be wonderful if apps were distributed as a tarball that looked something like this:

    /usr/local/bin/emptriv

    /usr/local/share/fonts/emptriv.font

    /usr/local/share/emptriv/datafiles

    /etc/preinit.d/M10emptriv

I'd argue that an /opt type structure might make more sense. Keep each app in its own directory to make it easier to clean. Maybe that plus a Stow-type thing to keep the binaries all in the same directory, if you like.

I'd argue that an /opt type structure might make more sense. Keep each app in its own directory to make it easier to clean.

Hmm... I'm not so familiar with /opt -- is that a SystemV/Solaris convention? There's an /opt on my IRIX box, but it's virtually empty -- /usr/local is much more used.

It's a SysV thing, IIRC. It might be an Open Group thing, though. I seem to remember that it was adopted by most of the commercial Unix vendors -- Sun, and SGI I know, possibly IBM and Digital as well.

Regardless, it's just like MSWindows's Program Files, except it works better, because it keeps all files related to that package within a subdirectory of /opt. Personally, I prefer using /usr/local on a real Unix machine, since you almost always have a package system and having a long PATH is a real pain, but developing a package system for the empeg seems like a waste of time, and I can't imagine that there will be many shared files between packages, and I don't think anyone's going to be relying on a PATH on the empeg.

But that's just my 2 cents. It doesn't make a hell of a lot of difference.

/opt has been used on linux systems in the past - usually by third party commercial vendors more used to the SysV world, but is offically obsolete as far as the LSB is concerned, in favor of /usr/local. But I can't really see much benefit in trying to religously follow the standard LSB on the empeg - I think that given the number of potential apps is relatively small, there is no net gain from using package management, and without some form of package management, the LSB model becomes tricky to administrate - expecially for linux/unix newbies, and/or a larger burden on developers. Given all of that, I'm more in favor of the /opt style, although I still think that /programs is more obvious to newbies.

Maybe I'm just being a little short-sighted or cynical though. Maybe the app developers would be willing to make the neccessary adjustments to easily install and run under a more standard LSB model. Given the release of a graphics library, maybe this could be a good thing in the long run.

I couldn't care less what it's called (opt, programs, bullshit, whatever); I just think that keeping separate apps separate might make sense. Of course, then you get into the problem of having startup scripts for each of those apps, and they must currently be outside that structure, assuming you're using preinit. So maybe a really simple package database would be a good idea. If not, maybe a standard place for shared files within opt/whatever would work, like /opt/shared.

Given the release of a graphics library, maybe this could be a good thing in the long run.

That was one of the things that led me to ask the question. If you have a simple stand alone app like pacman, it's no big deal -- you can put it wherever you like. But as soon as you have a shared graphics library, a shared font library, etc, etc, then apps have to know where to find it in its shared location -- otherwise you end up with multiple copies scattered all over the place. If you think it's hard for a newbie to install an app now, it'll only get worse when they have to deal with dependancies ("why doesn't this work?" Is the app in the same directory the gfxlib is?).

A package management database would probably be overkill, but joe user should be able to do something like this:

# ftp empeg
> cd /tmp
> rw
> put empacman.tgz
> quote site install empacman.tgz
> ro
> exit

This install script can untar and look for some specific files (LIB, FONTS, etc) that specify any dependancies (none if the files don't exist), and give appropriate error messages if the dependancies are not installed where they are expected. I don't think it would be unreasonable to expect the user to get and install dependancies if they are told what they are -- no apt-get here. The rest of the files in the tarball could simply be:

empacman/bin/empacman
empacman/share/empacman/hi.txt

(Note the extra directory there so clean up is still easy...)

The install script would look sorta like this (time to put up or shut up, I guess... ):

#!/bin/sh

# install script in half sh, half csh, cuz I don't know all the sh syntax...

tar xvf $1

appname = `echo $1 | sed 's/.tgz//'`

approot = '/usr/local'

cd $appname

if [-e ./LIBS] then

    foreach i (`cat ./LIBS`)

        if [ !-e $approot/lib/$i] then

            echo Missing $approot/$i

            exit

        fi

    end

fi

# etc, for fonts and whatever else



# make sure the bins and preinit script are really executable

chmod 755 ./bin/*



# Copy everything to the proper location

foreach i (`ls -cF | grep /` | sed 's/\///'`)

    cd $i

    ( cp -r * $approot/$i ) || ( echo "Error!"; exit )

    # maybe just exiting is a bit harsh...

    cd ..

end



# Copy the preinit.d script

cp M*$appname /etc/preinit.d

# check exit status here, too!



# Clean up

cd ..

rm -rf $1 $appname

Obviously, this presupposes that hda2 has been formatted, mounted, etc, but genixia's script can do that... It's pretty simple, but I think it's all we really need...

Cheers,

Well, /usr/local would be obvious to linux people, at least.

I just noticed that the /etc/profile already has /usr/local/bin in the path...