On 09/23/09 03:24 AM, [email protected] wrote:
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.
Thanks - that's good to hear!
What version/build did you initially install your system with?
Not sure I even remember any more, but snv111b is the baseline with
the snapshots; note this is on SPARC. Actually snv123 seems OK too,
But trying to boot snv111b results in a panic, presumably because
snv111b can't read zpool version 18 rpools. Having done this several
times now, I now have a snv111b snapshot that is good to go for an
image update, but the cycle is painful and requires uploading GBs
of stuff that would otherwise be unnecessary. And there's always
the possibility that there might not be an upgrade path from such
an old release. Finally, booting from UFS and then rebooting will
trash the boot archive (there's a CR for this); in general this
problem can make going back a few releases problematic unless you
are very careful to unmount zfs rpools before rebooting since even
snv123 will gratuitously update every boot archive it can find,
even if for the wrong architecture.
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.
Alas, there's no live CD for SPARC, although I understand that the AI
CD might be usable as a rescue disk at some point. I guess there's no
way to actually install snv121 now, so it would seem that going back to
snv111b is the only option. Our test machines have plenty of bootable
disks, so setting one or more aside is no big deal, just a big PITA.
Since, despite the segfault, the snv123 beadm does actually create a
bootable BE, could it be used to move forward to snv124 in the documented
workaround? The CR doesn't say what doesn't get set as a result of
the segfault. Maybe I should just wait for the release notes...
IMO, coupling beadm to releases isn't a great idea. It should be
separate, just like pkg itself. Then this wouldn't be a problem...
Should this be a separate RFE?
Thanks again -- Frank
_______________________________________________
indiana-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
