Re: Buster to Bullseye upgrade problem
On Sun 22 Aug 2021, at 15:37, David Wright <deblis@lionunicorn.co.uk> wrote:
> 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.
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.
>
>
Reply to: