During regular L3 work I often don't find enough time to work on the command line disk partitioner parted which I maintain.

Changes often directly affect yast-storage(-ng) and libstorage(-ng). @aschnell opens bugs faster than I can solve them. Upstream is often slow and often wants patches differently.

We are at SLE15 Beta 3 submission already. So such bugs are starting to get urgent.

This project is about using Hackweek to be able to work on parted without interruptions by L3s.

Buglist SLE15:

  • bsc#1058667 (cannot resize used/busy partitions) in SLE15 Beta 4
  • bsc#1064446 (NVDIMM/pmem devices not supported) in SLE15 Beta 4
  • bsc#1065197 (s390x BLKRRPART ioctl on FBA DASD issue) active devel
  • bsc#1066467 (parted -m $dev p doesn't escape ':' separator) in SLE15 Beta 4
  • bsc#1067435 (s390x BLKRRPART ioctl on ECKD DASD issue) YaST bug, DASD limitations

Buglist SLE11-SP4 (lower priority but much older):

  • bsc#887474 (cannot create msdos disk label if gpt disk label exists) only confirmed

Rather relevant to openSUSE:

  • bsc#959181 (fatresize: incorrect /dev/mmcblk* path) patch sent to upstream, submitted to Factory
  • bsc#1072479 (parted: fatresize 0.1 needs an upgrade to 1.0.3) WONTFIX - too many bugs

Looking for hackers with the skills:

partitioning storage sles c

This project is part of:

Hack Week 16

