Warning: debian stable kernel upgrade breaks most ARM SBC

version graph

Package:
src:linux;
Maintainer for src:linux is Debian Kernel Team ;

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded
to debian-bugs-dist@lists.debian.org, Debian Kernel Team :

Bug#922478; Package linux-image-4.9.0-8-armmp-lpae.
(Sat, 16 Feb 2019 18:03:04 GMT) (full text, mbox, link).


Acknowledgement sent
to Jürgen Löb :


New Bug report received and forwarded. Copy sent to Debian Kernel Team .
(Sat, 16 Feb 2019 18:03:04 GMT) (full text, mbox, link).


Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]
Package: linux-image-4.9.0-8-armmp-lpae

Version: 4.9.144-3

Severity: serious

Updated my Lamobo R1 board with apt update;apt upgrade

After the update uboot is struck at "Starting kernel". There is no
further output after "Starting kernel". Same happens on Bananapi 1
board. Unfortunately there is no more useful information.


I have been able to recover by downgrading to a backup kernel by
mounting the boot partiton on the sd card. Then:

dd if=boot.scr of=boot.script bs=72 skip=1 (extract script)

replaced  in boot.script:

setenv fk_kvers '4.9.0-8-armmp-lpae'

with

setenv fk_kvers '4.9.0-7-armmp-lpae'  (backup kernel that has been
available on my boot partition)

then:

mkimage -C none -A arm -T script -d boot.script boot.scr


Afterwards I have been able to boot the system with the old kernel
version. Then I was able to restore the previous version (4.9.130-2) with:

dpkg -i linux-image-4.9.0-8-armmp-lpae_4.9.130-2_armhf.deb (luckily
found the older package)

Upgrading to 4.9.144-3 again after this results in the unbootable
behavior again. Thus for sure the upgrade to 4.9.144-3 is causing the
problem.

-----------------------
Hiermit widerspreche ich/wir der Nutzung oder Uebermittlung 
meiner/unserer Daten fuer Werbezwecke oder fuer die Markt- oder 
Meinungsforschung gem. Par. 28 Abs. 3 Bundesdatenschutzgesetz.


[signature.asc (application/pgp-signature, attachment)]

Marked as found in versions linux/4.9.144-3.
Request was from Ben Hutchings
to control@bugs.debian.org.
(Sat, 16 Feb 2019 20:42:04 GMT) (full text, mbox, link).


Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Kernel Team :

Bug#922478; Package src:linux.
(Sun, 17 Feb 2019 11:42:04 GMT) (full text, mbox, link).


Acknowledgement sent
to Reco :


Extra info received and forwarded to list. Copy sent to Debian Kernel Team .
(Sun, 17 Feb 2019 11:42:04 GMT) (full text, mbox, link).


Message #14 received at 922478@bugs.debian.org (full text, mbox, reply):

	Hi all.

I'd like to add that plain armmp (non-lpae) is broken too.
At least for Armada385/Caiman and QEMU's virt.

Reco



Severity set to ‘serious’ from ‘normal’
Request was from Salvatore Bonaccorso
to control@bugs.debian.org.
(Sun, 17 Feb 2019 12:45:04 GMT) (full text, mbox, link).


Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Kernel Team :

Bug#922478; Package src:linux.
(Sun, 17 Feb 2019 15:27:02 GMT) (full text, mbox, link).


Acknowledgement sent
to "Timo Sigurdsson" :


Extra info received and forwarded to list. Copy sent to Debian Kernel Team .
(Sun, 17 Feb 2019 15:27:02 GMT) (full text, mbox, link).


Message #21 received at 922478@bugs.debian.org (full text, mbox, reply):

Hi,

I've also been hit by this bug on two systems (both are Lemaker Bananapi). The first system upgraded the kernel via unattended-upgrades and failed to come up after reboot. I don't have a serial cable, but I did hook up the board to a HDMI display. U-Boot loads the kernel, dtb and initramfs and starts the kernel but that's the last message and nothing happens after that anymore. My first suspicion was that something went wrong during the upgrade and the reboot might have happened before everything was configured. But I also tried manual package upgrade with a second device via apt update && apt full-upgrade followed by a manual reboot. That system didn't boot either.

I recovered both systems by replacing the contents of the directories /boot/ and /lib/modules/ with those of a recent backup (taken 3 days ago). After logging into the systems again, I downgraded the package linux-image-4.9.0-8-armmp-lpae to 4.9.130-2 and rebooted again in order to make sure no other package upgrade caused the issue. Indeed, with all packages up-to-date except linux-image-4.9.0-8-armmp-lpae, the systems work just fine.

So, there must be a serious regression in 4.9.144-3 at least on armmp-lpae. My amd64 systems run fine, btw, even with the latest kernel.


Thanks,

Timo



Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Kernel Team :

Bug#922478; Package src:linux.
(Sun, 17 Feb 2019 17:57:04 GMT) (full text, mbox, link).


Acknowledgement sent
to Vagrant Cascadian :


Extra info received and forwarded to list. Copy sent to Debian Kernel Team .
(Sun, 17 Feb 2019 17:57:04 GMT) (full text, mbox, link).


Message #26 received at 922478@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]
After upgrading to the latest 4.9.x kernel in sid, all of the armhf
boards running this kernel failed to boot.

Adding to the list:

imx6: Cubox-i4pro, Cubox-i4x4, Wandboard Quad
exynos5: Odroid-XU4
exynos4: Odroid-U3
rk3328: firefly-rk3288
sunxi A20: Cubietruck


So it clearly impacts a wide variety of systems...


live well,
  vagrant
[signature.asc (application/pgp-signature, inline)]

Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Kernel Team :

Bug#922478; Package src:linux.
(Sun, 17 Feb 2019 18:42:03 GMT) (full text, mbox, link).


Acknowledgement sent
to Cyril Brulebois :


Extra info received and forwarded to list. Copy sent to Debian Kernel Team .
(Sun, 17 Feb 2019 18:42:03 GMT) (full text, mbox, link).


Message #31 received at 922478@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]
Hi folks,

Jürgen Löb  (2019-02-16):
> Package: linux-image-4.9.0-8-armmp-lpae
> Version: 4.9.144-3
> Severity: serious
> 
> Updated my Lamobo R1 board with apt update;apt upgrade
> 
> After the update uboot is struck at "Starting kernel". There is no
> further output after "Starting kernel". Same happens on Bananapi 1
> board. Unfortunately there is no more useful information.
[…]

Summing up, it looks like everybody in cc is confirming the regression
happens between 4.9.130-2 and 4.9.144-3, with and without lpae, on
various boards. Any chance you could check what happens with the
4.9.135-1 intermediary version that can be found on snapshot.debian.org?

  https://snapshot.debian.org/package/linux/4.9.135-1/

This might help narrow it down when the regression happened.

(And please use reply-all so that everyone is kept in the loop.)


Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
[signature.asc (application/pgp-signature, inline)]

Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Kernel Team :

Bug#922478; Package src:linux.
(Sun, 17 Feb 2019 18:54:03 GMT) (full text, mbox, link).


Acknowledgement sent
to Reco :


Extra info received and forwarded to list. Copy sent to Debian Kernel Team .
(Sun, 17 Feb 2019 18:54:03 GMT) (full text, mbox, link).


Message #36 received at 922478@bugs.debian.org (full text, mbox, reply):

	Hi.

On Sun, Feb 17, 2019 at 07:38:18PM +0100, Cyril Brulebois wrote:
> Hi folks,
> 
> Jürgen Löb  (2019-02-16):
> > Package: linux-image-4.9.0-8-armmp-lpae
> > Version: 4.9.144-3
> > Severity: serious
> > 
> > Updated my Lamobo R1 board with apt update;apt upgrade
> > 
> > After the update uboot is struck at "Starting kernel". There is no
> > further output after "Starting kernel". Same happens on Bananapi 1
> > board. Unfortunately there is no more useful information.
> […]
> 
> Summing up, it looks like everybody in cc is confirming the regression
> happens between 4.9.130-2 and 4.9.144-3, with and without lpae, on
> various boards. Any chance you could check what happens with the
> 4.9.135-1 intermediary version that can be found on snapshot.debian.org?

Did this already in QEMU (virt board).
4.9.135-1 works.
4.9.144-1 (next one) is broken.

The problem is - 4.9.144-1 introduced large amount of changes, including
two Spectre mitigations.

My attempts to build a kernel with CONFIG_SPECTRE=n yielded unbootable
kernels, which may mean that:

a) Spectre mitigations are not related to the problem.
b) My kernel-rebuilding skill could use some improvement.

Reco



Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Kernel Team :

Bug#922478; Package src:linux.
(Sun, 17 Feb 2019 19:30:02 GMT) (full text, mbox, link).


Acknowledgement sent
to Cyril Brulebois :


Extra info received and forwarded to list. Copy sent to Debian Kernel Team .
(Sun, 17 Feb 2019 19:30:02 GMT) (full text, mbox, link).


Message #41 received at 922478@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]
Hi,

Reco  (2019-02-17):
> Did this already in QEMU (virt board).
> 4.9.135-1 works.
> 4.9.144-1 (next one) is broken.

Is there any chance you could share how to get such a VM set up in QEMU?

I'd be happy to try a few kernel builds, but having a quick way to check
whether a given kernel build is OK/KO would be much appreciated.
 

Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
[signature.asc (application/pgp-signature, inline)]

Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Kernel Team :

Bug#922478; Package src:linux.
(Sun, 17 Feb 2019 19:45:05 GMT) (full text, mbox, link).


Acknowledgement sent
to Reco :


Extra info received and forwarded to list. Copy sent to Debian Kernel Team .
(Sun, 17 Feb 2019 19:45:05 GMT) (full text, mbox, link).


Message #46 received at 922478@bugs.debian.org (full text, mbox, reply):

	Hi.

On Sun, Feb 17, 2019 at 08:27:34PM +0100, Cyril Brulebois wrote:
> Hi,
> 
> Reco  (2019-02-17):
> > Did this already in QEMU (virt board).
> > 4.9.135-1 works.
> > 4.9.144-1 (next one) is broken.
> 
> Is there any chance you could share how to get such a VM set up in QEMU?
> 
> I'd be happy to try a few kernel builds, but having a quick way to check
> whether a given kernel build is OK/KO would be much appreciated.

1) Install qemu-system-arm.

2) Unpack kernel .deb, locate vmlinuz-4.9.0-8-armmp.
Or search your just-built zImage.

3) Run qemu (no root required):

qemu-system-arm -M virt -nographic -kernel vmlinuz-4.9.0-8-armmp

If you see a kernel panic - the outcome is positive, the kernel is OK.
If it just stays there eating 100% CPU - the outcome is negative.

Reco



Merged 922478 922532
Request was from Julien Cristau
to control@bugs.debian.org.
(Sun, 17 Feb 2019 19:54:05 GMT) (full text, mbox, link).


Merged 922478 922532
Request was from Salvatore Bonaccorso
to control@bugs.debian.org.
(Sun, 17 Feb 2019 19:57:06 GMT) (full text, mbox, link).


Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Kernel Team :

Bug#922478; Package src:linux.
(Sun, 17 Feb 2019 20:09:03 GMT) (full text, mbox, link).


Acknowledgement sent
to Cyril Brulebois :


Extra info received and forwarded to list. Copy sent to Debian Kernel Team .
(Sun, 17 Feb 2019 20:09:03 GMT) (full text, mbox, link).


Message #55 received at 922478@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]
Hi,

Reco  (2019-02-17):
> 1) Install qemu-system-arm.
> 
> 2) Unpack kernel .deb, locate vmlinuz-4.9.0-8-armmp.
> Or search your just-built zImage.
> 
> 3) Run qemu (no root required):
> 
> qemu-system-arm -M virt -nographic -kernel vmlinuz-4.9.0-8-armmp
> 
> If you see a kernel panic - the outcome is positive, the kernel is OK.
> If it just stays there eating 100% CPU - the outcome is negative.

Perfect, checked with .135-1 and .144-3.

That's super useful, much appreciated!


Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
[signature.asc (application/pgp-signature, inline)]

Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Kernel Team :

Bug#922478; Package src:linux.
(Sun, 17 Feb 2019 20:30:12 GMT) (full text, mbox, link).


Acknowledgement sent
to "Timo Sigurdsson" :


Extra info received and forwarded to list. Copy sent to Debian Kernel Team .
(Sun, 17 Feb 2019 20:30:12 GMT) (full text, mbox, link).


Message #60 received at 922478@bugs.debian.org (full text, mbox, reply):

Hi,

Cyril Brulebois schrieb am 17.02.2019 19:38:

> Hi folks,
> 
> Jürgen Löb  (2019-02-16):
>> Package: linux-image-4.9.0-8-armmp-lpae
>> Version: 4.9.144-3
>> Severity: serious
>> 
>> Updated my Lamobo R1 board with apt update;apt upgrade
>> 
>> After the update uboot is struck at "Starting kernel". There is no
>> further output after "Starting kernel". Same happens on Bananapi 1
>> board. Unfortunately there is no more useful information.
> […]
> 
> Summing up, it looks like everybody in cc is confirming the regression
> happens between 4.9.130-2 and 4.9.144-3, with and without lpae, on
> various boards. Any chance you could check what happens with the
> 4.9.135-1 intermediary version that can be found on snapshot.debian.org?
> 
>  https://snapshot.debian.org/package/linux/4.9.135-1/
> 
> This might help narrow it down when the regression happened.
> 
> (And please use reply-all so that everyone is kept in the loop.)

So, I also tested 4.9.135-1 on a Bananapi board and can confirm it works.

I would suspect the issue is caused by Debian's kernel configuration or changes. The Kernel CI project has ARM hardware, including the Bananapi board and does tests of stable kernel updates to verify that the kernel boots. At least with multi_v7_defconfig and sunxi_defconfig, upstream 4.9.144 does boot on Allwinner-based hardware, see: https://kernelci.org/soc/allwinner/job/stable-rc/kernel/v4.9.144/

On a sidenote: This issue makes me wonder if Debian's approach to kernel updates (i.e. not bumping the version number/ABI and overwriting the kernel image and modules) is really the best option. IMHO Ubuntu's handling of kernel updates is more robust. It would have made things much easier today if I could have simply selected an older kernel in the bootloader, rather than having to recover one from a backup.

Kind regards,

Timo



Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Kernel Team :

Bug#922478; Package src:linux.
(Sun, 17 Feb 2019 21:45:02 GMT) (full text, mbox, link).


Acknowledgement sent
to Vagrant Cascadian :


Extra info received and forwarded to list. Copy sent to Debian Kernel Team .
(Sun, 17 Feb 2019 21:45:02 GMT) (full text, mbox, link).


Message #65 received at 922478@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]
Control: retitle 922478 upgrade linux-image-4.9.0-8-armmp-lpae:armhf from 4.9.130-2 to 4.9.144-3 renders many systems unbootable

On 2019-02-17, Timo Sigurdsson wrote:
> Cyril Brulebois schrieb am 17.02.2019 19:38:
>> Jürgen Löb  (2019-02-16):
>>> Package: linux-image-4.9.0-8-armmp-lpae
>>> Version: 4.9.144-3
>>> Severity: serious

FWIW, I also built a local package from 4.9.155-1~ from salsa/stretch
git, and it worked on a wandboard quad.

$ uname -a
Linux wbq0 4.9.0-9-armmp #1 SMP Debian 4.9.155-1~20190217~1 (2019-02-17) armv7l GNU/Linux

live well,
  vagrant
[signature.asc (application/pgp-signature, inline)]

Changed Bug title to ‘upgrade linux-image-4.9.0-8-armmp-lpae:armhf from 4.9.130-2 to 4.9.144-3 renders many systems unbootable’ from ‘upgrade linux-image-4.9.0-8-armmp-lpae:armhf from 4.9.130-2 to 4.9.144-3 renders Bananapi and Lamobo R1 unbootable’.
Request was from Vagrant Cascadian
to 922478-submit@bugs.debian.org.
(Sun, 17 Feb 2019 21:45:02 GMT) (full text, mbox, link).


Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Kernel Team :

Bug#922478; Package src:linux.
(Sun, 17 Feb 2019 21:51:05 GMT) (full text, mbox, link).


Acknowledgement sent
to Adrian Bunk :


Extra info received and forwarded to list. Copy sent to Debian Kernel Team .
(Sun, 17 Feb 2019 21:51:05 GMT) (full text, mbox, link).


Message #72 received at 922478@bugs.debian.org (full text, mbox, reply):

On Sun, Feb 17, 2019 at 09:52:48AM -0800, Vagrant Cascadian wrote:
> After upgrading to the latest 4.9.x kernel in sid, all of the armhf
> boards running this kernel failed to boot.
> 
> Adding to the list:
> 
> imx6: Cubox-i4pro, Cubox-i4x4, Wandboard Quad
> exynos5: Odroid-XU4
> exynos4: Odroid-U3
> rk3328: firefly-rk3288
> sunxi A20: Cubietruck
> 
> 
> So it clearly impacts a wide variety of systems...

debian/patches/debian/arm-avoid-abi-change-in-4.9.139.patch changes
the order of struct processor but lacks a corresponding change to 
arch/arm/mm/proc-macros.S

> live well,
>   vagrant

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed




Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Kernel Team :

Bug#922478; Package src:linux.
(Mon, 18 Feb 2019 00:57:04 GMT) (full text, mbox, link).


Acknowledgement sent
to Vagrant Cascadian :


Extra info received and forwarded to list. Copy sent to Debian Kernel Team .
(Mon, 18 Feb 2019 00:57:04 GMT) (full text, mbox, link).


Message #77 received at 922478@bugs.debian.org (full text, mbox, reply):

On 2019-02-17, Vagrant Cascadian  wrote:
> On 2019-02-17, Timo Sigurdsson wrote:
>> Cyril Brulebois schrieb am 17.02.2019 19:38:
>>> Jürgen Löb  (2019-02-16):
> FWIW, I also built a local package from 4.9.155-1~ from salsa/stretch
> git, and it worked on a wandboard quad.
>
> $ uname -a
> Linux wbq0 4.9.0-9-armmp #1 SMP Debian 4.9.155-1~20190217~1 (2019-02-17) armv7l GNU/Linux

That seemed to work fine on several tested boards.

I also did a local build commenting out
"debian/arm-avoid-abi-change-in-4.9.139.patch" in debian/patches and
removing "debian/abi/4.9.0-8/armhf_none_armmp" so that the abi conflicts
didn't fail to build...

$ uname -a
Linux cbxi4b 4.9.0-8-armmp #1 SMP Debian 4.9.144-4~20190217~1 (2019-02-17) armv7l GNU/Linux

Sounds like there may be a less intrusive patch in the works...


live well,
  vagrant



Marked as found in versions linux/4.9.130-2.
Request was from Salvatore Bonaccorso
to control@bugs.debian.org.
(Mon, 18 Feb 2019 10:09:05 GMT) (full text, mbox, link).


Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Kernel Team :

Bug#922478; Package src:linux.
(Mon, 18 Feb 2019 11:33:04 GMT) (full text, mbox, link).


Acknowledgement sent
to Neil Williams :


Extra info received and forwarded to list. Copy sent to Debian Kernel Team .
(Mon, 18 Feb 2019 11:33:04 GMT) (full text, mbox, link).


Message #86 received at 922478@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]
On Sun, 17 Feb 2019 21:26:41 +0100 (CET) "Timo Sigurdsson"
 wrote:
> Hi,
> 
> Cyril Brulebois schrieb am 17.02.2019 19:38:
> 
> > Hi folks,
> > 
> > Jürgen Löb  (2019-02-16):
> >> Package: linux-image-4.9.0-8-armmp-lpae
> >> Version: 4.9.144-3
> >> Severity: serious
> >> 
> >> Updated my Lamobo R1 board with apt update;apt upgrade
> >> 
> >> After the update uboot is struck at "Starting kernel". There is no
> >> further output after "Starting kernel". Same happens on Bananapi 1
> >> board. Unfortunately there is no more useful information.
> > […]
> > 
> > Summing up, it looks like everybody in cc is confirming the
> > regression happens between 4.9.130-2 and 4.9.144-3, with and
> > without lpae, on various boards. Any chance you could check what
> > happens with the 4.9.135-1 intermediary version that can be found on
> > snapshot.debian.org?
> > 
> >  https://snapshot.debian.org/package/linux/4.9.135-1/
> > 
> > This might help narrow it down when the regression happened.
> > 
> > (And please use reply-all so that everyone is kept in the loop.)
> 
> So, I also tested 4.9.135-1 on a Bananapi board and can confirm it
> works.
> 
> I would suspect the issue is caused by Debian's kernel configuration
> or changes. The Kernel CI project has ARM hardware, including the
> Bananapi board and does tests of stable kernel updates to verify that
> the kernel boots. At least with multi_v7_defconfig and
> sunxi_defconfig, upstream 4.9.144 does boot on Allwinner-based
> hardware, see:
> https://kernelci.org/soc/allwinner/job/stable-rc/kernel/v4.9.144/
> 

Is it feasible to have a script in devscripts or similar which maps the
version of the kernel *Candidate* to KernelCI URLs for the same
version?

Can we correlate Debian kernel versions to something like
https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.144/
or
https://kernelci.org/boot/all/job/stable-rc/kernel/v4.9.144/ ?



-- 

Neil Williams
home@codehelp.co.uk

[Message part 2 (application/pgp-signature, inline)]

Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Kernel Team :

Bug#922478; Package src:linux.
(Mon, 18 Feb 2019 12:33:02 GMT) (full text, mbox, link).


Acknowledgement sent
to Steve McIntyre :


Extra info received and forwarded to list. Copy sent to Debian Kernel Team .
(Mon, 18 Feb 2019 12:33:02 GMT) (full text, mbox, link).


Message #91 received at 922478@bugs.debian.org (full text, mbox, reply):

On Sun, Feb 17, 2019 at 04:54:00PM -0800, Vagrant Cascadian wrote:
>On 2019-02-17, Vagrant Cascadian  wrote:
>> On 2019-02-17, Timo Sigurdsson wrote:
>>> Cyril Brulebois schrieb am 17.02.2019 19:38:
>>>> Jürgen Löb  (2019-02-16):
>> FWIW, I also built a local package from 4.9.155-1~ from salsa/stretch
>> git, and it worked on a wandboard quad.
>>
>> $ uname -a
>> Linux wbq0 4.9.0-9-armmp #1 SMP Debian 4.9.155-1~20190217~1 (2019-02-17) armv7l GNU/Linux
>
>That seemed to work fine on several tested boards.
>
>I also did a local build commenting out
>"debian/arm-avoid-abi-change-in-4.9.139.patch" in debian/patches and
>removing "debian/abi/4.9.0-8/armhf_none_armmp" so that the abi conflicts
>didn't fail to build...
>
>$ uname -a
>Linux cbxi4b 4.9.0-8-armmp #1 SMP Debian 4.9.144-4~20190217~1 (2019-02-17) armv7l GNU/Linux

Yes, me too. Built similar and tested on the Marvell Armada XP here
and it solved the problem.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"Because heaters aren't purple!" -- Catherine Pitt




Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Kernel Team :

Bug#922478; Package src:linux.
(Mon, 18 Feb 2019 12:33:04 GMT) (full text, mbox, link).


Acknowledgement sent
to Steve McIntyre :


Extra info received and forwarded to list. Copy sent to Debian Kernel Team .
(Mon, 18 Feb 2019 12:33:04 GMT) (full text, mbox, link).


Message #96 received at 922478@bugs.debian.org (full text, mbox, reply):

On Mon, Feb 18, 2019 at 11:28:10AM +0000, Neil Williams wrote:
>On Sun, 17 Feb 2019 21:26:41 +0100 (CET) "Timo Sigurdsson"
>> 
>> So, I also tested 4.9.135-1 on a Bananapi board and can confirm it
>> works.
>> 
>> I would suspect the issue is caused by Debian's kernel configuration
>> or changes. The Kernel CI project has ARM hardware, including the
>> Bananapi board and does tests of stable kernel updates to verify that
>> the kernel boots. At least with multi_v7_defconfig and
>> sunxi_defconfig, upstream 4.9.144 does boot on Allwinner-based
>> hardware, see:
>> https://kernelci.org/soc/allwinner/job/stable-rc/kernel/v4.9.144/

Yup. The bug is clearly coming from a local Debian patch.

>Is it feasible to have a script in devscripts or similar which maps the
>version of the kernel *Candidate* to KernelCI URLs for the same
>version?
>
>Can we correlate Debian kernel versions to something like
>https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.144/
>or
>https://kernelci.org/boot/all/job/stable-rc/kernel/v4.9.144/ ?

Sure, maybe. I've suggested kernelci as a useful thing to help here,
but we really need to be testing kernels complete with all the Debian
patches to...

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.




Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Kernel Team :

Bug#922478; Package src:linux.
(Mon, 18 Feb 2019 12:45:11 GMT) (full text, mbox, link).


Acknowledgement sent
to w.opr@gmx.de:


Extra info received and forwarded to list. Copy sent to Debian Kernel Team .
(Mon, 18 Feb 2019 12:45:11 GMT) (full text, mbox, link).


Message #101 received at 922478@bugs.debian.org (full text, mbox, reply):

Hi all.

I'd like to add that 4.9.0-8-686 Version is broken too.
At least for my ALIX-Board ALIX.2D2 from PC Engines.

(CPU: 500 MHz AMD Geode LX800)

W.O.



Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Kernel Team :

Bug#922478; Package src:linux.
(Mon, 18 Feb 2019 12:57:04 GMT) (full text, mbox, link).


Acknowledgement sent
to "Timo Sigurdsson" :


Extra info received and forwarded to list. Copy sent to Debian Kernel Team .
(Mon, 18 Feb 2019 12:57:04 GMT) (full text, mbox, link).


Message #106 received at 922478@bugs.debian.org (full text, mbox, reply):

Hi,

On Mon, 18 Feb 2019 11:28:10 +0000, Neil Williams  wrote:
> Is it feasible to have a script in devscripts or similar which maps the
> version of the kernel *Candidate* to KernelCI URLs for the same
> version?
> 
> Can we correlate Debian kernel versions to something like
> https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.144/
> or
> https://kernelci.org/boot/all/job/stable-rc/kernel/v4.9.144/ ?

I just had another look and found they also have a job for the stable releases rather than the release candidates:
https://kernelci.org/build/stable/branch/linux-4.9.y/kernel/v4.9.144/

So, as long as the Debian kernel is based on a longterm kernel which is still supported upstream, the mapping should work.

What might be worth a thought as well, though, is to have such automated testing of the Debian kernels as well. Either by asking the Kernel CI project whether they'd be willing to build and test Debian kernels, too, or by setting up an infrastructure similar to theirs just for Debian. Now, I wouldn't expect Debian to have as much hardware to test on, but in this particular case it would have helped already to test the kernel in a virtualized setup. Based on this thread, it seems to me that the armhf kernels haven't received any boot testing prior to release. If that's really the case, I guess something along these lines might help Debian substantially.


Cheers,

Timo






Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>.
Last modified:
Mon Feb 18 13:08:15 2019;
Machine Name:
beach

Debian Bug tracking system

Debbugs is free software and licensed under the terms of the GNU
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.

Copyright © 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson,
2005-2017 Don Armstrong, and many other contributors.

Read More

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.