ubuntu how do I properly install Motherboard drivers
UbuntuThis forum is for the discussion of Ubuntu Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
ubuntu how do I properly install Motherboard drivers
Okay so I have wild idea to build a new Ubuntu computer from scratch. This is a great motherboard with lots of features, planning to have a RAID, and an AMD 64 bit processor(s).
I want to be sure that I am installing the correct drivers..
can anyone point me to a 'guide' to building a computer such as this?
The best way to know if you have proper drivers is to get a Live CD and try it on your system. And if everything is working the way you want, you got all the drivers you should.
Please post the manufacturer and modell of your mainboard, maybe someone here has it already working and can give you more info about compatibility. You can also have a look in the Hardware Compatibility List.
Okay so I have wild idea to build a new Ubuntu computer from scratch.
Not at all "wild". It is the most economical and effective way for a competent person to get a desktop Linux system.
Quote:
This is a great motherboard with lots of features,
What motherboard?
Quote:
planning to have a RAID
You didn't exactly say you intend to use the advertised RAID features of the motherboard. But I think you inferred it. If so, that is a bad idea.
Motherboard RAID is almost certainly "fake RAID". Fake RAID is worse than software RAID in several ways. Unless you intend to support a consistent RAID structure across a Windows/Linux dual boot, there is no reason to use fake RAID in Linux. If you want RAID, use software RAID or pay for real hardware RAID.
Before deciding to have RAID at all, make sure you understand why you want RAID. The reason for the RAID would say a lot toward the way you configure it. If you don't really have a reason, maybe you'll realize it isn't worth the trouble.
Quote:
an AMD 64 bit processor(s).
That's nice. That fact doesn't affect nor inform the other decisions nearly as much as you might expect.
Quote:
I want to be sure that I am installing the correct drivers..
Linux doesn't generally distribute or use "Motherboard Drivers". The motherboard sound, motherboard SATA, motherboard wired Ethernet, and other features for which Windows might use motherboard drivers to get optimal performance all tend to work with Linux via standard drivers and no motherboard specific versions of those drivers exist.
The display and wireless network devices (whether motherboard or not) often require some effort to get the right drivers set up, but the driver availability is not organized by motherboard even when those components are built into the motherboard. You need manufacturer and detailed model info for the components (rather than the motherboard) to resolve any such driver issues. Once you have the system, a Linux liveCD has tools that will help get detailed component info for display or network etc. components that are described imprecisely in the online specs you can see before you buy. It is often worth looking for such info in the online specs and trying to search for issues before buying, but that is not an easy nor reliable process. You still might find yourself looking for help after it is all assembled.
While this is not specific to the motherboard, unless you plan to use a motherboard with integrated graphics, I would recommend going with a nvidia graphics card instead of ati. The proprietary nvidia drivers are much easier and trouble free to install and configure than the proprietary ati drivers are.
While this is not specific to the motherboard, unless you plan to use a motherboard with integrated graphics, I would recommend going with a nvidia graphics card instead of ati. The proprietary nvidia drivers are much easier and trouble free to install and configure than the proprietary ati drivers are.
How can it be easier to click on nVidia instead of ATI in the driver manager?
How can it be easier to click on nVidia instead of ATI in the driver manager?
It is just that the nvidia linux drivers tend to be more reliable and less problematic than the ati linux drivers from what I have seen around these forums.
So here is what I have in mind:
Ubuntu 10.10
AMD PhenomII x6 1090
8GB RAM
Gigabyte AMD 880GMA/SB850
and two 500GB hard drives..to be RAID.
When do I set up the software RAID?
I will start out tomorrow with the live CD.
I don't happen to know that for Ubuntu, but I expect it could be found easily in Ubuntu documentation or with an online search.
I have only really used RAID for servers, not workstations, and for servers I use Centos. Setting up the software RAID as part of the Centos install process is very obvious. It was not obvious to me in the Ubuntu install process, but I also wasn't looking for it.
How you set up RAID should depend on why you want the RAID. What are the kinds of failures you want to cover? How much 100% likely setup cost is justified up front to save how much low probability recovery cost later? Keep in mind that RAID is far inferior to backup for any kind of long term data security.
With two drives, I expect you want RAID 1 for its reliability increase with 50% capacity loss and little performance difference (writes are more expensive, reads may be less expensive). But maybe you meant RAID 0 for its performance increase with capacity unchanged and reliability decreased. I can't really guess your goals.
With software RAID, you normally make the decision per partition, rather than for the whole pair of drives. In a serious production system, you often have working data in which performance is more important than extreme reliability (remember the drives themselves are very reliable, so even RAID 0 makes data loss from hardware problems far less likely than data loss from operator error or software bugs). So you might make a pair of work partitions (one per drive) joined by RAID 0, where other pairs are joined by RAID 1.
In a more typical system the only area where performance is that much more important than extreme reliability is /tmp. When I am using mostly RAID 1, I make /tmp be a tmpfs rather than either its own partition or a directory inside the / partition. A tmpfs increases your need for swap space, so I set up one swap partition on each drive and let Linux use the swap partitions independently. That is more efficient than merging swap with RAID 0 and much much better than merging swap with RAID 1.
That plan (and everything else I ever do with RAID) is making some assumptions about acceptable extra effort at recovery time after an unlikely drive failure. If instead, I were creating a live transaction processing system, then extra hardware and initial setup costs would be insignificant and everything would focus on minimizing the costs associated with the low probability failures.
At the opposite extreme, in setting up an ordinary workstation, RAID isn't justified at all. If you multiply the moderate savings from having RAID during a hard drive failure times the very low probability of ever having that failure, the result doesn't justify the initial costs of the RAID. Backup is justified because it covers a higher costs of data loss times a higher probability of operator error, software bug or hardware failure causing that loss. Regarding data loss, backup is better protection for all but your most recent data (created since last backup). RAID is the only protection for your most recent data but only protects against some hardware failures, not against the more common (operator error, and software) causes of data loss.
I don't happen to know that for Ubuntu, but I expect it could be found easily in Ubuntu documentation or with an online search.
I have only really used RAID for servers, not workstations, and for servers I use Centos. Setting up the software RAID as part of the Centos install process is very obvious. It was not obvious to me in the Ubuntu install process, but I also wasn't looking for it.
How you set up RAID should depend on why you want the RAID. What are the kinds of failures you want to cover? How much 100% likely setup cost is justified up front to save how much low probability recovery cost later? Keep in mind that RAID is far inferior to backup for any kind of long term data security.
With two drives, I expect you want RAID 1 for its reliability increase with 50% capacity loss and little performance difference (writes are more expensive, reads may be less expensive). But maybe you meant RAID 0 for its performance increase with capacity unchanged and reliability decreased. I can't really guess your goals.
With software RAID, you normally make the decision per partition, rather than for the whole pair of drives. In a serious production system, you often have working data in which performance is more important than extreme reliability (remember the drives themselves are very reliable, so even RAID 0 makes data loss from hardware problems far less likely than data loss from operator error or software bugs). So you might make a pair of work partitions (one per drive) joined by RAID 0, where other pairs are joined by RAID 1.
In a more typical system the only area where performance is that much more important than extreme reliability is /tmp. When I am using mostly RAID 1, I make /tmp be a tmpfs rather than either its own partition or a directory inside the / partition. A tmpfs increases your need for swap space, so I set up one swap partition on each drive and let Linux use the swap partitions independently. That is more efficient than merging swap with RAID 0 and much much better than merging swap with RAID 1.
That plan (and everything else I ever do with RAID) is making some assumptions about acceptable extra effort at recovery time after an unlikely drive failure. If instead, I were creating a live transaction processing system, then extra hardware and initial setup costs would be insignificant and everything would focus on minimizing the costs associated with the low probability failures.
At the opposite extreme, in setting up an ordinary workstation, RAID isn't justified at all. If you multiply the moderate savings from having RAID during a hard drive failure times the very low probability of ever having that failure, the result doesn't justify the initial costs of the RAID. Backup is justified because it covers a higher costs of data loss times a higher probability of operator error, software bug or hardware failure causing that loss. Regarding data loss, backup is better protection for all but your most recent data (created since last backup). RAID is the only protection for your most recent data but only protects against some hardware failures, not against the more common (operator error, and software) causes of data loss.
Well I didn't get prompted to install the array. Didn't look at the documentation anyhow. Just cocky I guess. Anyhow, I'll pass on the array for now. Got a big enough hard drive anyhow for what I need it for and with linux the backup scheduling is a breeze so that will do for now.
Thanks..but I still want to check into just to learn more.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.