[opensuse-factory] Tumbleweed snapshot 20161006, system ran out of space
The 1499 files for the update where neatly downloaded but at installing time the system ran out of space after finishing 682 files. Hereunder the message. A repeat zypper dup resulted with an for me unintellegable message. In the past I remember being able to enlarge he ext4 extensions with Partition Magic but in this case I am working with btrfs filesystem which is not yet recognized by the Partition Magic i have here. 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? Thanks in advance Constant ============================================================= ( 680/1499) Installing: wireless- tools-30.pre9-37.8.x86_64......................................[done] ( 681/1499) Installing: thin-provisioning- tools-0.6.3-1.3.x86_64...............................................[done] ( 682/1499) Installing: python3-base-3.5.1-3.6.x86_64................[done] ( 683/1499) Installing: python-base-2.7.12-1.3.x86_64................[error] Installation of python-base-2.7.12-1.3.x86_64 failed: Error: Subprocess failed. Error: RPM failed: installing package python- base-2.7.12-1.3.x86_64 needs 19MB on the / filesystem Abort, retry, ignore? [a/r/i] (a): a Warning: %posttrans scripts skipped while aborting: xfsprogs-4.5.0-1.5.x86_64.rpm thin-provisioning-tools-0.6.3-1.3.x86_64.rpm Problem occured during or after installation or removal of packages: Installation aborted by user Please see the above error message for a hint. dhcppc2:/home/constant # zypper -n -vvv dup Verbosity: 3 Entering non-interactive mode. Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. Initializing Target Target initialization failed: Failed to cache rpm database (1). History: - 'rpmdb2solv' '-r' '/' '-X' '-A' '-p' '/etc/products.d' '/var/cache/zypp/ solv/@System/solv' '-o' '/var/cache/zypp/solv/@System/solvRy20bw' repo_write failed ==- opensuse:tumbleweed:20161013 Qt: 5.7.0 KDE Frameworks: 5.26.0 kf5-config: 1.0 KDE Plasma: 5.8.0 Kernel: 4.7.6-1-default Linux User 183145 working on a Pentium IV . -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Constant Brouerius van Nidek <cbroueriusvannidek@gmail.com> [10-19-16 08:13]:
The 1499 files for the update where neatly downloaded but at installing time the system ran out of space after finishing 682 files. Hereunder the message. A repeat zypper dup resulted with an for me unintellegable message. In the past I remember being able to enlarge he ext4 extensions with Partition Magic but in this case I am working with btrfs filesystem which is not yet recognized by the Partition Magic i have here.
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? Thanks in advance
add space or remove unnecessary files/apps, hint: older log files and/or clean tmp. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Dne středa 19. října 2016 19:11:36 CEST, Constant Brouerius van Nidek napsal(a):
The 1499 files for the update where neatly downloaded but at installing time the system ran out of space after finishing 682 files. Hereunder the message. A repeat zypper dup resulted with an for me unintellegable message. In the past I remember being able to enlarge he ext4 extensions with Partition Magic but in this case I am working with btrfs filesystem which is not yet recognized by the Partition Magic i have here.
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? Thanks in advance
Constant
============================================================= ( 680/1499) Installing: wireless- tools-30.pre9-37.8.x86_64......................................[done] ( 681/1499) Installing: thin-provisioning- tools-0.6.3-1.3.x86_64...............................................[done] ( 682/1499) Installing: python3-base-3.5.1-3.6.x86_64................[done] ( 683/1499) Installing: python-base-2.7.12-1.3.x86_64................[error] Installation of python-base-2.7.12-1.3.x86_64 failed: Error: Subprocess failed. Error: RPM failed: installing package python- base-2.7.12-1.3.x86_64 needs 19MB on the / filesystem
Abort, retry, ignore? [a/r/i] (a): a Warning: %posttrans scripts skipped while aborting: xfsprogs-4.5.0-1.5.x86_64.rpm thin-provisioning-tools-0.6.3-1.3.x86_64.rpm
Problem occured during or after installation or removal of packages: Installation aborted by user
Please see the above error message for a hint.
dhcppc2:/home/constant # zypper -n -vvv dup Verbosity: 3 Entering non-interactive mode. Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. Initializing Target Target initialization failed: Failed to cache rpm database (1). History: - 'rpmdb2solv' '-r' '/' '-X' '-A' '-p' '/etc/products.d' '/var/cache/zypp/ solv/@System/solv' '-o' '/var/cache/zypp/solv/@System/solvRy20bw' repo_write failed
Hi, Id' rollback last snapshot(s) (snapper rollback ...) to get rid of semi- downloaded packages. Then I'd check how many snapshots You have (snapper list) and delete some old/unneeded (snapper delete X-Y) and check how many free space do You have (btrfs filesystem show /) and may be clear /tmp, old logs, whatever. Zypper starts with snapshot prior to downloading and ends with another snapshot with updated system. -- Vojtěch Zeisek Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/ https://trapa.cz/
On Wed, Oct 19, 2016 at 3:20 PM, Vojtěch Zeisek <vojtech.zeisek@opensuse.org> wrote: ...
( 683/1499) Installing: python-base-2.7.12-1.3.x86_64................[error] Installation of python-base-2.7.12-1.3.x86_64 failed: Error: Subprocess failed. Error: RPM failed: installing package python- base-2.7.12-1.3.x86_64 needs 19MB on the / filesystem
Abort, retry, ignore? [a/r/i] (a): a ...
Hi, Id' rollback last snapshot(s) (snapper rollback ...)
snapper rollback works by creating *more* snapshots, thus freezing current "out of space" condition ... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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?
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. HTH. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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. Then run your zypper update again. The packages that are already updated will not be downloaded again. But it will download the needed ones again. This should take less space. Rinse and repeat. Of get more free disk space. I don't know of a better way that does not involve downloading the not-yet-updated packages. A variation on zypper cc that only clears installed packages from the cache. But I don't know what that is. So I do the brute force approach. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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
it does not seem to have been mentioned, but after removing files and snapper images i believe you would need to re-balance. i.e. sudo btrfs balance start -dusage=30 / On 19 October 2016 at 17:06, Brüns, Stefan <Stefan.Bruens@rwth-aachen.de> wrote:
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
-- 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 <Stefan.Bruens@rwth-aachen.de> 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
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
<Stefan.Bruens@rwth-aachen.de> 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 ... 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 Kind regards, Stefan -- 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
<Stefan.Bruens@rwth-aachen.de> 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
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
<Stefan.Bruens@rwth-aachen.de> 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? 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. Kind regards, Stefan
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
<Stefan.Bruens@rwth-aachen.de> 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
On Wed, 2016-10-19 at 16:21 +0000, Brüns, Stefan wrote:
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
<Stefan.Bruens@rwth-aachen.de> 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 ...
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-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... Cheers, Dominiqe
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
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. I suppose there could be a way to do it via the YaST Partitioner, which may make life a bit easier. P.S. I guess I must be blind because I couldn't find the instructions in https://features.opensuse.org/320834 either. I appreciate the additional links.
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
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? 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)
On Thu, Oct 20, 2016 at 10:45 AM, Johannes Meixner <jsmeix@suse.de> 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
Hello, On Oct 20 11:58 Andrei Borzenkov wrote (excerpt):
Well, this structure was a *proposal* so far and user is completely free to refuse it and chose its own scheme, not?
Of course - it is free software - you are completely free to do what you want - but then be brave and do not expect something from someone else.
So instructions how to add single volume are still useful.
Everything is described, see "man btrfs..." and so on. What else do you expect when you chose your own scheme?
User may opt out mysql subvolume during installation because no mySQL was originally installed but may opt to install it later.
You are completely free to do what you want - but then stay brave and do not expect someone else will guide you out of your own trouble. Cf. https://lists.opensuse.org/opensuse-factory/2016-10/msg00397.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
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)
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
Dne 21.10.2016 v 08:26 Pierre de Villemereuil napsal(a):
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".
No, heaps are not defined by package groups but by package dependencies, see below.
Is there something I'm missing?
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. See https://github.com/openSUSE/libzypp/blob/458ecc2ba3354bef0b5d8aaf7bccc9da3d1... -- Ladislav Slezák YaST Developer SUSE LINUX, s.r.o. Corso IIa Křižíkova 148/34 18600 Praha 8 -- 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 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. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
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
On Wed, Oct 19, 2016 at 3:11 PM, Constant Brouerius van Nidek <cbroueriusvannidek@gmail.com> wrote: ...
============================================================= ( 680/1499) Installing: wireless- tools-30.pre9-37.8.x86_64......................................[done] ( 681/1499) Installing: thin-provisioning- tools-0.6.3-1.3.x86_64...............................................[done] ( 682/1499) Installing: python3-base-3.5.1-3.6.x86_64................[done] ( 683/1499) Installing: python-base-2.7.12-1.3.x86_64................[error] Installation of python-base-2.7.12-1.3.x86_64 failed: Error: Subprocess failed. Error: RPM failed: installing package python- base-2.7.12-1.3.x86_64 needs 19MB on the / filesystem
Abort, retry, ignore? [a/r/i] (a): a Warning: %posttrans scripts skipped while aborting: xfsprogs-4.5.0-1.5.x86_64.rpm thin-provisioning-tools-0.6.3-1.3.x86_64.rpm
Problem occured during or after installation or removal of packages: Installation aborted by user
Please see the above error message for a hint.
dhcppc2:/home/constant # zypper -n -vvv dup Verbosity: 3 Entering non-interactive mode. Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. Initializing Target Target initialization failed: Failed to cache rpm database (1). History: - 'rpmdb2solv' '-r' '/' '-X' '-A' '-p' '/etc/products.d' '/var/cache/zypp/ solv/@System/solv' '-o' '/var/cache/zypp/solv/@System/solvRy20bw' repo_write failed
Try to delete old snapshots (snapper list, snapper delete). Wait for some time to allow for space reclamation (it is not instant). You may want to run btrfs balance thereafter, it may recover even more space. If unsure, post "snapper list" and "btrfs sub get-default /" output. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op woensdag 19 oktober 2016 19:11:36 CEST schreef Constant Brouerius van Nidek:
The 1499 files for the update where neatly downloaded but at installing time the system ran out of space after finishing 682 files. Hereunder the message. A repeat zypper dup resulted with an for me unintellegable message. In the past I remember being able to enlarge he ext4 extensions with Partition Magic but in this case I am working with btrfs filesystem which is not yet recognized by the Partition Magic i have here.
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? Thanks in advance
Constant
============================================================= ( 680/1499) Installing: wireless- tools-30.pre9-37.8.x86_64......................................[done] ( 681/1499) Installing: thin-provisioning- tools-0.6.3-1.3.x86_64...............................................[done] ( 682/1499) Installing: python3-base-3.5.1-3.6.x86_64................[done] ( 683/1499) Installing: python-base-2.7.12-1.3.x86_64................[error] Installation of python-base-2.7.12-1.3.x86_64 failed: Error: Subprocess failed. Error: RPM failed: installing package python- base-2.7.12-1.3.x86_64 needs 19MB on the / filesystem
Abort, retry, ignore? [a/r/i] (a): a Warning: %posttrans scripts skipped while aborting: xfsprogs-4.5.0-1.5.x86_64.rpm thin-provisioning-tools-0.6.3-1.3.x86_64.rpm
Problem occured during or after installation or removal of packages: Installation aborted by user
Please see the above error message for a hint.
dhcppc2:/home/constant # zypper -n -vvv dup Verbosity: 3 Entering non-interactive mode. Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. Initializing Target Target initialization failed: Failed to cache rpm database (1). History: - 'rpmdb2solv' '-r' '/' '-X' '-A' '-p' '/etc/products.d' '/var/cache/zypp/ solv/@System/solv' '-o' '/var/cache/zypp/solv/@System/solvRy20bw' repo_write failed
==- opensuse:tumbleweed:20161013 Qt: 5.7.0 KDE Frameworks: 5.26.0 kf5-config: 1.0 KDE Plasma: 5.8.0 Kernel: 4.7.6-1-default Linux User 183145 working on a Pentium IV .
Remove some of the btrfs snapshots. Using 'zypper clean' would mean having to download all the packages again, probably ending up with the same error. -- Gertjan Lettink, a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (17)
-
Andrei Borzenkov -
Anton Aylward -
Brüns, Stefan -
C. R. Oldham -
Carlos E. R. -
Chan Ju Ping -
Constant Brouerius van Nidek -
Dominique Leuenberger / DimStar -
Johannes Meixner -
Karl Ove Hufthammer -
Knurpht - Gertjan Lettink -
Ladislav Slezak -
nicholas cunliffe -
Patrick Shanahan -
Pierre de Villemereuil -
Roger Oberholtzer -
Vojtěch Zeisek