linux-kernel - Re: 2.6.22-git17 boot failure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <46A64CD5.2030800@goop.org>
Date:	Tue, 24 Jul 2007 12:02:45 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Tilman Schmidt <tilman@...p.cc>
CC:	Olaf Hering <olh@...e.de>, LKML <linux-kernel@...r.kernel.org>,
	Gabriel C <nix.or.die@...glemail.com>,
	Andi Kleen <andi@...stfloor.org>
Subject: Re: 2.6.22-git17 boot failure

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/