On Mon, 2014-05-05 at 17:25 +0200, Karsten Merker wrote:
> On Thu, May 01, 2014 at 08:36:52AM +0100, Ian Campbell wrote:
> > On Wed, 2014-04-30 at 22:26 +0200, Karsten Merker wrote:
>
> > > 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
>
> Hello,
>
> while I think the changes you have in mind are a worthy goal, I
> would like to get basic sunxi support into flash-kernel rather
> sooner than later to have it available with the release of d-i
> jessie alpha 2. My patch is in line with the existing behaviour
> of flash-kernel, so I would really like to see it integrated now
> instead of being deferred until after a (possibly larger) rewrite
> of the flash-kernel code base, which is basically unrelated to
> adding sunxi support, has happened.
I didn't mean to suggest otherwise, the "I'd also like to see" was more
musing on the future than asking you to do something now ("probably a
separate project").
> > > 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).
>
> That is of course a valid design decision, but as it would break
> the currently documented/expected behaviour of the Boot-Device
> keyword in flash-kernel for a part of the use cases,
I was talking specifically about the case where Boot-Device wasn't used,
nothing should change when it is, because you have to copy things in
that case.
> I'd
> personally prefer copying to symlinking. A compromise could be
> to use copying when Boot-Device is defined and to use symlinking
> otherwise. Would that be acceptable to you?
Yes, but I'm not sure why either is necessary on this platform, can you
really not just use the vmlinuz/initrd.img symlinks which the Debian
kernel packages create? IOW I don't think you need to set
Boot-{Kernel,Initrd}-Path on this platform either, and then you avoid
this can of worms too.
This is what Ubuntu's flash-kernel does on highbank which is a similar
situation.
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/1399306741.19277.238.ca...@hastur.hellion.org.uk
