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? -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
