[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#809476: marked as done (Linux 4.4-rc6 fails to boot on QNAP TS-109)

Your message dated Thu, 28 Jan 2016 06:33:50 +0000
with message-id <E1aOg9O-0003ck-MP@franck.debian.org>
and subject line Bug#809476: fixed in flash-kernel 3.56
has caused the Debian Bug report #809476,
regarding Linux 4.4-rc6 fails to boot on QNAP TS-109
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 owner@bugs.debian.org
immediately.)


-- 
809476: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809476
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: linux
Version: 4.4~rc6-1~exp1
Severity: important

I tried to boot Debian's 4.4-rc6 kernel on my QNAP TS-109 and it failed
to boot with:
[   19.380002] Unpacking initramfs...
[   19.380044] Initramfs unpacking failed: junk in compressed archive

After spending ages bisecting and not getting anywhere, I spoke to Ben
Hutchings who thought it was a kernel size issue and that part of the
initramfs was now getting overwritten.  And he was right (disabling
some options made the kernel boot).

On the QNAP TS-109, the kernel/ramdisk are loaded like this:

> cp.b 0xff200000 0x800000 0x3fffff
> setenv bootargs console=ttyS0,115200n8 root=/dev/ram rw initrd=0x800000,0x3fffff
> bootm 0xff000000

So the ramdisk is copied to memory while the kernel is loaded from flash
(where we have a 2 MB limit due to the partition size).

u-boot loads it like this:

## Booting image at 00400000 ...
   Load Address: 00008000
   Entry Point:  00008000

This is the load address used by the original QNAP firmware.

I guess the kernel is uncompressed and overwrites part of the ramdisk
located at 0x800000.  I don't really get this part because
arch/arm/boot/Image is only 6.1 MB (but vmlinux is around 9 MB, even
on the kernel that works).

Anyway, I guess we have two options:

1) In addition to ensuring the compressed kernel is below 2 MB (to fit
in the flash partition) we should ensure that the uncompressed kernel
is smaller than some limit.

or:

2) We could change the load address to 0x00c08000 which is after the
ramdisk (the ramdisk is loaded at 0x800000 and can only be 4 MB due
to the size of the MTD partition).  u-boot says:
> Addresses 20M - 0M are saved for the U-Boot usage.
so I guess this is ok.  I made this change and the kernel and ramdisk
loaded correctly.

However, I don't fully understand the boot process.  I've copied some
ARM experts.  Can you comment whether using 0x00c08000 as the load
address is safe / the correct thing to do, or is there a better
solution?

If this is the right approach, I suggest the following patch to
flash-kernel:

diff --git a/db/all.db b/db/all.db
index 936d498..4344265 100644
--- a/db/all.db
+++ b/db/all.db
@@ -877,7 +877,7 @@ Kernel-Flavors: orion5x
 Machine-Id: 1565
 Mtd-Kernel: Kernel
 Mtd-Initrd: RootFS1
-U-Boot-Kernel-Address: 0x00008000
+U-Boot-Kernel-Address: 0x00c08000
 Required-Packages: u-boot-tools
 Bootloader-Sets-Incorrect-Root: yes
 
@@ -898,7 +898,7 @@ Kernel-Flavors: orion5x
 Machine-Id: 1601
 Mtd-Kernel: Kernel
 Mtd-Initrd: RootFS1
-U-Boot-Kernel-Address: 0x00008000
+U-Boot-Kernel-Address: 0x00c08000
 Required-Packages: u-boot-tools
 Bootloader-Sets-Incorrect-Root: yes
 

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

--- End Message ---
--- Begin Message --- 
Source: flash-kernel
Source-Version: 3.56

We believe that the bug you reported is fixed in the latest version of
flash-kernel, 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 809476@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Christian Perrier <bubulle@debian.org> (supplier of updated flash-kernel 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 ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Thu, 28 Jan 2016 07:16:20 +0100
Source: flash-kernel
Binary: flash-kernel flash-kernel-installer
Architecture: source
Version: 3.56
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team <debian-boot@lists.debian.org>
Changed-By: Christian Perrier <bubulle@debian.org>
Description:
 flash-kernel - utility to make certain embedded devices bootable
 flash-kernel-installer - Make the system bootable (udeb)
Closes: 809476
Changes:
 flash-kernel (3.56) unstable; urgency=medium
 .
   [ Martin Michlmayr ]
   * QNAP TS-109/TS-209 and TS-409: change the kernel address to be after
     the ramdisk so the uncompressed kernel doesn't overwrite the ramdisk.
     (Closes: #809476)
 .
   [ Vagrant Cascadian ]
   * Update Cubieboard4 entry to generate uImage and uInitrd loadable by
     the vendor u-boot, which doesn't support boot scripts.
Checksums-Sha1:
 fa1a4f5b57dface8070e37bd918aaf5d66c91528 1853 flash-kernel_3.56.dsc
 7338d9b5791ea088b256b6874c38f50105f9f997 64892 flash-kernel_3.56.tar.xz
Checksums-Sha256:
 a89feb4d8ad838f1476d4506a86196407c4f9a7d5171743fee0ed963e3acb09b 1853 flash-kernel_3.56.dsc
 fd96293d6bc9f1af463887fbcd36e8dbe4c7c397e95a513fe3aa3d999af807eb 64892 flash-kernel_3.56.tar.xz
Files:
 e542552b30cae84144bdd31d52fab8eb 1853 utils optional flash-kernel_3.56.dsc
 b18ca8a827aa70c262277c59903aafe9 64892 utils optional flash-kernel_3.56.tar.xz

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJWqbNtAAoJEIcvcCxNbiWoqT4QAISPWzCnjIHly4swRR/TAUkL
XQpSUpdThGBp0kk7rU6MpjutIvXvS+nXznkpJ8hayC8MJv8Yh4vcfijmrnzQa73y
GmEMx1jWtFVBmH4jMMjXc9uSYFJrFUgKspjqn2vmKK7dL4cyezsvK/9OmJYNZA3y
aNBP8go8JuhjvNgMhJDeIYPR23ch3PXHZblFDsegV9DC4JwLuT2icBna+3aiysFa
MRHE34fJVebv77Xb2TjdmC9Cy2oOvDKCFKRb2sB9mfSwaWjJtw0anjxgZAlrH+s8
1iWDWo6xJkgrYxFp88h8KktoIi0D4AamYUAZ/myljvjRJyLUqb6wwEpO4JE+cQRs
wX49l0YDuGfEDCfgDSfM+icL4xRbbpr33Brgy9981BcKVDq/mInD+psZP/d2IK3N
N/4YrYE6+d2nW8/56ZKhwABlYHhxScCFVYSYaB8SnQ0sexk8zbNy+QqJOt6CfVgf
0OdDSRU9xu0KYY9ES8s7nVtWORZv7HmGXdIy1WOOIaRkRgvXLOBRKjr6uxnf1Cq8
f59vBGL3ye+vOisudX1b9DOai/apw7nCu8ixkJOckbxoHRHjRyJTmLFUEXODYTwC
qlxiQZfdaFD1EQQiBFoefJVhfSQ6X4TsRdlBx76ZTzCX8ybUn8FVIIwpsQFa2qYl
iYhqV/wOgsSBvNvhLA6o
=qGLV
-----END PGP SIGNATURE-----

--- End Message ---
Reply to: