Unable to boot 2.6.16-hardened-r9 (weird error)

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Unable to boot 2.6.16-hardened-r9 (weird error)

gentuxx
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

I'm trying to get an SELinux system up and running and not having much
success with the 2.6 kernel.  I had a bootable config, but didn't
record/backup the config after it worked, and it got borked when
trying to add SElinux features.  SILO sucks.  Anyway, now when I try
*ANY* 2.6 kernel, the boot fails with the error "YEEE, Ultrasparc sbus
not found".  Um, this is an Ultra5 with PCI/IDE, so why is the sbus
becoming an issue?  I've found the following two config options in the
kernel config:

CONFIG_SBUS=y
CONFIG_SBUSCHAR=y

....they seem to be automatically enabled, and don't show up in `make
menuconfig'.  (There are a couple more 'SBUS' options that are there,
but they aren't enabled.)  I've tried compiling/booting kernels
(2.6.16-gentoo-r11/2.6.17-gentoo-r1/2.6.16-hardened-r9) with *and*
without these options enabled, but I get the same error everytime.
So, what the heck?  What's causing this seemingly weird error?  How
can I find out whether the SBUS is *expected* and not found (in the
kernel and not the system), or *not expected* and found (on the system
and not in the kernel)?

TIA

- --
gentux
echo "hfouvyyAhnbjm/dpn" | perl -pe 's/(.)/chr(ord($1)-1)/ge'

gentux's gpg fingerprint ==> 5495 0388 67FF 0B89 1239  D840 4CF0 39E2
18D3 4A9E
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)

iD8DBQFErqf1TPA54hjTSp4RArjRAKDyBlYlwvD7PtLnor1zl95k0A0VcQCgl0OB
9T8XsNKUWozKJ5yzmN7zofU=
=2IQo
-----END PGP SIGNATURE-----

--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Unable to boot 2.6.16-hardened-r9 (weird error)

Hamish Greig
On Saturday 08 July 2006 04:29, gentuxx wrote:
> "YEEE, Ultrasparc sbus
> not found".  Um, this is an Ultra5 with PCI/IDE, so why is the sbus
> becoming an issue?  I've found the following two config options in the
> kernel config:
>
> CONFIG_SBUS=y
> CONFIG_SBUSCHAR=y

If a driver being built relies on one of those, then it is not
viewable/selectable. In drivers/atm, drivers/parport, drivers/net and
drivers/scsi selecting certain hardware/drivers automatically enables them
(from memory of a similar problem trying to tftpboot an ultra5/10 with a
config modified from an e3000 kernel)
You can find out what is actually making those "invisible" by grepping your
kernel sources for SBUS or SBUSCHAR and piping the results through grep again
and finding "depends"
grep -r SBUS "/path/to/kernel-sources/"  | grep  depends

then look at the Kconfig files listed and see what is "depending" on SBUS and
turn it off.

HIH

Hamish

--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Unable to boot 2.6.16-hardened-r9 (weird error)

gentuxx
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hamish Greig wrote:

> On Saturday 08 July 2006 04:29, gentuxx wrote:
>> "YEEE, Ultrasparc sbus
>> not found".  Um, this is an Ultra5 with PCI/IDE, so why is the sbus
>> becoming an issue?  I've found the following two config options in the
>> kernel config:
>>
>> CONFIG_SBUS=y
>> CONFIG_SBUSCHAR=y
>
> If a driver being built relies on one of those, then it is not
> viewable/selectable. In drivers/atm, drivers/parport, drivers/net and
> drivers/scsi selecting certain hardware/drivers automatically enables them
> (from memory of a similar problem trying to tftpboot an ultra5/10 with a
> config modified from an e3000 kernel)
> You can find out what is actually making those "invisible" by grepping
your
> kernel sources for SBUS or SBUSCHAR and piping the results through grep
again
> and finding "depends"
> grep -r SBUS "/path/to/kernel-sources/"  | grep  depends
>
> then look at the Kconfig files listed and see what is "depending" on
SBUS and
> turn it off.
>
> HIH
>
> Hamish
>
Thanks for the response, but it turned out to be something much more
trivial.  Upon closer inspection, I discovered that I had NOT enabled
PCI support in the kernel I was trying to compile.  So, because the
SBUS options were enabled by default, it was trying to load the SBUS
when it couldn't recognize the PCI bus.

What you suggest seems like an interesting way to pare down the
kernel, though.  If I ever decide that I want a leaner kernel, I might
try what you suggested.

Thanks!

- --
gentux
echo "hfouvyyAhnbjm/dpn" | perl -pe 's/(.)/chr(ord($1)-1)/ge'

gentux's gpg fingerprint ==> 5495 0388 67FF 0B89 1239  D840 4CF0 39E2
18D3 4A9E
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)

iD8DBQFErz0tTPA54hjTSp4RAoGsAKDaWrXDoorepBi9+8ImjzagkOKjywCfYQoa
zJXQkgqGe2iXlynKg+3blVs=
=cIrd
-----END PGP SIGNATURE-----

--
[hidden email] mailing list