hibernate stops working after upgrade to F29 from F28
by Ranjan Maitra
Hi,
I tried the following:
systemctl hibernate
and I get:
Failed to hibernate system via logind: Resume not configured, can't hibernate
I have never previously had to configure anything on an upgraded system already capable of hibernating (once hibernated). Has something changed? What do I do to fix this issue?
Many thanks and best wishes,
Ranjan
--
Important Notice: This mailbox is ignored: e-mails are set to be deleted on receipt. Please respond to the mailing list if appropriate. For those needing to send personal or professional e-mail, please use appropriate addresses.
5 years, 4 months
dnf update fails
by Willis Yonker
Hi,
I did a fresh install of Fedora 29 a few weeks ago. It seems to work fine
except now dnf seems to not want to use the fedora repo. If I remove the
fedora.repo file, or even disable the fedora repo in the file, it works.
Any help would be appreciated!
Thank you!
If I run dnf -v update, here is the last part of the output:
Fedora 29 - x86_64
13 kB/s | 18 kB 00:01
reviving: 'fedora' can be revived - metalink checksums match.
not found other for: Fedora 29 - x86_64
not found modules for: Fedora 29 - x86_64
not found deltainfo for: Fedora 29 - x86_64
not found updateinfo for: Fedora 29 - x86_64
loading repo 'fedora' failure: repo_add_solv() has failed.
Error: Loading repository 'fedora' has failed
Here is the last part of the dnf.log file:
2018-11-30T14:56:58Z DEBUG loading repo 'fedora' failure: repo_add_solv()
has failed.
2018-11-30T14:56:58Z DDEBUG Cleaning up.
2018-11-30T14:56:58Z SUBDEBUG
Traceback (most recent call last):
File "/usr/lib/python3.7/site-packages/dnf/base.py", line 144, in
_add_repo_to_sack
self._sack.load_repo(hrepo, build_cache=True, **mdload_flags)
_hawkey.Exception: repo_add_solv() has failed.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 64, in main
return _main(base, args, cli_class, option_parser_class)
File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 99, in _main
return cli_run(cli, base)
File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 115, in
cli_run
cli.run()
File "/usr/lib/python3.7/site-packages/dnf/cli/cli.py", line 1054, in run
self._process_demands()
File "/usr/lib/python3.7/site-packages/dnf/cli/cli.py", line 785, in
_process_demands
load_available_repos=self.demands.available_repos)
File "/usr/lib/python3.7/site-packages/dnf/base.py", line 400, in
fill_sack
self._add_repo_to_sack(r)
File "/usr/lib/python3.7/site-packages/dnf/base.py", line 148, in
_add_repo_to_sack
_("Loading repository '{}' has failed").format(repo.id))
dnf.exceptions.RepoError: Loading repository 'fedora' has failed
2018-11-30T14:56:58Z CRITICAL Error: Loading repository 'fedora' has failed
5 years, 4 months
Kernel 4.19 does not make an ethernet connection
by Lester M Petrie
Hi,
I am currently running Fedora 28. I did a dnf upgrade this morning, and
it upgraded the kernel to 4.19.
Linux morgoth.localdomain 4.19.4-200.fc28.x86_64
After rebooting to the new kernel, I found I could not connect to
anything over ethernet. I rebooted to the previous kernel, which was 4.18.
Linux morgoth.localdomain 4.18.18-200.fc28.x86_64
My connection worked again. I went looking in the journal for entries
related to the ifname. Under the 4.19 kernel, I found the following
entries(sorry for the wrapping, I can't seem to turn it off).
-- Logs begin at Thu 2018-05-10 18:16:12 EDT, end at Thu 2018-11-29
14:05:16 EST. --
Nov 29 13:58:38 morgoth.localdomain kernel: r8169 0000:06:00.0 enp6s0:
renamed from eth0
Nov 29 13:59:29 morgoth.localdomain NetworkManager[920]: <info>
[1543517969.1764] ifcfg-rh: new connection
/etc/sysconfig/network-scripts/ifcfg-enp6s0
(8719d767-2f8e-3fc1-a9e2-522bde03a5a7,"enp6s0")
Nov 29 13:59:30 morgoth.localdomain NetworkManager[920]: <info>
[1543517970.4361] manager: (enp6s0): new Ethernet device
(/org/freedesktop/NetworkManager/Devices/2)
Nov 29 13:59:30 morgoth.localdomain NetworkManager[920]: <info>
[1543517970.4371] device (enp6s0): state change: unmanaged ->
unavailable (reason 'managed', sys-iface-state: 'external')
Nov 29 13:59:30 morgoth.localdomain kernel: IPv6: ADDRCONF(NETDEV_UP):
enp6s0: link is not ready
Nov 29 13:59:30 morgoth.localdomain kernel: IPv6: ADDRCONF(NETDEV_UP):
enp6s0: link is not ready
For the 4.18 kernel, I get the following, plus many more lines after it
is connected.
-- Logs begin at Thu 2018-05-10 18:16:12 EDT, end at Thu 2018-11-29
14:10:03 EST. --
Nov 29 14:08:04 morgoth.localdomain kernel: r8169 0000:06:00.0 enp6s0:
renamed from eth0
Nov 29 14:08:59 morgoth.localdomain NetworkManager[930]: <info>
[1543518539.5379] ifcfg-rh: new connection
/etc/sysconfig/network-scripts/ifcfg-enp6s0
(8719d767-2f8e-3fc1-a9e2-522bde03a5a7,"enp6s0")
Nov 29 14:09:00 morgoth.localdomain NetworkManager[930]: <info>
[1543518540.6720] manager: (enp6s0): new Ethernet device
(/org/freedesktop/NetworkManager/Devices/2)
Nov 29 14:09:00 morgoth.localdomain NetworkManager[930]: <info>
[1543518540.6731] device (enp6s0): state change: unmanaged ->
unavailable (reason 'managed', sys-iface-state: 'external')
Nov 29 14:09:00 morgoth.localdomain kernel: IPv6: ADDRCONF(NETDEV_UP):
enp6s0: link is not ready
Nov 29 14:09:00 morgoth.localdomain kernel: r8169 0000:06:00.0 enp6s0:
link down
Nov 29 14:09:00 morgoth.localdomain kernel: IPv6: ADDRCONF(NETDEV_UP):
enp6s0: link is not ready
Nov 29 14:09:02 morgoth.localdomain NetworkManager[930]: <info>
[1543518542.3332] device (enp6s0): carrier: link connected
Nov 29 14:09:02 morgoth.localdomain kernel: r8169 0000:06:00.0 enp6s0:
link up
Nov 29 14:09:02 morgoth.localdomain kernel: IPv6:
ADDRCONF(NETDEV_CHANGE): enp6s0: link becomes ready
Looking at these, I did a search for r8169. The 4.19 kernel gives the
following.
-- Logs begin at Thu 2018-05-10 18:16:12 EDT, end at Thu 2018-11-29
14:46:52 EST. --
Nov 29 13:58:37 morgoth.localdomain kernel: libphy: r8169: probed
Nov 29 13:58:37 morgoth.localdomain kernel: r8169 0000:06:00.0 eth0:
RTL8168c/8111c, a4:ba:db:f9:fa:9d, XID 3c4000c0, IRQ 33
Nov 29 13:58:37 morgoth.localdomain kernel: r8169 0000:06:00.0 eth0:
jumbo features [frames: 6128 bytes, tx checksumming: ko]
Nov 29 13:58:38 morgoth.localdomain kernel: r8169 0000:06:00.0 enp6s0:
renamed from eth0
Nov 29 13:59:30 morgoth.localdomain kernel: Generic PHY r8169-600:00:
attached PHY driver [Generic PHY] (mii_bus:phy_addr=r8169-600:00,
irq=IGNORE)
The 4.18 kernel shows the following.
-- Logs begin at Thu 2018-05-10 18:16:12 EDT, end at Thu 2018-11-29
14:46:52 EST. --
Nov 29 14:08:03 morgoth.localdomain kernel: r8169 Gigabit Ethernet
driver 2.3LK-NAPI loaded
Nov 29 14:08:03 morgoth.localdomain kernel: r8169 0000:06:00.0: can't
disable ASPM; OS doesn't have ASPM control
Nov 29 14:08:03 morgoth.localdomain kernel: r8169 0000:06:00.0 eth0:
RTL8168c/8111c, a4:ba:db:f9:fa:9d, XID 3c4000c0, IRQ 33
Nov 29 14:08:03 morgoth.localdomain kernel: r8169 0000:06:00.0 eth0:
jumbo features [frames: 6128 bytes, tx checksumming: ko]
Nov 29 14:08:04 morgoth.localdomain kernel: r8169 0000:06:00.0 enp6s0:
renamed from eth0
Nov 29 14:09:00 morgoth.localdomain kernel: r8169 0000:06:00.0 enp6s0:
link down
Nov 29 14:09:02 morgoth.localdomain kernel: r8169 0000:06:00.0 enp6s0:
link up
Is there something obvious to do that will get the 4.19 kernel
connecting? Is there someother information that would help find the
problem? Thanks for any help.
--
Lester M Petrie
5 years, 4 months
Fedora29 + 802.1x
by Todor Petkov
Hello,
in the office we are using 802.1x authentication on the switches with
username/password. It was working just fine for me, but after upgrade to
Fedora29, it stopped authenticating. On the switch I don't see anything
about user/pass being wrong. In NetworkManager I am using PEAP +
user/password authentication, as before, but it just stopped working.
Anyone with similar issue?
Thanks in advance
5 years, 4 months
Rubygem
by Emmett Culley
When I upgrades to Fedora 29 I had to remove a package to get through it. Namely rubygem-compass-immport-once had a conflict. now when I attempt to install it I get:
['\n Problem 1: conflicting requests\n - nothing provides rubygem(sass) = 3.2) needed by rubygem-compass-import-once-1.0.5-10.fc29.noarch\n Problem 3: package rubygem-compass-import-once-doc-1.0.5-10.fc29.noarch requires rubygem-compass-import-once = 1.0.5-10.fc29, but none of the providers can be installed\n - conflicting requests\n - nothing provides (rubygem(sass) = 3.2) needed by rubygem-compass-import-once-1.0.5-10.fc29.noarch\n Problem 4: package rubygem-compass-rails-2.0.4-6.fc29.noarch requires (rubygem(compass) >= 1.0.0 with rubygem(compass) = 0.12.2, but none of the providers can be installed\n - conflicting requests\n - nothing provides rubygem(sass)
Does anyone have any ideas how to fix the. Kind of a pain not having compass to compile CSS.
Emmett
5 years, 4 months
Download Archive for F28 iso
by Joerg Lechner
Hi,
had a crash and lost the F28 iso. Found only F24/F25 in Fedora Archives. Does anyone know a Fedora Archive containing F28 iso?
Thanks in advance!
Kind regards
5 years, 4 months
Fedora 29 root -
by Bob Goodwin
.
I just did a new install of Fedora 29 and find the installation provides
no root password. I have a lot of configuration to do and sudo is
inconvenient.
Bob
--
Bob Goodwin - Zuni, Virginia, USA
http://www.qrz.com/db/W2BOD
box10 FEDORA-27/64bit LINUX XFCE Fastmail POP3
5 years, 5 months
Fedora29 + 802.1x
by Todor Petkov
Hello,
in the office we are using 802.1x authentication on the switches with
username/password. It was working just fine for me, but after upgrade to
Fedora29, it stopped authenticating. On the switch I don't see anything
about user/pass being wrong. In NetworkManager I am using PEAP +
user/password authentication, as before, but it just stopped working.
Anyone with similar issue?
Thanks in advance
5 years, 5 months
what is wrong with dnf?
by Tom Horsley
I ran "dnf -y update" this morning. It said the last
metadata update was 8 days ago and there was nothing
to do.
I then ran "dnf clean all" and "dnf -y update" again
and it is loading 414 new updates.
What really bad setting is it consulting to think that
8 day old metadata is up to date, and where the heck do
I fix it?
5 years, 5 months