text:
This page documents common bugs in Fedora 20 and, if available, fixes or workarounds for these problems. If you find your problem in this page, please do not file a bug for it, unless otherwise instructed. Where appropriate, a reference to the current bug(s) in Bugzilla is included.
Release Notes
Read the Fedora 20 release announcement and the Fedora 20 release notes for specific information about changes in Fedora 20 and other general information.
My bug is not listed
Not every bug is listed in this page, but Bugzilla should be a comprehensive database of known bugs. This page is a sampling of the bugs most commonly discussed on our mailing lists and forums.
To see if your bug has already been reported, you can search Bugzilla. If it has not yet been reported, we encourage you to do so to help improve Fedora for yourself and others. A guide to Bugs and feature requests has been prepared to assist you.
If you believe an already-reported bug report should be added to this page because it is commonly encountered, you can:
- Add it yourself, if you have wiki access. Please follow the style and guidelines explained in the comments in the page source.
- Or, add the CommonBugs keyword to the bug report. Someone from the QA team will then inspect the issue to determine whether the bug should be listed as a common bug. To expedite your request, please add a comment to the bug that includes
- a summary of the problem
- any known workarounds
- an assessment on the impact to Fedora users
For reference, you can query Bugzilla for bugs tagged CommonBugs:
- CommonBugs? (bugs with CommonBugs keyword, but do not yet have a link to one or more Common Bugs pages)
- CommonBugs+(bugs with CommonBugs keyword and contain a link to one or more Common Bugs pages)
Major issues
RPM scriptlets fail during updates
link to this item - Bugzilla: #1054350
A bug in SELinux policy introduced via an update causes RPM scriptlets to fail to execute in Fedora 20 if SELinux is enabled and is in enforcing mode which is the default in Fedora 20.
Sample output:
warning: %post(libkcompactdisc-4.12.1-1.fc20.x86_64) scriptlet failed, exit status 127 Non-fatal POSTIN scriptlet failure in rpm package libkcompactdisc-4.12.1-1.fc20.x86_64
To resolve such problems, run the following commands as root user or using sudo. The first command disables SELinux enforcement for the current session and the subsequent commands expire the yum caching and gets the SELinux policy update which fixes this issue and the last command enables SELinux enforcement back.
# setenforce 0 # yum clean expire-cache # yum update selinux-policy\* # setenforce 1
If you install any packages which failed with scriptlet errors before doing the above procedure, reinstall them using yum reinstall <package name>. If you are unsure of the package names, you can use yum history list to find out the number of the transaction and use yum history undo <transaction number> and then use yum history redo <transaction number> to reinstall the packages.
Fedora SELinux maintainers have a policy of only loosening the policy and typically never tightening it on updates precisely to avoid such kind of problems, however a policy inclusion meant for Rawhide, the development version of Fedora was accidentally included in this release. Fedora SELinux maintainers will be setting up a much higher karma requirement for new updates to avoid similar problems in the future.
System fails to boot after install using LVM Thin Provisioning
link to this item - Bugzilla: #1040669
Fedora 20 introduces install-time support for LVM Thin Provisioning as a feature. Unfortunately, a late change to fix another serious bug inadvertently introduced a serious bug in this support. If you install Fedora 20 using the release packages (a live install, DVD install, or network install using a repository that contains the frozen release-time package set rather than including updates) and place any system partition (/home and other data partitions are not affected) on a thin-provisioned LV, the installed system will fail to boot. After a delay of 2-3 minutes, it will drop you an emergency mode. The cause of the bug is that tools needed for accessing thin provisioned LVs are erroneously left out of both system-specific and generic initramfs builds due to the broken change in Dracut, the tool that generates the initramfs.
There is no simple workaround for this issue if you are affected by it. Obviously, you can avoid it by not installing to thin-provisioned LVM. Network installs which include the update repository should not be affected by the issue, as the fixed dracut package is now in the stable updates repository.
If you do find yourself affected by the issue and wish to rescue the installation rather than re-install, you can use the installer's rescue mode.
Boot to rescue mode and choose Continue to mount your installed system and go to a shell. Now run the following:
chroot /mnt/sysimage /bin/bash yum update dracut dracut -f exit reboot
This should update dracut
to the fixed version and re-generate the initramfs to include the necessary tools. Now your system should boot normally (though an SELinux relabel may run on the first boot).
Crash when switching from a complete mirror repository to a DVD-based repository: NoSuchGroup: 3d-printing
link to this item - Bugzilla: #1033749
This issue does not affect the simple cases of booting from the DVD and using it as the package source, or booting from the network install image and using a normal public Fedora mirror as the package source. Each of those cases works fine. You do not need to worry about this issue if this is how you plan to install Fedora 20.
However, if you set the Installation Source for a Fedora 20 installation to be a source with a complete set of packages - such as the default remote repository configuration, or any full Fedora 20 mirror - then switch to a source which contains only the restricted set of packages on the DVD image - such as a repository which simply is the DVD image, accessed via any protocol, or any other repository somehow generated solely from the DVD package set - the installer will likely crash with a NoSuchGroup: 3d-printing error.
In practice what this means is if you boot the network install image normally - so that the default remote repository is automatically configured - and then attempt to switch to, say, an NFS or HTTP repository which just contains the DVD ISO image (or has the contents of the DVD ISO image mounted or copied to it), the installer will likely crash.
There are several possible workarounds for this. You can simply set things up so your install repository contains the full package set, not the subset from the DVD image. You can pass in your desired repository configuration with the inst.repo boot parameter or using a kickstart with the repo command - this will cause your chosen repository to be configured straight away, and so avoid the bug. Or you can boot with the askmethod parameter, which has the effect of telling the installer not to try and configure the default remote repository automatically, but to wait for you to enter the Installation Source hub and choose a repository configuration yourself, which again should avoid the bug. You could even boot from the DVD image itself, though that does not seem likely to be a very useful workaround for the majority of cases where you would actually want to install from a separate repository containing only the DVD image file or contents.
389 Directory Server crashes during search operation
link to this item - 389-ds #47629
A tester has reported repeated crashes in Fedora 20's 389 Directory Server during search operations. This crash is currently being investigated and will be fixed as soon as possible.
Due to this and other 389 and FreeIPA issues discussed later in this page, we strongly recommend not deploying any kind of production 389 Directory Server or FreeIPA server using the Fedora 20 release at this point. Updates will be issued to resolve this and the other bugs listed on this page, and it should be safe to deploy a Fedora 20-based 389 / FreeIPA server with those updates installed. This entry will be updated when updates are available, or you can follow the relevant tickets.
/root permissions incorrect on pre-release installations
link to this item - Bugzilla: #1037688
This issue does not affect systems installed with or upgraded after the release of the final release version of Fedora 20, but we are documenting it as it may be of significant interest to those who used Fedora 20 prior to release.
If you used any Fedora 20 pre-release (or test compose or release candidate build), the permissions on the /root directory are likely to be incorrect: an older version of the rootfiles
package set the permissions to 0755 (users other than root can read files in the /root directory). We felt it not a good idea to try and fix this with an update, as sysadmins who manually change their /root permissions would not want us to override those changes, but we would like to make those who installed from pre-releases aware of the issue. The usual default Fedora permissions (and those set by the final release version of Fedora 20) are 0550. You can run su -c 'chmod 0550 /root'
to set those permissions, which will prevent users other than root from reading files in /root.
Installation issues
Installer crashes with No such file or directory: '/dev/md' if MD-RAID set is referred to by device node name in /etc/fstab
link to this item - Bugzilla: #980267
If you attempt to install Fedora 20 on a system containing an existing Linux system whose /etc/fstab
contains one or more entries referring to a partition on an MD-RAID set by its device node name (e.g. /dev/md0p1
or /dev/md127p2
), the installer will likely crash, with the error No such file or directory: '/dev/md'.
Identifying any storage device by its device node name is fragile and it is usually a better idea to use something more robust such as a filesystem label or UUID, but it is of course a bug that the Fedora installer crashes when it encounters such a situation; it should handle it more gracefully.
To work around this issue, either adjust the /etc/fstab
entry to refer to the device(s) by a more robust identifier, or temporarily comment them out while running the Fedora installation. The latter approach will have the minor drawback that Fedora will not be able to identify the device(s) as being part of any existing installation, and will instead display them in the 'Unknown' group of the Custom Partitioning screen, if you visit it during your installation.
Problem with Installation Source spoke when installing from a partially complete kickstart
link to this item - Bugzilla: #972265
If you attempt to install Fedora 20 using a partially-complete kickstart - in particular, a kickstart which specifies a package set but no installation source - you will find that the interactive process for setting that option behaves strangely. On the Installation Source spoke, you may not be able to use the default Closest mirror option. If you are affected by this problem, you can manually enter the URL of the Fedora 20 mirror list, and check the This URL refers to a mirror list. box. The URLs for the 64-bit and 32-bit mirror lists are https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-20&arch=x86_64
and https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-20&arch=i386
link to this item - Bugzilla: #986731
If you have an existing UEFI-native operating system and do a UEFI-native install of Fedora alongside it, attempting to boot the previously existing OS from Fedora's bootloader may fail consistently. The reason for this failure is that os-prober currently fails to set the correct boot options for the previously existing OS in the GRUB menu.
You may be able to use your system firmware's interface to the UEFI boot manager to boot the previously existing OS directly. This boot menu is often accessible at reboot time by interrupting the boot process and choosing to boot from a different device, but implementations vary between firmwares. The Windows boot option is often named Windows Boot Manager.
Alternatively, you can use the efibootmgr
command from Fedora to direct the system to boot a particular UEFI boot manager entry on the next reboot. efibootmgr
should list all the UEFI boot manager entries. Identify the one for Windows, and run su -c 'efibootmgr -n XXXX'
, where XXXX is the (hexadecimal) number that follows the word Boot in the efibootmgr
output for that entry. For instance, if efibootmgr
[user@host ~]# efibootmgr BootCurrent: 0000 Timeout: 1 seconds BootOrder: 0000,0002 Boot0000* Fedora Boot0002* Windows Boot Manager
then you could run su -c 'efibootmgr -n 0002'
to instruct the system to boot Windows on the next startup.
You may also be able to manually edit the Fedora bootloader (GRUB) configuration to supply the parameters required to boot the previously existing OS from the Fedora boot menu.
Network configuration changes made after clicking Configure in installer (nm-connection-editor) are not applied unless interface is turned off and on again
link to this item - Bugzilla: #1018471
The Fedora installer's network configuration screen has a button labelled 'Configure', which launches the nm-connection-editor utility to allow configuration of the network connection. Due to issues in the interaction between the installer and the separate nm-connection-editor process, configuration set in the nm-connection-editor process will not take effect unless and until you turn the connection off and then on again. We will attempt to remedy this for future Fedora releases, but it now cannot be resolved in Fedora 20, as the installer cannot be updated after release.
In custom partitioning, cannot change size of a pre-existing LV after setting a mount point for it and scheduling it to be reformatted
link to this item - Bugzilla: #1040445
If you use custom partitioning while installing Fedora 20 to a system with a pre-existing LVM LV, assign a mount point to that LV, and set it to be re-formatted, you will no longer be able to request that its size be changed. Any attempts to change the 'Desired Capacity' field and hit 'Update Settings' will result in the size returning to the previous value.
This issue is easy to work around; as long as the volume is not both assigned a mount point and scheduled to be reformatted, you can successfully adjust its size (as long as that adjustment is achievable within the container, of course). So if you run into this problem, simply temporarily undo the mount point assignment and/or 'reformat' check box, make the size change, and then re-apply the mount point and 'reformat'.
In custom partitioning, cannot change size of a pre-existing partition then reset it to initial value
link to this item - Bugzilla: #1040352
If you use custom partitioning while installing Fedora 20 to a system with one or more pre-existing partitions, then change the target size of any partition and subsequently change your mind and decide you did not want to resize it after all, you will not be able to set it back to precisely its original size (and cancel the resize request). Any attempt to do so will cause the value to change to a previous setting, which can look quite strange.
If you do run into this problem, you can work around it by hitting the 'Reset All' button, which will let you start over from scratch with the storage configuration as it actually exists on the disk(s) prior to Fedora 20 installation beginning.
In custom partitioning, cannot change size of a pre-existing LV multiple times then reset it to initial value
link to this item - Bugzilla: #1040413
If you use custom partitioning while installing Fedora 20 to a system with one or more pre-existing LVM LVs, and change the target size of an LV more than once during one custom partitioning 'run', you will no longer be able to set it back to precisely its original size (and cancel the resize request). Any attempt to do so will cause the value to change to a previous setting, which can look quite strange.
If you're a bit indecisive about what size you want your LVs to be and run into this problem, you can work around it by hitting the 'Reset All' button, which will let you start over from scratch with the storage configuration as it actually exists on the disk(s) prior to Fedora 20 installation beginning.
Installation crashes during partitioning if disk was scanned after an encrypted volume has already been unlocked
link to this item - Bugzilla: #1008732
This is a complex issue. Broadly speaking, if you somehow trigger the installer to do a disk scan after having already accessed a previously-existing encrypted storage volume, then the installation may crash during the partitioning stage with the error LUKSError: luks device not configured. The bug report contains several different possible reproduction scenarios; all are fairly involved, but it is something you may be most likely to run into when installing to a system with an existing encrypted storage volume and then running through partitioning multiple times or using the Refresh Disks function in the custom partitioning screen.
As there are various ways to encounter this issue and they are all quite involved it's difficult to suggest a precise workaround, but broadly speaking, the workaround is to reboot and try the install again, without using the Refresh Disks button (which actually rescans the disks on the system, as opposed to Reset all which just resets the custom partitioning screen to the state it was in when you first entered - it is safe to use that button) or running the installer or the partitioning phase multiple times.
link to this item - Bugzilla: #1038855
If you use the Fedora 20 installer's rescue mode, and enter the interactive shell to try and rescue your installed system, then on exiting the shell it would be expected that you would return to the top-level rescue mode menu, or perhaps that the system would reboot. Instead, you wind up stuck on a screen that says Pane is dead. At this point, your partitions are still mounted, and a hard reset could possibly cause data loss. Do not do a hard shut down or reboot. You can hit ctrl-alt-f2 (or ctrl-b 2) to get a second shell and run 'reboot', or just hit ctrl-alt-del to trigger a clean reboot.
Network installation with Authoring and Publishing group selected fails
link to this item - Bugzilla: #959696
Due to an unmarked conflict between two texlive-related packages (ht
and texlive-tex4ht-bin
), Fedora 20 installations with the Authoring and Publishing package group selected (and possibly with the Font design group selected) will fail.
The offending packages (and groups) are not present on the Fedora 20 DVD, so the bug is not present there. The issue affects only network installs. It will be resolved once the conflict between the two packages is fixed with an update, so long as you enable the updates repository in your installation.
Installer performs a UEFI native installation even if noefi parameter is specified
link to this item - Bugzilla: #1047904
Due to a change in the kernel's behaviour when the noefi parameter is passed, if you boot a Fedora 20 image in native UEFI mode but pass the noefi parameter to try and force a BIOS-native installation, Fedora 20's installer still believes the system is booted in native UEFI mode and performs a UEFI-native installation. If you are relying on this workaround for some reason, use the updates image to avoid this bug.
UEFI install to ms-dos ('MBR') labelled disk fails with unclear errors
link to this item - Bugzilla: #978430
As veterans of the Fedora 16 release may remember, there are two commonly-used 'disk label' or 'partition table' formats known as 'gpt' and 'ms-dos' or 'mbr'.
Fedora 20's installer effectively requires that native UEFI installations be performed to a disk with the 'gpt' format (in fact, it requires that the EFI system partition be on such a disk). In fact, this is not a requirement of the official UEFI specification: it leaves open the possibility of an EFI system partition residing on an ms-dos labelled disk, though it is possible that some firmwares may not support such a configuration.
In any case, if you attempt to do a native UEFI install of Fedora 20 such that the EFI system partition will reside on an ms-dos labelled disk, this will fail. You are likely get an error of the form you have not created a bootloader stage1 target device, possibly with the note that the volume backing the EFI system partition must have one of the following disklabel types: gpt. You may also observe unusual behaviour on the Reclaim space screen, if you use it in your installation attempt. Note that you can encounter this error message even when installing to a gpt-labelled disk if you use custom partitioning and fail to correctly configure an EFI system partition: when doing a UEFI install you must include a partition of the 'EFI system partition' type, and mount it at the path /boot/efi.
We have found that there appear to be some systems 'in the wild' with existing native UEFI operating system installations to an ms-dos labelled drive. Unfortunately, this bug means you cannot install Fedora 20 in a dual-boot configuration to the same drive as such an operating system. You would need to install to a second drive in order to dual boot.
If you wish to do a native UEFI installation of Fedora 20, it must be to a gpt-labelled disk, or you must configure your installation such that all existing partitions on the disk on which the EFI system partition will reside will be deleted (doing this will cause the installer to reformat it with a gpt disk label). Note that it is not possible to change the label format of a disk in a non-destructive way with the installer: it requires a complete re-format.
You can, however, convert it using the gdisk
utility from a live image prior to running the installer. Simply invoke gdisk
as root using your hard disk device as the first argument (e.g. su -c 'gdisk /dev/sda'
) and it will offer to convert the partition table for you. After answering "yes", type w
and press Enter to commit the changes to disk, then type q
and press Enter to exit gdisk
. Please note that conversion is a potentially risky operation; make sure you have backups before proceeding! Also, existing operating system installations may fail to boot after converting your partition table, so you may have to reinstall them (or just their bootloader if possible) in order for them to function again.
If you do not actually wish to perform a native UEFI installation, you should boot your installation medium in BIOS compatibility mode if your system firmware allows you to do so. Different firmwares present this capability in different ways, so we cannot provide definitive instructions. If you cannot see how to achieve this in your firmware, you can use an installation medium which is not compatible with UEFI-native booting: for instance, write a USB stick using the livecd-iso-to-disk
tool without passing the --efi
If all else fails, you can boot your installation medium in UEFI native mode, but pass the kernel parameters inst.updates=https://www.happyassassin.net/updates/updates-1047904.img noefi
when booting the installer: this should cause the installer to perform a BIOS-native installation instead of a UEFI-native installation. The updates image is necessary to avoid a bug that causes the installer to still believe it is in UEFI native mode even if the noefi
parameter is passed: see this entry for details.
For Fedora 21, we intend to revise the installer to handle this situation in a better way. We apologize for any inconvenience it causes.
USB stick from which install is running appears as a possible install target
link to this item - Bugzilla: #874381
In some circumstances, when you are installing Fedora 20 from a USB stick, the stick itself will show up as a possible 'target disk' on the Installation Destination screen where you choose which disk(s) to install onto. This is not intended to happen. It is not possible to install to the USB stick from which the installation is running: if you attempt to do this, the installation will fail. Naturally, therefore, we recommend you simply avoid selecting the stick on this screen.
'Selected' state for disks is indicated with a small and easily missed check mark
link to this item - Bugzilla: #967682
On the installer screen where you choose which disks will be used for Fedora 20 installation, disks that are selected as installation targets are marked with a fairly small black check mark in the lower right hand corner; disks that are not selected do not have the check mark.
This has been changed since Fedora 18, when disks that were selected were highlighted in blue, and now the blue highlight simply means the UI element is selected. So if you click on a disk that was previously selected as an install target, then you have just de-selected it - so the check mark goes away - but the UI element is active, so it is highlighted in blue.
Add to this that if you only have a single hard disk it will be pre-selected as an install target when you enter the page, and it has become clear that this design is confusing people. Many users have entered the screen and clicked to 'select' their single disk - in fact de-selecting it, because it was already selected, but not noticing the mistake.
Bootloader password is required on each boot
link to this item - Bugzilla: #840160
If you set a bootloader password during installation of Fedora 19 (which is only possible when doing a kickstart-based install), the password will be required at each boot of the system. This is a change in behaviour from Fedora 15 and earlier, where the password was required only to change settings from within the bootloader.
Lawrence Lowe suggests that the --unrestricted parameter can be added to menuentry lines in the grub config file to make them available without the password being entered.
Non-GNOME initial setup utility does not warn of failure to create a user account
link to this item - Bugzilla: #965797
In Fedora 20, the initial-setup utility (shown after a graphical install with any desktop other than GNOME if you do not create a user account during installation) does not present any kind of warning if you leave it without having created a user account. Thus it is relatively easy to arrive at a graphical login screen without any user accounts available.
The old utility would allow you to skip user account creation, but required you to click through a warning in order to do so, to ensure no-one did it inadvertently. This is also how initial-setup should behave.
We have tested that the desktops for which the new tool is used - KDE, Xfce, LXDE, MATE, and Sugar - all allow login as root, so this bug should not present any major roadblocks to accessing the installed system. However, if you do install without creating a user account, we strongly advise that you log in as root only in order to create a user account, and then immediately log out and in future always log in as the user account. Using a graphical desktop with root privileges can increase your vulnerability to remote attack, to simple mistakes having severe consequences, and to bugs caused by software not expecting to be run with root privileges.
This issue does not affect the GNOME initial setup utility: in fact, that utility will not allow you to skip user account creation at all.
Kickstart: if no password is specified for a user account, it will be unlocked
link to this item - Bugzilla: #1063540
In Fedora 20 (and 19), if you do a kickstart installation and your kickstart contains a user directive with no password, the user will be created as an unlocked account: it will be possible to log in to it with no password. This differs from previous releases and from the behaviour previously described on the wiki page (which has now been updated), where such an account would be created locked: impossible to log into.
To create a locked user account, explicitly specify the --lock parameter to the user directive in your kickstart file. It would be best practice to do this in any case, and not rely on the default behaviour being correct, as this case shows!
This issue will be resolved for future releases.
Upgrade issues
Upgrade fails if /var is a separate partition
link to this item - Bugzilla: #1045168
If the /var
, or more specifically the /var/tmp
directory on your system is a separate partition from the root filesystem (whether using regular partitions or LVM), a fedup-based upgrade may fail to work correctly. After the first stage is complete and you reboot, the upgrade environment may fail to find the /var device. Testers report that the system will in fact boot to your normal graphical environment instead of to the upgrade process, in this case.
This is fixed in fedup-0.8.0-4. You don't need to re-run fedup
- just update and reboot.
Upgrade fails with dependency issues if perl-Language-Expr
is installed
link to this item - Bugzilla: #992666
If you attempt to upgrade a system with the perl-Language-Expr
package installed to Fedora 20, it will likely fail, as the package has broken dependencies in the Fedora 20 repositories. In Fedora 20, nothing else requires the package, but in Fedora 19 and earlier, some things did.
Until we resolve this problem, the workaround is to remove perl-Language-Expr
and all its dependencies before upgrading, perform the upgrade, and then reinstall any of the dependencies you still wish to use. They should all install without a problem after the upgrade.
Fedup: upgrade can't start without rd.luks.uuid/rd.lvm.lv/rd.md.uuid boot args
link to this item - Bugzilla: #974000
The system may hang during the reboot after running the command fedup --network 20
if these parameters are not specified.
Under normal circumstances, the installer would set up those arguments for you, but some people who migrated from GRUB to GRUB2 by hand have dropped those arguments - which works fine for F17 and F18, but fails for F19 and later.
The recommended fix is to restore the rd.luks.uuid/rd.lvm.lv/etc. arguments from your old grub.cfg. In a pinch, you can add "rd.auto=1" to your boot arguments to make dracut try to automatically set up every disk it finds; this isn't recommended for general use though.
Upgrading to Tmux 1.9a-2 results in not being able to connect to sessions created previously
link to this item - Bugzilla: #1073119
If you've recently updated tmux - you might not be able to connect to sessions created with your earlier version of tmux. There are two workarounds for this. Run
pgrep tmux
/exe at
to connect to your older session so you can migrate it - or downgrade.
Hardware issues
Software issues
DVD not available as a package repository after installation
link to this item - Bugzilla: #888307
In older releases of Fedora - at least older than Fedora 18 - after you installed from the DVD, it was automatically used as a repository for installing packages after system installation. Since Fedora 18, due to changes to the underlying tools, this function has no longer worked. We hope to be able to restore it soon, but cannot commit to a specific time frame.
A comment on the bug provides a partial workaround which will allow you to install packages from the DVD using the yum
libvirt guests are killed on host shutdown
link to this item - Bugzilla: #1031696
When hosting virtual guests via libvirt in recent Fedora releases it is intended that, if you shut the host down with the guests still running, they will be suspended and then resumed when you boot the host up again. This does not currently work in Fedora 20. If you shut the host down with guests running, they will simply be uncleanly shut down (the processes are killed).
We are currently investigating to try and find a fix for this issue. In the mean time, if your virtual guests are of any value to you, please shut them down cleanly before shutting down the host. We apologize for any inconvenience this may cause.
KVM guests using the qxl graphics driver may display sluggish graphics performance on Fedora 20 hosts
link to this item - Bugzilla: #1020393
With a sufficiently recent version of Fedora's virtualization stack, such as that in Fedora 20, a feature is available for guests that use the qxl virtual graphics adapter and driver which is intended to provide smooth playback of video in the guest guests. However, it seems this 'streaming' mode can erroneously be invoked when certain non-video operations happen in guest machines, and this causes very sluggish graphics performance and artifacting. In particular, the way GNOME 3 handles screen redraws means this problem affects guests running GNOME 3 very badly, but it can also be seen on other desktops in certain circumstances, such as when scrolling through a web page that contains many large images.
We have implemented a workaround for the qxl driver in Fedora 20 which means that Fedora 20 guests are not affected by this bug, and we will likely provide the workaround for Fedora 19 as an update. However, the bug may still be observed on other guest operating systems that include a qxl driver which is new enough to take advantage of the streaming feature, but does not contain this workaround. If you are unfortunate enough to be affected, you can edit the configuration of the virtual machine (e.g. via virsh
), and change the line that looks like this:
<graphics type='spice' autoport='yes'/>
to look like this instead:
<graphics type='spice' autoport='yes'> <streaming mode='off'/> </graphics>
This disables the 'streaming' feature for the virtual machine, which should completely avoid the problem occurring on any guest operating system.
Error messages about swap activation if swap is on a plain partition on a GPT disk
link to this item - Bugzilla: #1017509
If your swap device is a plain partition (not LVM-backed) on a GPT-labelled disk, it appears that systemd has some trouble activating this, and you will notice errors in your system log at each boot, related to swap activation. However, testing indicates that the swap device is ultimately activated successfully. This issue is unlikely to cause any real problems, we note it purely to explain why you may see these errors in the system log. You can run the command swapon
without any parameters if you wish to check that the partition has been successfully activated.
link to this item - Bugzilla: #1028813
Some Fedora 20 users have encountered periodic, apparently random crashes in GNOME Shell. As Shell respawns itself automatically when it crashes, this manifests itself as the Shell and all window decorations disappearing for a few seconds, then returning, and a notification that a crash occurred. If you examine or report the crash information, it is always in a Javascript-related function. Often, but not always, an attempt to report it as a bug will result in it being identified as a duplicate of bug #1028813.
This issue is proving very tricky to isolate and fix: it appears to be some sort of memory corruption caused by GNOME's particular user of the Mozilla Javascript engine, which it uses. We are treating it as a high priority issue, but work on debugging it is difficult. GNOME's respawning behaviour means it is only really an inconvenience, but we recognize that it's annoying and we do aim to fix it as soon as we can.
If you are familiar with debugging this kind of issue using valgrind, you may be able to help us in fixing it. Details on the debugging information that would be useful can be found in bug #1034467 (the corresponding Rawhide bug) and Mozilla bug #972725.
Desktop elements appear too large in GNOME ("high DPI" mode incorrectly enabled)
link to this item - Bugzilla: #1025391
GNOME / GTK+ 3.10, included in Fedora 20, includes initial support for "high DPI" mode - essentially, rendering text and other display elements using more pixels on very high resolution displays, so that they appear at a 'normal' size.
Detecting when this mode should be engaged depends on being able to reliably determine the display resolution and physical size, and there are some known cases - particularly Samsung displays, particularly televisions - where this does not work correctly, resulting in the "high DPI" mode being enabled on displays where it should not be used. The symptom of this bug is that the GNOME interface, text and icons and so on look too large.
If you are affected by this issue, running the command gsettings set org.gnome.desktop.interface scaling-factor 1
- as your regular user account, not as root! - should resolve it. A graphical preference for the scaling factor should be added to the GNOME Tweak Tool at some point in the future, to make it easier to override the auto-detected setting.
Crash in speech-dispatcher process when launching GNOME or KDE screen readers
link to this item - Bugzilla: #995639
Both GNOME and KDE desktops in Fedora 20 include a screen reader application, a tool for visually-impaired users which reads the contents of the screen aloud. GNOME's is orca
, KDE's is jovie
. Commonly, when launching either of these, you will be notified of a crash in the speech-dispatcher
This may be disconcerting, but testing indicates it does not actually prevent the screen reader applications from working correctly; you can safely proceed to use them. It is not necessary to report the crash, as the issue is already known and we are attempting to find a solution, but it will not harm anything if you do.
Repeated dbus error messages logged with ModemManager.service disabled
link to this item - Bugzilla: #1018017
If you have NetworkManager installed and active, but you disable ModemManager.service - which you might well choose to do if you have no cellular modem - this will result in error messages being printed to the system logs every two minutes:
Dec 14 09:27:02 localhost dbus-daemon[671]: dbus[671]: [system] Activating via systemd: service name='org.freedesktop.ModemManager1' unit='dbus-org.freedesktop.ModemManager1.service' Dec 14 09:27:02 localhost dbus[671]: [system] Activating via systemd: service name='org.freedesktop.ModemManager1' unit='dbus-org.freedesktop.ModemManager1.service' Dec 14 09:27:02 localhost dbus[671]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.ModemManager1.service': Unit dbus-org.freedesktop.ModemManager1.service failed to load: No such file or directory. Dec 14 09:27:02 localhost dbus-daemon[671]: dbus[671]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.ModemManager1.service': Unit dbus-org.freedesktop.ModemManager1.service failed to load: No such file or directory.
There is no more serious consequence of this problem, but you may find the log spam annoying. You can avoid it by re-enabling ModemManager.service, or by removing ModemManager entirely with su -c 'yum remove ModemManager'
Eclipse crashes with Google Talk plugin installed
link to this item - Bugzilla: #1040223
Multiple users have reported an unusual bug in the Eclipse IDE: it commonly crashes if the Google Talk plugin is installed.
Unfortunately, as the Google Talk plugin is proprietary and no debugging symbols are available, Fedora developers cannot resolve this issue. A Google employee has stated that he has reported the issue internally, but we have received no progress reports since then.
Users have reported that the Eclipse IDE no longer crashes when the latest version of the Google Talk plugin is installed. Therefore updating the plugin would be strongly recommended. If this still fails, a workaround has been suggested at https://bugzilla.redhat.com/show_bug.cgi?id=1043438#c3. Alternatively you may choose to remove the Google Talk plugin.
ZIP support in PHP
link to this item - Bugzilla: #999313
In Fedora 20, support from ZIP has been dropped from main php package and is now provided in a separate php-pecl-zip package.
If you need zip support, as for any other extension, run su -c 'yum install php-zip'
yum reports duplicate packages installed, older version cannot be easily removed
link to this item - Bugzilla: #989145 - Bugzilla: #1028430 - Bugzilla: #1029006 - Bugzilla: #1017493 - Bugzilla: #995158
This note covers a category of issues, rather than a specific bug.
The RPM packaging system used by Fedora allows the execution of scripts, often known in context as 'scriptlets', at various points during the process of installing, removing and updating packages. In this context, RPM considers 'updating' a package to consist of installing the new package and then removing the old package, as two separate operations (in fact, all installation operations are run, and then all removal operations are run). A package can specify scriptlets to run:
- Before the entire transaction of which its installation and/or removal will be a part (%pretrans)
- Before it is installed (%pre)
- After it is installed (%post)
- Before it is removed (%preun)
- After it is removed (%postun)
- After the entire transaction of which its installation and/or removal will be a part (%posttrans)
An idiosyncracy of this system is that it can lead to bugs that are almost impossible to fix entirely. In particular, the %preun stage is vulnerable to this. If a package is ever built with a broken %preun scriptlet, then the game is almost entirely lost: you cannot really 'fix' a broken %preun scriptlet with an update, because of when the scriptlet is executed. 'Updating' to the new package consists of installing the new package and removing the old one, and the broken %preun scriptlet will be executed on removal of the old package. Ironically, in fact, if a packager notices a broken %preun scriptlet and ships an update to fix it, the very act of installing the update that fixes the broken scriptlet will trigger the broken scriptlet. When scriptlet execution fails, RPM will abort immediately and still consider the affected package to be installed, although all its files have already been removed (or updated to the newer version if the package was being updated rather than removed).
Sometimes we are able to work around this with clever tricks like inserting a hack in a scriptlet that we know will be executed before the broken %preun scriptlet which somehow works around the error, but this is not always practical. In general, if you are unfortunate enough to install a package with a broken %preun scriptlet (or, in certain circumstances, another broken scriptlet), it is likely you will wind up with a duplicate package database entry whenever you come to update or remove that package.
If you have been affected by this class of bug and now have a 'duplicate' package installed that you are having difficulty removing, it can usually be resolved by running:
rpm -e --noscripts (packagename-version)
Package versions known to have been affected by this type of issue within the last three releases include the following, though this cannot be known to be an exhaustive list:
- kde-settings-kdm-19-23.fc19
- nscd-2.17-13.fc19
- lightdm-1.4.0-2.fc18
- usbmuxd-1.0.8-10.fc19 and usbmuxd-1.0.8-10.fc20
- acpid-2.0.19-4.fc20
Bluetooth HSP/HFP Profile stops working with upgrade from F19
link to this item - Bugzilla: #1045548
Fedora 19 used Bluez 4 and supported switching between A2DP Sink profile (sink only) and the HSP/HFP Telephony profile (mono sink + mic source). Fedora 20 migrated to Bluez5 which has a regression causing HSP/HFP Telephone profile to not be available. This regression is documented in the draft release notes for Pulseaudio 5.0, which say (in "Notes for packagers"): "PulseAudio now supports BlueZ 5, but only the A2DP profile. BlueZ 4 is still the only way to make HSP/HFP work."
Text renders fuzzy with Cantarell font (default Gnome font)
link to this item - Bugzilla: #1035486
Fedora 20 includes a new freetype package, which now uses a new font rendering engine (CFF) compared to previous Fedora releases (autohinter). This engine causes the Cantarell font to appear "fuzzy" due to the font darkening. Several workarounds include using "slight" hinting or to temporarily use the autohinter engine (freetype 2.4.11).
rsyslogd consumes 100% CPU time
link to this item - Bugzilla: #1047039
Several users have reported seeing the rsyslogd logging daemon consuming 100% of CPU time (this may manifest as sluggish performance and/or high power consumption and heat production). This appears to be triggered by specific contents of the systemd journal.
Deleting the contents of the journal - in either /var/log/journal
or /run/log/journal
- will resolve the issue, though of course result in you losing the copy of the system logs accessible via journalctl
and other journal-related tools.
If you continue to run into the issue, it may be easier simply to remove the rsyslog
package and rely on the journal for system logging.
Resolved issues
link to this item - Bugzilla: #1040922
Attempting to launch the application Panorama Stitcher from the KDE menus in Fedora 20 would result in it crashing. This application is only present on the menus by default if you install from DVD, not if you install from the KDE live image. The panorama function is really one of the many Kipi image manipulation plugins for KDE, and is usually expected to be accessed from a Kipi-enabled graphics manipulation application; its presence in the menus is only a convenience.
Multiple cases of "group (groupname) does not exist" errors when running yum
link to this item - Bugzilla: #1043207 - Bugzilla: #1014202 - Bugzilla: #1043221 - Bugzilla: #1043231
If you switched to group_command=compat mode as a workaround for this issue, you can now safely return to group_command=objects mode once you have updated yum, by running {{{1}}}
There were several similar and inter-related bugs in Fedora 20's Yum package manager which could cause it to print bogus warnings about groups not existing in certain circumstances. You might have seen any of these warning messages:
- Warning: group (groupname) does not exist.
- Warning: environment (groupname) does not exist.
- Warning: Environment Group (groupname) does not exist.
when running yum groupinstall (groupname)
, yum install @(groupname)
, or yum upgrade
after having once installed any package or environment group with yum groupinstall (groupname)
or yum install @(groupname)
. The most common and most visible case of this bug - where you saw multiple instances of the first warning - would occur only if you had updated to yum-3.4.3-120.fc20 or higher, it did not affect the initial Fedora 20 version, yum-3.4.3-106.fc20.
A less immediately visible but somewhat more significant issue was that, when you installed an "environment group", yum failed to correctly keep track of which "package groups" were installed as a part of that "environment group" - it in fact never considered any package group to have been installed as part of an environment group. This meant that running "yum group remove (environment group)" would not remove anything. Note that any such environment group installations you did with an affected version of yum - anything prior to 3.4.3-127 - will still be affected by this.
We have not yet discovered any very serious consequences of these bugs - they are mostly superficial, though they can be annoying. As far as we are currently aware, there is no possibility of data loss, or of the packaging system becoming seriously broken. It is safe to continue using your Fedora 20 system and working with packages, even if you see these messages. Some of the more advanced group functions related to the Fedora 19 "yum groups as objects" feature, however, would not perform as advertised.
Various 'workarounds' were possible, though all involve in some way interfering with the operation of the aforementioned Fedora 19 "yum groups as objects" feature. Probably the safest and most easily reversible was to run:
yum-config-manager --save --setopt=group_command=compat
This will configure yum to effectively disable the "groups as objects" feature and revert to the simple handling of groups it used prior to Fedora 19. The major drawback of this is that the yum group remove
command almost never does what you want in this configuration. Another possible workaround was to run yum group mark remove (groupname)
for each affected group. This was a little more work, and also harder to reverse in future, but it is safe. It tells yum to consider the group in question as 'not installed', but will not lead to the removal of any packages unless you run a specific command or change a configuration setting.
yum groups mark convert command recommended by yum results in many additional packages being installed on yum update
link to this item - Bugzilla: #1043207
If you run certain yum commands, it may advise you to run a command yum groups mark convert
. This is related to the Fedora 19 "yum groups as objects" feature: it is intended to look at an existing Fedora system, work out which package groups are installed, and write that information out for the use of the "groups as objects" feature.
Testing has indicated that prior to yum-3.4.3-128.fc20 this command was too aggressive in determining which package groups were installed, and marked for instance groups from which only a single package is present on the system as being 'installed', even if that package was actually installed individually or as part of another group. As one of the "groups as objects" features is that not-currently-installed packages from installed groups will be added when running yum upgrade
, the result is that, on running yum upgrade
after yum groups mark convert
, yum will attempt to install many new packages, most of which you likely do not want.
If you ran the command with an affected version of yum and wish to prevent yum trying to install additional packages, there are several possibilities.
The easiest is to run yum-config-manager --save --setopt=group_command=compat
, which will have the effect of disabling the "groups as objects" functionality entirely, reverting yum to its pre-Fedora 19 handling of package groups. Unless you were interested in taking advantage of the "groups as objects" features, you will likely be happy with this behavior.
If you wish to try and maintain the "groups as objects" functionality (despite this bug and the others discussed above), you can run yum group list installed hidden -v
to print the list of groups that yum now believes is installed, and run yum group mark remove (groupname)
to tell yum to consider a group as 'not installed'. Do this for each of the groups you do not want, until yum no longer wishes to install additional packages you do not want.
Missing attributes in objectclasses in 389 Directory Server (and hence FreeIPA)
link to this item - 389-ds #47631
A bug in the schema parser in the version of the 389 Directory Server included with Fedora 20 could result in objectclasses missing attributes. This bug could have significant and unpredictable negative effects depending on your LDAP configuration; it is at least likely that you will see unexpected errors when attempting to add or modify any entry with one of the broken objectclasses. This bug has already been reported to cause significant issues when running a FreeIPA server on Fedora 20, and if you replicate a broken Fedora 20 deployment of 389 Directory Server / FreeIPA with a working deployment, the issue may spread to the previously-working servers.
Due to other 389 and FreeIPA issues discussed earlier in this page, we still recommend not deploying any kind of production 389 Directory Server or FreeIPA server using the Fedora 20 release at this point. Updates will be issued to resolve the other bugs listed on this page, and it should be safe to deploy a Fedora 20-based 389 / FreeIPA server with those updates installed.
389 Directory Server referential integrity plugin fails to work
link to this item - 389-ds #47624
If your configuration of the referint (referential integrity) plugin for the 389 Directory Server is missing these two attributes:
nsslapd-pluginEntryScope: dc=example,dc=com nsslapd-pluginContainerScope: dc=example,dc=com
then the plugin would fail to work correctly (attributes would not be adjusted as expected). These attributes were added to the default referint configuration in 389-ds #47621, but it was not intended that the plugin would break if they were not present. If you were affected by this issue, it could be worked around by adjusting your referint plugin configuration to specify these two attributes.
As there are several other significant bugs in this software stack discussed on this page, we strongly recommend you do not deploy FreeIPA or 389 Directory Server on Fedora 20 in production at all until these issues are resolved.
389 Directory Server crashes after enabling FreeIPA Active Directory trust support
link to this item - Bugzilla: #1041732 - Bugzilla: #1043546
It was reported that, if you set up a FreeIPA server on Fedora 20 and enable the Active Directory trust support by running ipa-adtrust-install
, the 389 Directory Server (LDAP server) could crash. In fact there were two crashes, one in 389-ds itself, and one in the slapi-nis
plugin. The result of this was that the FreeIPA domain will cease to function correctly, since the LDAP server component is a vital one.
Upgrade to Fedora 20 with fedup 0.7 fails, reboots shortly after booting the System Upgrade option
Upgrading from Fedora 18 or Fedora 19 to Fedora 20 using the FedUp utility will fail if you use version 0.7 or earlier. The symptom is that the first stage of upgrade (before rebooting) works successfully, but when you reboot to complete the upgrade, the second stage begins but almost immediately aborts and reboots back to your previous Fedora system. The failure is not harmful in any way - your existing Fedora install will not be damaged, and you will be able to upgrade to Fedora 20 successfully by following the instructions below.
We apologize for this error - pre-release testing of Fedora 20 indicated that fedup 0.7 would work successfully for most upgrades, but this does not seem to have worked out.
Happily, the resolution is simple: use fedup 0.8 or later for a successful upgrade. If you have not yet upgraded to Fedora 20, simply ensure you have version 0.8 or later of fedup installed (it is available from the updates repository) before running. As long as you use fedup 0.8 or later, your upgrade should run successfully.
If you have already run fedup 0.7 and encountered this issue, you can achieve a successful upgrade with fedup 0.8. Note that the location to which fedup downloads files has changed between 0.7 and 0.8. You can simply run 0.8 and achieve a successful upgrade, but it will re-download files unnecessarily, consuming time, bandwidth and space. To avoid this, before running fedup 0.8, run these commands:
su -c 'mv /var/lib/fedora-upgrade /var/lib/system-upgrade' su -c 'mv /var/tmp/fedora-upgrade /var/tmp/system-upgrade'
This will save you time, bandwidth and disk space.
If you have already run both a failed 0.7 and a successful 0.8 upgrade attempt, you may wish to check if the /var/lib/fedora-upgrade
and /var/tmp/fedora-upgrade
directories exist, and if so, remove them: they are no longer needed and are simply occupying disk space.
Upgrade to Fedora 20 with fedup 0.8 fails due to GPG key problems
link to this item - Bugzilla: #1040689
Version 0.8 of the FedUp upgrader adds checking of GPG keys on packages as a feature. This improves the security and verifiability of the upgrade process, but there are a few circumstances in which it may cause problems.
First, it requires that the version of Fedora you are upgrading from have the package signing keys of the version of Fedora you are upgrading to available. This requires that you update to the latest stable version of the fedora-release
package prior to running fedup. Otherwise, it will fail during the setup phase with the error message Downloading failed: could not verify GPG signature: No public key.
Second, fedup may abort if it cannot find a GPG key for all enabled package repositories. If you have any third party repositories configured, fedup may not be able to find keys for them. If fedup is failing with what looks like a GPG key-related error, and you have any third party repositories enabled, try temporarily disabling them before running fedup. You can re-enable them after the upgrade has completed and then run yum update
to update packages from them.
Alternative on-screen keyboards do not work correctly in GNOME
link to this item - Bugzilla: #1019073
A bug in the mutter
window manager for GNOME 3 meant that on-screen keyboards other than GNOME's own native one (available from the 'Universal Access' control panel applet or panel menu if enabled) would not work correctly: clicking on a key on the keyboard would not result in the character appearing in the currently-active application.
link to this item - Bugzilla: #1038959
Testing indicated that, in Fedora 20, it was not possible to browse SMB/CIFS shared resources - i.e. Windows or Samba file or device shares - with the default FirewallD firewall enabled, even if you enabled the 'samba-client' firewalld service. By comparison, in Fedora 19, browsing appeared to work even without needing to enable that service. The issue was not specific to a particular desktop or file manager utility, it seemed to be an issue in the firewalling layer. You could connect to a share by entering the path explicitly, and shares that were advertised via zeroconf/Bonjour may show up when you browse.
MyPasswordSafe crashes
link to this item - Bugzilla: #1042667
Users of the MyPasswordSafe application reported that it commonly crashed on Fedora 20 when generating or entering passwords. If you submitted a bug report it would likely appear as a duplicate of bug #1042667.
Disabling SELinux via configuration file failed with libselinux-2.2.1-4.fc20
link to this item - Bugzilla: #1046470
After the release of Fedora 20, libselinux-2.2.1-4.fc20 was submitted as an update, passed basic validation testing, and went to the stable updates repository. Unfortunately, it turned out that this update contained a bug which makes it impossible to disable SELinux via the configuration file /etc/selinux/config
. If you set:
in that file, you would instead most likely get permissive mode, rather than a completely disabled SELinux. To work around this issue, you could pass selinux=0 on the kernel command line: this would successfully disable SELinux.
CUPS hangs on shutdown (causing a long wait on system shutdown) if printer sharing is enabled
link to this item - Bugzilla: #1044602
It was reported that if the Publish shared printers connected to this system option was enabled in Print Settings - Server Settings, then the CUPS daemon would hang when the system tried to stop it (i.e. on shutdown/reboot or when stopping it manually with systemctl stop cups.service
). After a few minutes, systemd would time out and forcibly kill the process allowing the shutdown/reboot to complete.
ARM: HDMI output and USB peripherals not working on Beagle Bone Black
link to this item - Bugzilla: #1012025
Fedora 20 GA has non functional USB/HDMI. At the moment, to use the Beagle Bone Black, you will need a serial console attached to the 6 pin serial header. There's full details here. The 3.12.7 kernel has full working usb/hdmi/network. There's kernel but not user space support for a virtual serial port over the USB OTG port but this is as yet doesn't have userspace support. Unofficial updated images are planned to be made available by the Fedora ARM team for the convenience of Beagle Bone Black users shortly after the 3.12 kernel lands with the only difference being the 3.12 kernel in the image.
GNOME Shell crashes after creating a keyring without a password
link to this item - Bugzilla: #1012844
In Fedora 20 with the GNOME desktop, if you attempted to create a new keyring without a password or change the password of your keyring to an empty string (you may do this from the "Passwords and Keys" application, or you may be prompted to create a keyring password the first time GNOME attempts to store some kind of key), the GNOME shell would crash. The workaround for this is to always use a password on your keyring.
Sudden inability to unlock screen, or log in to running system (caused by creation of /var/run/nologin)
link to this item - Bugzilla: #1043212
The systemd version (208-9.fc20) included with Fedora 20 can, on some systems, cause the file /var/run/nologin
(or - reports differ - /run/nologin
) to be created during normal system operation. This has various consequences: it will prevent new user logins to the system, prevent a shutdown being triggered, and can prevent unlocking an active session. There has been one report that, if the system is hibernated in this state, on resume, the desktop session will not be locked.
This behaviour ultimately appears to be triggered by the issuing of multiple systemctl
commands in quick succession. This can sometimes occur during package installation / update / removal operations.
Attempting to perform an affected operation at a console will present the message "System is booting up. See pam_nologin(8)." The workaround is to remove the file /var/run/nologin
manually: if you are 'locked out', you should be able to log into a virtual terminal (ctrl-alt-f2, ctrl-alt-f3...) as root to remove the file.


text:
Lir Teardrop Pendant
Capture the beauty of the waves of the sea with this elegant this silver plated pendant, designed and created by the Newbridge Silverware design team to celebrate 30 years of handcrafted jewellery. This timeless collection is ideal for adding those final touches to your look and will make a beautiful gift for any occasion.
Product Features
- Silver Plated with a Protective Anti Tarnish Layer
- Contemporary Design
- Perfect Gift for Any Occasion
- Presented in Our Iconic Newbridge Silverware Gift Box
Chain length 570mm including a slider mechanism for easy adjustment, pendant 23mm x 34mm.
FREE delivery on orders over £100.
Each item is hand-packed with care and attention, then sent to you in discreet outer packaging with no mention of Hanratty Jewellers on the outside. So if you're ordering a gift, or planning a surprise, you can be safe in the knowledge it will remain a secret!
Standard Delivery:
Free on orders over £100, £4.95 for orders under £100
- Delivery is within 3-5 working days Your order will be delivered by Royal Mail
- You will be notified when your order is dispatched and provided with a tracking link
Next Day Delivery:
Free on orders over £200, £8.95 for orders under £200
- Northern Ireland & UK addresses only
- Order before 12 noon Monday to Friday for next day delivery*
- Your order will be delivered by Royal Mail
- You will be notified when your order is dispatched and provided with a tracking link
Please note, not all of our items will be available for next day delivery such as engraving, sizing, special instructions**.
Click & Collect:
Free on all orders
- Buy your items online and collect in store within 2-3 working days
- You will be notified when your order is ready for collection
Republic of Ireland Delivery:
Free on orders over £100, £7.95 for orders under £100
- Standard delivery only
- Your order will be delivered by An Post
- You will be notified when your order is dispatched and provided with a tracking link
Delivery Terms & Conditions
**Delivery Exceptions
We are unable to provide next day delivery on Items that require special instructions such as engraving or sizing.
On some occasions, we may have to order your item direct from our suppliers. In this instance, we will contact you to update you on your order progress and timeframe for when to expect your order.
*Next day delivery schedule is as follows:
Orders placed before 12 noon Monday to Friday will be delivered the next working day.
Orders placed after 12 noon Monday to Friday will be delivered in 2 working days.
Orders placed on Saturday & Sunday will be delivered on Tuesday.
Returns Policy
After receiving your parcel, if you are not 100% happy with your purchase simply send it back and we will be more than happy to give you a full refund or an exchange. Please ensure that the item is in its original packaging and accompanied by your proof of purchase. The items must be returned to us unworn within 30days.
Please allow 10 days for your return to be processed. If you requested a refund, it will be applied to the original card used to place your order.
Please post your items back to the below address:
Hanratty Jewellers
7 Cardinal O'Fiaich Square
Co. Down
N. Ireland
Please ensure that any items returned to us are securely packaged as we will not accept liability for items lost or damaged in transit for return or exchange. We would recommend when posting any items back to us to do so via recorded delivery and to obtain a receipt for your records. You are responsible for returning the item back to us and the return postage charge. Please do not hesitate to contact us if you have any queries regarding our returns policy.
Please note, this refund policy applies only to orders placed through our website and does not apply to items purchased in store.
We trust all our products to be of the highest quality and will guarantee everything against manufacturing defects. Please ensure to retain your proof of purchase and guarantee booklet enclosed within the product box as this acts as your full manufacturing warranty. If your item has a manufacturing defect, please contact us to arrange return. These rights are additional to and do not detract from your statutory rights.

subset: commoncrawl


text:
1a But the Ephraimites said to him, "What have you done to us, not summoning us when you went to fight against Midian?" And they quarreled bitterly with him. 2But he answered them, "What have I done in comparison with you? Is not the gleaning of Ephraim better than the vintage of Abiezer?b 3It was into your power God delivered the princes of Midian, Oreb and Zeeb.c What have I been able to do in comparison with you?" When he said this, their anger against him subsided.
4When Gideon reached the Jordan and crossed it, he and his three hundred men were exhausted and famished. 5So he said to the people of Succoth, "Will you give my followers some loaves of bread? They are exhausted, and I am pursuing Zebah and Zalmunna, kings of Midian." 6But the princes of Succoth replied, "Are the hands of Zebah and Zalmunna already in your possession, that we should give food to your army?"* 7Gideon said, "Very well; when the LORD has delivered Zebah and Zalmunna into my power, I will thrash your bodies with desert thorns and briers." 8He went up from there to Penuel and made the same request of them, but the people of Penuel answered him as had the people of Succoth. 9So to the people of Penuel, too, he said, "When I return in peace, I will demolish this tower."
10Now Zebah and Zalmunna were in Karkor with their force of about fifteen thousand men; these were all who were left of the whole Kedemite army, a hundred and twenty thousand swordsmen having fallen. 11Gideon went up by the route of the tent-dwellers east of Nobah and Jogbehah, and attacked the force when it felt secure. 12Zebah and Zalmunna fled and Gideon pursued them. He captured the two kings of Midian, Zebah and Zalmunna, terrifying the entire force.
13Then Gideon, son of Joash, returned from battle by the pass of Heres. 14He captured a young man of Succoth and questioned him, and he wrote down for him the seventy-seven princes and elders of Succoth. 15So he went to the princes of Succoth and said, "Here are Zebah and Zalmunna, with whom you taunted me, 'Are the hands of Zebah and Zalmunna already in your possession, that we should give food to your weary men?'" 16He seized the elders of the city, and with desert thorns and briers he thrashed the people of Succoth. 17He also demolished the tower of Penuel and killed the people of the city.
18Then he said to Zebah and Zalmunna, "What about the men you killed at Tabor?" "They were all like you," they replied. "They appeared to be princes." 19"They were my brothers, my mother's sons," he said. "As the LORD lives, if you had spared their lives, I would not kill you." 20Then he said to his firstborn, Jether, "Go, kill them." But the boy did not draw his sword, for he was afraid, for he was still a boy. 21d Zebah and Zalmunna said, "Come, kill us yourself, for as a man is, so is his strength." So Gideon stepped forward and killed Zebah and Zalmunna. He also took the crescents that were on the necks of their camels.
22e The Israelites then said to Gideon, "Rule over us—you, your son, and your son's son—for you saved us from the power of Midian." 23But Gideon answered them, "I will not rule over you, nor shall my son rule over you. The LORD must rule over you."f
24Gideon went on to say, "Let me make a request of you. Give me, each of you, a ring from his spoils." (Since they were Ishmaelites,* the enemy had gold rings.) 25"We will certainly give them," they replied, and they spread out a cloak into which everyone threw a ring from his spoils. 26The gold rings he had requested weighed seventeen hundred gold shekels, apart from the crescents and pendants, the purple garments worn by the kings of Midian, and apart from the trappings that were on the necks of their camels. 27g Gideon made an ephod out of the gold and placed it in his city, Ophrah. All Israel prostituted themselves there, and it became a snare to Gideon and his household.
28Midian was brought into subjection by the Israelites; they no longer held their heads high, and the land had rest for forty years,h during the lifetime of Gideon.
Gideon's Son Abimelech. 29Then Jerubbaal, son of Joash, went to live in his house. 30i Now Gideon had seventy sons, his own offspring, for he had many wives. 31His concubine* who lived in Shechem also bore him a son, whom he named Abimelech. 32At a good old age Gideon, son of Joash, died and was buried in the tomb of Joash his father in Ophrah of the Abiezrites. 33j But after Gideon was dead, the Israelites again prostituted themselves by following the Baals, making Baal-berith* their god. 34The Israelites did not remember the LORD, their God, who had delivered them from the power of their enemies all around them. 35Nor were they loyal to the house of Jerubbaal (Gideon) for all the good he had done for Israel.
* [8:6] Are the hands…already in your possession…?: i.e., can you already boast of victory? The hands of slain enemies were sometimes cut off and counted as trophies.
* [8:24] Ishmaelites: evidently used here as a general term for nomads, whose wealth was in the form of gold and flocks. The genealogies in Genesis place the Midianites as descendants of Abraham and his wife Keturah (Gn 25:1–2), and the Ishmaelites as the descendants of Ishmael, son of Abraham and Hagar, Sarah's Egyptian slave (Gn 25:12–16).
* [8:31] Concubine: a wife of secondary rank.
* [8:33] Baal-berith: a divine epithet meaning "lord of the covenant." The same deity is called El-berith, "god of the covenant," in 9:46.
Copyright 2019-2024 USCCB, please review our Privacy Policy


