Re: catastrophe - but how? Aptitude goes mad
On Thu 30 Jun 2016 at 22:41:57 (-0400), Gene Heskett wrote:
> On Thursday 30 June 2016 20:51:37 David Wright wrote:
> > On Thu 30 Jun 2016 at 19:35:44 (-0400), Gene Heskett wrote:
> > > On Thursday 30 June 2016 19:25:37 Lisi Reisz wrote:
> > > > On Thursday 30 June 2016 21:12:46 Henrique de Moraes Holschuh wrote:
> > > > > On Thu, 30 Jun 2016, Gene Heskett wrote:
> > > > > > Thats not excusable behavior, but whats worse is that debian's
> > > > > > people are denying there is a problem. 'scuse me? I swear,
> > > > > > they couldn't smell coffee with a nose full of it.
> > > > >
> > > > > Well, if either of you two (that suffered the runaway aptitude
> > > > > issue) still have the /etc of the box that caused trouble,
> > > > > kindly do this:
> > > > >
> > > > > grep -r Assume-Yes /etc
> > > > >
> > > > > If it returns any match in the aptitude config files, there you
> > > > > have it.
> > > >
> > > > I have this on my desktop at home:
> > > >
> > > > root@Tux-II:/home/lisi# grep -R Assume-Yes /etc
> > > > grep: /etc/fonts/conf.d/70-no-bitmaps.conf: No such file or
> > > > directory Binary file /etc/alternatives/aptitude matches
> > > > root@Tux-II:/home/lisi
> > > >
> > > > It rather looks as though I should be worried?
> > >
> > > No, thats just grep being grep, it says that of ANY binary file it
> > > tries to read as text. I have spent days pouring over the manpages
> > > for grep, looking for a option to feed it to make grep quit that,
> > > simply because its so verbose that what you are looking for can get
> > > lost in its blathering about that.
> >
> > I have no idea what that's meant to be the explanation for.
>
> For the fact that it claimed /etc/alternatives/aptitude was a match when
> Lisi ran the correct grep as quoted in a previous email.
It claimed it matched because it *did* match. grep prints matches;
it's what's on the tin.
There's nothing verbose about it: quite the opposite in fact.
With a text file, it would have printed *all* the matching
lines. Here, in a binary file, any number of matches is confirmed
("claimed" in your parlance) by merely one line.
> > Why does Binary file /etc/alternatives/aptitude trigger a match?
>
> Because it is?
>
> gene@coyote:/opt$ file /etc/alternatives/aptitude
> /etc/alternatives/aptitude: symbolic link to /usr/bin/aptitude-curses
> gene@coyote:/opt$ file /usr/bin/aptitude-curses
> /usr/bin/aptitude-curses: ELF 32-bit LSB shared object, Intel 80386,
> version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2,
> for GNU/Linux 2.6.26,
> BuildID[sha1]=3508f8a2610e542bc916835e4caea373c28eb8f0, stripped
That explains why it says "Binary file", not why it matched.
I explained both why it's a binary and why it matched.
> > What you were running was aptitude, obviously. On my laptop:
>
> Which "you" are you refering to, because Lisi and I have shared that same
> leaky boat experience with aptitude.
Both of you, at different times. Why does that matter?
> > $ which aptitude
> > /usr/bin/aptitude
> > $ ls -l /usr/bin/aptitude
> > lrwxrwxrwx 1 root root 26 Oct 10 2012 /usr/bin/aptitude ->
> > /etc/alternatives/aptitude $ ls -l /etc/alternatives/aptitude
> > lrwxrwxrwx 1 root root 24 Oct 10 2012 /etc/alternatives/aptitude ->
> > /usr/bin/aptitude-curses $ ls -l /usr/bin/aptitude-curses
> > -rwxr-xr-x 1 root root 4340528 Nov 8 2014 /usr/bin/aptitude-curses
> >
> > (The last line might be different if you use some version other than
> > curses.)
> >
> > So the question becomes Why does the binary file
> > /usr/bin/aptitude-curses, that you actually run, match?
>
> Who knows, but grep, for this job, lies like a cheap rug.
No it doesn't. It's a binary. It matches. Both those statements
made by grep are true. Or is your dispute with the fact that
/etc/alternatives/aptitude is in fact a link? So what: we're
dealing with the output of grep -R, and R forces grep to follow
links regardless.
> file will tell
> you more. And it gives a valid answer that aptitude-curses is in fact a
> binary file. And thats what worried Lisi, needlessly.
Why would Lisi worry about a binary file in /etc/alternatives? That's
what it's stuffed full of, if you're following links. 89 ELFs/251 on
my laptop. Only 33/251 are plain text files.
What "grep -R Assume-Yes /etc" was meant to be doing was searching for
some nook or cranny where aptitude was being told to assume "yes" in
answer to questions it might pose. *Any* match *might* lead one to
suppose that the search had been successful, which *would* be worrying.
However, the explanation for the match shows that the search was
not successful: it was just a false alarm caused by... (explanation
follows as it did originally)...
> > Well, in order to decide whether you have typed
> > aptitude --assume-yes
> > aptitude needs to contain the string "assume-yes" against which to
> > check your typing. Ditto Aptitude::CmdLine::Assume-Yes for checking
> > against the configuration file.
> >
> > So a match here is no surprise and no worry.
In other words, aptitude contains tables of strings with every
conceivable option in them, whether or not anyone actually uses them.
So the search turned up nothing of significance.
> > However, you should also check for anything in /root/.aptitude/config
> > as that could override the /etc/ stuff. (Probably nothing.)
> > So your problem might boil down to why aptitude thought all those
> > packages should go, ie what happened to the package(s) at the top
> > of the dependency chain(s) whose job was to keep them all installed.
> >
> > Sorry I don't have much experience of aptitude other than the
> > visual interface (ie no action given on the command line).
> > I'm really an apt-get user. In order to remove "unused" packages,
> > I have to type apt-get autoremove which I sometimes do in response
> > to its telling me there are such packages lying around. It's not
> > easy for me to tell from the documentation whether "Installed packages
> > will not be removed unless they are unused (see the section “Managing
> > Automatically Installed Packages” in the aptitude reference manual)¹"
> > means that they'll be removed automatically without any further
> > confirmation.
> >
> > ¹safe-upgrade in man aptitude.
Cheers,
David.
Reply to: