https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# elemental
a
This message was deleted.
s
Hi Robert, so glad to see you back here with interesting questions. > Is building your own images still the only/best way to add packages (zypper install or otherwise) to a base image (such as the ones provided in the official channel), or can this now be achieved at a MachineRegistration or SeedImage level? Building your own images has never been the only way of adding software, but the preferred one, and still is. The reasoning is that we envision treating your OS in an analog way of what you'd do with a container. You build and iterate few times to get the desired behavior and from there you are capable to use it and rebuild it if needed in an easy manner. To the specific question, it is possible to include additional software at SeedImage level and at MachineRegistration level. Now they both support yip syntax too, you could consider something like the following:
Copy code
apiVersion: elemental.cattle.io/v1beta1
kind: MachineRegistration
metadata:
  ...
spec:
  ...
  config:
    cloud-config:
      stages:
        after-install-chroot:
        - &extraPackages
          name: "Install additional software"
          commands:
          - |
            echo "Some shell script is executed here to include extra packages|binaries"
        after-upgrade-chroot:
        - <<: *extraPackages
        after-reset-chroot:
        - <<: *extraPackages
This would include a shell script snippted that would be executed in install, upgrade and reset in a chroot of the to be deployed system before it is marked as read only.
Amazing to see the new 
sl-micro 6.0
base/bare-metal/kvm images and the new documentation on channels (oh
and the ability to build raw images in the Rancher GUI!!). I personally
find it strange though that the 
kvm
image swaps 
kernel-default
out for 
kernel-default-base
, and also doesn’t add any of the packages that 
baremetal
gets. Surely the 
base
image should have the smaller kernel package, and 
kvm
literally just add 
qemu-guest-agent
ontop of 
baremetal
?
I can’t think why we wouldn’t want access to the same packages as a
baremetal env just because we’re virtualised, keen to know the rationale
behind this. My main interest in this is that I think the 
baremetal
image finally supports all the requirements for Longhorn (I haven’t
100% tested this yet), but because I also need the guest agent, it’s not
much use to me.
So, the rationale is the following: 
baremetal
image includes all firmware available for a wide variety of hardware plus some commodity packages already in (podman, network tools, etc.). 
kvm
flavor was just meant to be a minimal image to verify against libvirt, so essentially the 
base
image plus kvm specific packages and uses the base kernel and the firmware scope will be reduced in virtualized environments. I understand your concern regarding the package set of the images, specially if you are willing for images with extra commodity packages and kvm related ones. We are well aware this can be improved and feedback like yours is valuable to us.
@sticky-tailor-45974 Is this documentation still the best/only way to add LVMs? I’d be curious to know more about this comment as I can’t figure out how I might achieve this by only modifying the SeedImage resource
Yes all this should be still valid, but most likely all this can achieved easier now. I'll go through it and try to update it in the following days. The 
SeedImage
resource includes as 
cloud-config
section that is added to 
iso-config/
into the resulting ISO filesystem.
a
Huge thanks David this is all super helpful. I’m on board with your comments about having an independently reproducible OS image, I think at some point (once I’m done exploring and testing) I’ll come back to that approach and will have some followup questions about base image sources and the OBS, but for now I’m keen to play with the 
after-install-chroot
method. Given the options I now have for adding packages to images I’m less concerned with the package sets in official images but glad that’s helpful feedback. I’ll see where I can get to with adding LVMs via SeedImages on Monday, thanks again!
@sticky-tailor-45974 I’ve been getting somewhere with LVMs - creating pvs/gvs/lvs in the 
post-install
stage from my 
seedImage
seems to work great. I’m having some difficulty mounting them however. Following the guide above, I understand that modifications to 
/etc/fstab
should be done at the 
initramfs
stage, and because I know from examples in the cloud-config &amp; MachineRegistration reference, this stage can be hooked into from the Registration Endpoint. As such, I tried putting my command in there, but something doesn’t seem quite right…
Copy code
apiVersion: <http://elemental.cattle.io/v1beta1|elemental.cattle.io/v1beta1>
kind: MachineRegistration
metadata:
  creationTimestamp: '2024-10-08T13:05:58Z'
  generation: 16
  managedFields:
    - apiVersion: <http://elemental.cattle.io/v1beta1|elemental.cattle.io/v1beta1>
      fieldsType: FieldsV1
      fieldsV1:
        f:status:
          .: {}
          f:conditions: {}
          f:registrationToken: {}
          f:registrationURL: {}
          f:serviceAccountRef: {}
      manager: elemental-operator
      operation: Update
      subresource: status
      time: '2024-10-15T12:43:37Z'
    - apiVersion: <http://elemental.cattle.io/v1beta1|elemental.cattle.io/v1beta1>
      fieldsType: FieldsV1
      fieldsV1:
        f:spec:
          .: {}
          f:config:
            .: {}
            f:cloud-config:
              .: {}
              f:stages:
                .: {}
                f:initramfs: {}
              f:users: {}
            f:elemental:
              .: {}
              f:install:
                .: {}
                f:device: {}
                f:reboot: {}
                f:snapshotter:
                  .: {}
                  f:type: {}
              f:reset:
                .: {}
                f:reboot: {}
                f:reset-oem: {}
                f:reset-persistent: {}
          f:machineName: {}
      manager: rancher
      operation: Update
      time: '2024-10-22T09:56:55Z'
  name: elemental
  namespace: fleet-default
  resourceVersion: '8146715'
  uid: 129139f5-96ff-4d4a-92dc-1f37a586f5f7
spec:
  config:
    cloud-config:
      stages:
        initramfs:
          - commands:
              - echo "Mount LVM for longhorn at boot"
            name: Mount LVM for longhorn at boot
      users:
        - name: root
          passwd: root
    elemental:
      install:
        device: /dev/vda
        reboot: true
        snapshotter:
          type: loopdevice
      reset:
        reboot: true
        reset-oem: true
        reset-persistent: true
  machineName: ${System Data/Runtime/Hostname}
status:
  conditions:
    - lastTransitionTime: '2024-10-15T12:43:37Z'
      message: ''
      reason: SuccessfullyCreated
      status: 'True'
      type: Ready
  registrationToken: 86wchwtdhfr95trqw8x57p7k9njjmzmqqbwxk6gv7mft2pgpt2hk6j
  registrationURL: >-
    <https://rancher.10.0.0.11.nip.io/elemental/registration/86wchwtdhfr95trqw8x57p7k9njjmzmqqbwxk6gv7mft2pgpt2hk6j>
  serviceAccountRef:
    kind: ServiceAccount
    name: elemental
    namespace: fleet-default
Even if my command is just an echo as in the example above (I was trying to verify my command wasn’t failing or anything), I can no longer log into my elemental machine with the user in my cloud config, which suggests this stage hook isn’t working properly and the rest of my cloud-config isn’t getting executed or something? Since I can’t log in, I can’t check any logs/see if my command has had any effect. If I omit the stages section, I can log in just fine. Any ideas what’s wrong here?
(for clarity - I'm not logging in via ssh, but the web console that Harvester provides for its VMs)
s
HI @acoustic-country-10006 sorry took a while to respond. In the pasted resource yaml there is an error with the 
cloud-config
syntax, it mixes cloud-init syntax with 
yip
syntax, from v1.6 yip syntax is also possible but not together it is one or either the other, not both. So
Copy code
cloud-config:
  stages:
    initramfs:
    - commands:
      - echo "Mount LVM for longhorn at boot"
        name: Mount LVM for longhorn at boot
  users:
  - name: root
    passwd: root
should be translated into:
Copy code
cloud-config:
  stages:
    initramfs:
    - name: "Mount LVM for longhorn at boot"
      commands:
      - echo "Mount LVM"
    boot:
    - name: "Setting root user password"
      users:
        root:
          passwd: root
More over I reworked entirely the LVM example that used to be in docs and I adapted to current and latest elemental-operator features. It is significantly simplified now in comparison to what it used to be, see the new section here
a
Ahh that makes sense and clears up another confusion I had too, thanks very much. I just tried that fix and things look good! Thanks for reworking the docco also, hopefully that helps others too
How does this process differ when using a RAW image rather than an ISO? As far as I understand, the post-install hook won’t be available since we’re not “installing” to a volume. In that case, where should I put the steps that create the LVM?
Ohh, booting from a raw does a register reset doesn’t it, I’ll see if this works in the post-reset hook 🤞
hmm, no luck with that
4 Views
Open in Slack
PreviousNext
Powered by