UBCD V5.1 beta 1 available for download

[Victor Chew]

This version is obsolete. The latest version is available at:
viewforum.php?f=7

UBCD V5.1 beta 1 is now available for download

Torrent: http://www.ultimatebootcd.com/download/ ... so.torrent
Magnet URI: magnet:?xt=urn:btih:24VEQ7MEVTZ4Y6ZPNA3SWZSMQISJ56Q5
HTTP: http://ubcd.mirror.fusa.be/ubcd51b1.iso
FTP/HTTP: http://ubcd.linuxfreedom.com
md5sum: 1ef674a5c12df5ec92b9b22db2dbc0d5
sha1sum: 9ed8c3feb956d87034918e6e0b0351055757e4b6
SHA-256: B38FB6B780815C2EFC4D46CE8649ED0B9C5E1A4E41DBF31EFDC279F047EC0EDB (computed using 7-Zip's "Calculate checksum" function)

Description:

This release is my first attempt at updating some Linux components (F-Prot and XFPROT in Parted Magic). Hopefully I didn't miss anything.

@ady: I found out isolinux.bin is modified by mkisofs during ISO image generation. That's why the isolinux.bin in UBCD is different from the one in the syslinux distro.

Changelog:
- Disabled FDUBCD menu for WDIDLE3 and DIMM_ID in ubcd.ini.
- Re-added missing aida16.cab to fdubcd.iso.gz.
- Updated Offline NT Password & Registry Editor to v110511. Thanks to IceCube for the update.
- Updated ASTRA to V5.50. Thanks to ady for the update.
- Updated to SPFDisk to 2000-03v. Thanks to Explorer09 for the update.
- Filter away Parted Magic entries in grub4dos menus.
- Updated Intel Processor Identification Utility to V4.31. Thanks to ady for the update.
- Updated Parted Magic to V6.2. Updated F-Prot to V6.0.3. Update XFPROT to V2.4.
- Updated UBCD FreeDOS to V1.43. Updated XCOPY to V1.4a. Updated SYS.COM from FreeDOS kernel 2039. Updated LOWDMA.SYS and UMBPCI.SYS to V3.81. Changed help.bat in level1\help.bat to test for MORE.EXE instead of MORE.COM.
- Updated ubcd\tools\unxutils\bin\xz.exe to V5.0.3. Thanks to ady for the update.

[ady]

I found out isolinux.bin is modified by mkisofs during ISO image generation. That's why there's a one byte difference between the isolinux.bin in UBCD and syslinux distro.

These following questions are not for Victor specifically, but for anyone who could help find some answer/workaround.

Is there any other method (or command argument or other tools) to get "the original" isolinux.bin and still have the ubcd iso correctly built?

Is this issue happening to any other project using isolinux.bin?

[Icecube]

Is there any other method (or command argument or other tools) to get "the original" isolinux.bin and still have the ubcd iso correctly built?

It is possible, but it is not that easy to do it manually.

If you just want to check if the isolinux.bin file is from an official release, only checksum from byte 64 to the end (so the boot-info-table is skipped).

Is this issue happening to any other project using isolinux.bin?

Yes, unless isolinux.bin is chainloaded from grub4dos, in which case it is patched in memory when you use the chainloader command. Also Syslinux chain.c32 can patch isolinux.bin (modified or unmodified) and chainload it, just like grub4dos.

The -boot-info-table switch of mkisofs changes isolinux.bin:

Code: Select all

EL TORITO BOOT INFORMATION TABLE

     When the -boot-info-table  option  is  given,  mkisofs  will
     modify the boot file specified by the -b option by inserting
     a 56-byte "boot information table" at offset 8 in the  file.
     This  modification is done in the source filesystem, so make
     sure you use a copy if this file is  not  easily  recreated!
     This file contains pointers which may not be easily or reli-
     ably obtained at boot time.

     The format of this table is as follows; all integers are  in
     section 7.3.1 ("little endian") format.

       Offset    Name           Size      Meaning
        8        bi_pvd         4 bytes   LBA of primary volume descriptor
       12        bi_file        4 bytes   LBA of boot file
       16        bi_length      4 bytes   Boot file length in bytes
       20        bi_csum        4 bytes   32-bit checksum
       24        bi_reserved    40 bytes  Reserved

     The 32-bit checksum is the sum of all the  32-bit  words  in
     the  boot file starting at byte offset 64.  All linear block
     addresses (LBAs) are given  in  CD  sectors  (normally  2048
     bytes).

http://cdrecord.berlios.de/private/man/ ... ofs.8.html

ISOLINUX needs to know the LBA of the isolinux.bin file to find the rest of isolinux.bin. At boot time only 2048 bytes of isolinux.bin are read (-no-emul-boot and -boot-load-size 4 ("virtual" (512-byte) sectors to load in no-emulation mode)).

[ady]

@Icecube, thanks for the info. So, if I understand correctly, this is related to mkisofs too, not only to isolinux.bin. Is there any way to avoid this issue? I mean, if Victor (or any user customizing UBCD for that matter) could use a different tool other than mkisofs to build the UBCD ISO, will this issue appear too?

***


BTW:

Code: Select all

ubcd51b1\ubcd\tools\win32\unxutils\readme.txt

Should be updated with the newer info, like:

Code: Select all

7-zip is v.9.22
http://sourceforge.net/projects/sevenzip/files/7-Zip/9.22/
  7z.exe (7z922.exe)

Code: Select all

xz is v.5.0.3 now from
http://tukaani.org/xz/
  xz.exe from the Windows version

In addition, please consider checking updates for the auxiliary tools that came from http://sourceforge.net/projects/mingw/files/
for the next UBCD beta (Icecube might have better ideas than me about them).

[Icecube]

@Icecube, thanks for the info. So, if I understand correctly, this is related to mkisofs too, not only to isolinux.bin. Is there any way to avoid this issue? I mean, if Victor (or any user customizing UBCD for that matter) could use a different tool other than mkisofs to build the UBCD ISO, will this issue appear too?

This is not an issue, but a feature of mkisofs. The -boot-info-table switch will cause the patching of isolinux.bin. ISOLINUX requires this info (LBA offset). ISOLINUX has some default values that might work in some cases though.
This is also one of the reasons why using ISO editors, is a bad idea. They can accidentally move the isolinux.bin file to another LBA offset, so ISOLINUX can't boot correctly anymore (Can't find it seconds stage).

If you use the modified isolinux.bin to generate a new ISO, the file is patched at the same bytes, so I don't really see the problem.

[ady]

If you use the modified isolinux.bin to generate a new ISO, the file is patched at the same bytes, so I don't really see the problem.

There is no "problem" . UBCD will still work.

ISOLINUX requires this info (LBA offset). ISOLINUX has some default values that might work in some cases though.

So, no matter if a user uses mkisofs or any other tool to build the ISO, isolinux.bin can't be exactly the same as the original (which comes in the syslinux package)? Ever?

Does this mean that any ISO (like Linux distros) that uses isolinux.bin to boot (not chained from other boot loader) actually uses a "patched" isolinux.bin?

[Icecube]

Does this mean that any ISO (like Linux distros) that uses isolinux.bin to boot (not chained from other boot loader) actually uses a "patched" isolinux.bin?

Yes. At least afaik.

[ady]

Does this mean that any ISO (like Linux distros) that uses isolinux.bin to boot (not chained from other boot loader) actually uses a "patched" isolinux.bin?

Yes. At least afaik.

Icecube, thank you for your answers.

***

Victor,

According to what I already posted in a previous ubcd development topic:

_ ESTOOL.EXE (in estool.cab) has the correct checksum, but the wrong modification date. For the next UBCD release, please rebuild the cab with the original executable file (original modification date).

_ MBRWORK.EXE and its readme.txt file (in mbrwork.cab) have the correct checksums, but the wrong modification date. For the next UBCD release, please rebuild the cab with the original files (original modification dates).

_ Partition Saving (savepart.cab) also has its files with the wrong modification date. For the next UBCD release, please rebuild the cab with the original files (original modification dates).

_ Astra (astra.cab) also has its files with the wrong modification date. For the next UBCD release, please rebuild the cab with the original files (original modification dates).

Those are the archives with wrong modification dates that I currently know about. The reason for the different modification dates might not be the same for all the archives.

