I fiddled with this briefly in a VM. My initial thought was to nuke the partition's primary superblock. Doing so does not cause dumpe2fs to report a "filesystem state" of "error" but it does (obviously) break your partition ("Bad magic number in super-block") ... so maybe that's all you need for your testing. Running fsck against a partition in this state and inspecting the value of $?
will report a status of 8 (operational error).
Anyway, this is dangerous and I would not advise doing it on any system where you have data you care about. Try it in a VM like I did.
You can get some information about the file system like this:
dumpe2fs /dev/sda1 | egrep "state|superblock|Block size"
You will see that the filesystem has a primary superblock, and some number of backup superblocks. If you are prepared to break things, take note of a few things in that output:
- "Block size: X": take note of X
- "Primary superblock at Y": take note Y
- "Backup superblock at Z": take note of at least one Z
Now destroy your primary superblock:
dd if=/dev/zero of=/dev/sda1 bs=X count=1 seek=Y
Congratulations! Your filesystem is now broken.
Unmount it if it is mounted:
umount /dev/sda1
Then run fsck specifying the location of one of the backup superblocks noted earlier:
fsck -b Z /dev/sda1
Now mount /dev/sda1 somewhere, and you should be back in business.