Bug 527792

+++ This bug was initially created as a clone of Bug #518342 +++

+++ This bug was initially created as a clone of Bug #495680 +++

Escalated to Bugzilla from IssueTracker

--- Additional comment from tao on 2009-04-14 07:27:59 EDT ---

Provide clear and concise problem description as it is understood at the time of escalation
>> Under %post section of RHEL5 installation haldaemon and messagebus service is stopped. 
Later after reboot these services are running. But under %post they are stopped.
If we add commands to start (/etc/init.d/messagebus start;/etc/init.d/haldaemon start) it in %post then they get started. But they are not running by default.

rhnreg_ks has the below code which fetches the information and decides whether the system is fully virt or para virt or a physical host system

..snip ..
    bus = dbus.SystemBus()
           device_obj = \
               bus.get_object('org.freedesktop.Hal',
                              '/org/freedesktop/Hal/devices/computer')
           device = dbus.Interface(device_obj, 'org.freedesktop.Hal.Device')
           vendor = device.GetPropertyString('smbios.bios.vendor')
..snip ..

As messagebus and haldaemon are stopped in post , rhnreg_ks is unable to get the required information and hence the system is treated as a host system.

How reproducible:
>> Always

Steps to reproduce :
>> 
- Kickstart a RHEL5 system and under %post section specify a activation key to register the system on satellite/RHN.
Under %post you can specify :
rhnreg_ks --activationkey=<activation key> --serverUrl=http://server/XMLRPC


Actual Result :
>>> 
rhnreg_ks command executed in %post fails with :
Error reading hardware information: dbus_bindings.DBusException
Error reading DMI information: dbus_bindings.DBusException

Under %post :
dbus-daemon is stopped
hald is stopped

Desired Result:
>>>

Under %post :
dbus-daemon should be running
hald should be running

rhnreg_ks command executed in %post should work without any errors.

State specific action requested of SEG
>> Would like SEG to investigate on why haldaemon and messagebus are stopped in %post section.
If this is an expected behavior then rhnreg_ks command needs to be modified. It should not refer DMI information in %post but should have some other resources to decide whether system is host/para virt/fully virt. 

State whether or not a defect in the product is suspected
>> Yes. RHEL5 installation under post haldaemon and messagebus should be running
OR
the way rhnreg_ks decides whether system is para/fully virt should be changed.

sosreport 
>>>
Have attached the sosreport of the system which was kickstarted.
This event sent from IssueTracker by mmatsuya  [SEG - RHN]
 issue 284884

--- Additional comment from mmatsuya on 2009-04-14 07:49:09 EDT ---

I opened this bugzilla as a bug of rhn-client-tools.
This issue is similar to https://bugzilla.redhat.com/show_bug.cgi?id=253596. But actually, this is not same. The errata of BZ253596 doesn't help this issue. 

If I understand the bugzilla correctly, the fix was just avoiding the output of the error messages to stdout. 

The important point of this issue is that fullvirt guest is recognized as a normal host (non guest). As a result, it uses one entitlement (update or management) for fullvirt guest. This bring the bad effect to the subscription management on RHN.

We need for this fix...
1) to find another method to identify if it's fullvirt guest, except for hal.
or
2) to start hald and dbus-daemon before the execution of rhnreg_ks

Unfortunately, I don't have any idea for first one. So it seems that the second one is easier. 
If starting *always* both hald and dbus-daemon on installation is not prefer, those ones should be started *on demand* in rhnreg_ks (or anaconda). Otherwise, if rhnreg_ks fails to know if it's a fullvirt guest via dbus/hal, maybe we should not decide it as the normal host (not guest).

Thanks,

Masahiro

--- Additional comment from jhutar on 2009-08-18 03:41:52 EDT ---

Hello,
I have tested this issue on one my XEN host with RHEL-5.3 (partly updated to 5.4 - but host sw should not matter in this case) where I have created PV 5.4 using virt-manager and kickstart containing this:

%post
echo "serverURL=https://sputnik-stage.brq.redhat.com/XMLRPC" >> /etc/sysconfig/rhn/up2date
echo "sslCACert=/etc/sysconfig/rhn/RHN-ORG-TRUSTED-SSL-CERT" >> /etc/sysconfig/rhn/up2date
wget -O /etc/sysconfig/rhn/RHN-ORG-TRUSTED-SSL-CERT https://sputnik-stage.brq.redhat.com/pub/RHN-ORG-TRUSTED-SSL-CERT --no-check-certificate
ps ax > /root/bz495680-ps-ax.log
service messagebus status > /root/bz495680-services.log
service haldaemon status >> /root/bz495680-services.log
cp /etc/sysconfig/rhn/up2date /root/bz495680-up2date.log
rhnreg_ks --activationkey=2-jhutar-bz495680 &> /root/bz495680-rhnreg_ks.log
%end

Host system was registered to the sputnik-stage Satellite (5.2) and was entitled with the Provisioning and Virtualization entitlements.

After the kickstart completed, everything looks OK:

  1. guest system is registered to the sputnik-stage Satellite
  2. I see guest system in the Virtualization -> Details tab of the host
     system in the Satellite's WebUI
  3. on the other hand, /root/bz495680-services.log shows mentioned services
     were stopped before registration in the %post

Only problem I see is:

  1. guest system registered with profile name "unknown"

Do you have a clue what am I doing incorrectly while trying to reproduce this issue?

Regards,
Jan

--- Additional comment from atodorov on 2009-08-18 03:56:17 EDT ---

(In reply to comment #3)
> Do you have a clue what am I doing incorrectly while trying to reproduce this
> issue?

Hi Jan,
you're starting dbus and hal manually in %post before calling rhnreg_ks!
Either:
1) The behavior needs to be documented - bad because even documented people will still forget to start dbus and hal in their %post scripts and hit errors or;

2) Have anaconda start hal and dbus in stage2 or;

3) Have rhnreg_ks check if hal and dbus are running and start them automatically if not. Possibly stop the services after registration (not preference for this one).

--- Additional comment from jhutar on 2009-08-18 06:22:00 EDT ---

