Bug#340344: yaird: Fail to create initrd on s390/s390x
On Thu, Dec 01, 2005 at 12:03:58PM +0100, Ivan Warren wrote:
> 1) Hardware.pm was missing "load CcwDev" and "load CcwMap" (easy fix)
Oops, thanks for the fix, is in the repo now.
> 2) The initramfs gets built :
OK, looks normal.
> 3) Boot fails :
> Device /sys/block/dasda/dev seems to be down.
> Debugging opportunity, type ^D to continue.
So there's something extra we need to figure out ...
> Possible explanation :
>
> dasd_mod won't autodetect dasds unless specifically requested to do so !
> Apparently, the appropriate parameter would be :
>
> dasd=autodetect
>
> (based on drivers/s390/block/dasd_devmap.c)
Possibly.
If you do
echo options dasd_mod > /etc/modprobe.d/test123
and rerun yaird, the parameter should be added to the image
(you can see this happening in the -v and -d output)
However, I'm curious why this would be necessary now and not for
your old kernel. Lets see if we can get this to work without
needing changes to your modprobe configuration.
If I'm correct, you're running under 2.6.11
with initrd-tools, trying to get 2.6.14 to boot with yaird.
Could you extract the /sbin/init script from a 2.6.11 initrd
and post it? If it's convenient to place the whole content
of initrd somewhere online that could also be usefull, but
mostly i'm after the /sbin/init.
Is there any difference in kernel command line parameters when booting?
> However, this would mean guaranteed failure on some dasd configuration
> changes (this requires a small explanation of the S/390 and z/Arch I/O
> architecture : Each device is known by 2 ids : A subchannel number and a
> device number. The "device number" represents the 'physical' connection (ex
> : 010A means device 0A on channel 01).. The subchannel number is a sequence
> number in the configuration, and *THAT* is what is used to perform I/O
> operations (a device cannot be addressed directly by its device number -
> ONLY by its subchannel number).. Furthermore, any autodetection scheme would
> most probably use that subchannel numbering to name devices (or more exactly
> to assign minor numbers). If 0108 is your 1st dasd device it will most
> probably be named 'dasda'.. If a new dasd is inserted at 0100, chances are
> 0108 will now be called 'dasdb' - *however* if dasd_mod is passed a specific
> list of dasd devices, the naming will probably remain unchanged - regardless
> of any configuration change - the 1st device listed will be named 'dasda').
>
> The sequence numbering is also model dependent. on IBM real iron, they are
> usually related to the order in which they appear in the IOCDS (a microcode
> configuration file that describes the system's I/O configuration). On z/VM
> (IBM's virtualization solution) the numbering is related to the order in
> which the devices are declared in the CP directory (The virtual machines
> definition file). On hercules (an open source S/370, S/390 and z/Arch
> emulator, which I am using for these tests) the subchannels are numbered
> based on the order in which they appear in the hercules configuration
> file... However, the architecture makes *NO* guarantee whatsoever as to the
> actual order and even whether that number remains identical between each POR
> (Power On Reset) - The only architectural guarantee is that the numbering is
> contiguous (no holes).
There's a known issue that if the hardware changes, the yaird image will
not automatically cope with that.
However, for the case you describe the path in /sys/devices may change,
but the path in /sys/block should remain stable. Otherwise your initrd
would need to use /dev/disk/by-label/ to boot reliably, and I don't think
support for that is in initrd-tools.
For now, lets look at differences between initrd and yaird-generated image,
and keep the sequence numbering in mind as a possible alternative lead.
Thanks,
Erik
Reply to: