Bug 971385

Summary:	ix86-kernels 4.5.0 from Kernel:stable refuse to boot
Product:	[openSUSE] openSUSE 13.1	Reporter:	Axel Köllhofer <AxelKoellhofer>
Component:	Kernel	Assignee:	E-mail List <kernel-maintainers>
Status:	RESOLVED DUPLICATE	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None	CC:	bjoernv, dimstar, fvogt
Version:	Final
Target Milestone:	---
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Axel Köllhofer 2016-03-16 11:49:16 UTC

Actually, I am not sure if this is related to

https://bugzilla.opensuse.org/show_bug.cgi?id=970239

I run openSUSE 13.1 ix86 with kernels from Kernel:stable Repository, so this issue might also occur on newer openSUSE-Versions if they support 32bit installations (most likely 13.2 but not 42.1).

With kernel-4.5.0 (I tried "default" and "pae" flavor) the machine fails to boot at a very early stage.
After selecting the respective kernel from grub menu the screen turns black, there is no output at all and the machine hangs.

So it looks as if loading the kernel image to memory does not succeed.

On another machine with x86_64 installation (running openSUSE Leap 42.1), the respective kernel (4.5.0 with "default" flavor) boots without problems.

As kernel 4.4.5 (pae) from Kernel:stable boots fine on the affected machine, I tried to find any changes in kernel configuration related to RAM/Memory handling between those two versions.

The only thing which was obvious enough that even I found it, was

config-4.4.5-1.g09dee88-pae:CONFIG_DDR=y

config-4.5.0-1.g95a9976-pae:# CONFIG_DDR is not set

but these settings are identical to the respective x86_64 kernels which work, so I am not sure if I found something relevant in that CONFIG option.

As the system hangs immediately after selecting the respective kernel, I don't know (at least yet) how to give more useful information.

Greetings,

AK

Comment 1 Fabian Vogt 2016-03-16 11:58:22 UTC

Definitely the same issue.

> So it looks as if loading the kernel image to memory does not succeed.

Almost: The kernel is loaded into memory just fine, but it needs to copy/decompress itself to a different location, which does not work correctly with the latest binutils in factory, which Kernel:stable is built with.

*** This bug has been marked as a duplicate of bug 970239 ***

Comment 2 Dominique Leuenberger 2016-03-16 12:10:36 UTC

(In reply to Fabian Vogt from comment #1)
> Definitely the same issue.

On a 13.1 build? We should never ever have binutils 2.26 in the play there.

Comment 3 Björn Voigt 2016-03-16 12:11:54 UTC

Unfortunately the kernel:stable repository already contains i586/i686 kernels which do not boot. I use the repository since many years, fortunately not with 32bit PCs anymore.

Can't we disable publishing kernels for i586/i686 in kernel:stable repository? Removing the broken kernel RPMs files would be more difficult, I'm afraid.

Comment 4 Fabian Vogt 2016-03-16 12:18:40 UTC

(In reply to Dominique Leuenberger from comment #2)
> (In reply to Fabian Vogt from comment #1)
> > Definitely the same issue.
> 
> On a 13.1 build? We should never ever have binutils 2.26 in the play there.

Kernel:stable has only a single repository for x86*: "standard", which uses openSUSE:Factory/standard.

Comment 5 Dominique Leuenberger 2016-03-16 12:21:32 UTC

(In reply to Fabian Vogt from comment #4)
> (In reply to Dominique Leuenberger from comment #2)
> > (In reply to Fabian Vogt from comment #1)
> > > Definitely the same issue.
> > 
> > On a 13.1 build? We should never ever have binutils 2.26 in the play there.
> 
> Kernel:stable has only a single repository for x86*: "standard", which uses
> openSUSE:Factory/standard.

oh! Nice setup - I missed that, but this explains it of course, yes. Thanks for the clarification.

Comment 6 Axel Köllhofer 2016-03-16 15:46:48 UTC

(In reply to Fabian Vogt from comment #1)
> Definitely the same issue.

Then sorry for posting a duplicate, I was just slightly confused as in Tumbleweed this issue was already present in kernel 4.4.4, while Kernel:stable kernels 4.4.4 and 4.4.5 still worked. 

I missed the point that the problem is not the kernel itself and considering the fact that kernel updates in Tumbleweed are always a bit behind those in Kernel:stable, this (at least now) makes perfect sense to me.

> Almost: The kernel is loaded into memory just fine, but it needs to
> copy/decompress itself to a different location, which does not work
> correctly with the latest binutils in factory, which Kernel:stable is built
> with.

Thanks for clarification.

Greetings,

AK