[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: disk-image and partitions
Re: disk-image and partitions
Sun, 21 Apr 2019 22:38:19 +0900
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3
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).
> 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
> 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.