Packaging hints for transactional updates

classic Classic list List threaded Threaded
50 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Packaging hints for transactional updates

Thorsten Kukuk

Hi,

I started to collect issues with RPMs and transational-updates and
how to avoid them:
https://en.opensuse.org/openSUSE:Packaging_for_transactional-updates

Luckily, until now it's not much and most RPMs are fine.

  Thorsten

--
Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Packaging hints for transactional updates

Johannes Meixner

Hello Thorsten,

On Mar 20 15:06 Thorsten Kukuk wrote (excerpt):
> https://en.opensuse.org/openSUSE:Packaging_for_transactional-updates

It reads:
-------------------------------------------------------------------------
... instead of creating a snapshot, updating the current system and
rolling back if an error happened, we create a snapshot, update this
snapshot, and do a "rollback" to that snapshot if no error did occur.
-------------------------------------------------------------------------

Can you explain therein the reason behind why it is done this way
or add a link that points to an explanation?

( I have my own personal idea what the reason behind could be
but I would prefer to also know the "official" reason behind ;-)


Kind Regards
Johannes Meixner
--
SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
Graham Norton - HRB 21284 (AG Nuernberg)

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Packaging hints for transactional updates

Thorsten Kukuk
On Tue, Mar 21, Johannes Meixner wrote:

>
> Hello Thorsten,
>
> On Mar 20 15:06 Thorsten Kukuk wrote (excerpt):
> > https://en.opensuse.org/openSUSE:Packaging_for_transactional-updates
>
> It reads:
> -------------------------------------------------------------------------
> ... instead of creating a snapshot, updating the current system and
> rolling back if an error happened, we create a snapshot, update this
> snapshot, and do a "rollback" to that snapshot if no error did occur.
> -------------------------------------------------------------------------
>
> Can you explain therein the reason behind why it is done this way
> or add a link that points to an explanation?

That's explained in the very first sentences:

"Transactional updates are atomic. This means, either the update is fully
 applied without any error, or no change is made to the system. Additional,
 transactional upates should not influence the currently running processes."

If you update the running system, none of this is fullfillable.

  Thorsten

--
Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Packaging hints for transactional updates

Richard Biener
On Tue, 21 Mar 2017, Thorsten Kukuk wrote:

> On Tue, Mar 21, Johannes Meixner wrote:
>
> >
> > Hello Thorsten,
> >
> > On Mar 20 15:06 Thorsten Kukuk wrote (excerpt):
> > > https://en.opensuse.org/openSUSE:Packaging_for_transactional-updates
> >
> > It reads:
> > -------------------------------------------------------------------------
> > ... instead of creating a snapshot, updating the current system and
> > rolling back if an error happened, we create a snapshot, update this
> > snapshot, and do a "rollback" to that snapshot if no error did occur.
> > -------------------------------------------------------------------------
> >
> > Can you explain therein the reason behind why it is done this way
> > or add a link that points to an explanation?
>
> That's explained in the very first sentences:
>
> "Transactional updates are atomic. This means, either the update is fully
>  applied without any error, or no change is made to the system. Additional,
>  transactional upates should not influence the currently running processes."
>
> If you update the running system, none of this is fullfillable.

But it also means the "running system" part that is transactionally
modified should better be readonly as otherwise you lose changes
done during transaction start and commit?

Richard.

>   Thorsten
>
>

--
Richard Biener <[hidden email]>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Packaging hints for transactional updates

Thorsten Kukuk
On Tue, Mar 21, Richard Biener wrote:

> On Tue, 21 Mar 2017, Thorsten Kukuk wrote:
>
> > On Tue, Mar 21, Johannes Meixner wrote:
> >
> > >
> > > Hello Thorsten,
> > >
> > > On Mar 20 15:06 Thorsten Kukuk wrote (excerpt):
> > > > https://en.opensuse.org/openSUSE:Packaging_for_transactional-updates
> > >
> > > It reads:
> > > -------------------------------------------------------------------------
> > > ... instead of creating a snapshot, updating the current system and
> > > rolling back if an error happened, we create a snapshot, update this
> > > snapshot, and do a "rollback" to that snapshot if no error did occur.
> > > -------------------------------------------------------------------------
> > >
> > > Can you explain therein the reason behind why it is done this way
> > > or add a link that points to an explanation?
> >
> > That's explained in the very first sentences:
> >
> > "Transactional updates are atomic. This means, either the update is fully
> >  applied without any error, or no change is made to the system. Additional,
> >  transactional upates should not influence the currently running processes."
> >
> > If you update the running system, none of this is fullfillable.
>
> But it also means the "running system" part that is transactionally
> modified should better be readonly as otherwise you lose changes
> done during transaction start and commit?

If you want to be 100% safe: yes, the root filesystem should
be read-only, as we do for SUSE CaaSP for this reason.
But, if you run the transactional-update in the night with automatic
reboot, or make sure that all data is written in other subvolumes
beside the root subvolume, you are mostly safe, too.

So my openSUSE Tumbleweed installations are updated at 3 o'clock in
the night automatically and reboot if patches where successfully
applied.

But some people already think about porting the read-only root subvolume
code to Tumbleweed for transactional updates. But this will require quite
a lot of changes to existing RPMs.

  Thorsten

--
Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Packaging hints for transactional updates

Richard Biener
On Tue, 21 Mar 2017, Thorsten Kukuk wrote:

> On Tue, Mar 21, Richard Biener wrote:
>
> > On Tue, 21 Mar 2017, Thorsten Kukuk wrote:
> >
> > > On Tue, Mar 21, Johannes Meixner wrote:
> > >
> > > >
> > > > Hello Thorsten,
> > > >
> > > > On Mar 20 15:06 Thorsten Kukuk wrote (excerpt):
> > > > > https://en.opensuse.org/openSUSE:Packaging_for_transactional-updates
> > > >
> > > > It reads:
> > > > -------------------------------------------------------------------------
> > > > ... instead of creating a snapshot, updating the current system and
> > > > rolling back if an error happened, we create a snapshot, update this
> > > > snapshot, and do a "rollback" to that snapshot if no error did occur.
> > > > -------------------------------------------------------------------------
> > > >
> > > > Can you explain therein the reason behind why it is done this way
> > > > or add a link that points to an explanation?
> > >
> > > That's explained in the very first sentences:
> > >
> > > "Transactional updates are atomic. This means, either the update is fully
> > >  applied without any error, or no change is made to the system. Additional,
> > >  transactional upates should not influence the currently running processes."
> > >
> > > If you update the running system, none of this is fullfillable.
> >
> > But it also means the "running system" part that is transactionally
> > modified should better be readonly as otherwise you lose changes
> > done during transaction start and commit?
>
> If you want to be 100% safe: yes, the root filesystem should
> be read-only, as we do for SUSE CaaSP for this reason.

But I wonder if the current scheme of doing the modification in the live
system and rolling back on error works closer to 100% then (in the
case of read-write root).  Given a transaction abort should be
the minority of cases ...

> But, if you run the transactional-update in the night with automatic
> reboot, or make sure that all data is written in other subvolumes
> beside the root subvolume, you are mostly safe, too.

Doesn't sound like "no changes to the running system" to me then ;)

> So my openSUSE Tumbleweed installations are updated at 3 o'clock in
> the night automatically and reboot if patches where successfully
> applied.
>
> But some people already think about porting the read-only root subvolume
> code to Tumbleweed for transactional updates. But this will require quite
> a lot of changes to existing RPMs.

So what issue are we solving then?  That is, is this for CaaSP only
where we can guarantee the r/o root?

Richard.

--
Richard Biener <[hidden email]>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Packaging hints for transactional updates

Thorsten Kukuk
On Tue, Mar 21, Richard Biener wrote:

> So what issue are we solving then?  That is, is this for CaaSP only
> where we can guarantee the r/o root?

The problems we want to solve are all the broken systems you can
regular read on the factory list about after an update, because the
update in the running system did break other running processes.
Especially the Desktop.

  Thorsten

--
Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Packaging hints for transactional updates

Richard Biener
On Tue, 21 Mar 2017, Thorsten Kukuk wrote:

> On Tue, Mar 21, Richard Biener wrote:
>
> > So what issue are we solving then?  That is, is this for CaaSP only
> > where we can guarantee the r/o root?
>
> The problems we want to solve are all the broken systems you can
> regular read on the factory list about after an update, because the
> update in the running system did break other running processes.
> Especially the Desktop.

Sure.  But do we now exchange this for all the broken systems where
replacing root with the snapshot after the transaction?  And are we
sure the number of broken systems will actually shrink with this
change?  (and can you prove that?)

Richard.

>   Thorsten
>
>

--
Richard Biener <[hidden email]>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Packaging hints for transactional updates

Thorsten Kukuk
On Tue, Mar 21, Richard Biener wrote:

> On Tue, 21 Mar 2017, Thorsten Kukuk wrote:
>
> > On Tue, Mar 21, Richard Biener wrote:
> >
> > > So what issue are we solving then?  That is, is this for CaaSP only
> > > where we can guarantee the r/o root?
> >
> > The problems we want to solve are all the broken systems you can
> > regular read on the factory list about after an update, because the
> > update in the running system did break other running processes.
> > Especially the Desktop.
>
> Sure.  But do we now exchange this for all the broken systems where
> replacing root with the snapshot after the transaction?  And are we
> sure the number of broken systems will actually shrink with this
> change?  (and can you prove that?)

Sorry, but I neither understand what you are writing here nor what
your problem is.

What I can prove is: all the problems the people had with updates,
that their running applications did crash and the update did not
finish and their system were left over in a unbootable state can
be solved with this.
And about your fear about that the snapshot is in a broken state
after update even if zypper did not return any error: if this happens,
this would also happen with your normal running system. It does not
matter if you update a snapshot or the real system, the installed RPMs
are the same.

And, don't forget: if you don't like transactional updates, nobody is
forcing you to use them.

  Thorsten

--
Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Packaging hints for transactional updates

Dominique Leuenberger / DimStar
In reply to this post by Richard Biener
On Tue, 2017-03-21 at 15:45 +0100, Richard Biener wrote:
>
> Sure.  But do we now exchange this for all the broken systems where
> replacing root with the snapshot after the transaction?  And are we
> sure the number of broken systems will actually shrink with this
> change?  (and can you prove that?)

That question implies to never dare testing a different approach than
what is currently in use - as you will not be able to guarantee that a
new idea as such works better than the old way of doing things without
testing it.

So far, nobody said that TW will be switching hard to transactional
updates - but having the option available and being able to gain
experiences is certainly a nice thing to have

Cheers,
Dominique
--
Dimstar / Dominique Leuenberger <[hidden email]>

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Packaging hints for transactional updates

Richard Biener
In reply to this post by Thorsten Kukuk
On Tue, 21 Mar 2017, Thorsten Kukuk wrote:

> On Tue, Mar 21, Richard Biener wrote:
>
> > On Tue, 21 Mar 2017, Thorsten Kukuk wrote:
> >
> > > On Tue, Mar 21, Richard Biener wrote:
> > >
> > > > So what issue are we solving then?  That is, is this for CaaSP only
> > > > where we can guarantee the r/o root?
> > >
> > > The problems we want to solve are all the broken systems you can
> > > regular read on the factory list about after an update, because the
> > > update in the running system did break other running processes.
> > > Especially the Desktop.
> >
> > Sure.  But do we now exchange this for all the broken systems where
> > replacing root with the snapshot after the transaction?  And are we
> > sure the number of broken systems will actually shrink with this
> > change?  (and can you prove that?)
>
> Sorry, but I neither understand what you are writing here nor what
> your problem is.
>
> What I can prove is: all the problems the people had with updates,
> that their running applications did crash and the update did not
> finish and their system were left over in a unbootable state can
> be solved with this.

True - this is because you are not updating the running system but
the one that is activated after the next reboot (as far as I understand).

> And about your fear about that the snapshot is in a broken state
> after update even if zypper did not return any error: if this happens,
> this would also happen with your normal running system. It does not
> matter if you update a snapshot or the real system, the installed RPMs
> are the same.

No, I am refering to the time window between creating the snapshot
and activating it.  For a true transaction you'd need to verify
the root you are about to replace with the updated snapshot is in
the same state as at the time of snapshot creation (thus, it had
better be readonly).  Otherwise you are losing data.

> And, don't forget: if you don't like transactional updates, nobody is
> forcing you to use them.

Of course.

But the system you are implementing sounds a more dangerous way of
effectively downloading the update in the running system, rebooting,
and at defined state (say, in initrd context) create the snapshot,
install into it and continue booting from it.

_Without_ the issue of that inconsistency due to the time window
the root is active between creating the snapshot and activating it.

Richard.

>   Thorsten
>
>

--
Richard Biener <[hidden email]>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Packaging hints for transactional updates

Thorsten Kukuk
On Tue, Mar 21, Richard Biener wrote:

> No, I am refering to the time window between creating the snapshot
> and activating it.  For a true transaction you'd need to verify
> the root you are about to replace with the updated snapshot is in
> the same state as at the time of snapshot creation (thus, it had
> better be readonly).  Otherwise you are losing data.

If you clearly seperate data from applications, as you have to do
for snapshot and rollback anyways, the risk is really very low.
And if you use a read-only root filesystem, the risk is zero.
But this are not only problems with transactional updates, you have
the same problems already today if you use rollback. And there the
risk of data lossage is much, much higher.

> But the system you are implementing sounds a more dangerous way of
> effectively downloading the update in the running system, rebooting,
> and at defined state (say, in initrd context) create the snapshot,
> install into it and continue booting from it.

That's how Windows is doing it and GNOME tries to implement it.
You should watch my presentation at Fosdem this year, which negativ
impact this already had in the past.

  Thorsten

--
Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Packaging hints for transactional updates

Michael Matz
Hi,

On Tue, 21 Mar 2017, Thorsten Kukuk wrote:

> If you clearly seperate data from applications, as you have to do
> for snapshot and rollback anyways, the risk is really very low.
> And if you use a read-only root filesystem, the risk is zero.
> But this are not only problems with transactional updates, you have
> the same problems already today if you use rollback. And there the
> risk of data lossage is much, much higher.

But a rollback always implies data-loss (namely all the data written
since).  That's known by people (at least by those that have some mental
concept of "transactional").  Data-loss by activation of an update is
surprising.

What happens e.g. in this situation:

% user installs update
% user installs more updates
% user adds repo and installs a new rpm foo
% user reboots (because finally he's annoyed by the warning of having to
  reboot)

foo is gone from the rebooted system, right (except of course for the
desktop item for that program, now pointing to a dead file, which is even
more surprising)?  Are at least updates 1 and 2 merged?

> > But the system you are implementing sounds a more dangerous way of
> > effectively downloading the update in the running system, rebooting,
> > and at defined state (say, in initrd context) create the snapshot,
> > install into it and continue booting from it.
>
> That's how Windows is doing it and GNOME tries to implement it.

But the way Windows does it (I don't know about GNOME) is definitely more
like a proper transaction than installing into a snapshot and just
activating it at next reboot over whatever was there before.  That's not
transactional at all because the abort-transaction with concurrent writes
is missing.

> You should watch my presentation at Fosdem this year, which negativ
> impact this already had in the past.

Perhaps, are the slides somewhere?


Ciao,
Michael.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Packaging hints for transactional updates

Michael Matz
In reply to this post by Dominique Leuenberger / DimStar
Hi,

On Tue, 21 Mar 2017, Dimstar / Dominique Leuenberger wrote:

> On Tue, 2017-03-21 at 15:45 +0100, Richard Biener wrote:
> >
> > Sure.  But do we now exchange this for all the broken systems where
> > replacing root with the snapshot after the transaction?  And are we
> > sure the number of broken systems will actually shrink with this
> > change?  (and can you prove that?)
>
> That question implies to never dare testing a different approach than
> what is currently in use - as you will not be able to guarantee that a
> new idea as such works better than the old way of doing things without
> testing it.
Well, but it must at least be sound if it causes work for others, right?
So, proving might be a bit too harsh indeed, but the transactional updates
(at least as I understand them right now) seem a bit dubious in that they
replace a certain set of problem with other (IMHO worse) problems.

How many of the problems solved by transactional updates are actually
solved by the required reboot (or could be solved by that alone), and not
by the installing-into-snapshot aspect?


Ciao,
Michael.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Packaging hints for transactional updates

Thorsten Kukuk
In reply to this post by Michael Matz
On Tue, Mar 21, Michael Matz wrote:

> Hi,
>
> On Tue, 21 Mar 2017, Thorsten Kukuk wrote:
>
> > If you clearly seperate data from applications, as you have to do
> > for snapshot and rollback anyways, the risk is really very low.
> > And if you use a read-only root filesystem, the risk is zero.
> > But this are not only problems with transactional updates, you have
> > the same problems already today if you use rollback. And there the
> > risk of data lossage is much, much higher.
>
> But a rollback always implies data-loss (namely all the data written
> since).  That's known by people (at least by those that have some mental
> concept of "transactional").  Data-loss by activation of an update is
> surprising.
>
> What happens e.g. in this situation:
>
> % user installs update
> % user installs more updates
> % user adds repo and installs a new rpm foo
> % user reboots (because finally he's annoyed by the warning of having to
>   reboot)
>
> foo is gone from the rebooted system, right (except of course for the
> desktop item for that program, now pointing to a dead file, which is even
> more surprising)?  Are at least updates 1 and 2 merged?

Nothing happend and foo is there, if the user only uses the
transactional-update script and not a mix of different tools.

> But the way Windows does it (I don't know about GNOME) is definitely more
> like a proper transaction than installing into a snapshot and just
> activating it at next reboot over whatever was there before.  That's not
> transactional at all because the abort-transaction with concurrent writes
> is missing.

Sorry, but exactly the other way around is true. Windows is not doing
any transaction at all. If your system breaks, it's broken.
What Windows calls "transaction" in this case is only what is written
into the windows registry, not on harddisk.

> Perhaps, are the slides somewhere?

Yes, in the Fosdem archive.

  Thorsten
--
Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Packaging hints for transactional updates

Dominique Leuenberger / DimStar
In reply to this post by Michael Matz
On Tue, 2017-03-21 at 16:28 +0100, Michael Matz wrote:

> That question implies to never dare testing a different approach
> > than
> > what is currently in use - as you will not be able to guarantee
> > that a
> > new idea as such works better than the old way of doing things
> > without
> > testing it.
>
> Well, but it must at least be sound if it causes work for others,
> right? 
> So, proving might be a bit too harsh indeed, but the transactional
> updates 
> (at least as I understand them right now) seem a bit dubious in that
> they 
> replace a certain set of problem with other (IMHO worse) problems.
Don't get me wrong: I like the fact that people DISCUSS about the
solution and potential issues they see. And I'm sure Thorsten agrees on
that too. Just don't always phrase everything in a way stating that all
the new stuff just is more broken than all the old broken stuff.

> How many of the problems solved by transactional updates are
> actually 
> solved by the required reboot (or could be solved by that alone), and
> not 
> by the installing-into-snapshot aspect?

Updating a system is a tricky thing. We have been using zypper dup from
within a running session for a long time now, with the chance to
rollback when it fails. Every so often users complain the session
crashed halfway leaving them in a bad place.

GNOME upstream tries to eliminate this by downloading all the updates
to the local cache, reboot the machine to a minimal running system,
update all the packages and reboot the system into a working system
(unlike Windows, though, it does NOT tell you when you have to do it:
you actively click on 'reboot and update' from within GNOME Software or
 select the checkbox 'perform updates on next boot' when you
reboot/shutdown your system) - of course everybody complains that
booting to apply updates is not what we are used to do on Unix/Linux,
and if you understand the setup well enough, you can actually judge on
it - most 'users' I tend to talk to would not know how to get started.

Transactional Updates does a similar thing, from the other angle:
update a snapshot that you will boot to once the update is complete. Of
course, just like GNOME's approach, it also requires you to reboot the
system. And in plus it requires a very strict separation of program
files managed by the package manager from the data part (as would be
the case with rollback).

I'm not yet sure if any of the methods being implemented / tested at
this moment will give us ALL solutions to all problems... but exploring
the options is certainly the way to go. No shame in admitting at one
point 'oh well, that did not work out as expected - but we learned this
and that about the problem'

Cheers,
Dominique

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Packaging hints for transactional updates

Michael Matz
In reply to this post by Thorsten Kukuk
Hi,

On Tue, 21 Mar 2017, Thorsten Kukuk wrote:

> > What happens e.g. in this situation:
> >
> > % user installs update
> > % user installs more updates
> > % user adds repo and installs a new rpm foo
> > % user reboots (because finally he's annoyed by the warning of having to
> >   reboot)
> >
> > foo is gone from the rebooted system, right (except of course for the
> > desktop item for that program, now pointing to a dead file, which is even
> > more surprising)?  Are at least updates 1 and 2 merged?
>
> Nothing happend and foo is there, if the user only uses the
> transactional-update script and not a mix of different tools.

That's nice.  Is zypper for installing the rpm at above third step a
different tool for these purposes (and does it mean that the rpm is
installed twice, once into the used-after-reboot snapshot, and once into
the currently used one?)

> > But the way Windows does it (I don't know about GNOME) is definitely more
> > like a proper transaction than installing into a snapshot and just
> > activating it at next reboot over whatever was there before.  That's not
> > transactional at all because the abort-transaction with concurrent writes
> > is missing.
>
> Sorry, but exactly the other way around is true. Windows is not doing
> any transaction at all. If your system breaks, it's broken.
> What Windows calls "transaction" in this case is only what is written
> into the windows registry, not on harddisk.

Um.  I'm not sure how to say this, but you do know that NTFS provides
snapshots as well and Windows makes use of them for update purposes much
similar to our rollback scenario with btrfs?  And as the kernel-related
updates for it are installed at points where there are definitely no other
writers, namely at shutdown or bootup, yes, that is actually transactional
(or at least more so, all this talk about "transactional" related to
updates and filesystems is a bit dodgy as it's quite a bit unlike
transactions in the database sense).  That this is done in Windows had
initially different reasons, but now the side-effect is that the updates
are safe from concurrent writes. (that would be comparable to us
installing the updates from initrd just after mounting the FSes)

> > Perhaps, are the slides somewhere?
>
> Yes, in the Fosdem archive.

Looking.  I'm still hoping I have some basic misunderstanding of the whole
"transactional" updates idea.


Ciao,
Michael.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Packaging hints for transactional updates

Thorsten Kukuk
On Tue, Mar 21, Michael Matz wrote:

> Um.  I'm not sure how to say this, but you do know that NTFS provides
> snapshots as well and Windows makes use of them for update purposes much
> similar to our rollback scenario with btrfs?

If it is used for Windows Updates it does not work in practice, else the
windows installation on my laptop wouldn't go in a corrupt state
unrepairable by Windows by an update.
And only wikipedia assumes that the Windows Update is using it, Microsoft
itself is not mentioning it.
Ah, wait, yes, Windows can do a rollback and Microsoft explains it, but
at first you need to get the current broken state booting to start the
GUI to do the rollback ...
If there are other ways, MS is hiding them well in their documentation.

  Thorsten

--
Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Packaging hints for transactional updates

Michael Matz
In reply to this post by Dominique Leuenberger / DimStar
Hi,

On Tue, 21 Mar 2017, Dimstar / Dominique Leuenberger wrote:

> Don't get me wrong: I like the fact that people DISCUSS about the
> solution and potential issues they see. And I'm sure Thorsten agrees on
> that too. Just don't always phrase everything in a way stating that all
> the new stuff just is more broken than all the old broken stuff.

Well, I'll try, but unfortunately I think this is actually the case :-/

> GNOME upstream tries to eliminate this by downloading all the updates
> to the local cache, reboot the machine to a minimal running system,
> update all the packages and reboot the system into a working system
> (unlike Windows, though, it does NOT tell you when you have to do it:
> you actively click on 'reboot and update' from within GNOME Software or
>  select the checkbox 'perform updates on next boot' when you
> reboot/shutdown your system) - of course everybody complains that
> booting to apply updates is not what we are used to do on Unix/Linux,
> and if you understand the setup well enough, you can actually judge on
> it - most 'users' I tend to talk to would not know how to get started.
>
> Transactional Updates does a similar thing, from the other angle:
> update a snapshot that you will boot to once the update is complete. Of
> course, just like GNOME's approach, it also requires you to reboot the
> system. And in plus it requires a very strict separation of program
> files managed by the package manager from the data part (as would be
> the case with rollback).

So, from the reboot-is-necessary aspect, both are equivalent.  People will
either dislike this or not, but the same for both.  Also the time for the
activation of new stuff is the same (at reboot).  So the difference is
only how the new bytes becomes activated.  With initrd/Windows/GNOME
approach: installed on top of whatever was there at reboot time;
transactional-updates: _replacing_ whatever was there at reboot time with
whatever was there at reboot-time minus $arbitrary_time plus updates.

I mean, it seems so very obvious to me that the latter is the worse of the
two.

> I'm not yet sure if any of the methods being implemented / tested at
> this moment will give us ALL solutions to all problems... but exploring
> the options is certainly the way to go. No shame in admitting at one
> point 'oh well, that did not work out as expected - but we learned this
> and that about the problem'

Fair enough.  Experiments certainly will provide real knowledge instead of
mere arguments :)


Ciao,
Michael.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Packaging hints for transactional updates

Thorsten Kukuk
In reply to this post by Michael Matz
On Tue, Mar 21, Michael Matz wrote:

> Well, but it must at least be sound if it causes work for others, right?

It does not. The work for transactional updates is the same as for
snapshots and rollback. This is the nice idea behind it.

  Thorsten

--
Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

123
Loading...