SliTaz Forum
You are not logged in.
Pages: 1
Hello,
In Slitaz 4.0, there is a Syslinux module, md5sum.c32.
I customized the ISO and added files. Slitaz works correctly, so I have no problem with it.
But when I use md5sum.c32 in the customized ISO, it gives inconsistent results. I mean that even when the files tested are in fact correct, the result of md5sum.c32 states that some files are "not checked".
To replicate this problem in the original Slitaz 4.0 ISO, I boot it once, select to check media. When the check finishes I go back to the menu and select the same option (check media) again, without rebooting.
By repeating the checksum in the original Slitaz 4.0 again and again about 10 times (maybe more, I lost track), I finally see the same behavior as happened with the customized ISO. The checksum was OK the first 10 (or so) times (without rebooting), and then suddenly the result of md5sum.c32 changes and some files give a "not checked" result.
After that, If I reboot once and try the same procedure again (repeating check media several times without rebooting in between), then I see the same strange behavior: files that pass the first 10 (or so) times and then they return "not checked". Interestingly, the fail happens exactly at the same point in the checksum.
In Cook, there is a new "c32box.c32 md5sum" module that includes (or replaces) md5sum.c32. The new c32box.c32 behaves exactly the same as the older md5sum.c32.
The easiest way to replicate this problem is to customize the ISO with many more (say, 180) files than the original and to include the added files in the corresponding md5 check list file.
Moreover, after the last checksum run, the boot prompt won't let me do anything. At this point, trying to start the menu again fails, as trying to start any other kernel.
Please, Can someone else replicate this behavior?
Can this problem in "md5sum.c" be solved?
TIA,
Ady.
Offline
What kind of CPU are you using? 64bit systems will return a wrong number because of higher and more memory registers. It's a known issue with 32bit modules/code used on 64bit systems.
Offline
isolinux does not support iso format rockridge extensions.
md5sum.c32 can open 8.3 only (maybe more)
'Not checked' means 'Unsupported file name (by isolinux)'
Offline
Those explanations would be valid if the checksum would always fail, or if it would always result in "not checked". But I'm describing an inconsistency in the results, not a failure in my system.
The first time all is OK. Without rebooting, I select "check media" again and the result changes!!!
Moreover, if I generate an even bigger ISO with more files (that are also listed in the md5 check list), I'll see the problem already in the first run. If the customized ISO is smaller (but still with more files than the original Slitaz 4), then the first and second runs are OK and the "not checked" starts at the third run.
That's why I am requesting for someone else to replicate this behavior with the original Slitaz 4.0. It takes some patience to run the "check media" boot selection more than 10 times (but less than 20) in a row without rebooting, but it is not _that_ much time either. I'd say it is more boring than it is time-consuming.
Additionally, I don't know if this strange behavior depends on the amount of RAM available.
So, please, can someone take the original Slitaz 4.0 and replicate this?
TIA,
Ady.
Offline
During the weekend I tested a Slitaz-rolling.iso in VBox.
The list of checksums contains only 23 files, so to reproduce the same behavior I already described, here is what I did:
1_ Boot the ISO once;
2_ Selected "check media" 26 times in a row without rebooting in between;
3_ For the first 25 iterations, the results were correct, but the 26th time, the results changed, and I wasn't able to do anything else from the boot prompt after it.
This problem has nothing to do with x32/x64, nor to 8.3 filename restrictions.
This is a problem with md5sum.c related to the number of files to be checked.
Please, at least make the effort to replicate this behavior in your systems and report it back here.
TIA,
Ady.
Offline
The default md5 checksum on the site matches the ISO image and NOT the burned CD. Comparing them will result in a mismatch.However checking within the LiveCD is different because several factors are in play. First the CD you burned the iso to and the device that burned it. A defect in either would make the LiveCD not work, especially for a sensitive one like our compressed iso image. That you pass the test 20+ times tells me a totally different story. The iso image and the burned copies aren't at fault. Neither is the file you mentioned. It is your system. More precisely it's, your RAM and how your system uses it.
This used to happen to me with Ubuntu and I couldn't figure out why. Then I messed with my bios settings and noticed memory error checking for RAM was disabled. Once I enabled it, the problem disappeared. While Windows is more forgiving, Linux expects a more precise system to work. Anything less and it fails.
Offline
@Trixar_za,
Have you even really read what I am posting?
I don't mean to be rude, but your post has nothing to do with md5sum.c32 or with c32box.c32. This is not about the md5 checksum for the downloaded ISO, and sure it has nothing to do with Ubuntu, since Ubuntu checks its media using a different approach.
@All,
Since Pascal Bellard is the author of these Syslinux modules, I hope at least he understands what I am talking about.
Now, whoever wants to replicate this wrong behavior, I already gave 3 methods to do it. Here is the 4th:
1_ Expand your Original Slitaz 4.0 (or new rolling) ISO image.
2_ Open the md5sum file that contains the md5 checksum list.
3_ Copy the content (the list) again and again up to 4, or 5 or 6 times in the same md5sum file.
4_ Save the modified md5sum file.
5_ Build the modified ISO.
6_ Follow the same testing procedures as before (posted in my previous posts).
Since the list of files (and md5 checksums) is longer, instead of taking 9 or 26 iterations of "check media", it should take just 2 or 3 iterations to see the problem (less than 5 minutes) in any VM.
Moreover, if the list in md5sum is repeated even more times, then you will get to a point were even the first run of "check media" will fail, no matter what.
You can test this on real CD, on USB drive, or in a virtual machine.
Please replicate this behavior, so maybe Pascal will be able to find the problem.
TIA,
Ady.
Offline
Is there anything I can do to facilitate the test?
Can anyone (Bellard?) take less than 10 minutes so to replicate the behavior with any Slitaz 4.0+ ISO in a VM (using the 4th method is faster) and report it here?
TIA,
Ady.
Offline
Bellard?
Offline
I am changing the status of this topic as "solved", in hope that the following information might trigger the "real" solution in the future.
1_ Some time ago, patches taken from the official Syslinux git were applied to the Syslinux package in Slitaz Rolling (wok) to solve the md5sum problem.
2_ The official Syslinux 4.07-pre1 release contains the necessary patches to solve the problem of md5sum in all cases (Slitaz 4.0 : "md5sum.c32" ; Slitaz Rolling : "c32box.c32 md5sum").
Some additional comments:
1_ I would suggest using the official Syslinux 4.07-pre1 (in the same way the official Syslinux 4.06 was used before in combination with the Slitaz-specific c32 modules), instead of making specific patches in Slitaz.
2_ For better clarity, the md5sum.c used to build c32box.c32 (for Slitaz Rolling / cook) should be re-named as "c32box.c" (with the corresponding adjustments in receipts and what not).
3_ I would still wish / like to have "separated" 'ifmem.c / ifmem.c32' and 'md5sum.c / md5sum.c32' (and when I say here "md5sum.c", I mean not as the source of the whole big c32box.c32, but as the source of a "separated" md5sum.c32).
4_ Request for improvement: After the final report of md5sum.c32, the module should "pause" (display "Press any key to continue"), instead of automatically returning back to the Syslinux prompt, since the timer (TIMEOUT directive) clears the screen.
If more details are needed, please don't hesitate to ask.
Thank you and Best Regards,
Ady.
Offline
Pages: 1
[ Generated in 0.018 seconds, 7 queries executed - Memory usage: 1.56 MiB (Peak: 1.77 MiB) ]