Bug#523942: linux-image-2.6.26-2-s390 will not boot!
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 s390 platform? Or do you use a common platform
(such as i386) to build kernel images for all platforms? Has the
Debian installer been rebuilt with the new kernel image? If so, I'll
try it out to see if it works.
I doubt that this has anything to do with the problem, but I'll
mention it anyway just for grins because I'm running out of ideas.
There are a couple of departures in my environment from the typical
plain vanilla Debian install. First of all, the minidisks that I
use are CMS-formatted minidisks, not Linux cdl minidisks. They
have been processed under CMS with the FORMAT and RESERVE commands,
which creates a single implicit partition on the minidisk consisting
of the reserved CMS file. The dasdfmt and fdasd commands under
Linux are therefore not used in preparing these minidisks. mke2fs
is used, however, to create a file system on the implicit partition.
(In the case of the swap disk, mkswap is used instead of mke2fs.) Second,
with the exception of the /boot partition, which is controlled by
the dasd_eckd_mod driver, all other partitions are controlled by
the dasd_diag_mod driver. Here is my setup:
----------
vdev Linux device Partition Mount Point Driver
---- ------------ --------- ----------- -------------
0200 dasda dasda1 / dasd_diag_mod
0201 dasdb dasdb1 /boot dasd_eckd_mod
0202 dasdc dasdc1 /home dasd_diag_mod
0203 dasdd dasdd1 swap dasd_diag_mod
----------
I would use dasd_diag_mod for all of the minidisks, if I could;
but zipl requires that the /boot partition use the ECKD
discipline. The dasd_diag_mod driver can only be used in a
virtual machine under z/VM. When I IPL, I use the CP command
IPL 0201
I know from experience that it is absolutely critical that
dasd_diag_mod get loaded BEFORE dasd_mod. Otherwise, the
permanent root file system cannot be mounted. Is it possible that
anything in the stock kernel might cause dasd_mod to be loaded
before dasd_diag_mod?
Here are some pertinent files that control this:
/etc/modprobe.d/dasd:
----------
options dasd_mod dasd=0.0.0200(diag),0.0.0201,0.0.0202-0.0.0203(diag)
----------
/etc/initramfs-tools/modules:
----------
dasd_diag_mod
dasd_eckd_mod
dasd_mod
----------
/etc/fstab:
----------
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
/dev/dasda1 / ext3 defaults,errors=remount-ro 0 1
/dev/dasdb1 /boot ext3 defaults 0 2
/dev/dasdc1 /home ext3 defaults 0 2
/dev/dasdd1 none swap sw 0 0
----------
/etc/zipl.conf
----------
[defaultboot]
defaultmenu = menu
:menu
target = /boot
1 = debian
2 = old
default = 1
prompt = 1
timeout = 10
[debian]
target = /boot
image = /boot/vmlinuz
ramdisk = /boot/initrd.img
parameters = root=/dev/dasda1 vmhalt=LOGOFF vmpoff=LOGOFF
[old]
target = /boot
image = /boot/vmlinuz.old
ramdisk = /boot/initrd.img.old
parameters = root=/dev/dasda1 vmhalt=LOGOFF vmpoff=LOGOFF
optional = 1
----------
Currently, /boot/vmlinuz is a symbolic link to /boot/vmlinuz-2.6.26-custom2c-s390,
/boot/initrd.img is a symbolic link to /boot/initrd.img-2.6.26-custom2c-s390,
/boot/vmlinuz.old is a symbolic link to /boot/vmlinuz-2.6.26-2-s390, and
/boot/initrd.img.old is a symbolic link to /boot/initrd.img-2.6.26-2-s390.
This makes "debian", the default system, point to the kernel image that works,
2.6.26-custom2c-s390; and "old", which can be selected by request with
#CP VINPUT VMSG 2
from the zipl menu points to the stock kernel that doesn't work, 2.6.26-2-s390.
The reason that I have not bothered to give these details before is that
(a) linux-image-2.6.26-1-s390 works and (b) linux-image-2.6.26-2-s390x works.
Both of these images work in the same setup as above. We need to concentrate
on that. Why would the above two images work but not linux-image-2.6.26-2-s390?
Reply to: