In the case of the /etc/fstab if it's a file system required to boot it will bork
I don't mind it borking. But the system offered me the choice of "continue". When I took that choice, the system returned to the SAME bork. I would have preferred it if "continue" had meant "skip this".
You mentioned you'd already created a ticket for this, do you have the number of the ticket?
I wrote ticket # 11719 for a different problem - which appears to exist in all XO-1 12.1.0 builds (I believe I saw it before os3; it definitely exists in os5 and os6). [Whereas the "no device for the XO-1 SD card (beneath the display) problem only showed up with XO-1 build os6.]
Ticket # 11719 says that for XO-1 12.1.0 builds, nothing exists in the /dev tree which can be used in a 'mount' command to access the files which OFW uses to boot the XO-1. [These files exist in a separate partition on NAND; when things work correctly that partition gets mounted onto /bootpart -- then those files can be accessed/manipulated (e.g., via manual commands) from the running XO-1 system.]
My own interest is in customizing the olpc.fth file that OFW uses when it boots the XO-1. But the same problem arises if the user performs 'yum upgrade kernel' (assuming that a newer kernel version has been placed in the olpc-f17-xo1 repo). With the # 11719 problem present in XO-1 12.1.0, the output of the 'yum upgrade' (which got placed into /boot) CAN'T be copied onto /bootpart (because there is no filesystem mounted on /bootpart). The result is that the XO-1 12.1.0 system ignores attempts to upgrade its boot process, and continues to use those "boot files" which were created when the XO-1 12.1.0 build was originally compiled.
mikus
p.s. Please let me repeat:
It is not clear to me what the "we need detailed reports" are that would allow you to discover whether such a problem exists on the XO-1 you use.