Re: disk-image and partitions

[rendaw]

On 4/17/19 5:40 AM, rendaw wrote:
> 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

I think I have an answer to the first couple new questions:

Thanks to Ludovic's suggestion in the other thread I tried out setting
(initrd) in (operating-system) to override #:volatile-root.

This doesn't do anything, because disk-image overrides initrd with a
forced-volatile version.  It has a `#:volatile?` parameter but I
couldn't find this exposed anywhere.  It doesn't seem possible to create
a RW system from a disk image.

But digging around in the source code I think volatile-root: #t is what
I want.  I didn't realize that when the docs say that changes will be
discarded that's _all_ changes, including package installation,
reconfiguration, and other guix commands.