I issued the mkinitramfs command with the exact options you specified,
then re-ran zipl, then rebooted. No change in results. But the
custom kernel built with kernel-package works just fine. Could this be
some kind of cross-compilation problem, perhaps? Do you build your
s390 kernels on an
On Sat, Jul 04, 2009 at 08:28:38PM -0400, STEPHEN POWELL wrote:
I notice that the fix for this bug (div64.c) has finally made it into the
official
Debian kernel source code. However, the latest stock kernel, 2.6.26-2-s390,
revision
2.6.26-17, still won't boot in my virtual machine under
I notice that the fix for this bug (div64.c) has finally made it into the
official
Debian kernel source code. However, the latest stock kernel, 2.6.26-2-s390,
revision
2.6.26-17, still won't boot in my virtual machine under z/VM 5.4.0, running in
an IFL LPAR
on a z/890. I still have to build
Yes, 15lenny2 was a security update. This fix is queued for 2.6.26-16
which should be included in Debian 5.0.2.
Well, I guess that makes sense; since the kernel that is packaged with
the Debian installer needs to be replaced too. Even s390x kernels,
which are not affected by this bug, are
The latest kernel update, revision 2.6.26-15lenny2, still does not
contain the fix for this problem.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
On Mon, May 18, 2009 at 03:18:38PM -0400, STEPHEN POWELL wrote:
The latest kernel update, revision 2.6.26-15lenny2, still does not
contain the fix for this problem.
Yes, 15lenny2 was a security update. This fix is queued for 2.6.26-16
which should be included in Debian 5.0.2.
--
dann frazier
On Tue, Apr 21, 2009 at 09:32:02AM -0400, STEPHEN POWELL wrote:
Please give it a try anyway.
So what you want me to do is to download the Debianized kernel source package
aptitude install linux-source-2.6.26
then obtain the patch from http://lkml.org/lkml/2009/3/18/79, apply the patch,
Actually, I decided to go ahead and do the plan I had outlined, just for grins,
while I was waiting on an answer.
If it didn't work, and Frans said yes, do that, I could then say it didn't
work right away and save time.
But it did work!
Here is what I did, as close as I can remember it. I was
Correction. The s390 server did not have two virtual CPUs. It had a *LIMIT*
of two virtual CPUs. In other words, its CP directory entry contained
MACH XA 2
This statement creates only one virtual CPU, but allows a second one to be
defined, if desired, by means of the
CP DEFINE CPU
Could http://bugs.debian.org/511334 be related to your problem? There's a
link to patch in one of the last messages.
See especially messages #57 and #65.
Cheers,
FJP
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Could http://bugs.debian.org/511334 be related to your problem? There's a
link to patch in one of the last messages.
See especially messages #57 and #65.
It's possible that they may be related. The difference, though, is that the user
in problem number 511334 was running in a virtual machine
STEPHEN POWELL wrote:
My problem, on the other hand, has always been that the kernel hangs
right before the permanent root file system gets mounted. I've always
been able to get that far but no farther. For me, the key is that the
s390x kernel works flawlessly, but the s390 kernel hangs.
Can you boot the old kernel and unpack the initramfs to see if the
needed modules got added? See the DEBUG section of initramfs-tools(8)
for a command to do the unpacking.
As you know, the initial RAM file system is not included with the kernel
image package but is built dynamically during
I just tried re-building the initial RAM file system for the 2.6.26-1-s390
kernel image, rerunning zipl, and rebooting.
It came up fine. It does not appear to be a problem with the build process for
the initial RAM file system.
If it is, it is a build problem which is specific to the new kernel
By the way, I have another server that runs the 64-bit version of the kernel
image (linux-image-2.6.26-2-s390x), and it works fine.
Either the bug affects only the 31-bit version of the kernel, or there is an
environmental difference of some kind.
I have found an environmental difference between the two servers, one of which
runs linux-image-2.6.26-2-s390x (and will boot)
and the other of which runs linux-image-2.6.26-2-s390 (and will not boot). The
s390x server has only one virtual CPU.
The s390 server has two virtual CPUs. I changed
Package: linux-image-2.6.26-2-s390
Version: 2.6.26-15
Severity: critical
This particular Linux kernel image will not boot on a virtual machine in ESA
mode under z/VM. I have not tried other platforms (LPAR, for example).
Here is the boot log:
--
Booting default (debian)...
[
On Mon, Apr 13, 2009 at 03:45:33PM -0400, STEPHEN POWELL wrote:
Package: linux-image-2.6.26-2-s390
Version: 2.6.26-15
Severity: critical
This particular Linux kernel image will not boot on a virtual machine in ESA
mode under z/VM. I have not tried other platforms (LPAR, for example).
Not
18 matches
Mail list logo
