AV Linux MX Edition is here!

[drummer]

I think openbox is only for the 32bit version

Yeah I got a little ahead of myself lol, but I can use Openbox for the WM in XFCE instead of XFWM, and of course just create a Openbox desktop to log into as well as the default XFCE.

The vid kinda got me all excited (blush).

[fehlix]

The iso's md5:

Code: Select all

$ md5sum AVL-MXE-2020.11.23-xfce4-amd64.iso
7c12005d3a8b3669f84d536542215062  AVL-MXE-2020.11.23-xfce4-amd64.iso

with the iso mounted:

Code: Select all

linuxfs
root@mx-desktop:/mnt/iso/iso1/antiX# md5sum -c linuxfs.md5 
linuxfs: FAILED
md5sum: WARNING: 1 computed checksum did NOT match

root@mx-desktop:/mnt/iso/iso1/antiX# head /mnt/iso/iso1/antiX/*.md5
==> /mnt/iso/iso1/antiX/initrd.gz.md5 <==
e2d82f4774577e556c2ba6c7a99d53bc  initrd.gz

==> /mnt/iso/iso1/antiX/linuxfs.md5 <==
cdaf6aace23e4f2e176001727acb52e3  linuxfs

Ok, so this confirms you got also the wrongly generated linuxfs.md5.
The checkmd5 option on the LiveBoot menu is doing excatly the same
and gives me a warning/error message and an option to ignore or shutdown.
Make sure you selected not the other checkfs option.

AVL-MXE-64bit-F4_options.png

F4-checkmd5.png

F4-checkmd5-non-fatal-error-warning.png

If you can reproduce getting no warning despite the manual failed md5sum check
we would need to further investigate.

[fehlix]

I fear I have used a wrong word.. by 'compromised' I did not mean in a security or malware way. I meant if there were flaws or errors in the filesystem that would make the system function improperly or unstable

If the ISO-checksum do match, we can assume the ISO are OK, with only one flaw of the wrongly generated linuxfs.md5. So until you have the isos updated, you could tell the user, that the ISO are not compromised.
It also a good idea to publish the ISO-checksum not just only on the download server, but somehwere on the download-page to avoid a single point of failure.
In addition do manual generate a gnupg signature file and put on the server like the cheksum files.
I'll send a gnupg-iso-signing receipt ina minute or so..

.. I don't think it is a surprise that JayM would have a successful copy to USB using DD, there are not the same md5sum checks with DD are there? Also Jay ran checkfs not md5sum..

