On Sat, 2014-05-10 at 18:46 +0200, Karsten Merker wrote:
> On Thu, May 08, 2014 at 09:20:33PM +0100, Ian Campbell wrote:
> > On Tue, 2014-05-06 at 21:24 +0200, Karsten Merker wrote:
> > > So this means that on an armhf system set up by d-i, the symlinks
> > > are actually in place where we need them for the boot scripts. I
> > > am very short on time at the moment, so I can't work on the
> > > topic now, but I'll look into it again some time later this week.
> >
> > It was mostly a case of cherry picking the bits of your patch which were
> > still needed and since I had a few spare moments this evening it took a
> > stab at it (I hope that's ok), the result is attached.
> ^^^^^^^^^^^^^^^^
> Of course!
>
> > Works for me on a DI installed system with 3.14-1-armmp built from SVN.
> > My u-boot bootcmd is:
> > scsi scan;setenv device scsi;setenv partition 0;load ${device}
> > ${partition} ${scriptaddr} boot.scr;source ${scriptaddr}
>
> I have run a few tests with your patchset and everything looks ok
> as far as I can tell. Attached is a tiny additional patch to the
> manpage to document the new "--force" option.
I've applied this, added debian/changelog entries as necessary and
pushed the whole lot to flash-kernel.git.
I also added a second doc commit with:
+Note that when the \-\-force the kernel can be overwritten with the current
+version whenever a package is installed which changes the kernel, initramfs
+etc. Therefore this is only really useful for one-off testing.
+.P
since it might be a bit surprising the --force is undone by e.g.
installing/upgrading a package which supplies an mkinitramfs hook
I deliberately haven't uploaded yet due to the .isinstallable issue you
mention below. Unless anyone thinks it is worth having this now? Maybe
an upload to experimental is in order?
Ian.
>
> While running the tests I have stumbled over another issue that needs
> to be tackled with regard to d-i. Currently flash-kernel is not run
> within d-i on an armhf/armmp system, due to
> flash-kernel-installer.isinstallable only allowing it to be run for
> specific archdetect results (covering iop32x, ixp4xx, kirkwood, mx5,
> orion5x and s3c24xx). Is there a specific reason why machine support
> is checked using a list of archdetect results and not directly via the
> flash-kernel machine db using the according functions (which are both
> available in the flash-kernel-installer udeb)?
>
> Having a separate list based on archdetect means additional information
> to keep up to date and has other problems as well in the context of
> multiplatform kernels: when adding armhf/generic to the list,
> flash-kernel gets run in the "make the system bootable" step, but it
> causes d-i do stop with a rather unspecific error if the particular
> system is technically supported by the armmp kernel but does not have a
> machine db entry in flash-kernel. Responsible is the following
> fragment of the flash-kernel main() function:
>
> if ! check_supported "$machine"; then
> error "Unsupported platform."
> fi
>
> which exits with a return code of 1 and causes d-i to output
>
> Installation step failed
> An installation step failed. You can try to run the failing item
> again from the menu, or skip it and choose something else. The
> failing step is: Make the system bootable
>
> When checking platform support flash-kernel-installer.isinstallable
> based on the flash-kernel machine db, this problem does not occur.
>
> Regards,
> Karsten
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/1399922469.15871.13.ca...@hastur.hellion.org.uk
