grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: handling mount points in grub-mkrelpath


From: Robert Millan
Subject: Re: handling mount points in grub-mkrelpath
Date: Fri, 4 Dec 2009 22:23:32 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

On Sun, Nov 29, 2009 at 09:52:32PM +0100, Felix Zielcke wrote:
> Vladimir wanted to have this discussed on ML
> 
> The old shell function make_system_path_relative_to_its_root outputed /
> if you gave it /boot and it was on a seperate partition.
> grub-mkrelpath currently outputs /boot
> 
> This breaks booting at least with the 10_linux generated entries.
> 
> Attached is my fix for that, which I'll update today to Debian.
> 
> We already broke backward compatibility with the commandline for Xen.
> IMO in this grub-mkrelpath case there's no need to break compatibility.
> 
> But maybe I can find a good way to handle this inside
> util/grub-mkconfig_lib.in just for compatibility.

Hi,

The old behaviour seems correct, so there's no need to break compatibility.

Please could you commit this in trunk?


> 2009-11-29 Felix Zielcke <address@hidden>
> 
>       * util/misc.c (make_system_path_relative_to_its_root): Correctly cope 
> with
>       mount points.
> === modified file 'util/misc.c'
> --- util/misc.c       2009-11-25 23:10:02 +0000
> +++ util/misc.c       2009-11-29 19:19:28 +0000
> @@ -500,7 +500,17 @@ make_system_path_relative_to_its_root (c
>  
>        /* buf is another filesystem; we found it.  */
>        if (st.st_dev != num)
> -     break;
> +     {
> +       /* offset == 0 means path given is the mount point.  */
> +       if (offset == 0)
> +         {
> +           free (buf);
> +           free (buf2);
> +           return strdup ("/");
> +         }
> +       else
> +         break;
> +     }
>  
>        offset = p - buf;
>        /* offset == 1 means root directory.  */
> 

> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel


-- 
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."




reply via email to

[Prev in Thread] Current Thread [Next in Thread]