This wish is simple. When the 2.0 Final upgrade is released, I'd like it to make a /usr partition which points to /dev/hda2. If it doesn't already contain a valid filesystem, mkfs it. Future upgrade files should then leave this partition intact.

This would give us a directory that we can almost guarantee new users will have on their Empeg for 3rd party app installs. Similar to Windoze's "Program Files" directory but less annoying to type out. We could then install our apps to /usr/local and have them safe from future upgrades wiping them out.

Does this sound good?

i like it and dsont sound too hard either..

Now this is a good wish. I wonder how fast we can fill it?

What's wrong with creating a subdirectory under Drive0/Var for the purpose of installing user apps?

This way, it would not get erased with an .upgrade.

If the 2.0 final creates a new partition, then the partition would be erased with each upgrade and all the user-apps would have to be reinstalled every time somone .upgrades. I'd much rather see user apps go on the same partition as the music files and the config.ini. Not only would re-installing no longer be necessary, but you would also gain a lot of disk space for your apps.

What's wrong with creating a subdirectory under Drive0/Var for the purpose of installing user apps?

Potential problems:

1. /drive0/var is also where your config.ini and other Important Things (tm) live. One very human mistake in an install script or even in an installer's own code and that stuff could get torched. Not a good thing.
2. Music partitions can approach 100% capacity as new tunes are added. The reserved /dev/hda2 partition (which is currently there on *everyone's Empeg* and is not used for anything normally) would be isolated from such things.
3. Isolating the user apps to their own drive is also a good thing as people start to experiment with various ways of having read-write access to write GPS logs, ODB-2 logs, or whatever other kind of info.

Oh, and user apps were what this partition was set aside for in the first place (according to Hugo). That alone is enough for me to say let's put it to good use.

If the 2.0 final creates a new partition, then the partition would be erased with each upgrade and all the user-apps would have to be reinstalled every time somone .upgrades

That's exactly what I said it would *not* do if this were implemented the way I'm asking. My request is that the upgrade file and upgrade tool work in such a way that if the partition doesn't already exist, it gets mkfs'ed (formatted) and mounted to /usr. If it does exist, it's left alone. The upgrade files clearly already have some mechanism for doing certain things to the partitions and pumping various contents onto them, I can't imagine this is that much of a big deal?

hi.

The upgrade mechanism has no means to check wether a specific partition is already formated. It only knows how to overwrite a partition completely (by means of a partition image). The music partition is initialized using a slightly different approach in that it first installs a special partition image on the software partition, which formats the music partition on next boot, after which the software partititon gets overwritten again (at least if I understood the .upgrade file format and the upgclient code correctly). But even this mechanism does not provide any means to format a partition only if it isn't already formated.

cu,
sven

Thanks for filling in the technical details, Sven. In that case I guess the upgrade mechanism (the upgrade tool and the format of the .upgrade files, I guess) might have to be changed to accomodate this request. Whatever it takes, I think setting up a /usr partition which is preserved between upgrades would be of great benefit. We can all do it ourselves but the key is a having *standard* which we could pretty much be guaranteed that users have. Otherwise install scripts and installers themselves become much more complicated, methinks.

I hope this will at least be considered for the future.

Hi.

I really think building a special .upgrade file to create and initialize hda2 is a better solution. Probably along with a modified kernel to boot from that partition. An alternative to a modified kernel is a modification of /dev/hda4(? the player partition), either by us, or by the empeg team. That modification check if hda2 is formated, and if so, mounts it (to /opt for example) and starts a specific program there (e.g. /opt/bin/init).
However, I am still looking at the first variant (a modified kernel plus hda2 as the new root partition). This requires reimplementation of the empeg supplied init program though, if my findings are correct.
I would then supply a kernel (alternatively as a .upgrade file that only updates the kernel) and a hda2 initializer. The way I would implement that environment, it would create a (e.g.) 64MB file on hda5, if it isn't already existing and mounts it as a loop back device. After that, hda2 could be updated with newer versions of the base environment (by means of a .upgrade file) without replacing user installed programs (which are installed in the loop back'ed filesystem). After updates of the empeg supplied software (which usually replaces the kernel), only the kernel needs to be re-installed.
This isn't really well thought out yet, but I don't have much time these days to look into hobby projects like this.

cu,
sven

Hi.

I just had a look at the .upgrade file for 2.0beta11. And if I understand that correctly, the following happens upon boot:

1. The BIOS (or whatever) of the player loads the Linux kernel from flash.
2. The kernel get's started and lots its initial root partition from a different area of flash. The file linuxrc from the root directory of the flash disk is run.
3. the linuxrc is responsible for the pumping of disk partitions and the remounting of the root device (this time from /dev/hda5 or whatever the real root disk should be).
4. the /sbin/init program from the disk partition is run, which really gets the player going.
   

Could someone from empeg verify that this analysis is true?
Especially the part about the flashdisk and the linuxrc contained therein is important to me. I am thinking about modifying the flashdisk and would like to know if I am right about its purpose (which would effectively forbid doing the thing I want to do). Also: How large could the flashdisk be at max?

cu,
sven

I'm not an empeg guy, but...

The flashdisk is rather limited, Mark Lord is scavenging bytes for Hijack use. I had to plead a good case to get the use of 12 bits of flash for tone controls.

I know it must be limited, I just would like to know how limited it is, and if I recognized the purpose of the linuxrc therein.

cu,
sven

Hi.

Never mind, I just realized it must be at it's maximum size alread: 320k.
At least the flash disk starts at 0xb0000 and with 320k size, it ends at 0xfffff, which is most probably the end of the flash memory area (1MB, right?).

cu,
sven