On Tue, 2019-01-29 at 06:11 +0800, Ed Greshko wrote:
> On 1/28/19 11:55 PM, Patrick O'Callaghan wrote:
> > On Mon, 2019-01-28 at 21:54 +0800, Ed Greshko wrote:
> >
> > > I'll do more in my AM.
> > Thanks again.
> >
>
> Well, yesterday I was able to replicate the symptoms of the problem you're
>
On 1/29/19 6:39 PM, Patrick O'Callaghan wrote:
> Interesting, though I wouldn't expect a difference between Gnome and
> KDE guests. Note that my guest is Fedora Server, with no DE installed.
The "difference" is if you install Fedora KDE spin from the Live Media it
Doesn't Install
any libvirt stuf
On Tue, 2019-01-29 at 10:39 +, Patrick O'Callaghan wrote:
> So, maybe, try disabling libvirt.service on any guests which may have it
> enabled and
> > reboot *everything* to see if your problem persists.
>
> Interesting, though I wouldn't expect a difference between Gnome and
> KDE guests. N
On 1/29/19 7:02 PM, Patrick O'Callaghan wrote:
> OK, first of all the Fedora guest doesn't have libvirt.service enabled,
> maybe because it was installed with no DE.
>
> Secondly, I did the following:
>
> 1) Verified that the Windows guest was still working.
> 2) Started the Fedora guest.
> 3) Both
After attempting today's updates, the system is almost unusable. The
problems seem to be caused by journal. I see messages like the above.
I tried rm /var/log/journal//* hoping it would clear up. But after
several reboots I still see such messages.
kde won't start at all. I'm using mate
Some more info:
df
Filesystem 1K-blocks Used Available Use% Mounted on
devtmpfs 3905924 0 3905924 0% /dev
tmpfs3920940 0 3920940 0% /dev/shm
tmpfs3920940 9740 3911200 1% /run
tmpfs3920940 0 3920940 0%
On Tue, 2019-01-29 at 20:18 +0800, Ed Greshko wrote:
> I didn't have a Win10 guest. So, I installed. And tested with a Fedora
> Guest. Both are
> still working just fine after
>
> [egreshko@f29g ~]$ uptime
> 20:16:43 up 33 min, 2 users, load average: 0.07, 0.02, 0.00
>
> How about putting
On Tue, 2019-01-29 at 14:59 +, Patrick O'Callaghan wrote:
> On Tue, 2019-01-29 at 20:18 +0800, Ed Greshko wrote:
> > I didn't have a Win10 guest. So, I installed. And tested with a Fedora
> > Guest. Both are
> > still working just fine after
> >
> > [egreshko@f29g ~]$ uptime
> > 20:16:43
On Tue, 29 Jan 2019 at 03:32, Robert Nichols wrote:
>
> On 1/28/19 8:03 AM, Ian Malone wrote:
> >I wouldn't recommend just doing /dev/zero if the CIA,
> > or even a moderately funded newspaper might specifically be after your
> > data,
>
> I would be interested to know if you can name any data rec
Finally got to the root problem. It seems I'm running on btrfs (single
device), and the metadata became too full. This causes WIERD behavior - df
would switch between sometimes showing 50% free space and 0% free.
Operations would mysteriously fail with NOSPC even though there was loads of
fr
On 01/29/2019 11:36 AM, Neal Becker wrote:
I got working again by deleting a bunch of files. I think there is some
other way I can get more metadata space for btrfs, but not sure about that.
Report it as a bug. If it's actually expected behavior, somebody will
probably tell you how to deal w
On 1/27/19 6:47 PM, Wolfgang Pfeiffer wrote:
Yes, something like that is what I suspect: The actual data on disk
would be left untouched when the *disk/partition* is encrypted. I had
a look through documents explaining luks, and again and again the
topic is "disk" encryption, not "data" encrypti
On 1/28/19 2:12 AM, Patrick O'Callaghan wrote:
Another point: several people have mentioned using /dev/urandom. It's
important to note that this is a *pseudo-random* generator. It starts
from a random seed, but from that generates a completely deterministic
pattern. If you have the seed, you have
On 1/30/19 1:37 AM, Patrick O'Callaghan wrote:
> And we're back ...
>
> I worked away using the Windows guest for several hours. Network access
> kept going, though the system felt slightly sluggish at times. When I
> looked at the Fedora guest (which I hadn't touched in all this time) it
> was off
14 matches
Mail list logo
