Re: Bug#832004: jessie-pu: package wpa/2.3-1+deb8u4

[Cyril Brulebois]

Adam D. Barratt  (2016-07-30):
> On Wed, 2016-07-27 at 15:07 +0200, Andrew Shadura wrote:
> > On 21/07/16 12:19, Adam D. Barratt wrote:
> > > 
> > > On 2016-07-21 11:01, Adam D. Barratt wrote:
> > >> Control: tags -1 -moreinfo +confirmed
> > > [...]
> > >> +wpa (2.3-1+deb8u4) jessie-security; urgency=medium
> > >>
> > >> The distribution there should be "jessie" (and was in the earlier
> > >> diff). With that changed, please feel free to go ahead.
> > > 
> > > Actually, hold on that. It was just pointed out to me that the patches
> > > aren't in unstable yet - that needs to happen first.
> > 
> > How about now? :)
> 
> The package was uploaded, and looks okay to me - -boot?

No objections, thanks.


KiBi.


signature.asc
Description: Digital signature

Bug#833097: flash-kernel: should exist when DTB doesn't exist

[Martin Michlmayr]

Package: flash-kernel
Version: 3.68

At the moment, flash-kernel doesn't exit when the DTB doesn't exist.
It will print the DTB to be used but then not copy it.  That will
result in devices not being able to boot.

Ian, is there a reason why we *don't* want to exit?

Right now we have:

get_dtb_name() prints "DTB: $dtb_name"

handle_dtb() returns if there's no DTB.

If there's a DTB, handle_dtb() will call
local dtb=$(find_dtb_file)

But then it only copies the DTB if the file exists:
if [ -e "$dtb" ]; then
and there's no "else".

Surely if a DTB is specified ($dtb_name is not empty) we need the DTB
so there should be an

else
error "Cannot find DTB file $dtb"
fi

Is there a situation where we want to continue without the DTB file?

-- 
Martin Michlmayr
http://www.cyrius.com/

Re: flash-kernel: handle DTBs in vendor subdir

[Martin Michlmayr]

* Ian Campbell  [2016-07-31 10:20]:
> I've attached the two patches I had sitting in my branch here, they
> look sensible but I honestly can't remember what state they are in.
> 
> AFAICT the main difference is that they preserve the directory layout
> rather than collapsing it. Not sure there is any particular reason to
> favour either way of doing it so feel free to either ignore or pickup
> these patches.

The boot script looks for dtbs/${fk_kvers}/${fdtfile} and $fdtfile
doesn't contain the vendor subdir, so I think this approach is wrong.

> One thing my patches handles which I'm not sure yours does is the pre-
> subdir-transition versions on ARM64, which my commit log says happened
> in v3.19-rc1. That might be important for backports and/or upgrades.

I looked at your other patch and I like the approach since it supports
the old and new way.  Personally I found search_for_dtb_file_in_prefix
a bit hard to read and wonder if a simple 'find' might do.

What do you think of this approach?  This no longer requires the
vendor subdir in DTB-Id.  I think this is better since e.g. the RPi3
has the same device tree on 32 and 64 bit and I assume one will be in
a vendor subdir whereas the other won't be.

Any comments?

diff --git a/README b/README
index 02ba3fd..9458a23 100644
--- a/README
+++ b/README
@@ -115,9 +115,13 @@ The supported fields are:
   This option is ignored if a DTB is to be appended, via either DTB-Append or
   DTB-Append-From.
 
-* DTB-Id: (optional) specifies the name of the DTB file for this device. If
-  the value begins with a `!' then the field is a script which should be run.
-  The script must produce the DTB filename (and nothing else) on stdout.
+* DTB-Id: (optional) specifies the name of the DTB file for this device
+  relative to the kernel package DTB dir or /etc/flash-kernel/dtbs.
+  It's not necessary to specify the directory if the DTB is in a vendor
+  subdirectory as flash-kernel will search for the filename in
+  subdirectories.  If the value begins with a `!' then the field is a script
+  which should be run.  The script must produce the DTB filename (just the
+  filename, without a vendor subdirectory) on stdout (and nothing else).
 
 * DTB-Append: (optional) when yes the DTB specified by DTB-Id will be appended
   to the kernel image.
diff --git a/functions b/functions
index 0f597b8..f008515 100644
--- a/functions
+++ b/functions
@@ -241,6 +241,12 @@ get_dtb_name() {
;;
esac
if [ -n "$dtb_name" ] ; then
+   # DTBs on arm64 are stored in subdirs for each vendor; strip
+   # the dir away (in case someone specified it, although it's
+   # not needed).
+   # The DTB will be stored in /boot/dtbs/$kvers/ without
+   # additional subdirs.
+   dtb_name=$(basename $dtb_name)
echo "DTB: $dtb_name" >&2
fi
 }
@@ -558,11 +564,11 @@ find_dtb_file() {
echo "$dtb_name"
;;
*)
-   if [ -e "/etc/flash-kernel/dtbs/$dtb_name" ] ; then
-   echo "/etc/flash-kernel/dtbs/$dtb_name"
-   else
-   echo "/usr/lib/linux-image-$kvers/$dtb_name"
+   local dtb=$(find /etc/flash-kernel/dtbs -name $dtb_name 
2>/dev/null | head -n 1)
+   if [ -z "$dtb" ]; then
+   dtb=$(find /usr/lib/linux-image-$kvers -name $dtb_name 
2>/dev/null | head -n 1)
fi
+   echo $dtb
;;
esac
 }
@@ -597,8 +603,8 @@ handle_dtb() {
rmdir --ignore-fail-on-non-empty /boot/dtbs
fi
else
-   if [ -e $dtb ]; then
-   echo "Installing $dtb_name into 
/boot/dtbs/$kvers/$dtb_name" >&2
+   if [ -e "$dtb" ]; then
+   echo "Installing $dtb into /boot/dtbs/$kvers/$dtb_name" 
>&2
mkdir -p /boot/dtbs/$kvers/
cp "$dtb" "/boot/dtbs/$kvers/$dtb_name.new"
backup_and_install \

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#809611: d-i fails to boot on HP mv2120

[Mike Thompson]

Hi Martin,

Sure.  It may take me a few days to get some time, but I'll give it a try
and let you know how it goes.

Mike

On Sat, Jul 30, 2016 at 7:23 PM, Martin Michlmayr  wrote:

> Mike, can you please give these instructions a go?  This is what I
> intend to post to the mv2120 list.
>
> --
>
> Mike Thompson reported that Debian stretch (the upcoming Debian 9)
> doesn't boot on the HP mv2120 anymore.  I don't know how many Debian
> users are left who run Debian on their mv2120.  I gave away my device
> several years ago.  Recently I bought an mv2120 from eBay in order to
> debug this issue.
>
> While I found a solution, it requires users to change a setting on their
> device.  Please make sure to make this change, otherwise your device
> will no longer boot when you upgrade to Debian 9.
>
> The new settings are compatible with Debian 8 (jessie) and Debian 9
> (stretch), so I suggest you make the changes now.
>
> If you have serial console access to the mv2120, you can run some
> commands in u-boot.  Simply interrupt the boot process by pressing a key
> and type the following:
>
> setenv loadAddr 0x060
> setenv bootcmd 'bootext2 0,1:1,2 0x060 /boot/uImage /dev/sda
> /dev/sdb'
> saveenv
>
> If you don't have a serial console, you can make the changes from within
> Debian.  Run the following commands:
>
> cat >/etc/fw_env.config < /dev/mtd0   0x0 0x1000 0x2
> EOF
>
> fw_setenv loadAddr 0x060
> fw_setenv bootcmd "bootext2 0,1:1,2 0x060 /boot/uImage /dev/sda
> /dev/sdb"
>
> This will create a config file so you can modify the u-boot environment
> and use fw_setenv to update two boot variables.
>
> Once you made the changes, upgrades to Debian 9 should work fine and you
> can also use the Debian installer if you want to perform a new
> installation.
>
> Please note that Debian 9 will be the last release to support the HP
> mv2120.
>
> --
>
> Note that the installer from
>
> https://d-i.debian.org/daily-images/armel/daily/orion5x/network-console/hp/mv2120/netboot.img
> will not boot right now with these settings.  However, you can change the
> loadAddr to 0x050 and it should work.  I just commited a fix in Git so
> it should work in a day or so with 0x060.
>
> --
> Martin Michlmayr
> http://www.cyrius.com/
>

Re: flash-kernel: arm64 doesn't have bootz

[Martin Michlmayr]

* Ian Campbell  [2016-07-31 10:14]:
> > Are all arm64 boards only going to support booti and not bootz?
> 
> bootz refers to the zImage which is only an ARM image type and not an
> ARM64 one, which is an Image and hence booti.

And according to this email, all arm64 boards will have booti soon:
http://lists.denx.de/pipermail/u-boot/2016-July/262385.html

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#833072: Can't create armel chroot using debootstrap - Invalid Release file, no entry for main/binary-armel/Packages

[Martin Michlmayr]

* Jeffrey Walton  [2016-07-31 11:42]:
> Primarily because its a port: https://www.debian.org/ports/ and
> https://www.debian.org/ports/arm/ .
> 
> Other, lesser reasons include there's no documentation (follow the
> links above), and using non-port procedures fails sooner than the
> ports procedure:

ports.debian.org is for ports that are not officially part of Debian.
I realize this isn't obvious.

> I: Running command: debootstrap --arch armel --foreign --keyring
> /usr/share/keyrings/debian-archive-keyring.gpg --variant=buildd
> --exclude=debfoster unstable debian-armel http://ftp.debian.org/

You have to use http://ftp.debian.org/debian

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#833072: marked as done (Can't create armel chroot using debootstrap - Invalid Release file, no entry for main/binary-armel/Packages)

[Debian Bug Tracking System]

Your message dated Sun, 31 Jul 2016 17:14:14 +0100
with message-id <20160731161414.gx13...@einval.com>
and subject line Re: Bug#833072: Can't create armel chroot using debootstrap - 
Invalid Release file, no entry for main/binary-armel/Packages
has caused the Debian Bug report #833072,
regarding Can't create armel chroot using debootstrap - Invalid Release file, 
no entry for main/binary-armel/Packages
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.)


-- 
833072: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833072
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: debootstrap
Version: 1.0.81
Severity: important

The host computer is running Debian Sid, fully patched.

Results from host computer:

I: Running command: debootstrap --arch armel --foreign --keyring
/usr/share/keyrings/debian-ports-archive-keyring.gpg --variant=buildd
--exclude=debfoster unstable debian-armel
http://ftp.ports.debian.org/debian-ports
I: Retrieving Release
I: Retrieving Release.gpg
I: Checking Release signature
I: Valid Release signature (key id 69DDB0560EA86E87E83599B3B4C86482705A2CE1)
E: Invalid Release file, no entry for main/binary-armel/Packages

sources.list from host computer:

deb http://ftp.us.debian.org/debian/ sid main contrib
# deb http://ftp.us.debian.org/debian/ sid/updates main contrib

# deb http://ftp.us.debian.org/debian/ sid-updates main
# deb http://security.debian.org/ sid/updates main

debootstrap from host computer:

Package: debootstrap
Version: 1.0.81
Installed-Size: 249
Maintainer: Debian Install System Team 
Architecture: all
Depends: wget
Recommends: gnupg, debian-archive-keyring
Description-en: Bootstrap a basic Debian system
 debootstrap is used to create a Debian base system from scratch,
 without requiring the availability of dpkg or apt. It does this by
 downloading .deb files from a mirror site, and carefully unpacking them
 into a directory which can eventually be chrooted into.
