On Sun, Aug 16, 2015 at 05:27:21PM -0400, Stephen Powell wrote: > That's because sysconfig-hardware isn't in the initial RAM file system, > and therefore doesn't bring DASD volumes online until the permanent root > file system has been mounted. As much as I dislike sysconfig-hardware, it's probably the thing we should do: Include a hook script that includes enough of sysconfig-hardware to bring up hardware early in the initrd. (Best to not fail if any of it is missing at this point. Debugging from within the initrd is awkward.) I was under the impression -- mostly because of the presence of the mentioned hook script -- that this already happened. > If the permanent root file system is a partition on a physical volume, > there is exception code in > > /usr/share/initramfs-tools/scripts/init-premount/sysconfig_hardware > > to bring that specific volume online early, but only if the root device > is specified in zipl via the form > > root=/dev/disk/by-path/ccw-0.0.xxxx-partz > > where xxxx is the device number and z is the partition number. It must > be in this form so that > > /usr/share/initramfs-tools/scripts/init-premount/sysconfig_hardware > > knows the device number and can bring it online via > > echo 1 >/sys/bus/ccw/devices/0.0.xxxx/online > > This is one reason, but not the only reason, why I advised the OP not > to make the root file system a logical volume. The correct thing is to fix that. There are multiple facets to that. I guess the easiest is to include the list of /etc/sysconfig/hardware in the initrd, in the hope that the installer writes it out already with all configured DASDs. Otherwise you need to figure out the root disks, which is hard to generalize on Linux. (No "give me all underlying disks for this mount point" command.) > On my systems, I add sysconfig-hardware to the initial RAM file system, > using the method described in > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621080 > > but of course this cannot be done until *after* installation. > The main reason that I do it is so that I can specifiy the root > file system in zipl as > > root=UUID=... > > which will only work if all the DASD volumes have been brought online > already, and therefore udev has found the volumes and their partitions > and has created symbolic links for them in /dev/disk. This makes > the boot process much closer to how it works on all other hardware > platforms that Debian supports. I'm sympathetic to making it more alike other platforms. The route SUSE went with running grub2 from a kernel image booted by zipl and then kexec()ing into the right kernel and initrd is a bit too much, though. (OTOH, if someone wants to implement that for Debian that'd be great.) Kind regards Philipp Kern
Attachment:
signature.asc
Description: Digital signature