On the way home tonight, my friend and I started talking about the facts that we knew and started speculating as to what is really happening. We had eliminated the operating system as the issue by testing it out on both XP and another Vista machine. We came up with a few experiments to run to eliminate the possibility of it being a hardware issue. On the computer that was causing the problem, we mounted it using a live linux CD, then unmounted and confirmed that it was still working. That eliminated the hardware.
With those eliminated, we figured it had to be related to software. Since we were seeing this on a sony machine and a dell machine, it eliminated sony and dell software (what's on one would not likely be on the other). That made 3rd party software suspect. Found that a common program was Norton Internet Security 2009. Tried disabling it, but it still caused the problem. Uninstalled and... it worked! Installed Norton Internet Security 2007 and it continued to work, so it was specific to the 2009 version.
We're speculating that Norton is marking the drive, much like it does when you use Ghost (also by the same company). It could be marking it to trap boot sector viruses, or marking it as a monitored drive. Whatever the reason, it is apparently compatible with Vista, XP, and Gentoo Linux, but not compatible with the NTFS driver on the ScreenPlay Pro.
Response to comments:
Sabi -- per your request:
/ # cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / ext3 ro 0 0
none /dev devfs rw 0 0
none /proc proc rw,nodiratime 0 0
devpts /dev/pts devpts rw 0 0
none /sys sysfs rw 0 0
none /tmp ramfs rw 0 0
/dev/ide/host0/bus0/target0/lun0/part2 /usr/local/etc/dvdplayer ext3 rw 0 0
/dev/ide/host0/bus0/target0/lun0/part4 /usr/local/etc/dvdplayer/hdd/volumes/HDD1
ntfs rw,uid=0,gid=0,fmask=0177,dmask=077,nls=utf8,errors=continue,mft_zone_mult
iplier=1 0 0
/dev/rd/0 /mnt/rd vfat rw,nodiratime,fmask=0022,dmask=0022,codepage=cp437,iochar
set=iso8859-1 0 0
/ # uname -a
Linux Iomega 2.6.12.6-VENUS #29 Wed Sep 10 22:00:48 CST 2008 mips unknown
Hacking devices can/will void your warranty and can turn your expensive consumer electronics into worthless trash if you don't know what you're doing. This blog is for information purposes only, and if you try to hack into your own consumer electronics, you do so at your own risk. The device I'm currently hacking is the Canon SX10 IS camera.
Friday, January 2, 2009
Subscribe to:
Post Comments (Atom)
It's the kernel NTFS driver which can explain the reliability problems ...
ReplyDeleteThe Norton Internet Security 2009 related discovery was very interesting. Nice job! Here is how you could figure out more details, if interested.
Install ntfsprogs and save the NTFS image on Linux:
ntfsclone -o orig.img /dev/iomega
attach/detach drive to the PC
attach to Linux again
ntfscmp orig.img /dev/iomega
This will tell exactly what files/attributes were changed (bootsector, etc). Then you can compare them with diff or a hexeditor.
You can mount both the image and the drive with NTFS-3G using the show_sys_files mount option which will show the metadata files too (bootsector, etc). Probably the bootsector checksum is the problem. This would also suggest that they are using an, old kernel NTFS driver.
Just seen these scary kernel NTFS driver error messages at
ReplyDeletehttp://rtd1261.wikidot.com/forum/t-112999/iomega-screenplay-pro#post-347115
Yes, it **is** the old Linux NTFS kernel driver. Directory corruption, file data location corruption then kernel crash. Woow! :-(
I wonder why they didn't use the free, stable and widely adopted NTFS-3G driver? They even have a version optimized for consumer electronics devices.