On Mittwoch, 19. Oktober 2016 14:53:29 CEST Roger Oberholtzer wrote:

On 10/19/2016 08:11 AM, Constant Brouerius van Nidek wrote:

...

...

I regret that zypper is not able to recognize when an update will run info space problems. Tumbleweed is installed on my sdc3 on a 35 Gib partition. sdc 1and 2 (40 Gib) have been cleaned and could be used by Tumbleweed.

Somebody an idea how to solve my actual problem?

When this has happened to me, I cleared the download cache (zypper cc). This should remove all the downloaded updates that are taking disk space.

Note that early Tumbleweed (in its current incarnation as a rolling distro) missed to set up /var/cache (and thus /var/cache/zypp/packages) as a seperate subvolume. Any downloaded packages ended up in the snapshot. A new installation has this fixed, an updated installation may be affected. You can check this yourself: $> mount | grep /var/cache If this yields a subvolume, you are fine, otherwise see https://features.opensuse.org/320834 Kind regards, Stefan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Oct 19, 2016 at 9:06 AM, Brüns, Stefan wrote:

Note that early Tumbleweed (in its current incarnation as a rolling distro) missed to set up /var/cache (and thus /var/cache/zypp/packages) as a seperate subvolume.

[...]

A new installation has this fixed, an updated installation may be affected.

Is there an easy way to fix this if one has been using Tumbleweed for a long time? --cro -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

19.10.2016 19:21, Brüns, Stefan пишет:

On Mittwoch, 19. Oktober 2016 09:41:09 CEST C. R. Oldham wrote:

...

On Wed, Oct 19, 2016 at 9:06 AM, Brüns, Stefan

wrote:

...

Note that early Tumbleweed (in its current incarnation as a rolling distro) missed to set up /var/cache (and thus /var/cache/zypp/packages) as a seperate subvolume.

[...]

...

A new installation has this fixed, an updated installation may be affected.

Is there an easy way to fix this if one has been using Tumbleweed for a long time?

You could have followed the link I provided and you removed from the quotes ...

... which says "There must be some steps wrongly documented or omitted." :p

It states the same as what can be found in the SLES 12 SP2 release notes: https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12-SP2/#fate-320834

I do not have @ subvolume. OK, I do know how to do it without this link anyway, but still this link won't help those users who happened to install TW when @ was not created and who are not deep in btrfs. And BTW I just was about to do "mv /var/cache/* /mnt/var/cache" when I looked ad pkmon output ... it should better suggest doing it in single user to be sure /var/cache is not being updated. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

19.10.2016 19:59, Brüns, Stefan пишет:

On Mittwoch, 19. Oktober 2016 19:47:05 CEST Andrei Borzenkov wrote:

...

19.10.2016 19:21, Brüns, Stefan пишет:

...

On Mittwoch, 19. Oktober 2016 09:41:09 CEST C. R. Oldham wrote:

...

On Wed, Oct 19, 2016 at 9:06 AM, Brüns, Stefan

wrote:

...

Note that early Tumbleweed (in its current incarnation as a rolling distro) missed to set up /var/cache (and thus /var/cache/zypp/packages) as a seperate subvolume.

[...]

...

A new installation has this fixed, an updated installation may be affected.

Is there an easy way to fix this if one has been using Tumbleweed for a long time?

You could have followed the link I provided and you removed from the quotes ...

... which says "There must be some steps wrongly documented or omitted." :p

...

It states the same as what can be found in the SLES 12 SP2 release notes: https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12-SP2/#fate-320834

I do not have @ subvolume. OK, I do know how to do it without this link anyway, but still this link won't help those users who happened to install TW when @ was not created and who are not deep in btrfs.

Did you really read the text?

Yes, but you are right.

The text *clearly* states what to do, for both cases (@ subvolume available or not). It is a step by step guide, read it, follow it, done.

Yes, I skimmed over. Sorry.

Kind regards,

Stefan

N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩrg==

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Dominique Leuenberger / DimStar skreiv 19. okt. 2016 19:02:

Or, as we care for openSUSE and not SLE, the Leap 42.2 release notes contain the instructions too:

https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/42.2/

Even with the distinction if you have a "@" subvolume or not...

I have tried to follow this step-by-step instruction, and steps 1–8 worked well (i.e. no error messages), but step 9 says: Add an entry to /etc/fstab for the new /var/cache subvolume. Use an existing subvolume as a template to copy from. However, I do not *have* any existing subvolume entires to use as templates. Can anyone paste an example subvolume entry? For the record, the entry for my root partition looks like this: LABEL=myroot / btrfs compress,space_cache,ssd 0 0 (Yes, I prefer using a label instead of the UUID.) -- Karl Ove Hufthammer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Chan Ju Ping skreiv 20. okt. 2016 04:20:

On Wednesday, October 19, 2016 10:08:59 PM CDT Karl Ove Hufthammer wrote:

...

However, I do not *have* any existing subvolume entires to use as templates. Can anyone paste an example subvolume entry?

For the record, the entry for my root partition looks like this:

LABEL=myroot / btrfs compress,space_cache,ssd 0 0

(Yes, I prefer using a label instead of the UUID.)

Here's an example of a subvolume from my /etc/fstab:

UUID=1dd67662-3768-4ad2-90a2-1e9c6cc11239 /var/tmp btrfs subvol=var/tmp 0 0

Which I changed to:

UUID=1dd67662-3768-4ad2-90a2-1e9c6cc11239 /var/cache btrfs subvol=var/cache 0 0

Hopefully that's the right way about it.

Thank you. It seems to have worked. -- Karl Ove Hufthammer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Oct 20, 2016 at 10:45 AM, Johannes Meixner wrote:

Hello,

On Oct 19 19:02 Dominique Leuenberger / DimStar wrote (excerpt):

...

On Wed, 2016-10-19 at 16:21 +0000, Brüns, Stefan wrote:

...

https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12-SP2/#fate-32083 4

\

Or, as we care for openSUSE and not SLE, the Leap 42.2 release notes contain the instructions too:

https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/42.2/

Even with the distinction if you have a "@" subvolume or not...

I did not investigate that instructions in detail but on first glance it looks rather complicated.

In particular I wonder why /usr/sbin/mksubvolume is not used to create such subvolumes in compliance with our SLE12, Leap, and Tumbleweed default btrfs subvolume structures?

Well, this structure was a *proposal* so far and user is completely free to refuse it and chose its own scheme, not? So you cannot assume every subvolume proposed by default during installation exists. OTOH when /var/cache is proposed as separate volume, good chances are user will keep it; but if it was not proposed in the first place user likely would not think about adding it. So instructions how to add single volume are still useful. Also this is not limited to /var/cache. User may opt out mysql subvolume during installation because no mySQL was originally installed but may opt to install it later. What should happen in this case? It would be good to have at least some reminder about possible problems when leaving database on root btrfs subvolume ...

Cf. https://lists.opensuse.org/opensuse-factory/2016-10/msg00397.html

I think more and more issues indicate that (open)SUSE really needs an "official" tool that can create and remove btrfs subvolumes in full compliance with our various kind of default btrfs subvolume structures on SLE12, Leap, and Tumbleweed, cf. https://lists.opensuse.org/opensuse-factory/2016-10/msg00434.html

Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi ! I'm interested in the config features below, so I tried DownloadInHeaps, which seemed very interesting and a good compromise, but it downloaded everything in advance. I would expect some independent "heaps" to be downloaded and installed separately like Plasma on one side, KDE Apps on the other... I even had an Owncloud update coming from another repo, I would have expected it to be a separate "heap". Is there something I'm missing? DownloadAsNeeded work as expected however (without file conflict check, which is expected). Cheers, Pierre

There are two ways to run 'zypper up/dup'

The first is to download *ALL* the RPMs, then step though them one by one doing the install, the remove them, freeing up that space.

Obviously you need to have enough space not only to download all that but to handle any growth.

As you can see from the config file, the download is into /var, which is one reason I've suggested that this is put on a different FS from the RootFS. I'm really allergic to the BtrFS "One filesystem to rule them all" attitude.

The second, which you can arrange by an entry in the config file (where else?).

The config file says

## Commit download policy to use as default. ## ## DownloadOnly, Just download all packages to the local cache. ## Do not install. Implies a dry-run. ## ## DownloadInAdvance, First download all packages to the local cache. ## Then start to install. ## ## DownloadInHeaps, Similar to DownloadInAdvance, but try to split ## the transaction into heaps, where at the end of ## each heap a consistent system state is reached. ## ## DownloadAsNeeded Alternating download and install. Packages are ## cached just to avid CD/DVD hopping. This is the ## traditional behaviour. ## ## <UNSET> If a value is not set, empty or unknown, we pick ## some sane default.

Now you'll probably notice that the install/default is to have it unset and you'll says that because of what you encountered its "not sane". I agree.

The real default seems to be "DownloadInAdvance". Hence your Big OUCH.

Traditional or not, you need to explicitly set

commit.downloadMode = DownloadAsNeeded

There's probably some way to do that on the command line if you want to pour over the man page in detail.

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

OK. Shame, that would be most helpful for TW large updates! Le jeudi 20 octobre 2016, 11:12:50 NZDT Carlos E. R. a écrit :

On 2016-10-20 04:51, Pierre de Villemereuil wrote:

...

Hi !

I'm interested in the config features below, so I tried DownloadInHeaps, which seemed very interesting and a good compromise, but it downloaded everything in advance. I would expect some independent "heaps" to be downloaded and installed separately like Plasma on one side, KDE Apps on the other... I even had an Owncloud update coming from another repo, I would have expected it to be a separate "heap".

Is there something I'm missing?

Zypper supports heaps, but no "heaps" are defined, AFAIK.

-- Cheers / Saludos,

Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 10/21/2016 07:28 AM, Ladislav Slezak wrote:

Dne 21.10.2016 v 08:26 Pierre de Villemereuil napsal(a):

...

...

Zypper supports heaps, but no "heaps" are defined, AFAIK.

No, see this snippet from the /etc/zypp/zypp.conf file:

## DownloadInHeaps, Similar to DownloadInAdvance, but try to split ## the transaction into heaps, where at the end of ## each heap a consistent system state is reached.

So if you need to update some core package (e.g. glibc) then the result might be that you need to update *all* packages at once because you might not be able to split the package updates into consistent heaps.

But the core problem is that libzypp does not implement the "DownloadInHeaps" mode fully, currently is supports only a single heap which means it behaves just like the "DownloadInAdvance" mode.

That's why I suggest ## DownloadAsNeeded Alternating download and install. Packages are ## cached just to avid CD/DVD hopping. This is the ## traditional behaviour. -- My definition of an expert in any field is a person who knows enough about what's really going on to be scared. P. J. Plauger, Computer Language, March 1983 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 10/21/2016 07:47 AM, Carlos E. R. wrote:

On 2016-10-21 13:33, Anton Aylward wrote:

...

That's why I suggest

## DownloadAsNeeded Alternating download and install. Packages are ## cached just to avid CD/DVD hopping. This is the ## traditional behaviour.

Problematic if network fails.

I very much disagree. BTDT. All modes have /some/ hypothetical failure mode. The one we are discussing here concerns 'out of space'. That seems to arise as a emergent property of using BtrFS and particular scope and lack of purging of snapshots. Other's have suggested ways of working with BtrFS. My way was to disable snapshots. I also have /var as a separate, no BtrFS, file system, so as to avoid this issue. Not that I'm short of space on either RootFS or /var, you understand :-) There's not just one one way of solving many problems. As it is, this step-and-repeat method makes the trade-off of reducing space demand. Tht's one pososble solution for the OP. As it happens, zypper re-orders the sequence of installs according to a dependency tree. -- inoculatte (v): To take coffee intravenously when you are running late. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org