DevHeads.net

What did I just ruin?

I may have outsmarted myself.

I was about to upgrade packages and I wanted to capture the plethora of
messages I expected
this to produce, so I did it under script(1). It captured all right, but
I'm a bit worried by a thing it
captured a few times...

For instance, at the end of fetching packages.... it's got a problem with
Dialog (whatever that is)
and it's not clear that its workaround worked.

-- Get:75 <a href="http://us.archive.ubuntu.com/ubuntu" title="http://us.archive.ubuntu.com/ubuntu">http://us.archive.ubuntu.com/ubuntu</a> xenial-updates/main amd64
ntp-doc all 1:4.2.8p4+dfsg-3ubuntu5.9 [1,169 kB]
Get:76 <a href="http://us.archive.ubuntu.com/ubuntu" title="http://us.archive.ubuntu.com/ubuntu">http://us.archive.ubuntu.com/ubuntu</a> xenial-updates/main amd64 rfkill
amd64 0.5-1ubuntu3.1 [8,530 B]
Fetched 281 MB in 37s (7,395 kB/s)
debconf: unable to initialize frontend: Dialog
debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell
buffer, or without a controlling terminal.)
debconf: falling back to frontend: Readline
Extracting templates from packages: 100%
Preconfiguring packages ...
(Reading database ... 258286 files and directories currently installed.)
Preparing to unpack .../libquadmath0_5.4.0-6ubuntu1~16.04.10_amd64.deb ...
Can anyone clarify?

++
Kevin O'Gorman
#define QUESTION ((bb) || (!bb)) /* Shakespeare */

Please consider the environment before printing this email.

Comments

Re: What did I just ruin?

By Colin Watson at 07/10/2018 - 10:31

On Mon, Jul 09, 2018 at 08:37:43PM -0700, Kevin O'Gorman wrote:
Everything is fine. This message is informational, and for your
purposes you can ignore it.

(The full-screen Dialog frontend that might in some cases be used to ask
questions during installation would be pretty ugly in script(1) output,
so you're probably better off with the Readline frontend in this case
anyway.)

Re: What did I just ruin?

By Kevin O'Gorman at 07/10/2018 - 12:36

Hmm. I didn't mention that the whole thing was wrapped in a combination of
functions and scripts and it never seemed to actually try to interact with
me at all. I had intentionally set TERM=dumb so that any interaction could
be captured by script(1).

This is all because I'm a hobbyist with 6 (or so) computers running various
Ubuntu flavors, and I'm really sick of waiting around for updates, and then
wondering what happened with one of them because I can't remember what I
did on which one. I want a record, because sometimes things go wrong and
I'd like to be able to post a query like I did to start this thread, in
which I quote the output of the update process. I want defaults wherever
possible, because I can't think of a package where I use anything else.

Call me a grumpy old codger if you like. There are times that's exactly
what I feel like.

Anyway in accordance with the above, I have scripts like get-update.sh
which calls functions (from .bash_aliases) to set up script and redirect
output to got-update-<timestamp>.script. This gives me a record of what
happened. I have quite a collection of such scripts which remind me what
to install when it's time to go to the next LTS. because I always to a
fresh install to a new partition. I create new home directories in that
partition so that config files match the OS that I boot. All data files
are in a mountable partition and some of its directories get mounted onto
the home partition. That way the data is available to any OS version, but
the dotfiles are specific.

Then along comes the occasional package that wants to interact with me a
half-hour after I started the installation and I'm off having supper. Or
asleep. I then grumble about arrogant software.

Feel free to point out the error of my ways. Or ask for copies of my
scripts. Whichever.

Re: What did I just ruin?

By Colin Watson at 07/10/2018 - 14:55

On Tue, Jul 10, 2018 at 09:36:35AM -0700, Kevin O'Gorman wrote:
Sure. The fact that a debconf frontend starts up doesn't necessarily
mean that it actually does any interaction with the user; the frontend
also handles shunting data back and forward between package maintainer
scripts and the debconf database.

Re: What did I just ruin?

By Liam Proven at 07/10/2018 - 12:44

On Tue, 10 Jul 2018 at 18:38, Kevin O'Gorman < ... at gmail dot com> wrote:
<a href="https://help.ubuntu.com/lts/serverguide/automatic-updates.html.en" title="https://help.ubuntu.com/lts/serverguide/automatic-updates.html.en">https://help.ubuntu.com/lts/serverguide/automatic-updates.html.en</a>

Re: What did I just ruin?

By Kevin O'Gorman at 07/09/2018 - 23:38

Perrhaps I should add that apt-get had the --quiet and --assume-yes options

Re: What did I just ruin?

By silver.bullet at 07/10/2018 - 02:39

You did not mention how you invoked script and the apt-get command. The
script manpage explicitly mentions that it requires an interactive
shell, see
<a href="http://manpages.ubuntu.com/manpages/xenial/man1/script.1.html" title="http://manpages.ubuntu.com/manpages/xenial/man1/script.1.html">http://manpages.ubuntu.com/manpages/xenial/man1/script.1.html</a> .

