* 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

  * 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.

  There are several graphical user interfaces available to configure iptables.

  * link:http://www.fwbuilder.org/_fwbuilder[fwbuilder]: Very complete GUI tools

  * link:http://shorewall.net/_Shorewall[Shorewall]: Another very complete GUI

  * link:http://www.turtlefirewall.com/_Turtle_firewall_project[Turtle firewall

  * link:http://users.telenet.be/stes/ipmenu.html_IPmenu[IPmenu] :A console based

  The following section describes yet another frontend: `system-config-firewall`.

  == Additional resources

  * For more examples, see the

  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]

  * For _Fedora 20 and earlier_: https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-livecd-desktop.ks[fedora-livecd-desktop.ks]

  * 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.

  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.

  +

  ----

  Please select what kind of key you want:

  Again, the default is sufficient for almost all users, and represents an _extremely_ strong level of security.

  . Choose when the key will expire.

  +

  ----

  Please specify how long the key should be valid.

  . Enter `y` to finish the process.

  . Enter your name and email address.

  . Enter your real email address for your GPG key.

  . Use the comment field to include aliases or other information.

  . 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.

  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.

  . Select the _Search_ tab and enter the name `seahorse`.

  . Select the checkbox next to the `seahorse` package and select _Apply_ to add the software.

  To create a key:

  = Creating GPG Keys Using the KDE Desktop

  . Start the KGpg program from the main menu by selecting menu:Utilities[PIM > KGpg].

  . Enter your name, email address, and an optional comment in the dialog box that appears prompting you to create a new key pair.

  . Enter your passphrase in the next dialog box.

  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`.

  == To enable repo:

  . Login as root:

  . 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:

  . Check if your system has FirewallD enabled.

  [source,bash]

  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

  * 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

  * 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 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}>>.

  * `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

  * `*.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].

  * `H:M:S` is the message timestamp

  * `ms` is the millisecond part of timestamp.

  * `LOGLEVEL` is the message loglevel.

  ** `DEBUG`

  ** `INFO`

  ** `WARN`

  ** `ERR`

  ** `CRIT`

  * `facility` is the program or component that created the message.

  * `message` is the log message itself.

  For the logs running in terminals, the format simply is:

  . 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.

  . In the guest editor, add following information into the `<devices>` section:

  [source,xml]

  ----

  ----

  . Start the virtual machine.

  . Continue with the installation.

  ==== virt-install

  * 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.

  * 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

  * dnf-automatic-download.timer - Only download

  * dnf-automatic-install.timer - Download and install

  * dnf-automatic-notifyonly.timer - Only notify via configured emitters

  You can still use _download_updates_ and _apply_updates_ settings from

  inside _/etc/dnf/automatic.conf_.

  * You are unlikely to apply updates manually for whatever reason(s).

  * The machine is not critical and occasional unplanned downtime is

  * You can live without remote access to the machine until you can get to

  * You do not have any irreplaceable data on the machine, or have proper

  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

  automatic updates are:

  * It provides a critical service that you don't want to risk having

  * You installed custom software, compiled software from source, or use

  * You installed a custom kernel, custom kernel modules, third party

  * Your enviroment requires meticulous change-control procedures.

  * You update from other third party yum|dnf repositories besides Fedora

  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

  * Unwanted side effects. Some packages can create annoying side effects,

  * Bugs. Many packages contain buggy software or installation scripts.

  * Automatic updates may not complete the entire process needed to make

  [[best-practices-when-using-automatic-updates]]

  Best practices when using automatic updates

  1.  Remove `rhgb` and `quiet` from the kernel command line

  2.  Add `rd.shell` to the kernel command line. This will present a shell

  3.  Add `rd.shell rd.debug log_buf_len=1M` to the kernel command line so

  4.  Inspect the system logs:

  +

  ....

  report:

  * The exact kernel command-line used. Typically from the bootloader

  * A copy of your disk partition information from

  * A device listing from device-mapper. This can be obtained by running

  * A list of block device attributes including vol_id compatible mode.

  * Turn on dracut debugging (see

  * If you use a dracut configuration file, please include

  [[logical-volume-management-related-problems]]

  below.

  1.  Open the file for editing. Below the line _timeout=5_, add the

  +

  ....

  serial --unit=0 --speed=9600

  fails to locate your root filesystem. To enable the shell:

  1.  Add the boot parameter `rd.shell` to your bootloader configuration

  2.  Remove the boot arguments `rhgb` and `quiet`

  A sample bootloader configuration file is listed below.

  * A LVM logical volume (e.g. )

  * An encrypted device (e.g. )

  * A network attached device (e.g.

  The exact method for locating and preparing will vary. However, to

  continue with a successful boot, the objective is to locate your root

   2      10.8GB  55.6GB  44.7GB  logical                lvm

  ....

  2.  You recall that your root volume was a LVM logical volume. Scan and

  +

  ....

  # lvm vgscan

  /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

  +

  ....

  UUID=$(cryptsetup luksUUID /dev/mapper/linux-root)

  ln -s /dev/mapper/luks-$UUID /dev/root

  ....

  6.  With the root volume available, you may continue booting the system

  +

  ....

  exit

  multi-user.target )

  * Run

  To examine what gets started when when booted into a specific target. (

  In the above example the multi-user.target )

  figure it out:

  * Wayland session should have `WAYLAND_DISPLAY` variable set, X11

  +

  ....

  $ echo $WAYLAND_DISPLAY

  wayland-0

  ....

  * `loginctl` can give you this information. First run `loginctl` and

  +

  ....

  $ loginctl show-session <YOUR_NUMBER> -p Type

  However, this list of not always entirely reliable, some apps might be

  missing.

  * You can try to run the app while unsetting `DISPLAY` environment

  +

  ....

  $ DISPLAY='' 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

  +

  ....

  lg

  The most notable Wayland-ready toolkits are:

  * https://en.wikipedia.org/wiki/GTK%2B[GTK+ 3] - default apps in GNOME

  * https://en.wikipedia.org/wiki/Qt_%28software%29[QT 5] - many apps in

  The most notable Wayland compositors are:

  * https://en.wikipedia.org/wiki/Wayland_%28display_server_protocol%29#Weston[Weston]

  * https://en.wikipedia.org/wiki/Mutter_%28software%29[Mutter] -

  * https://community.kde.org/KWin/Wayland[Kwin] - compositor in KDE. If

  [id='testing-under-different-compositors']

  == Testing under different compositors

  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

  +

  ....

  $ weston-launch

  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

  * https://bugzilla.gnome.org/showdependencytree.cgi?id=757579&hide_resolved=1[Wayland-related

  * https://bugzilla.redhat.com/showdependencytree.cgi?id=WaylandRelated&hide_resolved=1[Wayland-related

  * [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=---

  * [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=---

  * Google search

  [id='filing-a-bug']

  places where to report it:

  * https://bugzilla.redhat.com/[Red Hat Bugzilla] - recommended for

  * https://bugzilla.gnome.org/[GNOME Bugzilla] - recommended for issues

  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

  of these trackers, depending where you reported the bug:

  * https://bugzilla.redhat.com/show_bug.cgi?id=1277927[Wayland Tracker in

  * https://bugzilla.gnome.org/show_bug.cgi?id=757579[Wayland Tracker in

  [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,

  +

  ....

  $ journalctl -ab > journal.log

  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

  2.  Wayland debug output. If you can reproduce the issue, please run the

  +

  ....

  $ 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

  +

  ....

  $ GDK_BACKEND=x11 command

  $ lspci -nn > lspci.out

  ....

  5.  Package versions. You can collect the list and versions of all your

  +

  ....

  $ rpm -qa | sort > packages.out

  ....

  6.  The

  [id='debugging-gnome-shell']

  Debugging gnome-shell

  ----

  . If some of your packages have unsatisfied dependencies, the upgrade will refuse to continue until you run it again with an extra `--allowerasing` option.

  +

  * 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.

  . Trigger the upgrade process. This will restart your machine into the upgrade process:

  +

  1.  enter KDE System Settings

  2.  choose Hardware / Input Devices / Touchpad (If it's not there,

  3.  select the Tapping tab

  4.  check the "Enable tapping" checkbox

  5.  set some tapping actions under "Buttons" below, the default is to do

  Alternatively, the systemwide method described under

  link:#Other_window_managers[Other window managers] can also be used.

  * *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.

  * *Maintainer*: A body of volunteers that takes care of the software packages provided in Fedora.

  * *QA*: Quality assurance is the process of ensuring that the software works as intended.

  * *Bodhi*: The http://bodhi.fedoraproject.org[Fedora QA Web Application].

  * *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.

  * *Attachment*: Files that provide more information of the issue can be uploaded with the bug report using the button here.

  * *Severity, Hardware, OS*: These fields are optional and need not be set.

  to check out that branch with:

  1. Check out the branch for which you would like to build a kernel (`master`

      [source,bash]

      ----

      ----

  2. To avoid conflicts with existing kernels, you can set a custom buildid by

  3. Make whatever changes or customizations you need.

   cd /home/liveuser/kernel-tests

  * If you are not using the test day image you will need to clone the kernel-tests repo.

   git clone https://pagure.io/kernel-tests.git

   going on.

  * The SysRq magic keys may still work. You may need to add

  * Setting `nmi_watchdog=1` on the kernel command line will cause a panic when

  == Logs to collect ==

  ====

  . Find the newest version you can that works. This will be the initial "good"

  . Install the <<build-custom-kernel.adoc#get-the-dependencies,dependencies>>

  . 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

  . Start a new `git-bisect` with `git bisect start`.

  . Mark the newest version that works as "good" with `git bisect good <tag>`.

  . Mark the first version that does not work as "bad" with `git bisect bad

  . <<build-custom-kernel.adoc#building-the-kernel,Build the kernel>>. Sometimes

  . <<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,

  . Repeat the previous five steps until you've found the commit that introduced

  * View and agree to the http://www.openh264.org/BINARY_LICENSE.txt

  * Download the appropriate binary for your system here:

  Example installation for version 1.1:

  warning.

  * From the Search field type in 264 and a handful of options will

  ` media.gmp-gmpopenh264.autoupdate` +

  ` media.gmp-gmpopenh264.enabled` +

  * Restart Firefox

  * After restarting, the following string in about:config will change to

  ` media.gmp-gmpopenh264.version`

  '''

  Package management systems have many advantages: