Re: [CentOS] Possible bug with latest 7.3 installer, md RAID1, and SATADOM.

[David C. Miller]

>> On Fri, Apr 14, 2017 at 2:28 PM, David C. Miller <mille...@fusion.gat.com>
>> wrote:
>> 
>> I'm seeing a problem that I think maybe a bug with the mdraid software on
>> the latest CentOS installer. I have a couple of new supermicro servers and
>> each system has two innodisk 32GB SATADOM's that are experiencing the same
>> issue. I used the latest CentOS-7-x86_64-1611 to install to the two
>> SATADOM's a simple RAID1 for the root. The install goes just fine but when
>> I boot off the new install I see one of two behaviours. It either hangs at
>> boot, or boots fine but I start getting errors when using the system. For
>> example it will give me  the following error if I try to run yum update.
>>
>> error: rpmdb: damaged header #6 retrieved -- skipping.
>>
>> It will just hang giving that error over and over. I have to use a
>> different login session to kill it or reboot. It doesn't even log anything
>> to journelctl or /var/log/messages. At first I thought either the hardware
>> was the issue(sata port, controller, SATADOM, etc). However, I do not see
>> any issues if I don't try to raid the disks. Setting either of the
>> SATADOM's up as a single system drive works just fine. It does not matter
>> if I choose xfs or ext4 for the filesystem when I try to RAID them either.
>> Making an md RAID1 out of the two disks with 7.3 installer is the only
>> combination I see this issue with. If I use the previous 7.2
>> installer(CentOS-7-x86_64-1511) I don't see the problem at all. I can run
>> yum update, reboot, and everything is still ok. I should also point out
>> that I tested the CentOS 7.3 installer creating a md RAID1 system drive
>> using two regular spinning hard drives and that worked just fine. I was
>> wondering if anyone else has seen something similar or can confirm th
>>  is problem before I submit it as a real bug..
>>
>> TL/DR. Two different supermicro servers, both using innodisk 32GB
>> SATADOM's and latest CentOS 7.3 installer to create a RAID1 system results
>> in freezes and weird errors. Using the CentOS 7.2 installer works fine.
>>
>> David Miller.
>> _______

> From: "Cameron Smith" <came...@networkredux.com>
> To: "CentOS mailing list" <centos@centos.org>
> Sent: Friday, April 14, 2017 2:48:56 PM
> Subject: Re: [CentOS] Possible bug with latest 7.3 installer, md RAID1,   
> and SATADOM.

> Is there a reason you are not using the built in controller to RAID the
> SATADOMs?
> 
> As I remember on SuperMicro there are two controllers. One for the SATADOMs
> and another for the conventional disks.
> 
> Cameron

It requires additional software to monitor the hardware RAID. CentOS can 
monitor the health of the drives and the mdRAID. It is trivial to setup postfix 
to relay through my mail gateway so both smartd and md will send me an email as 
soon as it sees an issue. Relying on a hardware raid card is just one more 
point of failure. I only get HBA cards and let Linux handle it. On top of that 
I can move the drives to any other system and it will still work.

David Miller.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Possible bug with latest 7.3 installer, md RAID1, and SATADOM.

[Cameron Smith]

Is there a reason you are not using the built in controller to RAID the
SATADOMs?

As I remember on SuperMicro there are two controllers. One for the SATADOMs
and another for the conventional disks.

Cameron

On Fri, Apr 14, 2017 at 2:28 PM, David C. Miller 
wrote:

> I'm seeing a problem that I think maybe a bug with the mdraid software on
> the latest CentOS installer. I have a couple of new supermicro servers and
> each system has two innodisk 32GB SATADOM's that are experiencing the same
> issue. I used the latest CentOS-7-x86_64-1611 to install to the two
> SATADOM's a simple RAID1 for the root. The install goes just fine but when
> I boot off the new install I see one of two behaviours. It either hangs at
> boot, or boots fine but I start getting errors when using the system. For
> example it will give me  the following error if I try to run yum update.
>
> error: rpmdb: damaged header #6 retrieved -- skipping.
>
> It will just hang giving that error over and over. I have to use a
> different login session to kill it or reboot. It doesn't even log anything
> to journelctl or /var/log/messages. At first I thought either the hardware
> was the issue(sata port, controller, SATADOM, etc). However, I do not see
> any issues if I don't try to raid the disks. Setting either of the
> SATADOM's up as a single system drive works just fine. It does not matter
> if I choose xfs or ext4 for the filesystem when I try to RAID them either.
> Making an md RAID1 out of the two disks with 7.3 installer is the only
> combination I see this issue with. If I use the previous 7.2
> installer(CentOS-7-x86_64-1511) I don't see the problem at all. I can run
> yum update, reboot, and everything is still ok. I should also point out
> that I tested the CentOS 7.3 installer creating a md RAID1 system drive
> using two regular spinning hard drives and that worked just fine. I was
> wondering if anyone else has seen something similar or can confirm th
>  is problem before I submit it as a real bug..
>
> TL/DR. Two different supermicro servers, both using innodisk 32GB
> SATADOM's and latest CentOS 7.3 installer to create a RAID1 system results
> in freezes and weird errors. Using the CentOS 7.2 installer works fine.
>
> David Miller.
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Possible bug with latest 7.3 installer, md RAID1, and SATADOM.

[David C. Miller]

I'm seeing a problem that I think maybe a bug with the mdraid software on the 
latest CentOS installer. I have a couple of new supermicro servers and each 
system has two innodisk 32GB SATADOM's that are experiencing the same issue. I 
used the latest CentOS-7-x86_64-1611 to install to the two SATADOM's a simple 
RAID1 for the root. The install goes just fine but when I boot off the new 
install I see one of two behaviours. It either hangs at boot, or boots fine but 
I start getting errors when using the system. For example it will give me  the 
following error if I try to run yum update.

error: rpmdb: damaged header #6 retrieved -- skipping.

It will just hang giving that error over and over. I have to use a different 
login session to kill it or reboot. It doesn't even log anything to journelctl 
or /var/log/messages. At first I thought either the hardware was the issue(sata 
port, controller, SATADOM, etc). However, I do not see any issues if I don't 
try to raid the disks. Setting either of the SATADOM's up as a single system 
drive works just fine. It does not matter if I choose xfs or ext4 for the 
filesystem when I try to RAID them either. Making an md RAID1 out of the two 
disks with 7.3 installer is the only combination I see this issue with. If I 
use the previous 7.2 installer(CentOS-7-x86_64-1511) I don't see the problem at 
all. I can run yum update, reboot, and everything is still ok. I should also 
point out that I tested the CentOS 7.3 installer creating a md RAID1 system 
drive using two regular spinning hard drives and that worked just fine. I was 
wondering if anyone else has seen something similar or can confirm th
 is problem before I submit it as a real bug..

TL/DR. Two different supermicro servers, both using innodisk 32GB SATADOM's and 
latest CentOS 7.3 installer to create a RAID1 system results in freezes and 
weird errors. Using the CentOS 7.2 installer works fine.

David Miller.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Possible bug in kickstart

[James A. Peltier]

Sorry, just a follow up to see if anyone has similar experiences with the 
method of kickstarting bridges on CentOS 7.1.  According to the docs things are 
correct for 7.1 and I just want to make sure I'm not doing something 
incorrectly before filing a bug with Red Hat

- Original Message -
| Hello All,
| 
| I seem to have run into a bug with the new --bridgeslaves=INTERFACE option.
| It would seem that if I tell the bridge device to use a virtual interface
| (like bond0) rather than a physical interface (em1/em2) that kickstart
| completely barfs on it.  I have provided my network section below which
| works fine as long as i don't enable all the bridge content.
| 
| When the installation starts off the creation of bond0 and all VLANs on bond0
| go without issue.  Jumping into TTY2 I can type 'ip a' and see all the bond0
| device and bond0.VLANID devices no problem.
| 
| When I enable bridge content with --bridgeslaves=bond0 or
| --bridgeslaves=bond0.VLANID anaconda barfs
| 
| When I enable bridge content with --bridgeslaves=em1 or --bridgeslaves=em2
| anaconda doesn't have an issue.
| 
| Is this expected behaviour?  I really don't want to have to manually
| manipulate the ifcfg-bond* interfaces and create the ifcfg-BRIDGE*
| interfaces manually so I'd like this to work.
| 
| 
| 
| 
| # Configure a bond over the slaves in failover mode
| network --device=bond0 --noipv6 --bootproto=dhcp --onboot=yes
| --bondslaves=em1,em2 --bondopts=mode=active-backup;primary=em1 --activate
| 
| # Configure VLANs
| network --device=bond0 --vlanid=11 --noipv6 --onboot=yes --bootproto=dhcp
| --activate
| network --device=bond0 --vlanid=100 --noipv6 --onboot=yes --bootproto=dhcp
| --activate
| network --device=bond0 --vlanid=302 --noipv6 --onboot=yes --bootproto=dhcp
| --activate
| network --device=bond0 --vlanid=303 --noipv6 --onboot=yes --bootproto=dhcp
| --activate
| network --device=bond0 --vlanid=304 --noipv6 --onboot=yes --bootproto=dhcp
| --activate
| network --device=bond0 --vlanid=306 --noipv6 --onboot=yes --bootproto=dhcp
| --activate
| 
| # Create a bridge on the bonded VLAN interfaces
| network --device=FASNET --bridgeslaves=bond0
| network --device=GLUSTER --bridgeslaves=bond0.11
| network --device=EXPERIMENTAL --bridgeslaves=bond0.302
| network --device=NAT --bridgeslaves=bond0.303
| network --device=DMZ2 --bridgeslaves=bond0.304
| network --device=NETM --bridgeslaves=bond0.306
| 
| --
| James A. Peltier
| IT Services - Research Computing Group
| Simon Fraser University - Burnaby Campus
| Phone   : 604-365-6432
| Fax : 778-782-3045
| E-Mail  : jpelt...@sfu.ca
| Website : http://www.sfu.ca/itservices
| Twitter : @sfu_rcg
| Powering Engagement Through Technology
| ___
| CentOS mailing list
| CentOS@centos.org
| http://lists.centos.org/mailman/listinfo/centos
| 

-- 
James A. Peltier
IT Services - Research Computing Group
Simon Fraser University - Burnaby Campus
Phone   : 604-365-6432
Fax : 778-782-3045
E-Mail  : jpelt...@sfu.ca
Website : http://www.sfu.ca/itservices
Twitter : @sfu_rcg
Powering Engagement Through Technology
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] Possible bug in kickstart

[James A. Peltier]

Hello All,

I seem to have run into a bug with the new --bridgeslaves=INTERFACE option.  
It would seem that if I tell the bridge device to use a virtual interface (like 
bond0) rather than a physical interface (em1/em2) that kickstart completely 
barfs on it.  I have provided my network section below which works fine as long 
as i don't enable all the bridge content.

When the installation starts off the creation of bond0 and all VLANs on bond0 
go without issue.  Jumping into TTY2 I can type 'ip a' and see all the bond0 
device and bond0.VLANID devices no problem.

When I enable bridge content with --bridgeslaves=bond0 or 
--bridgeslaves=bond0.VLANID anaconda barfs

When I enable bridge content with --bridgeslaves=em1 or --bridgeslaves=em2 
anaconda doesn't have an issue.

Is this expected behaviour?  I really don't want to have to manually manipulate 
the ifcfg-bond* interfaces and create the ifcfg-BRIDGE* interfaces manually so 
I'd like this to work.




# Configure a bond over the slaves in failover mode
network --device=bond0 --noipv6 --bootproto=dhcp --onboot=yes 
--bondslaves=em1,em2 --bondopts=mode=active-backup;primary=em1 --activate

# Configure VLANs
network --device=bond0 --vlanid=11 --noipv6 --onboot=yes --bootproto=dhcp 
--activate
network --device=bond0 --vlanid=100 --noipv6 --onboot=yes --bootproto=dhcp 
--activate
network --device=bond0 --vlanid=302 --noipv6 --onboot=yes --bootproto=dhcp 
--activate
network --device=bond0 --vlanid=303 --noipv6 --onboot=yes --bootproto=dhcp 
--activate
network --device=bond0 --vlanid=304 --noipv6 --onboot=yes --bootproto=dhcp 
--activate
network --device=bond0 --vlanid=306 --noipv6 --onboot=yes --bootproto=dhcp 
--activate

# Create a bridge on the bonded VLAN interfaces
network --device=FASNET --bridgeslaves=bond0
network --device=GLUSTER --bridgeslaves=bond0.11
network --device=EXPERIMENTAL --bridgeslaves=bond0.302
network --device=NAT --bridgeslaves=bond0.303
network --device=DMZ2 --bridgeslaves=bond0.304
network --device=NETM --bridgeslaves=bond0.306

-- 
James A. Peltier
IT Services - Research Computing Group
Simon Fraser University - Burnaby Campus
Phone   : 604-365-6432
Fax : 778-782-3045
E-Mail  : jpelt...@sfu.ca
Website : http://www.sfu.ca/itservices
Twitter : @sfu_rcg
Powering Engagement Through Technology
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] possible bug, unusable system after hibernate

[Patrick]

Hi

I put my computer into hibernate last night. This morning I could not 
save thunderbird email drafts and I rebooted my system. It stopped 
before launching X and offered a root rescue shell.

I am using a solid state drive and it's very possible that it just ended 
up with a failed sector. It's my understanding that these drives are 
fast but less robust then rotary based ones.

This may be nothing but if you have just backed up your data maybe you 
could try to hibernate just in case it is a real issue and is reproducible.

Thanks-Patrick
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] Possible bug in yum requirements handling with yum-priorities

[Kai Schaetzl]

Just upgraded my perl-DBD-SQLite rpmforge package to 1.25 which resulted 
in all applications trying to use it to fail.
As it turns out the following happened:
Newer versions of DBD::SQLite need a DBI version of at least 1.57. The 
rpmforge package *does* include this requirement. However, CentOS includes 
DBI 1.52 and doesn't provide newer versions. As a good administrator I'm 
using yum priorities and thus the software is locked at the CentOS 
version. I would think that yum should not have upgraded perl-DBD-SQLite 
if it cannot fulfill the requirement of perl-DBI = 1.57.
Or is this expected behavior? Should I open a bug report?

For anyone hitting this problem:
- either exclude perl-DBD-SQLite in the rpmforge repo
- or exclude perl-DBI* from the CentOS base and updates repos
 (this will update to DBI 1.607 plus two dependencies, works fine)

Kai

-- 
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com



___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] Possible bug?

[Sam Drinkard]

I had some problems with apache, and there were so many, (caused by 
removing ispconfig) I decided to just remove and re-install.  This is 
what happened when I tried to do so, both from remote and via console.  
I tried the DVD as well as yum, and got essentially the same thing.  My 
webserver  is down, and I'd sure like to get this fixed if anyone can 
help out.


Begin errors:

Component: pirut
Summary: TBe8ae967a sqlitesack.py:94:_read_db_obj:TypeError: 
unsubscriptable object

Traceback (most recent call last):
  File /usr/sbin/pirut, line 373, in _apply
output = self.applyChanges(self.mainwin)
  File /usr/lib/python2.4/site-packages/pirut/__init__.py, line 813, 
in applyChanges
self.checkDeps(mainwin)
  File /usr/lib/python2.4/site-packages/pirut/__init__.py, line 550, 
in checkDeps
(result, msgs) = self.buildTransaction()
  File /usr/lib/python2.4/site-packages/yum/__init__.py, line 647, in 
buildTransaction
(rescode, restring) = self.resolveDeps()
  File /usr/lib/python2.4/site-packages/yum/depsolve.py, line 696, in 
resolveDeps
CheckDeps, checkinstalls, checkremoves, missing = 
self._resolveRequires(errors)
  File /usr/lib/python2.4/site-packages/yum/depsolve.py, line 779, in 
_resolveRequires
thisneeds = self._checkInstall(txmbr)
  File /usr/lib/python2.4/site-packages/yum/depsolve.py, line 851, in 
_checkInstall
provs = self.tsInfo.getProvides(*req)
  File /usr/lib/python2.4/site-packages/yum/transactioninfo.py, line 
432, in getProvides
result.update(self.getNewProvides(name, flag, version))
  File /usr/lib/python2.4/site-packages/yum/transactioninfo.py, line 
414, in getNewProvides
for pkg, hits in self.pkgSack.getProvides(name, flag, 
version).iteritems():
  File /usr/lib/python2.4/site-packages/yum/packageSack.py, line 300, 
in getProvides
return self._computeAggregateDictResult(getProvides, name, flags, 
version)
  File /usr/lib/python2.4/site-packages/yum/packageSack.py, line 470, 
in _computeAggregateDictResult
sackResult = apply(method, args)
  File /usr/lib/python2.4/site-packages/yum/sqlitesack.py, line 861, 
in getProvides
return self._search(provides, name, flags, version)
  File /usr/lib/python2.4/site-packages/yum/sqlitesack.py, line 43, in 
newFunc
return func(*args, **kwargs)
  File /usr/lib/python2.4/site-packages/yum/sqlitesack.py, line 837, 
in _search
for pkg in self.searchFiles(name, strict=True):
  File /usr/lib/python2.4/site-packages/yum/sqlitesack.py, line 43, in 
newFunc
return func(*args, **kwargs)
  File /usr/lib/python2.4/site-packages/yum/sqlitesack.py, line 586, 
in searchFiles
self._sql_pkgKey2po(rep, cur, pkgs)
  File /usr/lib/python2.4/site-packages/yum/sqlitesack.py, line 470, 
in _sql_pkgKey2po
pkg = self._packageByKey(repo, ob['pkgKey'])
  File /usr/lib/python2.4/site-packages/yum/sqlitesack.py, line 413, 
in _packageByKey
po = self.pc(repo, cur.fetchone())
  File /usr/lib/python2.4/site-packages/yum/sqlitesack.py, line 68, in 
__init__
self._read_db_obj(db_obj)
  File /usr/lib/python2.4/site-packages/yum/sqlitesack.py, line 94, in 
_read_db_obj
setattr(self, item, _share_data(db_obj[item]))
TypeError: unsubscriptable object

Local variables in innermost frame:
item: name
db_obj: None

Many thanks..

Sam

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Possible bug?

[nate]

Sam Drinkard wrote:
 I had some problems with apache, and there were so many, (caused by
 removing ispconfig) I decided to just remove and re-install.  This is
 what happened when I tried to do so, both from remote and via console.
 I tried the DVD as well as yum, and got essentially the same thing.  My
 webserver  is down, and I'd sure like to get this fixed if anyone can
 help out.

You try just running rpm -i path to httpd packages ?

Those errors look specific to yum and you can probably get the
system up faster by bypassing yum for now.

nate


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Possible bug?

[Sam Drinkard]

nate wrote:
 Sam Drinkard wrote:
   
 I had some problems with apache, and there were so many, (caused by
 removing ispconfig) I decided to just remove and re-install.  This is
 what happened when I tried to do so, both from remote and via console.
 I tried the DVD as well as yum, and got essentially the same thing.  My
 webserver  is down, and I'd sure like to get this fixed if anyone can
 help out.
 

 You try just running rpm -i path to httpd packages ?

 Those errors look specific to yum and you can probably get the
 system up faster by bypassing yum for now.

 nate


 ___
 CentOS mailing list
 CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos

   
Nate,

The command yum clean all took care of the problem.  I had no idea 
something as simple as that would make the stuff work!  I almost tried 
that while I was at the POP, but figured it was more of a problem with 
pirut or python or something.  Anyhow, I cleaned it, reinstalled apache, 
and all is back running now.

Thanks yall...

Sam

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] Possible bug in ifup-eth script of Centos 5.2 (combination of bond and bridge)

[Marco Fretz]

Dear CentOS,

I think i found a bug in the /etc/sysconfig/network-scripts/ifup-eth script 
of CentOS 5.2. i can post the my changed ifup-eth script if you want. 
Am I the first one with this problem?

Situation: 
- eth2 and eth3 should be in bond1 interface
- bond1 should be an interface of bridge named iscsi

the problem is that the brctl addif command in ifup-eth gets executed before 
the slave interfaces of a bonding are enslaved.

brctl addif fails if you are trying to add a bonding interface to a bridge and 
the bonding interface have no slaves.

my solution was to switch the order in the ifup-eth script:
- to the bonding (slave interfaces) stuff before the bridge stuff

and its working... the bonding interface gets his slaves and can be added to 
the bridge without any errors.


best regards
 Marco



___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] possible bug 5.1 - possibly more of a package issue

[dnk]

Hi there, not really sure if this is a bug, but more so rather a missing file...

I installed a fresh 5.1 copy very minimal - no desktop, etc. Now it
came up later that I would need a desktop on this install. So I was
going to just groupinstall in the Gnome Desktop.

# yum groupinstall GNOME Desktop Environment

Now while processing the dependencies, it fails out with a dependency
for libgaim.so.0 (for package nautilus-sendto). So I tried...

# yum provides libgaim.so.0

No results.

Ideas?

dnk
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] possible bug 5.1 - possibly more of a package issue

[William L. Maltby]

On Tue, 2007-12-18 at 10:30 -0800, dnk wrote:
 Hi there, not really sure if this is a bug, but more so rather a missing 
 file...
 
 I installed a fresh 5.1 copy very minimal - no desktop, etc. Now it
 came up later that I would need a desktop on this install. So I was
 going to just groupinstall in the Gnome Desktop.
 
 # yum groupinstall GNOME Desktop Environment
 
 Now while processing the dependencies, it fails out with a dependency
 for libgaim.so.0 (for package nautilus-sendto). So I tried...
 
 # yum provides libgaim.so.0
 
 No results.
 
 Ideas?
 
 dnk
 snip sig stuff

My 5.0 DVD and 5.1 iso image show the packages gaim.i386 and gaim-
devel.i386 provide this. They are beta-2:2.0.0* versions.

command was

yum --whatprovides libgaim.so.0

HTH
-- 
Bill

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] possible bug 5.1 - possibly more of a package issue

[William L. Maltby]

On Tue, 2007-12-18 at 10:30 -0800, dnk wrote:
 snip
CORRECTION, not --whatprovides. Drop the dashes.

-- 
Bill

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] possible bug 5.1 - possibly more of a package issue

[dnk]

I had not tired installing it from the CD (yet), but the issue was
more when installing from a remote repo with the groupinstall command
(and the dependency failing). However I will try that other option you
mentioned.

regards,

dnk

On Dec 18, 2007 11:15 AM, William L. Maltby [EMAIL PROTECTED] wrote:

 On Tue, 2007-12-18 at 10:30 -0800, dnk wrote:
  Hi there, not really sure if this is a bug, but more so rather a missing 
  file...
 
  I installed a fresh 5.1 copy very minimal - no desktop, etc. Now it
  came up later that I would need a desktop on this install. So I was
  going to just groupinstall in the Gnome Desktop.
 
  # yum groupinstall GNOME Desktop Environment
 
  Now while processing the dependencies, it fails out with a dependency
  for libgaim.so.0 (for package nautilus-sendto). So I tried...
 
  # yum provides libgaim.so.0
 
  No results.
 
  Ideas?
 
  dnk
  snip sig stuff

 My 5.0 DVD and 5.1 iso image show the packages gaim.i386 and gaim-
 devel.i386 provide this. They are beta-2:2.0.0* versions.

 command was

 yum --whatprovides libgaim.so.0

 HTH
 --
 Bill

 ___
 CentOS mailing list
 CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] possible bug 5.1 - possibly more of a package issue

[Akemi Yagi]

On Dec 18, 2007 10:30 AM, dnk [EMAIL PROTECTED] wrote:
 Hi there, not really sure if this is a bug, but more so rather a missing 
 file...

 I installed a fresh 5.1 copy very minimal - no desktop, etc. Now it
 came up later that I would need a desktop on this install. So I was
 going to just groupinstall in the Gnome Desktop.

 # yum groupinstall GNOME Desktop Environment

 Now while processing the dependencies, it fails out with a dependency
 for libgaim.so.0 (for package nautilus-sendto). So I tried...

In fact, this is a known upstream issue.  Please see:

http://bugs.centos.org/view.php?id=2483

Akemi
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos