http://bugzilla.suse.com/show_bug.cgi?id=1156441 Fabian Vogt <fvogt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |iforster@suse.com -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1156441 http://bugzilla.suse.com/show_bug.cgi?id=1156441#c2 --- Comment #2 from Fabian Vogt <fvogt@suse.com> --- (In reply to Michael Chang from comment #1)

(In reply to Fabian Vogt from comment #0)

...

Some grub2 configs rely on being able to read and write certain environment variables (like health_checker_flag), but this only works if grub2-editenv was called previously. grub2-install should take care of setting up the env_block for systems which need it, if it doesn't exist yet.

The real usage of grubenv is really out of control by the grub-install as it is specific to application by dropping it's own snipped to grub-mkconfig or via custom.cfg to source it somewhere.

Yes, that's exactly my point. grub2-install does not how how and whether grubenv is used, so it has to make sure that it is fully available. Without initializing env_block, that is not the case.

If I remember correctly Ignaz has a solution to the health_checker_flag issue by using a writable subvolume in combination of grub script snippet. Would this be related or we are having other issue ?

It's tangentially related, having grubenv moved below /boot/writable allows initializing env_block even with a read-only /boot. grub2-install isn't called from that context though, so that shouldn't really matter. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1156441 http://bugzilla.suse.com/show_bug.cgi?id=1156441#c4 --- Comment #4 from Ignaz Forster <iforster@suse.com> --- (In reply to Michael Chang from comment #3)

(In reply to Fabian Vogt from comment #2)

...

(In reply to Michael Chang from comment #1)

...

If I remember correctly Ignaz has a solution to the health_checker_flag issue by using a writable subvolume in combination of grub script snippet. Would this be related or we are having other issue ?

It's tangentially related, having grubenv moved below /boot/writable allows initializing env_block even with a read-only /boot. grub2-install isn't called from that context though, so that shouldn't really matter.

I am confused as this seems to conflict with "grub2-install should take care of setting up the env_block for systems ..." from description above. Here you are with "grub2-install isn't called from that context though, so that shouldn't really matter."

The problem is imho a slightly different one: As long as the 'env_block' variable is not set it is not possible to write to the environment block from within GRUB with Btrfs. This means that at least on first boot it isn't possible to write any value there. On read-only root file systems we have the additional problem that we obviously can't force writing the file later (e.g. during first boot), so in the end we need a mechanism which makes sure grubenv is initialized properly during installation. At least that's how I understand Fabian's ticket. (The /boot/writable subvolume doesn't help here, as the env_block is only written to /boot/grub2/grubenv.) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1156441 http://bugzilla.suse.com/show_bug.cgi?id=1156441#c6 Fabian Vogt <fvogt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(fvogt@suse.com) | --- Comment #6 from Fabian Vogt <fvogt@suse.com> --- (In reply to Michael Chang from comment #5)

Hi Fabian and Ignaz

Thanks for the explanation, I am a bit getting on the track now.

What about setting up env_block in grub2-mkconfig ? Since it is mostly useful for grub.cfg which expected the path being /boot/grub2/grubenv, the feature/functionality could be self-contained rather than relying on separate grub2-install.

Please let me know if you have any concern for the idea ? Thanks.

I suppose that would work, but only if grub2-mkconfig is used. There are some cases (like until recently, kiwi generated images), which use grub2-install, but then put their own grub.cfg into /boot/grub2/grub.cfg, without calling grub2-mkconfig at any point. grub2-install is AFAICT the only binary which has to be called before grub can be used on a system, so it's the only place to ensure that grubenv is fully available during boot. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1156441 http://bugzilla.suse.com/show_bug.cgi?id=1156441#c8 Fabian Vogt <fvogt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(fvogt@suse.com) | --- Comment #8 from Fabian Vogt <fvogt@suse.com> --- (In reply to Michael Chang from comment #7)

Think it twice, I am still reluctant to patch grub2-install as the potential conflict in usage of /boot/grub2/grubenv with other application that expects it to be otherwise, like symlink or such.

grubenv should be managed by grub only, if other tools break it later that's IMO a bug in those tools. As long as grub2-install only creates grubenv with env_block if it didn't exist before, I do not see any problem here.

Shouldn't the application whichever requires the /boot/grub2/grubenv to run holds the responsibility to initialize it ? What's the difficulty doing that ?

I've got three reasons: 1. grubenv is a core feature of grub, which should always be available anyway 2. Only grub2-install knows where and how (btrfs vs. non-btrfs) to initialize it 3. How should applications do that? The rpm's %post script might not even run on the target system. This is the case for kiwi image builds for instance.

Thanks for your patience.

-- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1156441 http://bugzilla.suse.com/show_bug.cgi?id=1156441#c10 Fabian Vogt <fvogt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(fvogt@suse.com) | --- Comment #10 from Fabian Vogt <fvogt@suse.com> --- (In reply to Michael Chang from comment #9)

Alri(In reply to Fabian Vogt from comment #8)

...

(In reply to Michael Chang from comment #7)

...

Think it twice, I am still reluctant to patch grub2-install as the potential conflict in usage of /boot/grub2/grubenv with other application that expects it to be otherwise, like symlink or such.

grubenv should be managed by grub only, if other tools break it later that's IMO a bug in those tools. As long as grub2-install only creates grubenv with env_block if it didn't exist before, I do not see any problem here.

In my opinion there's no clear cut here as to what manages grubenv. It is an open storage file for persistent settings to grub.cfg. Any application or user could manage it through grub2-editenv, for initialization just calling "grub2-editenv create ..." or simply any command would silently initialize if not there yet.

Exactly that is not the case. To actually initialize env_block, one has to "grub2-editenv delete saved_entry". YaST sets saved_entry during installation "by accident", which is the only reason grubenv with env_block is actually there after regular installation.

...

...

Shouldn't the application whichever requires the /boot/grub2/grubenv to run holds the responsibility to initialize it ? What's the difficulty doing that ?

I've got three reasons:

1. grubenv is a core feature of grub, which should always be available anyway

But is also not mandatory .. as system could run without it. Certain function would require it and was created on an ad hoc basis.

Not necessarily. For health-checker to work properly, grubenv + env_block need to be there. Currently there's a nasty error message when booting images with health-checker installed. The system boots anyway as there's a timeout, but without health-checker support.

...

2. Only grub2-install knows where and how (btrfs vs. non-btrfs) to initialize it

I think grub2-editenv was taught to know how to do so.

Correct, but grub2-editenv is not called by grub2-install. That's what this bug report is about.

...

3. How should applications do that? The rpm's %post script might not even run on the target system. This is the case for kiwi image builds for instance.

How about calling "grub2-editenv create ..." or "grub2-editenv set key=val ..." in %post ?

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.

Thanks.

-- You are receiving this mail because: You are on the CC list for the bug.

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.

http://bugzilla.suse.com/show_bug.cgi?id=1156441 http://bugzilla.suse.com/show_bug.cgi?id=1156441#c14 --- Comment #14 from Michael Chang <mchang@suse.com> --- (In reply to Ignaz Forster from comment #12) [snip]

...

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.

This also made me confused, as the writable /boot/writable seems to be enough to overcome the ro snapshot that grubenv with $env_block could be directly created on. What's the reason it's not proceeded ? [snip]

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.

OK. As it really sounds no other way out here then I'll try patch grub-install. I will let you informed once any progress made. Or ping me if you need anything from me. Thanks. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1156441 http://bugzilla.suse.com/show_bug.cgi?id=1156441#c17 --- Comment #17 from Ignaz Forster <iforster@suse.com> --- In bug 1126900, comment 14 I may have found a solution to mitigate the read-only root file system specific problem mentioned in comment 4: Linking the grubenv file to a writable subvolume would make it possible to write the 'env_block' variable when calling grub2-editenv. However this approach also doesn't solve the problem that GRUB is not able to write an environment variable until grub2-editenv has been called from userspace at least once. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1156441 http://bugzilla.suse.com/show_bug.cgi?id=1156441#c19 Michael Chang <mchang@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(iforster@suse.com | |) --- Comment #19 from Michael Chang <mchang@suse.com> --- (In reply to Ignaz Forster from comment #17)

In bug 1126900, comment 14 I may have found a solution to mitigate the read-only root file system specific problem mentioned in comment 4: Linking the grubenv file to a writable subvolume would make it possible to write the 'env_block' variable when calling grub2-editenv.

Would you please provide more detail as it sounds the grub2-install should now create symlink to the grubenv in writable subvoulume rather than regular file as plain /boot/grub2/grubenv ?

However this approach also doesn't solve the problem that GRUB is not able to write an environment variable until grub2-editenv has been called from userspace at least once.

Would you please check comment#18 for the test package ? IIUC you are also looking for the $env_block to be initialized by grub2-install that the bug report is all about, despite the regular file vs symlink not yet clear to me. Thanks. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1156441 http://bugzilla.suse.com/show_bug.cgi?id=1156441#c21 --- Comment #21 from Michael Chang <mchang@suse.com> --- (In reply to Ignaz Forster from comment #20)

(In reply to Michael Chang from comment #18)

...

Here the test package for grub2-install to set up $env_block in grubenv file, Would you please take some time to test if it works as expected ?

https://build.opensuse.org/package/show/home:michael-chang:bsc:1156441/grub2

I just rebuilt the images with your modified grub version - everything expected by this patch is working perfectly fine now: * The grubenv file is present in the image with the env_block variable set. * Due to this variables can be set in GRUB also during first boot. * Modifying the variable with grub2-editenv in the running system still works.

Thanks for the testing and quick turnaround. I will commit it to factory if my other test doesn't have problem.

Thanks a lot!

The other ticket is more or less independent of this patch: On read-only systems it may still be a good idea to be able to write the grub environment block. To make this possible the idea is to put the grubenv file onto a separate writable partition. I've currently implemented this using a subvolume called "/boot/writable", which will be created on read-only systems only, linking /boot/grub2/grubenv to /boot/writable/grubenv. This would be working in theory, but unfortunately KIWI deletes any files called /boot/*/grubenv, so this is not working for our images. On the other hand the solution is quite hacky (requiring to generate a GRUB script to run before the 00_header) and creates differences between a read-only and a read-write system, so I'm not really keen to keep it. A saner solutions seems to be to make grub2 use a different directory for grubenv from the beginning and uniformly for all systems (e.g. /boot/var). If you are not opposed to this I'd just develop a prototype to demonstrate what I mean.

Well. I think it inevitable to patch or supply new grub scripts for looking up the grubenv in different directory. And to have grub-editenv to work uniformly it seems symlink is better (like other distor did/does). Anyway having prototype is a good idea to help understanding mutually. Thanks. -- You are receiving this mail because: You are on the CC list for the bug.