On Thu, Feb 18, 2021 at 12:29 AM Tim Jackson wrote:
> OK: https://bugzilla.redhat.com/show_bug.cgi?id=1930004
As I noted in my Feb. 5 reply, the bug is in gnome-boxes, which
Provides some internal libraries. See
https://bugzilla.redhat.com/show_bug.cgi?id=1925723.
--
Jerry James
http://www.jame
On Wed, Feb 17, 2021 at 02:54:19PM -0800, Paolo Galtieri wrote:
> So the appropriate wireless driver is loaded, however ifconfig shows the
> following devices:
Instead of using the 'ifconfig' tool, try running 'ip link show'.
Perhaps the interface is just down. Also, many Dells have a
keypress/sw
On Thu, 2021-02-18 at 07:43 +0800, Ed Greshko wrote:
> On 18/02/2021 03:07, Jerome Lille wrote:
> > 192.168.1.101 is the IP of my local NFS server (Centos7), my Fedora
> > desktop that produces these error messages has some shares from it
> > mounted. No errors on the NFS server and the nfs shares
Here's the info
ip link show
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp0s20f0u1u4: mtu 1500 qdisc
fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 00:e0:4c:68:0b:68 b
On 19/02/2021 00:38, Jerome Lille wrote:
On Thu, 2021-02-18 at 07:43 +0800, Ed Greshko wrote:
On 18/02/2021 03:07, Jerome Lille wrote:
192.168.1.101 is the IP of my local NFS server (Centos7), my Fedora
desktop that produces these error messages has some shares from it
mounted. No errors on the
On 2/18/21 8:38 AM, Jerome Lille wrote:
But as I said the nfs shares seem to work fine, I can read and write to
files on them.
Yep, everything will look fine until an application on your client tries
to lock a file, and then it will hang forever. Locking files during
editing is pretty common
