Found these two items:
Bug 1884042 - From Fed32, grub cannot boot Fed33 if Fed33 is installed with live defaults for btrfs and the reverse
@hedayat @javierm do I understand the issue correctly? And in the RHBZ comment 6 in particular, if that's a reasonable way forward or should we just be looking at solving this with BootLoaderSpec?
And then as it pertains to the release notes, how visible should this be? We could just CommonBugs the RHBZ with the work around described in the release notes issue. And/or I can give it a mention somewhere in the Btrfs by Default release note, as long as it doesn't make things too cluttered or complicated.
Metadata Update from @chrismurphy:
- Issue set to the milestone: Future Release
- Issue tagged with: Desktop, Dev
Oops, I'm sorry if I'm repeating myself here in some parts. Maybe I should answered here instead of fedora-docs/release-notes#560.
Well, first of all it seems that there are 2 completely different bugs: 1. Not recognizing F33 on btrfs by F32 or another F33. and 2. F33 cannot properly boot F32.
I wonder if the second one is related to btrfs at all. F32 is not on BTRFS, and that F33 itself is running on BTRFS should have nothing to do with how F32 is being found and configured. There can be a bug, and it is most probably not a new bug. So it probably shouldn't even go to CommonBugs. What I can guess is that it is related to BLS, as I think os-prober won't find proper kernel cmdline args in BLS config files. And actually, I think it shouldn't: BLS is there to remove the need for os-prober at all! So, this probably should be an unsupported config: since BLS came in Fedora, the supported method to boot multiple Fedora OSes should be using a shared /boot with BLS entries for all of them; so entries found by os-prober shouldn't matter at all. (BTW, note that currently BLS entries for F31/F32 use $kernelopts variable, which should be manually replaced with the actual value needed for booting them. Fortunately, it seems that F33 has started to not use this variable in its BLS config files, so it won't be a problem for later releases).
Well, looking at what I just wrote above, I'd say that it also applies to the other problem too: as we have BLS now, it is better for us to rely on that for booting multiple Fedora installations on a single system and to recognize it as the supported configuration. For any OS supporting BLS, ideally os-prober should not try to create any entry at all! But even if it does, they should be ignored by the user. This is the only reason BLS can be useful at all!
So, IMHO, the way forward for multi-Fedora systems should be BLS, not os-prober.
However, os-prober bug with regard to recognizing btrfs OSes probably can be followed separately too, but to fix booting non-BLS distros rather than booting other (modern) Fedora installations. Although, as I said in the bug report, it is all maintenance burden: os-prober upstream is almost dead!
@hedayat Thanks for the fast responses! If it's a btrfs specific problem we can talk about it here. In the meantime I see from bug 1884042 what info you need to figure out what's wrong. I'll try to reproduce in a VM.
But yeah I'm more inclined to tighten things up with BLS support, including in the installer if necessary, for this use case. In fact it's advantageous going forward if we have Fn and Fn+1 in separate subvolumes on the same Btrfs. And we have a draft test case for it.
The main gotcha being Fedora 32 and older use a macro for kernel options with the variable set in grubenv. And we're space limited in the grubenv, at best two kernel opts variables are possible. Whereas in Fedora 33 and newer it's explicit in each BLS, and thus it's only limited by the Btrfs pool size. So the future is definitely brighter.
About the older releases, well they are already broken (e.g. F31 -> F32 upgrade), so we are not in a worse position for F33. :P And I think it is so late in F33 release cycle to try to create a work around for it :P If the bug which removes older loader entries is fixed, it is at least an improvement compared to F32 upgrade :D
Yeah that is Bug 1874724 - dual boot Fedora, 2nd installation erases 1st installation's /boot/loader/entries *conf files and I agree it's a higher priority.
@hedayat Pretty sure I saw this got fixed in F34?
Bug #1874724? Not sure. IIRC, it still removed old BLS entries in F34 Beta.
Tomorrow I'll test latest F34 RC to see if anything has changed. But, as the bug is untouched, it probably not.
But if you mean manual backup of F33 BLS entries work, yes they worked unmodified. :)
to comment on this ticket.