On 2/3/19 1:55 AM, Patrick O'Callaghan wrote:
> On Sat, 2019-02-02 at 09:02 -0500, Sam Varshavchik wrote:
>> Ed Greshko writes:
>>
>>> Well, it would be good to
>>>
>>> Stop firewalld, dump the IPTables, start the VPN daemon, wait a bit, and
>>> dump the IPTables
>>> again.
>>>
>>> Also, it w
On 2/2/19 4:22 AM, Patrick O'Callaghan wrote:
Last ditch left-field idea: I have a (commercial) VPN service which is
not normally turned on but does have a systemd daemon running. I turned
it off and everything started working.
I'll bet the vpn is messing with your routes.
___
On Fri, Feb 1, 2019 at 5:20 PM Ulf Volmer wrote:
> On 01.02.19 08:56, Marco Guazzone wrote:
> > It happened again.
> > This time with kernel 4.20.4-200.fc29.x86_64.
>
> Did you run memtest in the meantime?
>
> Best regards
> Ulf
>
Hi,
[I resend the message without the memtest screenshot because
On Sat, 2019-02-02 at 21:50 +0800, Ed Greshko wrote:
> On 2/2/19 8:22 PM, Patrick O'Callaghan wrote:
> > Last ditch left-field idea: I have a (commercial) VPN service which is
> > not normally turned on but does have a systemd daemon running. I turned
> > it off and everything started working.
> >
On Sat, 2019-02-02 at 10:02 -0500, Tom Horsley wrote:
> On Sat, 2 Feb 2019 21:50:55 +0800
> Ed Greshko wrote:
>
> > If you'd made no changes why then did the
> > problem arise?
>
> There are some things man was not meant to know :-).
It's a firewall Jim, but not as we know it ...
poc
__
On Sat, 2019-02-02 at 09:02 -0500, Sam Varshavchik wrote:
> Ed Greshko writes:
>
> > Well, it would be good to
> >
> > Stop firewalld, dump the IPTables, start the VPN daemon, wait a bit, and
> > dump the IPTables
> > again.
> >
> > Also, it would be helpful to actually name the commercial
On Sat, 2 Feb 2019 21:50:55 +0800
Ed Greshko wrote:
> If you'd made no changes why then did the
> problem arise?
There are some things man was not meant to know :-).
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to
On Sat, Feb 02, 2019 at 02:48:11PM +0100, Wolfgang Pfeiffer wrote:
So the warning cryptsetup is giving here:
-
cryptsetup open --type plain -d /dev/urandom /dev/sdd dmcrypt.test
WARNING: Device /dev/sdd already contains a 'ext4' superblock signature.
WARNING!
Detected dev
Ed Greshko writes:
Well, it would be good to
Stop firewalld, dump the IPTables, start the VPN daemon, wait a bit, and
dump the IPTables
again.
Also, it would be helpful to actually name the commercial VPN which may warn
others about
the pitfall.
Pretty sure it's Cisco Anyconnect.
On 2/2/19 8:22 PM, Patrick O'Callaghan wrote:
> Last ditch left-field idea: I have a (commercial) VPN service which is
> not normally turned on but does have a systemd daemon running. I turned
> it off and everything started working.
>
> I am now looking at 3 Fedora guests and a Windows guest all c
On Tue, Jan 29, 2019 at 03:48:01PM -0800, Gordon Messmer wrote:
On 1/27/19 6:47 PM, Wolfgang Pfeiffer wrote:
[ .. ]
It sounds like you're unfamiliar with the implementation, and possibly
with filesystems and block devices in general. I'll try to explain,
with some simplifications. You su
On Sat, 2019-02-02 at 12:01 +, Patrick O'Callaghan wrote:
> On Sat, 2019-02-02 at 10:55 +0800, Ed Greshko wrote:
> > On 2/2/19 6:13 AM, Patrick O'Callaghan wrote:
> > > On Fri, 2019-02-01 at 17:55 +, Patrick O'Callaghan wrote:
> > > > They both show *the same MAC address*: 52:54:00:8b:88:60
On Sat, 2019-02-02 at 10:55 +0800, Ed Greshko wrote:
> On 2/2/19 6:13 AM, Patrick O'Callaghan wrote:
> > On Fri, 2019-02-01 at 17:55 +, Patrick O'Callaghan wrote:
> > > They both show *the same MAC address*: 52:54:00:8b:88:60, which looks
> > > at least suspicious.
> > Correction: the address b
On 02/01/19 22:54, Marshall Neill wrote:
F9 will toggle the sidebar view.
.
That was it, perfect, I start Thunar, click on "^" to get to "/" and
then pressing "F9" brings up the display I need, NETWORK is at the
bottom of the list and from there I can get to the NAS.
Thank you for the hel
On Mon, 28 Jan 2019, Daniel Walsh wrote:
... big snip ...
> atomic storage reset
>
> I believe does the right thing. It should cleanup devicemapper as
> well.
just checking on this ... the "atomic" command is part of the
"atomic" package, which is not technically required to run docker on
my
15 matches
Mail list logo
