Hi,

I'll give it a try tonight.

Thanks!

Ross

Mmm.. I've thought about it some more, and it will not work for you as a standalone script -- it still needs to have the filesystems formatted and the like.

So I'll spin a builder image that incorporates it. Later today.

Cheers

Okay, you can get builder_bigdisk_v4.upgrade from my web server at
h t t p : / / r t r . c a / bigdisk /

This is totally untested, but might work..

I've now added a FORCE argument to the builder script.

Cheers

Hi,

The new Builder.v4 is installed.

It came up with the Drives Already Built message and wouldn't build the filesystem until I deleted the fids and var directories.

It looked like it worked correctly, including the new swap modifications. I then installed the car2_v2.01_hijack on it.

Emplode saw it and it had the correct capacity (233GB) which decremented with playlist entries.

It is currently loading 20GB of songs over USB.

I'll let you know how it works out.

Thanks,

Ross

Yeah, I've got to add a front-panel prompter for that situation.

Meanwhile, though, one can connect over serial, and force it to run with this:

exec /sbin/init FORCE

Cheers

If you can get the ethernet working, it is noticeably faster than the USB for everything, including uploads.

Cheers

One issue I had while preparing this, was that the initial partitioning is still done by the firmware (?) prior to the /sbin/init script being run -- where we then want to redo the partitioning.

This is not a big problem, because we leave the root filesystem in the exact same place/size in the new partitioning scheme, so programs don't suddenly crash when we do that.

But the kernel doesn't normally allow use of the modified /dev/hda partition table until after a reboot (some of my own ancient code). So the v4 builder image includes a new prerelease Hijack kernel that gets rid of that restriction / safety-valve.

Problem solved. Ain't source code wonderful?

Cheers

Ross, could you check whether or not it still has 64MB swap space now? (and 32MB dynamic data, as well..).

Eg. When you can, just do cat /proc/partitions from the serial port, and post the results here.

I'm trying to figure out how the firmware decides to write a partition table or not. Both the builder and v2.01 .upgrade files include "partition drive" chunks (directives to the firmware), but I haven't yet puzzled out what the firmware does in reaction to those.

Thanks.

This is /linuxrc in the initrd.

By "pressing Ctrl-A" (i.e. sending \x01 down the serial port) the upgrader stops /linuxrc from mounting the disk-based root partition on / and exiting to {/dev/hda5}/sbin/init -- and, instead, causes it to enter "upgrader mode", where the commands available include partitioning a drive, and filling a partition from a gzipped filesystem image down the serial port.

Peter

Yeah, I see the ext2 initrd (aka. "ramdisk") image in flash (/proc/flash_b0000), but it's mostly just one big closed-source executable.

What I don't know (for sure), is exactly what it does when the .upgrader encounters a "DRIVE" chunk, which seems to mean "create a partition table", sometimes.

Where is the decision made as to whether or not to overwrite the on-disk partition table with a new one? Does the Windows-based upgrader decide, or does linuxrc on the initrd decide?

I'm just wondering if an altered swap/spare/dyndata partition is reverted when a v2.01 or v3a11 software .upgrade file is applied over top of the built disk.

Because all of the .upgrade files seem to include the "DRIVE" chunk for hda, not just the builder .upgrade.

EDIT: What I call a "DRIVE hda" chunk, is a type 0x20 chunk inside the .upgrade file.

Cheers

Are you dead sure it's "sometimes" and not "always"?


This was all done before I even started at Empeg, but I expect that all stock upgrade files unconditionally repartition the first drive. That would mean that as long as we didn't move the music partition, we could in theory have fiddled with the other sizes from version to version. We never did change anything, though.

I still think that if the goal is to get more swap on Hijacked players, the easiest thing to do would be mkswap /dev/hda2 (or hdb6), and suborn sys_swapon and sys_swapoff to additionally do their thing on the second swap-partition whenever invoked for /dev/hda6. IMO you really don't want to create a population of players incompatible with stock upgrade files.

Peter

That's no big deal. We've already got respun .upgrades for 2.01 and v3a11, and with those nobody really needs the originals.

But I do want to be able to increase the swap partition and have it stay that way. This may require replacing the ramdisk (initrd) image, I suppose, with something more open source that we can hack.

But first we need to figure out what it does, and what it does not do.

Cheers

Mmmm.. since it is running Linux at that point, I suppose I can simply have the Hijack kernel disallow overwriting a valid empeg partition table from the linuxrc script.

Then we could leave the initrd alone, and just continue to customize things in the init script instead.

Mmm..

..Or just remove the repartition chunk (type 0x20) from the respun .upgrade files completely. Yeah, that's probably better to do.

Then those respun files will be compatible with empegs built with any builder, rather than being locked to the default factory build scheme (which we've now outgrown).

And should someone accidently install a factory software load by mistake, it will destroy the partition table, and then not be able to find the music partition. We could provide a special builder image to restore things, or just make the stock bigdisk_builder clever enough to handle that.

Mmm... Gotta poke at it to see how it really works now..

Cheers

I respectfully disagree. I'm on Peter's side here. Mark, if your respun upgrades will create players whose music partitions will get hosed by rolling back to a stock upgrade, then there should be gigantic blinking red warning letters all over them.

I understand the need to move forward instead of backward, and I know that altering the partition table can offer important advantages. But so far, you've managed to make a lot of wonderful new things possible for our players without breaking backward compatibility with the stock files. It would be nice if that trend could continue.

Never mind. I just tested it here, and discovered that it fails -- it never creates the 64MB swap at all.

The fdisk program was missing from the builder image, and the copy of /bin/bash on the builder is different from the copy used on the developer software images -- missing features that I used in the new script.

I'll fix both of those, and put up a V5 shortly at the same place, but it may yet need more work to force the later software .upgrade files to not destroy what it does.

Cheers

Hi,

I guess I was wrong about the swap size. This is the results of the cat after loading the 20 GB.


empeg:/empeg/bin# cat /proc/partitions
major minor #blocks name

3 0 244198584 hda
3 1 1 hda1
3 2 40162 hda2
3 3 24097 hda3
3 4 244091610 hda4
3 5 24034 hda5
3 6 16033 hda6
empeg:/empeg/bin#


On a positive note, it did complete the sync and successfully loaded the 20GB of songs.

I'll try the new build when its available.


As far as the ethernet, that's the next project...

Thanks,

Ross

Okay, there's a V5 builder there now, and a V5 of v3alpha11 to apply afterwards. This combo works for me.

I don't have a v2.01 there yet.

Cheers

Okay, 2.01_v3 is there now too.

Cheers

Hi,

I'll check them out!

Thanks,

Ross

Hi,

This is what I got with the new v5 build....

Done!
+ echo 'POPUP 999show_message("Done!")
9 Done!'
+ exec /bin/bash --login
bash-2.03# cat /proc/partitions
major minor #blocks name

3 0 244198584 hda
3 1 1 hda1
3 2 40162 hda2
3 3 40162 hda3
3 4 244027350 hda4
3 5 24034 hda5
3 6 64228 hda6
bash-2.03#

Is this correct?

I will install the new v5 player hijack now.

Thanks,

Ross

Hi,

This is what I get with the v5 builder and the v5 player software installed:

empeg:/empeg/bin# cat /proc/partitions
major minor #blocks name

3 0 244198584 hda
3 1 1 hda1
3 2 40162 hda2
3 3 40162 hda3
3 4 244027350 hda4
3 5 24034 hda5
3 6 16033 hda6
empeg:/empeg/bin#


and


empeg:/# cd drive0
empeg:/drive0# ls -la
total 16
drwxr-xr-x 5 0 0 1024 Feb 29 00:36 .
drwxr-xr-x 15 502 220 1024 Apr 9 2008 ..
drwxr-xr-x 2 0 0 1024 Feb 29 00:36 fids
drwxr-xr-x 2 0 0 12288 Feb 29 00:32 lost+found
drwxr-xr-x 2 0 0 1024 Feb 29 00:36 var
empeg:/drive0#


If this looks good, I will load 20 GB of songs on it tonight.

Thanks for all of the hard work!

Ross

That looks correct, but..


... but not that. And it should not have been possible to get that, either. I wonder what I did wrong there?

EDIT: You didn't happen to reinstall Hijack in between the builder and the software installer, did you.. a no-no with the new layout.

Hi,

No, I used the procedure that you gave to a recent poster to cause a rebuild to occur:


rwm

rm -r /drive0/fids

rom


Then I executed the v5 builder, after it completed, I sent the previous message.

I then executed the v5 hijack. After it completed, I sent the second message.

I did notice one thing during the build. While writing inodes, with the previous builders, the inode total was 29797. The last v5 builder had a total of 29798.

It looks like the player hijack reset the swap space again.

Thanks,

Ross

Yeah, that had to be what went on.

With the new V5 scheme, I've updated the Hijack kernel in all of the V5 files, so you should not overwrite it by installing a previous version in between.

Doing so resulted in the swap space being reduced back down to 16MB from 64MB. Not harmful, but it means that things will crash later (insufficient swap) once the drive is filled up a bit.

You may have been mislead by the original labelling on the files -- I've now updated the index file on my site to indicate that all of the V5 stuff now has hijack v488+ incorporated.

Cheers

Hi,

I just re-checked the partition tables again and they are the same as I reported earlier (16M swap).

I also verifed that I used the correct files from your website. BTW, I like the way you re-arranged them.

Thanks,

Ross

Mmm.. okay, I must have been too gentle in my kernel hack to prevent this issue on your specific drives.

V6 is now available, and uses a larger hammer in that code. Untested here (not that it matters, it seems), but I have a good feeling about it.

Cheers

Hi,

I'll check it out.

Thanks,

Ross

Hi,

I used the same process as I described in the previous email.

This is what I got with the v6 builder....


bash-2.03# cat /proc/partitions
major minor #blocks name

3 0 244198584 hda
3 1 1 hda1
3 2 40162 hda2
3 3 40162 hda3
3 4 244027350 hda4
3 5 24034 hda5
3 6 64228 hda6
bash-2.03#


...... This looks correct ......


This is what I got with the v6 Player Software afterwards....


empeg:/empeg/bin# cat /proc/partitions
major minor #blocks name

3 0 244198584 hda
3 1 1 hda1
3 2 40162 hda2
3 3 40162 hda3
3 4 244027350 hda4
3 5 24034 hda5
3 6 16033 hda6
empeg:/empeg/bin#


...... Looks like the same thing happened again. What am I doing wrong? ......

Do I need to install the FIDS patch that you mention on your website before I install the player software? This shouldn't affect the swap partition should it?


BTW, Its nice to have the player display messages to see what is going on during the installs. What is the "prevented 48258" message?


Thanks,

Ross