Greetings!

I commented over here that I have seen something reproducable. When using the builder to wipe and rebuild a used disk, there appears to be some problem with building the hard drive.

I have been able to reproduce it again, and I have the logs here...

All tests were done with emplode 2.0 on a Windows 2000 box. All syncs and builds were performed over the serial port to the player in Mark's docking station. The player has a plug (trimmed from a dead power supply) in it, so it will attempt to flash at boot.

First, I start with a fully functional 20GB player.

I apply the 2001/10/22 builder for the Mark2. The upgrade succeeds without any error on screen. After the upgrade finishes, I yank the power to the unit, so I can hook up hyperterminal.

The build boot appears fine during the self check. You get the normal "drive already built" message:

Trying to unmount old root ... okay
Freeing unused kernel memory: 4k initDrive(s) appear to be already built. Skipping.
Press return to continue anyway - anything else to start a shell.

As expected, it will build...

warning: can't open /etc/mtab: No such file or directory
Making first drive...
mke2fs 1.14, 9-Jan-1999 for EXT2 FS 0.5b, 95/08/09
ext2fs_check_if_mount: No such file or directory while determining whether /dev/
hda4 is mounted.
Linux ext2 filesystem format
Filesystem label=
152000 inodes, 19451880 blocks
0 blocks (0.00%) reserved for the super user
First data block=1
Block size=1024 (log=0)
Fragment size=1024 (log=0)
2375 block groups
8192 blocks per group, 8192 fragments per group
64 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409, 663553,
1024001, 1990657, 2809857, 5120001, 5971969, 17915905,

Writing inode tables: done
Writing superblocks and filesystem accounting information: done

real 1m1.951s
user 0m0.350s
sys 0m3.580s

UNTIL...

(not really repeated, but just listed again to show where it happens)
real 1m1.951s
user 0m0.350s
sys 0m3.580s
set_blocksize: b_count 1, dev ide0(3,4), block 1!
EXT2-fs error (device ide0(3,4)): ext2_check_descriptors: Block bitmap for group
64 not in group (block 3)!
EXT2-fs: group descriptors corrupted !
mount: wrong fs type, bad option, bad superblock on /dev/hda4,
or too many mounted file systems
hdstress.cpp 189 ( 19): Poll result=1 on fd=5
hdstress.cpp 194 ( 19): Read a button press
hdstress.cpp 194 ( 19): Read a button press

You get this error. After that error occurs, it goes into the stress test.

Now, at this point, you are in a quasi-built state. The root drive is built, but the music partition is not. You can successfully load the player 2.0 developer image, and even load hijack without any errors. Afterward, you can boot the player without error to a blank playlist and use the player app / menus. If you attempt to perform a sync with emplode here (and it will find the player), emplode will crash and exit at, or immediately after, the checking media option.

If you were to boot with hyperterminal now, you would see:

Partition check:
hda: hda1 < hda5 hda6 > hda2 hda3 hda4
RAMDISK: ext2 filesystem found at block 0
RAMDISK: Loading 320 blocks [1 disk] into ram disk... done.
VFS: Mounted root (ext2 filesystem).
empeg-pump v0.03 (19980601)
Press Ctrl-A to enter pump...hange_root: old root has d_count=1
Trying to unmount old root ... okay
Freeing unused kernel memory: 4k initEXT2-fs error (device ide0(3,4)): ext2_chec
k_descriptors: Block bitmap for group 64 not in group (block 3)!
EXT2-fs: group descriptors corrupted !
mount: wrong fs type, bad option, bad superblock on /dev/hda4,
or too many mounted file systems
warning: can't open /etc/mtab: No such file or directory
umount: /drive0: not mounted

(Note: this boot log was taken with the builder kernel, but it should not matter.)

At this stage, there is nothing the user can do except to rebuild the drive again. It might be possible to recover with FSCK, but why bother at this point. When you rebuild, you will see the errors above, and the builder will continue through the build correctly. It will not detect the previous (unsuccessful) build, and will process the drive as if it were new from the box / packet.

After this second, successful build completes, you can use the player as normal.

Now, I suspect that there may be something in the builder code that is finding the existing partitions, but is having trouble cleaning / recreating them. I have been able to reproduce this on drives ranging from 6GB to 80GB, inside the docking station and with normal use.

Just curious to see if anyone else has seen this before...

*bump*

I was hoping someone else had seen similar behavior. Just curious.

I'm sure you're not the only one. But I think you're the only one who did detailed diagnosis of the problem and actually found out where the problem was. If I'd been the one to run into this problem, I would have just tried the builder a second time, written it off to FM, and forgotten about it. I'm sure there are a few "help, can't get drive upgrade to work" posts on the BBS that were caused by this problem, we just didn't know it at the time.

Greetings!

I had to build a lot of disks, for various reasons, and it seemed to be repeatable. Thought I would mention it, and give the information in case another version of the disk builder (with swap support for the MarkI) would be compiled / release...

So let's see. So far, the builder image needs the following bug fixes...

- Support for larger-than-127gb disks.

- This rebuild bug fixed.

- Enabling swap at certain times so that a low-RAM player like a Mk1 can do a proper build on a large disk.

Anything else? I'm hoping that they can release a new builder image along with the 3.0 public beta.

Well, it would be nice if you could also use the buttons / knob to confirm a rebuild of the drive instead of having to flash the player, swap to hyperterminal and connect in to hit <enter> to confirm the rebuild... But that isn't really a bug...

Mmm.. this is all so easy to do inside Hijack.. Mmm...

Greetings!

True, but at this point, you have the builder kernel loaded on the machine, so hijack would not apply...

My guess would be to look out for a builder version of Hijack, or a new menu item on the Hijack menu that says 'build disks'.

My feeling is it may be the latter,and it will even have an option so you can pick which drive to build

Who needs a builder kernel, anyway?

I suppose if I added a few lines to Hijack to have it set up the partition table and run mke2fs to create the filesystems, then building a disk would take perhaps 20-40 seconds total. One could then just follow-up with the .upgrade file after that -- either the slow "old" way, or the fast ethernet way under Linux / Knoppix.

Mmm.. but I suppose I'd have to also figure out what to do with the "special" partitions.. I wonder if just zeroing them out would be enough? Mmm...

Ahh.. now there's a gotcha! The mke2fs command is not available on a fresh disk.. perhaps a "builder" Hijack kernel could include a copy, or maybe I can find a way to store it where it wouldn't normally take up any memory on a working player..

Really though, it's not a good use of the kernel - building a disk is a specialist task, only generally used after you've actually taken the player apart to fit a new disk. Having it as a separate upgrade file isn't exactly a hardship.

Other products (eg, Rio Central) have much better builders, with UIs and so on, which were created after the carplayer builder - which is just a shellscript and a disk excercising program. Maybe we could get one of the later builders running for v3.

Hugo

>it's not a good use of the kernel

True, but it's by far the easiest place for us to do things -- doesn't require a sluggish serial link or finicky download programs, and anyone doing drive upgrades probably already knows how to load a hijack kernel, or already has one loaded and so can just click on "Upgrade Hijack" in JEmplode.

And with the current builder broken (doesn't work for 80GB drives on Mk1, and possibly Mk2 players(?)), we're just kicking the can thinking about alternatives.

A nice v3.0 beta with a modern builder would be a good alternative! But then, it's probably a Windows-centric GUI again, so that doesn't help a lot of us with Linux, MacOS, etc.. Unless you folks have discovered Java in the interim (?)

Cheers

I don't like the idea of having disk builder in the software I run all the time, as accidents do occasionally happen (particularly if you have children - or worse, students). OTOH, a specialised kernel with the builder preloaded into RAM disk or something does make sense, if the builder kernel has /proc/empeg_kernel so that it can be overwritten with an everyday player kernel when it's done.

That's kinda what I'm leaning towards -- just a special big/fat Hijack with all the usual goodies plus built-in builder capability (likely a flashdisk image), that can be loaded when needed, and replaced with a stock Hijack when no longer needed.

Just musing at this point..

There are other products which run protocol2 and have java content management apps that are not far from shipping...

The builder wouldn't be anything-centric, apart from the empeg.

Hugo

Hello,

I was since yesterday with Paul via PM in contact, concerning fitting in a 80 GB Hitachi Travelstar HDD into my MK2 device. I was spending a cupple of hours to get this new BIG HDD working. We decide, to let you know about my troubles and how I got it finally work.

I did try different ways to get it work, but only one way was successfully.

As I did explain above, I did try to install with the latest builder a 80 GB Hitachi Traverstar on my MK2. I did try as a primary HDD, as a secondary HDD without success. Then I did check on my Windows XP with a disk format, If the HDD works or if it's a DOA. It was working.

After all that and a cupple more builder executions, I did open my Backup MK2a and was letting the builder run on this device. This was working at the first run.

After that, I did put the HDD back on my MK2 and now it works also in this device.

It's really strange.....So I do not recommand an 80 GB drive for an MK2 owner, who has no Mk2a backup device.....

Thanks to Paul for helping me on that issue.

bye