Bug#870615: debian-installer: FTBFS on armhf: missing firefly-rk3288/u-boot.img

[Vagrant Cascadian]

Control: severity 870615 important

On 2017-08-03, Vagrant Cascadian wrote:
> On 2017-08-03, Cyril Brulebois wrote:
>> d-i now FTBFSes on armhf, due to:
>> ,---[ hd-media ]---
>> | gen-hd-image: Installing /usr/lib/u-boot/firefly-rk3288/u-boot-spl.rksd at 
>> sector 64 ...
>> | gen-hd-image: Installing /usr/lib/u-boot/firefly-rk3288/u-boot.img at 
>> sector 256 ...
>> | config/armhf//hd-media.cfg:33: recipe for target 
>> 'hd-media_images_concatenateable' failed
...
>> I suppose this is due to this change in u-boot on 2017-08-01:
>> |  u-boot (2017.07+dfsg1-2) unstable; urgency=medium
>> |  .
>> |* u-boot-rockchip:
>> |  - Ship u-boot.bin in firefly-rk3288 instead of u-boot.img.
>> |  - Add NEWS file explaining the change for firefly-rk3288.
>>
>> See https://tracker.debian.org/news/860117
...
> This may actually require changing the d-i code(the new method requires
> appending two things together before dd'ing them, rather that dd'ing two
> things at specific locations), or more changes to u-boot (I could
> pregenerate that part in u-boot, though that means shipping redundant
> bits).
>
> Might be best to temporarily disable the firefly-rk3288 in d-i until I
> figure out what's best to do...

I've disabled it in git for now, will explore a proper fix soon.

live well,
  vagrant


signature.asc
Description: PGP signature

Processed: Re: Bug#870615: debian-installer: FTBFS on armhf: missing firefly-rk3288/u-boot.img

[Debian Bug Tracking System]

Processing control commands:

> severity 870615 important
Bug #870615 [src:debian-installer] debian-installer: FTBFS on armhf: missing 
firefly-rk3288/u-boot.img
Severity set to 'important' from 'serious'

-- 
870615: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870615
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#860304: [BUG 860304] flash-kernel: Incorrect installation path for dtbs

[Heinrich Schuchardt]

Hello Vagrant,

May 26th you indicated you would like to fix the problem after the
Stretch release date.

Any news so far?

Best regards

Heinrich

Bug#870628: Please warn about slow starts on USB

[Holger Wansing]

Hi 

Am Donnerstag 3. August 2017 schrieb Samuel Thibault:
> Holger Wansing, on jeu. 03 août 2017 17:38:46 +, wrote:
> > Am Donnerstag 3. August 2017 schrieb Steve McIntyre:
> > > On Thu, Aug 03, 2017 at 05:18:58PM +0200, Jean-Michel Vourgère wrote:
> > > >Package: installation-guide-amd64
> > > >Severity: normal
> > > >
> > > >Hello
> > > >
> > > >I recently installed form scratch a Stretch to an old computer using an 
> > > >USB
> > > >stick.
> > > >
> > > >The "boot menu" show and I hit enter for "Graphical Install". And then I
> > > >though it crashed. Twice. The keys don't make the menu move. Caps lock 
> > > >key
> > > >doesn't work.
> > > >It actually took 2'10" to show next menu "Select a language".
> > > >
> > > >I believe section "5.1.1 Booting from USB Memory Stick" should warn
> > > >about possible big delays.
> > > 
> > > This is really not normal. What system are you running (walking?) on?
> > 
> > Might be "normal", when booting from a USB 1.0 port or stick?
> 
> The gtk initrd is like 38MB, at USB 1.0 speed (1.5Mbps) that's almost
> two minutes yes.  I however wonder how old a computer needs to be to be
> only 1.0...

As I wrote: maybe the computer is a new one, but the stick is
an old one with 1.0-only capabilities...

Holger

-- 
Sent from my Jolla phone
http://www.jolla.com/

Bug#870430: linux-image-4.9.0-3-marvell: Couldn't find DTB in /usr/lib/linux-image-4.9.0-3-marvell or /etc/flash-kernel/dtbs

[Ian Campbell]

On Wed, 2017-08-02 at 21:29 +0200, noone never wrote:
> Please find my answers inline.

Thanks! In particular for...

> [...]
> > The message:
> >     Couldn't find DTB  in /usr/lib/linux-image-4.9.0-3-marvell or
> > /etc/flash-kernel/dtbs
> > is interesting since the double space in "DTB  in" is supposed to
> > contain $dtb_name, i.e. the path to look for, but it doesn't not.
> > Please could you attach the full output of running `sh -x
> > /usr/sbin/flash-kernel`, maybe that will include a clue as to where
> > things have gone astray.
> 
> Log is attached 

... this.

Looking at uses of dtb in you trace:
$ grep dtb ~/tmp/flash-kernel-log.txt
[...]
+ dtb_name=kirkwood-sheevaplug.dtb
+ '[' -n kirkwood-sheevaplug.dtb ']'
+ echo 'Using DTB: kirkwood-sheevaplug.dtb'
Using DTB: kirkwood-sheevaplug.dtb

So dtb_name is successfully assigned and reported here.

+ handle_dtb
+ '[' xkirkwood-sheevaplug.dtb = x ']'
+ local dtb
+ local dtb_name

But here it is redeclared as a local shadowing the original, but
unassigned.

++ find_dtb_file
++ local dtb
++ case "$dtb_name" in
+++ find /etc/flash-kernel/dtbs -name
++ dtb=
++ dtb=
++ error 'Couldn'\''t find DTB  in /usr/lib/linux-image-4.9.0-3-marvell or 
/etc/flash-kernel/dtbs'
++ echo 'Couldn'\''t find DTB  in /usr/lib/linux-image-4.9.0-3-marvell or 
/etc/flash-kernel/dtbs'
Couldn't find DTB  in /usr/lib/linux-image-4.9.0-3-marvell or 
/etc/flash-kernel/dtbs

and we end up using the blank version here.

I have a suspicious this was introduced by the fix to #836697 in [0]
which seems to have added the shadowing "local dtb_name".

It's a bit naughty but if you edit /usr/share/flash-kernel/functions
and  near the top of handle_dtb() change the:
local dtb
local dtb_name
into
local dtb
local dtb_name=$(basename $dtb_name)

and then remove the "dtb_name=$(basename $dtb_name)" from both halves
of the following if statement, does that fix it?

Martin, does that fix seem correct to you?

I think the "local dtb" bit could also move into the else have with the
"dtb=$(find_dtb_file)" as well, but that would be an unrelated change.

This ultimately seems to be down to a difference in the behaviour of
/bin/dash vs /bin/bash, which I suppose is why it has not been widely
seen:

$ cat > t.sh 

Bug#870628: Please warn about slow starts on USB

[Lennart Sorensen]

On Thu, Aug 03, 2017 at 07:55:09PM +0200, Samuel Thibault wrote:
> The gtk initrd is like 38MB, at USB 1.0 speed (1.5Mbps) that's almost
> two minutes yes.  I however wonder how old a computer needs to be to be
> only 1.0...

I have never seen a machine with only 1.0 USB that could boot from USB.
I don't think the concept of booting from USB existed until we had USB 2.
It was just too slow to comprehend trying.

And how could a 64bit machine have only USB 1.0?  Not a chance.

Now if the USB key happens to be a Kingston Datatraveller G3 like the
one on my desk, then I can believe it taking forever and crashing.
That thing is an unreliable piece of crap that somehow claims to be USB3.

-- 
Len Sorensen

Bug#870628: Please warn about slow starts on USB

[Samuel Thibault]

Holger Wansing, on jeu. 03 août 2017 17:38:46 +, wrote:
> Am Donnerstag 3. August 2017 schrieb Steve McIntyre:
> > On Thu, Aug 03, 2017 at 05:18:58PM +0200, Jean-Michel Vourgère wrote:
> > >Package: installation-guide-amd64
> > >Severity: normal
> > >
> > >Hello
> > >
> > >I recently installed form scratch a Stretch to an old computer using an USB
> > >stick.
> > >
> > >The "boot menu" show and I hit enter for "Graphical Install". And then I
> > >though it crashed. Twice. The keys don't make the menu move. Caps lock key
> > >doesn't work.
> > >It actually took 2'10" to show next menu "Select a language".
> > >
> > >I believe section "5.1.1 Booting from USB Memory Stick" should warn
> > >about possible big delays.
> > 
> > This is really not normal. What system are you running (walking?) on?
> 
> Might be "normal", when booting from a USB 1.0 port or stick?

The gtk initrd is like 38MB, at USB 1.0 speed (1.5Mbps) that's almost
two minutes yes.  I however wonder how old a computer needs to be to be
only 1.0...

Samuel

Bug#870628: Please warn about slow starts on USB

[Holger Wansing]

Hi,

Am Donnerstag 3. August 2017 schrieb Steve McIntyre:
> On Thu, Aug 03, 2017 at 05:18:58PM +0200, Jean-Michel Vourgère wrote:
> >Package: installation-guide-amd64
> >Severity: normal
> >
> >Hello
> >
> >I recently installed form scratch a Stretch to an old computer using an USB
> >stick.
> >
> >The "boot menu" show and I hit enter for "Graphical Install". And then I
> >though it crashed. Twice. The keys don't make the menu move. Caps lock key
> >doesn't work.
> >It actually took 2'10" to show next menu "Select a language".
> >
> >I believe section "5.1.1 Booting from USB Memory Stick" should warn
> >about possible big delays.
> 
> This is really not normal. What system are you running (walking?) on?

Might be "normal", when booting from a USB 1.0 port or stick?

Holger 

-- 
Sent from my Jolla phone
http://www.jolla.com/

Bug#870628: Please warn about slow starts on USB

[Steve McIntyre]

On Thu, Aug 03, 2017 at 05:18:58PM +0200, Jean-Michel Vourgère wrote:
>Package: installation-guide-amd64
>Severity: normal
>
>Hello
>
>I recently installed form scratch a Stretch to an old computer using an USB
>stick.
>
>The "boot menu" show and I hit enter for "Graphical Install". And then I
>though it crashed. Twice. The keys don't make the menu move. Caps lock key
>doesn't work.
>It actually took 2'10" to show next menu "Select a language".
>
>I believe section "5.1.1 Booting from USB Memory Stick" should warn
>about possible big delays.

This is really not normal. What system are you running (walking?) on?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
The two hard things in computing:
 * naming things
 * cache invalidation
 * off-by-one errors  -- Stig Sandbeck Mathisen

Bug#870628: Please warn about slow starts on USB

[Jean-Michel Vourgère]

Package: installation-guide-amd64
Severity: normal

Hello

I recently installed form scratch a Stretch to an old computer using an USB
stick.

The "boot menu" show and I hit enter for "Graphical Install". And then I
though it crashed. Twice. The keys don't make the menu move. Caps lock key
doesn't work.
It actually took 2'10" to show next menu "Select a language".

I believe section "5.1.1 Booting from USB Memory Stick" should warn
about possible big delays.

partman-auto-lvm_60_i386.changes ACCEPTED into unstable

[Debian FTP Masters]

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 03 Aug 2017 14:28:21 +0200
Source: partman-auto-lvm
Binary: partman-auto-lvm
Architecture: source all
Version: 60
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Christian Perrier 
Description:
 partman-auto-lvm - Automatically partition storage devices using LVM (udeb)
Closes: 759553
Changes:
 partman-auto-lvm (60) unstable; urgency=medium
 .
   [ Vincent McIntyre ]
   * Don't use 'stat' in auto-lvm.sh, it doesn't work. Use -e instead.
 Closes: #759553
Checksums-Sha1:
 93ea82f203e885f328db6a17e8162a8324cb2515 1692 partman-auto-lvm_60.dsc
 59ce5715cc5817d5f9f65705be10b710154cdfae 86772 partman-auto-lvm_60.tar.xz
 11d04bb5bf6641c52ace8de2cff84276329b27c7 71560 partman-auto-lvm_60_all.udeb
 c97bca473b969ead258322d1f9d8f9e065dbbfb1 4299 
partman-auto-lvm_60_i386.buildinfo
Checksums-Sha256:
 037f81dec417ef4ac882936ed73b7cb8f04aea07dfa05db220b293b01d0c4728 1692 
partman-auto-lvm_60.dsc
 33d26437a0fdda119969803ebabf39356f8c40d2623fd1c7ab4c01b57ec2fbb2 86772 
