https://bugzilla.redhat.com/show_bug.cgi?id=1220066
Bug ID: 1220066
Summary: grub2-install suggestion doesn't distinguish between
BIOS and UEFI installs
Product: Fedora Documentation
Version: devel
Component: system-administrator's-guide
Assignee: swadeley(a)redhat.com
Reporter: bugzilla(a)colorremedies.com
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: swadeley(a)redhat.com
ttps://docs.fedoraproject.org/en-US/Fedora/21/html/System_Administrators_Gu…
Section 20.4 and 20.4.1 apply only to BIOS computers, not UEFI. On UEFI:
1. grub2-install fails
https://bugzilla.redhat.com/show_bug.cgi?id=1101352
2. If grub2-efi-modules is installed, grub2-install succeeds but then:
2a. This will break UEFI Secure Boot systems because the core.img/grubx64.efi
binary that gets created isn't signed and therefore UEFI Secure Boot will
reject it.
2b. On UEFI systems without Secure Boot, GRUB behavior is different in a number
of ways including that it will no longer look to /boot/efi/EFI/fedora/grub.cfg
but rather to /boot/grub2/grub.cfg.
Two ways to fix the documentation:
a.) A side bar that says this section doesn't apply to systems with UEFI
firmware (maybe a link to where we give them a hint "how to find out what kind
of firmware you have"), and/or that this section is effectively done by 20.4.2
step 3.
b.) Reorganize 20.4 into discreet BIOS and UEFI sections.
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1288809
Bug ID: 1288809
Summary: Minor discrepancy in the Fedora documentation
Product: Fedora Documentation
Version: devel
Component: documentation-guide
Severity: medium
Assignee: sparks(a)redhat.com
Reporter: pj.pandit(a)yahoo.co.in
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: jhradile(a)redhat.com, pkovar(a)redhat.com,
sparks(a)redhat.com, stickster(a)gmail.com,
zach(a)oglesby.co
Document URL: https://docs.fedoraproject.org/en-US/index.html
Section Number and Name: Older Fedora documentation
Describe the issue: It still talks about F19 & F20 releases.
"The Fedora Documentation Project only maintains documentation for Fedora 19
and Fedora 20."
Suggestions for improvement: It should be F21 & F22, as older releases.
Additional information:
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1002573
Bug ID: 1002573
Summary: Enable SELinux Labeled NFS Support
Product: Fedora Documentation
Version: devel
Component: security-guide
Keywords: Tracking
Assignee: sparks(a)redhat.com
Reporter: sparks(a)redhat.com
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: jreznik(a)redhat.com, me(a)petetravis.com,
nobody(a)fedoraproject.org, pkennedy(a)redhat.com,
security-guide-list(a)redhat.com, sparks(a)redhat.com,
steved(a)redhat.com, stickster(a)gmail.com,
zach(a)oglesby.co
Depends On: 984718, 998566, 1001346
+++ This bug was initially created as a clone of Bug #1001346 +++
+++ This bug was initially created as a clone of Bug #998566 +++
This is a tracking bug for Change: Enable SELinux Labeled NFS Support
For more details, see: http://fedoraproject.org//wiki/Changes/LabeledNFS
The Linux Kernel has grown support for passing SELinux labels between a client
and server using NFS.
Discussion at
https://lists.fedoraproject.org/pipermail/devel-announce/2013-July/001216.h…
Please assess existing documentation for the impact of this Change.
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1317222
Bug ID: 1317222
Summary: typo in 2.4.2 IPv6
Product: Fedora Documentation
Version: devel
Component: security-guide
Severity: low
Assignee: sparks(a)redhat.com
Reporter: darthcookient(a)gmail.com
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: pkennedy(a)redhat.com, security-guide-list(a)redhat.com,
sparks(a)redhat.com, zach(a)oglesby.co
Description of problem:
"...There are some security features that were side effects to NAT; the biggest
being that outside traffic cannot make it inside the network unless a port is
forwarded across the router. Because IPv6 solves the addressing problem there
is no longer a need to use NAT. Everything can have a public IP address and, by
extension, everything is not publically routable across the Internet when
physical and logical connections are made."
Forgive me if I'm wrong but if I understand correctly, this should say:
"everything IS publically routable across the Internet when physical..."
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=982914
Bug ID: 982914
Summary: 7.4.1. Configuring 802.1x Security
Product: Fedora Documentation
Version: devel
Component: system-administrator's-guide
Severity: unspecified
Priority: unspecified
Assignee: jhradile(a)redhat.com
Reporter: im_dracula(a)hotmail.com
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: jhradile(a)redhat.com
Description of problem:
In section 7.4.1 under 'Procedure 7.8. For a wired connection...', '
Procedure 7.9. For a wireless connection...':
The 'Network Connections' dialogue can be accessed via:
activities --> applications --> sundry --> network connections, or via
nm-connection-editor
This is not specified at all in this section.
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=982911
Bug ID: 982911
Summary: 7.3.3. Establishing a Mobile Broadband Connection
Product: Fedora Documentation
Version: devel
Component: system-administrator's-guide
Severity: unspecified
Priority: unspecified
Assignee: jhradile(a)redhat.com
Reporter: im_dracula(a)hotmail.com
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: jhradile(a)redhat.com
Description of problem:
Under section 7.3.3, in 'Procedure 7.3. Adding a New Mobile Broadband
Connection', 'Procedure 7.4. Editing an Existing Mobile Broadband Connection':
network connection editor can also be found at:
activities --> applications --> sundry --> network connections
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=982910
Bug ID: 982910
Summary: 7.3.5. Establishing a DSL Connection
Product: Fedora Documentation
Version: devel
Component: system-administrator's-guide
Severity: unspecified
Priority: unspecified
Assignee: jhradile(a)redhat.com
Reporter: im_dracula(a)hotmail.com
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: jhradile(a)redhat.com
Description of problem:
In section 7.3.5 under 'Procedure 7.6. Adding a New DSL Connection', 'Procedure
7.7. Editing an Existing DSL Connection':
These procedures could also specify that the network connections editor can be
accessed from:
activities --> applications --> Sundry --> Network Connections
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1221780
Bug ID: 1221780
Summary: how to identify firmware types, UEFI vs BIOS
Product: Fedora Documentation
Version: devel
Component: system-administrator's-guide
Assignee: swadeley(a)redhat.com
Reporter: bugzilla(a)colorremedies.com
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: swadeley(a)redhat.com
I'm not finding advice in documentation to identify firmware type. Should we,
and if so where should it go?
Identifying firmware type comes in handy e.g. reinstalling grub, see bug
1220066.
The problem is, users overwhelmingly equate UEFI and BIOS, often referring to
it as UEFI BIOS, mainly because OEM's still call firmware updates "BIOS
updates".
Two possible ways to reliably identify UEFI vs BIOS firmware.
On an EFI system:
# ls /sys/firmware/efi
config_table efivars fw_platform_size fw_vendor runtime runtime-map
systab vars
On a BIOS system:
# ls /sys/firmware/efi
ls: cannot access /sys/firmware/efi: No such file or directory
----
On an EFI system:
# efibootmgr
BootCurrent: 0000
Timeout: 5 seconds
BootOrder: 0000,0080
Boot0000* Fedora
Boot0080* Mac OS X
Boot0082*
BootD1A6* AST
BootFFFF*
On a BIOS system:
# efibootmgr
efibootmgr: EFI variables are not supported on this system.
Unknowns:
The first method always works since ls is for sure installed no matter what. I
need to test if efibootmgr is always installed, e.g. netinstall (?), it
definitely is always installed from lives. But if it's not installed, then it's
not a UEFI system.
How does coreboot firmware manifest? I think it's mainly a "better BIOS" and
should behave as such.
ARM firmware?
--
You are receiving this mail because:
You are the QA Contact for the bug.
The following is a list of bugs or attachments to bugs in which a user has been
waiting more than 7 days for a response from you. Please take
action on these requests as quickly as possible. (Note that some of these bugs
might already be closed, but a user is still waiting for your response.)
We'll remind you again in another 7 days if these requests are still
outstanding, or if there are any new requests where users have been waiting
more than 7 days for your response.
review
------
Bug 1124344: yum --security update doesn't work on non-fedora repos. This limitation is probably undocumented. (573 days old)
https://bugzilla.redhat.com/show_bug.cgi?id=1124344https://bugzilla.redhat.com/attachment.cgi?id=942713&action=edit
To see all your outstanding requests, visit:
https://bugzilla.redhat.com/request.cgi?action=queue&requestee=docs-qa%40li…
The following is a list of bugs or attachments to bugs in which a user has been
waiting more than 7 days for a response from you. Please take
action on these requests as quickly as possible. (Note that some of these bugs
might already be closed, but a user is still waiting for your response.)
We'll remind you again in another 7 days if these requests are still
outstanding, or if there are any new requests where users have been waiting
more than 7 days for your response.
review
------
Bug 1124344: yum --security update doesn't work on non-fedora repos. This limitation is probably undocumented. (566 days old)
https://bugzilla.redhat.com/show_bug.cgi?id=1124344https://bugzilla.redhat.com/attachment.cgi?id=942713&action=edit
To see all your outstanding requests, visit:
https://bugzilla.redhat.com/request.cgi?action=queue&requestee=docs-qa%40li…