On both dd-dumped or fullfeatured mode generated LiveUSB, the MD5-sum check of the antiX/*.md5 sum are identical. So I can only assume JayM have chosen the other checkfs option, otherwise it would be an issue within the Live md5sum check script, which I would be really surprise me . Manual check after isomount is the quickest way anyway.

[fehlix]

Quick receipt to digital sign ISO or other data files.

For publishing ISO's in addition to have checksums prepared some users like to perform a digital signature check to verify the iso-file is not compromised. For this purpose we create a dedicated gnupg signing key,
which provides only signing but no encryption capabilities.

Quick generate signing key:
gpg --quick-generate-key "NAME <email>" algo purpose expire
NAME: choose any name, probaly best related to iso-signing
EMAIL: need not to be a valid one
ALLGO: rsa4096
purpose: sign
expiration: 2 years
Example:

Code: Select all

gpg --quick-generate-key  "demo iso signing key <demo-iso-signing@demos-home.com>" rsa4096 sign 2y

Code: Select all

gpg --quick-generate-key  "demo iso signing key <demo-iso-signing@demos-home.com>" rsa4096 sign 2y

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: key EF80867E1956F430 marked as ultimately trusted
gpg: revocation certificate stored as '/home/demo/.gnupg/openpgp-revocs.d/9D2AAC5F57F8CD9BF78FD1B7EF80867E1956F430.rev'
public and secret key created and signed.

Note that this key cannot be used for encryption.  You may want to use
the command "--edit-key" to generate a subkey for this purpose.
pub   rsa4096 2020-11-27 [SC] [expires: 2022-11-27]
      9D2AAC5F57F8CD9BF78FD1B7EF80867E1956F430
uid                      demo iso signing key <demo-iso-signing@demos-home.com>

List signing key with fingerprint:
list keys

Code: Select all

gpg --keyid-format 0xlong --list-keys demo-iso-signing@demos-home.com
pub   rsa4096/0xEF80867E1956F430 2020-11-27 [SC] [expires: 2022-11-27]
      9D2AAC5F57F8CD9BF78FD1B7EF80867E1956F430
uid                   [ultimate] demo iso signing key <demo-iso-signing@demos-home.com>

list keys with finger print

Code: Select all

gpg --keyid-format 0xlong --fingerprint 0xEF80867E1956F430
or
gpg --keyid-format 0xlong --fingerprint demo-iso-signing@demos-home.com

pub   rsa4096/0xEF80867E1956F430 2020-11-27 [SC] [expires: 2022-11-27]
      Key fingerprint = 9D2A AC5F 57F8 CD9B F78F  D1B7 EF80 867E 1956 F430
uid                   [ultimate] demo iso signing key <demo-iso-signing@demos-home.com>

Key-ID in our example is "0xEF80867E1956F430"

Sign an ISO-file
with long and short options:

Code: Select all

gpg --local-user "demo-iso-signing@demos-home.com" --detach-sign --output demo-test.iso.sig demo-test.iso

gpg -u "demo-iso-signing@demos-home.com" -b -o demo-test.iso.sig demo-test.iso
gpg -u "demo-iso-signing@demos-home.com" -b  demo-test.iso

gpg -u 0xEF80867E1956F430 -b  demo-test.iso

Export public signing key
Export the public signing key into a file and make it availbe on your web-server.

Code: Select all

gpg --armor --output 0xEF80867E1956F430_public_signing_key.asc  --export 0xEF80867E1956F430

Send the public iso-signing key to the gnupg-keyserver network:

Code: Select all

gpg --keyserver pool.sks-keyservers.net --send-key 0xEF80867E1956F430
gpg --keyserver keyserver.ubuntu.com    --send-key 0xEF80867E1956F430

Export secret signing key as backup and to make it available on another computer:

Code: Select all

gpg --armor --output 0xEF80867E1956F430_secrete.asc  --export-secret-keys  0xEF80867E1956F430

Import secret signing key on another computer:

Code: Select all

gpg --import 0xEF80867E1956F430_secrete.asc

Make a paper backup copy of secrete key:
to be printed on paper

Code: Select all

gpg --export-secret-keys  0xEF80867E1956F430  | paperkey > 0xEF80867E1956F430_secrete_paperkey.txt

The generated printed paperkey.txt can be easiley read from paper copy by OCR.

Reconstruct secrete key from a paperkey.txt file combined public key:
paperkey --pubring my-public-key.gpg --secrets my-key-text-file.txt --output my-secret-key.gpg

Code: Select all

paperkey --pubring 0xEF80867E1956F430_public_signing_key.asc --secrets 0xEF80867E1956F430_secrete_paperkey.txt --output 0xEF80867E1956F430_secrete.gpg

[Adrian]

That's great tutorial, maybe it needs to be put in a Wiki page instead of losing the instructions on some obscure thread in the forum

[AVLinux]

Thanks so much fehlix for taking the time to prepare that guide!

On the other issue I really need to put on the brakes here.. I have an issue occurring now that defies my comprehension, I need to get a 'checksum clean' ISO off of this machine and move to an older machine to continue development. I don't know if it's a memory problem, a CPU support problem, a heat problem, an SSD problem but this machine is flaky somehow. I'm not a dummy or a newb when it comes to building PC's and choosing hardware but I am baffled so I think before I waste one more second of anyone's precious time I'd like to determine if the existing released 64bit ISO can have the faulty linuxfs md5sum fixed OR if installing that ISO on a new host machine and re-running MX-Snapshot and producing an ISO without a bad linuxfs checksum will create a path forward.

Here's where things are at now, read slowly because it's pretty convoluted:

If you recall you sent me an updated MX-Snapshot, I installed it, rebooted the machine just in case, re-ran bleachbit which I always do before building an ISO and I built the ISO which as I reported to you on the forum last night generated all correct checksums and passed all the F4 boot tests and it did! After all of our forum discussions last night just before going to bed I added one updated program to the ISO, ran bleachbit, ran the new MX-Snapshot again this time with 12 CPUs in mksqfs and for some reason that I cannot begin to fathom Snapshot generated checksums that do not match the ISO just like my original issue with the performance CPU governor!? The thing is the governor is still set to 'ondemand'. OK maybe it didn't like the revised CPU setting so I unset the 12 CPU settings back to default and ran the new Snapshot again, same issue... ISO md5 and SHA512 are incorrect.. Then I downgraded MX-Snapshot to the current Repository version again and tried it because despite the linuxfs md5sum problem the repo version of MX-Snapshot was generating correct ISO checksums every time.. well not any more... md5 and SHA512 are still incorrect.. As a final last resort before posting this I ran the Repo version of Snapshot with 4 CPU's set in mksqfs and once again, incorrect checksums... So I am DOA right now for the ability to Respin an ISO off of this hardware. This is why I want to fix what I have if possible and take this machine out of development..

[JayM]

i had just run the head command for *.md5 in the antiX directory of the mounted but not booted from live USB burned in dd mode. here's the result of md5sum:

Code: Select all

$ md5sum linuxfs
7475ac389c3ead1c7e5a8b228025b0d6  linuxfs

and again here's the head command on linuxfs.md5:

Code: Select all

$ head linuxfs.md5
cdaf6aace23e4f2e176001727acb52e3  linuxfs

So it looks like an md5 computation error when MX Snapshot computed the md5 sum then created the rootfs.md5 file.

Regarding multiple sync commands: https://utcc.utoronto.ca/~cks/space/blo ... gendOfSync
It seems that running sync more than once actually just creates a delay before executing the command that comes after, so I would think that a sleep command would do the same thing which is just to wait a bit for the sync to finish clearing the buffers before continuing. Multiple syncs shouldn't be necessary. (I do vaguely remember, in the early days of Linux, when doing something-or-other, maybe a kernel compilation (?) that instructions always said to manually sync three times as per the example in the website I linked to. That was decades ago though so I don't remember it clearly. I seem to recall having to do it in AT&T Unix SysV 3.2 also, 30-some years ago. I think that was before shutting down or rebooting though, as per the blog in my link.)

Maybe adding a short sleep after syncing or possibly before and/or after the md5 calculations is all that's needed? I have a gut feeling that it's a timing issue as AVLinux also had iso md5 issues creating snapshots with the performance CPU governor enabled and I believe he's using a custom low-latency kernel. Maybe the buffers weren't cleared when the calculations were done because the kernel and/or processor are too fast?

[Be OK]

Downloaded the iso today md5 checks flashed on usb stick with balenaetcher usb would not boot so flashed with mxliveusbmaker using DD as is a 4GB stic. Sadly that will not boot to.Using file manager i can see the files on the stick.Using gparted it show as file system iso9660 loabel mxlive used,unused and flags empty.
The release candidate2 was installed with no problems and running.
Machine:: Laptop System: Hewlett-Packard product: HP Pavilion 17 Notebook PC.
The problem is in the bios the boot manager option is greyed like the stick is not bootable.
Any advice ?

[fehlix]

Downloaded the iso today md5 checks flashed on usb stick with balenaetcher usb would not boot so flashed with mxliveusbmaker using DD as is a 4GB stic. Sadly that will not boot to.Using file manager i can see the files on the stick.Using gparted it show as file system iso9660 loabel mxlive used,unused and flags empty.
The release candidate2 was installed with no problems and running.
Machine:: Laptop System: Hewlett-Packard product: HP Pavilion 17 Notebook PC.
The problem is in the bios the boot manager option is greyed like the stick is not bootable.
Any advice ?

Yes, try another USB-stick USB-3 min 8GB. ALso you can try full feature mode instead of DD-mode.
The 64bit ISO boots here in BIOS and UEFI mode without an issue.
When you create in full-feature mode, you might see a warning about an internal md5sum check of linuxfs failed.
This is a know issue, and can be ignored for this ISO, as it will be fixed in an updated version.

[Be OK]

@fehlix ok will do that on a 8GB,and yes i had read here about the md5 and that the iso was ok as was mine checksum.
Will edit this here if i have succes,Sadly no at the end of the stick he give a error and it looks like it does not write a bootloader.
Wil flash again as i dint read the error :(
liveusb maker 2.41.17
check md5 for initrd.gz , check md5 for linuxfs and check md5 for vmlinux

live usb maker took 22 minutes and 53 seconds

then a popup with the text
Error encountered in the LiveUSB creation process. after that i try to boot in other machine to, Nothing that machine hangs after selecting usbdrive (enter).