Greetings;
I killed x trying to make this )*(&%$ video card work so I put the f10 dvd in and updated it to F10.
Two immediate problems.
1. Grub must have miss-fired, all I get is the grub shell and I have to enter all the boot data line by line in order to boot. Is that a fresh grub- install?
2. Yum wants to update 435 packages, but many dependencies stop it. What is the f10 procedure to bring that up to speed now?
On Thu, 2009-02-26 at 22:37 -0500, Gene Heskett wrote:
Greetings;
I killed x trying to make this )*(&%$ video card work so I put the f10 dvd in and updated it to F10.
Two immediate problems.
- Grub must have miss-fired, all I get is the grub shell and I have to enter
all the boot data line by line in order to boot. Is that a fresh grub- install?
---- that hasn't been a commonly reported problem with F10 but after you boot up, have you run 'grub-install /dev/sda' to ensure that grub is properly installed? What does /boot/grub/grub.conf look like? ----
- 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.
You probably want to check out this page http://fedoraproject.org/wiki/YumUpgradeFaq even if you used the DVD or preupgrade to install the update as this has a lot of information useful like 'clean stuff' section and various issues going from like 8=>9 or 9=>10
Craig
On Thursday 26 February 2009, Craig White wrote:
On Thu, 2009-02-26 at 22:37 -0500, Gene Heskett wrote:
Greetings;
I killed x trying to make this )*(&%$ video card work so I put the f10 dvd in and updated it to F10.
Two immediate problems.
- Grub must have miss-fired, all I get is the grub shell and I have to
enter all the boot data line by line in order to boot. Is that a fresh grub- install?
that hasn't been a commonly reported problem with F10 but after you boot up, have you run 'grub-install /dev/sda' to ensure that grub is properly installed? What does /boot/grub/grub.conf look like?
# grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/sdb3 # initrd /initrd-version.img #boot=/dev/sdb default=0 fallback=9 timeout=15 splashimage=(hd0,0)/grub/splash.xpm.gz # 0 title Fedora (2.6.27.5-117.fc10.i686.PAE) root (hd0,0) kernel /vmlinuz-2.6.27.5-117.fc10.i686.PAE ro root=UUID=811c07da-065e-4da7-988e-686913725b53 rhgb quiet nomodeset initrd /initrd-2.6.27.5-117.fc10.i686.PAE.img
# 2 title Fedora (2.6.27.5-117.fc10.i686) root (hd0,0) kernel /vmlinuz-2.6.27.5-117.fc10.i686 ro root=UUID=811c07da-065e-4da7-988e-686913725b53 rhgb quiet nomodeset initrd /initrd-2.6.27.5-117.fc10.i686.img
# 3 title fedora (2.6.28) root (hd0,0) kernel /vmlinuz-2.6.28 ro root=LABEL=/ rhgb quiet nomodeset initrd /initrd-2.6.28.img
# 4 title fedora (2.6.28.2) root (hd0,0) kernel /vmlinuz-2.6.28.2 ro root=LABEL=/ rhgb quiet nomodeset initrd /initrd-2.6.28.2.img
# 5 title fedora (2.6.28.3) root (hd0,0) kernel /vmlinuz-2.6.28.3 ro root=LABEL=/ rhgb quiet nomodeset initrd /initrd-2.6.28.3.img
# 6 title fedora (2.6.28.4) root (hd0,0) kernel /vmlinuz-2.6.28.4 ro root=LABEL=/ rhgb quiet nomodeset initrd /initrd-2.6.28.4.img
# 7 title fedora (2.6.28.5) root (hd0,0) kernel /vmlinuz-2.6.28.5 ro root=LABEL=/ rhgb quiet nomodeset initrd /initrd-2.6.28.5.img
# 8 title fedora (2.6.28.6) root (hd0,0) kernel /vmlinuz-2.6.28.6 ro root=LABEL=/ rhgb quiet nomodeset initrd /initrd-2.6.28.6.img
# 9 title fedora (2.6.28.7) root (hd0,0) kernel /vmlinuz-2.6.28.7 ro root=LABEL=/ rhgb quiet nomodeset initrd /initrd-2.6.28.7.img
#10 title fedora (2.6.29-rc2) root (hd0,0) kernel /vmlinuz-2.6.29-rc2 ro root=LABEL=/ rhgb quiet nomodeset initrd /initrd-2.6.29-rc2.img #11 title fedora (2.6.29-rc3) root (hd0,0) kernel /vmlinuz-2.6.29-rc3 ro root=LABEL=/ rhgb quiet nomodeset initrd /initrd-2.6.29-rc3.img #12 title Ubuntu jaunty (development branch), kernel 2.6.28-6-generic root (hd2,0) uuid dec5d1c4-967e-4946-8f1b-4b30b6ceee07 kernel /vmlinuz-2.6.28-6-generic root=UUID=cb93c923-1039-44ba-965f-9fb581dc16be ro quiet splash initrd /initrd.img-2.6.28-6-generic quiet
#11 title Ubuntu jaunty (development branch), kernel 2.6.28-6-generic (recovery mode) root (hd2,0) uuid dec5d1c4-967e-4946-8f1b-4b30b6ceee07 kernel /vmlinuz-2.6.28-6-generic root=UUID=cb93c923-1039-44ba-965f-9fb581dc16be ro single initrd /initrd.img-2.6.28-6-generic
#12 title Ubuntu jaunty (development branch), memtest86+ root (hd2,0) uuid dec5d1c4-967e-4946-8f1b-4b30b6ceee07 kernel /memtest86+.bin quiet ======================
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 ?
- 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.
Thanks Craig.
You probably want to check out this page http://fedoraproject.org/wiki/YumUpgradeFaq even if you used the DVD or preupgrade to install the update as this has a lot of information useful like 'clean stuff' section and various issues going from like 8=>9 or 9=>10
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.
[root@coyote ~]# glxgears 1628 frames in 5.0 seconds = 325.495 FPS 1636 frames in 5.0 seconds = 327.036 FPS 1635 frames in 5.0 seconds = 326.821 FPS 1573 frames in 5.0 seconds = 314.521 FPS 1455 frames in 5.0 seconds = 290.819 FPS 1521 frames in 5.0 seconds = 304.192 FPS
Which surprises me, it feels a heck of a lot slower. Moving firefox an inch to the left takes about 10 seconds as it redraws the whole screen about 50 times doing it.
It was doing about 900 before I broke it. And I could move a screen as fast as the mouse moved. Sigh.
Craig
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). 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. ----
- 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 ----
[root@coyote ~]# glxgears 1628 frames in 5.0 seconds = 325.495 FPS 1636 frames in 5.0 seconds = 327.036 FPS 1635 frames in 5.0 seconds = 326.821 FPS 1573 frames in 5.0 seconds = 314.521 FPS 1455 frames in 5.0 seconds = 290.819 FPS 1521 frames in 5.0 seconds = 304.192 FPS
Which surprises me, it feels a heck of a lot slower. Moving firefox an inch to the left takes about 10 seconds as it redraws the whole screen about 50 times doing it.
It was doing about 900 before I broke it. And I could move a screen as fast as the mouse moved. Sigh.
---- 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.
Craig
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
On Fri, 2009-02-27 at 00:22 -0500, Gene Heskett wrote:
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.
---- your box dude - neither /usr/lib nor /usr/local/lib are ever 'pathed' environmental variables but rather the compiled software should know where to look. Obviously you are referring to something specific when talking about versions 1.2.4 and 2.2.8 and my guess is that you are referring to amanda which really makes no sense to build/install with --prefix=/usr at all. In fact, you should just be building rpms and not compiling from source but that's a discussion that we have had before. Well written software would search /usr/local/lib before /usr/lib if it were built with --prefix=/usr/local (which should be the default). ----
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.
---- I sort of thought that this was the default.
try typing 'echo $PATH' and someone correct me if I'm wrong but I gathered that the order presented from that command is also the order that the commands are parsed.
Craig
On Friday 27 February 2009, Craig White wrote:
On Fri, 2009-02-27 at 00:22 -0500, Gene Heskett wrote:
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.
your box dude - neither /usr/lib nor /usr/local/lib are ever 'pathed' environmental variables but rather the compiled software should know where to look. Obviously you are referring to something specific when talking about versions 1.2.4 and 2.2.8 and my guess is that you are referring to amanda which really makes no sense to build/install with --prefix=/usr at all. In fact, you should just be building rpms and not compiling from source but that's a discussion that we have had before.
And we'll have this discussion till the cows come home dripping. :) But I don't run amanda from /usr, never have, nor do I run it as root, in fact it detects that its running as root and bawls you out as it exits. And building an rpm of amanda violates many of amanda most basic security tenets, most basic is that of not using any more permissions than is absolutely required. And rpm built and installed by a common user cannot get the suid's a couple pieces of it needs, which is why you build it as an unprivileged user so all the rights are set, but do the actual install as root so the suid's can be set. The last I knew, rpm is as yet incapable of doing all this when rpm is also running unprivileged.
Well written software would search /usr/local/lib before /usr/lib if it were built with --prefix=/usr/local (which should be the default).
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.
I sort of thought that this was the default.
try typing 'echo $PATH' and someone correct me if I'm wrong but I gathered that the order presented from that command is also the order that the commands are parsed.
I think this also depends on the output of ldconfig. One used to be able to fine tune the order of its database, but somebody got the 10 kilowatt idea to get rid of an ld.so.conf file the user could control the order of the processing with and put individual files in a subdir. And guess what, the last time I looked at its output, it alphabetizes the subdir contents before it processes them. So you can't put /usr/local/lib at the top of the list anymore. I should have filed a bz on that long ago. I suppose a bit of renaming might suffice to set the processing order, but about the time I'd get that sorted its time to update. Or switch distro's.
This isn't your fault of course, but sometimes I am led to wonder just what were they smoking when they change something like that just because they can.
Now, I finally backtraced the dependency that pulls in strigi-devel, and then yum needs a bug filed on it, it claims that the -devel package needs the parent package which is not available, so it upchucks and stops. Funny thing though, the parent package is also shown as already installed. Who is at fault in this I haven't the foggiest, but it sure is a showstopper.
Oh well, tomorrow is another day. Mail is flowing, and web browsing almost works. Maybe if i reboot to test the grub-install, the newer radeonhd drivers I just installed will fix that.
Thanks Craig
-
Craig White -
Gene Heskett