I do, but I am not entering btrfs-specific stuff yet. I partitioned the disk, and I failed to format partition 1 into EFI system partition. The error message says /dev/vda in question is mounted and the resource is busy.
If there's nothing on the disk yet, unmount all partitions (umount /dev/vda*) and start over with the partitioning. The fdisk which comes with the standard Alpine ISO is very limited. Install a more complete partitioning tool as described on the second page I linked in my previous comment. You can also format the hard disk in the server control panel to start with a clean slate.
If there's nothing on the disk yet, unmount all partitions (umount /dev/vda*) and start over with the partitioning. The fdisk which comes with the standard Alpine ISO is very limited. Install a more complete partitioning tool as described on the second page I linked in my previous comment. You can also format the hard disk in the server control panel to start with a clean slate.
Well I might have found the reason https://helpcenter.netcup.com/en/wiki/server…ning-kvm-server. I'd better to format in the rescue mode then.
Thank you for your reply, but it was not really the issue of the partition tool in my case.
You only need to boot a different OS if you need to modify partitions that the installed OS is using. If you're just installing Alpine, you can do that from the installer ISO just fine. Make sure you don't upload the ISO as a hard disk image in the server control panel. In that case the system will indeed boot from the hard disk and keep you from repartitioning it. Upload the ISO in the DVD drive section and insert it into the virtual DVD drive, enable booting from DVD and then you'll be able to partition the hard disk and install to it. Format the hard disk from the server control panel to make sure that the system will not boot from the Alpine image you copied to it previously.
If you are planning to run more than one server with Alpine, I can also recommend the following (this is what I do): https://github.com/alpinelinux/alpine-make-vm-image
With the script you can simply create a ready-to-use qcow2 image and then upload it in scp and use it again and again. This way you only have to do the installation once. This is a bit annoying with an ISO if you have to do it more than once. The script also works perfectly with btrfs.
If you are planning to run more than one server with Alpine, I can also recommend the following (this is what I do): https://github.com/alpinelinux/alpine-make-vm-image
Sorry, wenn ich den Thread kapere. Wie ist der Verwendungszweck eines solchen Alpine Servers? Ist das ein Barebone OS für nur eine Anwendung mit möglichst wenig Overhead? Oder die kleinstmögliche Dockerumgebung? Ich verwende bisher nur Alpine in Docker (FROM), aber auf nen Server hab ichs jetzt noch nicht installiert.
Sorry, wenn ich den Thread kapere. Wie ist der Verwendungszweck eines solchen Alpine Servers? Ist das ein Barebone OS für nur eine Anwendung mit möglichst wenig Overhead? Oder die kleinstmögliche Dockerumgebung? Ich verwende bisher nur Alpine in Docker (FROM), aber auf nen Server hab ichs jetzt noch nicht installiert.
Letztendlich ist Alpine ja auch nur eine Linux Distribution unter vielen, wenn man mal von der musl libc und openrc absieht. Ich nutze Alpine vor allem als Kubernetes Node. Davon habe ich einige. Hier zahlt sich durchaus aus, dass Alpine so klein und schlank ist. Man kann das daher viel schneller deployen als ein Full Bloat OS wie Debian oder Fedora und auch die Updates/Reboots gehen im Vergleich super schnell. Es ist aber im Gegensatz zu anderen speziellen K8s OS (z.B. Talos) immer noch eine richtige Linux Distribution mit einem richtigen Paketmanager, damit man hier auch dem Node entsprechende Zusatzdienste installieren kann (z.B. Monitoring Agents).
Ich habe aber auch Mailserver mit Alpine. Das funktioniert ebenfalls wunderbar. Vor allem, da Alpine ein recht umfangreiches Repository bietet. Da findet man einige Pakete, die man in Debian, RHEL oder Fedora vergeblich sucht oder auf 3rd Party Quellen angewiesen ist.
Aber das ist wie so oft eine subjektive Einschätzung. Ich würde niemanden überreden wollen, dass er sich das anschaut oder sogar einsetzen soll. Denn man muss mit den Sonderheiten auch klar kommen. Wenn man sich über die Jahre an systemd gewöhnt hat, dann ist ein Umstieg auf openrc wirklich nicht einfach. Im Container merkt man das nicht, da man dort ja keinen Service Daemon hat. Ich kenne openrc noch aus meinen früheren Gentoo Jahren. Daher war es für mich dann doch einfacher. Es ist halt vor allem für die interessant, die wirklich das KISS Prinzip auf dem OS (ausprobieren) wollen.
Danke für die ausführliche Antwort. Also im Prinzip eine Art "Bare Metal" ContainerOS mit added bonus Paketmanager. Verstehe. Als 25 Jahre langer Debian User würde ich mich wohl schwer tun, aber ich seh die Vorteile. Und wenn da sonst Container laufen, kann das OS so schlank wie möglich sein.