(In reply to comment #4)
> (In reply to comment #3)
> > Do you have a clue what am I doing incorrectly while trying to reproduce this
> > issue?
> 
> Hi Jan,
> you're starting dbus and hal manually in %post before calling rhnreg_ks!
[...]

No, I'm not, there is just "status". Or am I missing something?

--- Additional comment from jhutar on 2009-08-18 06:27:24 EDT ---

Also just checked on my workstation with F10 to install full-virt system (as mentioned in comment #2):

> 1) to find another method to identify
>    if it's fullvirt guest, except for hal.

And system is registered and kernel field in WebUI shows "Kernel: 2.6.18-162.el5". But this is probably not good test-case as a host is Fedora. Not sure. Anyway when I call rhnreg_ks after the installation (with both messagebus and haldaemon running), I'm getting same result.

--- Additional comment from pkilambi on 2009-08-19 16:11:59 EDT ---

Sending        up2date_client/rhnreg.py
Transmitting file data .
Committed revision 186347.

--- Additional comment from pkilambi on 2009-08-19 16:16:17 EDT ---

If we can get approval to get this into 5.4, I dont mind respinning packages.

--- Additional comment from ssalevan on 2009-08-19 16:21:31 EDT ---

*** Bug 518308 has been marked as a duplicate of this bug. ***

--- Additional comment from jsherril on 2009-08-19 19:21:13 EDT ---

Cloning this for possible inclusion in VADER.

Committed to master in commit: e879a81

Waiting for commitment before cherrypicking to VADER branch.

--- Additional comment from cperry on 2009-08-20 10:40:57 EDT ---

Given instructions to Devan to merge into vader and build new Stage ISO with fix.

--- Additional comment from dgoodwin on 2009-08-20 10:44:06 EDT ---

Satellite.git: f23396276421f2d73bd1ebcf9ebc8443e1343105

--- Additional comment from dgoodwin on 2009-08-20 10:45:13 EDT ---

Whoops, wrong commit id: 5fffc51efceea19013f1d018887db3942bf4876d

--- Additional comment from psklenar on 2009-08-20 10:54:46 EDT ---

hello, was original issue same like this one :

tried on kvm guest with latest rhel54 20090812
satellite is from 20090730

# rhnreg_ks --serverUrl=http://rlx-0-10.rhndev.redhat.com/XMLRPC
--password=admin --username=admin --force
libvir: Remote error : unable to connect to '/var/run/libvirt/libvirt-sock': No
such file or directory
An error has occurred:

libvirt.libvirtError
See /var/log/up2date for more information
[root@dhcp-lab-186 ~]# tail -n 19 /var/log/up2date 

[Thu Aug 20 10:49:47 2009] up2date 
Traceback (most recent call last):
  File "/usr/sbin/rhnreg_ks", line 216, in ?
    cli.run()
  File "/usr/share/rhn/up2date_client/rhncli.py", line 65, in run
    sys.exit(self.main() or 0)
  File "/usr/sbin/rhnreg_ks", line 178, in main
    rhnreg.sendVirtInfo(systemId)
  File "/usr/share/rhn/up2date_client/rhnreg.py", line 642, in sendVirtInfo
    support.refresh()
  File "/usr/share/rhn/virtualization/support.py", line 51, in refresh
    if _is_host_domain():
  File "/usr/share/rhn/virtualization/support.py", line 161, in _is_host_domain
    conn = libvirt.open(None)
  File "/usr/lib64/python2.4/site-packages/libvirt.py", line 159, in open
    if ret is None:raise libvirtError('virConnectOpen() failed')
libvirt.libvirtError: unable to connect to '/var/run/libvirt/libvirt-sock': No
such file or directory


registration with rhn_register works

--- Additional comment from pkilambi on 2009-08-20 11:43:30 EDT ---

Developer testing:

Satellite 530 with newest jar from vader branch: dhcp77-153.rhndev.redhat.com

Client is a vm

For 5u4 kickstart case:
=======================
* create a ks profile with a 5u4 tree

* schedule a kickstart and monitor the registration step at the post kickstart

* registration succeeds.

* snip from ks-post.log

Stopping system message bus: ESC[60G[ESC[0;31mFAILEDESC[0;39m]
Starting system message bus: ESC[60G[ESC[0;32m  OK  ESC[0;39m]
Stopping HAL daemon: ESC[60G[ESC[0;31mFAILEDESC[0;39m]
Starting HAL daemon: ESC[60G[ESC[0;32m  OK  ESC[0;39m]
--2009-08-20 15:21:37--  http://dhcp77-153.rhndev.redhat.com/pub/RHN-ORG-TRUSTED-SSL-CERT
Resolving dhcp77-153.rhndev.redhat.com... 10.10.77.153

For 5u3 kickstart case:
======================
* create a ks profile with a 5u3 tree

* schedule a kickstart and monitor the registration step at the post kickstart

* registration succeeds.

* snip from ks-post.log
Stopping system message bus: ESC[60G[ESC[0;31mFAILEDESC[0;39m]
Starting system message bus: ESC[60G[ESC[0;32m  OK  ESC[0;39m]
Stopping HAL daemon: ESC[60G[ESC[0;31mFAILEDESC[0;39m]
Starting HAL daemon: ESC[60G[ESC[0;32m  OK  ESC[0;39m]
--15:38:45--  http://dhcp77-153.rhndev.redhat.com/pub/RHN-ORG-TRUSTED-SSL-CERT
Resolving dhcp77-153.rhndev.redhat.com... 10.10.77.153

For 5u1 kickstart case:
======================
* create a ks profile with a 5u1 tree

* schedule a kickstart and monitor the registration step at the post kickstart

* registration succeeds.
Stopping system message bus: ESC[60G[ESC[0;31mFAILEDESC[0;39m]
Starting system message bus: ESC[60G[ESC[0;32m  OK  ESC[0;39m]
Stopping HAL daemon: ESC[60G[ESC[0;31mFAILEDESC[0;39m]
Starting HAL daemon: ESC[60G[ESC[0;32m  OK  ESC[0;39m]
--15:58:45--  http://dhcp77-153.rhndev.redhat.com/pub/RHN-ORG-TRUSTED-SSL-CERT
Resolving dhcp77-153.rhndev.redhat.com... 10.10.77.153

--- Additional comment from pkilambi on 2009-08-20 11:45:36 EDT ---

(In reply to comment #5)
> hello, was original issue same like this one :
> 
> tried on kvm guest with latest rhel54 20090812
> satellite is from 20090730
> 
> # rhnreg_ks --serverUrl=http://rlx-0-10.rhndev.redhat.com/XMLRPC
> --password=admin --username=admin --force
> libvir: Remote error : unable to connect to '/var/run/libvirt/libvirt-sock': No
> such file or directory
> An error has occurred:
> 
> libvirt.libvirtError
> See /var/log/up2date for more information

This looks like you dont have libvirt running. This sounds specifically for guests and yes your libvirt daemon is suppose to be running if not you need to start it to make sure it is. This has nothing to do with this bug.

--- Additional comment from whayutin on 2009-08-20 12:35:04 EDT ---

[root@rlx-3-06 ~]# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 5.4 (Tikanga)
[root@rlx-3-06 ~]# cat /etc/motd 

RHN Satellite kickstart on 2009-08-20


libxml2-python              ##################################################
cp: cannot stat `/tmp/ks-tree-copy/*': No such file or directory
Stopping system message bus: [FAILED]
Starting system message bus: [  OK  ]
Stopping HAL daemon: [FAILED]
Starting HAL daemon: [  OK  ]
--2009-08-20 12:19:05--  http://dhcp77-153.rhndev.redhat.com/pub/RHN-ORG-TRUSTED-SSL-CERT
Resolving dhcp77-153.rhndev.redhat.com... 10.10.77.153
Connecting to dhcp77-153.rhndev.redhat.com|10.10.77.153|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 5093 (5.0K) [text/plain]

same results on rlx-3-18.. so far so good..
checking older distributions now

--- Additional comment from ssalevan on 2009-08-21 14:26:07 EDT ---

VERIFIED on latest QA build.

--- Additional comment from cperry on 2009-08-24 10:05:22 EDT ---

Making this bug public. 

Summary:

When performing a RHEL 5.4 Kickstart installation and within the post script section you perform a rhnreg_ks registration of the system a 5.3 Satellite, the registration will fail. The failure is due to two daemons not running within the kickstart environment that we use to query SMBIOS information to determine if KVM host/guest. 

NOTES:
This bug will also likely effect registrations during kickstart to the RHN Hosted (rhn.redhat.com / xmlrpc.rhn.redhat.com) environment. 

Customers using Satellite 5.2 or earlier will not hit this bug, since they are not KVM aware Satellites for entitlement consumption. 

Solution:
Within the kickstart post script (%post) before you run the registration command (rhnreg_ks) add these two lines to restart daemons needed to query for SMBIOS hardware information:

/etc/init.d/messagebus restart
/etc/init.d/haldaemon restart 


Cliff

--- Additional comment from psklenar on 2009-09-17 09:43:30 EDT ---

verified again
kickstart contains in %post section:
/etc/init.d/messagebus restart
/etc/init.d/haldaemon restart

services are restarted in post on all arch except of ia64 : [Bug 523741] hald stop in %post, system is not registered to satellite after successful ks

moving to release pending