I’m using combustion with microOS and the Self-Install ISO by mounting a combustion.vdi to my VM and everything is working fine to auto provision and boot into a configured system.
The issue is the install boot itself isn’t fully automated. Two manual interactions remain:
GRUB menu at first boot: The Self-Install ISO defaults to “Boot from hard disk” and waits for input. I have to arrow down and select “Install MicroOS” within the timeout window or the VM boots to the empty attached drive.
Target disk selection during install: After “Install MicroOS” runs, the installer prompts to choose which disk to install onto. The Combustion VHD shows up in this list alongside the empty OS disk. The OS disk is never the first option.
Is there a way to remaster the Self-Install ISO so that I can automate this?
VMs are UEFI with secure boot + vTPM
Hi, I’ve just been working on the same sort of thing… But I’m using Leap 16.0 Minimal install and libvirt… What virtualization are you using?
With virt-install I hook direct to the Combustion script so no need for another device via --sysinfo type=fwcfg,entry0.name="opt/org.opensuse.combustion/script",entry0.file="/data/development/kubernetes/libvirt_combustion/combustion/script"
@linuxuser3134 Hi, the other thought would be to try the Agama Installer and profiles , the agama-installer.x86_64-20+ series supports Tumbleweed (used it for my last Tumbleweed install), Slowroll and MicroOS?
@malcolmlewis Unrelated, what is the difference between leap micro and openSUSE microOS? Is it only the transactional-update and immutable nature of microOS that makes it different. (granted it’s a big difference) Is Leap also immutable?
I think I remember installing Leap because I accidently used Leap Micro instead of MicroOS and I thought they had some SSH option during the installation. Is that true? MicroOS doesn’t seem to have any option like that.
I’m using XEN w/ XCP-ng so I can’t do anything with QEMU. Gemini and the various other slop generators suggested a few things and specifically xorriso. Have you heard of this tool? It’s a tool to repackage files into a new bootable ISO? So, the idea being I can unpackage the ISO and then make the required grub modifications to point to these selection options automatically on first boot. I want to preserve my secure boot installation.
I really don’t want to move away from combustion either I like my current deployment structure and would rather not switch over. Agama would mean a different workflow, right?
Leap Micro follows Leap with respect to updates and is transactional based, MicroOS tracks Tumbleweed…
Switching to Agama would mean a work flow adjust, but going forward this is what the openSUSE developers are focused on… I too like combustion, but I do see the need to move to profiles. I tag the Agama iso image with a password and then can do a remote install via https://agama.local as in plug in the USB, system will boot (as long as USB is selected as first boot), so that would aleviate that, but I suspect you can tweak to run combustion…
Worth a read https://documentation.suse.com/sles/16.0/html/SLES-x86-64-agama-automated-installation/index.html and published today…
Oh, nooooo… 
Ha, I spent a lot of time figuring out combustion.
Can I use that script that combustion uses? How does agama play with ansible does it work with a declarative configuration file as well?
@linuxuser3134 likewise 
I’m not really sure, there are some other Forum users working with profiles, perhaps @SeglerEDCE, @eec-kowen and @gendjaral could offer some input?
1 Like
@linuxuser3134 Since I was mentioned, I can at least offer ideas. Whether or not it fits your case is another issue. My workflow is more OS image based. I am by no means an expert in this at all either but I know how to put pieces together once I’m made aware of the right tools.
I use HCP Packer to bring up a QEMU VM from a Leap ISO. Packer serves files via http out of a directory in the folder you specify. Put your agama jsonnet file in there. Packer’s QEMU source lets you “type” VNC keys so basically it emulates a human at the keyboard to append the boot string to the kernel before install. So you provide the agama file address to the kernel. From there, I do very minimal/base configuration with agama, just enough to get the VM off the ground with networking and SSH. Next, using Packer’s Ansible provisioner, I get more detailed with playbooks. At the end of the process you are left with a configured .raw or .qcow2 VM disk that you can do whatever you want with. In my workflow, I attach the .raw VM disk as a loop device at the host level and build an OS image using the Clonezilla suite (ocs-sr, ocs-iso). The resulting ISO is the artifact with minimal user interaction to restore the image onto a real system.
This is a super high overview for a bare metal image. You can slice and dice this up however you want for cloud images or other goals.
I don’t know if any of this is useful but I had some time and figured I’d sling something out there since I’ve had to work with Suse for many years and have poured a lot time into automating installs recently. It does at least seem like packer would be helpful with the interaction bits you want to cut out though. If you need specifics, I can paste some snippets of my HCL2 templates to show you how it works.
1 Like
I just had a quick play here with a simple json file for MicroOS, hostname, locale, root and user with hashed passwords and ssh keys, I have a script to automate preparing and starting a vm. Then ssh’d onto the vm, scp’d the json file over and validated it, loaded the profile, started the installation and all worked fine. I suspect an OEMDRV/autoinst.jsonnet will do the trick(?).
Ref: https://agama-project.github.io/docs/user/profile/working_with_profiles
It will be interesting to compare with some more json/jsonnet work, my current setup with combustion and a qcow2 images is less that two minutes a bit longer if installing k3s.
Hey! I work a lot with PXE based installations. In some cases, a custom ISO image is used, which can be created as follows:
Dependencies
zypper install bsdtar mksusecd
Preparation
mkdir custom-leap160
cd custom-leap160
bsdtar -xf ~/<path-to-original-iso.iso>
cp ~/<path-to-json.json> .
vim boot/grub2/grub.cfg
Modify ISO grub.cfg
...
# 0 defines the first menu-entry (Boot from Hard Disk) here
set default=0
set timeout=10
...
menuentry "Boot from Hard Disk" ... {
...
...
}
# <--- New entries beginning from here --->
menuentry "Prepare, but Partition and Confirm manually - Leap 16.0" --class os --unrestricted {
set gfxpayload=keep
echo Loading kernel...
linux ($root)/boot/x86_64/loader/linux ${extra_cmdline} ${isoboot} live.password=XYZ inst.auto=file:///run/initramfs/live/main.json inst.install=0
echo Loading initrd...
initrd ($root)/boot/x86_64/loader/initrd
}
# Just a placeholder to prevent accidental selection
menuentry ' '{
true
}
menuentry "Fully Auto Install Leap 16.0" --class os --unrestricted {
set gfxpayload=keep
echo Loading kernel...
linux ($root)/boot/x86_64/loader/linux ${extra_cmdline} ${isoboot} live.password=XYZ inst.auto=file:///run/initramfs/live/main.json inst.install=1
echo Loading initrd...
initrd ($root)/boot/x86_64/loader/initrd
}
# Just a placeholder to prevent accidental selection
menuentry ' '{
true
}
# <--- End of new entries --->
...
Note
file:// " /run/initramfs/live/ " is mountpoint of current custom-leap160/ root
inst.install=1 FullyAuto
live.password=XYZ (one-time remote pass SSH/HTTP)
Re-package
cd ..
mksusecd --create custom-leap160.iso custom-leap160/
I hope that was helpful.
2 Likes
thank you, for these tips! I’ll look into this and follow up with questions. @malcolmlewis thanks for pulling more people into the post.