All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] core/partmap: Add El Torito boot catalog parsing
@ 2015-06-07 10:24 Ross Lagerwall
  2015-06-08 16:51 ` Andrei Borzenkov
  0 siblings, 1 reply; 12+ messages in thread
From: Ross Lagerwall @ 2015-06-07 10:24 UTC (permalink / raw)
  To: grub-devel; +Cc: Ross Lagerwall

Add a module, part_eltorito, to allow parsing of the El Torito boot
catalog into partitions. This follows the El Torito Bootable CD-ROM
Format Specification Version 1.0 and the UEFI Specification 2.5.
In cases where the specification is unclear, the code follows the UEFI
reference implementation.

This is useful when booting CDs in UEFI mode. Before, GRUB would not be
able to use the embedded ESP from which it was executed, so it would
have a root and prefix set to the top level of the CD. This could result
in subtle configuration bugs, because the same ISO booted from a USB
disk (using isohybrid) would have its root and prefix set to the
embedded ESP because it can find it through the MBR.
With this change, GRUB is able to access the embedded ESP and set its
root and prefix correctly when booting a CD in UEFI mode. It also
allows GRUB to access embedded floppy and HDD images.

Tested with OVMF and a couple of real machines.

Signed-off-by: Ross Lagerwall <rosslagerwall@gmail.com>
---
 grub-core/Makefile.core.def  |   5 ++
 grub-core/partmap/eltorito.c | 199 +++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 204 insertions(+)
 create mode 100644 grub-core/partmap/eltorito.c

diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index a6101de..f07572b 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -1785,6 +1785,11 @@ module = {
 };
 
 module = {
+  name = part_eltorito;
+  common = partmap/eltorito.c;
+};
+
+module = {
   name = part_msdos;
   common = partmap/msdos.c;
 };
diff --git a/grub-core/partmap/eltorito.c b/grub-core/partmap/eltorito.c
new file mode 100644
index 0000000..dee6250
--- /dev/null
+++ b/grub-core/partmap/eltorito.c
@@ -0,0 +1,199 @@
+/* eltorito.c - Read GUID Partition Tables (GPT).  */
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2002,2005,2006,2007,2008  Free Software Foundation, Inc.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or
+ *  (at your option) any later version.
+ *
+ *  GRUB is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with GRUB.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <grub/disk.h>
+#include <grub/misc.h>
+#include <grub/mm.h>
+#include <grub/partition.h>
+#include <grub/dl.h>
+#include <grub/i18n.h>
+
+GRUB_MOD_LICENSE ("GPLv3+");
+
+#define ISO9660_LOG2_BLKSZ          2
+#define BOOT_RECORD_LBA             (0x11 << ISO9660_LOG2_BLKSZ)
+#define PRIMARY_VOLUME_LBA          (0x10 << ISO9660_LOG2_BLKSZ)
+#define VOLUME_SPACE_SIZE_OFFSET    0x50
+#define ELTORITO_MAGIC              (grub_cpu_to_le16_compile_time (0xAA55))
+#define ELTORITO_BOOTABLE           0x88
+#define ELTORITO_NOT_BOOTABLE       0x00
+#define ELTORITO_MEDIA_TYPE_MASK    0x03
+#define ELTORITO_TYPE_NO_EMUL       0x00
+#define ELTORITO_TYPE_FLOPPY_1_2    0x01
+#define ELTORITO_TYPE_FLOPPY_1_4    0x02
+#define ELTORITO_TYPE_FLOPPY_2_8    0x03
+#define ELTORITO_TYPE_HDD           0x04
+
+static const char *IDENT = "CD001";
+static const char SYSTEM_ID[32] = "EL TORITO SPECIFICATION";
+
+struct boot_record {
+  grub_uint8_t indicator;
+  char identifier[5];
+  grub_uint8_t version;
+  char system_id[32];
+  grub_uint8_t pad[32];
+  grub_uint32_t catalog_sector;
+} GRUB_PACKED;
+
+union et_entry {
+  /* The validation entry. */
+  struct {
+    grub_uint8_t header;
+    grub_uint8_t platform;
+    grub_uint16_t reserved;
+    char identifier[24];
+    grub_uint16_t checksum;
+    grub_uint16_t magic;
+  } validation GRUB_PACKED;
+
+  /* All other entries. */
+  struct {
+    grub_uint8_t boot_indicator;
+    grub_uint8_t media_type;
+    grub_uint16_t load_segment;
+    grub_uint8_t system_type;
+    grub_uint8_t unused;
+    grub_uint16_t sector_count;
+    grub_uint32_t load_lba;
+    char pad[20];
+  } e GRUB_PACKED;
+
+  /* Used for calculating the checksum. */
+  grub_uint16_t bin[16];
+};
+
+static struct grub_partition_map grub_eltorito_partition_map;
+
+static grub_err_t
+grub_eltorito_partition_map_iterate (grub_disk_t disk,
+                                     grub_partition_iterate_hook_t hook,
+                                     void *hook_data)
+{
+  struct grub_partition part;
+  struct boot_record br;
+  union et_entry entries[64];
+  unsigned int i;
+  int found = 0;
+  grub_uint16_t checksum = 0, sector_count;
+  grub_uint32_t total_sectors;
+
+  /* Find boot catalog. */
+  if (grub_disk_read (disk, BOOT_RECORD_LBA, 0, sizeof br, &br))
+    return grub_errno;
+
+  if (br.indicator != 0 || br.version != 1 ||
+      grub_memcmp (br.identifier, IDENT, sizeof br.identifier) != 0 ||
+      grub_memcmp (br.system_id, SYSTEM_ID, sizeof SYSTEM_ID) != 0)
+    return grub_error (GRUB_ERR_BAD_PART_TABLE, "invalid boot descriptor");
+
+  part.offset = grub_le_to_cpu32 (br.catalog_sector) << ISO9660_LOG2_BLKSZ;
+
+  /* Load boot catalog and verify the validation entry. */
+  if (grub_disk_read (disk, part.offset, 0, sizeof entries, entries))
+    return grub_errno;
+
+  if (entries[0].validation.header != 1 ||
+      entries[0].validation.reserved != 0 ||
+      entries[0].validation.magic != ELTORITO_MAGIC)
+    return grub_error (GRUB_ERR_BAD_PART_TABLE, "invalid validation entry");
+
+  for (i = 0; i < ARRAY_SIZE (entries[0].bin); i++)
+    checksum += grub_le_to_cpu16 (entries[0].bin[i]);
+  if (checksum != 0)
+    return grub_error (GRUB_ERR_BAD_PART_TABLE, "invalid validation entry");
+
+  /* Calculate the number of sectors, in case the ISO9660 filesystem is smaller
+     than the disk. */
+  if (grub_disk_read (disk, PRIMARY_VOLUME_LBA, VOLUME_SPACE_SIZE_OFFSET,
+                      sizeof total_sectors, &total_sectors))
+    return grub_errno;
+  total_sectors = grub_le_to_cpu32 (total_sectors) << ISO9660_LOG2_BLKSZ;
+  total_sectors = grub_min (total_sectors,
+                            disk->total_sectors << (disk->log_sector_size -
+                                                    GRUB_DISK_SECTOR_BITS));
+
+  part.partmap = &grub_eltorito_partition_map;
+  part.parent = disk->partition;
+
+  /* Add a partition for each valid entry. */
+  for (i = 1; i < ARRAY_SIZE (entries); i++)
+    {
+      if ((entries[i].e.boot_indicator == ELTORITO_BOOTABLE ||
+           entries[i].e.boot_indicator == ELTORITO_NOT_BOOTABLE) &&
+          entries[i].e.load_lba != 0)
+        {
+	  part.number = found++;
+	  part.index = i;
+	  part.start = entries[i].e.load_lba << ISO9660_LOG2_BLKSZ;
+          sector_count = grub_le_to_cpu16 (entries[i].e.sector_count);
+
+          /* Calculate the sector size as it's done in the UEFI reference
+             implementation so that partitions are matched correctly. */
+          switch (entries[i].e.media_type & ELTORITO_MEDIA_TYPE_MASK)
+            {
+            case ELTORITO_TYPE_NO_EMUL:
+            default:
+              if (sector_count < 2)
+                part.len = total_sectors - part.start;
+              else
+                part.len = sector_count << ISO9660_LOG2_BLKSZ;
+              break;
+            case ELTORITO_TYPE_HDD:
+              if (sector_count < 2)
+                part.len = total_sectors - part.start;
+              else
+                part.len = sector_count;
+              break;
+            case ELTORITO_TYPE_FLOPPY_1_2:
+              part.len = 2400;
+              break;
+            case ELTORITO_TYPE_FLOPPY_1_4:
+              part.len = 2880;
+              break;
+            case ELTORITO_TYPE_FLOPPY_2_8:
+              part.len = 5760;
+              break;
+            }
+
+	  if (hook (disk, &part, hook_data))
+	    return grub_errno;
+        }
+    }
+
+  return GRUB_ERR_NONE;
+}
+
+\f
+/* Partition map type.  */
+static struct grub_partition_map grub_eltorito_partition_map =
+  {
+    .name = "eltorito",
+    .iterate = grub_eltorito_partition_map_iterate,
+  };
+
+GRUB_MOD_INIT(part_eltorito)
+{
+  grub_partition_map_register (&grub_eltorito_partition_map);
+}
+
+GRUB_MOD_FINI(part_eltorito)
+{
+  grub_partition_map_unregister (&grub_eltorito_partition_map);
+}
-- 
2.4.2



^ permalink raw reply related	[flat|nested] 12+ messages in thread

* Re: [PATCH] core/partmap: Add El Torito boot catalog parsing
  2015-06-07 10:24 [PATCH] core/partmap: Add El Torito boot catalog parsing Ross Lagerwall
@ 2015-06-08 16:51 ` Andrei Borzenkov
  2015-06-08 17:31   ` Ross Lagerwall
  0 siblings, 1 reply; 12+ messages in thread
From: Andrei Borzenkov @ 2015-06-08 16:51 UTC (permalink / raw)
  To: Ross Lagerwall; +Cc: grub-devel

В Sun,  7 Jun 2015 11:24:46 +0100
Ross Lagerwall <rosslagerwall@gmail.com> пишет:

> Add a module, part_eltorito, to allow parsing of the El Torito boot
> catalog into partitions. This follows the El Torito Bootable CD-ROM
> Format Specification Version 1.0 and the UEFI Specification 2.5.
> In cases where the specification is unclear, the code follows the UEFI
> reference implementation.
> 
> This is useful when booting CDs in UEFI mode. Before, GRUB would not be
> able to use the embedded ESP from which it was executed, so it would
> have a root and prefix set to the top level of the CD. This could result
> in subtle configuration bugs, because the same ISO booted from a USB
> disk (using isohybrid) would have its root and prefix set to the
> embedded ESP because it can find it through the MBR.

You can already access ESP on hybrid image using e.g. (cd0,msdos1); why
is it not enough?

> With this change, GRUB is able to access the embedded ESP and set its
> root and prefix correctly when booting a CD in UEFI mode. It also
> allows GRUB to access embedded floppy and HDD images.
> 


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] core/partmap: Add El Torito boot catalog parsing
  2015-06-08 16:51 ` Andrei Borzenkov
@ 2015-06-08 17:31   ` Ross Lagerwall
  2015-06-08 17:50     ` Andrei Borzenkov
  0 siblings, 1 reply; 12+ messages in thread
From: Ross Lagerwall @ 2015-06-08 17:31 UTC (permalink / raw)
  To: Andrei Borzenkov; +Cc: grub-devel

[-- Attachment #1: Type: text/plain, Size: 1474 bytes --]

On Mon, Jun 08, 2015 at 07:51:44PM +0300, Andrei Borzenkov wrote:
> В Sun,  7 Jun 2015 11:24:46 +0100
> Ross Lagerwall <rosslagerwall@gmail.com> пишет:
> 
> > Add a module, part_eltorito, to allow parsing of the El Torito boot
> > catalog into partitions. This follows the El Torito Bootable CD-ROM
> > Format Specification Version 1.0 and the UEFI Specification 2.5.
> > In cases where the specification is unclear, the code follows the UEFI
> > reference implementation.
> > 
> > This is useful when booting CDs in UEFI mode. Before, GRUB would not be
> > able to use the embedded ESP from which it was executed, so it would
> > have a root and prefix set to the top level of the CD. This could result
> > in subtle configuration bugs, because the same ISO booted from a USB
> > disk (using isohybrid) would have its root and prefix set to the
> > embedded ESP because it can find it through the MBR.
> 
> You can already access ESP on hybrid image using e.g. (cd0,msdos1); why
> is it not enough?

This is about booting a CD in UEFI mode; it may not be a hybrid disc in
which case it doesn't have an MBR.

Also, in the case of a hybrid image booted using a CD, the mismatch between
the 2048 byte sectors of the CD and the 512 byte sector values used in the
MBR means that GRUB is not able to access the correctly ESP anyway.

For these reasons, I think it is useful to parse the El Torito boot
catalog.

Regards,
-- 
Ross Lagerwall

[-- Attachment #2: Type: application/pgp-signature, Size: 213 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] core/partmap: Add El Torito boot catalog parsing
  2015-06-08 17:31   ` Ross Lagerwall
@ 2015-06-08 17:50     ` Andrei Borzenkov
  2015-06-08 18:25       ` Ross Lagerwall
  0 siblings, 1 reply; 12+ messages in thread
From: Andrei Borzenkov @ 2015-06-08 17:50 UTC (permalink / raw)
  To: Ross Lagerwall; +Cc: grub-devel

[-- Attachment #1: Type: text/plain, Size: 4120 bytes --]

В Mon, 8 Jun 2015 18:31:06 +0100
Ross Lagerwall <rosslagerwall@gmail.com> пишет:

> On Mon, Jun 08, 2015 at 07:51:44PM +0300, Andrei Borzenkov wrote:
> > В Sun,  7 Jun 2015 11:24:46 +0100
> > Ross Lagerwall <rosslagerwall@gmail.com> пишет:
> > 
> > > Add a module, part_eltorito, to allow parsing of the El Torito boot
> > > catalog into partitions. This follows the El Torito Bootable CD-ROM
> > > Format Specification Version 1.0 and the UEFI Specification 2.5.
> > > In cases where the specification is unclear, the code follows the UEFI
> > > reference implementation.
> > > 
> > > This is useful when booting CDs in UEFI mode. Before, GRUB would not be
> > > able to use the embedded ESP from which it was executed, so it would
> > > have a root and prefix set to the top level of the CD. This could result
> > > in subtle configuration bugs, because the same ISO booted from a USB
> > > disk (using isohybrid) would have its root and prefix set to the
> > > embedded ESP because it can find it through the MBR.
> > 
> > You can already access ESP on hybrid image using e.g. (cd0,msdos1); why
> > is it not enough?
> 
> This is about booting a CD in UEFI mode; it may not be a hybrid disc in
> which case it doesn't have an MBR.
> 

So you need to either add partition label or add additional driver to
grub.efi. The former works already and does not require any new code.

> Also, in the case of a hybrid image booted using a CD, the mismatch between
> the 2048 byte sectors of the CD and the 512 byte sector values used in the
> MBR means that GRUB is not able to access the correctly ESP anyway.
> 

It may depend on how you create partition table. Neither openSUSE DVD
nor images created by grub-mkrescue have problems. Did you actually try
it?

As example

bor@opensuse:~/src/grub> xorriso --indev /datastore/iso/openSUSE-13.2-DVD-x86_64.iso --report-el-torito plain --report-system-area plain
xorriso 1.3.8 : RockRidge filesystem manipulator, libburnia project.

xorriso : NOTE : Loading ISO image tree from LBA 0
xorriso : UPDATE : 6102 nodes read in 1 seconds
xorriso : NOTE : Detected El-Torito boot information which currently is set to be discarded
Drive current: -indev '/datastore/iso/openSUSE-13.2-DVD-x86_64.iso'
Media current: stdio file, overwriteable
Media status : is written , is appendable
Boot record  : El Torito , MBR isohybrid cyl-align-off
Media summary: 1 session, 2284287 data blocks, 4461m data, 31.5g free
Volume id    : 'openSUSE-13.2-DVD-x86_640051'
El Torito catalog  : 20  1
El Torito images   :   N  Pltf  B   Emul  Ld_seg  Hdpt  Ldsiz         LBA
El Torito boot img :   1  BIOS  y   none  0x0000  0x00      4        5826
El Torito boot img :   2  UEFI  y   none  0x0000  0x00      1         896
El Torito img path :   1  /boot/x86_64/loader/isolinux.bin
El Torito img opts :   1  boot-info-table isohybrid-suitable
El Torito img path :   2  /boot/x86_64/efi
System area options: 0x00000202
System area summary: MBR isohybrid cyl-align-off
ISO image size/512 : 9137148
Partition offset   : 0
MBR heads per cyl  : 0
MBR secs per head  : 0
MBR partition table:   N Status  Type        Start       Blocks
MBR partition      :   1   0x00  0xef         3584         8064
MBR partition      :   2   0x80  0x17        11648      9126528
MBR partition path :   1  /boot/x86_64/efi
bor@opensuse:~/src/grub> 

You may consider using xorriso to create image, it does quite good job
with hybrid images.

> For these reasons, I think it is useful to parse the El Torito boot
> catalog.
> 

I'm not entirely opposed to it, I just do not see compelling reasons to
do it :)

I actually think that viewing ESP as opaque binary executable and using
ISO as primary data location is more generic and useful. This way you
can have any amount of different platform binaries all sharing common
/boot/grub on ISO with common configuration. Also information in El
Torito boot image (as grub.cfg) is not as easily accessible as
information on ISO. Making it hard to understand what image actually
does.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] core/partmap: Add El Torito boot catalog parsing
  2015-06-08 17:50     ` Andrei Borzenkov
@ 2015-06-08 18:25       ` Ross Lagerwall
  2015-06-08 19:01         ` Andrei Borzenkov
  2015-06-08 19:31         ` Thomas Schmitt
  0 siblings, 2 replies; 12+ messages in thread
From: Ross Lagerwall @ 2015-06-08 18:25 UTC (permalink / raw)
  To: Andrei Borzenkov; +Cc: grub-devel

[-- Attachment #1: Type: text/plain, Size: 4995 bytes --]

On Mon, Jun 08, 2015 at 08:50:48PM +0300, Andrei Borzenkov wrote:
> В Mon, 8 Jun 2015 18:31:06 +0100
> Ross Lagerwall <rosslagerwall@gmail.com> пишет:
> 
> > On Mon, Jun 08, 2015 at 07:51:44PM +0300, Andrei Borzenkov wrote:
> > > В Sun,  7 Jun 2015 11:24:46 +0100
> > > Ross Lagerwall <rosslagerwall@gmail.com> пишет:
> > > 
> > > > Add a module, part_eltorito, to allow parsing of the El Torito boot
> > > > catalog into partitions. This follows the El Torito Bootable CD-ROM
> > > > Format Specification Version 1.0 and the UEFI Specification 2.5.
> > > > In cases where the specification is unclear, the code follows the UEFI
> > > > reference implementation.
> > > > 
> > > > This is useful when booting CDs in UEFI mode. Before, GRUB would not be
> > > > able to use the embedded ESP from which it was executed, so it would
> > > > have a root and prefix set to the top level of the CD. This could result
> > > > in subtle configuration bugs, because the same ISO booted from a USB
> > > > disk (using isohybrid) would have its root and prefix set to the
> > > > embedded ESP because it can find it through the MBR.
> > > 
> > > You can already access ESP on hybrid image using e.g. (cd0,msdos1); why
> > > is it not enough?
> > 
> > This is about booting a CD in UEFI mode; it may not be a hybrid disc in
> > which case it doesn't have an MBR.
> > 
> 
> So you need to either add partition label or add additional driver to
> grub.efi. The former works already and does not require any new code.
> 
> > Also, in the case of a hybrid image booted using a CD, the mismatch between
> > the 2048 byte sectors of the CD and the 512 byte sector values used in the
> > MBR means that GRUB is not able to access the correctly ESP anyway.
> > 
> 
> It may depend on how you create partition table. Neither openSUSE DVD
> nor images created by grub-mkrescue have problems. Did you actually try
> it?
> 
> As example
> 
> bor@opensuse:~/src/grub> xorriso --indev /datastore/iso/openSUSE-13.2-DVD-x86_64.iso --report-el-torito plain --report-system-area plain
> xorriso 1.3.8 : RockRidge filesystem manipulator, libburnia project.
> 
> xorriso : NOTE : Loading ISO image tree from LBA 0
> xorriso : UPDATE : 6102 nodes read in 1 seconds
> xorriso : NOTE : Detected El-Torito boot information which currently is set to be discarded
> Drive current: -indev '/datastore/iso/openSUSE-13.2-DVD-x86_64.iso'
> Media current: stdio file, overwriteable
> Media status : is written , is appendable
> Boot record  : El Torito , MBR isohybrid cyl-align-off
> Media summary: 1 session, 2284287 data blocks, 4461m data, 31.5g free
> Volume id    : 'openSUSE-13.2-DVD-x86_640051'
> El Torito catalog  : 20  1
> El Torito images   :   N  Pltf  B   Emul  Ld_seg  Hdpt  Ldsiz         LBA
> El Torito boot img :   1  BIOS  y   none  0x0000  0x00      4        5826
> El Torito boot img :   2  UEFI  y   none  0x0000  0x00      1         896
> El Torito img path :   1  /boot/x86_64/loader/isolinux.bin
> El Torito img opts :   1  boot-info-table isohybrid-suitable
> El Torito img path :   2  /boot/x86_64/efi
> System area options: 0x00000202
> System area summary: MBR isohybrid cyl-align-off
> ISO image size/512 : 9137148
> Partition offset   : 0
> MBR heads per cyl  : 0
> MBR secs per head  : 0
> MBR partition table:   N Status  Type        Start       Blocks
> MBR partition      :   1   0x00  0xef         3584         8064
> MBR partition      :   2   0x80  0x17        11648      9126528
> MBR partition path :   1  /boot/x86_64/efi
> bor@opensuse:~/src/grub> 
> 
> You may consider using xorriso to create image, it does quite good job
> with hybrid images.

Yes I have tried, and I made a video of it :-)
https://rossl.org/junk/grub.webm

See that GRUB is not able to access (cd0,msdos2), which is the embedded
FAT partition.

> 
> > For these reasons, I think it is useful to parse the El Torito boot
> > catalog.
> > 
> 
> I'm not entirely opposed to it, I just do not see compelling reasons to
> do it :)
> 
> I actually think that viewing ESP as opaque binary executable and using
> ISO as primary data location is more generic and useful. This way you
> can have any amount of different platform binaries all sharing common
> /boot/grub on ISO with common configuration. Also information in El
> Torito boot image (as grub.cfg) is not as easily accessible as
> information on ISO. Making it hard to understand what image actually
> does.
> 

Except that the ESP isn't a binary executable, the firmware presents it
as a file system and gives it to GRUB as the boot location.

As it currently stands, the configurations are not shared, because
currently when booting the image using a CD it will look for the cfg at
(cd0)/..., and when booting the same image off a USB, it will look at
the FAT partition (hd0,msdos2)/... because it knows how to find it.

Cheers,
-- 
Ross Lagerwall

[-- Attachment #2: Type: application/pgp-signature, Size: 213 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] core/partmap: Add El Torito boot catalog parsing
  2015-06-08 18:25       ` Ross Lagerwall
@ 2015-06-08 19:01         ` Andrei Borzenkov
  2015-06-20 10:16           ` Ross Lagerwall
  2015-06-08 19:31         ` Thomas Schmitt
  1 sibling, 1 reply; 12+ messages in thread
From: Andrei Borzenkov @ 2015-06-08 19:01 UTC (permalink / raw)
  To: Ross Lagerwall; +Cc: grub-devel

[-- Attachment #1: Type: text/plain, Size: 5523 bytes --]

В Mon, 8 Jun 2015 19:25:12 +0100
Ross Lagerwall <rosslagerwall@gmail.com> пишет:

> On Mon, Jun 08, 2015 at 08:50:48PM +0300, Andrei Borzenkov wrote:
> > В Mon, 8 Jun 2015 18:31:06 +0100
> > Ross Lagerwall <rosslagerwall@gmail.com> пишет:
> > 
> > > On Mon, Jun 08, 2015 at 07:51:44PM +0300, Andrei Borzenkov wrote:
> > > > В Sun,  7 Jun 2015 11:24:46 +0100
> > > > Ross Lagerwall <rosslagerwall@gmail.com> пишет:
> > > > 
> > > > > Add a module, part_eltorito, to allow parsing of the El Torito boot
> > > > > catalog into partitions. This follows the El Torito Bootable CD-ROM
> > > > > Format Specification Version 1.0 and the UEFI Specification 2.5.
> > > > > In cases where the specification is unclear, the code follows the UEFI
> > > > > reference implementation.
> > > > > 
> > > > > This is useful when booting CDs in UEFI mode. Before, GRUB would not be
> > > > > able to use the embedded ESP from which it was executed, so it would
> > > > > have a root and prefix set to the top level of the CD. This could result
> > > > > in subtle configuration bugs, because the same ISO booted from a USB
> > > > > disk (using isohybrid) would have its root and prefix set to the
> > > > > embedded ESP because it can find it through the MBR.
> > > > 
> > > > You can already access ESP on hybrid image using e.g. (cd0,msdos1); why
> > > > is it not enough?
> > > 
> > > This is about booting a CD in UEFI mode; it may not be a hybrid disc in
> > > which case it doesn't have an MBR.
> > > 
> > 
> > So you need to either add partition label or add additional driver to
> > grub.efi. The former works already and does not require any new code.
> > 
> > > Also, in the case of a hybrid image booted using a CD, the mismatch between
> > > the 2048 byte sectors of the CD and the 512 byte sector values used in the
> > > MBR means that GRUB is not able to access the correctly ESP anyway.
> > > 
> > 
> > It may depend on how you create partition table. Neither openSUSE DVD
> > nor images created by grub-mkrescue have problems. Did you actually try
> > it?
> > 
> > As example
> > 
> > bor@opensuse:~/src/grub> xorriso --indev /datastore/iso/openSUSE-13.2-DVD-x86_64.iso --report-el-torito plain --report-system-area plain
> > xorriso 1.3.8 : RockRidge filesystem manipulator, libburnia project.
> > 
> > xorriso : NOTE : Loading ISO image tree from LBA 0
> > xorriso : UPDATE : 6102 nodes read in 1 seconds
> > xorriso : NOTE : Detected El-Torito boot information which currently is set to be discarded
> > Drive current: -indev '/datastore/iso/openSUSE-13.2-DVD-x86_64.iso'
> > Media current: stdio file, overwriteable
> > Media status : is written , is appendable
> > Boot record  : El Torito , MBR isohybrid cyl-align-off
> > Media summary: 1 session, 2284287 data blocks, 4461m data, 31.5g free
> > Volume id    : 'openSUSE-13.2-DVD-x86_640051'
> > El Torito catalog  : 20  1
> > El Torito images   :   N  Pltf  B   Emul  Ld_seg  Hdpt  Ldsiz         LBA
> > El Torito boot img :   1  BIOS  y   none  0x0000  0x00      4        5826
> > El Torito boot img :   2  UEFI  y   none  0x0000  0x00      1         896
> > El Torito img path :   1  /boot/x86_64/loader/isolinux.bin
> > El Torito img opts :   1  boot-info-table isohybrid-suitable
> > El Torito img path :   2  /boot/x86_64/efi
> > System area options: 0x00000202
> > System area summary: MBR isohybrid cyl-align-off
> > ISO image size/512 : 9137148
> > Partition offset   : 0
> > MBR heads per cyl  : 0
> > MBR secs per head  : 0
> > MBR partition table:   N Status  Type        Start       Blocks
> > MBR partition      :   1   0x00  0xef         3584         8064
> > MBR partition      :   2   0x80  0x17        11648      9126528
> > MBR partition path :   1  /boot/x86_64/efi
> > bor@opensuse:~/src/grub> 
> > 
> > You may consider using xorriso to create image, it does quite good job
> > with hybrid images.
> 
> Yes I have tried, and I made a video of it :-)
> https://rossl.org/junk/grub.webm
> 
> See that GRUB is not able to access (cd0,msdos2), which is the embedded
> FAT partition.
> 

OK. What about using GPT? it definitely works, just tested.

> > 
> > > For these reasons, I think it is useful to parse the El Torito boot
> > > catalog.
> > > 
> > 
> > I'm not entirely opposed to it, I just do not see compelling reasons to
> > do it :)
> > 
> > I actually think that viewing ESP as opaque binary executable and using
> > ISO as primary data location is more generic and useful. This way you
> > can have any amount of different platform binaries all sharing common
> > /boot/grub on ISO with common configuration. Also information in El
> > Torito boot image (as grub.cfg) is not as easily accessible as
> > information on ISO. Making it hard to understand what image actually
> > does.
> > 
> 
> Except that the ESP isn't a binary executable, the firmware presents it
> as a file system and gives it to GRUB as the boot location.
> 
> As it currently stands, the configurations are not shared, because
> currently when booting the image using a CD it will look for the cfg at
> (cd0)/..., and when booting the same image off a USB, it will look at
> the FAT partition (hd0,msdos2)/... because it knows how to find it.
> 

Image created by grub-mkrescue looks at the same place whatever way it
is booted. You need to set prefix to ()/path/to/grub then it will be
auto-filled with correct boot device name.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: core/partmap: Add El Torito boot catalog parsing
  2015-06-08 18:25       ` Ross Lagerwall
  2015-06-08 19:01         ` Andrei Borzenkov
@ 2015-06-08 19:31         ` Thomas Schmitt
  1 sibling, 0 replies; 12+ messages in thread
From: Thomas Schmitt @ 2015-06-08 19:31 UTC (permalink / raw)
  To: grub-devel

Hi,

Andrei Borzenkov wrote:
> > Drive current: -indev '/datastore/iso/openSUSE-13.2-DVD-x86_64.iso'
> > [...]
> > You may consider using xorriso to create image, it does quite good job
> > with hybrid images.

Thanks for the compliment. (The openSUSE ISOs are not made by
xorriso, though, but rather by genisoimage, isohybrid, and
a head transplantation to make MBR partition 2 mountable,
if i remember correctly my curious research about
openSUSE-13.1-NET-x86_64.iso.)


Ross Lagerwall wrote:
> Yes I have tried, and I made a video of it :-)
> See that GRUB is not able to access (cd0,msdos2), which is the embedded
> FAT partition.

The trick of the others could be to let the GRUB2 software
from ESP look up and use the GRUB2 stuff in a directory of
the ISO.
So GRUB2 booted via UEFI from CD does not need to access
the ESP by own means.

A user once explained me his setup and mentioned that
he runs grub-mkimage with "--config=", "iso9660" and "search",
and that the "embedded grub.cfg" looks like
  search.fs_label RECOVERY root
  set prefix=($root)/boot/grub 


Have a nice day :)

Thomas



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] core/partmap: Add El Torito boot catalog parsing
  2015-06-08 19:01         ` Andrei Borzenkov
@ 2015-06-20 10:16           ` Ross Lagerwall
  2015-06-20 10:19             ` Vladimir 'phcoder' Serbinenko
                               ` (2 more replies)
  0 siblings, 3 replies; 12+ messages in thread
From: Ross Lagerwall @ 2015-06-20 10:16 UTC (permalink / raw)
  To: Andrei Borzenkov; +Cc: grub-devel

[-- Attachment #1: Type: text/plain, Size: 6989 bytes --]

On Mon, Jun 08, 2015 at 10:01:17PM +0300, Andrei Borzenkov wrote:
> В Mon, 8 Jun 2015 19:25:12 +0100
> Ross Lagerwall <rosslagerwall@gmail.com> пишет:
> 
> > On Mon, Jun 08, 2015 at 08:50:48PM +0300, Andrei Borzenkov wrote:
> > > В Mon, 8 Jun 2015 18:31:06 +0100
> > > Ross Lagerwall <rosslagerwall@gmail.com> пишет:
> > > 
> > > > On Mon, Jun 08, 2015 at 07:51:44PM +0300, Andrei Borzenkov wrote:
> > > > > В Sun,  7 Jun 2015 11:24:46 +0100
> > > > > Ross Lagerwall <rosslagerwall@gmail.com> пишет:
> > > > > 
> > > > > > Add a module, part_eltorito, to allow parsing of the El Torito boot
> > > > > > catalog into partitions. This follows the El Torito Bootable CD-ROM
> > > > > > Format Specification Version 1.0 and the UEFI Specification 2.5.
> > > > > > In cases where the specification is unclear, the code follows the UEFI
> > > > > > reference implementation.
> > > > > > 
> > > > > > This is useful when booting CDs in UEFI mode. Before, GRUB would not be
> > > > > > able to use the embedded ESP from which it was executed, so it would
> > > > > > have a root and prefix set to the top level of the CD. This could result
> > > > > > in subtle configuration bugs, because the same ISO booted from a USB
> > > > > > disk (using isohybrid) would have its root and prefix set to the
> > > > > > embedded ESP because it can find it through the MBR.
> > > > > 
> > > > > You can already access ESP on hybrid image using e.g. (cd0,msdos1); why
> > > > > is it not enough?
> > > > 
> > > > This is about booting a CD in UEFI mode; it may not be a hybrid disc in
> > > > which case it doesn't have an MBR.
> > > > 
> > > 
> > > So you need to either add partition label or add additional driver to
> > > grub.efi. The former works already and does not require any new code.
> > > 
> > > > Also, in the case of a hybrid image booted using a CD, the mismatch between
> > > > the 2048 byte sectors of the CD and the 512 byte sector values used in the
> > > > MBR means that GRUB is not able to access the correctly ESP anyway.
> > > > 
> > > 
> > > It may depend on how you create partition table. Neither openSUSE DVD
> > > nor images created by grub-mkrescue have problems. Did you actually try
> > > it?
> > > 
> > > As example
> > > 
> > > bor@opensuse:~/src/grub> xorriso --indev /datastore/iso/openSUSE-13.2-DVD-x86_64.iso --report-el-torito plain --report-system-area plain
> > > xorriso 1.3.8 : RockRidge filesystem manipulator, libburnia project.
> > > 
> > > xorriso : NOTE : Loading ISO image tree from LBA 0
> > > xorriso : UPDATE : 6102 nodes read in 1 seconds
> > > xorriso : NOTE : Detected El-Torito boot information which currently is set to be discarded
> > > Drive current: -indev '/datastore/iso/openSUSE-13.2-DVD-x86_64.iso'
> > > Media current: stdio file, overwriteable
> > > Media status : is written , is appendable
> > > Boot record  : El Torito , MBR isohybrid cyl-align-off
> > > Media summary: 1 session, 2284287 data blocks, 4461m data, 31.5g free
> > > Volume id    : 'openSUSE-13.2-DVD-x86_640051'
> > > El Torito catalog  : 20  1
> > > El Torito images   :   N  Pltf  B   Emul  Ld_seg  Hdpt  Ldsiz         LBA
> > > El Torito boot img :   1  BIOS  y   none  0x0000  0x00      4        5826
> > > El Torito boot img :   2  UEFI  y   none  0x0000  0x00      1         896
> > > El Torito img path :   1  /boot/x86_64/loader/isolinux.bin
> > > El Torito img opts :   1  boot-info-table isohybrid-suitable
> > > El Torito img path :   2  /boot/x86_64/efi
> > > System area options: 0x00000202
> > > System area summary: MBR isohybrid cyl-align-off
> > > ISO image size/512 : 9137148
> > > Partition offset   : 0
> > > MBR heads per cyl  : 0
> > > MBR secs per head  : 0
> > > MBR partition table:   N Status  Type        Start       Blocks
> > > MBR partition      :   1   0x00  0xef         3584         8064
> > > MBR partition      :   2   0x80  0x17        11648      9126528
> > > MBR partition path :   1  /boot/x86_64/efi
> > > bor@opensuse:~/src/grub> 
> > > 
> > > You may consider using xorriso to create image, it does quite good job
> > > with hybrid images.
> > 
> > Yes I have tried, and I made a video of it :-)
> > https://rossl.org/junk/grub.webm
> > 
> > See that GRUB is not able to access (cd0,msdos2), which is the embedded
> > FAT partition.
> > 
> 
> OK. What about using GPT? it definitely works, just tested.
> 
> > > 
> > > > For these reasons, I think it is useful to parse the El Torito boot
> > > > catalog.
> > > > 
> > > 
> > > I'm not entirely opposed to it, I just do not see compelling reasons to
> > > do it :)
> > > 
> > > I actually think that viewing ESP as opaque binary executable and using
> > > ISO as primary data location is more generic and useful. This way you
> > > can have any amount of different platform binaries all sharing common
> > > /boot/grub on ISO with common configuration. Also information in El
> > > Torito boot image (as grub.cfg) is not as easily accessible as
> > > information on ISO. Making it hard to understand what image actually
> > > does.
> > > 
> > 
> > Except that the ESP isn't a binary executable, the firmware presents it
> > as a file system and gives it to GRUB as the boot location.
> > 
> > As it currently stands, the configurations are not shared, because
> > currently when booting the image using a CD it will look for the cfg at
> > (cd0)/..., and when booting the same image off a USB, it will look at
> > the FAT partition (hd0,msdos2)/... because it knows how to find it.
> > 
> 
> Image created by grub-mkrescue looks at the same place whatever way it
> is booted. You need to set prefix to ()/path/to/grub then it will be
> auto-filled with correct boot device name.

GRUB calculates a boot device based on the device path given by the
firmware so:
With a normal CD, the firmware gives it something like
/ACPI(a3401d0,0)/PCI(1,1)/ATAPI(0,0,0)/CD,1,899,1838) which points to
the embedded ESP. GRUB doesn't know how to use that because it doesn't
know how to read the El Torito catalog so it just uses the root of the
CD as the boot device, i.e. (cd0), so the prefix becomes
(cd0)/path/to/grub.
With a hybrid USB, the firmware gives it something like
/ACPI(a3401d0,0)/PCI(1,1)/ATA(0)/HD(1,MBR,0x769FCE30,172,63488) which
GRUB finds and matches with the embedded ESP pointed to by the MBR e.g.
(hd0,msdos2), so the prefix becomes (hd0,msdos2)/path/to/grub. In other
words, the image will _not_ look at the same place whichever way it is
booted.

While Thomas's suggestion [1] does work around the issue, I think
reading the catalog is a better-engineered solution.

[1]:
"A user once explained me his setup and mentioned
he runs grub-mkimage with "--config=", "iso9660" and
and that the "embedded grub.cfg" looks like
search.fs_label RECOVERY root
set prefix=($root)/boot/grub"

Regards
-- 
Ross Lagerwall

[-- Attachment #2: Type: application/pgp-signature, Size: 213 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] core/partmap: Add El Torito boot catalog parsing
  2015-06-20 10:16           ` Ross Lagerwall
@ 2015-06-20 10:19             ` Vladimir 'phcoder' Serbinenko
  2015-06-20 13:52               ` Thomas Schmitt
  2015-06-21 11:28             ` Andrei Borzenkov
  2016-02-12 18:31             ` Vladimir 'φ-coder/phcoder' Serbinenko
  2 siblings, 1 reply; 12+ messages in thread
From: Vladimir 'phcoder' Serbinenko @ 2015-06-20 10:19 UTC (permalink / raw)
  To: The development of GRUB 2; +Cc: Andrey Borzenkov

[-- Attachment #1: Type: text/plain, Size: 7739 bytes --]

I agree with Andrei. El torito catalog contains bootable binaries. The fact
that this binary follows FAT format is purely tangential and we should not
put additional files there or access it either
Le 20 juin 2015 13:17, "Ross Lagerwall" <rosslagerwall@gmail.com> a écrit :

> On Mon, Jun 08, 2015 at 10:01:17PM +0300, Andrei Borzenkov wrote:
> > В Mon, 8 Jun 2015 19:25:12 +0100
> > Ross Lagerwall <rosslagerwall@gmail.com> пишет:
> >
> > > On Mon, Jun 08, 2015 at 08:50:48PM +0300, Andrei Borzenkov wrote:
> > > > В Mon, 8 Jun 2015 18:31:06 +0100
> > > > Ross Lagerwall <rosslagerwall@gmail.com> пишет:
> > > >
> > > > > On Mon, Jun 08, 2015 at 07:51:44PM +0300, Andrei Borzenkov wrote:
> > > > > > В Sun,  7 Jun 2015 11:24:46 +0100
> > > > > > Ross Lagerwall <rosslagerwall@gmail.com> пишет:
> > > > > >
> > > > > > > Add a module, part_eltorito, to allow parsing of the El Torito
> boot
> > > > > > > catalog into partitions. This follows the El Torito Bootable
> CD-ROM
> > > > > > > Format Specification Version 1.0 and the UEFI Specification
> 2.5.
> > > > > > > In cases where the specification is unclear, the code follows
> the UEFI
> > > > > > > reference implementation.
> > > > > > >
> > > > > > > This is useful when booting CDs in UEFI mode. Before, GRUB
> would not be
> > > > > > > able to use the embedded ESP from which it was executed, so it
> would
> > > > > > > have a root and prefix set to the top level of the CD. This
> could result
> > > > > > > in subtle configuration bugs, because the same ISO booted from
> a USB
> > > > > > > disk (using isohybrid) would have its root and prefix set to
> the
> > > > > > > embedded ESP because it can find it through the MBR.
> > > > > >
> > > > > > You can already access ESP on hybrid image using e.g.
> (cd0,msdos1); why
> > > > > > is it not enough?
> > > > >
> > > > > This is about booting a CD in UEFI mode; it may not be a hybrid
> disc in
> > > > > which case it doesn't have an MBR.
> > > > >
> > > >
> > > > So you need to either add partition label or add additional driver to
> > > > grub.efi. The former works already and does not require any new code.
> > > >
> > > > > Also, in the case of a hybrid image booted using a CD, the
> mismatch between
> > > > > the 2048 byte sectors of the CD and the 512 byte sector values
> used in the
> > > > > MBR means that GRUB is not able to access the correctly ESP anyway.
> > > > >
> > > >
> > > > It may depend on how you create partition table. Neither openSUSE DVD
> > > > nor images created by grub-mkrescue have problems. Did you actually
> try
> > > > it?
> > > >
> > > > As example
> > > >
> > > > bor@opensuse:~/src/grub> xorriso --indev
> /datastore/iso/openSUSE-13.2-DVD-x86_64.iso --report-el-torito plain
> --report-system-area plain
> > > > xorriso 1.3.8 : RockRidge filesystem manipulator, libburnia project.
> > > >
> > > > xorriso : NOTE : Loading ISO image tree from LBA 0
> > > > xorriso : UPDATE : 6102 nodes read in 1 seconds
> > > > xorriso : NOTE : Detected El-Torito boot information which currently
> is set to be discarded
> > > > Drive current: -indev '/datastore/iso/openSUSE-13.2-DVD-x86_64.iso'
> > > > Media current: stdio file, overwriteable
> > > > Media status : is written , is appendable
> > > > Boot record  : El Torito , MBR isohybrid cyl-align-off
> > > > Media summary: 1 session, 2284287 data blocks, 4461m data, 31.5g free
> > > > Volume id    : 'openSUSE-13.2-DVD-x86_640051'
> > > > El Torito catalog  : 20  1
> > > > El Torito images   :   N  Pltf  B   Emul  Ld_seg  Hdpt  Ldsiz
>  LBA
> > > > El Torito boot img :   1  BIOS  y   none  0x0000  0x00      4
> 5826
> > > > El Torito boot img :   2  UEFI  y   none  0x0000  0x00      1
>  896
> > > > El Torito img path :   1  /boot/x86_64/loader/isolinux.bin
> > > > El Torito img opts :   1  boot-info-table isohybrid-suitable
> > > > El Torito img path :   2  /boot/x86_64/efi
> > > > System area options: 0x00000202
> > > > System area summary: MBR isohybrid cyl-align-off
> > > > ISO image size/512 : 9137148
> > > > Partition offset   : 0
> > > > MBR heads per cyl  : 0
> > > > MBR secs per head  : 0
> > > > MBR partition table:   N Status  Type        Start       Blocks
> > > > MBR partition      :   1   0x00  0xef         3584         8064
> > > > MBR partition      :   2   0x80  0x17        11648      9126528
> > > > MBR partition path :   1  /boot/x86_64/efi
> > > > bor@opensuse:~/src/grub>
> > > >
> > > > You may consider using xorriso to create image, it does quite good
> job
> > > > with hybrid images.
> > >
> > > Yes I have tried, and I made a video of it :-)
> > > https://rossl.org/junk/grub.webm
> > >
> > > See that GRUB is not able to access (cd0,msdos2), which is the embedded
> > > FAT partition.
> > >
> >
> > OK. What about using GPT? it definitely works, just tested.
> >
> > > >
> > > > > For these reasons, I think it is useful to parse the El Torito boot
> > > > > catalog.
> > > > >
> > > >
> > > > I'm not entirely opposed to it, I just do not see compelling reasons
> to
> > > > do it :)
> > > >
> > > > I actually think that viewing ESP as opaque binary executable and
> using
> > > > ISO as primary data location is more generic and useful. This way you
> > > > can have any amount of different platform binaries all sharing common
> > > > /boot/grub on ISO with common configuration. Also information in El
> > > > Torito boot image (as grub.cfg) is not as easily accessible as
> > > > information on ISO. Making it hard to understand what image actually
> > > > does.
> > > >
> > >
> > > Except that the ESP isn't a binary executable, the firmware presents it
> > > as a file system and gives it to GRUB as the boot location.
> > >
> > > As it currently stands, the configurations are not shared, because
> > > currently when booting the image using a CD it will look for the cfg at
> > > (cd0)/..., and when booting the same image off a USB, it will look at
> > > the FAT partition (hd0,msdos2)/... because it knows how to find it.
> > >
> >
> > Image created by grub-mkrescue looks at the same place whatever way it
> > is booted. You need to set prefix to ()/path/to/grub then it will be
> > auto-filled with correct boot device name.
>
> GRUB calculates a boot device based on the device path given by the
> firmware so:
> With a normal CD, the firmware gives it something like
> /ACPI(a3401d0,0)/PCI(1,1)/ATAPI(0,0,0)/CD,1,899,1838) which points to
> the embedded ESP. GRUB doesn't know how to use that because it doesn't
> know how to read the El Torito catalog so it just uses the root of the
> CD as the boot device, i.e. (cd0), so the prefix becomes
> (cd0)/path/to/grub.
> With a hybrid USB, the firmware gives it something like
> /ACPI(a3401d0,0)/PCI(1,1)/ATA(0)/HD(1,MBR,0x769FCE30,172,63488) which
> GRUB finds and matches with the embedded ESP pointed to by the MBR e.g.
> (hd0,msdos2), so the prefix becomes (hd0,msdos2)/path/to/grub. In other
> words, the image will _not_ look at the same place whichever way it is
> booted.
>
> While Thomas's suggestion [1] does work around the issue, I think
> reading the catalog is a better-engineered solution.
>
> [1]:
> "A user once explained me his setup and mentioned
> he runs grub-mkimage with "--config=", "iso9660" and
> and that the "embedded grub.cfg" looks like
> search.fs_label RECOVERY root
> set prefix=($root)/boot/grub"
>
> Regards
> --
> Ross Lagerwall
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
>

[-- Attachment #2: Type: text/html, Size: 9932 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] core/partmap: Add El Torito boot catalog parsing
  2015-06-20 10:19             ` Vladimir 'phcoder' Serbinenko
@ 2015-06-20 13:52               ` Thomas Schmitt
  0 siblings, 0 replies; 12+ messages in thread
From: Thomas Schmitt @ 2015-06-20 13:52 UTC (permalink / raw)
  To: grub-devel

Hi,

not that i would want to interfere with GRUB2 development
decisions. Nevertheless, i have some comments from the view
of the specs.

Vladimir Serbinenko wrote:
> El torito catalog contains bootable binaries.

UEFI 2.4 9.3.6.2 "CD-ROM Media Device Path"
"The CD-ROM Media Device Path is used to define a system partition
 that exists on a CD-ROM. The CD-ROM is assumed to contain an
 ISO-9660 file system and follow the CD-ROM “El Torito” format.
 [...] In EFI the bootable entity is an EFI System Partition that
 is pointed to by the Boot Entry."

According to El Torito 1.0 the boot images may be emulated
disk-like devices or executable binaries for the given
platform:

2.0 "ISO-9660 and the Booting Catalog"
"The image may be virtualized into INT 13 drive number 00 or 80
 for bootable disk emulation, or [... some BIOS shortcut ...].
 The image may also simply be some code which will be loaded at
 boot time (no emulation)."

UEFI pierces a little hole into the theory of running on an
emulated disk by prescribing the "no emulation" mark in the
boot catalog which for BIOS means: load and execute binary.

12.3.2.1 "ISO-9660 and El Torito"
"[...] To boot from a CD-ROM or DVD-ROM in the boot services
 environment, an EFI System partition is stored in a “no emulation”
 mode as defined by the “El Torito” specification. [...]
 EFI differs from “El Torito” “no emulation” mode in that it does
 not load the “no emulation” image into memory and jump to it.
 EFI interprets the “no emulation” image as an EFI system partition."

------------------------------------------------------------------

So i think the general role of an El Torito boot image is not a
strong reason to reject its view as full flegded EFI system
partition.
But i see other reasons to restrict its role to an opaque launcher
for software in a directory of the ISO:

The El Torito catalog format implies size restriction to 32 MB.
EFI allows open end by size 0, but that's really not very neat.

I assume the higher boot stages of BIOS and EFI can share a lot of
GRUB2 software. The GRUB2 software needed for BIOS traditionally
resides in ISO 9660 directories.
So it is easier and less error prone to re-use it there rather
than changing the BIOS boot procedure to finding the ESP and
using its software.


Have a nice day :)

Thomas



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] core/partmap: Add El Torito boot catalog parsing
  2015-06-20 10:16           ` Ross Lagerwall
  2015-06-20 10:19             ` Vladimir 'phcoder' Serbinenko
@ 2015-06-21 11:28             ` Andrei Borzenkov
  2016-02-12 18:31             ` Vladimir 'φ-coder/phcoder' Serbinenko
  2 siblings, 0 replies; 12+ messages in thread
From: Andrei Borzenkov @ 2015-06-21 11:28 UTC (permalink / raw)
  To: Ross Lagerwall; +Cc: grub-devel

[-- Attachment #1: Type: text/plain, Size: 5048 bytes --]

В Sat, 20 Jun 2015 11:16:47 +0100
Ross Lagerwall <rosslagerwall@gmail.com> пишет:

> 
> GRUB calculates a boot device based on the device path given by the
> firmware so:

It is not quite true. GRUB will auofill device part if it is not
present, keeping partition.

> With a normal CD, the firmware gives it something like
> /ACPI(a3401d0,0)/PCI(1,1)/ATAPI(0,0,0)/CD,1,899,1838) which points to
> the embedded ESP. GRUB doesn't know how to use that because it doesn't
> know how to read the El Torito catalog so it just uses the root of the
> CD as the boot device, i.e. (cd0), so the prefix becomes
> (cd0)/path/to/grub.
> With a hybrid USB, the firmware gives it something like
> /ACPI(a3401d0,0)/PCI(1,1)/ATA(0)/HD(1,MBR,0x769FCE30,172,63488) which
> GRUB finds and matches with the embedded ESP pointed to by the MBR e.g.
> (hd0,msdos2), so the prefix becomes (hd0,msdos2)/path/to/grub. In other
> words, the image will _not_ look at the same place whichever way it is
> booted.
> 


bor@opensuse:~> /usr/sbin/fdisk -l /tmp/usb

Disk /tmp/usb: 10 MiB, 10485760 bytes, 20480 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A89483C6-73F0-43C7-B35E-1D62107C7362

Device       Start   End Sectors Size Type
/tmp/usb2  2048 20446   18399   9M Linux filesystem
bor@opensuse:~> sudo losetup
NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE
/dev/loop0         0      0         0  0 /tmp/usb
bor@opensuse:~> sudo mount /dev/loop0p2 /mnt
bor@opensuse:~> sudo pkgdatadir=$PWD ./grub-install -d grub-core --boot-directory=/mnt --efi-directory=/mnt --removable

bor@opensuse:~/src/grub> virtvm -drive file=/tmp/usb,if=virtio,media=disk,readonly -bios /usr/share/qemu/ovmf-x86_64.bin -serial stdio
...
                          GNU GRUB  version 2.02~beta2

   Minimal BASH-like line editing is supported. For the first word, TAB   
   lists possible command completions. Anywhere else TAB lists possible   
   device or file completions.                                            


grub> set
cmdpath=(hd0,gpt2)/EFI/BOOT
color_highlight=black/light-gray
color_normal=light-gray/black
feature_200_final=y
feature_all_video_module=y
feature_chainloader_bpb=y
feature_default_font_path=y
feature_menuentry_id=y
feature_menuentry_options=y
feature_nativedisk_cmd=y
feature_ntldr=y
feature_platform_search_hint=y
feature_timeout_style=y
grub_cpu=x86_64
grub_platform=efi
lang=
locale_dir=
pager=
prefix=(hd0,gpt2)/grub
root=hd0,gpt2
secondary_locale_dir=
grub> halt


bor@opensuse:~> dd if=/dev/loop0p2 of=/tmp/efi.img
bor@opensuse:~> xorriso -outdev /tmp/efi.iso -as mkisofs -graft-points --efi-boot /efi.img -efi-boot-part --efi-boot-image /efi.img=/tmp/efi.img
xorriso 1.3.8 : RockRidge filesystem manipulator, libburnia project.

Drive current: -outdev '/tmp/efi.iso'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, 39.5g free
Added to ISO image: file '/efi.img'='/tmp/efi.img'
xorriso : UPDATE : 1 files added in 1 seconds
xorriso : UPDATE : 1 files added in 1 seconds
ISO image produced: 4800 sectors
Written to medium : 4800 sectors at LBA 0
Writing to '/tmp/efi.iso' completed successfully.

bor@opensuse:~/src/grub> virtvm -cd /tmp/efi.iso -bios /usr/share/qemu/ovmf-x86_64.bin -serial stdio
...
                         GNU GRUB  version 2.02~beta2

   Minimal BASH-like line editing is supported. For the first word, TAB   
   lists possible command completions. Anywhere else TAB lists possible   
   device or file completions.                                            


grub> set
cmdpath=(cd0)/EFI/BOOT
color_highlight=black/light-gray
color_normal=light-gray/black
feature_200_final=y
feature_all_video_module=y
feature_chainloader_bpb=y
feature_default_font_path=y
feature_menuentry_id=y
feature_menuentry_options=y
feature_nativedisk_cmd=y
feature_ntldr=y
feature_platform_search_hint=y
feature_timeout_style=y
grub_cpu=x86_64
grub_platform=efi
lang=
locale_dir=
pager=
prefix=(cd0,gpt2)/grub
root=cd0,gpt2
secondary_locale_dir=
grub> halt



> While Thomas's suggestion [1] does work around the issue, I think
> reading the catalog is a better-engineered solution.

What's wrong with the above? Note that it works using standard commands
and does not even require manual image creation. What is missing here?

BTW using explicit el-torito partition grub-install could not be used.

The reason to use GPT is block size difference. In principle it may be
possible to rewrite BPB when adding it to ISO to adjust for different
sector size.

> 
> [1]:
> "A user once explained me his setup and mentioned
> he runs grub-mkimage with "--config=", "iso9660" and
> and that the "embedded grub.cfg" looks like
> search.fs_label RECOVERY root
> set prefix=($root)/boot/grub"
> 
> Regards


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] core/partmap: Add El Torito boot catalog parsing
  2015-06-20 10:16           ` Ross Lagerwall
  2015-06-20 10:19             ` Vladimir 'phcoder' Serbinenko
  2015-06-21 11:28             ` Andrei Borzenkov
@ 2016-02-12 18:31             ` Vladimir 'φ-coder/phcoder' Serbinenko
  2 siblings, 0 replies; 12+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2016-02-12 18:31 UTC (permalink / raw)
  To: grub-devel

[-- Attachment #1: Type: text/plain, Size: 276 bytes --]

On 20.06.2015 12:16, Ross Lagerwall wrote:
> GRUB calculates a boot device based on the device path given by the
> firmware so:
Please reread what Andrei said. GRUB combines stored prefix and
information from firmware. Syntax ()/boot/grub will always use the full disk


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2016-02-12 18:31 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-07 10:24 [PATCH] core/partmap: Add El Torito boot catalog parsing Ross Lagerwall
2015-06-08 16:51 ` Andrei Borzenkov
2015-06-08 17:31   ` Ross Lagerwall
2015-06-08 17:50     ` Andrei Borzenkov
2015-06-08 18:25       ` Ross Lagerwall
2015-06-08 19:01         ` Andrei Borzenkov
2015-06-20 10:16           ` Ross Lagerwall
2015-06-20 10:19             ` Vladimir 'phcoder' Serbinenko
2015-06-20 13:52               ` Thomas Schmitt
2015-06-21 11:28             ` Andrei Borzenkov
2016-02-12 18:31             ` Vladimir 'φ-coder/phcoder' Serbinenko
2015-06-08 19:31         ` Thomas Schmitt

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.