On Fri, Jul 29, 2022 at 2:32 PM Chris Murphy <li...@colorremedies.com> wrote:
> On Fri, Jul 29, 2022, at 4:38 AM, Kamil Paral wrote: > > Currently there is this (insufficient, of course): > > https://ask.fedoraproject.org/t/windows-with-encrypted-disks-bitlocker-cant-be-booted-from-the-grub-boot-menu/20612 > > > Looks pretty good actually. What's missing or unclear? > The workarounds section is bare bones. It needs to be made into a full proper guide, so that less experienced users can also follow it. > I think we should consider swapping the built-in bootmanager and > efibootmgr sections. The efibootmgr section needs enhancement first: how to > find the Windows boot entry number; use case 1: do a one time boot of > windows with --bootnext; use case 2: persistently make Windows or Fedora > the default boot OS with --bootorder; use case 3: boot Fedora from Windows > when Windows is the default boot OS. Each with examples and screenshots. > > The efibootmgr CLI is a consistent interface for everyone. It's much > easier to document concisely. The firmware method defies screenshots or > examples. I'd either make it a secondary section or remove it, but have no > strong feeling about it. > I believe both approaches should be present, but I don't feel strongly about ordering. When you want to boot a secondary OS (let's say Windows), the firmware option (when it works and you know how to trigger it) feels more natural to me, and is definitely more friendly than asking general users to run a cryptic command in a terminal as root. Also, booting Fedora, logging in and running a command just to be able to get into Windows is not the definition of a smooth experience for me. It would be a bit better with a GUI tool and even better if it could be done from GDM, but still an annoyance in all cases. Pressing e.g. F12 after starting the PC is the fastest way. It all depends how often you need to get to the secondary OS, or whether there are e.g. multiple users, some of them using Fedora and some of them Windows, on the same PC. The preferences can then differ a lot. > I'd like to see some proper guide available in Fedora Docs/Quick Docs/wiki > that I could reference from that Common Issue entry. > > > I'd like Ask and Quickdoc to be essentially identical. This no conflicting > info between them. Each is a single authoritative source. And each should > be updated in parity. > The Common Issues section on Ask isn't supposed to contain full-length articles, howto's, guides. At least how I imagine it. I'd prefer having a good guide written somewhere (Docs), and just link to it from Common Issues. The purpose of Common Issues is to highlight important and highly visible problems affecting lots of users, provide some links and context and a workaround if available, or a link to a system update when the fix is ready. If the current situation (can't boot Windows from GRUB on UEFI under certain conditions) becomes a feature instead of a bug, e.g. because we are unable to solve it and we remove the GRUB boot menu on all UEFI machines altogether as proposed, I'd even want it removed from Common Issues. It's really only supposed to document release bugs. General troubleshooting, howto's and guides should be elsewhere. We already somewhat discussed that with Mattdm when people wanted to add e.g. instructions on how to configure the proprietary nvidia driver, etc. It's not a bug -> we should have a separate section for these guides (on Ask/Docs/elsewhere), be it proprietary driver common steps, dual-boot configuration common steps, or anything similar. > One pretty big weakness I missed in the summary: the non-functional > Windows menu item in GRUB. That's quite a trap. I'm not sure any > documentation adequately addresses this. But I also don't know an easy way > to detect this situation and either inhibit creation of or remove this item. > I suppose Anaconda would have to be involved, detect encrypted partitions and provide a hint when the bootloader is created. It would be a static solution, far from ideal, but arguably better than the current state.
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
