iximiuz / docker-to-linux Goto Github PK

Thanks for your code and great docs!

I'm using this to create some forensics practice disk images.

I found this repo early in my endeavor, however, I did not think it was the best choice to start with, surely Vagrant would be a better choice? (Perhaps for mainstream distros, but not for small distros) Surely installing something like tinycore from an ISO directly with vboxmanage would be the ticket? (It worked, but wasn't easily reproducible, and I didn't want to mess with my home network to connect the vm to the Internet). Well, maybe docker-to-linux will work?

And it did! and the image is even smaller than tinycore disk images *shuffles nervously*, but an image for forensic practice doesn't have to be perfect fidelity, and one can boot qemu off this image anyway, so it's pretty darn good!

Anyway, I thought you might be curious and pleased to know how I've been using this "for fun" project.

Just for your information Suse/Rancher activly works on a similar idea in a gitops approach.
See elemental-toolkit

• https://github.com/rancher/elemental-toolkit
• https://rancher.github.io/elemental-toolkit/docs/

Could be an interesting source of inspiration for your project.

Regards.

This is so weird, at the very end of the build (make ubuntu), something is calling rm ubuntu.dir (and failing), but I can't figure out what! Any ideas?

rm ubuntu.dirmake: unlink: ubuntu.dir: Operation not permitted
 ubuntu.tar

I've been trying to install docker in the alpine dockerfile, on my local copy of the repository:

FROM alpine:latest
RUN apk add --no-cache linux-virt openrc docker
RUN rc-update add docker boot
RUN echo "root:root" | chpasswd

The problem I have currently is that, when the VM boots, the docker service cannot start. It seems to be unable to create mandatory files:

I know that I can make the filesystem writeable and successfully start the service with this script:

mount -o remount,rw /
service docker start

However, I simply cannot afford to be forced to run this every time I want to use the image! Simply rebooting makes the filesystem read-only again...

Is there a way to tell qemu to mount the file system as rw, or update the image configuration from the builder container to automate this process?

Hi again Ivan,

Have you try putting your raw image onto real HD?

This line is the reason that I'm asking as the extlinux was the boot loader that I've been using for years, until it gave me the trouble when me duplicating system from one machine to another --

A I have my specific ways of doing things, I usually do a brand new installation in one machine, and fully customize it to my comfort, then rsync it to another machine. The problem is, the extlinux boots fine from the first machine but just refuse to boot on the second machine no matter what I tried. I even tried to exclude all its relevant files when doing rsync it to another machine, then do a brand new extlinux installation there. But my new extlinux still refuse to boot.

I really hope that you've tried it and find it not a problem. thx.

any idea what is the default user/password in ubuntu?

I can take a stab at this if it seems plausible.

Hi!,
I've been having trouble with these steps using a bigger disk size. Just changing count to 2 in sudo dd if=/dev/zero of=linux.img bs=${IMG_SIZE} count=2 break the image at boot time.

My custom debian image is a little bigger, like 2.5gb , but i've checked using the same debian:stretch used in this examples and when i try to create a bigger disk size, it breaks. (it works flawlessly with sudo dd if=/dev/zero of=linux.img bs=${IMG_SIZE} count=1

I've would like to know more details about the sizes in the bootable part of the disk so i can change virtual disk size at will.

Can you do the same with ubuntu 14.04 and grub2?

Would you make this ext4 please?

I think Debian choosing ext4 over ext3 says a lot about its advantages.
Please consider. thx

Observing the following issue when building the container:

#6 0.611 E: Package 'extlinux' has no installation candidate

$ make alpine

Fails with message like:

[Format partition with ext3]
mke2fs 1.43.4 (31-Jan-2017)
Discarding device blocks: done                            
Creating filesystem with 261888 4k blocks and 65536 inodes
Filesystem UUID: 603c1544-a156-4188-bcb4-aca0eccf23cb
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done


[Copy linux directory structure to partition]
mount: /dev/loop0 is write-protected, mounting read-only
mount: cannot mount /dev/loop0 read-only
Makefile:51: recipe for target 'linux.img' failed
make[1]: *** [linux.img] Error 32
make[1]: Leaving directory '/root/docker-to-linux'
Makefile:38: recipe for target 'alpine.img' failed
make: *** [alpine.img] Error 2

Any thoughts on this?

I know you mentioned this is in your TODO but I can't seem to get it to work on my end. I tried replacing the Debian AMD image with the equivalent arm64, but when It comes time to make the boot loader with extlinux, it fails because it's apparently not available. Do you have any advice on how to implement this? I went down a u boot hole but didn't get that working either. x86_64 works great tho

Hi Ivan,

I don't use tweeter, so let me put my practical use-case here.

I've been looking for such docker-to-linux solution for years, and I'll search for it every now and there, but only yesterday did I find your project in google. I think your project, after being existing for two years, is taking mainstream and is becoming top hits from google.

Congratulations!

If you’re aware of the real use of the docker-to-linux project, please drop me a message and share your experience.

For me, I'll be using it to automate my Debian system installation. It's only for my personal use, which varies dramatically from the massive system installation that enterprises use (like Vagrant etc), as I have my specific ways of doing things, like alias that I'be been using for decades. Not being able to get into my accustomed environment in a brand new machine is the "dark age" to me, and I need to get over that period as short as possible.

However, there aren't many ready-made solutions that has both the power and versatility that allows me to do that, as far as real HD is concerned. I.e,

• For VM, I use Debian Preseed installation
• For Docker, I use packer

But for real HD installation, when it is only a bare-metal that I have to install everything from scratch, that's truly a dark age to me, that's why I've been looking for such docker-to-linux solution for years.

Thanks!

First off, just want to say what you're doing with this is absolutely amazing!

Steps to reproduce:

make ubuntu

qemu-system-x86_64 -drive file=linux.img,index=0,media=disk,format=raw -m 4096

See image for the error:

It works fine on a Mac M1 but since it doesn't run in native mode, without acceleration, the result is a bit slow.

I try to get a working solution starting from your work with

• switching to arm docker image, for instance : FROM --platform=linux/arm64/v8 ubuntu:20.04
• specify EFI option for qemu-system-aarch64 following : https://www.sevarg.net/2021/01/09/arm-mac-mini-and-boinc/
• but I failed to install a bootloader to this image...

Has anyone tried with an arm version or has the information to build a bootable linux system for Mac M1?

Is there a way to make multiple partitions? I'd like to break up the drive into three different partitions

I want to make an OS that doesn't require any maintenance, because I believe system maintenance sucks.

I'm currently on XUbuntu 16.04 and I'm about to switch distribution. I have to wipe out all of my system data (yes, after a backup) because there's really old building-from-source clones, executables and whatnots on my drive, and I don't know where to begin the cleanup. Wouldn't it be great if I never had to cleanup or upgrade my distribution in the first place?

Maybe I'm daydreaming, but in order to achieve that, I've been thinking of using docker as a "package manager" for applications. Custom Dockerfiles and application data would be stored somewhere in the file system tree, where application binaries would only reside within docker images and containers. This idea makes me think about exo kernels, although exo kernels are lower-level and can technically support Windows and Linux applications concurrently without a virtual layer.

Now, about the "versionable" part in the title: backups can come in quite handy sometimes, and I like git for it's ability to roll back any change and keep an history of what happened in a repository. Wouldn't it be nice if I could version my system configuration and simply create a new bootable image in one line when my computer dies? To achieve this, I would store Dockerfile / docker-compose.yml files in a repository, along with their configuration files. Once I succeed to install an application in a docker image, I commit the image configuration to a new folder in my repository. If I ever have to run the app somewhere else, it's simple: just clone, build and run; perhaps even just pull from Docker Hub. If I ever want to completely remove an application from my disk, I can also simply do that with docker rmi.

Another advantage of this idea is that distribution specific packages could be installed without having to bring potentially incompatible configuration on my system. For example, it would be possible to use any pacman package along with any apt-get package, effortlessly.

However, how can I be sure that my system configuration never gets out of hand? For me, this is where docker-to-linux comes into play. It allows me to store the fundamental OS configuration as a dockerfile. It gives me full control over what's in my system, regardless of the depth of my knowledge about Unix-like operating systems, basic tools, bootloaders, partitions, initramfs, bios, assembly, etc.

Yes, I might encounter issues along this journey. For instance, docker images usually take a lot of space. There might not be a lot of images on Docker Hub that fit exactly my use case, forcing me to write a big bunch of custom docker files (and this looks like maintenance to me). Maybe something exists that already solves the issues mentioned above, and I just don't know about it. So I can't tell whether the advantages of this idea over traditional system maintenance would be worth it.

Hi and thanks for sharing your work,
I wanted to test this, but I always get

[Format partition with ext3]
losetup: /os/linux.img: failed to set up loop device: Device or resource busy
Makefile:51: recipe for target 'linux.img' failed
make[1]: *** [linux.img] Error 1

I ran the following cmd line

sudo make ubuntu

It also failed with the same message when doing

sudo make debian

I'm running on an ubuntu 18.04.
Did I make any mistake in calling your script?

Update: I already checked issue #1 and added '--privileged=true' but the error still came up.

Hi, this project looks great, and I'm curious if it's possible to run scratch images same way?
Let's say pure c printf to terminal and infinity loop, or just a standalone web server with all required dependencies included, excluding systemd and other unnecessary parts?