mkrelpath doesn't do what it should...

mkrelpath doesn't do what it should...

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

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.

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

[Felix Zielcke]

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

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

[David Miller]

From: Felix Zielcke <fzielcke@z-51.de>
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.

Thanks I'll have a look.

Locally for testing, I changed the 10_linux script to pass the
complete image path name to the device root relative pathname
resolver.  That worked just as well.

In fact I don't see why these scripts don't do that, and relatively
resolve the /boot directory whatever seperately.

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

[Felix Zielcke]

Am Montag, den 07.12.2009, 03:24 -0800 schrieb David Miller:
> In fact I don't see why these scripts don't do that, and relatively
> resolve the /boot directory whatever seperately. 

Because it's faster to just call once for the directory
make_system_path_relative_to_its_root() instead of once for every kernel
you have.
Colin even added caching for prepare_grub_to_access_device() because it
can be slow if you have many many kernels.
-- 
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

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

[David Miller]

From: Felix Zielcke <fzielcke@z-51.de>
Date: Mon, 07 Dec 2009 23:06:46 +0100

> Am Montag, den 07.12.2009, 03:24 -0800 schrieb David Miller:
>> In fact I don't see why these scripts don't do that, and relatively
>> resolve the /boot directory whatever seperately. 
> 
> Because it's faster to just call once for the directory
> make_system_path_relative_to_its_root() instead of once for every kernel
> you have.
> Colin even added caching for prepare_grub_to_access_device() because it
> can be slow if you have many many kernels.

Ok, makes sense, thanks for explaining.

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

[David Miller]

From: Felix Zielcke <fzielcke@z-51.de>
Date: Mon, 07 Dec 2009 11:39:22 +0100

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

Seems to work properly now.  The paths all start with "//" but
I guess that's ok.

Thanks!