All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felix Zielcke <fzielcke@z-51.de>
To: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: mkrelpath doesn't do what it should...
Date: Mon, 07 Dec 2009 11:39:22 +0100	[thread overview]
Message-ID: <1260182362.2908.5.camel@fz.local> (raw)
In-Reply-To: <20091206.233053.45905914.davem@davemloft.net>

Am Sonntag, den 06.12.2009, 23:30 -0800 schrieb David Miller:
> I was trying to figure out why the kernel image paths generated
> automatically for me by grub-mkconfig were not correct.
> 
> I have /boot on a seperate partition, but in the generated config
> files it uses paths like /boot/vmlinux-2632 etc.
> 
> The problem is grub-mkrelpath and it's usage in the scrips such as
> "10_linux".
> 
> "/boot" is given to "grub-mkrelpath", and this results in
> the identical "/boot" in rel_dirname.
> 
> So all the paths emitted by 10_linux end up being "/boot" based
> instead of "/" based.
> 
> grub-mkrelpath seems to do the right thing if I pass it a full path,
> f.e. giving it "/boot/vmlinux" emits the correct "/vmlinux"

The one mount point case is now fixed in r1917
See Subject: `handling mount points in grub-mkrelpath' from me for the
patch.

> Casually inspecting make_system_path_relative_to_its_root() shows what
> appears to be another bug.  It seems to immediately break from the
> loop when a different device number than "/"'s is seen, but what if I
> have:
> 
> /one/two/three
> 
> Where / is /dev/hda1, /one/two is /dev/hda2 and /one/two/three is yet
> another mount from /dev/hda3.  It seems like the premature loop exit
> in this function will give us the wrong result here.
> 
> The loop needs to remember the string prefix point at which every
> device number change occurs, and once the whole path has been
> traversed it should unwind back to that point in order to emit
> the result.

Multiple mount points are an interesting case. Haven't thought about
them.
But they should be now handled correctly too.

-- 
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer




  reply	other threads:[~2009-12-07 10:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-07  7:30 mkrelpath doesn't do what it should David Miller
2009-12-07 10:39 ` Felix Zielcke [this message]
2009-12-07 11:24   ` David Miller
2009-12-07 22:06     ` Felix Zielcke
2009-12-07 23:18       ` David Miller
2009-12-08  4:35   ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1260182362.2908.5.camel@fz.local \
    --to=fzielcke@z-51.de \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.