After much pain, managed to install snv123. Now beadm /does/ segfault when creating a new BE (same pstack). I see the bug name has been changed now and it won't be fixed until next year :-(
As Glenn pointed out, the target milestone is simply which milestone the issue is expected to be fixed by. Most bugs are fixed well before that and I've requested the fix for this be expedited. It's also on the bugs we're tracking as potential stoppers for the release.
Is there any reason why beadm shouldn't be somewhat independent of release much as pkg is so that it can be fixed?
It's a matter of resources - we would definitely do that if required for a milestone build but we're not able to always address these issues in any particular development build.
The odd thing is that despite the segfault, it seems to create a perfectly good BE. Does this mean the segfault can be simply ignored, or is something nasty going to happen under the covers? I guess it really means that an upgrade from snv123 to snv124 will be impossible since it won't get past beadm, and none of my previous BEs can read the zfs rpool because I didn't think to do zpool create -o version=xx rpool <disk>.
What version/build did you initially install your system with?
This is one of the most infuriating and time consuming bugs I have ever encountered in many years of using Solaris. I hope it gets fixed in such a way that it isn't necessary to fall back to an ancient release to do an update...
Another potential work-around would be to boot a build 121 Live CD if this is an x86/x64 system, and then follow the documented work-around after importing the pool. Although I haven't tried that myself, you should be able to use the -e argument to beadm(1M) to clone your build 122 or 123 BE and then use image-update to move it forward. _______________________________________________ indiana-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
