On Wed, 2014-04-30 at 22:26 +0200, Karsten Merker wrote:

Oops, there was more!

> diff --git a/functions b/functions
> index 02f7381..3322eb0 100644
> --- a/functions
> +++ b/functions
> @@ -582,13 +582,17 @@ case "$method" in
>               fi
>               if [ -n "$boot_kernel_path" ]; then
>                       boot_kernel_path="$boot_mnt_dir/$boot_kernel_path"
> -                     # don't mv the original kernel
> +                     # If we have built a modified version of the kernel
> +                     # (uImage, machine-id prepended, etc.), then move
> +                     # this modified version to its destination and make
> +                     # a backup copy of the previous modified version.
> +                     # Otherwise just copy the original kernel to its
> +                     # destination.
>                       if [ "$kernel" != "$kfile" ]; then
>                               backup_and_install "$kernel" \
>                                       "$boot_kernel_path"
>                       else
> -                             # TODO add support for kernel symlink
> -                             :
> +                             cp -f "$kernel" "$boot_kernel_path"

Are these symlinks not created automatically by the kernel package?

I think it would be better to put the actual kernel/initrd path (i.e.
with the version suffix) directly into the boot.scr rather than creating
a link to the kernel just to launch it with.

I'd also like to see boot.scr-$version as the actual file and boot.scr
as a link to the latest (with f-k creating boot.scr-$version for all
installed versions). That's probably a separate project though

> The original TODO remarks speak of symlinking, but this would
> only work if the destination of the link is on the same
> filesystem as the link itself, as the bootloader could not resolve
> a cross-filesystem symlink.  This would in particular fail when
> using a Boot-Device entry to mount a seperate firmware boot
> partition, so I simply copy the kernel to its target position.

I think it would be fine to assume that no separate firmware boot
partition was being used in this mode, at least until such a platform
turns up (sunxi doesn't want/need it AFAIK).

Ian.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1398929812.23380.109.ca...@dagon.hellion.org.uk

Reply via email to