text:
What's the status of my order? What does "Awaiting Fulfillment" even mean?
- You can check the status of your order at this link.
- "Awaiting Fulfillment" means that we are still in the process of making your stuff (we print almost everything on demand) and packing it up for you. It's normal for your order to spend a while in this status.
- "Shipped" means we've sent your order to the post office, and it's now on it's way to you. If your order has shipped, you'll see a tracking number you can use to monitor its progress through the mail. Please note it may take a few days before your tracking number shows any updates.
- "Partially Shipped" means some of your stuff is on its way, and we're still working on the rest. We often split up orders into multiple shipments, so we can get each item to you as quickly as possible.
My order still hasn't shipped! Why is it taking so long to get my gear?
- Most of our orders ship out within 7 business days. This means it may be a week and a half of calendar days before your order ships, and then it will take a few more days to travel to your location and be delivered.
- Based on our experience, we recommend waiting two weeks from the date you placed your order before contacting us. In almost all cases, everything is fine and your order will ship soon.
- Sometimes we experience huge order spikes, for instance when the campaign is in the headlines. During these spikes, it may take us up to 10-14 business days to ship.
I made a mistake with my order. Can I change the items or the shipping info?
- If you need to make changes to your order, please contact us as soon as possible and include your order number. If your order hasn't shipped yet, we may be able to make certain changes.
- If your order has already shipped, unfortunately there is no longer anything we can do to change it.
- We can generally make changes to the shipping address and the purchaser contact information associated with the order.
- In most cases we cannot change, add or remove the retail items purchased in your order. There are customer protection processes in place that prevent us from adding new charges to your order, or changing the existing charges.
- If you absolutely need to change the items in your order, please contact us with the form below. We will cancel your original order and issue a refund. You will then be able to place a new order with the correct item information that you need.
The webstore is broken! I can't complete my order! Help!
- We're sorry that you're having trouble. Almost always, if the webstore isn't working correctly, if you try again on a different browser and/or computer, you will be able to purchase items successfully.
- If you're unable to complete your purchase, be sure you've entered your information in all fields, and clicked the "I Certify" dropdown. These fields are required before you can checkout, in order to comply with U.S. campaign finance laws.
I received my order, but my stuff is missing/damaged/wrong!
- We try our absolute hardest to ensure that all orders are fulfilled accurately, however mistakes do (rarely) happen.
- If you received an order that is missing items, contains the wrong items, or contains damaged items please contact us with your order number and details about the product you would like to return. We will respond as quickly as possible with information on how to process your return.
- Your request must arrive within 14 days from the time your order was delivered.
- If your damaged item is discontinued, we can provide you a with a different item or refund your purchase.
Can I order gear that's no longer available in the webstore?
- Unfortunately, no. The campaign moves fast, and so do we! We'd love to be able to offer discontinued items, but it's not currently possible.
How do I contact the campaign?
- Here at Bright Blue Ink, we run the campaign's webstore, make the stuff, and ship out the orders -- but we're not actually part of the campaign.
- If you have something to say to them, we recommend you contact Roland Gutierrez for Texas directly.
If the above didn't answer your question, please contact us.


text: Show All Photography Webdesign Art Concepts Portfolio filters Show All Photography Webdesign Art Concepts Universal Project Uniquely strategize magnetic bandwidth vis-a-vis mission-critical data. Intrinsicly benchmark emerging models via B2C users. Phosfluorescently enhance plug-and-play applications before B2B paradigms. Progressively repurpose multifunctional outsourcing before cross-unit alignments. 5 février, 2015 in Art Concepts Photography Project Credibly restore premier systems rather than performance based products. Authoritatively predominate impactful meta-services rather than out-of-the-box supply chains. 5 février, 2015 in Photography Video Project Seamlessly disintermediate unique services for business imperatives. Globally network enabled channels vis-a-vis front-end action items. Dynamically reintermediate cross functional technologies rather than frictionless vortals. Enthusiastically syndicate channels. 5 février, 2015 in Art Concepts, Webdesign Create Any Layout You Wish Collaboratively cultivate future-proof markets through economically sound solutions. Progressively scale one-to-one quality vectors through excellent content. Phosfluorescently unleash unique technologies for flexible vortals. 5 février, 2015 in Art Concepts Metro Gallery Inside Professionally develop 24/7 networks without standards compliant process improvements. Synergistically negotiate one-to-one outsourcing whereas excellent action items. Assertively customize alternative bandwidth before global growth strategies. 5 février, 2015 in Photography, Webdesign Real Estate Project Phosfluorescently cultivate magnetic leadership skills through impactful outsourcing. Enthusiastically parallel task resource-leveling technology rather than flexible technology. Efficiently streamline sustainable web-readiness with premier methods of empowerment. 5 février, 2015 in Photography, Webdesign Justified Gallery Enthusiastically impact competitive infomediaries with wireless data. Seamlessly conceptualize effective value with standardized leadership. Assertively deliver sustainable quality vectors with cross functional applications. Appropriately restore team building outsourcing. 5 février, 2015 in Art Concepts Simple Project Page Appropriately build high-payoff e-business rather than resource-leveling supply chains. Enthusiastically empower corporate initiatives after high standards in best practices. Credibly communicate accurate expertise synergize visionary meta-services before distributed resources. 5 février, 2015 in Photography, Webdesign Promotion Offensive Full-Width Portfolio Page 2 août, 2014 in Art Concepts Photography Lightbox With Full-Size Image 2 août, 2014 in Photography Load more


