mirror of
https://pagure.io/fedora-docs/quick-docs.git
synced 2024-11-28 14:56:35 +00:00
suppress indentation warning
This commit is contained in:
Jibec
parent
42424954aa
commit
20dcd9a7c7
32 changed files with 222 additions and 225 deletions
|
|
@ -11,5 +11,5 @@ The current Fedora RPM/ISO directory structure is laid out to mirror exactly the
|
|||
|
||||
* The `.iso` directories are named after the driver code directories from the upstream driver git tree.
|
||||
* Below the driver directories, the `$winversion/$arch/` directory naming
|
||||
is a Windows convention.
|
||||
is a Windows convention.
|
||||
* The RPM layout is 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.
|
||||
|
|
|
|||
|
|
@ -3,14 +3,14 @@
|
|||
There are several graphical user interfaces available to configure iptables.
|
||||
|
||||
* link:http://www.fwbuilder.org/_fwbuilder[fwbuilder]: Very complete GUI tools
|
||||
to configure iptables.
|
||||
to configure iptables.
|
||||
* link:http://shorewall.net/_Shorewall[Shorewall]: Another very complete GUI
|
||||
like fwbuilder.
|
||||
like fwbuilder.
|
||||
* link:http://www.turtlefirewall.com/_Turtle_firewall_project[Turtle firewall
|
||||
project]: Web interface and integrated to webmin. But it can not handle all
|
||||
iptables options.
|
||||
project]: Web interface and integrated to webmin. But it can not handle all
|
||||
iptables options.
|
||||
* link:http://users.telenet.be/stes/ipmenu.html_IPmenu[IPmenu] :A console based
|
||||
interface that covers all iptables functionality.
|
||||
interface that covers all iptables functionality.
|
||||
|
||||
The following section describes yet another frontend: `system-config-firewall`.
|
||||
|
||||
|
|
|
|||
|
|
@ -104,5 +104,5 @@ You can also use the following abbreviations of the [application]*nmcli* command
|
|||
== Additional resources
|
||||
|
||||
* For more examples, see the
|
||||
[citetitle]_pass:attributes[{blank}]*nmcli-examples*(5)_
|
||||
man page.
|
||||
[citetitle]_pass:attributes[{blank}]*nmcli-examples*(5)_
|
||||
man page.
|
||||
|
|
|
|||
|
|
@ -24,9 +24,9 @@ The configuration of the live image is defined by a file called _kickstart_. It
|
|||
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.
|
||||
: 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.
|
||||
: 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 `/usr/share/spin-kickstarts/` 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.
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ Other people use your public key to authenticate and/or decrypt your communicati
|
|||
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..
|
||||
|
||||
. Press the kbd:[Enter] key to assign a default value if desired.
|
||||
The first prompt asks you to select what kind of key you prefer:
|
||||
The first prompt asks you to select what kind of key you prefer:
|
||||
+
|
||||
----
|
||||
Please select what kind of key you want:
|
||||
|
|
@ -36,8 +36,8 @@ What keysize do you want? (2048)
|
|||
Again, the default is sufficient for almost all users, and represents an _extremely_ strong level of security.
|
||||
|
||||
. 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.
|
||||
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.
|
||||
|
|
@ -60,22 +60,22 @@ Is this correct (y/n)?
|
|||
. Enter `y` to finish the process.
|
||||
|
||||
. 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.
|
||||
_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 https://fedoraproject.org/wiki/Introduce_yourself_to_the_Docs_Project[self-introduction] on a mailing list, for example, enter the email address you use on that list.
|
||||
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 https://fedoraproject.org/wiki/Introduce_yourself_to_the_Docs_Project[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.")
|
||||
(Some people use different keys for different purposes and identify each key with a comment, such as "Office" or "Open Source Projects.")
|
||||
|
||||
. Enter the letter `O` at the confirmation prompt to continue if all entries are correct, or use the other options to fix any problems.
|
||||
|
||||
. Enter a passphrase for your secret key.
|
||||
The `gpg2` program asks you to enter your passphrase twice to ensure you made no typing errors.
|
||||
The `gpg2` program asks you to enter your passphrase twice to ensure you made no typing errors.
|
||||
|
||||
Finally, `gpg2` 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.
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Install the Seahorse utility, which makes GPG key management easier.
|
|||
. 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 "dnf install seahorse"`.
|
||||
You can also install Seahorse using the command line with the command `su -c "dnf install seahorse"`.
|
||||
|
||||
To create a key:
|
||||
|
||||
|
|
|
|||
|
|
@ -2,13 +2,13 @@
|
|||
= Creating GPG Keys Using the KDE Desktop
|
||||
|
||||
. Start the KGpg program from the main menu by selecting menu:Utilities[PIM > KGpg].
|
||||
If you have never used KGpg before, the program walks you through the process of creating your own GPG keypair.
|
||||
If you have never used KGpg before, the program walks you through the process of creating your own GPG keypair.
|
||||
|
||||
. Enter your name, email address, and an optional comment in the dialog box that appears prompting you to create a new key pair.
|
||||
You can also choose an expiration time for your key, as well as the key strength (number of bits) and algorithms.
|
||||
You can also choose an expiration time for your key, as well as the key strength (number of bits) and algorithms.
|
||||
|
||||
. Enter your passphrase in the next dialog box.
|
||||
At this point, your key appears in the main KGpg window.
|
||||
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`.
|
||||
|
|
|
|||
|
|
@ -6,9 +6,9 @@ Once you have downloaded the rpm, you can enable the repository.
|
|||
== To enable repo:
|
||||
|
||||
. Login as root:
|
||||
`$ su`
|
||||
`$ su`
|
||||
|
||||
. Create a file in */etc/yum.repos.d/* directory to enable third party repository. This file must end with *.repo* . The repository file contains the URL of the the repository, a name, enabled, gpgcheck.
|
||||
|
||||
. To enable repo, use the following command:
|
||||
`# dnf --enablerepo=<reponame>`
|
||||
`# dnf --enablerepo=<reponame>`
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ If you are not sure whether FirewallD is on your Fedora installation use the fol
|
|||
|
||||
|
||||
. Check if your system has FirewallD enabled.
|
||||
Enter the folowing on the command line:
|
||||
Enter the folowing on the command line:
|
||||
|
||||
[source,bash]
|
||||
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ In many cases, the error logs are most easily read with the less program, a comm
|
|||
if SQL isn’t behaving as expected, you can obtain more information about the source of the
|
||||
|
||||
* **systemctl status mysqld.service** doesn't start well, This information doesn’t explain
|
||||
well what is happening?, after this command you should type `journalctl -xe -u mariadb -u mysqld`.
|
||||
well what is happening?, after this command you should type `journalctl -xe -u mariadb -u mysqld`.
|
||||
* Look at Log files, can be located in `/var/log/mysql/mysqld.log` for MySQL, and `/var/log/mariabd` for MariaDB.
|
||||
|
||||
== How To Troubleshoot Socket Errors in SQL
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ Common causes of the rainbow display include:
|
|||
* Insufficient power supply. See the xref:raspberry-pi-prerequisites[Prerequisites] section at the beginning of this document.
|
||||
|
||||
* There's no operating system installed. Check that an operating system was installed and the microSD card was properly inserted into the Raspberry Pi.
|
||||
For instructions about Fedora ARM on Raspberry Pi:
|
||||
For instructions about Fedora ARM on Raspberry Pi:
|
||||
** For Fedora users, see: <<installing-fedora-on-a-raspberry-pi-using-the-fedora-arm-installer_{context}>>.
|
||||
** For users of other Linux distributions, see: <<installing-fedora-on-a-raspberry-pi-for-linux-users_{context}>>.
|
||||
** For Microsoft Windows users, see: <<installing-fedora-on-a-raspberry-pi-for-microsoft-windows-users_{context}>>.
|
||||
|
|
|
|||
|
|
@ -23,8 +23,7 @@ ISO is used to install paravirtual drivers in Windows guests. The `virtio-win/*.
|
|||
* `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
|
||||
* `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
|
||||
|
||||
NOTE: If you previously used isos from alt.fedoraproject.org, note that the current isos have a different file layout that matches the layout of the Red Hat Enterprise Linux isos. If you need old isos for backwards compatiblity you can find them on the https://fedorapeople.org/groups/virt/virtio-win/deprecated-isos/[deprecated isos page].
|
||||
|
|
|
|||
|
|
@ -57,17 +57,17 @@ where:
|
|||
|
||||
* `H:M:S` is the message timestamp
|
||||
* `ms` is the millisecond part of timestamp.
|
||||
Note that this will usually become zero on a remote syslog.
|
||||
Note that this will usually become zero on a remote syslog.
|
||||
* `LOGLEVEL` is the message loglevel.
|
||||
In theory, because kernel messages are part of anaconda logs, all loglevels that are defined in rsyslog can appear in the logfiles.
|
||||
Anaconda itself will however log only at the following loglevels:
|
||||
In theory, because kernel messages are part of anaconda logs, all loglevels that are defined in rsyslog can appear in the logfiles.
|
||||
Anaconda itself will however log only at the following loglevels:
|
||||
** `DEBUG`
|
||||
** `INFO`
|
||||
** `WARN`
|
||||
** `ERR`
|
||||
** `CRIT`
|
||||
* `facility` is the program or component that created the message.
|
||||
Could be for instance `kernel`, `anaconda`, `storage` or similar.
|
||||
Could be for instance `kernel`, `anaconda`, `storage` or similar.
|
||||
* `message` is the log message itself.
|
||||
|
||||
For the logs running in terminals, the format simply is:
|
||||
|
|
@ -144,7 +144,7 @@ Step by step instructions to set everything up follow:
|
|||
|
||||
. Create a testing virtual machine, e.g. using Virtual Manager </li>
|
||||
. Add the virtio-serial port to your virtual machine, direct it to the TCP port 6080 on the host.
|
||||
Start by editing the guest configuration:`virsh edit <machine name>`
|
||||
Start by editing the guest configuration:`virsh edit <machine name>`
|
||||
. In the guest editor, add following information into the `<devices>` section:
|
||||
[source,xml]
|
||||
----
|
||||
|
|
@ -159,7 +159,7 @@ eval `analog -p 6080 -o rsyslogd.conf -s /home/akozumpl/remote_inst`
|
|||
----
|
||||
. Start the virtual machine.
|
||||
. Continue with the installation.
|
||||
Immediately after the Anaconda greeting is displayed the log messages will appear in the directory given to `analog` script, in the `127.0.0.1` subdirectory.
|
||||
Immediately after the Anaconda greeting is displayed the log messages will appear in the directory given to `analog` script, in the `127.0.0.1` subdirectory.
|
||||
|
||||
==== virt-install
|
||||
|
||||
|
|
@ -174,8 +174,8 @@ If you are using virt-install you can configure it with the --channel option:
|
|||
* chroot syslog messages from `/mnt/sysimage/root/install.log.syslog` are not forwarded.
|
||||
* it is not possible to start the machine unless something is listening on the TCP port where virtio-serial is connected.
|
||||
* if you want to test that the virtio connection is working, instead of using analog and rsyslog just let a netcat utility listen on the given port, e.g.
|
||||
`nc -l 0.0.0.0 6080`.
|
||||
You should start seeing raw logs in the terminal once the guest machine starts booting.
|
||||
`nc -l 0.0.0.0 6080`.
|
||||
You should start seeing raw logs in the terminal once the guest machine starts booting.
|
||||
* if both remote TCP logging via `syslog=` and remote virtio logging via `virtiolog=` are specified on the command line, one has to setup two rsyslogd instances on the server/host to listen to both the connections otherwise the sending rsyslog's queues get full and the forwarding stops.
|
||||
|
||||
=== See also
|
||||
|
|
|
|||
|
|
@ -117,7 +117,7 @@ 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_
|
||||
in _/etc/dnf/automatic.conf_
|
||||
|
||||
You can still use _download_updates_ and _apply_updates_ settings from
|
||||
inside _/etc/dnf/automatic.conf_.
|
||||
|
|
@ -200,11 +200,11 @@ updates are:
|
|||
|
||||
* You are unlikely to apply updates manually for whatever reason(s).
|
||||
* The machine is not critical and occasional unplanned downtime is
|
||||
acceptable.
|
||||
acceptable.
|
||||
* You can live without remote access to the machine until you can get to
|
||||
its physical location to resolve problems.
|
||||
its physical location to resolve problems.
|
||||
* You do not have any irreplaceable data on the machine, or have proper
|
||||
backups of such data.
|
||||
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
|
||||
|
|
@ -223,46 +223,46 @@ 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.
|
||||
unscheduled downtime.
|
||||
* You installed custom software, compiled software from source, or use
|
||||
third party software that has strict package version requirements.
|
||||
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*.)
|
||||
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.
|
||||
(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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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
|
||||
|
|
|
|||
|
|
@ -51,9 +51,9 @@ 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
|
||||
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
|
||||
that dracut shell commands are printed as they are executed
|
||||
4. Inspect the system logs:
|
||||
+
|
||||
....
|
||||
|
|
@ -75,16 +75,16 @@ 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
|
||||
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
|
||||
the command
|
||||
* A list of block device attributes including vol_id compatible mode.
|
||||
This can be obtained by running the commands and
|
||||
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}}.
|
||||
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]]
|
||||
|
|
@ -136,7 +136,7 @@ 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:
|
||||
following:
|
||||
+
|
||||
....
|
||||
serial --unit=0 --speed=9600
|
||||
|
|
@ -172,7 +172,7 @@ 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.
|
||||
file (e.g.
|
||||
2. Remove the boot arguments `rhgb` and `quiet`
|
||||
|
||||
A sample bootloader configuration file is listed below.
|
||||
|
|
@ -216,7 +216,7 @@ include:
|
|||
* 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}})
|
||||
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
|
||||
|
|
@ -238,7 +238,7 @@ Number Start End Size Type File system Flags
|
|||
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
|
||||
activate any logical volumes
|
||||
+
|
||||
....
|
||||
# lvm vgscan
|
||||
|
|
@ -255,10 +255,10 @@ activate any logical volumes
|
|||
/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.
|
||||
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)
|
||||
|
|
@ -272,7 +272,7 @@ Key slot 0 unlocked.
|
|||
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
|
||||
by exiting the dracut shell
|
||||
+
|
||||
....
|
||||
exit
|
||||
|
|
|
|||
|
|
@ -83,7 +83,7 @@ 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`
|
||||
`/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 )
|
||||
|
|
|
|||
|
|
@ -86,16 +86,16 @@ 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:
|
||||
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`):
|
||||
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
|
||||
|
|
@ -143,7 +143,7 @@ $ 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:
|
||||
variable:
|
||||
+
|
||||
....
|
||||
$ DISPLAY='' command
|
||||
|
|
@ -159,8 +159,8 @@ $ 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:
|
||||
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
|
||||
|
|
@ -190,21 +190,21 @@ 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.
|
||||
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.
|
||||
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
|
||||
- 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.
|
||||
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.
|
||||
you run KDE, it is using this compositor.
|
||||
|
||||
[id='testing-under-different-compositors']
|
||||
== Testing under different compositors
|
||||
|
|
@ -241,7 +241,7 @@ 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:
|
||||
Wayland session), switch to a free VT (Ctrl+Alt+Fx) and run:
|
||||
+
|
||||
....
|
||||
$ weston-launch
|
||||
|
|
@ -285,17 +285,17 @@ 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]
|
||||
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]
|
||||
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])
|
||||
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]
|
||||
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]
|
||||
Wayland in Freedesktop Bugzilla]
|
||||
* Google search
|
||||
|
||||
[id='filing-a-bug']
|
||||
|
|
@ -306,11 +306,11 @@ 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
|
||||
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)
|
||||
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
|
||||
|
|
@ -320,18 +320,18 @@ 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])
|
||||
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]
|
||||
GNOME Bugzilla]
|
||||
|
||||
[id='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:
|
||||
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
|
||||
|
|
@ -341,10 +341,10 @@ 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.
|
||||
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:
|
||||
problematic app like this:
|
||||
+
|
||||
....
|
||||
$ WAYLAND_DEBUG=1 command |& tee debug.out
|
||||
|
|
@ -353,8 +353,8 @@ $ 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:
|
||||
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
|
||||
|
|
@ -380,14 +380,14 @@ All of this applies to just GTK+ 3 and QT 5 apps.
|
|||
$ lspci -nn > lspci.out
|
||||
....
|
||||
5. Package versions. You can collect the list and versions of all your
|
||||
packages installed using:
|
||||
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.
|
||||
link:Bugs_and_feature_requests#Things_Every_Bug_Should_Have[usual
|
||||
information] that every bug report should have.
|
||||
|
||||
[id='debugging-gnome-shell']
|
||||
Debugging gnome-shell
|
||||
|
|
|
|||
|
|
@ -63,13 +63,13 @@ sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-31-primary
|
|||
----
|
||||
|
||||
. If some of your packages have unsatisfied dependencies, the upgrade will refuse to continue until you run it again with an extra `--allowerasing` option.
|
||||
This often happens with packages installed from third-party repositories for which an updated repositories hasn't been yet published.
|
||||
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.
|
||||
This often happens with packages installed from third-party repositories for which an updated repositories hasn't been yet published.
|
||||
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 `--best` option to the command line.
|
||||
* If you want to remove/install some packages manually before running `dnf system-upgrade download` again, it is 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 will need to download all the packages once again.
|
||||
Otherwise the whole package cache will be removed after your operation, and you will need to download all the packages once again.
|
||||
|
||||
. Trigger the upgrade process. This will restart your machine into the upgrade process:
|
||||
+
|
||||
|
|
|
|||
|
|
@ -70,12 +70,12 @@ GNOME documentation]
|
|||
|
||||
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.)
|
||||
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
|
||||
nothing
|
||||
|
||||
Alternatively, the systemwide method described under
|
||||
link:#Other_window_managers[Other window managers] can also be used.
|
||||
|
|
|
|||
|
|
@ -16,10 +16,10 @@ There are a few terms that are commonly used in this document:
|
|||
* *Bug*: A bug is any behaviour in a software that appears unexpected/undesired.
|
||||
* *Bug tracker*: The Fedora bug tracking system at https://bugzilla.redhat.com.
|
||||
* *Package*: Each software that is available in Fedora has a formal package name that is used by the bug tracker and other infrastructure tools.
|
||||
Packages can be searched using the https://apps.fedoraproject.org/packages/[Fedora Packages web application].
|
||||
Packages can be searched using the https://apps.fedoraproject.org/packages/[Fedora Packages web application].
|
||||
* *Maintainer*: A body of volunteers that takes care of the software packages provided in Fedora.
|
||||
These are referred to as "package maintainers".
|
||||
They keep track of bugs, help with issues, and generally act as middlemen between the developers of the software and Fedora users.
|
||||
These are referred to as "package maintainers".
|
||||
They keep track of bugs, help with issues, and generally act as middlemen between the developers of the software and Fedora users.
|
||||
* *QA*: Quality assurance is the process of ensuring that the software works as intended.
|
||||
* *Bodhi*: The http://bodhi.fedoraproject.org[Fedora QA Web Application].
|
||||
|
||||
|
|
@ -100,9 +100,9 @@ The following fields need to be set:
|
|||
* *Version*: You should set this to the version of Fedora that you observed the bug on.
|
||||
* *Summary*: You should provide a useful short summary of the issue here.
|
||||
* *Description*: More detailed information about the issue should be provided here.
|
||||
It already contains a template, which is explained below.
|
||||
It already contains a template, which is explained below.
|
||||
* *Attachment*: Files that provide more information of the issue can be uploaded with the bug report using the button here.
|
||||
E.g,, screen-shots, log files, screen recordings.
|
||||
E.g,, screen-shots, log files, screen recordings.
|
||||
* *Severity, Hardware, OS*: These fields are optional and need not be set.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -115,7 +115,7 @@ The kernel, like any other Fedora package, has a branch per Fedora release.
|
|||
to check out that branch with:
|
||||
|
||||
1. Check out the branch for which you would like to build a kernel (`master`
|
||||
corresponds to Rawhide):
|
||||
corresponds to Rawhide):
|
||||
|
||||
[source,bash]
|
||||
----
|
||||
|
|
@ -123,8 +123,8 @@ corresponds to Rawhide):
|
|||
----
|
||||
|
||||
2. To avoid conflicts with existing kernels, you can set a custom buildid by
|
||||
changing `# define buildid .local` to `%define buildid .<your_custom_id_here>`
|
||||
in `kernel.spec`.
|
||||
changing `# define buildid .local` to `%define buildid .<your_custom_id_here>`
|
||||
in `kernel.spec`.
|
||||
|
||||
3. Make whatever changes or customizations you need.
|
||||
|
||||
|
|
|
|||
|
|
@ -56,7 +56,7 @@ Before testing, you need to install some packages:
|
|||
cd /home/liveuser/kernel-tests
|
||||
|
||||
* If you are not using the test day image you will need to clone the kernel-tests repo.
|
||||
Use this command in terminal:
|
||||
Use this command in terminal:
|
||||
|
||||
git clone https://pagure.io/kernel-tests.git
|
||||
|
||||
|
|
|
|||
|
|
@ -36,12 +36,12 @@ boot process, there may or may not be any output. Some good first steps are:
|
|||
going on.
|
||||
|
||||
* The SysRq magic keys may still work. You may need to add
|
||||
`sysrq_always_enabled=1` to the kernel boot command line. See
|
||||
https://fedoraproject.org/wiki/QA/Sysrq[the wiki article on SysRq on usage
|
||||
details].
|
||||
`sysrq_always_enabled=1` to the kernel boot command line. See
|
||||
https://fedoraproject.org/wiki/QA/Sysrq[the wiki article on SysRq on usage
|
||||
details].
|
||||
|
||||
* Setting `nmi_watchdog=1` on the kernel command line will cause a panic when
|
||||
an NMI watchdog timeout occurs.
|
||||
an NMI watchdog timeout occurs.
|
||||
|
||||
== Logs to collect ==
|
||||
|
||||
|
|
@ -80,38 +80,38 @@ considerably in most cases.
|
|||
====
|
||||
|
||||
. Find the newest version you can that works. This will be the initial "good"
|
||||
version. The first version you find that doesn't work will be the initial "bad"
|
||||
version.
|
||||
version. The first version you find that doesn't work will be the initial "bad"
|
||||
version.
|
||||
|
||||
. Install the <<build-custom-kernel.adoc#get-the-dependencies,dependencies>>
|
||||
required to build the kernel.
|
||||
required to build the kernel.
|
||||
|
||||
. Next, <<build-custom-kernel.adoc#getting-the-sources,get the source code>>.
|
||||
|
||||
. Prepare a `.config` file. Assuming you've got both the good and bad kernel
|
||||
installed, the config for both will be in `/boot/`.footnote:[When bisecting
|
||||
between major versions (e.g. `v4.16` and `v4.15`) new configuration options
|
||||
will be added and removed as you bisect. It's _usually_ safe to select the
|
||||
default.]
|
||||
installed, the config for both will be in `/boot/`.footnote:[When bisecting
|
||||
between major versions (e.g. `v4.16` and `v4.15`) new configuration options
|
||||
will be added and removed as you bisect. It's _usually_ safe to select the
|
||||
default.]
|
||||
|
||||
. Start a new `git-bisect` with `git bisect start`.
|
||||
|
||||
. Mark the newest version that works as "good" with `git bisect good <tag>`.
|
||||
For example: `git bisect good v4.16.8`.
|
||||
For example: `git bisect good v4.16.8`.
|
||||
|
||||
. Mark the first version that does not work as "bad" with `git bisect bad
|
||||
<tag>`. For example: `git bisect bad v4.17`.
|
||||
<tag>`. For example: `git bisect bad v4.17`.
|
||||
|
||||
. <<build-custom-kernel.adoc#building-the-kernel,Build the kernel>>. Sometimes
|
||||
commits cannot be built. If this happens, skip the commit with `git bisect
|
||||
skip`.
|
||||
commits cannot be built. If this happens, skip the commit with `git bisect
|
||||
skip`.
|
||||
|
||||
. <<build-custom-kernel.adoc#installing-the-kernel,Install the kernel>>.
|
||||
|
||||
. Reboot into the new kernel and test to see if it works.
|
||||
|
||||
. If the new kernel works, mark it as good with `git bisect good`. Otherwise,
|
||||
mark it as bad with `git bisect bad`.
|
||||
mark it as bad with `git bisect bad`.
|
||||
|
||||
. Repeat the previous five steps until you've found the commit that introduced
|
||||
the problem.
|
||||
the problem.
|
||||
|
|
|
|||
|
|
@ -91,7 +91,7 @@ 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
|
||||
https://github.com/cisco/openh264/releases
|
||||
|
||||
Example installation for version 1.1:
|
||||
|
||||
|
|
@ -108,8 +108,8 @@ 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:
|
||||
appear. Give the following Preference Names a value of true by
|
||||
double-clicking on false:
|
||||
|
||||
` media.gmp-gmpopenh264.autoupdate` +
|
||||
` media.gmp-gmpopenh264.enabled` +
|
||||
|
|
@ -118,7 +118,7 @@ double-clicking on false:
|
|||
|
||||
* Restart Firefox
|
||||
* After restarting, the following string in about:config will change to
|
||||
the current version that has been installed from the web:
|
||||
the current version that has been installed from the web:
|
||||
|
||||
` media.gmp-gmpopenh264.version`
|
||||
'''
|
||||
|
|
|
|||
|
|
@ -55,36 +55,34 @@ 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 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 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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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
|
||||
|
|
@ -97,22 +95,22 @@ 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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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:
|
||||
|
|
@ -126,9 +124,9 @@ 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 )
|
||||
PackageKit gui )
|
||||
2. Try one of the available link:Third_party_repositories[ 3rd party]
|
||||
repositories
|
||||
repositories
|
||||
3. link:How_to_create_an_RPM_package[ Build your own package]
|
||||
|
||||
[[package-management-tools]]
|
||||
|
|
|
|||
|
|
@ -41,12 +41,12 @@ 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].
|
||||
link:Package_Not_Found#Patents[ encumbered by software patents].
|
||||
* Fedora does not include proprietary software, only software with an
|
||||
link:Licensing[ acceptable license].
|
||||
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]!
|
||||
adding it to the link:PackageMaintainers/WishList[Package WishList], or
|
||||
even link:PackageMaintainers/Join[packaging it yourself]!
|
||||
|
||||
[[missing-codec]]
|
||||
== Missing Codec
|
||||
|
|
@ -59,9 +59,9 @@ 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].
|
||||
encumbered].
|
||||
* Some codecs may not be encumbered, but may be under an
|
||||
link:Licensing[unacceptable license].
|
||||
link:Licensing[unacceptable license].
|
||||
|
||||
The Fedora Project FAQ and community sites provide answers to commonly
|
||||
asked questions. link:Third_party_repositories[Third party repositories]
|
||||
|
|
@ -84,9 +84,9 @@ 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].
|
||||
encumbered].
|
||||
* Some hardware may not be supported under Linux yet, or is not yet in
|
||||
the upstream Linux kernel.
|
||||
the upstream Linux kernel.
|
||||
|
||||
Fedora strongly encourages new drivers to be included in upstream, and
|
||||
does not package individual, out-of-tree, kernel drivers.
|
||||
|
|
@ -108,10 +108,10 @@ 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].
|
||||
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]!
|
||||
consider adding it to the :Category:Font_wishlist[Font WishList], or
|
||||
even link:PackageMaintainers/Join[packaging it yourself]!
|
||||
|
||||
[[missing-mime-support]]
|
||||
== Missing MIME Support
|
||||
|
|
@ -121,14 +121,14 @@ 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.
|
||||
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.
|
||||
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]!
|
||||
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
|
||||
|
|
|
|||
|
|
@ -282,11 +282,11 @@ 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
|
||||
and consult it with specified map
|
||||
* *trust* — anyone who is able to connect to PostgreSQL server may act
|
||||
as any user without supplying password
|
||||
as any user without supplying password
|
||||
* *peer* — obtains user's name from operating system and checks if it
|
||||
matches database user name
|
||||
matches database user name
|
||||
|
||||
When database server is authenticating client, it seeks for a record
|
||||
with matching connection type, client address, requested database and
|
||||
|
|
|
|||
|
|
@ -13,8 +13,8 @@ QEMU is a generic and open source processor emulator which achieves a good emula
|
|||
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.
|
||||
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]]
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ To boot the system into rescue mode using `bash` follow these steps:
|
|||
. Use the arrow keys to go to the line that starts with `linux`, `linux16`, or `linuxefi`
|
||||
|
||||
. Go the the end of that line, add a space then type `rw init=/bin/bash`.
|
||||
If your disk is encrypted, you may need to add `plymouth.enable=0`
|
||||
If your disk is encrypted, you may need to add `plymouth.enable=0`
|
||||
|
||||
. Press *Ctrl-x* or *F10* to boot that entry
|
||||
|
||||
|
|
@ -99,7 +99,7 @@ To download and create a live USB of Fedora Workstation, follow the instructions
|
|||
. From the desktop, open a terminal and switch to root using `su` (it won't ask for a password)
|
||||
|
||||
. To view your hard drive device nodes, in the terminal type: `df -H`.
|
||||
For this example we will use `/dev/sda1` for the `/boot` partition and `/dev/sda2` for the root `/` partition.
|
||||
For this example we will use `/dev/sda1` for the `/boot` partition and `/dev/sda2` for the root `/` partition.
|
||||
+
|
||||
If you are using LVM partitions, type: `sudo lvscan` and note the `/dev` path of your root partition.
|
||||
For this example we will use `/dev/fedora/root`.
|
||||
|
|
|
|||
|
|
@ -91,11 +91,11 @@ Create a new VM in virt-manager. When you get to the final page of the
|
|||
|
||||
* Click 'Customize before install', then select 'Finish'
|
||||
* On the 'Overview' screen, Change the 'Firmware' field to select the
|
||||
'UEFI x86_64' option.
|
||||
'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.
|
||||
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
|
||||
|
|
@ -136,7 +136,7 @@ CD-ROM image and it should boot into the UEFI shell. At the prompt
|
|||
* 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.
|
||||
is now enabled for every subsequent boot.
|
||||
|
||||
[[testing-fedora-cddvd-secure-boot-in-a-vm]]
|
||||
Testing Fedora CD/DVD Secure Boot in a VM
|
||||
|
|
@ -149,7 +149,7 @@ to use this to test ISO media secureboot support.
|
|||
* 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
|
||||
checking dmesg
|
||||
|
||||
[[notes]]
|
||||
Notes
|
||||
|
|
@ -171,11 +171,11 @@ 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]
|
||||
page]
|
||||
* http://en.opensuse.org/openSUSE:UEFI_Secure_boot_using_qemu-kvm[OpenSUSE
|
||||
secureboot page]
|
||||
secureboot page]
|
||||
* http://www.labbott.name/blog/2016/09/15/secure-ish-boot-with-qemu/[Using
|
||||
SecureBoot with QEMU]
|
||||
SecureBoot with QEMU]
|
||||
|
||||
Category:Virtualization Category:QA
|
||||
'''
|
||||
|
|
|
|||
|
|
@ -247,7 +247,7 @@ grub by running
|
|||
....
|
||||
|
||||
- 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!
|
||||
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 ).
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
|
||||
. Be sure to *back-up your data* before upgrading your Fedora system in the event something breaks and leaves your system unusable.
|
||||
. Read the link:++https://fedoraproject.org/wiki/Releases#Current_Supported_Releases++[Release
|
||||
Notes] carefully before attempting an upgrade.
|
||||
Notes] carefully before attempting an upgrade.
|
||||
|
||||
====
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue