• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Linux wont install

Red Squirrel

Red Squirrel

No Lifer
Don't know if this is a linux issue or hardware issue but I'm in the process of building a server I keep having to RMA parts because stuff these days suck and is not made properly the first time. We seriously need to stop outsourcing to china, this is retarded. Can't even open a brand new motherboard box and have something that works. But anyway...

Trying to install CentOS 5.2 x64 and it keeps hanging at /sbin/loader. I rebooted a bunch of times, was getting a fan error (since I'm not using those 3 pin connectors so it thinks the system has no fans) rebooted a bunch of times again, now it keeps hanging at ACPI: PCI Root Bridge [PCO0]. It actually freezes the whole machine when it gets there. can't hit ctrl+alt+del or anything.

Ram tests ok, the CD is ok since I installed off it before. Any suggestions?

I'm googling it and lot of people have this problem but it suggests disabling stuff like usb and sata. I don't have a ps2 keyboard, and this is going to be a server, I can't just be going disabling stuff. Is there another way or am I screwed again? Sick of having to return stuff...


Motherboard is an Intel DG33TL
Ram is 8GB OCZ (don't recall exact specs)
Cpu is core2Quad
 
Off topic but in some other thread you mentioned that you were going to try F9. Just be careful of this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=446669

On certain chipset / BIOS / number of drives installed combinations it'll crash on boot and there is no good workaround. On other configurations it works perfectly (one of my systems suffers from this, a some others do not). If it gets past first boot, though, F9 is a good test of your system's LINUX stability, and might even be a good server OS to run; in SOME ways I'd trust it more than CentOs (better hardware compatibility with a wider range of devices).

As for Centos5 I know I had a similar annoying problem when trying to install it. I forget exactly what the problem was or what the fix was, however. It crashed during install a few times; eventually I got it to work. Not much difference with Fedora or Ubuntu or SUSE et. al. there.. there are some BIOS settings / BIOS bugs / OS bugs that will get in your way and crash your install or installed system. Learn to work around them and it'll probably run darn near forever.

I'd unplug any drive you're not actually using to install onto. Once installed, apply all updates for the OS, reboot, configure basic settings, do some stability tests. If that works well then try to bring your other drives / RAIDs / whatever online after the system is stabilized and fully updated.

If you have USB ports you cannot disable try to set they to "enable legacy devices", "enable usb keyboard support", "enable usb mouse support", "usb 2.0 support: disabled ; use usb 1.1 full speed not usb 2.0 high speed".

Set "Plug & Play OS Installed? NO" for a start, and if you have problems you can always try other settings (same with USB stuff).

As sad as it is, I find that it is OFTEN necessary to have a PS/2 keyboard since sometimes USB just doesn't work even here in almost 2009, what, 14 years after they introduced USB to the PC and claimed it would obsolete PS/2 by 1998.... Find a cheap $4 keyboard, $4 mouse and leave it in the closet except when you're debugging or doing BIOS stuff or whatever.

IDK what the boot flags are for CenTOS 5 exactly, but similar to these are often helpful for me on unstable systems / kernels:
nodmraid (unless you are using it)
noapic
noacpi
acpi=off
xdriver=vesa

and DELETE:
rhgb
quiet

These all being the kernel's boot line arguments you can edit in the grub menu or CD boot menu....





Originally posted by: RedSquirrel
Don't know if this is a linux issue or hardware issue but I'm in the process of building a server I keep having to RMA parts because stuff these days suck and is not made properly the first time. We seriously need to stop outsourcing to china, this is retarded. Can't even open a brand new motherboard box and have something that works. But anyway...

Trying to install CentOS 5.2 x64 and it keeps hanging at /sbin/loader. I rebooted a bunch of times, was getting a fan error (since I'm not using those 3 pin connectors so it thinks the system has no fans) rebooted a bunch of times again, now it keeps hanging at ACPI: PCI Root Bridge [PCO0]. It actually freezes the whole machine when it gets there. can't hit ctrl+alt+del or anything.

Ram tests ok, the CD is ok since I installed off it before. Any suggestions?

I'm googling it and lot of people have this problem but it suggests disabling stuff like usb and sata. I don't have a ps2 keyboard, and this is going to be a server, I can't just be going disabling stuff. Is there another way or am I screwed again? Sick of having to return stuff...


Motherboard is an Intel DG33TL
Ram is 8GB OCZ (don't recall exact specs)
Cpu is core2Quad
Click to expand...

 
Depending on what you're doing with the box (better not be any fancy GPU / USB / scanner / printer peripheral stuff or device driver hacking), you could try a longshot and see if you get lucky -- download VMWARE ESXi 3.5 current version, and just SEE if it boots / works on your hardware. It PROBABLY will be even more picky about hardware compatibility than CENTOS though. But if it DOES work... you could always install CENTOS as a guest under that.

Assuming that doesn't work, ...
FEDORA,
SUSE, ...
FreeBSD
OpenBSD
OpenSolaris

...in order of preference if what you really wanted was a LINUX box.

If you really wanted something so "serverish" then heck maybe Solaris / FreeBSD / OpenBSD would be just as good or better than Centos.

 
Actually this will be partially a VM server anyway.... so I may as well give ESXi a try. My goal is to do most of the server stuff on host but theres a few stuff I got in VMs, but I can just VM everything too.
 
I managed to install FC7 since I happened to have that CD. FC9 64-bit is almost done downloading so hopefully that works.

Only issue is FC7 did not see the built on nic so I hope FC9 will. And I can't put another nic in there since if I do the system wont power on, it just keeps powering off then back on non stop the second I plug in the psu. I was originally going to go dual nics and use a PCI one and the built on, but that wont work, so the built on better work out in FC9 or I'm screwed.
 
FC7, FC8 installed OK IIRC.. The FC9 dmraid/nash first boot after install bug is nasty but might not affect you depending on your chipset/BIOS/drive setup.

Fedora has so many updates for *any* of its current versions that you really can't know what is going to work or not (e.g. your NIC) until you've installed all the kernel and driver and so on updates for whatever version you install. You can always pull the update rpms for the kernel stuff and various drivers and install them manually off a CD/flash disk/USB disc via RPM. I've seen plenty of cases of things not working in the default install that a kernel update later fixes.

Sometimes with NICs they can actually work OK with the included driver but all that is missing is adding the PCI Vendor / Device ID numbers to the compatibility table of the existing driver so that the system knows what driver to use for an "unknown" model card. This is sadly often the case with common Marvell, Nvidia, et. al. NICs.

What chip is the NIC?

I personally would be worried about a system that doesn't boot if you add in a NIC. Sounds like PSU overload or a NIC card that is defective / short circuiting or some other kind of serious problem unless it is a hell of a BIOS bug but usually BIOS doesn't care so much about NICs assuming their onboard boot ROMs are not enabled and PXE boot is disabled...

I keep a couple of UNIX friendly USB 2.0 10/100 Mbit NICs around in case I need to add another NIC to a box quickly or in case the on-board NIC isn't supported by a driver and I need another choice or something. Some common (older model especially) Wireless NICs can be handy for similar reasons.

Did you try the noapic, noacpi, ... kernel boot switches and they didn't help?

You might want to try pulling non OS drives / controllers when you install FC9 to see if that helps you avoid its dmraid/nash/lvm bug.

 
The nic was a marvell, rather old. Bought it maybe 3 years ago for like 30 bucks so it was as low end as it gets as far as gig nics go. I automaticly assumed it was the nic so threw it out. It was basically sitting on the same shelf as all of the ISA/486 stuff that I keep (I don't know why). The boot flags like noacpi did not work.

FC9 got further though, I'm at the disc check portion which happens after the /sbin/loader and the PCI Root Bridge part. Only danger is I have seen instances where it hangs right after testing the disc (or after saying no) so we'll see...

Also should I expect more issues given this is a 64-bit version? the FC7 disc I had was 32-bit.
 
64 bit linux is perfectly stable these days IMHO.

Only if you're using unstable and very badly supported 3rd party binary non open source software like FLASH browser plugins, stuff like Quicktime, NDISWRAPPER drivers for NIC, various 3rd party WLAN / sound drivers, et. al. will you expect more probability of problems. Basically almost nothing you should be running on a server anyway so it should be a non-issue. Usually the open source drivers for sound / NIC / etc. work well enough for a broad enough set of hardware that using obsolete / unsupported OEM binary drivers for some old kernel is usually a mistake.

 
well so far so good! Got scared for a bit since I got a "error!" dialog (no actual error) after testing the dvd (said dvd was ok, then I hit ok to continue and got the error) I rebooted then chose not to test the CD as I only do it the first time I use the dvd anyway and so far so good. It even found my sata drive, which was another thing I was afraid of. I'm in the process of choosing packages now. So at this point I *should* be good, hopefully. Guess centOS just did not like my hardware.

Once this is done, is there some kind of test/diag I can run to ensure my system is stable hardware wise? I want to ensure everything is 100% before I put this into production.
 
Don't go too crazy optimizing what packages you want now (suggestion; YMMV).
You'll be updating hundreds of them with the update system once you finish installing the OS and boot for the first time (I assume you meant you're selecting packages in anaconda, the OS installer).
Also your biggest risk of crash is that nash bug which you won't know if you'll encounter until the install finishes and the system comes up booting successfully for the first full time (or not).

If you mostly know what packages you want off the top of your head, pup, pirut, yum, et. al. package search / installation tools will help you get them and update them.

Anyway good luck!

To check stability, do all the updates to the latest versions, then reboot, run some intensive I/O and CPU / Memory programs for 72 hours and see how it behaves.

If you plan to have it support hibernate / sleep / suspend / UPS auto-shutdown test those for sure in detail (several consecutive cycles of each) before going into production; they are fairly likely to cause crashes or lost data if they don't work 100%.

 
Various burn in / test / benchmark stuff:


bonnie++.x86_64 : Filesystem and disk benchmark & burn-in suite
Available Packages
Name : bonnie++
Arch : x86_64
Version : 1.03a
Release : 9.fc9
Size : 45 k
Repo : fedora
Summary : Filesystem and disk benchmark & burn-in suite
URL : http://www.coker.com.au/bonnie++/
License : GPL
Description: bonnie++ filesystem and disk benchmark suite aggressively reads & writes in various ways
: on your filesystem then outputs useful benchmark performance data. bonnie++ is also
: useful as a hardware, disk, and filesystem stability test, exposing some types of hardware
: or kernel failures that would otherwise be difficult to detect. Do not leave bonnie++
: installed on a production system. Use only while you test servers.


tiobench.x86_64 : Threaded I/O benchmark
Name : tiobench
Arch : x86_64
Version : 0.3.3
Release : 7.1
Size : 37 k
Repo : fedora
Summary : Threaded I/O benchmark
URL : http://tiobench.sourceforge.net
License : GPLv2+
Description: Tiobench is a portable, robust, fully-threaded file system benchmark especially designed
: to test I/O performance with multiple running threads.

iozone.x86_64 : Filesystem benchmarking utility
Name : iozone
Arch : x86_64
Version : 3
Release : 5.fc9
Size : 258 k
Repo : fedora
Summary : Filesystem benchmarking utility
URL : http://www.iozone.org
License : Freeware
Description: IOzone is a filesystem benchmark tool. The benchmark generates and measures a variety of
: file operations. Iozone has been ported to many machines and runs under many operating
: systems. Iozone is useful for performing a broad filesystem analysis of a vendors
: computer platform. The benchmark tests file I/O performance for the following operations:
: Read, write, re-read, re-write, read backwards, read strided, fread, fwrite, random read,
: pread ,mmap, aio_read, aio_write.


hardinfo.x86_64 : System Profiler and Benchmark
Name : hardinfo
Arch : x86_64
Version : 0.4.2.3
Release : 5.fc9
Size : 241 k
Repo : fedora
Summary : System Profiler and Benchmark
URL : http://hardinfo.berlios.de/
License : GPLv2
Description: HardInfo can gather information about a system's hardware and operating system, perform
: benchmarks, and generate printable reports either in HTML or in plain text formats


fs_mark.x86_64 : Benchmark synchronous/async file creation
Name : fs_mark
Arch : x86_64
Version : 3.2
Release : 2.fc9
Size : 16 k
Repo : updates-newkey
Summary : Benchmark synchronous/async file creation
URL : http://developer.osdl.org/dev/doubt/fs_mark
License : GPLv2+
Description: The fs_mark program is meant to give a low level bashing to file systems. The write
: pattern that we concentrate on is heavily synchronous IO across mutiple directories,
: drives, etc.


dbench.x86_64 : Filesystem load benchmarking tool
Name : dbench
Arch : x86_64
Version : 3.04
Release : 7.fc9
Size : 1.8 M
Repo : fedora
Summary : Filesystem load benchmarking tool
URL : http://samba.org/ftp/tridge/dbench/README
License : GPLv2+
Description: Dbench is a file system benchmark that generates load patterns similar to those of the
: commercial Netbench benchmark, but without requiring a lab of Windows load generators to
: run. It is now considered a de facto standard for generating load on the Linux VFS.



Available Packages
Name : memtest86+
Arch : x86_64
Version : 2.01
Release : 3.fc9
Size : 57 k
Repo : fedora
Summary : Stand-alone memory tester for x86 and x86-64 computers
URL : http://www.memtest.org
License : GPLv2
Description: Memtest86+ is a thorough stand-alone memory test for x86 and x86-64 architecture
: computers. BIOS based memory tests are only a quick check and often miss many of the
: failures that are detected by Memtest86+. Run 'memtest-setup' to add to your GRUB or lilo
: boot menu.

nuttcp.x86_64 : Tool for testing TCP connections
Name : nuttcp
Arch : x86_64
Version : 5.3.1
Release : 4.fc9
Size : 56 k
Repo : fedora
Summary : Tool for testing TCP connections
URL : ftp://ftp.lcp.nrl.navy.mil/pub/nuttcp/
License : Public Domain
Description: nuttcp is a network performance measurement tool intended for use by network and system
: managers. Its most basic usage is to determine the raw TCP (or UDP) network layer
: throughput by transferring memory buffers from a source system across an interconnecting
: network to a destination system, either transferring data for a specified time interval,
: or alternatively transferring a specified number of buffers. In addition to reporting the
: achieved network throughput in Mbps, nuttcp also provides additional useful information
: related to the data transfer such as user, system, and wall-clock time, transmitter and
: receiver CPU utilization, and loss percentage (for UDP transfers).

iperf.x86_64 : Measurement tool for TCP/UDP bandwidth performance
Available Packages
Name : iperf
Arch : x86_64
Version : 2.0.2
Release : 5.fc9
Size : 50 k
Repo : fedora
Summary : Measurement tool for TCP/UDP bandwidth performance
URL : http://dast.nlanr.net/Projects/Iperf/
License : BSD
Description: Iperf is a tool to measure maximum TCP bandwidth, allowing the tuning of various
: parameters and UDP characteristics. Iperf reports bandwidth, delay jitter, datagram loss.


http://folding.stanford.edu/English/Download
http://www.stanford.edu/group/...ease/FAH6.02-Linux.tgz


http://milkyway.cs.rpi.edu/milkyway/

http://setiathome.berkeley.edu/

 
So far so good I did not get that bug. Is it just a firstboot bug? I did a few reboots, so far so good. No updates yet. Will do those tomorrow while I'm at work, its getting hot in here even with window open.

I just did a test hot swap too looks good. Now thing is there is possibility of getting disk names mixed (ex: /dev/sdc may turn to /dev/sdb if /dev/sdb fails) could this be an issue? or if I use e2label on all drives/partitions I'll be ok? I plan to use software raid 5. Probably software raid 10 on the future array but not buying 4 more drives yet. The TB ones are going down faster then enron stocks, so I'll keep waiting, I'll have a bit under 2 TB for now anyway.

Just so glad this is coming together. Hopefully my super crappy Ultra UPS software works though. The UPS itself is great, but their Linux software sucks. TBH I don't even know if its working well on my current server, the monitor there does not get power so never bothered to do a true test lol.

 
Yes that bug is strictly first boot ... well first and every boot (because it won't boot) after the installer finishes. You're ok. You're lucky.

Drive naming is a little complex between UUIDs, labels, udev, et. al. If you do have FS level labels and UUIDs on them you can always determine which is which. As far as I've seen the "default" behavior with udev, automounter, and all that just doing the normal thing seems to keep the media pretty well managed, but YMMV. Label what you can label and use UUIDs where you can; mdadm does that pretty automatically with the UUIDs.

I like the (md / mdadm) SW RAID on FEDORA personally. Not so much as ZFS, but that's another story. Yes the cheap 1TB/1.5TB drives are tempting. I wish I could trade some old 300s / 500s for 1TBs now.

UPS S/W? If the UPS has a USB port or an interface to a standard DB-9 RS232 serial port, plug it in and see what happens using the default UPS monitoring software. A lot of the LINUX UPS monitoring s/w is smart enough to talk to a variety of popular commercial UPS products without OEM software. YMMV. If you're super worried about the quality (stability) of the closed source UPS software, you can always run it in a VM and then communicate the system state to the host or whatever...

F9's pretty good.. I've got it on 4-5 boxes and haven't had too many problems with it other than the installation thing and various things that updates have fixed or would eventually fix.

Originally posted by: RedSquirrel
So far so good I did not get that bug. Is it just a firstboot bug? I did a few reboots, so far so good. No updates yet. Will do those tomorrow while I'm at work, its getting hot in here even with window open.

I just did a test hot swap too looks good. Now thing is there is possibility of getting disk names mixed (ex: /dev/sdc may turn to /dev/sdb if /dev/sdb fails) could this be an issue? or if I use e2label on all drives/partitions I'll be ok? I plan to use software raid 5. Probably software raid 10 on the future array but not buying 4 more drives yet. The TB ones are going down faster then enron stocks, so I'll keep waiting, I'll have a bit under 2 TB for now anyway.

Just so glad this is coming together. Hopefully my super crappy Ultra UPS software works though. The UPS itself is great, but their Linux software sucks. TBH I don't even know if its working well on my current server, the monitor there does not get power so never bothered to do a true test lol.
Click to expand...

 
cool did not realize there was built in software for UPS, kinda figured the language between them was very propitiatory and what not. I'll give it a try when I get to that point.
 
There's some stuff. In addition to various things in the fedora repos there are 3rd party tools, and I believe some level of generic support for generic USB UPS related profiles and so on.

powertop.x86_64 : Power consumption monitor
kpowersave.x86_64 : KPowersave is the KDE frontend for powermanagement
gnome-power-manager.x86_64 : GNOME Power Manager
guidance-power-manager.x86_64 : KDE Power Manager

acpi.x86_64 : Command-line ACPI client
acpitool.x86_64 : Command line ACPI client
gkrellm.x86_64 : Multiple stacked system monitors in one process
wmacpi.x86_64 : Dockapp for laptop acpi/apm information

apcupsd.x86_64 : APC UPS Power Control Daemon for Linux
apcupsd-cgi.x86_64 : Web interface for apcupsd
apcupsd-gui.x86_64 : GUI interface for apcupsd

nut.x86_64 : Network UPS Tools
nut-cgi.x86_64 : CGI utilities for the Network UPS Tools
nut-client.i386 : Network UPS Tools client monitoring utilities
nut-client.x86_64 : Network UPS Tools client monitoring utilities
nut-devel.i386 : Development files for NUT Client
nut-devel.x86_64 : Development files for NUT Client
nut-xml.x86_64 : XML UPS driver for the Network UPS Tools
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top