[Spacewalk-list] RHEL 8 AppStream repo on Spacewalk 2.9
Hi all, I have created a RHEL 8 distribution with the following parameters: Label: rhel-8.0-release-x86_64-dvd Tree Path: /path/to/rhel-server-8.0-x86_64 Installer Generation: Red Hat Enterprise Linux 8 Directly under /path/to/rhel-server-8.0-x86_64 I have the RHEL 8 DVD content: AppStream EULA images RPM-GPG-KEY-redhat-beta BaseOS extra_files.json isolinux RPM-GPG-KEY-redhat-release EFI GPL media.repo TRANS.TBL I created a RHEL 8 profile using a RHEL 8 base channel and selecting the following: Available Trees: rhel-8.0-release-x86_64-dvd The generated kickstart contains the following: url --url http://spacewalk/ks/dist/org/2/rhel-8.0-release-x86_64-dvd repo --name=AppStream --baseurl=http://spacewalk/ks/dist/org/2/rhel-8.0-release-x86_64-dvd A client using the generated kickstart file fails because the AppStream repository appears to be incorrect. If I manually modify the repo line in /var/lib/rhn/kickstarts/wizard/rhel-8_0-x86_64-dvd--2.cfg as follows then the installer will complete: repo --name=AppStream --baseurl=http://spacewalk/ks/dist/org/2/rhel-8.0-release-x86_64-dvd/AppStream I've not defined 'AppStream' in any configuration areas, so I presume Spacewalk is generating this automatically. Any idea why it might be generating an invalid URL? Many thanks, Richard. ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Oracle 12/ 18 Database Support
On Thursday, May 2, 2019, 8:53:16 PM GMT+1, Avi Miller wrote: Hey Richard, > On 2 May 2019, at 7:01 pm, Richard wrote: > > My DBA tells me we are running in Oracle 11.2.0 compatibility mode (Database > Upgrade Guide). Is there any reason we should not move to Oracle 18.6.0 > compatibility ? None that I can think of. Our plan is to complete testing of Spacewalk 2.9 with the latest Oracle Instant Client 18c (which is available from yum.oracle.com with no click-through license any more[1]) and then push the spec file changes to shift to this client upstream. The updated Instant Client will work with all DB versions from 11gR2 all the way up to 19c. However, I don’t have an ETA on the completion of this testing yet. Our suite has to run across three database versions with the server on two major versions of the distro and two architectures for one of those versions, so it can take weeks to complete. :) Thanks, Avi [1] http://yum.oracle.com/repo/OracleLinux/OL7/oracle/instantclient/x86_64/index.html --- Hi Avi, By way of an update in case this is useful for you or anyone else. We were running Spacewalk 2.8 with Oracle 18.0.0. We upgraded to Spacewalk 2.9. The following error was generated when upgrading the database: # spacewalk-setup --external-oracle --upgrade* Setting up Oracle environment.* Setting up database.** Database: Setting up database connection for Oracle backend.Global Database Name or SID (requires tnsnames.ora)? X Username? X Password?Could not connect to the database. Your connection information may be incorrect. Error: Version [18.0.0] is not supported (does not match 12.2.0, 12.1.0, 11.2.0, 11.1.0, 10.2.0). As we'd discussed on this thread that Oracle 18 should work, I modified the /usr/share/perl5/vendor_perl/Spacewalk file and adjusted the allowed_db_versions list to make it read: my @allowed_db_versions = qw/18.0.0 12.2.0 12.1.0 11.2.0 11.1.0 10.2.0/; This allowed the installer to complete successfully and Spacewalk seems to be performing correctly. Richard. ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Oracle 12/ 18 Database Support
Hi Avi, On Wednesday, April 24, 2019, 9:46:47 PM GMT+1, Avi Miller wrote: > Spacewalk works fine with Oracle Database 11, 12, 18 and 19. Our upcoming > release of Spacewalk 2.9 is planned to be rebased (for want of a better word) > to the Oracle 18c Instant Client as well. > In the interim, the 11gR2 Instant Client that is required by the upstream > Spacewalk RPMs will connect just fine to newer database versions. > Let me know if you have any issues. Just a quick update in case this is of use. This morning we upgraded our database from 11.2.0.4 to Oracle 18.0.6. We continue to run Spacewalk 2.8, but will upgrade to Spacewalk 2.9 shortly. We had ORACLE_HOME defined in a couple of places which needed adjusting to point to the new Oracle release location: /root/.bash_profile /etc/sysconfig/osa-dispatcher /etc/rhn/cluster.ini After correcting these entries, Spacewalk started successfully. My DBA tells me we are running in Oracle 11.2.0 compatibility mode (Database Upgrade Guide). Is there any reason we should not move to Oracle 18.6.0 compatibility ? Richard. | | | | Database Upgrade Guide If new features are incompatible with your earlier release, then Database compatibility can cause issues. | | | ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
[Spacewalk-list] Oracle 12/ 18 Database Support
Hi there, We are currently running Spacewalk 2.8 with Oracle 11.2.0.4 We plan to upgrade to Spacewalk 2.9 shortly, but before we do we're considering updating Oracle to one of the following: 12.1.0.2 12.2.0.218 I found an old posting at Re: [Spacewalk-list] Connect Spacewalk (2.2) to Oracle 12.1 database where someone had success with Oracle 12.1 and I think the Oracle 11 Instant Client 11.2.0.4.0 is compatible with version 18. | | | | Re: [Spacewalk-list] Connect Spacewalk (2.2) to Oracle 12.1 database | | | Is anyone running Spacewalk using any of the above database versions? Richard. ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
[Spacewalk-list] unable to download repositories
Hi All Did an install of Spacewalk 2.6 onto RHEL 7.3 server. All installed and configured. I created a base channel for rhel-7-server-rpms and I have been unsuccessful in trying to sync repository. If I try to list channels with 'spacewalk-channel -l' I get the error Unable to locate SystemId file. Is this system registered? The SystemId file no longer exists with the demise of RHN - it is using RHSM. If I try with 'spacewalk-channel -L', enter the credentials for the spacewalk server and the return is rhn-plugin: Error communicating with the server. The message was : Name or service not known. If I try with 'satellite-sync -list-channels' I get the error of Spacewalk - live synchronization ERROR: Can't use live synchronization from RHN. This is not supported. If I try 'satellite-sync -c ' I get the error of Spacewalk - live synchronization ERROR: Can't use live synchronization from RHN. This is not supported. The spacewalk server is registered and subscribed to Red Hat Enterprise Linux Server with Smart Management, Premium & Red Hat Satellite. What gives? How can I sync the repositories? Many thanks Rick Garland The Denver Health email system has made the following annotations -CONFIDENTIALITY NOTICE - This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain information that is confidential or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify the sender by telephone or return e-mail and delete the original transmission and its attachments without reading or saving in any manner. Thank you. ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
[Spacewalk-list] Fwd: Can't get clients to register... Internal Server Error
Hello.
Just stood up a CentOS 6.4 box with Spacewalk 2.0. Was able to get one
client registered, but all subsequent hosts can't get registered.
When I run rhnreg_ks from the client, this is what I see:
[root@bugs ~]# rhnreg_ks
--serverUrl=http://spiff.royalhighness.org/XMLRPC--activationkey=1-centos6-x86_64
-
D: rpcServer: Calling XMLRPC registration.welcome_message
D: opening db environment /var/lib/rpm cdb:mpool:joinenv
D: opening db index /var/lib/rpm/Packages rdonly mode=0x0
D: locked db index /var/lib/rpm/Packages
D: loading keyring from pubkeys in /var/lib/rpm/pubkeys/*.key
D: couldn't find any keys in /var/lib/rpm/pubkeys/*.key
D: loading keyring from rpmdb
D: opening db index /var/lib/rpm/Name rdonly mode=0x0
D: added key gpg-pubkey-c105b9de-4e0fd3a3 to keyring
D: added key gpg-pubkey-6b8d79e6-3f49313d to keyring
D: added key gpg-pubkey-863a853d-4f55f54d to keyring
D: added key gpg-pubkey-0608b895-4bd22942 to keyring
D: Using legacy gpg-pubkey(s) from rpmdb
D: rpcServer: Calling XMLRPC registration.welcome_message
D: opening db index /var/lib/rpm/Providename rdonly mode=0x0
D: rpcServer: Calling XMLRPC registration.new_system
A protocol error occurred: Internal Server Error , attempt #1,
Error communicating with server. The message was:
Internal Server Error
D: closed db index /var/lib/rpm/Providename
D: closed db index /var/lib/rpm/Name
D: closed db index /var/lib/rpm/Packages
D: closed db environment /var/lib/rpm
[root@bugs ~]#
On the server, I see this in /var/log/rhn/rhn_server_xmlrpc.log:
2013/10/17 08:34:29 -07:00 1713 192.168.100.24:
xmlrpc/registration.welcome_message('lang: None',)
2013/10/17 08:34:30 -07:00 1712 192.168.100.24:
xmlrpc/registration.welcome_message('lang: None',)
2013/10/17 08:34:30 -07:00 1718 192.168.100.24:
xmlrpc/registration.create_system(token = '1-centos6-x86_64', '6',
'x86_64')
Is there something obvious that I'm missing?
Thanks for any help you can give me on this.
http://pastebin.com/CmabZWzM
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Running Spacewalk on RHEL 5 / CentOS 5
On 25/03/13 14:57, Cliff Perry wrote: Hi folks, today we provide Spacewalk releases on EL5, EL6, and current Fedora versions. Due to the increasing differences of EL5 vs. the newest OSes, we are seriously considering not releasing Spacewalk on EL5 anymore, since it hinders our ability to do some other forward-looking changes we would like to do. If we make the current Spacewalk 1.9 the last release on EL5, will Spacewalk users find it hard to migrate to EL6? Feedback is appreciated and will be taken into consideration for how quickly we make this change. is this just talking about the server side, rather than clients? currently running spacewalk server on el5/32 bit (making use of old hardware), and all works well. if 1.9 were to be the last el5 release, it wouldn't be too much of a pain - we would just stick on this version until able to migrate the server to el6/64, which we should be able to do without too much trouble, though we may get a release or two behind before we have time to do the upgrade. again, not really a worry. as for client side, we will have some (quite a few) el5 clients for a while yet, so it would be nice if these could continue to be managed by spacewalk. hope that's of some use. thanks, richard ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Restoring Spacewalk works fine then Cannot retrieve repository metadata
On 18/04/12 11:49, Ludovic BRACHET wrote: I just do a restore of Spacewalk, everything works again, but when I do a “yum clean all yum update” I have: Error: Cannot retrieve repository metadata (repomd.xml) for repository: epel-x86_64-el5. Please verify its path and try again I try on many servers and I received the same error: do you know how to debug that? hi ludovic, do you have a repomd.xml file in your /var/cache/rhn/repodata/epel-x86_64-el5 directory? taskomatic (i *think* it's taskomatic...) should create these files/update them when the packages in a channel change. thanks, richard ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] centos-errata.py and announcement list format changes
On 18/01/12 18:54, David Nutter wrote: On Wed, Jan 04, 2012 at 08:54:16PM +, David Nutter wrote: Hi folks, As some of you may have noticed the format of the centos-announce messages has changed, thus breaking my script that creates errata for them (http://www.bioss.ac.uk/staff/davidn/spacewalk-stuff/) I am working on a fix but unfortunately the changes required are fairly involved so it may be a day or two before I have a release ready and tested. Apologies for any inconvenience you may experience in the meantime. Hi folks, A new release is now available (finally): http://www.bioss.ac.uk/staff/davidn/spacewalk-stuff/ Due to format changes in the centos-announce mailing lists, the parsing logic has been completely rewritten. It's still horrible though :) Also, you will now have to use the dir package search strategy as the other two strategies spacewalk and satellitedir both rely on obtaining the md5sum from the centos-announce mailings. Since upstream now sends sha256 checksums these techniques can't work. I note with interest various discussions on the CentOS lists about making errata available in a more useful form. Hopefully my script won't be required for too much longer. Regards, hi david, excellent work - have just downloaded and updated, and all seems to be working well again, thanks for your efforts. i noticed there is a new requirement for python-lxml, which we didn't have installed, but all is now back up and running. thanks again, richard ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Taskomatic error after upgrade to Spacewalk 1.2
-Original Message- From: spacewalk-list-boun...@redhat.com [mailto:spacewalk-list- boun...@redhat.com] On Behalf Of Rudd, Richard Sent: 03 February 2011 17:16 To: spacewalk-list@redhat.com Subject: [Spacewalk-list] Taskomatic error after upgrade to Spacewalk 1.2 Hi, I upgraded our Spacewalk installation to version 1.2 today and I'm now seeing the error below in the rhn_taskomatic_daemon.log every 2 minutes. Does anyone have any idea how to fix it? I didn't see any errors during the upgrade process, although we are using an Oracle 11g database so I've had to change some of the environment settings to make Spacewalk work with this. Doing a select on the QRTZ_FIRED_TRIGGERS table shows no rows. SQL select * from QRTZ_FIRED_TRIGGERS; no rows selected SQL INFO | jvm 1| 2011/02/03 16:54:47 | 2011-02-03 16:54:47,451 [DefaultQuartzScheduler_QuartzSchedulerThread] ERROR org.quartz.core.ErrorLogger - An error occured while scanning for the next trigger to fire. INFO | jvm 1| 2011/02/03 16:54:47 | org.quartz.JobPersistenceException: Couldn't acquire next trigger: ORA-01400: cannot insert NULL into (SPACEWALK.QRTZ_FIRED_TRIGGERS.PRIORITY) INFO | jvm 1| 2011/02/03 16:54:47 | [See nested exception: java.sql.SQLIntegrityConstraintViolationException: ORA-01400: cannot insert NULL into (SPACEWALK.QRTZ_FIRED_TRIGGERS.PRIORITY) INFO | jvm 1| 2011/02/03 16:54:47 | ] INFO | jvm 1| 2011/02/03 16:54:47 | at org.quartz.impl.jdbcjobstore.JobStoreSupport.acquireNextTrigger(JobStoreSuppor t.java:1778) INFO | jvm 1| 2011/02/03 16:54:47 | at org.quartz.impl.jdbcjobstore.JobStoreTX.acquireNextTrigger(JobStoreTX.java:121 8) INFO | jvm 1| 2011/02/03 16:54:47 | at org.quartz.core.QuartzSchedulerThread.run(QuartzSchedulerThread.java:233) INFO | jvm 1| 2011/02/03 16:54:47 | * Nested Exception (Underlying Cause) --- INFO | jvm 1| 2011/02/03 16:54:47 | java.sql.SQLIntegrityConstraintViolationException: ORA-01400: cannot insert NULL into (SPACEWALK.QRTZ_FIRED_TRIGGERS.PRIORITY) INFO | jvm 1| 2011/02/03 16:54:47 | INFO | jvm 1| 2011/02/03 16:54:47 | at oracle.jdbc.driver.T2CConnection.checkError(T2CConnection.java:737) INFO | jvm 1| 2011/02/03 16:54:47 | at oracle.jdbc.driver.T2CConnection.checkError(T2CConnection.java:647) INFO | jvm 1| 2011/02/03 16:54:47 | at oracle.jdbc.driver.T2CPreparedStatement.executeForDescribe(T2CPreparedStatemen t.java:530) INFO | jvm 1| 2011/02/03 16:54:47 | at oracle.jdbc.driver.T2CPreparedStatement.executeForRows(T2CPreparedStatement.ja va:713) INFO | jvm 1| 2011/02/03 16:54:47 | at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1 307) INFO | jvm 1| 2011/02/03 16:54:47 | at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedState ment.java:3449) INFO | jvm 1| 2011/02/03 16:54:47 | at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStateme nt.java:3530) INFO | jvm 1| 2011/02/03 16:54:47 | at oracle.jdbc.driver.OraclePreparedStatementWrapper.executeUpdate(OraclePrepared StatementWrapper.java:1350) INFO | jvm 1| 2011/02/03 16:54:47 | at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPr eparedStatement.java:101) INFO | jvm 1| 2011/02/03 16:54:47 | at org.quartz.impl.jdbcjobstore.StdJDBCDelegate.insertFiredTrigger(StdJDBCDelegat e.java:3360) INFO | jvm 1| 2011/02/03 16:54:47 | at org.quartz.impl.jdbcjobstore.JobStoreSupport.acquireNextTrigger(JobStoreSuppor t.java:1771) INFO | jvm 1| 2011/02/03 16:54:47 | at org.quartz.impl.jdbcjobstore.JobStoreTX.acquireNextTrigger(JobStoreTX.java:121 8) INFO | jvm 1| 2011/02/03 16:54:47 | at org.quartz.core.QuartzSchedulerThread.run(QuartzSchedulerThread.java:233) Regards, Richard Rudd Systems Developer Exeter IT, Academic Services University of Exeter, EX4 4QE, UK ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list Just an update to this issue. I removed the NOT NULL constraint on the QRTZ_FIRED_TRIGGERS.PRIORITY field in the database and this appears to have fixed the issue. However I'm not sure what else this might break? Regards, Richard Rudd Systems Developer Exeter IT, Academic Services University of Exeter, EX4 4QE, UK ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Need help to troubleshoot osa-dispatcher problem.
i can't offer much help at the moment, i'm afraid, but can say that i am seeing
exactly the same behaviour.
we just upgraded to 1.2 a couple of days ago.
everything was working correctly in 1.1, but since the upgrade, the
osa-dispatcher fails to run correctly in the manner described below.
haven't had much time to delve into it just yet, but have tried the suggestions
mentioned.
any advice on what else may be worth tying would me much appreciated.
thanks,
richard
From: spacewalk-list-boun...@redhat.com
[mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Ron Helzer
Sent: 09 December 2010 06:41
To: spacewalk-list@redhat.com
Subject: [Spacewalk-list] Need help to troubleshoot osa-dispatcher problem.
After upgrading from Spacewalk 1.1 to 1.2; osa-dispatcher seems to have quit
working. I have exhausted my troubleshooting skills and have been unable to
determine the cause.
What works:
client OSA Status is online
OSA Ping System works
What doesn't work:
Scheduling any action does not trigger the client's osad to invoke rhn_check
Package versions:
osa-dispatcher-5.9.44-1.el5
jabberd-2.2.11-2.el5
spacewalk-setup-jabberd-1.3.1-1.el5
I have followed the instructions at
https://www.redhat.com/archives/spacewalk-list/2010-November/msg00181.html to
update the jabberd configuration. Also tried some of the suggestions offered in
https://www.redhat.com/archives/spacewalk-list/2010-November/msg00173.html to
no avail.
Results of `tail -f /var/log/rhn/osa-dispatcher.log | grep osa_dispatcher`
2010/12/09 01:28:17 -04:00 13878 0.0.0.0http://0.0.0.0:
osad/osa_dispatcher.process_once
2010/12/09 01:28:17 -04:00 13878 0.0.0.0http://0.0.0.0:
osad/osa_dispatcher.process_once('Clients to be pinged:', None)
2010/12/09 01:28:17 -04:00 13878 0.0.0.0http://0.0.0.0:
osad/osa_dispatcher.process_once('before process',)
2010/12/09 01:28:17 -04:00 13878 0.0.0.0http://0.0.0.0:
osad/osa_dispatcher.process_once('after process',)
2010/12/09 01:28:17 -04:00 13878 0.0.0.0http://0.0.0.0:
osad/osa_dispatcher.process_once('Not notifying jabber nodes',)
It's as if osa-dispatcher just doesn't see that there's a pending event it
should notify osad of...
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list
[Spacewalk-list] internal server error on 'add remote command to package install'
i have been seeing a problem since the update to 1.2, when scheduling a package install or removal, and using the 'add a remote command...' option. it is possible to enter the command, but when the 'confirm remote command..' is submitted, an internal server error is displayed. the traceback can be seen here: http://pastebin.com/xHbdHau8 scheduling a package removal/install without the remote command seems to work fine. let me know if i can provide any further information, etc. thanks, richard ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] after 1.2 update WEB TRACEBACK on remote command in SSM
patch applied, and problem fixed. thanks, richard -Original Message- From: spacewalk-list-boun...@redhat.com [mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Lukas Zapletal Sent: 09 December 2010 10:02 To: spacewalk-list@redhat.com Subject: Re: [Spacewalk-list] after 1.2 update WEB TRACEBACK on remote command in SSM On 12/09/2010 10:46 AM, Marco Giunta wrote: Is there any other patch available ??? Yes it is. You can find it on bugzilla. I can find it for you: https://bugzilla.redhat.com/show_bug.cgi?id=658250 Commit in the master: 3589dbc33ea667fc7e5d17ec5ee8e91eaeb0c8d4 Please inform us in this thread if you face this issue too. Thanks. -- Later, Lukas lzap Zapletal ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Kickstart Exception
I've also been trying to figure this one out, it seems there might be an issue with the kickstart file generation in spacewalk 1.1. I was able to get the kickstart working by manually editing the kickstart file in the /var/lib/rhn/kickstarts/wizard/ directory and amend the line before the certificate imports from: %post --logfile /mnt/sysimage/root/ks-rhn-post.log to be: %post --logfile /root/ks-rhn-post.log Unfortunately the kickstart file is recreated anytime a change is made so the above process is only a temporary fix. As I can't find where the kickstart file is generated from I can't make the change permanent! Regards, Richard -Original Message- From: spacewalk-list-boun...@redhat.com [mailto:spacewalk-list- boun...@redhat.com] On Behalf Of James Hogarth Sent: 06 September 2010 14:54 To: spacewalk-list@redhat.com Subject: [Spacewalk-list] Kickstart Exception Hey all, Hope someone has an idea on this as I'm starting to run out of them to try This is from a spacewalk 1.1 server trying to install centos 5 x86_64 with the updates and extras repos enabled. At this point I have no user pre/post scripts at all Traceback (most recent call first): File /tmp/treedir.27146/instimage/usr/lib/anaconda/iutil.py, line 45, in execWithRedirect stdout = open(stdout, w) File /usr/lib/anaconda/kickstart.py, line 75, in run root = scriptRoot) File /usr/lib/anaconda/kickstart.py, line 901, in lambda map (lambda s: s.run(anaconda.rootPath, serial, anaconda.intf), postScripts) File /usr/lib/anaconda/kickstart.py, line 901, in postAction map (lambda s: s.run(anaconda.rootPath, serial, anaconda.intf), postScripts) File /tmp/treedir.27146/instimage/usr/lib/anaconda/packages.py, line 44, in doPostAction anaconda.id.instClass.postAction(anaconda, flags.serial) File /usr/lib/anaconda/dispatch.py, line 204, in moveStep rc = stepFunc(self.anaconda) File /usr/lib/anaconda/dispatch.py, line 127, in gotoNext self.moveStep() File /usr/lib/anaconda/text.py, line 727, in run anaconda.dispatch.gotoNext() File /usr/bin/anaconda, line 974, in ? anaconda.intf.run(anaconda) IOError: [Errno 2] No such file or directory: '/mnt/sysimage//mnt/sysimage/root/ks-rhn-post.log' Local variables in innermost frame: searchPath: 0 stdout: /mnt/sysimage//mnt/sysimage/root/ks-rhn-post.log stdin: 0 argv: ['/tmp/ks-script-ugX7Or'] chroot: function chroot at 0xdc43f50 command: /bin/sh stderr: /mnt/sysimage//mnt/sysimage/root/ks-rhn-post.log root: /mnt/sysimage I've got the full anacdump and other logs here is anyone feels able to parse through them... James ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list smime.p7s Description: S/MIME cryptographic signature ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Is there a need for an announce mailing list?
On Wed, Dec 24, 2008 at 05:35, Jon Stanley jonstan...@gmail.com wrote: Is there any issue with this being @lists.fedorahosted.org? I actually have permissions to set that up if we want it there instead - I think the spacewalk-* belong there really, but that's a conversation for another day. I think they should all be on the same host. Other than than, I don't care either way. Richard ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Is there a need for an announce mailing list?
On Thu, Dec 18, 2008 at 21:50, Brandon Perkins bperk...@redhat.com wrote: Makes sense to me. I'll make it so (unless someone has a compelling reason not to). Thanks. Can you write email when it's set up? Richard ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