Description-md5: 883a8efb3ed16248b0d2091d9c0b60c9
Tag: admin::virtualization, devel::debian, implemented-in::shell,
 interface::commandline, protocol::http, role::program, scope::utility,
 suite::debian, works-with-format::tar, works-with::software:package
Section: admin
Priority: extra
Filename: pool/main/d/debootstrap/debootstrap_1.0.81_all.deb
Size: 65524
MD5sum: 1e445b445adb9316a62b2fc1981c10a4
SHA256: 688fbb3f414778437fe81f776dff15eaa797428f9dd99efe9cfa23eab7a38780
--- End Message ---
--- Begin Message ---
On Sun, Jul 31, 2016 at 11:42:28AM -0400, Jeffrey Walton wrote:
>>>Results from host computer:
>>>
>>>I: Running command: debootstrap --arch armel --foreign --keyring
>>>/usr/share/keyrings/debian-ports-archive-keyring.gpg --variant=buildd
>>>--exclude=debfoster unstable debian-armel
>>>http://ftp.ports.debian.org/debian-ports
>>>I: Retrieving Release
>>>I: Retrieving Release.gpg
>>>I: Checking Release signature
>>>I: Valid Release signature (key id 69DDB0560EA86E87E83599B3B4C86482705A2CE1)
>>>E: Invalid Release file, no entry for main/binary-armel/Packages
>>
>> Why are you trying to use debian-ports for armel? armel is a standard
>> Debian release architecture...
>
>Primarily because its a port: https://www.debian.org/ports/ and
>https://www.debian.org/ports/arm/ .
>
>Other, lesser reasons include there's no documentation (follow the
>links above), and using non-port procedures fails sooner than the
>ports procedure:
>
>I: Running command: debootstrap --arch armel --foreign --keyring
>/usr/share/keyrings/debian-archive-keyring.gpg --variant=buildd
>--exclude=debfoster unstable debian-armel http://ftp.debian.org/
>I: Retrieving Release
>E: Failed getting release file http://ftp.debian.org/dists/unstable/Release

You've got the wrong base URL there for the Debian archive; try

  http://ftp.debian.org/debian/

instead and it should work:

tack:~/tmp$ sudo debootstrap --arch armel --foreign --keyring
/usr/share/keyrings/debian-archive-keyring.gpg --exclude=debfoster
unstable debian-armel http://ftp.debian.org/debian/
I: Retrieving Release 
I: Retrieving Release.gpg 
I: Checking Release signature
I: Valid Release signature (key id
126C0D24BD8A2942CC7DF8AC7638D0442B90D010)
I: Retrieving Packages 
^CE: Interrupt caught ... exiting

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
We don't need no education.
We don't need no thought control.--- End Message ---

Bug#833072: Can't create armel chroot using debootstrap - Invalid Release file, no entry for main/binary-armel/Packages

[Jeffrey Walton]

>>Results from host computer:
>>
>>I: Running command: debootstrap --arch armel --foreign --keyring
>>/usr/share/keyrings/debian-ports-archive-keyring.gpg --variant=buildd
>>--exclude=debfoster unstable debian-armel
>>http://ftp.ports.debian.org/debian-ports
>>I: Retrieving Release
>>I: Retrieving Release.gpg
>>I: Checking Release signature
>>I: Valid Release signature (key id 69DDB0560EA86E87E83599B3B4C86482705A2CE1)
>>E: Invalid Release file, no entry for main/binary-armel/Packages
>
> Why are you trying to use debian-ports for armel? armel is a standard
> Debian release architecture...

Primarily because its a port: https://www.debian.org/ports/ and
https://www.debian.org/ports/arm/ .

Other, lesser reasons include there's no documentation (follow the
links above), and using non-port procedures fails sooner than the
ports procedure:

I: Running command: debootstrap --arch armel --foreign --keyring
/usr/share/keyrings/debian-archive-keyring.gpg --variant=buildd
--exclude=debfoster unstable debian-armel http://ftp.debian.org/
I: Retrieving Release
E: Failed getting release file http://ftp.debian.org/dists/unstable/Release

I would be awesome if someone would clearly document the procedure.

Jeff

Bug#833072: Can't create armel chroot using debootstrap - Invalid Release file, no entry for main/binary-armel/Packages

[Steve McIntyre]

On Sun, Jul 31, 2016 at 09:42:23AM -0400, Jeffrey Walton wrote:
>Package: debootstrap
>Version: 1.0.81
>Severity: important
>
>The host computer is running Debian Sid, fully patched.
>
>Results from host computer:
>
>I: Running command: debootstrap --arch armel --foreign --keyring
>/usr/share/keyrings/debian-ports-archive-keyring.gpg --variant=buildd
>--exclude=debfoster unstable debian-armel
>http://ftp.ports.debian.org/debian-ports
>I: Retrieving Release
>I: Retrieving Release.gpg
>I: Checking Release signature
>I: Valid Release signature (key id 69DDB0560EA86E87E83599B3B4C86482705A2CE1)
>E: Invalid Release file, no entry for main/binary-armel/Packages

Why are you trying to use debian-ports for armel? armel is a standard
Debian release architecture...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Welcome my son, welcome to the machine.

Bug#833072: Can't create armel chroot using debootstrap - Invalid Release file, no entry for main/binary-armel/Packages

[Jeffrey Walton]

Package: debootstrap
Version: 1.0.81
Severity: important

The host computer is running Debian Sid, fully patched.

Results from host computer:

I: Running command: debootstrap --arch armel --foreign --keyring
/usr/share/keyrings/debian-ports-archive-keyring.gpg --variant=buildd
--exclude=debfoster unstable debian-armel
http://ftp.ports.debian.org/debian-ports
I: Retrieving Release
I: Retrieving Release.gpg
I: Checking Release signature
I: Valid Release signature (key id 69DDB0560EA86E87E83599B3B4C86482705A2CE1)
E: Invalid Release file, no entry for main/binary-armel/Packages

sources.list from host computer:

deb http://ftp.us.debian.org/debian/ sid main contrib
# deb http://ftp.us.debian.org/debian/ sid/updates main contrib

# deb http://ftp.us.debian.org/debian/ sid-updates main
# deb http://security.debian.org/ sid/updates main

debootstrap from host computer:

Package: debootstrap
Version: 1.0.81
Installed-Size: 249
Maintainer: Debian Install System Team 
Architecture: all
Depends: wget
Recommends: gnupg, debian-archive-keyring
Description-en: Bootstrap a basic Debian system
 debootstrap is used to create a Debian base system from scratch,
 without requiring the availability of dpkg or apt. It does this by
 downloading .deb files from a mirror site, and carefully unpacking them
 into a directory which can eventually be chrooted into.
Description-md5: 883a8efb3ed16248b0d2091d9c0b60c9
Tag: admin::virtualization, devel::debian, implemented-in::shell,
 interface::commandline, protocol::http, role::program, scope::utility,
 suite::debian, works-with-format::tar, works-with::software:package
Section: admin
Priority: extra
Filename: pool/main/d/debootstrap/debootstrap_1.0.81_all.deb
Size: 65524
MD5sum: 1e445b445adb9316a62b2fc1981c10a4
SHA256: 688fbb3f414778437fe81f776dff15eaa797428f9dd99efe9cfa23eab7a38780

Bug#833053: Syntax error in the script that setupcon outputs

[Geert Stappers]

Control: tag -1 patch
stop

On Sun, Jul 31, 2016 at 07:02:03PM +0900, Jonny wrote:
> --- /a/setupcon
> +++ /b/setupcon
> @@ -911,7 +911,7 @@
>  if ls /dev/fb* >/dev/null 2>/dev/null; then
>  for i in /dev/vcs[0-9]*; do
>  {
> -$commands_f
> +${commands_f:-:}
>  } < /dev/tty\${i#/dev/vcs} > /dev/tty\${i#/dev/vcs}
>  done
>  fi

Bugreport *with* patch, NICE.
Now tagged as such.


Groeten
Geert Stappers
-- 
Leven en laten leven

Processed: Re: Bug#833053: Syntax error in the script that setupcon outputs

[Debian Bug Tracking System]

Processing control commands:

> tag -1 patch
Bug #833053 [console-setup] Syntax error in the script that setupcon outputs
Added tag(s) patch.

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

Bug#833053: Syntax error in the script that setupcon outputs

[Jonny]

Package: console-setup
Version: 1.148

Hi,

if you choose "Do not change the boot/kernel font" in debconf questions '"VGA" 
has a traditional appearance and has medium coverage of ...', and outputs the 
"/etc/console-setup/cached_setup_font.sh" such as the following.

#!/bin/sh



if ls /dev/fb* >/dev/null 2>/dev/null; then
for i in /dev/vcs[0-9]*; do
{

} < /dev/tty${i#/dev/vcs} > /dev/tty${i#/dev/vcs}
done
fi

mkdir -p /run/console-setup
> /run/console-setup/font-loaded
for i in /dev/vcs[0-9]*; do
{
printf '\033%%G'
} < /dev/tty${i#/dev/vcs} > /dev/tty${i#/dev/vcs}
done

This script Line 9 is the syntax error.


--- /a/setupcon
+++ /b/setupcon
@@ -911,7 +911,7 @@
 if ls /dev/fb* >/dev/null 2>/dev/null; then
 for i in /dev/vcs[0-9]*; do
 {
-$commands_f
+${commands_f:-:}
 } < /dev/tty\${i#/dev/vcs} > /dev/tty\${i#/dev/vcs}
 done
 fi

Re: flash-kernel: handle DTBs in vendor subdir

[Ian Campbell]

On Sat, 2016-07-30 at 16:52 -0700, Martin Michlmayr wrote:
> DTBs on arm64 are stored as vendor/dtb rather than everything in one
> directory.

I looked at this a while back but it seems I never completed it, or at
least never pushed it :-(.

I've attached the two patches I had sitting in my branch here, they
look sensible but I honestly can't remember what state they are in.

AFAICT the main difference is that they preserve the directory layout
rather than collapsing it. Not sure there is any particular reason to
favour either way of doing it so feel free to either ignore or pickup
these patches.

One thing my patches handles which I'm not sure yours does is the pre-
subdir-transition versions on ARM64, which my commit log says happened
in v3.19-rc1. That might be important for backports and/or upgrades.

Ian.From 3e9d1e6ea1b52ed282a14ecbdd0616be3f2079ee Mon Sep 17 00:00:00 2001
From: Ian Campbell 
Date: Sun, 28 Feb 2016 12:38:53 +
Subject: [PATCH 2/2] Search for DTBs in parent directories

If DTB-Id contains a subdirectory then as well as looking in the named location
also look in the parent directories.

This ensures that where DTBs have been moved by the kernel from the top level
into a subdirectory (as happened for arm64 in v3.19-rc1 when e.g.
apm-mustang.dtb moved to apm/apm-mustang.dtb) that flash-kernel can work with
both old and new kernels.

We search fully in /etc/flash-kernel/dtbs before looking in /usr/lib, so e.g.
we will find /etc/flash-kernel/dtbs/DTB before finding /usr/lib/.../DIR/DTB.
---
 README|  7 ---
 functions | 31 +--
 2 files changed, 29 insertions(+), 9 deletions(-)

diff --git a/README b/README
index 25a6d32..7b9356e 100644
--- a/README
+++ b/README
@@ -117,9 +117,10 @@ The supported fields are:
 
 * DTB-Id: (optional) specifies the name of the DTB file for this device,
   relative to the kernel package DTB dir or /etc/flash-kernel/dtbs. May
-  include a subdirectory. If the value begins with a `!' then the field is a
-  script which should be run.  The script must produce the DTB filename (and
-  nothing else) on stdout.
+  include a subdirectory, if the DTB is not found in the named subdirectory
+  then the parent directories will be searched. If the value begins with a `!'
+  then the field is a script which should be run.  The script must produce the
+  DTB filename (and nothing else) on stdout.
 
 * DTB-Append: (optional) when yes the DTB specified by DTB-Id will be appended
   to the kernel image.
diff --git a/functions b/functions
index 7cf1753..cb8dd70 100644
--- a/functions
+++ b/functions
@@ -552,17 +552,36 @@ android_flash() {
 	echo "done." >&2
 }
 
+search_for_dtb_file_in_prefix() {
+	local prefix=$1
+	local dtbdir=$(dirname "$dtb_name")
+	local dtbfile=$(basename "$dtb_name")
+
+	while true ; do
+		if [ "x$dtbdir" = "x." ] ; then
+			dtbdir=""
+		fi
+		if [ -e "$prefix/$dtbdir/$dtbfile" ] ; then
+			echo "$prefix/$dtbdir/$dtbfile"
+			return 0
+		fi
+		# We've run out of dir prefixes to strip
+		if [ "x$dtbdir" = "x" ] ; then
+			break;
+		fi
+		dtbdir=$(dirname "$dtbdir")
+	done
+	return 1
+}
+
 find_dtb_file() {
 	case "$dtb_name" in
 	/*)
 		echo "$dtb_name"
 		;;
 	*)
-		if [ -e "/etc/flash-kernel/dtbs/$dtb_name" ] ; then
-			echo "/etc/flash-kernel/dtbs/$dtb_name"
-		else
-			echo "/usr/lib/linux-image-$kvers/$dtb_name"
-		fi
+		search_for_dtb_file_in_prefix "/etc/flash-kernel/dtbs" ||
+		search_for_dtb_file_in_prefix "/usr/lib/linux-image-$kvers"
 		;;
 	esac
 }
@@ -604,7 +623,7 @@ handle_dtb() {
 		fi
 	else
 		if [ -e $dtb ]; then
-			echo "Installing $dtb_name into /boot/dtbs/$kvers/$dtb_name" >&2
+			echo "Installing $dtb into /boot/dtbs/$kvers/$dtb_name" >&2
 			mkdir -p /boot/dtbs/$kvers/$dtbdir
 			cp "$dtb" "/boot/dtbs/$kvers/$dtb_name.new"
 			backup_and_install \
-- 
2.8.1

From 5e16bdd278dbc10a1970a0db6c756158dc677c64 Mon Sep 17 00:00:00 2001
From: Ian Campbell 
Date: Sun, 28 Feb 2016 12:14:55 +
Subject: [PATCH 1/2] Handle DTB-Id with a subdirectory

In v3.19-rc1 Linux arm64 moved all DTB files into per-vendor subdirectories and
the Debian kernel package has followed suite.

Update the entry for Mustang (the only arm64 platform in the current
flash-kernel database) to add the apm/ prefix and adjust the code which
installs and removes the dtb to cope with subdirectories in this context.
---
 README   | 8 +---
 db/all.db| 2 +-
 debian/changelog | 6 ++
 functions| 8 +++-
 4 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/README b/README
index 02ba3fd..25a6d32 100644
--- a/README
+++ b/README
@@ -115,9 +115,11 @@ The supported fields are:
   This option is ignored if a DTB is to be appended, via either DTB-Append or
   DTB-Append-From.
 
-* DTB-Id: (optional) specifies the name of the DTB file for this device. If
-  the value begins with a `!' then the field is a script which should be run.
-  The script must produce the DTB 

Re: flash-kernel: arm64 doesn't have bootz

[Ian Campbell]

On Sat, 2016-07-30 at 17:14 -0700, Vagrant Cascadian wrote:
> 
> Are all arm64 boards only going to support booti and not bootz?

bootz refers to the zImage which is only an ARM image type and not an
ARM64 one, which is an Image and hence booti.

That would only change if someone added a self-decompressing kernel
image to ARM64 introducing a zImage to that platform. I have a vague
feeling I once saw it stated that this wasn't needed because
bootloaders can decompress these days, but I have no reference at all
for that.

Ian