Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #157436 > unrolled thread

Doing Dist-Upgrade or Such

Back to article view | Back to linux.debian.user

Contents

  Doing Dist-Upgrade or Such David Baron <d_baron@012.net.il> - 2015-09-06 12:10 +0200
    Re: Doing Dist-Upgrade or Such David Christensen <dpchrist@holgerdanske.com> - 2015-09-06 18:50 +0200
      Re: Doing Dist-Upgrade or Such David Baron <d_baron@012.net.il> - 2015-09-06 21:00 +0200
        Re: Doing Dist-Upgrade or Such Joe <joe@jretrading.com> - 2015-09-06 21:50 +0200
          Re: Doing Dist-Upgrade or Such David Baron <d_baron@012.net.il> - 2015-09-06 22:30 +0200
    Re: Doing Dist-Upgrade or Such Pascal Hambourg <pascal@plouf.fr.eu.org> - 2015-09-07 01:00 +0200
      Re: Doing Dist-Upgrade or Such David Baron <d_baron@012.net.il> - 2015-09-07 09:20 +0200
        Re: Doing Dist-Upgrade or Such Pascal Hambourg <pascal@plouf.fr.eu.org> - 2015-09-07 10:10 +0200
          Re: Doing Dist-Upgrade or Such dean <deanshannon3@gmail.com> - 2015-09-07 11:30 +0200
            Re: Doing Dist-Upgrade or Such Pascal Hambourg <pascal@plouf.fr.eu.org> - 2015-09-07 12:10 +0200
        Re: Doing Dist-Upgrade or Such David Wright <deblis@lionunicorn.co.uk> - 2015-09-07 16:30 +0200
          Re: Doing Dist-Upgrade or Such Pascal Hambourg <pascal@plouf.fr.eu.org> - 2015-09-07 17:30 +0200
            Re: Doing Dist-Upgrade or Such Cindy-Sue Causey <butterflybytes@gmail.com> - 2015-09-08 13:10 +0200
              Re: Doing Dist-Upgrade or Such David Wright <deblis@lionunicorn.co.uk> - 2015-09-08 23:40 +0200
            Re: Doing Dist-Upgrade or Such David Wright <deblis@lionunicorn.co.uk> - 2015-09-08 23:20 +0200

#157436 — Doing Dist-Upgrade or Such

Now that the g++ business is largely behind us, want to start upgrading. 
Problem is that with that darned partitioning by the Debian installation, 
there is not enough room on /var to accomplish upgrade of such size.

What can be done about this?

Note that to get an /opt, I bind this to a directory on my over-sized home.
Same for /usr/local!
These need not be mounted at boot or before home gets mounted so all this 
kludge is well-behaved and transparent.

Trick like this for all of /var, obviously will not play.
Any other ideas??

(Actually, apt's part of this is quite small in comparison.)

[toc] | [next] | [standalone]

#157458

On 09/06/2015 02:55 AM, David Baron wrote:
> Now that the g++ business is largely behind us, want to start upgrading.
> Problem is that with that darned partitioning by the Debian installation,
> there is not enough room on /var to accomplish upgrade of such size.

https://lists.debian.org/debian-user/2015/08/msg01056.html


David

[toc] | [prev] | [next] | [standalone]

#157467

On Sunday 06 September 2015 09:32:08 David Christensen wrote:
> On 09/06/2015 02:55 AM, David Baron wrote:
> > Now that the g++ business is largely behind us, want to start upgrading.
> > Problem is that with that darned partitioning by the Debian installation,
> > there is not enough room on /var to accomplish upgrade of such size.
> 
> https://lists.debian.org/debian-user/2015/08/msg01056.html
> 
> 
> David

Thanks, but I know how to, do not want to, reinstall. Should not have to do 
so.

Thinking of moving the /var/tmp KDE stuff elsewhere and symlinking. This takes 
up a large plurality, even majority of /var, not needed before login and home 
is mounted. What about that?

[toc] | [prev] | [next] | [standalone]

#157470

On Sun, 06 Sep 2015 21:54:13 +0300
David Baron <d_baron@012.net.il> wrote:

> On Sunday 06 September 2015 09:32:08 David Christensen wrote:
> > On 09/06/2015 02:55 AM, David Baron wrote:
> > > Now that the g++ business is largely behind us, want to start
> > > upgrading. Problem is that with that darned partitioning by the
> > > Debian installation, there is not enough room on /var to
> > > accomplish upgrade of such size.
> > 
> > https://lists.debian.org/debian-user/2015/08/msg01056.html
> > 
> > 
> > David
> 
> Thanks, but I know how to, do not want to, reinstall. Should not have
> to do so.
> 
> Thinking of moving the /var/tmp KDE stuff elsewhere and symlinking.
> This takes up a large plurality, even majority of /var, not needed
> before login and home is mounted. What about that?
> 

How close are you? If you upgrade, then clear the package cache, you
minimise the amount of work a dist-upgrade needs to do and maximise the
available space. If that isn't enough, you might manage to upgrade
groups of packages rather than all in one go. If you have a GUI, you
might find synaptic easier for that kind of work than aptitude or
apt-get.

You don't mention which distribution, but unstable certainly isn't in a
position to fully dist-upgrade at the moment, so I wouldn't have
thought that testing is either. After the g++ earthquake, we still have
the KDE tsunami to deal with. Libreoffice also cannot be upgraded, but
it has recently been in that state twice and recovered fairly quickly,
so it probably isn't a problem. But certainly in unstable, quite a few
packages which were stuck for a few weeks have now upgraded, and I
shifted about fifty this evening.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#157480

On Sunday 06 September 2015 20:45:02 Joe wrote:
> On Sun, 06 Sep 2015 21:54:13 +0300
> 
> David Baron <d_baron@012.net.il> wrote:
> > On Sunday 06 September 2015 09:32:08 David Christensen wrote:
> > > On 09/06/2015 02:55 AM, David Baron wrote:
> > > > Now that the g++ business is largely behind us, want to start
> > > > upgrading. Problem is that with that darned partitioning by the
> > > > Debian installation, there is not enough room on /var to
> > > > accomplish upgrade of such size.
> > > 
> > > https://lists.debian.org/debian-user/2015/08/msg01056.html
> > > 
> > > 
> > > David
> > 
> > Thanks, but I know how to, do not want to, reinstall. Should not have
> > to do so.
> > 
> > Thinking of moving the /var/tmp KDE stuff elsewhere and symlinking.
> > This takes up a large plurality, even majority of /var, not needed
> > before login and home is mounted. What about that?
> 
> How close are you? If you upgrade, then clear the package cache, you
> minimise the amount of work a dist-upgrade needs to do and maximise the
> available space. If that isn't enough, you might manage to upgrade
> groups of packages rather than all in one go. If you have a GUI, you
> might find synaptic easier for that kind of work than aptitude or
> apt-get.
> 
> You don't mention which distribution, but unstable certainly isn't in a
> position to fully dist-upgrade at the moment, so I wouldn't have
> thought that testing is either. After the g++ earthquake, we still have
> the KDE tsunami to deal with. Libreoffice also cannot be upgraded, but
> it has recently been in that state twice and recovered fairly quickly,
> so it probably isn't a problem. But certainly in unstable, quite a few
> packages which were stuck for a few weeks have now upgraded, and I
> shifted about fifty this evening.

I do an apt-get clear routinely. Just does not get me enough. Yes, unstable. 
Problem is, longer I wait, the larger the upgrade gets. I am not doing dist-
upgrade but so much of the stuff is interrelated that very few smaller groups 
of packages present themselves. I have about 500 meg available, just does not 
quite cut it.

Libreoffice and Texlive are two large groups. One idea might be to sacrifice them 
(I do not think I ever used the Tex), upgrade, and then reinstall the 
libreoffice which should then reinstall without a zillion other things. Maybe 
safer than playing with /var/tmp which is heavily subscribed by our favorite 
systemd. A couple of other large but independent packages can also be not 
upgraded, such as the html kde docs and such.

[toc] | [prev] | [next] | [standalone]

#157491

David Baron a écrit :
> Now that the g++ business is largely behind us, want to start upgrading. 
> Problem is that with that darned partitioning by the Debian installation, 
> there is not enough room on /var to accomplish upgrade of such size.

Too bad you did trust the Debian installer instead of using LVM and
leaving some space available for future needs. Worth thinking about for
your next installation.

> What can be done about this?
> 
> Note that to get an /opt, I bind this to a directory on my over-sized home.
> Same for /usr/local!
> These need not be mounted at boot or before home gets mounted so all this 
> kludge is well-behaved and transparent.

You can bind|link|whatever /var/cache/apt/archive to a filesystem with
enough free space.

[toc] | [prev] | [next] | [standalone]

#157503

> David Baron a écrit :
> > Now that the g++ business is largely behind us, want to start upgrading.
> > Problem is that with that darned partitioning by the Debian installation,
> > there is not enough room on /var to accomplish upgrade of such size.
> 
> Too bad you did trust the Debian installer instead of using LVM and
> leaving some space available for future needs. Worth thinking about for
> your next installation.
> 
What was presented for LVM did not look any better. Used LVM quite happily on 
previous installation (converted to it). However, if something goes awry, 
getting data out can be problematic.

> > What can be done about this?
> > 
> > Note that to get an /opt, I bind this to a directory on my over-sized
> > home.
> > Same for /usr/local!
> > These need not be mounted at boot or before home gets mounted so all this
> > kludge is well-behaved and transparent.
> 
> You can bind|link|whatever /var/cache/apt/archive to a filesystem with
> enough free space.

Running it this way right now, seems OK. Question: Is this directory needed at 
boot, i.e., before home is mounted (why I did not try this first off)??

If it does, can put it back when done. If OK, leave it this way.

[toc] | [prev] | [next] | [standalone]

#157506

David Baron a écrit :
>> David Baron a écrit :
>>> Problem is that with that darned partitioning by the Debian installation,
>>> there is not enough room on /var to accomplish upgrade of such size.
>>
>> Too bad you did trust the Debian installer instead of using LVM and
>> leaving some space available for future needs. Worth thinking about for
>> your next installation.
>>
> What was presented for LVM did not look any better.

Because you selected LVM in the assisted mode, which messes up sizes and
does not leave any free extents for future growth. You can still reduce
an oversized LV to free some extents but if the filesystem is ext2/3/4
it cannot be reduced online so it must be unmounted first. Depending on
the mount point, it may require to switch to single user mode or boot
from a maintenance system.

Knowing this, I always select the manual mode to set up LVM and leave
free space in the VG. It's worth the extra work. When I later find out
that /var (or whatever) has become too small, I just use free extents in
the VG to grow the related LV and filesystem. Online. No reboot, no
maintenance system, no partition resizing or moving needed.

>> You can bind|link|whatever /var/cache/apt/archive to a filesystem with
>> enough free space.
> 
> Running it this way right now, seems OK. Question: Is this directory needed at 
> boot, i.e., before home is mounted (why I did not try this first off)??

This directory is used by APT programs to store downloaded packages
files - not to update the package list. So unless some APT program
downloads packages at boot time, it's not needed.

[toc] | [prev] | [next] | [standalone]

#157510

On 07/09/15 17:42, Pascal Hambourg wrote:
> David Baron a écrit :
>>> David Baron a écrit :
>>>> Problem is that with that darned partitioning by the Debian installation,
>>>> there is not enough room on /var to accomplish upgrade of such size.
>>>
>>> Too bad you did trust the Debian installer instead of using LVM and
>>> leaving some space available for future needs. Worth thinking about for
>>> your next installation.
>>>
>> What was presented for LVM did not look any better.
> 
> Because you selected LVM in the assisted mode, which messes up sizes and
> does not leave any free extents for future growth. You can still reduce
> an oversized LV to free some extents but if the filesystem is ext2/3/4
> it cannot be reduced online so it must be unmounted first. Depending on
> the mount point, it may require to switch to single user mode or boot
> from a maintenance system.

Resize2fs is quite good at online resizing, not sure i'd do it on / but
i have lvresize and resize2fs /home and others many times without issue.

> Knowing this, I always select the manual mode to set up LVM and leave
> free space in the VG. It's worth the extra work. When I later find out
> that /var (or whatever) has become too small, I just use free extents in
> the VG to grow the related LV and filesystem. Online. No reboot, no
> maintenance system, no partition resizing or moving needed.

This is why I now always use LVM, online resizing and much safer than
resizing partitions.

[toc] | [prev] | [next] | [standalone]

#157512

dean a écrit :
> 
> On 07/09/15 17:42, Pascal Hambourg wrote:
>
>> Because you selected LVM in the assisted mode, which messes up sizes and
>> does not leave any free extents for future growth. You can still reduce
>> an oversized LV to free some extents but if the filesystem is ext2/3/4
>> it cannot be reduced online so it must be unmounted first. Depending on
>> the mount point, it may require to switch to single user mode or boot
>> from a maintenance system.
> 
> Resize2fs is quite good at online resizing, not sure i'd do it on / but
> i have lvresize and resize2fs /home and others many times without issue.

resizefs can extend a mounted filesystem but can reduce only an
unmounted filesystem. It is safe to extend / online, but you cannot of
course unmount / in the running system to reduce it.

Note that btrfs allows both online extension and reduction.

[toc] | [prev] | [next] | [standalone]

#157519

Quoting David Baron (d_baron@012.net.il):

Pascal, I believe, said:
> > You can bind|link|whatever /var/cache/apt/archive to a filesystem with
> > enough free space.
> 
> Running it this way right now, seems OK. Question: Is this directory needed at 
> boot, i.e., before home is mounted (why I did not try this first off)??
> 
> If it does, can put it back when done. If OK, leave it this way.

>From man apt-cache:

       -p, --pkg-cache
           Select the file to store the package cache. The package
           cache is the primary cache used by all operations.
           Configuration Item: Dir::Cache::pkgcache.

This appears to be the Right Way™.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#157522

David Wright a écrit :
> Quoting David Baron (d_baron@012.net.il):
> 
> Pascal, I believe, said:
>>> You can bind|link|whatever /var/cache/apt/archive to a filesystem with
>>> enough free space.
>> Running it this way right now, seems OK. Question: Is this directory needed at 
>> boot, i.e., before home is mounted (why I did not try this first off)??
>>
>> If it does, can put it back when done. If OK, leave it this way.
> 
>>From man apt-cache:
> 
>        -p, --pkg-cache
>            Select the file to store the package cache. The package
>            cache is the primary cache used by all operations.
>            Configuration Item: Dir::Cache::pkgcache.
> 
> This appears to be the Right Way.

I doubt it, since apt-cache is not involved in downloading .deb files,
so it's probably not the same cache. According to man apt-get, the
correct configuration item would rather be Dir::Cache::Archives.

[toc] | [prev] | [next] | [standalone]

#157551

On 9/7/15, Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
> David Wright a écrit :
>>
>>>From man apt-cache:
>>
>>        -p, --pkg-cache
>>            Select the file to store the package cache. The package
>>            cache is the primary cache used by all operations.
>>            Configuration Item: Dir::Cache::pkgcache.
>>
>> This appears to be the Right Way.
>
> I doubt it, since apt-cache is not involved in downloading .deb files,
> so it's probably not the same cache. According to man apt-get, the
> correct configuration item would rather be Dir::Cache::Archives.


*hmmmmmmmm........*

In seeing David's, I was already looking at "man apt-cache". Saw where
his is quoted from and was thinking......

#1) Ok, will have to test drive that so it's in the back of my mind if
it's ever needed.

Then next kneejerk reaction was....

#2) *WHY* are they using the term "file" and not "directory"?? That
doesn't sound right. The term "files" is NOT interchangeable with the
term "directory", and it seems like a technical writer would know that
distinction. Yeah, I know, "we" are the technical writers for
manpages, but still....... the file versus. directory distinction is a
very basic starting point in understanding Debian. :)

Moving on, now I'm looking at apt-get's manpage and thinking... Ok, do
what?! Doesn't that create some kind of conflict with apt-cache??

So I just kept flipping back and forth between the two man
pages....... and trying to really read and *comprehend* apt-cache's
one especially......

Is apt-cache's maybe really meaning *FILE*, as in each specific .deb
file, and not directory (aka "folder" in "other" operating systems)?

Just scratching my head out loud........

Cindy :)

-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs... off at the Fingertips on occasion.. *

[toc] | [prev] | [next] | [standalone]

#157593

Quoting Cindy-Sue Causey (butterflybytes@gmail.com):
> On 9/7/15, Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
> > David Wright a écrit :
> >>
> >>>From man apt-cache:
> >>
> >>        -p, --pkg-cache
> >>            Select the file to store the package cache. The package
> >>            cache is the primary cache used by all operations.
> >>            Configuration Item: Dir::Cache::pkgcache.
> >>
> >> This appears to be the Right Way.
> >
> > I doubt it, since apt-cache is not involved in downloading .deb files,
> > so it's probably not the same cache. According to man apt-get, the
> > correct configuration item would rather be Dir::Cache::Archives.
> 
> 
> *hmmmmmmmm........*
> 
> In seeing David's, I was already looking at "man apt-cache". Saw where
> his is quoted from and was thinking......
> 
> #1) Ok, will have to test drive that so it's in the back of my mind if
> it's ever needed.
> 
> Then next kneejerk reaction was....
> 
> #2) *WHY* are they using the term "file" and not "directory"?? That
> doesn't sound right. The term "files" is NOT interchangeable with the
> term "directory", and it seems like a technical writer would know that
> distinction. Yeah, I know, "we" are the technical writers for
> manpages, but still....... the file versus. directory distinction is a
> very basic starting point in understanding Debian. :)
> 
> Moving on, now I'm looking at apt-get's manpage and thinking... Ok, do
> what?! Doesn't that create some kind of conflict with apt-cache??
> 
> So I just kept flipping back and forth between the two man
> pages....... and trying to really read and *comprehend* apt-cache's
> one especially......
> 
> Is apt-cache's maybe really meaning *FILE*, as in each specific .deb
> file, and not directory (aka "folder" in "other" operating systems)?

One way of answering this question (and the earlier one) is not to read
the (arguably confusing) documentation but to ask Apt itself. Try typing
$ apt-config dump | less
and look at what the defaults are (subject to any changes you've made).

Dir::Cache "var/cache/apt/";
Dir::Cache::archives "archives/";
Dir::Cache::srcpkgcache "srcpkgcache.bin";
Dir::Cache::pkgcache "pkgcache.bin";

You can see here that Dir:: is the "Directories section", but not all
the values have to be directories (though some are).

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#157592

Quoting Pascal Hambourg (pascal@plouf.fr.eu.org):
> David Wright a écrit :
> > Quoting David Baron (d_baron@012.net.il):
> > 
> > Pascal, I believe, said:
> >>> You can bind|link|whatever /var/cache/apt/archive to a filesystem with
> >>> enough free space.
> >> Running it this way right now, seems OK. Question: Is this directory needed at 
> >> boot, i.e., before home is mounted (why I did not try this first off)??
> >>
> >> If it does, can put it back when done. If OK, leave it this way.
> > 
> >>From man apt-cache:
> > 
> >        -p, --pkg-cache
> >            Select the file to store the package cache. The package
> >            cache is the primary cache used by all operations.
> >            Configuration Item: Dir::Cache::pkgcache.
> > 
> > This appears to be the Right Way.
> 
> I doubt it, since apt-cache is not involved in downloading .deb files,
> so it's probably not the same cache. According to man apt-get, the
> correct configuration item would rather be Dir::Cache::Archives.

You're quite right; my mistake. Dir::Cache::Archives is the one bit of
Dir::Cache not documented there because it doesn't interest apt-cache.

For some reason, the DIRECTORIES part of   man apt.conf   doesn't have
subheadings like the rest, making it easier to overlook Dir::Cache there.

Cheers,
David.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web