I don't believe this behaviour is a bug in itself:
Frank Middleton wrote:
However, if you boot snv103 and then reboot, it will
also update the snv122 boot archive, rendering snv122 unbootable.
All versions up to snv122 exhibit this behavior.
I'm not sure why updating the boot archive would do this, but surely
this is a bug. Reboot should only update it's own archive, and not
any ZFS archives at all if it is running from UFS. Before submitting
a bug report, I thought I'd check here to see if a) if this is has
already been reported, and b) if I have the terminology right.
There is a private (i.e. undocumented) flag to bootadm which is called
at reboot time (and init 6, etc...). This flag causes bootadm to update
the archive on all *mounted* boot environments. I believe the normal
case for this is something like mounting up a "broken" BE, fixing it,
then rebooting. If still mounted at reboot time, then the archive will
be checked and resynced if necessary.
I too had been surprised to see something like "Creating boot_archive
for /mnt" when rebooting in the past, and I queried it. Above is the
answer I got (paraphrased).
I'm not sure what the logic is, but I suspect it starts with the
/etc/mnttab to search for candidate filesystems which might contain
alternate BEs. Thus in your case, I would guess that the x86 image is
rooted at a filesystem mount point? If so, bootadm will try and update
the archive on reboot.
I believe the underlying premise is that the boot-archive should never
be out of sync with the filesystem it refers to, so reboot and friends
will try to resync this during shutdown, even if it is not the current
BE (after all, it could be the BE you are about to boot, so the archive
better be up to date!).
What I'd suggest is that you add details of the corruption to your bug
(http://defect.opensolaris.org/bz/show_bug.cgi?id=11358). Things like:
What messages you see during shutdown
What state the boot archive is left in (i.e. is it 0-length,
null-filled file, etc...)
What happens if you take a copy, manually unpack it and mount it?
(use lofiadm + "mount -oro -Fufs" or possibly "-Fhsfs").
What are the contents of the archive if mounted as above?
What's not clear to me is why trashing an x86 boot archive on a SPARC
server is a problem? The SPARC system should never try to boot from it,
so why is this an issue in the first place?
Regards,
Brian
--
Brian Ruthven
Solaris Revenue Product Engineering
Sun Microsystems UK
Sparc House, Guillemont Park, Camberley, GU17 9QG
_______________________________________________
indiana-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
