all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: rendaw <7e9wc56emjakcm@s.rendaw.me>
To: help-guix@gnu.org
Subject: Re: disk-image and partitions
Date: Wed, 17 Apr 2019 05:40:04 +0900	[thread overview]
Message-ID: <bf6cfe41-1fdc-4c1b-f576-a1a353362704@s.rendaw.me> (raw)
In-Reply-To: <0e3e6cfb-c538-3b25-0692-aad961282476@s.rendaw.me>

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

  reply	other threads:[~2019-04-16 20:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-14  9:16 disk-image and partitions rendaw
2019-04-16 20:40 ` rendaw [this message]
2019-04-21 13:38   ` rendaw
2019-05-05 18:48 ` Chris Marusich
2019-05-07  2:10   ` rendaw
  -- strict thread matches above, loose matches on Subject: below --
2019-04-15 11:22 rendaw

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bf6cfe41-1fdc-4c1b-f576-a1a353362704@s.rendaw.me \
    --to=7e9wc56emjakcm@s.rendaw.me \
    --cc=help-guix@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.