Jason Zhao wrote: > It seems like there is an error about EFI label in x86.Please see in > line. > > Jason Zhao wrote: >> Hi, Jan, >> >> Thank you for your answer, please see comments in line. >> jan damborsky wrote: >> >>> 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. >>> >>> >> OK, it looks like libtd does not support EFI label now. Then, >> how about we will not test EFI label disk test cases now and >> if libtd will support it in the future, we will add related cases >> in test suite. >> >>> >>>> 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 >>>> > Currently, on x86 platform, If I marked EFI label, it actually generate > an EFI partition first, so in this way, it looks like libtd print out > "F", other > than "GF".
That might be a bug - I have verified that even if EFI label is created on x86 disk using format(1M) command, libdiskmgt library doesn't set DM_EFI flag for that disk and thus libtd doesn't report it as EFI labeled. I will investigate further if this is bug or required behavior in libdiskmgt. Thank you for catching this ! Jan > And currently test_td does work in this way, please see example(c3d1 is > an EFI label disk). > # test_td -d -v > Disk discovery > Total number of disks: 3 > ------------------------------------------------------------------------------- > > > num | name| vendor| ctype| mtype| rem| lbl| bsize|#of blocks|size [MB]| > ------------------------------------------------------------------------------- > > > 1 |* c3d0| unknown| ata| FIXED| No| VF| 512| 156248064| 76293| > 2 | c3d1| unknown| ata| FIXED| No| F| 512| 156248064| 76293| > 3 | dump| unknown|unknown| UNKN| No| GF| 512| 1038336| 507| > ------------------------------------------------------------------------------- > > > > Thanks > Jason
