Hi List,
We have bare metal systems that have no network at boot/install time (LACP
without fallback is used and we could not find any way to do PXE or DHCP at
boot time).
So we decided to use Uyuni integrated cobbler to create a bootable ISO for
installation:
#cobbler buildiso --distro=k8s-nodes-test:1:itmw-oss --airgapped
--iso=/data/install_test_nodes_01_bios.iso
--source=/var/autoinstall/SLE-15-SP2
We were able to boot from that image after switching from UEFI to legacy
BIOS boot style.
Autoyast starts but throws this errors:
"could not set patterns: enhanced_base"
"These packages cannot be found in the software repositories:
autoyast2: The package is not available
autoyast2-installation: The package is not available
chrony-pool-empty: The package is not available
tuned: The package is not available"
And finally dies with: "... nothing provides /bin/sh needed by
product:SLES-15.2..."
I checked content of my ISO image and think it looks good, can also find
the missing rpm files there:
# find ./|grep -e chrony-pool-empty -e tuned -e bash-[0-9]
./Module-Server-Applications/noarch/tuned-2.10.0-11.3.2.noarch.rpm
./Module-Basesystem/noarch/chrony-pool-empty-3.2-9.12.1.noarch.rpm
./Module-Basesystem/x86_64/bash-4.4-9.10.1.x86_64.rpm
I implemented it on a test system and was also able to find the rpms
autoyast is missing.
Why can't autoyast find these files? Must i reference them in my xml, in
add-on section? If so, how?
How can i create a bootable iso to install with autoyast without having a
network connection?
Or is there an easy way to create a boot iso that can activate LACP and
then do a network install?
Thanks,
Heiner
Dear Uyuni community,
I'm happy to let you know that we've release the Uyuni Contrib
repository [0].
Uyuni Contrib contains tools that are not part of the core Uyuni system,
mainly because they address a limited audience or are too experimental
to be part of the main repository. This does not preclude their
usefulness. So please use them with caution!
Uyuni Contrib has currently two folder:
* hubtools: Tools to install and configure SUSE Manager Hub.
* uyuni-tools: Collection of useful Uyuni Tools.
In order to use the tools with your Uyuni installation, you can simply
download and extract the ZIP file [1] from GitHub to, for example, /opt.
You Uyuni installation should have all dependencies needed to run all
the tools.
For more information, please check the corresponding README files:
* https://github.com/uyuni-project/contrib/blob/main/README.md
* https://github.com/uyuni-project/contrib/blob/main/hubtools/README.md
* https://github.com/uyuni-project/contrib/blob/main/uyuni-tools/README.md
Happy hacking!
Jochen
[0] https://github.com/uyuni-project/contrib/
[1] https://github.com/uyuni-project/contrib/archive/refs/heads/main.zip
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5
90409 Nuremberg
Germany
(HRB 36809, AG Nürnberg)
Managing Director: Felix Imendörffer
Hello,
We've been in contact with our Suse Account Team after evaluating and getting a Suma subscription to show our support.
First, congrats, the product seems pretty stable, usability is high (GUI is very reactive), it is well-integrated with Saltstack while at the same time providing interfaces for customization.
Concerning potential feedback and enhancement requests they told us to come here. So here is my current list:
* VERY DANGEROUS: Using groups: It is not clear from the system view that a state/config channel is applied to a system via a group.
If a system is managed through a group, that should be made clear on the Systems > system > Configuration > Overview screen and also Systems > system > States > Configuration Channels screen of that individual system. This is _very_ dangerous because applying a highstate might do unexpected things since the system is mostly invisibly part of a group.
In the same way, Configuration > Channels > channel > Systems does not show that the currently selected channel applies to any group (or a list of systems expanded from the group, for that matter).
It looks like groups were retrofitted, this really needs to be cleaned up.
* System shows ok (up-to-date) if product does not exist at all.
If you add a system for which the product is not mirrored to Suma at all, the "Updates" column of System List shows a green checkmark while the "base repo" column shows "(none)". The green checkmark is misleading, at most there should be a grey icon or so meaning that there is actually no info.
* System shows ok if there are non-compliant packages.
A green checkmark appears in System List if system contains non-compliant packages (Systems > system > Software > Packages > Non Compliant). The system list could somehow reflect the presence of non-compliant packages. These could for example pose a security risk.
* Very old OS release shows as ok/up-to-date.
For example, a fully patched SLES11-SP1 is shown with a green checkmark. Technically, this information therefore correct. However, in reality, the OS has been end-of-life for several years. It should show something other than the green checkmark which is creating a false belief that the system is ok while it should be replaced.
Certainly it would not be impossible to look at for example the release date of the latest patch. If it's too old, there can be a warning.
* In general, the system list/overview page could provide an even more holistic view by making more distinctions in the "Updates" column (or adding another "Status" perhaps)
- Show a warning for very old OS (see above)
- Show a warning if system contains non-compliant packages (see above)
- Show a warning if product does not exist at all (instead of green, see above)
- Reboot required could be shown in that same list (like after an SP migration)
- State apply failures could also reflect in that list
* Suma bootstrapping does not recognize enabled modules/products
If the system being onboarded was previously registered to SCC, SMT or RMT, the previously enabled modules (for example SDK or Web-Scripting-Module etc.) are not automatically activated, even if Suma has correctly mirrored them. Instead, you have to compare which modules were used previously and perform manual actions to add them again.
Probably this is not fixable, still it was something that caught our attention.
* Software Channel Management
Software > Manage > Channels page could show the sync policy for the individual channels. Currently there is no overview of the sync policies of the individual channels. You have to click on each one, open it and take a look.
Best regards,
J-M Roth
