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...


Edited by pgrzelak (30/05/2003 18:24)
_________________________
Paul Grzelak
200GB with 48MB RAM, Illuminated Buttons and Digital Outputs