[sles-beta] SLES12 x86_64 RC2 autoyast post-script zypper unusable, application locked by y2base

urs.frey at post.ch urs.frey at post.ch
Wed Aug 27 05:54:36 MDT 2014


Hello Stefan

The way to add add-on product repositories is well known to me, thank you very much.

BUT: 
As I mentioned I am using puppet and a CMDB. 
So my puppet modules when running will make sure, the correct software package depending the configuration requirements will be installed.

So it is not the same as e.g:
Autoyast post-script = >zypper in -y apache2, or zypper in -y mypackage

It works this way

/usr/bin/puppet agent --server=vpup02.pnet.ch --masterport=8140 --environment=config_development -v --no-daemonize --onetime --http_compression --libdir=/var/lib/puppet/lib/config_development --color=false --show_diff


And within the puppet manifest we have:
==========================
class admin::mcollective( $p_mco_admins = [] ) {

  $mcollective_classesfile = '/var/lib/puppet/classes_config.txt'
  if ( $::operatingsystem == 'SLES' and $::is_in_postinstallscript == 'false' ) {
    if ( $::operatingsystemrelease >= 11 ) {
      package {'pst-rubygem-stomp':
        ensure => latest,
        notify => Service['mcollective'],
      } ->
      package {'pst-rubygem-sshkeyauth':
        ensure => latest,
        notify => Service['mcollective'],
      } ->
      package {'pst-mcollective-server':
        ensure => latest,
        notify => Service['mcollective'],
        alias  => 'mcollective-server',
      }
    } else {
      package {'pst-rubygem-sshkeyauth':
        ensure => installed,
        notify => Service['mcollective'],
      } ->
      package {'pst-mcollective-server':
        ensure => installed,
        notify => Service['mcollective'],
        alias  => 'mcollective-server',
      }
    }
    if ( $::architecture == 'x86_64' ) {
      if ( $::operatingsystemrelease >= 12 ) {
        $mcollective_libdir = '/usr/lib64/ruby/site_ruby/2.1.0/x86_64-linux-gnu/mcollective.plugins:/etc/mcollective/plugin.d'
      } else {
        $mcollective_libdir = '/usr/lib64/ruby/site_ruby/1.8/x86_64-linux/mcollective.plugins:/etc/mcollective/plugin.d'
      }
    } else {
      $mcollective_libdir = '/usr/lib/ruby/site_ruby/1.8/i586-linux/mcollective.plugins:/etc/mcollective/plugin.d'
    }


Best regards


Urs Frey                                              
Post CH AG
Informationstechnologie
IT Betrieb 
Webergutstrasse 12 
3030 Bern (Zollikofen) 
Telefon : ++41 (0)58 338 58 70 
FAX     : ++41 (0)58 667 30 07 
E-Mail:   urs.frey at post.ch


-----Ursprüngliche Nachricht-----
Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Stefan Schubert
Gesendet: Wednesday, August 27, 2014 12:56 PM
An: sles-beta at lists.suse.com
Betreff: Re: [sles-beta] SLES12 x86_64 RC2 autoyast post-script zypper unusable, application locked by y2base

Hi,
the normal way of installingadditional and customized packages in 
autoyast is defined
here: 
http://doc.opensuse.org/projects/autoyast/configuration.html#idm139795987981568

It seem that this way does not fit your requirements. OK, here is a 
really HACK.
Libzypp (which is used by zypper) just checks the file /var/run/zypp.pid 
in order
checking the lock. (which is blamed by zypper).
So you would only have to move this file to other position, call your 
zypper calls
and please move this file back after you have finished your zypper calls.
But as I have already said, this is REALLY a hack and should NOT be the 
normal way:-)

Greetings
Stefan Schubert


g155:/home/src/ISOs # cat /var/run/zypp.pid
13544
g155:/home/src/ISOs # ps aux|grep 13544
root     13544 14.6  5.9 878604 235540 pts/20  Sl+  12:40   0:10 
/usr/lib/YaST2/bin/y2base sw_single qt
root     14047  0.0  0.0   9264   928 pts/21   S+   12:41   0:00 grep 
--color=auto 13544



Am 27.08.2014 11:10, schrieb urs.frey at post.ch:
> Hi
> I am trying to install SLES12 x86_64 RC2 onto my testservers using 
> autoyast
> I have a bunch of package installations and configurations to do, 
> which are configured by puppet.
> During autoyast post-script phase zypper unfortunately is locked by 
> y2base process
> root       603     1  0 10:53 tty7     00:00:00 /bin/sh 
> /usr/lib/YaST2/startup/YaST2.Second-Stage
> root      4040   603  0 10:54 tty7     00:00:00 /bin/sh 
> /usr/lib/YaST2/startup/YaST2.call installation continue
> root      4742  4040 27 10:54 tty7     00:00:11 y2base installation 
> ("continue") ncurses
> root      7597  4742  0 10:54 tty7     00:00:00 [snapper.py] <defunct>
> root      9337  4742  0 10:54 tty7     00:00:00 y2base installation 
> ("continue") ncurses
> root      9338  9337  0 10:54 tty7     00:00:00 y2base installation 
> ("continue") ncurses
> root      9339  9338  0 10:54 tty7     00:00:00 sh -c /bin/sh -x 
> /var/adm/autoinstall/scripts/post-script.sh &> 
> /var/adm/autoinstall/logs/post-script.sh.log
> root      9340  9339  0 10:54 tty7     00:00:00 /bin/sh -x 
> /var/adm/autoinstall/scripts/post-script.sh
> root      9693  9340  0 10:54 tty7     00:00:00 ps -efww
> So when having a look at the processes together with y2base I quickly 
> get the intention, that the second stage of autoyast itself, showing 
> the ncurses screen is the y2base process. So killing of y2base would 
> not be a good idea to gain zypper access.
> So for me going back to RPM package installation to omit zypper 
> conflict within autoyast post-script is not an option.
> Moving the entire puppet configuration and OEM package installation to 
> autoyast init-script seems to be the only way.
> But autoyast init-script on the other hand does run in the background 
> while systemD  already opens the console login for root.
> Having console logins already enabled, while autoyast init-script is 
> still running is really not a good way.
> regards
> Urs Frey
> Post CH AG
> Informationstechnologie
> IT Betrieb
> Webergutstrasse 12
> 3030 Bern (Zollikofen)
> Telefon : ++41 (0)58 338 58 70
> FAX     : ++41 (0)58 667 30 07
> E-Mail: _urs.frey at post.ch_ <mailto:urs.frey at post.ch>
>
>
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta


-- 
*******************************************************************************
Stefan Schubert
e-mail: schubi at suse.de
-------------------------------------------------------------------------------
SUSE LINUX Products GmbH
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstraße 5
90409 Nürnberg
Germany

_______________________________________________
sles-beta mailing list
sles-beta at lists.suse.com
http://lists.suse.com/mailman/listinfo/sles-beta


More information about the sles-beta mailing list