On Thursday 26 February 2009, Craig White wrote:
On Thu, 2009-02-26 at 23:19 -0500, Gene Heskett wrote:
The initial, commented /dev/sdb is correct, /dev/sda is the master drive on this mobo's only PATA interface, and is not normally mounted. /dev/sdb is the first SATA drive, and is selected as the first bootable hard disk in the bios. So I assume then that my command line to install grub again would then be: grub-install /dev/sdb ?
it seems odd that you would have it set to /dev/sdb and grub as (hd0,0).
Apparently that is just one of the gotcha's of running a very high priced (nearly 300 bucks bare) ASUS motherboard. It does damned little as you would expect it to do. If I had known that ASUS was on the ropes, and that their support sucked dead toads through soda straws, I wouldn't have touched it with your credit card let alone mine.
It shouldn't hurt I would think if you did grub-install to both /dev/sda and /dev/sdb. Most modern BIOS allows you to pick the boot order of the various drive types.
# this device map was generated by anaconda (hd0) /dev/sda (hd1) /dev/sdb And that file is dated back on the 15th of feb 2009. And I was NOT screwing with it then. So, based on that I did another grub-install on /dev/sda.
Here is a df report [root@coyote ~]# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda3 468832020 87577712 357054796 20% / /dev/sda1 194442 121466 62937 66% /boot /dev/sdc1 961432072 293643964 618950108 33% /amandatapes tmpfs 2074712 0 2074712 0% /dev/shm //goat.coyote.den/goat 58134488 4302672 50901964 8% /mnt/goat //shop.coyote.den/shop-slash 37800748 4647876 31232708 13% /mnt/shop /dev/sde1 38456308 30008496 6494312 83% /media/d
and I did some poking around with smartctl and that PATA drive, a 320Gb Maxtor, is actually registered into F10 as /dev/sdd. Go figure, it makes zero sense to me.
- Yum wants to update 435 packages, but many dependencies stop it.
What is the f10 procedure to bring that up to speed now?
you probably have some packages that have to be manually removed that are blocking the update.
I will probably hit a package that does this eventually, I have it processing the updates displayed about 1 yumex screen full at a time, and so far that hasn't triggered a dependency storm. That knocking sound, yeah, you know what it is.
package-cleanup --orphans will give you a lot of guidance on packages that it can't update.
I have tons of self compiled stuff here, and will again shortly. The radeonhd driver supplied with the dvd is so slow I can repaint the screen with a 2" wide paint brush faster.
in theory, that shouldn't have any impact on upgrades IF you put the compiled stuff in /usr/local
Often that is not the case, cuz identically named stuff is searched for in /usr/lib well before /usr/local/lib. This would be a great way to just update what we needed locally, but the search order makes sure it finds version 1.2.4 when we've been running 2.2.8 for a year. So we give up trying to bend it, and just build it with a --prefix=/usr and be done with it. Of course the rpms get overwritten and the system eventually goes tits up.
Now, if someone could tell me how to make it search /usr/local/* first, I'd be glad to follow those guidelines. I'd step into my src dir and rebuild and reinstall everything there to put itself into /usr/local then. [...]
get the updates installed first. You might find that the rpmfusion fglrx package is more to your liking though I wouldn't think that there would much of a performance difference between F9 and F10 w/r/t radeonhd but then again, I'm not using it.
The problem with that is that the fglrx is married to the kernel version. radeonhd at least, is only married to the x server version, and that is what I broke when I built the git pull of it. Besides that, I have yet to get fps out of fglrx that I get from radeonhd. That is one of the first things I had yumex update, but I haven't rebooted to try it yet. I'm just happier than a pig in it that the new kmail picked right up where the old one left off, it all works and I haven't touched a thing yet.
Thanks Craig.
Craig