The exisiting label= option offer to boot on a gpt partition that have
a particular label.
The existing guuid= option offer to boot on a disk or partition with a
particular label.
This new option offer to boot the disk that have a partition which
have a given label.
The label is so just a way to detect a disk to boot.
A typical use is for making an intelligent localboot like :
label localboot
com32 chain.c32
append dlabel=datapartition
This allow booting on a disk that sports a least one partition
labelled "datapartition".
You can consider dlabel= doing almost what mbr= does but by inspecting
the gpt partitions label.
Please find below the commit :
https://github.com/ErwanAliasr1/syslinux/commit/ebf8cbfb8cef49517aa36b4a79998b4332289489
If I may, I would like to suggest some possible rewording (perhaps adding some clarity, simplifying and solving some typos, I hope). BTW, any suggestions for an alternative name for this option, instead of "dlabel"?> The exisiting label= option offer to boot on a gpt partition that have > a particular label. > The existing guuid= option offer to boot on a disk or partition with a > particular label. >The existing "label:" and "guid:" options select a specified partition and jump to it.> This new option offer to boot the disk that have a partition which > have a given label. > The label is so just a way to detect a disk to boot. >The "dlabel" option searches in disks for a partition with the specified label, and jumps to the first _disk_ that matches the search. The specified partition might not be related to the boot process; its label is just used for the detection / selection of the disk.> A typical use is for making an intelligent localboot like : >A possible use case is for making a localboot like:> label localboot > com32 chain.c32 > append dlabel=datapartition > > This allow booting on a disk that sports a least one partition > labelled "datapartition". >This option allows booting a disk that contains at least one partition labeled "datapartition".> You can consider dlabel= doing almost what mbr= does but by inspecting > the gpt partitions label. > >The "dlabel:" option can be considered as doing almost what the "mbr:" option does, but by searching for a specified label in the GPT partitions.> Please find below the commit : > https://github.com/ErwanAliasr1/syslinux/commit/ebf8cbfb8cef49517aa36b4a79998b4332289489Additional suggestions for the text in the commit itself, with some spelling corrections and matching the wording used in the above suggestions:> 147 + * Search for a specific drive whic have a partition with agiven GPT label. 147 + * Search for a disk having a partition with a specified GPT label.> 339 + error("No disk label specified.");Since I am not a developer, I am not sure about this one. Where is the _disk_ label specified when we are talking about this "dlabel" option? Aren't we talking about labels of _partitions_? The same question would go for the line (with some line-formatting inaccuracy just in this email, which we should be ignoring here): 343 + error("Unable to find requested GPT partition by disk label."); I'd like to repeat my first question: any suggestions for an alternative name for this option, instead of "dlabel"? Regards, Ady.
On Jun 30, 2016 5:23 PM, "Ady Ady via Syslinux" <syslinux at zytor.com> wrote:> BTW, any suggestions for an alternative name for this option, instead > of "dlabel"?diskbylabel, diskbypartitionlabel, label2disk, etc. --Gene
H. Peter Anvin
2016-Jul-13 20:39 UTC
[syslinux] [PATCH] : Adding dlabel option to chain.c32
On 06/30/16 14:19, Ady Ady via Syslinux wrote:> > BTW, any suggestions for an alternative name for this option, instead > of "dlabel"? >"disklabel" -hpa
On 30.06.2016 19:41, Erwan Velu via Syslinux wrote:> The exisiting label= option offer to boot on a gpt partition that have > a particular label. > The existing guuid= option offer to boot on a disk or partition with a > particular label. > > This new option offer to boot the disk that have a partition which > have a given label. > The label is so just a way to detect a disk to boot. > > A typical use is for making an intelligent localboot like : > > label localboot > com32 chain.c32 > append dlabel=datapartition > > This allow booting on a disk that sports a least one partition > labelled "datapartition". > > You can consider dlabel= doing almost what mbr= does but by inspecting > the gpt partitions label. > > > Please find below the commit : > https://github.com/ErwanAliasr1/syslinux/commit/ebf8cbfb8cef49517aa36b4a79998b4332289489 ># gdisk -l /dev/vda ... Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. ... Number Start (sector) End (sector) Size Code Name 1 2048 411647 200.0 MiB EF00 EFI System Partition 2 411648 1435647 500.0 MiB 8300 BOOT System Partition 3 1435648 22646783 10.1 GiB 8300 ROOT System Partition 4 22646784 25163775 1.2 GiB 8200 SWAP System Partition # fdisk -l /dev/vda ... Disklabel type: gpt ... Device Start End Sectors Size Type /dev/vda1 2048 411647 409600 200M EFI System /dev/vda2 411648 1435647 1024000 500M Linux filesystem /dev/vda3 1435648 22646783 21211136 10.1G Linux filesystem /dev/vda4 22646784 25163775 2516992 1.2G Linux swap # fatlabel /dev/vda1 labelefi # e2label /dev/vda2 labelboot # e2label /dev/vda3 labelroot # swaplabel /dev/vda4 LABEL: labelswap ... Filesystem *label* and *label* of a swap area distinguish from GPT *name* of a partition Therefore -if- you are referring to a GPT partition *name*, simple *name* as append option - for GPT partition *name* selection, should suffice i.e. ... append name=gptpartitionname
> On 30.06.2016 19:41, Erwan Velu via Syslinux wrote: > > The exisiting label= option offer to boot on a gpt partition that have > > a particular label. > > The existing guuid= option offer to boot on a disk or partition with a > > particular label. > > > > This new option offer to boot the disk that have a partition which > > have a given label. > > The label is so just a way to detect a disk to boot. > > > > A typical use is for making an intelligent localboot like : > > > > label localboot > > com32 chain.c32 > > append dlabel=datapartition > > > > This allow booting on a disk that sports a least one partition > > labelled "datapartition". > > > > You can consider dlabel= doing almost what mbr= does but by inspecting > > the gpt partitions label. > > > > > > Please find below the commit : > > https://github.com/ErwanAliasr1/syslinux/commit/ebf8cbfb8cef49517aa36b4a79998b4332289489 > > > > > # gdisk -l /dev/vda > ... > Partition table scan: > MBR: protective > BSD: not present > APM: not present > GPT: present > > Found valid GPT with protective MBR; using GPT. > ... > Number Start (sector) End (sector) Size Code Name > 1 2048 411647 200.0 MiB EF00 EFI System Partition > 2 411648 1435647 500.0 MiB 8300 BOOT System Partition > 3 1435648 22646783 10.1 GiB 8300 ROOT System Partition > 4 22646784 25163775 1.2 GiB 8200 SWAP System Partition > > > # fdisk -l /dev/vda > ... > Disklabel type: gpt > ... > Device Start End Sectors Size Type > /dev/vda1 2048 411647 409600 200M EFI System > /dev/vda2 411648 1435647 1024000 500M Linux filesystem > /dev/vda3 1435648 22646783 21211136 10.1G Linux filesystem > /dev/vda4 22646784 25163775 2516992 1.2G Linux swap > > > # fatlabel /dev/vda1 > labelefi > > # e2label /dev/vda2 > labelboot > > # e2label /dev/vda3 > labelroot > > # swaplabel /dev/vda4 > LABEL: labelswap > ... > > > Filesystem *label* and *label* of a swap area > distinguish from > GPT *name* of a partition >_If_ I understand Erwan's patch correctly, we are talking about the GPT Partition Name, not the filesystem's label (but I could be wrong).> > Therefore -if- you are referring to a GPT partition *name*, > simple *name* as append option - for GPT partition *name* selection, should suffice > i.e. > ... > append name=gptpartitionnameNot exactly. We are distinguishing between the GPT Partition Name being used just to select the next device (for example, your "ROOT System Partition"), and the (Protective) MBR we are jumping to, in BIOS / CSM mode. In my prior email I suggested "diskbypartname" with relevant explanations (see http://www.syslinux.org/archives/2016-July/025305.html ). Tests and feedback are appreciated. Regards, Ady.> _______________________________________________ > Syslinux mailing list > Submissions to Syslinux at zytor.com > Unsubscribe or set options at: > http://www.zytor.com/mailman/listinfo/syslinux
On 30.06.2016 19:41, Erwan Velu via Syslinux wrote:> The exisiting label= option offer to boot on a gpt partition that have > a particular label.According to official documentation, 'label' does not refer solely to the GPT http://git.zytor.com/syslinux/syslinux.git/tree/doc/chain.txt#n80 - 'label' will select a partition by a label (searching is done in disk order) Neither the 'label' applies to partition, but refers to a *filesystem* label> The existing guuid= option offer to boot on a disk or partition with a > particular label. >'guuid' option does not exist, but 'guid' does http://git.zytor.com/syslinux/syslinux.git/tree/doc/chain.txt#n64 - 'guid' will select a drive by its guid (GPT only). http://git.zytor.com/syslinux/syslinux.git/tree/doc/chain.txt#n79 - 'guid' option will select a partition by a guid (not a type guid !)> This new option offer to boot the disk that have a partition which > have a given label. > The label is so just a way to detect a disk to boot. > > A typical use is for making an intelligent localboot like : > > label localboot > com32 chain.c32 > append dlabel=datapartition > > This allow booting on a disk that sports a least one partition > labelled "datapartition". > > You can consider dlabel= doing almost what mbr= does but by inspecting > the gpt partitions label. >[...] Are you actually referring to GPT *name* of a partition, instead of filesystem *label*?
> > Are you actually referring to GPT *name* of a partition, > instead of filesystem *label*?Please (re)read the entire email thread (there is a reason I posted a slightly modified, yet untested, patch).
Michal Soltys
2016-Jul-17 17:31 UTC
[syslinux] [PATCH] : Adding dlabel option to chain.c32
On 2016-06-30 19:41, Erwan Velu via Syslinux wrote:> The exisiting label= option offer to boot on a gpt partition that have > a particular label. > The existing guuid= option offer to boot on a disk or partition with a > particular label. > > This new option offer to boot the disk that have a partition which > have a given label. > The label is so just a way to detect a disk to boot. > > A typical use is for making an intelligent localboot like : > > label localboot > com32 chain.c32 > append dlabel=datapartition > > This allow booting on a disk that sports a least one partition > labelled "datapartition". > > You can consider dlabel= doing almost what mbr= does but by inspecting > the gpt partitions label. >Btw, I'm fine with the patch (functionally). As for the name for the option I'm not sure (and I can see it spawned lots of discussion). To not keep it too long, maybe something like diskbypname or diskbyplabel (or even both available) As for the patch, I'd change one comment: Return drive and iterator at proper position. to Return drive and iterator at 0th position. To follow the same "scheme" as in find_by_sig(). And move the code under that function maybe (so stuff returning drive is in one place). It's just nitpicking though. For the record, the whole iterator stuff is missing one thing I've had patch prepared a while ago (but I've been stomped with RL stuff for a while ...) that would also allow choosing GPT drive by MBR sig; gotta dig it up and test at some point. Not sure if that would be useful for you (or anyone ;) ).