This means not having a separate partition for my var folder would completely wipe away all of my data if would execute sudo coreos-installer install with my updated ign-file if im not wrong
am i guessing right?
What is the best way to get to the state where re-provisioning my bare-metal setup is as easy as possible
Below maybe some helpful snippets of my butane-config
Using ucore to automatically include nvidia-drivers
variant: fcos
version: 1.5.0
...
storage:
disks: # Define Disk
- device: /dev/nvme1n1
wipe_table: true
partitions:
- label: nvme2
number: 0 # No Explicit number
wipe_partition_entry: true
size_mib: 0 # Max Size
start_mib: 0 # First Startingpoint
filesystems: # Define Disk Filesystem
- path: /var/mnt/nvme2
device: /dev/disk/by-partlabel/nvme2
format: ext4
with_mount_unit: true
...
directories:
# For ucore rebase
- path: /etc/ucore-autorebase
mode: 0754
...
systemd:
units:
# Unit for auto-rebase
- name: ucore-unsigned-autorebase.service
enabled: true
contents: |
[Unit]
Description=uCore autorebase to unsigned OCI and reboot
ConditionPathExists=!/etc/ucore-autorebase/unverified
ConditionPathExists=!/etc/ucore-autorebase/signed
After=network-online.target
Wants=network-online.target
[Service]
Type=oneshot
StandardOutput=journal+console
ExecStart=/usr/bin/rpm-ostree rebase --bypass-driver ostree-unverified-registry:ghcr.io/ublue-os/fedora-coreos:stable-nvidia
ExecStart=/usr/bin/touch /etc/ucore-autorebase/unverified
ExecStart=/usr/bin/systemctl disable ucore-unsigned-autorebase.service
ExecStart=/usr/bin/systemctl reboot
[Install]
WantedBy=multi-user.target
...
hi @hricky
thank you for responding to my question
Now and then i need to make changes to my system for the services i run on it
e.g.
activate ipv6 for docker
activate WoL
…
I thought:
Its good practice to NOT adjust stuff manually because on next install i have to do it again (or even remember what i need to do to run my services)
Its good practice to try to always update and develop the butane-config as single source of truth and just re-provision the system
As mentioned i think my current workflow
change everything manually
try to update butane config “offline” in parallel and hope it works on next installation as expected
is not very good
Did i get something wrong?
If not, im searching for the path how to “re-configure” my already running system with all persistent files and docker volume mounts stored somewhere in var/home, without wiping/crashing/breaking my running system
PS:
im running fedora coreOS with “nvidia added”. Package name: fedora-coreos:stable-nvidia
EDIT:
I know why u asked, the post above was bad edit from my side! I did not accidentially install ucore, i am really running fedora-coreos:stable-nvidia → Edited initial post
Could you provide the output of the rpm-ostree status command?
If I understand you correctly, you are using FCOS (uCore) as a general purpose server operating system on a bare metal machine. In such a use case, re-provisioning (reinstallation) should rarely be necessary (especially if the system is running smoothly), just like with any other server operating system, i.e. Fedora Server.
I think it is good practice to keep the Butane config as a blueprint. Since I do various tests, I have a lot of Butane templates.
There’s nothing wrong with custom system configurations. Whether it’s manual or not is up to you. Personally, I would recommend using Ansible, in which case you will need to layer Python.
If you are running your applications in containers, which is the recommended way for FCOS, you may want to consider implementing some automation/orchestration, e.g. Docker/Podman Compose, Quadlets, or Kubernetes.
If you want to be able to re-provision your system from an updated Butane config then you probably want to have /var on a separated partition so that you can keep your data as is.
As Hristo said, you only need to re-provision if you want to use this mechanism to update your system config but you may also use other means to do so.
It looks like you are using uCore. At the end of the section from the link you provided in your previous post, it says:
Note
zincati fails to start on all systems with OCI based deployments (like uCore). Upstream efforts are active to develop an alternative.
Since I don’t have a uCore deployment at hand, I’m not sure if this is the cause of Zincati’s failures. I also noticed that your uCore version is outdated. I’m not sure why you’re still on version 40.20240416.3.1, but I would recommend that when the Zincati issue is resolved, you update your system to the latest release.
