Anaconda isn't going to activate the lvms not used for install.  If os-prober needs to look into them, it needs to activate (and then deactivate) them itself.

*** Bug 880491 has been marked as a duplicate of this bug. ***

os-prober can't do this because grub2 (in fact, 30_os-prober script) later uses the device to retrieve full boot parameters (it uses os-prober again for that, but that's a different script (linux-boot-prober) which is executed separately). Therefore, os-prober should not de-activate LVM partitions and linux-boot-prober doesn't know which partitions are activated and which ones where already active when os-prober was called. 

Therefore, activating/deactivating LVM partitions should be done either in Anaconda, or in grub2. It seems that anaconda team think that it is not their job (while it can be said that grub2-mkconfig is also part of install). On the other hand, doing it in grub2 has the advantage that it also works for already installed systems. I wonder if activating & deactivating LVM partitions on a running system is acceptable.

(In reply to comment #3)
> I wonder if activating &
> deactivating LVM partitions on a running system is acceptable.

FWIW, I don't think so.

I think it would be better to have a separate tool that could be run initially (or manually) and create a static /etc/grub.d file.

That would make it much more acceptable to run grub2-mkconfig after installing new kernels and thus avoid using /sbin/grubby.

- but that is OT ;-)

But FWIW: I doubt it will be fixed in grub. A fix in anaconda is much more likely to happen.

*** Bug 886270 has been marked as a duplicate of this bug. ***

Since this bug fix will not make F18 (as of this comments' timestamp), it is perhaps a very good idea to indicate the problem and the work around in the Fedora 18 release notes.

In the release notes I would indicate that if the system had multiple distributions or operating systems, and at boot time, if the grub presentation was missing some from the list, then perform the following after firstboot:

log to root or sudo su and run

grub2-mkconfig >/tmp/grub.cfg                 #check it out here
cp /boot/grub2/grub.cfg /boot/grub2/grub.bak  #make a backup and keep orig
cp /tmp/grub.cfg /boot/grub2                  #now delete original
rm /tmp/grub.cfg                              #now clean up.

I always retain a previous copy

(In reply to comment #6)

You should use -o instead of >, as mentioned in readme.fedora.

Hi Mads

Re using -o  

I am a cautious person and since there is no man page for grub2-mkconfig in "Fedora 17" to tell me if there are side effects of using -o

I remained cautious and chose to use redirection, which worked just fine for me.

Would -o create different ownership and permissions? (no man page to tell me)

If the Fedora team fixes the bug before go-live, then what I wrote is a moot point.  if F18 gets shipped with the bug, then as I pointed out, a good place to advise the admin or person doing the installation about the problem is with the release notes. In the notes, you may phrase the information and solution as you wish.

Doing something different from what the documentation says is not being cautious.

-o will make sure you never get a incomplete file even if grub2-mkconfig crashes.

Mads, would you please see if such a change can make it do Grub2, and if not, why? If it can be done in grub2, it has some advantages (it would also work if it is run in an installed system in which LVM devices are not active), and if it really shouldn't be fixed in grub2, this bug should be reassigned to Anaconda. 

I wonder if Anaconda disables LVM devices when run in live mode. If it doesn't, enabling all LVM devices in anaconda in DVD should be OK, since it is what happens in Live disks.

(In reply to comment #10)
Sorry, I don't have time for that at the moment. If anything I would suggest working with upstream grub.

But FWIW, right know I think that considering that os-prober already do a lot of probing and mounting of file systems, then it would be a reasonable expectation (and not significantly worse) if os-prober also did whatever it takes to detect lVMs.

Yes, I've considered doing this in os-prober, but I explained above that os-prober is actually called more than once from grub2-mkconfig (os-prober and linux-boot-prober for each GNU/Linux OS found), it should either preserve the state (which LVM partitions are activated by os-prober) and deactivate them after last call (which it can't detect), or should activate and deactivate them each time which could make it very slow and doesn't look like a good solution. It is much better if it is done in 30_os-prober or by Anaconda.

Before GO live, as a Beta tester who just wipes a spare physical disk clean and does a reinstall, I find that the grub.cfg after installation is far from complete. It is missing other distributions. (My config is 4 disks, with /dev/sdd used as a wipe-and-reinstall disk for Fedora testing. 

On the system are Windows, Mint14, Fedora 18, and Suse. 

Anaconda does not detect Mint14 or Suse as the final action before asking for the system to be rebooted.

On reboot, I actually do an immediate grub2-mkconfig and it properly corrects for the omissions during the F19 installation.

So, my question is, is the grub2-install in anaconda as currrent as the one in F19?

Merge this with 835517

More information is needed. Where does Mint14 and Suse installed? Are they on LVM or... ? If not LVM, it is probably some other requirement.

It seems that the same problem needs to be addressed for BTRFS partitions too.

This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

I have to say I disagree with Jesse's original assertion here (c#1).

It seems a much more desirable design for me that anaconda should ensure the environment in which grub2-mkconfig will run is optimal for OS discovery, than to expect grub2-mkconfig to go around poking things in order to try and find OSes. It just seems to me that it makes sense for grub2-mkconfig to run with the environment it's given; providing the correct environment should be the responsibility of the entity invoking it, which in this case is anaconda.

Either this bug, or bug 1110920 is a duplicate. The argument in 1110920 is to either fix the problem or inform the user that their previously bootable system won't appear in the boot menu after installing Fedora. Either way something needs to be done, it isn't OK to silently break a previously bootable system.

*** Bug 1110920 has been marked as a duplicate of this bug. ***

pjones agrees with the contention that it's not appropriate for grub2-mkconfig / os-prober to go around poking inactive storage devices to try and find OSes, hence the re-assignment back to anaconda.

This really does seem like a straight up anaconda bug, to me. anaconda really ought to make sure installed OSes are visible at the time it invokes bootloader configuration. At *least*, it must surely be anaconda's responsibility to ensure other Fedora / Red Hat instances are properly discoverable for bootloader purposes; it's hard to see how it can be anyone else's job to make sure that if you install two Fedora releases together, both are bootable.

Proposed as a Blocker for 21-final by Fedora user catanzaro using the blocker tracking app because:

 This bug does not appear to violate any current release criterion, which I find surprising. I propose a new blocker criterion:

"The installer must be able to detect all preexisting Linux installations and create working boot menu entries for those installations."

I'm sure that wording needs to be more precise, but the intent is that installing Fedora should not make previous Linux installations disappear. If that's too broad then we could restrict it to previous Fedora installations instead.

bz is not the place to propose new criteria. I also object to wording like 'must be able to detect ALL preexisting Linux installations', it seems like you are trying to add features via release criteria.

If you want new features, open a RFE bug for it or discuss it on the anaconda-devel mailing list: https://www.redhat.com/mailman/listinfo/anaconda-devel-list

(In reply to bcl from comment #24)
> bz is not the place to propose new criteria. I also object to wording like
> 'must be able to detect ALL preexisting Linux installations'

If there's a technical reason why this is infeasible, then we should certainly soften the wording.

> If you want new features, open a RFE bug for it or discuss it on the
> anaconda-devel mailing list:
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list

I think what I want is "Anaconda should run grub2-mkconfig when LVM devices are active" so probably this bug is sufficient.

please propose release criteria on the test@ list, thanks.

bcl: is it planned to fix this at least for the Fedora case for F21? It does seem like a significant bug.

(In reply to Adam Williamson (Red Hat) from comment #26)
> please propose release criteria on the test@ list, thanks.

OK!

Just to confirm, this is still valid in 21 Final TC1 (I was trying to test another UEFI multiboot bug,  but couldn't even manage to hit that one when installing alongside an F20 install to LVM, because of this bug).

We likely will not make this block F21 release - it's a bit late to add new multiboot requirements - but it'd certainly be nice if we could fix it in time.

I no longer have a concern

This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

let's see if this keeps the auto-close demons away, since this bug is not just going to magically disappear.

anaconda-26.21.4-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-f620d8c7c2

Looks like the Bodhi web UI likes to add random unrelated bugs to an update...

Just tested and confirmed this is still broken with Fedora 30 / Fedora 31. Install Fedora 30 to LVM, leave space available, install Fedora 31, boot: result, grub shows only F30, not F31. Running `grub2-mkconfig -o /boot/grub2/grub.cfg` gives a config with both F30 and F31. (Which doesn't work, probably due to BLS or something *HANDWAVE HANDWAVE*, but it demonstrates the original issue is still there).

>grub shows only F30, not F31
Gonna guess you mean it only shows F31, following F31 installation. Otherwise you've found a new bug.

Yeah, sorry, that is what I meant.

Thinking about F31+F32, I expect it's still a problem even though both use BLS. Upstream BootloaderSpec says $BOOT should be a shared volume. But the installer doesn't support it. Instead it'll create separate boot volumes for each installation, mounted at /boot, thereby making /boot/loader/entries contain only version specific BLS snippets, rather than them all going in the same place where the newest version of GRUB would pick up all of them.

To support this automatically anaconda needs to:
a. understand discoverable partitions spec as it relates to BLS [1]
b. automatically use the proper MBR/GPT partition type for $BOOT if it exists. And if not create it.
c. not step on the contents of $BOOT (BLS is silent on how this gets garbage collected or what to do if it's full but the installer I think knows enough to not run into this problem, and fail gracefully)

It also presents an opportunity to stop depending on users knowing or learning esoteric things: remove user control over creation of BIOS Boot, EFI System partition, and $BOOT, and handle these things automatically including creating them on all selected disks as destinations for installation. This would make custom partitioning easier to use, and more reliable.

[1]
Strictly speaking bootloaderspec says $BOOT should either be type 0xEA, or bc13c2ff-59e6-4262-a352-b275fd6f7172 or c12a7328-f81f-11d2-ba4b-00a0c93ec93b, and has some parameters for which it should be, including size constrains. Possibly it can be made simpler on Fedora, since the EFI System Partition isn't ever use as BLS $BOOT.

What about setting the boot volume (mounted at /boot) type ID to 0xEA and bc13c2ff-59e6-4262-a352-b275fd6f7172, instead of 0x83 and 0FC63DAF-8483-4772-8E79-3D69D8477DE4?

That would be sufficient to indicate "this is a reusable boot volume" for the purpose of multiple installations. And then the next question is if 1GiB is big enough for an explicitly shared $BOOT role for a few years for at least two or three OS's? Maybe 1.2GiB? *shrug*

@bcl
I don't see either the GPT linux boot type code in libparted/gpt.c; or a way to set an arbitrary GPT partition type code. I do see it in fdisk.

(In reply to Chris Murphy from comment #39)
> @bcl
> I don't see either the GPT linux boot type code in libparted/gpt.c; or a way
> to set an arbitrary GPT partition type code. I do see it in fdisk.

Which one do you mean? bc13c2ff...?
Who defined it and who is using it? I'm not opposed to adding new flags, but it needs to be widely accepted, not 'yet another random booting idea' :)
Also, parted does not support arbitrary GUIDs it only supports flags which are mapped to them.

0xEA for MBR disks, and bc13c2ff-59e6-4262-a352-b275fd6f7172 for GPT disks. Both are defined in the bootloaderspec, which is what Fedora's GRUB blscfg.mod is modeling after since Fedora 30. This GUID is supported in gdisk and fdisk.
https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/

Question for Javier and also Anaconda folks though, is whether a shared boot is an agreed upon goal. That is a central purpose of the bootloaderspec, but I think the spec was adopted to make bootloader configuration updates simpler and more reliable. But in order to have a shared boot volume, there needs to be a way to indicate it's a shared boot. And then a policy to a) create shared boot volumes b) reuse them if they exist. Otherwise if we're just creating more boot volumes instead of reusing them, we're going to end up littering the planet with 0xEA, bc13c2ff... for no reason.

(In reply to Chris Murphy from comment #38)
> What about setting the boot volume (mounted at /boot) type ID to 0xEA and
> bc13c2ff-59e6-4262-a352-b275fd6f7172, instead of 0x83 and
> 0FC63DAF-8483-4772-8E79-3D69D8477DE4?
> 

Wouldn't it conflict with the following from https://systemd.io/BOOT_LOADER_SPECIFICATION/?:
> For systems where the firmware is able to read file systems directly, $BOOT must be a file system readable by the firmware. For other systems and generic installation and live media, $BOOT must be a VFAT (16 or 32) file system. Applications accessing $BOOT should hence not assume that fancier file system features such as symlinks, hardlinks, access control or case sensitivity are supported.

We have links in /boot now.

Fedora 30/31/32 already depart from Boot Loader Spec in that regard. Whether UEFI or BIOS, /boot/loader/entries is on an ext4 $BOOT.

This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.