Re: [gentoo-user] Inconsistent behavior in my Gentoo OS instance

[Miroslav Rovis]

I've received one reply, and thanks again, but I had better remove the
gzip-"inconsistency" related bloat from my own previous email... I need the
previous text to make the remaining three important
parts/issues/inconsistencies clearer and easier to check, and reply to,
any of the three.

I will also reorder my quotes to get them easier to skip or skip to,
since they are separate issues/inconsistencies.

On 170501-18:17+0200, Miroslav Rovis wrote:
...
First issue
===========
(All first issue-related text have been removed here from all quotes
from my previous message)
...

Second issue
============
> Another part is actually on Wireshark mailing list. Pls. see:
>
> Filtering on (negated) frame.time_relative filters out wrong frame.number
> https://www.wireshark.org/lists/wireshark-users/201704/msg00037.html
> as well as my study at:
> https://www.croatiafidelis.hr/foss/cap/cap-170313-git-devuan-mail/git-devuan-mail-4.php
That page has just been updated with clearer instructions.

> (and the previous ones there, but I gave the last as it is simplest/fastest to check)
>
> There is information that any advanced reader can easily provide by retracing
> some of my steps there, and which would clear some uncertainties here.
...
> ... That's a serious bug or a
> serious malfunction in my Gentoo, the latter being most likely...
>
> And if it is the latter, it can only be one or the other way. One: the cause
> is in some Gentoo packge. Two: it is an attack by some unknown means.
>
> (
> If Air-Gapped is some info, I did try and editcap (and the whole
> Wireshark) behave in the same wrong way in my Air-Gapped too.
> ...
> )
>


Third issue
==========

The text it too much because the command line in which bash throw
strange error is a long for loop. The main point is marked with short new
text below.
> This is one of a series of commands that I used to check one of the backups,
> in three different instances of tar-gzip'd archive I checked (such as the
> /root directory tar-gzip'd today), and which showed faultless upon
> decompression in all the three instances, despite the three instances of
> tar-gzip'd archives not being identical (as their SHA256 sums show):
>
> # for i in $(ls -1d root_170430_g0n*.d/); do sum=$(echo $i|sed 's/\.d\//\.sum/'); echo $sum ; read FAKE ; j=$(echo $i | sed 's/\.d\//\.tar.gz/'); ls -l $j $i ; cd $i; pwd ; read FAKE ; for file in $(find ./ -name '*'); do if [ -f "$file" ]; then sha256sum $file >> ../$sum ; fi; done ; cd - ; done ;
>
> Now if I just place the cursor, by moving with Alt-F (skipping "words") and Ctrl-F (skipping  1 char) to just after:
>
> "for i in $(ls -1d root_170430_g0n*.d/" in that command,
>
> and if I then hit Tab for completion on the experssion there, I get (and I'm
> sorry for the mess, but that's what I get):
>
> g0n ~ # for i in $(ls -1d root_170430_g0n*.dbash: unexpected EOF while looking for matching `)'bash: syntax error: unexpected end of file//\.tar.gz/'); ls -l $j $i ; cd $i; pwd ; read FAKE ; for file in $(find ./ -name '*'); do if [ -f "$file" ]; then sha256sum $file >> ../$sum ; fi; done ; cd - ; done ;
>
> NOTE (at proofreading time): rechecked, I do get that same behavior the day
> after (wrote most of this yesterday, still to send this morning).
>
> [[
> NOTE (before delayed sending): In fact, it is only this clone that exibits the
> above Bash malfunctioning. I just checked the same for loop command (some six
> paragraphs above) in my Air-Gapped master [1] (never any internet it sees,
The [1] is important for understanding, especially this Bash issue in my
Gentoo instance.
Because in my Air-Gapped Gentoo instance that issue does not show at
all.
> longer workaround/detailed checking before updating it with stuff from
> internet, sneakernet or optical media), and it is just fine. That line, simply
> gave what it should:
>
> # for i in $(ls -1d root_170430_g0n*.d/); do sum=$(echo $i|sed 's/\.d\//\.sum/'); echo $sum ; read FAKE ; j=$(echo $i | sed 's/\.d\//\.tar.gz/'); ls -l $j $i ; cd $i; pwd ; read FAKE ; for file in $(find ./ -name '*'); do if [ -f "$file" ]; then sha256sum $file >> ../$sum ; fi; done ; cd - ; done
> root_170430_g0n_1.d// root_170430_g0n_2.d// root_170430_g0n.d//
> # [[and the same command line was back here]]
>
> under exact same conditions/circumstances as the clone of my Air-Gapped. And
> it's similar with some other completion issues: they seem non-existent in my
> Air-Gapped.
> ]]

This is the main point (in my clone that I use for online):
> IOW, first, Bash sullied the entire line, which is not very considerate of
> Her, and second that's not some usual error. Just for clarity, it wrote this:
>
The error:
> bash: unexpected EOF while looking for matching `)'bash: syntax error: unexpected end of file
>
> (and it wrote it by overwriting, which I never used to see in Bash)
  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  
  |  |  |  |  |  |  |  |  |  |  |  | 
Anyone else such behavior as well?

>
> What's going on there?... Ah... Importantly:
>
> do any of you other users get some erratic unusual behavior like this with Bash?
>
> Of course, I can move to the start of the line with Ctrl-A and then issue
> Ctrl-K to clear and capture to the entire line and then issue Ctrl-Y to paste
> it back, and no disorderly message remains, but Bash isn't behaving...
>
...
> ... if the reader has this bash version installed:
> $ bash --version
> GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu)
> Copyright (C) 2016 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>
> This is free software; you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> $
> they might be able to reproduce such kind of misbehavior.
Else it's only in my Gentoo instance (and only the for-online clone, not
in my Air-Gapped Gentoo instance).

Fourth issue
============
> And finally, and this is what eix throws on any package that I would check:
>
> g0n ~ # eix memtest86+
> * sys-apps/memtest86
>      Available versions:  4.3.7 (~)4.3.7-r1 {serial}
>      Homepage:            http://www.memtest86.com/
>      Description:         A stand alone memory test for x86 computers
...
>
> Found 2 matches
> Received SIGSEGV - you probably found a bug in eix.
> Please proceed with the following few instructions and help us find the bug:
>  * install gdb (sys-devel/gdb)
>  * reemerge eix with FEATURES="nostrip" CXXFLAGS="-g -ggdb3" LDFLAGS=""
>  * enter gdb with "gdb --args eix your_arguments_for_eix"
>  * type "run" and wait for the segfault to happen
>  * type "bt" to get a backtrace (this helps us a lot)
>  * post a bugreport and be sure to include the output from gdb.
  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  
  |  |  |  |  |  |  |  |  |  |  |  | 
Anyone else gets this too?

...
> ---
> [1] My methods are still these:
> Air-Gapped Gentoo Install, Tentative
> https://forums.gentoo.org/viewtopic-t-987268.html
>
> and
>
> Postfix smtp/TLS, Bkp/Cloning Mthd, Censorship/Intrusion
> https://forums.gentoo.org/viewtopic-t-999436.html#7613044
>

-- 
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr