Re: Support for sunxi-based ARM systems in d-i
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.
Reply to: