classic mode (v1)

Gustavo Niemeyer gustavo.niemeyer at
Tue Nov 24 15:15:01 UTC 2015

Hi Martin,

On Tue, Nov 24, 2015 at 11:58 AM, Martin Pitt <martin.pitt at>
> I actually promised myself to not point this out for the umpteenth
> time, but it seems the conversation on the gdoc stopped.

Sorry for making you come back onto this issue again. There might be
information we're lacking, so your participation is appreciated here.

> Michael Vogt [2015-11-23 17:48 +0100]:
> > We implement the classic mode as a writable overlay.
> I *strongly* recommend to not do this. We have dozens of bug reports
> of packages misbehaving on overlayfs; a particularly nasty case are
> packages that fail to upgrade/install on overlayfs, which is an use
> case which is relevant in the classic env (but not on a live system).

Do we know which specific packages are broken and what causes these
failures, so we can have a more clear idea of where the line between
working and non-working is?

It also degrades performance, causes stat() to misbehave (as the
> overlaying is leaked left and right into userspace, so e. g.
> "mountpoint" fails), and after a few rounds of dist-upgrades you still
> have the original old file system which is then just wasting disk
> space.

In which way does stat misbehave, and do you have an idea of how the
upstream feels about those issues so we can have a more informed view on
the case?

All this for saving a few seconds of time for the initial setup seems
> like an unacceptable trade-off to me..

All of this to have a snap that works similar to every other snap, and
takes no setup time the first time and every other time the snap is

> It seems like we have the following options:
> >
> > 1) Once ubuntu-classic is installed the snap can never be updated, but
> >    the *content* of the snap can be updated, i.e. you can keep your
> >    classic environment up-to-date via "sudo apt full-upgrade" (or we
> >    could even do it automatically via unattended-upgrades).
> See above, dist-upgrading is not reliable, and it's rather fiddly to
> fix the chroot after such a failure happened; this rules out
> unattended-upgrades.

It'd be nice to understand what is broken there.

> 2) All system level changes (like additionally installed packages in
> >    ubuntu-classic) are lost on each snap update.
> How would that be? As soon as you e. g. upgrade a deb, it's in the
> overlay, and if you change the same file in the underlay, that change

Both Michael and myself have stated in this thread we're not changing the
underlay and the overlay independently.

> 3) All system level changes are not persistent and you get a fresh
> >    overlay each time snappy shell ubuntu-classic is run.
> That's a practical option -- it avoids having to dist-upgrade manually

That's not much different than option 2. The question is just when to reset.

So this is essentially a question whether you want a schroot-like
experience or a real classic Ubuntu-like experience where you can
> install your favourite editor, debuggers, tools, etc. without having
> to reinstall and reconfigure it from scratch every time you use it.

Well, it's really a blend of the two, but perhaps more like a schroot. You
are playing in an environment inside another one, with consequences for how
systemd, devices, etc, behave. At the same time, we do want people to
install editors, debuggers, tools, etc, but people do that in schroots as

gustavo @
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the snappy-devel mailing list