http://bugzilla.suse.com/show_bug.cgi?id=1126900 http://bugzilla.suse.com/show_bug.cgi?id=1126900#c10 --- Comment #10 from Michael Chang <mchang@suse.com> --- (In reply to Ignaz Forster from comment #9)
(In reply to Michael Chang from comment #8)
Scratch that - It has been done already according to the changelog. I'm sorry for not keeping it up correct on my mind
No problem, thanks for taking care of it!
Now I am getting to understand your proclaim as this could be "just a cosmetic problem" .. The next question is do you need anything from me in order to close the ticker here ?
That's a good question, as I'm not sure what the best way to solve this problem would be.
My hesitation is partially caused by the fact that while playing around with our KIWI images I discovered another directly related problem: KIWI do not contain /boot/grub2/grubenv at all. Even on regular installations it is more or less a side effect that /boot/grub2/grubenv is generated at all *during installation*: In https://github.com/yast/yast-bootloader/blob/master/src/lib/bootloader/ sections.rb#L46 `/usr/sbin/grub2-set-default` is called. That script will in turn call `grubenv unset ...` towards the end, which will incidentally trigger the generation of the grubenv file. That doesn't seem to be a conscious creation of the file...
Now what's happening if the file isn't there? On rw file systems the file will just be created if one of a small set of accepted variables is set / deleted. On ro file systems the file obviously can't be created retroactively. grub2-editenv doesn't like that at all and will abort before even trying to write to the btrfs header. So with read-only root files systems we not only have that cosmetic problem, but writing the variables may fail completely.
IMHO the motivation of introducing external block is to workaround the inability of writing to btrfs filesystem's block, but if the file /boot/grub2/grubenv itself is read-only then its application is beyond the scope. In general it means all features require writing to /boot/grub2/grubenv will fail and I would treat that as a different thing - We have to seek for another location for writable environment block and btrfs header turns out to be a candidate (again) for it. And if it doesn't require any writing from grub, we can also choose to pick another location writable by the linux system. The next question is "Does health-care require grub to write to the health_checker_flag?" Because I did not see it happening in existing grub.cfg.
I can currently see the following options to solve this:
1. Most obvious fix - Don't print the error message in grub2-editenv if the data was written into the btrfs meta data successfully. - Make sure that KIWI is somehow triggering the generation of grubenv. Pro: simple to fix in grub2-editenv
In any case, I think we have to fix the ro error message as it did not make sense when the attempt is for writable external block.
Con: Shouts "hack" loudly; KIWI's code isn't really prepared for this, as on UEFI system it's just copying the modules without even calling `grub2-install` (Note: I just realized that Yomi also added that call to `grub2-set-default`); no generic solution, but works for all *SUSE use cases
Yes. I could share their feeling but we know life isn't perfect.
2. Use different path for grubenv - Use another location which we know will be writeable, e.g. `${config_directory}` if it's set and `${prefix}/${grub_cpu}-${grub_platform}/grubenv` (which may translate to /boot/grub2/i386-pc/grubenv or /boot/grub2/x86_64-efi/grubenv on x86) otherwise. Con: Needs migration; avoids snapshotting of GRUB environment variables (but that may even be desired?); also a hack, there's no guarantee those directories will stay writable
3. Use different path for this one variable - Like 2, but only save this one variable into a different file - Package would create an additional GRUB config file Pro: May be minimally invasive and still work?
IMHO #2 and #3 are more or less the same as we are pointing grub for another grubenv in the grub.cfg. And grub doesn't care what's inside the new grubenv because it simply loads all variables from it. Personally prefer this solution than the rest although it will require additional GRUB config file. I am thinking if we could just drop a new /etc/grub.d/01grubenv_dir with custom path to file grubenv.
4. Store grubenv in "BIOS boot" / "EFI System" or custom GRUB partition - The current GRUB environment block implementation has several limitations (i.e. doesn't work with LVM, software RAIDS or some file systems); it may be worth rethinking on how it could be stored more universally. - It may be possible to use the "BIOS boot" / "EFI System" partitions for it if available. Pro: May provide a clean, distribution independent solution, without any hacks Con: Lots of work and discussion necessary
IMHO the "BIOS boot" is way off, as noone will take care of cleaning it up and its inadvertent residuals could have side effect. Also the bios boot is a open common disk property thus it become hard to maintain local data laid on it. The EFI System may work, but it is specific to EFI and we still end up with the same trouble on other types of firmware.
Did I miss any options?
For LVM install, it used to have a proposition to use reserved area in LVM physical volumes, but grub2 upstream did not accept it and since the joint development was not public we have little clue for what have gone wrong. -- You are receiving this mail because: You are on the CC list for the bug.