Rebasing of the current MicroOS installation
a project by epaolantonio
Updated about 1 year ago. 3 hacker ♥️. 2 followers.

Project Description

It would be nice being able to "rebase" a MicroOS/Aeon/Kalpa installation. This can be useful, for example, to undo changes done manually with transactional-update shell, to try another variant (like replacing Aeon with Kalpa) and so on... but the goal of this project is mostly to get more knowledgeable with the MicroOS/ALP internals (tukit, snapper, et all) while doing something fun.

The new image would be committed as a brand new snapshot, so rollbacks can still happen if desirable.

Goal for this Hackweek

  • Being able to build a new image directly on-device, using official or custom patterns
  • Being able to use an already built official image

Join this project

Looking for hackers with the skills:

microos alp aeon kalpa transactionalupdates

This project is part of:

Hack Week 23

Activity

  • about 1 year ago: jzerebecki liked this project.
  • about 1 year ago: epaolantonio liked this project.
  • about 1 year ago: gleidi liked this project.
  • about 1 year ago: epaolantonio started this project.
  • about 1 year ago: epaolantonio added keyword "microos" to this project.
  • about 1 year ago: epaolantonio added keyword "alp" to this project.
  • about 1 year ago: epaolantonio added keyword "aeon" to this project.
  • about 1 year ago: epaolantonio added keyword "kalpa" to this project.
  • about 1 year ago: epaolantonio added keyword "transactionalupdates" to this project.
  • about 1 year ago: epaolantonio originated this project.


    • Comments

    • socon
      about 1 year ago by socon | Reply

      Is there any way to help? Are you creating documentation that we can follow / enhance?

      • epaolantonio
        about 1 year ago by epaolantonio | Reply

        Thank you for your interest! Once I've got something that can be reliably reproduced I'll put everything up (including documentation) in GitHub :)

        My Day 1 was mostly doing it by hand so to get a feeling on how it can be implemented (actually with some success)... now I'm working on the "image building" part... then it needs to be integrated with the transactional-update command

        Once I have something concrete I would love if you and everyone else can give it a shot!

    Similar Projects

    ADS-B receiver with MicroOS by epaolantonio

    I would like to put one of my spare Raspberry Pis to good use, and what better way to see what flies above my head at any time? add-emoji

    There are various ready-to-use distros already set-up to provide feeder data to platforms like Flightradar24, ADS-B Exchange, FlightAware etc... The goal here would be to do it using MicroOS as a base and containerized decoding of ADS-B data (via tools like dump1090) and web frontend (tar1090).

    Goals

    • Create a working receiver using MicroOS as a base, and containers based on Tumbleweed
    • Make it easy to install
    • Optimize for maximum laziness (i.e. it should take care of itself with minimum intervention)

    Resources

    • 1x Small Board Computer capable of running MicroOS
    • 1x RTL2832U DVB-T dongle
    • 1x MicroSD card
    • https://github.com/antirez/dump1090
    • https://github.com/flightaware/dump1090 (dump1090 fork by FlightAware)
    • https://github.com/wiedehopf/tar1090

    Ansible for add-on management by lmanfredi

    Description

    Machines can contains various combinations of add-ons and are often modified during the time.

    The list of repos can change so I would like to create an automation able to reset the status to a given state, based on metadata available for these machines

    Goals

    Create an Ansible automation able to take care of add-on (repo list) configuration using metadata as reference

    Resources