Actually I just thought the same thing, I fixed it with /etc/mount instead, but the result should be the same
I hit a few others bumps on the road.
I have mounted / with write and deleted the pesky usr-link, created /usr and moved /export/usr/* -> /usr.
It is still a bit wobbly, though. After a reboot, it says that it cannot find /usr/sbin/fsck.
Full message (muuuch shorter than before the "fix"):
WARNING - /usr/sbin/fsck not found. Most likely the mount of /usr failed or the /usr filesystem is badly damaged.
Jun 28 18:23:29 svc.startd[7]: svc:/system/filesystem/usr:default: Method "/libsvc/method/fs-usr" failed with exit status 95.
Jun 28 18:23:29 svc.startd[7]: system/filesystem/usr:default failed fatally: transitioned to maintenance (see 'svcs -xv' for details)
Requesting System Maintenance Mode
(See /lib/svc/share/README for more information.)
Console login service(s) cannot run
Now, when I log in, it's clear that there is no such thing as /usr/sbin. I suppose this is less-than-good
However, there are:
-bash-3.00# find / -name sbin
/usr/xpg6/platform/i86pc/sbin
/usr/xpg6/sbin
/usr/xpg6/sfw/sbin
/sbin
Speculation: Could I boot into failsafe and create a /usr/sbin and copy /usr/xpg6/sbin to /usr/sbin? I tried from System Maintenance to create /usr/sbin and then a cp /sbin/* /usr/sbin which failed with:
cp: bpgetfile and /usr/sbin//bpgetfile are identical
cp: cannot access in.mpathd
Addition:
I found that bpgetfile is a link to /usr/sbin/pgetfile and in.mpathd is another link to /usr/lib/iet/in.mpathd. These *could* be discarded at first and investigated later?