http://bugzilla.suse.com/show_bug.cgi?id=1156441 http://bugzilla.suse.com/show_bug.cgi?id=1156441#c12 --- Comment #12 from Ignaz Forster <iforster@suse.com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.