Hi all,
I did an install of OpenSolaris in which I specified that the whole disk should
be used for the installation. Here is what format verify produces for that
disk:
Part TagFlag Cylinders SizeBlocks
0 rootwm 1 - 60797 465.73GB
Alex,
I think the root cause of your confusion is that the format utility and
disk labels are very unfriendly and confusing.
Partition 2 identifies the whole disk and on x86 systems, space is
needed for boot-related information and is currently stored in
partition 8. Neither of these partitions
On Tue, Jan 06, 2009 at 10:22:20AM -0800, Alex Viskovatoff wrote:
I did an install of OpenSolaris in which I specified that the whole disk
should be used for the installation. Here is what format verify produces
for that disk:
Part TagFlag Cylinders Size
http://docs.sun.com/app/docs/doc/817-5093/disksconcepts-20068?a=view
(To add more confusion, partitions are also referred to as slices.)
Nope, at least not on x86 systems. A partition holds the Solaris part
of the disk, and that part is subdivided into slices. Partitions
are visible to other
On Tue, Jan 06, 2009 at 11:49:27AM -0700, cindy.swearin...@sun.com wrote:
My wish for this year is to boot from EFI-labeled disks so examining
disk labels is mostly unnecessary because ZFS pool components could be
constructed as whole disks, and the unpleasant disk
format/label/partitioning
- Original Message -
From: A Darren Dunham ddun...@taos.com
To: zfs-discuss@opensolaris.org
Sent: Tuesday, January 06, 2009 3:38 PM
Subject: Re: [zfs-discuss] Questions about OS 2008.11 partitioning scheme
On Tue, Jan 06, 2009 at 11:49:27AM -0700, cindy.swearin...@sun.com wrote:
My
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
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
Thanks for clearing that up. That all makes sense.
I was wondering why ZFS doesn't use the whole disk in the standard OpenSolaris
install. That explains it.
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
On Tue, Jan 06, 2009 at 01:24:17PM -0800, Alex Viskovatoff wrote:
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)
Hi Cindy,
I now suspect that the boot blocks are located outside of the space in
partition 0 that actually belongs to the zpool, in which case it is not
necessarily a bug that zpool attach does not write those blocks, IMO. Indeed,
that must be the case, since GRUB needs to get to stage2 in
On Tue, Jan 06, 2009 at 04:10:10PM -0500, JZ wrote:
Hello Darren,
This one, ok, was a validate thought/question --
Darn, I was hoping...
On Solaris, root pools cannot have EFI labels (the boot firmware doesn't
support booting from them).
http://blog.yucas.info/2008/11/26/zfs-boot-solaris/
12 matches
Mail list logo
