The only correct solution is to reinstall and restore from a backup. You say you don't have a backup, but the point here is that the idea behind forcing InnoDB recovery is that you can potentially get the server stable enough that you can make a backup. Then use it to restore on a fresh setup.
Obviously, make a copy of all the files before doing anything.
Unless there's a memo I didn't get, you don't want to try increasing the log sequence number to pacify InnoDB, because even if you manage to do it, you've still got a server with data corruption in unknown places -- fix the LSN and all you've really accomplished is made InnoDB unaware of the corruption. Forcing the LSN is pretty much a fool's errand.
Have you tried anything from...
The different levels, 1 through 6, cumulatively disable parts of InnoDB with the idea that if you disable enough functionality you might be able to get a successful
mysqldump or at least
SELECT ... INTO OUTFILE from the tables.
The idea is to use the lowest number that allows you to successfully dump your data, but if this error is occurring at startup like I think it may be, you might just want to go ahead and start with 6. If the server starts up, then try selecting from tables. It may crash again and if it does, then write that table off for the moment and move to the next table.
Once you've retrieved the data from the tables that aren't corrupt, you may be able to go back to the ones that don't work, and try to retrieve the data in small chucks with
SELECT ... LIMIT ... OFFSET.
Take a look at my answer to this similar question for some additional ideas.
You may also want to look at Percona's InnoDB data recovery tool as a potential resource, though I've never (fingers crossed) been caught without a backup or a running replication slave, so I've never needed it.