text:
9 products
9 products
9 products
Do you enjoy good, adult humor? So do we.
Twisted Wares features funny, snarky, pun-intended phrases & graphics on products that are both uniquely functional and hilarious.
Ring in the new year with the new Desert Collection by Silk All-in-One Mineral Paint.
Whether you prefer shabby chic, rustic, modern, contemporary, or somewhere between, Wise Owl's vast and ever-growing product line gives you access to premium products from paint-to-finish.


text:
Product Design:
Mountain Pendant Necklace,a unique Nature Jewelry gifts for Skiers, Hikers, Campers, Climbers and Nature Lovers.
Material: S925 sterling silver
Chain Length: 16/18/20 inch
Color: Silver, Gold, Rose Gold
Pendent Size:20*20mm
Package includes:
1* Necklace
1* Delicate Jewelry Box
1* Silver Polishing Cloth
Care Tips for your Jewelry:
Store your jewelry separately to avoid the scratch
Keep away from chemicals, sweat, bath, crash to avoid any damage
Rub your Jewelry with polishing cloth to bring back the shine
Size Guide
- Ring Size Guide
- Bracelet Guide
- Necklace Size Guide
This is a chart that will be extremely helpful for you to determine the ring size that you need. You can either make use of a tape or a small piece of string to measure the area that will be occupied by the ring. When it becomes a complete circle, make a mark on such string. This will be helpful for you to compare with the chart that is mentioned below.
1) *Measure your finger in warm temperatures at the end of the day.
2) *If your knuckle is a lot larger than the base of your finger,measure both the base of your finger and your knuckle and select a size between the two.
3) *When considering a wide band, move up a size from your measurement, for comfort's sake.
We have already listed some steps for you to choose your right size bracelets.
Step 1: Use the tape measure or a strip of paper to measure your wrist.
Just wrap the soft tape measure around the broadest part of your wrist and take note of the length. If you are using a plain strip of paper, mark your size with a pen or pencil then use a ruler to measure the length (The starting end of the paper must be at the base of the ruler and marked 0). That would be your wrist size.
Step 2: Add one inch, or 2.5 centimeters, onto this measurement to get the final length of your bracelets.
Please make sure there's enough space to tuck in 2 fingers as this is the space you need to add the charms. If you want to add less than seven charms, add 2 centimeters are ok. If you plan to wear eight or more charms, please add 3 centimeters. If you purchase a bangle, just choose the next size from your actual wrist measurement.
1. A bracelet is perfectly sized when you measure your wrist tightly and add 2 or 3 cm.
2. If you are between sizes, ask yourself how you like to wear your bracelet. If you wear it tightly choose the smaller size and if you like to wear it loosely take the next size up.
3. Please be aware that when you receive a new bracelet it will feel stiff, which can make it uncomfortably tight. The bracelet will quickly soften and become more flexible as you wear it.
4. Bear in mind that the more charms you add to your bracelets, the tighter it will become.
Necklace Length (Inches) Necklace Length (cm) Style Name Body Position 14" 35 cm Collar Fits close to neck 16" 40 cm Choker Choker 18" 45 cm Princess Hangs at the collarbone 20" 50 cm Matinee Reaches just pass the collarbone 22" 55cm Matinee Falls at or just above the top of the bust 24" 61 cm Opera Sits around the center of the bust 30" 76 cm Rope Drapes below the bust
Returns Policy
Your satisfaction is important to us and we know how important this special piece may be, that is why we make it with high quality components that can be enjoyed for a lifetime. If you purchase an item from us and are unhappy with it for any reason: We support refund/ exchange service within 60 days. You may return your item with a receipt or proof of purchase for a refund. The return fee will be borne by the customer, unless our mistakes. Items must be returned in salable condition and original packaging. Non-salable items cannot be returned.
Shipping Policy
Free Shipping on All Orders
Usually, We do our best to process and handle the orders and Our handcraft Time is 3-7 business days. We offer free standard registered airmail, or you can pay extra for express shipping during checkout.
Shipping Methods Shipping Time Cost Countries
USPS First Class Mail 8-15 Days Free United States
DHL 3-8 Days About $26 All countries
UPS 3-8 Days About $26 All countries
FEDEX 3-8 Days About $26 All countries
Express Shipping cannot deliver to P.O. Boxes or military addresses. We could only ship to P.O. Boxes and military addresses (APO, FPO) address via Standard Shipping method.


text:
3 pcs of frozen paratha (I used Kawan brand)
3 eggs
½ onion – slice thinly
1 spring onion – cut small
Salt and pepper to taste
1. In a bowl beat the eggs, add in salt, pepper, onion and spring onion. Mix well and set it aside.
2. In a non stick pan over medium heat cook the parathas (without oil) until lightly brown on both sides. Remove and set it aside.
3. In the same pan, heat up a bit of olive oil. Pour 1/3 of the eggs mixture into the pan, let it cook for 10 second then place the cooked paratha on top of the omelet.
4. Let the egg set before turning it over to cook through.
5. Remove and roll up the paratha like a Swiss roll. Do the same to the other two parathas.
6. Cut the paratha about 3/4 "thick and you can serve it with some curry.
Note : Do not thaw the frozen paratha.


text:
Prices from just £25.80 (inc. VAT) including camera survey
We offer a one hour response time to your Primrose Hill address.
We have drainage engineers covering the whole of London, in and around the M25, Herts, Beds & Bucks and can also offer appointments outside of this area by request.
Drain Clearance & Repairs Primrose Hill
Whether you have blocked drains, a blocked toilet or need a replacement drainage system, there is no job too big or small for us to consider. In fact prices start from as little as £25.80 (inc. VAT) and there is no call out charge. We also offer a 5% OAP discount. Phone today on 0800 043 4860 for a free, no obligation quote.
We offer a variety of services, Including:
- Blocked Drain Clearance
- Drain Root Removal
- Drain CCTV Surveys
- Drain Clearance
- Drainage Repairs & Replacement
- Drain Cleaning Emergency
- Blocked Toilets
- Blocked Sinks
Blocked Drains Primrose Hill
We understand that drainage issues can be nerve-wracking, especially when it comes to paying for work on your property that cannot be seen by yourself. This is why we offer a FREE camera survey on every job ( where possible ) so that you can rest assured that the job has been completed to the highest standard.
Emergency Drain Clearance
- London
- Essex
- Surrey
- Middlesex
- Kent
- Berkshire
- Hertfordshire
Drain Repairs Primrose Hill
It is not always necessary to excavate to repair a damaged drain and in these instances we will always try to utilise our state of the art methods of repair to ensure the least possible stress and disruption to you.
When possible we will reline the drain using a soft lining which can be put into the drain without excavation. This is then hardened using a chemical process which then renews the integrity of the pipeline ensuring that it is watertight.
Blocked Toilets Primrose Hill
Is your toilet blocked? We know what a problem blocked toilets can be and that you want them unblocked quickly, so we offer a 1 hour response time in and around the M25 to unblock your toilets, inspect, and solve your drainage issues. Usually the blockage is straightforward however we also offer CCTV drain surveys to help locate more complex issues with your drainage system, if the problem with your toilet is persistent / ongoing.
Drain CCTV Surveys Primrose Hill
Drain CCTV Surveys can offer the peace of mind that it is sometimes difficult to find when having drainage work carried out. It is always nerve wracking paying for a service when you cannot see the work that has been carried out. That is why we offer our drainage CCTV survey on completion when high pressure jetting was required. You can then rest assured that the work that you are paying for has been completed to the highest possible standard.
We are a member of a Trustatrader
and we think our reviews speak for themselves:
Can't recommend First Response Drainage highly enough. I had a problem with seepage in my garden which turned out to be from tree roots growing into my sewage pipes. They sorted out the problem replacing pipework in no time at all, and all at a price I was pleasantly surprised by. Five stars *****
Thank you very much First Response! My toilet became blocked on the day of my son's 4th birthday party and I was so stressed! As soon as I phoned First Response impressed me with their service. Friendly, Fast, Tidy and value for money.
I had a very very blocked kitchen sink. I phoned First Response and they arrived promptly and fixed it in no time. The service was friendly and the person who came to fix was tidy and friendly.


text:
Code: CYO|HS01 – Helicopter Safety Sign
This sign can be made in other sizes and colours. If you would like to request a different size or colour please email us.
For a fully customized sign please go to the CUSTOM MADE SIGN FORM
When you buy a sign from this website it will be made to the highest standard. All of our signs are made in New Zealand.
For more information about safety in the workplace please visit: WORKSAFE NZ
Safety Signs Sales Limited provides signs based on the customer requirements. We also stock signs that are popular. We do not install or give advice on workplace safety.
Signs provide clear, concise information. They are often the first warnings people will have about your workplace , should they enter it.
There are some requirements for signs generally. For example, they must be made out of a durable material that won't easily fade. They must be in plain English, readily understandable. The information (correct words and pictograms) must be clearly visible. They must also be legible from not less than 10 metres away under varying conditions (for example, rain or poor light).
The images on our website contain watermarking because watermarks provide copyright protection of our sign designs. No watermarks will appear on any sign you purchase from this website.
NOTE: This product and associated images are copyright and remain the property of Safety Sign Sales Limited therefore are protected by New Zealand Copyright Laws. No person or entity can profit from the use of this image or any other image shown on this site under New Zealand Copyright Law.


text:
keyword: Environmental management – 0 free books.
These Creative Commons Attribution-ShareAlike licensed ebooks are free to read - the people who created them want you to read and share them.
You are free to: copy and redistribute the material in any medium or format; remix, transform, and build upon the material; for any purpose, even commercially. Under the following terms: You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. If you remix, transform, or build upon the material, you must distribute your contributions under the same license as the original.
These books are included in the Directory of Open Access Books. This means that they have been peer-reviewed and are of interest to scholars.


text:
Atlantic Locksmith Store - Emergency Unlock 90025 - 310-819-3717
Locks and keys are omnipresent at your home, office and cars. It is almost impossible to find a home which does not have an entry door lock or an office without file - cabinet locks or a car without a lock on each door and the trunk. With so many locks in our life, it is not very difficult to lose a key now and then or damage a lock. At these times you need a reliable locksmith service which can take care of such situations and that too quickly. Atlantic Locksmith Store is one such service that has been providing first - class and affordable locksmith services to the residents and business owners of the Los Angeles, CA 90025.
We do everything that you expect a locksmith service to do and more. Right from traditional lock change and key cutting services to the installation of high - security locks at your home and office. If you need new garage door locks or ignition repair for your cars or master key system for your business, you can bank on us and we will deliver it. The large number of recommendations that our clients make to their relatives and friends, speak volumes about our service and our lasting impact on the residents of the Los Angeles, CA 90025.
Take a look at what we offer:
Key cutting services
Emergency lockout assistance
Locks rekeying
Lock replacement and new locks installation
Key duplication
Evictions services
Broken key extraction
Affordable transponder key creation
High-security laser car keys
Door repairs
And more
Atlantic Locksmith Store has employed some of the most qualified and experienced locksmiths eligible to work in Zip code 90025. Along with that we also further empower our locksmiths by providing them top grade tools, mobile locksmith vehicles for enhanced consumer convenience and by conducting regular workshops and training sessions, so that they are always on top of their game. Our fleet of mobile locksmith vehicles allows us to reach our customers in double quick time even if they are stranded in the outskirts of the city.
- Widespread availability in Zip Code 90025
- 24/7 locksmith service
- Quickest response to emergencies
- Proven track record
- Customer satisfaction focused team
- Cost – effective services
Call us to know more about our services, we will be happy to discuss how we can help to make your home and office safer. You can reach us at 310-819-3717 any time of the day.


text:
Ihre Thai-Massage in Bonn Mehlem
Bimai Thaimassage
privacy Policy
Who we are
Our website address is: https://www.bimaithaimassage.de/
Our Visiting Address: Bimai Thaimassage, Mainzer Straße 188, 53179 Bonn
Our Contact Information: Phone: 0228 35098220 | Mob. : 0162 6125652 | E-mail: email@example.com
What personal data we collect and why we collect it
This page is used to inform website visitors regarding our policies with the collection, use, and disclosure of Personal Information if anyone decided to use our Service, the Website https://www.bimaithaimassage.de/.
If you choose to use our Service, then you agree to the collection and use of information in relation with this policy. The Personal Information that we collect are used for providing and improving the Service. We will not use or share your information with anyone except as described in this Privacy Policy.
Information Collection and Use
For a better experience while using our Service, we may require you to provide us with certain personally identifiable information, including but not limited to your name, phone number, and e-mail address. The information that we collect will be used to contact or identify you.
Contact form
Personal data provided through our contact form are used to contact us. These personal data are only used to identify and contact the person in question. This information may be saved by us for a maximum of 1 month. If you feel that for some reason you do not want or mistakenly give us incorrect information or do not want us to have this information from you. Please contact us so that we can remove you.
Log Data
We want to inform you that whenever you visit our Service, we collect information that your browser sends to us that is called Log Data. This Log Data may include information such as your computer's Internet Protocol ("IP") address, browser version, pages of our Service that you visit, the time and date of your visit, the time spent on those pages, and other statistics.
Cookies are files with small amount of data that is commonly used an anonymous unique identifier. These are sent to your browser from the website that you visit and are stored on your computer's hard drive.
Our cookies improve access to our site and identify recurring visitors. In addition, our cookies enhance the user experience by tracking and targeting the user's interests. Our use of cookies is generally not linked to personally identifiable information on our site.
Links to Other Sites
Our Service may contain links to other sites. If you click on a third-party link, you will be directed to that site. Note that these external sites are not operated by us. Therefore, we strongly advise you to review the Privacy Policy of these websites. We have no control over, and assume no responsibility for the content, privacy policies, or practices of any third-party sites or services
Embedded content from other websites
Articles on this site may include embedded content (e.g. videos, images, articles, etc.). Embedded content from other websites behaves in the exact same way as if the visitor has visited the other website.
These websites may collect data about you, use cookies, embed additional third-party tracking, and monitor your interaction with that embedded content, including tracing your interaction with the embedded content if you have an account and are logged in to that website.
Who we share your data with
We value your trust in providing us your Personal Information, thus we are striving to use commercially acceptable means of protecting it. But remember that no method of transmission over the internet, or method of electronic storage is 100% secure and reliable, and we cannot guarantee its absolute security.
Third parties
We sell, trade, or otherwise transfer, not personally identifiable information to third parties.
Additional services
We may use other services that may occur on our site, where payment of goods or reservation of services may occur. The information is therefore shared with that party. But its sole purpose is to enable the customer to use the service. Read more on their page to review their privacy policy
Changes to This Privacy Policy
We may update our Privacy Policy from time to time. Thus, we advise you to review this page periodically for any changes. We will notify you of any changes by posting the new Privacy Policy on this page. These changes are effective immediately, after they are posted on this page.
By using our site, you agree to our privacy policy.
Last updated: November 30, 2019


text:
Compatible: 1997 Ford E-150
OEM Part Number: F7UZ-12A650-MD / EEC-V | California Emissions | 4.2L | A/T
Looking for a plug and play replacement F7UZ-12A650-MD ECU?
We can help!
Our rebuilt & tested replacement engine control unit (ECU) includes with a 2-year warranty.
Units typically ship out within 4 to 5 business days via priority mail.
Our refurbished & tested, OEM pre-owned unit will include a hassle free 2-year warranty.
Part numbers are important, be sure to order a replacement that matches your original part number.
No core charge – no need to send in your original unit.
Supplies may be limited.
"Do I need programming?"
This plug and play unit will not require any additional programming. Simply install the unit and go.
Your original keys will start the vehicle.
Technician's Notes:
Some common symptoms of a bad ECU include:
- Rough idle
- Cylinder misfire
- Poor acceleration
- Not found via OBD
- A/C no longer functions
- Failure or difficult to start
- Fault codes that will not clear
- Transmission shifting problems
Other acronyms for the Engine Computer: ECU Engine Control Unit – ECM Engine Control Module – BCM Body Control Module – PCM Power Control Module
OEM Meaning: Original Equipment Manufacturer – our units are factory original units.
We understand for some, a vehicle is part of the family. Our mission is to get your vehicle back on the road by offering quick and cost-effective solutions.
If you have any questions about this unit or anything else, please do not hesitate to reach out to us!


text:
Configure MySQL Workbench
NOTE: This section assumes that you have downloaded and installed MySQL Workbench.
To connect to your remote MySQL database server using MySQL Workbench, you have to allow remote connections to the server.
Once your MySQL server is configured to accept remote connections, you can connect to it using MySQL Workbench. Follow these steps:
Launch MySQL Workbench.
Click the "+" symbol in the "MySQL Connections" tab to add a new connection.
Configure the connection as follows:
Click "Test Connection" to test the connection.
If the connection is successful, click "OK" to save the connection.
Double-click the new connection to launch the MySQL Workbench SQL Editor. You may be prompted for a password. Use the same password you used when previously configuring the server to accept remote connections. Once connected, the SQL editor window will open and you can interact with the server using SQL commands, as shown below: