Comment # 12 on bug 1156441 from Ignaz Forster

Let me try to answer a few questions regarding the ro system; Fabian will be
able to give more details on the KIWI implementation side.

(In reply to Michael Chang from comment #11)
> Just to see my understanding correct, the reason for "need to be there" is
> the ro snapshot couldn't allow the file creation in ad-hoc basis, there has
> to be pre-allocated before snapshot is taken.

This is correct in the context of KIWI image creation. Creating the grubenv
file is not possible ad-hoc in the running system due the root file system
being read-only, so the file needs to be created before the system is booted
first. (But is also mustn't be created during the package installation phase,
see the last paragraph.)

> The peculiarity is that in ro
> snashot we are still able to write grubenv through env_block, but honestly I
> haven't tested this case would be free of error as it is really new ..

FYI: Setting the values in the env_block will work on a read-only root file
system, I tested that and it's currently in production ;-) The disadvantage is
that the command will still return with an error message, as the grubenv file
could not be modified, that's why I wanted to introduce the /boot/writable
subvolume. 

> > Point 3 is about why that does not work. Please explain how you would work
> > around %post not having access to the target btrfs filesystem.
> 
> Wouldn't the package installation, and hence the environment running %post,
> happen in target system ? Or is this a valid concern in transaction update ?

My understanding is that KIWI will install the system into an installation
environment and will only *later* copy the files to their final destination.
This, however, means that any package %post script do not see the real
installation device yet.