From mboxrd@z Thu Jan 1 00:00:00 1970 From: rendaw <7e9wc56emjakcm@s.rendaw.me> Subject: Re: disk-image and partitions Date: Wed, 17 Apr 2019 05:40:04 +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]:50622) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <7e9wc56emjakcm@s.rendaw.me>) id 1hGUsF-0001ge-H7 for help-guix@gnu.org; Tue, 16 Apr 2019 16:40:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <7e9wc56emjakcm@s.rendaw.me>) id 1hGUsD-0005MG-O2 for help-guix@gnu.org; Tue, 16 Apr 2019 16:40:11 -0400 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:38371) 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 1hGUsD-0005KT-5Q for help-guix@gnu.org; Tue, 16 Apr 2019 16:40:09 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 2510521B36 for ; Tue, 16 Apr 2019 16:40:08 -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 10A49103D7 for ; Tue, 16 Apr 2019 16:40:06 -0400 (EDT) In-Reply-To: <0e3e6cfb-c538-3b25-0692-aad961282476@s.rendaw.me> 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/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