Activity

  • about 7 years ago: mkubecek liked this project.
  • about 7 years ago: sparschauer added keyword "c" to this project.
  • about 7 years ago: sparschauer added keyword "partitioning" to this project.
  • about 7 years ago: sparschauer added keyword "storage" to this project.
  • about 7 years ago: sparschauer added keyword "sles" to this project.
  • about 7 years ago: sparschauer started this project.
  • about 7 years ago: sparschauer originated this project.

  • Comments

    • sparschauer
      about 7 years ago by sparschauer | Reply

      bsc#1064446 (NVDIMM), bsc#1066467 (Escaping ':') in Factory bsc#1058667 (resizepart) submitted to Factory bsc#1067435 (BLKRRPART ECKD DASD) became P1 but is not a parted bug -> DASD limitations, YaST bug

    Similar Projects

    Agama Expert Partitioner by joseivanlopez

    Description

    Agama is a new Linux installer that will be very likely used for SLES 16.

    It offers an UI for configuring the target system (language, patterns, network, etc). One of the more complex sections is the storage configuration, which is going to be revamped. This project consists on exploring the possibility of having something similar to the YaST Expert Partitioner for Agama.

    Goals

    • Explore different approaches for the storage UI in Agama.


    New migration tool for Leap by lkocman

    Update

    I will call a meeting with other interested people at 11:00 CET https://meet.opensuse.org/migrationtool

    Description

    SLES 16 plans to have no yast tool in it. Leap 16 might keep some bits, however, we need a new tool for Leap to SLES migration, as this was previously handled by a yast2-migration-sle

    Goals

    A tool able to migrate Leap 16 to SLES 16, I would like to cover also other scenarios within openSUSE, as in many cases users would have to edit repository files manually.

    • Leap -> Leap n+1 (minor and major version updates)
    • Leap -> SLES docs
    • Leap -> Tumbleweed
    • Leap -> Slowroll
    • Leap Micro -> Leap Micro n+1 (minor and major version updates)
    • Leap Micro -> MicroOS

    Hackweek 24 update

    Marcela and I were working on the project from Brno coworking as well as finalizing pieces after the hackweek. We've tested several migration scenarios and it works. But it needs further polishing and testing.

    Projected was renamed to opensuse-migration-tool and was submitted to devel project https://build.opensuse.org/requests/1227281

    Repository

    https://github.com/openSUSE/opensuse-migration-tool

    Out of scope is any migration to an immutable system. I know Richard already has some tool for that.

    Resources

    Tracker for yast stack reduction code-o-o/leap/features#173 YaST stack reduction


    SUSE KVM Best Practices by roseswe

    Description

    SUSE Best Practices around KVM, especially for SAP workloads. Early Google presentation already made from various customer projects and SUSE sources.

    Goals

    Complete presentation we can reuse in SUSE Consulting projects

    Resources

    KVM (virt-manager) images

    SUSE/SAP/KVM Best Practices

    • https://documentation.suse.com/en-us/sles/15-SP6/single-html/SLES-virtualization/
    • SAP Note 1522993 - "Linux: SAP on SUSE KVM - Kernel-based Virtual Machine" && 2284516 - SAP HANA virtualized on SUSE Linux Enterprise hypervisors https://me.sap.com/notes/2284516
    • SUSECon24: [TUTORIAL-1253] Virtualizing SAP workloads with SUSE KVM || https://youtu.be/PTkpRVpX2PM
    • SUSE Best Practices for SAP HANA on KVM - https://documentation.suse.com/sbp/sap-15/html/SBP-SLES4SAP-HANAonKVM-SLES15SP4/index.html


    SUSE AI Meets the Game Board by moio

    Use tabletopgames.ai’s open source TAG and PyTAG frameworks to apply Statistical Forward Planning and Deep Reinforcement Learning to two board games of our own design. On an all-green, all-open source, all-AWS stack!
    A chameleon playing chess in a train car, as a metaphor of SUSE AI applied to games


    Results: Infrastructure Achievements

    We successfully built and automated a containerized stack to support our AI experiments. This included:

    A screenshot of k9s and nvtop showing PyTAG running in Kubernetes with GPU acceleration

    ./deploy.sh and voilà - Kubernetes running PyTAG (k9s, above) with GPU acceleration (nvtop, below)

    Results: Game Design Insights

    Our project focused on modeling and analyzing two card games of our own design within the TAG framework:

    • Game Modeling: We implemented models for Dario's "Bamboo" and Silvio's "Totoro" and "R3" games, enabling AI agents to play thousands of games ...in minutes!
    • AI-driven optimization: By analyzing statistical data on moves, strategies, and outcomes, we iteratively tweaked the game mechanics and rules to achieve better balance and player engagement.
    • Advanced analytics: Leveraging AI agents with Monte Carlo Tree Search (MCTS) and random action selection, we compared performance metrics to identify optimal strategies and uncover opportunities for game refinement .

    Cards from the three games

    A family picture of our card games in progress. From the top: Bamboo, Totoro, R3

    Results: Learning, Collaboration, and Innovation

    Beyond technical accomplishments, the project showcased innovative approaches to coding, learning, and teamwork:

    • "Trio programming" with AI assistance: Our "trio programming" approach—two developers and GitHub Copilot—was a standout success, especially in handling slightly-repetitive but not-quite-exactly-copypaste tasks. Java as a language tends to be verbose and we found it to be fitting particularly well.
    • AI tools for reporting and documentation: We extensively used AI chatbots to streamline writing and reporting. (Including writing this report! ...but this note was added manually during edit!)
    • GPU compute expertise: Overcoming challenges with CUDA drivers and cloud infrastructure deepened our understanding of GPU-accelerated workloads in the open-source ecosystem.
    • Game design as a learning platform: By blending AI techniques with creative game design, we learned not only about AI strategies but also about making games fun, engaging, and balanced.

    Last but not least we had a lot of fun! ...and this was definitely not a chatbot generated line!

    The Context: AI + Board Games


    FizzBuzz OS by mssola

    Project Description

    FizzBuzz OS (or just fbos) is an idea I've had in order to better grasp the fundamentals of the low level of a RISC-V machine. In practice, I'd like to build a small Operating System kernel that is able to launch three processes: one that simply prints "Fizz", another that prints "Buzz", and the third which prints "FizzBuzz". These processes are unaware of each other and it's up to the kernel to schedule them by using the timer interrupts as given on openSBI (fizz on % 3 seconds, buzz on % 5 seconds, and fizzbuzz on % 15 seconds).

    This kernel provides just one system call, write, which allows any program to pass the string to be written into stdout.

    This project is free software and you can find it here.

    Goal for this Hackweek

    • Better understand the RISC-V SBI interface.
    • Better understand RISC-V in privileged mode.
    • Have fun.

    Resources

    Results

    The project was a resounding success add-emoji Lots of learning, and the initial target was met.


    Add a machine-readable output to dmidecode by jdelvare

    Description

    There have been repeated requests for a machine-friendly dmidecode output over the last decade. During Hack Week 19, 5 years ago, I prepared the code to support alternative output formats, but didn't have the time to go further. Last year, Jiri Hnidek from Red Hat Linux posted a proof-of-concept implementation to add JSON output support. This is a fairly large pull request which needs to be carefully reviewed and tested.

    Goals

    Review Jiri's work and provide constructive feedback. Merge the code if acceptable. Evaluate the costs and benefits of using a library such as json-c.


    FastFileCheck work by pstivanin

    Description

    FastFileCheck is a high-performance, multithreaded file integrity checker for Linux. Designed for speed and efficiency, it utilizes parallel processing and a lightweight database to quickly hash and verify large volumes of files, ensuring their integrity over time.

    https://github.com/paolostivanin/FastFileCheck

    Goals

    • Release v1.0.0

    Design overwiew:

    • Main thread (producer): traverses directories and feeds the queue (one thread is more than enough for most use cases)
    • Dedicated consumer thread: manages queue and distributes work to threadpool
    • Worker threads: compute hashes in parallel

    This separation of concerns is efficient because:

    • Directory traversal is I/O bound and works well in a single thread
    • Queue management is centralized, preventing race conditions
    • Hash computation is CPU-intensive and properly parallelized


    ESETv2 Emulator / interpreter by m.crivellari

    Description

    ESETv2 is an intriguing challenge developed by ESET, available on their website under the "Challenge" menu. The challenge involves an "assembly-like" language and a Python compiler that generates .evm binary files.

    This is an example using one of their samples (it prints N Fibonacci numbers):

    .dataSize 0
    .code
    
    loadConst 0, r1 # first
    loadConst 1, r2 # second
    
    loadConst 1, r14 # loop helper
    
    consoleRead r3
    
    loop:
        jumpEqual end, r3, r15
    
        add r1, r2, r4
        mov r2, r1
        mov r4, r2
    
        consoleWrite r1
    
        sub r3, r14, r3
        jump loop
    end:
    hlt
    

    This language also supports multi-threading. It includes instructions such as createThread to start a new thread, joinThread to wait until a thread completes, and lock/unlock to facilitate synchronization between threads.

    Goals

    • create a full interpreter able to run all the available samples provided by ESET.
    • improve / optimize memory (eg. using bitfields where needed as well as avoid unnecessary memory allocations)

    Resources

    Achivements

    Project still not complete. Added lock / unlock instruction implementation but further debug is needed; there is a bug somewhere. Actually the code it works for almost all the examples in the samples folder. 1 of them is not yet runnable (due to a missing "write" opcode implementation), another will cause the bug to show up; still not investigated, anyhow.