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
Looking for hackers with the skills:
This project is part of:
Hack Week 23
Activity
Comments
-
about 1 year ago by socon | Reply
Is there any way to help? Are you creating documentation that we can follow / enhance?
-
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? 
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
Project status (2024-11-22)
So I'd say that I'm pretty satisfied with how it turned out. I've packaged readsb (as a replacement for dump1090), tar1090, tar1090-db and mlat-client (not used yet).
Current status:
- Able to set-up a working receiver using combustion+ignition (web app based on Fuel Ignition)
- Able to feed to various feeds using the Beast protocol (Airplanes.live, ADSB.fi, ADSB.lol, ADSBExchange.com, Flyitalyadsb.com, Planespotters.net)
- Able to feed to Flightradar24 (initial-setup available but NOT tested! I've only tested using a key I already had)
- Local web interface (tar1090) to easily visualize the results
- Cockpit pre-configured to ease maintenance
What's missing:
- MLAT (Multilateration) support. I've packaged mlat-client already, but I have to wire it up
- FlightAware support
Give it a go at https://g7.github.io/adsbreceiver/ !
Project links
- https://g7.github.io/adsbreceiver/
- https://github.com/g7/adsbreceiver
- https://build.opensuse.org/project/show/home:epaolantonio:adsbreceiver
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
- Machines
- Repositories
- Developing modules
- Basic VM Guest management
- Module
zypper_repository_list - ansible-collections community.general
Results
Created WIP project Ansible-add-on-openSUSE