184 replies to this topic

[fly]

theres nothing wrong.you will see only one entry.
when you install both vista and xp ophcrack . Xboot combines them in to one. hence you will see only one menu entry.
but tables for both vista(/tables/vista_free) and xp (/tables/xp_free_small)are present. so it will work for both Xp vista.

Just as a suggestion, you might want to find a way to note that, as its very confusing....

[Juraj]

This is great program :-)

I think that option for adding multiple versions of iso from one program would be nice.

Also I have suggestion for program g4l (G4L is a hard disk and partition imaging and cloning tool.) http://sourceforge.net/projects/g4l/

And one problem, if I don't empty flash drive and clonezilla is already there and I try add clonezilla again I get this error:



ERROR REPORT (27. 12. 2010 18:29:04)
Please Submit this Error report to developer.
Operating System version :Microsoft Windows NT 6.1.7600.0
.NET Framework version :4.0.30319.1
Error message :
Error occured during adding file Clonezilla, 121 MB, C:\Users\Juraj\Desktop\USB FlashDrive\clonezilla.iso
Error Report :
Log :

7-Zip 9.20 Copyright © 1999-2010 Igor Pavlov 2010-11-18

Processing archive: C:\Users\Juraj\Desktop\USB FlashDrive\clonezilla.iso

file F:\images\clonezilla\filesystem.squashfs
already exists. Overwrite with
live\filesystem.squashfs?
(Y)es / (N)o / (A)lways / (S)kip all / A(u)to rename all / (Q)uit?
ERROR: Can't allocate required memory!

Error Log :

Exit code : 2
List of ISO Files:
Filename = clonezilla.iso ; ISO File = Clonezilla ; File Size = 121 MB
Exception Message :

StackTrace :

[shamurshamur]

This is great program :-)

I think that option for adding multiple versions of iso from one program would be nice.

And one problem, if I don't empty flash drive and clonezilla is already there and I try add clonezilla again I get this error:



ERROR REPORT (27. 12. 2010 18:29:04)
Please Submit this Error report to developer.
Operating System version :Microsoft Windows NT 6.1.7600.0
.NET Framework version :4.0.30319.1
Error message :
Error occured during adding file Clonezilla, 121 MB, C:\Users\Juraj\Desktop\USB FlashDrive\clonezilla.iso
Error Report :
Log :

7-Zip 9.20 Copyright © 1999-2010 Igor Pavlov 2010-11-18

Processing archive: C:\Users\Juraj\Desktop\USB FlashDrive\clonezilla.iso

file F:\images\clonezilla\filesystem.squashfs
already exists. Overwrite with
live\filesystem.squashfs?
(Y)es / (N)o / (A)lways / (S)kip all / A(u)to rename all / (Q)uit?
ERROR: Can't allocate required memory!

Error Log :

Exit code : 2
List of ISO Files:
Filename = clonezilla.iso ; ISO File = Clonezilla ; File Size = 121 MB
Exception Message :

StackTrace :

Hi juraj,
thanks for reporting the bug.this will get fixed in next release
Also in next version i will support multiple version of clonezilla.

Regards.

[mpierce0]

Awesome tool.
ubuntu and ophcrack work perfectly.
works better much better than the pendrivelinux multibooter.
i would like to see support for many more linux distros:

crunchbang
http://crunchbanglin...atler/20101205/

jolicloud
http://www.jolicloud.com/download

puppy arcade
http://scottjarvis.com/page105.htm

fedora
http://fedoraproject.org/en/get-fedora

linux mint
http://www.linuxmint.com/download.php

dsl
http://www.damnsmall...g/download.html

and bactrack
http://www.backtrack....org/downloads/

thanks

[steve6375]

A very small point but the frame in the Edit Multiboot USB window has a typo - Reinstall Bottloader.

I think you should have a Download button on the main Create MultiBoot window - users may miss the fact that you have the download from website feature unless they look in the File menu as the help instructions say to Drag and Drop files - or you could change the help to say 'Use the File - Download menu to find iso files to download and then Drag and Drop iso files blah blah...'

QEMU from USB now works for me (it did not before on Beta 1/2)

Could Xboot have an install option to install Xboot so that we can right-click on an ISO in Windows Explorer and choose 'Boot ISO using Qemu' or 'Add to XBOOT Multiboot'. The first option would mean we could run any ISO from Explorer, the second saves having to find the multiboot drag and drop window when adding many isos to make a single multiboot pen/iso.

Small issues - I ran Qemu on an ISO file but also had the same ISO file in the multiboot menu. Whilst booted using Qemu, I clicked on the MD5 button and it said 'File not found' (because QEMU had it locked) - but the button for MD5 now says 'Wait...' and is greyed out and is still greyed out even after I closed QEMU.

UBCD4WIN.iso was identified as Ultimate Boot CD 4 DOS.
When creating an ISO, it does not tell you the location of the ISO it created or allow you to change the destination (in case you do not have enough room on the selected hard disk volume). A folder destination change button would be good?

[Grinch]

Thanks for such a handy program. I've been looking for something like this for some time now. One thing I would like to see added in the future is the ability to add Floppy images as well. I've still got a bunch of old Dos programs like Quicktech and Spinrite That I cuttenly use EZboot to make cdroms with but I'd like to start using them on a flash drive as well...

Keep up the good work.....

[Juraj]

Hi juraj,
thanks for reporting the bug.this will get fixed in next release
Also in next version i will support multiple version of clonezilla.

Regards.

I tought about multiple versions of iso's in general, in my case Hirens Boot CD

And I agree with Grinch, support for floppy images would be great.

Edited by Juraj, 28 December 2010 - 09:40 PM.

[steve6375]

One thing to be aware of when using Qemu to boot a physical USB drive is that no writes can be made to the USB drive via the BIOS. For instance, if you boot to MS-DOS and type echo.>FRED then type CTRL.C and then DIR you will see that the file FRED is not listed. QEMU does not allow writes to a physical drive. I guess this would also apply to grub4dos commands like dd and the default command, etc.
So you need to test the USB drive on real hardware if you want to test real mode OS's or environments.
If anyone knows a way around this (self-imposed) limitation in QEMU it would be very nice to know! It can be temporarily avoided by using Qemu snapshot ( -s ) but this may cause a problem if loading large non-DOS images so it might not be a good idea to always include the -s option in the Qemu command line?

[steve6375]

To speed up the support of more bootable images, it might help if you could make your app read an ini file (or similar) which contains instructions for XBoot on what to do with the iso/img file. This would mean that end users could edit the ini file and add their own iso files or img files and test it. When finished and fully tested, they could simply send the ini settings to you for acceptance testing and inclusion in the next release. It also means you could distribute new INI files without needing to distribute the whole exe again. This should save you a lot of time and work in the future!
You could also have a 'auto-update' button in Xboot which would update the INI file(s) from the web with the latest version(s).
Just a thought...

[Wonko the Sane]

To speed up the support of more bootable images, it might help if you could make your app read an ini file (or similar) which contains instructions for XBoot on what to do with the iso/img file. This would mean that end users could edit the ini file and add their own iso files or img files and test it. When finished and fully tested, they could simply send the ini settings to you for acceptance testing and inclusion in the next release. It also means you could distribute new INI files without needing to distribute the whole exe again. This should save you a lot of time and work in the future!

Not only.

If the .ini file is "human readable" it can be used by non-XBoot users to find the settings needed for any given distro supported by XBoot.
This would create a "compact" set of useful data to the same effect of the grub4dos "grub4dos, .iso images and (hd32) or (0xFF) mapping" thread:
http://reboot.pro/5041/

This is a common problem with "proprietary" apps: the actual meaningful data is "hidden under the hood", and consequently it is of no or little use to anyone but the users of the specific app, sharing the actual data would be of help for everyone.


Wonko

[shamurshamur]

Not only.

If the .ini file is "human readable" it can be used by non-XBoot users to find the settings needed for any given distro supported by XBoot.
This would create a "compact" set of useful data to the same effect of the grub4dos "grub4dos, .iso images and (hd32) or (0xFF) mapping" thread:
http://reboot.pro/5041/

This is a common problem with "proprietary" apps: the actual meaningful data is "hidden under the hood", and consequently it is of no or little use to anyone but the users of the specific app, sharing the actual data would be of help for everyone.


Wonko

Great idea.
But it will need some generalization of ISO files.And i will need lot of help from members of boot-land to help me developing the model for format of .ini or XML files.

instead of .ini , we could use XML format.it is very powerful then .ini and yet very easy to understand.


using scripts to add ISO files to multiboot usb/iso is same as like making winpe by passing appropriate scripts to script interpretor.
In case of adding softwares to Win PE , we can divide all task in to various categories like
1) registry entries
2) copying some file to a specified path
etc.
and we can write some code to handle each categories of task in the script interpretor.
then script writers can write scripts for a particular software(we want to add to winpe) and pass it to script interpretor , which then execute these scripts.


what about the adding ISO files? Can we categories all task needed to add a ISO file in to definite categories of task like
1) Extracting files from ISO archive and copy them to a specified path
2) appending kernel options ( like iso-scan/filename) to a configuration file of syslinux or grub4dos.
3) hexediting a file .
etc.

first we have to make list of all possible categories of task we will be needing to add ISO files.And then we can write appropriate code to handle each task in script interpretor.

may be you can give me a example of pseudo .ini or xml file , just for starting.

[steve6375]

Maybe you could look at a simple Iso case and a complex case (backtrack or ophcrack?) and list what you do in your code?

presumably you need to recognise the iso file so you have some strings that you match?

e.g. "BT4" "OPH" ??
then you extract contents from the iso or just copy the whole iso over?
then you create menu entries for grub4dos or syslinux?
Do you use external files or create the menu entries from hard coded lines?

If you could list what things you do in your code, then the categories can be worked on?
Could we provide the grub4dos/syslinux menus as text files for instance, or do you need to modify the paths in the menu entries?

Personally I find INI files much more human readable than xml and not everyone has an XML editor/checker?
Not sure if scripts are the right way to go...

e.g.

[Ophcrack 2.3.1]

Type=iso
Strings="Ophcrack-xp-livecd-2.3.1"
Extract=Yes
Destination=%USB%/ophcrack_xp

syslinux_menu=aaaa/nbbbbbb/nccccccc/nddddd
grub4dos_menu=title aaaaa/nbbbbbbb/ncccccc/ndddddd

copyfiles1src=/ophcrack_xp/tables/*.*
copyfiles1dest%USB%/tables/*.*
copyfiles1switches=/e

delfiles1=
deldirs1=

;add more commands here


[next iso/img]


You do not need to use INI file structure/rules. You could make up your own structure e.g.

[iso 1]

Type=iso

(etc.)

[[grub4dos_menu]]
title aaa
bbb
cccc


[[syslinux_menu]]
label aaaa
bbbb
cccc


[iso 2]

etc

[Wonko the Sane]

Great idea.
But it will need some generalization of ISO files.And i will need lot of help from members of boot-land to help me developing the model for format of .ini or XML files.

instead of .ini , we could use XML format.it is very powerful then .ini and yet very easy to understand.

NO.

I mean, you are as always perfectly free to choose the format you prefer as an example you could store this info in a Registry Hive, just like BOOT.INI became the BCD , but XML is NOT "more powerful" than good ol' .INI format and is MUCH less "human readable" (unless of course you also provide a XML parser AND the needed "schema" or whatever).

OT , but JFYI:
http://www.911cd.net...pic=23408&st=21


Very simple example:

[Distro Name]
Name1="GParted Live"
Name2="PCLinuxOS"
...
[GParted Live]
Loader=Syslinux
Version=4.0.3
Config=Main.cfg
Title=label GParted Live
Line1=MENU DEFAULT
Line2=# MENU HIDE
Line3=MENU LABEL GParted Live (Default settings)
Line4=# MENU PASSWD
Line5=kernel /live/vmlinuz1
Line6=append initrd=/live/initrd1.img boot=live username=casper noswap vga=788 ip=frommedia
Line7=TEXT HELP
Line8=* GParted live version: 0.3.6-7. Live version maintainer: Steven Shiau
Line9=* Disclaimer: GParted live comes with ABSOLUTE NO WARRANTY
Line10=ENDTEXT


[PCLinuxOS]
Loader=grub4dos
Version=0.4.4
Config=menu.lst
Title=title PCLinuxOS LiveCD\n * Booting mapped ISO file *
Line1=map --unhook
Line2=map --unmap=0:0xff
Line3=find --set-root --ignore-floppies /pclos.iso
Line4=map --heads=0 --sectors-per-track=0 /pclos.iso (0xff)
Line5=map --hook
Line6=chainloader (0xff)

As an UNrelated (but not much ) note, this app seems a lot like doing more or less the same things, only it does them in AutoIt:
http://old.linuxliveusb.com/


AFAIK we have a number or very similar apps (i.e. things that aim to create a multiboot CD or USB device) using as "base" loaders either grub4dos or GRUB2 or Syslinux/Memdisk/etc., among them:

• XBOOT (here in this same thread)
  
• SARDU (here in boot-land reboot.pro forum)
  
• UNETBOOTIN (here in boot-land reboot.pro forum)
  
• MULTIBOOTISOS http://www.pendrivel...-multiboot-usb/
  
• LINUX LIVE USB CREATOR http://old.linuxliveusb.com/ (previously mentioned)
  
• MULTICD http://multicd.tuxfamily.org/

running either from Windows or Linux, but the final result is still the same: create a set of commands for any of the mentioned loaders to actually boot the specific distro.
Since syntax among the three mentioned "main" loaders is pretty much "translatable" to the other, and the actul "difficult" part is getting the "right" syntax and - if needed - "cheatcodes", the fact that the info on WHAT entries actually each app creates is an "obstacle" to knowledge and a LOT of "duplicated" work.

Maybe we could, at least for Davide Costa - SARDU and "tuxcantfly" - UNETBOOTIN, to talk to the developers and convince them to adopt a "common" .ini (or .xml, or whatever) "base archive" of working entries.


Wonko

[steve6375]

'Consulting' would be OK, but trying to get many people (especially developers/script writers) to agree on the best method will not be easy! I would suggest we invent one for XBoot, perfect it, and then try to get the others to include ini/xml support in their apps once it is working?
The main aim is to be able to get lots of people to submit working ini/xml files for Xboot. That way it is viral and not dependant on the constant attention of the author, especially in a few years time when shamursahmur moves onto other more interesting things than to spend his life modifying Xboot to support backtrack 12 or Windows 14!

[Wonko the Sane]

'Consulting' would be OK, but trying to get many people (especially developers/script writers) to agree on the best method will not be easy! I would suggest we invent one for XBoot, perfect it, and then try to get the others to include ini/xml support in their apps once it is working?
The main aim is to be able to get lots of people to submit working ini/xml files for Xboot. That way it is viral and not dependant on the constant attention of the author, especially in a few years time when shamursahmur moves onto other more interesting things than to spend his life modifying Xboot to support backtrack 12 or Windows 14!

Yep.

But again, the "main" thing is to have something easily "human readable" and "easily parsable" by *any* OS with *any* scripting engine or programming language, IMNSHO another reason to adopt the simplest (.ini) available "interchange format".

This way even those that won't use ANY of the listed apps will have access to the "knowledge" shared by the XBOOT Author and by helping members.


Wonko

[shamurshamur]

Yep.

But again, the "main" thing is to have something easily "human readable" and "easily parsable" by *any* OS with *any* scripting engine or programming language, IMNSHO another reason to adopt the simplest (.ini) available "interchange format".

This way even those that won't use ANY of the listed apps will have access to the "knowledge" shared by the XBOOT Author and by helping members.


Wonko

choosing format is not a big problem here. as both .ini and XMl can be converted in to each other easily.so suppose if someone writes script in .ini we can convert that to XML later or vice-versa.

we can choose the .ini format , i have no problem with it.

important problem is developing a model for scripts used to add ISO to multiboot usb/iso , as it is quite different from the model of scripts used for adding software to winpe.

[Wonko the Sane]

important problem is developing a model for scripts used to add ISO to multiboot usb/iso , as it is quite different from the model of scripts used for adding software to winpe.

No, it isn't.

I mean, if you want to make a script of some kind, you can use any of the available scripting engines (batch, vb, Winbuilder, etc.).

I was talking about the actual settings for the loader, THESE are the "difficult" part (that changes often and that is very hard to keep updated).
The actual scripting commands revolve about:

• download xy.iso from www.xylinux.org
  
• create folder "wx" (optional)
  
• put xy.iso inside root ( or previously created folder)
  
• rename xy.iso to yz.iso (optional)
  
• extract from yz.iso files: file1, file2, file3, filen (only if "real", "integral" .iso booting is NOT possible)
  
• write these lines into the main loader config file:
  
  ....
  ....
  ....

Anyone having difficulties with the above part can use XBOOT (or one or the other automatic apps) to make it.

What I was asking for was a way to have an easily mantainable and easily updatable with user contribution "database" of settings, accessible without running any of the mentioned apps in order to use this knowledge manually or for "custom projects".

[shamurshamur]

@Wonko the sane


the list you have given is good for starting. i would like to add some more steps to it.

• download xy.iso from www.xylinux.org
• create folder "wx" (optional)
• put xy.iso inside root ( or previously created folder)
• rename xy.iso to yz.iso (optional)
• delete files from yz.iso : file1 ,file2 ,file3
• append kernel parameters "iso-scan/filename" to files isolinux.cfg/menu.lst inside the yz.iso (optional)
• extract from yz.iso files: file1, file2, file3, filen (only if "real", "integral" .iso booting is NOT possible)
• hexedit file1,file2 (optional)
• write these lines into the main loader config file:
  
  ....
  ....
  ....

thats what i am talking about. we have to figure out what are all the possible things which we can add to above list
The bigger the above list more the functionality we can provide to script writers.
suppose if script writer is trying to add multiple version of windows xp and hence renaming the folder "i386" to "abcd" . then certainly some files need hex editing. if we forget to provide this facility of hex editing to script writer , he may not be able to add multiple version of windows xp to multiboot usb/iso.

So complete list of above steps is what required here and is the difficult part.

[Wonko the Sane]

The bigger the above list more the functionality we can provide to script writers.
suppose if script writer is trying to add multiple version of windows xp and hence renaming the folder "i386" to "abcd" . then certainly some files need hex editing. if we forget to provide this facility of hex editing to script writer , he may not be able to add multiple version of windows xp to multiboot usb/iso.

So complete list of above steps is what required here and is the difficult part.

Yes, but since every Author will use his/her own ways to do the "external changes" if you put the steps, EXACTLY as you wrote them in plain English, in the form of comment, he/she will be able to replicate them in the program and people just looking for knowledge may be able to re-do them manually.

So the .ini will become somethng like:

Spoiler

[Distro Name]
Name1="GParted Live"
...
...
[GParted Live]
;tested with version 0.7.1-1
;download gparted-live-0.7.1-1.iso from http://gparted.sourceforge.net/ (change filename accordingly to current)
;create folder "gparted" (optional)
;put downloaded .iso inside root ( or previously created folder)
;rename .iso to gparted.iso (optional)
;delete files from yz.iso : file1 ,file2 ,file3
;append kernel parameters "iso-scan/filename" to files isolinux.cfg/menu.lst inside the yz.iso (optional)
;extract from yz.iso files: file1, file2, file3, filen (only if "real", "integral" .iso booting is NOT possible)
;hexedit file1,file2 (optional)
Loader=Syslinux
Version=4.0.3
Config=Main.cfg
Title=label GParted Live
Line1=MENU DEFAULT
Line2=# MENU HIDE
Line3=MENU LABEL GParted Live (Default settings)
Line4=# MENU PASSWD
Line5=kernel /live/vmlinuz1
Line6=append initrd=/live/initrd1.img boot=live username=casper noswap vga=788 ip=frommedia
Line7=TEXT HELP
Line8=* GParted live version: 0.3.6-7. Live version maintainer: Steven Shiau
Line9=* Disclaimer: GParted live comes with ABSOLUTE NO WARRANTY
Line10=ENDTEXT

In other words the .ini file could be at the same time a "machine parsed" set of data AND a "human readable" set of instructions.




Wonko

[omega151x]

Active@ Boot Disk Suite

Problem being prompt for license info
Post
Post


MENU LABEL Active@ KILLDISK 5.1 Professsional Suite v4.1 - DOS LiveCD
The license file are stored in the root of /images/iafadgbfd.ISO

MENU LABEL Active@ KILLDISK 5.1 Professsional Suite v5.1 - Win LiveCD
The license file are stored in the root of /images/cijjacdib.ISO

MENU LABEL Active@ Boot Disk Suite 5.1.2 (LiveCD) Win & DOS Editon
The license file are stored in the root of /images/hggcieidi.iso

The BOOTDISK.KEY (license file)is located in the root of hggcieidi.iso which is located in /images/hggcieidi.iso on the xboot.iso

I am able to extract hggcieidi.iso from the xboot.iso and burn a separate CD & load it with out being prompt for license info; only when I incorporate the Active@ Boot Disk Suite in xboot.iso it ask me for license info.

Thanks in advanced for any help.

[angeloso]

Great tool shamurshamur:

Please, Can you do to implement in your tool ( xboot ) boot

live cd image xp?

I Have probing with one live cd xp and add image grub4 emulatión, and when boot from

quemu or in real dvd burn the fact is the same: blue screen xp just when charge final fase

But when boot from isolated live xp burn dvd/cd it works fine.

This make to me think of a bug in xboot for this type of iso images ( live cd/dvd xp )

Very thanks , sir shamurshamur for this very good gui tool

Edited by angeloso, 30 December 2010 - 10:34 PM.

[Wonko the Sane]

Just created a new thread for all things related to the new ".ini" approach, here:
http://reboot.pro/13511/


Wonko

[BrN888]

I've triyng to make a ISO with both version msdart of win vista - x86 e x64 but when the iso is finished only one of the msdart is present..
I already tried add one like grub4dos and the other like msdart, but the result is the same... this happens with msdart win7 x64 and x86...

[omega151x]

Problem

Problem: being prompt for license info

Active@ Boot Disk Suite 5.1.2 (Live CD) Win & DOS Editon

workaround to my problem:
I copy the BOOTDISK.KEY file from Active@ Boot Disk Suite ISO to the root of xboot.iso

[shamurshamur]

I've triyng to make a ISO with both version msdart of win vista - x86 e x64 but when the iso is finished only one of the msdart is present..
I already tried add one like grub4dos and the other like msdart, but the result is the same... this happens with msdart win7 x64 and x86...

i know. i will fix this in next release.