I would suggest the command grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg be changed to grub2-mkconfig -o /etc/grub2-efi.cfg since that is correct on all current and past versions of fedora as far as I can recall.
I suggest to open a thread in discussion.fedoraproject.org under the #docs tag. Normally a git issue would be an alternative but as the migration of the different Docs from pagure to gitlab is ongoing, that might be a bit confusing at the moment (But in case: this one is already at gitlab). At discussion.fp you can be sure that it ends up where intended.
I’ll put this in the Docs matrix channel in the meanwhile.
I am a bit careful with suggesting Docs pull requests and such at ask.fp, not specifically about this Doc but about Docs in general. I am a bit afraid of many people reading this and opening issues and pull requests against any repo. At the moment, some are at pagure, some at gitlab, sometimes confusions of repos are possible (plus proper formatting). The Docs organization can be a bit confusing at the moment and I think the pull request is not the best way to start engaging with the Docs. I want to avoid issues/requests that cause more work than they solve, but also avoiding to deter someone from forwarding relevant information due to the complexity and fault possibilities Hope that makes sense.
Hrm, but one doesn’t need to know where the repo is hosted. We just use the buttons in the top right of whatever page and that will directly take us to the repository (or so I thought)?
I understand the concern around the added work pull requests etc. add on us reviewers, but we’ve seen quite an increase in people actually coming forward to help with docs, so I think we can manage it. We’re more than happy to help folks learn the necessary skills (and become long term docs contributors in the process)
But I think that the majority of audience at ask.fp will not know this out of the box, or how to proceed when they are then forwarded to a GitLab Login page (where they do need to use not their own GitLab login but the FAS, …). Making this more comprehensible and creating “Docs about Docs” is under way, and elaborate how to do things then (there were lots of discussions in the recent time, including about privileges in the repos and such). I think it is primarily Ben and PBoy working on that. So it should be first the “how to” do Docs, then the pull request based upon that. Nevertheless, it is of course probabilistic how to do this best, each possibility having its own pros and cons.
Personally, I am a big fan of the widespread github + readthedocs approach, or something compatible. That’s quick and easy, and well known/documented: KISS. But as this would make most what we have obsolete, this is not an option I guess
I thought from earlier comments here that the problem noted would be fixed soon.
I just checked today and see this.
Rebuild the grub.cfg file by running the grub2-mkconfig -o command as follows:
On BIOS-based machines, issue the following command as root:
~]# grub2-mkconfig -o /boot/grub2/grub.cfg
On UEFI-based machines, issue the following command as root:
~]# grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
It is not yet fixed and still leads readers to the incorrect way to run grub2-mkconfig on a UEFI system.
I guess I will also open a note on the fedora discussion list.
This does not belong to discussion.fp. A GitLab issue (new tickets should be opened at GitLab instead of pagure) would be the appropriate place for that:
I will check tomorrow if there is a reason for that and let you know. But feel free to open an issue in advance.
Supplement: it was a bit confusing in the past weeks because some things were handled in GitLab, some in pagure, and some things directly in discussion.fp given the migration. This is why I suggested discussion.fp above, which would of course still be read by Docs people, but now, the Docs organization has started to focus on GitLab and if there are any new Docs-related issues, feel free to generally open tickets there and no longer on pagure. Issues about the content of Docs belong to tickets.
There is not yet a final decision, but at the moment, a consensus seems to develop towards processing the existing pagure tickets in pagure so that they do not need to be transferred, but to open new tickets in GitLab. This applies to the organizational Fedora Docs repo, where you can open general tickets about Docs (if unsure, create tickets there), but applies also to the other repos which are managed by Fedora Docs.
Existing pull requests have to be evaluated in advance to the migration for being accepted or considered obsolete, or to be re-done at GitLab (the goal was/is to process as many PR requests as possible before the migration of a repo).
It should be noted that at the moment, some repositories are in pagure, some in GitLab (migration ongoing), and not all Docs are maintained by Fedora Docs itself (e.g., DEI Docs are maintained by DEI). These teams have to make their own policy about that.
There are still some migration-related changes ongoing, pipeline to be introduced, CI/CD, etc. and I currently don’t know for sure what is already done/standardized in this respect or not.
But when the GitLab procedures are finally standardized, I think the regulars and leaders of ask.fp could become prime examples of “sporadic” contributors. The idea is that Docs does not just contain persistent members but also people who contribute from time to time, just when they find something they want to change - without any ongoing obligation. The example @computersavvy put forward here would be a well example of that. Creating an issue, or directly the pull request, might save you even time.
Also, you could give us some feedback about the processes and procedures when first-time / one-time / sporadic contributing because we still lack this type of non-binding external contribution.
To avoid misunderstandings: this type of contribution will not impose pressures on you in terms of breaking/corrupting Docs because external contributions will be reviewed by a core member before the merge will be approved. So you do not need to be afraid of breaking something, and a guide will be provided as well. I think a lot of incentives can come from ask.fp (both in terms of content but also in terms of external incentives about our processes/procedures).
Meta thread in discussion.fp about the overall issue & how to proceed in future: