fix uefi bootloader issue

[jibby0]

This forces grub2-mkconfig to use /boot/efi/EFI/fedora to install UEFI entries, rather than the nonexistent /boot/efi/EFI/tigeros. This fixes the bootloader install issue #58 . No visual change occurs: all entries in the UEFI bootup menu still say TigerOS.

However, if we really wanted to use a different directory, we'd need to repackage grub2-efi, as the fedora directory is included in that package upstream.

[axk4545]

@RITlug/tigeros-team requesting review here to discuss whether we want TigerOS to be able to install in parallel with Fedora on a dual boot as mentioned in #58

[jibby0]

I couldn't say for sure whether or not it'd be dual-bootable. I don't know much about EFI grub, but I remember that for MBR, grub used os-prober or the like to find all operating systems and place them in grub.cfg. So each OS would overwrite that file, but I don't know if they'd actually change anything. Or what the repercussions of having two OS configs in one EFI directory would be.

To be safe, it might be better to repackage. That would just include pulling from upstream, unpackaging, renaming a folder, and repackaging, right? Would we want to call our package something else, or is there a way to tell dnf not to pull grub2-efi from upstream? A different name for our grub package might be confusing.

See #71 (comment)

[axk4545]

@Josh1147582 what I meant is that according to @AdamWill in #58 if we make ours use fedora it will not in parallel with a Fedora system dualboot. I am asking if we are ok with this. I would defer to @AdamWill or another person from upstream Fedora on your other questions.

[ct-martin]

Marking as no until we can talk about this a little. @axk4545 and I started having a conversation about the gradient from a flavor/spin of a distro vs being a separate distro which is relevant and I want to talk with him again before we make choice. I do propose having an iso build with the fix so that we can continue work elsewhere though.

[axk4545]

@Josh1147582 I believe that we can either have our installclass package make the directory or we can have a grub2-efi pacakage and just not set the replace, obsolete or conflict part of the spec so that both can be installed. Probably better to make our installclass create the directory it needs

[axk4545]

@axk4545 WRT to @ct-martin's comment I agree that we should test the result first to see whether it actually does what we think it does.

[jwflory]

I prefer using a unique naming scheme to preserve dual boot with existing Fedora installations; however, I don't understand clear pros/cons to either approach.

Some of us might have pre-existing Fedora installations on bare metal but also want to install TigerOS for testing or use. However, I am not a technical expert on this change and don't understand why this change over another. To me, it looks like a simple text file change and I don't understand why using fedora vs. tigeros makes this more like maintaining a remix versus an entire operating system.

It would help if someone clearly laid out possible outcomes (positive or negative) in a bullet list.

[axk4545]

@jflory7 I am not sure why this effects our status as a remix either. I am leaning towards allowing dual booting with Fedora but I am not sure the implications of maintaining our own grub2-efi pacakage. According to my memory we decided to remain a remix and make our scrips available in formats other than RPM when practical.

[axk4545]

@Josh1147582 I also discovered that grub-efi is actually provided by the grub package so I am consulting with Korora and Fedora community members on our options to not break upstream or ourselves

[jibby0]

I tried installing Fedora workstation 26 in parallel with the TigerOS install. From what it looks like, this change means whichever OS was installed last take over the boot process: in this case, only Fedora showed up after the Fedora install.

So this change would indeed break EFI dualbooting with Fedora.

Hopefully there's a better way of fixing it than hosting our own grub package(s). @axk4545 Let us know if another remix has a more elegant solution than making alternative packages.

@jflory7 I think Christian's saying that a change like this, if solved by hosting our own grub package(s), would mean further separation from upstream, and more independence/work on our part. The grub2-efi package in standard Fedora includes a fedora EFI directory. For us to use a tigeros EFI directory, and remain compatible with Fedora, we may need to package/host our own grub stuff.

[axk4545]

@Josh1147582 @jflory7 @ct-martin @RITlug/tigeros-team it looks like the others just use the fedora efi dir so our choice now is this:

• Allow dualboot with Fedora and Korora but make our own grub2-efi package
  or
• Follow what Korora does and not allow dualboot with Fedora or Korora.

With the second option we could also work with Korora to find a more permanent solution.
please add a reaction to this comment; +1 for option 2 or -1 for option 1

[axk4545]

@jflory7 here is your list:
No dualboot
pros:

• one less package to maintain
• can collaborate with Korora on a more permanent fix
  cons:
• no way for devs already running Fedora to test without a dedicated disk or machine

Dualboot
pros:

• no restrictions on what users can run
• can maybe help other remixes to grow
  cons:
• one more package to maintain
• not sure how much it will actually be used besides devs

[ct-martin]

@jflory7 @axk4545 @Josh1147582

So @Josh1147582 was more or less correct in what I meant. What I was trying to say was that by being incompatible with Fedora, we run the line of acting as a replacement/acting (!= being) as independent (due to the fact that the majority of the experience we intentionally want to remain as stock Fedora). Given the incompatibility and how many of us run Fedora, I think this is something to bear in mind, although it's not an issue if the problem didn't exist since we can cleanly coexist.

Additionally, @axk4545 's comment on can collaborate with Korora on a more permanent fix is not a pro or con in my opinion, it's an action item. I don't want to have to build and host our own grub packages, however, I also don't think that being incompatible with stock Fedora is the correct action either. I would propose that we make a separate branch for this to go to so that we can build, and continue working in devel (which will be pulled to the new branch from that side) while we work with Korora, Fedora, and any other relevant groups (Anaconda, Grub, etc.) to get a proper fix. Personally, I think that the kickstart or Anaconda installclass should be able to provide this change.

[axk4545]

@ct-martin we can ask @AdamWill and some of the Anaconda people if that can be done... not sure it can but I think @Josh1147582 was testing a fix. Did we get a result from that?

[jibby0]

@axk4545 We tried adding creation of the tigeros directory to the spec file of anaconda-installclass-tigeros. The installer no longer reports an error (since grub2-mkconfig succeeds), but the system won't boot.

[jibby0]

Unless there's a way to solve this without packaging our own grub, I would say this is the best solution.

While it'd be great to be dual bootable with Fedora, it's not feasible to package our own grub. It may just be a matter of renaming the directory in a few packages, but what if we miss one? If we pull something critical from upstream without changing it, it could mean bootloader issues for users.

Korora handles this in the same manner: I'm guessing they do so because of the danger involved, or because a majority of their user base won't have Korora and Fedora installed at the same time.

Other than for testing purposes, I would say we're in the same boat user-wise: a Fedora user who really wanted to use our layouts/packages/etc. would install them, or add our repo.

TLDR

Changing the folder

• Could be dangerous for users if repackaging is done improperly.
• Makes testing easier, but would likely serve a small user base.

Not changing the folder

• Safest for the average user.
• TigerOS couldn't be dual booted with Fedora.

[AdamWill]

I'm not sure it's realistically possible to 'fix' this, exactly. The directory doesn't just need to be there, it actually needs to have all the bootloader files in it. And we (Fedora, that is) ship our bootloader files...in an RPM package, because that's how we ship everything. And the files in an RPM package are in one place, that's kinda it. I just don't see how we could feasibly make it so you can cause the bootloader files to go somewhere different only by changing the install class.

Maybe someone smarter than me can think of something, but I really can't...

[jwflory]

We discussed this in the 2017 Nov. 17 and decided to move forward with this PR to close #58. @Josh1147582 or @axk4545 will file a new ticket to track the long-term issue behind this (that is, getting a fix upstream).

This is ready to merge. 🎬

We discussed this in person during the RITlug meeting and decided to move forward with this.