Finalmente descubrí lo que era. Después de cancelar el cambio de tamaño original (solo un simple ctrl+C), ejecuté e2fsck -f -y /dev/sdb3 para corregir cualquier problema que hice. Pude montar la partición aún con el tamaño original, por lo que no se perdieron datos. Luego ejecuté resize2fs con el indicador de depuración (resize2fs -d 14 <xxx> ) y me di cuenta de que estaba atascado en un bucle constante al intentar reubicar una parte de los inodos.
Finalmente conseguí que funcionara usando un más viejo versión de e2fsprogs. Puse Ubuntu 9.10 (Karmic Koala) en una memoria USB, la inicié, instalé los controladores rr232x de código abierto para poder manipular la matriz y ejecuté la versión anterior de e2fsprogs (resize2fs 1.41.9 (22 de agosto de 2009) , para ser exactos).
Originalmente probé el resize2fs -p /dev/sdb3 863000000 , y me había dicho que requería ~26 millones de bloques. Así que tomé el tamaño objetivo, lo agregué e hice resize2fs -p /dev/sdb3 1000000000 . 10 minutos después me saludan con el mensaje:
/dev/sdb3 ahora tiene 1000000000 bloques
Ahora supongo que la última pregunta es por qué la versión más nueva de e2fsprogs no podía/no me decía que estaba pidiendo un tamaño demasiado pequeño (y por qué ofrecía un tamaño tan pequeño en primer lugar)?