Hi Alex, The fact that you have to install the boot blocks manually on the second disk that you added with zpool attach is a bug! I should have mentioned this bug previously.
If you had used the initial installation method to create a mirrored root pool, the boot blocks would have been applied automatically. I don't think a way exists to discern whether the boot blocks are already applied. I can't comment on why resilvering can't do this step. Cindy Alex Viskovatoff wrote: > Cindy, > > Well, it worked. The system can boot off c4t0d0s0 now. > > But I am still a bit perplexed. Here is how the invocation of installgrub > went: > > a...@diotiima:~# installgrub -m /boot/grub/stage1 /boot/grub/stage2 > /dev/rdsk/c4t0d0s0 > Updating master boot sector destroys existing boot managers (if any). > continue (y/n)?y > stage1 written to partition 0 sector 0 (abs 16065) > stage2 written to partition 0, 267 sectors starting at 50 (abs 16115) > stage1 written to master boot sector > a...@diotima:~# > > So installgrub writes to partition 0. How does one know that those sectors > have not already been used by zfs, in its mirroring of the first drive by > this second drive? And why is writing to partition 0 even necessary? Since > c3t0d0 must contain stage1 and stage2 in its partition 0, wouldn't c4t0d0 > already have stage1 and stage 2 in its partition 0 through the silvering > process? > > I don't find the present disk format/label/partitioning experience > particularly unpleasant (except for grubinstall writing directly into a > partition which belongs to a zpool). I just wish I understood what it > involves. > > Thank you for that link to the System Administration Guide. I just looked at > it again, and it says partition 8 "Contains GRUB boot information". So > partition 8 is the master boot sector and contains GRUB stage1? > > Alex _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
