0

The idea is to have a docker image, or something similar, where I configure a whole bunch of hardware-unrelated things, and then deploy that to an actual device like a raspberry pi or plain x64 server.

I'm assuming this is not possible to do it this straightforward, since docker has some virtualized hardware that will mismatch the target? And I don't want to run a docker-image in a container on a fresh linux install, I need everything to run native.

Can someone point me in the right direction how to achieve this, what kind of dev-ops software I should think of when starting this. Other than making a few install-scripts and copying over the configs (which is what is basically pretty much is really).

Where I want to get is to have a restore-image, that I preferably am configuring in a virtual machine, en then have a starting point where I install that image on (virtually) any hardware and it will boot...

Or do I have misconceptions on how linux handles changing hardware? (I have bad experience with GPUs changing)

(Looking around it seems like docker is the best and most sensible solution for this, using docker export, but I'm curious if there are even simpler solutions, perhaps a program that can export the specific applications/configs that I specify, instead of manually writing a script, not because lazy, but because of human error)

Improve this question
2
  • 2
    Docker is not a virtualization technology. Docker is a application containerization technology. Containers in Linux built out of ID namespaces carved within the same "host" kernel, so there is no performance penalty. There is no "emulated hardware". Which also means that images for amd64 and for arm (Raspberry Pi) will be different, since they contain binaries compiled for certain target architecture. Best start is to try. Learn Kubernetes (which is used to run Docker containers in production). Commented Jul 12, 2022 at 8:51
  • 3
    It’s quite a leap to go from a single proof-of-concept showing how to create a bootable image from a container, to “docker is the best and most sensible solution for this”… Could you edit your question to reframe it, ignoring the pre-conceived Docker solution, and give some idea of the customisation goals you have in mind? If you have an idea of your target distribution that would help too, and your exact platforms (you won’t really be able to build a single image for a Pi and an x86 system). Commented Jul 12, 2022 at 8:57

1 Answer 1

Reset to default
1

I assume that what you are looking for is a way to "clone" an image of the installed system with applications, configuration etc.) to a different machine (actual bare-metal hardware, not a virtual machine).

So you should start off also with real hardware as the source, not a virtual machine or Docker container. Install everything you need on that machine, but try to avoid installing device-specific third party drivers. If you can stick to the drivers that are automatically provided by the kernel, there are quite big chances your image will run on another machine. Of course it needs to be the same architecture, so if you want to build an image for x86, you need a x86 machine, and if you want to build an image for Pi, you need a Pi.

Then you can use Clonezilla to make a disk image and then restore that image on another machine. However, Clonezilla is available for x86 machines only, not for Pi.

Another method is to dd the whole disk (as a raw device) to a file on external drive/USB stick and restore that image file on another machine (writing to raw disk device again), but there is a limitation that you need to have identical size disks in both machines - otherwise I don't expect the cloned system to boot at all. Of course you need to do this after the machine (either source or target) is booted from a live medium, so that the OS on disk is not active (in case of target machine it's not present at all, so the only way to boot is from a live medium).

Most "hardcore" method, requiring quite a lot of work (but you can use this method to clone your system to a machine with a much bigger disk) is to tar the whole filesystem(s) on disk (also after booting from live medium) and unpack them to appropriate partition(s) on target machine (after manually creating the partition(s), of course). After this, you need to adjust the /etc/fstab file (as the partition UUID(s) usually will be different) and install the bootloader on the target machine. I have "cloned" working systems several times using this method, when we replaced servers with more powerful hardware.

Warning: If the machine has a statically configured IP address(es), the "cloned" target machine will have the same address(es) - you have to change them manually. In case of some systems, you have also to delete some files from /etc/udev/rules.d (the ones that have "persistent" in their name) to make udev "forget" the devices from the old machine and detect them again on next boot - otherwise, you could have problems for example with network interfaces not present (as in this example)

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.