docs-qa January 2021

docs-qa@lists.fedoraproject.org

1 participants
4 discussions

[Bug 1893428] New: netinstall image requirement for using kickstart could be made clearer
by bugzilla＠redhat.com 21 Jun '21

21 Jun '21

https://bugzilla.redhat.com/show_bug.cgi?id=1893428 Bug ID: 1893428 Summary: netinstall image requirement for using kickstart could be made clearer Product: Fedora Documentation Version: devel Status: NEW Component: install-guide Severity: low Assignee: pbokoc(a)redhat.com Reporter: glaebhoerl(a)gmail.com QA Contact: docs-qa(a)lists.fedoraproject.org CC: pbokoc(a)redhat.com, zach(a)oglesby.co Target Milestone: --- Classification: Fedora Based on the https://docs.fedoraproject.org/en-US/fedora/f33/install-guide/advanced/Kick… page, I attempted to add an inst.ks= boot option to my Fedora Workstation installation image (after copying its contents to a FAT32 filesystem). This resulted, when beginning the installation, in the message: "Kickstart is not supported on live installs. This installation will continue interactively." Googling for this message found single-digit hits, almost all of which were for the several-years-old commit which originally added the message. It was very unclear to me what I should have been doing instead, and spent most of a day fruitlessly googling to try to find out. Every page only ever said that I needed to add a boot option to the kernel command line of the installer (which is what I believed myself to be doing), and went from there. The root of the issue is that it was not apparent to me what the alternative to a "live install" was, or how to activate it. (Maybe I needed to pass different boot options so that it would boot directly into the installer?? I spent a while trying different ways to achieve this.) "Kickstart is not supported on live installs" may have been sufficient information back in the day when live and non-live installation images were provided side by side, but these days, at least for the Workstation version, live is the only download option prominently visible, and it is not even called out as being such. Finally, after trying the twentieth combination of search terms, I found that the page https://docs.fedoraproject.org/en-US/fedora/f33/install-guide/install/Prepa… mentions that "Kickstart installation requires the netinstall media type, or a direct installation booting method such as PXE; kickstarts are not supported with live images". I admit that if I had read all of the instructions linearly from beginning to end, then I would probably not have had this problem. Nonetheless, I humbly suggest that if the "Automating the Installation with Kickstart" page also made some mention of this requirement, it would be a helpful thing. In addition, it might be helpful to extend the "kickstart is not supported on live installs" error message with some mention of the suggested alternatives as well. Thank you for your work and attention. -- You are receiving this mail because: You are the QA Contact for the bug.

1 8

[Bug 1615744] Kernel module signing instructions for Secure Boot contain errors
by bugzilla＠redhat.com 29 Jan '21

29 Jan '21

https://bugzilla.redhat.com/show_bug.cgi?id=1615744 --- Comment #3 from nicolasoliver03(a)gmail.com --- Great docs! The only missing thing I see is how you re-sign a module with a custom key. For example, I am using my own Secure Boot PK, KEK, DB and DBX, and I have a custom signed kernel. How do I pull already signed modules from the fedora repos and re-sign with my custom key so they can work on Secure Boot. The docs in https://www.kernel.org/doc/html/v4.15/admin-guide/module-signing.html does not say anything about it, and assumes you are compiling the module. Do you need to remove the previous signature, or can you append the new signature? Other than that, I think the docs are great :) -- You are receiving this mail because: You are the QA Contact for the bug.

1 0

[Bug 1615744] Kernel module signing instructions for Secure Boot contain errors
by bugzilla＠redhat.com 29 Jan '21

29 Jan '21

https://bugzilla.redhat.com/show_bug.cgi?id=1615744 Marc Methot <mmethot(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mmethot(a)redhat.com --- Comment #2 from Marc Methot <mmethot(a)redhat.com> --- This has been addressed in the newer docs: - https://docs.fedoraproject.org/en-US/fedora/f32/system-administrators-guide… -- You are receiving this mail because: You are the QA Contact for the bug.

1 0

[Bug 1907756] New: Issues in dnf-plugins-core manpages
by bugzilla＠redhat.com 05 Jan '21

05 Jan '21

https://bugzilla.redhat.com/show_bug.cgi?id=1907756 Bug ID: 1907756 Summary: Issues in dnf-plugins-core manpages Product: Fedora Documentation Version: devel Status: NEW Component: packager-guide Severity: low Assignee: pbokoc(a)redhat.com Reporter: debian(a)helgefjell.de QA Contact: docs-qa(a)lists.fedoraproject.org CC: pkovar(a)redhat.com Target Milestone: --- Classification: Fedora Dear dnf-plugins-core maintainer, (I don't understand the systematics of this bugzilla instance, so please reassign appropriately. Thanks) the manpage-l10n project maintains a large number of translations of man pages both from a large variety of sources (including dnf-plugins-core) as well for a large variety of target languages. During their work translators notice different possible issues in the original (english) man pages. Sometimes this is a straightforward typo, sometimes a hard to read sentence, sometimes this is a convention not held up and sometimes we simply do not understand the original. We use several distributions as sources and update regularly (at least every 2 month). This means we are fairly recent (some distributions like archlinux also update frequently) but might miss the latest upstream version once in a while, so the error might be already fixed. We apologize and ask you to close the issue immediately if this should be the case, but given the huge volume of projects and the very limited number of volunteers we are not able to double check each and every issue. Secondly we translators see the manpages in the neutral po format, i.e. converted and harmonized, but not the original source (be it man, groff, xml or other). So we cannot provide a true patch (where possible), but only an approximation which you need to convert into your source format. Finally the issues I'm reporting have accumulated over time and are not always discovered by me, so sometimes my description of the problem my be a bit limited - do not hesitate to ask so we can clarify them. I'm now reporting the errors for your project. If future reports should use another channel, please let me know. Man pages: dnf-repoclosure.8, dnf-repodiff.8, dnf-repomanage.8 Issue: Incorrect markup: I<yum.conf (5)> → B<yum.conf>(5) "I<yum.conf (5)>\n" "http://yum.baseurl.org/\n" -- Man page: dnf-reposync.8 Issue: Incorrect markup: B<dnf(8)> → B<dnf>(8) "All general DNF options are accepted. Namely, the B<--repoid> option can be " "used to specify the repositories to synchronize. See I<Options> in B<dnf(8)> " "for details." -- You are receiving this mail because: You are the QA Contact for the bug.

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

docs-qa January 2021