Hi!
I have tried hard to make this message to the point. But that wasn't easy, as
what I figured out about gzip --only after hours of work-- I still do need
confirmation about, even though all appears correct.
gzip apparently inconsistent behavior occupies the most part of the report on
inconsistencies here (esp. the script make_gzip_archives_consistent.sh).
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
(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.
The third part is about Bash apparent misbehavior.
And the fourth part is about eix complaining it has a bug, it's near the bottom part
of this email.
That is my starting point, and at this stage, after having spent quite a few
hours on this issue below (but I have other issues not-directly-related to my system
that haven't allowed me to finish and send this yet)...
This issue below I thought at first could be related to my Wireshark woes, and
now I don't... and at this stage (the proofreading time) I'm actually asking for
any confirmation/denial on my findings about it...
miro@g0n ~ $ ls -lh wireshark-users_miroR_q_bug_q.txt
-rw-r--r-- 1 miro miro 802 2017-04-30 17:16 wireshark-users_miroR_q_bug_q.txt
miro@g0n ~ $ ls -l --block-size=K wireshark-users_miroR_q_bug_q.txt
-rw-r--r-- 1 miro miro 1K 2017-04-30 17:16 wireshark-users_miroR_q_bug_q.txt
miro@g0n ~ $ mv -vi wireshark-users_miroR_q_bug_q.txt gzip_buggy.txt
'wireshark-users_miroR_q_bug_q.txt' -> 'gzip_buggy.txt'
miro@g0n ~ $ tar czf gzip_buggy.txt.tar.gz gzip_buggy.txt
miro@g0n ~ $ tar czf gzip_buggy.txt_1.tar.gz gzip_buggy.txt
miro@g0n ~ $ tar czf gzip_buggy.txt_2.tar.gz gzip_buggy.txt
miro@g0n ~ $ sha256sum gzip_buggy.txt*.tar.gz
26bcad15b4a81a3606859fdd4560af0e2c4cd875f1271808afb4569c50bfb5ec gzip_buggy.txt_1.tar.gz
bd8f51bcd3274bbee4f73fa7ba9e1a2acd5db5d27f5643f72de10c52e224c22a gzip_buggy.txt_2.tar.gz
251a57e83ebaf4f07179f4a6500be80612a39ac6d2e97e482b30fb0a4de66f56 gzip_buggy.txt.tar.gz
miro@g0n ~ $
You may check attachments:
gzip_buggy.txt_1.tar.gz
gzip_buggy.txt_2.tar.gz
gzip_buggy.txt.tar.gz
I think this is not like it should be. But the important question, really, is:
is this the case in my machine only, or is it Gentoo-userdom wide?
I fear it's the former, but like I asked in that Wireshark thread
(
And it was amazing to see how little people care... there are always plenty of
readers of Wireshark ML, and while not all can understand that thread --it
took me years since I first used Wireshark to get to be able to minimally
contribute there... lots of readers there such--, and of course those that can
not really understand, need not reply... but lots of readers of Wireshark ML
can easily repeat my steps that show in which exact fashion my Wireshark
misbehaves...
I'll be thankful is some Gentoo reader fills in this huge gap of
carelessness..
)
[but like I asked in that Wireshark thread,] I ask here on Gentoo users ML (or
readers from elsewhere).
Pls. somebody confirm if this is, or is not, the case in their Gentoo
machines. By simply decompressing the tar-gzip'd archive are do the tar-gzip
compression as I did, and checking the sums of them.
If you don't like my text file, you can use any file (like the ASCII file
below, which I hope should be simple and fine enough), and reproduce what I
tried with it.
So let's try /usr/bin/eix-installed-after
It's ASCII, it's Gentoo, everybody has it on this ML, but for visitors, it's in
You may check attachments:
eix-installed-after_1.tar.gz
eix-installed-after_2.tar.gz
eix-installed-after.tar.gz
In my Gentoo, I copied it in my homedir and...
miro@g0n ~ $ tar czf eix-installed-after.tar.gz eix-installed-after
miro@g0n ~ $ tar czf eix-installed-after_1.tar.gz eix-installed-after
miro@g0n ~ $ tar czf eix-installed-after_2.tar.gz eix-installed-after
miro@g0n ~ $ sha256sum eix-installed-after*.tar.gz
80d004b1ecc6e6c2aec7cd453d05c7b4e4cc4092b9cef6b7c3fb31d148eb2310 eix-installed-after_1.tar.gz
f4c30c6d4ccc90d1ec2cc6df2ac10cae2545d04a85c7ff39207d93129cd0ec78 eix-installed-after_2.tar.gz
a8161c5771b661476966250af31d2b8bd80581a3e0c52d535b401524ee541ae7 eix-installed-after.tar.gz
miro@g0n ~ $
And let me go further. Inspecting those...:
miro@g0n ~ $ ls -l eix-installed-after*.tar.gz
-rw-r--r-- 1 miro miro 3771 2017-04-30 17:39 eix-installed-after_1.tar.gz
-rw-r--r-- 1 miro miro 3771 2017-04-30 17:39 eix-installed-after_2.tar.gz
-rw-r--r-- 1 miro miro 3771 2017-04-30 17:39 eix-installed-after.tar.gz
miro@g0n ~ $ ls -l --block-size=K eix-installed-after*.tar.gz
-rw-r--r-- 1 miro miro 4K 2017-04-30 17:39 eix-installed-after_1.tar.gz
-rw-r--r-- 1 miro miro 4K 2017-04-30 17:39 eix-installed-after_2.tar.gz
-rw-r--r-- 1 miro miro 4K 2017-04-30 17:39 eix-installed-after.tar.gz
miro@g0n ~ $
...those tiny files, I find that...:
miro@g0n ~ $ hexdump -C eix-installed-after.tar.gz | head -c38
00000000 1f 8b 08 00 25 05 06 59 00 miro@g0n ~ $ hexdump -C eix-installed-after_1.tar.gz | head -c38
00000000 1f 8b 08 00 27 05 06 59 00 miro@g0n ~ $ hexdump -C eix-installed-after_2.tar.gz | head -c38
00000000 1f 8b 08 00 29 05 06 59 00 miro@g0n ~ $
miro@g0n ~ $
...it's always the... ah well, for clarity, let's head just the first 25 bytes
of the hex representation, whihc will later be 5 bytes for dd commands...:
miro@g0n ~ $ hexdump -C eix-installed-after.tar.gz | head -c25
00000000 1f 8b 08 00 25 miro@g0n ~ $ hexdump -C eix-installed-after_1.tar.gz | head -c25
00000000 1f 8b 08 00 27 miro@g0n ~ $ hexdump -C eix-installed-after_2.tar.gz | head -c25
00000000 1f 8b 08 00 29 miro@g0n ~ $
...that it's always (or almost always, see below about PART3 sometimes being
different) just the 5th byte that is different, in the way that doing the
procedure below will get those files which differed at creation time...:
80d004b1ecc6e6c2aec7cd453d05c7b4e4cc4092b9cef6b7c3fb31d148eb2310 eix-installed-after_1.tar.gz
f4c30c6d4ccc90d1ec2cc6df2ac10cae2545d04a85c7ff39207d93129cd0ec78 eix-installed-after_2.tar.gz
a8161c5771b661476966250af31d2b8bd80581a3e0c52d535b401524ee541ae7 eix-installed-after.tar.gz
(
Notice: the hash is always new. You won't get any of those hashes above
if you tar-gzip it. This is about the non-identical results.
)
...to become identical. This procedure, that I'll put in the script:
Pls see attachment:
make_gzip_archives_consistent.sh
The fact is, I have, hours ago (this is slow work for me...) made a backup
(and spent all this time, and more to write that script), and noticed how my
gzip behaves, or should I say the gzip program *in my machine*... And...
And I can tell that I get different instances of archives consistently fixed
with that script.
I only can't get identical archives when PART3 is different in some (usually
only one of the three) of the archives.
NOTE (at proofreading time): But I'm not investigating that anymore, find how
I confirmed that the archives upon decompression are all of verifiably same
content, and that suffices.
I really have tried only on my backup, on multiple series of three different
tar-gzip'ed instances each of which in the series was done on the same
directory with the script above.
The script is just a proof of concept, and a demonstration of the apparent
issue. Because this previously does not seem to me to have been the case, but
maybe I misremember?
I checked a few of the tar-gzip'd archives of my backup, and so far they have
always, upon decompression, shown identical in all the different instances.
The finding
===========
I've typically compared series of three instances of same directories that I
backed up, such as /home/miro, /root and /var/log, and they always were
identical upon decompression.
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
That means *probably* all is fine with gzip, and there is no issue.
(But this result was not trivial to get by... and since I'm unsure in my
conclusion, I'm still posting this, asking for confirmation or denial.)
So maybe I've been chasing shadows here... And for long hours...
And I'm sorry if that is so, but look at that issue that I have with
Wireshark! Look at that! That's not a shadow. 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.
Same holds for the gzip inconsistency --or "inconsistency".
)
And looking for solution to that Wireshark issue, I found the above issue
which appeared to me to be some kind of inconsistency...
And I have other inconsistencies, bogus or true that they might be, such as
with bash.
One is very quick to report. Here it goes...
Thanks for any report on how this issue, and the one with Wireshark, shows,
completely in order or just like in my machine, in any other Gentoo users'
systems.
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,
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.
]]
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:
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)
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...
I'll try and send this soon, but I first need to finish my backup...
Backup is done. Just, I guess 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.
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
* sys-apps/memtest86+
Available versions: 2.01^t 4.00^t 4.20-r1 (~)4.20-r3 5.01-r2 (~)5.01-r3 {floppy iso serial}
Homepage: http://www.memtest.org/
Description: Memory tester based on memtest86
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.
Sorry for the inconvenience and thanks in advance!
g0n ~ #
Too many inconsistencies. Where do I start searching for the causes?
(As far as the fourth "inconsistency", I was thinking about trying memtest as
per:
Message-ID: <LO1P123MB067395FD4E9010B549743C9280120@LO1P123MB0673.GBRP123.PROD.OUTLOOK.COM>
How to get memtest onto a USB drive
https://lists.gt.net/gentoo/user/325837#325837
, but that's just for lack of other ideas, these issues don't look
like bad memory. I might still try it, but when I go to sleep, not sooner.
)
Regards!
---
[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
I have tried hard to make this message to the point. But that wasn't easy, as
what I figured out about gzip --only after hours of work-- I still do need
confirmation about, even though all appears correct.
gzip apparently inconsistent behavior occupies the most part of the report on
inconsistencies here (esp. the script make_gzip_archives_consistent.sh).
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
(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.
The third part is about Bash apparent misbehavior.
And the fourth part is about eix complaining it has a bug, it's near the bottom part
of this email.
That is my starting point, and at this stage, after having spent quite a few
hours on this issue below (but I have other issues not-directly-related to my system
that haven't allowed me to finish and send this yet)...
This issue below I thought at first could be related to my Wireshark woes, and
now I don't... and at this stage (the proofreading time) I'm actually asking for
any confirmation/denial on my findings about it...
miro@g0n ~ $ ls -lh wireshark-users_miroR_q_bug_q.txt
-rw-r--r-- 1 miro miro 802 2017-04-30 17:16 wireshark-users_miroR_q_bug_q.txt
miro@g0n ~ $ ls -l --block-size=K wireshark-users_miroR_q_bug_q.txt
-rw-r--r-- 1 miro miro 1K 2017-04-30 17:16 wireshark-users_miroR_q_bug_q.txt
miro@g0n ~ $ mv -vi wireshark-users_miroR_q_bug_q.txt gzip_buggy.txt
'wireshark-users_miroR_q_bug_q.txt' -> 'gzip_buggy.txt'
miro@g0n ~ $ tar czf gzip_buggy.txt.tar.gz gzip_buggy.txt
miro@g0n ~ $ tar czf gzip_buggy.txt_1.tar.gz gzip_buggy.txt
miro@g0n ~ $ tar czf gzip_buggy.txt_2.tar.gz gzip_buggy.txt
miro@g0n ~ $ sha256sum gzip_buggy.txt*.tar.gz
26bcad15b4a81a3606859fdd4560af0e2c4cd875f1271808afb4569c50bfb5ec gzip_buggy.txt_1.tar.gz
bd8f51bcd3274bbee4f73fa7ba9e1a2acd5db5d27f5643f72de10c52e224c22a gzip_buggy.txt_2.tar.gz
251a57e83ebaf4f07179f4a6500be80612a39ac6d2e97e482b30fb0a4de66f56 gzip_buggy.txt.tar.gz
miro@g0n ~ $
You may check attachments:
gzip_buggy.txt_1.tar.gz
gzip_buggy.txt_2.tar.gz
gzip_buggy.txt.tar.gz
I think this is not like it should be. But the important question, really, is:
is this the case in my machine only, or is it Gentoo-userdom wide?
I fear it's the former, but like I asked in that Wireshark thread
(
And it was amazing to see how little people care... there are always plenty of
readers of Wireshark ML, and while not all can understand that thread --it
took me years since I first used Wireshark to get to be able to minimally
contribute there... lots of readers there such--, and of course those that can
not really understand, need not reply... but lots of readers of Wireshark ML
can easily repeat my steps that show in which exact fashion my Wireshark
misbehaves...
I'll be thankful is some Gentoo reader fills in this huge gap of
carelessness..
)
[but like I asked in that Wireshark thread,] I ask here on Gentoo users ML (or
readers from elsewhere).
Pls. somebody confirm if this is, or is not, the case in their Gentoo
machines. By simply decompressing the tar-gzip'd archive are do the tar-gzip
compression as I did, and checking the sums of them.
If you don't like my text file, you can use any file (like the ASCII file
below, which I hope should be simple and fine enough), and reproduce what I
tried with it.
So let's try /usr/bin/eix-installed-after
It's ASCII, it's Gentoo, everybody has it on this ML, but for visitors, it's in
You may check attachments:
eix-installed-after_1.tar.gz
eix-installed-after_2.tar.gz
eix-installed-after.tar.gz
In my Gentoo, I copied it in my homedir and...
miro@g0n ~ $ tar czf eix-installed-after.tar.gz eix-installed-after
miro@g0n ~ $ tar czf eix-installed-after_1.tar.gz eix-installed-after
miro@g0n ~ $ tar czf eix-installed-after_2.tar.gz eix-installed-after
miro@g0n ~ $ sha256sum eix-installed-after*.tar.gz
80d004b1ecc6e6c2aec7cd453d05c7b4e4cc4092b9cef6b7c3fb31d148eb2310 eix-installed-after_1.tar.gz
f4c30c6d4ccc90d1ec2cc6df2ac10cae2545d04a85c7ff39207d93129cd0ec78 eix-installed-after_2.tar.gz
a8161c5771b661476966250af31d2b8bd80581a3e0c52d535b401524ee541ae7 eix-installed-after.tar.gz
miro@g0n ~ $
And let me go further. Inspecting those...:
miro@g0n ~ $ ls -l eix-installed-after*.tar.gz
-rw-r--r-- 1 miro miro 3771 2017-04-30 17:39 eix-installed-after_1.tar.gz
-rw-r--r-- 1 miro miro 3771 2017-04-30 17:39 eix-installed-after_2.tar.gz
-rw-r--r-- 1 miro miro 3771 2017-04-30 17:39 eix-installed-after.tar.gz
miro@g0n ~ $ ls -l --block-size=K eix-installed-after*.tar.gz
-rw-r--r-- 1 miro miro 4K 2017-04-30 17:39 eix-installed-after_1.tar.gz
-rw-r--r-- 1 miro miro 4K 2017-04-30 17:39 eix-installed-after_2.tar.gz
-rw-r--r-- 1 miro miro 4K 2017-04-30 17:39 eix-installed-after.tar.gz
miro@g0n ~ $
...those tiny files, I find that...:
miro@g0n ~ $ hexdump -C eix-installed-after.tar.gz | head -c38
00000000 1f 8b 08 00 25 05 06 59 00 miro@g0n ~ $ hexdump -C eix-installed-after_1.tar.gz | head -c38
00000000 1f 8b 08 00 27 05 06 59 00 miro@g0n ~ $ hexdump -C eix-installed-after_2.tar.gz | head -c38
00000000 1f 8b 08 00 29 05 06 59 00 miro@g0n ~ $
miro@g0n ~ $
...it's always the... ah well, for clarity, let's head just the first 25 bytes
of the hex representation, whihc will later be 5 bytes for dd commands...:
miro@g0n ~ $ hexdump -C eix-installed-after.tar.gz | head -c25
00000000 1f 8b 08 00 25 miro@g0n ~ $ hexdump -C eix-installed-after_1.tar.gz | head -c25
00000000 1f 8b 08 00 27 miro@g0n ~ $ hexdump -C eix-installed-after_2.tar.gz | head -c25
00000000 1f 8b 08 00 29 miro@g0n ~ $
...that it's always (or almost always, see below about PART3 sometimes being
different) just the 5th byte that is different, in the way that doing the
procedure below will get those files which differed at creation time...:
80d004b1ecc6e6c2aec7cd453d05c7b4e4cc4092b9cef6b7c3fb31d148eb2310 eix-installed-after_1.tar.gz
f4c30c6d4ccc90d1ec2cc6df2ac10cae2545d04a85c7ff39207d93129cd0ec78 eix-installed-after_2.tar.gz
a8161c5771b661476966250af31d2b8bd80581a3e0c52d535b401524ee541ae7 eix-installed-after.tar.gz
(
Notice: the hash is always new. You won't get any of those hashes above
if you tar-gzip it. This is about the non-identical results.
)
...to become identical. This procedure, that I'll put in the script:
Pls see attachment:
make_gzip_archives_consistent.sh
The fact is, I have, hours ago (this is slow work for me...) made a backup
(and spent all this time, and more to write that script), and noticed how my
gzip behaves, or should I say the gzip program *in my machine*... And...
And I can tell that I get different instances of archives consistently fixed
with that script.
I only can't get identical archives when PART3 is different in some (usually
only one of the three) of the archives.
NOTE (at proofreading time): But I'm not investigating that anymore, find how
I confirmed that the archives upon decompression are all of verifiably same
content, and that suffices.
I really have tried only on my backup, on multiple series of three different
tar-gzip'ed instances each of which in the series was done on the same
directory with the script above.
The script is just a proof of concept, and a demonstration of the apparent
issue. Because this previously does not seem to me to have been the case, but
maybe I misremember?
I checked a few of the tar-gzip'd archives of my backup, and so far they have
always, upon decompression, shown identical in all the different instances.
The finding
===========
I've typically compared series of three instances of same directories that I
backed up, such as /home/miro, /root and /var/log, and they always were
identical upon decompression.
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
That means *probably* all is fine with gzip, and there is no issue.
(But this result was not trivial to get by... and since I'm unsure in my
conclusion, I'm still posting this, asking for confirmation or denial.)
So maybe I've been chasing shadows here... And for long hours...
And I'm sorry if that is so, but look at that issue that I have with
Wireshark! Look at that! That's not a shadow. 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.
Same holds for the gzip inconsistency --or "inconsistency".
)
And looking for solution to that Wireshark issue, I found the above issue
which appeared to me to be some kind of inconsistency...
And I have other inconsistencies, bogus or true that they might be, such as
with bash.
One is very quick to report. Here it goes...
Thanks for any report on how this issue, and the one with Wireshark, shows,
completely in order or just like in my machine, in any other Gentoo users'
systems.
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,
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.
]]
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:
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)
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...
I'll try and send this soon, but I first need to finish my backup...
Backup is done. Just, I guess 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.
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
* sys-apps/memtest86+
Available versions: 2.01^t 4.00^t 4.20-r1 (~)4.20-r3 5.01-r2 (~)5.01-r3 {floppy iso serial}
Homepage: http://www.memtest.org/
Description: Memory tester based on memtest86
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.
Sorry for the inconvenience and thanks in advance!
g0n ~ #
Too many inconsistencies. Where do I start searching for the causes?
(As far as the fourth "inconsistency", I was thinking about trying memtest as
per:
Message-ID: <LO1P123MB067395FD4E9010B549743C9280120@LO1P123MB0673.GBRP123.PROD.OUTLOOK.COM>
How to get memtest onto a USB drive
https://lists.gt.net/gentoo/user/325837#325837
, but that's just for lack of other ideas, these issues don't look
like bad memory. I might still try it, but when I go to sleep, not sooner.
)
Regards!
---
[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