My guess is, that since debconf was "falling back to frontend:
Readline", the dialog required to answer with "yes" or "no" and nothing
else, so the "assume-yes" option did exactly this, it always assumed
"yes", otherwise apt-get would have aborted, see
<a href="http://manpages.ubuntu.com/manpages/xenial/man8/apt-get.8.html" title="http://manpages.ubuntu.com/manpages/xenial/man8/apt-get.8.html">http://manpages.ubuntu.com/manpages/xenial/man8/apt-get.8.html</a> .

However, I wonder what "yes" is for e.g. a config related "default
action", see
<a href="http://manpages.ubuntu.com/manpages/cosmic/man1/dpkg.1.html" title="http://manpages.ubuntu.com/manpages/cosmic/man1/dpkg.1.html">http://manpages.ubuntu.com/manpages/cosmic/man1/dpkg.1.html</a> , if neither
the dpkg option "force-confnew" or "force-confold" is used. Is the
default action to always install the new or to always keep the old
configuration file, or could the default action be different for each
package, or is this the type of question apt-get would abort?

I'm curious about the replies from those subscribers, who usually
provide examples with the "assume-yes" option, when replying to other
subscriber's requests.

Re: What did I just ruin?

By Colin Watson at 07/10/2018 - 10:29

On Tue, Jul 10, 2018 at 08:39:13AM +0200, Ralf Mardorf wrote:
I'm afraid that your guess is entirely wrong. apt-get --assume-yes
doesn't influence debconf in any way.

debconf's readline frontend is still perfectly capable of asking
questions, so no harm will have come of this. The message about
downgrading to a different frontend is essentially informational (but
useful if you were specifically expecting a different frontend).

Even in noninteractive mode (which wasn't what happened here, but is a
further possible fallback), packages are strongly encouraged to have
reasonable default behaviour if they can't ask a question. In the
corner case where they can't ask a question and there's no reasonable
default, they will normally fail in an obvious way, i.e. causing the
package to fail to configure. It's not possible to make universal
statements about this since it's up to procedural code in individual
packages' maintainer scripts, but this is the norm.

The default action depends on the state of the conffiles being
processed. For example, if the existing file is unmodified from that in
the previously-installed version of the package then the default action
is to install the new version of the file, whereas if it's been modified
locally then the default action is to keep the old version.

In any case, this is irrelevant here, since that didn't happen here and
merely using script(1) wouldn't have caused dpkg to be unable to ask
conffile questions.

Furthermore, apt-get --assume-yes also doesn't affect dpkg conffile
prompts; it *only* affects the relatively small number of questions
asked by apt itself.

I am not such a person, but for all the reasons above this line of
enquiry is a red herring with regard to the OP's situation.

Re: What did I just ruin?

By silver.bullet at 07/10/2018 - 15:05

On Tue, 10 Jul 2018 15:29:08 +0100, Colin Watson wrote:
You are quoting out of context.

He? This is exactly my guess! So if you should be right, my guess
should be right, too ;).

The culprit isn't "DEBIAN_FRONTEND", but it is "TERM", OTOH in this
case they are related to each other.

On Tue, 10 Jul 2018 09:36:35 -0700, Kevin O'Gorman wrote:
On Mon, 9 Jul 2018 20:37:43 -0700, Kevin O'Gorman wrote:
;)

Re: What did I just ruin?

By Colin Watson at 07/11/2018 - 05:42

On Tue, Jul 10, 2018 at 09:05:20PM +0200, Ralf Mardorf wrote:
Not intentionally. What context did you feel I was missing?

The structure of the sentence above seemed (and still seems after I've
reread it a couple of times) to indicate some kind of link between
debconf falling back to the readline frontend and apt-get's --assume-yes
option. No such link exists.

If this was your guess, then I'm afraid that that was completely opaque
to me from your previous message ...

Re: What did I just ruin?

By silver.bullet at 07/11/2018 - 07:53

On Wed, 11 Jul 2018 10:42:54 +0100, Colin Watson wrote:
Simply put, I wanted to point out, that I guess that apt-get worked as
wanted, but that the debconf much likely required the fallback,
regarding an issue cause by the way script was invoked. Since we didn't
know that the OP set TERM=dumb, we only could guess. Actually debconf
informed that the "Dialog frontend will not work on a dumb terminal, an
emacs shell buffer, or without a controlling terminal".

Re: What did I just ruin?

By silver.bullet at 07/10/2018 - 02:53

On Tue, 2018-07-10 at 08:39 +0200, Ralf Mardorf wrote:
Should a real-time user group be added? Yes/No or shouldn't a real-time
user group be added Yes/No? Similar questions most likely only appear
when installing a new package, but actually an upgrade could install a
new package.