You're changed your filesystem mount options to "data=journal" to lower the chances of a data loss in case of a system crash.

On reboot you find out the system won't come up.

Begin: Running /scripts/init-bottom ... done.
[    1.724403] EXT3-fs (xvda): error: cannot change data mode on remount. The filesystem is mounted in data=ordered mode and you try to remount it in data=journal mode.
[    1.754372] Adding 204796k swap on /dev/xvdb.  Priority:-1 extents:1 across:204796k SS
mount: / not mounted already, or bad option

To fix this you really have to access your filesystem while it's not mounted. In case of a VPS do it from the host, otherwise from a PXE boot emergency kernel or LiveCD.

Once there, issue the following command on the filesystem:

tune2fs -ojournal_data /dev/vgname/lvname

On the next boot you can find the new mount option in /proc/mounts

/dev/xvda / ext3 rw,relatime,errors=remount-ro,barrier=0,data=journal 0 0

Technical stuff:

What happens there is that Ubuntu initially used mode "ro" and then uses "remount" to switch the filesystem to read-write mode. Since the filesystem is already mounted, the "default journaling options" are already active - and they're set to data=ordered.
It is no longer possible to switch the filesystem journaling to data=journal since the filesystem doesn't allow to change the journal mode on the fly.
This looks perfectly sensible when switching between different RW modes, whereas when switching from RO to RW (that means: with a "cold" journal, that might have been replayed but definitely NOT written) this is nothing more than a design fuckup combined with an educative error message.

And one more:

I saw some references that you could set the root mount mode at the grub cmdline, at least in earlier Ubuntu releases

Your grub kernel line would read something likeĀ ?... ro root-mount-opts=writeback ...