UBCD V5.3.5 available for download

[Victor Chew]

UBCD V5.3.5 is available for download:

You can grab it via:
- torrent (immediately)
- rysnc (to update an existing installation)
- normal download at the download page (to come later after mirror owners have updated)

Changelog:

- I made an unfortunate mistake in V5.3.4 whereby both ASTRA and INTELPIU within DOSAPPS/FDUBCD were not updated as they should be. Both apps have been properly updated in this release. Thanks to ady for pointing out the error to me in a PM.
- Updated Intel Processor Identification Utility to V5.10. Thanks to ady for the update.
- Added Partition Explorer V1.01. Thanks to ady for the suggestion.
- Updated Partition Saving to V4.20. Thanks to ady for the update.
- Updated ASTRA to V6.30. Thanks to ady for the update.
- Added syslinux64 for execution on x64 Linux kernels. Updated "ubcd/tools/linux/ubcd2usb/readme.txt" to clarify/fix errors based on user feedback.
- To increase capacity (so that Partition Explorer can be accommodated), FDUBCD is now based on the 50MB image file located at http://bootcd.narod.ru/images.htm. Also a new build process is now used to ensure the image is always rebuilt from scratch, which minimizes mismatches and errors.

[Victor Chew]

Hi Victor,

In the UBCD 5.3.5 announcement:

_ There seems to be a typo, "FBCD" -> "fdubcd" ?

_ The download link for the torrent is wrong. Probably it should point to the main download page, or to the 5.3.5 torrent with an additional link to the download page.

TIA,
Ady.

Both issues corrected. Thanks!

[ady]

Regarding ubcd535 -> ubcd/tools/linux/ubcd2usb/readme.txt

_ I would suggest changing from:
"You cannot run syslinux"

to:
"You cannot run the syslinux installer"

so to avoid misinterpretations between "you cannot execute the installer from..." and "you cannot boot your drive using the SYSLINUX bootloader".

_ I would also suggest changing:
"1. Remove your USB thumb drive from your USB port if you already attached it."

so to include unmounting it first (if needed).


_ The note:
" NOTE: If you are running x64 kernel instead of x86, you will need to use syslinux64
instead of syslinux. Alternatively, install syslinux using the package manager supported
by your distribution. The last resort is to download the syslinux tarball and compile
from scratch."

seems to me inaccurate.

The need for "syslinux64" is only relevant for a "pure" 64-bit OS. When some form of "multilib*" (or equivalent) is present, the 32-bit syslinux installers are usable in a 64-bit OS.

BTW, I am curious about the origin of the "syslinux64" installer. Where is it coming from (upstream / package / patches / version)?

Additionally, the "last resort" suggestion could be somewhat confusing to users. The "tarball" might refer to the source package for the specific distro, or may refer to the official upstream archives from kernel.org. In the latter case, they already include binaries too. But, whichever the case, executing one version of the syslinux installer and using a different version (or, in some cases, same version from different package) of c32 files will most probably produce some version mismatch error.

Whenever a SYSLINUX installer is used, the c32 modules to be used shall come from the same exact package.

I wonder whether there should be some comment about searching for auxiliary tools as alternative installation method, as we have been asked (and answered) recently here in the forum regarding the installation of UBCDLive under Linux. See "Alternate ways of writing UBCDLive V0.2.2b ISO to USB?" as example (but beware of the specific instructions in that topic, as they are not exactly valid "as-is" for UBCD).


_ IMHO, the suggested options for the syslinux installer should be modified. I think that using the "-s" parameter should only be mentioned as a second (or third) alternative, in case the normal command line (without "-s") doesn't succeed (in booting the device with SYSLINUX).

Finally, the "Additional resources" link is outdated and has some flaws. I am not sure it is wise to add it, specially now that the "readme" content which that linked article is referring to has been modified / updated. The content of that article is no longer relevant (at all), so it would probably cause more confusion than anything else.

[Victor Chew]

The need for "syslinux64" is only relevant for a "pure" 64-bit OS. When some form of "multilib*" (or equivalent) is present, the 32-bit syslinux installers are usable in a 64-bit OS.

BTW, I am curious about the origin of the "syslinux64" installer. Where is it coming from (upstream / package / patches / version)?

I was testing the instructions under a 64-bit installation of Debian Wheezy, where the included 32-bit syslinux didn't work.

The included 64-bit syslinux64 was compiled on the same system from the original syslinux 4.0.7 source tarball, so it should have no conflicts with the included c32 modules.

I wonder whether there should be some comment about searching for auxiliary tools as alternative installation method, as we have been asked (and answered) recently here in the forum regarding the installation of UBCDLive under Linux. See "Alternate ways of writing UBCDLive V0.2.2b ISO to USB?" as example (but beware of the specific instructions in that topic, as they are not exactly valid "as-is" for UBCD).

I will include multibootusb as a possible alternative in the instructions as mentioned in that thread. (I will also be testing multibootusb on UBCDLive later when I have time. I think it will probably work since it is Debian-based.)

Finally, the "Additional resources" link is outdated and has some flaws.

I agree that the link provided may be slightly outdated, but I don't see any outright flaw.

Anyways, I will incorporate your suggestions in the instructions for the next release.

[ady]

I wonder whether there should be some comment about searching for auxiliary tools as alternative installation method, as we have been asked (and answered) recently here in the forum regarding the installation of UBCDLive under Linux. See "Alternate ways of writing UBCDLive V0.2.2b ISO to USB?" as example (but beware of the specific instructions in that topic, as they are not exactly valid "as-is" for UBCD).

I will include multibootusb as a possible alternative in the instructions as mentioned in that thread. (I will also be testing multibootusb on UBCDLive later when I have time. I think it will probably work since it is Debian-based.)

In the topic I already linked to, your instructions were already for UBCDLive. My point is the other way around: the instructions you posted are not going to work "as-is" for UBCD5.3.5.iso; they rather need some minimal modification. The reason is that UBCDLive uses a Debian structure for ISOLINUX without improvements, while UBCD uses a structure better suited (with version 4.07 of Syslinux) for multiboot and customizations. In UBCD (not UBCDLive) this includes the usage of absolute paths for the c32 modules in the cfg files, which is the "correct" way to do it, at least for version 4.07 of Syslinux.

If you add specific instructions for auxiliary tools (e.g. multibootusb), I would suggest providing the context (e.g. "performed under Debian Wheezy with version N.M of X tool"). Other context environments (e.g. other distro, other versions...) might have different results (because of different paths in the distro, or the behavior of the auxiliary tool in other environments...).

A different approach could be to add to the "readme" link to a (pinned) topic here in the forum, with instructions and comments. Such topic would be "closed" for comments. You would only update it when needed (by editions with "strike-through" tags, or by additional posts in the same pinned topic), and additional comments / suggestions about it should be posted in other topics, maintaining a clean pinned topic with no "endless discussions and multiple opinions" that would only confuse final users / readers searching for a clear tutorial.

Finally, the "Additional resources" link is outdated and has some flaws.

I agree that the link provided may be slightly outdated, but I don't see any outright flaw.

Anyways, I will incorporate your suggestions in the instructions for the next release.

The article has some flaws, but I really don't want to discuss it here. The other point is much more important: the "readme" has been updated in such a way that the reason for the article to exist in the first place is no longer relevant, and there is no other positive contribution in the article. Moreover, the article is not "generic enough", so Linux users of many distros with newer versions of Syslinux should not follow those instructions. In other words, currently there is no positive contribution in that article, and there are potential negative effects when following its instructions.

Which brings me to one of the most repeated mistakes made by users: the version of the bootloader shall match the exact same version of the c32 modules (and/or, equivalently, state it the other way around too). Another way to express it: there shall be an exact match between the version of the bootloader and the version of the c32 modules. This comment (or similar) should be added to the "readme". Some Linux users will mix the methods, or will miss the usage of the specific installers included in UBCD.

For example (among several other situations), when using the syslinux installer installed in the distro (instead of the one already included in UBCD), the c32 files in UBCD should be replaced with the ones installed in the distro. When correctly following the instructions (i.e. using the installer already included in UBCD), then the c32 modules already used in UBCD should be fine.

Some users take their "working" USB drive and they simply copy over the files from UBCD. This can easily end with a mismatch version error between the version of the bootloader they already have and the c32 modules included in UBCD. This situation is also frequently found when using auxiliary tools (Unetbootin and similar).

These situations are more common than you might think; suffice to read forum posts in any distro's forum, or in mailing lists, or irc, or...

I hope these comments would help to improve the "readme", or at least to some users attempting to install UBCD to a (USB) drive.

[Victor Chew]

In the topic I already linked to, your instructions were already for UBCDLive.

No, my instructions were for UBCD. It was tested with UBCD V5.3.4 under Debian Wheezy with multibootusb_7.5.0-1. By copying the UBCD files to the root of the USB memory stick, there's no path issue at all.

A different approach could be to add to the "readme" link to a (pinned) topic here in the forum, with instructions and comments. Such topic would be "closed" for comments.

OK, will update the readme as such, though I don't think the topic should be "closed". If that's the case, we should be pointing to a tutorial instead. If someone hits a problem, that would be the obvious thread to ask a question.

[ady]

No, my instructions were for UBCD.

OK. The (linked) topic in question was originally about UBCDLive, so perhaps the distinction was not clear enough in that context.

A different approach could be to add to the "readme" link to a (pinned) topic here in the forum, with instructions and comments. Such topic would be "closed" for comments.

OK, will update the readme as such, though I don't think the topic should be "closed". If that's the case, we should be pointing to a tutorial instead. If someone hits a problem, that would be the obvious thread to ask a question.

I don't mean that everything should be in the forum. I still consider the prior comments as being relevant for the readme itself.

Regarding a topic being closed or not, in theory I would agree with you. Unfortunately, users frequently don't care where they post (e.g. an off-topic question in a the Tutorials and HowTos section of the forum ), and instead of a clear help, such topic could easily become "whatever I have currently in my head" .

One reason to suggest a pinned topic instead of a tutorial is because the tutorial web page is frequently not read / seen, according to some (st*pid) posts asking (st*pid and off-topic) questions posted in the forum. Let's not forget the UBCD wiki.

Anyway, for several years the readme for Linux users was not edited. Hopefully some additional corrections / updates and it will be OK for the next several years.

[ady]

For next release:

2015JUN04:
DBAN 2.3.0

[EDIT]
2015Jun19
Intel Processor Identification Utility 5.25 was released.
[/EDIT]

[EDIT2]
2015Aug13
Intel Processor Identification Utility 5.30 was released.
[/EDIT2]

[fryedsoft]

Hdat2 Updated to 5.1

http://www.hdat2.com/

[Victor Chew]

Noted. Thanks!

It's about time I update UBCD again...

[ady]

It's about time I update UBCD again...

In that case, please consider updating:

_ Intel Processor Identification Utility

_ dban

_ miray hdclone



There might be other potential updates (including auxiliary tools, but these *must* be tested for backward compatibility before actually updating them).

Regards,
Ady.

[pic16f84a]

When will there be a new version of UBCD?

[Victor Chew]

I have been procrastinating due to work.

I can't promise, but hopefully I can pick things up in early June when my current project finishes.

[hotlips69]

Memtest86 is miles out of date.
New version at: http://www.memtest86.com/

Memtest86+ hasn't been updated for almost 2 years and maybe a dead project?
Very annoying as I use it all the time, but it has stopped recognising recent motherboard/chipset revisions and I don't know who to contact to ask if it's ever going to be updated again?

[ady]

Memtest86 is miles out of date.
New version at: http://www.memtest86.com/

No, the version included in UBCD is not outdated.

Passmark has only been updating the UEFI-based variant, not the BIOS-based / legacy one.

Considering that almost all tools / programs included in UBCD are for BIOS only, and that UBCD does not include a UEFI-based method to boot (because the included tools cannot be used under UEFI anyway), then including the UEFI-based variant of memtest86.com would only be a complete waste of resources with no advantage for UBCD at all.

[ady]

2016May26

ASTRA for DOS version 6.40 was released.