11 replies to this topic

[Wonko the Sane]

Only to place a link to this thread where the discussion is going on:

http://www.msfn.org/...-torito-images/

 

The part strictly speaking related to grub4dos is in this post:

http://www.msfn.org/...ages/?p=1085403

 

 

Whilst the good Syslinux guys have decided (as seen since version 2.12) to pre-embed the size and the checksum (and write EFBEADDE as "filler"), the good grub4dos guys leave the whole set of bytes set to 00's.

 

The net effect is that IF the .iso is made with mkisofs AND the -boot-info-table option was chosen, Isobuster has no troubles with it.

 

Otherwise the size is still found as 2048 bytes since the bootinfotable in the first sector is all 00's.

Given the complexity of the options of mkisofs I would guess that the amount of GRLDR based .iso's around made with the "-boot-info-table" represent maybe 0.01% of the total number of GRLDR based .iso's.

 

And I plead guilty, too  , for having built numberless of such .iso's without the switch:

http://reboot.pro/to...ub4dos/?p=84348

 

I may ask tinybit/chenall  (current grub4dos maintainers  ) if they would consider to pre-populate the size and checksum in the bootinfotable in future versions of GRLDR (unless there is any size effect since GRLDR doubles as hard disk MBR + hidden sectors loaders).

 

 

 

Wonko

[tinybit]

grldr no-emulation-mode bootable CDROM iso can be made with or without the -boot-info-table switch.

 

The boot info table is not used during the grldr boot process. That is why nearly all grldr ISOs are built without the -boot-info-table switch.

 

I can't see why we should place an "unused" boot info table with grldr ISOs.

[Wonko the Sane]

I can't see why we should place an "unused" boot info table with grldr ISOs.

No *real* reason.

 

On the other hand what was the reason why grldr was made compatible with -boot-info-table at all?

As well, possibly no *real* reason.

 

I claim that the same absence of a real reason can be used to say "why not putting this info there"?

 

The *feature* (or lack of it) would not I believe change anything of relevance, really, and maybe (that is a very vague maybe, rest assured ) having the size of the file may somehow be useful for *some* uses (but I have no idea on which ones would be useful in practice ).

 

 

Wonko

[tinybit]

what was the reason why grldr was made compatible with -boot-info-table at all?
As well, possibly no *real* reason.

There might be a reason. If someone "erroneously" used the -boot-info-table switch, things would not go too bad.
 

I claim that the same absence of a real reason can be used to say "why not putting this info there"?

The *feature* (or lack of it) would not I believe change anything of relevance, really, and maybe (that is a very vague maybe, rest assured ) having the size of the file may somehow be useful for *some* uses (but I have no idea on which ones would be useful in practice ).


Wonko

If that was a feature, and it was documented, then the developers/maintainers should keep this feature for subsequent/future versions. That means the developers/maintainers would lose an option to use this space for other purposes.

If the space is "reserved", then the developers/maintainers could use it for any purpose. Possibly a bug fix(for a buggy BIOS) might need such a space.

Do not run out of resources. Great Importance Should be Accorded to the Sustainable Development.

[Wonko the Sane]

Good.

 

Still, the combination of size of file with checksum of the bootsector should be enough to prevent issues, if and when that area is/will be used for other purposes.

 

But the sheer moment it will be used for this new scope, the use of mkisofs with -boot-info-table will need to be prohibited as if I get it right when the -boot-info-table is chosen that area is overwritten by mkisofs, "no questions asked".

 

No problem , of course and as said, the idea was asking if the change could be considered, and it can be not.

 

Wonko

[tinybit]

Generally speaking, who would care about the checksum issue and the such?

 

It should be the boot record itself.

 

The developer of the boot record can determine how to successfully load the whole boot record from the media. It is the developer who should be responsible for the success(ratio) of the boot record. This has not so much to do with others. Especially, the developer can determine whether or not to use a checksum, and (if used) which algorithm should be used. All in all, and in the end, all those efforts are for a high ratio of the success of the boot record.

 

At this moment, I don't think the boot info table is a "must". I don't think it is important enough for grub4dos or for most of others.

 

The beginning sector is so important, and the code in it is so crowded, that we shouldn't and won't allow trivial or unimportant code/data to be there.

 

We should only allow code that must be there to be there.

 

We should not allow code that just can be there to be there.

 

 

[Wonko the Sane]

Noone said it was a "must", it was actually a possible way to have the thingy more similar to the way Isolinux has been made, without any counterproductive effects.
 
Adding size and checksum at build time would cost nothing.
 
As said, the -boot-info-table is an option present in mkisofs (and in genisoimage and in xorrisofs, i.e. the programs that - combined - make up for I believe nearly 100% of .iso making under Linux - bootable or non-bootable), and it is so relevant that the good grub4dos developers allowed in their code some "free space" compatible with the use of this switch.
 
Having this same space pre-set to all 00's (like it is currently in GRLDR), to all EF BE AD DE (as in isolinux early versions), to 0x00000010/0x000000/bi_BootFileLength/bi_Checksum + all EF BE AD DE (as in more recent isolinux versions) doesn't change anything whether the -boot-info-table switch is used or not.
 
The moment when that area will be used for other uses by the good grub4dos guys, then, using the -boot-info-table switch will make a difference, as it will change those bytes.
 
Choosing to write to the first 64 bytes of grldr:

EB 3E 80 05 20 39 FF FF 20 48 65 6C 6C 6F 20 67 
75 79 73 2C 20 77 65 6C 63 6F 6D 65 20 74 6F 20 
74 68 65 20 77 6F 6E 64 65 72 66 75 6C 20 77 6F 
72 6C 64 20 6F 66 20 67 72 75 62 34 64 6F 73 21 

would also be perfectly fine with me.
 

Wonko

P.S.: I will tag the added few lines as "declaration of intents" (under the main tag "gratuitious comments"):

The beginning sector is so important, and the code in it is so crowded, that we shouldn't and won't allow trivial or unimportant code/data to be there.
 
We should only allow code that must be there to be there.
 
We should not allow code that just can be there to be there.

the parts in red are those that I will use to remember to avoid proposing any trivial or unimportant changes, actually propose anything at all so that I won't risk that it may be considered trivial or unimportant .

[tinybit]

This area/space is reserved for the developers of grub4dos. It is not reserved for boot info table.

So it should be 00 as normal.

[Wonko the Sane]

This area/space is reserved for the developers of grub4dos. It is not reserved for boot info table.

So it should be 00 as normal.

 

Relax  , I won't steal any of your precious 00's   in order to reuse them for evil scopes  .

I posted here to ask (nicely) if you could lend 8 bytes for other uses (only until you don't need to use them) and you explained why you don't want to.

 

This is fine , and ends the discussion.


Wonko

[tinybit]

the parts in red are those that I will use to remember to avoid proposing any trivial or unimportant changes, actually propose anything at all so that I won't risk that it may be considered trivial or unimportant.

I may think of something as trivial/unimportant, but, I cannot assure all others have the same thought. "My idea" != "truth".

All of the proposals are not trivial/unimportant. But in the content of a proposal, something(such as code and data) can be trivial/unimportant. Don't disguise replacement of concept.

Also I should clarify that if something is considered trivial/unimportant, the words trivial/unimportant are relatively, not absolutely. It depends on different viewing from different perspectives or depends on the object that will be compared to.

[Wonko the Sane]

Don't disguise replacement of concept.

I don't, rest assured.

 

Still the tag of "gratuitious" will remain, this thread could have ended on post #5 fine.

 

Wonko

[tinybit]

But the sheer moment it will be used for this new scope, the use of mkisofs with -boot-info-table will need to be prohibited

 

Surely. But the time is not up. By this moment, we can still use the -boot-info-table switch.

 

EDIT:

 

I am sorry I might have to continue. I should reply some questions that was not replied.

 

From beginning to end, I like all of your posts very much. I really appreciate your posts, although my English understanding is so poor.

 

emm...  "gratuitious" should be "gratuitous"?

 

 

 

I posted here to ask (nicely) if you could lend 8 bytes for other uses (only until you don't need to use them)

 

Even one byte cannot be lent. The total (boot)sector space has only 512 bytes or 2048 bytes. The land is very valuable. If I lent one byte, what if a future developer want the byte? I am afraid the developer would complain or even get angry and call me a fool. I can lend several KB without any worries behind, if it is not in such a precious, valuable, costly and expensive area. The house could be empty, but is neither for sale nor for lending.