UBCD V5.2 discussion

Discussion/announcements about test/beta releases of UBCD will be posted here.

Moderators: Icecube, StopSpazzing

Message
Author
ady
Posts: 832
Joined: Sat May 08, 2010 5:26 am

Re: UBCD V5.2 discussion

#41 Post by ady » Sun Dec 02, 2012 8:05 am

Let's try to maintain the posts on-topic.

Anyway, there is no need to be so picky with a simple link :P ; it is OK to post a link in code tags so to copy it manually.

Code: Select all

http://omniboot.at/images/[base]/amemtest.img.gz
In theory, you could use something similar to:

Code: Select all

[url]http://omniboot.at/images/[base]/amemtest.img.gz[/url]
or

Code: Select all

[noparse][/noparse]
and other tricks, but the specific version of the forum board software (phpBB in this case) should be able to support those characters, or should know how to parse the equivalent specific html code, which is very frequently not the case.

So:
1_ Avoid using "special" characters in urls if at all possible.
2_ Avoid posting temporal links (use "code" tags instead).
3_ If #1 is not possible, use “code” tags.

If really needed, for further discussion about it please open a topic in the chat subforum.

Now, please, let's focus this topic on UBCD V5.2 development discussion 8) .

ady
Posts: 832
Joined: Sat May 08, 2010 5:26 am

Re: UBCD V5.2 discussion

#42 Post by ady » Sun Dec 02, 2012 11:43 am

_ Boot menu -> Others -> Why the repeated FDUBCD and PMagic boot entries?

_ BIOS -> KEYDisk and CMOSPWD seem to have "incorrect" help texts.

_ Change the entries that have:

Code: Select all

  LINUX /pmagic/bzImage (merssene, stress...)
to:

Code: Select all

  COM32 linux.c32 /pmagic/bzImage
and add "linux.c32" to "/boot/syslinux/".

OR to:

Code: Select all

  COM32 /pmagic/boot/syslinux/linux.c32 /pmagic/bzImage
(without the need to add "linux.c32" to "/boot/syslinux/", but adds one more “cross-reference” between pmagic and ubcd directories).

_ Is vesamenu.c32 needed in UBCD5.2?

_ Request: In " ./ubcd/menus/syslinux/ " please change " pmagic1.hlp " and " pmagic2.hlp " to " pmagic8.txt " and " pmagic9.txt " respectively.

Then in " main.cfg " please change " F1 pmagic1.hlp " and " F2 pmagic2.hlp " to " F8 pmagic8.txt " and " F9 pmagic9.txt " respectively.


_ dban.iso and dban.iso.gz (deja vu)?

_ In

Code: Select all

./ubcd/tools/win32/mkfdubcd.cmd
-> line 35,

change:

Code: Select all

del "%a1%\boot\isolinux\boot.catalog" 2> NUL
to:

Code: Select all

del "%a1%\boot.catalog" 2> NUL
for fdubcd.img in ubcd52.

_ ubcd2iso.cmd , line 58, what's %UBCD2ISO_ARGS% for? (It comes also from ubcd2iso.sh.)


_ Please update

Code: Select all

 ./ubcd/tools/win32/unxutils/bin/xz.exe
to latest version (5.0.4 ATM).

_ In

Code: Select all

./ubcd/tools/linux/readme.txt
-> line 4, correct typo to "readme".


_ fdubcd.iso -> fdubcd.img -> dosapps -> ubcd.ini:
hddera33 command == hdderase command.
Couldn't this be a problem when all cabs are initially expanded?
I think the filename "hdderase.exe" in hddera33.cab should be changed to avoid potential overwriting. Am I wrong?


_ I noticed that inside fdubcd.img 52a1, the file names are not uppercase as they used to be (uppercase is the normal standard DOS 8.3 format), so lowercase is (unnecessarily) using long file names support, which potentially occupies more space and it's harder to read.

_ What's ettool.com for?

_ Which exact version of the FreeDOS kernel is being used in fdubcd52a1?

I have not finished testing, so more comments may come in the next days...

Victor Chew
Posts: 1368
Joined: Mon Feb 21, 2005 10:59 pm
Contact:

Re: UBCD V5.2 discussion

#43 Post by Victor Chew » Mon Dec 03, 2012 8:08 pm

edit: as of removing Alegr Memtest: I solved the problem with incompatibility with FD-UBCD by creating a separate image.
Thanks! Tested and added to 5.2a2.
Yeah, Parted Magic 11-30 has been released two days ago.
Will update in 5.2a2.
Please differentiate between "updates" and "ports" and "forks". xosl 1.1.5 should be kept, whether others are included or not.
I will include both in 5.2a2. Based on my research, it seems XOSL-OW may have its problems too with certain PC hardware, so including both will ensure the widest range of hardware is supported.
I believe this is a mistake. SG2D doesn't support grub legacy. Grub2 is completely different than grub legacy. It is correct that SGD is no longer developed, but grub legacy is still in use. There are alternatives for rescuing grub legacy systems, but they are MUCH bigger in size than SGD. Please maintain SGD included in UBCD.
OK, will reinstate SGD in a2.
FDUBCD can be started in several "modes", including customizing each startup line with F8. So I don't understand the reason not to include AleGr as it was before.
FDUBCD requires some form of HIMEM.SYS to be installed, otherwise certain modules will refuse to work subsequently. If you boot in "Clean" mode, you will have no access to the CDROM drive and the toolchain required to identify/extract the CAB files. Hence, having its own boot image probably makes the most sense.
Besides that 1 report, can someone else confirm (replicate) this problem?
Tested on VMWare and the two laptops that I have access to, with the same problem.
It should be noted that 4.2a3 is an ALPHA version only and was never finished. The previous version is STABLE. The program is "too powerful" to be "messing around" with it.
I did some Googling and didn't find anyone complaining about data destroying bug in 4.2a3. 4.2a3 is the LAST version that the author deemed acceptable to put on his website with a clear message that there will be no further development. I think that says a lot.
Perhaps you could include pcisniffer.pdf from Miray Software's website. You didn't include it in UBCD 5.1.1.
Will do.

Victor Chew
Posts: 1368
Joined: Mon Feb 21, 2005 10:59 pm
Contact:

Re: UBCD V5.2 discussion

#44 Post by Victor Chew » Mon Dec 03, 2012 8:41 pm

_ Boot menu -> Others -> Why the repeated FDUBCD and PMagic boot entries?
Good catch! Will be fixed in a2.
_ BIOS -> KEYDisk and CMOSPWD seem to have "incorrect" help texts.
How so? Seems to be correct.
COM32 linux.c32 /pmagic/bzImage
OK. Will do.
_ Is vesamenu.c32 needed in UBCD5.2?
Nope. Removed.
_ Request: In " ./ubcd/menus/syslinux/ " please change " pmagic1.hlp " and " pmagic2.hlp " to " pmagic8.txt " and " pmagic9.txt " respectively.
Rationale for doing so? :roll:
_ dban.iso and dban.iso.gz (deja vu)?
Fixed.
Change: del "%a1%\boot\isolinux\boot.catalog" 2> NUL
Done.
_ ubcd2iso.cmd , line 58, what's %UBCD2ISO_ARGS% for? (It comes also from ubcd2iso.sh.)
Will be ignored by normal user. But useful for advanced user to pass args to mkisofs without editing the script. For example, I use it to make mkisofs ignore certain directories ("website") when generating the alpha ISO image.
Please update: ./ubcd/tools/win32/unxutils/bin/xz.exe
Done.
-> line 4, correct typo to "readme".
Done.
Couldn't this be a problem when all cabs are initially expanded? I think the filename "hdderase.exe" in hddera33.cab should be changed to avoid potential overwriting. Am I wrong?
No a problem. The files are expanded to different directories, so there will be two "hdderase.exe", but in different directories.
What's ettool.com for?
"ettool.com" and "etdump.com" can be found here. They are for debugging problems related to eltorito.sys. I included them so as to make it easier for us to debug the CDROM problem under grub4dos. In the next release, I will move "ettool.com" to "bin" (where etdump.com) can be found.
Which exact version of the FreeDOS kernel is being used in fdubcd52a1?
The latest "2040".

Victor Chew
Posts: 1368
Joined: Mon Feb 21, 2005 10:59 pm
Contact:

Re: UBCD V5.2 discussion

#45 Post by Victor Chew » Mon Dec 03, 2012 10:13 pm

About 100 different keyboards compared to about 20? Just have a look at /FREEDOS/PACKAGES/BASE/KEYBX.ZIP.
Bad news. It will be quite difficult to replace mkeyb with keyb in FD11. The two programs are just too different. It will require the current keyboard cab to be redone from scratch.

ady
Posts: 832
Joined: Sat May 08, 2010 5:26 am

Re: UBCD V5.2 discussion

#46 Post by ady » Tue Dec 04, 2012 2:19 am

Victor Chew wrote:
_ BIOS -> KEYDisk and CMOSPWD seem to have "incorrect" help texts.
How so? Seems to be correct.
It just "sounded" strange to see the link to CMOSPwd in KeyDisk (which has its own page too) but not in the CMOSPwd entry, that's all. Since you don't usually add the links to the help text... Not at all a big issue, or not an issue at all :).
_ Request: In " ./ubcd/menus/syslinux/ " please change " pmagic1.hlp " and " pmagic2.hlp " to " pmagic8.txt " and " pmagic9.txt " respectively.
Rationale for doing so? :roll:
The hlp file name extension under Windows makes unnecessarily "complicated" to read or edit the content of those files. Thus the change to txt.

About F8 and F9, it would leave the more usual/common F1-F7 for (future) UBCD itself (or for customizations), instead of using them for pmagic. BTW, pmagic has its own F1-F12 help files too. I could had also suggested F11-F12, but I'd rather avoid F10-F12 if F1-F9 are available.
_ ubcd2iso.cmd , line 58, what's %UBCD2ISO_ARGS% for? (It comes also from ubcd2iso.sh.)
Will be ignored by normal user. But useful for advanced user to pass args to mkisofs without editing the script. For example, I use it to make mkisofs ignore certain directories ("website") when generating the alpha ISO image.
Could you please add this as REM comment in ":_help" (Usage) in the script? An example in the script in ":_help" (Example) would be welcomed too (I think as REM would be enough).
Which exact version of the FreeDOS kernel is being used in fdubcd52a1?
The latest "2040".
Any reason not to use 2041?

TIA,
Ady.

Don Manuel
Posts: 34
Joined: Mon Nov 19, 2012 11:18 pm

Re: UBCD V5.2 discussion

#47 Post by Don Manuel » Tue Dec 04, 2012 3:16 am

Victor Chew wrote:
About 100 different keyboards compared to about 20? Just have a look at /FREEDOS/PACKAGES/BASE/KEYBX.ZIP.
Bad news. It will be quite difficult to replace mkeyb with keyb in FD11. The two programs are just too different. It will require the current keyboard cab to be redone from scratch.
Well, I am not really surprised, if it was a short hack as integrating the kblang= parameter I would have offered yet my result instead of asking you. Btw, will you use this modification to the keybrd.cab (ntegrating the kblang= parameter) that I made, just in case somebody else would also like to make use of it - in the official release? I mean, not because it would save me some minutes each update ;)

Explorer09
Posts: 178
Joined: Fri Jun 17, 2011 11:23 pm

Re: UBCD V5.2 discussion

#48 Post by Explorer09 » Tue Dec 04, 2012 4:15 pm

ady wrote: The hlp file name extension under Windows makes unnecessarily "complicated" to read or edit the content of those files. Thus the change to txt.
Those two files are not pure text files. There are two control characters inside when decoded in ASCII. FF (0x0c) and SI (0x0f)
Are you sure there will be no problem editing them in Windows' Notepad?

ady
Posts: 832
Joined: Sat May 08, 2010 5:26 am

Re: UBCD V5.2 discussion

#49 Post by ady » Wed Dec 05, 2012 12:26 am

Explorer09 wrote:
ady wrote: The hlp file name extension under Windows makes unnecessarily "complicated" to read or edit the content of those files. Thus the change to txt.
Those two files are not pure text files. There are two control characters inside when decoded in ASCII. FF (0x0c) and SI (0x0f)
Are you sure there will be no problem editing them in Windows' Notepad?
Yes, I am sure they can be edited with any text editor. In fact, they can be edited almost exclusively by text editors. You can also generate a new simple text file and display it with F1-F12 (and there are other alternatives too) from the Syslinux boot menu.

