This commit is contained in:
Matthew Miller
parent
cdfa79c99e
commit
d66c5e0a69
52 changed files with 15649 additions and 3 deletions
80
en-US/3rd-party-repos.adoc
Normal file
80
en-US/3rd-party-repos.adoc
Normal file
|
|
@ -0,0 +1,80 @@
|
|||
= Third party repositories
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/Third_party_repositories
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
There are a number of third-party software repositories for Fedora. They
|
||||
typically have more liberal licensing policies and provide software
|
||||
packages that Fedora excludes for various reasons. These software
|
||||
repositories are not officially affiliated or endorsed by the Fedora
|
||||
Project. Use them at your own discretion. A detailed list is maintained
|
||||
at https://ask.fedoraproject.org/en/question/39797/[Ask Fedora page]
|
||||
|
||||
The following repositories are commonly used by end users and do not
|
||||
conflict with each other
|
||||
|
||||
* http://rpmfusion.org
|
||||
* http://rpm.livna.org (Complementary to RPM Fusion)
|
||||
|
||||
There are a number of other repositories listed below but many of them
|
||||
are known to explicitly conflict with each other and hence not
|
||||
recommended unless you are a power user and know the technical aspects
|
||||
better.
|
||||
|
||||
* http://rpmfusion.org/FedoraThirdPartyRepos
|
||||
|
||||
[[mixing-third-party-software-repositories]]
|
||||
Mixing third party software repositories
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
We generally do not recommend mixing a lot of third party repositories
|
||||
since they might conflict with each other causing instability and hard
|
||||
to debug issues. If you are not a technical user, one safer method is to
|
||||
not enable the third-party repo by default and instead use the
|
||||
`--enablerepo` switch for `yum|dnf`, or a similar method configurable in
|
||||
the graphical package manager. There are a number of yum|dnf plugins for
|
||||
setting repo priorities or protecting the base packages from being
|
||||
obsoleted by third party repositories which are helpful to more
|
||||
technical users.
|
||||
|
||||
[[references]]
|
||||
References
|
||||
~~~~~~~~~~
|
||||
|
||||
* http://thread.gmane.org/gmane.linux.redhat.fedora.advisory-board/3288
|
||||
* http://fedoraproject.org/wiki/Objectives
|
||||
* http://fedoraproject.org/wiki/Forbidden_items
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
315
en-US/anaconda.adoc
Normal file
315
en-US/anaconda.adoc
Normal file
|
|
@ -0,0 +1,315 @@
|
|||
= Anaconda
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/Anaconda
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
image:DSC_3217.JPG[ 400px | Entering Anaconda, Montana. A city probably
|
||||
named after this installation program. David Cantrell took this picture
|
||||
in 2011. His grey VW Jetta is parked in the
|
||||
background.,title=" 400px | Entering Anaconda, Montana. A city probably named after this installation program. David Cantrell took this picture in 2011. His grey VW Jetta is parked in the background."]
|
||||
|
||||
Anaconda is the installation program used by Fedora, Red Hat Enterprise
|
||||
Linux and link:Anaconda/Distros[ some other distributions].
|
||||
|
||||
During installation, a target computer's hardware is identified and
|
||||
configured, and the appropriate file systems for the system's
|
||||
architecture are created. Finally, anaconda allows the user to install
|
||||
the operating system software on the target computer. anaconda can also
|
||||
upgrade existing installations of earlier versions of the same
|
||||
distribution. After the installation is complete, you can reboot into
|
||||
your installed system and continue doing customization using
|
||||
https://fedoraproject.org/wiki/InitialSetup[initial setup].
|
||||
|
||||
anaconda is a fairly sophisticated installer. It supports installation
|
||||
from local and remote sources such as CDs and DVDs, images stored on a
|
||||
hard drive, NFS, HTTP, and FTP. Installation can be scripted with
|
||||
link:Anaconda/Kickstart[ kickstart] to provide a fully unattended
|
||||
installation that can be duplicated on scores of machines. It can also
|
||||
be run over VNC on headless machines. A variety of advanced storage
|
||||
devices including LVM, RAID, iSCSI, and multipath are supported from the
|
||||
partitioning program. anaconda provides advanced debugging features such
|
||||
as remote logging, access to the python interactive debugger, and remote
|
||||
saving of exception dumps.
|
||||
|
||||
[[users]]
|
||||
Users
|
||||
~~~~~
|
||||
|
||||
If you are a user having problems with anaconda, please use the user
|
||||
support forum for your distribution such as
|
||||
http://forums.fedoraforum.org/forumdisplay.php?f=6[Fedora Forum] or
|
||||
https://admin.fedoraproject.org/mailman/listinfo/users[fedora-users].
|
||||
|
||||
From time to time, we may distribute updates for anaconda to fix
|
||||
problems in Fedora releases. The link:Anaconda/Updates[ updates] wiki
|
||||
page explains how to use these updates images.
|
||||
|
||||
Need to see what's changed from release to release? See our
|
||||
link:Anaconda/Changes[migration guide] which summarizes changes for
|
||||
users, rebuilders, and contributors.
|
||||
|
||||
[[advanced-users]]
|
||||
Advanced Users
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
If you are an advanced user of anaconda, you should check out
|
||||
https://anaconda-installer.readthedocs.io/en/latest/boot-options.html[our
|
||||
reference to anaconda command line
|
||||
options],https://anaconda-installer.readthedocs.io/en/latest/kickstart.html[our
|
||||
kickstart file format documentation] and link:Anaconda/Logging[ our
|
||||
reference to logging capabilities of anaconda].
|
||||
|
||||
There is a mailing list devoted to the use of kickstart. You can find
|
||||
the list signup and archive information at
|
||||
http://www.redhat.com/mailman/listinfo/kickstart-list[kickstart list] .
|
||||
This is the best place to share tips and tricks about kickstart.
|
||||
|
||||
[[distribution-builders]]
|
||||
Distribution Builders
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
For information on how to customize anaconda and trees created with it,
|
||||
please see link:Anaconda/ProductImage[ product.img],
|
||||
link:Anaconda/BuildDocProject[ BuildDocProject] and
|
||||
link:Anaconda/Customization[ Customization].
|
||||
|
||||
[[mailing-lists]]
|
||||
Mailing Lists
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
There are two mailing lists for Anaconda. The first is the development
|
||||
mailing list. This list is used to discuss development issues, submit
|
||||
patches, and other activities related to extending anaconda. The sign up
|
||||
for the development list is located at
|
||||
https://listman.redhat.com/mailman/listinfo/anaconda-devel-list[anaconda
|
||||
development list site] . Past discussions can be found in the
|
||||
https://www.redhat.com/archives/anaconda-devel-list[anaconda development
|
||||
archives] .
|
||||
|
||||
The second list is a user oriented list on how to create kickstart
|
||||
files. The kickstart list is the place to discuss automated installation
|
||||
issues. The sign up for the kickstart list is located at
|
||||
https://www.redhat.com/mailman/listinfo/kickstart-list[anaconda
|
||||
kickstart list site] . Past discussions can be found in the
|
||||
https://www.redhat.com/archives/kickstart-list[anaconda kickstart
|
||||
archives] .
|
||||
|
||||
Patch review used to take place on a mailing list dedicated to
|
||||
submitting and reviewing patches. Patch review now takes place on
|
||||
https://github.com/rhinstaller/anaconda/pulls[GitHub] via pull requests.
|
||||
Past discussions of patches can be found in the
|
||||
https://lists.fedorahosted.org/pipermail/anaconda-patches/[anaconda-patches
|
||||
archives], which is the main purpose this mailing list now serves.
|
||||
|
||||
[[irc]]
|
||||
IRC
|
||||
~~~
|
||||
|
||||
There is also an IRC channel on http://freenode.net. This resource is
|
||||
for discussion of anaconda development, not for distribution
|
||||
customization questions.
|
||||
|
||||
[[how-to-contribute]]
|
||||
How to Contribute
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
For how to contribute to Anaconda and related projects, see the
|
||||
https://fedoraproject.org/wiki/Anaconda/Contribute[Contributing to
|
||||
Anaconda and related projects] documentation.
|
||||
|
||||
Please note that useful contributions are not limited to submitting
|
||||
patches for source code. You can also help with
|
||||
https://anaconda-installer.readthedocs.io/en/latest/testing.html[testing],
|
||||
reporting bugs, improving translations or extending the Anaconda
|
||||
documentation.
|
||||
|
||||
[[developers-guide]]
|
||||
Developers' Guide
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
anaconda is now almost entirely written in Python 3. The graphical front
|
||||
end uses GTK+ 3 via gobject-introspection, and as much of the interface
|
||||
as possible is written using the glade interface builder. The earliest
|
||||
parts of anaconda are in shell for integration with dracut, and there's
|
||||
still a little bit of C thrown in for interfacing with certain
|
||||
libraries.
|
||||
|
||||
Here are some documents if you are planning on working on anaconda. More
|
||||
are in the works:
|
||||
|
||||
* Anaconda/Devel/Translation
|
||||
|
||||
* If you want to work on Anaconda, you should start with the
|
||||
link:Anaconda/SourceOverview[Source Overview], which contains a high
|
||||
level discussion of the source files and what they do. Then look at the
|
||||
https://anaconda-installer.readthedocs.io/en/latest/[online
|
||||
documentation] for information on how to test, debug, and develop
|
||||
anaconda.
|
||||
|
||||
Familiarize yourself with the tools that anaconda uses. Check out the
|
||||
following external reference documents:
|
||||
|
||||
* https://developer.gnome.org/gtk3/stable/[GTK+ reference]
|
||||
* https://docs.python.org/2/tutorial/[Python tutorial]
|
||||
* https://docs.python.org/2/py-modindex.html[Python module reference]
|
||||
|
||||
[[getting-the-source]]
|
||||
Getting the Source
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The primary methods of distributing the anaconda source are source RPMs
|
||||
in the
|
||||
http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/source/SRPMS/[Fedora
|
||||
development tree] and git. To access the current source code in in
|
||||
non-rpm format, you'll need to install git.
|
||||
|
||||
`dnf install git`
|
||||
|
||||
Note that several related packages will be installed as well. After the
|
||||
git source code management tool has been installed, then you use
|
||||
anonymous git access to the Anaconda repository.
|
||||
|
||||
`git clone `https://github.com/rhinstaller/anaconda.git[`https://github.com/rhinstaller/anaconda.git`]
|
||||
|
||||
The output may look similar to the following:
|
||||
|
||||
`Initialized empty Git repository in /home/drkludge/anacondatest/anaconda/.git/` +
|
||||
`remote: Generating pack...` +
|
||||
`remote: Counting objects: 10861` +
|
||||
`remote: Done counting 91222 objects.` +
|
||||
`remote: Deltifying 91222 objects...` +
|
||||
`remote: 100% (91222/91222) done` +
|
||||
`Indexing 91222 objects...` +
|
||||
`100% (91222/91222) done` +
|
||||
`remote: Total 91222 (delta 68785), reused 90187 (delta 68059)` +
|
||||
`Resolving 68785 deltas...` +
|
||||
`100% (68785/68785) done` +
|
||||
`Checking 543 files out...` +
|
||||
`100% (543/543) done`
|
||||
|
||||
If you have committer access to anaconda, then you will want to use the
|
||||
git+ssh access url.
|
||||
|
||||
`git clone git+ssh://git@github.com/rhinstaller/anaconda.git`
|
||||
|
||||
Once you've committed changes locally, you can push them with
|
||||
|
||||
`git push`
|
||||
|
||||
If you would just like to browse the Anaconda git repository via the
|
||||
web, then please use the following
|
||||
https://github.com/rhinstaller/anaconda.git[Anaconda git URLs].
|
||||
|
||||
https://github.com/rhinstaller/anaconda
|
||||
|
||||
Anaconda has an https://github.com/rhinstaller/kickstart-tests[extensive
|
||||
suite of tests] that is still growing. If you contribute new
|
||||
functionality, it's good practice to include some tests along with that.
|
||||
We have a
|
||||
https://anaconda-installer.readthedocs.io/en/latest/testing.html[document
|
||||
that outlines the test suite infratructure and describes how to run
|
||||
tests].
|
||||
|
||||
To contribute you should read our
|
||||
https://anaconda-installer.readthedocs.io/en/latest/contributing.html[guidelines
|
||||
for contributing].
|
||||
|
||||
[[reporting-problems]]
|
||||
Reporting Problems
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If you are having difficulty installing, please file the problem report
|
||||
with your distribution vendor.
|
||||
|
||||
Before filing a bug, please read up on
|
||||
link:How_to_debug_installation_problems[How to debug installation
|
||||
problems], which will tell you how to fill out useful bug reports that
|
||||
will help us quickly solve your problem. Also try searching bugzilla for
|
||||
other reports about your problem, as some bugs are often filed by
|
||||
several people.
|
||||
|
||||
link:Anaconda/AnacondaBugWorkflow[ AnacondaBugWorkflow] is a guideline
|
||||
to how Fedora anaconda bugs pass through bugzilla, and what all the
|
||||
various statuses really mean. This is *only* for Fedora.
|
||||
|
||||
[[anaconda-team]]
|
||||
Anaconda Team
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
image:20170607-brq-anaconda-group-photo02.jpg[ 500px,title=" 500px"]
|
||||
|
||||
From left to right, the following people are the anaconda team and are
|
||||
responsible for the majority of commits. Of course, we get help from
|
||||
other people both from Red Hat and from the volunteer community as well.
|
||||
|
||||
* Jiri Konecny (jkonecny): DUD, CI, UX, stuff.
|
||||
* User:Rvykydal[Radek Vykydal] (rvykydal): Networking, Atomic,
|
||||
packaging.
|
||||
* User:M4rtink[Martin Kolman] (mkolman): initial-setup, password stuff,
|
||||
UX, other stuff.
|
||||
* User:sbueno[Samantha N. Bueno] (sbueno): Manager.
|
||||
* Vendula Poncova (vponcova): s390x, storage tweaks, UX, other stuff.
|
||||
|
||||
[[anaconda-team-emeritus]]
|
||||
Anaconda Team Emeritus
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
* User:Clumens[Chris Lumens] (clumens)
|
||||
* User:Pjones[Peter Jones] (pjones)
|
||||
* User:Bcl[Brian Lane] (bcl)
|
||||
* User:Dcantrel[David Cantrell] (dcantrell)
|
||||
* User:Wwoods[Will Woods] (wwoods)
|
||||
* User:Dlehman[Dave Lehman] (dlehman)
|
||||
* User:vpodzime[Vratislav Podzimek] (vpodzime):
|
||||
* User:dshea[David Shea] (dshea)
|
||||
* User:katzj[Jeremy Katz] (katzj)
|
||||
* Joel Andres Granados (jgranado)
|
||||
* Hans de Goede (hansg)
|
||||
* User:Akozumpl[Ales Kozumplik] (akozumpl)
|
||||
* User:Mgracik[Martin Gracik] (mgracik)
|
||||
* User:jkeating[Jesse Keating] (jlk)
|
||||
* User:Msivak[Martin Sivak] (msivak)
|
||||
|
||||
[[design]]
|
||||
Design
|
||||
~~~~~~
|
||||
|
||||
* link:Anaconda/UX_Redesign[ Anaconda UX Redesign]
|
||||
* link:How_to_Create_an_Anaconda_Banner[ How to Create an Anaconda
|
||||
Banner]
|
||||
|
||||
Category:Anaconda
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
334
en-US/apache-httpd.adoc
Normal file
334
en-US/apache-httpd.adoc
Normal file
|
|
@ -0,0 +1,334 @@
|
|||
= Apache HTTP Server
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/Apache_HTTP_Server
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
The Apache HTTP Server is one of the most commonly-used web servers.
|
||||
This page acts as a quick start guide to deploying and configuring
|
||||
Apache on Fedora. For (many) more details, please see
|
||||
https://httpd.apache.org/docs/current/[upstream's extensive
|
||||
documentation].
|
||||
|
||||
[[installation]]
|
||||
Installation
|
||||
~~~~~~~~~~~~
|
||||
|
||||
`$ su` +
|
||||
`# dnf install httpd`
|
||||
|
||||
To have the server start at each boot:
|
||||
|
||||
`# systemctl enable httpd.service`
|
||||
|
||||
To start the server now:
|
||||
|
||||
`# systemctl start httpd.service`
|
||||
|
||||
At this point, you should be able to browse to http://localhost on the
|
||||
server and access the Apache test page. You will most likely not be able
|
||||
to access the server from any other host, yet: we will change this
|
||||
link:#firewall-configuration[later].
|
||||
|
||||
[[tlsssl-support]]
|
||||
TLS/SSL support
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
If you want TLS/SSL support, you can also install , which is based on
|
||||
https://www.openssl.org[OpenSSL]. Alternatives are (uses
|
||||
https://www.gnutls.org/[GnuTLS]) and (uses
|
||||
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS[NSS]).
|
||||
|
||||
[[using-mod_ssl]]
|
||||
Using mod_ssl
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
Install mod_ssl package and it will be automatically enabled
|
||||
|
||||
`# dnf install mod_ssl`
|
||||
|
||||
[[install-an-existing-certificate]]
|
||||
Install an existing certificate
|
||||
+++++++++++++++++++++++++++++++
|
||||
|
||||
If you already have a certificate generated on another computer, move
|
||||
the certificate and the key file to the correct folder, and ensure their
|
||||
SELinux contexts, ownership, and permissions are correct:
|
||||
|
||||
`# mv key_file.key /etc/pki/tls/private/myhost.com.key` +
|
||||
`# restorecon /etc/pki/tls/private/myhost.com.key` +
|
||||
`# chown root.root /etc/pki/tls/private/myhost.com.key` +
|
||||
`# chmod 0600 /etc/pki/tls/private/myhost.com.key` +
|
||||
`#` +
|
||||
`# mv certificate.crt /etc/pki/tls/certs/myhost.com.crt` +
|
||||
`# restorecon /etc/pki/tls/certs/myhost.com.crt` +
|
||||
`# chown root.root /etc/pki/tls/certs/myhost.com.crt` +
|
||||
`# chmod 0600 /etc/pki/tls/certs/myhost.com.crt`
|
||||
|
||||
After this link:#mod_ssl-configuration[ set it up]
|
||||
|
||||
[[generate-a-new-certificate]]
|
||||
Generate a new certificate
|
||||
++++++++++++++++++++++++++
|
||||
|
||||
How to https://fedoraproject.org/wiki/Https#openssl[generate a new
|
||||
certificate]
|
||||
|
||||
[[mod_ssl-configuration]]
|
||||
mod_ssl configuration
|
||||
+++++++++++++++++++++
|
||||
|
||||
The default TLS/SSL configuration is contained in the file (if you are
|
||||
using ). If you examine that file, you will see the directives that
|
||||
specify where the TLS/SSL certificate and key are located:
|
||||
|
||||
`SSLCertificateFile /etc/pki/tls/certs/localhost.crt` +
|
||||
`SSLCertificateKeyFile /etc/pki/tls/private/localhost.key`
|
||||
|
||||
If you look carefully, you will see that these directives are actually
|
||||
enclosed in a block defining a
|
||||
https://httpd.apache.org/docs/current/vhosts/[virtual host]:
|
||||
|
||||
+
|
||||
`...` +
|
||||
`SSLCertificateFile /etc/pki/tls/certs/localhost.crt` +
|
||||
`...` +
|
||||
`SSLCertificateKeyFile /etc/pki/tls/private/localhost.key` +
|
||||
`...` +
|
||||
|
||||
If we wanted to define a different location for these files, we could
|
||||
edit the lines in directly, but it would be better to create a new file
|
||||
:
|
||||
|
||||
+
|
||||
`SSLCertificateFile /etc/pki/tls/certs/www.myhost.org.crt` +
|
||||
`SSLCertificateKeyFile /etc/pki/tls/private/www.myhost.org.key` +
|
||||
|
||||
This file will override those two settings for the _default_:443 virtual
|
||||
host; all other settings from will be kept.
|
||||
|
||||
[[settings-for-individual-virtual-hosts]]
|
||||
Settings for individual virtual hosts
|
||||
|
||||
If you want a specific virtual host to use SSL/TLS with a different
|
||||
certificate from the default, open that virtual host's configuration
|
||||
file, usually , and insert these lines between and :
|
||||
|
||||
`SSLEngine on` +
|
||||
`SSLCertificateFile /etc/pki/tls/certs/hostname.crt` +
|
||||
`SSLCertificateKeyFile /etc/pki/tls/private/hostname.key`
|
||||
|
||||
[[installing-webapps]]
|
||||
Installing webapps
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
You probably want to run something on your web server. Many of the most
|
||||
popular 'web applications' are packaged for Fedora. Using the packaged
|
||||
versions of web applications is usually recommended: they will be
|
||||
configured following the distribution's best practices which help to
|
||||
ensure the security of the installation, for instance by installing
|
||||
static files to locations the web server does not have the ability to
|
||||
write to, and doing access control with configuration files rather than
|
||||
files, which are slightly more vulnerable to attack.
|
||||
|
||||
Packaged web applications will also be configured to work with SELinux,
|
||||
which provides significant security benefits.
|
||||
|
||||
You will also receive updates through the usual Fedora update process,
|
||||
making it easier to keep your installation up to date.
|
||||
|
||||
They will also often have the default configuration tweaked according to
|
||||
Fedora's conventions, meaning you have to do less work to get the
|
||||
application up and running.
|
||||
|
||||
Most web applications are simply packaged according to their name. For
|
||||
example, you can install Wordpress with:
|
||||
|
||||
`# dnf install wordpress`
|
||||
|
||||
Packaged web applications will usually provide Fedora-specific
|
||||
instructions in a documentation file - for instance, Wordpress provides
|
||||
the files and . It is always a good idea to read these files!
|
||||
|
||||
Packaged web applications usually restrict access by default so you can
|
||||
access them only from the server host itself, to ensure you can run all
|
||||
initial configuration safely and things like administration interfaces
|
||||
are not left accessible to the public. For information on how to broaden
|
||||
access, see link:#webapp-access-control[below].
|
||||
|
||||
Web applications commonly require the use of a database server. This
|
||||
wiki contains information on installing and configuring PostgreSQL and
|
||||
MariaDB on Fedora.
|
||||
|
||||
[[configuration]]
|
||||
Configuration
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
is the main Apache configuration file. It _includes_ : if the same
|
||||
setting is specified in both and a file in , the setting from the file
|
||||
will win. Files in are read in alphabetical order: a setting from will
|
||||
win over a setting from , which will win over a setting from , which
|
||||
will win over a setting from .
|
||||
|
||||
It is usually best practice never to modify or any of the files shipped
|
||||
by Fedora packages directly. If you make any local changes to these
|
||||
files, then any changes to them in newer package versions will not be
|
||||
directly applied: instead a file will be created and you will have to
|
||||
merge the changes manually. It is usually better instead to create a new
|
||||
file in which will take precedence over the file you wish to 'modify',
|
||||
and make your settings there. For instance, to change a setting
|
||||
specified in you could create the file and place your setting in that
|
||||
file. We will see an example of this next.
|
||||
|
||||
After making any changes to your server configuration, you should run:
|
||||
|
||||
`# apachectl reload`
|
||||
|
||||
to apply the changes. Certain changes may require Apache to be fully
|
||||
restarted:
|
||||
|
||||
`# systemctl restart httpd.service`
|
||||
|
||||
[[enabling-access-to-web-applications]]
|
||||
Enabling access to web applications
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Fedora-packaged web applications are usually configured such that, by
|
||||
default, access is allowed only from localhost. Typically you will find
|
||||
that there is a file with the following (among other settings):
|
||||
|
||||
+
|
||||
` ` +
|
||||
` # Apache 2.4` +
|
||||
` Require local` +
|
||||
` ` +
|
||||
` ` +
|
||||
` # Apache 2.2` +
|
||||
` Order Deny,Allow` +
|
||||
` Deny from all` +
|
||||
` Allow from 127.0.0.1` +
|
||||
` Allow from ::1` +
|
||||
` ` +
|
||||
|
||||
Before allowing general access to the webapp, ensure you have configured
|
||||
it correctly and the administration interface and other sensitive areas
|
||||
are not accessible without appropriate authentication. Also remember to
|
||||
ensure your database configuration is secure, if the application uses a
|
||||
database. To broaden access to the application, you can create a file .
|
||||
To allow access to all systems on a typical local network, you could
|
||||
write:
|
||||
|
||||
+
|
||||
` ` +
|
||||
` # Apache 2.4` +
|
||||
` Require local` +
|
||||
` Require ip 192.168.1` +
|
||||
` ` +
|
||||
` ` +
|
||||
` # Apache 2.2` +
|
||||
` Order Deny,Allow` +
|
||||
` Deny from all` +
|
||||
` Allow from 127.0.0.1` +
|
||||
` Allow from ::1` +
|
||||
` Allow from 192.168.1` +
|
||||
` ` +
|
||||
|
||||
Once you are sure the application is correctly configured, this
|
||||
configuration will allow access from any host:
|
||||
|
||||
+
|
||||
` ` +
|
||||
` # Apache 2.4` +
|
||||
` Require all granted` +
|
||||
` ` +
|
||||
` ` +
|
||||
` # Apache 2.2` +
|
||||
` Order Deny,Allow` +
|
||||
` Allow from all` +
|
||||
` ` +
|
||||
|
||||
[[opening-firewall-ports]]
|
||||
Opening firewall ports
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Apache uses port 80 for plain http connections and port 443 for TLS/SSL
|
||||
connections by default. To make this service available from other
|
||||
computers or the Internet your have to allow Apache through the firewall
|
||||
like this:
|
||||
|
||||
To open the firewall at each boot:
|
||||
|
||||
For plain HTTP connections:
|
||||
|
||||
`# firewall-cmd --permanent --add-service=http`
|
||||
|
||||
For TLS/SSL connections:
|
||||
|
||||
`# firewall-cmd --permanent --add-service=https`
|
||||
|
||||
To open the firewall right now:
|
||||
|
||||
For plain HTTP connections:
|
||||
|
||||
`# firewall-cmd --add-service=http`
|
||||
|
||||
For TLS/SSL connections:
|
||||
|
||||
`# firewall-cmd --add-service=https`
|
||||
|
||||
Remember that if your server is running behind a NAT router, you will
|
||||
also need to configure your router to forward the HTTP and HTTPS ports
|
||||
to your server if you wish to allow access from outside your local
|
||||
network.
|
||||
|
||||
[[disable-test-page]]
|
||||
Disable test page
|
||||
^^^^^^^^^^^^^^^^^
|
||||
|
||||
To disable the test page comment out all the lines in the file
|
||||
|
||||
[[references]]
|
||||
References
|
||||
~~~~~~~~~~
|
||||
|
||||
* https://httpd.apache.org/docs/current/[Apache documentation]
|
||||
* https://httpd.apache.org/docs/current/getting-started.html[Apache
|
||||
"Getting Started"]
|
||||
* https://httpd.apache.org/docs/current/ssl/[Apache TLS/SSL
|
||||
documentation]
|
||||
* https://httpd.apache.org/docs/current/misc/security_tips.html[Apache
|
||||
security tips]
|
||||
* OwnCloud
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
478
en-US/autoupdates.adoc
Normal file
478
en-US/autoupdates.adoc
Normal file
|
|
@ -0,0 +1,478 @@
|
|||
= AutoUpdates
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/AutoUpdates
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
[[automatic-updates]]
|
||||
Automatic Updates
|
||||
-----------------
|
||||
|
||||
You must decide whether to use automatic link:dnf[DNF] or link:yum[YUM]
|
||||
updates on each of your machines. There are a number of arguments both
|
||||
for and against automatic updates to consider. However, there is no
|
||||
single answer to this question: It is up to the system administrator or
|
||||
owner of each machine to decide whether automatic updates are desirable
|
||||
or not for that machine. One of the things which makes one a good system
|
||||
administrator is the ability to evaluate the facts and other people's
|
||||
suggestions, and then decide for onesself what one should do.
|
||||
|
||||
A general rule that applies in most cases is as follows:
|
||||
|
||||
_If the machine is a critical server, for which unplanned downtime of a
|
||||
service on the machine can not be tolerated, then you should not use
|
||||
automatic updates. Otherwise, you *may* choose to use them._
|
||||
|
||||
Even the general rule above has exceptions, or can be worked around.
|
||||
Some issues might be resolved through a special setup on your part. For
|
||||
example, you could create your own dnf|yum repository on a local server,
|
||||
and only put in it tested or trusted updates. Then use the automatic
|
||||
updates from only your own repository. Such setups, while perhaps more
|
||||
difficult to setup and maintain, can remove a large amount of risk
|
||||
otherwise inherent in automatic updates.
|
||||
|
||||
[[how-are-automatic-updates-done]]
|
||||
How are automatic updates done?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
You can use a service to automatically download and install any new
|
||||
updates (for example security updates).
|
||||
|
||||
[[fedora-22-or-later-versions]]
|
||||
Fedora 22 or later versions
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The http://dnf.readthedocs.org/en/latest/automatic.html[dnf-automatic]
|
||||
RPM package as a link:dnf[DNF] component provides a service which is
|
||||
started automatically.
|
||||
|
||||
[[install-and-settings-of-dnf-automatic]]
|
||||
Install and settings of dnf-automatic
|
||||
+++++++++++++++++++++++++++++++++++++
|
||||
|
||||
On a fresh install of Fedora 22 with default options the dnf-automatic
|
||||
RPM is not installed, the first command below installs this RPM.
|
||||
|
||||
....
|
||||
dnf install dnf-automatic
|
||||
....
|
||||
|
||||
Though, you have to change a configuration file. In order to do this,
|
||||
run as the root user (or become root via su -) from a terminal window.
|
||||
|
||||
....
|
||||
env EDITOR='gedit -w' sudoedit /etc/dnf/automatic.conf
|
||||
....
|
||||
|
||||
Detailed description of dnf-automatic settings is provided on
|
||||
http://dnf.readthedocs.org/en/latest/automatic.html[dnf-automatic] page.
|
||||
|
||||
[[run-dnf-automatic]]
|
||||
Run dnf-automatic
|
||||
+++++++++++++++++
|
||||
|
||||
Once you are finished with configuration, execute:
|
||||
|
||||
`systemctl enable dnf-automatic.timer && systemctl start dnf-automatic.timer`
|
||||
|
||||
to enable and start the systemd timer.
|
||||
|
||||
Check status of dnf-automatic:
|
||||
|
||||
`# systemctl list-timers *dnf-*`
|
||||
|
||||
[[changes-as-of-fedora-26]]
|
||||
Changes as of Fedora 26
|
||||
|
||||
As of Fedora 26 there are now three timers that control dnf-automatic.
|
||||
|
||||
* dnf-automatic-download.timer - Only download
|
||||
* dnf-automatic-install.timer - Download and install
|
||||
* dnf-automatic-notifyonly.timer - Only notify via configured emitters
|
||||
in _/etc/dnf/automatic.conf_
|
||||
|
||||
You can still use _download_updates_ and _apply_updates_ settings from
|
||||
inside _/etc/dnf/automatic.conf_.
|
||||
|
||||
[[fedora-21-or-earlier-versions]]
|
||||
Fedora 21 or earlier versions
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The yum-cron RPM package provides a service which is started
|
||||
automatically. Though, you have to change a configuration file. In order
|
||||
to do this, run as the root user (or become root via su -) from a
|
||||
terminal window. On a fresh install of Fedora 20 with default options
|
||||
the yum-cron RPM is not installed, the first command below installs this
|
||||
RPM.
|
||||
|
||||
....
|
||||
yum install -y yum-cron
|
||||
env EDITOR='gedit -w' sudoedit /etc/yum/yum-cron.conf"
|
||||
....
|
||||
|
||||
and enter your password. After, change the line
|
||||
|
||||
....
|
||||
apply_updates = no
|
||||
....
|
||||
|
||||
to
|
||||
|
||||
....
|
||||
apply_updates = yes
|
||||
....
|
||||
|
||||
Save the file. You are now done. Yum-cron updates your system every time
|
||||
when there are new updates available.
|
||||
|
||||
[[can-we-trust-dnf-or-yum-updates]]
|
||||
Can we trust dnf or yum updates?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Dnf and Yum in Fedora has the GPG key checking enabled by default.
|
||||
Assuming that you have imported the correct GPG keys, and still have
|
||||
gpgcheck=1 in your for dnf or for yum, then we can at least assume that
|
||||
any automatically installed updates were not corrupted or modified from
|
||||
their original state. Using the GPG key checks, there is no way for an
|
||||
attacker to generate packages that your system will accept as valid
|
||||
(unless they have a copy of the *private* key corresponding to one you
|
||||
installed) and any data corruption during download would be caught.
|
||||
|
||||
However, the question would also apply to the question of update
|
||||
quality. Will the installation of the package cause problems on your
|
||||
system? This we can not answer. Each package goes through a QA process,
|
||||
and is assumed to be problem free. But, problems happen, and QA can not
|
||||
test all possible cases. It is always possible that any update may cause
|
||||
problems during or after installation.
|
||||
|
||||
[[why-use-automatic-updates]]
|
||||
Why use Automatic updates?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The main advantage of automating the updates is that machines are likely
|
||||
to get updated more quickly, more often, and more uniformly than if they
|
||||
updates are done manually. We see too many compromised machines on the
|
||||
internet which would have been safe if the latest updates where
|
||||
installed in a timely way.
|
||||
|
||||
So while you should still be cautious with any automated update
|
||||
solution, in particular on production systems, it is definitely worth
|
||||
considering, at least in some situations.
|
||||
|
||||
[[reasons-for-using-automatic-updates]]
|
||||
Reasons FOR using automatic updates
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
While no one can determine for you if your machine is a good candidate
|
||||
for automatic updates, there are several things which tend to make a
|
||||
machine a better candidate for automatic updates.
|
||||
|
||||
Some things which might make your machine a good candidate for automatic
|
||||
updates are:
|
||||
|
||||
* You are unlikely to apply updates manually for whatever reason(s).
|
||||
* The machine is not critical and occasional unplanned downtime is
|
||||
acceptable.
|
||||
* You can live without remote access to the machine until you can get to
|
||||
its physical location to resolve problems.
|
||||
* You do not have any irreplaceable data on the machine, or have proper
|
||||
backups of such data.
|
||||
|
||||
If all of the above apply to your machine(s), then automatic updates may
|
||||
be your best option to help secure your machine. If not all of the above
|
||||
apply, then you will need to weigh the risks and decide for yourself if
|
||||
automatic updates are the best way to proceed.
|
||||
|
||||
[[reasons-against-using-automatic-updates]]
|
||||
Reasons AGAINST using automatic updates
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
While no one can determine for you if your machine is a bad candidate
|
||||
for automatic updates, there are several things which tend to make a
|
||||
machine a worse candidate for automatic updates.
|
||||
|
||||
Some things which might make your machine be a bad candidate for
|
||||
automatic updates are:
|
||||
|
||||
* It provides a critical service that you don't want to risk having
|
||||
unscheduled downtime.
|
||||
* You installed custom software, compiled software from source, or use
|
||||
third party software that has strict package version requirements.
|
||||
* You installed a custom kernel, custom kernel modules, third party
|
||||
kernel modules, or have a third party application that depends on kernel
|
||||
versions (this may not be a problem if you exclude kernel updates, which
|
||||
is the default in Fedora dnf.conf or yum.conf files). (But see also
|
||||
https://bugzilla.redhat.com/show_bug.cgi?id=870790[bug #870790] - you
|
||||
may need to modify in Fedora 22 or later versions in base section to add
|
||||
exclude=kernel*. or in Fedora 21 or earlier versions to
|
||||
exclude=kernel*.)
|
||||
* Your enviroment requires meticulous change-control procedures.
|
||||
* You update from other third party yum|dnf repositories besides Fedora
|
||||
(core, extras, legacy ) repositories which may conflict in versioning
|
||||
schemes for the same packages.
|
||||
|
||||
There are also some other reasons why installing automatic updates
|
||||
without testing may be a bad idea. A few such reasons are:
|
||||
|
||||
* The need to back up your configuration files before an update. Even
|
||||
the best package spec files can have mistakes. If you have modified a
|
||||
file which is not flagged as a configuration file, then you might lose
|
||||
your configuration changes. Or an update may have a different format of
|
||||
configuration file, requiring a manual reconfiguration. It is often best
|
||||
to backup your configuration files before doing updates on critical
|
||||
packages such as mail, web, or database server packages.
|
||||
* Unwanted side effects. Some packages can create annoying side effects,
|
||||
particularly ones which have cron jobs. Updates to base packages like
|
||||
openssl, openldap, sql servers, etc. can have an effect on many other
|
||||
seemingly unrelated packages.
|
||||
* Bugs. Many packages contain buggy software or installation scripts.
|
||||
The update may create problems during or after installation. Even
|
||||
cosmetic bugs like those found in previous Mozilla updates (causing the
|
||||
user's icons to be removed or break) can be annoying or problematic.
|
||||
* Automatic updates may not complete the entire process needed to make
|
||||
the system secure. For example, dnf or yum can install a kernel update,
|
||||
but until the machine is rebooted (which dnf or yum will not do
|
||||
automatically) the new changes won't take effect. The same may apply to
|
||||
restarting daemons. This can leave the user feeling that he is secure
|
||||
when he is not.
|
||||
|
||||
[[best-practices-when-using-automatic-updates]]
|
||||
Best practices when using automatic updates
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If you decide to use automatic updates, you should at least do a few
|
||||
things to make sure you are up-to-date.
|
||||
|
||||
Check for package updates which have been automatically performed, and
|
||||
note if they need further (manual) intervention. You can monitor what
|
||||
dnf or yum has updated via its log file (usually or ).
|
||||
|
||||
[[fedora-22-or-later-versions-1]]
|
||||
Fedora 22 or later versions
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
You can monitor updates availability automatically by email after
|
||||
modifying dnf-automatic configuration file (usually ).
|
||||
|
||||
....
|
||||
[emitters]
|
||||
emit_via = email
|
||||
|
||||
[email]
|
||||
# The address to send email messages from.
|
||||
email_from = root@localhost.com
|
||||
|
||||
# List of addresses to send messages to.
|
||||
email_to = root
|
||||
|
||||
# Name of the host to connect to to send email messages.
|
||||
email_host = localhost
|
||||
....
|
||||
|
||||
You would replace root with a actual email address to which you want to
|
||||
report sent, and localhost with a actual address of SMTP server. This
|
||||
change will mean that after dnf-automatic runs, it will email you
|
||||
information you about available updates, or log about downloaded
|
||||
packages, or installed updates according to settings in .
|
||||
|
||||
[[fedora-21-or-earlier-versions-1]]
|
||||
Fedora 21 or earlier versions
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
You can monitor this automatically by email by modifying the cron job to
|
||||
mail you the last part of the log file. For example, edit
|
||||
/etc/cron.daily/yum.cron so that it looks like the following:
|
||||
|
||||
....
|
||||
#!/bin/sh
|
||||
|
||||
if [ -f /var/lock/subsys/yum ] ; then
|
||||
/usr/bin/yum -R 10 -e 0 -d 0 -y update yum
|
||||
/usr/bin/yum -R 120 -e 0 -d 0 -y update
|
||||
/usr/bin/tail /var/log/yum.log | /bin/mail -s yum-report youremail@yourdmain
|
||||
fi
|
||||
....
|
||||
|
||||
You would replace youremail@yourdomain with a actual email address to
|
||||
which you want to report sent. This change will mean that after yum runs
|
||||
every night, it will email you the tail end of the log file showing what
|
||||
happened. (Note this assumes you have a working mail setup on your
|
||||
machine.)
|
||||
|
||||
[[alternative-methods]]
|
||||
Alternative methods
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
As an alternative to dnf-automatic or yum-cron,
|
||||
https://github.com/rackerlabs/auter[auter] can be used. This operates in
|
||||
a similar way to yum-cron, but provides more flexibility in scheduling,
|
||||
and some additional options including running custom scripts before or
|
||||
after updates, and automatic reboots. This comes at the expensive of
|
||||
more complexity to configure.
|
||||
|
||||
....
|
||||
dnf install auter
|
||||
....
|
||||
|
||||
Edit the configuration. Descriptions of the options are contained in the
|
||||
conf file:
|
||||
|
||||
....
|
||||
/etc/auter/auter.conf
|
||||
....
|
||||
|
||||
Auter is not scheduled by default. Add a schedule for "--prep" (if you
|
||||
want to pre-download updates) and "--apply" (install updates). The
|
||||
installed cron job contains lots of examples:
|
||||
|
||||
....
|
||||
/etc/cron.d/auter
|
||||
....
|
||||
|
||||
To make auter run immediately without waiting for the cron job to run,
|
||||
for example for testing or debugging, you can simply run it from the
|
||||
command line:
|
||||
|
||||
....
|
||||
auter --apply
|
||||
....
|
||||
|
||||
If you want to disable auter from running, including from any cron job:
|
||||
|
||||
....
|
||||
auter --disable
|
||||
....
|
||||
|
||||
[[alternatives-to-automatic-updates]]
|
||||
Alternatives to automatic updates
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
[[notifications]]
|
||||
Notifications
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
[[fedora-22-or-later-versions-2]]
|
||||
Fedora 22 or later versions
|
||||
+++++++++++++++++++++++++++
|
||||
|
||||
Instead of automatic updates, dnf-automatic can only download new
|
||||
updates and can alert your via email of available updates which you
|
||||
could then install manually. It can be set by editing of file.
|
||||
|
||||
[[fedora-21-or-earlier-versions-2]]
|
||||
Fedora 21 or earlier versions
|
||||
+++++++++++++++++++++++++++++
|
||||
|
||||
Instead of automatic updates yum can alert your via email of available
|
||||
updates which you could then install manually. You could accomplish such
|
||||
a setup with a cron job such as that listed below. Simply put this in
|
||||
/etc/cron.daily with a suitable filename (such as
|
||||
yum-check-updates.cron).
|
||||
|
||||
....
|
||||
#!/bin/sh
|
||||
|
||||
/usr/bin/yum check-update 2>&1 | /bin/mail -s "yum check-update output" root
|
||||
....
|
||||
|
||||
You can of course change the email address it sends to, etc. to meet
|
||||
your own needs.
|
||||
|
||||
[[scheduling-updates]]
|
||||
Scheduling updates
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Another common problem is having automatic updates run when it isn't
|
||||
desired (holidays, weekends, vacations, etc). If there are times that no
|
||||
one will be around to fix any problem arising the from the updates, it
|
||||
may be best to avoid doing updates on those days.
|
||||
|
||||
[[fedora-22-or-later-versions-3]]
|
||||
Fedora 22 or later versions
|
||||
+++++++++++++++++++++++++++
|
||||
|
||||
This problem can be fixed by modification of the timer of dnf-automatic
|
||||
using the description on
|
||||
https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units[Use
|
||||
Systemctl] page.
|
||||
|
||||
[[fedora-21-or-earlier-versions-3]]
|
||||
Fedora 21 or earlier versions
|
||||
+++++++++++++++++++++++++++++
|
||||
|
||||
One method is to use a crontab entry instead of the
|
||||
/etc/cron.daily/yum.conf provided by default. For example, to only run
|
||||
updates from Monday through Friday mornings (avoiding weekends), you
|
||||
might use a crontab entry such as the following:
|
||||
|
||||
....
|
||||
0 7 * * 1-5 /usr/bin/yum -y update
|
||||
....
|
||||
|
||||
If you need more control over when it runs, you could create a file
|
||||
called, for example, /usr/local/etc/no-yum-update.conf, which contains a
|
||||
list of dates not to update on. What dates go in this file is up to you
|
||||
to decide (vacations, holidays, etc). The dates would be in the format
|
||||
YYYY-MM-DD (e.g. 2005-03-31). Then create a
|
||||
/etc/cron.daily/yum-update.cron script something like the following:
|
||||
|
||||
....
|
||||
#!/bin/sh
|
||||
|
||||
today=$(date +%Y-%m-%d)
|
||||
|
||||
while read banned; do
|
||||
[ "$today" == "$banned" ] && exit 0
|
||||
done < /usr/local/etc/no-yum-update.conf
|
||||
yum -y update
|
||||
....
|
||||
|
||||
[[other-methods-of-protection]]
|
||||
Other methods of protection
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Yet another thing to consider if not using automatic updates is to
|
||||
provide your machine with some other forms of protection to help defend
|
||||
any attacks that might occur before updates are in place. This might
|
||||
include an external firewall, a host-based firewall (like iptables,
|
||||
ipchains, and/or tcp wrappers), not performing dangerous tasks on the
|
||||
computer (like browsing the web, reading e-mail, etc), and monitoring
|
||||
the system for instrusions (with system log checkers, IDS systems,
|
||||
authentication or login monitoring, etc).
|
||||
|
||||
'''''
|
||||
|
||||
Category:Documentation
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
384
en-US/build-custom-kernel.adoc
Normal file
384
en-US/build-custom-kernel.adoc
Normal file
|
|
@ -0,0 +1,384 @@
|
|||
= Building a custom kernel
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/Building_a_custom_kernel
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
This document provides instructions for advanced users who want to
|
||||
rebuild the kernel from some source. Note, however, that when building
|
||||
or running any such kernel, one should NOT expect support from the
|
||||
Fedora kernel team; you're pretty much on your own here if something
|
||||
doesn't work as you'd hoped or expected. But hey, you're an advanced
|
||||
user, so you can handle it, right? Anyway, advanced users build custom
|
||||
kernels for a variety of reasons:
|
||||
|
||||
* To apply patches for testing that they either generated or obtained
|
||||
from another source
|
||||
* To reconfigure the existing kernel
|
||||
* To learn more about the kernel and kernel development
|
||||
|
||||
[[dependencies-for-building-kernels]]
|
||||
Dependencies for building kernels
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Not all of these will apply to all methods but this provides a good
|
||||
dependency list of items to install
|
||||
|
||||
`# sudo dnf install fedpkg fedora-packager rpmdevtools ncurses-devel pesign`
|
||||
|
||||
Give the following command from the top directory of the kernel source
|
||||
tree once you have checked it out
|
||||
|
||||
`# sudo dnf builddep kernel.spec`
|
||||
|
||||
if you plan to run 'make xconfig'
|
||||
|
||||
`# sudo dnf install qt3-devel libXi-devel gcc-c++`
|
||||
|
||||
Also make sure you add the user doing the build to /etc/pesign/users and
|
||||
run the authorize user script:
|
||||
|
||||
`# sudo /usr/libexec/pesign/pesign-authorize-users`
|
||||
|
||||
It should be noted that pesign pesign-rh-test-certs gets pulled in
|
||||
automatically for some, but not for everyone, it depends on how you
|
||||
installed pesign. It is best to make sure that you have it installed.
|
||||
|
||||
[[building-a-kernel-from-the-fedora-source-tree]]
|
||||
Building a Kernel from the Fedora source tree
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Make sure you have installed all dependencies
|
||||
|
||||
`$ fedpkg clone kernel`
|
||||
|
||||
you will likely need to checkout the source anonymously unless you have
|
||||
an Fedora developer account
|
||||
|
||||
`$ fedpkg clone -a kernel`
|
||||
|
||||
As of the time of this wiki writing, the kernel is managed using git.
|
||||
Each fedora release is a separate branch. rawhide tracks master. To get
|
||||
the tree for a particular release, you can use git checkout from the top
|
||||
of your newly created source tree.
|
||||
|
||||
e.g. for fedora 23,
|
||||
|
||||
`$ git checkout origin/f23`
|
||||
|
||||
You can now make whatever changes / customizations you need before
|
||||
generating the rpms and installing them. You may want to consider
|
||||
uncommenting
|
||||
|
||||
`# define buildid .local`
|
||||
|
||||
to avoid conflicts, e.g.
|
||||
|
||||
`%define buildid .local`
|
||||
|
||||
When finished, generate the appropriate rpms with
|
||||
|
||||
`$ fedpkg local`
|
||||
|
||||
The rpms will be generated in a subdirectory $ARCH which can then be
|
||||
installed:
|
||||
|
||||
`$ dnf install --nogpgcheck ./x86_64/kernel-$version.rpm`
|
||||
|
||||
[[building-a-non-debugging-kernel]]
|
||||
Building a non-debugging kernel
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Branched kernels are built with debugging enabled by default in the
|
||||
early stages of the release to assist developers. To make a kernel with
|
||||
debugging information disabled, you can follow the above instructions to
|
||||
check out and do:
|
||||
|
||||
`$ make release`
|
||||
|
||||
`$ fedpkg local`
|
||||
|
||||
[[enabling-config-options]]
|
||||
Enabling config options
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If there are configuration options that need to be adjusted for your
|
||||
build, you can add changes in the kernel-local file. These changes will
|
||||
get picked up when you build.
|
||||
|
||||
[[updating]]
|
||||
Updating
|
||||
^^^^^^^^
|
||||
|
||||
* `$ cd kernel`
|
||||
* `kernel $ git status`
|
||||
** your tree will be dirty in the configs and kernel.spec
|
||||
* `kernel $ git stash`
|
||||
** puts aside your changes so your tree will be clean
|
||||
* `kernel $ git pull origin`
|
||||
** update to the latest tree from fedpkg git
|
||||
|
||||
Now you can run whatever other commands you want (e.g. make release)
|
||||
|
||||
[[building-a-kernel-from-the-exploded-git-trees]]
|
||||
Building a kernel from the exploded git trees
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Fedora keeps a git tree containing Fedora patches applied on top of the
|
||||
vanilla sources.
|
||||
|
||||
`$ git clone `git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git[`git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git`]
|
||||
|
||||
`$ git checkout -b my_branch kernel-4.7.4-200.fc24`
|
||||
|
||||
You can now build the kernel following regular kernel instructions. This
|
||||
tree is useful for generating patches that can be applied to the
|
||||
kernel.spec.
|
||||
|
||||
[[building-a-kernel-from-the-source-rpm]]
|
||||
Building a Kernel from the source RPM
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Instructions for this are on a link:Building_a_custom_kernel/Source_RPM[
|
||||
separate page]. In general, you should use one of the other methods for
|
||||
building the kernel which are much easier.
|
||||
|
||||
[[building-only-kernel-modules-out-of-tree-modules]]
|
||||
Building Only Kernel Modules (Out Of Tree Modules)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This section is for users who are only interested in working on a kernel
|
||||
module, and who do not wish to build an entire custom kernel. It is not
|
||||
necessary to download and rebuild the entire kernel in order to build a
|
||||
module. To build a module for the currently running kernel, only the
|
||||
matching `kernel-devel` package is required. Run the following command
|
||||
to install the `kernel-devel` package using `dnf`.
|
||||
|
||||
....
|
||||
su -c 'dnf install kernel-devel'
|
||||
....
|
||||
|
||||
You can build against any kernel version, as long as you have `kernel`
|
||||
and `kernel-devel` packages installed for that version. The rest of this
|
||||
section assumes we're building for the running kernel; if not, replace
|
||||
`\`uname -r\`` with the desired version number.
|
||||
|
||||
As a simple example, to build the `foo.ko` module from `foo.c`, create
|
||||
the following `Makefile` in the directory containing the `foo.c` file:
|
||||
|
||||
....
|
||||
obj-m := foo.o
|
||||
|
||||
KDIR := /lib/modules/$(shell uname -r)/build
|
||||
PWD := $(shell pwd)
|
||||
|
||||
default:
|
||||
[TAB]$(MAKE) -C $(KDIR) M=$(PWD) modules
|
||||
....
|
||||
|
||||
[TAB] Denotes a tab character which must come first for makefile lines
|
||||
containing commands.
|
||||
|
||||
Then, issue the `make` command to build the `foo.ko` module.
|
||||
|
||||
The above is a helpful local Makefile wrapper invoking kbuild; in
|
||||
general you can simply do things like
|
||||
|
||||
....
|
||||
# make -C /lib/modules/`uname -r`/build M=`pwd` modules
|
||||
# make -C /lib/modules/`uname -r`/build M=`pwd` clean
|
||||
# make -C /lib/modules/`uname -r`/build M=`pwd` modules_install
|
||||
....
|
||||
|
||||
etc to build those targets.
|
||||
|
||||
[[building-vanilla-upstream-kernel]]
|
||||
Building Vanilla upstream kernel
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Sometimes a Fedora developer may ask you to try building and installing
|
||||
an upstream kernel (possibly with a patch added) for testing. If there
|
||||
are multiple iterations, it may be quicker for you to do this than for
|
||||
the developer to turn around several RPMs.
|
||||
|
||||
[[existing-fedora-vanilla-packages]]
|
||||
Existing Fedora Vanilla packages
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
There is an effort underway for packaging vanilla kernels.
|
||||
link:Kernel_Vanilla_Repositories[ See if this meets your needs first]
|
||||
|
||||
[[getting-the-sources]]
|
||||
Getting the sources
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Clone a kernel tree from kernel.org
|
||||
|
||||
`$ git clone `git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git[`git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git`]
|
||||
This will clone the entire upstream tree. This may take a while
|
||||
depending on your connection speed. (While the tree is syncing, why not
|
||||
take the time to update some steps on this wiki that are inevitably out
|
||||
of date?)
|
||||
|
||||
`$ cd linux`
|
||||
|
||||
Double check what baseline is being used and check out a new one if
|
||||
necessary:
|
||||
|
||||
`$ git checkout v4.5.2`
|
||||
|
||||
[[applying-patches]]
|
||||
Applying patches
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
[[the-patch-method]]
|
||||
The patch method
|
||||
++++++++++++++++
|
||||
|
||||
If you were asked to apply any patches by the developer, this is the
|
||||
stage at which we would do so. These would typically be applied using a
|
||||
command something like..
|
||||
|
||||
`$ cat ~/testpatch.diff | patch -p1`
|
||||
|
||||
If you have to try multiple different patches individually, you can
|
||||
unapply the previous one after testing by adding -R on the end of the
|
||||
above command.
|
||||
|
||||
[[the-git-method]]
|
||||
The git method
|
||||
++++++++++++++
|
||||
|
||||
Most developers these days generate patches using git and you can use
|
||||
git to help apply patches. You can do:
|
||||
|
||||
`$ git am -3 `
|
||||
|
||||
This will create a git commit of a single patch in your tree.
|
||||
|
||||
[[configuring-the-kernel]]
|
||||
Configuring the kernel
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Chances are that the kernel you are running is older than the one you
|
||||
are about to configure. This means there will be new options. There are
|
||||
several possibilities here.
|
||||
|
||||
* If the developer has pointed you at a specific config file to use,
|
||||
save it in the linux directory with the filename .config
|
||||
* You can take your existing .config file by using the command
|
||||
`cp /boot/config-\`uname -r\`* .config`
|
||||
|
||||
When you run the next step, you'll be asked (potentially lots of)
|
||||
questions about all the new options. Just hitting return 'should' always
|
||||
pick the safe decision for each option. However, it's worth taking care
|
||||
and reading each option, as this isn't always the case, and they may
|
||||
introduce new features your distro isn't capable of running, which may
|
||||
result in a non-booting system.
|
||||
|
||||
* FIXME how to grab a rawhide config
|
||||
|
||||
With the config in place, you are now ready to move on to the next step.
|
||||
|
||||
[[building-the-kernel]]
|
||||
Building the kernel
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
`$EDITOR Makefile` Change the EXTRAVERSION line to add something on the
|
||||
end. For example, if it reads "EXTRAVERSION = -rc5" change it to
|
||||
"EXTRAVERSION = -rc5-dave" (what you choose is only relevant for the
|
||||
final part of this procedure)
|
||||
|
||||
`$ make oldconfig`
|
||||
|
||||
`$ make bzImage`
|
||||
|
||||
`$ make modules`
|
||||
|
||||
(become root)
|
||||
|
||||
`# make modules_install`
|
||||
|
||||
`# make install`
|
||||
|
||||
You have now built and installed a kernel. It will show up in the grub
|
||||
menu next time you reboot.
|
||||
|
||||
[[rebuilding]]
|
||||
Rebuilding
|
||||
^^^^^^^^^^
|
||||
|
||||
If you have been asked to try several different things, the procedure
|
||||
once you have already built the tree once is mostly the same. A
|
||||
`make clean` is recommended between builds. This will leave the .config
|
||||
in place, so you can skip that step above and proceed straight to the
|
||||
`make bzImage` part of the steps above. Because we installed ccache in
|
||||
the first step, subsequent builds may go a lot faster as the compiler
|
||||
hits files that haven't changed since the last time it built them.
|
||||
|
||||
[[cleaning-up]]
|
||||
Cleaning up
|
||||
^^^^^^^^^^^
|
||||
|
||||
Once you have tested the kernel, and you've booted back to one of your
|
||||
kernels installed from an RPM, you can clean up the files that the above
|
||||
procedure installed by becoming root, and calling these commands. (Be
|
||||
sure to get the kernel version correct!) Remember above, we changed
|
||||
EXTRAVERSION to add a 'tag' to the kernel ? All the files it installed
|
||||
will have this as part of the filename. So you should be able to use
|
||||
wildcards to delete them safely using commands similar to those below.
|
||||
(Just replace 'dave' with whatever tag you chose)
|
||||
|
||||
....
|
||||
rm -f /boot/config-2.6.*dave* /boot/initrd-2.6.*dave* /boot/vmlinuz-*dave* /boot/System.map-*dave*
|
||||
rm -rf /lib/modules/2.6*dave*
|
||||
....
|
||||
|
||||
Finally, you will need to remove the kernel as an option to your
|
||||
bootloader. This will change from architecture to architecture. For x86,
|
||||
(as root), edit /boot/grub2/grub.cfg or /boot/efi/EFI/fedora/grub.cfg if
|
||||
you have EFI enabled and delete the four lines relating to your kernel
|
||||
(They should be easy to spot, they'll be the ones with your tag).
|
||||
They'll look something like this..
|
||||
|
||||
....
|
||||
title Fedora Core (2.6.22-rc3-dave)
|
||||
root (hd0,0)
|
||||
kernel /vmlinuz-2.6.22-rc3-dave ro root=/dev/md0
|
||||
initrd /initrd-2.6.22-rc3-dave.img
|
||||
....
|
||||
|
||||
Category:Documentation Category:Tutorials
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
553
en-US/bumblebee.adoc
Normal file
553
en-US/bumblebee.adoc
Normal file
|
|
@ -0,0 +1,553 @@
|
|||
= Bumblebee
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/Bumblebee
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
[[description]]
|
||||
Description
|
||||
~~~~~~~~~~~
|
||||
|
||||
Nvidia Optimus is an optimization technology created by Nvidia which,
|
||||
depending on the resource load generated by client software
|
||||
applications, will transparently and seamlessly switch between two
|
||||
graphics adapters within a computer system in order to provide either
|
||||
maximum performance or minimum power draw from the system's graphics
|
||||
rendering hardware. From
|
||||
https://github.com/Bumblebee-Project/Bumblebee/wiki/FAQ[Bumblebee's
|
||||
FAQ]: Bumblebee is a effort to make Nvidia Optimus enabled laptops work
|
||||
in GNU/Linux systems. Such feature involves two graphics cards with two
|
||||
different power consumption profiles plugged in a layered way sharing a
|
||||
single framebuffer.
|
||||
|
||||
The discrete GPU (NVidia) is turned off when not in use and activated
|
||||
and turned on though ACPI calls when demanding OpenGL applications
|
||||
require the extra power the discrete GPU can give. Demanding OpenGL
|
||||
applications might include such things as 3D games or 3D rendering
|
||||
software but would not include such things as a web browser or a video
|
||||
playback program like mplayer or VLC.
|
||||
|
||||
[[how-can-you-tell-if-you-have-an-optimus-notebook-computer]]
|
||||
How can you tell if you have an optimus notebook computer?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If you purchased a notebook with an NVidia sticker on it, you _might_
|
||||
have a optimus computer. If you don’t have an optimus technology
|
||||
computer nothing in this documentation is relevant to your PC. (Optimus
|
||||
was slated at one point to go in desktop PCs but the industry ended up
|
||||
rejecting that concept…)
|
||||
|
||||
To tell, after you have installed the OS, open a terminal window and
|
||||
type:
|
||||
|
||||
....
|
||||
$ lspci | grep 'VGA\|3D'
|
||||
....
|
||||
|
||||
If you see two video cards in the output like:
|
||||
|
||||
....
|
||||
$ lspci | grep 'VGA\|3D'
|
||||
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06)
|
||||
02:00.0 3D controller: NVIDIA Corporation GM108M [GeForce 940MX] (rev a2)
|
||||
....
|
||||
|
||||
And one is a Intel “Integrated Graphics Controller” and the other is a
|
||||
“NVIDIA Corporation” chip, then you probably have an optimus notebook.
|
||||
|
||||
To further verify, if you have the two VGA devices with one as Intel
|
||||
Integrated and other as NVIDIA, as root look for the
|
||||
/sys/kernel/debug/vgaswitcheroo/switch file. If it exists, then you have
|
||||
an optimus PC. If its missing, then you might not. (It might be that you
|
||||
have a card that nouveau can’t use yet because it is too new…)
|
||||
|
||||
[[before-you-get-started]]
|
||||
Before you get started
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Most users will want to turn off “Secure boot” in the bios or UEFI
|
||||
screen when you need nvidia drivers or bbswitch-dkms. If you want to
|
||||
make your own public / private keys for kernel module signing you can
|
||||
look
|
||||
https://docs.fedoraproject.org/en-US/Fedora/22/html/System_Administrators_Guide/sect-signing-kernel-module-with-the-private-key.html[here]
|
||||
or
|
||||
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect-signing-kernel-modules-for-secure-boot.html[here]
|
||||
for more information on the subject. If you end up doing that and use
|
||||
the closed source NVidia driver, you will need to edit the
|
||||
/etc/bumblebee/bumblebee-nvidia-sign.conf file.
|
||||
|
||||
Next, do a dnf update before you begin. And just to be safe, reboot your
|
||||
PC so that you are booted into the newest kernel. The reason for this is
|
||||
that you want the kernel-devel package to match the kernel you are
|
||||
running under. If you don’t reboot after a dnf update these versions may
|
||||
differ which will cause compiling problems.
|
||||
|
||||
[[installation]]
|
||||
Installation
|
||||
~~~~~~~~~~~~
|
||||
|
||||
[[for-free-or-open-source-solution]]
|
||||
For free or open source solution
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Some users http://www.kroah.com/log/linux/stable_api_nonsense.html[feel
|
||||
strongly] that they should not use closed source kernel modules. This is
|
||||
understandable. In all cases,
|
||||
http://nouveau.freedesktop.org/wiki/Optimus/[PRIME] will work better
|
||||
then using bumblebee.
|
||||
|
||||
In fact, you can no longer use the bumblebee software with nouveau any
|
||||
longer even if you want to. See
|
||||
https://github.com/Bumblebee-Project/Bumblebee/issues/773[issue 773] for
|
||||
further information about this subject. You *MUST USE PRIME*. The
|
||||
nouveau driver already handles power saving nowadays so bumblebee would
|
||||
just be superfluous…
|
||||
|
||||
[[for-closed-source-solution]]
|
||||
For closed source solution
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Do not use the NVidia video drivers from *http://rpmfusion.org/*,
|
||||
*http://negativo17.org/*. I’m sure they are fine drivers and I am not
|
||||
trying to criticize them at all. But they *DO NOT support or work* with
|
||||
bumblebee without modifications. I have created a pair of drivers
|
||||
packages you may use that require no modifications to work. There is a
|
||||
managed version which contains a reasonably recent “long lived branch”
|
||||
driver blob. There is also a unmanaged repo which contains an empty
|
||||
drivers package. The unmanaged version requires you to download a “blob”
|
||||
from http://www.nvidia.com/object/unix.html[here] and then copy the file
|
||||
manually to the /etc/sysconfig/nvidia/ directory as root. You might need
|
||||
the “unmanaged” version if your laptop requires a “legacy” driver
|
||||
version or if you need the “short lived branch” driver for some reason.
|
||||
Do not install both the managed and unmanaged repos. You should pick one
|
||||
or the other depending on your needs. If you are unsure which to use,
|
||||
use the managed repo.
|
||||
|
||||
*Special note concerning versions 355.11-375.10:*
|
||||
|
||||
There is a bug which prevents certain versions from working with the
|
||||
unmanaged version of the bumblebee-nvidia shell script wrapper. I have
|
||||
opened a discussion thread
|
||||
https://devtalk.nvidia.com/default/topic/885657/linux/can-t-install-driver-to-work-with-bumblebee-with-version-355-11/[here]
|
||||
concerning this problem. See also
|
||||
https://github.com/NVIDIA/nvidia-installer/issues/1[this issue] on
|
||||
github.com. If you use a version older then 355.11 or newer then 375.10
|
||||
you should be ok. If you need one in between those you’ll have to patch
|
||||
and compile the nvidia-installer program yourself to get it to work.
|
||||
You’d need to disable the symlink check and the runtime check within the
|
||||
c code which is what we did for a while there with the “managed”
|
||||
version.
|
||||
|
||||
[[for-closed-source-solution-fedora]]
|
||||
For closed source solution fedora
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Add bumblebee repo:
|
||||
|
||||
....
|
||||
# dnf -y --nogpgcheck install http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora$(rpm -E %fedora)/noarch/bumblebee-release-1.2-1.noarch.rpm
|
||||
....
|
||||
|
||||
Managed NVidia repo:
|
||||
|
||||
....
|
||||
# dnf -y --nogpgcheck install http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee-nonfree/fedora$(rpm -E %fedora)/noarch/bumblebee-nonfree-release-1.2-1.noarch.rpm
|
||||
....
|
||||
|
||||
or Unmanaged NVidia repo:
|
||||
|
||||
....
|
||||
# dnf -y --nogpgcheck install http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee-nonfree-unmanaged/fedora$(rpm -E %fedora)/noarch/bumblebee-nonfree-unmanaged-release-1.2-1.noarch.rpm
|
||||
....
|
||||
|
||||
'''Remember, you do not want to install both the managed and unmanaged
|
||||
repos. Pick one or the other but not both! '''
|
||||
|
||||
No multilib fedora 23+:
|
||||
|
||||
....
|
||||
# dnf install bumblebee-nvidia bbswitch-dkms primus kernel-devel
|
||||
....
|
||||
|
||||
Multilib on a 64 bit install fedora 23+: (You may need to add additional
|
||||
32 bit packages to get your 32 bit applications to work with
|
||||
bumblebee/primus)
|
||||
|
||||
....
|
||||
# dnf install bumblebee-nvidia bbswitch-dkms VirtualGL.x86_64 VirtualGL.i686 primus.x86_64 primus.i686 kernel-devel
|
||||
....
|
||||
|
||||
You will need to reboot before you can test if its working. *If you used
|
||||
the “unmanaged” repo don’t forget to copy the NVidia “blob” to
|
||||
/etc/sysconfig/nvidia/ before you reboot!* Most folks will want the
|
||||
“managed” version rather then the “unmanaged” version.
|
||||
|
||||
[[using-bumblebee-software]]
|
||||
Using bumblebee software
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
*General usage*
|
||||
|
||||
....
|
||||
$ optirun [options] application [application-parameters]
|
||||
....
|
||||
|
||||
For example, start a Windows applications with optimus named
|
||||
application.exe:
|
||||
|
||||
....
|
||||
$ optirun wine application.exe
|
||||
....
|
||||
|
||||
For another example, open NVidia settings panel with optimus:
|
||||
|
||||
....
|
||||
$ optirun -b none nvidia-settings -c :8
|
||||
....
|
||||
|
||||
For another example, open the java based Minecraft with primus bridge:
|
||||
|
||||
....
|
||||
$ optirun -b primus java -jar /PATH/TO/Minecraft.jar
|
||||
....
|
||||
|
||||
For a list of the options for optirun, view its manual page:
|
||||
|
||||
....
|
||||
$ man optirun
|
||||
....
|
||||
|
||||
In general, using the primus bridge gives better performance then using
|
||||
the default VirtualGL bridge. In bumblebee 4.0 (coming soon) primus will
|
||||
become the default bridge and VirtuaGL will need to be called explicitly
|
||||
if you still want it. Also beginning with bumblebee 4.0 (coming soon)
|
||||
the VirtuaGL dependency will be replaced with a primus dependency
|
||||
instead. So you might not even have VirtuaGL installed by default in the
|
||||
future.
|
||||
|
||||
For primus, there is a separate shell script you can use to invoke it
|
||||
called “primusrun.”
|
||||
|
||||
For a list of the options for primusrun, view its manual page:
|
||||
|
||||
....
|
||||
$ man primusrun
|
||||
....
|
||||
|
||||
....
|
||||
$ primusrun java -jar /PATH/TO/Minecraft.jar
|
||||
....
|
||||
|
||||
and
|
||||
|
||||
....
|
||||
$ optirun -b primus java -jar /PATH/TO/Minecraft.jar
|
||||
....
|
||||
|
||||
are functionally equivalent commands.
|
||||
|
||||
It may become tedious to always use the optirun program in a terminal to
|
||||
launch 3D games or other 3D opengl applications. You may wish to create
|
||||
desktop launchers which use the optirun or primusrun commands in order
|
||||
to streamline this process.
|
||||
|
||||
For example, in MATE desktop environment, when you right click on an
|
||||
empty space in the desktop a popup menu is displayed. One option on this
|
||||
menu is “Create launcher..” which allows you to create a graphical
|
||||
launcher icon for your apps which can be left on the desktop or moved
|
||||
into some folder. Other desktop environments also offer this
|
||||
functionality though the methods differ from desktop to desktop.
|
||||
|
||||
[[multi-monitor-setup-with-closed-driver]]
|
||||
Multi monitor setup with closed driver
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Optimus laptops have two video chips: an integrated Intel and a discrete
|
||||
NVidia one. If the port (DisplayPort / HDMI / VGA) is wired to the Intel
|
||||
chip, you do not need to do anything special to get external monitors to
|
||||
work.
|
||||
|
||||
When the external port is wired into the NVidia chip, you cannot
|
||||
currently expand the screen over monitors without extra effort. Read on
|
||||
if you fall into this category…
|
||||
|
||||
Install the intel-gpu-tools package.
|
||||
|
||||
....
|
||||
# dnf install intel-gpu-tools
|
||||
....
|
||||
|
||||
Running ‘intel-virtual-output’ (from the intel-gpu-tools rpm) without
|
||||
any extra parameters will daemonize itself and detect attached displays
|
||||
in the background. It will then perform all the trickery of virtualizing
|
||||
and cloning so that the newly attached screen can be used via
|
||||
conventional screen management methods, such as cloning/extending with
|
||||
xrandr.
|
||||
|
||||
For example, if your laptop’s display is called eDP1, and your using a
|
||||
external adapter called HDMI1, and you wanted the display to be
|
||||
1920×1080 resolution, you could run the following commands:
|
||||
|
||||
To have your HDMI screen to the right of your desktop, run:
|
||||
|
||||
....
|
||||
$ xrandr –output eDP1 –mode 1920×1080 –output HDMI1 –mode 1920×1080 –right-of eDP1
|
||||
....
|
||||
|
||||
To clone your desktop, run:
|
||||
|
||||
....
|
||||
$ xrandr –output eDP1 –mode 1920×1080 –output HDMI1 –mode 1920×1080 –same-as eDP1
|
||||
....
|
||||
|
||||
There are many different possibilities. Type xrandr with no arguments to
|
||||
see what displays you have attached. See
|
||||
https://github.com/Bumblebee-Project/Bumblebee/wiki/Multi-monitor-setup[this
|
||||
web page] for further information on this subject. Read the manual page
|
||||
for xrandr for even more information on the possibilities this command
|
||||
provides.
|
||||
|
||||
If intel-virtual-output works ok running by hand you could add it to
|
||||
your startup automatically if you desire. One way would be to create a
|
||||
/etc/rc.d/rc.local script and add it into there. Another way might be to
|
||||
create a systemd unit file as Type=oneshot. A third way might be to run
|
||||
it at login using whatever mechanism your desktop environment supports
|
||||
for doing such things. For example, in MATE desktop environment, there
|
||||
is a mate-session-properties program (System -> Preferences -> Personal
|
||||
-> Startup Applications) that you can run programs from when you login.
|
||||
Most desktop environments offer similar functionality though the methods
|
||||
differ from desktop to desktop.
|
||||
|
||||
[[troubleshooting]]
|
||||
Troubleshooting
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
When you are using the closed source NVidia drivers, there is a checking
|
||||
system you can run. To test, type this command:
|
||||
|
||||
....
|
||||
$ bumblebee-nvidia --check
|
||||
....
|
||||
|
||||
This will tell you if the NVidia driver and bbswitch-dkms compiled into
|
||||
the current kernel ok. It works with both the managed and unmanaged
|
||||
driver packages.
|
||||
|
||||
Some other errors you may encounter form the output from
|
||||
bumblebee-nvidia –check
|
||||
|
||||
....
|
||||
Error: Too many NVidia blobs in /etc/sysconfig/nvidia/
|
||||
Blob count = 2.
|
||||
....
|
||||
|
||||
This means that there are too many NVidia “blobs” in
|
||||
/etc/sysconfig/nvidia/ and the solution is to delete one of them.
|
||||
|
||||
....
|
||||
Error: No Nvidia blob in /etc/sysconfig/nvidia/
|
||||
....
|
||||
|
||||
This means there is no blob in /etc/sysconfig/nvidia/ and you should
|
||||
copy one there if using the unmanaged repo or re-install
|
||||
bumblebee-nvidia if using the managed repo. (dnf reinstall
|
||||
bumblebee-nvidia)
|
||||
|
||||
If the module did not compile, you can run:
|
||||
|
||||
....
|
||||
# bumblebee-nvidia --debug
|
||||
....
|
||||
|
||||
as root or via sudo. This may give you clues as to why the nvidia
|
||||
installer was unable to work.
|
||||
|
||||
Type
|
||||
|
||||
....
|
||||
$ bumblebee-nvidia --help
|
||||
....
|
||||
|
||||
to see a full list of options the wrapper script provides.
|
||||
|
||||
If you see this error:
|
||||
|
||||
....
|
||||
[ERROR]You've no permission to communicate with the Bumblebee daemon. Try adding yourself to the 'bumblebee' group
|
||||
[ERROR]Could not connect to bumblebee daemon - is it running?
|
||||
....
|
||||
|
||||
It could be caused by adding another user account to your notebook after
|
||||
you have already installed the various bumblebee packages. The solution
|
||||
is to run:
|
||||
|
||||
....
|
||||
# usermod -a -G bumblebee USERNAME
|
||||
....
|
||||
|
||||
where *USERNAME* is your account name to add to the bumblebee group. You
|
||||
MUST be in the bumblebee group for primusrun or optirun to work.
|
||||
|
||||
*Primusrun mouse delay/disable VSYNC*
|
||||
|
||||
For primusrun, VSYNC is enabled by default and as a result, it could
|
||||
make mouse input delay lag or even slightly decrease performance. Test
|
||||
primusrun without VSYNC:
|
||||
|
||||
....
|
||||
$ vblank_mode=0 primusrun glxgears
|
||||
....
|
||||
|
||||
*Primus issues under compositing window managers*
|
||||
|
||||
Since compositing hurts performance, invoking primus when a compositing
|
||||
WM is active is
|
||||
https://github.com/amonakov/primus#issues-under-compositing-wms[not
|
||||
recommended]. If you need to use primus with compositing and see
|
||||
flickering or bad performance, synchronizing primus’ display thread with
|
||||
the application’s rendering thread may help:
|
||||
|
||||
....
|
||||
$ PRIMUS_SYNC=1 primusrun ...
|
||||
....
|
||||
|
||||
*optirun crashes after you boot into “Troubleshooting -> Start Fedora
|
||||
Live in basic graphics mode” and do an install that way.*
|
||||
|
||||
If you did an install under “Troubleshooting -> Start Fedora Live in
|
||||
basic graphics mode.” bumblebee will not work. You can tell by examining
|
||||
the /var/log/Xorg.8.log log file and looking for Kernel command line:
|
||||
and seeing nomodeset on that line. When you use “Start Fedora Live in
|
||||
basic graphics mode.” it adds “nomodeset” to your kernel command line
|
||||
which will cause your machine to use the VESA driver and make bumblebee
|
||||
not work. (It will just crash when you try) To fix that, edit
|
||||
/etc/default/grub and on the GRUB_CMDLINE_LINUX= line, remove the word
|
||||
nomodeset and then save the file, next, either run
|
||||
|
||||
....
|
||||
# grub2-mkconfig -o /boot/grub2/grub.cfg
|
||||
....
|
||||
|
||||
on a BIOS based notebook or
|
||||
|
||||
....
|
||||
# grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
|
||||
....
|
||||
|
||||
on a UEFI based notebook. Then reboot. After that
|
||||
bumblebee/optirun/primusrun should start working.
|
||||
|
||||
[[compatibility-with-recent-laptops-that-have-american-megatrend-bioses]]
|
||||
Compatibility with recent laptops that have American Megatrend BIOSes
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Some recent laptop models featuring AMI bioses have some compatibility
|
||||
issues with bbswitch and Optimus, making them unable to load into
|
||||
graphics mode and crashing every time it is attempted, as discussed in
|
||||
further details in this post on the Bumblebee's github:
|
||||
https://github.com/Bumblebee-Project/Bumblebee/issues/764#issuecomment-234494238
|
||||
.
|
||||
|
||||
If you are trying to use Linux on a recent Optimus laptop and it crashes
|
||||
every time you try to enter a graphics environment, please try adding
|
||||
the following parameters to your boot loader (Fedora users usually have
|
||||
GRUB installed):
|
||||
|
||||
....
|
||||
acpi_osi=! acpi_osi='Windows 2009'
|
||||
....
|
||||
|
||||
This seems to work on most laptop models facing this issue, but bear in
|
||||
mind that this workaround has not been tested in every laptop model ever
|
||||
made – so your mileage may vary. If the problems persist, you could try
|
||||
updating your BIOS or look for more info in the Bumblebee documentation
|
||||
and their community.
|
||||
|
||||
[[broken-power-management-with-kernel-4.8]]
|
||||
Broken power management with kernel 4.8
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If you have a newer laptop (BIOS date 2015 or newer), then Linux 4.8
|
||||
might break bbswitch since bbswitch does not support the newer,
|
||||
recommended power management method. As a result, the dGPU may fail to
|
||||
power on, fail to power off or worse.
|
||||
|
||||
See https://github.com/Bumblebee-Project/bbswitch/issues/140[Issue 140]
|
||||
for further information about this problem.
|
||||
|
||||
As a workaround, add pcie_port_pm=off to your kernel parameters.
|
||||
|
||||
Alternatively, if you are only interested in power saving (and perhaps
|
||||
use of external monitors), remove bumblebee / bbswitch and rely on
|
||||
Nouveau runtime power-management (which supports the new method).
|
||||
|
||||
[[mesa-13.0.3-6-and-libglvnd-issues]]
|
||||
mesa-13.0.3-6 and libglvnd issues
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
In fedora 25 and 26 a new library called libglvnd was added which
|
||||
initially caused some issues.
|
||||
|
||||
primus-1.1.03282015-4 and newer, bumblebee-3.2.1-13 and newer, and
|
||||
(managed version) bumblebee-nvidia-375.26-2 and newer, and (un-managed
|
||||
version) bumblebee-nvidia-3.0-2 and newer will work with the newer mesa
|
||||
and new libglvnd library.
|
||||
|
||||
When you first upgrade to mesa-13.0.3-6 or newer bumblebee-nvidia
|
||||
doesn't know that it needs to rebuild the shim. So you can force that by
|
||||
running the command:
|
||||
|
||||
....
|
||||
bumblebee-nvidia --force
|
||||
....
|
||||
|
||||
via su as root or via sudo. And the primus bridge should work after
|
||||
that. You can track this issue upstream
|
||||
https://github.com/amonakov/primus/issues/193[here].
|
||||
|
||||
[[useful-links]]
|
||||
Useful links
|
||||
~~~~~~~~~~~~
|
||||
|
||||
* http://bumblebee-project.org/
|
||||
* https://github.com/Bumblebee-Project/Bumblebee/wiki
|
||||
* https://github.com/Bumblebee-Project/Bumblebee/
|
||||
* https://github.com/Bumblebee-Project/bbswitch
|
||||
* https://github.com/amonakov/primus
|
||||
* https://www.linux.ncsu.edu/bumblebee/
|
||||
|
||||
http://www.thelinuxrain.com/articles/the-state-of-nvidia-optimus-on-linux[The
|
||||
State of NVIDIA Optimus on Linux]
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
90
en-US/chromium.adoc
Normal file
90
en-US/chromium.adoc
Normal file
|
|
@ -0,0 +1,90 @@
|
|||
= Chromium
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/Chromium
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
[[chromium-web-browser]]
|
||||
Chromium web browser
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Chromium is the upstream project that Google Chrome browser is based on.
|
||||
|
||||
As of August 2016, Chromium is now included in the Fedora Repositories.
|
||||
If you were using the old Chromium
|
||||
http://copr.fedoraproject.org/coprs/spot/chromium/[Copr] repository, you
|
||||
should simply get the newer chromium as an upgrade via dnf.
|
||||
|
||||
[[notes-on-fedora-chromium]]
|
||||
Notes on Fedora Chromium
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
* Fedora's Chromium package is built to support the widevine plugin (but
|
||||
does not include it). To enable this, copy libwidevinecdm.so and
|
||||
libwidevinecdmadapter.so from the Google Chrome package into
|
||||
/usr/lib64/chromium-plugins (and restart chromium). You should see
|
||||
"Widevine Content Decryption Module" in chrome://flags.
|
||||
|
||||
* Fedora's Chromium package does not include support for h264, mp3, or
|
||||
aac, because of legal concerns.
|
||||
|
||||
* To use the PPAPI "PepperFlash" flash plugin, download it here:
|
||||
|
||||
https://get.adobe.com/flashplayer/otherversions/
|
||||
|
||||
Choose Linux 64-bit, FP 22.0 (or later) for other Linux 64-bit, PPAPI.
|
||||
|
||||
You will then have flash_player_ppapi_linux.x86_64.tar.gz. Unpack it
|
||||
into /usr/lib64/chromium-browser/PepperFlash/. Then, restart chromium.
|
||||
You should see Adobe Flash Player in chrome://plugins.
|
||||
|
||||
* To enable speech synthesis support, pass the
|
||||
"--enable-speech-dispatcher" flag to chromium-browser.
|
||||
|
||||
[[google-chrome]]
|
||||
Google Chrome
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
Since Chromium is upstream for Google Chrome, all the same issues apply.
|
||||
In addition to that, Fedora does not include Google Chrome because it is
|
||||
a proprietary product and bundles other proprietary software such as
|
||||
Adobe Flash plugin. However, Google does maintain a dnf|yum repository
|
||||
for Fedora at
|
||||
|
||||
https://www.google.com/chrome/
|
||||
|
||||
The link above also includes downloadable RPMs that you may use to
|
||||
install Chrome.
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
75
en-US/configure-sudo.adoc
Normal file
75
en-US/configure-sudo.adoc
Normal file
|
|
@ -0,0 +1,75 @@
|
|||
= Configuring Sudo
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/Configuring_Sudo
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
Fedora users should use a regular user account for regular day to day
|
||||
activities and a root account only for system administration. Use the
|
||||
personal account you created following the installation process, at
|
||||
first boot, for daily use. Use the root account only for administration
|
||||
of your system.
|
||||
|
||||
To run as root use the or commands. Avoid using root for any
|
||||
non-administration usage, since the root account makes it easy to create
|
||||
security or data risks. If you frequently use a single user desktop, you
|
||||
may find it convenient to configure so you can use the same password to
|
||||
access root as you use for your regular account. To do this, select to
|
||||
be added to the Administration group during installation. To do it
|
||||
later, or to add a different user, follow this procedure:
|
||||
|
||||
1. Become the root user using the command. Enter the password for the
|
||||
root account when prompted.
|
||||
+
|
||||
....
|
||||
su -
|
||||
....
|
||||
2. Run this command, using your user account name in the place of
|
||||
"sampleusername":
|
||||
+
|
||||
....
|
||||
usermod sampleusername -a -G wheel
|
||||
....
|
||||
+
|
||||
You must now log off and back on in order to have access to the wheel
|
||||
group. Note that when prompts you for a password, it expects your user
|
||||
password, not root's.
|
||||
|
||||
[[reference]]
|
||||
Reference
|
||||
~~~~~~~~~
|
||||
|
||||
http://fedorasolved.org/post-install-solutions/sudo
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
1951
en-US/create-an-rpm.adoc
Normal file
1951
en-US/create-an-rpm.adoc
Normal file
File diff suppressed because it is too large
Load diff
215
en-US/create-and-use-livecd.adoc
Normal file
215
en-US/create-and-use-livecd.adoc
Normal file
|
|
@ -0,0 +1,215 @@
|
|||
= How to create and use a Live CD
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/How_to_create_and_use_a_Live_CD
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
This page explains how to make a custom-content Live CD or DVD on
|
||||
Fedora-based systems including derived distributions such as RHEL,
|
||||
CentOS and others.
|
||||
|
||||
[[getting-started]]
|
||||
Getting started
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
To create a live image, the *livecd-creator* tool is used. Super user
|
||||
privileges are needed. The tool is more or less self-documenting, use to
|
||||
see options.
|
||||
|
||||
The *livecd-creator* tool is part of the `livecd-tools` package. If it
|
||||
is not installed on your system, add it with link:dnf[DNF] or
|
||||
link:yum[YUM]:
|
||||
|
||||
....
|
||||
su -c 'yum install livecd-tools spin-kickstarts' #Versions prior to Fedora 22
|
||||
or
|
||||
su -c 'dnf install livecd-tools spin-kickstarts' #Fedora 22 and beyond
|
||||
....
|
||||
|
||||
If you are interested in localized (i.e. translated into other
|
||||
languages) live CD files, install also *l10n-kickstarts*.
|
||||
|
||||
[[configuring-the-image]]
|
||||
Configuring the image
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The configuration of the live image is defined by a file called
|
||||
_kickstart_. It can include some basic system configuration items, the
|
||||
package manifest and a script to be run at the end of the build process.
|
||||
|
||||
For the Fedora project, the most important live image configurations
|
||||
files are:
|
||||
|
||||
* *https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-live-base.ks[fedora-live-base.ks]*
|
||||
: The base live image system (included in the 'livecd-tools' package).
|
||||
* For _Fedora 20 and earlier_:
|
||||
*https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-livecd-desktop.ks[fedora-livecd-desktop.ks]*
|
||||
: Complete desktop with applications and input/output support for all
|
||||
supported locales in Fedora (this one is part of the 'spin-kickstarts'
|
||||
package) - despite the name, this is the kickstart that generates the
|
||||
~1GB-sized images for recent releases.
|
||||
* For _Fedora 21 and later_:
|
||||
*https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-live-workstation.ks[fedora-live-workstation.ks]*
|
||||
- this is the Workstation product configuration.
|
||||
|
||||
_kickstart_ files for other spins (e.g. Fedora Electronics Lab) can be
|
||||
found in after installing the 'spin-kickstarts' package. These pre-made
|
||||
configuration files can be a great place to start, as they already have
|
||||
some useful pre and post-installation scripts.
|
||||
image:system-config-kickstart.png[system-config-kickstart,title="fig:system-config-kickstart"]
|
||||
You can create a customized _kickstart_ file by running . Note that you
|
||||
might have to install the package first with in Fedora 22 and beyond or
|
||||
in earlier versions of Fedora. This tool is mainly intended for
|
||||
generating kickstart files for automated installs, not live images, so
|
||||
the output will probably not be usable without editing, but it may help
|
||||
you to generate particular kickstart directives. Remember to add the
|
||||
line:
|
||||
|
||||
....
|
||||
%include /usr/share/spin-kickstarts/fedora-live-base.ks
|
||||
....
|
||||
|
||||
at the beginning of your _kickstart_ file to include the base live
|
||||
configuration.
|
||||
|
||||
[[making-the-image]]
|
||||
Making the image
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
To make the image, simply issue the following command:
|
||||
|
||||
....
|
||||
livecd-creator --verbose \
|
||||
--config=/path/to/kickstart/file.ks \
|
||||
--fslabel=Image-Label \
|
||||
--cache =/var/cache/live
|
||||
....
|
||||
|
||||
The name given by _--fs-label_ is used:
|
||||
|
||||
* as a file system label on the ext3 and iso9660 file systems (As such,
|
||||
it's visible on the desktop as the CD name).
|
||||
* in the _isolinux_ boot loader.
|
||||
|
||||
If you have the repositories available locally and don't want to wait
|
||||
for the download of packages, just substitute the URLs listed in the
|
||||
configuration file to point to your local repositories.
|
||||
|
||||
[[examples]]
|
||||
Examples
|
||||
~~~~~~~~
|
||||
|
||||
[[spinning-the-fedora-desktop]]
|
||||
Spinning the fedora desktop
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The following command:
|
||||
|
||||
....
|
||||
livecd-creator --verbose \
|
||||
--config=/usr/share/spin-kickstarts/fedora-live-workstation.ks \
|
||||
--fslabel=Fedora-LiveCD \
|
||||
--cache=/var/cache/live
|
||||
....
|
||||
|
||||
will create a live CD called "Fedora-LiveCD" using the
|
||||
*fedora-live-workstation.ks* configuration file.
|
||||
|
||||
[[a-barebones-live-cd]]
|
||||
A Barebones Live CD
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The command
|
||||
|
||||
....
|
||||
livecd-creator --verbose \
|
||||
--config=/usr/share/doc/livecd-tools-`rpm -q livecd-tools --qf "%{VERSION}"`/livecd-fedora-minimal.ks \
|
||||
--cache=/var/cache/live
|
||||
....
|
||||
|
||||
will create a live CD that will boot to a login prompt.
|
||||
|
||||
[[testing-your-live-cd-using-kvm-or-qemu]]
|
||||
Testing your Live CD using KVM or qemu
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
image:Screenshot_qemu_gtk3.png[QEMU running Fedora
|
||||
17,title="QEMU running Fedora 17"]
|
||||
|
||||
As root:
|
||||
|
||||
`qemu-kvm -m 2048 -vga qxl -cdrom filename.iso`
|
||||
|
||||
If you do not have Wikipedia:Kernel-based_Virtual_Machine[ KVM] support,
|
||||
you have to use qemu instead
|
||||
|
||||
`qemu-system-x86_64 -m 2048 -vga qxl -cdrom filename.iso`
|
||||
|
||||
Replace *filename.iso* with the name of your created Live CD image and
|
||||
*qemu-system-x86_64* with an appropriate qemu binary for the target
|
||||
system, e.g *qemu-system-i386*.
|
||||
|
||||
[[using-your-new-live-image]]
|
||||
Using your new live image
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
You can http://docs.fedoraproject.org/readme-burning-isos/[burn your
|
||||
image directly to a CD or a DVD] if it fits, or you can
|
||||
link:How_to_create_and_use_Live_USB[ write it to a USB stick].
|
||||
|
||||
[[live-image-media-verification]]
|
||||
Live Image Media Verification
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The live image can incorporate functionality to verify itself. To do so,
|
||||
you need to have *isomd5sum* installed both on the system used for
|
||||
creating the image and installed into the image. This is so that the
|
||||
*implantisomd5* and *checkisomd5* utilities can be used. These utilities
|
||||
take advantage of embedding an md5sum into the application area of the
|
||||
iso9660 image. This then gets verified before mounting the real root
|
||||
filesystem.
|
||||
|
||||
[[other-resources]]
|
||||
Other Resources
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
* A link:Classroom[ Fedora Classroom] class covering
|
||||
link:Classroom/Creating_Fedora_Remix[ creating Fedora remixes].
|
||||
* If you are distributing your spin you need to be concerned about
|
||||
link:JeroenVanMeeuwen/Revisor/FedoraRebrandRemixGuidelines[ trademark
|
||||
usage and GPL responsibilities].
|
||||
|
||||
Category:Spins Category:LiveMedia
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
427
en-US/create-gpg-keys.adoc
Normal file
427
en-US/create-gpg-keys.adoc
Normal file
|
|
@ -0,0 +1,427 @@
|
|||
= Creating GPG Keys
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/Creating_GPG_Keys
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
This page explains in detail how to obtain a GPG key using common Fedora
|
||||
utilities. It also provides information on managing your key as a Fedora
|
||||
contributor.
|
||||
|
||||
[[creating-gpg-keys]]
|
||||
Creating GPG Keys
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
[[creating-gpg-keys-using-the-gnome-desktop]]
|
||||
Creating GPG Keys Using the GNOME Desktop
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Install the *Seahorse* utility, which makes GPG key management easier.
|
||||
From the main menu, select _Applications > Add/Remove Software_. Select
|
||||
the _Search_ tab and enter the name _seahorse_. Select the checkbox next
|
||||
to the _seahorse_ package and select _Apply_ to add the software. You
|
||||
can also install *Seahorse* using the command line with the command
|
||||
`su -c "yum install seahorse"`.
|
||||
|
||||
To create a key, go the the Activities overview and select _Passwords
|
||||
and Encryption Keys_, which starts the application *Seahorse*.
|
||||
|
||||
From the _File_ menu select _New..._ then _PGP Key_ then click
|
||||
_Continue_. Type your full name, email address, and an optional comment
|
||||
describing who you are (e.g.: John C. Smith, jsmith@example.com, The
|
||||
Man). Click _Create_. A dialog is displayed asking for a passphrase for
|
||||
the key. Choose a passphrase that is strong but also easy to remember.
|
||||
Click _OK_ and the key is created.
|
||||
|
||||
To find your GPG key ID click on the _My Personal Keys_ tab and look in
|
||||
the _Key ID_ column next to the newly created key. In most cases, if you
|
||||
are asked for the key ID, you should prepend "0x" to the key ID, as in
|
||||
"0x6789ABCD".
|
||||
|
||||
Now you should link:#BackupGNOME[ make a backup] of your private key.
|
||||
|
||||
[[creating-gpg-keys-using-the-kde-desktop]]
|
||||
Creating GPG Keys Using the KDE Desktop
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Start the *KGpg* program from the main menu by selecting _Utilities >
|
||||
PIM > KGpg_. If you have never used *KGpg* before, the program walks you
|
||||
through the process of creating your own GPG keypair.
|
||||
|
||||
A dialog box appears prompting you to create a new key pair. Enter your
|
||||
name, email address, and an optional comment. You can also choose an
|
||||
expiration time for your key, as well as the key strength (number of
|
||||
bits) and algorithms. The next dialog box prompts you for your
|
||||
passphrase. At this point, your key appears in the main *KGpg* window.
|
||||
|
||||
To find your GPG key ID, look in the _Key ID_ column next to the newly
|
||||
created key. In most cases, if you are asked for the key ID, you should
|
||||
prepend "0x" to the key ID, as in "0x6789ABCD".
|
||||
|
||||
Now you should link:#BackupKDE[ make a backup] of your private key.
|
||||
|
||||
[[creating-gpg-keys-using-the-command-line]]
|
||||
Creating GPG Keys Using the Command Line
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Use the following shell command:
|
||||
|
||||
....
|
||||
gpg2 --full-gen-key
|
||||
....
|
||||
|
||||
This command generates a key pair that consists of a public and a
|
||||
private key. Other people use your public key to authenticate and/or
|
||||
decrypt your communications. Distribute your *public* key as widely as
|
||||
possible, especially to people who you know will want to receive
|
||||
authentic communications from you, such as a mailing list. The Fedora
|
||||
Documentation Project, for example, asks participants to include a GPG
|
||||
public key in their link:DocsProject/SelfIntroduction[
|
||||
self-introduction] .
|
||||
|
||||
A series of prompts directs you through the process. Press the *Enter*
|
||||
key to assign a default value if desired. The first prompt asks you to
|
||||
select what kind of key you prefer:
|
||||
|
||||
....
|
||||
Please select what kind of key you want:
|
||||
(1) RSA and RSA (default)
|
||||
(2) DSA and Elgamal
|
||||
(3) DSA (sign only)
|
||||
(4) RSA (sign only)
|
||||
Your selection?
|
||||
....
|
||||
|
||||
In almost all cases, the default is the correct choice. A RSA/RSA key
|
||||
allows you not only to sign communications, but also to encrypt files.
|
||||
|
||||
Next, choose the key size:
|
||||
|
||||
....
|
||||
RSA keys may be between 1024 and 4096 bits long. Larger is almost always recommended here, however your use case and security models may dictate otherwise.
|
||||
What keysize do you want? (2048)
|
||||
....
|
||||
|
||||
Again, the default is sufficient for almost all users, and represents an
|
||||
_extremely_ strong level of security.
|
||||
|
||||
Next, choose when the key will expire. It is a good idea to choose an
|
||||
expiration date instead of using the default, which is _none._ If, for
|
||||
example, the email address on the key becomes invalid, an expiration
|
||||
date will remind others to stop using that public key.
|
||||
|
||||
....
|
||||
Please specify how long the key should be valid.
|
||||
0 = key does not expire
|
||||
<n> = key expires in n days
|
||||
<n>w = key expires in n weeks
|
||||
<n>m = key expires in n months
|
||||
<n>y = key expires in n years
|
||||
Key is valid for? (0)
|
||||
....
|
||||
|
||||
Entering a value of `1y`, for example, makes the key valid for one year.
|
||||
(You may change this expiration date after the key is generated, if you
|
||||
change your mind.)
|
||||
|
||||
Before the `gpg` program asks for signature information, the following
|
||||
prompt appears:
|
||||
|
||||
....
|
||||
Is this correct (y/n)?
|
||||
....
|
||||
|
||||
Enter `y` to finish the process.
|
||||
|
||||
Next, enter your name and email address. _Remember this process is about
|
||||
authenticating you as a real individual._ For this reason, include your
|
||||
_real name_. Do not use aliases or handles, since these disguise or
|
||||
obfuscate your identity.
|
||||
|
||||
Enter your real email address for your GPG key. If you choose a bogus
|
||||
email address, it will be more difficult for others to find your public
|
||||
key. This makes authenticating your communications difficult. If you are
|
||||
using this GPG key for link:DocsProject/SelfIntroduction[
|
||||
self-introduction] on a mailing list, for example, enter the email
|
||||
address you use on that list.
|
||||
|
||||
Use the comment field to include aliases or other information. (Some
|
||||
people use different keys for different purposes and identify each key
|
||||
with a comment, such as "Office" or "Open Source Projects.")
|
||||
|
||||
At the confirmation prompt, enter the letter *O* to continue if all
|
||||
entries are correct, or use the other options to fix any problems.
|
||||
|
||||
Finally, enter a passphrase for your secret key. The `gpg` program asks
|
||||
you to enter your passphrase twice to ensure you made no typing errors.
|
||||
|
||||
Finally, `gpg` generates random data to make your key as unique as
|
||||
possible. Move your mouse, type random keys, or perform other tasks on
|
||||
the system during this step to speed up the process. Once this step is
|
||||
finished, your keys are complete and ready to use:
|
||||
|
||||
....
|
||||
pub 1024D/1B2AFA1C 2005-03-31 John Q. Doe (Fedora Docs Project) <jqdoe@example.com>
|
||||
Key fingerprint = 117C FE83 22EA B843 3E86 6486 4320 545E 1B2A FA1C
|
||||
sub 1024g/CEA4B22E 2005-03-31 [expires: 2006-03-31]
|
||||
....
|
||||
|
||||
The key fingerprint is a shorthand "signature" for your key. It allows
|
||||
you to confirm to others that they have received your actual public key
|
||||
without any tampering. You do not need to write this fingerprint down.
|
||||
To display the fingerprint at any time, use this command, substituting
|
||||
your email address:
|
||||
|
||||
....
|
||||
gpg2 --fingerprint jqdoe@example.com
|
||||
....
|
||||
|
||||
Your "GPG key ID" consists of 8 hex digits identifying the public key.
|
||||
In the example above, the GPG key ID is 1B2AFA1C. In most cases, if you
|
||||
are asked for the key ID, you should prepend "0x" to the key ID, as in
|
||||
"0x1B2AFA1C".
|
||||
|
||||
Now you should link:#BackupCLI[ make a backup] of your private key.
|
||||
Including your revocation keys for all active keys ( this allows your
|
||||
revoking keys in the event of lost passphrase of key compromise)
|
||||
|
||||
[[making-a-backup]]
|
||||
Making a Backup
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
[[making-a-key-backup-using-the-gnome-desktop]]
|
||||
Making a Key Backup Using the GNOME Desktop
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Right-click your key and select _Properties_. Select the _Details_ tab,
|
||||
and _Export_, next to the _Export Complete Key_ label. Select a
|
||||
destination filename and click _Save_.
|
||||
|
||||
Store the copy in a secure place, such as a locked container. Now you
|
||||
are ready to link:#ExportGNOME[ make your public key available to
|
||||
others] .
|
||||
|
||||
[[making-a-key-backup-using-the-kde-desktop]]
|
||||
Making a Key Backup Using the KDE Desktop
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Right-click your key and select _Export Secret Key_. At the confirmation
|
||||
dialog, click _Export_ to continue, then select a destination filename
|
||||
and click _Save_.
|
||||
|
||||
Store the copy in a secure place, such as a locked container. Now you
|
||||
are ready to link:#ExportKDE[ make your public key available to others]
|
||||
.
|
||||
|
||||
[[making-a-key-backup-using-the-command-line]]
|
||||
Making a Key Backup Using the Command Line
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Use the following command to make the backup, which you can then copy to
|
||||
a destination of your choice:
|
||||
|
||||
....
|
||||
gpg2 --export-secret-keys --armor jqdoe@example.com > jqdoe-privkey.asc
|
||||
....
|
||||
|
||||
Store the copy in a secure place, such as a locked container. Now you
|
||||
are ready to link:#ExportCLI[ make your public key available to others]
|
||||
.
|
||||
|
||||
[[making-your-public-key-available]]
|
||||
Making Your Public Key Available
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
When you make your public key available to others, they can verify
|
||||
communications you sign, or send you encrypted communications if
|
||||
necessary. This procedure is also known as _exporting_.
|
||||
|
||||
You should now export your key using link:#ExportGNOME[ GNOME] ,
|
||||
link:#ExportKDE[ KDE] , or the link:#ExportCLI[ command line] . You can
|
||||
also link:#ExportFile[ copy your key manually] to a file if you wish to
|
||||
email it to individuals or groups.
|
||||
|
||||
[[exporting-a-gpg-key-using-the-gnome-desktop]]
|
||||
Exporting a GPG Key Using the GNOME Desktop
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Export the key to a public keyserver where other project members can
|
||||
obtain it. Right-click the key and select _Sync and Publish Keys..._ (or
|
||||
in the seahorse menu bar click on the _Remote_ menu and select _Sync and
|
||||
Publish Keys..._). Click _Key Servers_, select
|
||||
_hkp://subkeys.pgp.net:11371_ in the _Publish Keys To_ combobox, click
|
||||
_Close_ and then _Sync_.
|
||||
|
||||
You can now link:#Safeguarding[ read more about safeguarding your key]
|
||||
or use your browser to go back to a previous page.
|
||||
|
||||
[[exporting-a-gpg-key-using-the-kde-desktop]]
|
||||
Exporting a GPG Key Using the KDE Desktop
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
After your key has been generated, you can export the key to a public
|
||||
keyserver by right-clicking on the key in the main window, and selecting
|
||||
_Export Public Keys_. From there you can export your public key to the
|
||||
clipboard, an ASCII file, to an email, or directly to a key server.
|
||||
Export your public key to the default key server.
|
||||
|
||||
You can now link:#Safeguarding[ read more about safeguarding your key]
|
||||
or use your browser to go back to a previous page.
|
||||
|
||||
[[exporting-a-gpg-key-using-the-command-line]]
|
||||
Exporting a GPG Key Using the Command Line
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Use the following command to send your key to a public keyserver:
|
||||
|
||||
....
|
||||
gpg2 --send-key KEYNAME
|
||||
....
|
||||
|
||||
For _KEYNAME_, substitute the key ID or fingerprint of your primary
|
||||
keypair.
|
||||
|
||||
This will send your key to the gnupg default key server
|
||||
(keys.gnupg.net), if you prefer another one use :
|
||||
|
||||
....
|
||||
gpg2 --keyserver hkp://pgp.mit.edu --send-key KEYNAME
|
||||
....
|
||||
|
||||
Replacing "pgp.mit.edu" with your server of choice.
|
||||
|
||||
You can now link:#Safeguarding[ read more about safeguarding your key]
|
||||
or use your browser to go back to a previous page.
|
||||
|
||||
[[copying-a-public-key-manually]]
|
||||
Copying a Public Key Manually
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If you want to give or send a file copy of your key to someone, use this
|
||||
command to write it to an ASCII text file:
|
||||
|
||||
....
|
||||
gpg2 --export --armor jqdoe@example.com > jqdoe-pubkey.asc
|
||||
....
|
||||
|
||||
You can now link:#Safeguarding[ read more about safeguarding your key]
|
||||
or use your browser to go back to a previous page.
|
||||
|
||||
[[safeguarding-your-secret-key]]
|
||||
Safeguarding Your Secret Key
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Treat your secret key as you would any very important document or
|
||||
physical key. (Some people always keep their secret key on their person,
|
||||
either on magnetic or flash media.) If you lose your secret key, you
|
||||
will be unable to sign communications, or to open encrypted
|
||||
communications that were sent to you.
|
||||
|
||||
[[hardware-token-options]]
|
||||
Hardware Token options
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If you followed the above, you have a secret key which is just a regular
|
||||
file. A more secure model than keeping the key on disk is to use a
|
||||
hardware token.
|
||||
|
||||
There are several options available on the market, for example the
|
||||
https://www.yubico.com/products/yubikey-hardware/yubikey4/[YubiKey].
|
||||
Look for a token which advertises OpenPGP support. See
|
||||
https://blog.josefsson.org/2014/06/23/offline-gnupg-master-key-and-subkeys-on-yubikey-neo-smartcard/[this
|
||||
blog entry] for how to create a key with offline backups, and use the
|
||||
token for online access.
|
||||
|
||||
[[gpg-key-revocation]]
|
||||
GPG Key Revocation
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
When you revoke a key, you withdraw it from public use. _You should only
|
||||
have to do this if it is compromised or lost, or you forget the
|
||||
passphrase._
|
||||
|
||||
[[generating-a-revocation-certificate]]
|
||||
Generating a Revocation Certificate
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
When you create the key pair you should also create a key revocation
|
||||
certificate. If you later issue the revocation certificate, it notifies
|
||||
others that the public key is not to be used. Users may still use a
|
||||
revoked public key to verify old signatures, but not encrypt messages.
|
||||
As long as you still have access to the private key, messages received
|
||||
previously may still be decrypted. If you forget the passphrase, you
|
||||
will not be able to decrypt messages encrypted to that key.
|
||||
|
||||
....
|
||||
gpg2 --output revoke.asc --gen-revoke KEYNAME
|
||||
....
|
||||
|
||||
If you do not use the `--output` flag, the certificate will print to
|
||||
standard output.
|
||||
|
||||
For _KEYNAME_, substitute either the key ID of your primary keypair or
|
||||
any part of a user ID that identifies your keypair. Once you create the
|
||||
certificate (the `revoke.asc` file), you should protect it. If it is
|
||||
published by accident or through the malicious actions of others, the
|
||||
public key will become unusable. It is a good idea to write the
|
||||
revocation certificate to secure removable media or print out a hard
|
||||
copy for secure storage to maintain secrecy.
|
||||
|
||||
[[revoking-a-key]]
|
||||
Revoking a key
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
....
|
||||
gpg2 --import revoke.asc
|
||||
....
|
||||
|
||||
Once you locally revoke the key, you should send the revoked certificate
|
||||
to a keyserver, regardless of whether the key was originally issued in
|
||||
this way. Distribution through a server helps other users to quickly
|
||||
become aware the key has been compromised.
|
||||
|
||||
Export to a keyserver with the following command:
|
||||
|
||||
....
|
||||
gpg2 --keyserver subkeys.pgp.net --send KEYNAME
|
||||
....
|
||||
|
||||
For _KEYNAME_, substitute either the key ID of your primary keypair or
|
||||
any part of a user ID that identifies your keypair.
|
||||
|
||||
See the Using_GPG page for more ideas on using your new GPG keys.
|
||||
|
||||
Category:Informal_Documentation Category:Encryption
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
358
en-US/create-hello-world-rpm.adoc
Normal file
358
en-US/create-hello-world-rpm.adoc
Normal file
|
|
@ -0,0 +1,358 @@
|
|||
= How to create a GNU Hello RPM package
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/How_to_create_a_GNU_Hello_RPM_package
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
This is a short hands-on tutorial on writing RPM files, showing how to
|
||||
quickly step up to create simple source and binary software packages. It
|
||||
assumes some familiarity with using pre-made RPM packages, and with the
|
||||
FOSS building process.
|
||||
|
||||
For comprehensive information on how to create RPM files, including more
|
||||
detailed tips, refer to link:How_to_create_an_RPM_package[How to create
|
||||
an RPM package]. If you plan to create an RPM package for the Fedora
|
||||
repository, follow the process for
|
||||
link:Join_the_package_collection_maintainers[How to join the Fedora
|
||||
Package Collection Maintainers], including following the various Fedora
|
||||
guidance.
|
||||
|
||||
This tutorial demonstrates packaging of the GNU "Hello World" project.
|
||||
While the C program printing 'Hello World" to standard output is
|
||||
trivial, the GNU version contains most of the usual peripheral
|
||||
components associated with a typical FOSS project, including the
|
||||
configuration/build/install environment, documentation,
|
||||
internationalization, etc. The GNU version, however, traditionally
|
||||
consists of a `tar` file containing the source code and configure/make
|
||||
scripts, but it does not include the packaging information. Therefore,
|
||||
it's a reasonable vehicle to practice building RPMs on.
|
||||
|
||||
[[development-environment]]
|
||||
Development environment
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To build RPMs we need a set of development tools. This is a
|
||||
one-time-only setup, installed by running those commands from a system
|
||||
administration (`root`) account:
|
||||
|
||||
....
|
||||
# dnf install fedora-packager @development-tools
|
||||
....
|
||||
|
||||
To be able to test the build procedure in a clean chroot you need to
|
||||
configure your non-privileged account to be a member of the 'mock'
|
||||
group:
|
||||
|
||||
....
|
||||
# usermod -a -G mock <your username>
|
||||
....
|
||||
|
||||
Those are the only commands requiring `root` privileges. All the
|
||||
remaining work should be done from your regular, non-privileged account,
|
||||
or even from a separate account created just for development work.
|
||||
Modern RPM-based systems, including Fedora, are set up to build and test
|
||||
RPM packages purely from within a non-privileged account. The command
|
||||
|
||||
....
|
||||
$ rpmdev-setuptree
|
||||
....
|
||||
|
||||
sets up an RPM build area in your `~/rpmbuild` directory. This directory
|
||||
will contain several subdirectories, for the project source code, RPM
|
||||
configuration files and for the resulting source and binary packages.
|
||||
|
||||
[[building-a-hello-world-rpm]]
|
||||
Building a "Hello World" RPM
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
We need the source code of the project we are packaging, often referred
|
||||
to as the 'upstream' source. We will download it from the project's
|
||||
website into the `~/rpmbuild/SOURCE` directory. We are getting the
|
||||
compressed tarball archive, which happens to be the preferred
|
||||
distribution form for most FOSS projects.
|
||||
|
||||
....
|
||||
$ cd ~/rpmbuild/SOURCES
|
||||
$ wget http://ftp.gnu.org/gnu/hello/hello-2.10.tar.gz
|
||||
....
|
||||
|
||||
The RPM package is configured by `.spec` files. We will create a
|
||||
template file `hello.spec` in the appropriate directory:
|
||||
|
||||
....
|
||||
$ cd ~/rpmbuild/SPECS
|
||||
$ rpmdev-newspec hello
|
||||
....
|
||||
|
||||
Recent versions of `Emacs` and `vi` have .spec file editing modes which
|
||||
will also bring up a similar template upon creating a new file. So you
|
||||
can just use the following command for example to use the template
|
||||
automatically.
|
||||
|
||||
....
|
||||
$ emacs hello.spec
|
||||
....
|
||||
|
||||
[[inside-a-.spec-file]]
|
||||
Inside a `.spec` file
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The fields in our `.spec` file need slight editing. Please follow the
|
||||
link:How_to_create_an_RPM_package#Spec_file_pieces_explained[Fedora
|
||||
rules] for these fields. In our case, the file might start as follows:
|
||||
|
||||
....
|
||||
Name: hello
|
||||
Version: 2.10
|
||||
Release: 1
|
||||
Summary: The "Hello World" program from GNU
|
||||
License: GPLv3+
|
||||
URL: https://www.gnu.org/software/hello/
|
||||
Source0: https://ftp.gnu.org/gnu/hello/hello-%{version}.tar.gz
|
||||
|
||||
%description
|
||||
The "Hello World" program, done with all bells and whistles of a proper FOSS
|
||||
project, including configuration, build, internationalization, help files, etc.
|
||||
|
||||
%changelog
|
||||
* Thu Jul 07 2011 The Coon of Ty <Ty@coon.org> - 2.10-1
|
||||
- Initial version of the package
|
||||
....
|
||||
|
||||
The `Version` should mirror upstream while `Release` numbers our work
|
||||
within Fedora.
|
||||
|
||||
The first letter of the `Summary` should be uppercase to avoid `rpmlint`
|
||||
complaints.
|
||||
|
||||
It is your responsibility to check the `License` status of the software,
|
||||
by inspecting the source files and/or their `LICENSE` files, and/or by
|
||||
talking to the authors.
|
||||
|
||||
The `Group` tag was historically used to classify the package in
|
||||
accordance with the list in `/usr/share/doc/rpm-``/GROUPS`. It is being
|
||||
phased out so you will not see it added by default. However, it doesn't
|
||||
hurt to add it anyway.
|
||||
|
||||
The `%changelog` should document the work on preparing the RPM,
|
||||
especially if there are security and bug patches included on top of the
|
||||
base upstream source. Changelog data can be displayed by
|
||||
`rpm --changelog -q `, which is very useful for instance to find out if
|
||||
specific bug and security patches were included in the installed
|
||||
software, thanks to the diligent Fedora packagers who include this info
|
||||
with the relevant http://cve.mitre.org/[CVE] numbers.
|
||||
|
||||
The `%changelog` entry should include the version string to avoid
|
||||
`rpmlint` complaints.
|
||||
|
||||
Multi-line sections like `%changelog` or `%description` start on a line
|
||||
under the directive, and end with a blank line.
|
||||
|
||||
Lines which aren't needed (e.g. `BuildRequires` and `Requires`) can be
|
||||
commented out with a hash ('#') for now.
|
||||
|
||||
Many lines in the template don't need to be changed at all in many
|
||||
cases, at least for the initial attempt.
|
||||
|
||||
[[building-the-package]]
|
||||
Building the package
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
We are ready for the first run to build source, binary and debugging
|
||||
packages:
|
||||
|
||||
....
|
||||
$ rpmbuild -ba hello.spec
|
||||
....
|
||||
|
||||
It will complain and list the unpackaged files, i.e. the files that
|
||||
would be installed in the system that weren't declared as belonging to
|
||||
the package. We need to declare them in the `%files` section. Do not
|
||||
hardcode names like `/usr/bin/`, but use macros, like `%{_bindir}/hello`
|
||||
instead. The manual pages should be declared in the `%doc` subsection:
|
||||
`%doc %{_mandir}/man1/hello.1.*`.
|
||||
|
||||
This is an iterative process: after editing the `.spec` file, rerun
|
||||
`rpmbuild`.
|
||||
|
||||
Since our program uses translations and internationalization, we are
|
||||
seeing a lot of undeclared i18 files. The
|
||||
Packaging:Guidelines#Handling_Locale_Files[recommended method] to
|
||||
declare them is:
|
||||
|
||||
* find the filenames in the `%install` step: `%find_lang %{name}`
|
||||
* add the required build dependencies: `BuildRequires: gettext`
|
||||
* use the found filenames `%files -f %{name}.lang`
|
||||
|
||||
If the program uses GNU `info` files, you need to make sure the
|
||||
installation and uninstallation of the package does not interfere with
|
||||
other software on the system, by using this boilerplate:
|
||||
|
||||
* delete the `dir` file in `%install`:
|
||||
`rm -f %{buildroot}/%{_infodir}/dir`
|
||||
* `Requires(post): info` and `Requires(preun): info`
|
||||
* add those steps:
|
||||
|
||||
....
|
||||
%post
|
||||
/sbin/install-info %{_infodir}/%{name}.info %{_infodir}/dir || :
|
||||
|
||||
%preun
|
||||
if [ $1 = 0 ] ; then
|
||||
/sbin/install-info --delete %{_infodir}/%{name}.info %{_infodir}/dir || :
|
||||
fi
|
||||
....
|
||||
|
||||
This snippet is copied directly from
|
||||
Packaging:ScriptletSnippets#Texinfo. That page contains solutions to
|
||||
many common packaging tasks. If possible, try to copy a solution from
|
||||
there instead of devising your own.
|
||||
|
||||
[[a-complete-hello.spec-file]]
|
||||
A complete `hello.spec` file
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Here's the initial version of `hello.spec`:
|
||||
|
||||
....
|
||||
Name: hello
|
||||
Version: 2.10
|
||||
Release: 1%{?dist}
|
||||
Summary: The "Hello World" program from GNU
|
||||
|
||||
License: GPLv3+
|
||||
URL: http://ftp.gnu.org/gnu/%{name}
|
||||
Source0: http://ftp.gnu.org/gnu/%{name}/%{name}-%{version}.tar.gz
|
||||
|
||||
BuildRequires: gettext
|
||||
|
||||
Requires(post): info
|
||||
Requires(preun): info
|
||||
|
||||
%description
|
||||
The "Hello World" program, done with all bells and whistles of a proper FOSS
|
||||
project, including configuration, build, internationalization, help files, etc.
|
||||
|
||||
%prep
|
||||
%autosetup
|
||||
|
||||
%build
|
||||
%configure
|
||||
make %{?_smp_mflags}
|
||||
|
||||
%install
|
||||
%make_install
|
||||
%find_lang %{name}
|
||||
rm -f %{buildroot}/%{_infodir}/dir
|
||||
|
||||
%post
|
||||
/sbin/install-info %{_infodir}/%{name}.info %{_infodir}/dir || :
|
||||
|
||||
%preun
|
||||
if [ $1 = 0 ] ; then
|
||||
/sbin/install-info --delete %{_infodir}/%{name}.info %{_infodir}/dir || :
|
||||
fi
|
||||
|
||||
%files -f %{name}.lang
|
||||
%{_mandir}/man1/hello.1.*
|
||||
%{_infodir}/hello.info.*
|
||||
%{_bindir}/hello
|
||||
|
||||
%doc AUTHORS ChangeLog NEWS README THANKS TODO
|
||||
%license COPYING
|
||||
|
||||
%changelog
|
||||
* Tue Sep 06 2011 The Coon of Ty <Ty@coon.org> 2.10-1
|
||||
- Initial version of the package
|
||||
....
|
||||
|
||||
With this `.spec` file, you should be able to successfully complete the
|
||||
build process, and create the source and binary RPM packages.
|
||||
|
||||
Next you should check them for conformance with RPM design rules, by
|
||||
running `rpmlint` on the `.spec` file and all RPMs:
|
||||
|
||||
....
|
||||
$ rpmlint hello.spec ../SRPMS/hello* ../RPMS/*/hello*
|
||||
....
|
||||
|
||||
If there are no warnings or errors, we've succeeded. Otherwise, use
|
||||
`rpmlint -i` or `rpmlint -I <error_code>` to see a more verbose
|
||||
description of the `rpmlint` diagnostics.
|
||||
|
||||
[[the-mock-builds]]
|
||||
The `mock` builds
|
||||
^^^^^^^^^^^^^^^^^
|
||||
|
||||
To check that the package build will succeed in the Fedora restricted
|
||||
build environment, check it with `mock`. The default `mock`
|
||||
configuration builds the package against Rawhide - the Fedora
|
||||
development branch.
|
||||
|
||||
....
|
||||
$ mock --verbose ../SRPMS/hello-2.10-1.fc25.src.rpm
|
||||
....
|
||||
|
||||
[[references]]
|
||||
References
|
||||
~~~~~~~~~~
|
||||
|
||||
* link:How_to_create_an_RPM_package[How to create an RPM package]
|
||||
* link:Building_RPM_packages_(20090405)[Building RPM packages
|
||||
(20090405)]
|
||||
* link:Using_Mock_to_test_package_builds[Using Mock to test package
|
||||
builds]
|
||||
* link:Using_the_Koji_build_system[Using the Koji build system]
|
||||
|
||||
[[history]]
|
||||
History
|
||||
~~~~~~~
|
||||
|
||||
Przemek Klosowski wrote this tutorial when he worked through
|
||||
link:Building_RPM_packages_%2820090405%29[Christoph Wickert's IRC
|
||||
session on building RPMs] using Rahul Sundaram suggestion of GNU "Hello
|
||||
World" as a test case. After he wrote up his experience, he found out
|
||||
about the excellent and extensive link:How_to_create_an_RPM_package[How
|
||||
to create an RPM package] page on this wiki, as well as the
|
||||
http://www.absolutepanic.org/blog/2009/07/building-a-gnu-hello-world-rpm[Christian
|
||||
Lyder Jacobsen's website]. However, Christian isn't planning to update
|
||||
his site, and it seemed that a 5-minute 'fast food' alternative to the
|
||||
more extensive article might suit some people. More in-depth information
|
||||
on using and building RPM packages is available from link:Yum[other
|
||||
sources].
|
||||
|
||||
Category:Package_Maintainers[Category:Package Maintainers]
|
||||
Category:How_to[Category:How to]
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
64
en-US/create-xorg-conf.adoc
Normal file
64
en-US/create-xorg-conf.adoc
Normal file
|
|
@ -0,0 +1,64 @@
|
|||
= How to create xorg.conf
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/How_to_create_xorg.conf
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
Fedora releases since do not create a file, used to configure the X
|
||||
server, by default. The X configuration is automatically determined each
|
||||
time X is started. In most cases, this works well and there is no need
|
||||
to manually specify X configuration information.
|
||||
|
||||
If you need to make manual changes to X configuration for any reason,
|
||||
you will first need to create a file.
|
||||
|
||||
[[xorg--configure]]
|
||||
Xorg -configure
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
You can create a basic using the X executable itself. As root run:
|
||||
|
||||
....
|
||||
Xorg :1 -configure
|
||||
....
|
||||
|
||||
This will create the file , which you can then copy to :
|
||||
|
||||
....
|
||||
cp /root/xorg.conf.new /etc/X11/xorg.conf
|
||||
....
|
||||
|
||||
and edit according to your needs.
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
305
en-US/debug-dracut-problems.adoc
Normal file
305
en-US/debug-dracut-problems.adoc
Normal file
|
|
@ -0,0 +1,305 @@
|
|||
= How to debug Dracut problems
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/How_to_debug_Dracut_problems
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
*Foreword*
|
||||
|
||||
If you are experiencing a problem with system initialization due to
|
||||
Dracut, please see the link:Bugs/Common[common bugs] document before
|
||||
filing a bug. Some easy configuration tweaks that fix a wide range of
|
||||
issues may be listed there. If the problem you are seeing is not listed
|
||||
there or none of the workarounds seem to help, please consider filing a
|
||||
bug to help us make Fedora run better on your hardware.
|
||||
|
||||
Be prepared to include some information (logs) about your system as
|
||||
well. These should be complete (no snippets please), not in an archive,
|
||||
uncompressed, with MIME type set as text/plain.
|
||||
|
||||
[[identifying-your-problem-area]]
|
||||
Identifying your problem area
|
||||
-----------------------------
|
||||
|
||||
1. Remove `rhgb` and `quiet` from the kernel command line
|
||||
2. Add `rd.shell` to the kernel command line. This will present a shell
|
||||
should dracut be unable to locate your root device
|
||||
3. Add `rd.shell rd.debug log_buf_len=1M` to the kernel command line so
|
||||
that dracut shell commands are printed as they are executed
|
||||
4. Inspect the system logs:
|
||||
+
|
||||
....
|
||||
# less /run/initramfs/rdsosreport.txt
|
||||
# journalctl -a
|
||||
# dmesg
|
||||
# less /run/initramfs/init.log
|
||||
....
|
||||
|
||||
[[information-to-include-in-your-report]]
|
||||
Information to include in your report
|
||||
-------------------------------------
|
||||
|
||||
[[all-bug-reports]]
|
||||
All bug reports
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
In all cases, the following should be mentioned and attached to your bug
|
||||
report:
|
||||
|
||||
* The exact kernel command-line used. Typically from the bootloader
|
||||
configuration file (e.g. ) or from
|
||||
* A copy of your disk partition information from
|
||||
* A device listing from device-mapper. This can be obtained by running
|
||||
the command
|
||||
* A list of block device attributes including vol_id compatible mode.
|
||||
This can be obtained by running the commands and
|
||||
* Turn on dracut debugging (see
|
||||
link:How_to_debug_Dracut_problems#Debugging[the 'debugging dracut'
|
||||
section]), and attach all relevant information from the boot log. This
|
||||
can be obtained by running the command grep dracut}}.
|
||||
* If you use a dracut configuration file, please include
|
||||
|
||||
[[logical-volume-management-related-problems]]
|
||||
Logical Volume Management related problems
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
As well as the information from
|
||||
link:How_to_debug_Dracut_problems#AllInfo[the 'all bug reports'
|
||||
section], include the following information:
|
||||
|
||||
* Include physical volume information by running the command:
|
||||
* Include volume group information by running the command:
|
||||
* Include logical volume information by running the command:
|
||||
|
||||
[[software-raid-related-problems]]
|
||||
Software RAID related problems
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
As well as the information from
|
||||
link:How_to_debug_Dracut_problems#AllInfo[the 'all bug reports'
|
||||
section], include the following information:
|
||||
|
||||
* If using software RAID disk partitions, please include the output of
|
||||
|
||||
[[network-root-device-related-problems]]
|
||||
Network root device related problems
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This section details information to include when experiencing problems
|
||||
on a system whose root device is located on a network attached volume
|
||||
(e.g. iSCSI, NFS or NBD). As well as the information from
|
||||
link:How_to_debug_Dracut_problems#AllInfo[the 'all bug reports'
|
||||
section], include the following information:
|
||||
|
||||
* Please include the output of
|
||||
|
||||
[[debugging-dracut]]
|
||||
Debugging dracut
|
||||
----------------
|
||||
|
||||
[[configure-a-serial-console]]
|
||||
Configure a serial console
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Successfully debugging dracut will require some form of console logging
|
||||
during the system boot. This section documents configuring a serial
|
||||
console connection to record boot messages. To enable serial console
|
||||
output for both the kernel and the bootloader, follow the procedure
|
||||
below.
|
||||
|
||||
1. Open the file for editing. Below the line _timeout=5_, add the
|
||||
following:
|
||||
+
|
||||
....
|
||||
serial --unit=0 --speed=9600
|
||||
terminal --timeout=5 serial console
|
||||
....
|
||||
2. Also in , add the following boot arguemnts to the _kernel_ line:
|
||||
+
|
||||
....
|
||||
console=tty0 console=ttyS0,9600
|
||||
....
|
||||
3. When finished, the file should look similar to the example below.
|
||||
+
|
||||
....
|
||||
default=0
|
||||
timeout=5
|
||||
serial --unit=0 --speed=9600
|
||||
terminal --timeout=5 serial console
|
||||
title Fedora (2.6.29.5-191.fc11.x86_64)
|
||||
root (hd0,0)
|
||||
kernel /vmlinuz-2.6.29.5-191.fc11.x86_64 ro root=/dev/mapper/vg_uc1-lv_root console=tty0 console=ttyS0,9600
|
||||
initrd /dracut-2.6.29.5-191.fc11.x86_64.img
|
||||
....
|
||||
|
||||
More detailed information on how to configure the kernel for console
|
||||
output can be found at
|
||||
http://www.faqs.org/docs/Linux-HOWTO/Remote-Serial-Console-HOWTO.html#CONFIGURE-KERNEL[1].
|
||||
|
||||
[[using-the-dracut-shell]]
|
||||
Using the dracut shell
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Dracut offers a shell for interactive debugging in the event dracut
|
||||
fails to locate your root filesystem. To enable the shell:
|
||||
|
||||
1. Add the boot parameter `rd.shell` to your bootloader configuration
|
||||
file (e.g.
|
||||
2. Remove the boot arguments `rhgb` and `quiet`
|
||||
|
||||
A sample bootloader configuration file is listed below.
|
||||
|
||||
....
|
||||
default=0
|
||||
timeout=5
|
||||
serial --unit=0 --speed=9600
|
||||
terminal --timeout=5 serial console
|
||||
title Fedora (2.6.29.5-191.fc11.x86_64)
|
||||
root (hd0,0)
|
||||
kernel /vmlinuz-2.6.29.5-191.fc11.x86_64 ro root=/dev/mapper/vg_uc1-lv_root console=tty0 rd.shell
|
||||
initrd /dracut-2.6.29.5-191.fc11.x86_64.img
|
||||
....
|
||||
|
||||
If system boot fails, you will be dropped into a shell as seen in the
|
||||
example below.
|
||||
|
||||
....
|
||||
No root device found
|
||||
Dropping to debug shell.
|
||||
|
||||
sh: can't access tty; job control turned off
|
||||
#
|
||||
....
|
||||
|
||||
Use this shell prompt to gather the information requested above (see
|
||||
link:How_to_debug_Dracut_problems#AllInfo[the 'all bug reports'
|
||||
section]).
|
||||
|
||||
[[accessing-the-root-volume-from-the-dracut-shell]]
|
||||
Accessing the root volume from the dracut shell
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
From the dracut debug shell, you can manually perform the task of
|
||||
locating and preparing your root volume for boot. The required steps
|
||||
will depend on how your root volume is configured. Common scenarios
|
||||
include:
|
||||
|
||||
* A block device (e.g. )
|
||||
* A LVM logical volume (e.g. )
|
||||
* An encrypted device (e.g. )
|
||||
* A network attached device (e.g.
|
||||
iscsi:@192.168.0.4::3260::iqn.2009-02.org.fedoraproject:for.all}})
|
||||
|
||||
The exact method for locating and preparing will vary. However, to
|
||||
continue with a successful boot, the objective is to locate your root
|
||||
volume and create a symlink which points to the file system. For
|
||||
example, the following example demonstrates accessing and booting a root
|
||||
volume that is an encrypted LVM Logical volume.
|
||||
|
||||
1. Inspect your partitions using
|
||||
+
|
||||
....
|
||||
# parted /dev/sda -s p
|
||||
Model: ATA HTS541060G9AT00 (scsi)
|
||||
Disk /dev/sda: 60.0GB
|
||||
Sector size (logical/physical): 512B/512B
|
||||
Partition Table: msdos
|
||||
|
||||
Number Start End Size Type File system Flags
|
||||
1 32.3kB 10.8GB 107MB primary ext4 boot
|
||||
2 10.8GB 55.6GB 44.7GB logical lvm
|
||||
....
|
||||
2. You recall that your root volume was a LVM logical volume. Scan and
|
||||
activate any logical volumes
|
||||
+
|
||||
....
|
||||
# lvm vgscan
|
||||
# lvm vgchange -ay
|
||||
....
|
||||
3. You should see any logical volumes now using the command :
|
||||
+
|
||||
....
|
||||
# blkid
|
||||
/dev/sda1: UUID="3de247f3-5de4-4a44-afc5-1fe179750cf7" TYPE="ext4"
|
||||
/dev/sda2: UUID="Ek4dQw-cOtq-5MJu-OGRF-xz5k-O2l8-wdDj0I" TYPE="LVM2_member"
|
||||
/dev/mapper/linux-root: UUID="def0269e-424b-4752-acf3-1077bf96ad2c" TYPE="crypto_LUKS"
|
||||
/dev/mapper/linux-home: UUID="c69127c1-f153-4ea2-b58e-4cbfa9257c5e" TYPE="ext3"
|
||||
/dev/mapper/linux-swap: UUID="47b4d329-975c-4c08-b218-f9c9bf3635f1" TYPE="swap"
|
||||
....
|
||||
4. From the output above, you recall that your root volume exists on an
|
||||
encrypted block device. Following the guidance disk encryption guidance
|
||||
from the
|
||||
http://docs.fedoraproject.org/install-guide/f%7B%7BFedoraVersion%7D%7D/en-US/html/apcs04s04.html[
|
||||
Installation Guide], you unlock your encrypted root volume.
|
||||
+
|
||||
....
|
||||
UUID=$(cryptsetup luksUUID /dev/mapper/linux-root)
|
||||
cryptsetup luksOpen /dev/mapper/linux-root luks-$UUID
|
||||
Enter passphrase for /dev/mapper/linux-root:
|
||||
Key slot 0 unlocked.
|
||||
....
|
||||
5. Next, make a symbolic link to the unlocked root volume
|
||||
+
|
||||
....
|
||||
ln -s /dev/mapper/luks-$UUID /dev/root
|
||||
....
|
||||
6. With the root volume available, you may continue booting the system
|
||||
by exiting the dracut shell
|
||||
+
|
||||
....
|
||||
exit
|
||||
....
|
||||
|
||||
[[summary-of-dracut-kernel-command-line-options]]
|
||||
Summary of dracut kernel command line options
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
A selection of the most common debugging related dracut options:
|
||||
|
||||
rd.shell : Drop to a shell, if the initramfs fails. +
|
||||
rd.debug : set -x for the dracut shell. +
|
||||
rd.break=[cmdline|pre-udev|pre-trigger|initqueue|pre-mount|mount|pre-pivot|cleanup]
|
||||
: drop the shell on defined breakpoint (use
|
||||
`egrep 'rd.?break' /usr/lib/dracut/modules.d/99base/init.sh` to find the
|
||||
breakpoints supported by your dracut version) +
|
||||
rd.udev.info : set udev to loglevel info +
|
||||
rd.udev.debug : set udev to loglevel debug::
|
||||
|
||||
See the `dracut.cmdline(7)`
|
||||
http://man7.org/linux/man-pages/man7/dracut.cmdline.7.html[man page] for
|
||||
the complete reference.
|
||||
|
||||
Category:Debugging[D] Category:How_to[Category:How to]
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
146
en-US/debug-systemd-problems.adoc
Normal file
146
en-US/debug-systemd-problems.adoc
Normal file
|
|
@ -0,0 +1,146 @@
|
|||
= How to debug Systemd problems
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/How_to_debug_Systemd_problems
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
*Foreword*
|
||||
|
||||
If you are experiencing a problem with system boot up due to Systemd,
|
||||
please see the link:Bugs/Common[common bugs] document before filing a
|
||||
bug. Some easy configuration tweaks that fix a wide range of issues may
|
||||
be listed there. If the problem you are seeing is not listed there or
|
||||
none of the workarounds seem to help, please consider filing a bug to
|
||||
help us make Fedora run better on your hardware.
|
||||
|
||||
[[debugging-systemd-problems]]
|
||||
Debugging systemd problems
|
||||
--------------------------
|
||||
|
||||
[[various-useful-systemd-related-commands]]
|
||||
Various useful systemd related commands
|
||||
---------------------------------------
|
||||
|
||||
* Run `systemctl list-jobs`
|
||||
|
||||
To identify slow boot and look for the jobs that are "running" those
|
||||
jobs are the ones where boot waits for completion on and the ones that
|
||||
listed as "waiting" will be executed only after those which are
|
||||
"running" are completed.
|
||||
|
||||
* Run `systemctl list-units -t service --all`
|
||||
|
||||
To list all available services and their current status
|
||||
|
||||
* Run `systemctl list-units -t service`
|
||||
|
||||
To show all active services
|
||||
|
||||
* Run `systemctl status sshd.service`
|
||||
|
||||
To examine the current runtime status of a service. (In the above
|
||||
example the ssh service)
|
||||
|
||||
* Run `systemctl list-units -t target --all`
|
||||
|
||||
To show all available targets.
|
||||
|
||||
* Run `systemctl list-units -t target`
|
||||
|
||||
To show all active targets.
|
||||
|
||||
* Run `systemctl show -p "Wants" multi-user.target`
|
||||
|
||||
To see which services a target pulls in. ( In the above example the
|
||||
multi-user.target )
|
||||
|
||||
* Run
|
||||
`/usr/lib/systemd/systemd --test --system --unit=multi-user.target`
|
||||
|
||||
To examine what gets started when when booted into a specific target. (
|
||||
In the above example the multi-user.target )
|
||||
|
||||
[[systemd-boot-parameters]]
|
||||
Systemd boot parameters
|
||||
-----------------------
|
||||
|
||||
The following boot parameters are also available to further assist with
|
||||
debugging boot issues.
|
||||
|
||||
systemd.unit= : Overrides the unit to activate on boot. This may be used
|
||||
to temporarily boot into a different boot unit, for example
|
||||
rescue.target or emergency.target. ( Defaults to default.target. )::
|
||||
|
||||
systemd.dump_core= : Takes a boolean argument. If true systemd dumps
|
||||
core when it crashes. Otherwise no core dump is created. ( Defaults to
|
||||
true )::
|
||||
|
||||
systemd.crash_shell= : Takes a boolean argument. If true systemd spawns
|
||||
a shell when it crashes. Otherwise no core dump is created. Defaults to
|
||||
false, for security reasons, as the shell is not protected by any
|
||||
password authentication.::
|
||||
|
||||
systemd.crash_chvt= :Takes an integer argument. If positive systemd
|
||||
activates the specified virtual terminal when it crashes. ( Defaults to
|
||||
-1 )::
|
||||
|
||||
systemd.confirm_spawn= : Takes a boolean argument. If true asks for
|
||||
confirmation when spawning processes. ( Defaults to false )::
|
||||
|
||||
systemd.show_status= : Takes a boolean argument. If true shows terse
|
||||
service status updates on the console during bootup. ( Defaults to true
|
||||
)::
|
||||
|
||||
systemd.sysv_console= : Takes a boolean argument. If true output of SysV
|
||||
init scripts will be directed to the console. ( Defaults to true, unless
|
||||
quiet is passed as kernel command line option in which case it defaults
|
||||
to false. )::
|
||||
|
||||
systemd.log_target= : Set log target. Argument must be one of console,
|
||||
syslog, kmsg, syslog-or-kmsg, null.::
|
||||
|
||||
systemd.log_level= : Set log level. As argument this accepts a numerical
|
||||
log level or the well-known syslog symbolic names (lowercase): emerg,
|
||||
alert, crit, err, warning, notice, info, debug.::
|
||||
|
||||
systemd.log_color= : Highlight important log messages. Argument is a
|
||||
boolean value. If the argument is omitted it defaults to true.::
|
||||
|
||||
systemd.log_location= : Include code location in log messages. This is
|
||||
mostly relevant for debugging purposes. Argument is a boolean value. If
|
||||
the argument is omitted it defaults to true.::
|
||||
|
||||
Category:Debugging[D] Category:How_to[Category:How to]
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
552
en-US/debug-wayland-problems.adoc
Normal file
552
en-US/debug-wayland-problems.adoc
Normal file
|
|
@ -0,0 +1,552 @@
|
|||
= How to debug Wayland problems
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/How_to_debug_Wayland_problems
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
https://en.wikipedia.org/wiki/Wayland_%28display_server_protocol%29[Wayland]
|
||||
is intended as a simpler replacement for
|
||||
https://en.wikipedia.org/wiki/X_Window_System[X11]. It changes the
|
||||
design of a Linux desktop architecture considerably. Unlike X11, there
|
||||
is no dedicated standalone server in Wayland. What was previously done
|
||||
between the app, its toolkit, the Xserver and the window manager is now
|
||||
shared between the app, its toolkit and the Wayland compositor which
|
||||
manages the compositing, input, windows management, etc. The apps and
|
||||
toolkits are now in charge of their own rendering and decorations
|
||||
(client side decorations), so any issues usually sit between the toolkit
|
||||
(e.g. GTK+) and the Wayland compositor (e.g. mutter).
|
||||
|
||||
You can read more about Wayland on the GNOME
|
||||
https://wiki.gnome.org/Initiatives/Wayland[Wayland initiative] wiki
|
||||
page. You can read more about the current state of Wayland features on
|
||||
link:Wayland_features[Wayland features] page.
|
||||
|
||||
[[identifying-wayland-problems]]
|
||||
Identifying Wayland problems
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
[[are-you-running-a-wayland-session]]
|
||||
Are you running a Wayland session?
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
In *GNOME*, there's a gear button at the login screen which can be used
|
||||
to either log into a Wayland session (simply called _GNOME_, it's the
|
||||
default option), or a legacy X11 session (called _GNOME on Xorg_). If
|
||||
you have a password-less user account, you won't see the gear icon, it
|
||||
is displayed only when the password prompt appears. Use the gear button
|
||||
to determine type of session you're logging into. If you want to start
|
||||
your session in a different way, read
|
||||
https://wiki.gnome.org/Initiatives/Wayland/TryingIt[the advanced
|
||||
techniques for trying Wayland].
|
||||
|
||||
image:gdm-pick-wayland.png[gdm-pick-wayland.png,title="gdm-pick-wayland.png",width=400]
|
||||
|
||||
In *KDE*, there is support for running a nested Wayland session inside
|
||||
your X11 session. You'll need to install `kwin-wayland` package and then
|
||||
follow up with https://community.kde.org/KWin/Wayland[this howto]. There
|
||||
doesn't seem to be out-of-the-box support for running a full Wayland
|
||||
session at the moment.
|
||||
|
||||
Other desktop environments are not currently capable of running a
|
||||
Wayland session.
|
||||
|
||||
[[identifying-the-session-type-in-runtime]]
|
||||
Identifying the session type in runtime
|
||||
|
||||
If you want to figure out which type of session you're running right
|
||||
now, without logging out and in again, you can use several ways to
|
||||
figure it out:
|
||||
|
||||
* Wayland session should have `WAYLAND_DISPLAY` variable set, X11
|
||||
session should not have it:
|
||||
+
|
||||
....
|
||||
$ echo $WAYLAND_DISPLAY
|
||||
wayland-0
|
||||
....
|
||||
* `loginctl` can give you this information. First run `loginctl` and
|
||||
find your session number (if should be an integer number, with your
|
||||
username and seat assigned). Then look at the session type (`x11` or
|
||||
`wayland`):
|
||||
+
|
||||
....
|
||||
$ loginctl show-session <YOUR_NUMBER> -p Type
|
||||
Type=x11
|
||||
....
|
||||
|
||||
If you're running an X11 session, not a Wayland session, your problems
|
||||
are not related to Wayland. It's a bug either in that particular
|
||||
application, or X11 itself, see link:How_to_debug_Xorg_problems[How to
|
||||
debug Xorg problems].
|
||||
|
||||
[[does-your-application-run-on-wayland-natively-or-uses-xwayland-x11-compatibility-layer]]
|
||||
Does your application run on Wayland natively, or uses XWayland (X11
|
||||
compatibility layer)?
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
It is important to know whether the problematic application is a native
|
||||
Wayland application, or runs through XWayland, which allows legacy
|
||||
applications to still run on top of Xorg server, but display in a
|
||||
Wayland session.
|
||||
|
||||
There are several ways how to identify whether an application is using
|
||||
Wayland or XWayland:
|
||||
|
||||
* Select the window using `xwininfo` or `xprop`. Run:
|
||||
+
|
||||
....
|
||||
$ xwininfo
|
||||
....
|
||||
+
|
||||
Your mouse pointer should change to a cross under X11, it doesn't seem
|
||||
to change under Wayland. Now click anywhere inside the app window you
|
||||
want to test. If the `xwininfo` command finishes (it should print window
|
||||
properties into the terminal), the app under test is running under
|
||||
XWayland. If nothing happens (the `xwininfo` command is still waiting
|
||||
until you select a window), the app under test is running under Wayland
|
||||
(you can close the command with `Ctrl+C`). +
|
||||
You can also use `xprop` command using the same instructions.
|
||||
* XWayland applications are listed in `xlsclients` output. Run:
|
||||
+
|
||||
....
|
||||
$ xlsclients
|
||||
....
|
||||
+
|
||||
However, this list of not always entirely reliable, some apps might be
|
||||
missing.
|
||||
* You can try to run the app while unsetting `DISPLAY` environment
|
||||
variable:
|
||||
+
|
||||
....
|
||||
$ DISPLAY='' command
|
||||
....
|
||||
+
|
||||
If the application runs OK, it should be using Wayland natively.
|
||||
* You can run the app with `WAYLAND_DEBUG=1` environment variable:
|
||||
+
|
||||
....
|
||||
$ WAYLAND_DEBUG=1 command
|
||||
....
|
||||
+
|
||||
If you see loads of output (when compared to a standard run), the app is
|
||||
using Wayland natively.
|
||||
* Under GNOME, you can determine this using
|
||||
http://blog.bodhizazen.net/linux/how-to-determine-if-an-application-is-using-wayland-or-xwayland/[integrated
|
||||
Looking Glass tool]. Hit `Alt+F2`, run:
|
||||
+
|
||||
....
|
||||
lg
|
||||
....
|
||||
+
|
||||
click on _Windows_ in the upper right corner of the tool and select
|
||||
desired window by clicking on its name. If you see `MetaWindowWayland`
|
||||
in the first line, this app is running under Wayland. If you see
|
||||
`MetaWindowX11` in the first line, this app is running under X11.
|
||||
|
||||
If you have identified the problem to be in a XWayland application, try
|
||||
to reproduce the issue in a standard X11 session. If it happens as well,
|
||||
it is not related to Wayland, it's a bug either in that particular
|
||||
application, or Xorg server, see link:How_to_debug_Xorg_problems[How to
|
||||
debug Xorg problems]. If the problem happens only under XWayland but not
|
||||
in an X11 session, it should still be reported against Xorg server (
|
||||
package), because XWayland is included in it (as
|
||||
`xorg-x11-server-Xwayland` subpackage).
|
||||
|
||||
[[identifying-problem-component]]
|
||||
Identifying problem component
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Wayland itself is a protocol and the problem is rarely in the protocol
|
||||
itself. Rather, the problem is likely to be in the app or its toolkit,
|
||||
or in the compositor.
|
||||
|
||||
The most notable Wayland-ready toolkits are:
|
||||
|
||||
* https://en.wikipedia.org/wiki/GTK%2B[GTK+ 3] - default apps in GNOME
|
||||
environment use almost exclusively this toolkit. Please note that apps
|
||||
using older GTK+ 2 are not Wayland-ready.
|
||||
* https://en.wikipedia.org/wiki/Qt_%28software%29[QT 5] - many apps in
|
||||
KDE environment use this toolkit. Please note that apps using older QT 4
|
||||
are not Wayland-ready.
|
||||
|
||||
The most notable Wayland compositors are:
|
||||
|
||||
* https://en.wikipedia.org/wiki/Wayland_%28display_server_protocol%29#Weston[Weston]
|
||||
- the reference implementation of a Wayland compositor, maintained
|
||||
directly by the Wayland project
|
||||
* https://en.wikipedia.org/wiki/Mutter_%28software%29[Mutter] -
|
||||
compositor in GNOME. If you run GNOME, it is using this compositor.
|
||||
* https://community.kde.org/KWin/Wayland[Kwin] - compositor in KDE. If
|
||||
you run KDE, it is using this compositor.
|
||||
|
||||
[[testing-under-different-compositors]]
|
||||
Testing under different compositors
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If you experience a problem with a Wayland app, it is very useful to
|
||||
know whether the problem is present under just a single compositor (in
|
||||
that case it's likely a compositor bug) or under multiple compositors
|
||||
(in that case it's likely an app/toolkit bug).
|
||||
|
||||
Please run your session with the reference Weston compositor and try to
|
||||
reproduce the issue. You can either run Weston as a nested window, or as
|
||||
a full session. First, install package (you can read many useful
|
||||
information in its man page):
|
||||
|
||||
`$ sudo dnf install weston`
|
||||
|
||||
Then create a config file which will specify that you want to have
|
||||
XWayland support enabled in your weston sessions. Create
|
||||
`~/.config/weston.ini` with this contents:
|
||||
|
||||
`[core]` +
|
||||
`modules=xwayland.so`
|
||||
|
||||
Now you can start weston either as nested window or as a full session.
|
||||
|
||||
* To start a nested Weston window, run this from a terminal:
|
||||
+
|
||||
....
|
||||
$ weston
|
||||
....
|
||||
+
|
||||
A Weston window should open and you should see and a terminal icon in
|
||||
its top left corner. Use that icon to launch a terminal and from that
|
||||
you can run apps and other commands using Weston. Exit the compositor by
|
||||
simply closing the window or killing the `weston` process.
|
||||
* To start a full Weston session (not nested inside another X11 or
|
||||
Wayland session), switch to a free VT (Ctrl+Alt+Fx) and run:
|
||||
+
|
||||
....
|
||||
$ weston-launch
|
||||
....
|
||||
+
|
||||
You can exit the session by pressing Control+Alt+Backspace shortcut.
|
||||
|
||||
If you can reproduce the issue with Weston, file an issue against the
|
||||
app or its toolkit (gtk+, qt, etc). Otherwise file the issue against the
|
||||
compositor your environment uses (mutter, kwin, etc). If the problem
|
||||
occurs only with XWayland apps but not native Wayland apps, report a bug
|
||||
against Xorg server.
|
||||
|
||||
[[reporting-the-issue]]
|
||||
Reporting the issue
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
[[using-up-to-date-software]]
|
||||
Using up-to-date software
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Before reporting the bug, please make sure you use the latest available
|
||||
software. You need to run on *Fedora 23 or later*, older Fedora versions
|
||||
are not going to get updated with latest Wayland fixes. Make sure there
|
||||
are no system updates waiting:
|
||||
|
||||
`$ sudo dnf update`
|
||||
|
||||
If there are (and the available updates look plausibly related to the
|
||||
components you're seeing issues with), please update the system and
|
||||
verify whether the issue is still present or has been fixed.
|
||||
|
||||
[[looking-for-similar-reports]]
|
||||
Looking for similar reports
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
In order to avoid duplicate reports and also wasting your time debugging
|
||||
something someone has maybe already debugged, please search through the
|
||||
existing reports first. The most visible issues or concerns are listed
|
||||
in
|
||||
link:#Known_issues.2C_frequent_complaints.2C_fundamental_changes[Known
|
||||
issues, frequent complaints, fundamental changes]. If you don't see it
|
||||
there, you need to search deeper. You can find Wayland related issues
|
||||
most likely in here:
|
||||
|
||||
* [https://bugzilla.gnome.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&component=Backend%3A%20Wayland&component=wayland&list_id=74680&order=changeddate%20DESC%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&product=gtk%2B&product=mutter&query_based_on=&query_format=advanced
|
||||
mutter/wayland and GTK+/wayland in GNOME Bugzilla]
|
||||
* https://bugzilla.gnome.org/showdependencytree.cgi?id=757579&hide_resolved=1[Wayland-related
|
||||
issues tracker across GNOME Bugzilla]
|
||||
* https://bugzilla.redhat.com/showdependencytree.cgi?id=WaylandRelated&hide_resolved=1[Wayland-related
|
||||
issues tracker across Red Hat Bugzilla]
|
||||
(https://bugzilla.redhat.com/showdependencytree.cgi?id=KDEWaylandRelated&hide_resolved=1[KDE
|
||||
tracker])
|
||||
* [https://bugzilla.redhat.com/buglist.cgi?classification=Fedora&component=wayland&list_id=4118943&order=changeddate%20DESC%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&product=Fedora&query_based_on=&query_format=advanced&resolution=---
|
||||
Wayland in Red Hat Bugzilla]
|
||||
* [https://bugs.freedesktop.org/buglist.cgi?list_id=561109&order=changeddate%20DESC%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&product=Wayland&query_based_on=&query_format=advanced&resolution=---
|
||||
Wayland in Freedesktop Bugzilla]
|
||||
* Google search
|
||||
|
||||
[[filing-a-bug]]
|
||||
Filing a bug
|
||||
^^^^^^^^^^^^
|
||||
|
||||
After you've identified against which component to (most probably)
|
||||
report the issue and found no existing report of it, there are several
|
||||
places where to report it:
|
||||
|
||||
* https://bugzilla.redhat.com/[Red Hat Bugzilla] - recommended for
|
||||
issues related to wayland itself, weston compositor, non-GNOME apps, KDE
|
||||
project, QT toolkit
|
||||
* https://bugzilla.gnome.org/[GNOME Bugzilla] - recommended for issues
|
||||
related to mutter compositor, GTK+ toolkit, applications under the GNOME
|
||||
project (most of default apps in Fedora Workstation)
|
||||
|
||||
When reporting the issue, please make your report block our tracker, so
|
||||
that we have a good overall picture of what is broken across many
|
||||
different components. In your bug report, set *Blocks: WaylandRelated*
|
||||
or *Blocks: KDEWaylandRelated* (you might need to toggle showing
|
||||
advanced fields to see the _Blocks:_ field). That will make it block one
|
||||
of these trackers, depending where you reported the bug:
|
||||
|
||||
* https://bugzilla.redhat.com/show_bug.cgi?id=1277927[Wayland Tracker in
|
||||
Red Hat Bugzilla]
|
||||
(https://bugzilla.redhat.com/show_bug.cgi?id=1298494[KDE tracker])
|
||||
* https://bugzilla.gnome.org/show_bug.cgi?id=757579[Wayland Tracker in
|
||||
GNOME Bugzilla]
|
||||
|
||||
[[information-to-include-in-your-bug-report]]
|
||||
Information to include in your bug report
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
1. System journal. Since there is no unique server like the X11 server,
|
||||
most of the important information will come from the the Wayland
|
||||
compositor and the apps. All of that should be in system journal
|
||||
nowadays. You can save a full journal since last boot like this:
|
||||
+
|
||||
....
|
||||
$ journalctl -ab > journal.log
|
||||
....
|
||||
+
|
||||
You can also edit the file and according to the timestamps remove
|
||||
everything long prior to when the issue occurred, in order to make the
|
||||
log more succinct.
|
||||
* If your system crashed or became unresponsive so that you had to
|
||||
reboot it, you can see the journal from the previous boot using
|
||||
`journalctl -a -b -1` instead.
|
||||
2. Wayland debug output. If you can reproduce the issue, please run the
|
||||
problematic app like this:
|
||||
+
|
||||
....
|
||||
$ WAYLAND_DEBUG=1 command |& tee debug.out
|
||||
....
|
||||
+
|
||||
You should see loads of output being printed out. It will involve all
|
||||
communication between the app and the compositor.
|
||||
3. Information whether the same problem occurs when you run the app
|
||||
using XWayland instead of Wayland. For GTK+ 3 apps, you can force a
|
||||
native Wayland app to run using XWayland like this:
|
||||
+
|
||||
....
|
||||
$ GDK_BACKEND=x11 command
|
||||
....
|
||||
+
|
||||
Vice versa, you can also force a XWayland app to run using Wayland (in
|
||||
case it has just experimental support):
|
||||
+
|
||||
....
|
||||
$ GDK_BACKEND=wayland command
|
||||
....
|
||||
+
|
||||
QT 5 apps run with XWayland by default. You can force Wayland backend:
|
||||
+
|
||||
....
|
||||
$ QT_QPA_PLATFORM=wayland-egl command
|
||||
....
|
||||
+
|
||||
All of this applies to just GTK+ 3 and QT 5 apps.
|
||||
4. Hardware description is useful for some hardware-related bugs:
|
||||
+
|
||||
....
|
||||
$ lspci -nn > lspci.out
|
||||
....
|
||||
5. Package versions. You can collect the list and versions of all your
|
||||
packages installed using:
|
||||
+
|
||||
....
|
||||
$ rpm -qa | sort > packages.out
|
||||
....
|
||||
6. The
|
||||
link:Bugs_and_feature_requests#Things_Every_Bug_Should_Have[usual
|
||||
information] that every bug report should have.
|
||||
|
||||
[[debugging-gnome-shell]]
|
||||
Debugging gnome-shell
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If gnome-shell gets stuck and unresponsive, it's very helpful to obtain
|
||||
a backtrace from its process and attach it to the report. If this
|
||||
happens, switch to a different VT if possible (`Ctrl+Alt+F3` through
|
||||
`F7`), or log in using ssh. First install debug symbols:
|
||||
|
||||
....
|
||||
$ sudo dnf debuginfo-install `rpm -q gnome-shell`
|
||||
....
|
||||
|
||||
Then attach gdb debugger to your gnome-shell process:
|
||||
|
||||
....
|
||||
$ gdb -p `pgrep -U $(id -un) -x gnome-shell`
|
||||
...
|
||||
(gdb) set logging on
|
||||
(gdb) thread apply all backtrace full
|
||||
... press Enter until the whole backtrace is displayed ...
|
||||
(gdb) quit
|
||||
....
|
||||
|
||||
You should have the backtrace saved in `gdb.txt` file.
|
||||
|
||||
[[debugging-mutter]]
|
||||
Debugging mutter
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
You can debug mutter (used in gnome-shell) by setting its
|
||||
https://developer.gnome.org/meta/stable/running-mutter.html[environment
|
||||
variables]. These need to be set prior to run gnome-shell, so if you
|
||||
want to log into GNOME from GDM, you need to create a wrapper script
|
||||
called from a desktop file in `/usr/share/wayland-sessions`.
|
||||
|
||||
*FIXME: Putting the wrapper script and desktop file here would be
|
||||
helpful.*
|
||||
|
||||
[[known-issues-frequent-complaints-fundamental-changes]]
|
||||
Known issues, frequent complaints, fundamental changes
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Here we will list high-profile issues which are known to be broken, not
|
||||
yet implemented, or intentionally behaving differently from regular X11
|
||||
apps. Also please look at link:Wayland_features[Wayland features] which
|
||||
lists all current missing or in-progress features and their details.
|
||||
|
||||
To see all known issues, look at Bugzilla reports as mentioned in
|
||||
link:#Looking_for_similar_reports[Looking for similar reports].
|
||||
|
||||
[[graphical-applications-cant-be-run-as-root-from-terminal]]
|
||||
Graphical applications can't be run as root from terminal
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
It is not possible to start graphical apps under the root account from
|
||||
terminal when using `su` or `sudo`. Apps which use polkit to request
|
||||
administrator permissions for just certain operations and only when
|
||||
needed are not affected (they are not started as root right away). The
|
||||
discussion is ongoing about the best approach to take, see
|
||||
https://bugzilla.redhat.com/show_bug.cgi?id=1274451[bug 1274451] and
|
||||
https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.org/thread/A6VXI4WAGSIIWGOTAVNDBVS4VFYXITHA/#2YU2RBYCXQSCGHGP772W5LRXUMTSINHA["On
|
||||
running gui applications as root" thread in fedora-devel mailing list].
|
||||
|
||||
[[many-well-known-x11-utilities-dont-work]]
|
||||
Many well-known X11 utilities don't work
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Power users are familiar with a large range of X11-related utilities,
|
||||
like `xkill`, `xrandr`, `xdotool`, `xsel`. These tools won't work under
|
||||
Wayland session, or will only work with XWayland applications but not
|
||||
Wayland applications. Some tools might have a replacement which allows
|
||||
to perform similar tasks.
|
||||
|
||||
*FIXME: add some Wayland-ready replacements for popular X11 tools*
|
||||
|
||||
[[games-and-other-apps-cant-change-monitor-resolution]]
|
||||
Games and other apps can't change monitor resolution
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
It is no longer possible for an app to change monitor resolution.
|
||||
Usually this was done by games to increase performance. Wayland-based
|
||||
games will use a different approach - scaling its output. But for X11
|
||||
games (running through XWayland) this solution is not available. This
|
||||
results in a number of different types of behavior, based on how the
|
||||
game is written - the game might be fixed in the desktop resolution, or
|
||||
rendered as a small centered image with black bars around it, or crash
|
||||
on startup, or something different. See
|
||||
https://bugzilla.redhat.com/show_bug.cgi?id=1289714[bug 1289714].
|
||||
|
||||
For some games, a possible workaround is to manually set custom monitor
|
||||
resolution before running the game, if you really need it. It will not
|
||||
help always, though.
|
||||
|
||||
[[screen-capture-is-not-available-with-usual-apps]]
|
||||
Screen capture is not available with usual apps
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
One of the features of Wayland is its security design, which helps to
|
||||
guard the user against malicious apps. Apps can no longer see everything
|
||||
on the screen and spy on you. But that also means you cannot run a
|
||||
common application (like or ) and use it to make a screenshot or a
|
||||
screencast of your desktop - it will see only its own window, but
|
||||
nothing else (or it might crash right away). System (trusted) apps need
|
||||
to be used to perform these actions.
|
||||
|
||||
In GNOME, you can use Screenshot tool (available in overview or as
|
||||
`Printscreen` hotkey or as `gnome-screenshot` command) to capture a
|
||||
screenshot of the full desktop or a particular window. You can press
|
||||
`Ctrl+Alt+Shift+R` keyboard shortcut to start video recording of the
|
||||
whole desktop (stop it by pressing the same shortcut again, there's an
|
||||
indicator in the upper right corner, or it stops automatically after 30
|
||||
seconds by default) and find the screencast in `~/Videos`. For
|
||||
screencast, you can also use
|
||||
https://extensions.gnome.org/extension/690/easyscreencast/[EasyScreenCast]
|
||||
gnome-shell extension.
|
||||
|
||||
[[mouse-pointer-is-laggingstuttering-under-load]]
|
||||
Mouse pointer is lagging/stuttering under load
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If your computer is under load, your mouse pointer movement might stop
|
||||
being fluent, but start lagging (get stuck in a place for a short time,
|
||||
then jump to a different place instantly). This is probably more
|
||||
noticeable on slow systems/systems with fewer CPU cores. See
|
||||
https://bugzilla.gnome.org/show_bug.cgi?id=745032[bug 745032].
|
||||
|
||||
[[keyboard-events-are-sometimes-quickly-repeated]]
|
||||
Keyboard events are sometimes quickly repeated
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
There is a rare issue when you press a key to type a letter and you'll
|
||||
see multiple copies of the letter typed in. See
|
||||
https://bugzilla.gnome.org/show_bug.cgi?id=757942[bug 757942] and
|
||||
https://bugzilla.gnome.org/show_bug.cgi?id=777693[bug 777693].
|
||||
|
||||
[[not-all-keys-can-be-sent-to-a-remote-desktop-or-a-virtual-machine]]
|
||||
Not all keys can be sent to a remote desktop or a virtual machine
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Some applications forward all input, including system-specific
|
||||
keys/shortcuts like or , to a remote system. This is mostly remote
|
||||
desktop viewers like _vncviewer_ or virtual machine managers like
|
||||
_virt-manager_ or _boxes_. Under Wayland, some of these shortcuts can't
|
||||
be intercepted, and therefore are used in the host system, not the
|
||||
remote/guest system. See
|
||||
https://bugzilla.redhat.com/show_bug.cgi?id=1285770[bug 1285770].
|
||||
|
||||
Category:Debugging[W] Category:How_to[Category:How to] Category:Wayland
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
377
en-US/dnf-system-upgrade.adoc
Normal file
377
en-US/dnf-system-upgrade.adoc
Normal file
|
|
@ -0,0 +1,377 @@
|
|||
= DNF system upgrade
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/DNF_system_upgrade
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
[[what-is-dnf-system-upgrade]]
|
||||
What is DNF system upgrade?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
https://github.com/rpm-software-management/dnf-plugin-system-upgrade[dnf-plugin-system-upgrade]
|
||||
is a plugin for the link:Dnf[dnf] package manager which handles system
|
||||
upgrades. It is the recommended command line upgrade method for Fedora
|
||||
21 and later (Except Atomic Host, which uses rpm-ostree; for that see
|
||||
Atomic_Host_upgrade).
|
||||
|
||||
[[what-does-dnf-system-upgrade-do]]
|
||||
What does DNF system upgrade do?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
DNF system upgrade can upgrade your system to a newer release of Fedora,
|
||||
using a mechanism similar to that used for offline package updates. The
|
||||
updated packages are downloaded while the system is running normally,
|
||||
then the system reboots to a special environment (implemented as a
|
||||
systemd target) to install them. Once installation of the updated
|
||||
packages is complete, the system reboots again to the new Fedora
|
||||
release.
|
||||
|
||||
[[how-do-i-use-it]]
|
||||
How do I use it?
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
1. *Back up* your important data. Every system change is potentially
|
||||
risky, be prepared. In case you update your workstation, it is also wise
|
||||
to download a https://getfedora.org/en/workstation/[Workstation Live
|
||||
image] and make sure your hardware (graphics card, wifi, etc) works well
|
||||
with the latest kernel and drivers.
|
||||
2. Update your system using the standard updater for your desktop or :
|
||||
+
|
||||
....
|
||||
$ sudo dnf upgrade --refresh
|
||||
....
|
||||
+
|
||||
(Don't type the `$` in these commands; that just indicates that you type
|
||||
this at a terminal prompt as a non-root user.)
|
||||
+
|
||||
After updating, we recommend you reboot your computer, especially if
|
||||
you've just installed a new kernel. +
|
||||
* Please note that there is
|
||||
link:Common_F23_bugs#plymouth-theme-upgrade[an issue] if you use a
|
||||
non-default plymouth boot theme. If you do, please follow the issue
|
||||
description to make sure your upgrade will not be affected.
|
||||
* Double check your DNF configuration in , if you have done any custom
|
||||
configuration (either manually or via third-party tool), it's
|
||||
recommended to revert it to default before updating and upgrading your
|
||||
system.
|
||||
3. Install package:
|
||||
+
|
||||
....
|
||||
$ sudo dnf install dnf-plugin-system-upgrade
|
||||
....
|
||||
4. Download the updated packages: \{\{#tag:pre|$ sudo dnf
|
||||
system-upgrade download --refresh --releasever=}} Change the
|
||||
`--releasever=` number if you want to upgrade to a different system
|
||||
release. Most people will want to upgrade to the latest stable release,
|
||||
which is **, but if you're running Fedora , you might want to upgrade
|
||||
just to Fedora . You can also use for upgrading to Branched or `rawhide`
|
||||
for upgrading to Rawhide (warning: those are not stable releases).
|
||||
* If you are upgrading to Rawhide, you will need to import the rpm gpg
|
||||
key for it. This will be the highest numbered key version in . For
|
||||
example if there is a Branched release that is , then you should look
|
||||
for a , and if there is currently no Branched release, it will be .
|
||||
\{\{#tag:pre|$ sudo rpm --import
|
||||
/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora--primary}}
|
||||
5. If some of your packages have unsatisfied dependencies, the upgrade
|
||||
will refuse to continue until you run it again with an extra option.
|
||||
This often happens with packages installed from third-party repositories
|
||||
for which an updated repositories hasn't been yet published. Please
|
||||
study the output very carefully and examine which packages are going to
|
||||
be removed. None of them should be essential for system functionality,
|
||||
but some of them might be important for your productivity.
|
||||
* In case of unsatisfied dependencies, you can sometimes see more
|
||||
details if you add option to the command line.
|
||||
* If you want to remove/install some packages manually before running
|
||||
`dnf system-upgrade download` again, it's advisable to perform those
|
||||
operations with `--setopt=keepcache=1` dnf command line option.
|
||||
Otherwise the whole package cache will be removed after your operation,
|
||||
and you'll need to download all the packages once again.
|
||||
6. Trigger the upgrade process:
|
||||
+
|
||||
....
|
||||
$ sudo dnf system-upgrade reboot
|
||||
....
|
||||
+
|
||||
This will reboot your machine immediately. The system should boot again
|
||||
into Fedora using the same kernel, but this time, the upgrade process
|
||||
appears on the boot screen.
|
||||
7. Wait for the upgrade process to complete.
|
||||
|
||||
[[frequently-asked-questions]]
|
||||
Frequently Asked Questions
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
[[how-do-i-report-issues-that-i-find-with-upgrades]]
|
||||
How do I report issues that I find with upgrades?
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
First see link:Common_F{{FedoraVersionNumber}}_bugs[Common
|
||||
F\{\{FedoraVersionNumber}} bugs] or
|
||||
link:Common_F{{FedoraVersionNumber[next}} bugs] to check if the problem
|
||||
is a very prominent issue we already know of. If it is not there,
|
||||
https://bugzilla.redhat.com/buglist.cgi?product=Fedora&component=dnf-plugin-system-upgrade&resolution=---[search
|
||||
for an existing bug report]. If you do not see a report that matches
|
||||
your symptoms, you can file a new report from the search page. Please
|
||||
follow the bug reporting instructions mentioned in
|
||||
https://github.com/rpm-software-management/dnf-plugin-system-upgrade[this
|
||||
README] and in `man dnf.plugin.system-upgrade`.
|
||||
|
||||
If you hit issues after upgrade with a specific package, file a bug
|
||||
against the package with which you are having issues.
|
||||
|
||||
[[does-dnf-system-upgrade-verify-the-software-it-runs-or-installs-during-upgrade]]
|
||||
Does DNF system upgrade verify the software it runs or installs during
|
||||
upgrade?
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Yes. The package signing keys for newer Fedora releases are sent to
|
||||
older Fedora releases in order to allow DNF to verify the integrity of
|
||||
the packages it downloads. You can disable this function with the
|
||||
parameter if you need to do so for any reason (not recommended, you're
|
||||
then opened to attacks from malicious software).
|
||||
|
||||
[[will-packages-in-third-party-repositories-be-upgraded]]
|
||||
Will packages in third party repositories be upgraded?
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Yes, if they are set up like regular DNF repositories and do not hard
|
||||
code the repository path. Commonly-used third party repositories usually
|
||||
work fine, but if you attempt to upgrade prior to or soon after an
|
||||
official Fedora release, they may not have updated their repository
|
||||
paths yet, and DNF may be unable to find their packages. This will
|
||||
usually not prevent the upgrade running successfully, though, and you
|
||||
can update the packages from the third-party repository later.
|
||||
|
||||
[[can-i-upgrade-from-an-end-of-life-release]]
|
||||
Can I upgrade from an link:End_of_life[End of life] release?
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Note that Fedora strongly recommends against ever running an end-of-life
|
||||
release on any production system, or any system connected to the public
|
||||
internet, in any circumstances. You should never allow a production
|
||||
Fedora deployment to reach end-of-life in the first place.
|
||||
|
||||
With that in mind, if you do have an end-of-life release newer than
|
||||
Fedora 20 installed on a system you cannot just discard or re-deploy,
|
||||
you can attempt to upgrade it, though this is a less-tested and
|
||||
less-supported operation. You can try to upgrade through intermediate
|
||||
releases until you reach a currently-supported release, or try to
|
||||
upgrade to a currently-supported release in a single operation. It is
|
||||
not possible to state with certainty which approach is more likely to be
|
||||
successful.
|
||||
|
||||
If you attempt to upgrade across more than two releases in one
|
||||
operation, please also read the link:#multi[next answer].
|
||||
|
||||
If you have Fedora 20 or earlier installed, you cannot upgrade with DNF
|
||||
system upgrade alone. You must upgrade at least part of the way
|
||||
link:Upgrading_Fedora_using_package_manager[using bare or ]. You can
|
||||
either upgrade to Fedora 21 that way and then upgrade the rest of the
|
||||
way using DNF system upgrade, or you can attempt the entire upgrade
|
||||
using bare or . Note this method is in itself not an officially
|
||||
recommended upgrade mechanism. To be frank, any upgrade from Fedora 20
|
||||
or earlier is very much done 'at your own risk'.
|
||||
|
||||
[[how-many-releases-can-i-upgrade-across-at-once]]
|
||||
How many releases can I upgrade across at once?
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The most common scenario is an upgrade across just one release (e.g. to
|
||||
). However, for the first month or so after a new release comes out,
|
||||
upgrades from the last-but-one release to that release are 'supported',
|
||||
in the sense that we include this scenario in the
|
||||
link:Fedora_Release_Criteria[Fedora Release Criteria], test it for at
|
||||
least clean installs of supported package sets, and will treat bugs
|
||||
discovered in such upgrades as significant. The
|
||||
link:Fedora_Release_Life_Cycle[Fedora Release Life Cycle] is
|
||||
specifically designed to provide this approximate one month 'grace
|
||||
period' so you can choose to upgrade long-lived systems only once every
|
||||
two releases, rather than having to do it every release.
|
||||
|
||||
Around a month after the new release comes out, the last-but-one release
|
||||
goes link:End_of_life[End of life], at which point the
|
||||
link:#eol[previous question] applies. Still, that upgrade is still
|
||||
pretty likely to work successfully for some time after the release goes
|
||||
end-of-life.
|
||||
|
||||
Upgrades across more than two releases are not 'supported', and issues
|
||||
encountered in such upgrades may not be considered significant bugs.
|
||||
Note that any upgrade across more than two releases must by definition
|
||||
be an upgrade from an end-of-life release, and so the link:#eol[previous
|
||||
question] applies here too.
|
||||
|
||||
When upgrading across multiple releases, you may find you need to
|
||||
link:Upgrading_Fedora_using_package_manager#packagekey[import the target
|
||||
release package signing key manually]. Fedora releases usually only have
|
||||
the package signing keys for the next two releases installed (because
|
||||
they go end-of-life before the N+3 release is branched). Before Fedora
|
||||
22, it was not consistently the case that every release had keys for the
|
||||
next two releases, either. If dnf complains about a missing key, this is
|
||||
what you must do.
|
||||
|
||||
[[can-i-use-dnf-system-upgrade-to-upgrade-to-a-pre-release-e.g.-a-beta]]
|
||||
Can I use DNF system upgrade to upgrade to a pre-release (e.g. a Beta)?
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Yes. It should always be possible to attempt such an upgrade. Of course,
|
||||
this function is as subject to temporary breakage as is any other aspect
|
||||
of a pre-release, and generally speaking, the earlier the release in
|
||||
question, the less likely it is to work without problems.
|
||||
|
||||
[[optional-post-upgrade-tasks]]
|
||||
Optional post-upgrade tasks
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
These are tasks you can do after a successful upgrade. *They are mostly
|
||||
intended for power users. If you are a general user who doesn't use
|
||||
terminal daily, you don't need to worry about this.*
|
||||
|
||||
[[update-system-configuration-files]]
|
||||
Update system configuration files
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Most configuration files are stored in `/etc`. If there are any updates
|
||||
to them and you touched some of those files before, RPM creates new
|
||||
files with either `.rpmnew` suffix (the new default config file), or
|
||||
`.rpmsave` suffix (your old config file backed up). You can search for
|
||||
these files, go through the changes and make sure your custom changes
|
||||
are still included and the new defaults are applied as well. A tool that
|
||||
tried to simplify this is . Install the package, and then use it as:
|
||||
|
||||
`$ sudo rpmconf -a`
|
||||
|
||||
See more information in its manual page.
|
||||
|
||||
[[clean-up-old-packages]]
|
||||
Clean up old packages
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
You can see list of packages with broken dependencies like this:
|
||||
|
||||
`$ sudo dnf repoquery --unsatisfied`
|
||||
|
||||
Ideally there should be none. If there are some, consider removing them,
|
||||
because they are not likely to work properly anyway.
|
||||
|
||||
You can see duplicated packages (packages with multiple versions
|
||||
installed) like this:
|
||||
|
||||
`$ sudo dnf repoquery --duplicated`
|
||||
|
||||
For ordinary packages, just the latest version should be installed. But
|
||||
there can be exceptions to the rule, only remove what you are sure you
|
||||
no longer need.
|
||||
|
||||
Some packages might stay on your system while they have been removed
|
||||
from the repositories. See them using:
|
||||
|
||||
`$ sudo dnf list extras`
|
||||
|
||||
If you don't use these, you can consider removing them:
|
||||
`dnf remove $(dnf repoquery --extras --exclude=kernel,kernel-\*)`.
|
||||
Please note that this list is only valid if you have a fully updated
|
||||
system. Otherwise you'll see all installed packages which are no longer
|
||||
in the repositories, because there is a newer update available. So
|
||||
before acting on these, make sure you have run `sudo dnf update` and
|
||||
generate the list of extra packages again. Also, this list might contain
|
||||
packages installed from third-party repositories for which an updated
|
||||
repository hasn't been published yet. This often involves e.g. RPM
|
||||
Fusion or Dropbox.
|
||||
|
||||
You can remove no-longer-needed packages using:
|
||||
|
||||
`$ sudo dnf autoremove`
|
||||
|
||||
but *beware* that dnf decides that a package is no longer needed if you
|
||||
haven't explicitly asked to install it and nothing else requires it.
|
||||
That doesn't mean that package is not useful or that you don't use it.
|
||||
*Only remove what you are certain you don't need*. There's a known bug
|
||||
in PackageKit which doesn't mark packages as user-installed, see
|
||||
https://bugzilla.redhat.com/show_bug.cgi?id=1259865[bug 1259865]. If you
|
||||
use PackageKit (or GNOME Software, Apper, etc) for installation, this
|
||||
output might list even important apps and system packages, so beware.
|
||||
|
||||
[[resolving-post-upgrade-issues]]
|
||||
Resolving post-upgrade issues
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
*Only follow up these steps if you have troubles with your upgraded
|
||||
system. It should not be needed in the vast majority of upgrades.*
|
||||
|
||||
[[rebuilding-rpm-database]]
|
||||
Rebuilding RPM database
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If you see warnings when working with RPM/DNF tools, your database might
|
||||
have gotten corrupted for some reason. It is possible to rebuild it and
|
||||
see if resolves your issues. Always back up `/var/lib/rpm/` first. To
|
||||
rebuild the database, run:
|
||||
|
||||
`$ sudo rpm --rebuilddb`
|
||||
|
||||
[[using-distro-sync-to-resolve-dependency-issues]]
|
||||
Using distro-sync to resolve dependency issues
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The system upgrade tool uses distro-sync method by default. If your
|
||||
system stayed partly unupgraded or you see some package dependency
|
||||
issues, you might try to fix it by running another distro-sync manually.
|
||||
This tries to make your installed packages exactly the same version as
|
||||
in currently enabled repositories, even if it meant downgrading some
|
||||
packages:
|
||||
|
||||
`$ sudo dnf distro-sync`
|
||||
|
||||
A stronger variant also allows to remove package for which package
|
||||
dependencies can't be satisfied. Always carefully review which packages
|
||||
are going to be removed before confirming this:
|
||||
|
||||
`$ sudo dnf distro-sync --allowerasing`
|
||||
|
||||
[[relabel-files-with-latest-selinux-policy]]
|
||||
Relabel files with latest SELinux policy
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If you see warnings that some actions were not allowed because of
|
||||
current SELinux policy, it might be a case of having some files
|
||||
incorrectly label with SELinux permissions. This might happen in case of
|
||||
some bug or if you had SELinux disabled in some point of time in the
|
||||
past. You can relabel the whole system by running:
|
||||
|
||||
`$ sudo touch /.autorelabel`
|
||||
|
||||
and rebooting. The next boot will take a long time and will check and
|
||||
fix all SELinux labels on all your files.
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
203
en-US/dnf.adoc
Normal file
203
en-US/dnf.adoc
Normal file
|
|
@ -0,0 +1,203 @@
|
|||
= DNF
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/DNF
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
*DNF* is a software package manager that installs, updates, and removes
|
||||
link:package[packages] on RPM-based Linux distributions. It
|
||||
automatically computes dependencies and determines the actions required
|
||||
to install packages. DNF also makes it easier to maintain groups of
|
||||
machines, eliminating the need to manually update each one using rpm.
|
||||
Introduced in Fedora 18, it has been the default package manager since
|
||||
Fedora 22.
|
||||
|
||||
DNF or Dandified yum is the next generation version of yum. It roughly
|
||||
maintains CLI compatibility with yum and defines a strict API for
|
||||
extensions and plugins. Plugins can modify or extend features of DNF or
|
||||
provide additional CLI commands on top of those mentioned below. If you
|
||||
know the name of such a command (including commands mentioned bellow),
|
||||
you may find/install the package which provides it using the appropriate
|
||||
virtual provide in the form of dnf-command() where is the name of the
|
||||
command; e.g. dnf-command(repoquery) for a repoquery command (the same
|
||||
applies to specifying dependencies of packages that require a particular
|
||||
command).
|
||||
|
||||
[[features]]
|
||||
Features
|
||||
~~~~~~~~
|
||||
|
||||
* Support for multiple repositories
|
||||
* Simple configuration
|
||||
* Dependency calculation based on modern depsolving technology
|
||||
* Faster and less memory-intensive operation
|
||||
* RPM-consistent behavior
|
||||
* Package group support, including multiple-repository groups
|
||||
* Simple interface
|
||||
* Documented, solid Python API
|
||||
* DNF runs in both Python 2 and Python 3
|
||||
* C bindings for lower level libraries:
|
||||
** hawkey for package querying and depsolving. PackageKit is already
|
||||
making use of hawkey
|
||||
** librepo for repo operations. PackageKit is already making use of
|
||||
librepo
|
||||
** libcomps for comps operations
|
||||
|
||||
[[available-commands]]
|
||||
Available commands
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
autoremove
|
||||
|
||||
check-update
|
||||
|
||||
clean
|
||||
|
||||
distro-sync
|
||||
|
||||
downgrade
|
||||
|
||||
group
|
||||
|
||||
help
|
||||
|
||||
history
|
||||
|
||||
info
|
||||
|
||||
install
|
||||
|
||||
list
|
||||
|
||||
makecache
|
||||
|
||||
mark
|
||||
|
||||
provides
|
||||
|
||||
reinstall
|
||||
|
||||
remove
|
||||
|
||||
repolist
|
||||
|
||||
repository-packages
|
||||
|
||||
search
|
||||
|
||||
updateinfo
|
||||
|
||||
upgrade
|
||||
|
||||
upgrade-to
|
||||
|
||||
[[installation]]
|
||||
Installation
|
||||
~~~~~~~~~~~~
|
||||
|
||||
DNF comes with Fedora since version 18, but DNF can installed by using
|
||||
the yum Command:
|
||||
|
||||
....
|
||||
# yum install dnf
|
||||
....
|
||||
|
||||
As of Fedora 22, yum has been replaced with DNF and doesn't need to be
|
||||
install.
|
||||
|
||||
[[usage]]
|
||||
Usage
|
||||
~~~~~
|
||||
|
||||
In the basic methods, DNF can be used almost exactly as yum to search,
|
||||
install or remove packages:
|
||||
|
||||
....
|
||||
# dnf search audacity
|
||||
....
|
||||
|
||||
....
|
||||
# dnf install audacity
|
||||
....
|
||||
|
||||
....
|
||||
# dnf remove audacity
|
||||
....
|
||||
|
||||
[[automatic-updates]]
|
||||
Automatic Updates
|
||||
^^^^^^^^^^^^^^^^^
|
||||
|
||||
The DNF-Automatic RPM package as a DNF component provides a service for
|
||||
automatic download and installation of updates. It can automatically
|
||||
monitor and report via email availability of updates, or send a log
|
||||
about downloaded packages and installed updates. See AutoUpdates section
|
||||
or http://dnf.readthedocs.org/en/latest/automatic.html[DNF-Automatic]
|
||||
page.
|
||||
|
||||
[[system-upgrades]]
|
||||
System Upgrades
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
Fedora Products can be upgraded with DNF system upgrade plugin or
|
||||
directly with DNF. See Upgrade section.
|
||||
|
||||
[[language-support-using-dnf]]
|
||||
Language Support Using Dnf
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
DNF can be used to install or remove Language Support. A detailed
|
||||
description with a list of available languages can be found on
|
||||
https://fedoraproject.org/wiki/I18N/Language_Support_Using_Dnf[Language
|
||||
Support Using Dnf] page.
|
||||
|
||||
[[documentation]]
|
||||
Documentation
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
\1. http://dnf.readthedocs.org/[Documentation Index]
|
||||
|
||||
\2. http://dnf.readthedocs.org/en/latest/command_ref.html[Command
|
||||
Reference]
|
||||
|
||||
\3. http://dnf.baseurl.org/[DNF blog]
|
||||
|
||||
\4. https://github.com/rpm-software-management/dnf/wiki[DNF wiki]
|
||||
|
||||
\5. Changes/DNF-2.0
|
||||
|
||||
Category:Documentation Category:Software_Management[Category:Software
|
||||
Management]
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
523
en-US/edit-iptables-rules.adoc
Normal file
523
en-US/edit-iptables-rules.adoc
Normal file
|
|
@ -0,0 +1,523 @@
|
|||
= How to edit iptables rules
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/How_to_edit_iptables_rules
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
In this how-to, we will illustrate three ways to edit iptables Rules :
|
||||
|
||||
* *CLI :* iptables command line interface and system configuration file
|
||||
/etc/sysconfig/iptables.
|
||||
* *TUI (text-based) interface :* setup or system-config-firewall-tui
|
||||
* *GUI :* system-config-firewall
|
||||
|
||||
NOTE: This how-to illustrates editing existing iptables Rules, not the
|
||||
initial creation of Rules chains.
|
||||
|
||||
__TOC__
|
||||
|
||||
[[cli-command-line-interface]]
|
||||
CLI (command line interface)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
[[hot-changes-to-iptables-rules]]
|
||||
Hot changes to iptables Rules
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The following procedures allow changes in the behaviour of the firewall
|
||||
while it is running.
|
||||
|
||||
Read the man pages for iptables (man iptables) for further explanations
|
||||
and more sophisticated Rules examples.
|
||||
|
||||
[[listing-rules]]
|
||||
Listing Rules
|
||||
+++++++++++++
|
||||
|
||||
Current running iptables Rules can be viewed with the command
|
||||
|
||||
....
|
||||
iptables -L
|
||||
....
|
||||
|
||||
.
|
||||
|
||||
Example of iptables Rules allowing any connections already established
|
||||
or related, icmp requests, all local traffic, and ssh communication:
|
||||
|
||||
....
|
||||
[root@server ~]# iptables -L
|
||||
Chain INPUT (policy DROP)
|
||||
target prot opt source destination
|
||||
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
|
||||
ACCEPT icmp -- anywhere anywhere
|
||||
ACCEPT all -- anywhere anywhere
|
||||
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
|
||||
|
||||
Chain FORWARD (policy ACCEPT)
|
||||
target prot opt source destination
|
||||
|
||||
Chain OUTPUT (policy ACCEPT)
|
||||
target prot opt source destination
|
||||
....
|
||||
|
||||
Note that Rules are applied in order of appearance, and the inspection
|
||||
ends immediately when there is a match. Therefore, for example, if a
|
||||
Rule rejecting ssh connections is created, and afterward another Rule is
|
||||
specified allowing ssh, the Rule to reject is applied and the later Rule
|
||||
to accept the ssh connection is not.
|
||||
|
||||
[[appending-rules]]
|
||||
Appending Rules
|
||||
+++++++++++++++
|
||||
|
||||
The following adds a Rule at the end of the specified chain of iptables:
|
||||
|
||||
....
|
||||
[root@server ~]# iptables -A INPUT -p tcp --dport 80 -j ACCEPT
|
||||
[root@server ~]# iptables -L
|
||||
Chain INPUT (policy DROP)
|
||||
target prot opt source destination
|
||||
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
|
||||
ACCEPT icmp -- anywhere anywhere
|
||||
ACCEPT all -- anywhere anywhere
|
||||
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
|
||||
ACCEPT tcp -- anywhere anywhere tcp dpt:http
|
||||
|
||||
Chain FORWARD (policy ACCEPT)
|
||||
target prot opt source destination
|
||||
|
||||
Chain OUTPUT (policy ACCEPT)
|
||||
target prot opt source destination
|
||||
....
|
||||
|
||||
Notice the last line in chain INPUT. There are now five Rules in that
|
||||
chain.
|
||||
|
||||
[[deleting-rules]]
|
||||
Deleting Rules
|
||||
++++++++++++++
|
||||
|
||||
To delete a Rule, you must know its position in the chain. The following
|
||||
example deletes an existing Rule created earlier that is currently in
|
||||
the fifth position:
|
||||
|
||||
....
|
||||
[root@server ~]# iptables -D INPUT 5
|
||||
[root@server ~]# iptables -L
|
||||
Chain INPUT (policy DROP)
|
||||
target prot opt source destination
|
||||
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
|
||||
ACCEPT icmp -- anywhere anywhere
|
||||
ACCEPT all -- anywhere anywhere
|
||||
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
|
||||
|
||||
Chain FORWARD (policy ACCEPT)
|
||||
target prot opt source destination
|
||||
|
||||
Chain OUTPUT (policy ACCEPT)
|
||||
target prot opt source destination
|
||||
....
|
||||
|
||||
[[inserting-rules]]
|
||||
Inserting Rules
|
||||
+++++++++++++++
|
||||
|
||||
Create a Rule at the top (first) position:
|
||||
|
||||
....
|
||||
[root@server ~]# iptables -I INPUT 1 -p tcp --dport 80 -j ACCEPT
|
||||
[root@server ~]# iptables -L
|
||||
Chain INPUT (policy DROP)
|
||||
target prot opt source destination
|
||||
ACCEPT tcp -- anywhere anywhere tcp dpt:http
|
||||
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
|
||||
ACCEPT icmp -- anywhere anywhere
|
||||
ACCEPT all -- anywhere anywhere
|
||||
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
|
||||
|
||||
Chain FORWARD (policy ACCEPT)
|
||||
target prot opt source destination
|
||||
|
||||
Chain OUTPUT (policy ACCEPT)
|
||||
target prot opt source destination
|
||||
....
|
||||
|
||||
The number given after the chain name indicates the position *before* an
|
||||
existing Rule. So, for example, if you want to insert a Rule *before*
|
||||
the third rule you specify the number 3. Afterward, the existing Rule
|
||||
will then be in the fourth position in the chain.
|
||||
|
||||
[[replacing-rules]]
|
||||
Replacing Rules
|
||||
+++++++++++++++
|
||||
|
||||
Rules may be specified to replace existing Rules in the chain.
|
||||
|
||||
In the example shown previously, the first Rule given allows connections
|
||||
to the http port (port 80) from anywhere. The following replaces this
|
||||
Rule, restricting connections to the standard http port (port 80) only
|
||||
from the network address range 192.168.0.0/24:
|
||||
|
||||
....
|
||||
[root@server ~]# iptables -R INPUT 1 -p tcp -s 192.168.0.0/24 --dport 80 -j ACCEPT
|
||||
[root@server ~]# iptables -L
|
||||
Chain INPUT (policy DROP)
|
||||
target prot opt source destination
|
||||
ACCEPT tcp -- 192.168.0.0/24 anywhere tcp dpt:http
|
||||
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
|
||||
ACCEPT icmp -- anywhere anywhere
|
||||
ACCEPT all -- anywhere anywhere
|
||||
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
|
||||
|
||||
Chain FORWARD (policy ACCEPT)
|
||||
target prot opt source destination
|
||||
|
||||
Chain OUTPUT (policy ACCEPT)
|
||||
target prot opt source destination
|
||||
....
|
||||
|
||||
[[flushing-rules]]
|
||||
Flushing Rules
|
||||
++++++++++++++
|
||||
|
||||
To flush or clear iptables Rules, use the *--flush*, *-F* option :
|
||||
|
||||
....
|
||||
iptables -F <chain>
|
||||
....
|
||||
|
||||
Specifying a ** is optional; without a chain specification, all chains
|
||||
are flushed.
|
||||
|
||||
Example to flush Rules in the *OUTPUT* chain :
|
||||
|
||||
....
|
||||
[root@server ~]# iptables -F OUTPUT
|
||||
....
|
||||
|
||||
[[making-changes-persistent]]
|
||||
Making changes persistent
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The iptables Rules changes using CLI commands will be lost upon system
|
||||
reboot. However, iptables comes with two useful utilities:
|
||||
*iptables-save* and *iptables-restore*.
|
||||
|
||||
* *iptables-save* prints a dump of current iptables rules to *stdout*.
|
||||
These may be redirected to a file:
|
||||
|
||||
....
|
||||
[root@server ~]# iptables-save > iptables.dump
|
||||
[root@server ~]# cat iptables.dump
|
||||
# Generated by iptables-save v1.4.12 on Wed Dec 7 20:10:49 2011
|
||||
*filter
|
||||
:INPUT DROP [45:2307]
|
||||
:FORWARD ACCEPT [0:0]
|
||||
:OUTPUT ACCEPT [1571:4260654]
|
||||
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
|
||||
-A INPUT -p icmp -j ACCEPT
|
||||
-A INPUT -i lo -j ACCEPT
|
||||
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
|
||||
COMMIT
|
||||
# Completed on Wed Dec 7 20:10:49 2011
|
||||
....
|
||||
|
||||
* iptables-restore : restore a dump of rules made by iptables-save.
|
||||
|
||||
....
|
||||
[root@server ~]# iptables-restore < iptables.dump
|
||||
[root@server ~]# iptables -L
|
||||
Chain INPUT (policy DROP)
|
||||
target prot opt source destination
|
||||
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
|
||||
ACCEPT icmp -- anywhere anywhere
|
||||
ACCEPT all -- anywhere anywhere
|
||||
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
|
||||
|
||||
Chain FORWARD (policy ACCEPT)
|
||||
target prot opt source destination
|
||||
|
||||
Chain OUTPUT (policy ACCEPT)
|
||||
target prot opt source destination
|
||||
....
|
||||
|
||||
In the default configuration, stopping or restarting the iptables
|
||||
service will discard the running configuration. This behavior can be
|
||||
changed by setting IPTABLES_SAVE_ON_STOP="yes" or
|
||||
IPTABLES_SAVE_ON_RESTART="yes" in /etc/sysconfig/iptables-config. If
|
||||
these values are set, the affected files are:
|
||||
|
||||
* ....
|
||||
/etc/sysconfig/iptables
|
||||
....
|
||||
+
|
||||
for IPv4
|
||||
* ....
|
||||
/etc/sysconfig/ip6tables
|
||||
....
|
||||
+
|
||||
for IPv6
|
||||
|
||||
If preferred, these files may be edited directly, and iptables service
|
||||
restarted to commit the changes. The format is similar to that of the
|
||||
iptables CLI commands:
|
||||
|
||||
....
|
||||
# Generated by iptables-save v1.4.12 on Wed Dec 7 20:22:39 2011
|
||||
*filter <--------------------------------------------------------- Specify the table of the next rules
|
||||
:INPUT DROP [157:36334] <----------------------------------------- This is the three chain belong to filter table, then the policy of the chain
|
||||
:FORWARD ACCEPT [0:0] <------------------------------------------- and between brackets [<packet-counter>:<byte-counter>] numbers is for
|
||||
:OUTPUT ACCEPT [48876:76493439] <--------------------------------- debug/informations purpose only. Leave them at their current value.
|
||||
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT <--------- A rule.
|
||||
-A INPUT -p icmp -j ACCEPT <-------------------------------------- You just have to take all arguments
|
||||
-A INPUT -i lo -j ACCEPT <---------------------------------------- of an iptables command.
|
||||
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
|
||||
COMMIT <---------------------------------------------------------- Needed at each end of table definition. Commit rules in that table.
|
||||
# Completed on Wed Dec 7 20:22:39 2011
|
||||
....
|
||||
|
||||
If needed, to reset packet and byte counters, use *-Z*, *--zero* :
|
||||
|
||||
....
|
||||
iptables -Z <chain> <rule_number>
|
||||
....
|
||||
|
||||
It is possible to reset only reset a single rule counter. It can be
|
||||
useful, if you want to know how many packets were captured for a
|
||||
specific rule.
|
||||
|
||||
[[tui-text-based-user-interface]]
|
||||
TUI (text-based user interface)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
There is two ways to managing iptables rules with a text-based user
|
||||
interface, either using *setup* or *system-config-firewall-tui*. Using
|
||||
*system-config-firewall-tui* takes you directly to editing the rules.
|
||||
Using *setup* you need to select *firewall configuration* and then you
|
||||
can edit rules. Starting with *setup* looks like this:
|
||||
|
||||
image:Firewall-tui.PNG[setup menu
|
||||
utility,title="setup menu utility",width=700]
|
||||
|
||||
On the next screen, which is where you start with
|
||||
*system-config-firewall-tui*, make sure that "Firewall" is enabled, or
|
||||
you cannot edit the settings. Then select *Customize* :
|
||||
|
||||
image:First_menu_firewall_tui.PNG[Firewall Configuration by TUI. First
|
||||
screen.,title="Firewall Configuration by TUI. First screen.",width=700]
|
||||
|
||||
There is good chance that a service you want to modify is part of the
|
||||
list of standard "Trusted" services. Select the services you want to
|
||||
trust (ports to open) and press *Forward* (which means 'next', it is not
|
||||
port forwarding):
|
||||
|
||||
image:Firewall_TUI_Trusted_services..PNG[Editing trusted service with
|
||||
firewall tui
|
||||
interface.,title="Editing trusted service with firewall tui interface.",width=700]
|
||||
|
||||
The Other Ports menu lets you open additional ports not in the list of
|
||||
standard Trusted Services, or to edit an existing list of additional
|
||||
ports :
|
||||
|
||||
image:Firewall_TUI_other_ports.PNG[Editing Other ports on firewall
|
||||
configuration by TUI
|
||||
interface.,title="Editing Other ports on firewall configuration by TUI interface.",width=700]
|
||||
|
||||
To add other ports, specify one port or a port range, and choose between
|
||||
*tcp* or *udp* for the protocol. The port range format is _beginningPort
|
||||
- endingPort_.
|
||||
|
||||
image:Firewall_TUI_adding_other_ports[Adding other ports on firewall
|
||||
configuration by TUI
|
||||
interface.,title="Adding other ports on firewall configuration by TUI interface.",width=700]
|
||||
|
||||
The trusted interfaces menu allows you to trust all traffic on a network
|
||||
interface. All traffic will be allowed and the port filtering rules will
|
||||
never match. You should only select an interface that faces a private
|
||||
network, never an interface that directly faces the Internet.
|
||||
|
||||
image:Firewall_TUI_trusted_interfaces.PNG[Trusted
|
||||
interfaces.,title="Trusted interfaces.",width=700]
|
||||
|
||||
The Masquerading menu lets you select an interface to be masqueraded.
|
||||
Masquerading is better known as
|
||||
*http://en.wikipedia.org/wiki/Network_address_translation[NAT]* (Network
|
||||
Address Translation), and it is useful for example when your computer is
|
||||
used as gateway to access the internet:
|
||||
|
||||
image:Firewall_TUI_masquerading.PNG[Firewall TUI interface :
|
||||
masquerading.,title="Firewall TUI interface : masquerading.",width=700]
|
||||
|
||||
Port forwarding, also known as
|
||||
*http://en.wikipedia.org/wiki/Network_address_translation#Port_address_translation[PAT]*,
|
||||
permits traffic from one port to be rerouted to another port.
|
||||
|
||||
image:Firewall_TUI_Port_Forwarding.PNG[Firewall TUI interface :
|
||||
configuring Port
|
||||
Forwarding.,title="Firewall TUI interface : configuring Port Forwarding.",width=700]
|
||||
|
||||
For example:
|
||||
|
||||
image:Firewall_TUI_Port_Forwarding_Adding.PNG[Firewall TUI : adding port
|
||||
forwarding
|
||||
rules.,title="Firewall TUI : adding port forwarding rules.",width=700]
|
||||
|
||||
The ICMP Filter menu lets you reject various types of ICMP packets. By
|
||||
default, no limitations are made, but you can define rules to reject
|
||||
ICMP traffic, define the return error to an ICMP request, etc.
|
||||
|
||||
image:Firewall_TUI_ICMP_Filter.PNG[Firewall TUI: configuring ICMP
|
||||
behaviour.,title="Firewall TUI: configuring ICMP behaviour.",width=700]
|
||||
|
||||
Finally, you can add custom firewall rules. These must be prepared ahead
|
||||
of time in files that use the same format as the iptables file.
|
||||
|
||||
image:Firewall_TUI_Custom_Rules.PNG[Firewall TUI: create custom
|
||||
rules.,title="Firewall TUI: create custom rules.",width=700]
|
||||
|
||||
For adding custom rules you have specify the protocol between *ipv4* or
|
||||
*ipv6* and on what table add the custom rules *filter*, *mangle* or
|
||||
*nat* then the path to the file containing rules to add :
|
||||
|
||||
image:Firewall_TUI_Custom_Rules_Adding.PNG[Firewall TUI: adding a custom
|
||||
rules.,title="Firewall TUI: adding a custom rules.",width=700]
|
||||
|
||||
When you have completed all menus, *Close* the interface, which brings
|
||||
you back to the first screen of firewall configuration. Select *OK* and
|
||||
a warning message appear :
|
||||
|
||||
image:Firewall_TUI_Warning.PNG[Firewall TUI
|
||||
warning.,title="Firewall TUI warning.",width=700]
|
||||
|
||||
Select *Yes* if the configuration you made fits to you and exit
|
||||
interface, or *No* to go back to the firewall configuration screen.
|
||||
|
||||
[[gui]]
|
||||
GUI
|
||||
~~~
|
||||
|
||||
[[red-hat-gui-configuration-tool]]
|
||||
Red Hat GUI configuration tool
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
GUI interface allow you exactly the same thing that TUI interface, but
|
||||
it is more friendly usable.
|
||||
|
||||
First time you start GUI, you have a welcome message that warning you
|
||||
that if you have existing manual rules then this rules will be
|
||||
overwritten. image:Firewall_GUI_First_Time_Startup.PNG[First time
|
||||
startup message,title="fig:First time startup message"]
|
||||
|
||||
Before all, you need to *Enable* your firewall to use Firewall
|
||||
Configuration utility.
|
||||
|
||||
image:FireWwall_GUI_startup.PNG[Firewall Gui startup
|
||||
screen,title="Firewall Gui startup screen"]
|
||||
|
||||
Then utility warn you that you don't have any existing configuration and
|
||||
want you execute the wizard. Click on *Start wizard*:
|
||||
|
||||
image:No_configuration.PNG[No firewall
|
||||
configuration,title="No firewall configuration"]
|
||||
|
||||
Click on forward :
|
||||
|
||||
image:Firewall_Wizard.PNG[Firewall Wizard : welcome
|
||||
screen,title="Firewall Wizard : welcome screen"]
|
||||
|
||||
_System with network access_ enable Firewall and _System without network
|
||||
access_ disable Firewall, so select _System with network access_ :
|
||||
|
||||
image:Firewall_Wizard_2.PNG[Firewall Wizard : network
|
||||
access?,title="Firewall Wizard : network access?"]
|
||||
|
||||
Beginner allow you to modify only _Trusted Services_, it's fine if you
|
||||
use only known services like ftp, dns, http, etc but don't allow you to
|
||||
configure customs ports range, select _Expert_ to have full featured
|
||||
Firewall Configuration utility, you can change this option later in the
|
||||
*Options* menu Main windows, in *User Skill Level* :
|
||||
|
||||
image:Firewall_Wizard_3.PNG[Firewall Wizard :
|
||||
skill?,title="Firewall Wizard : skill?"]
|
||||
|
||||
*Server* template enable only ssh port on firewall configuration
|
||||
_Desktop_ template enable additional ports for _IPsec_, _Multicast DNS_,
|
||||
_Network Printing Client_ and _SSH_. For convenience select Desktop, and
|
||||
*OK* :
|
||||
|
||||
image:Firewall_Wizard_4.PNG[Firewall Wizard : configuration
|
||||
base?,title="Firewall Wizard : configuration base?"]
|
||||
|
||||
As described earlier _Desktop_ template enable 4 services _IPsec_,
|
||||
_mDNS_, _IPP_ and _SSH_. If you have services listed in *Trusted
|
||||
Services* section that you want to enabled, you just have to click on
|
||||
it, that's all. It is possible to change template by using the *Options*
|
||||
menu, in *Load Default Configuration*.
|
||||
|
||||
image:Firewall_Wizard_5.PNG[Firewall Main interface :
|
||||
enabled,title="Firewall Main interface : enabled"]
|
||||
|
||||
*Other Ports* allow you to edit custom rules if your service port wasn't
|
||||
in *Trusted service*. To begin, just click on *Add* button. Then either
|
||||
you choose in services list the right service or you tick *User Defined*
|
||||
and fill requested information about *Port / Port Range* and *Protocol*.
|
||||
|
||||
image:Firewall_GUI_other_ports.PNG[Firewall GUI : edit other ports
|
||||
rules.,title="Firewall GUI : edit other ports rules."]
|
||||
|
||||
*Trusted Interfaces*, *Masquerading*, *Port Forwarding*, *ICMP Filter*
|
||||
and _Custom Rules_' have exactly the same effect than in TUI interface.
|
||||
|
||||
When configuration fits to you, just click on the *Apply* button.
|
||||
|
||||
[[others-gui]]
|
||||
Others GUI
|
||||
^^^^^^^^^^
|
||||
|
||||
There are others GUI available to configure iptables rules.
|
||||
|
||||
* http://www.fwbuilder.org/_fwbuilder[http://www.fwbuilder.org/
|
||||
fwbuilder] : very complete gui tools to configure iptables.
|
||||
* http://shorewall.net/_Shorewall[http://shorewall.net/ Shorewall] :
|
||||
another very complete gui like fwbuilder.
|
||||
* http://www.turtlefirewall.com/_Turtle_firewall_project[http://www.turtlefirewall.com/
|
||||
Turtle firewall project] : web interface and integrated to webmin. Fits
|
||||
to basic usage of Iptables, can not handle all iptables options like
|
||||
fwbuilder
|
||||
* http://users.telenet.be/stes/ipmenu.html_IPmenu[http://users.telenet.be/stes/ipmenu.html
|
||||
IPmenu] : console based interface that allow you all iptables
|
||||
functionalities.
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
134
en-US/enable-touchpad-click.adoc
Normal file
134
en-US/enable-touchpad-click.adoc
Normal file
|
|
@ -0,0 +1,134 @@
|
|||
= How to enable touchpad click
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/How_to_enable_touchpad_click
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
[[scope]]
|
||||
Scope
|
||||
~~~~~
|
||||
|
||||
Fedora tries to make various desktop environments available to its
|
||||
users. Since Fedora tries to
|
||||
link:Staying_close_to_upstream_projects[stay as close to upstream] as
|
||||
possible, we follow the various defaults selected by the desktop
|
||||
environment upstreams. Generally, this entails a disabled touchpad click
|
||||
by default. This wiki page tries to compile the different methods that
|
||||
can be used to enable "tapping" on various desktop environments.
|
||||
|
||||
*Please note that this is only a resource to aid our users. For
|
||||
discussions on this setting, please talk to the relevant DE upstream.
|
||||
Fedora does not intend to make any changes to upstream defaults.*
|
||||
|
||||
[[desktop-configurations]]
|
||||
Desktop configurations
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This wiki page has more information about
|
||||
link:Input_device_configuration[Input Device configuration]. An example
|
||||
xorg.conf.d snippet to enable tapping is given
|
||||
Input_device_configuration#Example:_Tap-to-click[here].
|
||||
|
||||
[[gnome]]
|
||||
GNOME
|
||||
^^^^^
|
||||
|
||||
The "*mouse and touchpad*" utility can be used to enable tapping and set
|
||||
scrolling options in GNOME.
|
||||
|
||||
http://library.gnome.org/users/gnome-help/stable/mouse-touchpad-click.html.en[Official
|
||||
GNOME documentation]
|
||||
|
||||
[[kde-plasma-workspaces]]
|
||||
KDE Plasma Workspaces
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
1. enter KDE System Settings
|
||||
2. choose Hardware / Input Devices / Touchpad (If it's not there,
|
||||
install kcm_touchpad first, then restart System Settings. It's installed
|
||||
by default.)
|
||||
3. select the Tapping tab
|
||||
4. check the "Enable tapping" checkbox
|
||||
5. set some tapping actions under "Buttons" below, the default is to do
|
||||
nothing
|
||||
|
||||
Alternatively, the systemwide method described under
|
||||
link:#Other_window_managers[Other window managers] can also be used.
|
||||
|
||||
[[xfce]]
|
||||
XFCE
|
||||
^^^^
|
||||
|
||||
1. Enter XFCE Settings
|
||||
2. Select the Mouse and Touchpad settings
|
||||
3. If necessary, select your Touchpad device
|
||||
4. In the General section, enable "Tap touchpad to click"
|
||||
|
||||
[[other-window-managers]]
|
||||
Other window managers
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Create a new file named
|
||||
/etc/X11/xorg.conf.d/99-synaptics-overrides.conf.
|
||||
|
||||
Then, in your favourite text editor, modify this file as such:
|
||||
|
||||
....
|
||||
Section "InputClass"
|
||||
Identifier "touchpad overrides"
|
||||
# This makes this snippet apply to any device with the "synaptics" driver
|
||||
# assigned
|
||||
MatchDriver "synaptics"
|
||||
|
||||
####################################
|
||||
## The lines that you need to add ##
|
||||
# Enable left mouse button by tapping
|
||||
Option "TapButton1" "1"
|
||||
# Enable vertical scrolling
|
||||
Option "VertEdgeScroll" "1"
|
||||
# Enable right mouse button by tapping lower right corner
|
||||
Option "RBCornerButton" "3"
|
||||
####################################
|
||||
|
||||
EndSection
|
||||
....
|
||||
|
||||
For more information on tweaking xorg.conf.d files, please read the man
|
||||
page:
|
||||
|
||||
....
|
||||
man xorg.conf
|
||||
....
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
330
en-US/fedora-life-cycle.adoc
Normal file
330
en-US/fedora-life-cycle.adoc
Normal file
|
|
@ -0,0 +1,330 @@
|
|||
= Fedora Release Life Cycle
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
The Fedora Project releases a new version of Fedora approximately every
|
||||
6 months and provides updated packages (maintenance) to these releases
|
||||
for approximately 13 months. This allows users to "skip a release" while
|
||||
still being able to always have a system that is still receiving
|
||||
updates.
|
||||
|
||||
[[development-schedule]]
|
||||
Development Schedule
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
We say _approximately every 6 months_ because like many things, they
|
||||
don't always go exactly as planned. The schedule is not strictly
|
||||
time-based, but a hybrid of time and quality. The milestone releases are
|
||||
QA:Release_validation_test_plan[tested] for compliance with the
|
||||
link:Fedora_Release_Criteria[Fedora Release Criteria], and releases will
|
||||
be delayed if this is not the case.
|
||||
|
||||
The schedule for the release currently under development, , is on its
|
||||
link:Releases/{{FedoraVersion[|next}}/Schedule| release schedule] page.
|
||||
Alpha, Beta, and General Availability (final) releases happen at 14:00
|
||||
UTC.
|
||||
|
||||
[[development-planning]]
|
||||
Development Planning
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Fedora development planning is handled by the
|
||||
link:Changes/Policy[Release Planning Process]. So-called _Changes_ are
|
||||
proposed, initially reviewed, and monitored through the development
|
||||
process by the link:Fedora_Engineering_Steering_Committee[engineering
|
||||
steering committee].
|
||||
|
||||
[[development-process]]
|
||||
Development Process
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Fedora uses a system involving two 'development' trees.
|
||||
link:Releases/Rawhide[Rawhide] is a constantly rolling development tree.
|
||||
No releases are built directly from Rawhide. 14 weeks before the planned
|
||||
date of a Fedora release, a tree for that release is
|
||||
"link:Releases/Branched[Branched]" from the Rawhide tree. At that point
|
||||
the Rawhide tree is moving towards the release _after_ the new Branched
|
||||
release, and the pending release is stabilized in the Branched tree.
|
||||
|
||||
After the link:Updates_Policy#Bodhi_enabling[Bodhi enabling point], the
|
||||
Bodhi system is permanently active on the Branched release (all the way
|
||||
until it goes EOL), and requirements for updates to be marked as
|
||||
_stable_ are set out in the link:Updates_Policy[Updates Policy].
|
||||
Packages must go through the
|
||||
link:Repositories#updates-testing[_updates-testing_] repository for the
|
||||
release before entering its link:Repositories#stable[_stable_]
|
||||
repository, according to rules defined in the updates policy: these
|
||||
rules tighten gradually from Alpha through to post-GA (Final), but the
|
||||
basic process does not change.
|
||||
|
||||
For some time prior to a milestone (Alpha, Beta, Final) release a
|
||||
link:Milestone_freezes[freeze] is in effect which prevents packages
|
||||
moving from _updates-testing_ to _stable_ except in accordance with the
|
||||
QA:SOP_blocker_bug_process[blocker] and
|
||||
QA:SOP_freeze_exception_bug_process[freeze exception] bug policies. This
|
||||
freeze is lifted once the milestone is finished, and so packages begin
|
||||
to move from _updates-testing_ to _stable_ as normal again, until the
|
||||
next milestone's freeze date.
|
||||
|
||||
[[schedule-methodology]]
|
||||
Schedule Methodology
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Fedora release schedules are proposed by the
|
||||
link:Fedora_Program_Management[Fedora Program Manager] and ratified by
|
||||
the link:FESCo[ Fedora Engineering Steering Committee (FESCo)], with
|
||||
input from other groups. FESCo is responsible for overseeing the
|
||||
technical direction of the Fedora distribution. A core schedule is
|
||||
created using the key tasks listed below. Detailed team schedules are
|
||||
built around these dates.
|
||||
|
||||
[cols=",,",options="header",]
|
||||
|=======================================================================
|
||||
|Task/Milestone |Start Day (Tuesdays or Thursdays) |Length
|
||||
|Planning and Development |_Branch point_ of _previous release_ plus
|
||||
*one day* |Variable
|
||||
|
||||
|link:Changes/Policy#For_Developers[Changes Checkpoint #1: Proposal
|
||||
deadline] |Tue: _Branch point_ minus *3 months* |n/a
|
||||
|
||||
|link:Releases/Branched[Branch point] |Tue: _Alpha Freeze_ minus *2
|
||||
weeks* |n/a
|
||||
|
||||
|link:Changes/Policy#For_Developers[Changes Checkpoint #2: Feature
|
||||
completion deadline] |Tue: *Same day* as _Branch point_ |N/A
|
||||
|
||||
|QA:SOP_compose_request[Alpha test composes] |Any time after _Branch
|
||||
point_ |Until _Alpha release candidates_
|
||||
|
||||
|link:Milestone_freezes[ Alpha Freeze] |Tue: _Alpha Release_ minus *2
|
||||
weeks* |QA:SOP_freeze_exception_bug_process and
|
||||
QA:SOP_blocker_bug_process in effect until _Alpha Release_
|
||||
|
||||
|link:Updates_Policy#Bodhi_activation[Bodhi activation point] |Tue:
|
||||
*Same day* as _Alpha Freeze_ |Bodhi enabled and Updates_Policy
|
||||
requirements in effect until _EOL_
|
||||
|
||||
|String Freeze |Tue: *Same day* as _Alpha Freeze_
|
||||
|link:Software_String_Freeze_Policy[Software String Freeze Policy] in
|
||||
effect until _GA Release_
|
||||
|
||||
|QA:SOP_compose_request[Alpha release candidates] |Any time after _Alpha
|
||||
Freeze_ |Until _Alpha Release_
|
||||
|
||||
|Alpha Go_No_Go_Meeting |*Thu* @ 13:00 E\{D,S}T: planned _Alpha Release_
|
||||
*minus five days* (repeats if No-Go) |n/a
|
||||
|
||||
|Alpha Release |Tue: _Beta Release_ minus *5 weeks*, _Alpha Freeze_ plus
|
||||
*2 weeks* |Live until _Beta Release_
|
||||
|
||||
|QA:SOP_compose_request[Beta test composes] |Tue: _Beta Freeze_ minus *2
|
||||
weeks*, _Alpha Release_ plus *1 week* |Until _Beta release candidates_
|
||||
|
||||
|link:Milestone_freezes[ Beta Freeze] |Tue: _Beta Release_ minus *2
|
||||
weeks*, _Alpha Release_ plus *3 weeks*
|
||||
|QA:SOP_freeze_exception_bug_process and QA:SOP_blocker_bug_process in
|
||||
effect until _Beta Release_
|
||||
|
||||
|QA:SOP_compose_request[Beta release candidates] |Any time after _Beta
|
||||
Freeze_ |Until _Beta Release_
|
||||
|
||||
|link:Changes/Policy#For_Developers[Changes Checkpoint #3: 100% code
|
||||
complete deadline ] |Tue: *Same day* as _Beta Freeze_ |N/A
|
||||
|
||||
|Beta Go_No_Go_Meeting |*Thu* @ 13:00 E\{D,S}T: planned _Beta Release_
|
||||
*minus five days* (repeats if No-Go) |n/a
|
||||
|
||||
|Beta Release |Tue: _Beta Freeze_ plus *2 weeks*, _GA Release_ minus *5
|
||||
weeks* |Live until _GA release_
|
||||
|
||||
|QA:SOP_compose_request[Final test composes] |Tue: _Final Freeze_ minus
|
||||
*2 weeks*, _Beta Release_ plus *1 week* |Until _Final release
|
||||
candidates_
|
||||
|
||||
|link:Milestone_freezes[ Final Freeze] |Tue: _Final Release_ minus *2
|
||||
weeks*, _Beta Release_ plus *3 weeks*
|
||||
|QA:SOP_freeze_exception_bug_process and QA:SOP_blocker_bug_process in
|
||||
effect until _GA Release_
|
||||
|
||||
|QA:SOP_compose_request[Final release candidates] |Any time after _Final
|
||||
Freeze_ |Until _GA Release_
|
||||
|
||||
|Final Go_No_Go_Meeting |*Thu* @ 13:00 E\{D,S}T: planned _GA Release_
|
||||
*minus five days* (repeats if No-Go) |n/a
|
||||
|
||||
|GA Release |Tue: *Primary date* from which rest of schedule derives
|
||||
|n/a
|
||||
|
||||
|Maintenance |Tue: *Same day* as _GA release_ |~**13 Months**
|
||||
|
||||
|End of Life |_GA of next-but-one release_ plus *one month* |n/a
|
||||
|=======================================================================
|
||||
|
||||
[[steps-to-construct-a-new-schedule]]
|
||||
Steps to Construct a New Schedule
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
This is admittedly an unusual methodology, but it is fairly easy to
|
||||
generate using the the
|
||||
[https://fedorapeople.org/groups/schedule/f-%7B%7BFedoraVersionNumber%7Cnext%7D}
|
||||
TaskJuggler schedules] the Fedora Program Manager maintains.
|
||||
|
||||
1. Pick _GA release_ date (the Tuesday before May 1st or October 31st)
|
||||
* Check with Fedora PR to ensure that planned dates do not conflict with
|
||||
other ecosystem planned events (so we get the maximum press benefit)
|
||||
2. Work backwards using consistent spacing for freezes, composes, and
|
||||
releases for Alpha, Beta, and Final, as described above, to the _Branch
|
||||
point_
|
||||
3. Set the link:Changes/Policy[change proposal checkpoint/deadline]
|
||||
working backwards from the _Branch point_
|
||||
4. The time before the _change proposal checkpoint/deadline_ and after
|
||||
the _Branch point of the previous release_ is the time dedicated to
|
||||
_development_
|
||||
* Development time varies from from release to release based on when the
|
||||
previous release branched
|
||||
* The stabilization and testing time (from _Branch point_ until _GA
|
||||
release_) is held constant from release to release
|
||||
|
||||
Schedule draft is submitted to FESCo via its ticketing system for the
|
||||
approval. Initially, all milestones except "Change Checkpoint: Proposal
|
||||
submission deadline (System Wide Changes)" are scheduled as so called
|
||||
"no earlier than". Final schedule is set after the FESCo's review of
|
||||
proposed and accepted Changes proposals and "no earlier than" note is
|
||||
removed from schedule. This gives us opportunity to properly plan
|
||||
release, especially for changes with high impact on the release.
|
||||
|
||||
[[development-schedule-rationale]]
|
||||
Development Schedule Rationale
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Fedora generally develops new releases over a six month period to
|
||||
provide a regular and predictable release schedule. The bi-annual
|
||||
targeted release dates are _May Day_ (May 1st) and _Halloween_ (October
|
||||
31) making them easy to remember and avoiding significant holiday
|
||||
breaks. Changes to this standard must be approved by the
|
||||
community-elected link:FESCo[ Fedora Engineering Steering Committee
|
||||
(FESCo)].
|
||||
|
||||
A six month release schedule also follows the precedence of Red Hat
|
||||
Linux (precursor to Fedora). Former Red Hat software engineer Havoc
|
||||
Pennington offers a historical perspective
|
||||
http://article.gmane.org/gmane.linux.redhat.fedora.advisory-board/1475/[here].
|
||||
GNOME started following a time based release based on the ideas and
|
||||
success of Red Hat Linux and other distributions following Fedora having
|
||||
adopted a similar release cycle. Several other major components,
|
||||
including the Linux kernel, Openoffice.org, Xorg, have started following
|
||||
a time based release schedule. While the exact release schedules vary
|
||||
between these components and other upstream projects, the interactions
|
||||
between these components and Fedora makes a six month time based release
|
||||
schedule a good balance.
|
||||
|
||||
Although due to how planning process and release validation works,
|
||||
Fedora is not a strictly time based distribution but uses combination of
|
||||
both time and feature based release paradigms. This way we can react to
|
||||
bigger changes aka new installed, way how we release bits (Fedora.Next)
|
||||
etc.
|
||||
|
||||
[[schedule-contingency-planning]]
|
||||
Schedule Contingency Planning
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If the Alpha, Beta, or Final link:Go_No_Go_Meeting[Go_No_Go_Meetings]
|
||||
result in a "No Go" determination, that milestone and subsequent
|
||||
milestones will be pushed back by one week.
|
||||
|
||||
One week is added to the schedule to maintain the practice of releasing
|
||||
on Tuesdays. Tuesdays are the designated release day because they are
|
||||
good days for news coverage and the established day we synchronize our
|
||||
content with the mirrors that carry our releases. Be aware of holidays
|
||||
and of possible PR conflicts (contact Fedora PR) with the new proposed
|
||||
final date.
|
||||
|
||||
Go/No Go meetings receive input from representatives of
|
||||
link:Fedora_Engineering_Steering_Committee[FESCo],
|
||||
link:ReleaseEngineering[Release Engineering], and link:QA[Quality
|
||||
Assurance].
|
||||
|
||||
[[maintenance-schedule]]
|
||||
Maintenance Schedule
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
We say maintained for _approximately 13 months_ because the supported
|
||||
period for releases is dependent on the date the release under
|
||||
development goes final. As a result, _Release X_ is supported until one
|
||||
month after the release of _Release X+2_.
|
||||
|
||||
This translates into:
|
||||
|
||||
* will be maintained until 1 month after the release of .
|
||||
* will be maintained until 1 month after the release of .
|
||||
|
||||
[[maintenance-schedule-rationale]]
|
||||
Maintenance Schedule Rationale
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Fedora is link:Objectives[ focused] on free and open source software
|
||||
link:Red_Hat_contributions[ innovations] and moves quickly. If you want
|
||||
a distribution that moves slower but has a longer lifecycle, Red Hat
|
||||
Enterprise Linux, which is derivative of Fedora or free rebuilds of that
|
||||
such as CentOS might be more suitable for you. Refer to the RHEL page
|
||||
for more details.
|
||||
|
||||
Historically, the Fedora Project has found supporting two releases plus
|
||||
Rawhide and the pre-release Branched code to be a manageable work load.
|
||||
|
||||
[[end-of-life-eol]]
|
||||
End of Life (EOL)
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
When a release reaches the point where it is no longer supported nor
|
||||
updates are created for it, then it is considered _End of Life_ (EOL).
|
||||
Branches for new packages in the SCM are not allowed for distribution X
|
||||
after the Fedora X+2 release and new builds are no longer allowed.
|
||||
|
||||
The tasks performed at EOL are documented in the
|
||||
link:End_of_life_SOP[End of life SOP].
|
||||
|
||||
[[additional-release-schedule-information]]
|
||||
Additional Release Schedule Information
|
||||
---------------------------------------
|
||||
|
||||
* Overview of Releases, including currently supported releases
|
||||
* link:End_of_life[ Unsupported Releases]
|
||||
* link:Releases/HistoricalSchedules[ Historical Release Information]
|
||||
|
||||
Category:Distribution
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
1193
en-US/firewalld.adoc
Normal file
1193
en-US/firewalld.adoc
Normal file
File diff suppressed because it is too large
Load diff
39
en-US/flash.adoc
Normal file
39
en-US/flash.adoc
Normal file
|
|
@ -0,0 +1,39 @@
|
|||
= Flash
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/Flash
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
436
en-US/get-started-with-virt.adoc
Normal file
436
en-US/get-started-with-virt.adoc
Normal file
|
|
@ -0,0 +1,436 @@
|
|||
= Getting started with virtualization
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/Getting_started_with_virtualization
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
This page deals with using Fedora to host virtual guests. For
|
||||
information the different virtualization technologies available in
|
||||
Fedora, see the link:Tools/Virtualization[dedicated page].
|
||||
|
||||
[[using-virtualization-on-fedora]]
|
||||
Using virtualization on Fedora
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Fedora uses the libvirt family of tools as its virtualization solution.
|
||||
By default libvirt on Fedora will use Qemu to run guest instances.
|
||||
|
||||
For information on other virtualization platforms, refer to
|
||||
http://virt.kernelnewbies.org/TechComparison.
|
||||
|
||||
Qemu can emulate a host machine in software, or given a CPU with
|
||||
hardware support (see below) can use http://www.linux-kvm.org[KVM] to
|
||||
provide a fast full virtualization.
|
||||
|
||||
Other virtualization products and packages are available but are not
|
||||
covered by this guide.
|
||||
|
||||
[[installing-and-configuring-fedora-for-virtualized-guests]]
|
||||
Installing and configuring Fedora For virtualized guests
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This section covers setting up libvirt on your system. After the
|
||||
successful completion of this section you will be able to create
|
||||
virtualized guest operating systems.
|
||||
|
||||
[[system-requirements]]
|
||||
System requirements
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The common system requirements for virtualization on Fedora are:
|
||||
|
||||
* At least 600MB of hard disk storage per guest. A minimal command-line
|
||||
Fedora system requires 600MB of storage. Standard fedora desktop guests
|
||||
require at least 3GB of space.
|
||||
* At least 256MB of RAM per guest plus 256 for the base OS. At least
|
||||
756MB is recommended for each guest of a modern operating system. A good
|
||||
rule of thumb is to think about how much memory is required for the
|
||||
operating system normally and allocate that much to the virtualized
|
||||
guest.
|
||||
|
||||
KVM requires a CPU with virtualization extensions, found on most
|
||||
consumer CPUs made in the past couple years. These extensions are called
|
||||
Intel VT or AMD-V. To check whether you have proper CPU support, run the
|
||||
command:
|
||||
|
||||
....
|
||||
$ egrep '^flags.*(vmx|svm)' /proc/cpuinfo
|
||||
....
|
||||
|
||||
If NOTHING is printed, your system does not support the relevant
|
||||
extensions. You can still use the QEMU/KVM, but the emulator will fall
|
||||
back to software virtualization, which is FAR FAR slower.
|
||||
|
||||
[[installing-the-virtualization-packages]]
|
||||
Installing the virtualization packages
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
When installing Fedora, the virtualization packages can be installed by
|
||||
selecting *Virtualization* in the Base Group in the installer. (This may
|
||||
http://docs.fedoraproject.org/en-US/Fedora/13/html/Installation_Guide/s1-pkgselection-x86.html[no
|
||||
longer apply to your installation method] though).
|
||||
|
||||
For existing Fedora installations, QEMU, KVM, and other virtualization
|
||||
tools can be installed by running the following command which installs
|
||||
the virtualization group:
|
||||
|
||||
[[fedora-22-to-current]]
|
||||
Fedora 22 to current:
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
For Fedora 21 or previous installations, replace "dnf" with "yum." Yum
|
||||
is now a deprecated package manager and is replaced by DNF on
|
||||
installations of Fedora 22 and onward.
|
||||
|
||||
....
|
||||
su -c "dnf install @virtualization"
|
||||
....
|
||||
|
||||
This will install below Mandatory and Default packages.
|
||||
|
||||
....
|
||||
$ dnf groupinfo virtualization
|
||||
|
||||
Group: Virtualisation
|
||||
Group-Id: virtualization
|
||||
Description: These packages provide a virtualisation environment.
|
||||
Mandatory Packages:
|
||||
=virt-install
|
||||
Default Packages:
|
||||
=libvirt-daemon-config-network
|
||||
=libvirt-daemon-kvm
|
||||
=qemu-kvm
|
||||
=virt-manager
|
||||
=virt-viewer
|
||||
Optional Packages:
|
||||
guestfs-browser
|
||||
libguestfs-tools
|
||||
python-libguestfs
|
||||
virt-top
|
||||
....
|
||||
|
||||
This will install Mandatory, Default and Optional Packages.
|
||||
|
||||
....
|
||||
su -c "dnf group install with-optional virtualization"
|
||||
....
|
||||
|
||||
To start the service:
|
||||
|
||||
....
|
||||
su -c "systemctl start libvirtd"
|
||||
....
|
||||
|
||||
To start the service on boot:
|
||||
|
||||
....
|
||||
su -c "systemctl enable libvirtd"
|
||||
....
|
||||
|
||||
Verify that the kvm kernel modules were properly loaded:
|
||||
|
||||
....
|
||||
$ lsmod | grep kvm
|
||||
kvm_amd 55563 0
|
||||
kvm 419458 1 kvm_amd
|
||||
....
|
||||
|
||||
If that command did not list kvm_intel or kvm_amd, KVM is not properly
|
||||
configured. See
|
||||
link:How_to_debug_Virtualization_problems#Ensuring_system_is_KVM_capable[
|
||||
Ensuring system is KVM capable] for troubleshooting tips.
|
||||
|
||||
[[networking-support]]
|
||||
Networking Support
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
|
||||
By default libvirt will create a private network for your guests on the
|
||||
host machine. This private network will use a 192.168.x.x subnet and not
|
||||
be reachable directly from the network the host machine is on, but
|
||||
virtual guests can use the host machine as a gateway and can connect out
|
||||
via it. If you need to provide services on your guests that are
|
||||
reachable via other machines on your host network you can use iptables
|
||||
DNAT rules to forward in specific ports, or you can setup a Bridged env.
|
||||
|
||||
See the http://wiki.libvirt.org/page/Networking[libvirt networking setup
|
||||
page] for more information on how to setup a Bridged network.
|
||||
|
||||
[[creating-a-fedora-guest]]
|
||||
Creating a Fedora guest
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The installation of Fedora guests using anaconda is supported. The
|
||||
installation can be started on the command line via the `virt-install`
|
||||
program or in the GUI program `virt-manager`.
|
||||
|
||||
[[creating-a-guest-with-virt-install]]
|
||||
Creating a guest with virt-install
|
||||
++++++++++++++++++++++++++++++++++
|
||||
|
||||
`virt-install` is a command line based tool for creating virtualized
|
||||
guests. Refer to
|
||||
http://virt-tools.org/learning/install-with-command-line/ for
|
||||
understanding how to use this tool. Execute `virt-install --help` for
|
||||
command line help.
|
||||
|
||||
`virt-install` can use kickstart files, for example
|
||||
`virt-install -x ks=kickstart-file-name.ks`.
|
||||
|
||||
If graphics were enabled, a VNC window will open and present the
|
||||
graphical installer. If graphics were not enabled, a text installer will
|
||||
appear. Proceed with the fedora installation.
|
||||
|
||||
[[creating-a-guest-with-virt-manager]]
|
||||
Creating a guest with virt-manager
|
||||
++++++++++++++++++++++++++++++++++
|
||||
|
||||
Start the GUI Virtual Machine Manager by selecting it from the
|
||||
"Applications-->System Tools" menu, or by running the following command:
|
||||
|
||||
....
|
||||
su -c "virt-manager"
|
||||
....
|
||||
|
||||
If you encounter an error along the lines of "Failed to contact
|
||||
configuration server; some possible causes are that you need to enable
|
||||
TCP/IP networking for ORBit, or you have stale NFS locks due to a system
|
||||
crash", trying running `virt-manager` not as root (without the `su -c`).
|
||||
The GUI will prompt for the root password.
|
||||
|
||||
1. Open a connection to a hypervisor by choosing File-->Add
|
||||
connection...
|
||||
2. Choose "qemu" for KVM, or "Xen" for Xen.
|
||||
3. Choose "local" or select a method to connect to a remote hypervisor
|
||||
4. After a connection is opened, click the new icon next to the
|
||||
hypervisor, or right click on the active hypervisor and select "New"
|
||||
(Note - the new icon is going to be improved to make it easier to see)
|
||||
5. A wizard will present the same questions as appear with the
|
||||
`virt-install` command-line utility (see descriptions above). The wizard
|
||||
assumes that a graphical installation is desired and does not prompt for
|
||||
this option.
|
||||
6. On the last page of the wizard there is a "Finish" button. When this
|
||||
is clicked, the guest OS is provisioned. After a few moments a VNC
|
||||
window should appear. Proceed with the installation as normal.
|
||||
|
||||
[[remote-management]]
|
||||
Remote management
|
||||
^^^^^^^^^^^^^^^^^
|
||||
|
||||
The following remote management options are available:
|
||||
|
||||
* (easiest) If using non-root users via SSH, then setup instructions are
|
||||
at: http://wiki.libvirt.org/page/SSHSetup
|
||||
* If using root for access via SSH, then create SSH keys for root, and
|
||||
use `ssh-agent` and `ssh-add` before launching `virt-manager`.
|
||||
* To use TLS, set up a local certificate authority and issue x509 certs
|
||||
to all servers and clients. For information on configuring this option,
|
||||
refer to http://wiki.libvirt.org/page/TLSSetup.
|
||||
|
||||
[[guest-system-administration]]
|
||||
Guest system administration
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
When the installation of the guest operating system is complete, it can
|
||||
be managed using the GUI `virt-manager` program or on the command line
|
||||
using `virsh`.
|
||||
|
||||
[[managing-guests-with-virt-manager]]
|
||||
Managing guests with virt-manager
|
||||
+++++++++++++++++++++++++++++++++
|
||||
|
||||
Start the Virtual Machine Manager. Virtual Machine Manager is in the
|
||||
"Applications-->System Tools" menu, or execute:
|
||||
|
||||
....
|
||||
su -c "virt-manager"
|
||||
....
|
||||
|
||||
\{1} If you are not root, you will be prompted to enter the root
|
||||
password. Choose`Run unprivileged` to operate in a read-only non-root
|
||||
mode.
|
||||
|
||||
* Choose the host you wish to manage and click "Connect" in the "Open
|
||||
Connection" dialog window.
|
||||
* The list of virtual machines is displayed in the main window. Guests
|
||||
that are running will display a ">" icon. Guests that are not running
|
||||
will be greyed out.
|
||||
* To manage a particular guest, double click on it, or right click and
|
||||
select "Open".
|
||||
* A new window for the guest will open that will allow you to use its
|
||||
console, see information about its virtual hardware and start/stop/pause
|
||||
it.
|
||||
|
||||
For further information about `virt-manager` consult the
|
||||
http://virt-manager.et.redhat.com/[project website]
|
||||
|
||||
Bugs in the `virt-manager` tool should be reported in
|
||||
http://bugzilla.redhat.com[BugZilla] against the 'virt-manager'
|
||||
component
|
||||
|
||||
[[managing-guests-with-virsh]]
|
||||
Managing guests with virsh
|
||||
++++++++++++++++++++++++++
|
||||
|
||||
The `virsh` command line utility that allows you to manage virtual
|
||||
machines. Guests can be managed on the command line with the `virsh`
|
||||
utility. The `virsh` utility is built around the libvirt management
|
||||
APIl:
|
||||
|
||||
* `virsh` has a stable set of commands whose syntax and semantics are
|
||||
preserved across updates to the underlying virtualization platform.
|
||||
* `virsh` can be used as an unprivileged user for read-only operations
|
||||
(e.g. listing domains, listing domain statistics).
|
||||
* `virsh` can manage domains running under Xen, Qemu/KVM, esx or other
|
||||
backends with no perceptible difference to the user
|
||||
|
||||
To start a virtual machine:
|
||||
|
||||
....
|
||||
su -c "virsh create <name of virtual machine>"
|
||||
....
|
||||
|
||||
To list the virtual machines currently running:
|
||||
|
||||
....
|
||||
su -c "virsh list"
|
||||
....
|
||||
|
||||
To list all virtual machines, running or not:
|
||||
|
||||
....
|
||||
su -c "virsh list --all"
|
||||
....
|
||||
|
||||
To gracefully power off a guest:
|
||||
|
||||
....
|
||||
su -c "virsh shutdown <virtual machine (name | id | uuid)>"
|
||||
....
|
||||
|
||||
To non gracefully power off a guest:
|
||||
|
||||
....
|
||||
su -c "virsh destroy <virtual machine (name | id | uuid)>"
|
||||
....
|
||||
|
||||
To save a snapshot of the machine to a file:
|
||||
|
||||
....
|
||||
su -c "virsh save <virtual machine (name | id | uuid)> <filename>"
|
||||
....
|
||||
|
||||
To restore a previously saved snapshot:
|
||||
|
||||
....
|
||||
su -c "virsh restore <filename>"
|
||||
....
|
||||
|
||||
To export the configuration file of a virtual machine:
|
||||
|
||||
....
|
||||
su -c "virsh dumpxml <virtual machine (name | id | uuid)"
|
||||
....
|
||||
|
||||
For a complete list of commands available for use with `virsh`:
|
||||
|
||||
....
|
||||
su -c "virsh help"
|
||||
....
|
||||
|
||||
Or consult the manual page: `man 1 virsh`
|
||||
|
||||
Bugs in the `virsh` tool should be reported in
|
||||
http://bugzilla.redhat.com[BugZilla] against the 'libvirt' component.
|
||||
|
||||
[[other-virtualization-options]]
|
||||
Other virtualization options
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
[[qemukvm-without-libvirt]]
|
||||
QEMU/KVM without Libvirt
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
QEMU/KVM can be invoked directly without libvirt, however you won't be
|
||||
able to use tools such as virt-manager, virt-install, or virsh. Plain
|
||||
QEMU (without KVM) can also virtualize other processor architectures
|
||||
like ARM or PowerPC. See link:How_to_use_qemu[How to use qemu]
|
||||
|
||||
[[xen]]
|
||||
Xen
|
||||
^^^
|
||||
|
||||
Fedora can run as a Xen Guest OS and also be used as a Xen host (with
|
||||
the latter being true from Fedora 16; for using an earlier version of
|
||||
Fedora as a Xen Host, check out the experimental repo available at
|
||||
http://myoung.fedorapeople.org/dom0). For a guide on how to install and
|
||||
setup a Fedora Xen host, look at the
|
||||
http://wiki.xen.org/wiki/Fedora_Host_Installation[Fedora Host
|
||||
Installation] page on the Xen Project wiki.
|
||||
|
||||
[[openstack]]
|
||||
OpenStack
|
||||
^^^^^^^^^
|
||||
|
||||
OpenStack consists of a number services for running IaaS clouds. They
|
||||
are the Object Store (Swift), Compute (Nova) and Image (Glance)
|
||||
services. It is a link:Features/OpenStack[Fedora 16 feature].
|
||||
|
||||
[[opennebula]]
|
||||
OpenNebula
|
||||
^^^^^^^^^^
|
||||
|
||||
link:Features/OpenNebula[OpenNebula] is an Open Source Toolkit for Data
|
||||
Center Virtualization.
|
||||
|
||||
[[ovirt]]
|
||||
oVirt
|
||||
^^^^^
|
||||
|
||||
The https://www.ovirt.org/[oVirt project] is an open virtualization
|
||||
project providing a feature-rich, end to end, server virtualization
|
||||
management system with advanced capabilities for hosts and guests,
|
||||
including high availability, live migration, storage management, system
|
||||
scheduler, and more.
|
||||
|
||||
[[troubleshooting-bug-reporting-and-known-issues]]
|
||||
Troubleshooting, bug reporting, and known issues
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
For a list of known unresolved issues, as well as troubleshooting tips,
|
||||
please see link:How_to_debug_Virtualization_problems[How to debug
|
||||
virtualization problems]
|
||||
|
||||
Category:Documentation Category:Virtualization
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
482
en-US/grub2.adoc
Normal file
482
en-US/grub2.adoc
Normal file
|
|
@ -0,0 +1,482 @@
|
|||
= GRUB 2
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/GRUB_2
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
[[introduction]]
|
||||
Introduction
|
||||
------------
|
||||
|
||||
GRUB 2 is the latest version of GNU GRUB, the GRand Unified Bootloader.
|
||||
A bootloader is the first software program that runs when a computer
|
||||
starts. It is responsible for loading and transferring control to the
|
||||
operating system kernel, (Linux, in the case of Fedora). The kernel, in
|
||||
turn, initializes the rest of the operating system.
|
||||
|
||||
GRUB 2 has replaced what was formerly known as GRUB (i.e. version 0.9x),
|
||||
which has, in turn, become GRUB Legacy.
|
||||
|
||||
Starting with Fedora 16, GRUB 2 is the default bootloader on x86 BIOS
|
||||
systems. For upgrades of BIOS systems the default is also to install
|
||||
GRUB 2, but you can opt to skip bootloader configuration entirely.
|
||||
|
||||
[[tasks-common-issues]]
|
||||
Tasks / Common issues
|
||||
---------------------
|
||||
|
||||
[[updating-grub-2-configuration-on-bios-systems]]
|
||||
Updating GRUB 2 configuration on BIOS systems
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The grub2 packages contain commands for installing a bootloader and for
|
||||
creating a bootloader configuration file.
|
||||
|
||||
grub2-install will install the bootloader - usually in the MBR, in free
|
||||
unpartioned space, and as files in /boot. The bootloader is installed
|
||||
with something like:
|
||||
|
||||
....
|
||||
grub2-install /dev/sda
|
||||
....
|
||||
|
||||
grub2-mkconfig will create a new configuration based on the currently
|
||||
running system, what is found in /boot, what is set in
|
||||
/etc/default/grub, and the customizable scripts in /etc/grub.d/ . A new
|
||||
configuration file is created with:
|
||||
|
||||
....
|
||||
grub2-mkconfig -o /boot/grub2/grub.cfg
|
||||
....
|
||||
|
||||
The configuration format has evolved over time, and a new configuration
|
||||
file might be slightly incompatible with the old bootloader. It is
|
||||
therefore a good idea to first run grub2-install whenever you would need
|
||||
to run grub2-mkconfig.
|
||||
|
||||
The Fedora installer, anaconda, will run these grub2 commands and there
|
||||
is usually no reason to run them manually.
|
||||
|
||||
It is generally safe to directly edit /boot/grub2/grub.cfg in Fedora.
|
||||
Grubby in Fedora patches the configuration when a kernel update is
|
||||
performed and will try to not make any other changes than what is
|
||||
necessary. (Other distributions, in particular Debian and Debian-derived
|
||||
distributions provide a software patch that adds an command which is
|
||||
neither included nor needed in Fedora.) Manual changes might however be
|
||||
overwritten with grub2-mkconfig next time the system is upgraded with
|
||||
anaconda. Some customizations can be placed in /etc/grub.d/40_custom or
|
||||
/boot/grub2/custom.cfg and will survive running grub2-mkconfig.
|
||||
|
||||
[[updating-grub-2-configuration-on-uefi-systems]]
|
||||
Updating GRUB 2 configuration on UEFI systems
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To install or fix GRUB 2 on a UEFI system on Fedora 18 or newer, you
|
||||
need to do four things:
|
||||
|
||||
[[create-an-esp]]
|
||||
Create an ESP
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
UEFI firmware, in general, likes to boot from an EFI System Partition on
|
||||
a disk with a GPT label. In `gdisk`, it looks something like this:
|
||||
|
||||
....
|
||||
Number Start (sector) End (sector) Size Code Name
|
||||
1 2048 264191 128.0 MiB EF00 EFI System
|
||||
....
|
||||
|
||||
That partition should be formatted as FAT. If in doubt, FAT32 is a good
|
||||
dialect of FAT to choose.
|
||||
|
||||
Fedora expects this partition to be mounted at `/boot/efi`.
|
||||
|
||||
[[install-the-bootloader-files]]
|
||||
Install the bootloader files
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If you don't already have the relevant packages installed, do for Fedora
|
||||
22 and later versions with link:dnf[DNF] or with YUM for older Fedora
|
||||
releases:
|
||||
|
||||
....
|
||||
dnf install grub2-efi grub2-efi-modules shim
|
||||
yum install grub2-efi grub2-efi-modules shim
|
||||
....
|
||||
|
||||
If you do, then try:
|
||||
|
||||
....
|
||||
dnf reinstall grub2-efi grub2-efi-modules shim
|
||||
yum reinstall grub2-efi grub2-efi-modules shim
|
||||
....
|
||||
|
||||
instead.
|
||||
|
||||
Make sure that /boot/efi is mounted when you do this.
|
||||
|
||||
This installs the signed shim and the GRUB 2 binary.
|
||||
|
||||
[[create-a-grub-2-configuration]]
|
||||
Create a GRUB 2 configuration
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Under EFI, GRUB 2 looks for its configuration in
|
||||
`/boot/efi/EFI/fedora/grub.cfg`. For newly installed kernels to work,
|
||||
`grubby` expects `/etc/grub2-efi.cfg` to be a symlink to the real
|
||||
grub.cfg (i.e. `/boot/efi/EFI/fedora/grub.cfg`).
|
||||
|
||||
If you already have a grub 2 EFI config file, you should be okay. If
|
||||
not, grub2-mkconfig can help, but your mileage may vary.
|
||||
|
||||
` grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg`
|
||||
|
||||
[[create-a-boot-menu-entry]]
|
||||
Create a boot menu entry
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
TL;DR: This should happen automatically. If it doesn't, read on.
|
||||
|
||||
When you power on your system, your firmware will look for EFI variables
|
||||
that tell it how to boot. If you're already booted in EFI mode and EFI
|
||||
runtime services are working correctly, you can configure your boot menu
|
||||
with `efibootmgr`. If not, you'll have to bootstrap the process.
|
||||
|
||||
Fortunately, `shim` can help you bootstrap. The EFI program
|
||||
`/boot/efi/EFI/BOOT/fallback.efi` will look for files called `BOOT.CSV`
|
||||
in your ESP and will add boot entries corresponding to them, *if such
|
||||
entries do not already appear to exist*. `shim` provides a `BOOT.CSV`
|
||||
file that will add an entry for `grub2-efi` for you. So just using the
|
||||
EFI Shell to invoke `fallback.efi` should do the trick. You can do this
|
||||
with commands like:
|
||||
|
||||
....
|
||||
> fs0:
|
||||
> cd EFI\BOOT
|
||||
> fallback.efi
|
||||
....
|
||||
|
||||
If you have no boot entries at all, then just booting off your disk in
|
||||
UEFI mode should automatically invoke `/boot/efi/EFI/BOOT/BOOTX64.EFI`,
|
||||
which will, in turn, invoke `fallback.efi`.
|
||||
|
||||
If you already have incorrect boot entries, you'll either need to delete
|
||||
them or to modify `BOOT.CSV` to create new entries with different names.
|
||||
|
||||
[[adding-other-operating-systems-to-the-grub-2-menu]]
|
||||
Adding Other operating systems to the GRUB 2 menu
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
grub2-mkconfig will add entries for other operating systems it can find.
|
||||
That will be done based on the output of the os-prober tool.
|
||||
|
||||
That might however not work so well, especially not for booting other
|
||||
Linux operating systems, and especially not on UEFI systems. See
|
||||
http://www.gnu.org/software/grub/manual/grub.html#Multi_002dboot-manual-config
|
||||
.
|
||||
|
||||
[[setting-default-entry]]
|
||||
Setting default entry
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Due to `grub2-mkconfig` (and os-prober) we cannot predict the order of
|
||||
the entries in `/boot/grub2/grub.cfg`, so we set the default by
|
||||
name/title instead.
|
||||
|
||||
Open `/etc/default/grub` and ensure this line exists:
|
||||
|
||||
....
|
||||
GRUB_DEFAULT=saved
|
||||
....
|
||||
|
||||
and ensure this line not exists:
|
||||
|
||||
....
|
||||
GRUB_SAVEDEFAULT=true
|
||||
....
|
||||
|
||||
or ensure this line exists:
|
||||
|
||||
....
|
||||
GRUB_SAVEDEFAULT=false
|
||||
....
|
||||
|
||||
Apply the change to `grub.cfg` by running:
|
||||
|
||||
....
|
||||
grub2-mkconfig -o /boot/grub2/grub.cfg
|
||||
....
|
||||
|
||||
Now list all possible menu entries
|
||||
|
||||
....
|
||||
grep -P "submenu|^menuentry" /boot/grub2/grub.cfg | cut -d "'" -f2
|
||||
....
|
||||
|
||||
Now set the desired default menu entry
|
||||
|
||||
....
|
||||
grub2-set-default "<submenu title><menu entry title>"
|
||||
....
|
||||
|
||||
Verify the default menu entry
|
||||
|
||||
....
|
||||
grub2-editenv list
|
||||
....
|
||||
|
||||
If you understand the risks involved and still want to directly modify
|
||||
/boot/grub2/grub.cfg, here's how you can do it:
|
||||
|
||||
Edit /boot/grub2/grub.cfg, and change the line
|
||||
|
||||
....
|
||||
set default="0"
|
||||
....
|
||||
|
||||
to
|
||||
|
||||
....
|
||||
set default="5"
|
||||
....
|
||||
|
||||
[[encountering-the-dreaded-grub-2-boot-prompt]]
|
||||
Encountering the dreaded GRUB 2 boot prompt
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If improperly configured, GRUB 2 may fail to load and subsequently drop
|
||||
to a boot prompt. To address this issue, proceed as follows:
|
||||
|
||||
\0. Load the XFS and LVM modules
|
||||
|
||||
....
|
||||
insmod xfs
|
||||
insmod lvm
|
||||
....
|
||||
|
||||
\1. List the drives which GRUB 2 sees:
|
||||
|
||||
....
|
||||
grub2> ls
|
||||
....
|
||||
|
||||
\2. The output for a dos partition table /dev/sda with three partitons
|
||||
will look something like this:
|
||||
|
||||
....
|
||||
(hd0) (hd0,msdos3) (hd0,msdos2) (hd0,msdos1)
|
||||
....
|
||||
|
||||
\3. While the output for a gpt partition table /dev/sda with four
|
||||
partitions will look something like this:
|
||||
|
||||
....
|
||||
(hd0) (hd0,gpt4) (hd0,gpt3) (hd0,gpt2) (hd0,gpt1)
|
||||
....
|
||||
|
||||
\4. With this information you can now probe each partition of the drive
|
||||
and locate your vmlinuz and initramfs files:
|
||||
|
||||
....
|
||||
ls (hd0,1)/
|
||||
....
|
||||
|
||||
Will list the files on /dev/sda1. If this partition contains /boot, the
|
||||
output will show the full name of vmlinuz and initramfs.
|
||||
|
||||
\5. Armed with the location and full name of vmlinuz and initramfs you
|
||||
can now boot your system.
|
||||
|
||||
5a. Declare your root partition:
|
||||
|
||||
....
|
||||
grub> set root=(hd0,3)
|
||||
....
|
||||
|
||||
5b. Declare the kernel you wish to use:
|
||||
|
||||
....
|
||||
grub> linux (hd0,1)/vmlinuz-3.0.0-1.fc16.i686 root=/dev/sda3 rhgb quiet selinux=0
|
||||
# NOTE : add other kernel args if you have need of them
|
||||
# NOTE : change the numbers to match your system
|
||||
....
|
||||
|
||||
5c. Declare the initrd to use:
|
||||
|
||||
....
|
||||
|
||||
grub> initrd (hd0,1)/initramfs-3.0.0-1.fc16.i686.img
|
||||
# NOTE : change the numbers to match your system
|
||||
....
|
||||
|
||||
5d. Instruct GRUB 2 to boot the chosen files:
|
||||
|
||||
....
|
||||
grub> boot
|
||||
....
|
||||
|
||||
\6. After boot, open a terminal.
|
||||
|
||||
\7. Issue the grub2-mkconfig command to re-create the grub.cfg file
|
||||
grub2 needed to boot your system:
|
||||
|
||||
....
|
||||
grub2-mkconfig -o /boot/grub2/grub.cfg
|
||||
....
|
||||
|
||||
\8. Issue the grub2-install command to install grub2 to your hard drive
|
||||
and make use of your config:
|
||||
|
||||
....
|
||||
grub2-install --boot-directory=/boot /dev/sda
|
||||
# Note: your drive may have another device name. Check for it with mount command output.
|
||||
....
|
||||
|
||||
[[additional-scenario]]
|
||||
Additional Scenario
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
It's also possible to boot into a _configfile_ that's located on another
|
||||
partition. If the user is faced with such a scenario, as is often the
|
||||
case with multi-boot systems containing Ubuntu and Fedora, the following
|
||||
steps in the grub rescue shell might become useful to know:
|
||||
|
||||
....
|
||||
insmod part_msdos
|
||||
insmod xfs
|
||||
insmod lvm
|
||||
set root='hd0,msdos1'
|
||||
configfile /grub2/grub.cfg
|
||||
....
|
||||
|
||||
Where, *hd0,msdos1* is the pertinent _boot_ partition, which holds the
|
||||
grub.cfg file.
|
||||
|
||||
[[other-grub-2-issues]]
|
||||
Other GRUB 2 issues
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
''' Absent Floppy Disk ''': It has been reported by some users that GRUB
|
||||
2 may fail to install on a partition's boot sector if the computer
|
||||
floppy controller is activated in BIOS without an actual floppy disk
|
||||
drive being present. A possible workaround is to run (post OS install)
|
||||
from rescue mode:
|
||||
|
||||
....
|
||||
grub2-install <target device> --no-floppy
|
||||
....
|
||||
|
||||
[[setting-a-password-for-interactive-edit-mode]]
|
||||
Setting a password for interactive edit mode
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If you wish to password-protect GRUB2's interactive edit mode *but* you
|
||||
do not want to require users to enter a password to do a plain, simple,
|
||||
ordinary boot, create /etc/grub.d/01_users with the following lines:
|
||||
|
||||
....
|
||||
cat << EOF
|
||||
set superusers="root"
|
||||
export superusers
|
||||
password root secret
|
||||
EOF
|
||||
....
|
||||
|
||||
To apply your changes run:
|
||||
|
||||
....
|
||||
grub2-mkconfig -o /boot/grub2/grub.cfg
|
||||
....
|
||||
|
||||
You can encrypt the password by using pbkdf2. Use grub2-mkpasswd-pbkdf2
|
||||
to encrypt the password, then replace the password line with:
|
||||
|
||||
....
|
||||
password_pbkdf2 root grub.pbkdf2.sha512.10000.1B4BD9B60DE889A4C50AA9458C4044CBE129C9607B6231783F7E4E7191D8254C0732F4255178E2677BBE27D03186E44815EEFBAD82737D81C87F5D24313DDDE7.E9AEB53A46A16F30735E2558100D8340049A719474AEEE7E3F44C9C5201E2CA82221DCF2A12C39112A701292BF4AA071EB13E5EC8C8C84CC4B1A83304EA10F74
|
||||
....
|
||||
|
||||
More details can be found at
|
||||
https://help.ubuntu.com/community/Grub2/Passwords[Ubuntu Help: GRUB2
|
||||
Passwords].
|
||||
|
||||
Starting from atleast Fedora 21, the `--md5pass` kickstart option must
|
||||
be set using output from grub2-mkpasswd-pbkdf2.
|
||||
|
||||
[[using-old-graphics-modes-in-bootloader]]
|
||||
Using old graphics modes in bootloader
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Terminal device is chosen with GRUB_TERMINAL; additional quote from
|
||||
http://www.gnu.org/software/grub/manual/grub.html#Simple-configuration
|
||||
|
||||
Valid terminal output names depend on the platform, but may include
|
||||
‘console’ (PC BIOS and EFI consoles), ‘serial’ (serial terminal),
|
||||
‘gfxterm’ (graphics-mode output), ‘ofconsole’ (Open Firmware console),
|
||||
or ‘vga_text’ (VGA text output, mainly useful with Coreboot).
|
||||
|
||||
The default is to use the platform's native terminal output.
|
||||
|
||||
The default in Fedora is gfxterm and to get the legacy graphics modes
|
||||
you need to set GRUB_TERMINAL to right variable from the description
|
||||
above in /etc/default/grub
|
||||
|
||||
[[enable-serial-console-in-grub]]
|
||||
Enable Serial Console in Grub
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To enable Serial console in grub add the following entry's to
|
||||
/etc/default/grub
|
||||
|
||||
( Adjust baudrate/parity/bits/flow control to fit your environment and
|
||||
cables)
|
||||
|
||||
....
|
||||
GRUB_CMDLINE_LINUX='console=tty0 console=ttyS0,115200n8'
|
||||
GRUB_TERMINAL=serial
|
||||
GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"
|
||||
....
|
||||
|
||||
And re-generate grub
|
||||
|
||||
`grub2-mkconfig -o /boot/grub2/grub.cfg`
|
||||
|
||||
[[further-reading]]
|
||||
Further Reading
|
||||
---------------
|
||||
|
||||
* http://www.gnu.org/software/grub/manual/grub.html
|
||||
* Features/Grub2
|
||||
* Anaconda/Features/Grub2Migration
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
|
|
@ -1,4 +1,9 @@
|
|||
Place holder
|
||||
============
|
||||
Fedora Quick Docs
|
||||
=================
|
||||
|
||||
Put goodness here
|
||||
This repository represents asciidoc documents roughly converted from the top
|
||||
50 document-like pages in the Fedora Wiki. We want to move away from
|
||||
exposing users to the wild territory of workspace wikis and to a nice,
|
||||
topic-oriented wiki. So, this is kind of a seed project. Your help wanted!
|
||||
Please grab a file, make an edit, submit a PR, and then update the wiki page
|
||||
with `{{old}}` and a link to the shiny new document.
|
||||
240
en-US/java.adoc
Normal file
240
en-US/java.adoc
Normal file
|
|
@ -0,0 +1,240 @@
|
|||
= Java
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/Java
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
__TOC__
|
||||
|
||||
Java is about:
|
||||
|
||||
* Communities: the https://www.jcp.org/[Java Comunity Process] to define
|
||||
the platform, but also
|
||||
https://community.oracle.com/community/java/jug[Java User Groups]
|
||||
* Platforms (JVM, JRE ...) to run applications on PC, mobiles, embedded
|
||||
devices https://en.wikipedia.org/wiki/Java_(software_platform)
|
||||
* Programming languages (Java is the most popular, but there are Scala,
|
||||
Groovy, Clojure ...)
|
||||
https://en.wikipedia.org/wiki/Java_(programming_language)
|
||||
|
||||
What do you want to do:
|
||||
|
||||
* If you came here because an *application ask for Java* (or JRE, JVM)
|
||||
*to be installed*, then simply install .
|
||||
* If it still does not work:
|
||||
** Install javafx and icedtea-web packages as well.
|
||||
** Lastly, and if the application *ask specifically for
|
||||
http://www.oracle.com/technetwork/java/javase/index.html[Oracle Java]*:
|
||||
See here #Oracle_version.
|
||||
* If *you want to develop, code, on the Java Platform*: See
|
||||
Java/Development.
|
||||
|
||||
[[jre-jdk-jvm-jse-...]]
|
||||
JRE JDK JVM JSE ...
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Some vocabulary, if you are lost:
|
||||
|
||||
* *JRE* Java Runtime Environment. Required to run Java code and
|
||||
applications. Install .
|
||||
* *JVM* Java Virtual Machine. Main component of the JRE.
|
||||
* *JDK* Java Development Kit. Required only for development, coding.
|
||||
* *SDK* Software Development Kit. idem JDK
|
||||
* *JavaWS* https://en.wikipedia.org/wiki/Java_Web_Start[Java Web Start]
|
||||
is a framework to start application from the Internet
|
||||
* *JavaFX* https://en.wikipedia.org/wiki/JavaFX[JavaFX] is a plateform
|
||||
to create and deliver desktop and Rich Internet Apps.
|
||||
* *OpenJFX* is the JavaFX Open Source implementation
|
||||
* *OpenJDK* Open Source project behind the Java Platform
|
||||
http://openjdk.java.net/.
|
||||
* *IcedTea* is a support project for OpenJDK (concern only developers)
|
||||
http://icedtea.classpath.org/
|
||||
* *IcedTea-Web* is the Java Web Start package (It contains only JavaWS,
|
||||
No Applets anymore.) Install to run *JNPL* files.
|
||||
* *Applets* Obsolete techno. Not implemented in any recent package.
|
||||
* *JSE*, *J2SE*, *JEE* ... obsolete acronyms for **J**ava **S**tandard &
|
||||
**E**nterprise **E**dition. _JavaSE_ is like _JRE_.
|
||||
|
||||
[[what-is-in-java-openjdk-package]]
|
||||
What is in Java OpenJDK package
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
For most users, it is just another system library. It is not an
|
||||
application with a GUI, but it is required by some other applications to
|
||||
run. You might see a _OpenJDK Policy tool_ desktop application that
|
||||
comes with the package, but you should not have to use it.
|
||||
|
||||
Beware that JavaFX and JavaWS are packaged separately!
|
||||
|
||||
[[multiple-implementations]]
|
||||
Multiple implementations
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Fedora provides the Free . If this Open Source stack does not fulfil
|
||||
your requirements. Alternatives can be installed alongside or
|
||||
separately.
|
||||
|
||||
The **J**ava **C**ommunity **P**rocess defines the specifications of the
|
||||
platform that many implements (IBM J9, Jikes, Zing, Zulu Dalvik ...). We
|
||||
will only focus on Oracle here.
|
||||
|
||||
Multiple implementations can be installed side-by-side without
|
||||
interfering:
|
||||
|
||||
* The link:alternatives_system[alternatives system] allows to switch
|
||||
from one to another.
|
||||
* An application can directly reference a specific Java installation
|
||||
* Some applications include a java platform, it is then transparent for
|
||||
the user. (But the package is bigger.)
|
||||
|
||||
[[oracle-version]]
|
||||
Oracle version
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
Some applications still ask for Oracle's implementation. It is mostly
|
||||
based on the OpenJDK Open Source project, but there is proprietary code
|
||||
and Fedora does not package non-free software.
|
||||
|
||||
Installing Oracle Java is fine. Just beware *not* to use Oracle *RPM*,
|
||||
as it will kill OpenJDK default packages!
|
||||
|
||||
Oracle provides a tarball:
|
||||
https://java.com/en/download/help/linux_x64_install.xml
|
||||
|
||||
We recommend to simply unpack the archives (tarball) to your home folder
|
||||
and set to path if necessary.
|
||||
|
||||
[[switching-alternatives]]
|
||||
Switching alternatives
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If you installed multiple Java implementations or version, you can
|
||||
configure your system to use one or another.
|
||||
|
||||
*Developers*: beware that javac has its own independent alternative.
|
||||
i.e. to change the JDK, use _alternatives ... javac_!
|
||||
|
||||
Switching is done using the link:alternatives_system[alternatives
|
||||
system] (_also used to change some other subsystems_). Java's subsystem
|
||||
name is surprisingly _java_ and typical commands include:
|
||||
|
||||
....
|
||||
# alternatives --display java
|
||||
....
|
||||
|
||||
....
|
||||
# alternatives --config java
|
||||
....
|
||||
|
||||
See alternative's own documentation for more information for usage and
|
||||
parts involved.
|
||||
|
||||
Should be noted that JRE implementations installed outside Fedora
|
||||
distribution, may not support alternatives and thus not be visible
|
||||
there. Then the symbolic links under directory _/etc/alternatives_ must
|
||||
be manually fixed.
|
||||
|
||||
[[java-packages-in-fedora]]
|
||||
Java packages in Fedora
|
||||
-----------------------
|
||||
|
||||
There are many aliases for OpenJDK package, see
|
||||
http://pkgs.fedoraproject.org/cgit/rpms/java-1.8.0-openjdk.git/tree/java-1.8.0-openjdk.spec
|
||||
or do "dnf repoquery --provides java-1.8.0-openjdk".
|
||||
|
||||
You can use any of the following names:
|
||||
|
||||
* java
|
||||
* java-1.8.0
|
||||
* java-1.8.0-openjdk
|
||||
* java-openjdk
|
||||
* jre
|
||||
* jre-1.8.0
|
||||
* jre-1.8.0-openjdk
|
||||
* jre-openjdk
|
||||
|
||||
....
|
||||
dnf install java-1.8.0-openjdk
|
||||
....
|
||||
|
||||
might be the most safe (until 1.8 is EOL.)
|
||||
|
||||
*Note* that Java Web Start (*JavaWS*) and *JavaFX* are packaged
|
||||
separately 'icedtea-web' and 'javafx' respectively.
|
||||
|
||||
Typically, without JavaFX, you may have error like:
|
||||
|
||||
....
|
||||
java -jar scram.jar
|
||||
Error: Could not find or load main class com.frequal.scram.designer.jfx.Main
|
||||
....
|
||||
|
||||
....
|
||||
dnf install icedtea-web javafx
|
||||
....
|
||||
|
||||
[[communicate]]
|
||||
Communicate
|
||||
-----------
|
||||
|
||||
You can subscribe to
|
||||
https://admin.fedoraproject.org/mailman/listinfo/java-devel[java-devel
|
||||
list] or talk to us in irc://irc.freenode.net/fedora-java[#fedora-java]
|
||||
Freenode IRC channel. Read Communicate page for more information.
|
||||
|
||||
[[see-also]]
|
||||
See Also
|
||||
--------
|
||||
|
||||
* Java/FAQ
|
||||
* Java/Troubleshooting
|
||||
* https://Ask.FedoraProject.org/en/questions/scope:all/sort:activity-desc/tags:java/page:1/[Ask
|
||||
Fedora about Java]
|
||||
|
||||
* https://bugzilla.redhat.com/buglist.cgi?component=java-1.8.0-openjdk&product=Fedora&bug_status=NEW&bug_status=ASSIGNED&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&order=bugs.votes,bugs.bug_id[Java-1.8.0-OpenJDK
|
||||
bugs]
|
||||
|
||||
* SIGs/Java
|
||||
|
||||
[[references]]
|
||||
References
|
||||
----------
|
||||
|
||||
* http://openjdk.java.net/[OpenJDK Home]
|
||||
* https://wiki.openjdk.java.net/[OpenJDK Wiki]
|
||||
* http://jpackage.org/[Jpackage.org]
|
||||
|
||||
Category:Java Category:Language-specific_SIGs
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
255
en-US/jdk.adoc
Normal file
255
en-US/jdk.adoc
Normal file
|
|
@ -0,0 +1,255 @@
|
|||
= JDK on Fedora
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/JDK_on_Fedora
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
[[abstract]]
|
||||
Abstract
|
||||
~~~~~~~~
|
||||
|
||||
This page provides information about *JDK* installations on Fedora. (See
|
||||
also https://fedoraproject.org/wiki/Java[Java].)
|
||||
|
||||
This page will discuss mainly about Open JDK and Oracle JDK, how to
|
||||
install them, test and configure them on Fedora.
|
||||
|
||||
[[what-is-jdk]]
|
||||
What is JDK
|
||||
~~~~~~~~~~~
|
||||
|
||||
JDK or Java Development Kit is an implementation of Java Environment,
|
||||
Standard Edition and is required for Java development purposes.
|
||||
|
||||
[[openjdk-and-project-icedtea]]
|
||||
OpenJDK and project IcedTea
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
OpenJDK (Open Java Development Kit) is a free and open source
|
||||
implementation of the Java Platform, Standard Edition (Java SE). It is
|
||||
the result of an effort Sun Microsystems began in 2006. The
|
||||
implementation is licensed under the GNU General Public License (GNU
|
||||
GPL) with a linking exception. Were it not for the GPL linking
|
||||
exception, components that linked to the Java class library would be
|
||||
subject to the terms of the GPL license. OpenJDK is the official Java SE
|
||||
7 reference implementation. Fedora has shipped OpenJDK as default JRE
|
||||
implementation. It's based on Sun Microsystem's/Oracle's
|
||||
http://en.wikipedia.org/wiki/JavaOne[JavaOne] open source release and
|
||||
complemented by Red Hat's http://en.wikipedia.org/wiki/IcedTea[IcedTea]
|
||||
project that implements the missing third party components that
|
||||
Sun/Oracle could not release under free License.
|
||||
|
||||
About the installation, see
|
||||
https://developer.fedoraproject.org/tech/languages/java/java-installation.html[Developer.FedoraProject.Org/Java].
|
||||
|
||||
OpenJDK's *java.library.path*, shared librarary paths for i386 are:
|
||||
|
||||
....
|
||||
/usr/lib
|
||||
/usr/lib/jvm/java-1.?.0-openjdk-1.6.0.0.x86_64/jre/lib/
|
||||
....
|
||||
|
||||
and for x86_64:
|
||||
|
||||
....
|
||||
/usr/lib64
|
||||
/usr/lib/jvm/java-1.?.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/
|
||||
....
|
||||
|
||||
The JDK has as its primary components a collection of programming tools,
|
||||
including:
|
||||
|
||||
[[jdk-components]]
|
||||
JDK components
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
appletviewer – this tool can be used to run and debug Java applets
|
||||
without a web browser +
|
||||
apt – the annotation-processing tool +
|
||||
extcheck – a utility which can detect JAR-file conflicts +
|
||||
idlj – the IDL-to-Java compiler. This utility generates Java bindings
|
||||
from a given Java IDL file. +
|
||||
jabswitch – the Java Access Bridge. Exposes assistive technologies on
|
||||
Microsoft Windows systems. +
|
||||
java – the loader for Java applications. This tool is an interpreter and
|
||||
can interpret the class files generated by the javac compiler. Now a
|
||||
single launcher is used for both development and deployment. The old
|
||||
deployment launcher, jre, no longer comes with Sun JDK, and instead it
|
||||
has been replaced by this new java loader. +
|
||||
javac – the Java compiler, which converts source code into Java
|
||||
bytecode +
|
||||
javadoc – the documentation generator, which automatically generates
|
||||
documentation from source code comments +
|
||||
jar – the archiver, which packages related class libraries into a single
|
||||
JAR file. This tool also helps manage JAR files. +
|
||||
javafxpackager – tool to package and sign JavaFX applications +
|
||||
jarsigner – the jar signing and verification tool +
|
||||
javah – the C header and stub generator, used to write native methods +
|
||||
javap – the class file disassembler +
|
||||
javaws – the Java Web Start launcher for JNLP applications +
|
||||
JConsole – Java Monitoring and Management Console +
|
||||
jdb – the debugger +
|
||||
jhat – Java Heap Analysis Tool (experimental) +
|
||||
jinfo – This utility gets configuration information from a running Java
|
||||
process or crash dump. (experimental) +
|
||||
jmap – This utility outputs the memory map for Java and can print shared
|
||||
object memory maps or heap memory details of a given process or core
|
||||
dump. (experimental) +
|
||||
jmc – Java Mission Control +
|
||||
jps – Java Virtual Machine Process Status Tool lists the instrumented
|
||||
HotSpot Java Virtual Machines (JVMs) on the target system.
|
||||
(experimental) +
|
||||
jrunscript – Java command-line script shell. +
|
||||
jstack – utility which prints Java stack traces of Java threads
|
||||
(experimental) +
|
||||
jstat – Java Virtual Machine statistics monitoring tool (experimental) +
|
||||
jstatd – jstat daemon (experimental) +
|
||||
keytool – tool for manipulating the keystore +
|
||||
pack200 – JAR compression tool +
|
||||
policytool – the policy creation and management tool, which can
|
||||
determine policy for a Java runtime, specifying which permissions are
|
||||
available for code from various sources VisualVM – visual tool
|
||||
integrating several command-line JDK tools and lightweight clarification
|
||||
needed] performance and memory profiling capabilities +
|
||||
wsimport – generates portable JAX-WS artifacts for invoking a web
|
||||
service. +
|
||||
xjc – Part of the Java API for XML Binding (JAXB) API. It accepts an XML
|
||||
schema and generates Java classes. +
|
||||
Experimental tools may not be available in future versions of the JDK.
|
||||
|
||||
The JDK also comes with a complete Java Runtime Environment, usually
|
||||
called a private runtime, due to the fact that it is separated from the
|
||||
"regular" JRE and has extra contents. It consists of a Java Virtual
|
||||
Machine and all of the class libraries present in the production
|
||||
environment, as well as additional libraries only useful to developers,
|
||||
such as the internationalization libraries and the IDL libraries.
|
||||
|
||||
Copies of the JDK also include a wide selection of example programs
|
||||
demonstrating the use of almost all portions of the Java API. OpenJDK
|
||||
package name on Fedora is _java-1.?.0-openjdk_.
|
||||
|
||||
[[oracle-jdk]]
|
||||
Oracle JDK
|
||||
~~~~~~~~~~
|
||||
|
||||
Oracle provides JDK (Java Development Kit) for Java Developers. It
|
||||
includes a complete JRE plus tools for developing, debugging, and
|
||||
monitoring Java applications.
|
||||
|
||||
[[installing-oracle-jdk-on-fedora]]
|
||||
Installing Oracle JDK on Fedora
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
\1. Download the Oracle Java JDK
|
||||
http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html[here] +
|
||||
Note: download appropriate file, for example if your system is x64
|
||||
Fedora the download file is named like this: jdk-8u45-linux-x64.tar.gz +
|
||||
2. Create a folder named java in /usr/local/by this command:
|
||||
|
||||
....
|
||||
sudo mkdir -p /usr/local/java
|
||||
....
|
||||
|
||||
folder is created in root/usr/local/java +
|
||||
3. Copy the Downloaded file in the directory /usr/local/java. To do
|
||||
this, cd into directory where downloaded file is located and use this
|
||||
command for copying that file to /usr/local/java/:
|
||||
|
||||
....
|
||||
sudo cp -r jdk-8u40-linux-x64.tar.gz /usr/local/java
|
||||
....
|
||||
|
||||
\4. CD into /usr/local/java/ directory and extract that copied file by
|
||||
using this command:
|
||||
|
||||
....
|
||||
sudo tar xvzf jdk-8u45-linux-x64.tar.gz
|
||||
....
|
||||
|
||||
\5. After extraction you must see a folder named jdk1.8.0_45. +
|
||||
6. Update PATH file by opening /etc/profile file by the command
|
||||
|
||||
....
|
||||
sudo nano /etc/profile and paste the following at the end of the file:
|
||||
JAVA_HOME=/usr/local/java/jdk1.8.0_45
|
||||
PATH=$PATH:$HOME/bin:$JAVA_HOME/bin
|
||||
export JAVA_HOME
|
||||
export PATH
|
||||
....
|
||||
|
||||
> 7. Save and exit. +
|
||||
8. Tell the system that the new Oracle Java version is available by the
|
||||
following commands:
|
||||
|
||||
....
|
||||
sudo update-alternatives --install "/usr/bin/java" "java" "/usr/local/java/jdk1.8.0_45/bin/java" 1
|
||||
sudo update-alternatives --install "/usr/bin/javac" "javac" "/usr/local/java/jdk1.8.0_45/bin/javac" 1
|
||||
sudo update-alternatives --install "/usr/bin/javaws" "javaws" "/usr/local/java/jdk1.8.0_45/bin/javaws" 1
|
||||
....
|
||||
|
||||
\9. Make Oracle Java JDK as default by this following commands:
|
||||
|
||||
....
|
||||
sudo update-alternatives --set java /usr/local/java/jdk1.8.0_45/bin/java
|
||||
sudo update-alternatives --set javac /usr/local/java/jdk1.8.0_45/bin/javac
|
||||
sudo update-alternatives --set javaws /usr/local/java/jdk1.8.0_45/bin/javaws
|
||||
....
|
||||
|
||||
\10. Reload sytem wide PATH /etc/profile by this command:
|
||||
|
||||
....
|
||||
source /etc/profile
|
||||
....
|
||||
|
||||
\11. Reboot your system.
|
||||
|
||||
....
|
||||
reboot
|
||||
....
|
||||
|
||||
\12. Check Java JDK version by java -version command . If installation
|
||||
is succesful, it will display like the following:
|
||||
|
||||
....
|
||||
java version "1.8.0_45"
|
||||
Java(TM) SE Runtime Environment (build 1.8.0_45-xxx)
|
||||
Java HotSpot(TM) Server VM (build 25.45-xxx, mixed mode)
|
||||
....
|
||||
|
||||
That's it! Note: We Assumed that the downloaded file is named
|
||||
jdk-8u45-linux-x64.tar.gz and used this name in all the commands used in
|
||||
steps 2, 4 and 5. It may depends on the type of O.S, processor type
|
||||
(i.e., 32bit or 64bit)
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
262
en-US/kernel.adoc
Normal file
262
en-US/kernel.adoc
Normal file
|
|
@ -0,0 +1,262 @@
|
|||
= Kernel
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/Kernel
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
Assorted information related to the Fedora Linux kernel.
|
||||
|
||||
[[current-versions]]
|
||||
Current versions
|
||||
----------------
|
||||
|
||||
[cols=",,,",]
|
||||
|=======================================================================
|
||||
|Release |Version |MotM |Comments
|
||||
|
||||
|F25 |4.13.x |labbott |
|
||||
|
||||
|F26 |4.13.x |labbott |
|
||||
|
||||
|F27 |4.13.x |labbott |
|
||||
|
||||
|Rawhide |Latest mainline (4.14.x) |jforbes |Pretty much always the
|
||||
latest mainline tree.
|
||||
|=======================================================================
|
||||
|
||||
Each upstream major kernel release has a maintainer that follows the
|
||||
release through from merge window until it is no longer in a supported
|
||||
Fedora release. The field above shows which kernel releases match up
|
||||
with current Fedora releases, and who is maintaining that particular
|
||||
kernel. For example, labbott is maintaining 4.4 kernels in Fedora 22 and
|
||||
23, jforbes is maintaining 4.5 kernels in F24, and will maintain F22 and
|
||||
F23 as they are rebased to 4.5. If in doubt, send mail to the kernel
|
||||
list (info below) rather than individuals. The maintainers are part of
|
||||
the link:Fedora_Engineering[Fedora Engineering] team.
|
||||
|
||||
[[fedora-kernel-mailing-list]]
|
||||
Fedora kernel mailing list
|
||||
--------------------------
|
||||
|
||||
For discussion about Fedora related kernel package issues only. For "my
|
||||
kernel module doesn't work" type messages, see the
|
||||
http://kernelnewbies.org list, or linux-kernel.
|
||||
|
||||
[[irc]]
|
||||
IRC
|
||||
---
|
||||
|
||||
Join the channel on freenode.net.
|
||||
|
||||
[[source-checkout-info]]
|
||||
Source checkout info
|
||||
--------------------
|
||||
|
||||
....
|
||||
fedpkg co kernel
|
||||
....
|
||||
|
||||
This gets you the git checkout and sets up branches for the current
|
||||
releases and master (devel). Once you have switched to the branch you
|
||||
care about (with git checkout branchname), fedpkg prep will create a
|
||||
tree.
|
||||
|
||||
You'll then be left with a kernel-3.X.? directory, containing both an
|
||||
unpatched 'vanilla-3.X.?' dir, and a linux-3.X.?-noarch hardlinked dir
|
||||
which has the Fedora patches applied.
|
||||
|
||||
The above command will require you to have SSH access to the Fedora
|
||||
pkg-git archives. If you want to do an anonymous checkout of the
|
||||
sources, you can use:
|
||||
|
||||
....
|
||||
fedpkg co -a kernel
|
||||
....
|
||||
|
||||
[[contributing-to-the-fedora-kernel]]
|
||||
Contributing to the Fedora kernel
|
||||
---------------------------------
|
||||
|
||||
* If you are sending patches for the first time, there is a
|
||||
link:Kernel/FirstKernelPatch[ guide] to help you.
|
||||
* For one-off fixes, send them to the Fedora kernel mailing list, or if
|
||||
they are relevant upstream, send them directly to
|
||||
linux-kernel@vger.kernel.org and Fedora will inherit them on the next
|
||||
rebase
|
||||
* If you are sending lots of changes to the Fedora kernel, then it may
|
||||
make more sense for you to get commit access. (Note, for most things,
|
||||
sending them upstream is far more preferable).
|
||||
* To request commit access to the Fedora kernel:
|
||||
* Get a link:PackageMaintainers/Join[fedora account] if you don't
|
||||
already have one
|
||||
* Visit https://admin.fedoraproject.org/pkgdb/acls/name/kernel[the
|
||||
package db entry for the kernel] and request access for the branch(es)
|
||||
which interest you.
|
||||
* *Please* subscribe to the mailing list above. Important announcements
|
||||
regarding rebases, builds, patches being disabled, and much more happen
|
||||
there.
|
||||
* If you're interested in adding an out-of-tree driver or similar to the
|
||||
Fedora kernel, please read KernelDriverPolicy first. See
|
||||
KernelStagingPolicy also.
|
||||
* Here is a brief overview of the link:Kernel/Spec[kernel.spec] file
|
||||
|
||||
[[building]]
|
||||
Building
|
||||
--------
|
||||
|
||||
Fedora's kernels are signed during the build via the pesign client on a
|
||||
specific set of machines. To limit exposure of officially signed builds,
|
||||
only certain people can successfully submit builds that will be tagged
|
||||
into the various koji target tags. If you are not in this ACL then your
|
||||
build will start, but it will fail in the final tagging step. Scratch
|
||||
builds are not subject to this, so it is recommended to use that. If you
|
||||
want the ability to build kernels that go out to end-users when you
|
||||
'fedpkg build', you need to be in the ACLs that allow builds to be
|
||||
tagged.
|
||||
|
||||
Please note the caveats on official builds.
|
||||
|
||||
* The kernel package currently builds many rpms, which means it ties up
|
||||
the build system for hours at a time. For this reason, coordinate with
|
||||
other developers on irc/fedora-kernel-list to be sure there isn't more
|
||||
than one build happening at once.
|
||||
* Rawhide gets pushed once a day. If you think a build may occur later
|
||||
in the day for some reason, hold off on building. If in doubt, ask.
|
||||
* If you are checking in patches for any branch other than rawhide, the
|
||||
build won't automatically go out to users, it needs to be processed
|
||||
through http://bodhi.fedoraproject.org[bodhi] . Consider the negative
|
||||
effect of flooding end-users with too many updates, and coordinate your
|
||||
builds with others so that we push updates containing more than one fix.
|
||||
* For the end-user who wants to build a custom kernel, we offer a
|
||||
separate wiki page link:Building_a_custom_kernel[ with complete
|
||||
instructions].
|
||||
|
||||
[[updates]]
|
||||
Updates
|
||||
-------
|
||||
|
||||
[[process]]
|
||||
Process
|
||||
^^^^^^^
|
||||
|
||||
As mentioned above, updates have to go through bodhi. Below is the
|
||||
process we use for filing a kernel update in bodhi.
|
||||
|
||||
* Fill in the package NVR, the bugs it fixes, and any notes you would
|
||||
like to include. Normally this is simply "The stable update contains a
|
||||
number of important fixes across the tree", or for a rebase "The rebase
|
||||
contains improved hardware support, a number of new features, and many
|
||||
important fixes across the tree."
|
||||
* Ensure 'Suggest Reboot' is selected
|
||||
* Ensure 'Enable karma automatism' is *not* selected
|
||||
* Watch the commentary on the update, ensure bugs are filed for negative
|
||||
karma, etc
|
||||
* After the update has been in updates-testing for a decent amount of
|
||||
time and has significantly positive karma (these are relative), push it
|
||||
to stable.
|
||||
|
||||
With the wide variety of hardware and use cases Fedora users have, we
|
||||
have found that enabling auto-karma can be detrimental. Often testers
|
||||
will give positive karma for their use cases, hit the auto-karma limit,
|
||||
and the update will be queued for stable before it even hits
|
||||
updates-testing. That significantly reduces the tester pool and can
|
||||
cause an update that introduces issues for a significant number of
|
||||
people to be pushed to stable. We delay intentionally to try and catch
|
||||
these cases. While we will never achieve a perfect update, it has helped
|
||||
quite a bit.
|
||||
|
||||
[[schedule]]
|
||||
Schedule
|
||||
^^^^^^^^
|
||||
|
||||
For stable Fedora branches, the updates essentially follow the upstream
|
||||
stable release schedule. Those tend to be released once a week or
|
||||
slightly less frequently. We do the minor update, build and submit,
|
||||
making sure that the N-1 update is in stable before pushing that release
|
||||
(unless N-1 is very broken.) E.g. When 3.19.2 is released, we push it to
|
||||
testing and make sure 3.19.1 is at least queued for stable. That way
|
||||
bodhi doesn't obsolete the 3.19.1 update. When we have a major rebase
|
||||
for a stable Fedora branch, we follow the same guidelines as above but
|
||||
simply allow more time for people to test.
|
||||
|
||||
For a Fedora release in link:Releases/Branched[Branched] state, we tend
|
||||
to file updates at each relevant upstream milestone release. E.g. if
|
||||
that branch is working through the 4.0-rcX releases, we file an update
|
||||
once per -rc. As the Fedora release gets closer to GA, the kernel being
|
||||
shipped will transition to a stable upstream release. Then we
|
||||
essentially follow the same steps as above.
|
||||
|
||||
As mentioned in the previous section, Rawhide does not use bodhi for
|
||||
updates.
|
||||
|
||||
[[policies]]
|
||||
Policies
|
||||
--------
|
||||
|
||||
Below are some of the policies we use when it comes to various aspects
|
||||
of the Fedora kernel
|
||||
|
||||
* KernelRebases
|
||||
* KernelDriverPolicy
|
||||
* KernelStagingPolicy
|
||||
* KernelBuiltinPolicy
|
||||
* Information on the various debugging options used in Fedora kernels
|
||||
can be found at KernelDebugStrategy
|
||||
|
||||
[[other-handy-links]]
|
||||
Other handy links
|
||||
-----------------
|
||||
|
||||
* link:Kernel/TaskWishList[ Contribution ideas for the Fedora kernel ]
|
||||
* link:Kernel/SubmittingUpstream[ How to submit a patch upstream]
|
||||
* link:Kernel/DayToDay[ How to do various day to day tasks]
|
||||
* KernelCommonProblems
|
||||
* KernelBugTriage
|
||||
* link:Building_a_custom_kernel[Building a custom kernel]
|
||||
* link:Building_a_custom_kernel#Building_a_non-debugging_kernel[
|
||||
Building a non-debugging kernel ]
|
||||
* link:How_to_use_kdump_to_debug_kernel_crashes[How to use kdump to
|
||||
debug kernel crashes]
|
||||
* link:Kernel/EarlyDebugging[ How to debug very early kernel panics]
|
||||
* Information on building upstream kernels by hand for testing can be
|
||||
found at link:Building_a_custom_kernel#Building_Vanilla_upstream_kernel[
|
||||
Building a vanilla kernel]
|
||||
* https://admin.fedoraproject.org/updates/kernel[Kernel Updates]
|
||||
* KernelTestingInitiative
|
||||
* QA:Testcase_kernel_regression
|
||||
* RawhideKernelNodebug The repository for rawhide kernels built without
|
||||
debugging enabled.
|
||||
* link:Kernel/UsbmonOuput[ Capturing USBMON output]
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
562
en-US/live-usb.adoc
Normal file
562
en-US/live-usb.adoc
Normal file
|
|
@ -0,0 +1,562 @@
|
|||
= How to create and use Live USB
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
image:mediawriter-icon.png[mediawriter-icon.png,title="mediawriter-icon.png"]
|
||||
|
||||
This page explains *how to create and use Fedora USB media*. You can
|
||||
write all https://getfedora.org/[Fedora ISO images] to a USB stick,
|
||||
making this a convenient way on any USB-bootable computer to either
|
||||
install Fedora or try a 'live' Fedora environment without writing to the
|
||||
computer's hard disk. You will need a USB stick at least as large as the
|
||||
image you wish to write.
|
||||
|
||||
[[quickstart-using-fedora-media-writer]]
|
||||
Quickstart: Using Fedora Media Writer
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
image:Fedora_Live_USB_creator.png[Fedora Media Writer
|
||||
screenshot,title="Fedora Media Writer screenshot"]
|
||||
|
||||
For most cases, the best tool to create a Fedora USB stick is the
|
||||
https://github.com/MartinBriza/MediaWriter[Fedora Media Writer] utility,
|
||||
which was formerly known as LiveUSB Creator. It is available on Fedora,
|
||||
other Linux distributions using http://flatpak.org/[Flatpak], Windows
|
||||
and macOS.
|
||||
|
||||
Fedora Media Writer is graphical and easy to use. It can download recent
|
||||
Fedora images for you as well as writing them to the USB stick.
|
||||
|
||||
On Fedora, you can use a Fedora graphical software installation tool to
|
||||
install the package, or use the command line:
|
||||
|
||||
On Windows and macOS, you can download the installer from
|
||||
https://github.com/MartinBriza/MediaWriter/releases[the releases page].
|
||||
On other Linux distributions, if they support the
|
||||
http://flatpak.org/[Flatpak] application distribution system, you can
|
||||
download a flatpak from
|
||||
https://github.com/MartinBriza/MediaWriter/releases[the releases page].
|
||||
|
||||
To run the tool, look for *Fedora Media Writer* in the system menus.
|
||||
When you start Fedora Media Writer, the three dots in the bottom will be
|
||||
flashing while the tool checks for a new Fedora release.
|
||||
|
||||
To write the stick:
|
||||
|
||||
1. Choose which Fedora flavor you want to install or try.
|
||||
+
|
||||
::
|
||||
On the title screen, you can choose Workstation, Server or your own
|
||||
.iso file. Other choices (including KDE, Cinnamon, Xfce and so on) are
|
||||
under the "..." button at the bottom of the list.
|
||||
2. Ensure your USB stick is plugged into the system.
|
||||
3. Click _Create Live USB_.
|
||||
4. Ensure the right stick is selected.
|
||||
5. Click _Write to disk_ and wait for the write to complete.
|
||||
6. Once the stick has been written, shut the system down and boot it
|
||||
from the USB stick (see link:#booting[the Booting section]).
|
||||
|
||||
After writing, your USB stick will have a changed partition layout and
|
||||
some systems may report it to be about 10MB large. To return your USB
|
||||
stick to its factory configuration, insert the drive again while Fedora
|
||||
Media Writer is running. The app provides you with an option to restore
|
||||
to the factory layout. This layout includes a single VFAT partition.
|
||||
|
||||
__TOC__
|
||||
|
||||
[[booting-from-usb-sticks]]
|
||||
Booting from USB sticks
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
image:Bios_USB_boot.jpg[Set USB as first boot device. Your BIOS may be
|
||||
different.,title="Set USB as first boot device. Your BIOS may be different."]
|
||||
|
||||
Almost all modern PCs can boot from USB sticks (some very old ones may
|
||||
not be able to). However, precisely how you tell the system to boot from
|
||||
a USB stick varies substantially from system to system. First, just try
|
||||
this:
|
||||
|
||||
1. Power off the computer.
|
||||
2. Plug the USB drive into a USB port.
|
||||
3. Remove all other portable media, such as CDs, DVDs, floppy disks or
|
||||
other USB sticks.
|
||||
4. Power on the computer.
|
||||
5. If the computer is configured to automatically boot from the USB
|
||||
drive, you will see a screen that says "Automatic boot in 10 seconds..."
|
||||
with a countdown (unless you do a native UEFI boot, where you will see a
|
||||
rather more minimal boot menu).
|
||||
|
||||
If the computer starts to boot off the hard drive as normal, you'll need
|
||||
to manually configure it to boot off the USB drive. Usually, that should
|
||||
work something like this:
|
||||
|
||||
1. Wait for a safe point to reboot.
|
||||
2. As the machine starts to reboot, watch carefully for instructions on
|
||||
which key to press (usually a function key, Escape, Tab or Delete) to
|
||||
enter the boot device selection menu, "BIOS setup", "firmware", or
|
||||
"UEFI". Press and hold that key. If you miss the window of opportunity
|
||||
(often only a few seconds) then reboot and try again.
|
||||
3. Use the firmware ("BIOS") interface or the boot device menu to put
|
||||
your USB drive first in the boot sequence. It might be listed as a hard
|
||||
drive rather than a removable drive. Each hardware manufacturer has a
|
||||
slightly different method for doing so.
|
||||
+
|
||||
::
|
||||
*Be careful!* Your computer could become unbootable or lose
|
||||
functionality if you change any other settings. Though these settings
|
||||
can be reverted, you'll need to remember what you changed in order to
|
||||
do so.
|
||||
4. Save the changes, exit, and the computer should boot from the USB
|
||||
drive.
|
||||
|
||||
If your system has a link:Unified_Extensible_Firmware_Interface[UEFI]
|
||||
firmware, it will usually allow you to boot the stick in UEFI native
|
||||
mode or BIOS compatibility mode. If you boot in UEFI native mode and
|
||||
perform a Fedora installation, you will get a UEFI native Fedora
|
||||
installation. If you boot in BIOS compatibility mode and perform a
|
||||
Fedora installation, you will get a BIOS compatibility mode Fedora
|
||||
installation. For more information on all this, see the
|
||||
link:Unified_Extensible_Firmware_Interface[UEFI page]. USB sticks
|
||||
written from x86_64 images with link:#fmw[Fedora Media Writer],
|
||||
link:#gnome[GNOME Disk Utility], link:#dd[dd], other dd-style utilities,
|
||||
and link:#litd[livecd-iso-to-disk] with should be UEFI native bootable.
|
||||
Sticks written with other utilities may not be UEFI native bootable, and
|
||||
sticks written from i686 images will never be UEFI bootable.
|
||||
|
||||
[[checking-usb-disk-size-free-space]]
|
||||
Checking USB disk size / free space
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
As noted before, the disk must have a certain amount of storage space
|
||||
depending on the image you select. If you use a destructive method, the
|
||||
stick must be at least the size of the image; if you use a
|
||||
non-destructive method, it must have at least that much free space.
|
||||
Whichever operating system you are using, you can usually check this
|
||||
with a file manager, usually by right clicking and selecting
|
||||
_Properties_. Here is a screenshot of how this looks on GNOME:
|
||||
|
||||
image:Properties_USB_size.png[thumb|350px|none]
|
||||
|
||||
[[identifying-a-stick-by-name-on-linux]]
|
||||
Identifying a stick by name on Linux
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Most of the link:#writing[alternative writing methods] will require you
|
||||
to know the name for your USB stick - e.g. - when using them on Linux.
|
||||
You do not need to know this in order to use link:#fmw[Fedora Media
|
||||
Writer]. To find this out:
|
||||
|
||||
1. Insert the USB stick into a USB port.
|
||||
2. Open a terminal and run .
|
||||
3. Near the end of the output, you will see something like:
|
||||
|
||||
....
|
||||
[32656.573467] sd 8:0:0:0: [sdX] Attached SCSI removable disk
|
||||
....
|
||||
|
||||
where sdX will be sdb, sdc, sdd, etc. *Take note of this label* as it is
|
||||
the name of the disk you will use. We'll call it _sdX_ from now on. If
|
||||
you have connected more than one USB stick to the system, be careful
|
||||
that you identify the correct one - often you will see a manufacturer
|
||||
name or capacity in the output which you can use to make sure you
|
||||
identified the correct stick.
|
||||
|
||||
[[alternative-usb-stick-writing-methods]]
|
||||
Alternative USB stick writing methods
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
As explained above, the recommended method for writing the stick in most
|
||||
cases is link:#fmw[Fedora Media Writer]. In this section, other tools
|
||||
which may be useful in specific circumstances are documented.
|
||||
|
||||
[[using-gnome-disk-utility-linux-graphical-destructive]]
|
||||
Using GNOME Disk Utility (Linux, graphical, destructive)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
This method is for people running Linux (or another *nix) with GNOME,
|
||||
Nautilus and the GNOME Disk Utility installed. Particularly, if you are
|
||||
using a distribution other than Fedora which does not support Flatpak,
|
||||
this may be the easiest available method. A standard installation of
|
||||
Fedora, or a standard GNOME installation of many other distributions,
|
||||
should be able to use this method. On Fedora, ensure the packages and
|
||||
are installed. Similar graphical direct-write tools may be available for
|
||||
other desktops, or you may use the link:#dd[command line "direct write"
|
||||
method].
|
||||
|
||||
1. Download a Fedora image, choose a USB stick that does not contain
|
||||
any data you need, and connect it
|
||||
2. Run Nautilus (Files) - for instance, open the Overview by pressing
|
||||
the Start/Super key, and type _Files_, then hit enter
|
||||
3. Find the downloaded image, right-click on it, go to *Open With*, and
|
||||
click *Disk Image Writer*
|
||||
4. Double-check you're really, really sure you don't need any of the
|
||||
data on the USB stick!
|
||||
5. Select your USB stick as the *Destination*, and click *Start
|
||||
Restoring...*
|
||||
|
||||
[[command-line-method-using-the-livecd-iso-to-disk-tool-fedora-only-non-graphical-both-non-destructive-and-destructive-methods-available]]
|
||||
Command line method: Using the _livecd-iso-to-disk_ tool (Fedora only,
|
||||
non-graphical, both non-destructive and destructive methods available)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The method is slightly less reliable than Fedora Media Writer and can be
|
||||
used reliably only from within Fedora: it does not work in Windows or OS
|
||||
X, and is not supported (and will usually fail) in non-Fedora
|
||||
distributions. However, it supports three advanced features which FMW
|
||||
does not include:
|
||||
|
||||
1. You may use a _non-destructive_ method to create the stick, meaning
|
||||
existing files on the stick will not be destroyed. This is less reliable
|
||||
than the _destructive_ write methods, and should be used only if you
|
||||
have no stick you can afford to wipe.
|
||||
2. On live images, you can include a feature called a _persistent
|
||||
overlay_, which allows changes made to persist across reboots. You can
|
||||
perform updates just like a regular installation to your hard disk,
|
||||
except that kernel updates require link:#Kernel_updates[manual
|
||||
intervention] and link:#limited_overlay[overlay space may be
|
||||
insufficient]. Without a _persistent overlay_, the stick will return to
|
||||
a fresh state each time it is booted.
|
||||
3. On live images, you can also have a separate area to store user
|
||||
account information and data such as documents and downloaded files,
|
||||
with optional encryption for security and peace of mind.
|
||||
|
||||
By combining these features, you can carry your computer with you in
|
||||
your pocket, booting it on nearly any system you find yourself using.
|
||||
|
||||
It is not a good idea to try and write a new Fedora release using the
|
||||
version of in a much older Fedora release: it is best to only use a
|
||||
release a maximum of two versions older than the release you are trying
|
||||
to write.
|
||||
|
||||
Ensure the package is installed:
|
||||
|
||||
Basic examples follow. Remember to link:#device[identify your USB
|
||||
stick's device name] first. In all cases, you can add the parameter to
|
||||
(try to) render the stick bootable in native UEFI mode. Detailed usage
|
||||
information is available by running: or .
|
||||
|
||||
To make an existing USB stick bootable as a Fedora image - without
|
||||
deleting any of the data on it - make sure that the USB drive is not
|
||||
mounted before executing the following, and give the root password when
|
||||
prompted:
|
||||
|
||||
::
|
||||
|
||||
In case it is not possible to boot from a disk created with the method
|
||||
shown above, before re-partitioning and re-formatting, often resetting
|
||||
the master boot record will enable booting:
|
||||
|
||||
::
|
||||
|
||||
If necessary, you can have _livecd-iso-to-disk_ re-partition and
|
||||
re-format the target stick:
|
||||
|
||||
::
|
||||
|
||||
To include a persistent filesystem for , use the parameter. For example:
|
||||
|
||||
::
|
||||
|
||||
This will create a 2 GiB filesystem that will be mounted as each time
|
||||
the stick is booted, allowing you to preserve data in across boots.
|
||||
|
||||
To enable 'data persistence' support - so changes you make to the entire
|
||||
live environment will persist across boots - add the parameter to add a
|
||||
persistent data storage area to the target stick. For example:
|
||||
|
||||
::
|
||||
|
||||
where 2048 is the desired size (in megabytes) of the overlay. The
|
||||
_livecd-iso-to-disk_ tool will not accept an overlay size value greater
|
||||
than 4095 for VFAT, but for ext[234] filesystems it is only limited by
|
||||
the available space.
|
||||
|
||||
You can combine and , in which case data written to will not exhaust the
|
||||
persistent overlay.
|
||||
|
||||
[[command-line-direct-write-method-most-operating-systems-non-graphical-destructive]]
|
||||
Command line "direct write" method (most operating systems,
|
||||
non-graphical, destructive)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
This method direct writes the image to the USB stick much like
|
||||
link:#fmw[Fedora Media Writer] or link:#gnome[GNOME Disk Utility], but
|
||||
uses a command line utility named . Like the other "direct write"
|
||||
methods, it will destroy all data on the stick and does not support any
|
||||
of the advanced features like data persistence, but it is a very
|
||||
reliable method. The tool is available on most Unix-like operating
|
||||
systems, including Linux distributions and OS X, and
|
||||
http://www.chrysocome.net/dd[a Windows port is available]. This may be
|
||||
your best method if you cannot use Fedora Media Writer or GNOME Disk
|
||||
Utility, or just if you prefer command line utilities and want a simple,
|
||||
quick way to write a stick.
|
||||
|
||||
1. link:#device[Identify the name of the USB drive partition]. If using
|
||||
this method on Windows, with the port linked above, the command should
|
||||
provide you with the correct name.
|
||||
2. *Unmount all mounted partition from that device.* This is very
|
||||
important, otherwise the written image might get corrupted. You can
|
||||
umount all mounted partitions from the device with , where X is the
|
||||
appropriate letter, e.g.
|
||||
3. Write the ISO file to the device:
|
||||
+
|
||||
::
|
||||
4. Wait until the command completes.
|
||||
+
|
||||
::
|
||||
If you see , your dd version doesn't support the option and you'll
|
||||
need to remove it (and you won't see writing progress).
|
||||
|
||||
[[using-unetbootin-windows-os-x-and-linux-graphical-non-destructive]]
|
||||
Using http://unetbootin.sourceforge.net/[UNetbootin] (Windows, OS X and
|
||||
Linux, graphical, non-destructive)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
image:Unetbootin_gtk3.png[Unetbootin
|
||||
screenshot,title="Unetbootin screenshot"]
|
||||
|
||||
While your results may vary, it is usually the case that the
|
||||
link:#fmw[Fedora Media Writer], link:#litd[livecd-iso-to-disk],
|
||||
link:#gnome[GNOME] and link:#dd[dd] methods give better results than
|
||||
UNetbootin. If you encounter problems with UNetbootin, please contact
|
||||
the UNetbootin developers, not the Fedora developers.
|
||||
|
||||
UNetbootin is a graphical, bootable USB image creator. Using it will
|
||||
allow you to preserve any data you have in the USB drive. If you have
|
||||
trouble booting, however, you may wish to try with a blank, cleanly
|
||||
FAT32-formatted drive.
|
||||
|
||||
If you are running a 64-bit Linux distribution, UNetbootin may fail to
|
||||
run until you install the 32-bit versions of quite a lot of system
|
||||
libraries. Fedora cannot help you with this: please direct feedback on
|
||||
this issue to the UNetbootin developers.
|
||||
|
||||
1. Download the latest UNetbootin version from
|
||||
http://unetbootin.sourceforge.net/[the official site] and install it. On
|
||||
Linux, the download is an executable file: save it somewhere, change it
|
||||
to be executable (using or a file manager), and then run it.
|
||||
2. Launch UNetbootin. On Linux, you might have to type the root
|
||||
password.
|
||||
3. Click on *Diskimage* and search for the ISO file you downloaded.
|
||||
4. Select Type: USB drive and link:#device[choose the correct device
|
||||
for your stick]
|
||||
5. Click OK
|
||||
|
||||
[[creating-a-usb-stick-from-a-running-live-environment]]
|
||||
Creating a USB stick from a running live environment
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If you are already running a live CD, DVD, or USB and want to convert
|
||||
that into a bootable USB stick, run the following command:
|
||||
|
||||
::
|
||||
|
||||
See link:#Mounting_a_Live_USB_filesystem[this section] for mounting the
|
||||
root filesystem outside of a boot.
|
||||
|
||||
[[troubleshooting]]
|
||||
Troubleshooting
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
[[fedora-media-writer-problems]]
|
||||
Fedora Media Writer problems
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
* Bugs can be reported to
|
||||
https://github.com/MartinBriza/MediaWriter/issues[GitHub] or
|
||||
https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=mediawriter[Bugzilla].
|
||||
You can http://bugz.fedoraproject.org/mediawriter[browse existing
|
||||
Bugzilla reports]. Please report any problems you encounter that have
|
||||
not already been reported.
|
||||
|
||||
[[livecd-iso-to-disk-problems]]
|
||||
livecd-iso-to-disk problems
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
[[partition-isnt-marked-bootable]]
|
||||
Partition isn't marked bootable!
|
||||
++++++++++++++++++++++++++++++++
|
||||
|
||||
If you get the message , you need to mark the partition bootable. To do
|
||||
this, run , and use the command, where X is the appropriate letter and N
|
||||
is the partition number. For example:
|
||||
|
||||
....
|
||||
$ parted /dev/sdb
|
||||
GNU Parted 1.8.6
|
||||
Using /dev/sdb
|
||||
Welcome to GNU Parted! Type 'help' to view a list of commands.
|
||||
(parted) print
|
||||
Model: Imation Flash Drive (scsi)
|
||||
Disk /dev/sdX: 1062MB
|
||||
Sector size (logical/physical): 512B/512B
|
||||
Partition Table: msdos
|
||||
|
||||
Number Start End Size Type File system Flags
|
||||
1 32.3kB 1062MB 1062MB primary fat16
|
||||
|
||||
(parted) toggle 1 boot
|
||||
(parted) print
|
||||
Model: Imation Flash Drive (scsi)
|
||||
Disk /dev/sdX: 1062MB
|
||||
Sector size (logical/physical): 512B/512B
|
||||
Partition Table: msdos
|
||||
|
||||
Number Start End Size Type File system Flags
|
||||
1 32.3kB 1062MB 1062MB primary fat16 boot
|
||||
|
||||
(parted) quit
|
||||
Information: Don't forget to update /etc/fstab, if necessary.
|
||||
....
|
||||
|
||||
[[partitions-need-a-filesystem-label]]
|
||||
Partitions need a filesystem label!
|
||||
+++++++++++++++++++++++++++++++++++
|
||||
|
||||
If you get the message , you need to label the partition:
|
||||
|
||||
[[partition-has-different-physicallogical-endings]]
|
||||
Partition has different physical/logical endings!
|
||||
+++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
If you get this message from fdisk, you may need to reformat the flash
|
||||
drive when writing the image, by passing when writing the stick.
|
||||
|
||||
[[mbr-appears-to-be-blank]]
|
||||
MBR appears to be blank!
|
||||
++++++++++++++++++++++++
|
||||
|
||||
If your test boot reports a corrupted boot sector, or you get the
|
||||
message , you need to install or reset the master boot record (MBR), by
|
||||
passing when writing the stick.
|
||||
|
||||
[[livecd-iso-to-disk-on-other-linux-distributions]]
|
||||
livecd-iso-to-disk on other Linux distributions
|
||||
+++++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
is not meant to be run from a non-Fedora system. Even if it happens to
|
||||
run and write a stick apparently successfully from some other
|
||||
distribution, the stick may well fail to boot. Use of on any
|
||||
distribution other than Fedora is unsupported and not expected to work:
|
||||
please use an alternative method, such as link:#fmw[Fedora Media
|
||||
Writer].
|
||||
|
||||
[[ubuntus-usb-creator]]
|
||||
Ubuntu's _usb-creator_
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Ubuntu and derivative Linux distributions have a program similar to
|
||||
Fedora Media Writer. This *does not work* with Fedora ISO images, it
|
||||
silently rejects them. usb-creator requires the ISO to have a Debian
|
||||
layout, with a file and a casper directory. Do not attempt to use this
|
||||
utility to write a Fedora ISO image.
|
||||
|
||||
[[testing-a-usb-stick-using-qemu]]
|
||||
Testing a USB stick using qemu
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
You can test your stick using QEMU as shown in the screenshot below.
|
||||
|
||||
image:Screenshot_qemu_gtk3.png[`Screenshot_qemu_gtk3.png`,title="Screenshot_qemu_gtk3.png"]
|
||||
|
||||
For example, you could type the following commands:
|
||||
|
||||
....
|
||||
su -c 'umount /dev/sdX1'
|
||||
qemu -hda /dev/sdX -m 1024 -vga std
|
||||
....
|
||||
|
||||
[[mounting-a-live-usb-filesystem]]
|
||||
Mounting a Live USB filesystem
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
You can use the
|
||||
https://github.com/livecd-tools/livecd-tools/blob/master/tools/liveimage-mount[_liveimage-mount_]
|
||||
script in the package to mount an attached Live USB device or other
|
||||
LiveOS image, such as an ISO or Live CD. This is convenient when you
|
||||
want to copy in or out some file from the LiveOS filesystem on a Live
|
||||
USB, or just examine the files in a Live ISO or Live CD.
|
||||
|
||||
[[kernel-updates-for-livecd-iso-to-disk-written-images-with-a-persistent-overlay]]
|
||||
Kernel updates for _livecd-iso-to-disk_-written images with a persistent
|
||||
overlay
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If you have link:#limited_overlay[sufficient overlay space] to
|
||||
accommodate a kernel update on a Live USB installation, the kernel and
|
||||
initramfs will be installed to the /boot directory. To put these into
|
||||
service they must be moved to the /syslinux directory of the
|
||||
installation partition. This is accessible from the running Live USB
|
||||
filesystem at the /run/initramfs/live mount point. The new initramfs
|
||||
(such as initramfs-4.9.13-200.fc25.x86_64.img) and kernel (such as
|
||||
vmlinuz-4.9.13-200.fc25.x86_64) should be moved to replace the
|
||||
/run/initramfs/live/syslinux/initrd.img and
|
||||
/run/initramfs/live/syslinux/vmlinuz files, respectively.
|
||||
|
||||
* *Note*: _dracut_ no longer includes the _dmsquash-live_ module by
|
||||
default. Starting with Fedora 19, _dracut_ defaults to the option, which
|
||||
precludes the _dmsquash-live_ module. So, one can add a dracut config
|
||||
file, as root, before updating the kernel:
|
||||
|
||||
....
|
||||
echo 'hostonly="no"
|
||||
add_dracutmodules+=" dmsquash-live "' > /etc/dracut.conf.d/01-liveos.conf
|
||||
....
|
||||
|
||||
The following commands will move the new kernel and initramfs files to
|
||||
the device's /syslinux directory:
|
||||
|
||||
....
|
||||
bootpath=run/initramfs/live/syslinux
|
||||
new=4.9.13-200.fc25.x86_64
|
||||
|
||||
cd /
|
||||
mv -f boot/vmlinuz-$new ${bootpath}/vmlinuz
|
||||
mv -f boot/initramfs-${new}.img ${bootpath}/initrd.img
|
||||
....
|
||||
|
||||
[[multi-live-image-boot-installations]]
|
||||
Multi Live Image boot installations
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The _livecd-iso-to-disk_ --multi option allows one to install more than
|
||||
one LiveOS image on a single device. Version 24.2 or greater of will
|
||||
automatically configure the device boot loader to give a Multi Live
|
||||
Image Boot Menu for the device.
|
||||
|
||||
Category:LiveMedia
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
158
en-US/livecd.adoc
Normal file
158
en-US/livecd.adoc
Normal file
|
|
@ -0,0 +1,158 @@
|
|||
= FedoraLiveCD
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/FedoraLiveCD
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
[[download-and-create-live-image-or-live-usb]]
|
||||
Download and Create Live image or Live USB
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To download a pre-built Fedora Live image, visit
|
||||
https://getfedora.org/[the download page]. Then you can either:
|
||||
|
||||
* Burn the ISO to a CD or DVD. See
|
||||
http://docs.fedoraproject.org/readme-burning-isos/[here] for burning
|
||||
instructions.
|
||||
* Learn link:how_to_create_and_use_Live_USB[how to create and use Live
|
||||
USB].
|
||||
|
||||
If you want to build and then burn your own custom ISO, see
|
||||
link:How_to_create_and_use_a_Live_CD[How to create and use a Live CD].
|
||||
|
||||
[[advantages-and-limitations]]
|
||||
Advantages and Limitations
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Benefits:
|
||||
|
||||
* You can demonstrate features or try out a release, including testing
|
||||
hardware functionality, before hard disk/SSD installation.
|
||||
* Live USB/CD/DVD installation is faster than regular installation. Live
|
||||
USB/SD installation typically takes only a few minutes and can be
|
||||
configured with persistent storage.
|
||||
* You can use Live CD technology for backup and recovery of your
|
||||
installed hard drive.
|
||||
|
||||
Limitations:
|
||||
|
||||
* It is not possible to choose packages during installation. Live images
|
||||
typically have fewer packages than a regular installation image.
|
||||
* It is not possible to do an upgrade via the Anaconda installer. If you
|
||||
have a separate /home partition, you can just not format it during the
|
||||
installation and thus preserve your settings and /home content.
|
||||
* It is not possible to choose a non-default filesystem.
|
||||
* Once you shutdown a computer running from a Live CD, you will lose any
|
||||
settings or packages installed, but Live USB/SD installations may be
|
||||
configured with persistent storage.
|
||||
|
||||
[[fedora-live-image-features]]
|
||||
Fedora Live image features
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Current features:
|
||||
|
||||
1. A booted Live CD uses a temporary, in-memory, read-write rootfs, so
|
||||
it's possible to install software for use while the Live CD is running.
|
||||
2. Data persistence options available on Live USB/SD installations.
|
||||
3. Install to hard disks or USB/SD drives.
|
||||
4. Uses SELinux in enforcing mode and other security features by
|
||||
default.
|
||||
5. Includes best of breed software on the media.
|
||||
6. Stay as close to a normal desktop install with regard to features,
|
||||
or try specialized http://spins.fedoraproject.org/[Spins].
|
||||
7. Ability to create normal CD-ROM and CD-R media (less than 700 MB) or
|
||||
DVD images.
|
||||
8. Make it easy to do a derived Live CD with your own repositories,
|
||||
packages, and artwork.
|
||||
9. API used by LTSP, appliance creator and others.
|
||||
|
||||
[[contributors]]
|
||||
Contributors
|
||||
~~~~~~~~~~~~
|
||||
|
||||
* DavidZeuthen - Primary developer and maintainer of
|
||||
http://hal.freedesktop.org[HAL] and OLPC contributor.
|
||||
* JeremyKatz - Fedora Ninja. Adds backend for installing from a live
|
||||
image into link:Anaconda[ Anaconda].
|
||||
* DouglasMcClendon - LiveOS device mapper trickster.
|
||||
|
||||
[[communicate]]
|
||||
Communicate
|
||||
~~~~~~~~~~~
|
||||
|
||||
Fedora Live image users and developers can participate and contribute in
|
||||
the discussions happening in the Fedora list.
|
||||
(http://www.redhat.com/mailman/listinfo/fedora-livecd-list[predecessor
|
||||
list archives])
|
||||
|
||||
[[finding-the-code]]
|
||||
Finding the Code
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
The source code for the Live CD tools is maintained in git. The
|
||||
repository is at https://github.com/rhinstaller/livecd-tools/ . You can
|
||||
install it easily by installing the 'livecd-tools' package.
|
||||
|
||||
Kickstart files are in the spin-kickstarts.noarch package.
|
||||
|
||||
[[hard-drive-installation]]
|
||||
Hard Drive Installation
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The ability to install to a hard drive is available releases since
|
||||
Fedora 7. After the live media boots, click on the install icon on your
|
||||
desktop to start the installation. Installation from live image requires
|
||||
that GRUB and the /boot directory be installed onto a drive with an
|
||||
MSDOS partition label, or that the current machine supports EFI booting.
|
||||
If a pc-clone machine has only GPT hard drives, then you may need to use
|
||||
something such as a USB2.0 flash memory device (with an MSDOS partition
|
||||
label) as an intermediate destination.
|
||||
|
||||
In Fedora 15, instead of clicking the desktop icon, choose
|
||||
Applications->System Tools->Install to Hard Drive from the menu along
|
||||
the top of the screen.
|
||||
|
||||
[[references]]
|
||||
References
|
||||
~~~~~~~~~~
|
||||
|
||||
* https://web.archive.org/web/20080611062804/http://www-128.ibm.com/developerworks/linux/library/l-fedora-livecd/index.html[Mayank
|
||||
Sharma "IBM Developer Works: Build a Fedora Live CD" (archive.org
|
||||
version from June 2008)]
|
||||
* link:LiveOS_image[LiveOS image]
|
||||
|
||||
Category:LiveMedia
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
40
en-US/mirroring.adoc
Normal file
40
en-US/mirroring.adoc
Normal file
|
|
@ -0,0 +1,40 @@
|
|||
= Mirroring
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/Infrastructure/Mirroring
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
116
en-US/nested-virt-in-kvm.adoc
Normal file
116
en-US/nested-virt-in-kvm.adoc
Normal file
|
|
@ -0,0 +1,116 @@
|
|||
= How to enable nested virtualization in KVM
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/How_to_enable_nested_virtualization_in_KVM
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
Nested virtualization allows you to run a virtual machine (VM) inside
|
||||
another VM while still using hardware acceleration from the host.
|
||||
|
||||
[[nested-virt-support]]
|
||||
Nested virt support
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Check if your system supports it:
|
||||
|
||||
1. For Intel processors, look into
|
||||
`/sys/module/kvm_intel/parameters/nested`, for AMD processors into
|
||||
`/sys/module/kvm_amd/parameters/nested`. You should receive `1` or `Y`,
|
||||
if nested virt is supported, `0` or `N` otherwise. AMD processors should
|
||||
have it enabled by default, (certain) Intel processors might not.
|
||||
Example:
|
||||
+
|
||||
....
|
||||
$ cat /sys/module/kvm_intel/parameters/nested
|
||||
Y
|
||||
....
|
||||
2. If your host system does not have nested virt enabled (most probably
|
||||
just Intel case), try to enable it by booting with `kvm-intel.nested=1`
|
||||
argument on the kernel command line and check it again.
|
||||
|
||||
If your system still doesn't advertise support for nested virt, your
|
||||
hardware might be too old, or your distribution version outdated. Try
|
||||
booting latest Fedora.
|
||||
|
||||
[[configuration-in-virt-manager]]
|
||||
Configuration in virt-manager
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Configure your VM to use nested virt:
|
||||
|
||||
1. Make sure your VM is shut down
|
||||
2. Open virt-manager, go to the VM details page for that VM.
|
||||
3. Click on the Processor page.
|
||||
4. In the Configuration section, there are two options - either type
|
||||
`host-passthrough` into to Model field or enable Copy host CPU
|
||||
configuration checkbox (that fills `host-model` value into the Model
|
||||
field). Click Apply.
|
||||
* The difference between those two values is complicated, some details
|
||||
are in https://bugzilla.redhat.com/show_bug.cgi?id=1055002[bug 1055002].
|
||||
For nested virt, you'll probably want to use host-passthrough until
|
||||
issues with host-model are worked out. Be aware though, that
|
||||
host-passthrough is not recommended for general usage, just for nested
|
||||
virt purposes.
|
||||
|
||||
[[test-nested-virt]]
|
||||
Test nested virt
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
1. Start the VM
|
||||
2. Inside the VM, run `sudo dnf group install virtualization`
|
||||
3. Verify that the guest has virt correctly setup with:
|
||||
`sudo virt-host-validate` . The check for hardware virtualization should
|
||||
pass:
|
||||
+
|
||||
....
|
||||
$ sudo virt-host-validate
|
||||
QEMU: Checking for hardware virtualization : PASS
|
||||
QEMU: Checking for device /dev/kvm : PASS
|
||||
QEMU: Checking for device /dev/vhost-net : PASS
|
||||
QEMU: Checking for device /dev/net/tun : PASS
|
||||
LXC: Checking for Linux >= 2.6.26 : PASS
|
||||
....
|
||||
|
||||
[[see-also]]
|
||||
See Also
|
||||
~~~~~~~~
|
||||
|
||||
* QA:Testcase_KVM_nested_virt[QA:Testcase KVM nested virt]
|
||||
* https://bugzilla.redhat.com/show_bug.cgi?id=1055002
|
||||
* http://kashyapc.wordpress.com/2012/01/14/nested-virtualization-with-kvm-intel/
|
||||
* https://kashyapc.wordpress.com/2012/01/18/nested-virtualization-with-kvm-and-amd/
|
||||
|
||||
Category:Virtualization
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
40
en-US/networking-cli.adoc
Normal file
40
en-US/networking-cli.adoc
Normal file
|
|
@ -0,0 +1,40 @@
|
|||
= CLI
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/Networking/CLI
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
126
en-US/openh264.adoc
Normal file
126
en-US/openh264.adoc
Normal file
|
|
@ -0,0 +1,126 @@
|
|||
= OpenH264
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/OpenH264
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
This page contains information on the Cisco
|
||||
http://www.openh264.org/[OpenH264] codec.
|
||||
|
||||
[[background]]
|
||||
Background
|
||||
----------
|
||||
|
||||
Cisco provides an OpenH264 codec (as a source and a binary), which is
|
||||
their of implementation H.264 codec, and they cover all licensing fees
|
||||
for all parties using their binary. This codec allows you to use H.264
|
||||
in WebRTC with gstreamer and Firefox. It does *not* enable generic H.264
|
||||
playback, only WebRTC (see Mozilla
|
||||
https://bugzilla.mozilla.org/show_bug.cgi?id=1057646[bug 1057646]).
|
||||
|
||||
The code source is available at https://github.com/cisco/openh264 under
|
||||
a BSD license. The binary is released under this agreement from Cisco:
|
||||
http://www.openh264.org/BINARY_LICENSE.txt
|
||||
|
||||
Upstream Firefox versions download and install the OpenH264 plugin by
|
||||
default automatically. Due to it's binary nature, Fedora disables this
|
||||
automatic download.
|
||||
|
||||
[[installation-from-fedora-cisco-openh264-repository]]
|
||||
Installation from fedora-cisco-openh264 repository
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
A `fedora-cisco-openh264` repository is distributed since Fedora 24 by
|
||||
default (if you have at least `fedora-repos-24-0.5` package or newer).
|
||||
It contains OpenH264 binary link:Non-distributable-rpms[built inside the
|
||||
Fedora infrastructure], but distributed by Cisco, so that the all
|
||||
licensing fees are still covered by them. This repository also contains
|
||||
OpenH264 plugins for gstreamer and Firefox. It is disabled by default.
|
||||
In order to install OpenH264, you first need to enable it:
|
||||
|
||||
....
|
||||
$ sudo dnf config-manager --set-enabled fedora-cisco-openh264
|
||||
....
|
||||
|
||||
and then install the plugins:
|
||||
|
||||
....
|
||||
$ sudo dnf install gstreamer1-plugin-openh264 mozilla-openh264
|
||||
....
|
||||
|
||||
Afterwards you need open Firefox, go to menu -> Add-ons -> Plugins and
|
||||
enable OpenH264 plugin.
|
||||
|
||||
You can do a simple test whether your H.264 works in RTC on
|
||||
https://mozilla.github.io/webrtc-landing/pc_test.html[this page] (check
|
||||
_Require H.264 video_).
|
||||
|
||||
[[manual-install-of-binary]]
|
||||
Manual install of binary
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
* View and agree to the http://www.openh264.org/BINARY_LICENSE.txt
|
||||
* Download the appropriate binary for your system here:
|
||||
https://github.com/cisco/openh264/releases
|
||||
|
||||
Example installation for version 1.1:
|
||||
|
||||
`wget `http://ciscobinary.openh264.org/openh264-linux64-v1.1-Firefox33.zip[`http://ciscobinary.openh264.org/openh264-linux64-v1.1-Firefox33.zip`] +
|
||||
`mkdir -p ~/.mozilla/firefox/``/gmp-gmpopenh264/1.1/` +
|
||||
`cd ~/.mozilla/firefox/``/gmp-gmpopenh264/1.1/` +
|
||||
`unzip ~/openh264-linux64-v1.1-Firefox33.zip`
|
||||
|
||||
[[firefox-config-changes]]
|
||||
Firefox config changes
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Type about:config into the Firefox address/URL field and accept the
|
||||
warning.
|
||||
|
||||
* From the Search field type in 264 and a handful of options will
|
||||
appear. Give the following Preference Names a value of true by
|
||||
double-clicking on false:
|
||||
|
||||
` media.gmp-gmpopenh264.autoupdate` +
|
||||
` media.gmp-gmpopenh264.enabled` +
|
||||
` media.gmp-gmpopenh264.provider.enabled` +
|
||||
` media.peerconnection.video.h264_enabled`
|
||||
|
||||
* Restart Firefox
|
||||
* After restarting, the following string in about:config will change to
|
||||
the current version that has been installed from the web:
|
||||
|
||||
` media.gmp-gmpopenh264.version`
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
153
en-US/package-management.adoc
Normal file
153
en-US/package-management.adoc
Normal file
|
|
@ -0,0 +1,153 @@
|
|||
= Package management system
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/Package_management_system
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
[[package-management-system]]
|
||||
Package Management System
|
||||
-------------------------
|
||||
|
||||
[[introduction]]
|
||||
Introduction
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Fedora is a distribution that uses a package management system. This
|
||||
system is based on http://rpm.org[rpm] , the RPM Package Manager, with
|
||||
several higher level tools built on top of it, most notably
|
||||
https://www.freedesktop.org/software/PackageKit/[PackageKit] (default
|
||||
gui) and link:Yum[ yum] (command line tool). As of Fedora 22, yum has
|
||||
been replaced by link:Dnf[ dnf]. The Gnome Package Manager is another
|
||||
GUI package manager.
|
||||
|
||||
[[advantages-of-package-management-systems]]
|
||||
Advantages of package management systems
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Package management systems have many advantages:
|
||||
|
||||
* It's easy to query what version of a package is installed or
|
||||
available.
|
||||
|
||||
* It's easy to remove a package entirely, making sure all its files are
|
||||
gone.
|
||||
|
||||
* It's easy to verify the integrity of the packages files, so you can
|
||||
see if it's been corrupted or tampered with.
|
||||
|
||||
* It's easy to upgrade a package by installing the new version and
|
||||
removing all the old versions files. This will make sure not to leave
|
||||
any lingering files from the old package around to confuse or break
|
||||
things.
|
||||
|
||||
* It's easy to see what packages require or provide things that other
|
||||
packages provide or require, so you can be sure to have the needed items
|
||||
for the package to function correctly.
|
||||
|
||||
* It's easy to install or remove groups of packages.
|
||||
|
||||
* In many cases it's possible to downgrade back to a previous version of
|
||||
a package, for example when a new version has a bug.
|
||||
|
||||
[[disadvantages-of-package-management-systems]]
|
||||
Disadvantages of package management systems
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
* You are restricted to either using the versions of the package that
|
||||
are available or having to make your own package if you need a different
|
||||
version.
|
||||
|
||||
[[why-mixing-source-installs-and-packages-is-a-bad-idea]]
|
||||
Why mixing source installs and packages is a bad idea
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Package management systems have no way to query or note when you bypass
|
||||
them and install something from source. You should avoid mixing source
|
||||
installs and packaged installs for (at least) the following reasons:
|
||||
|
||||
* You lose all the advantages above from a package managed system.
|
||||
|
||||
* Installing from source may overwrite, delete, or change existing files
|
||||
that are in a package, making that package not function correctly.
|
||||
|
||||
* The source install may override a package install causing undefined
|
||||
behavior in the package or source installed item.
|
||||
|
||||
* Installing from source makes it impossible or very difficult for
|
||||
anyone to help you debug issues, since versions can't be easily queried
|
||||
and integrity checked.
|
||||
|
||||
* Fedora packages may include patches or configuration to work with
|
||||
other packages, but upstream source does not, leading to loss of
|
||||
functionality.
|
||||
|
||||
* Software installed from source will not upgrade with package managed
|
||||
packages, leading to breakage in the source install package on upgrades
|
||||
or os updates.
|
||||
|
||||
Strongly consider making your own package if you need a different
|
||||
version or a version of some package with changes. See:
|
||||
link:How_to_create_an_RPM_package[How to create a RPM package]
|
||||
|
||||
[[preferred-search-order-for-a-software]]
|
||||
Preferred search order for a software
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If some software is missing in your installation then you should try the
|
||||
following steps to get the packaged version:
|
||||
|
||||
1. Search in Fedora ( 'yum|dnf search foo' or search for 'foo' in the
|
||||
PackageKit gui )
|
||||
2. Try one of the available link:Third_party_repositories[ 3rd party]
|
||||
repositories
|
||||
3. link:How_to_create_an_RPM_package[ Build your own package]
|
||||
|
||||
[[package-management-tools]]
|
||||
Package Management tools
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
link:Dnf[ dnf] - Dandified Yum
|
||||
|
||||
link:Yum[ yum] - Yellowdog Updater Modified
|
||||
|
||||
https://www.freedesktop.org/software/PackageKit/[PackageKit] -
|
||||
PackageKit gui tool ('add/remove software' in your menu)
|
||||
|
||||
http://rpm.org[rpm] - RPM package manager.
|
||||
|
||||
http://ww1.yum-extender.org/[yumex] - Yum Extender.
|
||||
|
||||
Category:Software_Management[Category:Software Management]
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
144
en-US/packagekit-not-found.adoc
Normal file
144
en-US/packagekit-not-found.adoc
Normal file
|
|
@ -0,0 +1,144 @@
|
|||
= PackageKit Items Not Found
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/PackageKit_Items_Not_Found
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
[[missing-package]]
|
||||
Missing Package
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Unfortunately, the package you were searching for is not available in
|
||||
Fedora. There are a few common reasons why a package might not be in
|
||||
Fedora's repositories:
|
||||
|
||||
* Fedora does not include software that is
|
||||
link:Package_Not_Found#Patents[ encumbered by software patents].
|
||||
* Fedora does not include proprietary software, only software with an
|
||||
link:Licensing[ acceptable license].
|
||||
* It is possible that no one has packaged it yet. You might consider
|
||||
adding it to the link:PackageMaintainers/WishList[Package WishList], or
|
||||
even link:PackageMaintainers/Join[packaging it yourself]!
|
||||
|
||||
[[missing-codec]]
|
||||
Missing Codec
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
Unfortunately, the codec you were searching for is not available in
|
||||
Fedora. A codec is a program that enables encoding and/or decoding of a
|
||||
data stream, in a specific format such as MP3, MOV, or WMV.
|
||||
|
||||
There are a few common reasons why a codec might not be in Fedora's
|
||||
repositories:
|
||||
|
||||
* Many codecs are proprietary or link:Package_Not_Found#Patents[patent
|
||||
encumbered].
|
||||
* Some codecs may not be encumbered, but may be under an
|
||||
link:Licensing[unacceptable license].
|
||||
|
||||
The Fedora Project FAQ and community sites provide answers to commonly
|
||||
asked questions. link:Third_party_repositories[Third party repositories]
|
||||
contain a wide variety of software that has not been included in the
|
||||
official Fedora software repositories for various reasons. You can find
|
||||
additional software using a search engine like
|
||||
http://google.com[Google]. We would love to give you more specific
|
||||
instructions on enabling additional codecs but our hands are tied up due
|
||||
to software patents and legal restrictions around them. We apologize for
|
||||
the inconvenience caused by software patents and our legal team is
|
||||
working on getting these restrictions removed when it is possible to do
|
||||
so. Scroll down more for details on what we are doing and how you can
|
||||
help.
|
||||
|
||||
[[missing-driver]]
|
||||
Missing Driver
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
Unfortunately, the driver you were searching for is not available in
|
||||
Fedora. There are a few common reasons why a driver might not be in
|
||||
Fedora's repositories:
|
||||
|
||||
* Some drivers are proprietary or link:Package_Not_Found#Patents[patent
|
||||
encumbered].
|
||||
* Some hardware may not be supported under Linux yet, or is not yet in
|
||||
the upstream Linux kernel.
|
||||
|
||||
Fedora strongly encourages new drivers to be included in upstream, and
|
||||
does not package individual, out-of-tree, kernel drivers.
|
||||
|
||||
The Fedora Project FAQ and the more informal, unofficial
|
||||
http://fedorafaq.org[1] provide useful answers on commonly asked
|
||||
questions. However, the unofficial site is not associated with or
|
||||
supported by the Fedora Project. You can find many interesting things
|
||||
using a search engine like http://google.com[Google].
|
||||
link:Third_party_repositories[Third party repositories] might contain
|
||||
software that has been not been included in the official Fedora software
|
||||
repository.
|
||||
|
||||
[[missing-font]]
|
||||
Missing Font
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Unfortunately, the font you were searching for is not available in
|
||||
Fedora. There are a few common reasons why a font might not be in
|
||||
Fedora's repositories:
|
||||
|
||||
* Fedora does not include proprietary fonts, it only uses fonts with an
|
||||
link:Licensing/Fonts[ acceptable font license].
|
||||
* It is possible that no one has packaged that font yet. You might
|
||||
consider adding it to the :Category:Font_wishlist[Font WishList], or
|
||||
even link:PackageMaintainers/Join[packaging it yourself]!
|
||||
|
||||
[[missing-mime-support]]
|
||||
Missing MIME Support
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Unfortunately, there is nothing in Fedora that claims to support the
|
||||
MIME type you were searching for. There are a few common reasons why
|
||||
Fedora may not have support for a MIME type:
|
||||
|
||||
* Many MIME types are Windows-only. You may be able to use
|
||||
http://en.wikipedia.org/wiki/Wine_(software)[Wine] to run a Windows
|
||||
program under Linux that supports your MIME type.
|
||||
* Some MIME types are only supported by proprietary or
|
||||
link:Package_Not_Found#Patents[patent encumbered] software.
|
||||
* It is possible that acceptable software to support your MIME type
|
||||
exists, but that no one has packaged it yet. You might consider adding
|
||||
it to the link:PackageMaintainers/WishList[Package WishList], or even
|
||||
link:PackageMaintainers/Join[packaging it yourself]!
|
||||
|
||||
[[fedora-position-on-software-patents]]
|
||||
Fedora Position on Software Patents
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
470
en-US/postgresql.adoc
Normal file
470
en-US/postgresql.adoc
Normal file
|
|
@ -0,0 +1,470 @@
|
|||
= PostgreSQL
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/PostgreSQL
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
[[installation]]
|
||||
Installation
|
||||
~~~~~~~~~~~~
|
||||
|
||||
The installation and initialization of the postgresql server is a little
|
||||
bit different in comparison to other packages and other linux distros.
|
||||
This document aims to summarize basic installation steps relevant to
|
||||
recent fedora release. In first place, you may consider to install newer
|
||||
version than is packaged for fedora, see http://yum.postgresql.org/[1].
|
||||
However, this is not recommended.
|
||||
|
||||
`$ sudo yum install postgresql-server postgresql-contrib`
|
||||
|
||||
Or with dnf in Fedora 22 and later versions:
|
||||
|
||||
`$ sudo dnf install postgresql-server postgresql-contrib`
|
||||
|
||||
The postgresql server is turned off and disabled by default. You can
|
||||
enable its start during the boot using following command:
|
||||
|
||||
`$ sudo systemctl enable postgresql`
|
||||
|
||||
You can start the postgresql server only when necessary as follows.
|
||||
|
||||
`$ sudo systemctl start postgresql` +
|
||||
`Job for postgresql.service failed. See 'systemctl status postgresql.service' and 'journalctl -xn' for details.`
|
||||
|
||||
The database needs to be populated with initial data after installation.
|
||||
The error log describes problem and its solution.
|
||||
|
||||
`$ journalctl -xn` +
|
||||
`-- Logs begin at Mon 2013-11-04 14:38:33 CET, end at Thu 2013-11-14 11:45:56 CET. --` +
|
||||
`Nov 14 11:45:34 mlich-lenovo.usersys.redhat.com sudo[2054]: jmlich : TTY=pts/2 ; PWD=/home/jmlich ; USER=root ; COMMAND=/bin/systemctl status postgresql` +
|
||||
`Nov 14 11:45:37 mlich-lenovo.usersys.redhat.com sudo[2073]: jmlich : TTY=pts/2 ; PWD=/home/jmlich ; USER=root ; COMMAND=/bin/systemctl status postgresql` +
|
||||
`Nov 14 11:45:56 mlich-lenovo.usersys.redhat.com sudo[2105]: jmlich : TTY=pts/2 ; PWD=/home/jmlich ; USER=root ; COMMAND=/bin/systemctl start postgresql` +
|
||||
`Nov 14 11:45:56 mlich-lenovo.usersys.redhat.com systemd[1]: Starting PostgreSQL database server...` +
|
||||
`-- Subject: Unit postgresql.service has begun with start-up` +
|
||||
`-- Defined-By: systemd` +
|
||||
`-- Support: `http://lists.freedesktop.org/mailman/listinfo/systemd-devel[`http://lists.freedesktop.org/mailman/listinfo/systemd-devel`] +
|
||||
`--` +
|
||||
`-- Unit postgresql.service has begun starting up.` +
|
||||
`Nov 14 11:45:56 mlich-lenovo.usersys.redhat.com postgresql-check-db-dir[2108]: An old version of the database format was found.` +
|
||||
`Nov 14 11:45:56 mlich-lenovo.usersys.redhat.com postgresql-check-db-dir[2108]: Use "postgresql-setup upgrade" to upgrade to version 9.3.` +
|
||||
`Nov 14 11:45:56 mlich-lenovo.usersys.redhat.com postgresql-check-db-dir[2108]: See /usr/share/doc/postgresql/README.rpm-dist for more information.` +
|
||||
`Nov 14 11:45:56 mlich-lenovo.usersys.redhat.com systemd[1]: postgresql.service: control process exited, code=exited status=1` +
|
||||
`Nov 14 11:45:56 mlich-lenovo.usersys.redhat.com systemd[1]: Failed to start PostgreSQL database server.` +
|
||||
`-- Subject: Unit postgresql.service has failed` +
|
||||
`-- Defined-By: systemd` +
|
||||
`-- Support: `http://lists.freedesktop.org/mailman/listinfo/systemd-devel[`http://lists.freedesktop.org/mailman/listinfo/systemd-devel`] +
|
||||
`-- Documentation: `http://www.freedesktop.org/wiki/Software/systemd/catalog/be02cf6855d2428ba40df7e9d022f03d[`http://www.freedesktop.org/wiki/Software/systemd/catalog/be02cf6855d2428ba40df7e9d022f03d`] +
|
||||
`--` +
|
||||
`-- Unit postgresql.service has failed.` +
|
||||
`--` +
|
||||
`-- The result is failed.`
|
||||
|
||||
The database initialization could be done using following command. It
|
||||
creates the configuration files postgresql.conf and pg_hba.conf
|
||||
|
||||
`$ sudo postgresql-setup initdb`
|
||||
|
||||
Or on Fedora 22 and later:
|
||||
|
||||
`$ sudo postgresql-setup --initdb --unit postgresql`
|
||||
|
||||
[[upgrade]]
|
||||
Upgrade
|
||||
~~~~~~~
|
||||
|
||||
As you can see from error message in my example, it is not a fresh
|
||||
installation, but ugprade.
|
||||
|
||||
`Nov 14 11:45:56 mlich-lenovo.usersys.redhat.com postgresql-check-db-dir[2108]: An old version of the database format was found.` +
|
||||
`Nov 14 11:45:56 mlich-lenovo.usersys.redhat.com postgresql-check-db-dir[2108]: Use "postgresql-setup upgrade" to upgrade to version 9.3.`
|
||||
|
||||
With version 9 you can use upgrade tool. It is packaged as
|
||||
`postgresql-upgrade`:
|
||||
|
||||
....
|
||||
$ postgresql-setup upgrade
|
||||
|
||||
Redirecting to /bin/systemctl stop postgresql.service
|
||||
Upgrading database: OK
|
||||
|
||||
The configuration files was replaced by default configuration.
|
||||
The previous configuration and data are stored in folder /var/lib/pgsql/data-old.
|
||||
|
||||
See /var/lib/pgsql/pgupgrade.log for details.
|
||||
....
|
||||
|
||||
The data are located at
|
||||
|
||||
* /var/lib/pgsql/data
|
||||
* /var/lib/pgsql/data-old
|
||||
|
||||
The upgrade itself will backup your existing data and migrate your
|
||||
database. Don't forget to migrate your configuration (with meld for
|
||||
example: `meld /var/lib/pgsql/data{,-old}/postgresql.conf`).
|
||||
|
||||
You may need to switch postgresql to trust mode before update. This
|
||||
should be fixed already.
|
||||
|
||||
You can also upgrade by dumping your database and loading it again. For
|
||||
more information, see link:#link-upgrade[official documentation].
|
||||
|
||||
[[tips-and-tricks]]
|
||||
Tips and tricks
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
For database management is comfortable to use graphical tools such as
|
||||
phpPgAdmin or pgadmin3
|
||||
|
||||
`$ sudo yum install phpPgAdmin` +
|
||||
`$ sudo yum install pgadmin3`
|
||||
|
||||
Or with dnf in Fedora 22 and later versions:
|
||||
|
||||
`$ sudo dnf install phpPgAdmin` +
|
||||
`$ sudo dnf install pgadmin3`
|
||||
|
||||
[[firewall]]
|
||||
Firewall
|
||||
~~~~~~~~
|
||||
|
||||
PostgreSQL operates on port 5432 (or whatever else you set in your
|
||||
`postgresql.conf`). In firewalld you can open it like this:
|
||||
|
||||
`$ # make it last after reboot` +
|
||||
`$ firewall-cmd --permanent --add-port=5432/tcp` +
|
||||
`$ # change runtime configuration` +
|
||||
`$ firewall-cmd --add-port=5432/tcp`
|
||||
|
||||
In case of iptables:
|
||||
|
||||
`$ iptables -A INPUT -p tcp --dport 5432 -m state --state NEW,ESTABLISHED -j ACCEPT`
|
||||
|
||||
Bear in mind that you probably don't want to open your database server
|
||||
to the whole world.
|
||||
|
||||
[[selinux]]
|
||||
SELinux
|
||||
~~~~~~~
|
||||
|
||||
If you have SELinux enforced, you may run into trouble when trying to do
|
||||
some non-standard configuration. For example if you would like to change
|
||||
a location of your database, you have to add new context mapping for the
|
||||
new location:
|
||||
|
||||
`$ semanage fcontext -a -t postgresql_db_t "/my/new/location(/.*)?"`
|
||||
|
||||
If default port doesn't work for you, you may need to map postgre's port
|
||||
type to your desired port:
|
||||
|
||||
`$ semanage port -a -t postgresql_port_t -p tcp 5433`
|
||||
|
||||
If you install a webapp that wants to communicate with PostgreSQL via
|
||||
TCP/IP, you will have to tell SELinux to allow this on the webserver
|
||||
host:
|
||||
|
||||
`# setsebool -P httpd_can_network_connect_db on`
|
||||
|
||||
[[user-creation-and-database-creation]]
|
||||
User Creation and Database Creation
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Soon you run into need of creating a user (and database for the user).
|
||||
First, you have to switch user to interact with postgres:
|
||||
|
||||
`# su - postgres`
|
||||
|
||||
and then run postgre's interactive shell:
|
||||
|
||||
....
|
||||
$ psql
|
||||
psql (9.3.2)
|
||||
Type "help" for help.
|
||||
|
||||
postgres=#
|
||||
....
|
||||
|
||||
It might be good idea to add password for `postgres` user:
|
||||
|
||||
`postgres=# \password postgres`
|
||||
|
||||
Lets get back to user creation:
|
||||
|
||||
`postgres=# CREATE USER lenny WITH PASSWORD 'leonard';` +
|
||||
`postgres=# CREATE DATABASE carl OWNER lenny;`
|
||||
|
||||
this could be done from system shell too:
|
||||
|
||||
`$ createuser lenny` +
|
||||
`$ createdb --owner=lenny carl`
|
||||
|
||||
[[configuration]]
|
||||
Configuration
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
The postgresql server is using two main configuration files
|
||||
|
||||
* /var/lib/pgsql/data/postgresql.conf
|
||||
* /var/lib/pgsql/data/pg_hba.conf
|
||||
|
||||
[[systemd]]
|
||||
systemd
|
||||
^^^^^^^
|
||||
|
||||
Some configuration parameters are passed to daemon via command line
|
||||
options. This behaviour may override settings in postgresql.conf. For
|
||||
example, if you want to change the server's port number to 5433, create
|
||||
a file named "/etc/systemd/system/postgresql.service" containing:
|
||||
|
||||
`.include /lib/systemd/system/postgresql.service` +
|
||||
`[Service]` +
|
||||
`Environment=PGPORT=5433`
|
||||
|
||||
Note: changing PGPORT or PGDATA will typically require adjusting SELinux
|
||||
configuration as well; see section selinux.
|
||||
|
||||
Please follow the systemd documentation
|
||||
http://fedoraproject.org/wiki/Systemd#How_do_I_customize_a_unit_file.2F_add_a_custom_unit_file.3F[2]
|
||||
for more details.
|
||||
|
||||
[[postgresql.conf]]
|
||||
postgresql.conf
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
If you want postgres to accept network connections, you should change
|
||||
|
||||
`listen_addresses = 'localhost'`
|
||||
|
||||
to
|
||||
|
||||
`listen_addresses = '*'`
|
||||
|
||||
[[pg_hba.conf]]
|
||||
pg_hba.conf
|
||||
^^^^^^^^^^^
|
||||
|
||||
Once your database is set up, you need to configure access to your
|
||||
database server. This may be done by editing file
|
||||
`/var/lib/pgsql/data/pg_hba.conf`. There are rules like this in the
|
||||
file:
|
||||
|
||||
`# TYPE DATABASE USER ADDRESS METHOD` +
|
||||
` host all all 127.0.0.1/32 md5` +
|
||||
` host all all ::1/128 md5` +
|
||||
` local all postgres peer`
|
||||
|
||||
First field stands for connection type. It can have these values:
|
||||
|
||||
* *local* — Unix-domain socket
|
||||
* *host* — plain or SSL-encrypted TCP/IP socket
|
||||
* *hostssl* — is an SSL-encrypted TCP/IP socket
|
||||
* *hostnossl* — plain TCP/IP socket
|
||||
|
||||
Last column specifies which authentication method will be used.
|
||||
|
||||
* *md5* — client has to supply password processed with MD5 algorithm
|
||||
* *ident* — obtain user name of connecting client from operating system
|
||||
and consult it with specified map
|
||||
* *trust* — anyone who is able to connect to PostgreSQL server may act
|
||||
as any user without supplying password
|
||||
* *peer* — obtains user's name from operating system and checks if it
|
||||
matches database user name
|
||||
|
||||
When database server is authenticating client, it seeks for a record
|
||||
with matching connection type, client address, requested database and
|
||||
user name. As soon as it finds it, it performs the authentication. If
|
||||
authentication fails, no more subsequent records are taken into account.
|
||||
If no record matches, client's access is denied.
|
||||
|
||||
The default settings is usually restricted to localhost.
|
||||
|
||||
When you install your database server and at first you try to "make it
|
||||
work", you should turn off firewall, SELinux and make postgres'
|
||||
authentication permissive (bear in mind this will greatly expose your
|
||||
server, so do it _only_ on trusted network — preferably without not
|
||||
network at all):
|
||||
|
||||
`host all all 127.0.0.1/32 trust`
|
||||
|
||||
As soon as you are able to connect, turn the security systems on one by
|
||||
one while verifying the connection can be established.
|
||||
|
||||
For more information see official documentation for
|
||||
link:#link-pghba[pg_hba.conf file].
|
||||
|
||||
[[optimisation]]
|
||||
Optimisation
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Default configuration of postgres is severely undertuned. It can handle
|
||||
simple application with not so often database access but if you require
|
||||
higher performance, you should configure your instance better. All the
|
||||
magic is happening in `/var/lib/pgsql/data/postgresql.conf\``. Also
|
||||
logging mechanism is configured not very intuitively.
|
||||
|
||||
[[performance]]
|
||||
Performance
|
||||
^^^^^^^^^^^
|
||||
|
||||
Number of clients which may be connected to PostgreSQL at the same time:
|
||||
|
||||
`max_connections = `
|
||||
|
||||
`shared_buffers` is the entry point. This is telling PostgreSQL how much
|
||||
memory is dedicated for caching. Setting this to 25% of total memory of
|
||||
your system is a good start. If it doesn't work for you, try to go for
|
||||
something between 15% - 40% of total memory.
|
||||
|
||||
`shared_buffers = `
|
||||
|
||||
This value is used by query planner to know how much memory is available
|
||||
in the system. Query planner uses this information to figure out whether
|
||||
plan fits into memory or not. Setting this to 50% of total memory is a
|
||||
common practise.
|
||||
|
||||
`effective_cache_size = `
|
||||
|
||||
When PostgreSQL performs sorting operations it plans its strategy
|
||||
whether to sort the query on disk or in memory. Bear in mind that this
|
||||
memory is available for every sorting instance. In case of multiple
|
||||
users submitting queries to your database server, this can rump up
|
||||
pretty high. Therefore this is tightly bound to `max_connections`.
|
||||
|
||||
`work_mem = `
|
||||
|
||||
For more information about this topic I advise you to read official
|
||||
link:#link-tuning[documentation about] tuning PostgreSQL.
|
||||
|
||||
[[logging]]
|
||||
Logging
|
||||
^^^^^^^
|
||||
|
||||
By default, logs are rotated every week and you don't find much
|
||||
information in there (one could miss log level, date, time, ...). Also
|
||||
for simple web applications I prefer to increase verbosity.
|
||||
|
||||
`log_destination = 'stderr'`
|
||||
|
||||
This is just fine. If you would like syslog to take care of your logs,
|
||||
change it to `'syslog'`, or even `'syslog,stderr'` (if you go for
|
||||
syslog, don't forget to configure syslog itself too; for more info, see
|
||||
link:#link-logging[official documentation])
|
||||
|
||||
`logging_collector = on`
|
||||
|
||||
In case of logging to stderr, postgres will grab all the logs if you
|
||||
enable `logging_collector` option.
|
||||
|
||||
This is default option:
|
||||
|
||||
`log_filename = 'postgresql-%a.log'`
|
||||
|
||||
Much preferred could be to name log files by date when they were
|
||||
created:
|
||||
|
||||
`log_filename = 'postgresql-%G-%m.log'`
|
||||
|
||||
Rotation. This really depends on the app itself. In case of simple app
|
||||
with a few data in database, all the logs may be kept persistently on
|
||||
disk without rotation.
|
||||
|
||||
`log_truncate_on_rotation = off` +
|
||||
`log_rotation_age = 31d`
|
||||
|
||||
Increase number of entries in log:
|
||||
|
||||
`client_min_messages = notice # default notice` +
|
||||
`log_min_messages = info # default warning` +
|
||||
`log_min_error_statement = notice # default error`
|
||||
|
||||
If you would like to log slow queries, feel free to use this option:
|
||||
|
||||
`log_min_duration_statement = 1000 # in ms`
|
||||
|
||||
Default log entry doesn't contain much info:
|
||||
|
||||
`FATAL: Ident authentication failed for user "test"` +
|
||||
`DETAIL: Connection matched pg_hba.conf line 84: "host all all ::1/128 ident"`
|
||||
|
||||
Lets improve it to:
|
||||
|
||||
`2013-12-30 17:51:36 CET testx@::1(50867):postgres [11213] FATAL: password authentication failed for user "testx"` +
|
||||
`2013-12-30 17:51:36 CET testx@::1(50867):postgres [11213] DETAIL: Connection matched pg_hba.conf line 84: "host all all ::1/128 md5 "`
|
||||
|
||||
You just have to alter option `log_line_prefix`.
|
||||
|
||||
`# %t -- timestamp` +
|
||||
`# %u -- user` +
|
||||
`# %r -- client's host` +
|
||||
`# %d -- database` +
|
||||
`# %p -- PID` +
|
||||
`log_line_prefix = '%t %u@%r:%d [%p] '`
|
||||
|
||||
If you are running only single database with single user connecting, it
|
||||
would make more sense to simplify the prefix to
|
||||
|
||||
`log_line_prefix = '%t [%p] '`
|
||||
|
||||
[[final-recipe]]
|
||||
Final recipe
|
||||
++++++++++++
|
||||
|
||||
`log_destination = 'stderr'` +
|
||||
`logging_collector = on` +
|
||||
`log_filename = 'postgresql-%G-%m.log'` +
|
||||
`log_truncate_on_rotation = off` +
|
||||
`log_rotation_age = 31d` +
|
||||
`client_min_messages = notice` +
|
||||
`log_min_messages = info` +
|
||||
`log_min_error_statement = notice` +
|
||||
`log_line_prefix = '%t %u@%r:%d [%p] '`
|
||||
|
||||
[[reference]]
|
||||
Reference
|
||||
~~~~~~~~~
|
||||
|
||||
link:PostgreSQL/README.rpm-dist[Full RPM packaging documentation]
|
||||
|
||||
http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server[Tuning
|
||||
performance]
|
||||
|
||||
http://www.postgresql.org/docs/9.1/static/runtime-config-logging.html[Logging
|
||||
configuration]
|
||||
|
||||
http://www.postgresql.org/docs/9.1/static/upgrading.html[Upgrading
|
||||
PostgreSQL]
|
||||
|
||||
http://www.postgresql.org/docs/8.3/static/auth-pg-hba-conf.html[pg_hba.conf
|
||||
file]
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
168
en-US/qemu.adoc
Normal file
168
en-US/qemu.adoc
Normal file
|
|
@ -0,0 +1,168 @@
|
|||
= How to use qemu
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/How_to_use_qemu
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
[[how-to-use-qemu]]
|
||||
How to use QEMU
|
||||
---------------
|
||||
|
||||
QEMU is a very flexible virtualization technology however it is quite
|
||||
slow and it is recommended that you understand and evaluate alternative
|
||||
solutions before picking this one. Refer to
|
||||
link:Getting_started_with_virtualization[Getting started with
|
||||
virtualization]
|
||||
|
||||
[[qemu]]
|
||||
Qemu
|
||||
~~~~
|
||||
|
||||
QEMU is a generic and open source processor emulator which achieves a
|
||||
good emulation speed by using dynamic translation.
|
||||
|
||||
QEMU has two operating modes:
|
||||
|
||||
* Full system emulation. In this mode, QEMU emulates a full system (for
|
||||
example a PC), including a processor and various peripherials. It can be
|
||||
used to launch different Operating Systems without rebooting the PC or
|
||||
to debug system code.
|
||||
* User mode emulation (Linux host only). In this mode, QEMU can launch
|
||||
Linux processes compiled for one CPU on another CPU.
|
||||
|
||||
[[download]]
|
||||
Download
|
||||
~~~~~~~~
|
||||
|
||||
QEMU is available on Fedora repository. It can be installed by using
|
||||
link:dnf[DNF]:
|
||||
|
||||
....
|
||||
$ su -c "dnf install qemu"
|
||||
....
|
||||
|
||||
Or with YUM:
|
||||
|
||||
....
|
||||
$ su -c "yum install qemu"
|
||||
....
|
||||
|
||||
[[qemu-commands-since-f]]
|
||||
Qemu commands since F?+
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To discover the qemu commands that are installed perform the following:
|
||||
|
||||
....
|
||||
$ ls /usr/bin/qemu-*
|
||||
....
|
||||
|
||||
In the following examples where "qemu" is, substitute your command for
|
||||
executing qemu. E.g.
|
||||
|
||||
....
|
||||
qemu-system-i386
|
||||
....
|
||||
|
||||
or
|
||||
|
||||
....
|
||||
qemu-i386
|
||||
....
|
||||
|
||||
Of course, this does not apply to "qemu-img".
|
||||
|
||||
[[qemu-virtual-machine-installation]]
|
||||
Qemu virtual machine installation
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Create the virtual image for the system:
|
||||
|
||||
....
|
||||
$ qemu-img create fedora.qcow 5G
|
||||
....
|
||||
|
||||
Of course you are not obliged to take 5GB.
|
||||
|
||||
Note: Even if you take 10GB this does NOT mean that the image does
|
||||
really HAVE the size of 10GB. It just means that your new system is
|
||||
limited up to 10GB - if the new system takes only 1,2 GB also the image
|
||||
will only be at 1,2GB.
|
||||
|
||||
now let's install the OS. Put in the install CD and type into your
|
||||
konsole (all in one line without break):
|
||||
|
||||
....
|
||||
$ qemu -cdrom /dev/cdrom -hda fedora.qcow -boot d -net nic -net user -m 196 -localtime
|
||||
....
|
||||
|
||||
"-user -net" is important to have internet access within your new
|
||||
system. "-m 196" is the Set virtual RAM size (megabytes), default is 128
|
||||
MB, I chose 196.
|
||||
|
||||
The install may take some time. After the install, qemu will try to boot
|
||||
the new OS itself. Maybe this may fail (was the case for me) - but don't
|
||||
worry. If that happens: just close the qemu window and type the
|
||||
following command into your konsole to launch your new OS:
|
||||
|
||||
....
|
||||
$qemu fedora.qcow -boot c -net nic -net user -m 196 -localtime
|
||||
....
|
||||
|
||||
[[testing-iso-images]]
|
||||
Testing ISO Images
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Type, in the proper directory
|
||||
|
||||
....
|
||||
$ qemu -m 512M -cdrom <isoname>.iso
|
||||
....
|
||||
|
||||
[[debugging]]
|
||||
Debugging
|
||||
~~~~~~~~~
|
||||
|
||||
To get kernel output dumped to a file outside the virtual system, add
|
||||
e.g. "-serial file:/tmp/qemu-output.log" to the qemu command line. When
|
||||
booting the virtual system, add "console=ttyS0" to the kernel boot
|
||||
parameters.
|
||||
|
||||
This output is particularly helpful if you are having trouble booting
|
||||
the system, in which case you may also wish to remove "rhgb" and "quiet"
|
||||
from the kernel boot parameters.
|
||||
|
||||
Category:How_to
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
41
en-US/raspberry-pi.adoc
Normal file
41
en-US/raspberry-pi.adoc
Normal file
|
|
@ -0,0 +1,41 @@
|
|||
= Raspberry Pi
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
1. REDIRECT
|
||||
link:Architectures/ARM/Raspberry_Pi[Architectures/ARM/Raspberry Pi]
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
387
en-US/repositories.adoc
Normal file
387
en-US/repositories.adoc
Normal file
|
|
@ -0,0 +1,387 @@
|
|||
= Repositories
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/Repositories
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
This page explains the various Fedora repositories that exist for
|
||||
different Fedora Releases, the relationship between them, and what
|
||||
packages they contain.
|
||||
|
||||
[[the-fedora-repository]]
|
||||
The _fedora_ repository
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The _fedora_ repository exists for all Fedora releases after they have
|
||||
link:Releases/Branched[Branched] from link:Releases/Rawhide[Rawhide]. It
|
||||
is represented for Yum or http://dnf.baseurl.org/[DNF] in the file in
|
||||
the repository path. For any Fedora installation, this repository will
|
||||
be enabled by default, and should usually remain so.
|
||||
|
||||
[[the-fedora-repository-in-stable-releases]]
|
||||
The _fedora_ repository in stable releases
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
For stable releases, _fedora_ represents the frozen release state. It is
|
||||
a part of the frozen tree that is created by
|
||||
link:ReleaseEngineering[Release Engineering] when a release is approved
|
||||
at a Go_No_Go_Meeting. The package set it contains never changes after
|
||||
that time. It represents the _stable_ state of a stable release in
|
||||
conjunction with link:#updates[the _updates_ repository].
|
||||
|
||||
The stable release _fedora_ repositories for the various primary
|
||||
link:Architectures[architectures] can be found in the directory on the
|
||||
mirrors (where XX is the release), and can also be queried from
|
||||
MirrorManager. For instance,
|
||||
https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-%7B%7BFedoraVersionNumber%7D}&arch=x86_64
|
||||
will return mirrors for the x86_64 _fedora_ repository for .
|
||||
|
||||
[[the-fedora-repository-in-branched-releases]]
|
||||
The _fedora_ repository in link:Releases/Branched[Branched] releases
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
In Branched releases - the state a release is in between branching from
|
||||
link:Releases/Rawhide[Rawhide] and stable release, see
|
||||
link:Releases/Branched[Branched] for more details - the _fedora_
|
||||
repository alone represents the release's _stable_ state. The
|
||||
link:#updates[_updates_ repository] for Branched releases is not used
|
||||
until they become stable. Before the
|
||||
link:Updates_Policy#Bodhi_enabling[Bodhi enabling point], package builds
|
||||
for the Branched release are sent directly to this repository. After the
|
||||
_Bodhi enabling point_, package builds that pass the
|
||||
link:Updates_Policy[Updates Policy] move from link:#updates-testing[the
|
||||
_updates-testing_ repository] to this repository.
|
||||
|
||||
The Branched _fedora_ repositories for the various primary
|
||||
link:Architectures[architectures] can be found in the directory on the
|
||||
mirrors (where XX is the release), and can also be queried from
|
||||
MirrorManager. For instance,
|
||||
https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-%7B%7BFedoraVersionNumber%7Cnext%7D}&arch=x86_64
|
||||
will return mirrors for the x86_64 _fedora_ repository for .
|
||||
|
||||
[[the-updates-repository]]
|
||||
The _updates_ repository
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The _updates_ repository exists for Branched and stable releases, but is
|
||||
only populated and used for stable releases. It is represented for Yum
|
||||
or http://dnf.baseurl.org/[DNF] in the file in the repository path. It
|
||||
exists in Branched releases solely to prevent various tools that expect
|
||||
its existence from breaking. For any Fedora installation, this
|
||||
repository will be enabled by default, and should usually remain so.
|
||||
|
||||
For stable releases, _updates_ together with link:#fedora[_fedora_]
|
||||
represents the current _stable_ state of the release. Package builds
|
||||
that pass the link:Updates_Policy[Updates Policy] move from
|
||||
link:#updates-testing[the _updates-testing_ repository] to this
|
||||
repository. This difference from Branched is a result of the need to
|
||||
maintain a precise representation of the initial, 'frozen' state of a
|
||||
stable release.
|
||||
|
||||
The stable release _updates_ repositories for the various primary
|
||||
link:Architectures[architectures] can be found in the directory on the
|
||||
mirrors (where XX is the release), and can also be queried from
|
||||
MirrorManager. For instance,
|
||||
https://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f%7B%7BFedoraVersionNumber%7D}&arch=x86_64
|
||||
will return mirrors for the x86_64 _updates_ repository for .
|
||||
|
||||
[[the-updates-testing-repository]]
|
||||
The _updates-testing_ repository
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The _updates-testing_ repository exists for Branched releases after the
|
||||
link:Updates_Policy#Bodhi_enabling[Bodhi enabling point], and for stable
|
||||
releases. It is represented for Yum or http://dnf.baseurl.org/[DNF] in
|
||||
the file in the repository path. For both, it is a 'staging' location
|
||||
where new package builds are tested before being marked as 'stable' (and
|
||||
hence moving to the link:#fedora[_fedora_] repository or the
|
||||
link:#updates[_updates_] repository, respectively).
|
||||
|
||||
These builds are sometimes referred to as _update candidates_, and are
|
||||
reviewed with the Bodhi update feedback tool, according to the
|
||||
QA:Update_feedback_guidelines[update feedback guidelines].
|
||||
|
||||
The Updates_Policy defines the rules for marking update candidates as
|
||||
_stable_. The QA:Updates_Testing[QA updates-testing page] provides some
|
||||
information for testers on using this repository. The
|
||||
link:Package_update_HOWTO[package update guidelines] provide information
|
||||
for packagers on submitting builds to _updates-testing_ and to _stable_.
|
||||
|
||||
The _updates-testing_ repository is enabled by default for Branched
|
||||
releases, but disabled by default for stable releases. The switchover is
|
||||
made around the time of the link:Milestone_freezes[Final Freeze] for
|
||||
each release. Testers moving from Branched to stable may encounter
|
||||
errors running updates around this time, caused by dependency mismatches
|
||||
between packages already installed from the now-disabled
|
||||
_updates-testing_ repository. Running (or with yum command) or
|
||||
re-enabling the _updates-testing_ repository will both usually alleviate
|
||||
the issue; it is up to the individual user whether they wish to continue
|
||||
using the _updates-testing_ repository after the stable release or not.
|
||||
|
||||
The _updates-testing_ repositories for both Branched and stable releases
|
||||
can be found in the directory on the mirrors (where XX is the release),
|
||||
and can also be queried from MirrorManager. For instance,
|
||||
https://mirrors.fedoraproject.org/mirrorlist?repo=updates-testing-f%7B%7BFedoraVersionNumber%7D}&arch=x86_64
|
||||
will return mirrors for the x86_64 _updates-testing_ repository for .
|
||||
|
||||
[[the-rawhide-repository]]
|
||||
The _rawhide_ repository
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
In Rawhide - Fedora's rolling release repository, from which release are
|
||||
link:Releases/Branched[Branched] before finally going stable - _rawhide_
|
||||
is the only repository. All package builds are sent there. It is
|
||||
represented for Yum or http://dnf.baseurl.org/[DNF] in the file in the
|
||||
repository path. For any system running Rawhide, it should be enabled.
|
||||
For any other system, it should not.
|
||||
|
||||
The _rawhide_ repositories for the various primary
|
||||
link:Architectures[architectures] can be found in the directory on the
|
||||
mirrors, and can also be queried from MirrorManager. For instance,
|
||||
https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-rawhide&arch=x86_64
|
||||
will return mirrors for the x86_64 _fedora_ repository for Rawhide.
|
||||
|
||||
[[stable-is-not-a-repository]]
|
||||
_stable_ is not a repository
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
It is not unusual to see references to the 'stable repository', but this
|
||||
is something of a misnomer. _stable_ is more of a state that can be
|
||||
considered to exist for both link:Releases/Branched[Branched] releases
|
||||
post-link:Updates_Policy#Bodhi_enabling[Bodhi enabling] and for stable
|
||||
releases. It consists of package builds that were part of
|
||||
link:Releases/Rawhide[Rawhide] at the time they Branched, package builds
|
||||
sent directly to the Branched link:#fedora[_fedora_] repository between
|
||||
the branch point and the _Bodhi enabling point_, and package builds that
|
||||
passed the link:Updates_Policy[Updates Policy] and moved from
|
||||
link:#updates-testing[_updates-testing_] after the _Bodhi enabling
|
||||
point_.
|
||||
|
||||
For Branched releases, the _stable_ state is represented solely by the
|
||||
current contents of the link:#fedora[_fedora_] repository (and,
|
||||
arguably, the link:#bleed[_bleed_] repository, but that is a small
|
||||
case).
|
||||
|
||||
For stable releases, the _stable_ state is represented by the contents
|
||||
of the link:#fedora[_fedora_] repository combined with the contents of
|
||||
the link:#updates[_updates_] repository.
|
||||
|
||||
_stable_ is also a state a package can be considered to be in (or an
|
||||
attribute it can be considered to have) when it has been _pushed stable_
|
||||
or _tagged stable_ and exists in, or will soon exist in, a _stable_
|
||||
repository for a release - whichever literal repository that is (see
|
||||
above).
|
||||
|
||||
[[installation-and-product-repositories-trees]]
|
||||
Installation and link:Fedora.next[Product] repositories / trees
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The repositories referred to above are neither associated with a
|
||||
specific Fedora.next _Product_, nor part of an installable tree (a tree
|
||||
containing the necessary files to be used as a base repository by
|
||||
Anaconda, the Fedora installer). Specialized repositories exist for
|
||||
these purposes.
|
||||
|
||||
For Fedora.next releases - and later - there is (as of September 2014)
|
||||
no installable tree not associated with a specific Product. The
|
||||
installable trees for various Products can be found under on the mirrors
|
||||
for stable releases, and under for Branched pre-release milestones. They
|
||||
can also be queried from MirrorManager. For instance,
|
||||
https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-server-%7B%7BFedoraVersionNumber%7Cnext%7D}&arch=x86_64
|
||||
will return mirrors for the x86_64 current installation repository for
|
||||
Server.
|
||||
|
||||
These repositories are frozen (new packages are not pushed to them) and
|
||||
are created at various points in the
|
||||
link:Fedora_Release_Life_Cycle[Fedora Release Life Cycle]. A new
|
||||
installation tree (containing a repository) is built for several
|
||||
Products for each QA:SOP_compose_request[test compose or release
|
||||
candidate build], and the trees for the Alpha and Beta releases are made
|
||||
available on the mirrors in the directory (see above). They contain a
|
||||
subset of the full package set that is considered to define each Product
|
||||
(see link:How_to_use_and_edit_comps.xml_for_package_groups[comps] for
|
||||
the technical details of this).
|
||||
|
||||
The Product trees for the GA (Final) release are made available in the
|
||||
tree on the mirrors.
|
||||
|
||||
At any given point in the release cycle, the MirrorManager request for a
|
||||
Product repository may redirect to a test compose / release candidate
|
||||
tree, a pre-release milestone tree, or the Final release tree.
|
||||
|
||||
These repositories are usually not used or enabled by default on
|
||||
installed systems, as for that purpose they are redundant with one of
|
||||
the three primary repositories described above. However, one could use a
|
||||
Product repository in place of the link:#fedora[_fedora_] repository to
|
||||
keep a system limited to the Product package set. They are represented
|
||||
for Yum or http://dnf.baseurl.org/[DNF] in the file in the repository
|
||||
path, which may well not be installed on many systems.
|
||||
|
||||
[[other-repositories]]
|
||||
Other repositories
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
There are other repositories that fulfil various niche purposes, which
|
||||
are documented here for the sake of providing a comprehensive reference.
|
||||
They should not usually be significant to the vast majority of Fedora
|
||||
users. None of these repositories is represented in a packaged
|
||||
repository file, enabled by default, or should usually be used in a
|
||||
Fedora installation.
|
||||
|
||||
[[the-bleed-repository]]
|
||||
The _bleed_ repository
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The _bleed_ repository exists for a single purpose: during
|
||||
link:Milestone_freezes[Milestone freezes], it contains packages that
|
||||
have been granted 'freeze exceptions' via the QA:SOP_blocker_bug_process
|
||||
or QA:SOP_freeze_exception_bug_process, and which are desired to be
|
||||
included in the next test compose or release candidate build, but have
|
||||
not yet reached _stable_ state and hence been moved to the
|
||||
link:#fedora[_fedora_] repository. In other words, it contains packages
|
||||
explicitly required in TC/RC QA:SOP_compose_request[compose requests].
|
||||
|
||||
The _bleed_ repository can be found
|
||||
http://kojipkgs.fedoraproject.org/mash/bleed/[here], but again, is not
|
||||
usually of interest to the vast majority of Fedora users. The packages
|
||||
it contains are always also available from the build system, Koji, and
|
||||
usually from the link:#updates-testing[_updates-testing_] repository.
|
||||
|
||||
[[the-latest-repositories]]
|
||||
The _latest_ repositories
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The _latest_ http://kojipkgs.fedoraproject.org/repos/[repositories]
|
||||
contain packages for various build 'tags' as they arrive in the Koji
|
||||
build system. They are not
|
||||
https://git.fedorahosted.org/cgit/mash/[mashed], a process which
|
||||
principally handles multilib, and using them can cause various problems,
|
||||
in addition to overloading Fedora's development servers. It is almost
|
||||
always a better idea to cherry-pick new builds from Koji or Bodhi via
|
||||
their web interfaces or command line tools.
|
||||
|
||||
[[repositories-faq]]
|
||||
Repositories FAQ
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
[[why-is-updates-only-used-after-the-stable-release]]
|
||||
Why is link:#updates[_updates_] only used after the stable release?
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
As described above, updates for both link:Releases/Branched[Branched]
|
||||
pre-releases and final, 'stable' releases go through the
|
||||
link:#updates-testing[_updates-testing_] process before being moved to a
|
||||
link:#stable[_stable_] repository. Before the final release, they are
|
||||
placed in the link:#fedora[_fedora_] repository. After release, they are
|
||||
placed in link:#updates[_updates_].
|
||||
|
||||
The reason for the difference is that we want to have a record of the
|
||||
exact 'state' of a given Fedora stable release. That is, at the time a
|
||||
Fedora release is declared to be done at a link:Go_No_Go_Meeting[Go No
|
||||
Go Meeting], we consider the state of the release at that time to be the
|
||||
canonical definition of that release, and we wish to preserve a record
|
||||
of that state. For a stable release, the tree containing the _fedora_
|
||||
repository *is* that record, and the _fedora_ repository it contains is
|
||||
the canonical record of the precise _frozen_ package set that formed the
|
||||
main part of that stable release.
|
||||
|
||||
Since we wish to maintain this _frozen_ state for the _fedora_
|
||||
repository, we cannot place updates directly into it. The necessity for
|
||||
the _updates_ repository therefore becomes obvious - we need a place to
|
||||
put updates to stable releases that is outside the _frozen_ state of the
|
||||
release.
|
||||
|
||||
Before a stable release occurs, this mechanism is not necessary. Before
|
||||
the release is declared to be done, there is no _frozen_ state of the
|
||||
release: effectively, the whole Branched development process is _working
|
||||
towards_ what will become the _frozen_ state of the release, so of
|
||||
course package builds for the Branched release land directly in the
|
||||
_fedora_ repository.
|
||||
|
||||
[[why-is-updates-testing-enabled-by-default-in-pre-releases]]
|
||||
Why is _updates-testing_ enabled by default in pre-releases?
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
While link:Releases/Branched[Branched] development releases and stable
|
||||
releases both use an link:#updates-testing[_updates-testing_] repository
|
||||
together with the Bodhi update feedback system to stage packages before
|
||||
they reach the release's link:#stable[_stable_] state, it is enabled by
|
||||
default in Branched, but not in stable releases.
|
||||
|
||||
The reason is that the purpose of the _updates-testing_ system is
|
||||
somewhat different in each case. For stable releases, the system's goal
|
||||
is to prevent broken updates reaching the general Fedora user
|
||||
population. In most cases, Fedora systems are expected to have the
|
||||
_updates-testing_ repository disabled. Some QA testers then enable the
|
||||
repository on testing systems to try out the updates and provide
|
||||
feedback. The testers perform the job of making sure the updates are OK
|
||||
before they reach the general user population.
|
||||
|
||||
When it comes to a Branched pre-release, the expectation is that anyone
|
||||
who installs it wants to help test it: we effectively consider anyone
|
||||
running a Branched release to be a tester. The function of
|
||||
_updates-testing_ is different in this case. There is not a 'general
|
||||
user population' of Branched users who run with _updates-testing_
|
||||
disabled, and are protected from problematic updates by the group of
|
||||
update testers. Instead, _updates-testing_ in Branched serves other
|
||||
important functions.
|
||||
|
||||
The main purpose is to insulate _image builds_ from potentially
|
||||
problematic changes. Branched images - nightly images, and the Alpha,
|
||||
Beta and GA (Final) _milestone_ builds and their
|
||||
QA:SOP_compose_request[test compose and release candidate builds] - are
|
||||
built from the _stable_ packages, that is, only those in the _fedora_
|
||||
repository, not those in _updates-testing_. In this sense,
|
||||
_updates-testing_ protects not a set of users, but a set of _builds_,
|
||||
from potentially destabilizing changes. Especially when we are building
|
||||
an Alpha, Beta or GA release, we need to be able to reduce the amount of
|
||||
change in the package set between composes in order to produce an image
|
||||
of high quality. The _updates-testing_ mechanism allows for that: during
|
||||
link:Milestone_freezes[Milestone freezes], new builds can be sent to
|
||||
_updates-testing_, but cannot move from there to _stable_ (_fedora_)
|
||||
without special circumstances (see the
|
||||
QA:SOP_blocker_bug_process[blocker] and
|
||||
QA:SOP_freeze_exception_bug_process[freeze exception] processes). In
|
||||
this way, we can work on release images while not preventing packagers
|
||||
from sending out builds.
|
||||
|
||||
For this and other less important functions, we need as much feedback as
|
||||
possible, so it makes sense to have all pre-release testers have
|
||||
_updates-testing_ enabled by default, and encourage them to provide
|
||||
feedback through Bodhi.
|
||||
|
||||
Category:Release_Engineering[Category:Release Engineering]
|
||||
Category:Packaging
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
155
en-US/reset-root-password.adoc
Normal file
155
en-US/reset-root-password.adoc
Normal file
|
|
@ -0,0 +1,155 @@
|
|||
= How to reset a root password
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/How_to_reset_a_root_password
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
Setting up a root password is a mandatory part of a Fedora installation.
|
||||
If you forget or otherwise lose your root password, there are procedures
|
||||
to reset it.
|
||||
|
||||
* If you have set a password for your boot loader, refer to
|
||||
link:#using-installation-cd-dvd[ this section].
|
||||
* If you want to reset the boot loader password, refer to
|
||||
link:Reset_Bootloader_Password[ these instructions].
|
||||
* If none of these scenarios apply to you, proceed to
|
||||
link:#Entering_Rescue_Mode[ the next section].
|
||||
|
||||
Fedora uses _targets_ to determine the services being run when you start
|
||||
your system. Run level 1 can be used as a rescue mode. Booting Linux
|
||||
under run level 1, which is also called _single user mode_, will display
|
||||
a root prompt on bootup, from which you can reset the root password.
|
||||
|
||||
[[entering-rescue-mode]]
|
||||
Entering Rescue Mode
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
[[using-grub2]]
|
||||
Using GRUB2
|
||||
^^^^^^^^^^^
|
||||
|
||||
While booting the system the GRUB2 menu will be displayed, to boot the
|
||||
system using bash follow these steps:
|
||||
|
||||
* Use the arrow keys to select the boot entry you want to edit
|
||||
* Press *e* to start editing that entry
|
||||
* Use the arrow keys to go to the line that starts with *linux* or
|
||||
*linux16*
|
||||
** If you have a UEFI system it's the line that starts with *linuxefi*
|
||||
* Go the the end of that line add a space then *rw* then another space
|
||||
and *init=/bin/bash*
|
||||
** If your disk is encrypted, you may need to add *plymouth.enable=0* as
|
||||
well
|
||||
* Press *Ctrl-x* or *F10* to boot that entry
|
||||
|
||||
[[changing-root-password]]
|
||||
Changing root password
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
As root, changing password does not ask for your old password. Run the
|
||||
command:
|
||||
|
||||
....
|
||||
# passwd
|
||||
....
|
||||
|
||||
Enter your new root password twice. Congratulations! You now have now
|
||||
reset your root password.
|
||||
|
||||
To make sure that selinux context of file which were now modified is
|
||||
restored properly after reboot, run:
|
||||
|
||||
....
|
||||
# touch /.autorelabel
|
||||
....
|
||||
|
||||
You can than reboot the machine with
|
||||
|
||||
....
|
||||
# /sbin/reboot -f
|
||||
....
|
||||
|
||||
[[reset-password-using-a-fedora-cddvd]]
|
||||
Reset Password Using a Fedora CD/DVD
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
[[using-any-of-the-fedora-live-media]]
|
||||
Using any of the Fedora Live Media
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
* Boot the Live installation media
|
||||
* After it finishes booting and starts the live session, open a terminal
|
||||
and switch to root (using `su`, it won't ask for a password)
|
||||
* Create a directory where you can mount the filesystem of your
|
||||
installation:
|
||||
|
||||
`mkdir /mnt/sysimage`
|
||||
|
||||
* Mount the filesystem of your installation (/dev/sda1 is just an
|
||||
example, be sure to fill in the actual device node of your installation
|
||||
root */* partition):
|
||||
|
||||
`mount /dev/sda1 /mnt/sysimage`
|
||||
|
||||
* chroot to your installation:
|
||||
|
||||
`chroot /mnt/sysimage/`
|
||||
|
||||
* Change the root password:
|
||||
|
||||
`passwd`
|
||||
|
||||
* Exit from the chroot:
|
||||
|
||||
`exit`
|
||||
|
||||
That's it, simply reboot your system and then boot the installation from
|
||||
the HDD as usual.
|
||||
|
||||
[[reset-password-when-bios-is-password-protected]]
|
||||
Reset Password When BIOS is Password Protected
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If you cannot enter rescue mode because you forgot the BIOS password
|
||||
required to select an alternate boot device, you have three options:
|
||||
|
||||
* Refer to your computer's documentation for instructions on resetting
|
||||
the BIOS password in CMOS memory, usually by moving a physical jumper.
|
||||
* Physically change the boot order.
|
||||
* Temporarily move the system hard disk to another machine, and follow
|
||||
the procedures above to reset the root password.
|
||||
|
||||
Category:How_to
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
286
en-US/rhel.adoc
Normal file
286
en-US/rhel.adoc
Normal file
|
|
@ -0,0 +1,286 @@
|
|||
= Red Hat Enterprise Linux
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/Red_Hat_Enterprise_Linux
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
*Red Hat Enterprise Linux* (or RHEL) is a commercially supported
|
||||
derivative of Fedora tailored to meet the requirements of enterprise
|
||||
customers. It is a commercial product from Red Hat which also sponsors
|
||||
Fedora as a community project. Fedora is upstream for Red Hat Enterprise
|
||||
Linux but there are several other link:Derived_distributions[Derived
|
||||
distributions] available too.
|
||||
|
||||
[[whats-the-difference-between-fedora-and-red-hat-enterprise-linux]]
|
||||
What's the difference between Fedora and Red Hat Enterprise Linux?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Watch a video from
|
||||
http://www.redhatmagazine.com/2008/09/16/video-the-history-of-fedora/[Red
|
||||
Hat Magazine].
|
||||
|
||||
Both Fedora and Red Hat Enterprise Linux are open source. Fedora is a
|
||||
free distribution and community project and upstream for Red Hat
|
||||
Enterprise Linux. Fedora is a general purpose system that gives Red Hat
|
||||
and the rest of its contributor community the chance to innovate rapidly
|
||||
with new technologies. Red Hat Enterprise Linux is a commercial
|
||||
enterprise operating system and has its own set of test phases including
|
||||
alpha and beta releases which are separate and distinct from Fedora
|
||||
development.
|
||||
|
||||
The cost of Red Hat Enterprise Linux comes from the subscription, which
|
||||
provides assorted certifications and support for additional
|
||||
architectures, as well as 7 years and more of enterprise support. Red
|
||||
Hat also enhances its Red Hat Enterprise Linux offerings with additional
|
||||
software and with certification programs.
|
||||
|
||||
More information on the release history and lineage is available at
|
||||
link:History_of_Red_Hat_Linux[History of Red Hat Linux].
|
||||
|
||||
When you purchase Red Hat Enterprise Linux, you are also helping to
|
||||
support Fedora. Since Red Hat sponsors Fedora, what is good for Red Hat
|
||||
is usually good for Fedora. The major differences are:
|
||||
|
||||
* Support and associated services: Red Hat Enterprise Linux is a
|
||||
commercially supported product by Red Hat and provides service level
|
||||
agreements that is important for enterprise customers. This support
|
||||
involves both product assistance (hand holding) as well as
|
||||
prioritization of bug fixes and feature requests, certified hardware and
|
||||
software among other things. Fedora is supported by a wide community of
|
||||
developers and users but it is not commercially supported by Red Hat.
|
||||
Red Hat does http://fedoraproject.org/sponsors[sponsor] a large number
|
||||
of resources and link:Accounting[ funds] to the Fedora project including
|
||||
engineering, marketing and other services.
|
||||
|
||||
* link:LifeCycle[Lifecycle]: A new version of Red Hat Enterprise Linux
|
||||
comes out every few years and is supported for up to 10 years and can
|
||||
even be
|
||||
http://www.redhat.com/rhel/server/extended_lifecycle_support/[extended]
|
||||
to 13 years or more with additional subscriptions. New Fedora releases
|
||||
are available about every six months and every release gets updates for
|
||||
about 13 months.
|
||||
|
||||
* Software Packages: Software in Red Hat Enterprise Linux is a limited
|
||||
subset of Fedora and has about 4000 binary packages (RHEL 6). These are
|
||||
the ones enterprise customers demand and are supported by Red Hat.
|
||||
Fedora offers a wide range of software packages and the latest release
|
||||
has well over 25000 unique (not counting updates in Fedora 15) binary
|
||||
software packages available in the repository.
|
||||
|
||||
* Software Updates: Post release updates of software in Red Hat
|
||||
Enterprise Linux are usually limited to backported security and bug
|
||||
fixes, although enhancements are also offered usually via the major
|
||||
scheduled updates. Red Hat also offers
|
||||
http://www.press.redhat.com/2008/12/18/red-hat-increases-service-levels-and-reduces-costs-for-customers-with-extended-update-support/[extended
|
||||
update support] for customers wishing to stick to a single point release
|
||||
for a longer amount of time. Red Hat also aims to provide ABI
|
||||
compatibility within a release, whereas this is not guaranteed by the
|
||||
Fedora Project. Fedora software packages and updates are close to
|
||||
link:Staying_close_to_upstream_projects[ upstream] and include new
|
||||
features routinely.
|
||||
|
||||
* New Releases: Subscriptions are for a specified time period and not
|
||||
for a particular release. So you can move to any currently supported
|
||||
release of Red Hat Enterprise Linux including new versions of RHEL
|
||||
|
||||
Red Hat has a page explaining the benefits of the
|
||||
https://www.redhat.com/rhel/benefits/[subscription] in more detail. It
|
||||
also provides https://www.redhat.com/software/rhelorfedora/[an older
|
||||
comparison between the two options].
|
||||
|
||||
[[what-about-packages-not-part-of-red-hat-enterprise-linux-what-is-epel]]
|
||||
What about packages not part of Red Hat Enterprise Linux? What is EPEL?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
In order to focus Red Hat's efforts and limit support costs, only a
|
||||
selected subset of packages found in Fedora are included in the
|
||||
commercially supported product line. The Fedora Project has a community
|
||||
of people maintaining add-on packages for Red Hat Enterprise Linux and
|
||||
compatible rebuilds called link:EPEL[Extra Packages for Enterprise
|
||||
Linux], or EPEL.
|
||||
|
||||
[[what-is-the-release-cycle-of-red-hat-enterprise-linux]]
|
||||
What is the release cycle of Red Hat Enterprise Linux?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
There is no fixed release schedule for new releases. Red Hat Enterprise
|
||||
Linux is usually released approximately every 18 to 36 months and each
|
||||
release is http://www.redhat.com/security/updates/errata/[maintained for
|
||||
7 years] and can be
|
||||
http://www.redhat.com/rhel/server/extended_lifecycle_support/[extended]
|
||||
up to 10 years. Red Hat also offers
|
||||
http://www.press.redhat.com/2008/12/18/red-hat-increases-service-levels-and-reduces-costs-for-customers-with-extended-update-support/[extended
|
||||
update support] for customers wishing to stick to a single point release
|
||||
for a longer amount of time.
|
||||
|
||||
[[what-is-the-update-policy-for-red-hat-enterprise-linux]]
|
||||
What is the update policy for Red Hat Enterprise Linux?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Red Hat Enterprise Linux updates are more conservative and generally
|
||||
focus on security and bug fixes . Hardware enablement and targeted
|
||||
enhancements are delivered via scheduled minor updates and the policy is
|
||||
described in much more detail
|
||||
https://access.redhat.com/support/policy/updates/errata/[here]
|
||||
|
||||
Fedora's Updates_Policy is more liberal compared to Red Hat Enterprise
|
||||
Linux.
|
||||
|
||||
[[is-red-hat-enterprise-linux-available-for-free-or-low-cost]]
|
||||
Is Red Hat Enterprise Linux available for free or low cost?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
It is a commercial product and not available for free. There is a
|
||||
evaluation version for free download at
|
||||
https://www.redhat.com/rhel/details/eval/ and a version targeted at
|
||||
developers for 99$ at
|
||||
|
||||
https://www.redhat.com/apps/store/developers/rhel_developer_suite.html
|
||||
|
||||
Academic editions are available at a low cost as well
|
||||
|
||||
http://www.redhat.com/solutions/education/academic/
|
||||
|
||||
http://www.redhat.com/solutions/education/academic/individual/
|
||||
|
||||
[[is-red-hat-enterprise-linux-a-open-source-product]]
|
||||
Is Red Hat Enterprise Linux a open source product?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Yes. Binaries and updates are part of the
|
||||
http://www.gnu.org/philosophy/selling.html[commercial] subscription from
|
||||
Red Hat to its customers. The complete source code in the form of source
|
||||
RPM's is available publicly at Red Hat's
|
||||
ftp://ftp.redhat.com/pub/redhat/linux/enterprise/[ftp mirror], which is
|
||||
above and beyond the requirements of any of the free and open source
|
||||
licenses. Red Hat participates in the CentOS project and the sources are
|
||||
available from
|
||||
http://community.redhat.com/centos-faq/#_git_centos_org[their] site as
|
||||
well. Red Hat also provides a complementary repository containing small
|
||||
number of additional packages which are licensed from its partners under
|
||||
different licensing terms.
|
||||
|
||||
[[is-it-possible-to-use-the-publicly-available-source-rpms-to-rebuild-the-distribution]]
|
||||
Is it possible to use the publicly available source RPMs to rebuild the
|
||||
distribution?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Absolutely. All the SRPMS are under free and open source licenses that
|
||||
permit this. There are several such rebuilds and derivatives of Red Hat
|
||||
Enterprise Linux available. http://centos.org[CentOS] and
|
||||
https://www.scientificlinux.org/[Scientific Linux] are popular ones.
|
||||
|
||||
[[whats-the-difference-between-rebuilds-and-red-hat-enterprise-linux]]
|
||||
What's the difference between rebuilds and Red Hat Enterprise Linux ?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Red Hat Enterprise Linux is commercially supported by Red Hat, and
|
||||
offers a range of software and hardware certifications including third
|
||||
party ISV applications. Rebuilds often have a substantial
|
||||
http://lwn.net/Articles/345028/[delay in releasing updates] and
|
||||
especially for releasing rebuilds for
|
||||
https://lwn.net/Articles/435744/[major releases] of RHEL or minor point
|
||||
updates following that. Red Hat also offers other management features
|
||||
via a web service called http://rhn.redhat.com[Red Hat Network] that is
|
||||
not available to such rebuilds. Also, layered products such as Red Hat
|
||||
Application Stack, Red Hat Directory Server and Red Hat Satellite are
|
||||
only supported on top of Red Hat Enterprise Linux subscriptions. Many
|
||||
hardware, software and security certifications are only valid on Red Hat
|
||||
Enterprise Linux and not the rebuilds. Much of the technical content of
|
||||
Red Hat http://kbase.redhat.com[knowledge base] and
|
||||
http://access.redhat.com[customer support portal] is only available to
|
||||
Red Hat customers as well.
|
||||
|
||||
[[whats-the-relationship-between-centos-and-red-hat]]
|
||||
What's the relationship between CentOS and Red Hat?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Red Hat has explained this in detail at
|
||||
http://community.redhat.com/centos-faq/
|
||||
|
||||
[[history]]
|
||||
History
|
||||
~~~~~~~
|
||||
|
||||
Red Hat first offered an enterprise Linux support subscription for Red
|
||||
Hat Linux 6.1. It was not a separate product but the subscription level
|
||||
was branded as Red Hat 6.2E. Subsequently, Red Hat started creating a
|
||||
separate product with commercial service level agreements and longer
|
||||
lifecyle based on Red Hat Linux and later on Fedora. This was initially
|
||||
called as Advanced Server and rebranded as Red Hat Enterprise Linux in
|
||||
2003. The following table gives the lineage:
|
||||
|
||||
[cols=",,,",options="header",]
|
||||
|=======================================================================
|
||||
|Release |Codename |Release Date |Based on
|
||||
|Red Hat Linux 6.2E |Zoot |2000-03-27 |Red Hat Linux 6.2
|
||||
|
||||
|Red Hat Enterprise Linux 2.1 |Pensacola (AS)/ Panama (ES) |2002-03-26
|
||||
(AS) |Red Hat Linux 7.2
|
||||
|
||||
|Red Hat Enterprise Linux 3 |Taroon |2003-10-22 |Red Hat Linux 9
|
||||
|
||||
|Red Hat Enterprise Linux 4 |Nahant |2005-02-15 |Fedora Core 3
|
||||
|
||||
|Red Hat Enterprise Linux 5 |Tikanga |2007-03-14 |Fedora Core 6
|
||||
|
||||
|Red Hat Enterprise Linux 6 |Santiago |2010-11-10 |Mix of Fedora 12
|
||||
Fedora 13 and several modifications
|
||||
|
||||
|Red Hat Enterprise Linux 7 |Maipo |2014-06-10 |Primarily Fedora 19 with
|
||||
several changes from 20 and later
|
||||
|=======================================================================
|
||||
|
||||
Note that while during the release, the releases of Red Hat Enterprise
|
||||
Linux have similarities to the corresponding Fedora releases, the update
|
||||
cycle is very different between these distributions and hence they
|
||||
diverge drastically over time. Rebuilds of Red Hat Enterprise Linux
|
||||
itself such as CentOS and Scientific Linux tend to mirror it quite
|
||||
closely. If you are looking for packages that are available in Fedora
|
||||
but not in Red Hat Enterprise Linux, EPEL repository is a good place to
|
||||
start with.
|
||||
|
||||
* http://www.redhat.com/rhel/
|
||||
* link:Red_Hat_contributions[Red Hat contributions]
|
||||
|
||||
[[articles]]
|
||||
Articles
|
||||
^^^^^^^^
|
||||
|
||||
* http://www.redhat.com/magazine/019may06/features/fedora_rhel_1/
|
||||
* http://www.redhat.com/magazine/020jun06/features/fedora_rhel_2/
|
||||
* http://www.redhat.com/magazine/021jul06/features/fedora_rhel_3/
|
||||
* http://www.redhat.com/magazine/022aug06/features/fedora_rhel_4/
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
107
en-US/spotify.adoc
Normal file
107
en-US/spotify.adoc
Normal file
|
|
@ -0,0 +1,107 @@
|
|||
= Spotify
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/Spotify
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
https://www.spotify.com/[*Spotify*] is a cross-platform (available for
|
||||
Ubuntu, macOS and Windows) proprietary music streaming service. It is a
|
||||
freemium product, that is, a free version of it is available, but it is
|
||||
riddled with advertisements. To use it without advertisements one needs
|
||||
to pay for Spotify premium.
|
||||
|
||||
[[installation]]
|
||||
Installation
|
||||
~~~~~~~~~~~~
|
||||
|
||||
While it is not officially supported on Fedora or any other RPM-based
|
||||
distributions it is possible to get it to work on Fedora. There are two
|
||||
main ways of installing it:
|
||||
|
||||
* Using unofficial repositories like the
|
||||
http://negativo17.org/spotify-client/[negativo17 repository].
|
||||
* Using link:Flatpak[Flatpaks]
|
||||
|
||||
[[flatpak]]
|
||||
Flatpak
|
||||
^^^^^^^
|
||||
|
||||
To install it using Flatpak one needs to get the source files required
|
||||
to build it, then build it and add it to one's Flatpak remote and
|
||||
install it. This can be done using the following set of commands:
|
||||
|
||||
....
|
||||
sudo dnf install flatpak flatpak-builder git make ostree -y
|
||||
flatpak remote-add --from gnome https://sdk.gnome.org/gnome.flatpakrepo
|
||||
flatpak install gnome org.gnome.Platform 3.24
|
||||
flatpak install gnome org.gnome.Sdk 3.24
|
||||
git clone https://github.com/alexlarsson/spotify-app
|
||||
cd spotify-app
|
||||
make
|
||||
flatpak --user remote-add --no-gpg-verify local-spotify repo
|
||||
flatpak --user install local-spotify com.spotify.Client
|
||||
....
|
||||
|
||||
Please consult https://github.com/alexlarsson/spotify-app[the upstream
|
||||
instructions] in case the commands above don't work.
|
||||
|
||||
[[negativo17.org-repository]]
|
||||
Negativo17.org repository
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
This repository also contains the following packages features:
|
||||
|
||||
* Required libraries for enabling local files playback and file upload
|
||||
to personal playlists
|
||||
* Firewalld rules for enabling local service discovery and Spotify
|
||||
Connect (control other devices & output location)
|
||||
|
||||
Installation for Fedora:
|
||||
|
||||
....
|
||||
dnf config-manager --add-repo=http://negativo17.org/repos/fedora-spotify.repo
|
||||
dnf install spotify
|
||||
....
|
||||
|
||||
Installation for CentOS/RHEL 7+:
|
||||
|
||||
....
|
||||
yum-config-manager --add-repo=http://negativo17.org/repos/epel-spotify.repo
|
||||
yum install spotify
|
||||
....
|
||||
|
||||
Category:Audio Category:Proprietary_software[Category:Proprietary
|
||||
software]
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
87
en-US/switch-desktop-env.adoc
Normal file
87
en-US/switch-desktop-env.adoc
Normal file
|
|
@ -0,0 +1,87 @@
|
|||
= Switching Desktop Environments
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/Switching_Desktop_Environments
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
Fedora's default desktop environment is GNOME 3 in the Workstation spin,
|
||||
but it is very easy to try any of the many other desktop environments
|
||||
that are available without affecting your current desktop environment.
|
||||
|
||||
The desktop environment such as KDE, XFCE or MATE can be installed using
|
||||
GNOME Software or with dnf directly from the terminal
|
||||
|
||||
[[installation]]
|
||||
Installation
|
||||
~~~~~~~~~~~~
|
||||
|
||||
To use dnf, first find the full environment name using
|
||||
|
||||
....
|
||||
dnf grouplist -v
|
||||
....
|
||||
|
||||
`Available environment groups:` +
|
||||
` Fedora Server (server-product-environment)` +
|
||||
` Fedora Workstation (workstation-product-environment)` +
|
||||
` Fedora Cloud Server (cloud-server-environment)` +
|
||||
` KDE Plasma Workspaces (kde-desktop-environment)` +
|
||||
` Xfce Desktop (xfce-desktop-environment)` +
|
||||
` LXDE Desktop (lxde-desktop-environment)` +
|
||||
` Cinnamon Desktop (cinnamon-desktop-environment)` +
|
||||
` LXQt Desktop (lxqt-desktop-environment)` +
|
||||
` MATE Desktop (mate-desktop-environment)` +
|
||||
` Sugar Desktop Environment (sugar-desktop-environment)` +
|
||||
` Development and Creative Workstation (developer-workstation-environment)` +
|
||||
` Web Server (web-server-environment)` +
|
||||
` Infrastructure Server (infrastructure-server-environment)` +
|
||||
` Basic Desktop (basic-desktop-environment)` +
|
||||
` Minimal Install (minimal-environment)`
|
||||
|
||||
For actual installation, type the following, and be sure to prefix with
|
||||
the @ sign
|
||||
|
||||
....
|
||||
sudo dnf install @kde-desktop-environment
|
||||
....
|
||||
|
||||
[[switching-desktop-session]]
|
||||
Switching Desktop Session
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Once installed, you can switch to the new desktop simply by logging out
|
||||
and switching the session to the new desktop environment on the login
|
||||
screen. The exact method differs based on the display manager in use.
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
423
en-US/systemd.adoc
Normal file
423
en-US/systemd.adoc
Normal file
|
|
@ -0,0 +1,423 @@
|
|||
= Systemd
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/Systemd
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
systemd is a system and service manager for Linux, compatible with SysV
|
||||
and LSB init scripts. systemd provides aggressive parallelization
|
||||
capabilities, uses socket and D-Bus activation for starting services,
|
||||
offers on-demand starting of daemons, keeps track of processes using
|
||||
Linux cgroups, supports snapshotting and restoring of the system state,
|
||||
maintains mount and automount points and implements an elaborate
|
||||
transactional dependency-based service control logic. It can work as a
|
||||
drop-in replacement for sysvinit. For more information, watch the video
|
||||
at http://www.youtube.com/watch?v=TyMLi8QF6sw
|
||||
|
||||
[[why-systemd]]
|
||||
Why systemd?
|
||||
~~~~~~~~~~~~
|
||||
|
||||
http://0pointer.de/blog/projects/why.html
|
||||
|
||||
[[systemd-documentation]]
|
||||
systemd documentation
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
systemd has very comprehensive documentation. Refer to
|
||||
|
||||
http://0pointer.de/blog/projects/systemd-docs.html
|
||||
|
||||
[[boot-kernel-command-line]]
|
||||
Boot Kernel Command Line
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
On boot *systemd* activates (by default), the target unit
|
||||
_default.target_ whose job is to activate services and other units by
|
||||
pulling them in via dependencies.
|
||||
|
||||
To override the unit to activate, *systemd* parses its own kernel
|
||||
command line arguments via the `systemd.unit=` command line option. This
|
||||
may be used to temporarily boot into a different boot unit. The
|
||||
classical run-levels are replaced as following:
|
||||
|
||||
`systemd.unit=rescue.target` is a special target unit for setting up the
|
||||
base system and a rescue shell (similar to run level 1);
|
||||
`systemd.unit=emergency.target`, is very similar to passing
|
||||
`init=/bin/sh` but with the option to boot the full system from there;
|
||||
`systemd.unit=multi-user.target` for setting up a non-graphical
|
||||
multi-user system; `systemd.unit=graphical.target` for setting up a
|
||||
graphical login screen.
|
||||
|
||||
For details about these special systemd boot units, view the man
|
||||
`systemd.special` page. it scripts
|
||||
|
||||
[[what-is-the-tool-to-manage-services-with-systemd]]
|
||||
What is the tool to manage services with systemd?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
systemctl is the primary tool to use. It combines the functionality of
|
||||
both service and chkconfig into a single tool that you can use for
|
||||
instance to enable/disable services permanently or only for the current
|
||||
session.
|
||||
|
||||
list all running services etc:
|
||||
|
||||
....
|
||||
systemctl
|
||||
....
|
||||
|
||||
Refer to man systemctl for more details. systemd-cgls lists the running
|
||||
process in a tree format. It can recursively show the content of any
|
||||
given control group. Refer to man systemd-cgls for more details.
|
||||
|
||||
[[how-do-i-startstop-or-enabledisable-services]]
|
||||
How do I start/stop or enable/disable services?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Activates a service immediately:
|
||||
|
||||
....
|
||||
systemctl start foo
|
||||
....
|
||||
|
||||
Deactivates a service immediately:
|
||||
|
||||
....
|
||||
systemctl stop foo
|
||||
....
|
||||
|
||||
Restarts a service:
|
||||
|
||||
....
|
||||
systemctl restart foo
|
||||
....
|
||||
|
||||
Shows status of a service including whether it is running or not:
|
||||
|
||||
....
|
||||
systemctl status foo
|
||||
....
|
||||
|
||||
Enables a service to be started on bootup:
|
||||
|
||||
....
|
||||
systemctl enable foo
|
||||
....
|
||||
|
||||
Disables a service to not start during bootup:
|
||||
|
||||
....
|
||||
systemctl disable foo
|
||||
....
|
||||
|
||||
Prevent a service from starting dynamically or even manually unless
|
||||
unmasked:
|
||||
|
||||
....
|
||||
systemctl mask foo
|
||||
....
|
||||
|
||||
Check whether a service is already enabled or not:
|
||||
|
||||
....
|
||||
systemctl is-enabled foo
|
||||
....
|
||||
|
||||
Refer to man systemctl for more details.
|
||||
|
||||
[[how-do-i-change-the-target-runlevel]]
|
||||
How do I change the target (runlevel)?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
systemd has the concept of targets which is a more flexible replacement
|
||||
for runlevels in sysvinit.
|
||||
|
||||
Run level 3 is emulated by multi-user.target. Run level 5 is emulated by
|
||||
graphical.target. runlevel3.target is a symbolic link to
|
||||
multi-user.target and runlevel5.target is a symbolic link to
|
||||
graphical.target.
|
||||
|
||||
You can switch to 'runlevel 3' by running
|
||||
|
||||
....
|
||||
systemctl isolate multi-user.target
|
||||
....
|
||||
|
||||
You can switch to 'runlevel 5' by running
|
||||
|
||||
....
|
||||
systemctl isolate graphical.target
|
||||
....
|
||||
|
||||
[[how-do-i-change-the-default-target]]
|
||||
How do I change the default target?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
....
|
||||
systemctl set-default <name of target>.target
|
||||
....
|
||||
|
||||
graphical.target is the default. You might want multi-user.target for
|
||||
the equivalent of non graphical (runlevel 3) from sysv init. The full
|
||||
list of targets can be accessed via systemctl list-units --type=target
|
||||
|
||||
systemd does not use /etc/inittab file.
|
||||
|
||||
[[how-do-i-know-the-current-target]]
|
||||
How do I know the current target?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
....
|
||||
systemctl get-default
|
||||
....
|
||||
|
||||
[[how-to-power-off-the-machine]]
|
||||
How to power off the machine?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
You can use
|
||||
|
||||
....
|
||||
poweroff
|
||||
....
|
||||
|
||||
Some more possibilities are: `halt -p`, `init 0`, `shutdown -P now`
|
||||
|
||||
Note that `halt` used to work the same as `poweroff` in previous Fedora
|
||||
releases, but systemd distinguishes between the two, so `halt` without
|
||||
parameters now does exactly what it says - it merely stops the system
|
||||
without turning it off.
|
||||
|
||||
[[does-service-command-work-with-systemd]]
|
||||
Does service command work with systemd?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Yes. It has been modified to call systemctl automatically when dealing
|
||||
with systemd service files. So either of the following commands does the
|
||||
same thing
|
||||
|
||||
....
|
||||
systemctl stop NetworkManager
|
||||
....
|
||||
|
||||
(or)
|
||||
|
||||
....
|
||||
service NetworkManager stop
|
||||
....
|
||||
|
||||
[[does-chkconfig-command-work-with-systemd]]
|
||||
Does chkconfig command work with systemd?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Yes, for turning on/off services, compatibility has been provided both
|
||||
ways. chkconfig has been modified to call systemctl when dealing with
|
||||
systemd service files. Also systemctl automatically calls chkconfig when
|
||||
dealing with a traditional sysv init file.
|
||||
|
||||
So either of the following commands does the same thing
|
||||
|
||||
....
|
||||
systemctl disable NetworkManager
|
||||
....
|
||||
|
||||
(or)
|
||||
|
||||
....
|
||||
chkconfig NetworkManager off
|
||||
....
|
||||
|
||||
chkconfig --list doesn't list systemd services, only Sys V services. The
|
||||
output of chkconfig takes note of this, along with supplying additional
|
||||
information.
|
||||
|
||||
[[does-system-config-services-work-with-systemd]]
|
||||
Does system-config-services work with systemd?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Yes. It does.
|
||||
|
||||
[[how-do-i-change-the-number-of-gettys-running-by-default]]
|
||||
How do I change the number of gettys running by default?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The simplest way is to edit /etc/systemd/logind.conf
|
||||
([http://www.freedesktop.org/software/systemd/man/logind.conf.html#NAutoVTs=
|
||||
man page]):
|
||||
|
||||
....
|
||||
[Login]
|
||||
...
|
||||
NAutoVTs=8
|
||||
....
|
||||
|
||||
This setting will take effect after reboot.
|
||||
|
||||
Alternatively, getty@.services which open the login prompt can be
|
||||
enabled and started individually.
|
||||
|
||||
To add another getty:
|
||||
|
||||
....
|
||||
systemctl enable getty@tty8
|
||||
systemctl start getty@tty8
|
||||
....
|
||||
|
||||
To remove a getty:
|
||||
|
||||
....
|
||||
systemctl disable getty@tty8
|
||||
systemctl stop getty@tty8
|
||||
....
|
||||
|
||||
systemd does not use /etc/inittab file.
|
||||
|
||||
[[how-do-i-set-automatic-login-on-a-virtual-console-terminal]]
|
||||
How do I set automatic login on a virtual console terminal?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
First create a new service similar to getty@.service:
|
||||
|
||||
....
|
||||
# cp /lib/systemd/system/getty@.service \
|
||||
/etc/systemd/system/autologin@.service
|
||||
# ln -s /etc/systemd/system/autologin@.service \
|
||||
/etc/systemd/system/getty.target.wants/getty@tty8.service
|
||||
....
|
||||
|
||||
then edit ExecStart, Restart and Alias values, like this:
|
||||
|
||||
....
|
||||
...
|
||||
ExecStart=-/sbin/mingetty --autologin USERNAME %I
|
||||
Restart=no
|
||||
...
|
||||
Alias=getty.target.wants/getty@tty8.service
|
||||
....
|
||||
|
||||
and finally reload daemon and start the service:
|
||||
|
||||
....
|
||||
systemctl daemon-reload
|
||||
systemctl start getty@tty8.service
|
||||
....
|
||||
|
||||
Note that if you exit tty8 session, you wont be able to use it until
|
||||
next reboot or manual start by systemctl, except if you leave Restart as
|
||||
‘always’, but I highly recommend to avoid this according to security
|
||||
reasons.
|
||||
|
||||
[[how-do-i-customize-a-unit-file-add-a-custom-unit-file]]
|
||||
How do I customize a unit file/ add a custom unit file?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The best way to customize unit files is to add
|
||||
/etc/systemd/system/foobar.service.d/*.conf where foobar.service is the
|
||||
name of the service you want to customize. If a directory doesn't
|
||||
already exist, create one and drop a conf file with the settings you
|
||||
want to override. For example,
|
||||
|
||||
/etc/systemd/system/httpd.service.d/restart.conf
|
||||
|
||||
....
|
||||
[Service]
|
||||
Restart=always
|
||||
RestartSec=30
|
||||
....
|
||||
|
||||
Refer to man
|
||||
http://www.freedesktop.org/software/systemd/man/systemd.unit.html[systemd.unit]
|
||||
page for more details.
|
||||
|
||||
Special care must be taken when overriding options which can be set
|
||||
muliple times (`ExecStart`, `ExecStartPre`, `ExecStartPost` are a common
|
||||
example). Assigning some value to the option _appends_ to the existing
|
||||
list, while assiging the _empty_ value _resets_ the list.
|
||||
|
||||
For example, let's say we have a service file like this:
|
||||
|
||||
....
|
||||
[Service]
|
||||
ExecStart=/bin/echo execstart1
|
||||
ExecStart=
|
||||
ExecStart=/bin/echo execstart2
|
||||
ExecStartPost=/bin/echo post1
|
||||
ExecStartPost=/bin/echo post2
|
||||
....
|
||||
|
||||
When started, this service will print
|
||||
|
||||
....
|
||||
execstart2
|
||||
post1
|
||||
post2
|
||||
....
|
||||
|
||||
The same rules apply to snippets in `.d` directories. This means that
|
||||
snippets which override `ExecStart` and similar settings, often should
|
||||
start with the empty assignment `ExecStart=`, followed by the new
|
||||
setting.
|
||||
|
||||
[[how-do-i-debug-systemd-issues]]
|
||||
How do I debug systemd issues?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Refer to How_to_debug_Systemd_problems
|
||||
|
||||
[[man-pages]]
|
||||
Man pages
|
||||
---------
|
||||
|
||||
systemd comes with extensive documentation including several man pages.
|
||||
|
||||
On the web: http://www.freedesktop.org/software/systemd/man/[list of all
|
||||
systemd man pages],
|
||||
http://www.freedesktop.org/software/systemd/man/systemd.directives.html[index
|
||||
of all settings].
|
||||
|
||||
[[references]]
|
||||
References
|
||||
----------
|
||||
|
||||
* http://www.freedesktop.org/wiki/Software/systemd[Project homepage]
|
||||
* http://0pointer.de/blog/projects/ - Lennart's blog has lots of
|
||||
information about systemd. Lennart is the primary systemd developer
|
||||
* http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions
|
||||
* http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks
|
||||
* link:Features/systemd[ Features Fedora 15:systemd]
|
||||
* http://fosdem.org/2011/interview/lennart-poettering.html[Interview
|
||||
with the developer]
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
172
en-US/sysvinit-to-systemd-cheatsheet.adoc
Normal file
172
en-US/sysvinit-to-systemd-cheatsheet.adoc
Normal file
|
|
@ -0,0 +1,172 @@
|
|||
= SysVinit to Systemd Cheatsheet
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
This is a document to help system administrators who need to understand
|
||||
what commands in systemd replace their old workflow in sysvinit. If you
|
||||
want general information on systemd, refer to systemd.
|
||||
|
||||
[[services]]
|
||||
Services
|
||||
~~~~~~~~
|
||||
|
||||
Note that all recent versions of systemctl assume the '.service' if left
|
||||
off. So, 'systemctl start frobozz.service' is the same as 'systemctl
|
||||
start frobozz'
|
||||
|
||||
[cols=",,",options="header",]
|
||||
|=======================================================================
|
||||
|Sysvinit Command |Systemd Command |Notes
|
||||
|service frobozz start |systemctl start frobozz |Used to start a service
|
||||
(not reboot persistent)
|
||||
|
||||
|service frobozz stop |systemctl stop frobozz |Used to stop a service
|
||||
(not reboot persistent)
|
||||
|
||||
|service frobozz restart |systemctl restart frobozz |Used to stop and
|
||||
then start a service
|
||||
|
||||
|service frobozz reload |systemctl reload frobozz |When supported,
|
||||
reloads the config file without interrupting pending operations.
|
||||
|
||||
|service frobozz condrestart |systemctl condrestart frobozz |Restarts if
|
||||
the service is already running.
|
||||
|
||||
|service frobozz status |systemctl status frobozz |Tells whether a
|
||||
service is currently running.
|
||||
|
||||
|ls /etc/rc.d/init.d/ |systemctl (or) systemctl list-unit-files
|
||||
--type=service (or) +
|
||||
ls /lib/systemd/system/*.service /etc/systemd/system/*.service |Used to
|
||||
list the services that can be started or stopped +
|
||||
Used to list all the services and other units
|
||||
|
||||
|chkconfig frobozz on |systemctl enable frobozz |Turn the service on,
|
||||
for start at next boot, or other trigger.
|
||||
|
||||
|chkconfig frobozz off |systemctl disable frobozz |Turn the service off
|
||||
for the next reboot, or any other trigger.
|
||||
|
||||
|chkconfig frobozz |systemctl is-enabled frobozz |Used to check whether
|
||||
a service is configured to start or not in the current environment.
|
||||
|
||||
|chkconfig --list |systemctl list-unit-files --type=service (or) ls
|
||||
/etc/systemd/system/*.wants/ |Print a table of services that lists which
|
||||
runlevels each is configured on or off
|
||||
|
||||
|chkconfig --list | grep 5:on |systemctl list-dependencies
|
||||
graphical.target |Print a table of services that will be started when
|
||||
booting into graphical mode
|
||||
|
||||
|chkconfig frobozz --list |ls
|
||||
/etc/systemd/system/*.wants/frobozz.service |Used to list what levels
|
||||
this service is configured on or off
|
||||
|
||||
|chkconfig frobozz --add |systemctl daemon-reload |Used when you create
|
||||
a new service file or modify any configuration
|
||||
|=======================================================================
|
||||
|
||||
Note that all /sbin/service and /sbin/chkconfig lines listed above
|
||||
continue to work on systemd, and will be translated to native
|
||||
equivalents as necessary. The only exception is chkconfig --list.
|
||||
|
||||
[[runlevelstargets]]
|
||||
Runlevels/targets
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
Systemd has a concept of _targets_ which serve a similar purpose as
|
||||
runlevels but act a little different. Each _target_ is named instead of
|
||||
numbered and is intended to serve a specific purpose. Some _targets_ are
|
||||
implemented by inheriting all of the services of another _target_ and
|
||||
adding additional services to it. There are systemd __target__s that
|
||||
mimic the common sysvinit runlevels so you can still switch __target__s
|
||||
using the familiar `telinit RUNLEVEL` command. The runlevels that are
|
||||
assigned a specific purpose on vanilla Fedora installs; 0, 1, 3, 5, and
|
||||
6; have a 1:1 mapping with a specific systemd _target_. Unfortunately,
|
||||
there's no good way to do the same for the user-defined runlevels like 2
|
||||
and 4. If you make use of those it is suggested that you make a new
|
||||
named systemd _target_ as `/etc/systemd/system/$YOURTARGET` that takes
|
||||
one of the existing runlevels as a base (you can look at
|
||||
`/lib/systemd/system/graphical.target` as an example), make a directory
|
||||
`/etc/systemd/system/$YOURTARGET.wants`, and then symlink the additional
|
||||
services that you want to enable into that directory. (The service unit
|
||||
files that you symlink live in `/lib/systemd/system`).
|
||||
|
||||
[cols=",,",options="header",]
|
||||
|=======================================================================
|
||||
|Sysvinit Runlevel |Systemd Target |Notes
|
||||
|0 |runlevel0.target, poweroff.target |Halt the system.
|
||||
|
||||
|1, s, single |runlevel1.target, rescue.target |Single user mode.
|
||||
|
||||
|2, 4 |runlevel2.target, runlevel4.target, multi-user.target
|
||||
|User-defined/Site-specific runlevels. By default, identical to 3.
|
||||
|
||||
|3 |runlevel3.target, multi-user.target |Multi-user, non-graphical.
|
||||
Users can usually login via multiple consoles or via the network.
|
||||
|
||||
|5 |runlevel5.target, graphical.target |Multi-user, graphical. Usually
|
||||
has all the services of runlevel 3 plus a graphical login.
|
||||
|
||||
|6 |runlevel6.target, reboot.target |Reboot
|
||||
|
||||
|emergency |emergency.target |Emergency shell
|
||||
|=======================================================================
|
||||
|
||||
Changing runlevels:
|
||||
|
||||
[cols=",,",options="header",]
|
||||
|=======================================================================
|
||||
|Sysvinit Command |Systemd Command |Notes
|
||||
|telinit 3 |systemctl isolate multi-user.target (OR systemctl isolate
|
||||
runlevel3.target OR telinit 3) |Change to multi-user run level.
|
||||
|
||||
|sed s/^id:.*:initdefault:/id:3:initdefault:/ |ln -sf
|
||||
/lib/systemd/system/multi-user.target /etc/systemd/system/default.target
|
||||
|Set to use multi-user runlevel on next reboot.
|
||||
|=======================================================================
|
||||
|
||||
Kernel Options:
|
||||
|
||||
The above systemd targets can be used when booting. At the GRUB menu,
|
||||
edit the selection to add "systemd.unit=__target__" (without the
|
||||
double-quotation marks) as a kernel option where _target_ is one of the
|
||||
above. (For example, "rescue.target".)
|
||||
|
||||
Tip: the ".target" extention is optional. The "systemd.unit=rescue"
|
||||
kernel option works the same as "systemd.unit=rescue.target".
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
184
en-US/uefi-with-qemu.adoc
Normal file
184
en-US/uefi-with-qemu.adoc
Normal file
|
|
@ -0,0 +1,184 @@
|
|||
= Using UEFI with QEMU
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/Using_UEFI_with_QEMU
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
[[firmware-installation]]
|
||||
Firmware installation
|
||||
---------------------
|
||||
|
||||
UEFI for x86 QEMU/KVM VMs is called OVMF (Open Virtual Machine
|
||||
Firmware). It comes from EDK2 (EFI Development Kit), which is the UEFI
|
||||
reference implementation.
|
||||
|
||||
[[installing-uefi-for-qemu-from-fedora-repos]]
|
||||
Installing 'UEFI for QEMU' from Fedora repos
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Since June 2016, OVMF is available in Fedora repositories. All you need
|
||||
to have installed is `edk2-ovmf` RPM. Furthermore, it should be now a
|
||||
dependency of the package, so you probably have it installed already.
|
||||
This includes firmware for secureboot (`OVMF_CODE.secboot.fd`)
|
||||
|
||||
[[installing-uefi-for-qemu-nightly-builds]]
|
||||
Installing 'UEFI for QEMU' nightly builds
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Gerd Hoffmann, Red Hatter and QEMU developer, has a dnf repo on his
|
||||
personal site that provides nightly builds of a whole bunch of QEMU/KVM
|
||||
firmware, including EDK2/OVMF.
|
||||
|
||||
Here's how to pull down the nightly builds for x86:
|
||||
|
||||
` sudo dnf install dnf-plugins-core` +
|
||||
` sudo dnf config-manager --add-repo `http://www.kraxel.org/repos/firmware.repo[`http://www.kraxel.org/repos/firmware.repo`] +
|
||||
` sudo dnf install edk2.git-ovmf-x64`
|
||||
|
||||
Note, these are nightly builds, and may occasionally be broken.
|
||||
|
||||
[[optionally-configure-libvirtd-to-advertise-uefi-support]]
|
||||
Optionally Configure libvirtd to advertise UEFI support
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Libvirt needs to know about UEFI->NVRAM config file mapping, so it can
|
||||
advertise it to tools like virt-manager/virt-install. On Fedora 22 and
|
||||
later, libvirt packages are configured to look for the nightly build
|
||||
paths, so this will work out of the box.
|
||||
|
||||
However, if you want to use custom binaries, you will need to edit the
|
||||
nvram variable in /etc/libvirt/qemu.conf and restart libvirtd.
|
||||
|
||||
[[creating-a-vm]]
|
||||
Creating a VM
|
||||
-------------
|
||||
|
||||
[[virt-manager]]
|
||||
virt-manager
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Create a new VM in virt-manager. When you get to the final page of the
|
||||
'New VM' wizard, do the following:
|
||||
|
||||
* Click 'Customize before install', then select 'Finish'
|
||||
* On the 'Overview' screen, Change the 'Firmware' field to select the
|
||||
'UEFI x86_64' option.
|
||||
* Click 'Begin Installation'
|
||||
* The boot screen you'll see should use `linuxefi` commands to boot the
|
||||
installer, and you should be able to run `efibootmgr` inside that
|
||||
system, to verify that you're running an UEFI OS.
|
||||
|
||||
[[virt-install]]
|
||||
virt-install
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Add `--boot uefi` to your `virt-install` command. Example:
|
||||
|
||||
` sudo virt-install --name f20-uefi \` +
|
||||
` --ram 2048 --disk size=20 \` +
|
||||
` --boot uefi \` +
|
||||
` --location `https://dl.fedoraproject.org/pub/fedora/linux/releases/22/Workstation/x86_64/os/[`https://dl.fedoraproject.org/pub/fedora/linux/releases/22/Workstation/x86_64/os/`]
|
||||
|
||||
[[testing-secureboot-in-a-vm]]
|
||||
Testing Secureboot in a VM
|
||||
--------------------------
|
||||
|
||||
These steps describe how to test Fedora Secureboot support inside a KVM
|
||||
VM. The audience here is QA folks that want to test secureboot, and any
|
||||
other curious parties. This requires configuring the VM to use UEFI, so
|
||||
it builds upon the previous UEFI steps.
|
||||
|
||||
[[run-enrolldefaultkeys.efi]]
|
||||
Run EnrollDefaultKeys.efi
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
(Formerly this article recommended the independent utility
|
||||
"LockDown_ms.efi".)
|
||||
|
||||
Since OVMF doesn't ship with any SecureBoot keys installed, we need to
|
||||
install some to mimic what an MS certified UEFI machine will ship with.
|
||||
OVMF now ships with the binaries required to set up a default set of
|
||||
keys. The easiest way is to use UefiShell.iso which is available at
|
||||
`/usr/share/edk2/ovmf/UefiShell.iso`. Boot your VM with this as the
|
||||
CD-ROM image and it should boot into the UEFI shell. At the prompt
|
||||
|
||||
* Shell> fs0:
|
||||
* FS0:\> EnrollDefaultKeys.efi
|
||||
* FS0:\> reset
|
||||
* The VM will restart. Let it boot into Fedora as normal. Log in
|
||||
* You should see the string 'Secure boot enabled' in dmesg. Secureboot
|
||||
is now enabled for every subsequent boot.
|
||||
|
||||
[[testing-fedora-cddvd-secure-boot-in-a-vm]]
|
||||
Testing Fedora CD/DVD Secure Boot in a VM
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Once you have a secureboot configured VM as described above, it's easy
|
||||
to use this to test ISO media secureboot support.
|
||||
|
||||
* Use virt-manager to attach the ISO media to your VM
|
||||
* Use virt-manager to change the VM boot settings to boot off the CDROM
|
||||
* Start the VM
|
||||
* Switch to a terminal inside the VM, verify Secureboot is enabled by
|
||||
checking dmesg
|
||||
|
||||
[[notes]]
|
||||
Notes
|
||||
-----
|
||||
|
||||
[[using-uefi-with-aarch64-vms]]
|
||||
Using UEFI with AArch64 VMs
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
link:Architectures/ARM/AArch64[Fedora's AArch64 releases] will only run
|
||||
on UEFI, so require UEFI inside the VM. However the steps are slightly
|
||||
different. See this page for complete documentation:
|
||||
https://fedoraproject.org/wiki/Architectures/AArch64/Install_with_QEMU
|
||||
|
||||
[[extra-links]]
|
||||
Extra links
|
||||
-----------
|
||||
|
||||
* QA:Testcase_Virtualization_UEFI[QA:Testcase Virtualization UEFI]
|
||||
* http://www.linux-kvm.org/page/OVMF[KVM wiki OVMF page]
|
||||
* https://wiki.ubuntu.com/SecurityTeam/SecureBoot[Ubuntu secureboot
|
||||
page]
|
||||
* http://en.opensuse.org/openSUSE:UEFI_Secure_boot_using_qemu-kvm[OpenSUSE
|
||||
secureboot page]
|
||||
* http://www.labbott.name/blog/2016/09/15/secure-ish-boot-with-qemu/[Using
|
||||
SecureBoot with QEMU]
|
||||
|
||||
Category:Virtualization Category:QA
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
358
en-US/upgrading-fedora-online.adoc
Normal file
358
en-US/upgrading-fedora-online.adoc
Normal file
|
|
@ -0,0 +1,358 @@
|
|||
= Upgrading Fedora using package manager
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/Upgrading_Fedora_using_package_manager
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
This page contains information explaining how to upgrade Fedora online
|
||||
using (without the DNF system upgrade plugin).
|
||||
|
||||
[[upgrading-fedora-using-dnf-directly]]
|
||||
Upgrading Fedora using dnf directly
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
[[participate]]
|
||||
Participate
|
||||
~~~~~~~~~~~
|
||||
|
||||
If you are upgrading using Dnf and it shows any general dependency
|
||||
issues, please file them in http://bugzilla.redhat.com[Bugzilla]. But
|
||||
please read this page, all references pages and search the mailing list
|
||||
archives before filing bugs. And of course, please help keep this page
|
||||
updated.
|
||||
|
||||
If you want to help make live upgrades work smoothly, join the
|
||||
link:SIGs/LiveUpgrade[ Live Upgrade Special Interest Group].
|
||||
|
||||
[[upgrading-across-multiple-releases]]
|
||||
Upgrading across multiple releases
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If you need to upgrade across several releases, it is generally
|
||||
recommended to go one release at a time: for example, rather than going
|
||||
directly from to , first go to and then from there to . This tends to
|
||||
reduce the number of package dependency issues you may encounter. If you
|
||||
are upgrading from an link:End_of_life[End of life] release, please also
|
||||
see link:#eol[the end-of-life section].
|
||||
|
||||
[[instructions-to-upgrade-using-dnf]]
|
||||
Instructions to upgrade using dnf
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
[[backup-your-system]]
|
||||
1. Backup your system
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Backup any personal data to an external hard drive or to another
|
||||
machine. If there is some unrecoverable error that requires a fresh
|
||||
install, you don't want to lose any data.
|
||||
|
||||
[[read-about-common-problems]]
|
||||
2. Read about common problems
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Further down in this page there is a list of common problems specific to
|
||||
dnf upgrades for specific versions. Some of them require attention
|
||||
before the upgrade.
|
||||
|
||||
General advice on upgrading Fedora can be found on the Upgrading page.
|
||||
You should also read the
|
||||
http://docs.fedoraproject.org/install-guide/[Installation Guide] and
|
||||
http://docs.fedoraproject.org/release-notes/[Release Notes] for the
|
||||
version you plan to upgrade to - they contain important information
|
||||
regarding upgrading issues. Finally, check the list of
|
||||
link:Common_bugs[Common bugs].
|
||||
|
||||
[[clean-stuff]]
|
||||
3. Clean Stuff
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
Review and remove all .rpmsave and .rpmnew files before and after
|
||||
upgrading. (And if you have selinux enabled then remember to check
|
||||
security context if you move config files around.)
|
||||
|
||||
Now is a good time to remove packages you don't use - especially
|
||||
non-standard packages.
|
||||
|
||||
[[do-the-upgrade]]
|
||||
4. Do the upgrade
|
||||
^^^^^^^^^^^^^^^^^
|
||||
|
||||
If you have 3rd party repositories configured, you may need to adjust
|
||||
them for the new Fedora version. If you switch from one Fedora release
|
||||
to another there is often nothing that needs to be done. If you switch
|
||||
to Rawhide from a standard Fedora release (or vice versa) then most of
|
||||
the time you will need to install the Rawhide release RPMs from the 3rd
|
||||
party repository as well (or the standard ones, if switching back).
|
||||
|
||||
Note that the upgrade is likely to fail if there are outdated
|
||||
dependencies from packages not backed by a dnf repository or backed by a
|
||||
repository which isn't ready for the new version.
|
||||
|
||||
It is a good idea to do the upgrade outside the graphical environment.
|
||||
Log out of your graphical desktop and then
|
||||
|
||||
[[fedora-upgrade]]
|
||||
fedora-upgrade
|
||||
++++++++++++++
|
||||
|
||||
A small script named fedora-upgrade is available which aims to automate
|
||||
the process outlined below. To run it, do the following
|
||||
|
||||
....
|
||||
$ sudo dnf install fedora-upgrade
|
||||
$ sudo fedora-upgrade
|
||||
....
|
||||
|
||||
When performing upgrade via remote shell, it is good idea to use screen
|
||||
or tmux utility to be able to get back to running transaction in case
|
||||
your connection drops.
|
||||
|
||||
Alternatively, follow the manual steps:
|
||||
|
||||
[[go-to-a-text-console]]
|
||||
Go to a text console
|
||||
++++++++++++++++++++
|
||||
|
||||
....
|
||||
ctrl + alt + F2
|
||||
....
|
||||
|
||||
(or)
|
||||
|
||||
log in as root, and go into multi-user.target
|
||||
|
||||
....
|
||||
systemctl isolate multi-user.target
|
||||
....
|
||||
|
||||
[[fully-update-your-current-fedora-install]]
|
||||
Fully update your current Fedora install
|
||||
++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
....
|
||||
# dnf upgrade
|
||||
....
|
||||
|
||||
[[install-the-package-signing-key-for-the-release-you-are-upgrading-to]]
|
||||
Install the package signing key for the release you are upgrading to
|
||||
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
If you are upgrading across two releases or fewer from Fedora 20 or
|
||||
later, this step should be unnecessary. If you are upgrading from an
|
||||
older Fedora or upgrading across three or more releases, you may need to
|
||||
import the signing key for the target release.
|
||||
|
||||
If it turns out not to be, you should be able to import keys like so:
|
||||
|
||||
....
|
||||
# rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-23-x86_64
|
||||
....
|
||||
|
||||
, replacing "23" and "x86_64" with the new Fedora version and your
|
||||
architecture, respectively.
|
||||
|
||||
You can also find package signing keys for currently-supported releases
|
||||
https://getfedora.org/keys/[here]. Keys for EOL releases can be found
|
||||
https://getfedora.org/keys/obsolete.html[here]. Click _Primary_ (or
|
||||
_Secondary_, if you are using a secondary architecture), and you will
|
||||
see _Get it from: Fedora Project_, where _Fedora Project_ is a link.
|
||||
Copy that URL, and run:
|
||||
|
||||
....
|
||||
# rpm --import (url)
|
||||
....
|
||||
|
||||
to install the key. On old releases, may have trouble doing this; if
|
||||
that happens, download the file with or and import the downloaded file.
|
||||
|
||||
[[clean-the-cache]]
|
||||
Clean the cache
|
||||
+++++++++++++++
|
||||
|
||||
Then remove all traces of the version you are leaving from the dnf cache
|
||||
in `/var/cache/dnf`.
|
||||
|
||||
....
|
||||
# dnf clean all
|
||||
....
|
||||
|
||||
[[upgrade-all-packages]]
|
||||
Upgrade all packages
|
||||
++++++++++++++++++++
|
||||
|
||||
Run the upgrade command:
|
||||
|
||||
....
|
||||
# dnf --releasever=<target_release_number> --setopt=deltarpm=false distro-sync
|
||||
....
|
||||
|
||||
[[make-sure-fedora-is-upgraded]]
|
||||
5. Make sure Fedora is upgraded
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Distro-sync will usually take care of upgrades for the third party
|
||||
repositories you have enabled as well. Confirm with after the upgrade
|
||||
process is over. `dnf` might complain about conflicts or requirements.
|
||||
That is probably because you have used non-standard repositories or
|
||||
installed non-standard packages manually. Try to guess which packages
|
||||
cause the problem (or at least is a part of the dependency chain) -
|
||||
uninstall them and try again. Remember to install the packages again if
|
||||
they are essential.
|
||||
|
||||
Ensure that all (new) essential packages from the new version are
|
||||
installed with
|
||||
|
||||
....
|
||||
# dnf groupupdate 'Minimal Install'
|
||||
....
|
||||
|
||||
You might want to update other groups too, see
|
||||
|
||||
....
|
||||
# dnf grouplist
|
||||
....
|
||||
|
||||
For example
|
||||
|
||||
....
|
||||
# dnf groupupdate "GNOME Desktop" \
|
||||
"Development Tools" "Sound and Video" \
|
||||
"Games and Entertainment" "Administration Tools" \
|
||||
"Office/Productivity" "System Tools"
|
||||
....
|
||||
|
||||
[[preparing-for-reboot]]
|
||||
6. Preparing for reboot
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Before booting you should usually install the bootloader from your new
|
||||
grub by running
|
||||
|
||||
....
|
||||
/usr/sbin/grub2-install BOOTDEVICE
|
||||
....
|
||||
|
||||
- where BOOTDEVICE is often , or for some virtual machine installs. If
|
||||
you have more than one hard disk, make sure you use the correct device!
|
||||
|
||||
If you get an error (e.g. ) from that, then try ).
|
||||
|
||||
It might also be necessary to update the grub config file:
|
||||
|
||||
....
|
||||
cp --backup=numbered -a /boot/grub2/grub.cfg{,.bak} # create backup copy
|
||||
/usr/sbin/grub2-mkconfig -o /boot/grub2/grub.cfg # update config file
|
||||
....
|
||||
|
||||
[[cleanup-your-system]]
|
||||
7. Cleanup your system
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Again, cleanup your system as described in section 2. Also you might
|
||||
want to remove some cache files that are no longer used, for example
|
||||
files from older Fedora releases in the following directories:
|
||||
|
||||
* /var/cache/dnf
|
||||
* /var/cache/mock
|
||||
* /var/lib/mock
|
||||
|
||||
[[release-specific-notes]]
|
||||
Release specific notes
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Note: the release-specific notes for link:End_of_life[End of life]
|
||||
releases are on the
|
||||
link:Upgrading_from_EOL_Fedora_using_package_manager[EOL packager
|
||||
manager upgrade page].
|
||||
|
||||
[[from-pre-release]]
|
||||
From pre-release
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
If you are upgrading to a final release from an Alpha, Beta, or release
|
||||
candidate, please see link:Upgrading_from_pre-release_to_final[Upgrading
|
||||
from pre-release to final].
|
||||
|
||||
[[to-rawhide]]
|
||||
To Rawhide
|
||||
^^^^^^^^^^
|
||||
|
||||
See the link:Releases/Rawhide[Rawhide] release page for more information
|
||||
on Rawhide.
|
||||
|
||||
....
|
||||
# dnf upgrade
|
||||
# dnf install dnf-plugins-core fedora-repos-rawhide
|
||||
# dnf config-manager --set-disabled fedora updates updates-testing
|
||||
# dnf config-manager --set-enabled rawhide
|
||||
# dnf clean -q dbcache packages metadata
|
||||
# dnf --releasever=rawhide --setopt=deltarpm=false distro-sync --nogpgcheck
|
||||
|
||||
## Optional: it is generally advised to do a selinux autorelabel and reboot
|
||||
# touch /.autorelabel
|
||||
....
|
||||
|
||||
[[fedora-25]]
|
||||
Fedora 25
|
||||
^^^^^^^^^
|
||||
|
||||
No special instructions. Follow the above instructions.
|
||||
|
||||
[[fedora-24]]
|
||||
Fedora 24
|
||||
^^^^^^^^^
|
||||
|
||||
No special instructions. Follow the above instructions.
|
||||
|
||||
[[upgrading-from-legacy-end-of-life-eol-fedora-releases]]
|
||||
Upgrading from legacy end of life (EOL) Fedora releases
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Note that Fedora strongly recommends against ever running an end-of-life
|
||||
release on any production system, or any system connected to the public
|
||||
internet, in any circumstances. You should never allow a production
|
||||
Fedora deployment to reach end-of-life in the first place.
|
||||
|
||||
With that in mind, if you do have an end-of-life release installed on a
|
||||
system you cannot just discard or re-deploy, you can attempt to upgrade
|
||||
it, though this is a less-tested and less-supported operation.
|
||||
|
||||
For detailed instructions on upgrades from EOL releases, please read
|
||||
link:Upgrading_from_EOL_Fedora_using_package_manager[Upgrading from EOL
|
||||
Fedora using package manager].
|
||||
|
||||
Category:FAQ Category:How_to[Category:How to] Category:Documentation
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
177
en-US/upgrading.adoc
Normal file
177
en-US/upgrading.adoc
Normal file
|
|
@ -0,0 +1,177 @@
|
|||
= Upgrading
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/Upgrading
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
[[upgrading-fedora-workstation]]
|
||||
Upgrading Fedora Workstation
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Fedora Workstation 23 and later include a graphical system upgrade
|
||||
mechanism. When a newer stable release is available, you should see a
|
||||
graphical notification, similar to the ones you see for system updates.
|
||||
Clicking this, or running the _Software_ application and going to the
|
||||
_Updates_ pane, should show you a simple graphical interface for
|
||||
upgrading the system. It will first download the upgrade files, then
|
||||
prompt you to reboot the system and install them, again in similar
|
||||
fashion to a system update. When the upgrade is complete, the system
|
||||
will reboot again to the new release.
|
||||
|
||||
image:Upgradef24f25-gs.png[Upgradef24f25-gs.png,title="Upgradef24f25-gs.png",width=640]
|
||||
|
||||
[[upgrading-with-dnf-system-upgrade-plugin]]
|
||||
Upgrading with DNF system upgrade plugin
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
For instructions on upgrading with the DNF system upgrade plugin, refer
|
||||
to link:DNF_system_upgrade[the dedicated page]. This mechanism can also
|
||||
be used for Fedora Workstation upgrades if you prefer a command-line
|
||||
tool or if you need to try and analyze some kind of package issue that
|
||||
seems to be preventing the graphical method from working.
|
||||
|
||||
[[online-rebases-for-fedora-atomic-host-via-rpm-ostree]]
|
||||
Online rebases for
|
||||
https://getfedora.org/en/cloud/download/atomic.html[Fedora Atomic Host]
|
||||
via rpm-ostree
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
For instructions on upgrading Fedora Atomic Host installations between
|
||||
Fedora releases, refer to link:Atomic_Host_upgrade[the dedicated page].
|
||||
|
||||
[[online-upgrade-with-pure-dnf]]
|
||||
Online upgrade with pure DNF
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Upgrading from one release to the next using directly, without the DNF
|
||||
system upgrade plugin, is not explicitly tested by Fedora QA and issues
|
||||
with it are not considered blockers for a release, but in practice it
|
||||
works for many users. To learn more, refer to
|
||||
link:Upgrading_Fedora_using_package_manager[Upgrading Fedora using dnf].
|
||||
|
||||
[[updating-from-a-pre-release-alpha-beta-or-other-development-snapshot-to-the-final-release]]
|
||||
Updating from a pre-release (Alpha, Beta, or other development snapshot)
|
||||
to the final release
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If you are using a pre-release of Fedora, and want to know more about
|
||||
upgrading to the final release, refer to
|
||||
link:Upgrading_from_pre-release_to_final[Upgrading from pre-release to
|
||||
final]. This is not technically an 'upgrade' operation, it is simply an
|
||||
update, but there are some special considerations involved in making
|
||||
sure you stay on the update track you intend to use, which are
|
||||
documented on this page.
|
||||
|
||||
[[tips]]
|
||||
Tips
|
||||
~~~~
|
||||
|
||||
* Ensure you have a good backup of your data.
|
||||
|
||||
* Ensure you read the
|
||||
http://docs.fedoraproject.org/en-US/Fedora/%7B%7BFedoraVersionNumber%7D%7D/html/Release_Notes/[Release
|
||||
Notes] carefully before attempting an upgrade.
|
||||
|
||||
[[upgrading-to-rawhide-and-branched]]
|
||||
Upgrading to Rawhide and Branched
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
link:Releases/Rawhide[Rawhide] and link:Releases/Branched[Branched] are
|
||||
the development releases of Fedora. They are suitable for people who are
|
||||
developing or testing Fedora before broad public release. They are *NOT
|
||||
SUITABLE* for regular day-to-day use unless you are a fairly experienced
|
||||
user, and certainly not suitable for mission-critical use. You should
|
||||
read through those pages carefully before deciding to run Branched or,
|
||||
particularly, Rawhide. See link:Fedora_Release_Life_Cycle[Fedora Release
|
||||
Life Cycle] for more information on how the whole Fedora cycle works
|
||||
from Rawhide, to Branched, to the milestone releases (Alpha and Beta),
|
||||
to a 'final' release.
|
||||
|
||||
If you are sure you want to do it, upgrading to a Branched release or to
|
||||
Rawhide can be done with link:DNF_system_upgrade[DNF system upgrade]
|
||||
just like upgrading to a newer stable release. There are just a couple
|
||||
of special notes that are covered in the instructions.
|
||||
|
||||
[[upgrading-from-end-of-life-releases]]
|
||||
Upgrading from link:End_of_life[End of life] releases
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Note that Fedora strongly recommends against ever running an end-of-life
|
||||
release on any production system, or any system connected to the public
|
||||
internet, in any circumstances. You should never allow a production
|
||||
Fedora deployment to reach end-of-life in the first place.
|
||||
|
||||
With that in mind, if you do have an end-of-life release installed on a
|
||||
system you cannot just discard or re-deploy, you can attempt to upgrade
|
||||
it, though this is not officially tested or supported.
|
||||
|
||||
If you have Fedora 21 or later, you can try to upgrade using
|
||||
link:DNF_system_upgrade#eol[DNF system upgrade].
|
||||
|
||||
If you have Fedora 20 or earlier, you will have to perform at least part
|
||||
of the upgrade with
|
||||
link:Upgrading_from_EOL_Fedora_using_package_manager[bare ]. You can
|
||||
either use that method to upgrade to Fedora 21 or later and then use
|
||||
link:DNF_system_upgrade[DNF system upgrade] to upgrade from there to a
|
||||
currently-supported release, or just use bare or for the entire upgrade
|
||||
process.
|
||||
|
||||
Note that when upgrading from Fedora 20 or earlier, you are both
|
||||
upgrading from an end-of-life release and using a
|
||||
not-officially-recommended upgrade mechanism; such upgrades are very
|
||||
much performed 'at your own risk' and may well require various kinds of
|
||||
manual intervention to run and clean up the upgraded system, if they
|
||||
work at all.
|
||||
|
||||
[[upgrading-using-the-fedora-installer-anaconda]]
|
||||
Upgrading using the Fedora installer (anaconda)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Fedora releases up to Fedora 17 included upgrade functionality in the
|
||||
Fedora installer, anaconda. This can be a better choice than
|
||||
link:Upgrading_from_EOL_Fedora_using_package_manager[a package manager
|
||||
upgrade] for some EOL upgrades, especially upgrades to Fedora Core 2,
|
||||
Fedora Core 3, and Fedora 17. If you are attempting to upgrade from
|
||||
Fedora 16 or older, it is highly recommended to upgrade to Fedora 16 and
|
||||
then perform an installer upgrade from Fedora 16 to Fedora 17 before
|
||||
upgrading any further.
|
||||
|
||||
To upgrade using the installer, boot the system from a network install
|
||||
or DVD image for the target release, and run through the initial steps
|
||||
of the install process. After you select storage devices - if your
|
||||
install is located on a 'specialized' storage device, ensure to
|
||||
configure and select it - the installer should offer you the option to
|
||||
upgrade the installed system.
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
273
en-US/windows-virtio-drivers.adoc
Normal file
273
en-US/windows-virtio-drivers.adoc
Normal file
|
|
@ -0,0 +1,273 @@
|
|||
= Windows Virtio Drivers
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/Windows_Virtio_Drivers
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
[[overview]]
|
||||
Overview
|
||||
~~~~~~~~
|
||||
|
||||
This page describes how to obtain and use virtio drivers for Windows
|
||||
virtual machines running on KVM, and additional software agents for
|
||||
Windows VMs.
|
||||
|
||||
[[yumdnf-repo]]
|
||||
Yum|Dnf Repo
|
||||
~~~~~~~~~~~~
|
||||
|
||||
There is a yum|dnf repo shipping 'virtio-win' RPMs. The RPMs install
|
||||
driver binaries and agent installers on your host machine into
|
||||
/usr/share. These bits can then be shared with Windows VMs.
|
||||
|
||||
Install the repo file:
|
||||
|
||||
`sudo wget `https://fedorapeople.org/groups/virt/virtio-win/virtio-win.repo[`https://fedorapeople.org/groups/virt/virtio-win/virtio-win.repo`]` -O /etc/yum.repos.d/virtio-win.repo`
|
||||
|
||||
Then install the virtio-win package with link:dnf[DNF] or YUM:
|
||||
|
||||
`sudo dnf install virtio-win` +
|
||||
`sudo yum install virtio-win`
|
||||
|
||||
The .repo file provides two different repositories:
|
||||
|
||||
* virtio-win-stable
|
||||
** This provides builds of virtio-win that roughly correlates to what
|
||||
was shipped with the most recent RHEL release, meaning they have
|
||||
received a decent chunk of testing.
|
||||
** This repo is enabled by default.
|
||||
|
||||
* virtio-win-latest
|
||||
** This provides the latest driver builds. They may be development
|
||||
quality, or bug free, or complete broken. Caveat emptor :)
|
||||
** This repo is disabled by default. If you want to update from
|
||||
virtio-win-stable to the latest bits, do:
|
||||
`sudo yum --enablerepo=virtio-win-latest update virtio-win`
|
||||
|
||||
or with dnf:
|
||||
`sudo dnf --enablerepo=virtio-win-latest upgrade virtio-win`
|
||||
|
||||
[[rpm-contents]]
|
||||
RPM contents
|
||||
^^^^^^^^^^^^
|
||||
|
||||
* /usr/share/virtio-win/*.iso: ISO CDROM containing all the drivers. See
|
||||
details below
|
||||
* /usr/share/virtio-win/*.vfd: VFD floppy images for using during
|
||||
install of Windows XP
|
||||
* /usr/share/virtio-win/drivers: Copy of the extracted VFD driver
|
||||
contents
|
||||
* /usr/share/guest-agent/*.msi: QEMU Guest Agent 32bit and 64bit MSI
|
||||
installers
|
||||
|
||||
[[iso-contents]]
|
||||
ISO contents
|
||||
^^^^^^^^^^^^
|
||||
|
||||
The .iso contains the following bits:
|
||||
|
||||
* NetKVM/: Virtio Network driver
|
||||
* viostor/: Virtio Block driver
|
||||
* vioscsi/: Virtio SCSI driver
|
||||
* viorng/: Virtio RNG driver
|
||||
* vioser/: Virtio serial driver
|
||||
* Balloon/: Virtio Memory Balloon driver
|
||||
* qxl/: QXL graphics driver for Windows 7 and earlier. (build
|
||||
virtio-win-0.1.103-1 and later)
|
||||
* qxldod/: QXL graphics driver for Windows 8 and later. (build
|
||||
virtio-win-0.1.103-2 and later)
|
||||
* pvpanic/:
|
||||
https://github.com/qemu/qemu/blob/master/docs/specs/pvpanic.txt[QEMU
|
||||
pvpanic] device driver (build virtio-win-0.1.103-2 and later)
|
||||
* guest-agent/: QEMU Guest Agent 32bit and 64bit MSI installers
|
||||
* qemupciserial/:
|
||||
https://github.com/qemu/qemu/blob/master/docs/qemupciserial.inf[QEMU PCI
|
||||
serial] device driver
|
||||
* ** .vfd: VFD floppy images for using during install of Windows XP
|
||||
|
||||
[[direct-download]]
|
||||
Direct download
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Direct downloads are available for the .iso, .vfd, and qemu-ga
|
||||
installers.
|
||||
|
||||
* Stable virtio-win iso:
|
||||
https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso
|
||||
* Stable virtio-win x86 floppy:
|
||||
https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win_x86.vfd
|
||||
* Stable virtio-win amd64 floppy:
|
||||
https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win_amd64.vfd
|
||||
* Latest virtio-win iso:
|
||||
https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/latest-virtio/virtio-win.iso
|
||||
* Latest virtio-win x86 floppy:
|
||||
https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/latest-virtio/virtio-win_x86.vfd
|
||||
* Latest virtio-win amd64 floppy:
|
||||
https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/latest-virtio/virtio-win_amd64.vfd
|
||||
* Latest qemu-ga files:
|
||||
https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/latest-qemu-ga/
|
||||
* Full archive:
|
||||
https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/
|
||||
* Changelog: https://fedorapeople.org/groups/virt/virtio-win/CHANGELOG
|
||||
|
||||
If you previously used isos from alt.fedoraproject.org, note that these
|
||||
new isos have a different file layout (matching RHEL isos). If you need
|
||||
to access the old isos you can do so
|
||||
https://fedorapeople.org/groups/virt/virtio-win/deprecated-isos/[here].
|
||||
However these isos are deprecated and only kept around for back
|
||||
compatability. No new isos will be added there.
|
||||
|
||||
[[faq]]
|
||||
FAQ
|
||||
~~~
|
||||
|
||||
[[what-license-are-these-drivers]]
|
||||
What license are these drivers?
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The drivers are licensed under the GPLv2.
|
||||
|
||||
[[why-arent-the-drivers-shipped-as-part-of-fedora]]
|
||||
Why aren't the drivers shipped as part of Fedora?
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The drivers cannot be shipped as part of Fedora because they can't be
|
||||
built in Fedora's build system; the only way to build the drivers is on
|
||||
a Windows machine. Shipping pre-compiled sources is generally against
|
||||
Fedora policies. There's likely other objections as well.
|
||||
|
||||
[[where-do-the-builds-come-from]]
|
||||
Where do the builds come from?
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
All the windows binaries are scooped up from builds done on Red Hat's
|
||||
internal build system, which are generated using publicly available
|
||||
code.
|
||||
|
||||
See the README in this repo for some more details about how the RPM and
|
||||
repo are built: https://github.com/crobinso/virtio-win-pkg-scripts
|
||||
|
||||
[[what-is-the-reasoning-behind-the-rpmiso-layout]]
|
||||
What is the reasoning behind the RPM/ISO layout?
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
For starters, the primary purpose of the RPM/ISO is to mirror exactly
|
||||
the layout that is shipped with the latest RHEL release. This is so
|
||||
user/developers don't have to deal with differences between the two
|
||||
distros.
|
||||
|
||||
(Note: Historically the .iso files shipped on alt.fedoraproject.org did
|
||||
_not_ match the layout of the .iso shipped in RHEL. This changed in
|
||||
April 2015)
|
||||
|
||||
* The .iso directories are named after the driver code directories from
|
||||
the upstream driver git tree. There isn't much more to it than that.
|
||||
* Below the driver directories, the $winversion/$arch/ directory naming
|
||||
is a windows convention.
|
||||
* The RPM layout is kind of arbitrary in that it ships the .vfd content
|
||||
in the drivers/ dir, but not many of the other drivers from the .iso.
|
||||
This seems to be an historical oversight and should probably be fixed.
|
||||
|
||||
[[are-these-drivers-signed]]
|
||||
Are these drivers signed?
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
These drivers are cryptographically signed with Red Hat's vendor
|
||||
signature. However they are not signed with
|
||||
https://msdn.microsoft.com/en-us/library/windows/hardware/ff553976%28v=vs.85%29.aspx[Microsoft's
|
||||
WHQL signature].
|
||||
|
||||
[[how-are-these-drivers-different-from-what-is-shipped-with-rhel]]
|
||||
How are these drivers different from what is shipped with RHEL?
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The RPMs from the stable repository are the same driver builds as what
|
||||
is shipped in RHEL. However, the public drivers are not signed with
|
||||
https://msdn.microsoft.com/en-us/library/windows/hardware/ff553976%28v=vs.85%29.aspx[Microsoft's
|
||||
WHQL signature].
|
||||
|
||||
[[how-does-lack-of-whql-signature-affect-use-of-these-drivers]]
|
||||
How does lack of WHQL signature affect use of these drivers?
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
FIXME: Lack of WHQL signature causes windows to complain, need to
|
||||
explicitly document how
|
||||
|
||||
[[bugs]]
|
||||
Bugs
|
||||
~~~~
|
||||
|
||||
Please file any bug reports against
|
||||
https://bugzilla.redhat.com/enter_bug.cgi?product=Virtualization%20Tools&component=virtio-win[Product=Virtualization
|
||||
Tools Component=virtio-win]
|
||||
|
||||
When filing a bug, please provide the following info:
|
||||
|
||||
* The virtio-win version
|
||||
* The host distro
|
||||
* The qemu version
|
||||
* If using libvirt: sudo virsh dumpxml $vmname
|
||||
* The qemu command line. If using libvirt this can be found at
|
||||
/var/log/libvirt/qemu/$vmname.log
|
||||
|
||||
Questions/Comments about the RPMs or yum|dnf repos should be sent to
|
||||
regular fedora virt locations:
|
||||
https://fedoraproject.org/wiki/Virtualization#Mailing_list_and_IRC
|
||||
Questions/Comments about the actual drivers are probably best send to
|
||||
the upstream
|
||||
https://lists.nongnu.org/mailman/listinfo/qemu-devel[qemu-devel] or
|
||||
http://www.linux-kvm.org/page/Lists,_IRC[kvm] mailing lists
|
||||
|
||||
[[links]]
|
||||
Links
|
||||
~~~~~
|
||||
|
||||
* KVM windows guest drivers upstream code:
|
||||
https://github.com/virtio-win/kvm-guest-drivers-windows
|
||||
* QXL XDDM driver code: http://cgit.freedesktop.org/spice/win32/qxl
|
||||
* QXL WDDM driver code: https://github.com/vrozenfe/qxl-dod
|
||||
* Tree used by gnome-boxes for automatic driver installation:
|
||||
https://zeenix.fedorapeople.org/drivers/
|
||||
* Windows spice agent git repo:
|
||||
http://cgit.freedesktop.org/spice/win32/vd_agent
|
||||
* Spice guest tools installer code:
|
||||
http://cgit.freedesktop.org/~teuf/spice-nsis/
|
||||
* spice-guest-tools downloads:
|
||||
http://www.spice-space.org/download/binaries/spice-guest-tools/
|
||||
* Fedora virtio-win build scripts:
|
||||
https://github.com/crobinso/virtio-win-pkg-scripts
|
||||
|
||||
Category:Virtualization
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
213
en-US/wine.adoc
Normal file
213
en-US/wine.adoc
Normal file
|
|
@ -0,0 +1,213 @@
|
|||
= Wine
|
||||
|
||||
'''
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
|
||||
This page was automatically converted from https://fedoraproject.org/wiki/Wine
|
||||
|
||||
It is probably
|
||||
|
||||
* Badly formatted
|
||||
* Missing graphics and tables that do not covert well from mediawiki
|
||||
* Out-of-date
|
||||
* In need of other love
|
||||
|
||||
Please fix it, remove this notice, and then add to `_topic_map.yml`
|
||||
|
||||
Pull requests accepted at https://pagure.io/fedora-docs/fedora-howto
|
||||
|
||||
Once that is live, go to the original wiki page and add an `{{old}}`
|
||||
tag, followed by a note like
|
||||
|
||||
....
|
||||
{{admon/note|This page has a new home!|
|
||||
This wiki page is no longer maintained. Please find the up-to-date
|
||||
version at: https://docs.fedoraproject.org/whatever-the-url
|
||||
}}
|
||||
....
|
||||
|
||||
======
|
||||
|
||||
'''
|
||||
|
||||
|
||||
http://winehq.org/[Wine] is an open source implementation of the Windows
|
||||
API on top of X and OpenGL.
|
||||
|
||||
[[packages]]
|
||||
Packages
|
||||
~~~~~~~~
|
||||
|
||||
Fedora's Wine packages are split up to allow for smaller installations.
|
||||
The `wine` meta package will bring with it the most important components
|
||||
of Wine. Expert users may want to pick specific components from the list
|
||||
below:
|
||||
|
||||
[cols=",",]
|
||||
|=======================================================================
|
||||
|*name* |''' summary '''
|
||||
|
||||
|_wine_ |Meta package
|
||||
|
||||
|_wine-alsa_ |ALSA sound support for wine
|
||||
|
||||
|_wine-arial-fonts_ |Arial fonts provided by wine-staging
|
||||
|
||||
|_wine-capi_ |ISDN support for wine
|
||||
|
||||
|_wine-cms_ |Color Management for wine
|
||||
|
||||
|_wine-common_ |Common wine files and scripts
|
||||
|
||||
|_wine-core_ |Wine core package
|
||||
|
||||
|_wine-courier-fonts_ |Wine Courier font family
|
||||
|
||||
|_wine-desktop_ |Desktop integration features
|
||||
|
||||
|_wine-devel_ |Wine development environment
|
||||
|
||||
|_wine-filesystem_ |Filesystem directories and basic configuration for
|
||||
wine
|
||||
|
||||
|_wine-fixedsys-fonts_ |Wine Fixedsys font family
|
||||
|
||||
|_wine-fonts_ |Wine font meta package
|
||||
|
||||
|_wine-ldap_ |LDAP support for wine
|
||||
|
||||
|_wine-marlett-fonts_ |Wine Marlett font family
|
||||
|
||||
|_wine-ms-sans-serif-fonts_ |Wine MS Sans Serif font family
|
||||
|
||||
|_wine-openal_ |OpenAL sound support for wine
|
||||
|
||||
|_wine-opencl_ |OpenCL support for wine
|
||||
|
||||
|_wine-pulseaudio_ |PulseAudio support for wine
|
||||
|
||||
|_wine-small-fonts_ |Wine Small font family
|
||||
|
||||
|_wine-symbol-fonts_ |Wine Symbol font family
|
||||
|
||||
|_wine-systemd_ |Systemd configuration for the wine binfmt handler
|
||||
|
||||
|_wine-system-fonts_ |Wine System font family
|
||||
|
||||
|_wine-sysvinit_ |SysV initscript for the wine binfmt handler
|
||||
|
||||
|_wine-tahoma-fonts_ |Wine Tahoma font family
|
||||
|
||||
|_wine-tahoma-fonts-system_ |Wine Tahoma font family system integration
|
||||
|
||||
|_wine-twain_ |Twain (image scanning) support for wine
|
||||
|
||||
|_wine-wingdings-fonts_ |Wine Wingdings font family
|
||||
|
||||
|_wine-wingdings-fonts-system_ |Wine Wingdings font family system
|
||||
integration
|
||||
|=======================================================================
|
||||
|
||||
Additional documentation is provided via the ''wine-docs '' package.
|
||||
|
||||
[[available-versions]]
|
||||
Available versions
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Fedora applies fixes and features from the *wine-staging* project. EPEL
|
||||
packages do not use wine-staging patches.
|
||||
|
||||
*Current versions of Wine in Fedora:*
|
||||
|
||||
[cols=",",]
|
||||
|=================
|
||||
|Fedora 25 |1.9.21
|
||||
|Fedora 24 |1.9.20
|
||||
|EPEL 7 |1.8.5
|
||||
|EPEL 6 |1.8.5
|
||||
|EPEL 5 |1.0.1
|
||||
|=================
|
||||
|
||||
Newer versions may be available in the corresponding `updates-testing`
|
||||
repositories.
|
||||
|
||||
[[testing-versions]]
|
||||
Testing Versions
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
[cols=",",]
|
||||
|=================
|
||||
|Fedora 25 |1.9.22
|
||||
|Fedora 24 |1.9.22
|
||||
|EPEL 7 |-
|
||||
|EPEL 6 |-
|
||||
|EPEL 5 |-
|
||||
|=================
|
||||
|
||||
[[bugs-and-problems]]
|
||||
Bugs and problems
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
Before reporting bugs against Wine please make sure your system is fully
|
||||
up to date.
|
||||
|
||||
....
|
||||
dnf update
|
||||
....
|
||||
|
||||
Also check if a newer version is available in updates-testing.
|
||||
|
||||
....
|
||||
dnf --enablerepo=updates-testing update wine
|
||||
....
|
||||
|
||||
If you are using the proprietary graphics drivers please remove them
|
||||
from your system and try again, as they are known to cause problems.
|
||||
|
||||
When debugging Wine, your goal is to determine if the issue is one of
|
||||
_code functionality_ or _packaging in Fedora_.
|
||||
|
||||
Check the http://appdb.winehq.org[Wine Application Database] to see if
|
||||
your application is supported, or if there are known issues that match
|
||||
yours. Anything that falls into this category is a bug in upstream code
|
||||
functionality.
|
||||
|
||||
The next step is to see if the problem persists with a clean ~/.wine
|
||||
folder. To try this without losing your old configuration:
|
||||
|
||||
....
|
||||
mv ~/.wine ~/.wine-save
|
||||
....
|
||||
|
||||
Afterwards try to trigger the bug again. Your original wine folder can
|
||||
be restored with:
|
||||
|
||||
....
|
||||
rm -fr ~/.wine; mv ~/.wine-save ~/.wine
|
||||
....
|
||||
|
||||
If your application still does not work but has been working in a
|
||||
previous version of wine it is probably a regression. Consider filling a
|
||||
bug in the upstream https://bugs.wine-staging.com/[Wine-staging bug
|
||||
tracking system]. *Do not* file bugs in the Winehq.org bugzilla unless
|
||||
told to do so.
|
||||
|
||||
If you really think that your bug is Fedora-related, file a bug against
|
||||
the Wine component in https://bugzilla.redhat.com[Fedora's bug tracking
|
||||
system].
|
||||
|
||||
[[updates-testing]]
|
||||
Updates-Testing
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
If you use the version of wine in the updates-testing repository then
|
||||
please log into https://admin.fedoraproject.org/updates[bodhi] and
|
||||
comment on the build, including any problems that may be in the
|
||||
packaging, naming, or elsewhere. The build needs positive karma to be
|
||||
pushed to the updates repository.
|
||||
'''
|
||||
|
||||
See a typo, something missing or out of date, or anything else which can be
|
||||
improved? Edit this document at https://pagure.io/fedora-docs/fedora-howto.
|
||||
Loading…
Add table
Add a link
Reference in a new issue