The idea is to boot a disk in an mbr fashion while using the GPT (not filesystem) label to detect the disk. That is useful when you use grub2 & gpt. I was in case where my nodes (100s) have 8 disks each and no guarantee of which disk is "bootable" in the disk. This way I can tell "please boot the disk that have one partition labelled "xyz"". So nothing related to filesystem but gpt labels & disks. 2016-07-15 18:27 GMT+02:00 poma <pomidorabelisima at gmail.com>:> On 15.07.2016 17:53, Ady Ady via Syslinux wrote: > > > >> 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=gptpartitionname > > > > > > Not 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. > > > > For once, precise explanation of the author is really required, > afterwards the actual option name should not be a problem > > e.g. > append icecream=whicheverflavor > ;) > > >
On 16.07.2016 10:39, Erwan Velu wrote:> The idea is to boot a disk in an mbr fashion while using the GPT (not > filesystem) label to detect the disk. > > That is useful when you use grub2 & gpt. I was in case where my nodes > (100s) have 8 disks each and no guarantee of which disk is "bootable" in > the disk. > > This way I can tell "please boot the disk that have one partition labelled > "xyz"". > > So nothing related to filesystem but gpt labels & disks. >OK, this is sucus of your patch: https://github.com/ErwanAliasr1/syslinux/commit/ebf8cbf#diff-6fb847366ce3f1ddbf6ffd8fd4d408fcR165 + // We don't care about the actual partition that matched + pi_del(&iter); i.e. https://github.com/ErwanAliasr1/syslinux/commit/ebf8cbf#diff-6fb847366ce3f1ddbf6ffd8fd4d408fcR167 + // Let's return the disk itself instead + iter = pi_begin(&diskinfo, opt.piflags); + goto ok; Still, there is no GPT label, but *GPT* *Partition* *name* ;) https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_entries
On 16.07.2016 19:55, poma wrote:> On 16.07.2016 10:39, Erwan Velu wrote: >> The idea is to boot a disk in an mbr fashion while using the GPT (not >> filesystem) label to detect the disk. >> >> That is useful when you use grub2 & gpt. I was in case where my nodes >> (100s) have 8 disks each and no guarantee of which disk is "bootable" in >> the disk. >> >> This way I can tell "please boot the disk that have one partition labelled >> "xyz"". >> >> So nothing related to filesystem but gpt labels & disks. >> > > OK, this is sucus of your patch: > https://github.com/ErwanAliasr1/syslinux/commit/ebf8cbf#diff-6fb847366ce3f1ddbf6ffd8fd4d408fcR165 > + // We don't care about the actual partition that matched > + pi_del(&iter); > > i.e. > https://github.com/ErwanAliasr1/syslinux/commit/ebf8cbf#diff-6fb847366ce3f1ddbf6ffd8fd4d408fcR167 > + // Let's return the disk itself instead > + iter = pi_begin(&diskinfo, opt.piflags); > + goto ok; > > > Still, there is no GPT label, but *GPT* *Partition* *name* ;) > https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_entries >probably whence the "inconsistency" began - with so-called GPT partition "label": chain: Support booting GPT partition by label http://git.zytor.com/syslinux/syslinux.git/commit/?id=bf4d560 GPT partition "label" can be synonymous, but actual option should be the *name*, as specified in GPT scheme.
On 16.07.2016 10:39, Erwan Velu wrote:> The idea is to boot a disk in an mbr fashion while using the GPT (not > filesystem) label to detect the disk. > > That is useful when you use grub2 & gpt. I was in case where my nodes > (100s) have 8 disks each and no guarantee of which disk is "bootable" in > the disk. > > This way I can tell "please boot the disk that have one partition labelled > "xyz"". > > So nothing related to filesystem but gpt labels & disks. >For comparison - option "label" - GPT Partition name selection, working as expected SeaBIOS / SYSLINUX # gdisk -l /dev/vdc ... Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk /dev/vdc: ... ... Number Start (sector) End (sector) Size Code Name 1 2048 6143 2.0 MiB EF02 BIOS_Boot 2 411648 1435647 500.0 MiB 8300 GPT_Boot 3 1435648 22646783 10.1 GiB 8300 GPT_Root 4 22646784 25163775 1.2 GiB 8200 GPT_Swap boot: chain label=GPT_Boot OK ~~~~~~~~~~~~~~~~~~~~~~~~~~ As opposed to "label", "dlabel" ... https://github.com/ErwanAliasr1/syslinux/commit/ebf8cbf SeaBIOS / GRUB2 ... ... <target dev='vdc' bus='virtio'/> <boot order='3'/> ... ... <target dev='vdd' bus='virtio'/> <boot order='4'/> ... ... # gdisk -l /dev/vdc ... Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk /dev/vdc: ... ... Number Start (sector) End (sector) Size Code Name 1 2048 6143 2.0 MiB EF02 BIOS_Boot 2 411648 1435647 500.0 MiB 8300 GPT_Boot 3 1435648 22646783 10.1 GiB 8300 GPT_Root 4 22646784 25163775 1.2 GiB 8200 GPT_Swap # gdisk -l /dev/vdd ... Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk /dev/vdd: ... ... Number Start (sector) End (sector) Size Code Name 1 2048 6143 2.0 MiB EF02 BIOS_Boot_2 2 411648 1435647 500.0 MiB 8300 GPT_Boot_2 3 1435648 22646783 10.1 GiB 8300 GPT_Root_2 4 22646784 25163775 1.2 GiB 8200 GPT_Swap_2 /boot/extlinux/extlinux.conf ... label localboot com32 chain.c32 append dlabel=GPT_Root label localboot 2 com32 chain.c32 append dlabel=GPT_Root_2 ... OR boot: chain dlabel=GPT_Root OR boot: chain dlabel=GPT_Root_2 OR boot: chain dlabel=VanillaStrawberry OR boot: chain dlabel=literallywhateverentered The result is always the same, selected for boot is always drive with a higher boot priority, in this case - vdc
> > As opposed to "label", > "dlabel" ... > https://github.com/ErwanAliasr1/syslinux/commit/ebf8cbf > > SeaBIOS / GRUB2 > > ... > ... > <target dev='vdc' bus='virtio'/> > <boot order='3'/> > ... > ... > <target dev='vdd' bus='virtio'/> > <boot order='4'/> > ... > ... > > > # gdisk -l /dev/vdc > ... > Partition table scan: > MBR: protective > BSD: not present > APM: not present > GPT: present > > Found valid GPT with protective MBR; using GPT. > Disk /dev/vdc: ... > ... > Number Start (sector) End (sector) Size Code Name > 1 2048 6143 2.0 MiB EF02 BIOS_Boot > 2 411648 1435647 500.0 MiB 8300 GPT_Boot > 3 1435648 22646783 10.1 GiB 8300 GPT_Root > 4 22646784 25163775 1.2 GiB 8200 GPT_Swap > > > > # gdisk -l /dev/vdd > ... > Partition table scan: > MBR: protective > BSD: not present > APM: not present > GPT: present > > Found valid GPT with protective MBR; using GPT. > Disk /dev/vdd: ... > ... > Number Start (sector) End (sector) Size Code Name > 1 2048 6143 2.0 MiB EF02 BIOS_Boot_2 > 2 411648 1435647 500.0 MiB 8300 GPT_Boot_2 > 3 1435648 22646783 10.1 GiB 8300 GPT_Root_2 > 4 22646784 25163775 1.2 GiB 8200 GPT_Swap_2 > > > > /boot/extlinux/extlinux.conf > ... > label localboot > com32 chain.c32 > append dlabel=GPT_Root > > label localboot 2 > com32 chain.c32 > append dlabel=GPT_Root_2 > ... > > OR > boot: chain dlabel=GPT_Root > OR > boot: chain dlabel=GPT_Root_2 > OR > boot: chain dlabel=VanillaStrawberry > OR > boot: chain dlabel=literallywhateverentered > > > The result is always the same, > selected for boot is always drive with a higher boot priority, > in this case - vdc > >A couple of comments about this test that might be relevant. First, LABEL directives (nothing to do with any "label" related to chain.c32) should not include spaces (e.g. "localboot 2" should not be used for a LABEL directive). Now, regarding your 2 entries (i.e. LABELs) in extlinux.conf, what else is there? Would you please try using 'dlabel=GPT_Root_2' as your fist (LABEL) entry and as the DEFAULT label command? The reason I am requesting this is because Fedora (which you usually use for your tests, IIRC) 24 was released without a patch in Syslinux for gcc5+ (which solves this strange behavior in the Syslinux boot prompt). Although Rawhide already includes the relevant patch for Syslinux's CLI, it is still not updated to the very latest / current Syslinux git master head (only updated to 6.04-pre1). I guess the important question would be whether this test was performed from the current upstream Syslinux git master head + Erwan's patch, or rather from some older snapshot / build / version (+ Erwan's patch). If the former, then the problem in CLI seems to be back (in which case, the version of gcc being used to build these binaries might be a relevant detail). Regards, Ady.
That is perfectly true. I had a beautiful bug in the code .... Switching from python to C have some weird side-effect. Indenting is not enough, brackets are required.... So I pushed https://github.com/ErwanAliasr1/syslinux/commit/5a122d218553a6d4019273653ba9fad66d6ae79e with the fix. I tested it on my multi-disk system with success. I also changed the name of the function. 2016-07-17 8:21 GMT+02:00 poma <pomidorabelisima at gmail.com>:> On 16.07.2016 10:39, Erwan Velu wrote: > > The idea is to boot a disk in an mbr fashion while using the GPT (not > > filesystem) label to detect the disk. > > > > That is useful when you use grub2 & gpt. I was in case where my nodes > > (100s) have 8 disks each and no guarantee of which disk is "bootable" in > > the disk. > > > > This way I can tell "please boot the disk that have one partition > labelled > > "xyz"". > > > > So nothing related to filesystem but gpt labels & disks. > > > > > For comparison - option "label" - GPT Partition name selection, > working as expected > > SeaBIOS / SYSLINUX > > # gdisk -l /dev/vdc > ... > Partition table scan: > MBR: protective > BSD: not present > APM: not present > GPT: present > > Found valid GPT with protective MBR; using GPT. > Disk /dev/vdc: ... > ... > Number Start (sector) End (sector) Size Code Name > 1 2048 6143 2.0 MiB EF02 BIOS_Boot > 2 411648 1435647 500.0 MiB 8300 GPT_Boot > 3 1435648 22646783 10.1 GiB 8300 GPT_Root > 4 22646784 25163775 1.2 GiB 8200 GPT_Swap > > > boot: chain label=GPT_Boot > OK > > ~~~~~~~~~~~~~~~~~~~~~~~~~~ > > As opposed to "label", > "dlabel" ... > https://github.com/ErwanAliasr1/syslinux/commit/ebf8cbf > > SeaBIOS / GRUB2 > > ... > ... > <target dev='vdc' bus='virtio'/> > <boot order='3'/> > ... > ... > <target dev='vdd' bus='virtio'/> > <boot order='4'/> > ... > ... > > > # gdisk -l /dev/vdc > ... > Partition table scan: > MBR: protective > BSD: not present > APM: not present > GPT: present > > Found valid GPT with protective MBR; using GPT. > Disk /dev/vdc: ... > ... > Number Start (sector) End (sector) Size Code Name > 1 2048 6143 2.0 MiB EF02 BIOS_Boot > 2 411648 1435647 500.0 MiB 8300 GPT_Boot > 3 1435648 22646783 10.1 GiB 8300 GPT_Root > 4 22646784 25163775 1.2 GiB 8200 GPT_Swap > > > > # gdisk -l /dev/vdd > ... > Partition table scan: > MBR: protective > BSD: not present > APM: not present > GPT: present > > Found valid GPT with protective MBR; using GPT. > Disk /dev/vdd: ... > ... > Number Start (sector) End (sector) Size Code Name > 1 2048 6143 2.0 MiB EF02 BIOS_Boot_2 > 2 411648 1435647 500.0 MiB 8300 GPT_Boot_2 > 3 1435648 22646783 10.1 GiB 8300 GPT_Root_2 > 4 22646784 25163775 1.2 GiB 8200 GPT_Swap_2 > > > > /boot/extlinux/extlinux.conf > ... > label localboot > com32 chain.c32 > append dlabel=GPT_Root > > label localboot 2 > com32 chain.c32 > append dlabel=GPT_Root_2 > ... > > OR > boot: chain dlabel=GPT_Root > OR > boot: chain dlabel=GPT_Root_2 > OR > boot: chain dlabel=VanillaStrawberry > OR > boot: chain dlabel=literallywhateverentered > > > The result is always the same, > selected for boot is always drive with a higher boot priority, > in this case - vdc > > >