AV Linux MX Edition is here!

[dolphin_oracle]

But, I've found an issue. I'm using the x64 version. When opening a .h2song file with LMMS (installed via stable repo) the program itself closes immediately. I don't understand why.

Generally in Linux, when some program don't start or closes right away, you want to run in a terminal. That way, you will usually be able to see some error msg, which can then help in troubleshooting.

In your specific case, I don't know that app, I'm not using AV Linux, so someone else will need to tell you, what the command is.
Once you find out which command to run in a terminal, copy/paste output here for further help.

I doubt there is actually an error message anywhere since md5sum actually completes. it just computes the wrong value.

there is a log though at /var/log/mx-snapshot.log

[AVLinux]

Hi! Sorry, had to grab a quick bite in there..

OK so I tried the new MX-Snapshot package... created a new ISO, ISO checksums matched, burned to USB Key with LUM, Booted USB key and ran F4 md5sums options and all 3 files passed! That's good right??

[fehlix]

OK so I tried the new MX-Snapshot package... created a new ISO, ISO checksums matched, burned to USB Key with LUM, Booted USB key and ran F4 md5sums options and all 3 files passed! That's good right??

Exzellent!
Regarding heating issue you mentioned.
To reduce max number of processors to allow mksquashfs to take
do adjust within

Code: Select all

/etc/mx-snapshot.conf

the option "mksq_opt="
e.g like this for you 24 core system

Code: Select all

mksq_opt="-processors 12"

[AVLinux]

Oh that is a big relief to know!! So what did you change in MX-Snapshot?

Thanks for the info on changing the number of cores too!

[fehlix]

So what did you change in MX-Snapshot?

I added additional sync's and a forced freeing pagecache,
before each of the big files get processed by md5sum/sha512sum

Code: Select all

sync
sleep 1
echo 1 > /proc/sys/vm/drop_caches
sleep 1

[AVLinux]

Ahhh I see...so a couple more questions and hopefully you will be rid of me for a while..

So are the existing uploaded ISO's compromised in any way, or was the md5sum just not computed properly without any real issue to the installed system? Will Users who installed the original ISO be able to create their own snapshots once they upgrade to your updated MX-Snapshot Package? Or do I need to upload a whole new ISO ASAP?

Thanks again for your patience and quick response to this issue, I will be sure in the future to run all of the possible MD5 tests!

[fehlix]

Ahhh I see...so a couple more questions and hopefully you will be rid of me for a while..

So are the existing uploaded ISO's compromised in any way, or was the md5sum just not computed properly without any real issue to the installed system? Will Users who installed the original ISO be able to create their own snapshots once they upgrade to your updated MX-Snapshot Package? Or do I need to upload a whole new ISO ASAP?

Triggers two points:
Point 1:
The linuxfs.md5 is not just for the F4 option to have a comfortable check.
But all those md5sum's within the antiX folder do have a reason.
The main issue would be the error message the user will get from LUM (gui or cli) when user creates a full featured LiveUSB. Also, I'm not 100% sure whether a "wrong" md5sum might be an issue when doing a "rollback" after having made a remaster.
2nd point:
Whether the ISO's are compromised ...
None of the md5sum or sha*sum will tell you anything about the ISO are compromised or not.
The way people try to put a bit of certainty in this issue is to sign the iso using gnupg
to create a pgp-signature. With help of the published "public" signing key user could verify the signature of the iso. In case you have never done anything with gpg-signing I might send a quick receipt how to do this easily .. later ...

[JayM]

FYI i just burned the 64-bit iso to my flash drive using LUM in dd mode and it burned and booted. When I rebooted from the stick and selected checkfs from the F4 options menu it still booted and I didn't get any error messages. I assume this is because a dd burn results in a read-only live system while full-featured mode allows MX RemasterCC to write to the squashfs, and whatever is causing the file system checksum issue would prevent that, or rather RemasterCC won't write to a file system that it thinks is corrupt. Something like that anyway, I don't really know the internal workings of full-featured live USBs very well except from a user standpoint.

Off-topic slightly but I noticed that when I booted the 32-bit live USB it prompted me for a password (which i correctly guessed was "demo") but the 64-bit version automatically logged in.

[AVLinux]

Hi Jay,

Yes the 32bit uses SliM and is not Autologin, FWIW this is mentioned in the release notes and also on the webpage. You're correct it's "demo"

Due to the issues in this thread and because there was a last minute update to Harrison Mixbus 32C I have decided to upload an updated and fixed 64bit ISO..

[JayM]

You can configure SLIM to auto-login if you want: https://wiki.archlinux.org/index.php/SLiM