search

systemd / mkosi

💽 Build Bespoke OS Images
https://mkosi.systemd.io/
1.18k stars 319 forks source link

Use block device or new command #239

Closed lucasdemarchi closed 4 years ago

lucasdemarchi commented 6 years ago

In one of the cases in which I use mkosi is to create an image, copy it to a usb drive and then test on another machine. This has the limitation that I need to keep huge image files on my disk. In the past when I did arch-installer there was support to use a block device exactly because of this issue. In this case instead of creating the loop device it would use whatever was passed, e.g. /dev/sdb.

What I'm using right now that mkosi doesn't support this is to have a separate script to expand the / partition in the final drive (a little bit hacked to my partition layout): https://gist.github.com/lucasdemarchi/543800b28cf061258abc813d1dccb489

So now I'm not sure if it would be better to accept a block device as argument or if we could have a "flash" command that would take the output and dd it to the final destination, possibly expanding partitions.

thoughts?

poettering commented 6 years ago

Two things:

  1. Yes, adding this makes a lot of sense, there's already an RFE about this: #128. It's also listed in this super-brief TODO list embedded into the script itself... (I figure we should remove that TODO list from there though, and just either turn everything that's left from that list into RFE issues, or maintain a separate TODO file in the git repo).

  2. @keszybz and I discussed adding a proper framework to expanding partitions like that on boot to systemd itself. In fact part of it already landed: with the x-systemd.growfs mount option you can tell systemd to automatically extend a file system to its partition size on boot, right when mounting it. The second part is still missing though: a small component that during boot looks for a drop-in directory which contains definitions for partitions that shall either be created or resized.

poettering commented 6 years ago

Implementing #128 is not totally trivial, when it comes to supporting the incremental mode and for the squashfs case. But it shoulde definitely by done

lucasdemarchi commented 6 years ago

I didn't know about (2). That's indeed interesting. I'm not sure about the approach during boot though. What happens if you first boot it as a VM? I know about ConditionVirtualization, but virtualization could very well be the final state as well.

I think one of the alternatives I raised may be easier and is neither (1) or (2). I'm thinking about a flash command that would take the image produced and use either dd or bmap to copy it to another device. Since we already have the partition information in the script we know what the end format should be.

I do see value in the growfs mount option that I didn't know about, but I'm not 100% convinced it's the best approach for what I'm looking for.

r-darwish commented 6 years ago

@poettering is it really necessary to have an auto expand framework on boot? If mkosi is invoked on a block device then it can know the real size of the device during the build.

shibumi commented 4 years ago

@r-darwish this works only if your target block device is the device where you want to have your image.

I have a special use case. I want to make small images (500mb) or even less, then I want to copy these images to a much larger harddisk and then I want them to be resized on first boot.

This is an interesting usecase for linux distribution releases. Just imagine that you don't need to 'install' your favourite linux distribution anymore, instead it could be as easy as: curl https://getlinux.com/image && dd if=image of=/dev/sda

DaanDeMeyer commented 4 years ago

Let's close this as a duplicate of #128.