Raspberry Pi and SUSE Manager
a project by e_bischoff
Updated about 4 years ago. 5 hacker ♥️. 6 followers.

I have bought a Raspberry Pi 400 and would like to experiment how it integrates into SUSE ecosystem.

Project Description

Possible manipulations:

  • flash a micro SD card from a Macbook to install Ubuntu, SLES and/or openSUSE
  • same from an external USB-C SSD disk, compare speed
  • deploy SUSE Manager locally and register Pi
  • integrate into development VPN and register Pi into existing SUSE Manager instance
  • set up a local PXE server and try to install via pure PXE/TFTP
  • same from local SUSE Manager instance
  • try to develop in ARM assembler on the Pi
  • write findings or record a video

That's quite a lot and I will probably be able to do only a small part of it.

Goal for this Hackweek

Get familiar with the Raspberry Pi, our SUSE implementation and SUSE Manager integration.

Resources

Since the hardware is only available locally, it will probably be a one-man show, but feel free to join or just support!

Join this project

Looking for hackers with the skills:

raspberrypi susemanager uyuni

This project is part of:

Hack Week 20

Activity

  • over 4 years ago: phswartz joined this project.
  • over 4 years ago: sdevadiga joined this project.
  • over 4 years ago: e_bischoff added keyword "uyuni" to this project.
  • over 4 years ago: equill liked this project.
  • over 4 years ago: dnuzik liked this project.
  • over 4 years ago: mbrugger liked this project.
  • over 4 years ago: mlnoga liked this project.
  • almost 5 years ago: j_renner liked this project.
  • almost 5 years ago: e_bischoff started this project.
  • almost 5 years ago: e_bischoff added keyword "raspberrypi" to this project.
  • almost 5 years ago: e_bischoff added keyword "susemanager" to this project.
  • almost 5 years ago: e_bischoff originated this project.


    • Comments

    • e_bischoff
      over 4 years ago by e_bischoff | Reply

      Stealing some documentation from @nadvornik add-emoji :

      Raspberry Pi does not have UEFI implementation in firmware, with SLES it uses U-Boot with UEFI support. This means that it needs SD card with special image for the first boot. The boot process is following: RPi boots from SD card, loads U-Boot, kernel and initrd from SD card, then it connects to SUSE Manager and continues normally - check and eventually deploy system image image and boots it.

      • a_faerber
        over 4 years ago by a_faerber | Reply

        You should also be able to boot the SLES .iso (as another special image) from USB, with RPi3B+ or a recent RPi4 EEPROM firmware.

    • mlnoga
      over 4 years ago by mlnoga | Reply

      Hi, some thoughts. Benchmarking has been done a couple of times, e.g. by Tom's Hardware.

      A real problem to solve for SD-card based systems is card failure. Automated backup/restore on fresh SD card would find quite some fans. Most best practice sites just refer to full disk cloning. Maybe there's a smarter way, e.g. by using Machinery to tell apart base OS & changes?

      What I find really vexing on PI4 is lack of a proper 64 bit OS. Even on a Pi 4 with 8 GB, apps can at most use 2.5 GB. Raspberry PI OS 64-bit seems stuck in perpetual beta since last summer.

    • e_bischoff
      over 4 years ago by e_bischoff | Reply

      @mlnoga yes, the RaspDebian that was installed by default is 32 bits. The very first thing I did was to flash an Ubuntu, and that was 64 bits immediately.

    • e_bischoff
      over 4 years ago by e_bischoff | Reply

      @a_faerber yes, I am planning to try from USB disk as well as from SD card.

    • e_bischoff
      over 4 years ago by e_bischoff | Reply

      I am updating this file as I progress: http://w3.suse.de/~ebischoff/hackweek20.pdf .

    • e_bischoff
      over 4 years ago by e_bischoff | Reply

      @a_faerber I managed from USB HDD, but not from USB ISO. Any tip welcome.

    • e_bischoff
      over 4 years ago by e_bischoff | Reply

      PXE boot works. This finishes my hackweek.

    • joachimwerner
      over 4 years ago by joachimwerner | Reply

      A few additional comments from working with Raspberry Pi 4s with 8GB and the new SLE Micro 5.0 images:

      The SLE Micro RAW images can easily be copied to SD cards with dd or a tool like the Mac one you used.

      The nice thing with the SLE Micro images is that you can even boot them completely headless by defining the root password and other configurations you'd like to be done automatically from combustion and/or ignition. See the (beta) documentation here: https://susedoc.github.io/doc-sle/main/html/SLE-Micro-installation/article-installation.html#sec-slem-image-deployment

      The one thing that would be nice is if the ignition/combustion config could also be put directly into a directory on the SD card. Raspbian allows this to a certain extent. For example, you can just touch a file "ssh" in /boot to enable ssh.

      I didn't try out booting from harddisk or USB-SSD.

    • e_bischoff
      over 4 years ago by e_bischoff | Reply

      Thanks for the hint Joachim, I read your draft documentation.

      During my hackweek, I indeed did my tests with raw images with JeOS, and not with SUSE Linux Enterprise Micro.

      I indeed also did not investigate automation of the initial configuration. My expectation was that I would see some cloud-init script in action, but if there was one, I missed it :-P . That being said, resizing the root filesystem to make it span over all the root partition seemed to be the only initial step I had to do by hand.

    Similar Projects

    Build a Single Camera 3D Scanner (Photogrammetry). by lparkin

    Description

    I want to see how fast I can develop a single-camera (pi camera module v3) rig with a stepper motor controlling a turntable that rotates the model being scanned. The trick here is not to be super fancy with 100's of sensors and data inputs, quite the opposite. I want to see how accurate I can scan objects into 3D-printable models using only a camera and as many fixed and known parameters as possible.

    Speed to be augmented with agentic AI coding companion. As it stands, I have a 3D printer, pretty much all the electronics I need.

    Goals

    • Design and print working/workable camera rig
    • Design and print working/workable turntable (considering printing my own cylinder-style bearings as well)
    • Assemble rig components into MVP assembly
    • Develop application that can hook into existing tools, or leverage a library like openCV, to process 2D images into a 3D model.
    • Iterate until models are good enough to 3D print.

    Resources

    • https://www.instructables.com/3D-scanning-Photogrammetry-with-a-rotating-platfor/
    • https://www.instructables.com/3d-Scan-Anything-Using-Just-a-Camera/
    • https://www.instructables.com/Build-a-DIY-Desktop-3d-Scanner-With-Infinite-Resol/
    • https://www.instructables.com/3D-Laser-Scanning-DIY/

    Testing and adding GNU/Linux distributions on Uyuni by juliogonzalezgil

    Join the Gitter channel! https://gitter.im/uyuni-project/hackweek

    Uyuni is a configuration and infrastructure management tool that saves you time and headaches when you have to manage and update tens, hundreds or even thousands of machines. It also manages configuration, can run audits, build image containers, monitor and much more!

    Currently there are a few distributions that are completely untested on Uyuni or SUSE Manager (AFAIK) or just not tested since a long time, and could be interesting knowing how hard would be working with them and, if possible, fix whatever is broken.

    For newcomers, the easiest distributions are those based on DEB or RPM packages. Distributions with other package formats are doable, but will require adapting the Python and Java code to be able to sync and analyze such packages (and if salt does not support those packages, it will need changes as well). So if you want a distribution with other packages, make sure you are comfortable handling such changes.

    No developer experience? No worries! We had non-developers contributors in the past, and we are ready to help as long as you are willing to learn. If you don't want to code at all, you can also help us preparing the documentation after someone else has the initial code ready, or you could also help with testing :-)

    The idea is testing Salt (including bootstrapping with bootstrap script) and Salt-ssh clients

    To consider that a distribution has basic support, we should cover at least (points 3-6 are to be tested for both salt minions and salt ssh minions):

    1. Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
    2. Onboarding (salt minion from UI, salt minion from bootstrap scritp, and salt-ssh minion) (this will probably require adding OS to the bootstrap repository creator)
    3. Package management (install, remove, update...)
    4. Patching
    5. Applying any basic salt state (including a formula)
    6. Salt remote commands
    7. Bonus point: Java part for product identification, and monitoring enablement
    8. Bonus point: sumaform enablement (https://github.com/uyuni-project/sumaform)
    9. Bonus point: Documentation (https://github.com/uyuni-project/uyuni-docs)
    10. Bonus point: testsuite enablement (https://github.com/uyuni-project/uyuni/tree/master/testsuite)

    If something is breaking: we can try to fix it, but the main idea is research how supported it is right now. Beyond that it's up to each project member how much to hack :-)

    • If you don't have knowledge about some of the steps: ask the team
    • If you still don't know what to do: switch to another distribution and keep testing.

    This card is for EVERYONE, not just developers. Seriously! We had people from other teams helping that were not developers, and added support for Debian and new SUSE Linux Enterprise and openSUSE Leap versions :-)

    In progress/done for Hack Week 25

    Guide

    We started writin a Guide: Adding a new client GNU Linux distribution to Uyuni at https://github.com/uyuni-project/uyuni/wiki/Guide:-Adding-a-new-client-GNU-Linux-distribution-to-Uyuni, to make things easier for everyone, specially those not too familiar wht Uyuni or not technical.

    openSUSE Leap 16.0

    The distribution will all love!

    https://en.opensuse.org/openSUSE:Roadmap#DRAFTScheduleforLeap16.0

    Curent Status We started last year, it's complete now for Hack Week 25! :-D

    • [W] Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file) NOTE: Done, client tools for SLMicro6 are using as those for SLE16.0/openSUSE Leap 16.0 are not available yet
    • [W] Onboarding (salt minion from UI, salt minion from bootstrap scritp, and salt-ssh minion) (this will probably require adding OS to the bootstrap repository creator)
    • [W] Package management (install, remove, update...). Works, even reboot requirement detection

    Enhance setup wizard for Uyuni by PSuarezHernandez

    Description

    This project wants to enhance the intial setup on Uyuni after its installation, so it's easier for a user to start using with it.

    Uyuni currently uses "uyuni-tools" (mgradm) as the installation entrypoint, to trigger the installation of Uyuni in the given host, but does not really perform an initial setup, for instance:

    • user creation
    • adding products / channels
    • generating bootstrap repos
    • create activation keys
    • ...

    Goals

    • Provide initial setup wizard as part of mgradm uyuni installation

    Resources

    Set Uyuni to manage edge clusters at scale by RDiasMateus

    Description

    Prepare a Poc on how to use MLM to manage edge clusters. Those cluster are normally equal across each location, and we have a large number of them.

    The goal is to produce a set of sets/best practices/scripts to help users manage this kind of setup.

    Goals

    step 1: Manual set-up

    Goal: Have a running application in k3s and be able to update it using System Update Controler (SUC)

    • Deploy Micro 6.2 machine

    • Deploy k3s - single node

      • https://docs.k3s.io/quick-start

    • Build/find a simple web application (static page)

      • Build/find a helmchart to deploy the application

    • Deploy the application on the k3s cluster

    • Install App updates through helm update

    • Install OS updates using MLM

    step 2: Automate day 1

    Goal: Trigger the application deployment and update from MLM

    • Salt states For application (with static data)
      • Deploy the application helmchart, if not present
      • install app updates through helmchart parameters
    • Link it to GIT
      • Define how to link the state to the machines (based in some pillar data? Using configuration channels by importing the state? Naming convention?)
      • Use git update to trigger helmchart app update
    • Recurrent state applying configuration channel?

    step 3: Multi-node cluster

    Goal: Use SUC to update a multi-node cluster.

    • Create a multi-node cluster
    • Deploy application
      • call the helm update/install only on control plane?
    • Install App updates through helm update
    • Prepare a SUC for OS update (k3s also? How?)
      • https://github.com/rancher/system-upgrade-controller
      • https://documentation.suse.com/cloudnative/k3s/latest/en/upgrades/automated.html
      • Update/deploy the SUC?
      • Update/deploy the SUC CRD with the update procedure

    Set Up an Ephemeral Uyuni Instance by mbussolotto

    Description

    To test, check, and verify the latest changes in the master branch, we want to easily set up an ephemeral environment.

    Goals

    • Create an ephemeral environment manually

    • Create an ephemeral environment automatically

      Resources

    • https://github.com/uyuni-project/uyuni

    • https://www.uyuni-project.org/uyuni-docs/en/uyuni/index.html

    mgr-ansible-ssh - Intelligent, Lightweight CLI for Distributed Remote Execution by deve5h

    Description

    By the end of Hack Week, the target will be to deliver a minimal functional version 1 (MVP) of a custom command-line tool named mgr-ansible-ssh (a unified wrapper for BOTH ad-hoc shell & playbooks) that allows operators to:

    1. Execute arbitrary shell commands on thousand of remote machines simultaneously using Ansible Runner with artifacts saved locally.
    2. Pass runtime options such as inventory file, remote command string/ playbook execution, parallel forks, limits, dry-run mode, or no-std-ansible-output.
    3. Leverage existing SSH trust relationships without additional setup.
    4. Provide a clean, intuitive CLI interface with --help for ease of use. It should provide consistent UX & CI-friendly interface.
    5. Establish a foundation that can later be extended with advanced features such as logging, grouping, interactive shell mode, safe-command checks, and parallel execution tuning.

    The MVP should enable day-to-day operations to efficiently target thousands of machines with a single, consistent interface.

    Goals

    Primary Goals (MVP):

    Build a functional CLI tool (mgr-ansible-ssh) capable of executing shell commands on multiple remote hosts using Ansible Runner. Test the tool across a large distributed environment (1000+ machines) to validate its performance and reliability.

    Looking forward to significantly reducing the zypper deployment time across all 351 RMT VM servers in our MLM cluster by eliminating the dependency on the taskomatic service, bringing execution down to a fraction of the current duration. The tool should also support multiple runtime flags, such as:

    mgr-ansible-ssh: Remote command execution wrapper using Ansible Runner

Usage: mgr-ansible-ssh [--help] [--version] [--inventory INVENTORY]
                   [--run RUN] [--playbook PLAYBOOK] [--limit LIMIT]
                   [--forks FORKS] [--dry-run] [--no-ansible-output]

Required Arguments
--inventory, -i      Path to Ansible inventory file to use

Any One of the Arguments Is Required
--run, -r            Execute the specified shell command on target hosts
--playbook, -p       Execute the specified Ansible playbook on target hosts

Optional Arguments
--help, -h           Show the help message and exit
--version, -v        Show the version and exit
--limit, -l          Limit execution to specific hosts or groups
--forks, -f          Number of parallel Ansible forks
--dry-run            Run in Ansible check mode (requires -p or --playbook)
--no-ansible-output  Suppress Ansible stdout output

    Secondary/Stretched Goals (if time permits):

    1. Add pretty output formatting (success/failure summary per host).
    2. Implement basic logging of executed commands and results.
    3. Introduce safety checks for risky commands (shutdown, rm -rf, etc.).
    4. Package the tool so it can be installed with pip or stored internally.

    Resources

    Collaboration is welcome from anyone interested in CLI tooling, automation, or distributed systems. Skills that would be particularly valuable include:

    1. Python especially around CLI dev (argparse, click, rich)

    Uyuni Saltboot rework by oholecek

    Description

    When Uyuni switched over to the containerized proxies we had to abandon salt based saltboot infrastructure we had before. Uyuni already had integration with a Cobbler provisioning server and saltboot infra was re-implemented on top of this Cobbler integration.

    What was not obvious from the start was that Cobbler, having all it's features, woefully slow when dealing with saltboot size environments. We did some improvements in performance, introduced transactions, and generally tried to make this setup usable. However the underlying slowness remained.

    Goals

    This project is not something trying to invent new things, it is just finally implementing saltboot infrastructure directly with the Uyuni server core.

    Instead of generating grub and pxelinux configurations by Cobbler for all thousands of systems and branches, we will provide a GET access point to retrieve grub or pxelinux file during the boot:

    /saltboot/group/grub/$fqdn and similar for systems /saltboot/system/grub/$mac

    Next we adapt our tftpd translator to query these points when asked for default or mac based config.

    Lastly similar thing needs to be done on our apache server when HTTP UEFI boot is used.

    Resources

    Move Uyuni Test Framework from Selenium to Playwright + AI by oscar-barrios

    Description

    This project aims to migrate the existing Uyuni Test Framework from Selenium to Playwright. The move will improve the stability, speed, and maintainability of our end-to-end tests by leveraging Playwright's modern features. We'll be rewriting the current Selenium code in Ruby to Playwright code in TypeScript, which includes updating the test framework runner, step definitions, and configurations. This is also necessary because we're moving from Cucumber Ruby to CucumberJS.

    If you're still curious about the AI in the title, it was just a way to grab your attention. Thanks for your understanding.

    Nah, let's be honest add-emoji AI helped a lot to vibe code a good part of the Ruby methods of the Test framework, moving them to Typescript, along with the migration from Capybara to Playwright. I've been using "Cline" as plugin for WebStorm IDE, using Gemini API behind it.

    Goals

    • Migrate Core tests including Onboarding of clients
    • Improve test reliabillity: Measure and confirm a significant reduction of flakiness.
    • Implement a robust framework: Establish a well-structured and reusable Playwright test framework using the CucumberJS

    Resources

    Testing and adding GNU/Linux distributions on Uyuni by juliogonzalezgil

    Join the Gitter channel! https://gitter.im/uyuni-project/hackweek

    Uyuni is a configuration and infrastructure management tool that saves you time and headaches when you have to manage and update tens, hundreds or even thousands of machines. It also manages configuration, can run audits, build image containers, monitor and much more!

    Currently there are a few distributions that are completely untested on Uyuni or SUSE Manager (AFAIK) or just not tested since a long time, and could be interesting knowing how hard would be working with them and, if possible, fix whatever is broken.

    For newcomers, the easiest distributions are those based on DEB or RPM packages. Distributions with other package formats are doable, but will require adapting the Python and Java code to be able to sync and analyze such packages (and if salt does not support those packages, it will need changes as well). So if you want a distribution with other packages, make sure you are comfortable handling such changes.

    No developer experience? No worries! We had non-developers contributors in the past, and we are ready to help as long as you are willing to learn. If you don't want to code at all, you can also help us preparing the documentation after someone else has the initial code ready, or you could also help with testing :-)

    The idea is testing Salt (including bootstrapping with bootstrap script) and Salt-ssh clients

    To consider that a distribution has basic support, we should cover at least (points 3-6 are to be tested for both salt minions and salt ssh minions):

    1. Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
    2. Onboarding (salt minion from UI, salt minion from bootstrap scritp, and salt-ssh minion) (this will probably require adding OS to the bootstrap repository creator)
    3. Package management (install, remove, update...)
    4. Patching
    5. Applying any basic salt state (including a formula)
    6. Salt remote commands
    7. Bonus point: Java part for product identification, and monitoring enablement
    8. Bonus point: sumaform enablement (https://github.com/uyuni-project/sumaform)
    9. Bonus point: Documentation (https://github.com/uyuni-project/uyuni-docs)
    10. Bonus point: testsuite enablement (https://github.com/uyuni-project/uyuni/tree/master/testsuite)

    If something is breaking: we can try to fix it, but the main idea is research how supported it is right now. Beyond that it's up to each project member how much to hack :-)

    • If you don't have knowledge about some of the steps: ask the team
    • If you still don't know what to do: switch to another distribution and keep testing.

    This card is for EVERYONE, not just developers. Seriously! We had people from other teams helping that were not developers, and added support for Debian and new SUSE Linux Enterprise and openSUSE Leap versions :-)

    In progress/done for Hack Week 25

    Guide

    We started writin a Guide: Adding a new client GNU Linux distribution to Uyuni at https://github.com/uyuni-project/uyuni/wiki/Guide:-Adding-a-new-client-GNU-Linux-distribution-to-Uyuni, to make things easier for everyone, specially those not too familiar wht Uyuni or not technical.

    openSUSE Leap 16.0

    The distribution will all love!

    https://en.opensuse.org/openSUSE:Roadmap#DRAFTScheduleforLeap16.0

    Curent Status We started last year, it's complete now for Hack Week 25! :-D

    • [W] Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file) NOTE: Done, client tools for SLMicro6 are using as those for SLE16.0/openSUSE Leap 16.0 are not available yet
    • [W] Onboarding (salt minion from UI, salt minion from bootstrap scritp, and salt-ssh minion) (this will probably require adding OS to the bootstrap repository creator)
    • [W] Package management (install, remove, update...). Works, even reboot requirement detection