[opensuse] During zypper dup update: how to force the rpms to be downloaded temporarily to a specified repo (eg. /home/user/update)
My disk space on root is only 2 GB. Too low to perform an update via zypper dup because the amount of rpms downloaded prior installation exceeds the space. I did last time a trick that I simply forgot, I defined a place for the rmp to be downloaded in /home. I then lifted this when done. But I cannot recall the command. Anybody knows still how to do it? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data domenica 12 luglio 2020 17:46:55 CEST, Stakanov ha scritto:
My disk space on root is only 2 GB. Too low to perform an update via zypper dup because the amount of rpms downloaded prior installation exceeds the space. I did last time a trick that I simply forgot, I defined a place for the rmp to be downloaded in /home. I then lifted this when done. But I cannot recall the command.
Anybody knows still how to do it?
With other words: would zypper dup -C /home/user/upgrade to make an example be accepted during upgrade? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2020-07-12 9:54 a.m., Stakanov wrote:
In data domenica 12 luglio 2020 17:46:55 CEST, Stakanov ha scritto:
My disk space on root is only 2 GB. Too low to perform an update via zypper dup because the amount of rpms downloaded prior installation exceeds the space. I did last time a trick that I simply forgot, I defined a place for the rmp to be downloaded in /home. I then lifted this when done. But I cannot recall the command.
Anybody knows still how to do it?
With other words: would zypper dup -C /home/user/upgrade
to make an example be accepted during upgrade?
You could perhaps try "rebuilding" the cache for one of the repos: zypper ref -f [repo-alias] -C [new-cache-path] then check to see if the cache did get built in that location. This should not affect the existing cache in /var/cache (?) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
W dniu 12.07.2020 o 17:46, Stakanov pisze:
My disk space on root is only 2 GB. Too low to perform an update via zypper dup because the amount of rpms downloaded prior installation exceeds the space. I did last time a trick that I simply forgot, I defined a place for the rmp to be downloaded in /home. I then lifted this when done. But I cannot recall the command.
Anybody knows still how to do it?
In /etc/zypp/zypp.conf you can change paths
On 12/07/2020 17.46, Stakanov wrote:
My disk space on root is only 2 GB. Too low to perform an update via zypper dup because the amount of rpms downloaded prior installation exceeds the space. I did last time a trick that I simply forgot, I defined a place for the rmp to be downloaded in /home. I then lifted this when done. But I cannot recall the command.
Anybody knows still how to do it?
You could temporarily symlink or mount something on /var/cache/zypp/ (copy the current contents first, and back afterwards). -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Hello, On Sun, 12 Jul 2020, Stakanov wrote:
My disk space on root is only 2 GB. Too low to perform an update via zypper dup because the amount of rpms downloaded prior installation exceeds the space. I did last time a trick that I simply forgot, I defined a place for the rmp to be downloaded in /home. I then lifted this when done. But I cannot recall the command.
Anybody knows still how to do it?
==== /etc/zypp/zypp.conf ==== ## ## Path where the caches are kept. ## ## Valid values: A directory ## Default value: /var/cache/zypp ## # cachedir = /var/cache/zypp ==== HTH, -dnh -- Absolutely nothing should be concluded from these figures except that no conclusion can be drawn from them. -- Joseph L. Brothers, Linux/PowerPC Project) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/07/2020 11:46, Stakanov wrote:
My disk space on root is only 2 GB. Too low to perform an update via zypper dup because the amount of rpms downloaded prior installation exceeds the space. I did last time a trick that I simply forgot, I defined a place for the rmp to be downloaded in /home. I then lifted this when done. But I cannot recall the command.
Anybody knows still how to do it?
Two thing. 1 You can set the zypper config so that it downloads and install the RPMs one at a time rather than downloading the all before installing/ Look in /etc/zypp/zypp.con for this setting. ## ## 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. ## ## commit.downloadMode = commit.downloadMode = DownloadAsNeeded You might also look at ## Path where the caches are kept. ## ## Valid values: A directory ## Default value: /var/cache/zypp ## # cachedir = /var/cache/zypp and clean that out beforehand. Secondly, you might want to install and run 'bleachbit'. This utility does systematic cleanup. You can tell it to - purge language files for files you don't use - clean out caches - clean out VI's .swp files that get left around. - condense the firefox/thunderbird/seamonkey databases of redundant entries depending on whether it is run as a user or as root -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data lunedì 13 luglio 2020 06:30:05 CEST, Anton Aylward ha scritto:
On 12/07/2020 11:46, Stakanov wrote:
My disk space on root is only 2 GB. Too low to perform an update via zypper dup because the amount of rpms downloaded prior installation exceeds the space. I did last time a trick that I simply forgot, I defined a place for the rmp to be downloaded in /home. I then lifted this when done. But I cannot recall the command.
Anybody knows still how to do it?
Two thing.
1 You can set the zypper config so that it downloads and install the RPMs one at a time rather than downloading the all before installing/
Look in /etc/zypp/zypp.con for this setting.
## ## 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. ## ## commit.downloadMode = commit.downloadMode = DownloadAsNeeded
You might also look at
## Path where the caches are kept. ## ## Valid values: A directory ## Default value: /var/cache/zypp ## # cachedir = /var/cache/zypp
and clean that out beforehand.
Secondly, you might want to install and run 'bleachbit'. This utility does systematic cleanup. You can tell it to - purge language files for files you don't use - clean out caches - clean out VI's .swp files that get left around. - condense the firefox/thunderbird/seamonkey databases of redundant entries
depending on whether it is run as a user or as root
> Q: Are you sure? > >> A: Because it reverses the logical flow of conversation. >> >>> Q: Why is top posting frowned upon?
That gave actually with bleachbit 800 Mb free space more. I should have thought about this before. I also had to eliminate tex because it take too much space. I have an LVM with 20 GB for root, unfortunately with LVM resizing it is requiring afaik a new install. Today I would advise not less then 30 or even 40 GB. With the years something accumulates and what was plenty before...is straight, straight! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Stakanov wrote:
I also had to eliminate tex because it take too much space. I have an LVM with 20 GB for root, unfortunately with LVM resizing it is requiring afaik a new install.
No, you can resize without needing to reinstall.
Today I would advise not less then 30 or even 40 GB. With the years something accumulates and what was plenty before...is straight, straight!
For root-only, 20Gb has always been more than plenty for me. On a laptop with 15.2, I currently see less than 7Gb in use :-) -- Per Jessen, Zürich (18.2°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data lunedì 13 luglio 2020 09:27:56 CEST, Per Jessen ha scritto:
Stakanov wrote:
I also had to eliminate tex because it take too much space. I have an LVM with 20 GB for root, unfortunately with LVM resizing it is requiring afaik a new install.
No, you can resize without needing to reinstall.
Even with root inside a LVM?
Today I would advise not less then 30 or even 40 GB. With the years something accumulates and what was plenty before...is straight, straight!
For root-only, 20Gb has always been more than plenty for me. On a laptop with 15.2, I currently see less than 7Gb in use :-)
sudo df -h File system Dim. Usati Dispon. Uso% Montato su devtmpfs 3,8G 4,0K 3,8G 1% /dev tmpfs 3,8G 58M 3,8G 2% /dev/shm tmpfs 3,8G 1,8M 3,8G 1% /run tmpfs 3,8G 0 3,8G 0% /sys/fs/cgroup /dev/mapper/system-root 20G 17G 2,4G 88% / /dev/mapper/system-home 441G 343G 77G 82% /home tmpfs 3,8G 36K 3,8G 1% /tmp tmpfs 775M 16K 775M 1% /run/user/1000 tmpfs 775M 40K 775M 1% /run/user/1002 tmpfs 775M 56K 775M 1% /run/user/1001 And that after having uninstalled the whole tex. cleaned tmp, and bleachbit..... Any suggestion for the "culprit"? No KVM installed. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Stakanov wrote:
In data lunedì 13 luglio 2020 09:27:56 CEST, Per Jessen ha scritto:
Stakanov wrote:
I also had to eliminate tex because it take too much space. I have an LVM with 20 GB for root, unfortunately with LVM resizing it is requiring afaik a new install.
No, you can resize without needing to reinstall.
Even with root inside a LVM?
Booting from an LVM volume - hmm, dunno, I don't do that. I would expect grub to work fine though.
Today I would advise not less then 30 or even 40 GB. With the years something accumulates and what was plenty before...is straight, straight!
For root-only, 20Gb has always been more than plenty for me. On a laptop with 15.2, I currently see less than 7Gb in use :-)
sudo df -h File system Dim. Usati Dispon. Uso% Montato su devtmpfs 3,8G 4,0K 3,8G 1% /dev tmpfs 3,8G 58M 3,8G 2% /dev/shm tmpfs 3,8G 1,8M 3,8G 1% /run tmpfs 3,8G 0 3,8G 0% /sys/fs/cgroup /dev/mapper/system-root 20G 17G 2,4G 88% /
Wow.
And that after having uninstalled the whole tex. cleaned tmp, and bleachbit..... Any suggestion for the "culprit"? No KVM installed.
"du -hsx /*" might give you an idea of where to look. -- Per Jessen, Zürich (20.1°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 13/07/2020 11.02, Per Jessen wrote:
"du -hsx /*" might give you an idea of where to look.
There is a problem with that. Despite: -x, --one-file-system skip directories on different file systems It does scan inside home: Telcontar:~ # du -hsx /* 8.0K /%{_rundir} 211M /CopiaSeguridadParcial 20K /DEADJOE 22M /aeat 1.8M /bin 73M /boot 4.1M /core 196K /data 36K /dev 86M /etc 136M /etc_13.1 30M /etc_13.1.tar.xz 51G /home <==== ... -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
In data lunedì 13 luglio 2020 12:02:34 CEST, Carlos E. R. ha scritto:
On 13/07/2020 11.02, Per Jessen wrote:
"du -hsx /*" might give you an idea of where to look.
There is a problem with that. Despite:
-x, --one-file-system skip directories on different file systems
It does scan inside home:
Telcontar:~ # du -hsx /* 8.0K /%{_rundir} 211M /CopiaSeguridadParcial 20K /DEADJOE 22M /aeat 1.8M /bin 73M /boot 4.1M /core 196K /data 36K /dev 86M /etc 136M /etc_13.1 30M /etc_13.1.tar.xz 51G /home <==== ...
Same for me: sudo du -hsx /* [sudo] password di root: 1,6M /bin 178M /boot 4,0K /dev 21M /etc 289G /home 1,9G /lib 11M /lib64 4,0K /mnt 4,0K /opt du: impossibile leggere la directory '/proc/2734/task/2734/net': Argomento non valido du: impossibile leggere la directory '/proc/2734/net': Argomento non valido du: impossibile leggere la directory '/proc/3619/task/3619/net': Argomento non valido du: impossibile leggere la directory '/proc/3619/net': Argomento non valido du: impossibile leggere la directory '/proc/9493/task/9493/net': Argomento non valido du: impossibile leggere la directory '/proc/9493/net': Argomento non valido du: impossibile accedere a '/proc/28563/task/28563/fd/4': File o directory non esistente du: impossibile accedere a '/proc/28563/task/28563/fdinfo/4': File o directory non esistente du: impossibile accedere a '/proc/28563/fd/4': File o directory non esistente du: impossibile accedere a '/proc/28563/fdinfo/4': File o directory non esistente 0 /proc 221M /root 1,6M /run 9,9M /sbin 4,0K /selinux 24K /srv Seems all normal.....to me. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Stakanov wrote:
Same for me: sudo du -hsx /* [sudo] password di root: 1,6M /bin 178M /boot 4,0K /dev 21M /etc 289G /home 1,9G /lib 11M /lib64 4,0K /mnt 4,0K /opt 221M /root 1,6M /run 9,9M /sbin 4,0K /selinux 24K /srv
Seems all normal.....to me.
The above does not make up much in total, a lot less than 20Gb, but you also left out /usr and /var -- Per Jessen, Zürich (23.8°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 13/07/2020 12.17, Stakanov wrote:
In data lunedì 13 luglio 2020 12:02:34 CEST, Carlos E. R. ha scritto:
On 13/07/2020 11.02, Per Jessen wrote:
"du -hsx /*" might give you an idea of where to look.
There is a problem with that. Despite:
-x, --one-file-system skip directories on different file systems
It does scan inside home:
Telcontar:~ # du -hsx /* 8.0K /%{_rundir} 211M /CopiaSeguridadParcial 20K /DEADJOE 22M /aeat 1.8M /bin 73M /boot 4.1M /core 196K /data 36K /dev 86M /etc 136M /etc_13.1 30M /etc_13.1.tar.xz 51G /home <==== ...
Same for me: sudo du -hsx /* [sudo] password di root: 1,6M /bin 178M /boot 4,0K /dev 21M /etc 289G /home 1,9G /lib 11M /lib64 4,0K /mnt 4,0K /opt
0 /proc 221M /root 1,6M /run 9,9M /sbin 4,0K /selinux 24K /srv
Seems all normal.....to me.
There must be more, /var and /usr are not there. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
In data lunedì 13 luglio 2020 13:49:32 CEST, Carlos E. R. ha scritto:
On 13/07/2020 12.17, Stakanov wrote:
In data lunedì 13 luglio 2020 12:02:34 CEST, Carlos E. R. ha scritto:
On 13/07/2020 11.02, Per Jessen wrote:
"du -hsx /*" might give you an idea of where to look.
There is a problem with that. Despite: -x, --one-file-system
skip directories on different file systems
It does scan inside home:
Telcontar:~ # du -hsx /* 8.0K /%{_rundir} 211M /CopiaSeguridadParcial 20K /DEADJOE 22M /aeat 1.8M /bin 73M /boot 4.1M /core 196K /data 36K /dev 86M /etc 136M /etc_13.1 30M /etc_13.1.tar.xz 51G /home <==== ...
Same for me: sudo du -hsx /* [sudo] password di root: 1,6M /bin 178M /boot 4,0K /dev 21M /etc 289G /home 1,9G /lib 11M /lib64 4,0K /mnt 4,0K /opt
0 /proc 221M /root 1,6M /run 9,9M /sbin 4,0K /selinux 24K /srv
Seems all normal.....to me.
There must be more, /var and /usr are not there.
It is knowingly sufficient to behave like an idiot..... *****blush**** Did not scroll the screeeen aitch! sudo du -hsx /* [sudo] password di root: 1,6M /bin 178M /boot 4,0K /dev 21M /etc 289G /home 1,9G /lib 11M /lib64 4,0K /mnt 4,0K /opt du: impossibile leggere la directory '/proc/2734/task/2734/net': Argomento non valido du: impossibile leggere la directory '/proc/2734/net': Argomento non valido du: impossibile leggere la directory '/proc/3619/task/3619/net': Argomento non valido du: impossibile leggere la directory '/proc/3619/net': Argomento non valido du: impossibile leggere la directory '/proc/9493/task/9493/net': Argomento non valido du: impossibile leggere la directory '/proc/9493/net': Argomento non valido du: impossibile accedere a '/proc/28563/task/28563/fd/4': File o directory non esistente du: impossibile accedere a '/proc/28563/task/28563/fdinfo/4': File o directory non esistente du: impossibile accedere a '/proc/28563/fd/4': File o directory non esistente du: impossibile accedere a '/proc/28563/fdinfo/4': File o directory non esistente 0 /proc 221M /root 1,6M /run 9,9M /sbin 4,0K /selinux 24K /srv 0 /sys 68K /tmp 13G /usr 1,7G /var so /usr is the problem. But in usr is everything and nothing? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Stakanov wrote:
68K /tmp 13G /usr 1,7G /var
so /usr is the problem. But in usr is everything and nothing?
I guess you just have a lot of software installed, much like Dave, so 20Gb isn't quite enough - your initial proposal of 30 or 40 is good :-) You could take a look at "du -hsx /usr/*" - it could be kernel source taking up space in /usr/src -- Per Jessen, Zürich (24.6°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data lunedì 13 luglio 2020 15:16:53 CEST, Per Jessen ha scritto:
Stakanov wrote:
68K /tmp 13G /usr 1,7G /var
so /usr is the problem. But in usr is everything and nothing?
I guess you just have a lot of software installed, much like Dave, so 20Gb isn't quite enough - your initial proposal of 30 or 40 is good :-)
You could take a look at "du -hsx /usr/*" - it could be kernel source taking up space in /usr/src
sudo du -hsx /usr/* [sudo] password di root: Riprovare. [sudo] password di root: 506M /usr/bin 576K /usr/include 3,6G /usr/lib 4,0G /usr/lib64 80K /usr/local 80M /usr/sbin 3,7G /usr/share 664M /usr/src 16K /usr/x86_64-suse-linux I think it is really software.... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 13/07/2020 09:30, Stakanov wrote:
sudo du -hsx /usr/* [sudo] password di root: Riprovare. [sudo] password di root: 506M /usr/bin 576K /usr/include 3,6G /usr/lib
That might be software in total, but it might also be 'debris' from older stuff
4,0G /usr/lib64 80K /usr/local 80M /usr/sbin 3,7G /usr/share
That too might be a side effect of a lot of installed software. Each package bringing in a yet-another-copy-of the notice about free software. Also look at terminfo and zoneinfo. You might want to purge.
664M /usr/src 16K /usr/x86_64-suse-linux
I think it is really software....
Well, no. There's a lot of 'DATA', as I say, like terminfo and zoneinfo. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 13 Jul 2020 12:02:34 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 13/07/2020 11.02, Per Jessen wrote:
"du -hsx /*" might give you an idea of where to look.
There is a problem with that. Despite:
It's not a problem. As you say, it scans /home but if that's on a separate partition then you know it isn't the problem so just ignore it! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 13/07/2020 12.39, Dave Howorth wrote:
On Mon, 13 Jul 2020 12:02:34 +0200 "Carlos E. R." <> wrote:
On 13/07/2020 11.02, Per Jessen wrote:
"du -hsx /*" might give you an idea of where to look.
There is a problem with that. Despite:
It's not a problem. As you say, it scans /home but if that's on a separate partition then you know it isn't the problem so just ignore it!
It wastes time. Takes much longer to run. My root is relatively small and fast (nvme), but the rest is huge and slow (rotating rust). Yes, as Per says /* expands and includes /home in the command line, so it is scanned. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Mon, 13 Jul 2020 13:10:11 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 13/07/2020 12.39, Dave Howorth wrote:
On Mon, 13 Jul 2020 12:02:34 +0200 "Carlos E. R." <> wrote:
On 13/07/2020 11.02, Per Jessen wrote:
"du -hsx /*" might give you an idea of where to look.
There is a problem with that. Despite:
It's not a problem. As you say, it scans /home but if that's on a separate partition then you know it isn't the problem so just ignore it!
It wastes time. Takes much longer to run. My root is relatively small and fast (nvme), but the rest is huge and slow (rotating rust).
Ha! So you haven't suggested any alternative and you used the command yourself, so what's your point? It doesn't take long on my machine, despite it all being on rotating rust, because /home is pretty small (4.8G). Almost all my data is on separate filesystems. If you directly mount a large filesystem on /home then you'll have to scan it. You'll also have to deal with a whole class of problems that can occur that I don't, but I expect I have to deal with some you don't, so please don't discuss the merits.
Yes, as Per says /* expands and includes /home in the command line, so it is scanned.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 13/07/2020 13.57, Dave Howorth wrote:
On Mon, 13 Jul 2020 13:10:11 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 13/07/2020 12.39, Dave Howorth wrote:
On Mon, 13 Jul 2020 12:02:34 +0200 "Carlos E. R." <> wrote:
On 13/07/2020 11.02, Per Jessen wrote:
"du -hsx /*" might give you an idea of where to look.
There is a problem with that. Despite:
It's not a problem. As you say, it scans /home but if that's on a separate partition then you know it isn't the problem so just ignore it!
It wastes time. Takes much longer to run. My root is relatively small and fast (nvme), but the rest is huge and slow (rotating rust).
Ha! So you haven't suggested any alternative and you used the command yourself, so what's your point?
Of course I use the command, I don't have a better one! But maybe someone knows a better command. What I do is concoct a long parameter line including only the directories of interest and excluding /home and /data. But that line is only valid for me. There is this: --exclude=PATTERN exclude files that match PATTERN So, for me, this works: du -hsx --exclude=/home --exclude=/home1 --exclude=/home_aux --exclude=/data --exclude=/windows /* And I still should add /media and /opt It would have to be a script, that would create a exclude list from the output of the "mount" command, perhaps. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Carlos E. R. wrote:
On 13/07/2020 11.02, Per Jessen wrote:
"du -hsx /*" might give you an idea of where to look.
There is a problem with that. Despite:
-x, --one-file-system skip directories on different file systems
It does scan inside home:
Telcontar:~ # du -hsx /* 8.0K /%{_rundir} 211M /CopiaSeguridadParcial 20K /DEADJOE 22M /aeat 1.8M /bin 73M /boot 4.1M /core 196K /data 36K /dev 86M /etc 136M /etc_13.1 30M /etc_13.1.tar.xz 51G /home <==== ...
Yeah, probably because /home was explicitly specified. It'll do the job anyway. -- Per Jessen, Zürich (21.6°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 13/07/2020 05:02, Per Jessen wrote:
Stakanov wrote:
In data lunedì 13 luglio 2020 09:27:56 CEST, Per Jessen ha scritto:
Stakanov wrote:
I also had to eliminate tex because it take too much space. I have an LVM with 20 GB for root, unfortunately with LVM resizing it is requiring afaik a new install.
No, you can resize without needing to reinstall.
Even with root inside a LVM?
Booting from an LVM volume - hmm, dunno, I don't do that. I would expect grub to work fine though.
That capability was added to grub2 some years back; I don't know about other bootloaders. My installation and use of LVM dates to before that, which is why I have the boot partition outside LVM. Yes, I could change, but I'm not that sort of tinkerer. it works, it's stable. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 13/07/2020 04:23, Stakanov wrote:
Any suggestion for the "culprit"? No KVM installed.
You need more disk space. If you are unwilling to _migrate_ to a 1T upward then you can use a disk in parallel because you are using LVM. Why not get a 2T upwards while you are about it? Initialise the drive, make it a LVM with the same volume group as on your main drive. Then add to the existing LVs since you have more blocks in VG pool. There are many web pages on how to do this. When you've expanded the size of the LV you can expand the File system to that capacity. Along the way I suggest that you get a real /tmp for a number of reasons I also have an additional SWAP area in the LVM since I have space. # df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 684K 3.9G 1% /dev/shm tmpfs 3.9G 9.6M 3.9G 1% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/mapper/vgmain-vROOT4 40G 6.7G 32G 18% / /dev/sda1 1.9G 400M 1.4G 23% /boot /dev/mapper/vgmain-vTMP 9.8G 24M 9.2G 1% /tmp /dev/mapper/vgmain-vSRV 4.8G 969M 3.6G 21% /srv /dev/mapper/vgmain-vVAR 4.8G 1.3G 3.3G 29% /var /dev/mapper/vgmain-vLOCAL 2.9G 954M 1.8G 35% /usr/local /dev/mapper/vgmain-vOPT 4.8G 814M 3.8G 18% /opt /dev/mapper/vgmain-vUser4 12G 2.9G 8.7G 26% /usr/share /dev/mapper/vgmain-vISO.JFS 50G 30G 21G 60% /ISO /dev/mapper/vgmain-vHome 30G 6.6G 24G 22% /home /dev/mapper/vgmain-vMyMovies.JFS 50G 41G 9.2G 82% /home/anton/MyMovies /dev/mapper/vgmain-vPDF.JFS 5.0G 3.4G 1.7G 68% /home/anton/PDF /dev/mapper/vgmain-vMail 5.0G 3.7G 1.4G 73% /home/anton/Mail /dev/mapper/vgmain-vMedia.JFS 5.0G 4.1G 946M 82% /home/anton/Media /dev/mapper/vgmain-vDownloads 5.0G 755M 4.3G 15% /home/anton/Downloads /dev/mapper/vgmain-vCamera 15G 6.1G 9.0G 41% /home/anton/Photographs /dev/mapper/vgmain-vMyMusic.JFS 30G 12G 19G 39% /home/anton/MyMusic /dev/mapper/vgmain-vMovieAVI 50G 6.4G 44G 13% /home/anton/MyMovies/AVI /dev/mapper/vgmain-vPhoto2019.JFS 10G 2.8G 7.3G 28% /home/anton/Photographs/ByYear/2019 /dev/mapper/vgmain-vPhoto2017.JFS 6.0G 4.5G 1.6G 74% /home/anton/Photographs/ByYear/2017 /dev/mapper/vgmain-vPhoto2014.JFS 6.0G 4.6G 1.5G 76% /home/anton/Photographs/ByYear/2014 /dev/mapper/vgmain-vPhoto2018.JFS 10G 7.6G 2.5G 76% /home/anton/Photographs/ByYear/2018 /dev/mapper/vgmain-M4Vb 50G 19G 32G 38% /home/anton/MyMovies/M4Vb tmpfs 782M 216K 782M 1% /run/user/501 I know, I'll get castigated for having a separate /boot and ridicules for my organization, but it works for me. A lot of the organization has to do with the way my backups work. Most modern file systems are expandable. A few like ReiserFS are also shrinkable. I don't have much in the web side, but under late model Linux that's all under /srv. I deemed it worth it's own FS. if you run a database-oriented web site and the database is elsewhere you can set the /srv FS to RO. The /usr/share has all the man pages. Same reasoning. Just RW them when you 'zypper up'. I _could_ make all the file systems under ~anton to be mount on demand. Does anyone have suggestions about that? Obviously they don't need to be loaded when doing a 'zypper up'. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data lunedì 13 luglio 2020 14:03:10 CEST, Anton Aylward ha scritto:
On 13/07/2020 04:23, Stakanov wrote:
Any suggestion for the "culprit"? No KVM installed.
You need more disk space. If you are unwilling to _migrate_ to a 1T upward then you can use a disk in parallel because you are using LVM. Why not get a 2T upwards while you are about it?
Initialise the drive, make it a LVM with the same volume group as on your main drive. Then add to the existing LVs since you have more blocks in VG pool. There are many web pages on how to do this. When you've expanded the size of the LV you can expand the File system to that capacity.
Along the way I suggest that you get a real /tmp for a number of reasons
I also have an additional SWAP area in the LVM since I have space.
# df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 684K 3.9G 1% /dev/shm tmpfs 3.9G 9.6M 3.9G 1% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/mapper/vgmain-vROOT4 40G 6.7G 32G 18% / /dev/sda1 1.9G 400M 1.4G 23% /boot /dev/mapper/vgmain-vTMP 9.8G 24M 9.2G 1% /tmp /dev/mapper/vgmain-vSRV 4.8G 969M 3.6G 21% /srv /dev/mapper/vgmain-vVAR 4.8G 1.3G 3.3G 29% /var /dev/mapper/vgmain-vLOCAL 2.9G 954M 1.8G 35% /usr/local /dev/mapper/vgmain-vOPT 4.8G 814M 3.8G 18% /opt /dev/mapper/vgmain-vUser4 12G 2.9G 8.7G 26% /usr/share /dev/mapper/vgmain-vISO.JFS 50G 30G 21G 60% /ISO /dev/mapper/vgmain-vHome 30G 6.6G 24G 22% /home /dev/mapper/vgmain-vMyMovies.JFS 50G 41G 9.2G 82% /home/anton/MyMovies /dev/mapper/vgmain-vPDF.JFS 5.0G 3.4G 1.7G 68% /home/anton/PDF /dev/mapper/vgmain-vMail 5.0G 3.7G 1.4G 73% /home/anton/Mail /dev/mapper/vgmain-vMedia.JFS 5.0G 4.1G 946M 82% /home/anton/Media /dev/mapper/vgmain-vDownloads 5.0G 755M 4.3G 15% /home/anton/Downloads /dev/mapper/vgmain-vCamera 15G 6.1G 9.0G 41% /home/anton/Photographs /dev/mapper/vgmain-vMyMusic.JFS 30G 12G 19G 39% /home/anton/MyMusic /dev/mapper/vgmain-vMovieAVI 50G 6.4G 44G 13% /home/anton/MyMovies/AVI /dev/mapper/vgmain-vPhoto2019.JFS 10G 2.8G 7.3G 28% /home/anton/Photographs/ByYear/2019 /dev/mapper/vgmain-vPhoto2017.JFS 6.0G 4.5G 1.6G 74% /home/anton/Photographs/ByYear/2017 /dev/mapper/vgmain-vPhoto2014.JFS 6.0G 4.6G 1.5G 76% /home/anton/Photographs/ByYear/2014 /dev/mapper/vgmain-vPhoto2018.JFS 10G 7.6G 2.5G 76% /home/anton/Photographs/ByYear/2018 /dev/mapper/vgmain-M4Vb 50G 19G 32G 38% /home/anton/MyMovies/M4Vb tmpfs 782M 216K 782M 1% /run/user/501
I know, I'll get castigated for having a separate /boot and ridicules for my organization, but it works for me. A lot of the organization has to do with the way my backups work.
Most modern file systems are expandable. A few like ReiserFS are also shrinkable.
I don't have much in the web side, but under late model Linux that's all under /srv. I deemed it worth it's own FS. if you run a database-oriented web site and the database is elsewhere you can set the /srv FS to RO.
The /usr/share has all the man pages. Same reasoning.
Just RW them when you 'zypper up'.
I _could_ make all the file systems under ~anton to be mount on demand. Does anyone have suggestions about that? Obviously they don't need to be loaded when doing a 'zypper up'.
> Q: Are you sure? > >> A: Because it reverses the logical flow of conversation. >> >>> Q: Why is top posting frowned upon? It is not so much unwilling. Counting my money..... Samsung 850 pro inside, next would be 860 pro 1TB..........250 "Öcken" as people with a certain migratory background use to say here...
And yes, meditating about it some time, but even Corona did not help, price is like a monument of slavery, proudly frozen..... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 13/07/2020 09:01, Stakanov wrote:
It is not so much unwilling. Counting my money..... Samsung 850 pro inside, next would be 860 pro 1TB..........250 "Öcken" as people with a certain migratory background use to say here...
And yes, meditating about it some time, but even Corona did not help, price is like a monument of slavery, proudly frozen.....
I depends on grade and quality and ... what you expect as a lifetime out of the device. I figure on paying under C$100 when I replace storage. As life goes on that C$100 buys me more or faster. I'd offer to buy one for you but the shipping would be exorbitant. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 13/07/2020 14.03, Anton Aylward wrote: ...
I_could_ make all the file systems under ~anton to be mount on demand. Does anyone have suggestions about that? Obviously they don't need to be loaded when doing a 'zypper up'.
Systemd automount. /dev/mapper/vgmain-vMyMovies.JFS /home/anton/MyMovies TYPE x-systemd.automount,x-systemd.idle-timeout=300 1 2 type would be xfs or whatever you use. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Mon, 13 Jul 2020 09:27:56 +0200 Per Jessen <per@computer.org> wrote:
Stakanov wrote:
I also had to eliminate tex because it take too much space. I have an LVM with 20 GB for root, unfortunately with LVM resizing it is requiring afaik a new install.
No, you can resize without needing to reinstall.
Today I would advise not less then 30 or even 40 GB. With the years something accumulates and what was plenty before...is straight, straight!
For root-only, 20Gb has always been more than plenty for me. On a laptop with 15.2, I currently see less than 7Gb in use :-)
I think it all depends on what you mean by 'root-only', versus what most people expect. # du -xsh /* ... 14G /usr ... # du -xsh /usr/* 1.2G /usr/bin 111M /usr/include 1.9G /usr/lib 4.3G /usr/lib64 162M /usr/local 194M /usr/sbin 4.6G /usr/share 1.8G /usr/src 28K /usr/x86_64-suse-linux -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dave Howorth wrote:
On Mon, 13 Jul 2020 09:27:56 +0200 Per Jessen <per@computer.org> wrote:
For root-only, 20Gb has always been more than plenty for me. On a laptop with 15.2, I currently see less than 7Gb in use :-)
I think it all depends on what you mean by 'root-only', versus what most people expect.
I guess I meant to suggest "root without /home"
# du -xsh /* ... 14G /usr # du -xsh /usr/* 1.2G /usr/bin 111M /usr/include 1.9G /usr/lib 4.3G /usr/lib64 162M /usr/local 194M /usr/sbin 4.6G /usr/share 1.8G /usr/src
Yeah, it will obviously depend on what sort of stuff you have installed. Mine is a plain office/development laptop: office68:~ # du -hsx /usr 5.3G /usr office68:~ # du -hsx /usr/* 336M /usr/bin 11M /usr/include 396M /usr/lib 2.4G /usr/lib64 8.0K /usr/local 63M /usr/sbin 2.2G /usr/share 8.0K /usr/src 0 /usr/x86_64-suse-linux -- Per Jessen, Zürich (21.6°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 13/07/2020 12.51, Per Jessen wrote:
Dave Howorth wrote:
On Mon, 13 Jul 2020 09:27:56 +0200 Per Jessen <per@computer.org> wrote:
For root-only, 20Gb has always been more than plenty for me. On a laptop with 15.2, I currently see less than 7Gb in use :-)
I think it all depends on what you mean by 'root-only', versus what most people expect.
I guess I meant to suggest "root without /home"
# du -xsh /* ... 14G /usr # du -xsh /usr/* 1.2G /usr/bin 111M /usr/include 1.9G /usr/lib 4.3G /usr/lib64 162M /usr/local 194M /usr/sbin 4.6G /usr/share 1.8G /usr/src
Yeah, it will obviously depend on what sort of stuff you have installed. Mine is a plain office/development laptop:
office68:~ # du -hsx /usr 5.3G /usr office68:~ # du -hsx /usr/* 336M /usr/bin 11M /usr/include 396M /usr/lib 2.4G /usr/lib64 8.0K /usr/local 63M /usr/sbin 2.2G /usr/share 8.0K /usr/src 0 /usr/x86_64-suse-linux
Mine is much bigger. Result, edited: Telcontar:~ # du -hsx /* 8.0K /%{_rundir} 211M /CopiaSeguridadParcial 20K /DEADJOE 22M /aeat 1.8M /bin 73M /boot 4.1M /core 196K /data 36K /dev 86M /etc 136M /etc_13.1 30M /etc_13.1.tar.xz 1.1G /lib 14M /lib64 16K /lost+found 16K /media 496K /mnt 68K /new 96K /other 0 /proc 11G /root 2.3M /run 13M /sbin 4.0K /selinux 497M /srv 4.0K /subdomain 0 /sys 13M /tftpboot 412M /tmp 25G /usr <==== 9.6G /var <==== Telcontar:~ # -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 13/07/2020 03:27, Per Jessen wrote:
For root-only, 20Gb has always been more than plenty for me. On a laptop with 15.2, I currently see less than 7Gb in use :-)
The kicker there is the 'root only' qualifier. My system has Filesystem Size Used Avail Use% Mounted on dev/mapper/vgmain-vROOT4 40G 6.7G 32G 18% / which really isn't that different, is it? But it most certainly IS 'root only' because Filesystem Size Used Avail Use% Mounted on /dev/sda1 1.9G 400M 1.4G 23% /boot /dev/mapper/vgmain-vTMP 9.8G 24M 9.2G 1% /tmp /dev/mapper/vgmain-vSRV 4.8G 969M 3.6G 21% /srv /dev/mapper/vgmain-vVAR 4.8G 1.3G 3.3G 29% /var /dev/mapper/vgmain-vLOCAL 2.9G 954M 1.8G 35% /usr/local /dev/mapper/vgmain-vOPT 4.8G 814M 3.8G 18% /opt /dev/mapper/vgmain-vUser4 12G 2.9G 8.7G 26% /usr/share Well, OK, they aren't overpowering and they would fit in the 23G available. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (8)
-
Adam Mizerski -
Anton Aylward -
Carlos E. R. -
Darryl Gregorash -
Dave Howorth -
David Haller -
Per Jessen -
Stakanov