9:37 p.m.
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?
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
That's life.
What's life?
A magazine.
How much does it cost?
Two-fifty.
I only have a dollar.
That's life.
11:40 p.m.
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
11:22 p.m.
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.
----
> >> 2. 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
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Many people feel that they deserve some kind of recognition for all the
bad things they haven't done.
12:52 a.m.
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
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Administration: An ingenious abstraction in politics, designed to receive
the kicks and cuffs due to the premier or president.
-- Ambrose Bierce
10:44 p.m.
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.
----
>> 2. 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
9:56 p.m.
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.
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?
----
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?
----
2. 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
10:19 p.m.
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.
>
> 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?
----
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 ?
----
> 2. 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
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The more they over-think the plumbing the easier it is to stop up the drain.
5556
days inactive
5556
days old
6 comments
2 participants
participants (2)
-
Craig White -
Gene Heskett