6 Replies
Alright well here by popular demand working on putting a linux distro for all. I will post the requirement below and update as the community request anything. I am making this to be compatible with most hardware as well.
Core Requirements
Base OS:
Debian-based custom Linux distribution.
Partition Layout:
Boot Partition:
A small FAT32 partition for bootloader files, compatible with ARM and x86.
Root Partition A (/):
Active partition with a read-only root filesystem.
Root Partition B (/):
Inactive partition for staging updates.
Writable Partition (/data):
Dedicated writable partition for Docker containers, dependencies, and other dynamic data.
Filesystem Design:
Root partitions (A and B): ext4 or squashfs with OverlayFS for runtime modifications.
Writable partition: ext4, btrfs, or xfs (optimized for Docker).
Update Requirements
Dual-Partition Atomic Updates:
Updates are staged on the inactive partition.
Switch bootloader to updated partition after successful update validation.
Rollback to previous partition in case of failure.
Headless Operation:
Must be fully functional and accessible without a GUI.
Rollback Mechanism:
Automatic rollback to the previous partition on update failure.
Networking and Remote Access
SSH Enabled by Default:
Pre-installed and configured openssh-server.
Ensure SSH starts automatically on first boot.
Support key-based authentication with optional password login.
Networking:
Default configuration for DHCP.
Support for static IP configuration if needed.
Dynamic Data Management
Persistent Data Storage:
Store user data, logs, Docker containers, and other dynamic content on the /data partition.
Ensure /data is consistent across boots and partition switches.
Writable Layer:
OverlayFS for temporary runtime changes on the read-only root filesystem.
System Compatibility
Cross-Architecture Support:
Fully compatible with ARM (e.g., Raspberry Pi) and x86 architectures.
Separate images or builds for each architecture if needed.
Raspberry Pi Imager Support:
Create .img files compatible with Raspberry Pi Imager.
Security Considerations
System Integrity:
Root filesystem remains read-only to prevent tampering.
Use secure bootloader configurations (e.g., GRUB for x86, U-Boot for ARM).
SSH Security:
Optionally disable root login.
Key-based authentication for headless access.
Firewall (ufw) pre-configured to allow SSH traffic.
Updates and Upgrades:
Secure OTA update mechanism to update the inactive partition.
Deployment and Testing
Factory Reset Mechanism:
Provide an option to reset the writable partition or system settings to their default state.
Testing Across Architectures:
Validate the system, partition setup, and update mechanism on both ARM and x86 platforms.
Documentation:
Include clear instructions for first-time setup, partition usage, and system updates.
Optional Features (Future Consideration)
Compression:
Use squashfs for reduced storage requirements.
Snapshotting:
Use btrfs or similar for snapshot-based rollback.
Monitoring and Logs:
Implement remote log storage or monitoring tools for headless operation.
Docker Optimization:
Pre-configure Docker storage on the writable partition.
Let me know if there’s anything to add or adjust in this requirements list!
@Matti Airas what you think?
Stick with a single architecture (Raspberry Pi family, basically) and base it off the Raspberry Pi OS - there's a whole lot of work if you start doing a custom Debian from the ground up. The less you have delta to a base distro that works on your platform, the less you need to spend time on the base OS and the more you can focus on the marine customizations. It would still be possible to alter the course at a later point if there's demand for the x86 variant.
You can have a look at the OpenPlotter HALPI customizations - the OpenPlotter and HALPI stages are stacked on top of the stock pi-gen, with minimal changes to the earlier stages.
The partition ideas are great. Don't know whether squashfs would be needed or what its performance impact would be. I would try to keep the OS update facilities as standard as possible, though - could the A/B updates be implemented with e.g. apt hooks and wrappers around the Docker commands?
Wouldn't the factory reset mechanism necessitate having a third install partition? Or would that just nuke any custom configuration and data and restore the latest updated state?
Ok, the Official Name is going to be MarineComOS and I bought the domain. To help with Publishing the image.
@Matti Airas can you change the name of this thread to MarineComOS please?
There you go
Thank You.
OS is building right now. Was semi busy with the holidays visiting Family. But I will be able to test the OS in a couple of house.
http://git.relentnet.com/Relentnet/MarineComOS_RPI
@Matti Airas Working on adding HASS.IO to the image. But wondering if I do a docker or supervised installation. Not sure the HASS Add-Ons is something I want available only to prevent conflicts. But what do you think?
https://marinecomos.com/
will be spending more time on this soon.
Time to write my first image to a RPI and see what we get.
Re HASS; it depends on how you see the relationship between SK and HA. I think it might even be tempting to make SK a HA add-on but I probably haven't thought it through...