[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Buster to Bullseye upgrade problem



On Sun 22 Aug 2021 at 13:18:38 (+0100), Gareth Evans wrote:
> On Sun 22 Aug 2021, at 05:36, David Wright <deblis@lionunicorn.co.uk> 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 <snip> 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.


Reply to: