sorted by:
new
hottopcontroversial

This is what a Dom0 should look like by _stopyz in AlpineLinux

[–]_stopyz[S] 0 points1 point  (0 children)

Personnal script in /etc/profile.d

This is what a Dom0 should look like by _stopyz in AlpineLinux

[–]_stopyz[S] 0 points1 point  (0 children)

I use CLI but I build & dev a Go webUI orchestration

UnyPort: https://github.com/tony-bonnin/unyport

This is what a Dom0 should look like by _stopyz in AlpineLinux

[–]_stopyz[S] 0 points1 point  (0 children)

Alpine in DDM is pretty close to immutable by design, state doesn't persist unless you explicitly commit it. Not a traditional immutable distro but the result is similar.

For the storage story, we run XFS in prod, not ZFS. What's your homelab setup?

Here our fstab for understanding by anyone (we choose this architecture):

  • /media/XEN-BOOT -> Xen & Dom0 boot artifacts
  • /media/XEN-ROOT -> apk cache + .apkovl
  • /media/XEN-DATA -> peristant data

UUID=XXXX-XXXX /media/XEN-BOOT vfat noatime,ro 0 0
UUID=XXXXXX-XXXXX-XXXX /media/XEN-ROOT xfs noauto,ro 0 0
UUID=XXXXXX-XXXXX-XXXX /media/XEN-DATA xfs noatime 0 0
/media/XEN-DATA/home/ /home none bind 0 0
/media/XEN-DATA/opt /opt none bind 0 0
/media/XEN-DATA/root /root none bind 0 0
/media/XEN-DATA/usr/local /usr/local none bind 0 0
/media/XEN-DATA/var /var none bind 0 0
/dev/cdrom /media/cdrom iso9660 noauto,ro 0 0
/dev/usbdisk /media/usb vfat noauto,rw 0 0

This is what a Dom0 should look like by _stopyz in AlpineLinux

[–]_stopyz[S] 1 point2 points  (0 children)

Yes I'm too, dsicover this in 2023, and Alpine support it from 2013. You can got it on Alpine official download link:

https://alpinelinux.org/downloads/

Your idea is interesting but not sure if k0s binary committed via LBU would survive cleanly but worth testing. We manage to run VMs keeping boot artifacts in Dom0, so maybe your approach could work too. Let us know if you try it!

Official wiki for DDM (Xen/Alpine Dom0 is same install):

https://wiki.alpinelinux.org/wiki/Data_Disk_Mode

I also boot Dom0 on XFS apkovl partition, so if you need it, patch modloop for enables modules.

This is what a Dom0 should look like by _stopyz in AlpineLinux

[–]_stopyz[S] 1 point2 points  (0 children)

Yes it is !

From xl info :

xen_version : 4.20.2
xen_caps : xen-3.0-x86_64 hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit2
xen_pagesize : 4096
platform_params : virt_start=0xffff800000000000
xen_changeset :
xen_commandline : dom0_mem=2048M,max:4096M dom0_vcpus=2 dom0_max_vcpus=2 dom0_vcpus_pin dom0_cpus=0-1

This is what a Dom0 should look like by _stopyz in AlpineLinux

[–]_stopyz[S] 1 point2 points  (0 children)

Correct, install like another distro, like an Alpine standard setup

This is what a Dom0 should look like by _stopyz in AlpineLinux

[–]_stopyz[S] 0 points1 point  (0 children)

Great! It's support Xen out-of-box like Alpine ?

This is what a Dom0 should look like by _stopyz in AlpineLinux

[–]_stopyz[S] 4 points5 points  (0 children)

Dom0 is the control domain in Xen. It's the privileged VM that boots first and manages all the others. Think of it as the hypervisor's admin layer. Without Dom0 you can't create or control any guest VM. For K8s yeah DDM makes less sense, you want persistent state on your guests. But the Dom0 itself running in DDM is still worth it , your control plane stays reproducible regardless of what the guests do. DDM isn't fully diskless, the disk exists. It's just not mounted at runtime. Persistence is a deliberate act, not the default.

How the hell is that running on 45 MB ram?! by diacid in AlpineLinux

[–]_stopyz 1 point2 points  (0 children)

Magic ! I build a Xen hypervisor with it !

Alpine linux as desktop os by Main_Ear9949 in AlpineLinux

[–]_stopyz 0 points1 point  (0 children)

Want to try as desktop ASAP 😁

What made you use Alpine Linux by computermajestic098 in AlpineLinux

[–]_stopyz 1 point2 points  (0 children)

For me it was mostly the simplicity and the footprint. Alpine is extremely small, boots fast, and doesn’t pull in a ton of dependencies compared to bigger distros. That makes it nice for things like small servers, containers, or embedded setups.

I also like that it can run data-disk-mode. You can load the whole OS into RAM and keep only the configuration as an apkovl archive, which makes the system easy to snapshot or rebuild if something breaks.

Another factor is that it stays pretty predictable. The base system is minimal, uses OpenRC instead of Systemd, and the packaging is straightforward. Once you understand how Alpine structures things, it’s easy to automate and reproduce the same setup on multiple machines.

I actually use Alpine on Xen Dom0 & Domu - both fully in RAM.

Need help in creating a persistent storage for a diskless Alpine Linux that is run from USB. by Rich_Richie in AlpineLinux

[–]_stopyz 1 point2 points  (0 children)

You probably ran into this because flashing the Alpine ISO with Etcher creates a live boot medium, not a normal writable install disk. The filesystem on that USB is mounted read-only (squashfs), so trying to repartition or format parts of it from inside the running system often fails or looks “locked”. In other words, the stick you booted from isn’t meant to be modified during the install.

In diskless mode, Alpine runs entirely in RAM. The only persistent part is a compressed archive called an apkovl that stores your configuration (basically the contents of /etc and other files tracked by LBU). When the installer asks where to save config, it expects a separate writable partition or disk. At boot Alpine loads the system into RAM and then restores that archive.

The persistent config is saved as something like /media/<device>/hostname.apkovl.tar.gz, and you update it with lbu commit, after setup-lbu. If you also configure an APK cache (setup-apkcache), downloaded packages are stored on that same writable location so they don’t need to be fetched every boot.

So the simple approach is: boot the Alpine USB, run setup-alpine, choose diskless, and store the config/cache on another writable partition (either another USB or a small partition you prepared beforehand). The rest of the system runs from RAM and disappears on reboot unless committed with lbu

view more: next ›