apt/yum repository for waystation not automatically created:
During the std installation of a distribution, the conf files for yum/apt should be automatically updated to include the machine which has served during the deployment as a source repository for the core os.
It allows to just use apt/yum after installation to add missing packages e.g., or to solve dependencies vs an additional value added module.
Logged In: YES
user_id=1316443
Originator: NO
During image creation, System Designer will look in depots/apt-DIST-VER-ARCH and/or depots/yum-DIST-VER-ARCH and leave 'bread crumbs' for the post-install process. If these entries are found (/etc/opt/LinuxCOE/(apt||yum)/COE_BASE on client, the post install process will reconfigure apt/yum to point here for distribution specific binary and update trees. If these files are not found, the post install process only appends sources for any addons you have configured, leaving apt/yum pointing at whatever binary/update sources the distribution delivers as default values, which should be valid 'public' sources.
At least that's 'as planned', let me know if that's not happening.
Logged In: YES
user_id=87947
Originator: NO
here are some additional details:
1) for some reason, on this instance of SysDes, configure_yum was not being called on the target system, even tho all the supporting files were delivered and the patch_method was set to YUM. A manual invocation of the configure_yum script did what was expected, and then the modules would install.
2) before the above action, the retrofit script would say "Succeeded" for the bundle in question, but of course really couldn't install the bundle.
Found patch_method of YUM
It's yummy in here, apt depricated!
Attempting to install Mondorescue... consisting of RPM's mondo mindi mindi-busyb
ox afio buffer cdrecord
/usr/bin/yum -y install mondo mindi mindi-busybox afio buffer cdrecord
No Match for argument: mondo
No Match for argument: mindi
No Match for argument: mindi-busybox
No Match for argument: afio
No Match for argument: buffer
and the following packages were installed on the target host:
[root@localhost ~]# rpm -aq | grep linuxcoe
linuxcoe-yum-sources-4.0-0
linuxcoe-rhn-sources-3.1-2
linuxcoe-apt-sources-4.0-0
linuxcoe-sw-installer-4.0-0
linuxcoe-3.1-4
Logged In: YES
user_id=1316443
Originator: NO
Thx bryang, so there's 2 parts to this problem:
1) configure_yum didn't run
I'm at a loss here, that's tied into post_install of linuxcoe-yum-sources-4.0-0 RPM. Here's how it's built in EPM format:
%system all
%requires linuxcoe-sw-installer
%requires yum
%postinstall /usr/bin/perl /opt/LinuxCOE/bin/configure_yum
So *in theory*, if you installed this RPM, the script ran. Were you using the RPM I built or was it re-created? Today that script runs silent, if needed, I can add some debug/verification output in the script to throw at STDOUT when the rpm -i runs.
2) install_bundles thought it things were OK, but they were not
Yes, that's a bug, here's an example:
root@office:~# yum -y install obviously_broken_package
Setting up Install Process
Setting up repositories
No Repositories Available to Set Up
Reading repository metadata in from local files
Parsing package install arguments
No Match for argument: obviously_broken_package
Nothing to do
root@office:~# echo $?
0
root@office:~#
So, the yum install failed horribly, but yum exited with a happy error code. Darn it. I'm going to have to snag the output of yum and 'inspect' it in code to see if the operation was successful. That bites. I'll think on it some, maybe I can just zero in on looking for 'success', I'll have to do some trial and error with multiple packages.
Logged In: YES
user_id=87947
Originator: NO
ok, so re:
1) configure_yum prolly does run at install of linuxcoe-yum-sources, but if you happen to add a new bundle via retrofit (especially from another ?defs=), it would have to run again, right ?
2) could you simple loop thru packages spec'd in bundle and if rpm -q <pkg> are all okay, you are "good to go" ?