open-sharedroot-users — Discussion of user issues and wishes within the open-sharedroot project

[OSR-users] Changes on naming of the project and source hosting

[Marc G. <gr...@at...>]

Hello again,
after being silent for such a long time, I should try to bring everybody up on track.
As Olaf already stated in the past year we decided to integrate the open shared root project into ifs father project com.oonics.

The technical background is pretty easy. Besides the use case of shared root we've also seen many not shared root installation. Mainly when the focus was to have a installation that is capable of booting on different types of hardware (same architecture). We called this feature flexboot.

Besides some other projects came to live that added additional functionality that was not directly connected or necessary for having a shared root.

Basically this is the reason why we decided to move the open shared root projects inside the com.oonics project.
This does not change any function for using a shared root cluster but the naming.

Besides moving the name we also decided to move the code to an official openly available git repository. You can now find the latest code to be downloaded from https://github.com/comoonics. You'll find four repositories:

* git://github.com/comoonics/comoonics-initrd-ng.git: Is the repository for the initrd used for booting flexible Linux installations

* git://github.com/comoonics/comoonics-cluster-suite.git: The python libraries needed as dependency for some of the flexible Linux installation tools (see http://comoonics.org/development/ and the projects called comoonics-*-py).

* git://github.com/comoonics/comoonics-release.git: The release files.

* git://github.com/comoonics/comoonics-Dracut.git: The dracut modules to use open shared root with dracut (initrd of RHEL6 and Fedora)

Bugs and feature requests should be filed at https://bugzilla.comoonics.org/.

In the next weeks and months we'll also try to bring some information up2date on http://comoonics.org and http://open-sharedroot.org.

We're happy to get any kind of feedback.

Have fun
Marc.
______________________________________________________________________________

Marc Grimme

ATIX Informationstechnologie und Consulting AG | Einsteinstrasse 10 |
85716 Unterschleissheim | www.atix.de

Enterprise Linux einfach online kaufen: www.linux-subscriptions.com

Registergericht: Amtsgericht München, Registernummer: HRB 168930, USt.-Id.:
DE209485962 | Vorstand: Thomas Merz (Vors.), Marc Grimme, Mark Hlawatschek, Jan R. Bergrath |
Vorsitzender des Aufsichtsrats: Dr. Martin Buss

[OSR-users] Release of the open-shardroot software version 5.0

[Marc G. <gr...@at...>]

Hello,
I'm very happy to announce the availability for the open-sharedroot project version 5.0.

It is now possible to build diskless "shared" root clusters for the following configurations:

- RHEL5 Ext3, Ext4, NFS, GFS, GFS2*, GlusterFS*
- RHEL6 Ext3, Ext4, NFS, GFS2*, GlusterFS*
- SLES11 Ext3, Ext4, NFS, OCFS2
- Fedora*
- OpenSuSE*
- Now with and without configuration via /etc/cluster/cluster.conf.

* not yet or not officially supported

We are looking forward to your feedback.

See also  
http://comoonics.org/news-archive/release-of-com-oonics-5-0-for-rhel5-nfs-and-rhel6-nfs-sharedroot

Have fun.
Marc

______________________________________________________________________________

Marc Grimme

E-Mail: grimme( at )atix.de

ATIX Informationstechnologie und Consulting AG | Einsteinstrasse 10 |
85716 Unterschleissheim | www.atix.de

Enterprise Linux einfach online kaufen: www.linux-subscriptions.com

Registergericht: Amtsgericht München, Registernummer: HRB 168930, USt.-Id.:
DE209485962 | Vorstand: Thomas Merz (Vors.), Marc Grimme, Mark Hlawatschek, Jan R. Bergrath |
Vorsitzender des Aufsichtsrats: Dr. Martin Buss

Re: [OSR-users] Unable to boot Comoonics.. :(

[Mark H. <hla...@at...>]

Hi Nigel,

thanks for using open-sharedroot!

Could you please provide the following information:

1. boot your open-sharedroot with the boot parameter com-debug and provide the complete console output.
2. /etc/cluster/cluster.conf
3. /etc/hosts
4. output of #ifconfig -a

Redgards,

Mark

PS: You may want to try the latest open-sharedroot release candidate which is called RC1.


----- "Nigel Marett" <nig...@gm...> wrote:

> Greetings,
> 
> I've been banging my head against this for well over a week but can't
> seem to be able to figure out what is going on.
> 
> I'm installing a cluster on CentOS 5.5 and following the EL5 howto.
> (assuming the steps are identical)
> 
> Shared root builds, and all seems ok, but on boot the server stops
> when trying to mount the shared root.. (which is on a LVM, presented
> via iSCSI).
> 
> The issue appears to be related to ccsd, which starts with :
> 
> ccsd: cluster.conf (cluster name = mycluster, version = 1911201005)
> found.
> ccsd: Unable to sendto broadcast ipv6 socket, but inet_ntop returned
> NULL pointer: Cannot assign requested address
> ccsd: Initial Status:: Inquorate
> 
> 
> It's all downhill from there.. I can't mount any LV's because of:
> 
> comoonics 1> pvdisplay
> File descriptor 3 (/var/log/comoonics-boot.log) leaked on pvdisplay
> invocation.
> Parent PID 9937: /bin/bash
> File descriptor 4 (/var/log/comoonics-boot.log) leaked on pvdisplay
> invocation.
> Parent PID 9937: /bin/bash
> File descriptor 5 (/var/log/comoonics-boot.log) leaked on pvdisplay
> invocation.
> Parent PID 9937: /bin/bash
> 
> connect() failed on local socket: No such file or directory
> WARNING: Falling back to local file-based locking.
> Volume Groups with the clustered attribute will be inaccessible.
> 
> 
> Apologies for any typo's there.. I can't cut and paste from my KVM
> 
> I'm using comoonics productive for EL5 (on Centos 5) - just about to
> set up a real EL5 install to attempt this, but obviously I need
> cluster suite to get things working and it's a trial sub.. :(
> 

[OSR-users] Unable to boot Comoonics.. :(

[Nigel M. <nig...@gm...>]

Greetings,

I've been banging my head against this for well over a week but can't
seem to be able to figure out what is going on.

I'm installing a cluster on CentOS 5.5 and following the EL5 howto.
(assuming the steps are identical)

Shared root builds, and all seems ok, but on boot the server stops
when trying to mount the shared root.. (which is on a LVM, presented
via iSCSI).

The issue appears to be related to ccsd, which starts with :

ccsd: cluster.conf (cluster name = mycluster, version = 1911201005) found.
ccsd: Unable to sendto broadcast ipv6 socket, but inet_ntop returned
NULL pointer: Cannot assign requested address
ccsd: Initial Status:: Inquorate


It's all downhill from there.. I can't mount any LV's because of:

comoonics 1> pvdisplay
File descriptor 3 (/var/log/comoonics-boot.log) leaked on pvdisplay invocation.
Parent PID 9937: /bin/bash
File descriptor 4 (/var/log/comoonics-boot.log) leaked on pvdisplay invocation.
Parent PID 9937: /bin/bash
File descriptor 5 (/var/log/comoonics-boot.log) leaked on pvdisplay invocation.
Parent PID 9937: /bin/bash

connect() failed on local socket: No such file or directory
WARNING: Falling back to local file-based locking.
Volume Groups with the clustered attribute will be inaccessible.


Apologies for any typo's there.. I can't cut and paste from my KVM

I'm using comoonics productive for EL5 (on Centos 5) - just about to
set up a real EL5 install to attempt this, but obviously I need
cluster suite to get things working and it's a trial sub.. :(

Anyway, any help or advice would be appriciate.

Thanks in advance.

Kind Regards,


Nigel.


-- 
Nigel

Re: [OSR-users] clvmd crash at start

[Marc G. <gr...@at...>]

On what versions of comoonics packages are you currently working?

This look like an outdated version.

This bug is known and should be fixed.

Please check if you have the latest version.

Regards Marc.

----- Original Message -----
From: jjm...@pj...
To: ope...@li...
Sent: Saturday, October 16, 2010 5:45:43 PM
Subject: [OSR-users] clvmd crash at start

Hello. Im implementing a very larg cluster.. I have all the steps done  
.. all OK.. but when I reboot from my shared boot partitions it starts  
to boot perfect and then it stucks on starting clvmd with error

"could not create local socket" .. my bey clvmd is allready started...
So then.. the "Activating VGs" Fail...
All pre-services starts with OK

Al my config are done and the original cluster config with all nodes  
works perfectly
I have multipath with SAN storage and the osr booting logs recognize  
it and its luns, VGs and LVs (with the shared root lv)

Im stucked here.. :( could anybody help me please?



------------------------------------------------------------------------------
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
_______________________________________________
Open-sharedroot-users mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/open-sharedroot-users

-- 

Marc Grimme

Tel: +49 89 4523538-14
Fax: +49 89 9901766-0
E-Mail: gr...@at...

ATIX Informationstechnologie und Consulting AG | Einsteinstrasse 10 |
85716 Unterschleissheim | www.atix.de | www.open-sharedroot.org

Registergericht: Amtsgericht Muenchen, Registernummer: HRB 168930, USt.-Id.: 
DE209485962 | Vorstand: Marc Grimme, Mark Hlawatschek, Thomas Merz (Vors.) |
Vorsitzender des Aufsichtsrats: Dr. Martin Buss

[OSR-users] clvmd crash at start

[<jjm...@pj...>]

Hello. Im implementing a very larg cluster.. I have all the steps done  
.. all OK.. but when I reboot from my shared boot partitions it starts  
to boot perfect and then it stucks on starting clvmd with error

"could not create local socket" .. my bey clvmd is allready started...
So then.. the "Activating VGs" Fail...
All pre-services starts with OK

Al my config are done and the original cluster config with all nodes  
works perfectly
I have multipath with SAN storage and the osr booting logs recognize  
it and its luns, VGs and LVs (with the shared root lv)

Im stucked here.. :( could anybody help me please?

Re: [OSR-users] [Bug 386] Unable to boot with new localsocket based locking of clvmd

[Marc G. <gr...@at...>]

Jorge,
looks like your using VLANs on bonds and bridges.

In order to be able to use vlans you'll need the rpm comoonics-bootimage-extras-network.

Also the order of nics in the cluster.conf is important:

<eth name="eth0" mac="00:30:48:F0:10:34" master="bond0" slave="yes"/>
<eth name="eth1" mac="00:30:48:F0:10:55" master="bond0" slave="yes"/>
<eth name="bond0">
  <!-- Don't forget to set the properties for the bonding nic like this -->
  <properties>
     <property name="BONDING_OPTS">BONDING_OPTS="miimon=100 mode=1"</property>
  </properties>
</etc>
<eth name="bond0.165" bridge="br0"/>
<eth name="br0" type="bridge" ip="192.168.165.52" mask="255.255.255.0" gateway="192.168.165.1">
  <properties>
     <property name="STP">STP="off"</property>
  </properties>
</etc>
<eth name="bond0.20" ip="192.168.20.52" mask="255.255.255.0"/>
<!-- Sure with the mask?? -->
<eth name="bond0.10" ip="166.21.14.20"  mask="255.255.255.22"/>

Try this settings and let me know (Don't forget to install comooncis-bootimage-extras-network).

Regards Marc.
----- "Jorge Silva" <me...@je...> wrote:

> Marc
> 
> Hi -  just as a sanity check, I removed all the comoonics rpms I had .
> I 
> had removed the packages before, but I added them manually one by one.
> 
> This time, I removed them all and started from scratch
> 
> yum install comoonics-bootimage comoonics-cdsl-py
> 
> This is the only error I got but it seems that it is ok :
> 
> In order to be able to reboot properly with cluster filesystems it is
> 
> important to link
> /opt/atix/comoonics-bootimage/boot-scripts/com-halt.sh
> /sbin/halt.local
> Please try to fix or validate manually
> 
> I have checked :
>   ls -al /sbin/halt.local
> 
> lrwxrwxrwx 1 root root 54 Sep 19 15:06 /sbin/halt.local -> 
> /opt/atix/comoonics-bootimage/boot-scripts/com-halt.sh
> 
> Somehow my installation got messed up.  I now am able to build
> ramdisks 
> with no errors.
> 
> I now seem to be stuck on the activation of the network bridge
> 
> here is a section of my cluster.conf
> <eth mac="00:30:48:F0:10:34" master="bond0" name="eth0" slave="yes"/>
> <eth mac="00:30:48:F0:10:55" master="bond0" name="eth1" slave="yes"/>
> <eth name="bond0"/>
> <eth bridge="br0" name="bond0.165" options="STP=off"/>
> <eth gateway="192.168.165.1" ip="192.168.165.52" mask="255.255.255.0"
> 
> name="br0" type="Bridge"/> (I have tried this with bridge as well)
> <eth gateway="" ip="192.168.20.52" mask="255.255.255.0"
> name="bond0.20"/>
> <eth gateway="" ip="166.21.14.20" mask="255.255.255.22"
> name="bond0.10"/>
> 
> Attached are the screens for the network activation
> 
> Here are the rpm's I have installed:
> 
> comoonics-bootimage-listfiles-rhel-0.1-7.noarch
> SysVinit-comoonics-2.86-14.atix.1.x86_64
> comoonics-cdsl-py-0.2-31.noarch
> comoonics-cluster-py-0.1-27.noarch
> comoonics-bootimage-listfiles-all-0.1-15.noarch
> comoonics-bootimage-listfiles-rhel5-0.1-6.noarch
> comoonics-cluster-tools-py-0.1-10.noarch
> comoonics-bootimage-1.4-64.noarch
> comoonics-bootimage-extras-rdac-multipath-0.1-4.noarch
> comoonics-bootimage-extras-dm-multipath-rhel-0.1-3.noarch
> comoonics-tools-py-0.1-7.noarch
> comoonics-bootimage-extras-network-0.1-3.noarch
> comoonics-base-py-0.1-11.noarch
> comoonics-bootimage-initscripts-1.4-19.rhel5.noarch
> 
> 
> 
> 
> 
> 
> On 21/09/2010 10:15 AM, Marc Grimme wrote:
> > Jorge,
> > that looks strange.
> >
> > Could you try to extract the initrd as follows:
> > mkdir /tmp/initrd
> > cd /tmp/initrd
> > gzip -cd<pathtoinitrd>/initrd_sr-2.6.18-194.11.3.el5.img | cpio
> --extract --make-directories
> >
> > Then execute the following command:
> > chroot /tmp/initrd com-queryclusterconf nodeids
> >
> > What happens?
> >
> > Marc.
> > ----- "Jorge Silva"<me...@je...>  wrote:
> >
> >> Marc
> >>
> >> Hi - I have removed the packages are per your request I still get
> >> stuck
> >> at the same stage in the boot process
> >>
> >> Thanks for your help.
> >>
> >>
> >> I have downloaded from :
> >> using http://download.atix.de/yum/comoonics/rhel5/rc1/noarch/RPMS/
> >> Pakcages installed :
> >> comoonics-cluster-py-0.1-27.noarch
> >> comoonics-cluster-tools-py-0.1-10.noarch
> >> comoonics-bootimage-listfiles-rhel5-0.1-6.noarch
> >> comoonics-base-py-0.1-11.noarch
> >> comoonics-bootimage-listfiles-all-0.1-15.noarch
> >> comoonics-bootimage-extras-rdac-multipath-0.1-4.noarch
> >> comoonics-bootimage-extras-dm-multipath-rhel-0.1-3.noarch
> >> SysVinit-comoonics-2.86-14.atix.1.x86_64
> >> comoonics-bootimage-initscripts-1.4-19.rhel5.noarch
> >> comoonics-bootimage-extras-network-0.1-3.noarch
> >> comoonics-bootimage-listfiles-rhel-0.1-7.noarch
> >> comoonics-bootimage-1.4-64.noarch
> >> comoonics-tools-py-0.1-7.noarch
> >> comoonics-cdsl-py-0.2-31.noarch
> >>
> >> Rebuilding the ramdisk commands :
> >> [root@sms01d ~]# mkinitrd  -A 2.6.18-194.11.3.el5 -D
> >> 2.6.18-194.3.1.el5
> >> initrd_sr-2.6.18-194.11.3.el5.img
> >> Validating cluster configuration.                          [  OK 
> ]
> >> Executing files before mkinitrd.
> >> Executing skript "/etc/comoonics/bootimage/pre.mkinitrd.d/0[  OK
> >> ]heck.sh".
> >> Extracting rpms...                                         [  OK 
> ]
> >> Retrieving dependent files...found 2077 files              [  OK 
> ]
> >> Copying files...cp: cannot stat `/etc/udev/devices': No such file
> or
> >> directory
> >> cp: `/usr/lib/python2.4/site-packages/comoonics/AutoDelegator.py'
> and
> >>
> >> `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/site-pack
> >> ages/comoonics/AutoDelegator.py' are the same file
> >> cp:
> >>
> `/usr/lib/python2.4/site-packages/comoonics/cluster/ComClusterInfo.py'
> >>
> >> and `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/
> >> site-packages/comoonics/cluster/ComClusterInfo.py' are the same
> file
> >> cp:
> >>
> `/usr/lib/python2.4/site-packages/comoonics/cluster/ComClusterNodeNic.py'
> >> and
> >> `/tmp/initrd.mnt.Vl1218/usr/lib/python2
> >> .4/site-packages/comoonics/cluster/ComClusterNodeNic.py' are the
> same
> >> file
> >> cp:
> >>
> `/usr/lib/python2.4/site-packages/comoonics/cluster/ComClusterNode.py'
> >>
> >> and `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/
> >> site-packages/comoonics/cluster/ComClusterNode.py' are the same
> file
> >> cp:
> >>
> `/usr/lib/python2.4/site-packages/comoonics/cluster/ComClusterRepository.py'
> >>
> >> and `/tmp/initrd.mnt.Vl1218/usr/lib/pyth
> >> on2.4/site-packages/comoonics/cluster/ComClusterRepository.py' are
> the
> >>
> >> same file
> >> cp:
> >>
> `/usr/lib/python2.4/site-packages/comoonics/cluster/ComQueryMap.py'
> >> and `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/sit
> >> e-packages/comoonics/cluster/ComQueryMap.py' are the same file
> >> cp:
> >>
> `/usr/lib/python2.4/site-packages/comoonics/cluster/helper/__init__.py'
> >>
> >> and `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4
> >> /site-packages/comoonics/cluster/helper/__init__.py' are the same
> >> file
> >> cp:
> >>
> `/usr/lib/python2.4/site-packages/comoonics/cluster/helper/RedHatClusterHelper.py'
> >>
> >> and `/tmp/initrd.mnt.Vl1218/usr/li
> >>
> b/python2.4/site-packages/comoonics/cluster/helper/RedHatClusterHelper.py'
> >>
> >> are the same file
> >> cp:
> `/usr/lib/python2.4/site-packages/comoonics/cluster/__init__.py'
> >> and
> >> `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/site-p
> >> ackages/comoonics/cluster/__init__.py' are the same file
> >> cp: `/usr/lib/python2.4/site-packages/comoonics/ComDataObject.py'
> and
> >>
> >> `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/site-pack
> >> ages/comoonics/ComDataObject.py' are the same file
> >> cp: `/usr/lib/python2.4/site-packages/comoonics/ComExceptions.py'
> and
> >>
> >> `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/site-pack
> >> ages/comoonics/ComExceptions.py' are the same file
> >> cp: `/usr/lib/python2.4/site-packages/comoonics/ComLog.py' and
> >> `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/site-packages/co
> >>
> >> moonics/ComLog.py' are the same file
> >> cp: `/usr/lib/python2.4/site-packages/comoonics/ComPath.py' and
> >> `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/site-packages/c
> >>
> >> omoonics/ComPath.py' are the same file
> >> cp: `/usr/lib/python2.4/site-packages/comoonics/ComProperties.py'
> and
> >>
> >> `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/site-pack
> >> ages/comoonics/ComProperties.py' are the same file
> >> cp:
> >>
> `/usr/lib/python2.4/site-packages/comoonics/ComSystemInformation.py'
> >> and `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/si
> >> te-packages/comoonics/ComSystemInformation.py' are the same file
> >> cp: `/usr/lib/python2.4/site-packages/comoonics/ComSystem.py' and
> >> `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/site-packages
> >>
> >> /comoonics/ComSystem.py' are the same file
> >> cp: `/usr/lib/python2.4/site-packages/comoonics/DictTools.py' and
> >> `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/site-packages
> >>
> >> /comoonics/DictTools.py' are the same file
> >> cp: `/usr/lib/python2.4/site-packages/comoonics/__init__.py' and
> >> `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/site-packages/
> >>
> >> comoonics/__init__.py' are the same file
> >> cp: `/usr/lib/python2.4/site-packages/comoonics/lockfile.py' and
> >> `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/site-packages/
> >>
> >> comoonics/lockfile.py' are the same file
> >> cp: `/usr/lib/python2.4/site-packages/comoonics/odict.py' and
> >> `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/site-packages/com
> >>     oonics/odict.py'
> >> are the same file
> >> cp: `/usr/lib/python2.4/site-packages/comoonics/stabilized.py' and
> >> `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/site-package
> >> s/comoonics/stabilized.py' are the same file
> >> cp:
> `/usr/lib/python2.4/site-packages/comoonics/XMLConfigParser.py'
> >> and
> >> `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/site-pa
> >> ckages/comoonics/XMLConfigParser.py' are the same file
> >> cp: `/usr/lib/python2.4/site-packages/comoonics/XmlTools.py' and
> >> `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/site-packages/
> >>
> >> comoonics/XmlTools.py' are the same file
> >> cp: cannot stat `/usr/sbin/hot_add': No such file or directory
> >> cp: cannot stat `/usr/sbin/mppUtil': No such file or directory
> >>                                                              [  OK 
> ]
> >> Removing kernel 2.6.18-194.3.1.el5                         [  OK 
> ]
> >> Copying kernelmodules (2.6.18-194.11.3.el5)...184356 blocks
> >>                                                              [  OK 
> ]
> >> Post settings ..                                           [  OK 
> ]
> >> Executing files after mkinitrd.
> >> Sourcing skript "/etc/comoonics/bootimage/post.mkinitrd.d/0[  OK
> >> ]-cdsl-repository.sh". cdsl env
> >> builddate_file                                             [  OK 
> ]
> >> Creating index file ..                                     [  OK 
> ]
> >> Cpio and compress..                                        [  OK 
> ]
> >> Cleaning up (/tmp/initrd.mnt.Vl1218, )...                  [  OK 
> ]
> >> -rw-r--r-- 1 root root 49029 Sep 20 18:18
> >> initrd_sr-2.6.18-194.11.3.el5.img
> >>
> >>
> >> On 20/09/2010 3:17 PM, Marc Grimme wrote:
> >>> Hi Jorge,
> >>> first of all you need the channel from
> >>
> http://download.atix.de/yum/comoonics/rhel5/rc1/[noarchttp://download.atix.de/yum/comoonics/rhel5/rc1/h,{ARCHITECTURE}].
> >>> If this set also uninstall unnecessary packages like for example:
> >>> comoonics-pythonosfix-py-0.1-2.noarch
> >>> comoonics-cs-rgmanager-extras-0.5-26.noarch
> >>> comoonics-cs-xml-0.5-5.noarch
> >>>
> >>> Then rebuild your initrd and let me know about your progress.
> >>>
> >>> Also try to either send me a screenshot or output of your
> >> bootprocess.
> >>> Regards Marc.
> >>> ----- "Jorge Silva"<me...@je...>   wrote:
> >>> comoonics-bootimage-extras-rdac-multipath (You're not using rdac
> >> multipathing, I suppose)
> >>>> Marc
> >>>>
> >>>> Hi - updated all my files to the following from the rc1 dir:
> >>>> comoonics-cluster-py-0.1-27.noarch
> >>>> comoonics-cluster-tools-py-0.1-10.noarch
> >>>> comoonics-pythonosfix-py-0.1-2.noarch
> >>>> comoonics-cs-rgmanager-extras-0.5-26.noarch
> >>>> comoonics-bootimage-listfiles-rhel5-0.1-6.noarch
> >>>> comoonics-base-py-0.1-11.noarch
> >>>> comoonics-bootimage-listfiles-all-0.1-15.noarch
> >>>> comoonics-bootimage-extras-rdac-multipath-0.1-4.noarch
> >>>> comoonics-bootimage-extras-dm-multipath-rhel-0.1-3.noarch
> >>>> SysVinit-comoonics-2.86-14.atix.1.x86_64
> >>>> comoonics-bootimage-initscripts-1.4-19.rhel5.noarch
> >>>> comoonics-bootimage-extras-network-0.1-3.noarch
> >>>> comoonics-bootimage-listfiles-rhel-0.1-7.noarch
> >>>> comoonics-cs-xml-0.5-5.noarch
> >>>> comoonics-bootimage-1.4-64.noarch
> >>>> comoonics-tools-py-0.1-7.noarch
> >>>> comoonics-cdsl-py-0.2-31.noarch
> >>>>
> >>>> It builds the initrd - but get all the following errors, it
> builds
> >> it
> >>>> successfully however.
> >>>>
> >>>> I am unable to boot this new image - I get dropped into a shell
> at
> >> the
> >>>> stage where the cluster.conf gets validated it then suggests I
> run
> >>>> cc_validate cluster or something like that..  if I run
> cc_calidate
> >>>> cluster, I get no error message or anything else..
> >>>>
> >>>> Below is what I get when I am building the ramdisk.
> >>>>
> >>>> Copying files...cp: cannot stat `/etc/udev/devices': No such
> file
> >> or
> >>>> directory
> >>>> cp:
> `/usr/lib/python2.4/site-packages/comoonics/AutoDelegator.py'
> >> and
> >>>>
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/AutoDelegator.py'
> >>>> are the same file
> >>>> cp:
> >>>>
> >>
> `/usr/lib/python2.4/site-packages/comoonics/cluster/ComClusterInfo.py'
> >>>> and
> >>>>
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/cluster/ComClusterInfo.py'
> >>>> are the same file
> >>>> cp:
> >>>>
> >>
> `/usr/lib/python2.4/site-packages/comoonics/cluster/ComClusterNodeNic.py'
> >>>> and
> >>>>
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/cluster/ComClusterNodeNic.py'
> >>>> are the same file
> >>>> cp:
> >>>>
> >>
> `/usr/lib/python2.4/site-packages/comoonics/cluster/ComClusterNode.py'
> >>>> and
> >>>>
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/cluster/ComClusterNode.py'
> >>>> are the same file
> >>>> cp:
> >>>>
> >>
> `/usr/lib/python2.4/site-packages/comoonics/cluster/ComClusterRepository.py'
> >>>> and
> >>>>
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/cluster/ComClusterRepository.py'
> >>>> are the same file
> >>>> cp:
> >>>>
> >>
> `/usr/lib/python2.4/site-packages/comoonics/cluster/ComQueryMap.py'
> >>>> and
> >>>>
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/cluster/ComQueryMap.py'
> >>>> are the same file
> >>>> cp:
> >>>>
> >>
> `/usr/lib/python2.4/site-packages/comoonics/cluster/helper/__init__.py'
> >>>> and
> >>>>
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/cluster/helper/__init__.py'
> >>>> are the same file
> >>>> cp:
> >>>>
> >>
> `/usr/lib/python2.4/site-packages/comoonics/cluster/helper/RedHatClusterHelper.py'
> >>>> and
> >>>>
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/cluster/helper/RedHatClusterHelper.py'
> >>>> are the same file
> >>>> cp:
> >> `/usr/lib/python2.4/site-packages/comoonics/cluster/__init__.py'
> >>>> and
> >>>>
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/cluster/__init__.py'
> >>>> are the same file
> >>>> cp:
> `/usr/lib/python2.4/site-packages/comoonics/ComDataObject.py'
> >> and
> >>>>
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/ComDataObject.py'
> >>>> are the same file
> >>>> cp:
> `/usr/lib/python2.4/site-packages/comoonics/ComExceptions.py'
> >> and
> >>>>
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/ComExceptions.py'
> >>>> are the same file
> >>>> cp: `/usr/lib/python2.4/site-packages/comoonics/ComLog.py' and
> >>>>
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/ComLog.py'
> >>>> are the same file
> >>>> cp: `/usr/lib/python2.4/site-packages/comoonics/ComPath.py' and
> >>>>
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/ComPath.py'
> >>>> are the same file
> >>>> cp:
> `/usr/lib/python2.4/site-packages/comoonics/ComProperties.py'
> >> and
> >>>>
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/ComProperties.py'
> >>>> are the same file
> >>>> cp:
> >>>>
> >>
> `/usr/lib/python2.4/site-packages/comoonics/ComSystemInformation.py'
> >>>> and
> >>>>
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/ComSystemInformation.py'
> >>>> are the same file
> >>>> cp: `/usr/lib/python2.4/site-packages/comoonics/ComSystem.py'
> and
> >>>>
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/ComSystem.py'
> >>>> are the same file
> >>>> cp: `/usr/lib/python2.4/site-packages/comoonics/DictTools.py'
> and
> >>>>
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/DictTools.py'
> >>>> are the same file
> >>>> cp: `/usr/lib/python2.4/site-packages/comoonics/__init__.py' and
> >>>>
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/__init__.py'
> >>>> are the same file
> >>>> cp: `/usr/lib/python2.4/site-packages/comoonics/lockfile.py' and
> >>>>
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/lockfile.py'
> >>>> are the same file
> >>>> cp: `/usr/lib/python2.4/site-packages/comoonics/odict.py' and
> >>>>
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/odict.py'
> >>>> are the same file
> >>>> cp: `/usr/lib/python2.4/site-packages/comoonics/stabilized.py'
> and
> >>>>
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/stabilized.py'
> >>>> are the same file
> >>>> cp:
> >> `/usr/lib/python2.4/site-packages/comoonics/XMLConfigParser.py'
> >>>> and
> >>>>
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/XMLConfigParser.py'
> >>>> are the same file
> >>>> cp: `/usr/lib/python2.4/site-packages/comoonics/XmlTools.py' and
> >>>>
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/XmlTools.py'
> >>>> are the same file
> >>>> cp: cannot stat `/usr/sbin/hot_add': No such file or directory
> >>>> cp: cannot stat `/usr/sbin/mppUtil': No such file or directory
> >>>> On 19/09/2010 10:20 AM, Jorge Silva wrote:
> >>>>>    Marc
> >>>>>
> >>>>> Hi, thanks for getting back to me - I am sorry I'm not 100%
> sure
> >> of
> >>>>> the naming convention - the newer init scripts  you mentions
> for
> >>>>> Centos 5.5 would be in this directory
> >>>>>
> >>>>> /yum/comoonics/redhat-el5/rc1 -  is comoonics-4. 5.rc1 ?
> >>>>>
> >>>>> And just to clarify your naming conventions - is this correct.
> >>>>>
> >>>>> /yum/comoonics/redhat-el5/prod-4.5/ -s comoonics 4.5 ?
> >>>>>
> >>>>>
> >>>>> I will download the latest packages from the rc1 and let you if
> I
> >>>> have
> >>>>> any issues.
> >>>>>
> >>>>> Thanks
> >>>>> Jorge
> >>>>>
> >>>>> On 19/09/2010 2:26 AM, bug...@at... wrote:
> >>>>>> https://bugzilla.atix.de/show_bug.cgi?id=386
> >>>>>>
> >>>>>>
> >>>>>> Marc Grimme<ma...@at...>    changed:
> >>>>>>
> >>>>>>               What    |Removed                     |Added
> >>>>>>
> >>
> ----------------------------------------------------------------------------
> >>>>>>                 Status|NEW                         |ASSIGNED
> >>>>>>                   Flag|
> >> |comoonics-4.5+
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --- Comment #2 from Marc Grimme<ma...@at...>     2010-09-19
> >> 08:26:46
> >>>> ---
> >>>>>> Yes. I agree.
> >>>>>>
> >>>>>> This problem is already fixed in the current comoonics-4.6-rc1
> >> or
> >>>>>> preview.
> >>>>>>
> >>>>>> If attached the file
> >>>>>> /opt/atix/comoonics-bootimage/boot-scripts/etc/gfs-lib.sh.
> >>>>>>     * exchange this file,
> >>>>>>     * build a new initrd
> >>>>>>     * and reboot
> >>>>>>
> >>>>>> Let me know about your progress.
> >>>>>>
> >>>>>> This file just creates the directory /var/run/lvm. This is not
> >>>>>> available and
> >>>>>> therefore clvmd cannot communicate.
> >>>>>>
> >>>>>> Let me know if it helps.
> >>>>>>
> >>>>>> Marc.
> >>>>>>

-- 

Marc Grimme

Tel: +49 89 4523538-14
Fax: +49 89 9901766-0
E-Mail: gr...@at...

ATIX Informationstechnologie und Consulting AG | Einsteinstrasse 10 |
85716 Unterschleissheim | www.atix.de | www.open-sharedroot.org

Registergericht: Amtsgericht Muenchen, Registernummer: HRB 168930, USt.-Id.: 
DE209485962 | Vorstand: Marc Grimme, Mark Hlawatschek, Thomas Merz (Vors.) |
Vorsitzender des Aufsichtsrats: Dr. Martin Buss

Re: [OSR-users] [Bug 386] Unable to boot with new localsocket based locking of clvmd

[Marc G. <gr...@at...>]

Jorge,
that looks strange.

Could you try to extract the initrd as follows:
mkdir /tmp/initrd
cd /tmp/initrd
gzip -cd <pathtoinitrd>/initrd_sr-2.6.18-194.11.3.el5.img | cpio --extract --make-directories

Then execute the following command:
chroot /tmp/initrd com-queryclusterconf nodeids

What happens?

Marc.
----- "Jorge Silva" <me...@je...> wrote:

> Marc
> 
> Hi - I have removed the packages are per your request I still get
> stuck 
> at the same stage in the boot process
> 
> Thanks for your help.
> 
> 
> I have downloaded from :
> using http://download.atix.de/yum/comoonics/rhel5/rc1/noarch/RPMS/
> Pakcages installed :
> comoonics-cluster-py-0.1-27.noarch
> comoonics-cluster-tools-py-0.1-10.noarch
> comoonics-bootimage-listfiles-rhel5-0.1-6.noarch
> comoonics-base-py-0.1-11.noarch
> comoonics-bootimage-listfiles-all-0.1-15.noarch
> comoonics-bootimage-extras-rdac-multipath-0.1-4.noarch
> comoonics-bootimage-extras-dm-multipath-rhel-0.1-3.noarch
> SysVinit-comoonics-2.86-14.atix.1.x86_64
> comoonics-bootimage-initscripts-1.4-19.rhel5.noarch
> comoonics-bootimage-extras-network-0.1-3.noarch
> comoonics-bootimage-listfiles-rhel-0.1-7.noarch
> comoonics-bootimage-1.4-64.noarch
> comoonics-tools-py-0.1-7.noarch
> comoonics-cdsl-py-0.2-31.noarch
> 
> Rebuilding the ramdisk commands :
> [root@sms01d ~]# mkinitrd  -A 2.6.18-194.11.3.el5 -D
> 2.6.18-194.3.1.el5 
> initrd_sr-2.6.18-194.11.3.el5.img
> Validating cluster configuration.                          [  OK  ]
> Executing files before mkinitrd.
> Executing skript "/etc/comoonics/bootimage/pre.mkinitrd.d/0[  OK 
> ]heck.sh".
> Extracting rpms...                                         [  OK  ]
> Retrieving dependent files...found 2077 files              [  OK  ]
> Copying files...cp: cannot stat `/etc/udev/devices': No such file or 
> directory
> cp: `/usr/lib/python2.4/site-packages/comoonics/AutoDelegator.py' and
> 
> `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/site-pack               
> ages/comoonics/AutoDelegator.py' are the same file
> cp: 
> `/usr/lib/python2.4/site-packages/comoonics/cluster/ComClusterInfo.py'
> 
> and `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/               
> site-packages/comoonics/cluster/ComClusterInfo.py' are the same file
> cp: 
> `/usr/lib/python2.4/site-packages/comoonics/cluster/ComClusterNodeNic.py'
> and 
> `/tmp/initrd.mnt.Vl1218/usr/lib/python2               
> .4/site-packages/comoonics/cluster/ComClusterNodeNic.py' are the same
> file
> cp: 
> `/usr/lib/python2.4/site-packages/comoonics/cluster/ComClusterNode.py'
> 
> and `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/               
> site-packages/comoonics/cluster/ComClusterNode.py' are the same file
> cp: 
> `/usr/lib/python2.4/site-packages/comoonics/cluster/ComClusterRepository.py'
> 
> and `/tmp/initrd.mnt.Vl1218/usr/lib/pyth               
> on2.4/site-packages/comoonics/cluster/ComClusterRepository.py' are the
> 
> same file
> cp:
> `/usr/lib/python2.4/site-packages/comoonics/cluster/ComQueryMap.py' 
> and `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/sit               
> e-packages/comoonics/cluster/ComQueryMap.py' are the same file
> cp: 
> `/usr/lib/python2.4/site-packages/comoonics/cluster/helper/__init__.py'
> 
> and `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4               
> /site-packages/comoonics/cluster/helper/__init__.py' are the same
> file
> cp: 
> `/usr/lib/python2.4/site-packages/comoonics/cluster/helper/RedHatClusterHelper.py'
> 
> and `/tmp/initrd.mnt.Vl1218/usr/li               
> b/python2.4/site-packages/comoonics/cluster/helper/RedHatClusterHelper.py'
> 
> are the same file
> cp: `/usr/lib/python2.4/site-packages/comoonics/cluster/__init__.py'
> and 
> `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/site-p               
> ackages/comoonics/cluster/__init__.py' are the same file
> cp: `/usr/lib/python2.4/site-packages/comoonics/ComDataObject.py' and
> 
> `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/site-pack               
> ages/comoonics/ComDataObject.py' are the same file
> cp: `/usr/lib/python2.4/site-packages/comoonics/ComExceptions.py' and
> 
> `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/site-pack               
> ages/comoonics/ComExceptions.py' are the same file
> cp: `/usr/lib/python2.4/site-packages/comoonics/ComLog.py' and 
> `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/site-packages/co            
>   
> moonics/ComLog.py' are the same file
> cp: `/usr/lib/python2.4/site-packages/comoonics/ComPath.py' and 
> `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/site-packages/c             
>  
> omoonics/ComPath.py' are the same file
> cp: `/usr/lib/python2.4/site-packages/comoonics/ComProperties.py' and
> 
> `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/site-pack               
> ages/comoonics/ComProperties.py' are the same file
> cp:
> `/usr/lib/python2.4/site-packages/comoonics/ComSystemInformation.py' 
> and `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/si               
> te-packages/comoonics/ComSystemInformation.py' are the same file
> cp: `/usr/lib/python2.4/site-packages/comoonics/ComSystem.py' and 
> `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/site-packages              
> 
> /comoonics/ComSystem.py' are the same file
> cp: `/usr/lib/python2.4/site-packages/comoonics/DictTools.py' and 
> `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/site-packages              
> 
> /comoonics/DictTools.py' are the same file
> cp: `/usr/lib/python2.4/site-packages/comoonics/__init__.py' and 
> `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/site-packages/              
> 
> comoonics/__init__.py' are the same file
> cp: `/usr/lib/python2.4/site-packages/comoonics/lockfile.py' and 
> `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/site-packages/              
> 
> comoonics/lockfile.py' are the same file
> cp: `/usr/lib/python2.4/site-packages/comoonics/odict.py' and 
> `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/site-packages/com           
>    oonics/odict.py' 
> are the same file
> cp: `/usr/lib/python2.4/site-packages/comoonics/stabilized.py' and 
> `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/site-package               
> s/comoonics/stabilized.py' are the same file
> cp: `/usr/lib/python2.4/site-packages/comoonics/XMLConfigParser.py'
> and 
> `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/site-pa               
> ckages/comoonics/XMLConfigParser.py' are the same file
> cp: `/usr/lib/python2.4/site-packages/comoonics/XmlTools.py' and 
> `/tmp/initrd.mnt.Vl1218/usr/lib/python2.4/site-packages/              
> 
> comoonics/XmlTools.py' are the same file
> cp: cannot stat `/usr/sbin/hot_add': No such file or directory
> cp: cannot stat `/usr/sbin/mppUtil': No such file or directory
>                                                             [  OK  ]
> Removing kernel 2.6.18-194.3.1.el5                         [  OK  ]
> Copying kernelmodules (2.6.18-194.11.3.el5)...184356 blocks
>                                                             [  OK  ]
> Post settings ..                                           [  OK  ]
> Executing files after mkinitrd.
> Sourcing skript "/etc/comoonics/bootimage/post.mkinitrd.d/0[  OK  
> ]-cdsl-repository.sh". cdsl env
> builddate_file                                             [  OK  ]
> Creating index file ..                                     [  OK  ]
> Cpio and compress..                                        [  OK  ]
> Cleaning up (/tmp/initrd.mnt.Vl1218, )...                  [  OK  ]
> -rw-r--r-- 1 root root 49029 Sep 20 18:18
> initrd_sr-2.6.18-194.11.3.el5.img
> 
> 
> On 20/09/2010 3:17 PM, Marc Grimme wrote:
> > Hi Jorge,
> > first of all you need the channel from
> http://download.atix.de/yum/comoonics/rhel5/rc1/[noarchttp://download.atix.de/yum/comoonics/rhel5/rc1/h,{ARCHITECTURE}].
> >
> > If this set also uninstall unnecessary packages like for example:
> > comoonics-pythonosfix-py-0.1-2.noarch
> > comoonics-cs-rgmanager-extras-0.5-26.noarch
> > comoonics-cs-xml-0.5-5.noarch
> >
> > Then rebuild your initrd and let me know about your progress.
> >
> > Also try to either send me a screenshot or output of your
> bootprocess.
> >
> > Regards Marc.
> > ----- "Jorge Silva"<me...@je...>  wrote:
> > comoonics-bootimage-extras-rdac-multipath (You're not using rdac
> multipathing, I suppose)
> >> Marc
> >>
> >> Hi - updated all my files to the following from the rc1 dir:
> >> comoonics-cluster-py-0.1-27.noarch
> >> comoonics-cluster-tools-py-0.1-10.noarch
> >> comoonics-pythonosfix-py-0.1-2.noarch
> >> comoonics-cs-rgmanager-extras-0.5-26.noarch
> >> comoonics-bootimage-listfiles-rhel5-0.1-6.noarch
> >> comoonics-base-py-0.1-11.noarch
> >> comoonics-bootimage-listfiles-all-0.1-15.noarch
> >> comoonics-bootimage-extras-rdac-multipath-0.1-4.noarch
> >> comoonics-bootimage-extras-dm-multipath-rhel-0.1-3.noarch
> >> SysVinit-comoonics-2.86-14.atix.1.x86_64
> >> comoonics-bootimage-initscripts-1.4-19.rhel5.noarch
> >> comoonics-bootimage-extras-network-0.1-3.noarch
> >> comoonics-bootimage-listfiles-rhel-0.1-7.noarch
> >> comoonics-cs-xml-0.5-5.noarch
> >> comoonics-bootimage-1.4-64.noarch
> >> comoonics-tools-py-0.1-7.noarch
> >> comoonics-cdsl-py-0.2-31.noarch
> >>
> >> It builds the initrd - but get all the following errors, it builds
> it
> >>
> >> successfully however.
> >>
> >> I am unable to boot this new image - I get dropped into a shell at
> the
> >>
> >> stage where the cluster.conf gets validated it then suggests I run
> >> cc_validate cluster or something like that..  if I run cc_calidate
> >> cluster, I get no error message or anything else..
> >>
> >> Below is what I get when I am building the ramdisk.
> >>
> >> Copying files...cp: cannot stat `/etc/udev/devices': No such file
> or
> >> directory
> >> cp: `/usr/lib/python2.4/site-packages/comoonics/AutoDelegator.py'
> and
> >>
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/AutoDelegator.py'
> >>
> >> are the same file
> >> cp:
> >>
> `/usr/lib/python2.4/site-packages/comoonics/cluster/ComClusterInfo.py'
> >>
> >> and
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/cluster/ComClusterInfo.py'
> >>
> >> are the same file
> >> cp:
> >>
> `/usr/lib/python2.4/site-packages/comoonics/cluster/ComClusterNodeNic.py'
> >> and
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/cluster/ComClusterNodeNic.py'
> >>
> >> are the same file
> >> cp:
> >>
> `/usr/lib/python2.4/site-packages/comoonics/cluster/ComClusterNode.py'
> >>
> >> and
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/cluster/ComClusterNode.py'
> >>
> >> are the same file
> >> cp:
> >>
> `/usr/lib/python2.4/site-packages/comoonics/cluster/ComClusterRepository.py'
> >>
> >> and
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/cluster/ComClusterRepository.py'
> >>
> >> are the same file
> >> cp:
> >>
> `/usr/lib/python2.4/site-packages/comoonics/cluster/ComQueryMap.py'
> >> and
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/cluster/ComQueryMap.py'
> >>
> >> are the same file
> >> cp:
> >>
> `/usr/lib/python2.4/site-packages/comoonics/cluster/helper/__init__.py'
> >>
> >> and
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/cluster/helper/__init__.py'
> >>
> >> are the same file
> >> cp:
> >>
> `/usr/lib/python2.4/site-packages/comoonics/cluster/helper/RedHatClusterHelper.py'
> >>
> >> and
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/cluster/helper/RedHatClusterHelper.py'
> >>
> >> are the same file
> >> cp:
> `/usr/lib/python2.4/site-packages/comoonics/cluster/__init__.py'
> >> and
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/cluster/__init__.py'
> >>
> >> are the same file
> >> cp: `/usr/lib/python2.4/site-packages/comoonics/ComDataObject.py'
> and
> >>
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/ComDataObject.py'
> >>
> >> are the same file
> >> cp: `/usr/lib/python2.4/site-packages/comoonics/ComExceptions.py'
> and
> >>
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/ComExceptions.py'
> >>
> >> are the same file
> >> cp: `/usr/lib/python2.4/site-packages/comoonics/ComLog.py' and
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/ComLog.py'
> >>
> >> are the same file
> >> cp: `/usr/lib/python2.4/site-packages/comoonics/ComPath.py' and
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/ComPath.py'
> >>
> >> are the same file
> >> cp: `/usr/lib/python2.4/site-packages/comoonics/ComProperties.py'
> and
> >>
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/ComProperties.py'
> >>
> >> are the same file
> >> cp:
> >>
> `/usr/lib/python2.4/site-packages/comoonics/ComSystemInformation.py'
> >> and
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/ComSystemInformation.py'
> >>
> >> are the same file
> >> cp: `/usr/lib/python2.4/site-packages/comoonics/ComSystem.py' and
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/ComSystem.py'
> >>
> >> are the same file
> >> cp: `/usr/lib/python2.4/site-packages/comoonics/DictTools.py' and
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/DictTools.py'
> >>
> >> are the same file
> >> cp: `/usr/lib/python2.4/site-packages/comoonics/__init__.py' and
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/__init__.py'
> >>
> >> are the same file
> >> cp: `/usr/lib/python2.4/site-packages/comoonics/lockfile.py' and
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/lockfile.py'
> >>
> >> are the same file
> >> cp: `/usr/lib/python2.4/site-packages/comoonics/odict.py' and
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/odict.py'
> >>
> >> are the same file
> >> cp: `/usr/lib/python2.4/site-packages/comoonics/stabilized.py' and
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/stabilized.py'
> >>
> >> are the same file
> >> cp:
> `/usr/lib/python2.4/site-packages/comoonics/XMLConfigParser.py'
> >> and
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/XMLConfigParser.py'
> >>
> >> are the same file
> >> cp: `/usr/lib/python2.4/site-packages/comoonics/XmlTools.py' and
> >>
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/XmlTools.py'
> >>
> >> are the same file
> >> cp: cannot stat `/usr/sbin/hot_add': No such file or directory
> >> cp: cannot stat `/usr/sbin/mppUtil': No such file or directory
> >> On 19/09/2010 10:20 AM, Jorge Silva wrote:
> >>>   Marc
> >>>
> >>> Hi, thanks for getting back to me - I am sorry I'm not 100% sure
> of
> >>> the naming convention - the newer init scripts  you mentions for
> >>> Centos 5.5 would be in this directory
> >>>
> >>> /yum/comoonics/redhat-el5/rc1 -  is comoonics-4. 5.rc1 ?
> >>>
> >>> And just to clarify your naming conventions - is this correct.
> >>>
> >>> /yum/comoonics/redhat-el5/prod-4.5/ -s comoonics 4.5 ?
> >>>
> >>>
> >>> I will download the latest packages from the rc1 and let you if I
> >> have
> >>> any issues.
> >>>
> >>> Thanks
> >>> Jorge
> >>>
> >>> On 19/09/2010 2:26 AM, bug...@at... wrote:
> >>>> https://bugzilla.atix.de/show_bug.cgi?id=386
> >>>>
> >>>>
> >>>> Marc Grimme<ma...@at...>   changed:
> >>>>
> >>>>              What    |Removed                     |Added
> >>>>
> >>
> ----------------------------------------------------------------------------
> >>
> >>>>                Status|NEW                         |ASSIGNED
> >>>>                  Flag|                           
> |comoonics-4.5+
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --- Comment #2 from Marc Grimme<ma...@at...>    2010-09-19
> 08:26:46
> >> ---
> >>>> Yes. I agree.
> >>>>
> >>>> This problem is already fixed in the current comoonics-4.6-rc1
> or
> >>>> preview.
> >>>>
> >>>> If attached the file
> >>>> /opt/atix/comoonics-bootimage/boot-scripts/etc/gfs-lib.sh.
> >>>>    * exchange this file,
> >>>>    * build a new initrd
> >>>>    * and reboot
> >>>>
> >>>> Let me know about your progress.
> >>>>
> >>>> This file just creates the directory /var/run/lvm. This is not
> >>>> available and
> >>>> therefore clvmd cannot communicate.
> >>>>
> >>>> Let me know if it helps.
> >>>>
> >>>> Marc.
> >>>>

-- 

Marc Grimme

Tel: +49 89 4523538-14
Fax: +49 89 9901766-0
E-Mail: gr...@at...

ATIX Informationstechnologie und Consulting AG | Einsteinstrasse 10 |
85716 Unterschleissheim | www.atix.de | www.open-sharedroot.org

Registergericht: Amtsgericht Muenchen, Registernummer: HRB 168930, USt.-Id.: 
DE209485962 | Vorstand: Marc Grimme, Mark Hlawatschek, Thomas Merz (Vors.) |
Vorsitzender des Aufsichtsrats: Dr. Martin Buss

Re: [OSR-users] [Bug 386] Unable to boot with new localsocket based locking of clvmd

[Marc G. <gr...@at...>]

Hi Jorge,
first of all you need the channel from http://download.atix.de/yum/comoonics/rhel5/rc1/[noarchttp://download.atix.de/yum/comoonics/rhel5/rc1/h,{ARCHITECTURE}].

If this set also uninstall unnecessary packages like for example:
comoonics-pythonosfix-py-0.1-2.noarch
comoonics-cs-rgmanager-extras-0.5-26.noarch
comoonics-cs-xml-0.5-5.noarch

Then rebuild your initrd and let me know about your progress.

Also try to either send me a screenshot or output of your bootprocess.

Regards Marc.
----- "Jorge Silva" <me...@je...> wrote:
comoonics-bootimage-extras-rdac-multipath (You're not using rdac multipathing, I suppose)
> Marc
> 
> Hi - updated all my files to the following from the rc1 dir:
> comoonics-cluster-py-0.1-27.noarch
> comoonics-cluster-tools-py-0.1-10.noarch
> comoonics-pythonosfix-py-0.1-2.noarch
> comoonics-cs-rgmanager-extras-0.5-26.noarch
> comoonics-bootimage-listfiles-rhel5-0.1-6.noarch
> comoonics-base-py-0.1-11.noarch
> comoonics-bootimage-listfiles-all-0.1-15.noarch
> comoonics-bootimage-extras-rdac-multipath-0.1-4.noarch
> comoonics-bootimage-extras-dm-multipath-rhel-0.1-3.noarch
> SysVinit-comoonics-2.86-14.atix.1.x86_64
> comoonics-bootimage-initscripts-1.4-19.rhel5.noarch
> comoonics-bootimage-extras-network-0.1-3.noarch
> comoonics-bootimage-listfiles-rhel-0.1-7.noarch
> comoonics-cs-xml-0.5-5.noarch
> comoonics-bootimage-1.4-64.noarch
> comoonics-tools-py-0.1-7.noarch
> comoonics-cdsl-py-0.2-31.noarch
> 
> It builds the initrd - but get all the following errors, it builds it
> 
> successfully however.
> 
> I am unable to boot this new image - I get dropped into a shell at the
> 
> stage where the cluster.conf gets validated it then suggests I run 
> cc_validate cluster or something like that..  if I run cc_calidate 
> cluster, I get no error message or anything else..
> 
> Below is what I get when I am building the ramdisk.
> 
> Copying files...cp: cannot stat `/etc/udev/devices': No such file or 
> directory
> cp: `/usr/lib/python2.4/site-packages/comoonics/AutoDelegator.py' and
> 
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/AutoDelegator.py'
> 
> are the same file
> cp: 
> `/usr/lib/python2.4/site-packages/comoonics/cluster/ComClusterInfo.py'
> 
> and 
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/cluster/ComClusterInfo.py'
> 
> are the same file
> cp: 
> `/usr/lib/python2.4/site-packages/comoonics/cluster/ComClusterNodeNic.py'
> and 
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/cluster/ComClusterNodeNic.py'
> 
> are the same file
> cp: 
> `/usr/lib/python2.4/site-packages/comoonics/cluster/ComClusterNode.py'
> 
> and 
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/cluster/ComClusterNode.py'
> 
> are the same file
> cp: 
> `/usr/lib/python2.4/site-packages/comoonics/cluster/ComClusterRepository.py'
> 
> and 
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/cluster/ComClusterRepository.py'
> 
> are the same file
> cp:
> `/usr/lib/python2.4/site-packages/comoonics/cluster/ComQueryMap.py' 
> and 
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/cluster/ComQueryMap.py'
> 
> are the same file
> cp: 
> `/usr/lib/python2.4/site-packages/comoonics/cluster/helper/__init__.py'
> 
> and 
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/cluster/helper/__init__.py'
> 
> are the same file
> cp: 
> `/usr/lib/python2.4/site-packages/comoonics/cluster/helper/RedHatClusterHelper.py'
> 
> and 
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/cluster/helper/RedHatClusterHelper.py'
> 
> are the same file
> cp: `/usr/lib/python2.4/site-packages/comoonics/cluster/__init__.py'
> and 
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/cluster/__init__.py'
> 
> are the same file
> cp: `/usr/lib/python2.4/site-packages/comoonics/ComDataObject.py' and
> 
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/ComDataObject.py'
> 
> are the same file
> cp: `/usr/lib/python2.4/site-packages/comoonics/ComExceptions.py' and
> 
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/ComExceptions.py'
> 
> are the same file
> cp: `/usr/lib/python2.4/site-packages/comoonics/ComLog.py' and 
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/ComLog.py'
> 
> are the same file
> cp: `/usr/lib/python2.4/site-packages/comoonics/ComPath.py' and 
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/ComPath.py'
> 
> are the same file
> cp: `/usr/lib/python2.4/site-packages/comoonics/ComProperties.py' and
> 
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/ComProperties.py'
> 
> are the same file
> cp:
> `/usr/lib/python2.4/site-packages/comoonics/ComSystemInformation.py' 
> and 
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/ComSystemInformation.py'
> 
> are the same file
> cp: `/usr/lib/python2.4/site-packages/comoonics/ComSystem.py' and 
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/ComSystem.py'
> 
> are the same file
> cp: `/usr/lib/python2.4/site-packages/comoonics/DictTools.py' and 
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/DictTools.py'
> 
> are the same file
> cp: `/usr/lib/python2.4/site-packages/comoonics/__init__.py' and 
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/__init__.py'
> 
> are the same file
> cp: `/usr/lib/python2.4/site-packages/comoonics/lockfile.py' and 
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/lockfile.py'
> 
> are the same file
> cp: `/usr/lib/python2.4/site-packages/comoonics/odict.py' and 
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/odict.py'
> 
> are the same file
> cp: `/usr/lib/python2.4/site-packages/comoonics/stabilized.py' and 
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/stabilized.py'
> 
> are the same file
> cp: `/usr/lib/python2.4/site-packages/comoonics/XMLConfigParser.py'
> and 
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/XMLConfigParser.py'
> 
> are the same file
> cp: `/usr/lib/python2.4/site-packages/comoonics/XmlTools.py' and 
> `/tmp/initrd.mnt.p13843/usr/lib/python2.4/site-packages/comoonics/XmlTools.py'
> 
> are the same file
> cp: cannot stat `/usr/sbin/hot_add': No such file or directory
> cp: cannot stat `/usr/sbin/mppUtil': No such file or directory
> On 19/09/2010 10:20 AM, Jorge Silva wrote:
> >  Marc
> >
> > Hi, thanks for getting back to me - I am sorry I'm not 100% sure of
> 
> > the naming convention - the newer init scripts  you mentions for 
> > Centos 5.5 would be in this directory
> >
> > /yum/comoonics/redhat-el5/rc1 -  is comoonics-4. 5.rc1 ?
> >
> > And just to clarify your naming conventions - is this correct.
> >
> > /yum/comoonics/redhat-el5/prod-4.5/ -s comoonics 4.5 ?
> >
> >
> > I will download the latest packages from the rc1 and let you if I
> have 
> > any issues.
> >
> > Thanks
> > Jorge
> >
> > On 19/09/2010 2:26 AM, bug...@at... wrote:
> >> https://bugzilla.atix.de/show_bug.cgi?id=386
> >>
> >>
> >> Marc Grimme<ma...@at...>  changed:
> >>
> >>             What    |Removed                     |Added
> >>
> ----------------------------------------------------------------------------
> 
> >>
> >>               Status|NEW                         |ASSIGNED
> >>                 Flag|                            |comoonics-4.5+
> >>
> >>
> >>
> >>
> >> --- Comment #2 from Marc Grimme<ma...@at...>   2010-09-19 08:26:46
> ---
> >> Yes. I agree.
> >>
> >> This problem is already fixed in the current comoonics-4.6-rc1 or 
> >> preview.
> >>
> >> If attached the file 
> >> /opt/atix/comoonics-bootimage/boot-scripts/etc/gfs-lib.sh.
> >>   * exchange this file,
> >>   * build a new initrd
> >>   * and reboot
> >>
> >> Let me know about your progress.
> >>
> >> This file just creates the directory /var/run/lvm. This is not 
> >> available and
> >> therefore clvmd cannot communicate.
> >>
> >> Let me know if it helps.
> >>
> >> Marc.
> >>
> >

-- 

Marc Grimme

Tel: +49 89 4523538-14
Fax: +49 89 9901766-0
E-Mail: gr...@at...

ATIX Informationstechnologie und Consulting AG | Einsteinstrasse 10 |
85716 Unterschleissheim | www.atix.de | www.open-sharedroot.org

Registergericht: Amtsgericht Muenchen, Registernummer: HRB 168930, USt.-Id.: 
DE209485962 | Vorstand: Marc Grimme, Mark Hlawatschek, Thomas Merz (Vors.) |
Vorsitzender des Aufsichtsrats: Dr. Martin Buss

[OSR-users] Problem with rgmanager

[Stefano E. <ste...@so...>]

Hi Mark,

Yes, now the problem is solved.
I had forgotten to change the file /etc/hosts.
Thanks.

Bye
Stefano


Stefano,

is your problem solved now ?

-Mark

On Monday 31 August 2009 15:00:06 Stefano Elmopi wrote:
> Hi Mark,
>
> excuse me if I answer only now but I was on vacation.
> I am writing to confirm that the problem was that I didn't change the
> file /etc/hosts.......
> ...... as we say in Italy...... I'm lost in a glass of water !!
>
>
> Thanks,
>
> Stefano
>
>
>
> Date: Wed, 1 Jul 2009 17:33:48 +0200
> From: Mark Hlawatschek <hla...@at...>
> Subject: Re: [OSR-users] Problem with rgmanager
> To: ope...@li...
> Message-ID: <200...@at...>
> Content-Type: text/plain;  charset="utf-8"
>
> Stefano,
>
> could you please give us an overview of your network setup ?
> # cat /etc/hosts
> # ip addr
>
> Could you also send me the output of the following command:
> # cman_tool status
> # cman_tool nodes
>
> Thanks,
>
> Mark
>
>
>
> Ing. Stefano Elmopi
> Gruppo Darco - Area ICT Sistemi
> Via Ostiense 131/L Corpo B, 00154 Roma
>
> cell. 3466147165
> tel.  0657060500
> email:ste...@so...
>
> Il giorno 01/lug/09, alle ore 14:16, Stefano Elmopi ha scritto:
>> Hi,
>>
>> I am happening a strange thing. I created a cluster with two nodes,
>> clu01 and clu02,
>> with the Shared-Root on a SAN. The node clu01 has the IP address
>> 10.43.100.203
>>
>> <clusternode name="clu01" votes="1" nodeid="1">
>>  <com_info>
>>    <syslog name="clu01"/>
>>    <rootvolume name="/dev/sda2" fstype="ocfs2"/>
>>    <eth name="eth0" ip="10.43.100.203" mac="00:15:60:56:75:FD"/>
>>    <fenceackserver user="root" passwd="test123"/>
>>  </com_info>
>> </clusternode>
>>
>> I also configured the service Httpd on the cluster and everything
>> worked well.
>> I had to change IP address (10.43.105.10) to the node_1 and so I
>> preferred to do the procedure again,
>> formatting the Shared-Root but not the server clu01.
>> The cluster starts with the new IP address and when I am starting
>> rgmanager:
>>
>> /etc/init.d/rgmanager strat
>>
>> everything seems ok
>> but in the log file I read:
>>
>> Jun 27 10:13:14 clu01 kernel: dlm: Using TCP for communications
>> Jun 27 10:13:14 clu01 kernel: dlm: Can't create listening comms  
>> socket
>> Jun 27 10:13:14 clu01 kernel: dlm: cannot start dlm lowcomms -98
>>
>> and the output of command :
>>
>> clustat
>> Cluster Status for cluOCFS2 @ Wed Jul  1 13:35:10 2009
>> Member Status: Quorate
>>
>> Member Name
>> ID   Status
>> ------ ----
>> ---- ------
>> clu01
>> 1 Online, Local
>> clu02
>> 2 Offline
>>
>>
>> missing part on the service.
>> if I try to make the restart of rgmanager, the log is:
>>
>> Jun 28 04:02:08 clu01 syslogd 1.4.1: restart.
>> Jul  1 13:37:31 clu01 kernel: dlm: Using TCP for communications
>> Jul  1 13:37:31 clu01 kernel: dlm: Can't create listening comms  
>> socket
>> Jul  1 13:37:41 clu01 kernel: BUG: soft lockup - CPU#0 stuck for
>> 10s! [clurgmgrd:13230]
>> Jul  1 13:37:41 clu01 kernel:
>> Jul  1 13:37:41 clu01 kernel: Pid: 13230, comm:            clurgmgrd
>> Jul  1 13:37:41 clu01 kernel: EIP: 0060:[<c0608d90>] CPU: 0
>> Jul  1 13:37:41 clu01 kernel: EIP is at _spin_lock+0x7/0xf
>> Jul  1 13:37:41 clu01 kernel:  EFLAGS: 00000286    Tainted: G
>> (2.6.18-92.1.22.el5PAE #1)
>> Jul  1 13:37:41 clu01 kernel: EAX: f1d93a98 EBX: f1d93a94 ECX:
>> 00000000 EDX: e1958000
>> Jul  1 13:37:41 clu01 kernel: ESI: f1d93a94 EDI: f1e31000 EBP:
>> e1958ebc DS: 007b ES: 007b
>> Jul  1 13:37:41 clu01 kernel: CR0: 8005003b CR2: b7f48000 CR3:
>> 37caef00 CR4: 000006f0
>> Jul  1 13:37:41 clu01 kernel:  [<c06080ef>] __mutex_lock_slowpath
>> +0x19/0x7c
>> Jul  1 13:37:41 clu01 kernel:  [<c0608161>] .text.lock.mutex+0xf/0x14
>> Jul  1 13:37:41 clu01 kernel:  [<f8c2ff6b>] close_connection
>> +0x11/0x5a [dlm]
>> Jul  1 13:37:41 clu01 kernel:  [<f8c308fd>] dlm_lowcomms_start+0x53e/
>> 0x59c [dlm]
>> Jul  1 13:37:41 clu01 kernel:  [<c06076a4>] schedule+0x920/0x9cd
>> Jul  1 13:37:41 clu01 kernel:  [<f8c2e879>] dlm_new_lockspace
>> +0x87/0x742 [dlm]
>> Jul  1 13:37:41 clu01 kernel:  [<f8c33d38>] device_write+0x310/0x4b6
>> [dlm]
>> Jul  1 13:37:41 clu01 kernel:  [<f8c33a28>] device_write+0x0/0x4b6
>> [dlm]
>> Jul  1 13:37:41 clu01 kernel:  [<c0470283>] vfs_write+0xa1/0x143
>> Jul  1 13:37:41 clu01 kernel:  [<c0470875>] sys_write+0x3c/0x63
>> Jul  1 13:37:41 clu01 kernel:  [<c0404eff>] syscall_call+0x7/0xb
>> Jul  1 13:37:41 clu01 kernel:  =======================
>>
>>
>>
>> if I change the file cluster.conf, put back the old IP
>> (10.43.100.203) and create a new initrd,
>> rgmanager works well.
>> This happens even with the same IP subnet 10.43.100, in practice it
>> seems that it works only
>> with the single IP address with which it was originally created the
>> cluster !
>>
>>
>> Thanks.
>>
>>
>>
>> Ing. Stefano Elmopi
>> Gruppo Darco - Area ICT Sistemi
>> Via Ostiense 131/L Corpo B, 00154 Roma
>>
>> cell. 3466147165
>> tel.  0657060500
>> email:ste...@so...





Ing. Stefano Elmopi
Gruppo Darco - Resp. ICT Sistemi
Via Ostiense 131/L Corpo B, 00154 Roma

cell. 3466147165
tel.  0657060500
email:ste...@so...

[OSR-users] Brunel Hotel Vacancies Announcement

[Brunel H. L. <bru...@ya...>]

You are invited to "Brunel Hotel Vacancies Announcement ".


By your host Brunel Hotel London:

 Job Vacancies
Head Office Address 
79-81 Gloucester Terrace, London,UK.    
 
TEL  +44 703 186 6861. 
FAX  +44 870 974 1928.
 
I am Mrs.Grandison Stella, the Brunel Hotel Suites London Vacancies Announcement Secretary.
As per above request, we need manpower to work in Brunel Hotel in London. The total requirements will be 170 applicants, applicants that have the ability to work hard, only need to apply and must come from non-criminal origin and must agreed to abide by the hotel's rules 

     Date:		Saturday 21 November 2009

     Time:		8:00 - 8:00 (GMT +00:00)
     Location:		London UK
     Street:		79-81 Gloucester Terrace, London , UK
     City County Postcode:	w21ju
     Phone:		+44-703 186 6861

Guests:

     * sg...@re...
     * ri...@hu...
     * js...@re...
     * js...@re...
     * kv...@re...
     * mma...@re...
     * pkn...@re...
     * pla...@re...
     * gr...@at...
     * ope...@li...
     * ope...@li...
     * ge...@fe...
     * gl...@re...
     * ber...@fe...
     * lpo...@re...
     * des...@li...
     * fed...@re...
     * fed...@li...
     * ma...@po...
     * si...@fe...
     * dh...@re...
     * thi...@re...
     * fed...@fe...
     * br...@wo...
     * max...@fe...
     * amb...@fe...
     * co...@fe...
     * co...@fe...
     * co...@fe...
     * co...@fe...
     * co...@fe...
     * do...@fe...
     * fa...@fe...
     * inf...@fe...
     * mar...@fe...
     * lo...@fe...
     * de...@ht...
     * we...@ab...m
     * we...@de...m
     * na...@tr...
     * ap...@ex...
     * som...@nz...
     * so...@au...
     * chr...@sa...
     * web...@ma...
     * web...@ma...
     * ra...@cu...
     * na...@tr...
     * sec...@ht...
     * loc...@lo...

invitation_add_to_your_yahoo_calendar:

     http://uk.calendar.yahoo.com/?v=60&ST=20091121T080000%2B0000&TITLE=Brunel+Hotel+Vacancies+Announcement+&VIEW=d&DESC=+Job+Vacancies%0d%0aHead+Office+Address+%0d%0a79-81+Gloucester+Terrace,+London,UK.++++%0d%0a+%0d%0aTEL++%2b44+703+186+6861.+%0d%0aFAX++%2b44+870+974+1928.%0d%0a+%0d%0aI+am+Mrs.Grandison+Stella,+the+Brunel+Hotel+Suites+London+Vacancies+Announcement+Secretary.%0d%0aAs+per+above+request,+we+need+manpower+to+work+in+Brunel+Hotel+in+London.+The+total+requirements+will+be+170+applicants,+applicants+that+have+the+ability+to+work+hard,+only+need+to+apply+and+must+come+from+non-criminal+origin+and+must+agreed+to+abide+by+the+hotel%27s+rules+and+regulations.Salary+is+very+attractive+depending+on+experience+to+be+found+in+our+salary+and+benefit+which+will+be+forwarded+to+you+for+your+perusal.+Overtime%3a+2+hrs/day+Public+Holiday+/+Sunday%3a+Double+Pay.The+important+thing+here+is+speed.The+hotel+management+wants+the+whole+thing+settled+in+25+days+time.%0d%0aIf+you+can+meet+our+requirement+please+reply+for+further+procedures.+The+management+will+take+care+of+your+feeding,accommodation+including+your+air+ticket.+We+will+provide+all+the+relevant+backup+documents+to+enable+the+applicant+get+his+or+her+visa+at+U.K-Embassy+in+the+applicant%27s+country.Visas+will+be+issued+upon+approval+from+U.K+Immigration+lawyer.+If+you+are+interested+to+work+with+us,respond+to+this+mail+as+a+matter+of+urgency.if+you+are+willing+to+apply,you+should+contact+the+Brunel+Hotel+manager+Mr.Franklyn+Scott+via+our+official+Email+address,bru...@ya...++for+more+information+about+the+jobs+and+salary+details+OK,+I+am+Mrs.+Grandison+Stella,%0d%0a+%0d%0a+NOTES%3a%0d%0a+Only+candidates+that+contacted+us+via+our+Email+Address+shall+be+answered.%0d%0a+Email%3ab...@ya...+%0d%0a+%0d%0a+Thanks%0d%0a+Brunel+Hotel+Vacancies+Announcement+Secretary%0d%0a+Mrs,Grandison+Stella.&in_loc=London+UK&in_csz=w21ju&in_ph=%2b44-703+186+6861&in_st=79-81+Gloucester+Terrace,+London+,+UK&TYPE=10

    
Copyright © 2009 All Rights Reserved
 www.yahoo.co.uk

Privacy Policy:
 http://privacy.yahoo.com/privacy/uk

Terms of Service:
 http://uk.docs.yahoo.com/info/terms.html

Re: [OSR-users] [OSR-devel] Bridged Interfaces

[Marc G. <gr...@at...>]

----- "Gordan Bobic" <go...@bo...> wrote:

> Hmm, I'm trying to use this configuration:
> 
> <eth	name    = "eth1"
> 	mac     = "00:0B:DB:90:4E:1C"
> 	bridge  = "br1"
> 	driver  = "e1000"
> />
> <eth    name    = "br1"
> 	type    = "bridge"
> 	ip      = "10.2.255.252"
> 	mask    = "255.255.0.0"
> 	gateway = ""
        driver="bridge"
> />
What happens if you add driver="bridge" here?

Bridges can sometimes be a little "tricky" as they can up little late.

But try use the above settings and let me know if this helps.

Marc.
> 
> And the interfaces end up not coming up properly. The error message
> says 
> that it couldn't identify them, and I get dumped to the debug prompt.
> If 
> I then rmmod and modprobe them in the right order and configure 
> manually, it continues booting OK. Am I missing a parameter
> somewhere?
> 
> Gordan
> 
> Marc Grimme wrote:
> > Just keep the bridge small in the cluster.conf. 
> > The Bridge in ifcfg-<bridgename> will be Bridge not bridge.
> > Regards Marc.
> > ----- "Gordan Bobic" <go...@bo...> wrote:
> > 
> >> Marc Grimme wrote:
> >>
> >>>> Specifically, KVM bridged networking requires a bridged network
> >>>> device, 
> >>>> which I'm not sure can be set up in cluster.conf at the moment.
> >>  >
> >>> It can.
> >>> See
> >>>
> >>
> http://www.open-sharedroot.org/faq/administrators-handbook/cluster-system-administration/networking/configure-bridging-on-the-cluster-interfaces/?searchterm=bridge
> >>> Let me know if you have any further questions. But this is a
> typical
> >> setup and should not be a problem.
> >>
> >> Ah, awesome, I couldn't find that page in the docs. Clearly I
> wasn't 
> >> trying hard enough. :)
> >>
> >>
> >> [...]
> >>
> >>> What is doable is to specify both in the cluster.conf. If you
> want
> >> to bridge a NIC that is required in the initrd you need to specify
> >> both (the nic and the bridge) in the cluster.conf.
> >>> Your example would look as follows:
> >>> <cluster ..>
> >>> ..
> >>> <clusternode name="..." ..>
> >>>   <com_info>
> >>>      <eth name="eth0" mac="00:11:22:33:44:55" bridge="br0" ../>
> >>>      <eth name="br0"  ip="10.11.12.13" mask="255.0.0.0"
> >> gateway="10.255.255.254" ../>
> >>>      ..
> >>>   </com_info>
> >>> </clusternode>
> >>> ..
> >>> </cluster>
> >>>
> >>> What do you think?
> >> One minor question - the docs say that on the br0 interface, there
> 
> >> should be a 'type="bridge"' attribute (RH documentation says that
> in
> >> the 
> >> ifcfg file "Bridge" is case sensitive). Should this be added, and
> does
> >>
> >> this case-sensitivity hold in cluster.conf?
> >>
> >> Thanks.
> >>
> >> Gordan
> >

-- 

Marc Grimme

Tel: +49 89 4523538-14
Fax: +49 89 9901766-0
E-Mail: gr...@at...

ATIX Informationstechnologie und Consulting AG | Einsteinstrasse 10 |
85716 Unterschleissheim | www.atix.de | www.open-sharedroot.org

------------------------------------------------------------
** 12.11.09 ATIX IT Solution Day "Open Source meets Data Centre" **
Weitere Infos: www.atix.de
------------------------------------------------------------

Registergericht: Amtsgericht Muenchen, Registernummer: HRB 168930, USt.-Id.: 
DE209485962 | Vorstand: Marc Grimme, Mark Hlawatschek, Thomas Merz (Vors.) |
Vorsitzender des Aufsichtsrats: Dr. Martin Buss

Re: [OSR-users] Problem with rgmanager

[Mark H. <hla...@at...>]

Stefano,

is your problem solved now ?

-Mark

On Monday 31 August 2009 15:00:06 Stefano Elmopi wrote:
> Hi Mark,
>
> excuse me if I answer only now but I was on vacation.
> I am writing to confirm that the problem was that I didn't change the
> file /etc/hosts.......
> ...... as we say in Italy...... I'm lost in a glass of water !!
>
>
> Thanks,
>
> Stefano
>
>
>
> Date: Wed, 1 Jul 2009 17:33:48 +0200
> From: Mark Hlawatschek <hla...@at...>
> Subject: Re: [OSR-users] Problem with rgmanager
> To: ope...@li...
> Message-ID: <200...@at...>
> Content-Type: text/plain;  charset="utf-8"
>
> Stefano,
>
> could you please give us an overview of your network setup ?
> # cat /etc/hosts
> # ip addr
>
> Could you also send me the output of the following command:
> # cman_tool status
> # cman_tool nodes
>
> Thanks,
>
> Mark
>
>
>
> Ing. Stefano Elmopi
> Gruppo Darco - Area ICT Sistemi
> Via Ostiense 131/L Corpo B, 00154 Roma
>
> cell. 3466147165
> tel.  0657060500
> email:ste...@so...
>
> Il giorno 01/lug/09, alle ore 14:16, Stefano Elmopi ha scritto:
> > Hi,
> >
> > I am happening a strange thing. I created a cluster with two nodes,
> > clu01 and clu02,
> > with the Shared-Root on a SAN. The node clu01 has the IP address
> > 10.43.100.203
> >
> > <clusternode name="clu01" votes="1" nodeid="1">
> >   <com_info>
> >     <syslog name="clu01"/>
> >     <rootvolume name="/dev/sda2" fstype="ocfs2"/>
> >     <eth name="eth0" ip="10.43.100.203" mac="00:15:60:56:75:FD"/>
> >     <fenceackserver user="root" passwd="test123"/>
> >   </com_info>
> > </clusternode>
> >
> > I also configured the service Httpd on the cluster and everything
> > worked well.
> > I had to change IP address (10.43.105.10) to the node_1 and so I
> > preferred to do the procedure again,
> > formatting the Shared-Root but not the server clu01.
> > The cluster starts with the new IP address and when I am starting
> > rgmanager:
> >
> > /etc/init.d/rgmanager strat
> >
> > everything seems ok
> > but in the log file I read:
> >
> > Jun 27 10:13:14 clu01 kernel: dlm: Using TCP for communications
> > Jun 27 10:13:14 clu01 kernel: dlm: Can't create listening comms socket
> > Jun 27 10:13:14 clu01 kernel: dlm: cannot start dlm lowcomms -98
> >
> > and the output of command :
> >
> > clustat
> > Cluster Status for cluOCFS2 @ Wed Jul  1 13:35:10 2009
> > Member Status: Quorate
> >
> >  Member Name
> > ID   Status
> >  ------ ----
> > ---- ------
> >  clu01
> > 1 Online, Local
> >  clu02
> > 2 Offline
> >
> >
> > missing part on the service.
> > if I try to make the restart of rgmanager, the log is:
> >
> > Jun 28 04:02:08 clu01 syslogd 1.4.1: restart.
> > Jul  1 13:37:31 clu01 kernel: dlm: Using TCP for communications
> > Jul  1 13:37:31 clu01 kernel: dlm: Can't create listening comms socket
> > Jul  1 13:37:41 clu01 kernel: BUG: soft lockup - CPU#0 stuck for
> > 10s! [clurgmgrd:13230]
> > Jul  1 13:37:41 clu01 kernel:
> > Jul  1 13:37:41 clu01 kernel: Pid: 13230, comm:            clurgmgrd
> > Jul  1 13:37:41 clu01 kernel: EIP: 0060:[<c0608d90>] CPU: 0
> > Jul  1 13:37:41 clu01 kernel: EIP is at _spin_lock+0x7/0xf
> > Jul  1 13:37:41 clu01 kernel:  EFLAGS: 00000286    Tainted: G
> > (2.6.18-92.1.22.el5PAE #1)
> > Jul  1 13:37:41 clu01 kernel: EAX: f1d93a98 EBX: f1d93a94 ECX:
> > 00000000 EDX: e1958000
> > Jul  1 13:37:41 clu01 kernel: ESI: f1d93a94 EDI: f1e31000 EBP:
> > e1958ebc DS: 007b ES: 007b
> > Jul  1 13:37:41 clu01 kernel: CR0: 8005003b CR2: b7f48000 CR3:
> > 37caef00 CR4: 000006f0
> > Jul  1 13:37:41 clu01 kernel:  [<c06080ef>] __mutex_lock_slowpath
> > +0x19/0x7c
> > Jul  1 13:37:41 clu01 kernel:  [<c0608161>] .text.lock.mutex+0xf/0x14
> > Jul  1 13:37:41 clu01 kernel:  [<f8c2ff6b>] close_connection
> > +0x11/0x5a [dlm]
> > Jul  1 13:37:41 clu01 kernel:  [<f8c308fd>] dlm_lowcomms_start+0x53e/
> > 0x59c [dlm]
> > Jul  1 13:37:41 clu01 kernel:  [<c06076a4>] schedule+0x920/0x9cd
> > Jul  1 13:37:41 clu01 kernel:  [<f8c2e879>] dlm_new_lockspace
> > +0x87/0x742 [dlm]
> > Jul  1 13:37:41 clu01 kernel:  [<f8c33d38>] device_write+0x310/0x4b6
> > [dlm]
> > Jul  1 13:37:41 clu01 kernel:  [<f8c33a28>] device_write+0x0/0x4b6
> > [dlm]
> > Jul  1 13:37:41 clu01 kernel:  [<c0470283>] vfs_write+0xa1/0x143
> > Jul  1 13:37:41 clu01 kernel:  [<c0470875>] sys_write+0x3c/0x63
> > Jul  1 13:37:41 clu01 kernel:  [<c0404eff>] syscall_call+0x7/0xb
> > Jul  1 13:37:41 clu01 kernel:  =======================
> >
> >
> >
> > if I change the file cluster.conf, put back the old IP
> > (10.43.100.203) and create a new initrd,
> > rgmanager works well.
> > This happens even with the same IP subnet 10.43.100, in practice it
> > seems that it works only
> > with the single IP address with which it was originally created the
> > cluster !
> >
> >
> > Thanks.
> >
> >
> >
> > Ing. Stefano Elmopi
> > Gruppo Darco - Area ICT Sistemi
> > Via Ostiense 131/L Corpo B, 00154 Roma
> >
> > cell. 3466147165
> > tel.  0657060500
> > email:ste...@so...

[OSR-users] Problem with rgmanager

[Stefano E. <ste...@so...>]

Hi Mark,

excuse me if I answer only now but I was on vacation.
I am writing to confirm that the problem was that I didn't change the  
file /etc/hosts.......
...... as we say in Italy...... I'm lost in a glass of water !!


Thanks,

Stefano



Date: Wed, 1 Jul 2009 17:33:48 +0200
From: Mark Hlawatschek <hla...@at...>
Subject: Re: [OSR-users] Problem with rgmanager
To: ope...@li...
Message-ID: <200...@at...>
Content-Type: text/plain;  charset="utf-8"

Stefano,

could you please give us an overview of your network setup ?
# cat /etc/hosts
# ip addr

Could you also send me the output of the following command:
# cman_tool status
# cman_tool nodes

Thanks,

Mark



Ing. Stefano Elmopi
Gruppo Darco - Area ICT Sistemi
Via Ostiense 131/L Corpo B, 00154 Roma

cell. 3466147165
tel.  0657060500
email:ste...@so...

Il giorno 01/lug/09, alle ore 14:16, Stefano Elmopi ha scritto:

>
>
> Hi,
>
> I am happening a strange thing. I created a cluster with two nodes,  
> clu01 and clu02,
> with the Shared-Root on a SAN. The node clu01 has the IP address  
> 10.43.100.203
>
> <clusternode name="clu01" votes="1" nodeid="1">
>   <com_info>
>     <syslog name="clu01"/>
>     <rootvolume name="/dev/sda2" fstype="ocfs2"/>
>     <eth name="eth0" ip="10.43.100.203" mac="00:15:60:56:75:FD"/>
>     <fenceackserver user="root" passwd="test123"/>
>   </com_info>
> </clusternode>
>
> I also configured the service Httpd on the cluster and everything  
> worked well.
> I had to change IP address (10.43.105.10) to the node_1 and so I  
> preferred to do the procedure again,
> formatting the Shared-Root but not the server clu01.
> The cluster starts with the new IP address and when I am starting  
> rgmanager:
>
> /etc/init.d/rgmanager strat
>
> everything seems ok
> but in the log file I read:
>
> Jun 27 10:13:14 clu01 kernel: dlm: Using TCP for communications
> Jun 27 10:13:14 clu01 kernel: dlm: Can't create listening comms socket
> Jun 27 10:13:14 clu01 kernel: dlm: cannot start dlm lowcomms -98
>
> and the output of command :
>
> clustat
> Cluster Status for cluOCFS2 @ Wed Jul  1 13:35:10 2009
> Member Status: Quorate
>
>  Member Name                                                      
> ID   Status
>  ------ ----                                                      
> ---- ------
>  clu01                                                                
> 1 Online, Local
>  clu02                                                                
> 2 Offline
>
>
> missing part on the service.
> if I try to make the restart of rgmanager, the log is:
>
> Jun 28 04:02:08 clu01 syslogd 1.4.1: restart.
> Jul  1 13:37:31 clu01 kernel: dlm: Using TCP for communications
> Jul  1 13:37:31 clu01 kernel: dlm: Can't create listening comms socket
> Jul  1 13:37:41 clu01 kernel: BUG: soft lockup - CPU#0 stuck for  
> 10s! [clurgmgrd:13230]
> Jul  1 13:37:41 clu01 kernel:
> Jul  1 13:37:41 clu01 kernel: Pid: 13230, comm:            clurgmgrd
> Jul  1 13:37:41 clu01 kernel: EIP: 0060:[<c0608d90>] CPU: 0
> Jul  1 13:37:41 clu01 kernel: EIP is at _spin_lock+0x7/0xf
> Jul  1 13:37:41 clu01 kernel:  EFLAGS: 00000286    Tainted: G        
> (2.6.18-92.1.22.el5PAE #1)
> Jul  1 13:37:41 clu01 kernel: EAX: f1d93a98 EBX: f1d93a94 ECX:  
> 00000000 EDX: e1958000
> Jul  1 13:37:41 clu01 kernel: ESI: f1d93a94 EDI: f1e31000 EBP:  
> e1958ebc DS: 007b ES: 007b
> Jul  1 13:37:41 clu01 kernel: CR0: 8005003b CR2: b7f48000 CR3:  
> 37caef00 CR4: 000006f0
> Jul  1 13:37:41 clu01 kernel:  [<c06080ef>] __mutex_lock_slowpath 
> +0x19/0x7c
> Jul  1 13:37:41 clu01 kernel:  [<c0608161>] .text.lock.mutex+0xf/0x14
> Jul  1 13:37:41 clu01 kernel:  [<f8c2ff6b>] close_connection 
> +0x11/0x5a [dlm]
> Jul  1 13:37:41 clu01 kernel:  [<f8c308fd>] dlm_lowcomms_start+0x53e/ 
> 0x59c [dlm]
> Jul  1 13:37:41 clu01 kernel:  [<c06076a4>] schedule+0x920/0x9cd
> Jul  1 13:37:41 clu01 kernel:  [<f8c2e879>] dlm_new_lockspace 
> +0x87/0x742 [dlm]
> Jul  1 13:37:41 clu01 kernel:  [<f8c33d38>] device_write+0x310/0x4b6  
> [dlm]
> Jul  1 13:37:41 clu01 kernel:  [<f8c33a28>] device_write+0x0/0x4b6  
> [dlm]
> Jul  1 13:37:41 clu01 kernel:  [<c0470283>] vfs_write+0xa1/0x143
> Jul  1 13:37:41 clu01 kernel:  [<c0470875>] sys_write+0x3c/0x63
> Jul  1 13:37:41 clu01 kernel:  [<c0404eff>] syscall_call+0x7/0xb
> Jul  1 13:37:41 clu01 kernel:  =======================
>
>
>
> if I change the file cluster.conf, put back the old IP  
> (10.43.100.203) and create a new initrd,
> rgmanager works well.
> This happens even with the same IP subnet 10.43.100, in practice it  
> seems that it works only
> with the single IP address with which it was originally created the  
> cluster !
>
>
> Thanks.
>
>
>
> Ing. Stefano Elmopi
> Gruppo Darco - Area ICT Sistemi
> Via Ostiense 131/L Corpo B, 00154 Roma
>
> cell. 3466147165
> tel.  0657060500
> email:ste...@so...
>

Re: [OSR-users] Sorting of eth ports inside initrd

[Klaus S. <kla...@Ph...>]

Hi,

> It should be "options bonding miimon=100 mode=1". Shouldn't it?

yep, that was some skeleton in the closet. In the old version the 
options bond0 did work .....

Now it works completly.

Sincerly,
Klaus

Re: [OSR-users] Sorting of eth ports inside initrd

[Marc G. <gr...@at...>]

On Tuesday 04 August 2009 12:29:34 Klaus Steinberger wrote:
> Hi,
>
> >> Did you specify the driver at every nodes eth element?
> >
> > ahh, I needed the driver parameter also in the bonding entry. Now it
> > works.
>
> There is now one problem left:
>
> Our bonding device has to be set to the following options.
> options bond0 miimon=100 mode=1
> This in modprobe.conf, but the new initrd seems to not use that?
It should be "options bonding miimon=100 mode=1". Shouldn't it?
>
> How can I specify that parameters?
The /etc/modprobe.conf should end up in the initrd.
>
>
> Btw. where can I find the complete documentation for the com_info
> section? There are many howto's for different types of clusters, but is
> there any central point of documentation for com_info?
Not yet. We are going to have a consolidated Howto with also reference to 
com_info (see 
http://www.open-sharedroot.org/documentation/general-osr-howto). Some bits 
are also to be found in the Administrator Handbook 
(http://www.open-sharedroot.org/documentation/administrators-handbook).
Sorry about that.
>
> Sincerly,
> Klaus

-- 
Gruss / Regards,

Marc Grimme
http://www.atix.de/               http://www.open-sharedroot.org/

Re: [OSR-users] Sorting of eth ports inside initrd

[Klaus S. <kla...@Ph...>]

Hi,


>> Did you specify the driver at every nodes eth element?
> 
> ahh, I needed the driver parameter also in the bonding entry. Now it works.

There is now one problem left:

Our bonding device has to be set to the following options.
options bond0 miimon=100 mode=1
This in modprobe.conf, but the new initrd seems to not use that?

How can I specify that parameters?


Btw. where can I find the complete documentation for the com_info 
section? There are many howto's for different types of clusters, but is 
there any central point of documentation for com_info?

Sincerly,
Klaus

Re: [OSR-users] Sorting of eth ports inside initrd

[Klaus S. <kla...@Ph...>]

Hi,

> Did you specify the driver at every nodes eth element?

ahh, I needed the driver parameter also in the bonding entry. Now it works.

Thanks a lot!

Sincerly,
Klaus

Re: [OSR-users] Sorting of eth ports inside initrd

[Marc G. <gr...@at...>]

On Tuesday 04 August 2009 11:19:58 Klaus Steinberger wrote:
> Hi,
>
> >> Before we reorder our eth Ports in the Config, is there any way to
> >> change this behaviour, and fix the ordering of the module loading?
> >
> > Yes there is. With latest version of productive/preview. You can define
> > the driver per nic.
> >
> > This means if you specify:
> > <eth name="eth0" ... driver="bnx2"/>
> > For this nic bnx2 will be loaded first.
> >
> > Do think that could help?
>
> It seems to not work. If I specify driver="bnx2" it runs into the
> comoonics debug shell as it seems to not find parameters correctly.
>
> Now I tried resorting interfaces, but it got more bad, seems like
> loading order is really unpredictable.
>
> Sincerly,
> Klaus

Did you specify the driver at every nodes eth element?
If you don't specify the @driver at every clusternode in the cluster.conf udev 
is started for detecting the nic. If you want to have a static configuration 
use the @driver in every eth-tag you are using. Even if you use bridges.

My config looks as follows and it works very much predictable:
<?xml version='1.0' encoding='UTF-8'?>
<cluster config_version='35' name='clu_generix' type='gfs'>
  <clusternodes>
    <clusternode votes='1' nodeid='2' name='generix2.local'>
      <com_info>
        <eth mac='...' name='eth1' bridge="clusterbr0" driver="bridge"/>
	<eth type="bridge" name="clusterbr0" ip="10.10.10.82" mask='255.255.255.0' 
driver="tg3"/>
        <rootvolume name='/dev/vg_clu_generix_s/lv_sharedroot'  
mountopts="noatime"/>
        <fenceackserver passwd='XXX' user='root'/>
        <chrootenv mountpoint="/var/comoonics/chroot" fstype="ext3" 
device="/dev/vg_local/lv_chroot" chrootdir="/var/comoonics/chroot" 
driver="sata_mv libata sata_svw sata_mv"/>
        <syslog name="10.10.10.1"/>
        <scsi failover="mapper"/>
      </com_info>
      <fence>
       <method name="1">
	       <device name="fence_apc" port="2"/>
       </method>
       <method name="2">	
	       <device name="fence_sanbox2" port="6"/>
       </method>
      </fence>
    </clusternode>
    <clusternode votes='1' nodeid='3' name='generix3.local'>
      <com_info>
        <eth mac='...' name='eth1' bridge="clusterbr0" driver="bridge"/>
	<eth type="bridge" name="clusterbr0" ip="10.10.10.83" mask='255.255.255.0' 
driver="tg3"/>
        <rootvolume name='/dev/vg_clu_generix_s/lv_sharedroot' 
mountopts="defaults"/>
        <fenceackserver passwd='XXX' user='root'/>
        <chrootenv mountpoint="/var/comoonics/chroot" fstype="ext3" 
device="/dev/vg_local/lv_chroot" chrootdir="/var/comoonics/chroot" 
driver="sata_mv libata sata_svw sata_mv"/>
        <syslog name="10.10.10.1"/>
        <scsi failover="mapper"/>
      </com_info>
      <fence>
        <method name="1">
		<device name="fence_apc" port="3"/>
        </method>
        <method name="2">
                <device name="fence_ipmilan" ipaddr="192.168.3.90"/>
	</method>
      </fence>
    </clusternode>
    <clusternode votes='1' nodeid='4' name='generix4.local'>
      <com_info>
        <eth name='eth0' mac="..." driver="r8169"/>
        <eth name='eth1' mac="..." driver="e1000" bridge="clusterbr0"/>
	<eth type="bridge" name="clusterbr0" ip="10.10.10.84" mask='255.255.255.0' 
driver="bridge"/>
        <rootvolume name='/dev/vg_clu_generix_s/lv_sharedroot' 
mountopts="defaults"/>
        <fenceackserver passwd='XXX' user='root'/>
        <chrootenv mountpoint="/var/comoonics/chroot" fstype="ext3" 
device="/dev/vg_local/lv_chroot" chrootdir="/var/comoonics/chroot" 
driver="sata_mv libata sata_svw sata_mv ata_piix"/>
        <syslog name="10.10.10.1"/>
        <scsi failover="mapper"/>
      </com_info>
      <fence>
        <method name="1">
		<device name="fence_apc" port="4"/>
        </method>
       <method name="2">	
	       <device name="fence_sanbox2" port="7"/>
       </method>
      </fence>
    </clusternode>
  </clusternodes>
...

-- 
Gruss / Regards,

Marc Grimme
Phone: +49-89 452 3538-14
http://www.atix.de/               http://www.open-sharedroot.org/

ATIX Informationstechnologie und Consulting AG | Einsteinstrasse 10 |
85716 Unterschleissheim | www.atix.de | www.open-sharedroot.org

Registergericht: Amtsgericht Muenchen, Registernummer: HRB 168930, USt.-Id.: 
DE209485962 | Vorstand: Marc Grimme, Mark Hlawatschek, Thomas Merz (Vors.) |
Vorsitzender des Aufsichtsrats: Dr. Martin Buss

Re: [OSR-users] Sorting of eth ports inside initrd

[Klaus S. <kla...@Ph...>]

Hi,


>> Before we reorder our eth Ports in the Config, is there any way to
>> change this behaviour, and fix the ordering of the module loading?

> Yes there is. With latest version of productive/preview. You can define the 
> driver per nic.
> 
> This means if you specify:
> <eth name="eth0" ... driver="bnx2"/>
> For this nic bnx2 will be loaded first. 
> 
> Do think that could help?

It seems to not work. If I specify driver="bnx2" it runs into the 
comoonics debug shell as it seems to not find parameters correctly.

Now I tried resorting interfaces, but it got more bad, seems like 
loading order is really unpredictable.

Sincerly,
Klaus

Re: [OSR-users] Sorting of eth ports inside initrd

[Marc G. <gr...@at...>]

On Monday 03 August 2009 15:19:41 Klaus Steinberger wrote:
> Hi,
>
> we did run into trouble with the new production version of Openshared
> Root. We do have 6 Ethernet ports on our servers, 2 of them with the
> internal ports of the system board (broadcomm, bnx2 module), and 4
> additional ports on a add on PCI Express Card (Intel, e1000e Module).
>
> With the old initrd we got the following ordering:
>
> bnx2 Module:  eth0 and eth1
> e1000e Module:  eth2 - eth5
>
> Now with the new initrd, something changed with loading modules inside
> the initrd, and we got them exchanged, so e1000e is first (eth0 - eth3),
> and second bnx2  (eth4, eth5).
>
> Of course that didn't work, as our device assignements did not fit any
> more.
>
>
> Before we reorder our eth Ports in the Config, is there any way to
> change this behaviour, and fix the ordering of the module loading?
>
> Sincerly,
> Klaus Steinberger

Yes there is. With latest version of productive/preview. You can define the 
driver per nic.

This means if you specify:
<eth name="eth0" ... driver="bnx2"/>
For this nic bnx2 will be loaded first. 

Do think that could help?

-- 
Gruss / Regards,

Marc Grimme
http://www.atix.de/               http://www.open-sharedroot.org/

[OSR-users] Sorting of eth ports inside initrd

[Klaus S. <kla...@Ph...>]

Hi,

we did run into trouble with the new production version of Openshared 
Root. We do have 6 Ethernet ports on our servers, 2 of them with the 
internal ports of the system board (broadcomm, bnx2 module), and 4 
additional ports on a add on PCI Express Card (Intel, e1000e Module).

With the old initrd we got the following ordering:

bnx2 Module:  eth0 and eth1
e1000e Module:  eth2 - eth5

Now with the new initrd, something changed with loading modules inside 
the initrd, and we got them exchanged, so e1000e is first (eth0 - eth3), 
and second bnx2  (eth4, eth5).

Of course that didn't work, as our device assignements did not fit any more.


Before we reorder our eth Ports in the Config, is there any way to 
change this behaviour, and fix the ordering of the module loading?

Sincerly,
Klaus Steinberger

Re: [OSR-users] Problem with rgmanager

[Mark H. <hla...@at...>]

Stefano,

could you please give us an overview of your network setup ?
# cat /etc/hosts
# ip addr

Could you also send me the output of the following command:
# cman_tool status
# cman_tool nodes

Thanks,

Mark


On Wednesday 01 July 2009 14:16:04 Stefano Elmopi wrote:
> Hi,
>
> I am happening a strange thing. I created a cluster with two nodes,
> clu01 and clu02,
> with the Shared-Root on a SAN. The node clu01 has the IP address
> 10.43.100.203
>
> <clusternode name="clu01" votes="1" nodeid="1">
>    <com_info>
>      <syslog name="clu01"/>
>      <rootvolume name="/dev/sda2" fstype="ocfs2"/>
>      <eth name="eth0" ip="10.43.100.203" mac="00:15:60:56:75:FD"/>
>      <fenceackserver user="root" passwd="test123"/>
>    </com_info>
> </clusternode>
>
> I also configured the service Httpd on the cluster and everything
> worked well.
> I had to change IP address (10.43.105.10) to the node_1 and so I
> preferred to do the procedure again,
> formatting the Shared-Root but not the server clu01.
> The cluster starts with the new IP address and when I am starting
> rgmanager:
>
> /etc/init.d/rgmanager strat
>
> everything seems ok
> but in the log file I read:
>
> Jun 27 10:13:14 clu01 kernel: dlm: Using TCP for communications
> Jun 27 10:13:14 clu01 kernel: dlm: Can't create listening comms socket
> Jun 27 10:13:14 clu01 kernel: dlm: cannot start dlm lowcomms -98
>
> and the output of command :
>
> clustat
> Cluster Status for cluOCFS2 @ Wed Jul  1 13:35:10 2009
> Member Status: Quorate
>
>   Member Name                                                     ID
> Status
>   ------ ----                                                     ----
> ------
>   clu01
> 1 Online, Local
>   clu02
> 2 Offline
>
>
> missing part on the service.
> if I try to make the restart of rgmanager, the log is:
>
> Jun 28 04:02:08 clu01 syslogd 1.4.1: restart.
> Jul  1 13:37:31 clu01 kernel: dlm: Using TCP for communications
> Jul  1 13:37:31 clu01 kernel: dlm: Can't create listening comms socket
> Jul  1 13:37:41 clu01 kernel: BUG: soft lockup - CPU#0 stuck for 10s!
> [clurgmgrd:13230]
> Jul  1 13:37:41 clu01 kernel:
> Jul  1 13:37:41 clu01 kernel: Pid: 13230, comm:            clurgmgrd
> Jul  1 13:37:41 clu01 kernel: EIP: 0060:[<c0608d90>] CPU: 0
> Jul  1 13:37:41 clu01 kernel: EIP is at _spin_lock+0x7/0xf
> Jul  1 13:37:41 clu01 kernel:  EFLAGS: 00000286    Tainted: G
> (2.6.18-92.1.22.el5PAE #1)
> Jul  1 13:37:41 clu01 kernel: EAX: f1d93a98 EBX: f1d93a94 ECX:
> 00000000 EDX: e1958000
> Jul  1 13:37:41 clu01 kernel: ESI: f1d93a94 EDI: f1e31000 EBP:
> e1958ebc DS: 007b ES: 007b
> Jul  1 13:37:41 clu01 kernel: CR0: 8005003b CR2: b7f48000 CR3:
> 37caef00 CR4: 000006f0
> Jul  1 13:37:41 clu01 kernel:  [<c06080ef>] __mutex_lock_slowpath
> +0x19/0x7c
> Jul  1 13:37:41 clu01 kernel:  [<c0608161>] .text.lock.mutex+0xf/0x14
> Jul  1 13:37:41 clu01 kernel:  [<f8c2ff6b>] close_connection+0x11/0x5a
> [dlm]
> Jul  1 13:37:41 clu01 kernel:  [<f8c308fd>] dlm_lowcomms_start+0x53e/
> 0x59c [dlm]
> Jul  1 13:37:41 clu01 kernel:  [<c06076a4>] schedule+0x920/0x9cd
> Jul  1 13:37:41 clu01 kernel:  [<f8c2e879>] dlm_new_lockspace
> +0x87/0x742 [dlm]
> Jul  1 13:37:41 clu01 kernel:  [<f8c33d38>] device_write+0x310/0x4b6
> [dlm]
> Jul  1 13:37:41 clu01 kernel:  [<f8c33a28>] device_write+0x0/0x4b6 [dlm]
> Jul  1 13:37:41 clu01 kernel:  [<c0470283>] vfs_write+0xa1/0x143
> Jul  1 13:37:41 clu01 kernel:  [<c0470875>] sys_write+0x3c/0x63
> Jul  1 13:37:41 clu01 kernel:  [<c0404eff>] syscall_call+0x7/0xb
> Jul  1 13:37:41 clu01 kernel:  =======================
>
>
>
> if I change the file cluster.conf, put back the old IP (10.43.100.203)
> and create a new initrd,
> rgmanager works well.
> This happens even with the same IP subnet 10.43.100, in practice it
> seems that it works only
> with the single IP address with which it was originally created the
> cluster !
>
>
> Thanks.
>
>
>
> Ing. Stefano Elmopi
> Gruppo Darco - Area ICT Sistemi
> Via Ostiense 131/L Corpo B, 00154 Roma
>
> cell. 3466147165
> tel.  0657060500
> email:ste...@so...

[OSR-users] Problem with rgmanager

[Stefano E. <ste...@so...>]

Hi,

I am happening a strange thing. I created a cluster with two nodes,  
clu01 and clu02,
with the Shared-Root on a SAN. The node clu01 has the IP address  
10.43.100.203

<clusternode name="clu01" votes="1" nodeid="1">
   <com_info>
     <syslog name="clu01"/>
     <rootvolume name="/dev/sda2" fstype="ocfs2"/>
     <eth name="eth0" ip="10.43.100.203" mac="00:15:60:56:75:FD"/>
     <fenceackserver user="root" passwd="test123"/>
   </com_info>
</clusternode>

I also configured the service Httpd on the cluster and everything  
worked well.
I had to change IP address (10.43.105.10) to the node_1 and so I  
preferred to do the procedure again,
formatting the Shared-Root but not the server clu01.
The cluster starts with the new IP address and when I am starting  
rgmanager:

/etc/init.d/rgmanager strat

everything seems ok
but in the log file I read:

Jun 27 10:13:14 clu01 kernel: dlm: Using TCP for communications
Jun 27 10:13:14 clu01 kernel: dlm: Can't create listening comms socket
Jun 27 10:13:14 clu01 kernel: dlm: cannot start dlm lowcomms -98

and the output of command :

clustat
Cluster Status for cluOCFS2 @ Wed Jul  1 13:35:10 2009
Member Status: Quorate

  Member Name                                                     ID    
Status
  ------ ----                                                     ----  
------
  clu01                                                                
1 Online, Local
  clu02                                                                
2 Offline


missing part on the service.
if I try to make the restart of rgmanager, the log is:

Jun 28 04:02:08 clu01 syslogd 1.4.1: restart.
Jul  1 13:37:31 clu01 kernel: dlm: Using TCP for communications
Jul  1 13:37:31 clu01 kernel: dlm: Can't create listening comms socket
Jul  1 13:37:41 clu01 kernel: BUG: soft lockup - CPU#0 stuck for 10s!  
[clurgmgrd:13230]
Jul  1 13:37:41 clu01 kernel:
Jul  1 13:37:41 clu01 kernel: Pid: 13230, comm:            clurgmgrd
Jul  1 13:37:41 clu01 kernel: EIP: 0060:[<c0608d90>] CPU: 0
Jul  1 13:37:41 clu01 kernel: EIP is at _spin_lock+0x7/0xf
Jul  1 13:37:41 clu01 kernel:  EFLAGS: 00000286    Tainted: G        
(2.6.18-92.1.22.el5PAE #1)
Jul  1 13:37:41 clu01 kernel: EAX: f1d93a98 EBX: f1d93a94 ECX:  
00000000 EDX: e1958000
Jul  1 13:37:41 clu01 kernel: ESI: f1d93a94 EDI: f1e31000 EBP:  
e1958ebc DS: 007b ES: 007b
Jul  1 13:37:41 clu01 kernel: CR0: 8005003b CR2: b7f48000 CR3:  
37caef00 CR4: 000006f0
Jul  1 13:37:41 clu01 kernel:  [<c06080ef>] __mutex_lock_slowpath 
+0x19/0x7c
Jul  1 13:37:41 clu01 kernel:  [<c0608161>] .text.lock.mutex+0xf/0x14
Jul  1 13:37:41 clu01 kernel:  [<f8c2ff6b>] close_connection+0x11/0x5a  
[dlm]
Jul  1 13:37:41 clu01 kernel:  [<f8c308fd>] dlm_lowcomms_start+0x53e/ 
0x59c [dlm]
Jul  1 13:37:41 clu01 kernel:  [<c06076a4>] schedule+0x920/0x9cd
Jul  1 13:37:41 clu01 kernel:  [<f8c2e879>] dlm_new_lockspace 
+0x87/0x742 [dlm]
Jul  1 13:37:41 clu01 kernel:  [<f8c33d38>] device_write+0x310/0x4b6  
[dlm]
Jul  1 13:37:41 clu01 kernel:  [<f8c33a28>] device_write+0x0/0x4b6 [dlm]
Jul  1 13:37:41 clu01 kernel:  [<c0470283>] vfs_write+0xa1/0x143
Jul  1 13:37:41 clu01 kernel:  [<c0470875>] sys_write+0x3c/0x63
Jul  1 13:37:41 clu01 kernel:  [<c0404eff>] syscall_call+0x7/0xb
Jul  1 13:37:41 clu01 kernel:  =======================



if I change the file cluster.conf, put back the old IP (10.43.100.203)  
and create a new initrd,
rgmanager works well.
This happens even with the same IP subnet 10.43.100, in practice it  
seems that it works only
with the single IP address with which it was originally created the  
cluster !


Thanks.



Ing. Stefano Elmopi
Gruppo Darco - Area ICT Sistemi
Via Ostiense 131/L Corpo B, 00154 Roma

cell. 3466147165
tel.  0657060500
email:ste...@so...

[OSR-users] New Productive Version 4.5

[Mark H. <hla...@at...>]

Hi !!

The open-sharedroot project is proud to announce the general availability of 
the comoonics 4.5 productive version ! With this release, the project reached 
a major milestone and we want to thank and congratulate all participants in 
the project for this great success !!  

The latest release of the comoonics 4.5 beta has passed our strict quality 
assurance process and we are proud to announce the release of the cluster 
software comoonics 4.5!!

comoonics 4.5 includes the following major enhancements:

 * Improved boot-time configuration. Configure the cluster node during boot 
time.
 * Improved hardware detection and configuration.
 * Enhanced cluster lifecycle. Boot the same OS installation in different 
(virt-)hardware configurations.
 * Lite initrds to reduce the size of initrds by 50%
 * Update existing initrds without the need to newly build them
 * The same initrd can be used to boot multiple different kernels

The open-sharedroot project now adds support for the following technologies:
 * NFS3/NFS4
 * OCFS2
 * Ext3 (single node)

Mark