TIA.

[ady]

DLGDIAG5.CAB no longer contains the text files (they were there in ubcd51a1). The text files are not distributed in the latest version of DLGDIAG5 for DOS, but at least one of them was a help file, including command line parameters (this is the one that might be more important/useful).

The latest zip archive of DLGDIAG5 from WDC doesn't contain any extra text file, just the executable.

Anyway, the most important text file to the user should be the help file, specially for the command line arguments.

I think it could be useful to re-add it in the next ubcd release.

[Victor Chew]

@ady: I have noted all your suggestions.

However, for your suggestions involving modification dates, I won't be adding them to my todo.

Reason is because mod dates can be changed too easily, including something as trivial as changing the filenames to uppercase.

If your purpose is to check for changed files, binary checksums IMHO is the only reliable way to do it. And there are no lack of tools and means to help with the task.

[ady]

@ady: I have noted all your suggestions.

However, for your suggestions involving modification dates, I won't be adding them to my todo.

Reason is because mod dates can be changed too easily, including something as trivial as changing the file names to uppercase.

This seems to be not consistent with previous releases. Most CABs contain files with the correct modification date, even for files from 2004. CABs that were updated in several stable UBCD versions (with newer versions of the same files) also retained the correct (updated) modification date.

So the "little things" that can change the modification date to something else than the correct one, have appeared in recent development releases of UBCD. This change was not happening before.

About the mentioned case of changing the file names to uppercase.
First, it is absolutely not needed.
Second, the programs are started from menus or command-line. There is no main interest of changing their file names to uppercase (or lowercase or whatever; just leave it as the original producer published it).
Third, the action of changing a file name (completely, partially, or uppercase or whatever) doesn't change the modification date of a file. That only happens if you use a "special method" as you used for ubcd51a2/3, which is also unnecessary.

If you have to rebuild a CAB with a newer version of the files inside it, and you were to use the same method you have been using for years, the modification date should be again the original, correct one.

My request is to rebuild those specific CABs without waiting for a new version of the files inside them. If I find more of those archives, I'll post them (I haven't have the time to check them all).

If your purpose is to check for changed files, binary checksums IMHO is the only reliable way to do it. And there are no lack of tools and means to help with the task.

You just mentioned the main reason for my request. For a user to compare the files using checksums, there are cases where several layers of expanding archives are needed. It takes time to expand several layers, HDD space, run checksums on many files, make a list of comparison and filter the differences.

(NOTE: I "can't" just use 7-zip to get into several layers and expand only one file. I mean, 7-zip (and other tools) indeed allows this functionality, but expanding only one file or only the last layer is not enough for the full comparison.)

In contrast, if the CAB is as it is suppose to be, many file managers will do the comparison job trustworthy enough. A file manager is capable of comparing file names, dates, file sizes, folder structures... and give either the similarities or the differences.

Having the complete ISO checksum, and running once a security tool on the complete ISO is enough from a security point of view. I am not trying to check the files for security reasons, hence comparing with a file manager is enough.

If the file manager comparison method shows a different CAB (or any file for that matter), I can check *it* so to answer the question "Hmm, What was changed here?" or questions alike. I don't need to fully expand *all* the layers of archives in UBCD and check/compare each and every file.

If a CAB was modified, I use a file manager to explore it, or I expand that specific CAB and compare it to the original file downloaded from the producer of that tool.

By changing the correct modification date, the CABs' checksums change too, making the comparison steps MUCH more complicated and MUCH more time consuming.

How do you think I found the syslinux-related files that were not correctly updated in ubcd51a1? Other versions/programs (like diskcopy for example) that had some version inconsistency, or that had unnecessary files included, were discovered using the modification date as first clue.

For syslinux-related files, the first clue was the modification date. Only after that first clue, I checked the specific checksums, compare files with several different syslinux versions...

Moreover, not all the programs included in UBCD are listed somewhere. And there is no list of the versions included in the development releases of UBCD, other than the first post of each topic (which is not always correct nor complete). So, if I want to confirm the included version of some program, and compare it to the original current download of that program from its producer, the modification dates are, again, my first clue.

If the program is the same, the functions are the same, so there is no "absolutely critical" condition here. But having the correct modification date makes several "jobs" MUCH, MUCH more simple and MUCH, MUCH less time consuming.

By rebuilding once those CABs I mentioned, all those tasks are simplified for every future release.

Considering that stable versions of UBCD are released not-so-often, having the possibility to fast-check a file version using its modification date simplifies future customizations (or manual updates).

[Victor Chew]

Try this: mount both the old and new ISOs (using DaemonTools or something), then issue:

Code: Select all

diff -rq d:\ e:\

where "d:" and "e:" hold the old and new ISOs respectively.

[ady]

Try this: mount both the old and new ISOs (using DaemonTools or something), then issue:

Code: Select all

diff -rq d:\ e:\

where "d:" and "e:" hold the old and new ISOs respectively.

I would at least try it (before saying anything else about the dates or the differences), but I don't know what are you talking about.

Under Windows command line, there are, by default, tools for comparing text, binaries and folder structures, but I don't remember "diff".

In addition to the default tools, there are many freeware/shareware tools for that, and I have several of those tools in my system, including file managers.

If you could be more specific or give more info about it, I'll try/text/check "diff".

[ady]

Try this: mount both the old and new ISOs (using DaemonTools or something), then issue:

Code: Select all

diff -rq d:\ e:\

where "d:" and "e:" hold the old and new ISOs respectively.

Since I normally use Windows, I tried it using a VM of PartedMagic.

The result is both, less informative than I can do with the type of tools I mentioned before, and also almost useless for the specific goal.

A) As I already said, several layers of expansions/extractions are needed, and "diff" can't do it.

B) Once a modification date is changed, the archive is changed, even if the binary is the same. For example, compare the file:

Code: Select all

fdubcd.iso.gz -> fdubcd.iso -> fdubcd.img -> LEVEL3 -> AUTORUN3.CAB -> bin -> ubcd.bat

of all the development versions of ubcd51xx, and their modification dates.

The file is the same, but since the modification date was changed, the archive (autorun3.cab) is not the same.

This means that I have to find the difference, both binary and "metadata" (not technically correct, but to call it somehow).
The same would happen with lowercase/uppercase changes. All this is completely unnecessary.

C) The most important problem when using "diff" for this issue (or an equivalent tool under Windows, which I have several of them), is that the comparison is not only against a previous version/release of UBCD, but with the download of the original producer of each tool included in UBCD.

For this point, I can mention again Syslinux and DiskCopy, or add several of the more-than-20 tools I have compared before so to update them. And what about the files that were part of some CAB or some ISO that I mentioned that they were not necessary in UBCD, so they can be excluded?

All those examples started by comparing the original modification dates with those in UBCD.

The modification dates of files like "mdiskchk.com", "eltorito.sys", "shsucdx.com", "more.com/more.exe", "sys.com", and others were/are the first clue that something might be improved, or updated, or that was not updated when it should had (like some of the syslinux-related files). A binary comparison of the first layer of archives is not going to make it easy nor simple nor fast.

Instead, the modification date "is there". I can see it almost everywhere, without even the need to run a comparison first. Filtering by "modification date" also minimizes (a lot) the task.

D)Lastly, I'll give you the counter part. Say you changed the modification date of a file to 2011JUN28, but the original is from 2009. The binary might or might not be the same. For simple curiosity, if not for other valid reasons, the difference will make a user compare it to the original file (from the original producer, not from previous UBCD). "Is there a new version available? Is there any change? Maybe not, but why a different modification date? Is there something I'm not seeing? Was the original package tampered with?".

Of course, this is not 100% accurate, and is not going to happen every time and with every user. But there is no valid reason to make the change anyway.

Using the correct modification dates "is the correct thing to do", and I say it technically speaking.


PS:

Reason is because mod dates can be changed too easily, including something as trivial as changing the filenames to uppercase.

I mentioned this in a previous post of this topic, but I just want to make it clear enough. It is not accurate that “any simple” action can change the modification date. Changing the name, with uppercase, lowercase, completely or partially changed, or moving the file to a different location... The “access date” might change, but not the modification date. Using normal methods/actions, the modification date should not change.

[ady]

Intel Processor Identification Utility v.4.32 was released.

[Victor Chew]

Intel Processor Identification Utility v.4.32 was released.

Noted. Thanks!

If you could be more specific or give more info about it, I'll try/text/check "diff".

You can get "diff" from here:

http://gnuwin32.sourceforge.net/packages/diffutils.htm

the comparison is not only against a previous version/release of UBCD, but with the download of the original producer of each tool included in UBCD.

7Zip can help extract all the CABs to their own individual directories with two mouse clicks. After that it's a simple case of using "diff" or an equivalent tool to check for differences against another folder with the original binaries (in similarly-named subdirectories).

[ady]

7Zip can help extract all the CABs to their own individual directories with two mouse clicks. After that it's a simple case of using "diff" or an equivalent tool to check for differences against another folder with the original binaries (in similarly-named subdirectories).

That's not usable for all cases, as I already posted (with examples).

I don't even understand why it should be needed. It's not.

I'll give you a clear basic example. Astra was just updated to version 5.5.0 in UBCD. I download the original zip, expand it, make a cab. The result is a cab with the original modification dates. It takes about 5 minutes (or less). I see no reason to find a cab of Astra with different modification dates included in UBCD.

If I see the same modification date, I have no reason to doubt about the version (of Astra) included in UBCD. This type of data (modification date) does NOT require from the user to extract anything. Not even using one click with 7-zip. No need to extra HDD space for each and every archive (cab, gz, img, iso...). No need to extract several layers (not "parallel" layers, as your example, and not "serial" layers, which is even more time consuming).

Any modern file manager can show you modification dates, flat views and automatic comparison. Why should anyone would need to expand anything? Why you would create the need to compare using checksums, when there is no real need?

Moreover, I see absolutely no positive aspect of this change. That's how it was before, and I see no reason to change it.

How is it that the Astra cab turns to have files with a different modification date other than the original? What would be the purpose? Why would anyone leave it with the incorrect modification date? What exactly turned those files to have a different modification date other than the original?

Victor, I know that this is in your hands, but I can't understand the logic of this. I can't see *any* reason to leave this specific archives containing files with a different modification date; while having the correct modification date has only positive consequences. I can't see any reason not to correct it and to avoid the problem in the future.

[ady]

From http://www.freedos.org

New Freedos kernel v. 2040, with new kernel.sys and sys.com (and others) was released. Versions for all 8086 and for 386+, with 16 and 32 bits. Maybe there is a way to give different kernels for FDUBCD?

In addition, a new beta for Freedos is available. This should be an opportunity to find new versions of programs to update UBCD, or programs that are replacing older ones not maintained anymore. It could be added to the initial menu too, as a new option, so to help test (and report) this new Freedos beta.

[Victor Chew]

New Freedos kernel v. 2040, with new kernel.sys and sys.com (and others) was released. Versions for all 8086 and for 386+, with 16 and 32 bits. Maybe there is a way to give different kernels for FDUBCD?

Thanks! I am subscribed to their RSS, so I have received this news.

Victor, I know that this is in your hands, but I can't understand the logic of this. I can't see *any* reason to leave this specific archives containing files with a different modification date; while having the correct modification date has only positive consequences. I can't see any reason not to correct it and to avoid the problem in the future.

With regards to your ASTRA example, I don't really know what changed the timestamp. That's the thing. It's incredibly easy to change the timestamp. So am I now supposed to spend countless hours trying to figure out which software on my system has updated the timestamp of that file, and why it has done so? Or am I supposed to spend time "fixing" any differences in timestamps that you find, even when the files are binary identical?

I know, in an ideal world, the timestamps should match, you get what you want, and both of us will be happy. But this is not an ideal world, and we both have limited time and resources to work on a specific number of activities. I am just not prepared to take on the additional work of assuring that timestamps of files included in UBCD match those from the apps' websites when they are already binary identical.

Frankly, the % of users who will checking UBCD against downloads from the apps' websites are in the low minority. And for those who really want to take on this task, surely a binary comparison is more thorough and prudent than comparing timestamps?

[Icecube]

Parted Magic 6.3 is released.

The i486 version supports also very old CPUs (or CPUs with a limited instruction set).