I wouldn't get here into the details of (so-called in Syslinux) DISPLAY files format, so to maintain the discussion on-topic. If there is interest in adding help files (F1 - F12 and other methods) to UBCD boot menu, or to discuss this specific suggested change, lets open a new topic just for it. Just let me know, or start it and I'll gladly reply :).

Victor Chew
Posts: 1368
Joined: Mon Feb 21, 2005 10:59 pm
Contact:

Re: UBCD V5.2 discussion

#50 Post by Victor Chew » Wed Dec 05, 2012 12:32 pm

Btw, will you use this modification to the keybrd.cab (ntegrating the kblang= parameter) that I made, just in case somebody else would also like to make use of it - in the official release? I mean, not because it would save me some minutes each update ;)
Sure!

Don Manuel
Posts: 34
Joined: Mon Nov 19, 2012 11:18 pm

Re: UBCD V5.2 discussion

#51 Post by Don Manuel » Wed Dec 05, 2012 12:53 pm

Great, thanks :)

Victor Chew
Posts: 1368
Joined: Mon Feb 21, 2005 10:59 pm
Contact:

Re: UBCD V5.2 discussion

#52 Post by Victor Chew » Wed Dec 05, 2012 12:53 pm

The hlp file name extension under Windows makes unnecessarily "complicated" to read or edit the content of those files. Thus the change to txt.
OK. Sure.
About F8 and F9, it would leave the more usual/common F1-F7 for (future) UBCD itself (or for customizations), instead of using them for pmagic. BTW, pmagic has its own F1-F12 help files too. I could had also suggested F11-F12, but I'd rather avoid F10-F12 if F1-F9 are available.
F1 is typically reserved for "Help", so I think it makes more sense to preserve F1-F2.
Any reason not to use 2041?
I was using the kernel from FreeDOS 1.1, which is 2040. I will check out 2041. Thanks!

ady
Posts: 832
Joined: Sat May 08, 2010 5:26 am

Re: UBCD V5.2 discussion

#53 Post by ady » Thu Dec 06, 2012 2:14 am

Victor Chew wrote:
About F8 and F9, it would leave the more usual/common F1-F7 for (future) UBCD itself (or for customizations), instead of using them for pmagic. BTW, pmagic has its own F1-F12 help files too. I could had also suggested F11-F12, but I'd rather avoid F10-F12 if F1-F9 are available.
F1 is typically reserved for "Help", so I think it makes more sense to preserve F1-F2.
That's exactly my point. UBCD's help should be F1. The boot entry for PMagic is the only place that F1 is mentioned to the user. Change that line to F8 (together with the changes I already mentioned) and the help for pmagic will use F8-F9, leaving F1-F7 for UBCD help files (that could be developed for future releases after 5.2 gets out - no rush).

Additionally, many multiboot tools and distros use also F1-Fn, so leaving them clean makes it easier for the user to combine UBCD with them. If F1 was used for UBCD's help, that would be more reasonable (as pmagic itself uses F1 too).

Anyway, this is just a very minor detail.

On another issue, what's the need for fdubcd -> ETC -> config.sys and kernel.sys ? I mean, why in that directory?

Victor Chew
Posts: 1368
Joined: Mon Feb 21, 2005 10:59 pm
Contact:

Re: UBCD V5.2 discussion

#54 Post by Victor Chew » Thu Dec 06, 2012 1:29 pm

On another issue, what's the need for fdubcd -> ETC -> config.sys and kernel.sys ? I mean, why in that directory?
Arrgh... my stupid mistake. Will be fixed in a2.

ady
Posts: 832
Joined: Sat May 08, 2010 5:26 am

Re: UBCD V5.2 discussion

#55 Post by ady » Fri Dec 07, 2012 1:33 am

Victor,

Would you consider changing DBAN boot entry?

Currently, we have the full ISO, gzipped. But the only file really necessary is the DBAN.BZI file. The size would be about the same (for sure not bigger). Instead of booting it with memdisk -> isolinux, we can just boot it with isolinux directly (as we do with other tools).

The only "con" would be that DBAN.BZI is not an iso/img image, as the rest of the files in the "images" directory.

Ideally, we could use a subdirectory to add all the relevant info (F1-F12, DBAN.BZI, the different boot entries...). If you would rather leave the "images" directory with iso/img images only, we could move it to "/ubcd/boot/" as other tools have been moved in the past.

If you are interested, I could prepare the relevant isolinux files and updated boot entries. Let me know.

The Piney
Posts: 370
Joined: Mon Apr 30, 2007 11:06 am
Location: FL

Re: UBCD V5.2 discussion

#56 Post by The Piney » Sat Dec 08, 2012 9:22 pm

Victor Chew wrote:
So in fact, by skipping the antivirus databases in the original release of UBCD, you save time. I can only see pros, no cons.
OK, point taken. Lemme think about it. I hope the others can chime in on this as well.
I have liked being able to scan a system without internet access which requires having databases, but I could just download those to a flash drive before I go to the system. The saved space by NOT including the databases would allow for adding other tools, distros, etc.

ady
Posts: 832
Joined: Sat May 08, 2010 5:26 am

Re: UBCD V5.2 discussion

#57 Post by ady » Sun Dec 09, 2012 7:53 am

The Piney wrote:
Victor Chew wrote:
So in fact, by skipping the antivirus databases in the original release of UBCD, you save time. I can only see pros, no cons.
OK, point taken. Lemme think about it. I hope the others can chime in on this as well.
I have liked being able to scan a system without internet access which requires having databases, but I could just download those to a flash drive before I go to the system. The saved space by NOT including the databases would allow for adding other tools, distros, etc.
@The Piney,

If UBCD would get out today with current databases, and you were going to use the same antivirus database 6 months from now, the result of such scan would not be really relevant in most cases. It gives a false sense of security, which can potentially be even worse than not scanning at all. So you would need to download updated databases again anyway. Hence, the initial databases are a waste of space and bandwidth (except for the very first short period after UBCD gets out).

Victor Chew
Posts: 1368
Joined: Mon Feb 21, 2005 10:59 pm
Contact:

Re: UBCD V5.2 discussion

#58 Post by Victor Chew » Mon Dec 10, 2012 10:25 pm

Currently, we have the full ISO, gzipped. But the only file really necessary is the DBAN.BZI file. The size would be about the same (for sure not bigger). Instead of booting it with memdisk -> isolinux, we can just boot it with isolinux directly (as we do with other tools).
I prefer the current approach.

1) If we load dban.bzi directly, we miss the main menu
2) If we chainload isolinux.cfg, that won't work with grub4dos

Victor Chew
Posts: 1368
Joined: Mon Feb 21, 2005 10:59 pm
Contact:

Re: UBCD V5.2 discussion

#59 Post by Victor Chew » Mon Dec 10, 2012 10:27 pm

If UBCD would get out today with current databases, and you were going to use the same antivirus database 6 months from now, the result of such scan would not be really relevant in most cases. It gives a false sense of security, which can potentially be even worse than not scanning at all. So you would need to download updated databases again anyway. Hence, the initial databases are a waste of space and bandwidth (except for the very first short period after UBCD gets out).
I will release a version without the antivirus defs for those who want it that way. For the default version, I would still prefer something that works out of the box.

ady
Posts: 832
Joined: Sat May 08, 2010 5:26 am

Re: UBCD V5.2 discussion

#60 Post by ady » Mon Dec 10, 2012 11:33 pm

Victor Chew wrote: I prefer the current approach.

1) If we load dban.bzi directly, we miss the main menu
2) If we chainload isolinux.cfg, that won't work with grub4dos
I respect your preference for the current approach, but just to be clear, I don't understand the 2 points, specially the first one.

The "official" dban image uses the boot prompt. In my customized UBCD I use UBCD main boot menu -> dban boot menu (instead of cli). So I don't understand what you meant with your first point.

Regarding grub4dos, I guess you mean that the script to translate from syslinux to grub4dos boot menu would require a custom part just for dban. Is that it?
Victor Chew wrote: I will release a version without the antivirus defs for those who want it that way. For the default version, I would still prefer something that works out of the box.
Nah :P . Users' tendency will be to download the default bigger ISO image, and those that want to use updated antivirus definitions (should be anyone and everyone interested in these tools) will update them anyway.

My argument is about wasting less time, less bandwidth and less space, also reducing the "false security". With 2 alternatives, the result will be exactly the opposite, both for users and for you. If you are going to provide a download that already includes the antivirus databases, then IMO just provide that one and nothing else.

Post Reply