Hello Chris, Sorry for the late response but I was on vacation last week. On Sun, Feb 10, 2019 at 8:06 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > On Wed, Feb 6, 2019 at 1:08 AM Javier Martinez Canillas > <javier@xxxxxxxxxxxx> wrote: > > > > On Wed, Feb 6, 2019 at 5:28 AM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > > > > > https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault > > > > > > I want this change to succeed but I'm experiencing a regression, and > > > while trying to troubleshoot it I'm finding it difficult to understand > > > the myriad differences: > > > > > > > Is this on F29 or Rawhide? Also, it's on an EFI or BIOS install? > > Rawhide UEFI. I thought it was a regression compared to grubby and > grub2-mkconfig, because the problem doesn't happen with them. But > those tools work directly on the grub.cfg which on UEFI only ever > appears on FAT. Meanwhile, blscfg's .conf files are located at > /boot/loader/entries which on this particular test setup is subject to > zstd compression, and GRUB doesn't yet support zstd compression. GRUB > couldn't read the file contents, therefore it's not a regression, it's > a missing feature. Removing the compression solved the problem. > I see, thanks a lot for the explanation. > > > > there's a lot of grub2 documentation in Fedora and outside Fedora, all > > > of which conflicts with this feature. And Fedora's experts in QA and > > > > Could you please elaborate a little bit? If you see a big mismatch > > between some documentation and how the BLS support behaves, please > > point out so we can try to make it more transparent for users. > > If a user has bootloader related issues, I ordinarily would only ask > for a copy of the grub.cfg. But with bls systems, I need to ask for > the grub.cfg, all the .conf files, and the grubenv file. All of them > need to be interpreted. Each of those files are only described in > generic terms by upstream GRUB, and no one else is using those files > in the specific way they're being used in Fedora. > Yes, a BLS configuration comes with a different set of trade offs. Not having the boot entries in the grub2.cfg has the advantage that the file doesn't have to be modified on kernel install / removal, but as you said it also means that it doesn't contain all the information of your boot configuration. > Between this feature for F30, and the F29 feature to hide the grub > menu which comes with boot success+fail marking by using the grubenv, > there are substantial changes in bootloading on Fedora that exist no > where else and near as I can tell there is no documentation at all. I > can't really call specs we don't fully follow, or feature pages, to be > documentation. > You are correct, we will work on more documentation and also better tooling to manage the BLS snippets, grubenv file, etc. For example grub2-editenv is very fragile as was mentioned in this thread. > > > > On Rawhide the blscfg command now supports to load BLS entries to > > troubleshoot these cases. For example you should be able to do: > > > > blscfg (hd0,gpt2)/loader/entries/ > > > > to load all the BLS snippets from a directory or: > > > > blscfg (hd0,gpt2)/loader/entries/loader/entries/036f3661be4047b6b678d491f76df6f4-5.0.0-0.rc4.git3.1.fc30.x86_64.conf > > > > to load a single BLS snippet. > > Ok that is a useful troubleshooting technique. In my case this was > totally silent, ergo it found nothing even though there were files > there. Adding 'set debug=all' and then following that up with blscfg > exposed what directories it was looking at and the contents weren't > readable - and that's when I clued in. > Got it, I'm glad that you figured out the issue. > > > -- > Chris Murphy Best regards, Javier _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
