GOBIES - not your average fishes

GOBY:
http://en.wikipedia.org/wiki/Goby


GOBIES - as you may expect - is my own half @§§ed attempt to an acronym, standing for:
Great
Outline for
Booting through
Ini files
Exchangeable
Standard

The idea was originated by steve6375 here:
http://reboot.pro/13246/page__st__162

We already have the OK from :

• shamurshamur - developer of XBOOT http://reboot.pro/13246/
• DavideCosta - developer of SARDU http://reboot.pro/forum/100/

I am trying to contact other Authors of similar (or however "connected" utilities/programs/scripts).

Already contacted, and interested in the matter:

• maybeway36 - MULTICD http://multicd.tuxfamily.org/

Already contacted - waiting for reply:

• tuxcantfly - UNETBOOTIN http://reboot.pro/forum/79/

In the list to be contacted:

• MULTIBOOTISOS http://www.pendrivel...-multiboot-usb/
• LINUX LIVE USB CREATOR http://old.linuxliveusb.com/
• MultiSystem http://liveusb.info/dotclear/

What you can do :

• if you happen to know the developers of the above listed apps/scripts, please contact them pointing them to this thread
• if you happen to know a similar app that you think should be added to the list, post the app and a link to it's site
• if you have a (constructive) idea about the tags and info needed/wanted in the .ini file, post your idea
• if you think you can contribute in any other way, post what you may/are willing to do

What you CANNOT do :

• discuss the usage of .ini files, suggesting using .xml, hives, or ANY other non plain text, human readable, file format
• post the usual off topic and thread hijacking unrelated and senseless comments

In other words, if you like the idea , contribute to it , if you don't, just ignore this thread, there are a lot of better things in life than spreading negativity around .

Edit:
GOBIES project is cancelled on January 6th, 2011


Wonko

In other words, if you like the idea , contribute to it

More of a question at this point...Would this be a good thing to integrate into winbuilder scripting for the "other OS" stuff. I did some work recently in the win7Pe_SE project to "fix" the isolinx and even bcdw booting when they are selected as a boot manager so that it flowed better to the final iso creation, etc...

Scott

More of a question at this point...Would this be a good thing to integrate into winbuilder scripting for the "other OS" stuff.

The idea is simply to give to ALL developers AND users a common resource for either their apps or for manual making, and to avoid having good info either UNfindable, or scattered around, or "kept inside" non human readable binaries and what not.
As we have seen from experience "adding something" (either in the form of .iso or of "flat" directory layout) often requires a number of modification to the source or a "special" menu.lst entry (for grub4dos) or in syslinux/isolinux .cfg or in GRUB2 grub.cfg.

Due to the number of distro's that come out or are updated on a daily or weekly basis, every single developer needs - theoretically - to find independently the new setting at what not.

If you check the SARDU and the XBOOT threads, they are full of people asking "Please add xy.iso or wx distro or what not".

The idea is that the first one that has some time to test a new build, and can find the right settings, posts the related .ini snippet, this way the developers or the other apps can use that info and add that particular item to their database.

Please note how this activity would be not "reserved" anymore to developers, every final user can contribute.

Since everyone uses his/her own engine, like AutoIt, .Net 4 and now you with winbuilder it is unlikely that it will ever be possible (or it will take forever) to find a "common format" for EVERY step needed, but the settings for the bootloader and some info about the needed steps should be easy enough.

The number of views of the grub4dos thread - which works "non-programmatically" but more or less on the same principle:
http://reboot.pro/5041/
and the number of requests for "additions" to the various automated programs makes me think that such a "common" resource would be useful.

About adding it to winbuilder, the answer is "why not?", the idea of sharing info is that everyone can make use of it otr ignore it, as he/she preferes (or just fancies).


Wonko

About adding it to winbuilder, the answer is "why not?", the idea of sharing info is that everyone can make use of it otr ignore it, as he/she preferes (or just fancies).

Sounds fine...Will be watching this space...

But I know what you mean, since even adding in UBCD (without the PMAGIC) and then PMAGIC as a separate item involve disecting the ISO (pretty easy with 7zip), and then looking at the loader they use, and the menu structure, and then making the changes to the menus (to avoid the inevitable clash on which version of syslinux do they use, and that UBCD had a "hacked" version of a "config.c32 that could chain to either syslinux or isolinux, etc...

Coming up with a way to capture the information and provide a standard way to document it (so at least some of the easier ones could be handled) is a great idea! That's one reason I like winbuilder for things like this, since it is easy to see what the scripting does...

But as with many other things - choice is always a personal preference...

Some of the things that could be considered:

*ISO name (possibly more than one): MultiCD detects whether the ISO name is present
*Files/folders to copy from the ISO
*Subfiles/subfolders to NOT copy (or to remove after they are copied)
*Options asked to the user for each ISO that are remembered during copying files and while writing the isolinux.cfg, grub.cfg, or menu.lst
*Should we put in the lines to write for these config files, or should we put in info like kernel/initrd, image file, etc. and have the program write it?
*A way to get the version from the filename of the ISO

This isn't a comprehensive list, just some ideas.

*Subfiles/subfolders to NOT copy (or to remove after they are copied)

First off, good start to this...But, I would much rather see a list of what SHOULD be copied...removal after copy has some pothentially dangerous side effects of replacing an existing file with a different version. Of course, you could make the specification say that on any copy, fail or give warning if not the same (md5 hash?) - or even simpler failsafe of not to replace any existing file, and give warning/error...

BUT, again, good first start on things!!!

Scott

Very early draft attached. (meaning pre-alpha)

To be coherent with the "human readable" concept it is an Excel spreadsheet.


Wonko

P.S.: Posted a corrected version at post #12:
http://reboot.pro/13511/page__st__11

To be coherent with the "human readable" concept it is an Excel spreadsheet.

I hope you are aware of the fact that an Excel spreadsheet is a binary format, and not a human readable format.

I hope you are aware of the fact that an Excel spreadsheet is a binary format, and not a human readable format.

It seems like you are not very familiar with sarcasm/humour and with the use of emoticons to emphasize their intentional use.
This really saddens Wonko, he would have expected to provoke a quick laugh by contradicting himself so openly.

Maybe next time.


Wonko

I will make the extra section of SARDU with GOBIES compatiblity.

Would it be possible to define more than one loader; i.e. put both GRUB4DOS and ISOLINUX/SYSLINUX information in the .ini file, so the program can use either?

Would it be possible to define more than one loader; i.e. put both GRUB4DOS and ISOLINUX/SYSLINUX information in the .ini file, so the program can use either?

Sure, that's the idea.
In the draft example I only put grub4dos entries as I am more familiar with them, check line 16 of the draft, if you add a section:
[<main_loader>]
where <mainloader>:

[grub] <- this means grub ""legacy""
[grub4dos]
[Syslinux] <- use Syslinux for ANY among Syslinux/Isolinux/PxeLinux
[GRUB2]

and then all the fields and at least a:

[<method>]

section, where <method>:

Any among:
from_iso_n
from_ima_n
from_img_n
mem_from_iso_n
mem_from_ima_n
mem_from_img_n
flat_n
other_n

and all related entries, you have effectively a multi-loader, multi-boot .ini.

Remember that the draft is just a preliminary, alpha draft, anything can be changed, added or bettered.

If you (or anyone else) can post in "plain English" one (or possibly more) settings for booting the example "Parted Magic 5.8", flat or from iso with Syslinux/Isolinux/Memdisk/whatever, I can try adding these settigns to the draft and update it.

Anyway, there is a small typo in cell G8, this:

Parted Magic 5.8

should of course read:

fullname=Parted Magic 5.8

I am attaching, SAME draft0.xls/GOBIES_0.01 with the above typo corrected.
If you select the G cells from G2 up to G61, copy and paste in notepad or any other plain text editor, you should have a "valid" .ini file.

I am removing the attachment from previous post.
At the moment of this writing, it was downloaded 17 times.


Wonko

Nice work Wonko The Sane.

just wan't to clarifying some points.Tell me if i am right.

1) Each Linux distro ( parted magic , slitaz, etc) will have its own seperate .INI file
2) [Source Names] section will contain multiple version of same distros ( partedmagic-5.8.iso , partedmagic-5.7.iso etc ).

[source]

source001 = partedmagic-5.8.iso

source002 = partedmagic-5.7.iso

....

....

Nice work Wonko The Sane.

just wan't to clarifying some points.Tell me if i am right.

1) Each Linux distro ( parted magic , slitaz, etc) will have its own seperate .INI file
2) [Source Names] section will contain multiple version of same distros ( partedmagic-5.8.iso , partedmagic-5.7.iso etc ).

[source]

source001 = partedmagic-5.8.iso

source002 = partedmagic-5.7.iso

....

....

Not really (or at least that is not the original idea).

As I see it (but as said I am ready to change anything ), there are (there will be ) TWO types of .ini's:

• a plainer single source one
• a more complex multi source one

#1 above has NOT the [Source Names] section AND has a single [Source000] section and as many [<main_loader>] and [<method>] sections as needed.

#2 has the [Source Names] and any number of [Sourcelmn] sections, each with as many [<main_loader>] and [<method>] sections as needed.

In practice #2 is aimed to be the "backbone" of each and any "compatible project".
In your case it would be "XBOOT.INI", in it there should be all the distro's/whatever XBOOT supports.

#1 is aimed to be the "single user contribution" OR a quick extract of any of the various .ini's (of type #2) that will hopefully be available.

As an example, to create the example I simply chose a distro (parted magic 5.8), searched a bit around, did a couple of tests and created the entries that worked for me (with grub4dos only).

If that was an actual file, it would be named partedmagic-5.8.ini.
Anyone can get it, add to it (say) some Syslinux [<method>] sections and post the enhanced .ini.
What you would do, provided that inside you "XBOOT.INI" you had used the previous version of partedmagic-5.8.ini, as (say):

[Source Names]
Source001=Ubuntu 9.04
Source002=Ubuntu 10.10
Source...=......
Source317=Parted Magic 5.8
Source...=.....

Would simply to replace the whole [Source317] with the [Source000] from the single .ini file, renaming it's section from [Source000] to [Source317].

On the other hand, if "user X" wanted to create a simple multiboot something with just Ubuntu 10.10 and Parted Magic 5.8, he/she would simply extract from your BOOT.INI [Source002] and [Source317] to single .ini's and then either:

• use the "verbal" instructions manually
• combine just the two mentioned .ini's in a new (say) myXBOOT.INI and use XBOOT for the build (*)
• combine just the two mentioned .ini's in a new (say) mySARDU.INI and use SARDU for the build (*)
• combine just the two mentioned .ini's in a new (say) myGREATNEWAPP.INI and use a new app expressly developed for them(*)

BUT nothing prevents to use multi-source .ini's as "containers" for all the versions of a given distro/whatever, as you pointed out. (and have XBOOT get data from multiple .ini files)

Again, all is needed is to extract the single .ini's and re-combine one or more on them in the "app main .ini".

I presume that a simple utility program to extract from multi-source .ini's the single .ini's and one to actually re-combine them at will would be trivial to write (NOT in .NET 4 - please ).

(*) nothing prevents to optionally add inside each [<method>] section any number of "script lines" dedicated to the particular app, like:

XBOOT_01=copy /B afile.ext bfile.ext
XBOOT_02=hexedit bfile.ext offset 0x28 length 12 0x00
XBOOT_mn= ....
SARDU_01=xcopy /I /S /E /R /V /K /F /C /H adir bdir
SARDU_02= gsar bfile.ext -s
SARDU_mn=....
MYGREATNEWAPP
MYGREATNEWAPP_01=mysmartcopy adir bdir
MYGREATNEWAPP_02= mygreatpatcher bfile.ext somedata
MYGREATNEWAPP_mn=....
etc.

(just random commands above, just as an example)
any "other" app will simply ignore these lines.


Wonko

How about getting rid of the INi's of type 2. (for the sake of keeping things simple )

Type 1 are easy to use and no need to extract or do anything complicated.
Type 1 are also providing lot of modularity.
suppose a user wants to replace the script of a particular iso file say "partedmagic-5.8" . He can simply delete the file partedmagic-5.8.ini and just copy the alternative script from other script writer.No need to extract and combine anything.
Instead having a MyApp.ini containing script for many ISO files , we can have just bunch of collection of INI files , each file representing particular iso file.

It will make things very easy for newbies who are not at ease with editing script files.
Also users can create there own collection by selecting different scripts from different script writers.

How about getting rid of the INi's of type 2. (for the sake of keeping things simple )

Why "getting rid" ? They are entirely OPTIONAL. If you like the idea, you use it, if you don't, you don't.

Consider them a "folder" containing up to 999 "type 1" .ini's, simply a more compact (I repeat optional) way to manage the single .ini's.

Starting from the begining with such an Option is as I see it advisable, before or later someone will decide that n .ini's clutter the look of the app directory structure or that they don't look pretty or whatever, then will get to the idea of consolidating them, and as usual you'll have:

• Winbuilder peeps embedding the .ini's into .scripts
• other developers using 7zip
• other developers using the Registry
• other developers using a Truecrypt volume
• ....

and the result would be the usual tower of Babel!

The idea of a Standard, and particularly of a shared, collaboratively developed Interchange Standard, is to be:

• standard
• interchangeable

Wonko

@ Wonko the sane
just for clarification give me the example of "type 2" INI file containing script for 2 iso files(parted magic & slitaz)
( just add slitaz to the example of partedmagic given by you in draft)

@ Wonko the sane
just for clarification give me the example of "type 2" INI file containing script for 2 iso files(parted magic & slitaz)
( just add slitaz to the example of partedmagic given by you in draft)

Well, NO.

YOU post a "type 1" .ini file for Slitaz and I will add it to the draft.


Wonko

Well, NO.

YOU post a "type 1" .ini file for Slitaz and I will add it to the draft.


Wonko

Well , i am confused ,and not because of laziness,that i am asking.
so if you please kindly.....

Well , i am confused ,and not because of laziness,that i am asking.
so if you please kindly.....

draft1.xls attached
Added a single method [from_iso_0] with a single loader [grub4dos] for slitaz 3.0.

If someone is so kind as to post the settings for Parted Magic 5.8 and Slitaz 3.0 under Syslinux/Isolinux/whatever, I may be able to add them.

New draft also has "levels" so maybe it is of easier understanding.


Wonko

so basically you are implementing sub-section here.( grouping of some section under each [sourcelmn])
Right??



But we are having two sections sharing same name ie [grub4dos] . which does not seems right way.


if you want to group some section under [sourcelmn] then we can use following methedology.
For each section which is under [sourcelmn] its name will be [sourcelmn.sectionname].

that way we can avoid the sections with same name.

Here's i am giving the modified version of example you have given in draft1.

[Source Names]

Source001="Parted Magic 5.8"

Source002="Slitaz 3.0"









[Source001]

fullname=Parted Magic 5.8

version=5.8

homepage=http://partedmagic.com/

dl_page=http://sourceforge.net/projects/partedmagic/files/partedmagic/Parted%20Magic%205.8/pmagic-5.8.iso/download

dl_link=http://ovh.dl.sourceforge.net/project/partedmagic/partedmagic/Parted%20Magic%205.8/pmagic-5.8.iso

filename=pmagic-5.8.iso

new_filename=pmagic58.iso





[Source001.grub4dos]

version=http://nufans.net/grub4dos/current_release/grub4dos-0.4.4-2009-10-16.zip

homepage=http://reboot.pro/forum/66/

dl_page=http://nufans.net/grub4dos/current_release/

dl_link=http://nufans.net/grub4dos/current_release/grub4dos-0.4.4-2009-10-16.zip

filename=grldr

new_filename=grldr





[Source001.from_iso_1]

;this example uses a renamed pmagic-5.8.iso in a folder root\pmagic\

;create directory root\pmagic\

;copy pmagic-5.8.iso (renamed as per new_filename as pmagic58.iso) to root\pmagic\

filesystem=FAT16;FAT32;CDFS;NTFS;EXT2;EXT3

main_config=menu.lst

title=title PartedMagic 5.8 from iso renamed

line_01=find --set-root /pmagic/pmagic58.iso

line_02=map --heads=0 --sectors-per-track=0 /pmagic/pmagic58.iso (0xff)

line_03=map --hook

line_04=root (0xff)

line_05=kernel /pmagic/bzImage edd=off noapic load_ramdisk=1 prompt_ramdisk=0 rw vga=791 sleep=10 loglevel=0 keymap=us iso_filename=/pmagic/pmagic58.iso

line_06=initrd /pmagic/initramfs

alt_config_0=





[Source001.from_iso_2]

;this example uses pmagic-5.8.iso "as-is" in a folder root\pmagic\

;create directory root\pmagic\

;copy pmagic-5.8.iso to root\pmagic\

filesystem=FAT16;FAT32;CDFS;NTFS;EXT2;EXT3

main_config=menu.lst

title=title PartedMagic 5.8 from iso

line_01=find --set-root /pmagic/pmagic-5.8.iso

line_02=map --heads=0 --sectors-per-track=0 /pmagic/pmagic-5.8.iso (0xff)

line_03=map --hook

line_04=root (0xff)

line_05=chainloader





[Source001.flat_0]

;create root\pmagic directory

;extract from pmagic-5.8.iso files bzimage and initramfs and folder pmodules

;and place them in root\pmagic\ directory

main_config=menu.lst

title=title Parted Magic 5.8 flat

line_01=find --set-root /pmagic/bzimage

line_02=kernel /pmagic/bzImage edd=off noapic load_ramdisk=1 prompt_ramdisk=0 rw vga=791 sleep=10 loglevel=0 keymap=us

line_03=initrd initrd /pmagic/initramfs





[Source002]

fullname=Slitaz 3.0

version=3.0

homepage=http://www.slitaz.org/

dl_page=http://www.slitaz.org/en/get/

dl_link=http://mirror.slitaz.org/iso/3.0/slitaz-3.0.iso

filename=slitaz-3.0.iso

new_filename=slitaz-3.0.iso





[Source002.grub4dos]

version=http://nufans.net/grub4dos/current_release/grub4dos-0.4.4-2009-10-16.zip

homepage=http://reboot.pro/forum/66/

dl_page=http://nufans.net/grub4dos/current_release/

dl_link=http://nufans.net/grub4dos/current_release/grub4dos-0.4.4-2009-10-16.zip

filename=grldr

new_filename=grldr





[Source002.from_iso_0]

;this example uses a non-renamed slitaz-3.0.iso in a folder root\slitaz\

;create directory root\slitaz\

;copy slitaz-3.0.iso to root\slitaz\

filesystem=FAT16;FAT32;CDFS;NTFS;EXT2;EXT3

main_config=menu.lst

title=title slitaz-3.0.iso from iso

line_01=find --set-root /slitaz/slitaz-3.0.iso

line_02=map --heads=0 --sectors-per-track=0 /slitaz/slitaz-3.0.iso (0xff)

line_03=map --hook

line_04=root (0xff)

line_05=chainloader /slitaz/slitaz-3.0.iso (hd32)

alt_config_0=

so basically you are implementing sub-section here.( grouping of some section under each [sourcelmn])
Right??



But we are having two sections sharing same name ie [grub4dos] . which does not seems right way.


if you want to group some section under [sourcelmn] then we can use following methedology.
For each section which is under [sourcelmn] its name will be [sourcelmn.sectionname].

that way we can avoid the sections with same name.

Here's i am giving the modified version of example you have given in draft1.

Good idea, but wrong implementation.

I mean, if we go with sub-sections (which seems the right way as the structure is much more clear ) we need to go with sub-sections.

I.e. with this:

[Source001]
...
[Source001.grub4dos]
...
[Source001.from_iso_1]
...
[Source001.from_iso_2]
...

We don't have the "right" structure as soon as we introduce another [<mainloader>], say Syslinux, as the <method> does not contain explicit <mainloader> info.

So we need:

[Source001]
...
[Source001.grub4dos]
...
[Source001.grub4dos.from_iso_1]
...
[Source001.grub4dos.from_iso_2]
...
[Source001.syslinux]
...
[Source001.syslinux.from_iso_0]
...

What do you think of this?


Wonko

People intuitively identify slashes to sub-divide anything while dots are associated with different releases or versions of the same product line.

Otherwise, it also becomes gruesome to tell what is a sub section separator from a version delimiter.

As example:
[Source001.grub4dos.from_iso_2]
[Source001\grub4dos\from_iso_2]

People intuitively identify slashes to sub-divide anything while dots are associated with different releases or versions of the same product line.

Since we don't have dots in the strings we will use, nor version numbers, that's pretty much a non-problem.

BTW, those are backslashes, and a lot of people (like Unix/Linux users and web users, and grub4dos and Syslinux users ) will identify / (forward slashes) as separators.

JFYI .ini/.inf files do normally use dots and not backslashes or slashes.

http://www.wd-3.com/...ve/InfFiles.htm

I seem to remember you wrote a .ini/.inf parser some time ago - which you left unfinished and only partially working :
http://reboot.pro/3960/

If it was working and if you had finished it, it would be a nice tool for this initiative.

I presume next contribution will be something of utter relevance, such as "Why don't you use # instead of ; for comments?" (and yes a lot of people will "instinctively" see // as commenting separator)


Wonko

whatever we use . we should make it a rule that special character slash or dot should be reserved for representing hierarchies in section names and should not be used as normal naming character.

peace.