grub-devel
[Top][All Lists]
Advanced

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

Re: mkrelpath doesn't do what it should...


From: Felix Zielcke
Subject: Re: mkrelpath doesn't do what it should...
Date: Mon, 07 Dec 2009 11:39:22 +0100

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 via email to

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