r2558 made another use case for make_relative_to_its_root visible (else SEGFAULT)

r2558 made another use case for make_relative_to_its_root visible (else SEGFAULT)

[Felix Zielcke]

r2558 actually enabled this code path which was (almost) never executed
before in probe():

      if (S_ISREG (st.st_mode))
        {
          /* Regular file.  Verify that we can read it properly.  */

          grub_file_t file;
          grub_util_info ("reading %s via OS facilities", path);
          filebuf_via_sys = grub_util_read_image (path);

          grub_util_info ("reading %s via GRUB facilities", path);
          asprintf (&grub_path, "(%s)%s", drive_name, path);
          file = grub_file_open (grub_path);
          filebuf_via_grub = xmalloc (file->size);
          grub_file_read (file, filebuf_via_grub, file->size);

          grub_util_info ("comparing");

          if (memcmp (filebuf_via_grub, filebuf_via_sys, file->size))
            grub_util_error ("files differ");
        }
      printf ("%s\n", fs->name);

If /boot is on a seperate partition and you run `grub-probe -t
fs /boot/grub/core.img' grub_file_open returns 0 because grub_path is
the full system path and not a relative path which GRUB needs.


-- 
Felix Zielcke
Proud Debian Maintainer

Re: r2558 made another use case for make_relative_to_its_root visible (else SEGFAULT)

[Robert Millan]

On Fri, Sep 04, 2009 at 08:52:44PM +0200, Felix Zielcke wrote:
> r2558 actually enabled this code path which was (almost) never executed
> before in probe():
> 
>       if (S_ISREG (st.st_mode))
>         {
>           /* Regular file.  Verify that we can read it properly.  */
> 
>           grub_file_t file;
>           grub_util_info ("reading %s via OS facilities", path);
>           filebuf_via_sys = grub_util_read_image (path);
> 
>           grub_util_info ("reading %s via GRUB facilities", path);
>           asprintf (&grub_path, "(%s)%s", drive_name, path);
>           file = grub_file_open (grub_path);
>           filebuf_via_grub = xmalloc (file->size);
>           grub_file_read (file, filebuf_via_grub, file->size);
> 
>           grub_util_info ("comparing");
> 
>           if (memcmp (filebuf_via_grub, filebuf_via_sys, file->size))
>             grub_util_error ("files differ");
>         }
>       printf ("%s\n", fs->name);
> 
> If /boot is on a seperate partition and you run `grub-probe -t
> fs /boot/grub/core.img' grub_file_open returns 0 because grub_path is
> the full system path and not a relative path which GRUB needs.

A proper fix for this would be too intrusive for 1.97.  Unless someone
has a bright idea, I'll comment it out untill we've released.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: r2558 made another use case for make_relative_to_its_root visible (else SEGFAULT)

[Felix Zielcke]

Am Freitag, den 04.09.2009, 21:26 +0200 schrieb Robert Millan:
> On Fri, Sep 04, 2009 at 08:52:44PM +0200, Felix Zielcke wrote:
> > r2558 actually enabled this code path which was (almost) never executed
> > before in probe():
> > 
> >       if (S_ISREG (st.st_mode))
> >         {
> >           /* Regular file.  Verify that we can read it properly.  */
> > 
> >           grub_file_t file;
> >           grub_util_info ("reading %s via OS facilities", path);
> >           filebuf_via_sys = grub_util_read_image (path);
> > 
> >           grub_util_info ("reading %s via GRUB facilities", path);
> >           asprintf (&grub_path, "(%s)%s", drive_name, path);
> >           file = grub_file_open (grub_path);
> >           filebuf_via_grub = xmalloc (file->size);
> >           grub_file_read (file, filebuf_via_grub, file->size);
> > 
> >           grub_util_info ("comparing");
> > 
> >           if (memcmp (filebuf_via_grub, filebuf_via_sys, file->size))
> >             grub_util_error ("files differ");
> >         }
> >       printf ("%s\n", fs->name);
> > 
> > If /boot is on a seperate partition and you run `grub-probe -t
> > fs /boot/grub/core.img' grub_file_open returns 0 because grub_path is
> > the full system path and not a relative path which GRUB needs.
> 
> A proper fix for this would be too intrusive for 1.97.  Unless someone
> has a bright idea, I'll comment it out untill we've released.

For the release this is probable the best idea.


-- 
Felix Zielcke
Proud Debian Maintainer

Re: r2558 made another use case for make_relative_to_its_root visible (else SEGFAULT)

[Colin Watson]

On Sat, Sep 05, 2009 at 08:25:01PM +0200, Felix Zielcke wrote:
> Am Freitag, den 04.09.2009, 21:26 +0200 schrieb Robert Millan:
> > On Fri, Sep 04, 2009 at 08:52:44PM +0200, Felix Zielcke wrote:
> > > r2558 actually enabled this code path which was (almost) never executed
> > > before in probe():
> > 
> > A proper fix for this would be too intrusive for 1.97.  Unless someone
> > has a bright idea, I'll comment it out untill we've released.
> 
> For the release this is probable the best idea.

Agreed. Sorry for this regression.

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: r2558 made another use case for make_relative_to_its_root visible (else SEGFAULT)

[Robert Millan]

On Sat, Sep 05, 2009 at 09:04:19PM +0100, Colin Watson wrote:
> On Sat, Sep 05, 2009 at 08:25:01PM +0200, Felix Zielcke wrote:
> > Am Freitag, den 04.09.2009, 21:26 +0200 schrieb Robert Millan:
> > > On Fri, Sep 04, 2009 at 08:52:44PM +0200, Felix Zielcke wrote:
> > > > r2558 actually enabled this code path which was (almost) never executed
> > > > before in probe():
> > > 
> > > A proper fix for this would be too intrusive for 1.97.  Unless someone
> > > has a bright idea, I'll comment it out untill we've released.
> > 
> > For the release this is probable the best idea.
> 
> Agreed.

Ok, done.

> Sorry for this regression.

Not your fault!  Hopefully I'll remember to re-enable this after 1.97 is
released.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."