partman-auto-lvm_60.tar.xz
 545362d4167eee9b6f331c622dd641aae6628ed6adda32023c69cdb4672d1793 71560 
partman-auto-lvm_60_all.udeb
 c8a71c530a93880456f7fb7663d71e7a1fc4ecd9def4dcad18d1195e8e44dacf 4299 
partman-auto-lvm_60_i386.buildinfo
Files:
 1d72895330a1db4f682bb5c3f539dfd8 1692 debian-installer optional 
partman-auto-lvm_60.dsc
 1774e967af280c50220d487401eabcf5 86772 debian-installer optional 
partman-auto-lvm_60.tar.xz
 988b9e1b537d771ec6a6f693d2d3dc2c 71560 debian-installer optional 
partman-auto-lvm_60_all.udeb
 e1d15bf1db34bf1c8f53c61e71abeeda 4299 debian-installer optional 
partman-auto-lvm_60_i386.buildinfo

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJZgyIJAAoJEIcvcCxNbiWoQQYP/2ZjEF96GGEs1IJmUixzFqIi
YQi2SCZXG9edfGgCjRo9L8kQTDMgvzAE/mvSICkRCpLE/Nw1Ngp2CtEpUAX4WcVW
/lQgzAKUffu2NrOdPdwhIiO1e/AWJarNk1ISyQ/8Nn/J/ASwjINktT7EekCVylex
t0waTqAhuMmrvN71+qvW7xZatRSrGgzFNEBMFa/4H9A1InKdlMekL0uJdaRFPJ7H
F+RvL+uUtD25VzMUIKdlOH/HfqClPpSgH28oYXmEPTR9K78fNjlWFwed1KrTMGx/
nX2hQdZy9q7JD7gYFuSFGWbWziuBZPt5FPB+v2ljEqAUEgKWk64hHEsfwTCC7itc
ef8m7ApQaIW+jBTMOE4pJChXZpSiCWDJ0QscH2HWLRYzsiOZQlHilZOIU/OUccRQ
3WS3AMbcWg5atJ762PKUDM1pX/rpE5Sa44TVt/9blyqxSq5Y0OaMm98JSTtsyZCD
NDKRaORvDYRAYk+ZqVIcM6oFfwMV8yGNf9BUVKVQRCRyuQTL1ZrbKczcPemyOudx
NhR0b2JRIV2uszWb8GQjWHLq0wV8RFfjahAmRHsH6IWfuNVE4IvByvK3/jMEfaoW
kcqw6McgYI5Jfo/Yt2VDeEHhq2bhzk3kGra9vE4ji8qzRzQ9NXDqa/GHdVhvwOfK
AlWfH0kqPNQ0H+qzzomf
=ENW2
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

Processing of partman-auto-lvm_60_i386.changes

[Debian FTP Masters]

partman-auto-lvm_60_i386.changes uploaded successfully to localhost
along with the files:
  partman-auto-lvm_60.dsc
  partman-auto-lvm_60.tar.xz
  partman-auto-lvm_60_all.udeb
  partman-auto-lvm_60_i386.buildinfo

Greetings,

Your Debian queue daemon (running on host usper.debian.org)

Bug#759553: marked as done (partman-auto-lvm: Script uses nonexisting 'stat' binary in d-i)

[Debian Bug Tracking System]

Your message dated Thu, 03 Aug 2017 13:34:12 +
with message-id 
and subject line Bug#759553: fixed in partman-auto-lvm 60
has caused the Debian Bug report #759553,
regarding partman-auto-lvm: Script uses nonexisting 'stat' binary in d-i
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
759553: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759553
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: partman-auto-lvm
Version: 54
Severity: minor
User: debian-...@lists.debian.org
Usertags: debian-edu

While investigating a failing debootstrap (probably bug #633782), I came
across a strange message in the d-i syslog:

  main-menu[185]: (process:7514): /bin/autopartition-lvm: line 1: stat:
  not found

I checked, and there is no stat program available in the d-i
environment.  The code in question is probably in
/lib/partman/lib/auto-lvm.sh.  I lokated this fragment in
http://anonscm.debian.org/cgit/d-i/partman-auto-lvm.git/tree/lib/auto-lvm.sh >:

  if ! vg_get_info "$defvgname" && ! stat "/dev/$defvgname"; then

The 'stat' call always fail because there is no stat binary provided by
busybox.  Should it be rewritten or busybox extended?

Automatic partitioning seem to work, so the error do not seem to be
fatal.

-- 
Happy hacking
Petter Reinholtdsen
--- End Message ---
--- Begin Message ---
Source: partman-auto-lvm
Source-Version: 60

We believe that the bug you reported is fixed in the latest version of
partman-auto-lvm, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 759...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Christian Perrier  (supplier of updated partman-auto-lvm 
package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 03 Aug 2017 14:28:21 +0200
Source: partman-auto-lvm
Binary: partman-auto-lvm
Architecture: source all
Version: 60
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Christian Perrier 
Description:
 partman-auto-lvm - Automatically partition storage devices using LVM (udeb)
Closes: 759553
Changes:
 partman-auto-lvm (60) unstable; urgency=medium
 .
   [ Vincent McIntyre ]
   * Don't use 'stat' in auto-lvm.sh, it doesn't work. Use -e instead.
 Closes: #759553
Checksums-Sha1:
 93ea82f203e885f328db6a17e8162a8324cb2515 1692 partman-auto-lvm_60.dsc
 59ce5715cc5817d5f9f65705be10b710154cdfae 86772 partman-auto-lvm_60.tar.xz
 11d04bb5bf6641c52ace8de2cff84276329b27c7 71560 partman-auto-lvm_60_all.udeb
 c97bca473b969ead258322d1f9d8f9e065dbbfb1 4299 
partman-auto-lvm_60_i386.buildinfo
Checksums-Sha256:
 037f81dec417ef4ac882936ed73b7cb8f04aea07dfa05db220b293b01d0c4728 1692 
partman-auto-lvm_60.dsc
 33d26437a0fdda119969803ebabf39356f8c40d2623fd1c7ab4c01b57ec2fbb2 86772 
partman-auto-lvm_60.tar.xz
 545362d4167eee9b6f331c622dd641aae6628ed6adda32023c69cdb4672d1793 71560 
partman-auto-lvm_60_all.udeb
 c8a71c530a93880456f7fb7663d71e7a1fc4ecd9def4dcad18d1195e8e44dacf 4299 
partman-auto-lvm_60_i386.buildinfo
Files:
 1d72895330a1db4f682bb5c3f539dfd8 1692 debian-installer optional 
partman-auto-lvm_60.dsc
 1774e967af280c50220d487401eabcf5 86772 debian-installer optional 
partman-auto-lvm_60.tar.xz
 988b9e1b537d771ec6a6f693d2d3dc2c 71560 debian-installer optional 
partman-auto-lvm_60_all.udeb
 e1d15bf1db34bf1c8f53c61e71abeeda 4299 debian-installer optional 
partman-auto-lvm_60_i386.buildinfo

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJZgyIJAAoJEIcvcCxNbiWoQQYP/2ZjEF96GGEs1IJmUixzFqIi
YQi2SCZXG9edfGgCjRo9L8kQTDMgvzAE/mvSICkRCpLE/Nw1Ngp2CtEpUAX4WcVW
/lQgzAKUffu2NrOdPdwhIiO1e/AWJarNk1ISyQ/8Nn/J/ASwjINktT7EekCVylex
t0waTqAhuMmrvN71+qvW7xZatRSrGgzFNEBMFa/4H9A1InKdlMekL0uJdaRFPJ7H
F+RvL+uUtD25VzMUIKdlOH/HfqClPpSgH28oYXmEPTR9K78fNjlWFwed1KrTMGx/
nX2hQdZy9q7JD7gYFuSFGWbWziuBZPt5FPB+v2ljEqAUEgKWk64hHEsfwTCC7itc
ef8m7ApQaIW+jBTMOE4pJChXZpSiCWDJ0QscH2HWLRYzsiOZQlHilZOIU/OUccRQ
3WS3AMbcWg5atJ762PKUDM1pX/rpE5Sa44TVt/9blyqxSq5Y0OaMm98JSTtsyZCD
NDKRaORvDYRAYk+ZqVIcM6oFfwMV8yGNf9BUVKVQRCRyuQTL1ZrbKczcPemyOudx

Bug#870615: debian-installer: FTBFS on armhf: missing firefly-rk3288/u-boot.img

[Vagrant Cascadian]

On 2017-08-03, Cyril Brulebois wrote:
> d-i now FTBFSes on armhf, due to:
> ,---[ hd-media ]---
> | gen-hd-image: Installing /usr/lib/u-boot/firefly-rk3288/u-boot-spl.rksd at 
> sector 64 ...
> | gen-hd-image: Installing /usr/lib/u-boot/firefly-rk3288/u-boot.img at 
> sector 256 ...
> | config/armhf//hd-media.cfg:33: recipe for target 
> 'hd-media_images_concatenateable' failed
> | make[2]: *** [hd-media_images_concatenateable] Error 1
...
> ,---[ u-boot ]---
> | Providing u-boot binaries for Firefly-RK3288 ...
> | cp: cannot stat '/usr/lib/u-boot/firefly-rk3288/u-boot.img': No such file 
> or directory
> | config/armhf//u-boot.cfg:8: recipe for target 'u-boot-binaries' failed
> `---
>
> I suppose this is due to this change in u-boot on 2017-08-01:
> |  u-boot (2017.07+dfsg1-2) unstable; urgency=medium
> |  .
> |* u-boot-rockchip:
> |  - Ship u-boot.bin in firefly-rk3288 instead of u-boot.img.
> |  - Add NEWS file explaining the change for firefly-rk3288.
>
> See https://tracker.debian.org/news/860117
>
> It'd be nice if someone could double check what new path is needed, and
> push a commit to master after a test build. Otherwise I'll do so in a
> couple of days.

I'm sorry, my mistake, I totally forgot about u-boot's impact on
debian-installer again... *sigh*

This may actually require changing the d-i code(the new method requires
appending two things together before dd'ing them, rather that dd'ing two
things at specific locations), or more changes to u-boot (I could
pregenerate that part in u-boot, though that means shipping redundant
bits).

Might be best to temporarily disable the firefly-rk3288 in d-i until I
figure out what's best to do...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#870615: debian-installer: FTBFS on armhf: missing firefly-rk3288/u-boot.img

[Cyril Brulebois]

Source: debian-installer
Severity: serious
Justification: FTBFS

[vagrant@ in x-d-cc]

Hi,

d-i now FTBFSes on armhf, due to:
,---[ hd-media ]---
| gen-hd-image: Installing /usr/lib/u-boot/firefly-rk3288/u-boot-spl.rksd at 
sector 64 ...
| gen-hd-image: Installing /usr/lib/u-boot/firefly-rk3288/u-boot.img at sector 
256 ...
| config/armhf//hd-media.cfg:33: recipe for target 
'hd-media_images_concatenateable' failed
| make[2]: *** [hd-media_images_concatenateable] Error 1
`---

,---[ netboot ]---
| gen-hd-image: Installing /usr/lib/u-boot/firefly-rk3288/u-boot-spl.rksd at 
sector 64 ...
| gen-hd-image: Installing /usr/lib/u-boot/firefly-rk3288/u-boot.img at sector 
256 ...
| config/armhf//netboot.cfg:40: recipe for target 
'netboot_images_concatenateable' failed
| make[2]: *** [netboot_images_concatenateable] Error 1
`---

,---[ u-boot ]---
| Providing u-boot binaries for Firefly-RK3288 ...
| cp: cannot stat '/usr/lib/u-boot/firefly-rk3288/u-boot.img': No such file or 
directory
| config/armhf//u-boot.cfg:8: recipe for target 'u-boot-binaries' failed
`---

I suppose this is due to this change in u-boot on 2017-08-01:
|  u-boot (2017.07+dfsg1-2) unstable; urgency=medium
|  .
|* u-boot-rockchip:
|  - Ship u-boot.bin in firefly-rk3288 instead of u-boot.img.
|  - Add NEWS file explaining the change for firefly-rk3288.

See https://tracker.debian.org/news/860117

It'd be nice if someone could double check what new path is needed, and
push a commit to master after a test build. Otherwise I'll do so in a
couple of days.

Thanks already!


KiBi.