On 06/10/2018 10:21 AM, Patrick O'Callaghan wrote:
On Sun, 2018-06-10 at 09:28 -0400, Robert Moskowitz wrote:
Assuming you were logged into the guest when doing the host shutdown,
then if you had to log back in, the guest can't have been suspended and
resumed from where it left off.
I was log
On Sun, 2018-06-10 at 09:28 -0400, Robert Moskowitz wrote:
> > Assuming you were logged into the guest when doing the host shutdown,
> > then if you had to log back in, the guest can't have been suspended and
> > resumed from where it left off.
>
> I was logged in, but at the time, the session was
On 06/10/2018 08:50 AM, Patrick O'Callaghan wrote:
On Sun, 2018-06-10 at 08:02 -0400, Robert Moskowitz wrote:
Finally rebooted last night after a kernel update...
On 06/03/2018 01:16 PM, Samuel Sieb wrote:
On 06/03/2018 06:29 AM, Robert Moskowitz wrote:
On 06/03/2018 12:43 AM, Samuel Sieb w
On Sun, 2018-06-10 at 08:02 -0400, Robert Moskowitz wrote:
> Finally rebooted last night after a kernel update...
>
> On 06/03/2018 01:16 PM, Samuel Sieb wrote:
> > On 06/03/2018 06:29 AM, Robert Moskowitz wrote:
> > > On 06/03/2018 12:43 AM, Samuel Sieb wrote:
> > > > By default, libvirt and qemu
Finally rebooted last night after a kernel update...
On 06/03/2018 01:16 PM, Samuel Sieb wrote:
On 06/03/2018 06:29 AM, Robert Moskowitz wrote:
On 06/03/2018 12:43 AM, Samuel Sieb wrote:
By default, libvirt and qemu will pause the VM and save it when you
reboot. On startup, it resumes from wh
On Thu, 2018-06-07 at 00:55 +0800, Ed Greshko wrote:
> On 06/06/18 23:47, Patrick O'Callaghan wrote:
> > On Wed, 2018-06-06 at 14:44 +0200, Wolfgang Pfeiffer wrote:
> > > On Wed, Jun 06, 2018 at 12:29:02AM +0100, Patrick O'Callaghan wrote:
> > > > On Tue, 2018-06-05 at 18:39 +0200, Wolfgang Pfeiffe
On 06/06/18 23:47, Patrick O'Callaghan wrote:
> On Wed, 2018-06-06 at 14:44 +0200, Wolfgang Pfeiffer wrote:
>> On Wed, Jun 06, 2018 at 12:29:02AM +0100, Patrick O'Callaghan wrote:
>>> On Tue, 2018-06-05 at 18:39 +0200, Wolfgang Pfeiffer wrote:
And for those not so happy with tracer, there's al
On Wed, 2018-06-06 at 15:04 +0200, Wolfgang Pfeiffer wrote:
> On Wed, Jun 06, 2018 at 01:40:59PM +0100, Patrick O'Callaghan wrote:
> > On Wed, 2018-06-06 at 14:05 +0200, Wolfgang Pfeiffer wrote:
> > >
> > > To search for reboots I'd click the "Find" menu, right hand side-bar,
> > > if Google image
On Wed, 2018-06-06 at 14:44 +0200, Wolfgang Pfeiffer wrote:
> On Wed, Jun 06, 2018 at 12:29:02AM +0100, Patrick O'Callaghan wrote:
> > On Tue, 2018-06-05 at 18:39 +0200, Wolfgang Pfeiffer wrote:
> > > And for those not so happy with tracer, there's also another tool:
> > > dnf.plugin.needs_restarti
On Wed, Jun 06, 2018 at 01:40:59PM +0100, Patrick O'Callaghan wrote:
On Wed, 2018-06-06 at 14:05 +0200, Wolfgang Pfeiffer wrote:
To search for reboots I'd click the "Find" menu, right hand side-bar,
if Google images is correct, and then search for "clean" - because
that's the word, IIRC, the
On Wed, Jun 06, 2018 at 12:29:02AM +0100, Patrick O'Callaghan wrote:
On Tue, 2018-06-05 at 18:39 +0200, Wolfgang Pfeiffer wrote:
And for those not so happy with tracer, there's also another tool:
dnf.plugin.needs_restarting ("dnf needs-restarting")
AFAIK tracer is a rewritten and expanded vers
On Wed, 2018-06-06 at 14:05 +0200, Wolfgang Pfeiffer wrote:
> On Wed, Jun 06, 2018 at 12:25:03AM +0100, Patrick O'Callaghan wrote:
> > On Tue, 2018-06-05 at 18:13 +0200, Wolfgang Pfeiffer wrote:
> > > On Mon, Jun 04, 2018 at 06:58:11PM +0100, Patrick O'Callaghan wrote:
> > >
> > > > So it tells me
On Wed, Jun 06, 2018 at 12:25:03AM +0100, Patrick O'Callaghan wrote:
On Tue, 2018-06-05 at 18:13 +0200, Wolfgang Pfeiffer wrote:
On Mon, Jun 04, 2018 at 06:58:11PM +0100, Patrick O'Callaghan wrote:
> So it tells me the Win10 guest has been resumed. However internally the
> guest will presumably
On Tue, 2018-06-05 at 18:39 +0200, Wolfgang Pfeiffer wrote:
> And for those not so happy with tracer, there's also another tool:
> dnf.plugin.needs_restarting ("dnf needs-restarting")
AFAIK tracer is a rewritten and expanded version of needs-restarting.
poc
___
On Tue, 2018-06-05 at 18:13 +0200, Wolfgang Pfeiffer wrote:
> On Mon, Jun 04, 2018 at 06:58:11PM +0100, Patrick O'Callaghan wrote:
>
> > So it tells me the Win10 guest has been resumed. However internally the
> > guest will presumably have panicked and restarted because the GPU was
> > reset by th
On Tue, Jun 05, 2018 at 06:39:35PM +0200, Wolfgang Pfeiffer wrote:
> Thanks for explaining, and to everyone else in this thread: I'll try
> to keep sticking to a reboot after larger updates, I think .. ;)
>
> And for those not so happy with tracer, there's also another tool:
> dnf.plugin.needs_re
On Sat, Jun 02, 2018 at 10:43:39PM +0100, Patrick O'Callaghan wrote:
On Sat, 2018-06-02 at 18:49 +0200, Wolfgang Pfeiffer wrote:
On Sat, Jun 02, 2018 at 09:17:36AM -0700, Samuel Sieb wrote:
> On 06/02/2018 08:44 AM, Wolfgang Pfeiffer wrote:
> > See: 2001 or so unless you had upgraded to a new gb
On Mon, Jun 04, 2018 at 06:58:11PM +0100, Patrick O'Callaghan wrote:
So it tells me the Win10 guest has been resumed. However internally the
guest will presumably have panicked and restarted because the GPU was
reset by the host reboot. (I'm not enough of a Windows user to be able
to tell when i
On Mon, 2018-06-04 at 10:21 -0700, Samuel Sieb wrote:
> On 06/04/2018 02:40 AM, Patrick O'Callaghan wrote:
> > On Sun, 2018-06-03 at 10:19 -0700, Samuel Sieb wrote:
> > > No, it's a qemu function that saves the currently used VM memory and
> > > state. You do need to have enough free disk space av
On 06/04/2018 02:40 AM, Patrick O'Callaghan wrote:
On Sun, 2018-06-03 at 10:19 -0700, Samuel Sieb wrote:
No, it's a qemu function that saves the currently used VM memory and
state. You do need to have enough free disk space available to be able
to store that. The VM OS doesn't get notified abo
On Sun, 2018-06-03 at 10:19 -0700, Samuel Sieb wrote:
> On 06/03/2018 06:37 AM, Rex Dieter wrote:
> > Robert Moskowitz wrote:
> > > On 06/03/2018 12:43 AM, Samuel Sieb wrote:
> > > > By default, libvirt and qemu will pause the VM and save it when you
> > > > reboot. On startup, it resumes from whe
On 06/03/2018 01:16 PM, Samuel Sieb wrote:
On 06/03/2018 06:29 AM, Robert Moskowitz wrote:
On 06/03/2018 12:43 AM, Samuel Sieb wrote:
By default, libvirt and qemu will pause the VM and save it when you
reboot. On startup, it resumes from where it left off.
This has NOT been my experience w
On 06/03/2018 06:37 AM, Rex Dieter wrote:
Robert Moskowitz wrote:
On 06/03/2018 12:43 AM, Samuel Sieb wrote:
By default, libvirt and qemu will pause the VM and save it when you
reboot. On startup, it resumes from where it left off.
This has NOT been my experience with my F21 image i qemu. I
On 06/03/2018 06:29 AM, Robert Moskowitz wrote:
On 06/03/2018 12:43 AM, Samuel Sieb wrote:
By default, libvirt and qemu will pause the VM and save it when you
reboot. On startup, it resumes from where it left off.
This has NOT been my experience with my F21 image i qemu. Is there some
setti
On Sun, 2018-06-03 at 08:37 -0500, Rex Dieter wrote:
> Robert Moskowitz wrote:
>
> >
> >
> > On 06/03/2018 12:43 AM, Samuel Sieb wrote:
> > > On 06/02/2018 02:28 PM, Patrick O'Callaghan wrote:
> > > > Also, I usually have a VM running (Windows 10) that I prefer not to
> > > > have to restart jus
Robert Moskowitz wrote:
>
>
> On 06/03/2018 12:43 AM, Samuel Sieb wrote:
>> On 06/02/2018 02:28 PM, Patrick O'Callaghan wrote:
>>> Also, I usually have a VM running (Windows 10) that I prefer not to
>>> have to restart just because I updated one of Linux's libraries that
>>> the VM doesn't depen
On 06/03/2018 12:43 AM, Samuel Sieb wrote:
On 06/02/2018 02:28 PM, Patrick O'Callaghan wrote:
Also, I usually have a VM running (Windows 10) that I prefer not to
have to restart just because I updated one of Linux's libraries that
the VM doesn't depend on. This might even mean restarting my de
On Sun, 2018-06-03 at 18:21 +0800, Ed Greshko wrote:
> On 06/03/18 17:57, Patrick O'Callaghan wrote:
> > On Sun, 2018-06-03 at 05:56 +0800, Ed Greshko wrote:
> > > On 06/03/18 05:43, Patrick O'Callaghan wrote:
> > > > As has been said, this is an ongoing debate. Linux follows Unix in not
> > > > fo
On 06/03/18 17:57, Patrick O'Callaghan wrote:
> On Sun, 2018-06-03 at 05:56 +0800, Ed Greshko wrote:
>> On 06/03/18 05:43, Patrick O'Callaghan wrote:
>>> As has been said, this is an ongoing debate. Linux follows Unix in not
>>> forcing you to reboot except when switching to a new kernel (though
>>
On Sun, 2018-06-03 at 05:56 +0800, Ed Greshko wrote:
> On 06/03/18 05:43, Patrick O'Callaghan wrote:
> > As has been said, this is an ongoing debate. Linux follows Unix in not
> > forcing you to reboot except when switching to a new kernel (though
> > rebooting if glibc changes is strongly encourag
On Sat, 2018-06-02 at 21:43 -0700, Samuel Sieb wrote:
> On 06/02/2018 02:28 PM, Patrick O'Callaghan wrote:
> > Also, I usually have a VM running (Windows 10) that I prefer not to
> > have to restart just because I updated one of Linux's libraries that
> > the VM doesn't depend on. This might even m
On 06/02/2018 02:28 PM, Patrick O'Callaghan wrote:
Also, I usually have a VM running (Windows 10) that I prefer not to
have to restart just because I updated one of Linux's libraries that
the VM doesn't depend on. This might even mean restarting my desktop
session, which I can do without the VM e
On 06/02/2018 12:45 AM, Samuel Sieb wrote:
On 06/01/2018 09:32 PM, John Morris wrote:
On Fri, 2018-06-01 at 11:30 -0700, Samuel Sieb wrote:
You did online updates? This is the reason why offline updates is the
default now, because doing updates without a reboot can cause weird
situations li
On 06/03/18 09:30, Tim via users wrote:
> Allegedly, on or about 3 June 2018, Ed Greshko sent:
>> Oh, and let's not forget the times (twice in recent memory) where
>> updates to KDE Plasma resulted in not being able to logout or even
>> reboot from the menus. In that case one needed to know about
Allegedly, on or about 3 June 2018, Ed Greshko sent:
> Oh, and let's not forget the times (twice in recent memory) where
> updates to KDE Plasma resulted in not being able to logout or even
> reboot from the menus. In that case one needed to know about "init
> 6". :-) :-)
While some will argue t
On 06/03/18 05:43, Patrick O'Callaghan wrote:
> As has been said, this is an ongoing debate. Linux follows Unix in not
> forcing you to reboot except when switching to a new kernel (though
> rebooting if glibc changes is strongly encouraged). Running apps will
> continue to use old libraries even w
On Sat, 2018-06-02 at 18:49 +0200, Wolfgang Pfeiffer wrote:
> On Sat, Jun 02, 2018 at 09:17:36AM -0700, Samuel Sieb wrote:
> > On 06/02/2018 08:44 AM, Wolfgang Pfeiffer wrote:
> > > See: 2001 or so unless you had upgraded to a new gblic there wasn't a
> > > need to reboot Linux machines. Most of th
On 06/02/18 23:57, Patrick O'Callaghan wrote:
> Sam seems to suggest that rebooting is the only way to be sure of
> avoiding problems. I'm wondering if he's discounting the use of tracer
> as a way to do this more selectively, and if so is it because he thinks
> tracer is unreliable?
The one thing
On Sat, 2018-06-02 at 09:17 -0700, Samuel Sieb wrote:
> On 06/02/2018 08:44 AM, Wolfgang Pfeiffer wrote:
> > See: 2001 or so unless you had upgraded to a new gblic there wasn't a
> > need to reboot Linux machines. Most of the times it was enough to log
> > in/out of your X. And that was it. And tha
On Sat, Jun 02, 2018 at 09:17:36AM -0700, Samuel Sieb wrote:
> On 06/02/2018 08:44 AM, Wolfgang Pfeiffer wrote:
> > See: 2001 or so unless you had upgraded to a new gblic there wasn't a
> > need to reboot Linux machines. Most of the times it was enough to log
> > in/out of your X. And that was it.
On 06/02/2018 08:44 AM, Wolfgang Pfeiffer wrote:
See: 2001 or so unless you had upgraded to a new gblic there wasn't a
need to reboot Linux machines. Most of the times it was enough to log
in/out of your X. And that was it. And that approach was, AFAICS, what
John Morris probably was referring to
On 06/02/2018 08:57 AM, Patrick O'Callaghan wrote:
Sam seems to suggest that rebooting is the only way to be sure of
avoiding problems. I'm wondering if he's discounting the use of tracer
as a way to do this more selectively, and if so is it because he thinks
tracer is unreliable?
It is the onl
On Sat, 2018-06-02 at 21:40 +0800, Ed Greshko wrote:
> Seriously? This discussion comes up regularly. In most cases online
> updates work, but sometimes there are issues. Read the past threads for
> more info, but it's an extremely hard problem to make it always work for
>
On Fri, Jun 01, 2018 at 09:45:50PM -0700, Samuel Sieb wrote:
> On 06/01/2018 09:32 PM, John Morris wrote:
> > On Fri, 2018-06-01 at 11:30 -0700, Samuel Sieb wrote:
> >
> > > You did online updates? This is the reason why offline updates is the
> > > default now, because doing updates without a re
On 06/02/18 21:22, Patrick O'Callaghan wrote:
> On Sat, 2018-06-02 at 20:03 +0800, Ed Greshko wrote:
>> On 06/02/18 17:09, Patrick O'Callaghan wrote:
>>> On Fri, 2018-06-01 at 21:45 -0700, Samuel Sieb wrote:
On 06/01/2018 09:32 PM, John Morris wrote:
> On Fri, 2018-06-01 at 11:30 -0700, Sa
On Sat, 2018-06-02 at 20:03 +0800, Ed Greshko wrote:
> On 06/02/18 17:09, Patrick O'Callaghan wrote:
> > On Fri, 2018-06-01 at 21:45 -0700, Samuel Sieb wrote:
> > > On 06/01/2018 09:32 PM, John Morris wrote:
> > > > On Fri, 2018-06-01 at 11:30 -0700, Samuel Sieb wrote:
> > > >
> > > > > You did on
On 06/02/18 17:09, Patrick O'Callaghan wrote:
> On Fri, 2018-06-01 at 21:45 -0700, Samuel Sieb wrote:
>> On 06/01/2018 09:32 PM, John Morris wrote:
>>> On Fri, 2018-06-01 at 11:30 -0700, Samuel Sieb wrote:
>>>
You did online updates? This is the reason why offline updates is the
default
On Fri, 2018-06-01 at 21:45 -0700, Samuel Sieb wrote:
> On 06/01/2018 09:32 PM, John Morris wrote:
> > On Fri, 2018-06-01 at 11:30 -0700, Samuel Sieb wrote:
> >
> > > You did online updates? This is the reason why offline updates is the
> > > default now, because doing updates without a reboot ca
On 06/01/2018 09:32 PM, John Morris wrote:
On Fri, 2018-06-01 at 11:30 -0700, Samuel Sieb wrote:
You did online updates? This is the reason why offline updates is the
default now, because doing updates without a reboot can cause weird
situations like this.
Ok, you maniacs finally did it, you
On Fri, 2018-06-01 at 11:30 -0700, Samuel Sieb wrote:
> You did online updates? This is the reason why offline updates is the
> default now, because doing updates without a reboot can cause weird
> situations like this.
Ok, you maniacs finally did it, you made a Linux suck as hard as
Windows.
On 06/01/2018 03:59 PM, Samuel Sieb wrote:
On 06/01/2018 11:33 AM, Robert Moskowitz wrote:
On 06/01/2018 02:30 PM, Samuel Sieb wrote:
You did online updates? This is the reason why offline updates is
the default now, because doing updates without a reboot can cause
weird situations like thi
On 06/01/2018 11:33 AM, Robert Moskowitz wrote:
On 06/01/2018 02:30 PM, Samuel Sieb wrote:
You did online updates? This is the reason why offline updates is the
default now, because doing updates without a reboot can cause weird
situations like this.
Online? Offline?
online update is what
On 06/01/2018 02:30 PM, Samuel Sieb wrote:
On 05/31/2018 08:10 PM, Robert Moskowitz wrote:
Today, with the latest batch of updates (including
selinux-policy-targeted), I could not write to a USB drive. I was
under the gun to get something out, so I rebooted and USB writing
worked.
Just a
On 05/31/2018 08:10 PM, Robert Moskowitz wrote:
Today, with the latest batch of updates (including
selinux-policy-targeted), I could not write to a USB drive. I was under
the gun to get something out, so I rebooted and USB writing worked.
Just a bit of a glitch, but an inconvenience. It take
On 06/01/2018 07:32 AM, Patrick O'Callaghan wrote:
On Thu, 2018-05-31 at 23:10 -0400, Robert Moskowitz wrote:
Yesterday, I had no problem writing to a USB device.
Today, with the latest batch of updates (including
selinux-policy-targeted), I could not write to a USB drive. I was under
the gu
On Thu, 2018-05-31 at 23:10 -0400, Robert Moskowitz wrote:
> Yesterday, I had no problem writing to a USB device.
>
> Today, with the latest batch of updates (including
> selinux-policy-targeted), I could not write to a USB drive. I was under
> the gun to get something out, so I rebooted and US
On 05/31/2018 11:46 PM, Ed Greshko wrote:
On 06/01/18 11:10, Robert Moskowitz wrote:
Yesterday, I had no problem writing to a USB device.
Today, with the latest batch of updates (including selinux-policy-targeted), I
could not write to a USB drive. I was under the gun to get something out, s
On 06/01/18 11:10, Robert Moskowitz wrote:
> Yesterday, I had no problem writing to a USB device.
>
> Today, with the latest batch of updates (including selinux-policy-targeted), I
> could not write to a USB drive. I was under the gun to get something out, so
> I
> rebooted and USB writing worked
Yesterday, I had no problem writing to a USB device.
Today, with the latest batch of updates (including
selinux-policy-targeted), I could not write to a USB drive. I was under
the gun to get something out, so I rebooted and USB writing worked.
Just a bit of a glitch, but an inconvenience. I
59 matches
Mail list logo