From mboxrd@z Thu Jan 1 00:00:00 1970 From: rendaw <7e9wc56emjakcm@s.rendaw.me> Subject: Re: disk-image and partitions Date: Sun, 21 Apr 2019 22:38:19 +0900 Message-ID: References: <0e3e6cfb-c538-3b25-0692-aad961282476@s.rendaw.me> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([209.51.188.92]:59069) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <7e9wc56emjakcm@s.rendaw.me>) id 1hICfu-0006d9-Ry for help-guix@gnu.org; Sun, 21 Apr 2019 09:38:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <7e9wc56emjakcm@s.rendaw.me>) id 1hICfs-00079J-V1 for help-guix@gnu.org; Sun, 21 Apr 2019 09:38:30 -0400 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:59985) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from <7e9wc56emjakcm@s.rendaw.me>) id 1hICfr-00075L-3A for help-guix@gnu.org; Sun, 21 Apr 2019 09:38:27 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 3C57F210A8 for ; Sun, 21 Apr 2019 09:38:23 -0400 (EDT) Received: from [192.168.1.35] (y236169.dynamic.ppp.asahi-net.or.jp [118.243.236.169]) by mail.messagingengine.com (Postfix) with ESMTPA id 31DE1103C9 for ; Sun, 21 Apr 2019 09:38:21 -0400 (EDT) In-Reply-To: Content-Language: en-US List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: help-guix@gnu.org 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.