Re: disk-image and partitions

[rendaw]

On 4/14/19 6:16 PM, rendaw wrote:
> I think I'd like to use disk-image but a number of things were unclear
> from the documentation:
>
> 1. What and how many partitions are created?
>
> Reading the -t parameter I assume it's an image with just 1 root
> partition. If I need UEFI will an efi partition be created?
>
> 2. How can I refer to the created partitions in the config?
>
> Digging through the source it seems that in some modes of operation the
> root partition is automatically created and there's a local uuid value
> that's generated and shared between the partition + filesystem config,
> but I didn't see that exposed anywhere.
>
> I have various additional storage attached so I can't guarantee device
> order (sda/sdb/sdc).
>
> Thanks!


1. Two partitions are created - root and ESP.  ESP is hardcoded, root
type depends on the -t parameter.

2. Actually, the root partition is discarded (silently!) by disk-image,
and a new root partition definition is created which refers to the uuid
of the created filesystem.  This is a bit scary, because I might have
disk options I want to pass through

---

So after digging for a while it looks like the root filesystem on boot
(just with disk-image?) is mounted read only, then a tempfs mount is
placed on top of it with overlayfs.  Essentially, the root mount and
system configuration is read-only and any modifications are discarded on
reboot.

The filesystem is assembed in /root and then the boot process chroots
into /root.  Running mount at this point returns a bunch of gibberish like:

```

none on /proc

none on /dev

none on /sys

none on / type overlay

none on /gnu/store

```

I'm speculating here because I wasn't able to find an easy way to escape
the chroot to inspect the actual filesystem composition.

But even though /root is read only it's possible to upgrade the system? 
How does it do that if root is mounted RO?

Having some description to how the system works in the documentation
(rather than just the explanation of the programming interface) would be
really nice since guix is assembled so differently from other operating
systems.  Or maybe it's there and I couldn't find it?  I was
experimenting with the sample "Using the Configuration System" which
defines a root partition and a bootloader target, both of which are
invalid, but the system seems to build and run just fine (with
disk-image) which was a bit of a shock.

My goal is to run a RO system - packages can't be upgraded,
configuration can't be modified, binaries can't be installed (except
per-user).  It seems like this is very close to what I want.  In the
code I found a "volatile-root" parameter which suggests a RO root
filesystem if #f but AFAICT it's #t everywhere (that I could trace).  Is
there a way to do this?

I took away from what I found above that I should not define a root or
ESP partition in my configuration's file-systems section.  Seeing as
there seems to be absolutely no configuration for these parts, are there
any limitations to what sort of systems it can go on?

As a note, I've seen this in a couple places in the guix source, but it
would be super super helpful if instead of ignoring invalid
values/configurations the build process raised an error.  Ex: root
partition definitions when running disk-image, invalid -t values