Re: Apt upgrade problem

[Charles Curley]

On Sun, 16 Oct 2022 23:44:00 +0100
Mark Fletcher  wrote:

> "apt list --upgradable" shows a new version of the Amazon Workspaces
> client, version 4.3.0.1766. It also shows that there is one more
> version available.

This may be a silly question, but have you checked with Amazon customer
support? Assuming such beast exists.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Apt upgrade problem

[hede]

On Sun, 16 Oct 2022 23:44:00 +0100 Mark Fletcher  wrote:

> After "sudo apt update", the system informs me there is 1 package that can
> be upgraded.
> 
> "sudo apt upgrade" reports nothing to do, 0 packages upgraded, 0 newly
> installed, 0 to remove and 0 not upgraded...

One possible reason could be the new package conflict with some other installed 
package. "apt upgrade" doesn't remove packages. Maybe "apt full-upgrade" is at 
hand?

Maybe also "apt policy workspacesclient" gives some help. 

Or maybe "apt install workspacesclient=4.3.0.1766" installs the current version?

(sorry, just some ideas and no safe solution from me, as I'm not using amazons 
workspaceclient)

regards 
hede

Re: Apt upgrade problem

[David Wright]

On Sun 16 Oct 2022 at 23:44:00 (+0100), Mark Fletcher wrote:
> 
> Tonight I am seeing a behaviour pattern in my Debian Bullseye system that I
> have not seen before.
> 
> After "sudo apt update", the system informs me there is 1 package that can
> be upgraded.
> 
> "sudo apt upgrade" reports nothing to do, 0 packages upgraded, 0 newly
> installed, 0 to remove and 0 not upgraded...
> 
> "apt list --upgradable" shows a new version of the Amazon Workspaces
> client, version 4.3.0.1766. It also shows that there is one more version
> available.
> 
> "apt list -a --upgradable" shows:
> 
> Listing... Done
> workspacesclient/unknown 4.3.0.1766 amd64 [upgradable from: 4.2.0.1665]
> workspacesclient/now 4.2.0.1665 amd64 [installed,upgradable to: 4.3.0.1766]
> 
> "sudo apt install" reports:
> 
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
> 
> System doesn't seem to want to install the new version of the Amazon
> workspaces client. I'm assuming some dependency not known to the system is
> needed for the new version. However I also note the /unknown after the
> package name in the new version, which is /now in the current version. I am
> not sure what that is, but presumably /unknown isn't good... Can anyone
> suggest an approach to investigate why this upgrade won't happen?
> 
> In case important, Amazon workspaces client is included in my package list
> by "amazon-workspaces-clients.list" in /etc/apt/sources.list.d/ :
> 
> deb [arch=amd64] https://d3nt0h4h6pmmc4.cloudfront.net/ubuntu bionic main
> 
> That comes from the install instructions page of the Amazon Workspaces
> client. It did occur to me that perhaps the new version needs some
> additional repository, so I went back and checked but the installation
> instructions have not changed, so it seems not.

AFAIK the   apt list   command is only examining your lists that you
updated, whereas   apt install   is looking for the package itself.

So, apart from just trying again later, I would check if the package
is actually in the archive mirror you're using (or any other).
I don't think it would be the first time that a package's existence
is glimpsed in the lists before it actually gets transferred into
a particular mirror.

(I don't know anything about the ubuntu archives and that reference.)

Cheers,
David.

Apt upgrade problem

[Mark Fletcher]

Hi

Tonight I am seeing a behaviour pattern in my Debian Bullseye system that I
have not seen before.

After "sudo apt update", the system informs me there is 1 package that can
be upgraded.

"sudo apt upgrade" reports nothing to do, 0 packages upgraded, 0 newly
installed, 0 to remove and 0 not upgraded...

"apt list --upgradable" shows a new version of the Amazon Workspaces
client, version 4.3.0.1766. It also shows that there is one more version
available.

"apt list -a --upgradable" shows:

Listing... Done
workspacesclient/unknown 4.3.0.1766 amd64 [upgradable from: 4.2.0.1665]
workspacesclient/now 4.2.0.1665 amd64 [installed,upgradable to: 4.3.0.1766]

"sudo apt install" reports:

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.

System doesn't seem to want to install the new version of the Amazon
workspaces client. I'm assuming some dependency not known to the system is
needed for the new version. However I also note the /unknown after the
package name in the new version, which is /now in the current version. I am
not sure what that is, but presumably /unknown isn't good... Can anyone
suggest an approach to investigate why this upgrade won't happen?

In case important, Amazon workspaces client is included in my package list
by "amazon-workspaces-clients.list" in /etc/apt/sources.list.d/ :

deb [arch=amd64] https://d3nt0h4h6pmmc4.cloudfront.net/ubuntu bionic main

That comes from the install instructions page of the Amazon Workspaces
client. It did occur to me that perhaps the new version needs some
additional repository, so I went back and checked but the installation
instructions have not changed, so it seems not.

Thanks in advance

Mark

Re: Buster to Bullseye upgrade problem

[Gareth Evans]

On Sun 22 Aug 2021, at 15:37, David Wright  wrote:
> On Sun 22 Aug 2021 at 13:18:38 (+0100), Gareth Evans wrote:
> > On Sun 22 Aug 2021, at 05:36, David Wright  wrote:
> > > On Fri 20 Aug 2021 at 14:13:55 (+0100), Gareth Evans wrote:
> 
> > > > There is also no explanation in term.log, syslog or dpkg.log for the 
> > > > second interruption:
> > > > 
> > > > --
> > > > Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
> > > > [upgrade interrupted...]
> > > > W: APT had planned for dpkg to do more than it reported back (5014 vs 
> > > > 5047).
> > > >Affected packages: texlive-fonts-recommended:amd64 
> > > > texlive-lang-greek:amd64 texlive-latex-base:amd64 
> > > > texlive-latex-extra:amd64 texlive-latex-recommended:amd64 
> > > > texlive-pictures:amd64 texlive-plain-generic:amd64 texlive-science:amd64
> > > > ---
> 
> [ … ]
> 
> > > I'm no help here, as I've never seen output like that,
> > > neither the "[ … ]", nor the "W: APT had planned …".
> > > Is that output, with [upgrade interrupted...], a verbatim
> > > copy/paste? Did this message appear spontaneously, or
> > > because you yourself interrupted the process?
> > 
> > "[...]" was just my way of showing output until this point has not been 
> > included in the paste, or that the paste includes gaps in output.  I use 
> > this by habit from academic writing but perhaps  might be better for 
> > this purpose?  
> > 
> > The interrupt and following "W: APT had planned..." appeared spontaneously. 
> >  The upgrade stops, and [...] here stands in for etckeeper output, which I 
> > removed as noisy.
> 
> Both the < … > and [ … ] are fine; it's just that 

> [...] "upgrade
> interrupted", in a passive construction, avoids specifying the agent,
> which is what we need to know: was it you or APT whodunit.

It wasn't me, but an apparent breakage.

> 
> [ … ]
> 
> > I have just noticed that the logged action after which it trips up:
> > 
> > Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
> > 
> > is related to what may be another problem of sorts.  php7.3 packages are 
> > removed as part of the upgrade but the config (mods-[enabled]) isn't 
> > changed.  Apache2 won't start after upgrading until I
> > 
> > a2dismod *php*7.3*
> > 
> > >From /var/log/syslog: 
> > Aug 22 00:29:58 qwerty systemd[1]: Starting The Apache HTTP Server...
> > Aug 22 00:29:58 qwerty apachectl[59333]: apache2: Syntax error on line 146 
> > of /etc/apache2/apache2.conf: Syntax error on line 3 of 
> > /etc/apache2/mods-enabled/php7.3.load: Cannot load 
> > /usr/lib/apache2/modules/libphp7.3.so into server: 
> > /usr/lib/apache2/modules/libphp7.3.so: cannot open shared object file: No 
> > such file or directory
> > Aug 22 00:29:58 qwerty apachectl[59330]: Action 'start' failed.
> > 
> > Is it normal to have to do this sort of thing after a major upgrade?  If 
> > not, could a hiccup here be related to the upgrade breaking?
> 
> Well, the apache version is upgraded from 2.4.38 to 2.4.46 during the
> transition from buster to bullseye, and although APT will look after
> upgrading its conffiles, "conffiles" are those configuring the apache
> software, not the mods-available/enabled that configure the service.
> 
> People who run apache servers may have their own opinions on the
> correct procedure. My own would be that you should be sure a
> configuration is correct before you run that service, and testing
> it is not best done during a major upgrade, but when the dust has
> settled.

What do you mean by "when the dust has settled" in this context?  

Thanks,
Gareth

> 
> Cheers,
> David.
> 
> 

Re: Buster to Bullseye upgrade problem

[David Wright]

On Sun 22 Aug 2021 at 13:18:38 (+0100), Gareth Evans wrote:
> On Sun 22 Aug 2021, at 05:36, David Wright  wrote:
> > On Fri 20 Aug 2021 at 14:13:55 (+0100), Gareth Evans wrote:

> > > There is also no explanation in term.log, syslog or dpkg.log for the 
> > > second interruption:
> > > 
> > > --
> > > Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
> > > [upgrade interrupted...]
> > > W: APT had planned for dpkg to do more than it reported back (5014 vs 
> > > 5047).
> > >Affected packages: texlive-fonts-recommended:amd64 
> > > texlive-lang-greek:amd64 texlive-latex-base:amd64 
> > > texlive-latex-extra:amd64 texlive-latex-recommended:amd64 
> > > texlive-pictures:amd64 texlive-plain-generic:amd64 texlive-science:amd64
> > > ---

[ … ]

> > I'm no help here, as I've never seen output like that,
> > neither the "[ … ]", nor the "W: APT had planned …".
> > Is that output, with [upgrade interrupted...], a verbatim
> > copy/paste? Did this message appear spontaneously, or
> > because you yourself interrupted the process?
> 
> "[...]" was just my way of showing output until this point has not been 
> included in the paste, or that the paste includes gaps in output.  I use this 
> by habit from academic writing but perhaps  might be better for this 
> purpose?  
> 
> The interrupt and following "W: APT had planned..." appeared spontaneously.  
> The upgrade stops, and [...] here stands in for etckeeper output, which I 
> removed as noisy.

Both the < … > and [ … ] are fine; it's just that "upgrade
interrupted", in a passive construction, avoids specifying the agent,
which is what we need to know: was it you or APT whodunit.

[ … ]

> I have just noticed that the logged action after which it trips up:
> 
> Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
> 
> is related to what may be another problem of sorts.  php7.3 packages are 
> removed as part of the upgrade but the config (mods-[enabled]) isn't changed. 
>  Apache2 won't start after upgrading until I
> 
> a2dismod *php*7.3*
> 
> >From /var/log/syslog: 
> Aug 22 00:29:58 qwerty systemd[1]: Starting The Apache HTTP Server...
> Aug 22 00:29:58 qwerty apachectl[59333]: apache2: Syntax error on line 146 of 
> /etc/apache2/apache2.conf: Syntax error on line 3 of 
> /etc/apache2/mods-enabled/php7.3.load: Cannot load 
> /usr/lib/apache2/modules/libphp7.3.so into server: 
> /usr/lib/apache2/modules/libphp7.3.so: cannot open shared object file: No 
> such file or directory
> Aug 22 00:29:58 qwerty apachectl[59330]: Action 'start' failed.
> 
> Is it normal to have to do this sort of thing after a major upgrade?  If not, 
> could a hiccup here be related to the upgrade breaking?

Well, the apache version is upgraded from 2.4.38 to 2.4.46 during the
transition from buster to bullseye, and although APT will look after
upgrading its conffiles, "conffiles" are those configuring the apache
software, not the mods-available/enabled that configure the service.

People who run apache servers may have their own opinions on the
correct procedure. My own would be that you should be sure a
configuration is correct before you run that service, and testing
it is not best done during a major upgrade, but when the dust has
settled.

Cheers,
David.

Re: Buster to Bullseye upgrade problem

[Gareth Evans]

On Sun 22 Aug 2021, at 13:18, Gareth Evans  wrote:
> On Sun 22 Aug 2021, at 05:36, David Wright  wrote:
> > On Fri 20 Aug 2021 at 14:13:55 (+0100), Gareth Evans wrote:
> > > On Fri 20 Aug 2021, at 04:45, David Wright  
> > > wrote:
> > > > On Thu 19 Aug 2021 at 07:42:56 (+0100), Gareth Evans wrote:
> > 
> > > $ apt policy pitivi
> > > pitivi:
> > >   Installed: 0.999-1+b1
> > >   Candidate: 0.999-1+b1
> > >   Version table:
> > >  *** 0.999-1+b1 500
> > > 500 http://deb.debian.org/debian buster/main amd64 Packages
> > > 100 /var/lib/dpkg/status
> > > 
> > > So pitivi 0.999 as installed is a Buster package, and gir* is installed 
> > > during the upgrade as a dependency of Bullseye's newer pitivi version.
> > > 
> > > [Bullseye] 
> > > $ aptitude why gir1.2-gst-plugins-bad-1.0
> > > i   pitivi Depends gir1.2-gst-plugins-bad-1.0 (>= 1.18.0)
> > > 
> > > 
> > > The first upgrade interruption issue (repeated here for clarity):
> > > 
> > > --
> > > Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
> > > dpkg: error processing archive 
> > > /tmp/apt-dpkg-install-YeCJ7K/28-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb
> > >  (--unpack):
> > >  trying to overwrite 
> > > '/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib', 
> > > which is also in package pitivi 0.999-1+b1
> > > dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> > > --
> > > 
> > > appears to be a file conflict, per 
> > > 
> > > https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#file-conflicts
> > > 
> > > which includes that "File conflicts should not occur if you upgrade from 
> > > a “pure” buster system..."
> > > 
> > > So I would like to know if apt is not handling this properly, or if the 
> > > scenario of a file changing packages (see David's previous email) is an 
> > > expected exception to the (sort of) rule.
> > 
> 
> Hi David,
> 
> > As Sven posted, it looks as if #965007 is the cause. A snag is
> > that, because the bug has been closed, it no longer shows up on
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965007
> > Moral: for major upgrades, always set "Archived and Unarchived"
> > on https://www.debian.org/Bugs/ because these sorts of bug are
> > likely to have been fixed by the time unstable→stable arrives.
> > 
> > But the workaround is to recall reading (!) § 4.5.4 in the Release
> > Notes, and force things as shown there.
> 
> I did see that but had already managed to make progress with apt 
> install --fix-broken before twigging a file conflict (which is obvious 
> once realised!)
> 
> > 
> > > There is also no explanation in term.log, syslog or dpkg.log for the 
> > > second interruption:
> > > 
> > > --
> > > Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
> > > [upgrade interrupted...]
> > > W: APT had planned for dpkg to do more than it reported back (5014 vs 
> > > 5047).
> > >Affected packages: texlive-fonts-recommended:amd64 
> > > texlive-lang-greek:amd64 texlive-latex-base:amd64 
> > > texlive-latex-extra:amd64 texlive-latex-recommended:amd64 
> > > texlive-pictures:amd64 texlive-plain-generic:amd64 texlive-science:amd64
> > > ---
> > > 
> > > which occurs even if pitivi is removed before upgrading, and the warning 
> > > doesn't appear in term.log either.
> > > 
> > > If anyone can shed further light, I would be interested, but it's not 
> > > ultimately a roadblock to upgrading so possibly not worth worrying about.
> > 
> > I'm no help here, as I've never seen output like that,
> > neither the "[ … ]", nor the "W: APT had planned …".
> > Is that output, with [upgrade interrupted...], a verbatim
> > copy/paste? Did this message appear spontaneously, or
> > because you yourself interrupted the process?
> 
> "[...]" was just my way of showing output until this point has not been 
> included in the paste, or that the paste includes gaps in output.  I 
> use this by habit from academic writing but perhaps  might be 
> better for this purpose?  
> 
> The interrupt and following "W: APT had planned..." appeared 
> spontaneously.  The upgrade stops, and [...] here stands in for 
> etckeeper output, which I removed as noisy.
> 
> > 
> > ISTR that history.log records intent, not achievement, whereas
> > term.log can obviously /only/ log achievement, so a comparison
> > of their two lists of packages for the interrupted step might give
> > a clue, perhaps a more fruitful one than just the list of Affected
> > packages quoted above.
> 
> I have just noticed that the logged action after which it trips up:
> 
> Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
> 
> is related to what may be another problem of sorts.  php7.3 packages 
> are removed as part of the upgrade but the config (mods-available) 
> isn't changed.  Apache2 won't start after upgrading until I
> 
> a2dismod *php*7.3*
> 
> >From /var/log/syslog: 
> Aug 22 00:29:58 qwerty systemd[1]: Starting The Apache HTTP 

Re: Buster to Bullseye upgrade problem

[Gareth Evans]

On Sun 22 Aug 2021, at 05:36, David Wright  wrote:
> On Fri 20 Aug 2021 at 14:13:55 (+0100), Gareth Evans wrote:
> > On Fri 20 Aug 2021, at 04:45, David Wright  wrote:
> > > On Thu 19 Aug 2021 at 07:42:56 (+0100), Gareth Evans wrote:
> 
> > $ apt policy pitivi
> > pitivi:
> >   Installed: 0.999-1+b1
> >   Candidate: 0.999-1+b1
> >   Version table:
> >  *** 0.999-1+b1 500
> > 500 http://deb.debian.org/debian buster/main amd64 Packages
> > 100 /var/lib/dpkg/status
> > 
> > So pitivi 0.999 as installed is a Buster package, and gir* is installed 
> > during the upgrade as a dependency of Bullseye's newer pitivi version.
> > 
> > [Bullseye] 
> > $ aptitude why gir1.2-gst-plugins-bad-1.0
> > i   pitivi Depends gir1.2-gst-plugins-bad-1.0 (>= 1.18.0)
> > 
> > 
> > The first upgrade interruption issue (repeated here for clarity):
> > 
> > --
> > Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
> > dpkg: error processing archive 
> > /tmp/apt-dpkg-install-YeCJ7K/28-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb
> >  (--unpack):
> >  trying to overwrite 
> > '/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib', 
> > which is also in package pitivi 0.999-1+b1
> > dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> > --
> > 
> > appears to be a file conflict, per 
> > 
> > https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#file-conflicts
> > 
> > which includes that "File conflicts should not occur if you upgrade from a 
> > “pure” buster system..."
> > 
> > So I would like to know if apt is not handling this properly, or if the 
> > scenario of a file changing packages (see David's previous email) is an 
> > expected exception to the (sort of) rule.
> 

Hi David,

> As Sven posted, it looks as if #965007 is the cause. A snag is
> that, because the bug has been closed, it no longer shows up on
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965007
> Moral: for major upgrades, always set "Archived and Unarchived"
> on https://www.debian.org/Bugs/ because these sorts of bug are
> likely to have been fixed by the time unstable→stable arrives.
> 
> But the workaround is to recall reading (!) § 4.5.4 in the Release
> Notes, and force things as shown there.

I did see that but had already managed to make progress with apt install 
--fix-broken before twigging a file conflict (which is obvious once realised!)

> 
> > There is also no explanation in term.log, syslog or dpkg.log for the second 
> > interruption:
> > 
> > --
> > Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
> > [upgrade interrupted...]
> > W: APT had planned for dpkg to do more than it reported back (5014 vs 5047).
> >Affected packages: texlive-fonts-recommended:amd64 
> > texlive-lang-greek:amd64 texlive-latex-base:amd64 texlive-latex-extra:amd64 
> > texlive-latex-recommended:amd64 texlive-pictures:amd64 
> > texlive-plain-generic:amd64 texlive-science:amd64
> > ---
> > 
> > which occurs even if pitivi is removed before upgrading, and the warning 
> > doesn't appear in term.log either.
> > 
> > If anyone can shed further light, I would be interested, but it's not 
> > ultimately a roadblock to upgrading so possibly not worth worrying about.
> 
> I'm no help here, as I've never seen output like that,
> neither the "[ … ]", nor the "W: APT had planned …".
> Is that output, with [upgrade interrupted...], a verbatim
> copy/paste? Did this message appear spontaneously, or
> because you yourself interrupted the process?

"[...]" was just my way of showing output until this point has not been 
included in the paste, or that the paste includes gaps in output.  I use this 
by habit from academic writing but perhaps  might be better for this 
purpose?  

The interrupt and following "W: APT had planned..." appeared spontaneously.  
The upgrade stops, and [...] here stands in for etckeeper output, which I 
removed as noisy.

> 
> ISTR that history.log records intent, not achievement, whereas
> term.log can obviously /only/ log achievement, so a comparison
> of their two lists of packages for the interrupted step might give
> a clue, perhaps a more fruitful one than just the list of Affected
> packages quoted above.

I have just noticed that the logged action after which it trips up:

Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...

is related to what may be another problem of sorts.  php7.3 packages are 
removed as part of the upgrade but the config (mods-available) isn't changed.  
Apache2 won't start after upgrading until I

a2dismod *php*7.3*

>From /var/log/syslog: 
Aug 22 00:29:58 qwerty systemd[1]: Starting The Apache HTTP Server...
Aug 22 00:29:58 qwerty apachectl[59333]: apache2: Syntax error on line 146 of 
/etc/apache2/apache2.conf: Syntax error on line 3 of 
/etc/apache2/mods-enabled/php7.3.load: Cannot load 
/usr/lib/apache2/modules/libphp7.3.so into server: 
/usr/lib/apache2/modules/libphp7.3.so: cannot open shared 

Re: Buster to Bullseye upgrade problem

[David Wright]

On Fri 20 Aug 2021 at 14:13:55 (+0100), Gareth Evans wrote:
> On Fri 20 Aug 2021, at 04:45, David Wright  wrote:
> > On Thu 19 Aug 2021 at 07:42:56 (+0100), Gareth Evans wrote:

> $ apt policy pitivi
> pitivi:
>   Installed: 0.999-1+b1
>   Candidate: 0.999-1+b1
>   Version table:
>  *** 0.999-1+b1 500
> 500 http://deb.debian.org/debian buster/main amd64 Packages
> 100 /var/lib/dpkg/status
> 
> So pitivi 0.999 as installed is a Buster package, and gir* is installed 
> during the upgrade as a dependency of Bullseye's newer pitivi version.
> 
> [Bullseye] 
> $ aptitude why gir1.2-gst-plugins-bad-1.0
> i   pitivi Depends gir1.2-gst-plugins-bad-1.0 (>= 1.18.0)
> 
> 
> The first upgrade interruption issue (repeated here for clarity):
> 
> --
> Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
> dpkg: error processing archive 
> /tmp/apt-dpkg-install-YeCJ7K/28-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb 
> (--unpack):
>  trying to overwrite 
> '/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib', which 
> is also in package pitivi 0.999-1+b1
> dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> --
> 
> appears to be a file conflict, per 
> 
> https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#file-conflicts
> 
> which includes that "File conflicts should not occur if you upgrade from a 
> “pure” buster system..."
> 
> So I would like to know if apt is not handling this properly, or if the 
> scenario of a file changing packages (see David's previous email) is an 
> expected exception to the (sort of) rule.

As Sven posted, it looks as if #965007 is the cause. A snag is
that, because the bug has been closed, it no longer shows up on
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965007
Moral: for major upgrades, always set "Archived and Unarchived"
on https://www.debian.org/Bugs/ because these sorts of bug are
likely to have been fixed by the time unstable→stable arrives.

But the workaround is to recall reading (!) § 4.5.4 in the Release
Notes, and force things as shown there.

> There is also no explanation in term.log, syslog or dpkg.log for the second 
> interruption:
> 
> --
> Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
> [upgrade interrupted...]
> W: APT had planned for dpkg to do more than it reported back (5014 vs 5047).
>Affected packages: texlive-fonts-recommended:amd64 
> texlive-lang-greek:amd64 texlive-latex-base:amd64 texlive-latex-extra:amd64 
> texlive-latex-recommended:amd64 texlive-pictures:amd64 
> texlive-plain-generic:amd64 texlive-science:amd64
> ---
> 
> which occurs even if pitivi is removed before upgrading, and the warning 
> doesn't appear in term.log either.
> 
> If anyone can shed further light, I would be interested, but it's not 
> ultimately a roadblock to upgrading so possibly not worth worrying about.

I'm no help here, as I've never seen output like that,
neither the "[ … ]", nor the "W: APT had planned …".
Is that output, with [upgrade interrupted...], a verbatim
copy/paste? Did this message appear spontaneously, or
because you yourself interrupted the process?

ISTR that history.log records intent, not achievement, whereas
term.log can obviously /only/ log achievement, so a comparison
of their two lists of packages for the interrupted step might give
a clue, perhaps a more fruitful one than just the list of Affected
packages quoted above.

Cheers,
David.

Re: Buster to Bullseye upgrade problem

[Gareth Evans]

On Sat 21 Aug 2021, at 13:42, Sven Hartge  wrote:
> Gareth Evans  wrote:
> 
> > So I would like to know if apt is not handling this properly, or if
> > the scenario of a file changing packages (see David's previous email)
> > is an expected exception to the (sort of) rule.
> 

Hi Sven,

> > Shouldn't pitivi 0.999 be disregarded anyway as it's being upgraded?
> 
> No, because Debian Policy says that partial upgrades are supported and
> must work.

Interesting, thanks.  I will have a look at [1,2,3] which seem relevant - any 
good refs would be appreciated, even for other distros if the 
concepts/techniques are similar.

Many thanks,
Gareth

[1] https://www.debian.org/doc/debian-policy/policy.pdf

[2] https://wiki.debian.org/Packaging/Intro

[3] https://www.debian.org/doc/manuals/developers-reference/index.en.html

> 
> > It's not a conflict involving two Bullseye packages, nor with one from
> > Bullseye and one held/pinned etc, so I don't see why it should happen.
> 
> This might be a genuine bug in one of the two packages here, where a
> Conflict/Breaks/Replaces dependendy was needed to move a file from one
> package to another.
> 
> I think https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965007 is part
> of that problem.
> 
> Grüße,
> S°
> 
> -- 
> Sigmentation fault. Core dumped.
> 
> 

Re: Buster to Bullseye upgrade problem

[Sven Hartge]

Gareth Evans  wrote:

> So I would like to know if apt is not handling this properly, or if
> the scenario of a file changing packages (see David's previous email)
> is an expected exception to the (sort of) rule.

> Shouldn't pitivi 0.999 be disregarded anyway as it's being upgraded?

No, because Debian Policy says that partial upgrades are supported and
must work.

> It's not a conflict involving two Bullseye packages, nor with one from
> Bullseye and one held/pinned etc, so I don't see why it should happen.

This might be a genuine bug in one of the two packages here, where a
Conflict/Breaks/Replaces dependendy was needed to move a file from one
package to another.

I think https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965007 is part
of that problem.

Grüße,
S°

-- 
Sigmentation fault. Core dumped.

Re: Buster to Bullseye upgrade problem

[Gareth Evans]

On Fri 20 Aug 2021, at 04:45, David Wright  wrote:
> On Thu 19 Aug 2021 at 07:42:56 (+0100), Gareth Evans wrote:
> > On Thu 19 Aug 2021, at 05:50, David Wright  wrote:
> > > On Thu 19 Aug 2021 at 04:00:04 (+0100), Gareth Evans wrote:
> > > > On Wed 18 Aug 2021, at 23:33, piorunz  wrote:
> > > > > On 18/08/2021 16:14, Gareth Evans wrote:
> > > > > > Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
> > > > > > [1mdpkg:[0m error processing archive 
> > > > > > /tmp/apt-dpkg-install-Un4rDW/28-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb
> > > > > >  (--unpack):
> > > > > >   trying to overwrite 
> > > > > > '/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib',
> > > > > >  which is also in package pitivi 0.999-1+b1
> > > > > > [1mdpkg-deb:[0m [1;31merror:[0m paste subprocess was killed by 
> > > > > > signal (Broken pipe)
> > > > >
> > > > > IMO that's the source of your problem.
> > > > > You have two packages fighting to overwrite the same file. You should
> > > > > inspect them.
> > > > > Are you sure they come from buster, not from foreign repository?
> > > > 
> > > > Apparently they are both from Buster.
> > > 
> > > I'm afraid not. You need to check the version numbers more carefully.
> > 

Hello again,

Thanks David, for your clear explanation of the problem.

> > I meant the packages (gir1.2-gst-plugins-bad-1.0, pitivi) being upgraded, 
> > rather than the versions replacing them, were both from Buster at the point 
> > of the upgrade (weren't they?)
> 
> One might assume so, but only you can check that ...

I was mistaken in thinking that gir1.2-gst-plugins-bad-1.0 was installed in 
Buster in the first place.

[Buster]
$ apt policy gir*bad*
gir1.2-gst-plugins-bad-1.0:
  Installed: (none)
  Candidate: 1.14.4-1+deb10u2
  Version table:
 1.14.4-1+deb10u2 500
500 http://deb.debian.org/debian buster/main amd64 Packages
500 http://security.debian.org/debian-security buster/updates/main 
amd64 Packages

$ aptitude why gir1.2-gst-plugins-bad-1.0
Not currently installed
The candidate version 1.14.4-1+deb10u2 has priority optional
No dependencies require to install gir1.2-gst-plugins-bad-1.0

$ apt policy pitivi
pitivi:
  Installed: 0.999-1+b1
  Candidate: 0.999-1+b1
  Version table:
 *** 0.999-1+b1 500
500 http://deb.debian.org/debian buster/main amd64 Packages
100 /var/lib/dpkg/status

So pitivi 0.999 as installed is a Buster package, and gir* is installed during 
the upgrade as a dependency of Bullseye's newer pitivi version.

[Bullseye] 
$ aptitude why gir1.2-gst-plugins-bad-1.0
i   pitivi Depends gir1.2-gst-plugins-bad-1.0 (>= 1.18.0)


The first upgrade interruption issue (repeated here for clarity):

--
Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-YeCJ7K/28-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb 
(--unpack):
 trying to overwrite 
'/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib', which 
is also in package pitivi 0.999-1+b1
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
--

appears to be a file conflict, per 

https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#file-conflicts

which includes that "File conflicts should not occur if you upgrade from a 
“pure” buster system..."

So I would like to know if apt is not handling this properly, or if the 
scenario of a file changing packages (see David's previous email) is an 
expected exception to the (sort of) rule.

Shouldn't pitivi 0.999 be disregarded anyway as it's being upgraded?  It's not 
a conflict involving two Bullseye packages, nor with one from Bullseye and one 
held/pinned etc, so I don't see why it should happen.

FWIW I followed s4.2 of the release notes ("start from pure Debian") 
meticulously
https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#system-status

as well as running the commands kindly suggested by piorunz:

> On Wed 18 Aug 2021, at 23:33, piorunz  wrote:
> [...]
> check if any packages are newer than repository (possibly foreign)
> apt-show-versions | grep newer
> 
> check if any packages are foreign (not from Debian)
> aptitude search '~i(!~ODebian)'

There is also no explanation in term.log, syslog or dpkg.log for the second 
interruption:

--
Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
[upgrade interrupted...]
W: APT had planned for dpkg to do more than it reported back (5014 vs 5047).
   Affected packages: texlive-fonts-recommended:amd64 texlive-lang-greek:amd64 
texlive-latex-base:amd64 texlive-latex-extra:amd64 
texlive-latex-recommended:amd64 texlive-pictures:amd64 
texlive-plain-generic:amd64 texlive-science:amd64
---

which occurs even if pitivi is removed before upgrading, and the warning 
doesn't appear in term.log either.

If anyone can shed further light, I would be interested, but it's not 
ultimately a roadblock to upgrading so possibly not worth worrying 

Re: Buster to Bullseye upgrade problem

[Gareth Evans]

On Fri 20 Aug 2021, at 12:32, Greg Wooledge  wrote:
> On Thu, Aug 19, 2021 at 10:45:57PM -0500, David Wright wrote:
> > One might assume so, but only you can check that. There are two logs
> > of the upgrade. /var/log/apt/history.log (and its predecessors) shows
> > the command issued, followed by the packages affected, with the old
> > and new version numbers in parentheses. /var/log/apt/term.log (and its
> > predecessors) shows the various packages being unpacked and then set
> > up.
> 
> Huh.  I didn't know about the terminal session logs.  Nifty.
> 

> 'Twould be nice if it showed the command which was typed before each
> logged session, but still... nifty.

You may be aware of "script" which I have found useful for that. You have to 
overlook gibberishy characters though, as backspace and other special chars are 
included in the output file.

https://linux.die.net/man/1/script

You can set it up to run with new terminals, but I can't find the instructions 
to do so.

Kind regards
Gareth

Re: Buster to Bullseye upgrade problem

[Greg Wooledge]

On Thu, Aug 19, 2021 at 10:45:57PM -0500, David Wright wrote:
> One might assume so, but only you can check that. There are two logs
> of the upgrade. /var/log/apt/history.log (and its predecessors) shows
> the command issued, followed by the packages affected, with the old
> and new version numbers in parentheses. /var/log/apt/term.log (and its
> predecessors) shows the various packages being unpacked and then set
> up.

Huh.  I didn't know about the terminal session logs.  Nifty.

'Twould be nice if it showed the command which was typed before each
logged session, but still... nifty.

Re: Buster to Bullseye upgrade problem

[David Wright]

On Thu 19 Aug 2021 at 07:42:56 (+0100), Gareth Evans wrote:
> On Thu 19 Aug 2021, at 05:50, David Wright  wrote:
> > On Thu 19 Aug 2021 at 04:00:04 (+0100), Gareth Evans wrote:
> > > On Wed 18 Aug 2021, at 23:33, piorunz  wrote:
> > > > On 18/08/2021 16:14, Gareth Evans wrote:
> > > > > Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
> > > > > [1mdpkg:[0m error processing archive 
> > > > > /tmp/apt-dpkg-install-Un4rDW/28-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb
> > > > >  (--unpack):
> > > > >   trying to overwrite 
> > > > > '/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib',
> > > > >  which is also in package pitivi 0.999-1+b1
> > > > > [1mdpkg-deb:[0m [1;31merror:[0m paste subprocess was killed by signal 
> > > > > (Broken pipe)
> > > >
> > > > IMO that's the source of your problem.
> > > > You have two packages fighting to overwrite the same file. You should
> > > > inspect them.
> > > > Are you sure they come from buster, not from foreign repository?
> > > 
> > > Apparently they are both from Buster.
> > 
> > I'm afraid not. You need to check the version numbers more carefully.
> 
> I meant the packages (gir1.2-gst-plugins-bad-1.0, pitivi) being upgraded, 
> rather than the versions replacing them, were both from Buster at the point 
> of the upgrade (weren't they?)

One might assume so, but only you can check that. There are two logs
of the upgrade. /var/log/apt/history.log (and its predecessors) shows
the command issued, followed by the packages affected, with the old
and new version numbers in parentheses. /var/log/apt/term.log (and its
predecessors) shows the various packages being unpacked and then set
up. Again, there are old and new version numbers. And it's all timestamped.

BTW I can't immediately see why you would have
gir1.2-gst-plugins-bad-1.0 installed in buster (as a dependency),
because the only package that depends on it is
libgstreamer-plugins-bad1.0-dev, and I can't find anything that
depends on that.

> On Bullseye now:
> 
> $ apt policy *gir*bad*
> gir1.2-gst-plugins-bad-1.0:
>   Installed: 1.18.4-3
>   Candidate: 1.18.4-3
>   Version table:
>  *** 1.18.4-3 500
> 500 http://deb.debian.org/debian bullseye/main amd64 Packages
> 100 /var/lib/dpkg/status
> 
> $ aptitude why gir1.2-gst-plugins-bad-1.0
> i   pitivi Depends gir1.2-gst-plugins-bad-1.0 (>= 1.18.0)
> 
> (having installed pitivi again after removing it before upgrading to see what 
> difference it made)
> 
> I don't understand what the problem is/was - 

To summarise,

/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib included
↓↙
↓

yes  buster0.999-1+b1pitivi
no   bullseye  2020.09.2-3   pitivi

no   buster1.14.4-1+deb10u2  gir1.2-gst-plugins-bad-1.0
yes  bullseye  1.18.4-3  gir1.2-gst-plugins-bad-1.0

pitivi/bullseye depends on gir1.2-gst-plugins-bad-1.0 (>= 1.18.0) so
it can't be installed while buster's gir1.2-gst-plugins-bad-1.0 is there.

pitivi/buster must be removed before gir1.2-gst-plugins-bad-1.0/bullseye
is installed, to avoid having two versions of that file.

> shouldn't apt just have handled this?

AFAIK, assuming that buster was up-to-date at the start of the
dist-upgrade, and there were no "foreign" packages etc.
(I don't know anything about apt-forktracer.)

Cheers,
David.

Re: Buster to Bullseye upgrade problem

[Gareth Evans]

On Thu 19 Aug 2021, at 05:50, David Wright  wrote:
> On Thu 19 Aug 2021 at 04:00:04 (+0100), Gareth Evans wrote:
> > On Wed 18 Aug 2021, at 23:33, piorunz  wrote:
> > > On 18/08/2021 16:14, Gareth Evans wrote:
> > > > Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
> > > > [1mdpkg:[0m error processing archive 
> > > > /tmp/apt-dpkg-install-Un4rDW/28-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb
> > > >  (--unpack):
> > > >   trying to overwrite 
> > > > '/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib', 
> > > > which is also in package pitivi 0.999-1+b1
> > > > [1mdpkg-deb:[0m [1;31merror:[0m paste subprocess was killed by signal 
> > > > (Broken pipe)
> > >
> >  
> > > IMO that's the source of your problem.
> > > You have two packages fighting to overwrite the same file. You should
> > > inspect them.
> > > Are you sure they come from buster, not from foreign repository?
> > 

Hi David,

> > Apparently they are both from Buster.
> 
> I'm afraid not. You need to check the version numbers more carefully.

I meant the packages (gir1.2-gst-plugins-bad-1.0, pitivi) being upgraded, 
rather than the versions replacing them, were both from Buster at the point of 
the upgrade (weren't they?)

On Bullseye now:

$ apt policy *gir*bad*
gir1.2-gst-plugins-bad-1.0:
  Installed: 1.18.4-3
  Candidate: 1.18.4-3
  Version table:
 *** 1.18.4-3 500
500 http://deb.debian.org/debian bullseye/main amd64 Packages
100 /var/lib/dpkg/status

$ aptitude why gir1.2-gst-plugins-bad-1.0
i   pitivi Depends gir1.2-gst-plugins-bad-1.0 (>= 1.18.0)

(having installed pitivi again after removing it before upgrading to see what 
difference it made)

I don't understand what the problem is/was - shouldn't apt just have handled 
this?

Have I misunderstood what you have shown/what you are saying?

Thanks,
Gareth

> 
> $ apt policy gir1.2-gst-plugins-bad-1.0
> gir1.2-gst-plugins-bad-1.0:
>   Installed: (none)
>   Candidate: 1.14.4-1+deb10u2
>   Version table:
>  1.14.4-1+deb10u2 990
> 990 http://deb.debian.org/debian buster/main amd64 Packages
> 990 http://security.debian.org/debian-security 
> buster/updates/main amd64 Packages
> $ apt-file list gir1.2-gst-plugins-bad-1.0 
> gir1.2-gst-plugins-bad-1.0: 
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GstInsertBin-1.0.typelib
> gir1.2-gst-plugins-bad-1.0: 
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GstMpegts-1.0.typelib
> gir1.2-gst-plugins-bad-1.0: 
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GstPlayer-1.0.typelib
> gir1.2-gst-plugins-bad-1.0: 
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GstWebRTC-1.0.typelib
> gir1.2-gst-plugins-bad-1.0: 
> /usr/share/doc/gir1.2-gst-plugins-bad-1.0/AUTHORS
> gir1.2-gst-plugins-bad-1.0: 
> /usr/share/doc/gir1.2-gst-plugins-bad-1.0/NEWS.gz
> gir1.2-gst-plugins-bad-1.0: 
> /usr/share/doc/gir1.2-gst-plugins-bad-1.0/README.Debian
> gir1.2-gst-plugins-bad-1.0: 
> /usr/share/doc/gir1.2-gst-plugins-bad-1.0/README.gz
> gir1.2-gst-plugins-bad-1.0: 
> /usr/share/doc/gir1.2-gst-plugins-bad-1.0/changelog.Debian.gz
> gir1.2-gst-plugins-bad-1.0: 
> /usr/share/doc/gir1.2-gst-plugins-bad-1.0/changelog.gz
> gir1.2-gst-plugins-bad-1.0: 
> /usr/share/doc/gir1.2-gst-plugins-bad-1.0/copyright
> $ 
> 
> File list of package gir1.2-gst-plugins-bad-1.0 in bullseye of 
> architecture amd64
> 
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GstBadAudio-1.0.typelib
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GstCodecs-1.0.typelib
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GstInsertBin-1.0.typelib
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GstMpegts-1.0.typelib
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GstPlayer-1.0.typelib
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib ← 
> new in bullseye
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GstWebRTC-1.0.typelib
> /usr/share/doc/gir1.2-gst-plugins-bad-1.0/changelog.Debian.gz
> /usr/share/doc/gir1.2-gst-plugins-bad-1.0/changelog.gz
> /usr/share/doc/gir1.2-gst-plugins-bad-1.0/copyright
> 
> Cheers,
> David.
> 
> 

Re: Buster to Bullseye upgrade problem

[David Wright]

On Thu 19 Aug 2021 at 04:00:04 (+0100), Gareth Evans wrote:
> On Wed 18 Aug 2021, at 23:33, piorunz  wrote:
> > On 18/08/2021 16:14, Gareth Evans wrote:
> > > Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
> > > [1mdpkg:[0m error processing archive 
> > > /tmp/apt-dpkg-install-Un4rDW/28-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb
> > >  (--unpack):
> > >   trying to overwrite 
> > > '/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib', 
> > > which is also in package pitivi 0.999-1+b1
> > > [1mdpkg-deb:[0m [1;31merror:[0m paste subprocess was killed by signal 
> > > (Broken pipe)
> >
>  
> > IMO that's the source of your problem.
> > You have two packages fighting to overwrite the same file. You should
> > inspect them.
> > Are you sure they come from buster, not from foreign repository?
> 
> Apparently they are both from Buster.

I'm afraid not. You need to check the version numbers more carefully.

$ apt policy gir1.2-gst-plugins-bad-1.0
gir1.2-gst-plugins-bad-1.0:
  Installed: (none)
  Candidate: 1.14.4-1+deb10u2
  Version table:
 1.14.4-1+deb10u2 990
990 http://deb.debian.org/debian buster/main amd64 Packages
990 http://security.debian.org/debian-security buster/updates/main 
amd64 Packages
$ apt-file list gir1.2-gst-plugins-bad-1.0 
gir1.2-gst-plugins-bad-1.0: 
/usr/lib/x86_64-linux-gnu/girepository-1.0/GstInsertBin-1.0.typelib
gir1.2-gst-plugins-bad-1.0: 
/usr/lib/x86_64-linux-gnu/girepository-1.0/GstMpegts-1.0.typelib
gir1.2-gst-plugins-bad-1.0: 
/usr/lib/x86_64-linux-gnu/girepository-1.0/GstPlayer-1.0.typelib
gir1.2-gst-plugins-bad-1.0: 
/usr/lib/x86_64-linux-gnu/girepository-1.0/GstWebRTC-1.0.typelib
gir1.2-gst-plugins-bad-1.0: /usr/share/doc/gir1.2-gst-plugins-bad-1.0/AUTHORS
gir1.2-gst-plugins-bad-1.0: /usr/share/doc/gir1.2-gst-plugins-bad-1.0/NEWS.gz
gir1.2-gst-plugins-bad-1.0: 
/usr/share/doc/gir1.2-gst-plugins-bad-1.0/README.Debian
gir1.2-gst-plugins-bad-1.0: /usr/share/doc/gir1.2-gst-plugins-bad-1.0/README.gz
gir1.2-gst-plugins-bad-1.0: 
/usr/share/doc/gir1.2-gst-plugins-bad-1.0/changelog.Debian.gz
gir1.2-gst-plugins-bad-1.0: 
/usr/share/doc/gir1.2-gst-plugins-bad-1.0/changelog.gz
gir1.2-gst-plugins-bad-1.0: /usr/share/doc/gir1.2-gst-plugins-bad-1.0/copyright
$ 

File list of package gir1.2-gst-plugins-bad-1.0 in bullseye of architecture 
amd64

/usr/lib/x86_64-linux-gnu/girepository-1.0/GstBadAudio-1.0.typelib
/usr/lib/x86_64-linux-gnu/girepository-1.0/GstCodecs-1.0.typelib
/usr/lib/x86_64-linux-gnu/girepository-1.0/GstInsertBin-1.0.typelib
/usr/lib/x86_64-linux-gnu/girepository-1.0/GstMpegts-1.0.typelib
/usr/lib/x86_64-linux-gnu/girepository-1.0/GstPlayer-1.0.typelib
/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib ← new in 
bullseye
/usr/lib/x86_64-linux-gnu/girepository-1.0/GstWebRTC-1.0.typelib
/usr/share/doc/gir1.2-gst-plugins-bad-1.0/changelog.Debian.gz
/usr/share/doc/gir1.2-gst-plugins-bad-1.0/changelog.gz
/usr/share/doc/gir1.2-gst-plugins-bad-1.0/copyright

Cheers,
David.

Re: Buster to Bullseye upgrade problem

[Gareth Evans]

On Wed 18 Aug 2021, at 23:33, piorunz  wrote:
> On 18/08/2021 16:14, Gareth Evans wrote:
> > Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
> > [1mdpkg:[0m error processing archive 
> > /tmp/apt-dpkg-install-Un4rDW/28-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb
> >  (--unpack):
> >   trying to overwrite 
> > '/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib', 
> > which is also in package pitivi 0.999-1+b1
> > [1mdpkg-deb:[0m [1;31merror:[0m paste subprocess was killed by signal 
> > (Broken pipe)
>
 
> IMO that's the source of your problem.
> You have two packages fighting to overwrite the same file. You should
> inspect them.
> Are you sure they come from buster, not from foreign repository?

Apparently they are both from Buster.  Removing pitivi before upgrading 
improves things, but not completely plain sailing.

On Buster:

# aptitude search '?narrow(?installed, ?not(?origin(Debian)))'
#

# apt-forktracer | sort 
libck0 (0.6.0-1.2~bpo10+1) [Debian Backports: 0.6.0-1.2~bpo10+1]
libnvpair3linux (2.0.3-9~bpo10+1) [Debian Backports: 2.0.3-9~bpo10+1]
libuutil3linux (2.0.3-9~bpo10+1) [Debian Backports: 2.0.3-9~bpo10+1]
libzfs4linux (2.0.3-9~bpo10+1) [Debian Backports: 2.0.3-9~bpo10+1]
libzpool4linux (2.0.3-9~bpo10+1) [Debian Backports: 2.0.3-9~bpo10+1]
sane-airscan (0.99.19-1~bpo10+1) [Debian Backports: 0.99.19-1~bpo10+1]
sysbench (1.0.18+ds-1~bpo10+1) [Debian Backports: 1.0.18+ds-1~bpo10+1]
zfs-dkms (2.0.3-9~bpo10+1) [Debian Backports: 2.0.3-9~bpo10+1 2.0.3-9~bpo10+1] 
[Debian: 0.7.12-2+deb10u2 0.7.12-2+deb10u2]
zfs-initramfs (2.0.3-9~bpo10+1) [Debian Backports: 2.0.3-9~bpo10+1 
2.0.3-9~bpo10+1] [Debian: 0.7.12-2+deb10u2 0.7.12-2+deb10u2]
zfsutils-linux (2.0.3-9~bpo10+1) [Debian Backports: 2.0.3-9~bpo10+1] [Debian: 
0.7.12-2+deb10u2]
zfs-zed (2.0.3-9~bpo10+1) [Debian Backports: 2.0.3-9~bpo10+1] [Debian: 
0.7.12-2+deb10u2]

# aptitude search '~o'
#

# apt policy pitivi
pitivi:
  Installed: 0.999-1+b1
  Candidate: 0.999-1+b1
  Version table:
 *** 0.999-1+b1 500
500 http://deb.debian.org/debian buster/main amd64 Packages
100 /var/lib/dpkg/status

# apt-show-versions | grep newer
#

# aptitude search '~i(!~ODebian)'
#

# apt remove --purge pitivi

# apt upgrade --without-new-pkgs
(completes)

# apt full-upgrade
[...]
Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...

W: APT had planned for dpkg to do more than it reported back (7510 vs 7543).
   Affected packages: texlive-fonts-recommended:amd64 texlive-lang-greek:amd64 
texlive-latex-base:amd64 texlive-latex-extra:amd64 
texlive-latex-recommended:amd64 texlive-pictures:amd64 
texlive-plain-generic:amd64 texlive-science:amd64

# apt full-upgrade
(completes)

Oh well.  Thanks.
G


> 
> You have commands to check for this:
> 
> check if any packages are newer than repository (possibly foreign)
> apt-show-versions | grep newer
> 
> check if any packages are foreign (not from Debian)
> aptitude search '~i(!~ODebian)'
> 
> 
> --
> 
> With kindest regards, piorunz.
> 
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
> ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
> ⠈⠳⣄
> 
> 

Re: Buster to Bullseye upgrade problem

[piorunz]

On 18/08/2021 16:14, Gareth Evans wrote:

Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
[1mdpkg:[0m error processing archive 
/tmp/apt-dpkg-install-Un4rDW/28-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb 
(--unpack):
  trying to overwrite 
'/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib', which 
is also in package pitivi 0.999-1+b1
[1mdpkg-deb:[0m [1;31merror:[0m paste subprocess was killed by signal (Broken 
pipe)


IMO that's the source of your problem.
You have two packages fighting to overwrite the same file. You should
inspect them.
Are you sure they come from buster, not from foreign repository?

You have commands to check for this:

check if any packages are newer than repository (possibly foreign)
apt-show-versions | grep newer

check if any packages are foreign (not from Debian)
aptitude search '~i(!~ODebian)'


--

With kindest regards, piorunz.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: Buster to Bullseye upgrade problem

[Gareth Evans]

On Wed 18 Aug 2021, at 00:44, Gareth Evans  wrote:
> Hello,
> 
> I upgraded from Buster stable to Bullseye stable last night, with 
> apparent success eventually, but it went less than smoothly and I would 
> be grateful for any advice as to why that may have been.
> 
> I followed the preparation advice at
> 
> https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html
> 
> and it seemed to me that there were no non-Debian packages in 
> apt-forktracer output, although I'm afraid I didn't save the list.
> 
> The upgrade process stopped abruptly a couple of times, once without 
> any indication as to why.
> 
> $ cat /etc/apt/sources.list
> deb http://deb.debian.org/debian/ bullseye main contrib non-free
> deb http://deb.debian.org/debian/ bullseye-updates main contrib non-free
> #deb http://deb.debian.org/debian bullseye-proposed-updates main 
> contrib non-free
> deb http://deb.debian.org/debian-security/ bullseye-security main 
> contrib non-free
> deb http://deb.debian.org/debian/ bullseye-backports main contrib 
> non-free
> 
> 
> >From script output:
> 
> # apt full-upgrade
> [...]
> Errors were encountered while processing:
>  /tmp/apt-dpkg-install-2vllSE/09-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb
> 
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> # apt install --fix-broken
> [...]
> Setting up zfs-initramfs (2.0.3-9) ...
> Processing triggers for initramfs-tools (0.133+deb10u1) ...
> update-initramfs: Generating /boot/initrd.img-4.19.0-17-amd64
> 
> # apt full-upgrade
> [...]
> Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
> 
> W: APT had planned for dpkg to do more than it reported back (8974 vs 
> 9007).
>Affected packages: texlive-fonts-recommended:amd64 
> texlive-lang-greek:amd64 texlive-latex-base:amd64 
> texlive-latex-extra:amd64 texlive-latex-recommended:amd64 
> texlive-pictures:amd64 texlive-plain-generic:amd64 texlive-science:amd64
> 
> # apt full-upgrade
> [...]
> 
> Apparent success...
> 
> $ apt policy *gir*bad*
> gir1.2-gst-plugins-bad-1.0:
>   Installed: 1.18.4-3
>   Candidate: 1.18.4-3
>   Version table:
>  *** 1.18.4-3 500
> 500 http://deb.debian.org/debian bullseye/main amd64 Packages
> 100 /var/lib/dpkg/status
> 
> $ cat /etc/debian_version
> 11.0
> 
> $ uname -a
> Linux  5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03) 
> x86_64 GNU/Linux
> 
> Reboots without issue. 
> 
> Is there any way to verify an upgrade completed properly?  Would there 
> be obvious errors on exit if it didn't?
> 
> Thanks,
> Gareth
> 
> 

I have been digging/experimenting a bit more and have reverted to Buster 
several times by rolling back zfs snapshots to retry upgrading with different 
approaches:


(1) Minimal system upgrade, then full-upgrade, per

https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html#minimal-upgrade

Minimal upgrade completed without issue, but the same problems with the same 
solutions as in my first email appeared in the full-upgrade part of the process.


(2) Single-line sources.list:

deb http://deb.debian.org/debian/ bullseye main contrib non-free

Same approach as in (1), same problems and solutions.


(3) Minimal upgrade followed by "apt upgrade" (not full-upgrade) - this is 
apparently not to be recommended! (I know this is what full/dist-upgrade is 
for, but I thought I'd see what happened.)  Fwiw...

There were no breakages in the upgrade process in this approach, but then the 
system dropped to initramfs on reboot due to lack of zfs modules (much building 
having been conspicuous by its absence).  Booting into a previous kernel at 
this stage got to graphical login, all Bullseye themed so far, but no desktop 
appeared after successful login, and *Buster* shutdown screen appeared after 
holding power off.  


So whatever way I approach it, the upgrade doesn't run smoothly at all, though 
it seems to succeed eventually using a combination of 

[optionally...] apt upgrade --without-new-pkgs
apt full-upgrade
apt install --fix-broken
apt full-upgrade x2


As for causes...

syslog is silent on the issues

/var/log/apt/term.log shows:

--
Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
[1mdpkg:[0m error processing archive 
/tmp/apt-dpkg-install-Un4rDW/28-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb 
(--unpack):
 trying to overwrite 
'/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib', which 
is also in package pitivi 0.999-1+b1
[1mdpkg-deb:[0m [1;31merror:[0m paste subprocess was killed by signal (Broken 
pipe)
--

However it gives no clue as to why the upgrade stops again later, with things 
for apt still to do, after the second (of three) "apt full-upgrade"s, saying 
merely:

--
Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
Log ended: 2021-08-18  11:09:56
--


A quick google shows etckeeper causes problems at times, but nothing along 
these lines afaics, and at least one person appears to succeed in using it 

Buster to Bullseye upgrade problem

[Gareth Evans]

Hello,

I upgraded from Buster stable to Bullseye stable last night, with apparent 
success eventually, but it went less than smoothly and I would be grateful for 
any advice as to why that may have been.

I followed the preparation advice at

https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html

and it seemed to me that there were no non-Debian packages in apt-forktracer 
output, although I'm afraid I didn't save the list.

The upgrade process stopped abruptly a couple of times, once without any 
indication as to why.

$ cat /etc/apt/sources.list
deb http://deb.debian.org/debian/ bullseye main contrib non-free
deb http://deb.debian.org/debian/ bullseye-updates main contrib non-free
#deb http://deb.debian.org/debian bullseye-proposed-updates main contrib 
non-free
deb http://deb.debian.org/debian-security/ bullseye-security main contrib 
non-free
deb http://deb.debian.org/debian/ bullseye-backports main contrib non-free


>From script output:

# apt full-upgrade
[...]
Errors were encountered while processing:
 /tmp/apt-dpkg-install-2vllSE/09-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb

E: Sub-process /usr/bin/dpkg returned an error code (1)

# apt install --fix-broken
[...]
Setting up zfs-initramfs (2.0.3-9) ...
Processing triggers for initramfs-tools (0.133+deb10u1) ...
update-initramfs: Generating /boot/initrd.img-4.19.0-17-amd64

# apt full-upgrade
[...]
Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...

W: APT had planned for dpkg to do more than it reported back (8974 vs 9007).
   Affected packages: texlive-fonts-recommended:amd64 texlive-lang-greek:amd64 
texlive-latex-base:amd64 texlive-latex-extra:amd64 
texlive-latex-recommended:amd64 texlive-pictures:amd64 
texlive-plain-generic:amd64 texlive-science:amd64

# apt full-upgrade
[...]

Apparent success...

$ apt policy *gir*bad*
gir1.2-gst-plugins-bad-1.0:
  Installed: 1.18.4-3
  Candidate: 1.18.4-3
  Version table:
 *** 1.18.4-3 500
500 http://deb.debian.org/debian bullseye/main amd64 Packages
100 /var/lib/dpkg/status

$ cat /etc/debian_version
11.0

$ uname -a
Linux  5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03) x86_64 
GNU/Linux

Reboots without issue. 

Is there any way to verify an upgrade completed properly?  Would there be 
obvious errors on exit if it didn't?

Thanks,
Gareth

Since iOS 14.5 upgrade problem with Samba Share (no photo upload possible anymore)

[Daniel Schröter]

Hello,

since iOS upgrade to 14.5 last week I can not upload my photos to my samba 
share (Debian/unstable) anymore.

I tried to increase logging and took a look to wireshark already but didn't 
found the issue.

Anyone else has a problem with Samba since upgrade to iOS 14.5?

Thanks!

Bye

Re: Upgrade Problem

[Stefan Krusche]

Am Freitag, 4. Januar 2019 schrieb Richard Hector:
> On 4/01/19 9:49 PM, Andy Smith wrote:
> > Stephen, I think you're going to have to analyse where the space is
> > being used. If you use a graphical desktop then there might be a
> > graphical application that can help with this. On GNOME it's called
> > Disk Usage Analyzer. On the command line you could try something
> > like:
> >
> > $ sudo du -xh / | sort -rh | less
>
> I find ncdu very useful for this - it's a full-screen terminal-based
> interactive du, and lets you drill down to find where your space is
> used.

Thanks for the hint.  It's a pretty cool program.

Kind regards,
Stefan

Re: allocating disk space (was: Upgrade Problem)

[David Wright]

On Fri 04 Jan 2019 at 19:36:42 (-0500), Felix Miata wrote:
> David Wright composed on 2019-01-04 14:27 (UTC-0600):
> > On Fri 04 Jan 2019 at 13:41:33 (-0500), Felix Miata wrote:
> >> David Wright composed on 2019-01-04 10:19 (UTC-0600):
> >> > On Fri 04 Jan 2019 at 04:30:00 (-0500), Felix Miata wrote:
> 
> >> >>> This partitioning scheme seems really odd and unwieldy.  
> 
> >> >> Indeed. Considering the absence of a sysadmin,
> 
> >> > What's so unusual about that?
> 
> >> Standing alone, absolutely nothing, but it wasn't standing alone
> 
> > (The OP is standing alone, leaving us aside.)
> 
> > By snipping the rhetorical question that introduces my paragraph, it
> > now appears that "unusual" refers to the partitioning scheme. It
> > doesn't.
> 
> It wasn't intended to.
> 
> > It refers to the absence of a sysadmin. 
> 
> Intended.
> 
> >> >> absence of 2 possible primary partitions on sda,
> >> 
> >> > If the OP partitioned an MBR disk intending to subdivide the
> >> > filesystem, then it might be expected that they create an extended
> >> > partition. Why bother with holding off until you've got two
> >> > primary partitions set up first?
> 
> >> Off the top of my head:
> 
> >> 1-trivial I know, but avoiding seeing fdisk report "Partition table 
> >> entries are not in disk order"
> 
> >> 2-less trivial: partitions not being in disk order
> 
> > I don't understand. The time sequence would be
> 
> > sda1=primary [ free 
> >  ]
> 
> > sda1=primary [  "sda2"=extended 
> >  ]
> 
> > sda1=primary [ sda5=logicalfree 
> >  ]
> 
> > sda1=primary [ sda5=logical sda6=logical   free 
> >  ]
> 
> > sda1=primary [ sda5=logical sda6=logical sda7=logical   free
> >  ]
> 
> > sda1=primary [ sda5=logical sda6=logical sda7=logical sda8=logical 
> > possibly-free ]
> 
> > What's out of order?
> 
> This looks like it's assuming reference to the OP's disk state, which is not 
> what I was writing
> about. AFAIK, when entries /are/ out of order, far more steps had to have 
> been involved than those
> you listed.
> 
> >> 3-potential to have a primary partition added following a logical, thereby 
> >> making following
> >> freespace unavailable for one or more added logicals (disappearing 
> >> freespace).
> 
> > With the scenario above, it would be usual to fill the disk with the
> > extended partition, so there's no possibility of adding another primary.
> 
> Yes, when filling the disk at the outset. With the escalation of disk sizes 
> over the years, it's
> become more common not to allocate 100% at the outset. In non-ancient memory 
> I only ever fully
> allocated with my own disks at the outset with data disks, until small SDDs 
> became cheap.

I don't understand the reasoning.

> Some partitioning tools are better than others at allowing oneself to shoot 
> oneself in the foot.
> 
> > Here's the partition table of this laptop. Care to guess it's
> > evolution?
> 
> > Number  Start (sector)End (sector)  Size
> >12048 2050047   1000.0 MiB
> >2 2050048 2582527   260.0 MiB
> >3 2582528 4630527   1000.0 MiB
> >4 4630528 4892671   128.0 MiB
> >5 4892672   347348991   163.3 GiB
> >6   347348992   429268991   39.1 GiB /
> >7   429268992   511188991   39.1 GiB
> >8   511188992   883275775   177.4 GiB/home
> >9   883275776   883292159   8.0 MiB
> >   10   883292160   892084223   4.2 GiB  swap
> >   11   892086272   892803071   350.0 MiB
> >   12   892803072   894900223   1024.0 MiB
> >   13   894900224   947329023   25.0 GiB
> >   14   947329024   976773119   14.0 GiB
> 
> > Constrained by an inability to repartition the disk, how would
> > you distribute a Debian system across it while wasting the
> > least space?
> 
> That's a bit sketchy.

Worse then that: I don't have a clue what most of the original
partitions were for, and still don't. I just don't touch them.

Here's what I inherited:

/dev/sda1   2048   2050047   2048000 1000M Windows recovery environment
/dev/sda22050048   2582527532480  260M EFI System
/dev/sda32582528   4630527   2048000 1000M Lenovo boot partition
/dev/sda44630528   4892671262144  128M Microsoft reserved
/dev/sda54892672 892086271 887193600  423G Microsoft basic data
/dev/sda6  892086272 892803071716800  350M Windows recovery environment
/dev/sda7  892803072 894900223   20971521G Microsoft basic data
/dev/sda8  894900224 947329023  52428800   25G Microsoft basic data
/dev/sda9  947329024 976773119  29444096   14G Windows recovery environment

I have no idea why there are three recovery partitions of vastly
differing sizes, a manufacturer's boot 

Re: Upgrade Problem

[mick crane]

On 2019-01-07 02:56, John Crawley wrote:

On 06/01/2019 00.26, rhkra...@gmail.com wrote:

On Friday, January 04, 2019 08:21:30 PM David Wright wrote:

On Fri 04 Jan 2019 at 14:02:27 (-0500), Stephen P. Molnar wrote:


Having babbled for the last two paragraphs, I'll close buy saying 
that

I will revert to the entire installation on the same partition.


I would advise you to keep your separate /home partition. Except for
dot files/directories, they're independent of the OS. It makes
reinstallation and upgrades a lot easier.


I hink it is really inconvenient to have config information (basically 
the .
files) and what I call "real user data" (that is, documents, photos, 
videos,
...) combined in the same directory with the config information 
hidden.


My solution: I create a separate top level directory (e.g. / 
instead of
/home/) and store all my "real user data" in /, and let 
the OS and
application programs do what they want in /home/.  When I 
upgrade or
move to a new machine, I move (well, copy) the content of / but 
let the

new OS create and fool with a new /home/.


Chime in to agree on that, but I use /data/
It really makes upgrades easier to have all that ...data in its own 
partition.

Multi-boots can share it too.


I've tended to make a soft link in /home/me to another disk.

mick

--
Key ID4BFEBB31

Re: Upgrade Problem

[John Crawley]

On 06/01/2019 00.26, rhkra...@gmail.com wrote:

On Friday, January 04, 2019 08:21:30 PM David Wright wrote:

On Fri 04 Jan 2019 at 14:02:27 (-0500), Stephen P. Molnar wrote:



Having babbled for the last two paragraphs, I'll close buy saying that
I will revert to the entire installation on the same partition.


I would advise you to keep your separate /home partition. Except for
dot files/directories, they're independent of the OS. It makes
reinstallation and upgrades a lot easier.


I hink it is really inconvenient to have config information (basically the .
files) and what I call "real user data" (that is, documents, photos, videos,
...) combined in the same directory with the config information hidden.

My solution: I create a separate top level directory (e.g. / instead of
/home/) and store all my "real user data" in /, and let the OS and
application programs do what they want in /home/.  When I upgrade or
move to a new machine, I move (well, copy) the content of / but let the
new OS create and fool with a new /home/.


Chime in to agree on that, but I use /data/
It really makes upgrades easier to have all that ...data in its own  
partition.

Multi-boots can share it too.
--
John

Re: Upgrade Problem

[rhkramer]

On Friday, January 04, 2019 08:21:30 PM David Wright wrote:
> On Fri 04 Jan 2019 at 14:02:27 (-0500), Stephen P. Molnar wrote:

> > Having babbled for the last two paragraphs, I'll close buy saying that
> > I will revert to the entire installation on the same partition.
> 
> I would advise you to keep your separate /home partition. Except for
> dot files/directories, they're independent of the OS. It makes
> reinstallation and upgrades a lot easier.

That gives me a chance to rant (gently, I hope) on one of my pet peeves and 
how I solve it.

I hink it is really inconvenient to have config information (basically the . 
files) and what I call "real user data" (that is, documents, photos, videos, 
...) combined in the same directory with the config information hidden.

(I won't go into detail on that -- if you find it convenient, more power to 
you.)

My solution: I create a separate top level directory (e.g. / instead of 
/home/) and store all my "real user data" in /, and let the OS and 
application programs do what they want in /home/.  When I upgrade or 
move to a new machine, I move (well, copy) the content of / but let the 
new OS create and fool with a new /home/.  

(I do preserve the content of /home/ from the old machine / installation 
for some period of time in case I find that I need some configuration or such 
from there.)

Re: Upgrade Problem

[songbird]

Michael Stone wrote:
> songbird wrote:
>>Roberto C  Sánchez wrote:
>>> It might also indicate files that exist (i.e., occupy blocks) without
>>> having directory entries.  For example, this is the case when a program
>>> creates a temporary file, gets the descritor back from the syscall, then
>>> immediatley calls unlink on it.  The file descriptor is still active and
>>> the file can be written/read with the descriptor reference, but the file
>>> cannot be seen with 'ls' and, as I recall, it will not show up in the
>>> calculation made by 'du'.  The calculation made by 'df' will still be
>>> accurate, though.
>>
>>  wouldn't fsck clean that up?
>
> not if the program is still running; it's not an error condition. the 
> only case where fsck would help is if the whole machine crashed.

  i should have noted that i would likely have 
killed off processes and unmounted the file system
before fsck'ing it.


> the traditional gotcha for "nonexistent file taking up space" is 
> something generating a large log file, when someone tries to free the 
> space by deleting the file. if the program writing it is still running, 
> the file is gone but the space won't be freed until the program lets go 
> of the file. lsof has a "deleted" indicator which can identify this.

  *nods*


  songbird

Re: Upgrade Problem

[Eduardo M KALINOWSKI]

On 05/01/2019 01:15, Felix Miata wrote:
> David Wright composed on 2019-01-04 19:21 (UTC-0600):
>
>> Ignoring /home as it dwarfs / in size, it would be very easy to make a
>> mistake if you take an existing installation and hive off the /tmp and
>> /var into separate partitions. The problem boils down to leaving the
>> existing /var contents (in the root filesystem) in place when you
>> mount the new var partition onto /var, thereby making those files
>> inaccessible.
> +1
>
> So, boot rescue media, mount sda1, and check the contents of /var/. 
> Its apt cache might be
> loaded, thus you might not any more have reason to reinstall - just delete 
> everything in it and
> reboot. If something goes wrong, you planned on reinstalling anyway. :-)

No need for a live CD: you can use bind mounts to access the original
contents of dirs that serve as mount points for other filesystems:
https://unix.stackexchange.com/questions/4426/access-to-original-contents-of-mount-point

(Unless mount fails because of no free space...)


-- 
Eduardo M KALINOWSKI
edua...@kalinowski.com.br

Re: Upgrade Problem

[tomas]

On Fri, Jan 04, 2019 at 05:04:49PM -0500, songbird wrote:
> Roberto C  Sánchez wrote:
> ...
> > It might also indicate files that exist (i.e., occupy blocks) without
> > having directory entries.  For example, this is the case when a program
> > creates a temporary file, gets the descritor back from the syscall, then
> > immediatley calls unlink on it [...]

Even easier: you rm a file which is still held open by some program
(a log file may be a typical example). The file will continue existing
until the last program which has an open file descriptor to it closes
it. If you think of it, it just makes sense.

[...]

>   wouldn't fsck clean that up?

No, definitely not. Terminating the processes keeping the file open
will help (i.e. reboot will most definitely help).

>   if it might be potential useful information you were missing
> and wanted to get back you could copy the entire partition and
> then run a recovery/forensics program on it to see what it all
> was.

There are tricks to it: open files are to be found in /proc//fd:
there are some amusing war stories of clever sysadmins recovering
things from there after some mess-up.

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: Overhead of LVM (Re: Upgrade Problem)

[Reco]

Hi.

On Fri, Jan 04, 2019 at 11:03:48PM -0500, rhkra...@gmail.com wrote:
> On Friday, January 04, 2019 08:23:59 AM Reco wrote:
> > # pvs
> >   PV VG Fmt  Attr PSize  PFree
> >   /dev/md10  naslvm2 a--  14.55t 10.43t
> > 
> > # hdparm -Tt /dev/md10
> > /dev/md10:
> >  Timing cached reads:   1224 MB in  2.00 seconds = 612.05 MB/sec
> >  Timing buffered disk reads: 1210 MB in  3.00 seconds = 403.28 MB/sec
> > 
> > # hdparm -Tt /dev/nas/root
> > /dev/nas/root:
> >  Timing cached reads:   1224 MB in  2.00 seconds = 611.55 MB/sec
> >  Timing buffered disk reads: 1154 MB in  3.00 seconds = 384.42 MB/sec
> > 
> > I see a difference, but I's something I can live with.
> 
> Thanks very much!
> 
>  I need to learn more about pvs (I did google the man page), but I assume the 
> /dev/md10 and /dev/nas/root are two ways of referring to the same partition, 
> one within LVM, and one not?

md10 is a RAID10 consisting of 4 HDDs. No partitions, just
straightforward block devices.
/dev/nas/root is a logical volume (/ filesystem in this case), it
resides on this md10, as 'pvs' output shows.
Storage hierarchy is a as follows (lsblk, same for sdb, sdc and sdd):

NAME MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda8:01  7.3T  0 disk
└─md0  9:00  7.3T  0 raid1
  └─md10   9:10   0 14.6T  0 raid0
├─nas-root   254:20 15.3G  0 lvm   /

So yes, both md10 and /dev/nas/root are two ways of referring to the
same set of bytes on disks.

Reco

Re: Fwd: Upgrade Problem

[mick crane]

On 2019-01-04 21:03, Gene Heskett wrote:

On Friday 04 January 2019 14:34:59 Brian wrote:


On Fri 04 Jan 2019 at 13:49:52 -0500, Gene Heskett wrote:
> On Friday 04 January 2019 13:31:05 Nicolas George wrote:
> > deloptes (12019-01-04):
> > >We just pointed out
> > > that you do not have to be a sysadmin to operate a computer.
> >
> > And you are wrong. Operating a computer requires a sysadmin, there
> > is no way around it. If there is no dedicated one, that makes the
> > user the sysadmin. Their choice whether they become competent or
> > not;
> >
> > Regards,
>
> Another demonstration of TANSTAAFL Nicolas.  Its a law one will obey
> no matter how hard you try to ignore it.

I wish I understood that!


Why not, There Ain't No Such Thing As A Free lunch. If you think the
peanuts are free, check the price of the beer IOW.


What's the price of beer on the Isle of Wight to do with computers ?


--
Key ID4BFEBB31

Re: Fwd: Upgrade Problem

[Gene Heskett]

On Friday 04 January 2019 19:32:18 deloptes wrote:

> Gene Heskett wrote:
> >> So I was thinking perhaps this is good for the economy, because if
> >> most of the users were like me, there wouldn't be any economic
> >> growth in the past years.
> >
> > I see that too, darn it.
>
> Suddenly I spotted something that fits our discussion by the worst
> example - Apple.
> https://www.youtube.com/watch?v=_XneTBhRPYk

We've been victimized by that too. We bought a video editor in the fading 
days of NTSC, had a pair of G5's. Within a month we had a fire. They 
were filled with plastic moldings to direct the cooling air to the hot 
spots that I thought was pretty sharp engineering, until I realized a 
fan failure was guaranteed to destroy it in about a minute. Shitty $3 
fans, Apple, because we had opened it to verify the fire was out, 
refused to warranty a thing, quoteing nearly $8500 for a new one. We 
found another system for 3 G's that got us to the hi-def age in 2008. 
Apple has never learned that screwing your top of the line customer 
means he will never darken the apple door again. And AFAIK, no Apple 
product has ever had a rack screw in its ears at that station since.

That whole package, big crt monitors, software and a weeks on-site 
install and tutoring, cost us north of $25 grand, and we got about a 
months use out of it. Such memories aren't easily forgotten.

Cheers, Gene Heskett
-- 

Re: Overhead of LVM (Re: Upgrade Problem)

[rhkramer]

On Friday, January 04, 2019 08:23:59 AM Reco wrote:
> # pvs
>   PV VG Fmt  Attr PSize  PFree
>   /dev/md10  naslvm2 a--  14.55t 10.43t
> 
> # hdparm -Tt /dev/md10
> /dev/md10:
>  Timing cached reads:   1224 MB in  2.00 seconds = 612.05 MB/sec
>  Timing buffered disk reads: 1210 MB in  3.00 seconds = 403.28 MB/sec
> 
> # hdparm -Tt /dev/nas/root
> /dev/nas/root:
>  Timing cached reads:   1224 MB in  2.00 seconds = 611.55 MB/sec
>  Timing buffered disk reads: 1154 MB in  3.00 seconds = 384.42 MB/sec
> 
> I see a difference, but I's something I can live with.

Thanks very much!

 I need to learn more about pvs (I did google the man page), but I assume the 
/dev/md10 and /dev/nas/root are two ways of referring to the same partition, 
one within LVM, and one not?

Re: Upgrade Problem

[Felix Miata]

David Wright composed on 2019-01-04 19:21 (UTC-0600):

> On Fri 04 Jan 2019 at 14:02:27 (-0500), Stephen P. Molnar wrote:

>> Felix Miata wrote:

>>> Stephen P. Molnar composed on 2019-01-04 12:57 (UTC-0500):

 I haven't messed around with partitioning since the early days of
 Slackware, and that was with a great deal of trepidation?

>>> You just multiplied my curiosity about what exactly was responsible for 
>>> your current partitioning
>>> scheme, not to mention what will be used for your planned reinstallation.

>> The installer for Debian Stretch has an new option thzt  thought I'd
>> try.:  separate /home, /var and/temp partitions.

You did that for this Jessie to Stretch upgrade? That sounds like "messing 
around with partitioning"
to me.

> Ignoring /home as it dwarfs / in size, it would be very easy to make a
> mistake if you take an existing installation and hive off the /tmp and
> /var into separate partitions. The problem boils down to leaving the
> existing /var contents (in the root filesystem) in place when you
> mount the new var partition onto /var, thereby making those files
> inaccessible.

+1

So, boot rescue media, mount sda1, and check the contents of /var/. Its 
apt cache might be
loaded, thus you might not any more have reason to reinstall - just delete 
everything in it and
reboot. If something goes wrong, you planned on reinstalling anyway. :-)

> I would advise you to keep your separate /home partition. Except for
> dot files/directories, they're independent of the OS. It makes
> reinstallation and upgrades a lot easier.

+1
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: Upgrade Problem

[David Wright]

On Fri 04 Jan 2019 at 14:02:27 (-0500), Stephen P. Molnar wrote:
> On 01/04/2019 01:11 PM, Felix Miata wrote:
> > Stephen P. Molnar composed on 2019-01-04 12:57 (UTC-0500):
> > 
> > > I haven't messed around with partitioning since the early days of
> > > Slackware, and that was with a great deal of trepidation?
> > You just multiplied my curiosity about what exactly was responsible for 
> > your current partitioning
> > scheme, not to mention what will be used for your planned reinstallation.
> The installer for Debian Stretch has an new option thzt  thought I'd
> try.:  separate /home, /var and/temp partitions.

Ignoring /home as it dwarfs / in size, it would be very easy to make a
mistake if you take an existing installation and hive off the /tmp and
/var into separate partitions. The problem boils down to leaving the
existing /var contents (in the root filesystem) in place when you
mount the new var partition onto /var, thereby making those files
inaccessible.

> Over the last 50+ years as  Research Scientist I have tried to follow
> the policy that it's all right to make mistakes..  As long as you try
> not to make the same mistake in the same contiguous four hours - that
> is if you make a mistake in the morning, wait until that afternoon to
> repeat it.  But even more important from the mistake and try not to
> repeat it. I think that making mistakes is an integral part of the
> scientific method.
> 
> Of course, there is a corollary - you can't teach an old scientist new
> science.
> 
> Having babbled for the last two paragraphs, I'll close buy saying that
> I will revert to the entire installation on the same partition.

I would advise you to keep your separate /home partition. Except for
dot files/directories, they're independent of the OS. It makes
reinstallation and upgrades a lot easier.

Cheers,
David.

Re: Upgrade Problem

[David Wright]

On Fri 04 Jan 2019 at 16:18:03 (-0500), Roberto C. Sánchez wrote:
> On Fri, Jan 04, 2019 at 02:39:40PM -0600, David Wright wrote:
> > 
> > There's at least one other scenario that it would be worth eliminating
> > by checking that this equation is true (allowing for filesystem overheads):
> > 
> >   # du -shx
> > +
> >   $ df's Available
> > ≃
> >  partition's size.
> > 
> > This checks whether the mountpoints for /var and so on had files in
> > them before the partitions were mounted. These files would consume
> > filespace but not be detected by du.
> > 
> It might also indicate files that exist (i.e., occupy blocks) without
> having directory entries.  For example, this is the case when a program
> creates a temporary file, gets the descritor back from the syscall, then
> immediatley calls unlink on it.  The file descriptor is still active and
> the file can be written/read with the descriptor reference, but the file
> cannot be seen with 'ls' and, as I recall, it will not show up in the
> calculation made by 'du'.  The calculation made by 'df' will still be
> accurate, though.
> 
> So, you might ask yourself, why would a program create a file only to
> immediately unlink it?  Well, it happen that if the program terminates
> abnormally (i.e,. crashes), the disappearance of the reference to the
> file descriptor when the kernel cleans up the process table also causes
> it to free the associated blocks.  The same thing happens in a normal
> program termination, but in the abnormal case you have no guarantee that
> any clean up code will run.
> 
> As it happens, this is a great practical interview question for a system
> administrator.  Give them a machine where 'df' reports no free space but
> 'du' says it is not all used up and see if they know why that might be
> the case and how to resolve it.

Yes, that's a standard trick used by browsers when they're playing
videos etc. In fact, I have a program called hoover-streams.py for
just this case. It finds out the browser programs' PIDs and searches
/proc/$PID/fd/ for any that are connected to deleted files. Then it
copies from the file descriptors repeatedly, into files named from
wallclock time, printing the size so far and the filename, prefixed
by a + if something was just copied into that file and - if it wasn't.
(This corresponds to the right marker in the progress bar under the
video; the left one shows how far you've viewed it).
When you haven't seen + for a while, the files should all be complete.

But it does seem unlikely that the OP is going to have GB of files
being hung onto like this, even a chemist. :)

Cheers,
David.

Re: allocating disk space (was: Upgrade Problem)

[Felix Miata]

David Wright composed on 2019-01-04 14:27 (UTC-0600):

> On Fri 04 Jan 2019 at 13:41:33 (-0500), Felix Miata wrote:

>> David Wright composed on 2019-01-04 10:19 (UTC-0600):

>> > On Fri 04 Jan 2019 at 04:30:00 (-0500), Felix Miata wrote:

>> >>> This partitioning scheme seems really odd and unwieldy.  

>> >> Indeed. Considering the absence of a sysadmin,

>> > What's so unusual about that?

>> Standing alone, absolutely nothing, but it wasn't standing alone

> (The OP is standing alone, leaving us aside.)

> By snipping the rhetorical question that introduces my paragraph, it
> now appears that "unusual" refers to the partitioning scheme. It
> doesn't.

It wasn't intended to.

> It refers to the absence of a sysadmin. 

Intended.

>> >> absence of 2 possible primary partitions on sda,
>> 
>> > If the OP partitioned an MBR disk intending to subdivide the
>> > filesystem, then it might be expected that they create an extended
>> > partition. Why bother with holding off until you've got two
>> > primary partitions set up first?

>> Off the top of my head:

>> 1-trivial I know, but avoiding seeing fdisk report "Partition table entries 
>> are not in disk order"

>> 2-less trivial: partitions not being in disk order

> I don't understand. The time sequence would be

> sda1=primary [ free   
>]

> sda1=primary [  "sda2"=extended   
>]

> sda1=primary [ sda5=logicalfree   
>]

> sda1=primary [ sda5=logical sda6=logical   free   
>]

> sda1=primary [ sda5=logical sda6=logical sda7=logical   free  
>]

> sda1=primary [ sda5=logical sda6=logical sda7=logical sda8=logical 
> possibly-free ]

> What's out of order?

This looks like it's assuming reference to the OP's disk state, which is not 
what I was writing
about. AFAIK, when entries /are/ out of order, far more steps had to have been 
involved than those
you listed.

>> 3-potential to have a primary partition added following a logical, thereby 
>> making following
>> freespace unavailable for one or more added logicals (disappearing 
>> freespace).

> With the scenario above, it would be usual to fill the disk with the
> extended partition, so there's no possibility of adding another primary.

Yes, when filling the disk at the outset. With the escalation of disk sizes 
over the years, it's
become more common not to allocate 100% at the outset. In non-ancient memory I 
only ever fully
allocated with my own disks at the outset with data disks, until small SDDs 
became cheap.

Some partitioning tools are better than others at allowing oneself to shoot 
oneself in the foot.

> Here's the partition table of this laptop. Care to guess it's
> evolution?

> Number  Start (sector)End (sector)  Size
>12048 2050047   1000.0 MiB
>2 2050048 2582527   260.0 MiB
>3 2582528 4630527   1000.0 MiB
>4 4630528 4892671   128.0 MiB
>5 4892672   347348991   163.3 GiB
>6   347348992   429268991   39.1 GiB /
>7   429268992   511188991   39.1 GiB
>8   511188992   883275775   177.4 GiB/home
>9   883275776   883292159   8.0 MiB
>   10   883292160   892084223   4.2 GiB  swap
>   11   892086272   892803071   350.0 MiB
>   12   892803072   894900223   1024.0 MiB
>   13   894900224   947329023   25.0 GiB
>   14   947329024   976773119   14.0 GiB

> Constrained by an inability to repartition the disk, how would
> you distribute a Debian system across it while wasting the
> least space?

That's a bit sketchy. How about you do one of mine?
Number  Start (sector)End (sector)  Size
   1  63   80324   39.2 MiB
   2   80325  578339   243.2 MiB
   3  578340 1397654   400.1 MiB
   5 1397718 3502169   1.0 GiB swap
   6 350223317848214   6.8 GiB WinSYS
   71784827830137939   5.9 GiB /
   83013800335053829   2.3 GiB /home
   93505389344451854   4.5 GiB
  104445191846540304   1019.7 MiB  /usr/local
  114654036858010714   5.5 GiB /
  125801077869481124   5.5 GiB /
  136948118880951534   5.5 GiB /
  148095159892421944   5.5 GiB /
  1592422008   103892354   5.5 GiB /
  16   103892418   115362764   5.5 GiB /
  17   115362828   126833174   5.5 GiB /
  18   126833238   138303584   5.5 GiB /
  19   138303648   149773994   5.5 GiB /
  20   149774058   161244404   5.5 GiB /
  21   161244468   172714814   5.5 GiB /
  22   172714878   184185224   5.5 GiB /
  23   

Re: Fwd: Upgrade Problem

[deloptes]

Gene Heskett wrote:

>> So I was thinking perhaps this is good for the economy, because if
>> most of the users were like me, there wouldn't be any economic growth
>> in the past years.
> 
> I see that too, darn it.

Suddenly I spotted something that fits our discussion by the worst example -
Apple.
https://www.youtube.com/watch?v=_XneTBhRPYk

Re: Upgrade Problem

[Michael Stone]

On Fri, Jan 04, 2019 at 05:04:49PM -0500, songbird wrote:

Roberto C  Sánchez wrote:

It might also indicate files that exist (i.e., occupy blocks) without
having directory entries.  For example, this is the case when a program
creates a temporary file, gets the descritor back from the syscall, then
immediatley calls unlink on it.  The file descriptor is still active and
the file can be written/read with the descriptor reference, but the file
cannot be seen with 'ls' and, as I recall, it will not show up in the
calculation made by 'du'.  The calculation made by 'df' will still be
accurate, though.


 wouldn't fsck clean that up?


not if the program is still running; it's not an error condition. the 
only case where fsck would help is if the whole machine crashed.


the traditional gotcha for "nonexistent file taking up space" is 
something generating a large log file, when someone tries to free the 
space by deleting the file. if the program writing it is still running, 
the file is gone but the space won't be freed until the program lets go 
of the file. lsof has a "deleted" indicator which can identify this.

Re: Upgrade Problem

[songbird]

Roberto C  Sánchez wrote:
...
> It might also indicate files that exist (i.e., occupy blocks) without
> having directory entries.  For example, this is the case when a program
> creates a temporary file, gets the descritor back from the syscall, then
> immediatley calls unlink on it.  The file descriptor is still active and
> the file can be written/read with the descriptor reference, but the file
> cannot be seen with 'ls' and, as I recall, it will not show up in the
> calculation made by 'du'.  The calculation made by 'df' will still be
> accurate, though.
>
> So, you might ask yourself, why would a program create a file only to
> immediately unlink it?  Well, it happen that if the program terminates
> abnormally (i.e,. crashes), the disappearance of the reference to the
> file descriptor when the kernel cleans up the process table also causes
> it to free the associated blocks.  The same thing happens in a normal
> program termination, but in the abnormal case you have no guarantee that
> any clean up code will run.
>
> As it happens, this is a great practical interview question for a system
> administrator.  Give them a machine where 'df' reports no free space but
> 'du' says it is not all used up and see if they know why that might be
> the case and how to resolve it.

  wouldn't fsck clean that up?

  if it might be potential useful information you were missing
and wanted to get back you could copy the entire partition and
then run a recovery/forensics program on it to see what it all
was.


  songbird

Re: Upgrade Problem

[songbird]

David Wright wrote:
> On Fri 04 Jan 2019 at 17:13:44 (+), Eduardo M KALINOWSKI wrote:
>> On sex, 04 jan 2019, David Wright wrote:
>> > On Fri 04 Jan 2019 at 16:52:45 (+), Eduardo M KALINOWSKI wrote:
>> > > And in this case, the problem is easy to solve:
>> > >   rm /path/to/some/large/files/*
>> > 
>> > Wrong again. The free space on /home is sufficient to hold 10 copies
>> > of the entire / filesystem. And you presuppose that these large files
>> > exist, for which the OP has currently shown no evidence.
>> 
>> The used disk space must be somewhere. But you're right, there is
>> another possibility: lots of small files that together occupy a lot of
>> space.
>
> There's at least one other scenario that it would be worth eliminating
> by checking that this equation is true (allowing for filesystem overheads):
>
>   # du -shx
> +
>   $ df's Available
> ≃
>  partition's size.
>
> This checks whether the mountpoints for /var and so on had files in
> them before the partitions were mounted. These files would consume
> filespace but not be detected by du.

  very good points i hadn't considered.

  i do know it happens.

  thanks for the reminder.  :)


  songbird

Re: Upgrade Problem

[deloptes]

Joe wrote:

> Reinstalling looks good until you've done it, the old installation is
> history, and over the next few weeks you realise how much time you had
> spent over the last few years tweaking your computer to get it the way
> you like it.
> 
> And no, you cannot at the same time a) clear out the cruft, choose
> different and better software and do the partitioning better and b) just
> backup the old /etc and restore it.
> 
> Been there, done all that...
> 
> Apart from the fact that reinstalling becomes attractive only after
> you've really broken it badly, beyond the point where you can do dpkg
> --get-selections and suchlike. Nobody ever reinstalls before they
> desperately need to.

Might be true for linux ... for the MS crap it is a must, so I learned doing
backups (linux usb stick) and when I have to refresh my wife's or sister's
PC, I would restore the last backup I took right after refreshing the PC
the last time - you need some time to catch up with all the updates, but it
is less if you start from 10y ago.
It means this OS was not meant to be operated more than 3-5y even if you do
not do much on it it gets slower and slower as if a counter is running
somewhere.

I personally do not reinstall - PCs and servers are up to date - they were
installed some 10-15y ago. Migrated a lot of things though - bigger disks,
new motherboards etc. As times go by and things get more and more complex a
proper planning is required even for doing small things like adding
additional disks, but ... this falls into category sysadmin - a role I
avoid to play unless required.

regards

Re: Upgrade Problem

[Roberto C . Sánchez]

On Fri, Jan 04, 2019 at 02:39:40PM -0600, David Wright wrote:
> 
> There's at least one other scenario that it would be worth eliminating
> by checking that this equation is true (allowing for filesystem overheads):
> 
>   # du -shx
> +
>   $ df's Available
> ≃
>  partition's size.
> 
> This checks whether the mountpoints for /var and so on had files in
> them before the partitions were mounted. These files would consume
> filespace but not be detected by du.
> 

It might also indicate files that exist (i.e., occupy blocks) without
having directory entries.  For example, this is the case when a program
creates a temporary file, gets the descritor back from the syscall, then
immediatley calls unlink on it.  The file descriptor is still active and
the file can be written/read with the descriptor reference, but the file
cannot be seen with 'ls' and, as I recall, it will not show up in the
calculation made by 'du'.  The calculation made by 'df' will still be
accurate, though.

So, you might ask yourself, why would a program create a file only to
immediately unlink it?  Well, it happen that if the program terminates
abnormally (i.e,. crashes), the disappearance of the reference to the
file descriptor when the kernel cleans up the process table also causes
it to free the associated blocks.  The same thing happens in a normal
program termination, but in the abnormal case you have no guarantee that
any clean up code will run.

As it happens, this is a great practical interview question for a system
administrator.  Give them a machine where 'df' reports no free space but
'du' says it is not all used up and see if they know why that might be
the case and how to resolve it.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Fwd: Upgrade Problem

[Gene Heskett]

On Friday 04 January 2019 14:34:59 Brian wrote:

> On Fri 04 Jan 2019 at 13:49:52 -0500, Gene Heskett wrote:
> > On Friday 04 January 2019 13:31:05 Nicolas George wrote:
> > > deloptes (12019-01-04):
> > > >   We just pointed out
> > > > that you do not have to be a sysadmin to operate a computer.
> > >
> > > And you are wrong. Operating a computer requires a sysadmin, there
> > > is no way around it. If there is no dedicated one, that makes the
> > > user the sysadmin. Their choice whether they become competent or
> > > not;
> > >
> > > Regards,
> >
> > Another demonstration of TANSTAAFL Nicolas.  Its a law one will obey
> > no matter how hard you try to ignore it.
>
> I wish I understood that!

Why not, There Ain't No Such Thing As A Free lunch. If you think the 
peanuts are free, check the price of the beer IOW.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Upgrade Problem

[Brian]

On Fri 04 Jan 2019 at 14:02:27 -0500, Stephen P. Molnar wrote:

> On 01/04/2019 01:11 PM, Felix Miata wrote:
> > Stephen P. Molnar composed on 2019-01-04 12:57 (UTC-0500):
> > 
> > > I haven't messed around with partitioning since the early days of
> > > Slackware, and that was with a great deal of trepidation?
> > You just multiplied my curiosity about what exactly was responsible for 
> > your current partitioning
> > scheme, not to mention what will be used for your planned reinstallation.
> The installer for Debian Stretch has an new option thzt  thought I'd try.:
> separate /home, /var and/temp partitions.

I don't regard that option as new. Not in 2018/2019 and not from the
present d-i.

> Over the last 50+ years as  Research Scientist I have tried to follow the
> policy that it's all right to make mistakes..  As long as you try not to
> make the same mistake in the same contiguous four hours - that is if you
> make a mistake in the morning, wait until that afternoon to repeat it.  But
> even more important from the mistake and try not to repeat it. I think that
> making mistakes is an integral part of the scientific method.
> 
> Of course, there is a corollary - you can't teach an old scientist new
> science.

You have not read Robert Boyle or Isacc Newton in recent weeks? That's
all apart from the idea that there is nothing new to be learned. Did
you say you are a scientist? Apparently not a physicist, anyway.

> 
> Having babbled for the last two paragraphs, I'll close buy saying that I
> will revert to the entire installation on the same partition.

That's the best. Ignore LVM advocates.

-- 

Re: Upgrade Problem

[David Wright]

On Fri 04 Jan 2019 at 17:13:44 (+), Eduardo M KALINOWSKI wrote:
> On sex, 04 jan 2019, David Wright wrote:
> > On Fri 04 Jan 2019 at 16:52:45 (+), Eduardo M KALINOWSKI wrote:
> > > And in this case, the problem is easy to solve:
> > >   rm /path/to/some/large/files/*
> > 
> > Wrong again. The free space on /home is sufficient to hold 10 copies
> > of the entire / filesystem. And you presuppose that these large files
> > exist, for which the OP has currently shown no evidence.
> 
> The used disk space must be somewhere. But you're right, there is
> another possibility: lots of small files that together occupy a lot of
> space.

There's at least one other scenario that it would be worth eliminating
by checking that this equation is true (allowing for filesystem overheads):

  # du -shx
+
  $ df's Available
≃
 partition's size.

This checks whether the mountpoints for /var and so on had files in
them before the partitions were mounted. These files would consume
filespace but not be detected by du.

Cheers,
David.

Re: Upgrade Problem

[Joe]

On Fri, 04 Jan 2019 20:46:53 +0100
deloptes  wrote:


> 
> I asked why he does not reinstall, but didn't get meaningful answer -
> only, I can not do it and it takes too much time.
> 
> One can not argue with educated people, so I gave up.
> This is just an example how it works for most of the people. I am
> sure if he were working for the money he spends, he were reinstalling.

Reinstalling looks good until you've done it, the old installation is
history, and over the next few weeks you realise how much time you had
spent over the last few years tweaking your computer to get it the way
you like it.

And no, you cannot at the same time a) clear out the cruft, choose
different and better software and do the partitioning better and b) just
backup the old /etc and restore it.

Been there, done all that...

Apart from the fact that reinstalling becomes attractive only after
you've really broken it badly, beyond the point where you can do dpkg
--get-selections and suchlike. Nobody ever reinstalls before they
desperately need to.

-- 
Joe

Re: Upgrade Problem

[David Wright]

On Fri 04 Jan 2019 at 13:41:33 (-0500), Felix Miata wrote:
> David Wright composed on 2019-01-04 10:19 (UTC-0600):
> 
> > On Fri 04 Jan 2019 at 04:30:00 (-0500), Felix Miata wrote:
> 
> >>> This partitioning scheme seems really odd and unwieldy.  
> 
> >> Indeed. Considering the absence of a sysadmin,
> 
> > What's so unusual about that?
> 
> Standing alone, absolutely nothing, but it wasn't standing alone

(The OP is standing alone, leaving us aside.)

By snipping the rhetorical question that introduces my paragraph, it
now appears that "unusual" refers to the partitioning scheme. It
doesn't. It refers to the absence of a sysadmin. Here's the paragraph
again:

“What's so unusual about that? For a long time I ran linux and work but
 didn't consider myself an "operator" or "sysadmin". Employees in those
 categories ran closed shops of MS and Apple kit, plus a splinter group
 running what they considered "proper" unix on kit that I couldn't
 start to afford. Most of mine was 2nd hand PC cast offs.”

> >> absence of 2 possible primary partitions on sda,
> 
> > If the OP partitioned an MBR disk intending to subdivide the
> > filesystem, then it might be expected that they create an extended
> > partition. Why bother with holding off until you've got two
> > primary partitions set up first?
> 
> Off the top of my head:
> 
> 1-trivial I know, but avoiding seeing fdisk report "Partition table entries 
> are not in disk order"
> 
> 2-less trivial: partitions not being in disk order

I don't understand. The time sequence would be

sda1=primary [ free 
 ]

sda1=primary [  "sda2"=extended 
 ]

sda1=primary [ sda5=logicalfree 
 ]

sda1=primary [ sda5=logical sda6=logical   free 
 ]

sda1=primary [ sda5=logical sda6=logical sda7=logical   free
 ]

sda1=primary [ sda5=logical sda6=logical sda7=logical sda8=logical 
possibly-free ]

What's out of order?

> 3-potential to have a primary partition added following a logical, thereby 
> making following
> freespace unavailable for one or more added logicals (disappearing freespace).

With the scenario above, it would be usual to fill the disk with the
extended partition, so there's no possibility of adding another primary.
There may be occasional instances like the following squence, but
they'd be pretty rare in comparison:

sda1=primary  sda2=primary   sda3=primary sda4=primary

sda1=primary freesda3=primary sda4=primary

sda1=primary "sda2"=extended sda3=primary sda4=primary

> >> and the absence of sda6,
> 
> > I assume that's swap.

Yes.

> Yes, but:
> 
> # df -hl
> Filesystem  Size  Used Avail Use% Mounted on
> /dev/sda123G   23G 0 100% /
> /dev/sda2 ?   extended (presumably)
> /dev/sda5   9.2G  6.0G  2.8G  69% /var
> /dev/sda6 ?   ?   ?   swap
> /dev/sda7   1.9G  6.5M  1.7G   1% /tmp
> /dev/sda8   416G  103G  292G  27% /home
> ?freespace?   ?
> 
> Where is the logic responsible for the original allocations? Would any Debian 
> Installer have done it
> without intervention from the admin? It looks like the work of a naive admin. 
> Yet, OP claimed "I
> haven't messed around with partitioning since the early days of Slackware, 
> and that was with a great
> deal of trepidation".

We have no idea without being told the earlier history of the scheme,
what the intent was at the time of creating them, and how their
subsequent use evolved.

Here's the partition table of this laptop. Care to guess it's
evolution?

Number  Start (sector)End (sector)  Size
   12048 2050047   1000.0 MiB
   2 2050048 2582527   260.0 MiB
   3 2582528 4630527   1000.0 MiB
   4 4630528 4892671   128.0 MiB
   5 4892672   347348991   163.3 GiB
   6   347348992   429268991   39.1 GiB /
   7   429268992   511188991   39.1 GiB
   8   511188992   883275775   177.4 GiB/home
   9   883275776   883292159   8.0 MiB
  10   883292160   892084223   4.2 GiB  swap
  11   892086272   892803071   350.0 MiB
  12   892803072   894900223   1024.0 MiB
  13   894900224   947329023   25.0 GiB
  14   947329024   976773119   14.0 GiB

Constrained by an inability to repartition the disk, how would
you distribute a Debian system across it while wasting the
least space?

Cheers,
David.

Re: Fwd: Upgrade Problem

[Roberto C . Sánchez]

On Fri, Jan 04, 2019 at 08:09:55PM +, Brian wrote:
> On Fri 04 Jan 2019 at 14:37:36 -0500, Roberto C. Sánchez wrote:
> 
> > On Fri, Jan 04, 2019 at 07:34:59PM +, Brian wrote:
> > > On Fri 04 Jan 2019 at 13:49:52 -0500, Gene Heskett wrote:
> > > 
> > > > On Friday 04 January 2019 13:31:05 Nicolas George wrote:
> > > > 
> > > > > deloptes (12019-01-04):
> > > > > >   We just pointed 
> > > > > > out
> > > > > > that you do not have to be a sysadmin to operate a computer.
> > > > >
> > > > > And you are wrong. Operating a computer requires a sysadmin, there is
> > > > > no way around it. If there is no dedicated one, that makes the user
> > > > > the sysadmin. Their choice whether they become competent or not;
> > > > >
> > > > > Regards,
> > > > 
> > > > Another demonstration of TANSTAAFL Nicolas.  Its a law one will obey no 
> > > > matter how hard you try to ignore it.
> > > 
> > > I wish I understood that!
> > > 
> > https://en.wikipedia.org/wiki/TANSTAAFL
> 
> TANSTAAFL wasn't what I didn't understand, I know what it means. It's
> the whole post which is a mystery to me. Apart from you, perhaps.
> 
My mistake.  I think Gene's comment means something like, "people
always try to get something for nothing, but it never works."

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Fwd: Upgrade Problem

[Brian]

On Fri 04 Jan 2019 at 14:37:36 -0500, Roberto C. Sánchez wrote:

> On Fri, Jan 04, 2019 at 07:34:59PM +, Brian wrote:
> > On Fri 04 Jan 2019 at 13:49:52 -0500, Gene Heskett wrote:
> > 
> > > On Friday 04 January 2019 13:31:05 Nicolas George wrote:
> > > 
> > > > deloptes (12019-01-04):
> > > > > We just pointed 
> > > > > out
> > > > > that you do not have to be a sysadmin to operate a computer.
> > > >
> > > > And you are wrong. Operating a computer requires a sysadmin, there is
> > > > no way around it. If there is no dedicated one, that makes the user
> > > > the sysadmin. Their choice whether they become competent or not;
> > > >
> > > > Regards,
> > > 
> > > Another demonstration of TANSTAAFL Nicolas.  Its a law one will obey no 
> > > matter how hard you try to ignore it.
> > 
> > I wish I understood that!
> > 
> https://en.wikipedia.org/wiki/TANSTAAFL

TANSTAAFL wasn't what I didn't understand, I know what it means. It's
the whole post which is a mystery to me. Apart from you, perhaps.

-- 
Brian.

Re: Upgrade Problem

[Richard Hector]

On 4/01/19 9:49 PM, Andy Smith wrote:
> Stephen, I think you're going to have to analyse where the space is
> being used. If you use a graphical desktop then there might be a
> graphical application that can help with this. On GNOME it's called
> Disk Usage Analyzer. On the command line you could try something
> like:
> 
> $ sudo du -xh / | sort -rh | less

I find ncdu very useful for this - it's a full-screen terminal-based
interactive du, and lets you drill down to find where your space is used.

Difficult to install if apt isn't working, but in the past (IIRC) I've
just copied the binary from another machine.

Richard



signature.asc
Description: OpenPGP digital signature

Re: Fwd: Upgrade Problem

[deloptes]

Nicolas George wrote:

> It really is not, because the resources invested in the old computer are
> wasted (unless somebody gets it and recycles it). It is the same scheme
> than in Chaplin's _The Kid_: breaking a window to let a glazier sell a
> new one.
> 
> Alas, the idiotic way most people evaluate the economy, the GDP, often
> makes it seem that kind of thing is good. But according to the GDP,
> being stuck in traffic is good for the economy.
> 
> Regards,

I asked why he does not reinstall, but didn't get meaningful answer - only,
I can not do it and it takes too much time.

One can not argue with educated people, so I gave up.
This is just an example how it works for most of the people. I am sure if he
were working for the money he spends, he were reinstalling.

Re: Fwd: Upgrade Problem

[deloptes]

Brian wrote:

> Using the facilities on a computer is what a user does, just like the
> simple task of switching on an electric light in a house.
> 
> If by "operating", deloptes means "using", I think I could agree. If
> he means change the bulb or mend the fuse or go down to to the local
> substation to fix the problem we are outside the province of a user's
> remit. How about deleting a power station or two to get the lights in
> the house working?
> 
> The problem with computers is that a user says "this is *my* computer
> and I will do with it what I want. Consequently, the easiest way to
> happiness is to destroy the system and rebuild. Competence with system
> administration and its philosophy is hardly at the forefront in the use
> of computers.
> 
> Having said that, a full partition does require sensitive treatment. It
> hasn't received it in this thread.

you understood correctly and I agree completely with you.

I wonder no one suggested for the OP to take a backup, but I think OP knows
this already.

Re: Fwd: Upgrade Problem

[deloptes]

Gene Heskett wrote:

> On Friday 04 January 2019 13:31:05 Nicolas George wrote:
> 
>> deloptes (12019-01-04):
>> >We just pointed out
>> > that you do not have to be a sysadmin to operate a computer.
>>
>> And you are wrong. Operating a computer requires a sysadmin, there is
>> no way around it. If there is no dedicated one, that makes the user
>> the sysadmin. Their choice whether they become competent or not;
>>
>> Regards,
> 
> Another demonstration of TANSTAAFL Nicolas.  Its a law one will obey no
> matter how hard you try to ignore it.
> 
> Cheers, Gene Heskett

It requires sysadmin as far as a car requires a mechanic, but you could
always go to the shop and buy new one.

What I wanted to point out is that it is not a requirement per se for the
operation of the device. You are mixing both.

For the present case OP is acting as sysadmin - nothing wrong, so your point
is clear, but you mistakenly presume that one should play the same role. It
is not a must. It is a matter of choice and skills.

Even for the car, I can repair most of it if I am skilled and have the
manual, but I do not have to.

regards

Re: Fwd: Upgrade Problem

[Roberto C . Sánchez]

On Fri, Jan 04, 2019 at 07:34:59PM +, Brian wrote:
> On Fri 04 Jan 2019 at 13:49:52 -0500, Gene Heskett wrote:
> 
> > On Friday 04 January 2019 13:31:05 Nicolas George wrote:
> > 
> > > deloptes (12019-01-04):
> > > >   We just pointed out
> > > > that you do not have to be a sysadmin to operate a computer.
> > >
> > > And you are wrong. Operating a computer requires a sysadmin, there is
> > > no way around it. If there is no dedicated one, that makes the user
> > > the sysadmin. Their choice whether they become competent or not;
> > >
> > > Regards,
> > 
> > Another demonstration of TANSTAAFL Nicolas.  Its a law one will obey no 
> > matter how hard you try to ignore it.
> 
> I wish I understood that!
> 
https://en.wikipedia.org/wiki/TANSTAAFL

-- 
Roberto C. Sánchez

Re: Fwd: Upgrade Problem

[Brian]

On Fri 04 Jan 2019 at 13:49:52 -0500, Gene Heskett wrote:

> On Friday 04 January 2019 13:31:05 Nicolas George wrote:
> 
> > deloptes (12019-01-04):
> > > We just pointed out
> > > that you do not have to be a sysadmin to operate a computer.
> >
> > And you are wrong. Operating a computer requires a sysadmin, there is
> > no way around it. If there is no dedicated one, that makes the user
> > the sysadmin. Their choice whether they become competent or not;
> >
> > Regards,
> 
> Another demonstration of TANSTAAFL Nicolas.  Its a law one will obey no 
> matter how hard you try to ignore it.

I wish I understood that!

-- 
Brian.

Re: Fwd: Upgrade Problem

[Brian]

On Fri 04 Jan 2019 at 19:31:05 +0100, Nicolas George wrote:

> deloptes (12019-01-04):
> >   We just pointed out
> > that you do not have to be a sysadmin to operate a computer.
> 
> And you are wrong. Operating a computer requires a sysadmin, there is no
> way around it. If there is no dedicated one, that makes the user the
> sysadmin. Their choice whether they become competent or not;

Using the facilities on a computer is what a user does, just like the
simple task of switching on an electric light in a house.

If by "operating", deloptes means "using", I think I could agree. If
he means change the bulb or mend the fuse or go down to to the local
substation to fix the problem we are outside the province of a user's
remit. How about deleting a power station or two to get the lights in
the house working?

The problem with computers is that a user says "this is *my* computer
and I will do with it what I want. Consequently, the easiest way to
happiness is to destroy the system and rebuild. Competence with system
administration and its philosophy is hardly at the forefront in the use
of computers.

Having said that, a full partition does require sensitive treatment. It
hasn't received it in this thread.

-- 
Brian.

Re: Upgrade Problem

[Stephen P. Molnar]

On 01/04/2019 01:11 PM, Felix Miata wrote:

Stephen P. Molnar composed on 2019-01-04 12:57 (UTC-0500):


I haven't messed around with partitioning since the early days of
Slackware, and that was with a great deal of trepidation?

You just multiplied my curiosity about what exactly was responsible for your 
current partitioning
scheme, not to mention what will be used for your planned reinstallation.
The installer for Debian Stretch has an new option thzt  thought I'd 
try.:  separate /home, /var and/temp partitions.


Over the last 50+ years as  Research Scientist I have tried to follow 
the policy that it's all right to make mistakes..  As long as you try 
not to make the same mistake in the same contiguous four hours - that is 
if you make a mistake in the morning, wait until that afternoon to 
repeat it.  But even more important from the mistake and try not to 
repeat it. I think that making mistakes is an integral part of the 
scientific method.


Of course, there is a corollary - you can't teach an old scientist new 
science.


Having babbled for the last two paragraphs, I'll close buy saying that I 
will revert to the entire installation on the same partition.


--
Stephen P. Molnar, Ph.D.
Consultant
www.molecular-modeling.net
(614)312-7528 (c)
Skype: smolnar1

Re: Fwd: Upgrade Problem

[Gene Heskett]

On Friday 04 January 2019 13:31:05 Nicolas George wrote:

> deloptes (12019-01-04):
> >   We just pointed out
> > that you do not have to be a sysadmin to operate a computer.
>
> And you are wrong. Operating a computer requires a sysadmin, there is
> no way around it. If there is no dedicated one, that makes the user
> the sysadmin. Their choice whether they become competent or not;
>
> Regards,

Another demonstration of TANSTAAFL Nicolas.  Its a law one will obey no 
matter how hard you try to ignore it.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Fwd: Upgrade Problem

[Gene Heskett]

On Friday 04 January 2019 13:24:39 deloptes wrote:

> Greg Wooledge wrote:
> > All he has to do is find whatever's taking up an unexpected amount
> > of space in his root file system, and get rid of it.  This is an
> > essential system management skill that he HAS to learn, which he
> > will continue to use well beyond the current crisis.
> >
> > Reinstalling on a larger disk to "fix" this is like buying a new car
> > every time you run out of gasoline.
>
> almost like my brother in law who is buying a new notebook every 2
> years because the old one is getting slow. You can imagine which OS it
> is :)
>
> So I was thinking perhaps this is good for the economy, because if
> most of the users were like me, there wouldn't be any economic growth
> in the past years.

I see that too, darn it.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Upgrade Problem

[Felix Miata]

David Wright composed on 2019-01-04 10:19 (UTC-0600):

> On Fri 04 Jan 2019 at 04:30:00 (-0500), Felix Miata wrote:

>>> This partitioning scheme seems really odd and unwieldy.  

>> Indeed. Considering the absence of a sysadmin,

> What's so unusual about that?

Standing alone, absolutely nothing, but it wasn't standing alone

>> absence of 2 possible primary partitions on sda,

> If the OP partitioned an MBR disk intending to subdivide the
> filesystem, then it might be expected that they create an extended
> partition. Why bother with holding off until you've got two
> primary partitions set up first?

Off the top of my head:

1-trivial I know, but avoiding seeing fdisk report "Partition table entries are 
not in disk order"

2-less trivial: partitions not being in disk order

3-potential to have a primary partition added following a logical, thereby 
making following
freespace unavailable for one or more added logicals (disappearing freespace).

>> and the absence of sda6,

> I assume that's swap.

Yes, but:

# df -hl
Filesystem  Size  Used Avail Use% Mounted on
/dev/sda123G   23G 0 100% /
/dev/sda2   ?   extended (presumably)
/dev/sda5   9.2G  6.0G  2.8G  69% /var
/dev/sda6   ?   ?   ?   swap
/dev/sda7   1.9G  6.5M  1.7G   1% /tmp
/dev/sda8   416G  103G  292G  27% /home
?freespace? ?

Where is the logic responsible for the original allocations? Would any Debian 
Installer have done it
without intervention from the admin? It looks like the work of a naive admin. 
Yet, OP claimed "I
haven't messed around with partitioning since the early days of Slackware, and 
that was with a great
deal of trepidation".

> ...but the OP would become a better sysadmin by learning something during the 
> cleanup.

Indeed!
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: Fwd: Upgrade Problem

[Nicolas George]

deloptes (12019-01-04):
> So I was thinking perhaps this is good for the economy, because if most of
> the users were like me, there wouldn't be any economic growth in the past
> years.

It really is not, because the resources invested in the old computer are
wasted (unless somebody gets it and recycles it). It is the same scheme
than in Chaplin's _The Kid_: breaking a window to let a glazier sell a
new one.

Alas, the idiotic way most people evaluate the economy, the GDP, often
makes it seem that kind of thing is good. But according to the GDP,
being stuck in traffic is good for the economy.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature

Re: Fwd: Upgrade Problem

[Nicolas George]

deloptes (12019-01-04):
> We just pointed out
> that you do not have to be a sysadmin to operate a computer.

And you are wrong. Operating a computer requires a sysadmin, there is no
way around it. If there is no dedicated one, that makes the user the
sysadmin. Their choice whether they become competent or not;

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature

Re: Upgrade Problem

[songbird]

Stephen P. Molnar wrote:
> I want to thank those of you who responded to my request for assistance.
>
> A number of the replies, particularly those that did not editorialize, 
> where useful in that they convinced me that reinstalling the OS is the 
> simplest remedy for the problems.
>
> Let us put this thread to bed and stop wasting backspace.

  you're welcome, but for the life of me i can't figure
out why finding a few large files on / and moving or
removing them as needed to free up space isn't a quicker
solution for now...

  anyways, good luck.  :)


  asides follow:

  when i set up my new system i purposely did not include
LVM because i felt i didn't need that added layer of
complexity.  i also didn't use separate home directories
or var directories like i had on previous installs.

  with the price of SSDs coming down i felt that it was
more important to just have everything together and if i
need to create more space it will likely be easier to 
just get another SSD and plug it in.  so my current 
configuration looks like:


Filesystem 1K-blocks  Used Available Use% Mounted on
/dev/sda2  412282128 194153408 197116244  50% /
/dev/sda3   45876068   4362484  39153472  11% /ro1-root
/dev/sda1 973952  2100971852   1% /boot/efi

  and i have a swap space just in case i ever need it
(it rarely gets used):

/dev/sda4  935546880 974608383  39061504  18.6G Linux swap

  my /dev/sda3 partition is for running a backup stable
installation just in case i muck up the other testing/
unstable version on /dev/sda2 and need a fast way to 
get back on-line.  as yet another backup in case i really
mess up the system i have a stable installation to a
bootable USB stick.

  if you are installing to a newer machine be sure that
the EFI option is detected and used before you install
as fixing it afterwards can be painful.


  songbird

Re: Fwd: Upgrade Problem

[deloptes]

Greg Wooledge wrote:

> All he has to do is find whatever's taking up an unexpected amount of
> space in his root file system, and get rid of it.  This is an essential
> system management skill that he HAS to learn, which he will continue
> to use well beyond the current crisis.
> 
> Reinstalling on a larger disk to "fix" this is like buying a new car
> every time you run out of gasoline.

almost like my brother in law who is buying a new notebook every 2 years
because the old one is getting slow. You can imagine which OS it is :)

So I was thinking perhaps this is good for the economy, because if most of
the users were like me, there wouldn't be any economic growth in the past
years.

Re: Upgrade Problem

[Felix Miata]

Stephen P. Molnar composed on 2019-01-04 12:57 (UTC-0500):

> I haven't messed around with partitioning since the early days of 
> Slackware, and that was with a great deal of trepidation? 

You just multiplied my curiosity about what exactly was responsible for your 
current partitioning
scheme, not to mention what will be used for your planned reinstallation.
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: Upgrade Problem

[Stephen P. Molnar]

On 01/04/2019 12:13 PM, Roberto C. Sánchez wrote:

On Fri, Jan 04, 2019 at 05:47:07PM +0100, steve wrote:

Le vendredi 04 janvier 2019, Stephen P. Molnar a écrit :



where useful in that they convinced me that reinstalling the OS is the
simplest remedy for the problems.

You're welcome. But this last sentence is pretty sad because normally,
issues like yours do not require windows-style operation. For your info,
I have not reinstalled my Debian system for the last 15 years.
Reinstalling is a solution but what if in ten days the same issue arises
again? You'll ask the same questions and won't have learned much…

One of the power of GNU/Linux is that you can learn and fix problems.


I am not sure if Stephen went with an LVM solution, though I hope he
did.  Given that his former partition scheme was problematic for his use
case and that it was based on static partitions, the reinstallation
route may have been the best course.

It is important to remember that adjusting a static partition layout is
a high risk operation for even a highly skilled system administrator who
has performed the operation multiple times.  I suspect that if Stephen
even considered the possibility of attempting that sort of operation,
that he rightly judged the time investment required and likelihood of
causing irreparable damage to his configuration were justification
enough to reinstall.

Sometimes one just wants to get the job done and fiddling around with
system issues becomes more of an obstacle than an opportunity to learn.

Regards,

-Roberto

I haven't messed around with partitioning since the early days of 
Slackware, and that was with a great deal of trepidation?  As far as 
computer OS's are concerned I hope that the days of fools rush in are a 
thing of the past.


--
Stephen P. Molnar, Ph.D.
Consultant
www.molecular-modeling.net
(614)312-7528 (c)
Skype: smolnar1

Re: Fwd: Upgrade Problem

[deloptes]

Nicolas George wrote:

> Exactly. And the kind of payment that is expected from you for help on
> this mailing-list is not pecuniary, of course. It is that you do not
> just consume the answers given to you but instead try to increase your
> knowledge and understanding so that maybe one day you would be the one
> helping.

but you do not know the OP and can not estimate what he is doing with the
answers, so why should you judge others statements. We just pointed out
that you do not have to be a sysadmin to operate a computer.

regards

Re: Upgrade Problem

[Roberto C . Sánchez]

On Fri, Jan 04, 2019 at 05:47:07PM +0100, steve wrote:
> Le vendredi 04 janvier 2019, Stephen P. Molnar a écrit :
> 
> 
> > where useful in that they convinced me that reinstalling the OS is the
> > simplest remedy for the problems.
> 
> You're welcome. But this last sentence is pretty sad because normally,
> issues like yours do not require windows-style operation. For your info,
> I have not reinstalled my Debian system for the last 15 years.
> Reinstalling is a solution but what if in ten days the same issue arises
> again? You'll ask the same questions and won't have learned much…
> 
> One of the power of GNU/Linux is that you can learn and fix problems.
> 
I am not sure if Stephen went with an LVM solution, though I hope he
did.  Given that his former partition scheme was problematic for his use
case and that it was based on static partitions, the reinstallation
route may have been the best course.

It is important to remember that adjusting a static partition layout is
a high risk operation for even a highly skilled system administrator who
has performed the operation multiple times.  I suspect that if Stephen
even considered the possibility of attempting that sort of operation,
that he rightly judged the time investment required and likelihood of
causing irreparable damage to his configuration were justification
enough to reinstall.

Sometimes one just wants to get the job done and fiddling around with
system issues becomes more of an obstacle than an opportunity to learn.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Upgrade Problem

[Eduardo M KALINOWSKI]

On sex, 04 jan 2019, David Wright wrote:

On Fri 04 Jan 2019 at 16:52:45 (+), Eduardo M KALINOWSKI wrote:

And in this case, the problem is easy to solve:
  rm /path/to/some/large/files/*


Wrong again. The free space on /home is sufficient to hold 10 copies
of the entire / filesystem. And you presuppose that these large files
exist, for which the OP has currently shown no evidence.


The used disk space must be somewhere. But you're right, there is  
another possibility: lots of small files that together occupy a lot of  
space.

--
Eduardo M KALINOWSKI
edua...@kalinowski.com.br

Re: Upgrade Problem

[David Wright]

On Fri 04 Jan 2019 at 16:52:45 (+), Eduardo M KALINOWSKI wrote:
> On sex, 04 jan 2019, steve wrote:
> > > where useful in that they convinced me that reinstalling the
> > > OS is the simplest remedy for the problems.
> > 
> > You're welcome. But this last sentence is pretty sad because normally,
> > issues like yours do not require windows-style operation. For your info,
> > I have not reinstalled my Debian system for the last 15 years.
> > Reinstalling is a solution but what if in ten days the same issue arises
> > again? You'll ask the same questions and won't have learned much…
> > 
> > One of the power of GNU/Linux is that you can learn and fix problems.
> 
> I agree.
> 
> And in this case, the problem is easy to solve:
>   rm /path/to/some/large/files/*

Wrong again. The free space on /home is sufficient to hold 10 copies
of the entire / filesystem. And you presuppose that these large files
exist, for which the OP has currently shown no evidence.

Cheers,
David.

Re: Upgrade Problem

[Eduardo M KALINOWSKI]

On sex, 04 jan 2019, Eduardo M KALINOWSKI wrote:

And in this case, the problem is easy to solve:
  rm /path/to/some/large/files/*


The usual suspects (/var/logs, /var/cache, etc) have already been  
mentioned, and are in a different partition. One place to investigate  
is /lib/modules. It can grow quite a bit if one has several kernels  
installed. Ideal way to free up space is to apt-get remove the older  
kernel packages, but since that will likely not work while there is no  
free space, one could simply delete the files (with care not to remove  
the modules of the running kernel), and then remove the packages.

--
Eduardo M KALINOWSKI
edua...@kalinowski.com.br

Re: Fwd: Upgrade Problem

[David Wright]

On Fri 04 Jan 2019 at 08:15:11 (-0500), Greg Wooledge wrote:
> On Thu, Jan 03, 2019 at 09:22:49PM -0500, Gene Heskett wrote:
> > In this case, I hate to sound like 
> > an ass, but perhaps a re-install is in the future, doing the reinstall 
> > to a new drive [...]
> 
> Come on, people.  Show some sense.  (And yes, this includes the OP.)
> 
> He simply has a full root file system.  He has shown the df output at
> least twice now.
> 
> (A full root file system clearly and plainly shown by df despite the OP
> claiming he is certain he's not out of space, no less.)

That's rather unfair. songbird asked after space/inodes and the OP
responded with "so far as I know". With space in so many places,
it would be easy for someone to overlook no space on /. (Which is
why I replied "yes, but we don't" and asked for df to be posted).

On posting the output, the OP asked "could this e [sic] a problem?".

I see no "claim". AFAICT the OP's query was not directly replied to
until today, though obviously it, or the other df listing, was
read by others, continuing the discussion on several fronts.

Stepping back and reading this thread, it seems that there are a lot
of "solutions" being thrown in before the OP has been encouraged to
find out what the true root (pun intended) of the problem is.
As Felix hinted/suggested, I thought rather harshly, the problem
might not be caused by what you can see, but by what you can't.
The OP needs to examine the filesystem usage and see if that squares
with the free space, not go round deleting things (or shopping).

Most people's systems evolve (unless they're fresh install types)
and the history of the system might need to be taken into account.

Cheers,
David.

Re: Upgrade Problem

[Eduardo M KALINOWSKI]

On sex, 04 jan 2019, steve wrote:
where useful in that they convinced me that reinstalling the OS is  
the simplest remedy for the problems.


You're welcome. But this last sentence is pretty sad because normally,
issues like yours do not require windows-style operation. For your info,
I have not reinstalled my Debian system for the last 15 years.
Reinstalling is a solution but what if in ten days the same issue arises
again? You'll ask the same questions and won't have learned much…

One of the power of GNU/Linux is that you can learn and fix problems.


I agree.

And in this case, the problem is easy to solve:
  rm /path/to/some/large/files/*
--
Eduardo M KALINOWSKI
edua...@kalinowski.com.br

Re: Upgrade Problem

[steve]

Le vendredi 04 janvier 2019, Stephen P. Molnar a écrit :


where useful in that they convinced me that reinstalling the OS is the 
simplest remedy for the problems.


You're welcome. But this last sentence is pretty sad because normally,
issues like yours do not require windows-style operation. For your info,
I have not reinstalled my Debian system for the last 15 years.
Reinstalling is a solution but what if in ten days the same issue arises
again? You'll ask the same questions and won't have learned much…

One of the power of GNU/Linux is that you can learn and fix problems.

Happy New Year!

S

Re: Upgrade Problem

[David Wright]

On Fri 04 Jan 2019 at 04:30:00 (-0500), Felix Miata wrote:
> Andy Smith composed on 2019-01-04 08:57 (UTC):
>  > Several people have now suggested saving space in a bits of the
> > filesystem that Stephen has on dedicated partitions, so this is not
> > helpful.
> 
> > This partitioning scheme seems really odd and unwieldy.  
> 
> Indeed. Considering the absence of a sysadmin,

What's so unusual about that? For a long time I ran linux and work but
didn't consider myself an "operator" or "sysadmin". Employees in those
categories ran closed shops of MS and Apple kit, plus a splinter group
running what they considered "proper" unix on kit that I couldn't
start to afford. Most of mine was 2nd hand PC cast offs.

> absence of 2 possible primary partitions on sda,

If the OP partitioned an MBR disk intending to subdivide the
filesystem, then it might be expected that they create an extended
partition. Why bother with holding off until you've got two
primary partitions set up first?

> and the absence of sda6,

I assume that's swap.

> it makes me wonder what output from fdisk -l /dev/sda and fstab look
> like, and whether the upgrade included any partitioning changes that
> account for a lot of what's been left behind on /.

One could reboot into single user and find out whether there's a lot
of dross hidden under the mount points before /var and so on are
mounted (which I think might be what you're saying).

But while the system is currently running, a comparison of du -shx and
df for / might give a hint.

> IOW, what's behind the partitioning that exists, not just what it is
that's causing the huge consumption on /. Maybe time would be better
spent on a repartitioning and reinstallation than digging for causes.

Maybe, but the OP would become a better sysadmin by learning something
during the cleanup.

Cheers,
David.

Re: Upgrade Problem

[Stephen P. Molnar]

I want to thank those of you who responded to my request for assistance.

A number of the replies, particularly those that did not editorialize, 
where useful in that they convinced me that reinstalling the OS is the 
simplest remedy for the problems.


Let us put this thread to bed and stop wasting backspace.

--
Stephen P. Molnar, Ph.D.
Consultant
www.molecular-modeling.net
(614)312-7528 (c)
Skype: smolnar1

Re: Upgrade Problem

[Michael Stone]

On Thu, Jan 03, 2019 at 02:38:09PM -0500, Stephen P. Molnar wrote:

On 01/03/2019 01:27 PM, songbird wrote:

apt-get install libc --reinstall


root@AbNormal:/home/comp# apt-get install libc --reinstall
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package libc

so far as I know, I am not out of space.


You previously wrote:

root@AbNormal:/home/comp# df -hl
Filesystem  Size  Used Avail Use% Mounted on
/dev/sda123G   23G 0 100% /

Note that there is 0 available space...

Re: Fwd: Upgrade Problem

[tomas]

On Fri, Jan 04, 2019 at 08:44:27AM -0500, Gene Heskett wrote:
> On Friday 04 January 2019 08:15:11 Greg Wooledge wrote:
> 
> > On Thu, Jan 03, 2019 at 09:22:49PM -0500, Gene Heskett wrote:
> > > In this case, I hate to sound like
> > > an ass, but perhaps a re-install is in the future, doing the
> > > reinstall to a new drive [...]
> >
> > Come on, people.  Show some sense.  (And yes, this includes the OP.)
> >
> > He simply has a full root file system.  He has shown the df output at
> > least twice now.
> >
> > (A full root file system clearly and plainly shown by df despite the
> > OP claiming he is certain he's not out of space, no less.)
> 
> I don't have an argument against any of that Greg, but lets clarify one 
> thing here and now for the OP. Several responders keep using the "/root" 
> to describe what you clearly intend to be interpreted as the root of the 
> filesystem, AKA "/" when in 99.99% of the installs /root is the 
> sysadmin's home DIRECTORY, and not the root of the filesystem.

No, but /root is customarily in the root file system (mounted on /), and
it happens some times that there are things forgotten in there (e.g.
from manually installed packages, admin sessions squirreling away backups
of things, etc). Not a recommended pattern, but it happens.

I did interpret the proposals to look into /root in this vein.

Cheers
-- t


signature.asc
Description: Digital signature

Re: Fwd: Upgrade Problem

[Greg Wooledge]

On Fri, Jan 04, 2019 at 08:44:27AM -0500, Gene Heskett wrote:
> My own reinstall to a new, much larger disk, recommendation still stands, 
> that the OP would be back to a working system where he could remount 
> that old drive to his new install and recover the data he needs to 
> continue his project, much faster than he'll be able to fix this 
> install. IOW, the most expedient way to get the OP back up to speed on 
> whatever it is that he may be working on.

All he has to do is find whatever's taking up an unexpected amount of
space in his root file system, and get rid of it.  This is an essential
system management skill that he HAS to learn, which he will continue
to use well beyond the current crisis.

Reinstalling on a larger disk to "fix" this is like buying a new car
every time you run out of gasoline.

Re: Fwd: Upgrade Problem

[Gene Heskett]

On Friday 04 January 2019 08:15:11 Greg Wooledge wrote:

> On Thu, Jan 03, 2019 at 09:22:49PM -0500, Gene Heskett wrote:
> > In this case, I hate to sound like
> > an ass, but perhaps a re-install is in the future, doing the
> > reinstall to a new drive [...]
>
> Come on, people.  Show some sense.  (And yes, this includes the OP.)
>
> He simply has a full root file system.  He has shown the df output at
> least twice now.
>
> (A full root file system clearly and plainly shown by df despite the
> OP claiming he is certain he's not out of space, no less.)

I don't have an argument against any of that Greg, but lets clarify one 
thing here and now for the OP. Several responders keep using the "/root" 
to describe what you clearly intend to be interpreted as the root of the 
filesystem, AKA "/" when in 99.99% of the installs /root is the 
sysadmin's home DIRECTORY, and not the root of the filesystem.

So lets all quit using /root as the base of the filesystem, it is not, / 
is. /root is normally roots home directory, root being user #1 and there 
is quite a large diff.

My own reinstall to a new, much larger disk, recommendation still stands, 
that the OP would be back to a working system where he could remount 
that old drive to his new install and recover the data he needs to 
continue his project, much faster than he'll be able to fix this 
install. IOW, the most expedient way to get the OP back up to speed on 
whatever it is that he may be working on.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Overhead of LVM (Re: Upgrade Problem)

[Reco]

Hi.

On Fri, Jan 04, 2019 at 08:13:38AM -0500, rhkra...@gmail.com wrote:
> On Friday, January 04, 2019 03:49:37 AM Andy Smith wrote:
> > It's unfortunate that LVM was not used as it would make juggling
> > space between the multiple filesystems a lot easier. Oh well.
> 
> I guess I should consider using LVM on my next install.  Does it incur any 
> overhead during normal disk operations (I mean, like an extra level of 
> indirection or anything like that)?
> 
> Aside: just for laughs, my root (on Wheezy) is: 
> 
> rhk@s19:/rhk/askRhk$ df /
> Filesystem 1K-blocks   Used 
> Available Use% Mounted on
> /dev/disk/by-uuid/89   1921036 465852   1357600  26% /

# pvs
  PV VG Fmt  Attr PSize  PFree
  /dev/md10  naslvm2 a--  14.55t 10.43t

# hdparm -Tt /dev/md10
/dev/md10:
 Timing cached reads:   1224 MB in  2.00 seconds = 612.05 MB/sec
 Timing buffered disk reads: 1210 MB in  3.00 seconds = 403.28 MB/sec

# hdparm -Tt /dev/nas/root
/dev/nas/root:
 Timing cached reads:   1224 MB in  2.00 seconds = 611.55 MB/sec
 Timing buffered disk reads: 1154 MB in  3.00 seconds = 384.42 MB/sec

I see a difference, but I's something I can live with.

Reco

Re: Upgrade Problem

[Greg Wooledge]

On Fri, Jan 04, 2019 at 10:42:57AM +, Brian wrote:
> 2. Then go through
> 
>dpkg -l | less
> 
>line by line, asking "do I really need that?". I'd not bother with
>looking at the library packages. Tedious? Yes, like tidying the boot
>of a car.

There are some tools that will show you the packages sorted by size.
I wrote one in perl a couple decades ago:

https://wooledge.org/~greg/ds

There are other, fancier ones, but I still like mine.

Re: Fwd: Upgrade Problem

[Greg Wooledge]

On Thu, Jan 03, 2019 at 09:22:49PM -0500, Gene Heskett wrote:
> In this case, I hate to sound like 
> an ass, but perhaps a re-install is in the future, doing the reinstall 
> to a new drive [...]

Come on, people.  Show some sense.  (And yes, this includes the OP.)

He simply has a full root file system.  He has shown the df output at
least twice now.

(A full root file system clearly and plainly shown by df despite the OP
claiming he is certain he's not out of space, no less.)

Overhead of LVM (Re: Upgrade Problem)

[rhkramer]

On Friday, January 04, 2019 03:49:37 AM Andy Smith wrote:
> It's unfortunate that LVM was not used as it would make juggling
> space between the multiple filesystems a lot easier. Oh well.

I guess I should consider using LVM on my next install.  Does it incur any 
overhead during normal disk operations (I mean, like an extra level of 
indirection or anything like that)?

Aside: just for laughs, my root (on Wheezy) is: 

rhk@s19:/rhk/askRhk$ df /
Filesystem 1K-blocks   Used 
Available Use% Mounted on
/dev/disk/by-uuid/89   1921036 465852   1357600  26% /

Re: Fwd: Upgrade Problem

[Curt]

On 2019-01-03, Andy Smith  wrote:
> On Thu, Jan 03, 2019 at 10:27:30PM +0100, Nicolas George wrote:
>> > > Then ask your sysadmin.
>> 
>> > I have no sysadmin.
>> 
>> Then you are not "only a user", you are a sysadmin, and you are trying
>> to be one without acquiring the required knowledge.
>
> I Have No Sysadmin And I Must Sudo
>
>

With apologies to Harlan Ellison (let 'im RIP)?

Re: Fwd: Upgrade Problem

[Nicolas George]

Roberto C. Sánchez (12019-01-04):
> That said, like owning an automobile, with a computer sometimes things
> break or quit working as expected.  The machine then either has to be
> repaired or replaced and if the owner cannot handle the job on his or
> her own, then somebody else will need to handle it (and likely be paid
> for the service).

Exactly. And the kind of payment that is expected from you for help on
this mailing-list is not pecuniary, of course. It is that you do not
just consume the answers given to you but instead try to increase your
knowledge and understanding so that maybe one day you would be the one
helping.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature

Re: Fwd: Upgrade Problem

[Roberto C . Sánchez]

On Fri, Jan 04, 2019 at 11:16:57AM +0100, Nicolas George wrote:
> deloptes (2019-01-04):
> > Come on, the argument of Roberto C. Sánchez holds. Operator != Mechanic.
> 
> And I have not suggested that Roberto become a kernel hacker. I hope you
> noticed.
> 
I tried about 15 years ago.  It turns out I couldn't hack it :-)

I am older and wiser now, so I suppose I could, but my interests are now
elsewhere.

> >To
> > operate a PC means you know how to power on, login, start and use
> > application
> 
> What applications can they use if nobody installed them? You have a
> strange opinion of how a PC works.
> 
> There is no going around it: a PC is a very complex piece of technology.
> For everyday use, the complexity is well hidden, but not all day is
> everyday. There are unavoidably cases when somebody needs to deal with
> the complexity. In that case, there are only three options:
> 
> - pay somebody competent to do the job, or else entice them to do the
>   job for free;
> 
> - become competent;
> 
> - go live in a cave.
> 
The line between operator and administrator has been blurry since the
beginning of computing.  Just as people who own automobiles today need
to know far less in terms of mechanical diagnosis and repair than those
who owned automobiles 100 years ago, operating a Unix-like computer
today can be successfully accomplished with far less in the way
knowledge of system administration than was possible 20 or 30 years ago.

That said, like owning an automobile, with a computer sometimes things
break or quit working as expected.  The machine then either has to be
repaired or replaced and if the owner cannot handle the job on his or
her own, then somebody else will need to handle it (and likely be paid
for the service).

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Upgrade Problem

[Reco]

Hi.

On Fri, Jan 04, 2019 at 10:42:57AM +, Brian wrote:
> On Fri 04 Jan 2019 at 08:57:18 +, Andy Smith wrote:
> 
> > Hello,
> > 
> > On Fri, Jan 04, 2019 at 02:47:52AM +, Matthew Crews wrote:
> > > My guess? /home is on the same partition as /, which is a common setup
> > > for most end users. Running lsblk is one way to tell if this is the case.
> > 
> > >From one of Stephen's earlier emails:
> > 
> > root@AbNormal:/home/comp# df -hl
> > Filesystem  Size  Used Avail Use% Mounted on
> > udev3.9G 0  3.9G   0% /dev
> > tmpfs   789M   18M  772M   3% /run
> > /dev/sda123G   23G 0 100% /
> > tmpfs   3.9G   18M  3.9G   1% /dev/shm
> > tmpfs   5.0M  8.0K  5.0M   1% /run/lock
> > tmpfs   3.9G 0  3.9G   0% /sys/fs/cgroup
> > /dev/sda7   1.9G  6.5M  1.7G   1% /tmp
> > /dev/sda5   9.2G  6.0G  2.8G  69% /var
> > /dev/sda8   416G  103G  292G  27% /home
> > /dev/sdc120G  301M   19G   2% /sdc1
> > /dev/sdc2   439G  169G  270G  39% /sdc2
> > /dev/sdb1   1.8T  288G  1.5T  17% /sdb1
> > tmpfs   789M  4.0K  789M   1% /run/user/110
> > tmpfs   789M   28K  789M   1% /run/user/1000
> > 
> > i.e. /home is already on a separate partition.
> > 
> > Several people have now suggested saving space in a bits of the
> > filesystem that Stephen has on dedicated partitions, so this is not
> > helpful.
> > 
> > This partitioning scheme seems really odd and unwieldy. So much
> > wasted space on partitions that will never need anything like what
> > they have been assigned. This seems like a great example of how not
> > to partition a system - anyone thinking of using this many
> > partitions really should consider LVM in future.
> > 
> > Anyway, Stephen, you need to focus on finding useless things in / and
> > either removing them or moving them elsewhere. If it's just data
> > then it looks like somewhere under /home would be a good choice as
> > it has 292G available.
> > 
> > Ask before deleting anything you don't fully understand.
> 
> 1. First assess what the space on / is allocated to.
> 
>du -hs /lib/
>du -hs /etc/
>du -hs /usr/
>du -hs /usr/bin/
>du -hs /usr/local/ 

du -xh / | sort -h

Why bother typing several commands if you can type one?

Reco

Re: Upgrade Problem

[Brian]

On Fri 04 Jan 2019 at 08:57:18 +, Andy Smith wrote:

> Hello,
> 
> On Fri, Jan 04, 2019 at 02:47:52AM +, Matthew Crews wrote:
> > My guess? /home is on the same partition as /, which is a common setup
> > for most end users. Running lsblk is one way to tell if this is the case.
> 
> >From one of Stephen's earlier emails:
> 
> root@AbNormal:/home/comp# df -hl
> Filesystem  Size  Used Avail Use% Mounted on
> udev3.9G 0  3.9G   0% /dev
> tmpfs   789M   18M  772M   3% /run
> /dev/sda123G   23G 0 100% /
> tmpfs   3.9G   18M  3.9G   1% /dev/shm
> tmpfs   5.0M  8.0K  5.0M   1% /run/lock
> tmpfs   3.9G 0  3.9G   0% /sys/fs/cgroup
> /dev/sda7   1.9G  6.5M  1.7G   1% /tmp
> /dev/sda5   9.2G  6.0G  2.8G  69% /var
> /dev/sda8   416G  103G  292G  27% /home
> /dev/sdc120G  301M   19G   2% /sdc1
> /dev/sdc2   439G  169G  270G  39% /sdc2
> /dev/sdb1   1.8T  288G  1.5T  17% /sdb1
> tmpfs   789M  4.0K  789M   1% /run/user/110
> tmpfs   789M   28K  789M   1% /run/user/1000
> 
> i.e. /home is already on a separate partition.
> 
> Several people have now suggested saving space in a bits of the
> filesystem that Stephen has on dedicated partitions, so this is not
> helpful.
> 
> This partitioning scheme seems really odd and unwieldy. So much
> wasted space on partitions that will never need anything like what
> they have been assigned. This seems like a great example of how not
> to partition a system - anyone thinking of using this many
> partitions really should consider LVM in future.
> 
> Anyway, Stephen, you need to focus on finding useless things in / and
> either removing them or moving them elsewhere. If it's just data
> then it looks like somewhere under /home would be a good choice as
> it has 292G available.
> 
> Ask before deleting anything you don't fully understand.

1. First assess what the space on / is allocated to.

   du -hs /lib/
   du -hs /etc/
   du -hs /usr/
   du -hs /usr/bin/
   du -hs /usr/local/ 

   etc, etc.

2. Then go through

   dpkg -l | less

   line by line, asking "do I really need that?". I'd not bother with
   looking at the library packages. Tedious? Yes, like tidying the boot
   of a car.

3. Purge what is not wanted ("do I really need ten kernel packages?)
   with apt and occasionally use 'apt --purge autoremove', keeping an
   eye on 'df -hl'.

-- 
Brian.

Re: Upgrade Problem

[Nicolas George]

Felix Miata (2019-01-03):
> As others have noted, this is your root if not entire problem.

There is still the very worrying problem that ldconfig reported "ENOENT
2 No such file or directory" instead of "ENOSPC 28 No space left on
device". This is a bug, it should be reported.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature

Re: Fwd: Upgrade Problem

[Nicolas George]

deloptes (2019-01-04):
> Come on, the argument of Roberto C. Sánchez holds. Operator != Mechanic.

And I have not suggested that Roberto become a kernel hacker. I hope you
noticed.

>  To
> operate a PC means you know how to power on, login, start and use
> application

What applications can they use if nobody installed them? You have a
strange opinion of how a PC works.

There is no going around it: a PC is a very complex piece of technology.
For everyday use, the complexity is well hidden, but not all day is
everyday. There are unavoidably cases when somebody needs to deal with
the complexity. In that case, there are only three options:

- pay somebody competent to do the job, or else entice them to do the
  job for free;

- become competent;

- go live in a cave.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature

Re: Upgrade Problem

[Felix Miata]

Andy Smith composed on 2019-01-04 08:57 (UTC):
 > Several people have now suggested saving space in a bits of the
> filesystem that Stephen has on dedicated partitions, so this is not
> helpful.

> This partitioning scheme seems really odd and unwieldy.  

Indeed. Considering the absence of a sysadmin, absence of 2 possible primary 
partitions on sda, and
the absence of sda6, it makes me wonder what output from fdisk -l /dev/sda and 
fstab look like, and
whether the upgrade included any partitioning changes that account for a lot of 
what's been left
behind on /. IOW, what's behind the partitioning that exists, not just what it 
is that's causing the
huge consumption on /. Maybe time would be better spent on a repartitioning and 
reinstallation than
digging for causes.
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: Fwd: Upgrade Problem

[Frank Weißer]

Hi Stephen,

Stephen P. Molnar:



On 01/03/2019 02:42 PM, Greg Wooledge wrote:

On Thu, Jan 03, 2019 at 02:30:49PM -0500, Stephen P. Molnar wrote:

root@AbNormal:/home/comp# ls -ld / /etc /etc/ld.*
drwxr-xr-x  26 root root   4096 Dec 19 13:17 /
drwxr-xr-x 134 root root  12288 Jan  3 09:43 /etc
-rw-r--r--   1 root root 237114 Dec 26 14:47 /etc/ld.so.cache
-rw---   1 root root  12288 Jan  3 12:49 /etc/ld.so.cache~
-rw-r--r--   1 root root 34 Apr  9  2017 /etc/ld.so.conf
drwxr-xr-x   2 root root   4096 Aug 22 07:41 /etc/ld.so.conf.d

Well... /etc isn't missing, at least.

When I run "strace /sbin/ldconfig" on my system, I see this line:

rename("/etc/ld.so.cache~", "/etc/ld.so.cache") = 0

So, it seems that your ldconfig is generating the /etc/ld.so.cache~ file,
or at least a partial one (12288 is a suspiciously ROUND number, being
precisely 3 times 4 kilobytes).  And then ... something bad happens 
before

it can rename it to /etc/ld.so.cache.  Or finish writing it.

Are you out of disk space?  Granted, I would have expected a DIFFERENT
error message in that case, but it's a thing to check.

You might consider simply copying the /usr/bin/strace file from a
different Debian system onto this one, just so you can run it.

OK.  I happen to have Debian Stretch in a virtual machine for testing 
purposes.


strace is in /usr/bin on there.  I copied it to the host and ran it.

comp@AbNormal:~$ sudo ./strace
[sudo] password for comp:
./strace: must have PROG [ARGS] or -p PID
Try './strace -h' for more information.

I'm totally at sea here, which switch should iI use?

Also:

comp@AbNormal:~$ df -h
Filesystem  Size  Used Avail Use% Mounted on
udev    3.9G 0  3.9G   0% /dev
tmpfs   789M   18M  772M   3% /run
/dev/sda1    23G   23G 0 100% /   <- could this 
e a problem?

tmpfs   3.9G   12K  3.9G   1% /dev/shm
tmpfs   5.0M  8.0K  5.0M   1% /run/lock
tmpfs   3.9G 0  3.9G   0% /sys/fs/cgroup
/dev/sda7   1.9G  6.5M  1.7G   1% /tmp
/dev/sda5   9.2G  6.0G  2.8G  69% /var
/dev/sda8   416G  103G  292G  27% /home
/dev/sdc1    20G  301M   19G   2% /sdc1
/dev/sdc2   439G  169G  270G  39% /sdc2
/dev/sdb1   1.8T  288G  1.5T  17% /sdb1
tmpfs   789M  4.0K  789M   1% /run/user/110
tmpfs   789M   28K  789M   1% /run/user/1000

I have all of my application software in /home/comp/Apps



Your root partition is out of space,>> /dev/sda123G   23G 0 
100% /   <- could this
 so there won't be any writing to /etc , which is on this partition, 
until You get rid of some data, e.g. in /root.


Then try again, what You've been told in this thread.

kind regards

readU
Frank

Re: Upgrade Problem

[Andy Smith]

Hello,

On Fri, Jan 04, 2019 at 02:47:52AM +, Matthew Crews wrote:
> My guess? /home is on the same partition as /, which is a common setup
> for most end users. Running lsblk is one way to tell if this is the case.

>From one of Stephen's earlier emails:

root@AbNormal:/home/comp# df -hl
Filesystem  Size  Used Avail Use% Mounted on
udev3.9G 0  3.9G   0% /dev
tmpfs   789M   18M  772M   3% /run
/dev/sda123G   23G 0 100% /
tmpfs   3.9G   18M  3.9G   1% /dev/shm
tmpfs   5.0M  8.0K  5.0M   1% /run/lock
tmpfs   3.9G 0  3.9G   0% /sys/fs/cgroup
/dev/sda7   1.9G  6.5M  1.7G   1% /tmp
/dev/sda5   9.2G  6.0G  2.8G  69% /var
/dev/sda8   416G  103G  292G  27% /home
/dev/sdc120G  301M   19G   2% /sdc1
/dev/sdc2   439G  169G  270G  39% /sdc2
/dev/sdb1   1.8T  288G  1.5T  17% /sdb1
tmpfs   789M  4.0K  789M   1% /run/user/110
tmpfs   789M   28K  789M   1% /run/user/1000

i.e. /home is already on a separate partition.

Several people have now suggested saving space in a bits of the
filesystem that Stephen has on dedicated partitions, so this is not
helpful.

This partitioning scheme seems really odd and unwieldy. So much
wasted space on partitions that will never need anything like what
they have been assigned. This seems like a great example of how not
to partition a system - anyone thinking of using this many
partitions really should consider LVM in future.

Anyway, Stephen, you need to focus on finding useless things in / and
either removing them or moving them elsewhere. If it's just data
then it looks like somewhere under /home would be a good choice as
it has 292G available.

Ask before deleting anything you don't fully understand.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Upgrade Problem

[Andy Smith]

Hello,

On Thu, Jan 03, 2019 at 10:47:26PM -0500, Felix Miata wrote:
> Stephen P. Molnar composed on 2019-01-03 15:39 (UTC-0500):
> 
> > root@AbNormal:/home/comp# df -hl
> > Filesystem  Size  Used Avail Use% Mounted on
> ...
> > /dev/sda123G   23G 0 100% /
> 
> As others have noted, this is your root if not entire problem.

It seems so, and it should be fairly easy to fix. Stephen, please
resist the cries from others to "just reinstall". I think it would
be an unnecessary step and a sad outcome.

> Your / is more than 4.2 times the size of mine.

Certainly 23G in / seems excessive. There's bound to be something in
there that can be removed.

> Your /var/cache/apt/archives/ might contain more than 10 times the rest of /
> combined,

Unfortunately this is the wrong direction to go because Stephen
already has /var on a separate partition. Any savings made here will
not help for /.

It's unfortunate that LVM was not used as it would make juggling
space between the multiple filesystems a lot easier. Oh well.

Stephen, I think you're going to have to analyse where the space is
being used. If you use a graphical desktop then there might be a
graphical application that can help with this. On GNOME it's called
Disk Usage Analyzer. On the command line you could try something
like:

$ sudo du -xh / | sort -rh | less

Explanation:

"sudo" - do something as root

"du -xh /" - report disk usage of the / filesystem without going
into other filesystems ("x"). Report figures in human-readable units
("h").

"sort -rh" - pipe that through sort to get a sorted list, in reverse
order (biggest first, "r"), with the input being in human-readable
units ("h").

"less" - finally pipe it through the pager "less", so that it
doesn't all scroll off screen.

Hopefully the top few entries stand out to you as some large files
you put somewhere and can do without. Sadly unless things stand out
to you, it's going to be hard for us to recommend what you can
remove as we don't know what is on there that you need.

I find it unlikely that you have installed 23G of packages through
normal apt and as you are not a sysadmin I hesitate to suggest that
you start removing packages that you aren't 100% familiar with, in
case you break your system. But, you could do:

$ dpkg -l | less

to get a list of all packages installed through the package manager,
to see if there is anything that stands out to you.

My hunch though is that you will have a lot of downloaded files in
/root or some big apps from outside the package manager installed in
/opt.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Fwd: Upgrade Problem

[deloptes]

songbird wrote:

> often you can get quite a bit of space from the
> package cache.
> 

but his var is on dedicated partition

Re: Upgrade Problem

[Felix Miata]

Stephen P. Molnar composed on 2019-01-03 15:39 (UTC-0500):

> root@AbNormal:/home/comp# df -hl
> Filesystem  Size  Used Avail Use% Mounted on
...
> /dev/sda123G   23G 0 100% /

As others have noted, this is your root if not entire problem.

du -h on Stretch host fi965 here:
Filesystem  Size  Used Avail Use% Mounted on
/dev/sda25  5.4G  3.5G  1.7G  69% /
After apt autoclean
/dev/sda25  5.4G  2.7G  2.5G  52% /

Your / is more than 4.2 times the size of mine.

Your /var/cache/apt/archives/ might contain more than 10 times the rest of /
combined, most of which are probably packages used by Jessie, obsolete now
that you're on Stretch. Were it here I'd just navigate to 
/var/cache/apt/archives
in administrator mode and delete either all of it, or everything older than
the date you performed your dist-upgrade. Of course, apt can free cache space
too. ;)
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: Upgrade Problem

[Matthew Crews]

On 1/3/19 7:09 PM, Patrick Bartek wrote:

> I see from a later response that your / partition is 100% full.  That
> will defintely cause problems.  Whether it's THE problem, we won't know
> until you clean out / to less than 100%, say at least 90%. Less would
> be better.
> 
> I don't know why your / is 100% full.  I'm running Stretch and my
> 20GB / is only at 31%, and /var. /tmp, /usr are not separate
> partitons. Even on my Wheezy install which I ran for 5 years, /
> never was higher than 50% full and it was only a 16GB partition.
> 
> B
> 

My guess? /home is on the same partition as /, which is a common setup
for most end users. Running lsblk is one way to tell if this is the case.

I will echo what others have said. Free up some disk space, then try again.

-Matt