You are right. It is the fabric card's driver. I take it by the lpfc module you are running emulex cards. The best thing would be to grab the latest drivers from emulex and recompile for the kernel you want (2.4.21-37.ELsmp).

Man is a great resource. You can also use "info" as well.

ie. info cron

Just curious, have you tried switching from ALSA to OSS?

System -> Preferences -> Sound.

Change all the settings from ALSA to OSS.

Also, sometimes after an upgrade the ALSA ends up having the master channel mixer muted. Have you checked "alsamixer" to see what the sliders are set to?

What kernel version are you currently running? (uname -a)

There are a couple of things that have resolved the issue for people on the ubuntuforums...adding to the modprobe.conf:

options snd-pcsp index=-2
options snd slots=snd-hda-intel
options snd-hda-intel model=hp-m4
alias snd-card-0 snd-hda-intel
options snd-hda-intel enable_msi=1

or

options snd-hda-intel model=hp-m4 enable=1 index=0
options snd-hda-intel enable_msi=1

Source: http://ubuntuforums.org/showthread.php?t=1136670&highlight=Intel+82801I+%28ICH9+Family%29+sound

Hopefully that might help a little. :)

Really depends on what you are trying to achieve with your cluster. Are you trying to have a load balancer, or high-availability/failover redundancy?

This might be a good starting point for you:

http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Cluster_Suite_Overview/ch.gfscs.cluster-overview-CSO.html

lol, well, I will say for my "monkey business" that I did in a training class was this....

We had a "know it all" about everything. You know the type. No matter what your story is they have something better about the same thing....anyways, this particular person got very annoying, and they didn't lock down their box they were training on. So I just slipped in and added "shutdown now -r" as the last script to run in the init.d runlevel directories. As soon as the box got full up and running, the first thing it did was restart itself. Haha.

I like a good prank as much as the next person, but that guy just needed to be taken down a notch. It took him and the instructor a while to figure out what was going on. :)

The easiest way I do it is to change the runlevel setting real-time by letting init handle it.

Say I want to jump into the GUI mode (on most Linux distros):

telinit 5

Remember on Ubuntu they do it a little differently. You'd have to check where the SXXgdm script was sitting. Since the default is usually runlevel 2, and runlevel 3 probably starts the SXXgdm scritp you'd tell Ubuntu : telinit 3

To jump back to the regular non GUI:

telinit 3

(or in Ubuntu with your script that has already been controlled from the previous examples of this post): telinit 2

I also reboot the box in this manner or shut it down too:

telinit 6 = reboot
telinit 0 = shutdown

:)

Welcome to Linux! I applaud your interest and willingness to start and try Linux.

Reference your CD, most times it is a bad burn on a cheaper CD. You would need to first check the md5sum to make sure you got a good/full copy of the iso image you downloaded. You would have to download and install a tool for Windows to do that. Or if you downloaded it into your Ubuntu side, you can run from the command line:

md5sum <name of image>.iso

That will belch out a long hash number. You would need to compare that with what Remote-Exploit posts. If they differ you have an incomplete or corrupt iso.

The other thing to do is to open up /var/log/messages and look into it as to any error messages the box is recording. If you can hit the "esc" key while booting it should knock back to a scrolling dialogue. And you can look for error messages there.

Also, you might want to start with the manuals. Check the common errors and FAQ:

http://www.remote-exploit.org/backtrack_docs.html

Yeah, I'm not sure why Ubuntu did away with inittab (I know some groups want to use event.d as the new method). That is something worth research, and I might just do that. But either way, they did...they moved everything into /etc/event.d to control their runlevel scripts.

If you look at /etc/event.d, inside that directory is a file called "rc-default"

The code inside says:

# rc - runlevel compatibility
#
# This task guesses what the "default runlevel" should be and starts the
# appropriate script.

start on stopped rcS

script
runlevel --reboot || true

if grep -q -w -- "-s\|single\|S" /proc/cmdline; then
telinit S
elif [ -r /etc/inittab ]; then
RL="$(sed -n -e "/^id:[0-9]*:initdefault:/{s/^id://;s/:.*//;p}" /etc/inittab || true)"
if [ -n "$RL" ]; then
telinit $RL
else
telinit 2
fi
else
telinit 2
fi
end script

That is telling Ubuntu to enter into runlevel 2 at start up. Sweet...so we now know what runlevel it will boot up to at start, but now how do we kill off the GUI?

Inside the /etc/rc2.d directory (the directory that init will read and start up all scripts listed inside) you'll see the display manager call...usually looks like:

root@kryptikos:/etc/rc2.d# ls
README S20apport S50avahi-daemon S70dns-clean S99laptop-mode
S01policykit S20dkms_autoinstaller S50cups S70pppd-dns S99ondemand
S10acpid S20hotkey-setup S50NetworkManager S89anacron S99rc.local
S10apmd S20powernowd S50pulseaudio S89atd S99rmnologin
S10powernowd.early S20winbind S50rsync S89cron S99stop-readahead
S10sysklogd S24hal S50saned S90binfmt-support
S11klogd S25bluetooth S50system-tools-backends S98usplash
S12dbus [b] S30gdm [/b] S70bootlogs.sh S99acpi-support

If you check the README file in that directory it says to change the "S" to a "K"

The scripts in this directory are executed each time the system enters
this runlevel.

The scripts are all symbolic links whose targets are located in
/etc/init.d/ .

[b]To disable a service in this runlevel, rename its script in this directory
so that the new name begins with a 'K' and a two-digit number, where the
number is the difference between the two-digit number following the 'S'
in its current name, and 100. To re-enable the service, rename the script
back to its original name beginning with 'S'.[/b]

For a more information see /etc/init.d/README.

So the quickest way is to issue the command:

mv /etc/rc2.d/S30gdm /etc/rc2.d/K30gdm

I know that answer is a little longer than probably needed, but it gives a good background :)

According to SAP, Ubuntu isn't supported at all...which means their developers won't be too concerned about it. There were a few things over on the SAP Community though about Ubuntu. One of the things I found was:

https://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/4b5f23d3-0901-0010-19b6-d2e98d5586fb&overridelayout=true

Since Ubuntu is based on the Debian architecture that might lead you in the direction you need to successfully install.

Also you didn't mention what version of Ubuntu you had. The LTS or just one of the regular releases? A post I found stated:

Hi,

last week I have successfully installed R3 Enterprise 4.7 (Basis 6.20) on Ubuntu Breezy Badger (Linux kernel 2.6.12) just for test reasons and it works flawlessly.

You just need to cancel he installation before the SAP start and upgrade the SAPkernel to the newest 6.40 and generate standard locale ISO-8859-1, as Breezy Badger comes only with Unicode UTF-8 locales generated.

Regards,
Branislav

However that was an old post in 06.

I would reference the SAP Community for more specifics and folks who have/or are trying to do what you are interested in:

https://www.sdn.sap.com/irj/scn

With a notebook it really comes down to the video and wireless cards IMHO. Also, as far as your requirements go you can pair down any distribution and not load up all the software apps that are available at installation.

I run Ubuntu on my laptops because of the sheer ease it is easy to install, the fact that they have tools that already handle a good chunk of proprietary hardware/drivers (think Broadcom wireless cards and ATI video cards), and the community resources are massive. I've run various Ubuntu flavors on my laptops for the past 3 years.

But that's just my two cents. I've also run openSUSE and Fedora.

:)