Re: 2.6.22-git17 boot failure

[Jeremy Fitzhardinge <jeremy@goop.org>]

Tilman Schmidt wrote:
> Alright, I know what's going on now, and it looks like a problem with
> the Opensuse init script. In fact, the initrd for the Xen enabled
> kernel got a *different* init script than the one for the non-Xen one.
> The difference being:
>   

Phew, I was getting worried there for a minute.  Does the install script
check for CONFIG_XEN in the kernel config or something?

> --- /tmp/testing/init   2007-07-24 15:53:58.000000000 +0200
> +++ /tmp/xentest/init   2007-07-24 15:54:16.000000000 +0200
> @@ -308,6 +308,9 @@
>      fi
>  fi
>
> +caps="$(</proc/xen/capabilities)"
> +if [ "$caps" != "${caps%control_d*}" ]; then
> +
>  params=
>  for p in $(cat /proc/cmdline) ; do
>    case $p in
> @@ -509,6 +512,32 @@
>  echo "Loading dm-snapshot"
>  modprobe dm-snapshot $params
>
> +else
> +
> +params=
> +for p in $(cat /proc/cmdline) ; do
> +  case $p in
> +    dm-mod.*)
> +      params="$params ${p#dm-mod.}"
> +      ;;
> +  esac
> +done
> +echo "Loading dm-mod"
> +modprobe dm-mod $params
> +
> +params=
> +for p in $(cat /proc/cmdline) ; do
> +  case $p in
> +    dm-snapshot.*)
> +      params="$params ${p#dm-snapshot.}"
> +      ;;
> +  esac
> +done
> +echo "Loading dm-snapshot"
> +modprobe dm-snapshot $params
> +
> +fi
> +
>  echo -n "Waiting for /dev/mapper/control to appear: "
>  for i in 1 2 3 4 5; do
>      [ -e /dev/mapper/control ] && break
>
> In clear: the Xen init script reads /proc/xen/capabilities and if it
> doesn't find the magic string "control_d" in it, willfully *skips*
> loading all the SCSI and ATA stuff.
>
> The missing piece then is the innocent little line:
>
> /init: line 311: /proc/xen/capabilities: No such file or directory
>
> appearing on my screen during boot ... BOOM!
>
> If I just diligently type all the skipped modprobe commands
>
> $ modprobe scsi_mod
> $ modprobe sd_mod
> $ modprobe processor
> $ modprobe thermal
> $ modprobe libata
> $ modprobe ahci
> $ modprobe pata_marvell
> $ modprobe scsi_transport_spi
> $ modprobe aic7xxx
> $ modprobe fan
> $ modprobe edd
> $ ^D
>
> into the fallback shell by hand, the system comes up without further ado.
>
> So there, case solved. Now you sort it out who's to fix what. :-)
>   

Well, definitely on the suse side.  I don't think there's any point in
me renaming CONFIG_XEN to something less obvious to avoid this
breakage.  I guess the proper fix is to carry on as if its a native boot
if /proc/xen/* is missing, since they'll never be there when not booting
under Xen (and unlikely to be there in a paravirt-xen boot anyway).

    J