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.
  • over 4 years ago: j_renner liked this project.
  • over 4 years ago: e_bischoff started this project.
  • over 4 years ago: e_bischoff added keyword "raspberrypi" to this project.
  • over 4 years ago: e_bischoff added keyword "susemanager" to this project.
  • over 4 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

    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 and Salt-ssh clients, but NOT traditional clients, which are deprecated.

    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 :-)

    Pending

    In progress

    FUSS

    FUSS is a complete GNU/Linux solution (server, client and desktop/standalone) based on Debian for managing an educational network.

    https://fuss.bz.it/

    Seems to be a Debian 12 derivative, so adding it could be quite easy.

    • [W] Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
    • [W] Onboarding (salt minion from UI, salt minion from bootstrap script, and salt-ssh minion) (this will probably require adding OS to the bootstrap repository creator) --> Working for all 3 options (salt minion UI, salt minion bootstrap script and salt-ssh minion from the UI).
    • [W] Package management (install, remove, update...) --> Installing a new package works, needs to test the rest.
    • [I] Patching (if patch information is available, could require writing some code to parse it, but IIRC we have support for Ubuntu already). No patches detected. Do we support patches for Debian at all?
    • [W] Applying any basic salt state (including a formula)

    Flaky Tests AI Finder for Uyuni and MLM Test Suites by oscar-barrios

    Description

    Our current Grafana dashboards provide a great overview of test suite health, including a panel for "Top failed tests." However, identifying which of these failures are due to legitimate bugs versus intermittent "flaky tests" is a manual, time-consuming process. These flaky tests erode trust in our test suites and slow down development.

    This project aims to build a simple but powerful Python script that automates flaky test detection. The script will directly query our Prometheus instance for the historical data of each failed test, using the jenkins_build_test_case_failure_age metric. It will then format this data and send it to the Gemini API with a carefully crafted prompt, asking it to identify which tests show a flaky pattern.

    The final output will be a clean JSON list of the most probable flaky tests, which can then be used to populate a new "Top Flaky Tests" panel in our existing Grafana test suite dashboard.

    Goals

    By the end of Hack Week, we aim to have a single, working Python script that:

    1. Connects to Prometheus and executes a query to fetch detailed test failure history.
    2. Processes the raw data into a format suitable for the Gemini API.
    3. Successfully calls the Gemini API with the data and a clear prompt.
    4. Parses the AI's response to extract a simple list of flaky tests.
    5. Saves the list to a JSON file that can be displayed in Grafana.
    6. New panel in our Dashboard listing the Flaky tests

    Resources

    Uyuni Health-check Grafana Troubleshooter by ygutierrez

    Description

    This project explores the feasibility of using the open-source Grafana LLM plugin to enhance the Uyuni Health-check tool with LLM capabilities. The idea is to integrate a chat-based "AI Troubleshooter" directly into existing dashboards, allowing users to ask natural-language questions about errors, anomalies, or performance issues.

    Goals

    • Investigate if and how the grafana-llm-app plug-in can be used within the Uyuni Health-check tool.
    • Investigate if this plug-in can be used to query LLMs for troubleshooting scenarios.
    • Evaluate support for local LLMs and external APIs through the plugin.
    • Evaluate if and how the Uyuni MCP server could be integrated as another source of information.

    Resources

    Grafana LMM plug-in

    Uyuni Health-check

    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 and Salt-ssh clients, but NOT traditional clients, which are deprecated.

    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 :-)

    Pending

    In progress

    FUSS

    FUSS is a complete GNU/Linux solution (server, client and desktop/standalone) based on Debian for managing an educational network.

    https://fuss.bz.it/

    Seems to be a Debian 12 derivative, so adding it could be quite easy.

    • [W] Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
    • [W] Onboarding (salt minion from UI, salt minion from bootstrap script, and salt-ssh minion) (this will probably require adding OS to the bootstrap repository creator) --> Working for all 3 options (salt minion UI, salt minion bootstrap script and salt-ssh minion from the UI).
    • [W] Package management (install, remove, update...) --> Installing a new package works, needs to test the rest.
    • [I] Patching (if patch information is available, could require writing some code to parse it, but IIRC we have support for Ubuntu already). No patches detected. Do we support patches for Debian at all?
    • [W] Applying any basic salt state (including a formula)

    Uyuni read-only replica by cbosdonnat

    Description

    For now, there is no possible HA setup for Uyuni. The idea is to explore setting up a read-only shadow instance of an Uyuni and make it as useful as possible.

    Possible things to look at:

    • live sync of the database, probably using the WAL. Some of the tables may have to be skipped or some features disabled on the RO instance (taskomatic, PXT sessions…)
    • Can we use a load balancer that routes read-only queries to either instance and the other to the RW one? For example, packages or PXE data can be served by both, the API GET requests too. The rest would be RW.

    Goals

    • Prepare a document explaining how to do it.
    • PR with the needed code changes to support it

    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.

    Goals

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

    Resources