disk-image and partitions

disk-image and partitions

[rendaw]

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!

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

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.

Re: disk-image and partitions

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 959 bytes --]

rendaw <7e9wc56emjakcm@s.rendaw.me> writes:

> 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!

You had a lot of questions, and it's been a couple weeks.  Were you able
to get all your questions answered, or is there still something you need
help with?

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: disk-image and partitions

[rendaw]

On 5/6/19 3:48 AM, Chris Marusich wrote:
> rendaw <7e9wc56emjakcm@s.rendaw.me> writes:
>
>> 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!
> You had a lot of questions, and it's been a couple weeks.  Were you able
> to get all your questions answered, or is there still something you need
> help with?
>
Thanks, I think I've managed to figure this out.  For anyone reading the
thread I've put my findings in
https://gitlab.com/rendaw/blog/blob/master/how_to_guix_for_those_who_dont.md

disk-image and partitions

[rendaw]

So it looks like the root uuid might be generated, but from what I read
vfat uuids are translated from a partition serial number that isn't
manipulated in the guix source so getting uuids beforehand might be
impossible.

Both the root and efi partitions get a label, so I might be able to use
those to identify the partitions.  They're both hardcoded, but the
former is unstable (was changed earlier this month) and the definition
that exposes it (root-label) isn't exported...

I think my best choice here is to forcibly import "root-label" and
duplicate the hardcoded "GNU-ESP" in my config, but if the latter
changes I'll get an error at runtime rather than build time.

How would disk-image work in the first place?  It doesn't look like the
generated GNU-ESP or / are added to fstab automatically (checking the
output image).