When connecting a partition formatted with ext3, and possibly other formats that aren't ext2, vfat, or ntfs, the firmware might end up deleting the entire contents of the partition!

I experienced this after I disabled the 'autoinit' on my Debian partition and rebooted into the firmware. I telnetted in, and a little while later noticed that the hard disk was rather busy, so I did a 'ps x', and to my horror saw a 'rm -rf /mnt/USB/USB_D'. I killed it as quickly as I could, but it had already deleted the copy of my music collection I had on that ext3-formatted data partition.

It looks like the bug is in /bin/hotplug.sh. It first tries to mount a partition as ext2, then as vfat, then as ntfs, and if it fails it just 'rm -rf's the whole directory it tried to mount it to! Presumably the ext3 partition actually was mounted as ext2, but for some reason it still fell through the test for that.

I also noticed that both partitions on the disk were mounted multiple times. Could that be the problem? Pagano, could the mount attempts in the init script have something to do with this?

Unfortunately I'm not sure how many times the partitions were mounted, but I think it was three. I'm rather reluctant now to try it again, so I reactivated 'autoinit' to bypass the firmware and boot into Debian at the earliest possibility. (This works a treat btw, thanks again!)

Also converted the ext3 partition back to ext2, in case that was the problem. Then again, ext3 is fully backwards compatible with ext2, isn't it? Which could mean that ext2 partitions are at risk too.

The setup was no internal disk, a USB hard disk with an ext2, a swap, and an ext3 partition, and a Topfield PVR. No autoexec or autoinit on the disk. Perhaps the problem occurred when hotplug.sh was invoked for the PVR?

Could the bug be fixed by replacing 'rm -rf' with 'rmdir', since that doesn't recurse into non-empty directories?