docs-qa July 2013

docs-qa@lists.fedoraproject.org

1 participants
97 discussions

[Bug 891467] New: Need a section in the install guide regarding pxe booting on UEFI systems
by Red Hat Bugzilla 31 Jul '13

31 Jul '13

Product: Fedora Documentation https://bugzilla.redhat.com/show_bug.cgi?id=891467 Bug ID: 891467 Summary: Need a section in the install guide regarding pxe booting on UEFI systems Product: Fedora Documentation Version: devel Component: uefi-secure-boot-guide Severity: unspecified Priority: unspecified Reporter: jreed(a)redhat.com Depends On: 871565 +++ This bug was initially created as a clone of Bug #871565 +++ Description of problem: Fedora 18 will see greater use of UEFI systems, and as such we should round out our documentation regarding how to boot UEFI systems via other common methods besides those already addressed. Most notably the use of pxe boot in UEFI environments will now be available with secure boot enabled via both ipv4 and ipv6 the by using shim layer code: https://github.com/mjg59/shim We should further document how to boot a system and setup a pxe server to allow booting UEFI systems in this manner --- Additional comment from Jack Reed on 2012-11-12 01:01:52 EST --- Thanks Neil. Are you able to give me some details on how the procedure for setting up a PXE server for EFI would need to be changed to account for this? http://docs.fedoraproject.org/en-US/Fedora/17/html/Installation_Guide/s1-ne… And I expect the "Booting from the Network using PXE" section needs to be tweaked to account for EFI as well: http://docs.fedoraproject.org/en-US/Fedora/17/html/Installation_Guide/sn-bo… Are you able to tell me how this process differs on EFI systems? And what else would you like included here or elsewhere, particularly with regard to secure boot being enabled via via both ipv4 and ipv6 the by using shim layer code? I'm unclear on how this affects the procedure/s. And what are the other common methods that are not addressed that you would like to see covered? --- Additional comment from Neil Horman on 2012-12-18 11:19:16 EST --- Jack I'm sorry, the description above isn't complete. The additional need for documentation here is not exclusively to support UEFI systems, but to support them using PXE for IPV4 and IPV6 using non secureboot and secureboot environments. The documentation you have covers IPV4 in a non-secureboot environment. I'll try to touch on the general changes that need to be made in each case: PXE+UEFI+IPV4+NO Secureboot - You're good to go, no changes need to be made PXE+UEFI+IPV6+No Secureboot - the server dhcp6 option is not filename, you need to instead specify bootfile-url option, which is a text string of the form: bootfile-url="tftp://[ipv6-address-in-brackets]/path/to/grub.efi PXE+UEFI+[IPv4|IPV6]+Secureboot - You can't boot grub directly with secureboot enabled, as its unsigned. We're in the process of getting the shim utility: https://github.com/mjg59/shim It will be signed and needs to be specified as the filename option or the bootfile-url option on the dhcp server. The shim utility will be downloaded, validated, and then it will be responsible for downloading the actual grub image (which must be named grub.efi or grubx64.efi and be tftp-able from the same location that the shim image was located at) So, I'm not sure at how you're looking to organize the docs for fedora (if you want to document secureboot booting procedures separately from non-secureboot environments or not), but thats the information that I was hoping to cover in this bz. If you feel like you have all that information in various locations, and can ennumerate them here, I think that would satisfy this bz in my mind. If any of it is missing however, and can be added, I would greatly appreciate it. I've got some virtual qemu guests setup to run an IPv6+UEFI+secure boot emulated environment here which you're welcome to poke around with to help flesh out the instructions if need be. And of course, I'm happy to answer any further quesstions you might have here. Thanks! Neil --- Additional comment from Jack Reed on 2012-12-19 00:31:51 EST --- Thanks for this, Neil. Having the distinct requirements for each use case outlined is really useful. However, I'm still not clear on the context or exact format of these configuration changes. Are they made in /etc/dhcp/dhcpd.conf, a sample of which is provided in step 4 of the following? http://docs.fedoraproject.org/en-US/Fedora/17/html/Installation_Guide/s1-ne… If so, I assume that 'filename "pxelinux/bootia32.efi";' should be replaced with 'bootfile-url="tftp://[ipv6-address-in-brackets]/path/to/grub.efi' (in the second use case you outline) or whatever is required for the third use case. Is that correct? But the config file in step 4 is only an example, and the filename strings in it are relevant in case certain conditions are met, whereas the filename and bootname-url strings you're referring to are perhaps uniform rather than conditional. Would you mind providing quick edited versions of that sample config file that incorporate these IPv6 and IPv4/6 Secureboot strings? (I'm particularly unclear on how to configure the latter.) Assuming that's where the editing needs to be done, of course. If it is, then explaining what is needed for IPv6 and SecureBoot in the 'Configuring for EFI' procedure may be enough, as opposed to breaking them off into another procedure. If the steps prove too difficult to integrate though, I will break them off. That said, you might be interested in an F18 draft document I've just been reminded of: http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html-sin… It's only in the early stages, but the material you want to add may also be beneficial here. Or you may feel that it is best suited to that guide alone. I don't have the perspective on the applicability of this new material to gauge that, so let me know what you think. --- Additional comment from Neil Horman on 2012-12-19 09:11:43 EST --- Sure, I'll attach my sample configs in a bit. To answer your specific questions above: 1) When configuring pxe for IPv6 vs. IPv4, the dhcp server configuration needs to change. Specifially, when using ipv4 you need to specify the filename dhcp option, exactly as it appears in the current netboot document you reference above When configuring pxe for ipv6 (weather or not you use secure boot, or UEFI for that matter), in addition to modifying the dhcp server configuration to serve ipv6 addresses, pxe support requires that you, instead of using the filename dhcp option to specify the file to download, you instead use the bootfile-url option, which is formatted as I noted above (its also expanded on in the dhcp-options man page). Note this change is orthogonal to any changes required to enable secureboot over pxe. This is just the change needed to support ipv6 pxe boot. As you not above, your configuration example is just that, an example. I don't know if you want to expand on it to demonstrate how pxe works differently with ipv6. If you do however (and I think it would be a good idea), the bootfile-url option is what you need to document. 2) Secureboot, when enabling secureboot, you have to make some additional changes. Specifically you have to specify a special file to download (not just the grub bootloader). This is because grub won't be signed with the master key. The shim utility I mentioned before will. If you're trying to boot a system via pxe in UEFI secure boot mode using ipv4, you have to use the filename dhcp option to specify that the shim utilty file be downloaded, whereas if you are booting a system via pxe in UEFI secure boot mode over ipv6, then you need to specify the shim utilty file on the dhcp server using the bootfile-url option. Note that if you are _not_ in secure boot mode, then you can specify any pxe boot file that you want on the server. Thats the meat of the change here: When in secure boot mode you need to specify the shim utilty as the file to download via tftp, as opposed to operating in non-secure-boot mode, when you can download and run any arbitrary file. Looking at your Secure boot page, I think thats a good start. Perhaps thats how this documentation should be split up - item (1) above can be edited into the netboot documentation, to show how the dhcp server config changes when using ipv6, and item (2) can be discussed in the secure boot page (since the shim utiltiy is requried when using secure boot, regardless of weather your booting locally or via pxe). I'll attach my sample dhcpd6.conf file in just a moment. --- Additional comment from Neil Horman on 2012-12-19 09:49:06 EST --- Created attachment 666108 sample dhcpd6.conf file Heres my example dhcpd6.conf file, which uses the bootfile-url option. Note that it specifies the shim.efi utility. This setup was used to boot a system in secure boot mode. If we weren't in secure boot mode, we could download any file we wanted. As it is, the shim utility is signed, alowing it to be run in secure boot mode. Once its validated, it will attempt to download the grubx[32|64].efi file from the same location it was downloaded from. -- You are receiving this mail because: You are the QA Contact for the bug.

1 2

[Bug 990372] New: Corrections proposed for Italian translation
by Red Hat Bugzilla 31 Jul '13

31 Jul '13

https://bugzilla.redhat.com/show_bug.cgi?id=990372 Bug ID: 990372 Summary: Corrections proposed for Italian translation Product: Fedora Documentation Version: devel Component: uefi-secure-boot-guide Severity: medium Assignee: sparks(a)redhat.com Reporter: dhatarattha(a)route-add.net QA Contact: docs-qa(a)lists.fedoraproject.org CC: sparks(a)redhat.com Description of problem: Hello Fedorian people, As I was extending my culture on things UEFIcal, I stumbled on the http://docs.fedoraproject.org/it-IT/Fedora/18/html-single/UEFI_Secure_Boot_… document and dedided I would help out making it better and eventually finish the translation into Italian. Please find under the "Additional info:" header a list of paragraphs with proposed corrections organized organized this way: 1) Chapter where the paragraph is located (e.g.: 1.1. UEFI Secure Boot) 1a) original English text from http://docs.fedoraproject.org/en-US/Fedora/18/html/UEFI_Secure_Boot_Guide/s… 1b) current Italian translation 1c) proposed Italian translation so subsitute the current one. 2a) original English text 2b) current Italian translation 2c) proposed Italian translation ... and so on. More to come later on. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: 1.1. UEFI Secure Boot Users are not offered a way to override the boot loader decision to reject the signature, unlike the similar scenario with web server certificates. No certificate issuer information is provided to the user. Gli utenti non dispongono di un modo per evitare la decisione del boot loader di rifiutare la firma, a differenza dei web server certificati nella stessa situazione. Nessuna informazione è fornita all'utente. Gli utenti non hanno modo di evitare che il boot loader rifiuti la firma, a differenza dei certificati dei web server in situazioni analoghe. All'utente non è fornita alcuna informazione su chi ha emesso il certificato. UEFI Secure Boot does not prevent the installation or removal of second-stage boot loaders or require explicit user confirmation of such changes. Signatures are verified during booting, and not when the boot loader is installed or updated. UEFI Secure Boot non impedisce l'installazione o la rimozione di boot loader di secondo stadio, ne richiede conferme esplicite all'utente per ogni modifica. Le firme vengono veificate durante l'avvio UEFI Secure Boot non impedisce l'installazione o la rimozione di boot loader di secondo stadio, né richiede all'utente conferma esplicita per tali modifiche. Le firme sono verificate durante l'avvio Therefore, UEFI Secure Boot does not stop boot path manipulations. It only prevents the system from executing a modified boot path once such a modification has occurred, and simplifies their detection. Quindi, UEFI Secure Boot non blocca le modifiche dei percorsi di avvio, ma impedisce di far partire il sistema da un percorso d'avvio modificato una volta sia stato ritenuto tale e ne semplifica la rilevazione. Quindi, UEFI Secure Boot non blocca le modifiche dei percorsi di avvio. Impedisce solo di far partire il sistema da un percorso d'avvio dopo che è stata apportata una tale modifica, e semplifica il loro rilevamento. UEFI Secure Boot is currently only generally enabled on client devices, and is currently not recommended for deployment on server machines. It is expected that server technology will enable Secure Boot at a future date. UEFI Secure Boot attualmente è generalemte solo abilitato per alcuni dispositivi e non è raccomandato per la distribuzione di server. Si prevede che la tecnologia server supporterà Secure Boot in futuro. UEFI Secure Boot attualmente è abilitato in genere solo su alcuni dispositivi client, e ad oggi non se ne consiglia l'impiego sui server. Si prevede che la tecnologia server abiliterà il Secure Boot in futuro. 1.2. Microsoft Requirements for Secure Boot Based on the public record, the following security objectives for Microsoft Secure Boot appear likely: Sulla base della documentazione pubblica, gli obiettivi di sicurezza seguenti per Microsoft Secure Boot sembrano probabili: Stando a quanto pubblicato, appaiono probabili i seguenti obiettivi di sicurezza di Microsoft Secure Boot: » integrity protection of installation media which is stored on writable media (such as hard disk recovery partitions), » protezione dell'integrità dei media d'installazione che sono memorizzati su dispositivi scrivibili (come partizioni di ricovero), » protezione dell'integrità dei supporti d'installazione memorizzati su dispositivi scrivibili (come le partizioni di ripristino dei dischi fissi), It is unclear whether there are plans to restrict access to certain (online) content to systems which have enabled UEFI Secure Boot and whose boot path is cryptographically valid. This would imply a remote attestation aspect which is not part of the UEFI Secure Boot specification, and which cannot be implemented securely without additional hardware support. It also would imply to that UEFI Secure Boot is no longer truly optional. Non è chiaro se ci sono piani per la restrizione dell'accesso (online) di contenuto ai sistemi che hanno UEFI Secure Boot abilitato ed il quale percorso di avvio è crittograficamente valido. Questo implicherebbe un'attestazione remota che non è parte delle specifiche di UEFI Secure Boot e che non può essere implementata con sicurezza senza il supporto di hardware addizionale. Inoltre implicherebbe che un UEFI Secure Boot non più veramente opzionale. Non è chiaro se ci sono piani per la restrizione dell'accesso (online) di contenuto a sistemi che hanno UEFI Secure Boot abilitato ed il cui percorso di avvio è crittograficamente valido. Questo implicherebbe un'attestazione remota che non fa parte delle specifiche di UEFI Secure Boot e che non può essere implementata con sicurezza senza il supporto di hardware aggiuntivo. Inoltre implicherebbe anche che un UEFI Secure Boot non sia più veramente opzionale. 1.3. Fedora Secure Boot The Fedora Secure Boot implementation has a single security objective: it prevents the execution of unsigned code in kernel mode. L'implementazione Fedora Secure Boot ha un singolo obbiettivo di sicurezza: impedire l'esecuzione di codice non firmato nei moduli kernel. L'implementazione Fedora di Secure Boot ha un singolo obiettivo di sicurezza: impedire l'esecuzione di codice non firmato a livello del kernel. -- You are receiving this mail because: You are the QA Contact for the bug.

1 3

[Bug 919665] New: Dead link in Install Guide pointing to yum update settings
by Red Hat Bugzilla 29 Jul '13

29 Jul '13

Product: Fedora Documentation https://bugzilla.redhat.com/show_bug.cgi?id=919665 Bug ID: 919665 Summary: Dead link in Install Guide pointing to yum update settings Product: Fedora Documentation Version: devel Component: install-guide Severity: medium Priority: unspecified Reporter: bryan.sutherland(a)gmail.com Depends On: 901692 Section 18.1 - Updating Your System, has a link pointing to a non-existent set of instructions for configuring daily updates with yum. The particular paragraph is: "If your Fedora system has a permanent network connection, you may choose to enable daily system updates. To enable automatic updates, follow the instructions on the webpage http://docs.fedoraproject.org/yum/sn-updating-your-system.html." Is anyone aware of where this doc set may have gone? -- You are receiving this mail because: You are the QA Contact for the bug.

1 6

[Bug 951950] New: Wrong pdf link (linkt to draft quick inst guide)
by Red Hat Bugzilla 29 Jul '13

29 Jul '13

Product: Fedora Documentation https://bugzilla.redhat.com/show_bug.cgi?id=951950 Bug ID: 951950 Summary: Wrong pdf link (linkt to draft quick inst guide) Product: Fedora Documentation Version: devel Component: install-guide Severity: unspecified Priority: unspecified Assignee: jreed(a)redhat.com Reporter: kraymond(a)shaiton.org QA Contact: docs-qa(a)lists.fedoraproject.org CC: oglesbyzm(a)gmail.com Category: --- as reported on the websites ML[1] the Install Guide PDF link is wrong (redirected to the quick install guide draft) on docs.fpo [1] http://lists.fedoraproject.org/pipermail/websites/2013-April/011321.html -- You are receiving this mail because: You are the QA Contact for the bug.

1 3

[Bug 981930] New: [F19] "fedup" command not listed in Installation Guide index
by Red Hat Bugzilla 25 Jul '13

25 Jul '13

https://bugzilla.redhat.com/show_bug.cgi?id=981930 Bug ID: 981930 Summary: [F19] "fedup" command not listed in Installation Guide index Product: Fedora Documentation Version: devel Component: install-guide Severity: unspecified Priority: unspecified Assignee: pbokoc(a)redhat.com Reporter: stephent98(a)hotmail.com QA Contact: docs-qa(a)lists.fedoraproject.org CC: oglesbyzm(a)gmail.com, pbokoc(a)redhat.com Description of problem: The "fedup" command is documented in the upgrade section[1], but the "fedup" command itself is not listed in the index. [1] http://docs.fedoraproject.org/en-US/Fedora/19/html/Installation_Guide/ch18s… [2] http://docs.fedoraproject.org/en-US/Fedora/19/html/Installation_Guide/ix01.… Version-Release number of selected component (if applicable): Fedora 19 Installation Guide http://docs.fedoraproject.org/en-US/Fedora/19/html/Installation_Guide/index… 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.

1 3

[Bug 980796] New: 3.2.2.1.3 Unnecessary steps in instruction to produce USB stick with dd
by Red Hat Bugzilla 25 Jul '13

25 Jul '13

https://bugzilla.redhat.com/show_bug.cgi?id=980796 Bug ID: 980796 Summary: 3.2.2.1.3 Unnecessary steps in instruction to produce USB stick with dd Product: Fedora Documentation Version: devel Component: install-guide Severity: unspecified Priority: unspecified Assignee: pbokoc(a)redhat.com Reporter: dottedmag(a)dottedmag.net QA Contact: docs-qa(a)lists.fedoraproject.org CC: oglesbyzm(a)gmail.com, pbokoc(a)redhat.com Description of problem: Steps 3 (checking partition layout on USB stick) and 4 (checking fs on a partition on USB stick) are unnecessary: step 5 overwrites whole USB device and hence previous partition layout and filesystems do not matter anymore. Version-Release number of selected component (if applicable): Docs for Fedora 19 How reproducible: always Steps to Reproduce: 1. Follow the steps 1, 2 and 5 of instruction 2. Boot the resulting USB device Actual results: USB device boots properly Expected results: Something should go wrong, as steps in guide were skipped Additional info: -- You are receiving this mail because: You are the QA Contact for the bug.

1 6

[Bug 984329] New: Incorrect fedup command in install guide
by Red Hat Bugzilla 25 Jul '13

25 Jul '13

https://bugzilla.redhat.com/show_bug.cgi?id=984329 Bug ID: 984329 Summary: Incorrect fedup command in install guide Product: Fedora Documentation Version: devel Component: install-guide Severity: unspecified Priority: unspecified Assignee: pbokoc(a)redhat.com Reporter: p_s_oberoi(a)hotmail.com QA Contact: docs-qa(a)lists.fedoraproject.org CC: oglesbyzm(a)gmail.com, pbokoc(a)redhat.com Description of problem: The Fedora 19 installation guide says (Section 18.2 - Upgrading Your System) that to upgrade using a network source: sudo fedup --network 18 --debuglog fedupdebug.log I think the 18 should probably be a 19. The web page in question is: http://docs.fedoraproject.org/en-US/Fedora/19/html/Installation_Guide/ch18s… Version-Release number of selected component (if applicable): 19 -- You are receiving this mail because: You are the QA Contact for the bug.

1 2

[Bug 977749] New: Update screenshots in the Installation Guide for F19
by Red Hat Bugzilla 25 Jul '13

25 Jul '13

https://bugzilla.redhat.com/show_bug.cgi?id=977749 Bug ID: 977749 Summary: Update screenshots in the Installation Guide for F19 Product: Fedora Documentation Version: devel Component: install-guide Severity: unspecified Priority: unspecified Assignee: pbokoc(a)redhat.com Reporter: pbokoc(a)redhat.com QA Contact: docs-qa(a)lists.fedoraproject.org CC: oglesbyzm(a)gmail.com, pbokoc(a)redhat.com Some of the screenshots in the current version of the Fedora Installation Guide are outdated, showing titles like Fedora 18 and Fedora 19 Pre-release/Testing. These will need to be updated for F19 release. List of affected screenshots: /images/boot/boot_screen.png /images/langselection/langselection-GUI.png /images/preinstallhub/preinstall_hub.png /images/timezone/timezone.png /images/kbdconfig/keyboard.png /images/langselection/langselection-hub-GUI.png /images/installationsource/installationsource.png /images/netconfig/networkconfig.png /images/pkgselection/pkg-group.png /images/diskpartsetup/disk-setup.png /images/storagedevices/selectstoragedevices-multipath.png /images/storagedevices/selectstoragedevices-san.png /images/storagedevices/selectstoragedevices.png /images/diskpartitioning/ddmain.png /images/diskpartitioning/write_changes.png /images/pkgselection/installing-packages.png /images/firstboot/fb-createuser.png /images/reboot/reboot.png -- You are receiving this mail because: You are the QA Contact for the bug.

1 2

[Bug 979826] New: The User Creation section refers to setting up network login at install, this option is unavailable
by Red Hat Bugzilla 25 Jul '13

25 Jul '13

https://bugzilla.redhat.com/show_bug.cgi?id=979826 Bug ID: 979826 Summary: The User Creation section refers to setting up network login at install, this option is unavailable Product: Fedora Documentation Version: devel Component: install-guide Severity: unspecified Priority: unspecified Assignee: pbokoc(a)redhat.com Reporter: pbokoc(a)redhat.com QA Contact: docs-qa(a)lists.fedoraproject.org CC: oglesbyzm(a)gmail.com, pbokoc(a)redhat.com In the current version of the Fedora Installation guide, section 9.16.2. User Creation refers to the possibility of setting up network login during the initial user creation. However, the button is gone in the most recent build of Fedora 19 beta. Find out what's up with that and if necessary remove section 9.16.2.1. Authentication Configuration, which details the procedure for setting up network login during the installation. -- You are receiving this mail because: You are the QA Contact for the bug.

1 3

[Bug 987147] New: New Bugzilla component for multiboot guide
by Red Hat Bugzilla 23 Jul '13

23 Jul '13

https://bugzilla.redhat.com/show_bug.cgi?id=987147 Bug ID: 987147 Summary: New Bugzilla component for multiboot guide Product: Fedora Documentation Version: devel Component: docs-requests Assignee: nobody(a)fedoraproject.org Reporter: croberts(a)cintrixhosting.com QA Contact: docs-qa(a)lists.fedoraproject.org CC: nobody(a)fedoraproject.org, oglesbyzm(a)gmail.com, sparks(a)redhat.com, stickster(a)gmail.com Document URL: Section Number and Name: Describe the issue: Suggestions for improvement: Additional information: -- You are receiving this mail because: You are the QA Contact for the bug.

1 6

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

docs-qa July 2013