Hi Jason,
Jason Zhao wrote: > Hi, Jan and William, > > Some questions here, very appreciate if you can answer them. > 1. Does EFI label slice include "*flag*" and "*tag*"? Because libtd > shows nothing about these 2 attributes after I modify the slice > table. However, prtvtoc command could print the tag and flags out. > Is this a bug? Thank you for pointing this out. Looking at the libdiskmgt specification, it is not a bug, but expected behavior: [...] * For slice descriptors the attributes are: * index: uint32 * devt: uint64 * start (block): uint64 * size (blocks): uint64 * * optional attributes * only on slices that have a device ID * deviceid: string * only on slices on media with a VTOC label * tag: uint32 * flag: uint32 * only on slices on media with an EFI label * name: string * efi boolean * only on slices that are mounted * mountpoint: string * only on slices that are on drives shared in a cluster * localname: string [...] Full specification can be obtained here (available only internally): http://sac.sfbay.sun.com/Archives/CaseLog/arc/LSARC/2004/743/spec.txt Since at time of being, EFI labeled disk are not supported as target for the installation, we haven't evaluated yet if this limitation needs to be addressed. This is something we will need to take into account once installation on EFI labeled disks becomes requirement. > As following output. > # test_td -s all -v > > Slice discovery for all disks > ----------------------------------------------------------------- > num | name| idx| flg| tag| 1st block|#of blocks|size [MB]| > ----------------------------------------------------------------- > 1 | c0t0d0s2| 2| 00| 05| 0| 143349312| 69994| > 2 | c0t0d0s0| 0| 00| 02| 0| 143349312| 69994| > 3 | c0t1d0s5| 5| - | - | 1859265| 1228800| 600| <-- show nothing on > "flg" and "tag" > 4 | c0t1d0s3| 3| - | - | 1040065| 819200| 400| > 5 | c0t1d0s1| 1| - | - | 425665| 614400| 300| > 6 | c0t1d0s0| 0| - | - | 16065| 409600| 200| > 7 | c0t2d0s6| 6| 00| 04| 0| 286698624| 139989| > 8 | c0t2d0s2| 2| 01| 05| 0| 286698624| 139989| > 9 | c0t3d0s6| 6| 00| 04| 0| 286698624| 139989| > 10 | c0t3d0s2| 2| 01| 05| 0| 286698624| 139989| > 11 | - | - | - | - | - | - | - | > 12 | dump| 0| - | - | 34| 3145694| 1535| > ----------------------------------------------------------------- > > # prtvtoc /dev/rdsk/c0t1d0s0 > * /dev/rdsk/c0t1d0s0 partition map > * > * Dimensions: > * 512 bytes/sector > * 143374738 sectors > * 143374671 accessible sectors > * > * Flags: > * 1: unmountable > * 10: read-only > * > * Unallocated space: > * First Sector Last > * Sector Count Sector > * 34 16031 16064 > * 3292865 140081839 143374703 > * > * First Sector Last > * Partition Tag Flags Sector Count Sector Mount Directory > 0 2 00 16065 409600 425664 > 1 3 01 425665 614400 1040064 > 3 4 11 1040065 819200 1859264 > 5 1 10 1859265 1228800 3088064 > 8 11 00 3088065 204800 3292864 > > 2. what is mean of "F, VF, GF" for "lbl" attribute for disk > discovery? Those letters indicate if disk contains one of possible labels: F - disk contains FDISK partition table V - disk contains VTOC label G - disk contains GPT (EFI) label > As following. > # test_td -d -v > Disk discovery > Total number of disks: 2 > ------------------------------------------------------------------------------- > num | name| vendor| ctype| mtype| rem| lbl| bsize|#of blocks|size [MB]| > ------------------------------------------------------------------------------- > 1 |* c4d0| unknown| ata| FIXED| No| VF| 512| 312576768| 152625| > 2 | swap| unknown|unknown| UNKN| No| GF| 512| 1048576| 512| > ------------------------------------------------------------------------------- > > From our old assertions about td discovery, it looks like the > value of "lbl" has relation with disk label(i.e., SMI or EFI). > > Our current assertions show: > ARCH Label lbl value > x86 SMI VF > x86 EFI GF > x86 No label F > sparc SMI V > sparc EFI G Those are correct. > sparc No label F In this case, test_td should likely report 'unk' instead, since for Sparc platform libdiskmgt checks for FDISK partition table only for removable media: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libdiskmgt/common/partition.c#partition_has_fdisk Thank you, Jan > > Is the above table still correct? > > Thanks > Jason >
