141 replies to this topic

[LeMOGO]

I have tables to upload.
Where should I?

The map's note box is too small, and this post does not keep tab formatting when pasting. I do not want to redo (too much work).

• 1 text based table
• 1 excel table

I need something *really* free that will not delete files if not downloaded, and can be updated.

Edited by LeMOGO, 31 January 2011 - 04:55 PM.

[Wonko the Sane]

The map's note box is too small, and this post does not keep tab formatting when pasting. I do not want to redo (too much work).

• 1 text based table
• 1 excel table

I need something *really* free that will not delete files if not downloaded, and can be updated.

Temporarily, upload to *any* hosting site, I will download them and re-attach them to a post.


Wonko

[LeMOGO]

Table added to C.3.4.2.2.
Any one knows if a layer missing on this table?

Edited by LeMOGO, 01 February 2011 - 04:12 AM.

[LeMOGO]

I added it as an attachment on the mindmap. It can be downloaded from "download this table" in C.3.4.2.2

In case you are having troubles with the above, as per wonko's suggestion, I uploaded it here: http://www.filedropp...om/ufdcontaints
The right download button is the grey button in the grey box, the one that is labeled "Download This File"

I also added an attachment to C.3.3

Edited by LeMOGO, 01 February 2011 - 05:08 AM.

[LeMOGO]

...you will have to consider MORE categories, ..., to which you have to add
ALL the possible historical HD size barriers ...
AND the particular controller the stick uses
AND the particular way it can be setup through it's "Manufacturer Mass Production Tool" or Utility.
...
Wonko

Bullet 1 is done.
Now we can start with 2 & 3: HOW?

Please explain what the issue is with the controllers.

As for your last entry, well, that's inside information. What's to know? Someone who does not play at that level will simply not know of these intricacies, so, write, wonko write!

others (please contribute),

one of the questions above remains unanswered.

There is an exploratory stage during which one must must attempt to discover the workings of his/her BIOS in regards to usb devices. To explore the BIOS and come up with an educated guess/conclusion that will enable the user to boot from usb, several devices will be necessary.
Please make suggestions as to what devices should be at hand in the "tool bag" for use when testing the BIOS boot properties.

What do you personally use when exploring BIOS capabilities?

Table added to C.3.4.2.2.
Anyone knows if a layer missing on this table?

Edited by LeMOGO, 01 February 2011 - 06:44 AM.

[LeMOGO]

@wonko

How do super floppies fit in your matrix @ C.3.1.2.1?

[LeMOGO]

Just corrected a typo in the table: the CHS values in "Limits & constraints" should be 528MB/504MiB, not GB. Added ECHS and LBA values.

Latest uploaded file is here: http://www.filedropp.../ufdconstraints

Please remove the link from post #54 to avoid any confusion.
Thank you.


It should read as follows:
I added it as an attachment on the mindmap. It can be downloaded from "download this table" in C.3.4.2.2

In case you are having troubles with the above, as per wonko's suggestion, I uploaded it here: http://www.filedropp.../ufdconstraints
The right download button is the grey button in the grey box, the one that is labeled "Download This File"

I also added different attachment to C.3.3

Edited by LeMOGO, 01 February 2011 - 09:15 AM.

[Wonko the Sane]

@wonko

How do super floppies fit in your matrix @ C.3.1.2.1?

I am not sure to understand the question.
Anything that has a partition table is partitioned (and it is "HD-like").
Anything that has NOT a partition table is NOT partitioned (and it is "Floppy-like").

More:
http://reboot.pro/5660/

Inside the "Floppy-like" category there can be (based EXCLUSIVELY on size/geometry):

FLOPPIES:
"canonical floppies", shortened to floppies, or, if you prefer floppies that actually existed in the form of both media and drives for them, i.e. anything which size and geometry is:
OLD - practically not anymore used floppy formats (there are more, older that I won't cite):

• 368,640 bytes 360K floppy (DD 5.25") 40/2/9
• 1,222,800 bytes 1200K floppy (HD 5.25") 80/2/15
  (the latter is compatible with the El-Torito floppy emulation standard)

COMMON - "standard" floppy formats:

• 737,280 bytes 720K floppy (DD 3.5") 80/2/9
• 1,474,560 bytes 1440K floppy (HD 3.5") 80/2/18
• 2,949,120 bytes 2880K floppy (ED 3.5") 80/2/36
  (the latter two are compatible with the El-Torito floppy emulation standard)

RARE - "NON-standard" floppy formats - often NOT bootable and/or NOT usable on some drives and/or OS:

• 1,720,320 bytes 1680K floppy (HD 3.5" extended format) 80/2/21
• 1,763,328 bytes 1722K floppy (HD 3.5" extended format) 82/2/21
  (there are more that I won't list as they are really rare)

Of the above listed MOST BIOSes will only "know" a sub-set of the OLD + COMMON, typically motherboards that still have a floppy port may support booting from one, two or all of these ONLY:

• 1,222,800 bytes 1200K floppy (HD 5.25") 80/2/15
• 1,474,560 bytes 1440K floppy (HD 3.5") 80/2/18
• 2,949,120 bytes 2880K floppy (ED 3.5") 80/2/36
  (not so casually the three formats also allowed in El-Torito floppy emulation standard )

Some info for older/different formats can be found on Wikipedia:
http://en.wikipedia....iki/Floppy_disk

SUPERFLOPPIES:
"non-canonical" floppies,i.e. anything that has NOT the sizes (and geometries) above and that needed BOTH a special media and drive, typically:

• ZIP disks
  
  • ZIP 100 100,663,296 bytes CHS 96/64/32
  • ZIP 250 250,609,664 bytes CHS 239/64/32
  • ZIP 750 751,828,992 bytes ??? CHS 239/64/32 ???
• Superdisks
  
  • LS-120 126,222,336 bytes CHS 963/8/32
  • LS-240 262/32/56
  (more details on these already summed up here: http://reboot.pro/12436/

"pseudo-real floppies" i.e. floppy sizes that never existed media or drive for, examples:
http://www.911cd.net...showtopic=10853

• 3.84 3,932,160 bytes (custom) 80/2/48
• 5.76 5,898,240 bytes (custom) 160/2/36
• 8.10 8,294,400 bytes(custom) 225/2/36

but that follow the logic of "real" floppies.

"fake floppies", sizes and geometries are "free", one of these is nothing but an ordinary volume or primary partition with "Sectors before"=0, though they tend to use the common geometries for hard disks it is not really written anywhere that they "should", typical C/H/S are:

• n/16/63
• n/64/32
• n/64/63
• n/128/63
• n/240/63
• n/255/63

For the record there is an exception, something that could use "normal" media BUT needed the special drive, once again the LS-240, that seemingly could in a "special" mode write 32 Mb to a "common" ED 2.88 media. (no details about geometry or bootability of this).

In my view, and in practice when booting, anything among these:

Of the above listed MOST BIOSes will only "know" a sub-set of the OLD + COMMON, typically motherboards that still have a floppy port may support booting from one, two or all of these ONLY:

• 1,222,800 bytes 1200K floppy (HD 5.25") 80/2/15
• 1,474,560 bytes 1440K floppy (HD 3.5") 80/2/18
• 2,949,120 bytes 2880K floppy (ED 3.5") 80/2/36
  (not so casually the three formats also allowed in El-Torito floppy emulation standard )

is a "floppy".
Anything else, as long as it is NOT partitioned, is a "super-floppy".



Wonko

[LeMOGO]

@wonko

From all I read, there is no clear demarcation between what falls in the "super-floppy" category, so I will have to keep my focus on the boot process and why the categorization matters, then focus on how to ensure we understand the difference that makes a difference.

The issue at hand here is that at boot time, some BIOSes will think of any USB device in these terms:

(C.3.2.3.1) "Any USB storage device is a super-floppy".

We will need to consider that from time to time when formatting our USB devices. I propose the following:

Partitioned

• HDD

NOT partitioned

• FDD
  
• floppy: 1.2, 1.4, 2.88 emulation (with the above geometries)
• super-floppy: any non patitionned (no MBR) USB device

Since this decision is made based on the contents of the MBR, I created the entries in C.3.2.5.6 "different BIOSes see USB devices at boot time based on" "contents of the MBR" "no MBR present"
I tried to merge it to C.3.1.2.1, but these are different outlooks all together, so I kept the branches separate for now. If someone can think of a different logic, please let me know.
I will add all the floppy types in a new branch under C.3.1.2.1 at later time.
Unless there are objections to the above categorization, I will leave it as is.

[LeMOGO]

The categorization in C.3.1 "Types of USB boot devices" needs some accompanying logic other than the gathering of data. I tried the following logic, but it does not cover EVERYTHING in the branch since it was designed as a "tree" of type of devices that may be supported by BIOSes:

There are different types of USB boot devices because USB is just a way to plug things. The same things that are used to boot a computer under "normal" circumstances could also be used to boot while plugged via USB, but it will depend on how your BIOS "sees" that device at boot time (i.e. what controller the BIOS is created to "plug" (wire) your USB device to). While "real" (non-emulated) devices are seen as being of their own type, hard drives and flash drives will be seen as (some) Optical or Magnetic/Solid State devices (C.3.1) following the logic in C.3.2.

Another valid logic would be "these are the devices that may be supported by your BIOS as boot devices", but then, how would that practically relate to the decisions we have to make?
BIOSes can support any subset of that branch. These are the possibilities, now what?
I guess the answer to that would be "you need to try to find out what your BIOS behaves like" (looking at that list).
There has to be a point to that list. What is it? How do we use it?

[LeMOGO]

About super-floppies.
How about this:

If it is a "regular" floppy, it is a floppy.
If not, if it is not a hard drive, it is super-floppy

[Wonko the Sane]

Since this decision is made based on the contents of the MBR, ...

That is mostly true, but we do have some particular UBS sticks (reknown are a few NETAC models) that have a switch that makes them behave (and be seen) EXACTLY as a 1.44 Mb.

As I see it there are TWO factors:

• Size
• MBR or not

of which size is coming first.
Like (pseudocode):

IF size equal 1.2 THEN GOTO its-a-floppy

IF size NOT equal 1.44 THEN GOTO its-a-floppy

IF size NOT equal 2.88 THEN GOTO its-a-floppy

IF firstsector equal MBR THEN GOTO its-a-HD ELSE GOTO its-a-super-floppy

Which is EXACTLY your :

About super-floppies.
How about this:

If it is a "regular" floppy, it is a floppy.
If not, if it is not a hard drive, it is super-floppy

Wonko

[LeMOGO]

As I see it there are TWO factors:

• Size
• MBR or not

of which size is coming first.
Like (pseudocode):

IF size equal 1.2 THEN GOTO its-a-floppy

IF size NOT equal 1.44 THEN GOTO its-a-floppy

IF size NOT equal 2.88 THEN GOTO its-a-floppy

IF firstsector equal MBR THEN GOTO its-a-HD ELSE GOTO its-a-super-floppy

Well, if that's the case, then it should be:

• IF size IS equal 1.2 THEN GOTO its-a-floppy
• IF size IS equal 1.44 THEN GOTO its-a-floppy
• IF size IS equal 2.88 THEN GOTO its-a-floppy
• IF firstsector IS equal MBR THEN GOTO its-a-HD
• ELSE GOTO its-a-super-floppy

OR

IF disk size is (either 1.2, or 1.44, or 2.88) then it's a floppy
IF disc starts with MBR it's a Hard Drive
Else it's a supper-floppy

SO we should end up with this:

IF disc start with MBR it's a Hard Drive (bootable)
IF disk starts with BOOTSECTOR and size is (either 1.2, or 1.44, or 2.88) then it's a bootable floppy
IF disk starts with BOOTSECTOR it's a bootable supper-floppy
Else if size is (either 1.2, or 1.44, or 2.88) then it's a floppy, if not, it's a supper-floppy (storage only)

Look @ C.3.2.5.6 AND C.3.2.2.1 drive size under 1GB.

AND from this post

Be aware that most motherboards, even those that allow for booting from the maun three device types (superfloppy, zip, HD) actually have problems with the first two types and that a large number of motherboards only boot from USB "HD".
jaclaz

so, it's best to flip the bit to make your bootable UFD a "HD".

------------------------------------------------------------------------------------------------------
on a different topic:

Please give me YOUR rationale about post 60

Edited by LeMOGO, 02 February 2011 - 03:21 PM.

[Wonko the Sane]

Well, if that's the case, then it should be:

• IF size IS equal 1.2 THEN GOTO its-a-floppy
• IF size IS equal 1.44 THEN GOTO its-a-floppy
• IF size IS equal 2.88 THEN GOTO its-a-floppy
• IF firstsector IS equal MBR THEN GOTO its-a-HD
• ELSE GOTO its-a-super-floppy

Yes , sorry, typo .

SO we should end up with this:

IF disc start with MBR it's a Hard Drive (bootable)
IF disk starts with BOOTSECTOR and size is (either 1.2, or 1.44, or 2.88) then it's a bootable floppy
IF disk starts with BOOTSECTOR it's a bootable supper-floppy
Else if size is (either 1.2, or 1.44, or 2.88) then it's a floppy, if not, it's a supper-floppy (storage only)

Yes an No.
Both are simplifications.
There is no Law (except common sense) that can prevent me to put a MBR as first sector of a floppy.

But general problem is HOW to distinguish (in the real world) between a MBR and a PBR?

Point is that you cannot (and shouldn't) check for MBR code (as it may be different from OS to OS or from bootmanager to bootmanager), the only logical thing would be to check for a primary active partition in one of the 4 partition entries in the first sector.
But if you have grldr.mbr (as an example) installed, you could well have a disk with no Active partitions.
Actually you could also have one with only one extended partitions (with one or more logical volumes in it) and still it would be bootable.
And all these could be hidden, and yet grub4dos could be capable of booting.
And I could have a "stoopid" OLD Compaq MBR with 6 partition entries.

I think that there is no actual valid solution, the makebootfat triple effect MBR does AT THE SAME TIME look like:

• a HD MBR
• a superfloppy PBR
• a ZIP disk MBR

The only intelligent way would be (and there are motherboards that do have this option) to make the user choose among:

• USB-Floppy
• USB-HD-like
• USB-Super Floppy

but this doesn't help in the classification...

....and of course it is exactly because "bad" BIOSes use similar "bad" ways to understand if the "unspecified device" attached to the USB bus is a floppy, super-floppy or hd-like that there are so many problems.
And, yes, I was forgetting the 2 Partitions tnat some BIOSes "like" in order to presume that a "Removable" USB stick is actually a Hard Disk.

Look @ C.3.2.5.6 AND C.3.2.2.1 drive size under 1GB.
Please give me YOUR rationale about post 60

I'll check and let you know.


Wonko

[LeMOGO]

Well, since this is about how BIOSes see the drives, we'll have to discard the g4d stuff. With grub4dos we can perform all kinds of magic tricks. It is a branch of its own (not punched it yet).
Right now, we need to make sure we nail down the BIOS issues.

If I format my UFD as a floppy, and put a MBR on it, how will the BIOS see it?
If that does not matter, then our logic should revolve around the partition table, in which case, we need the change it accordingly and come up with something new.

But general problem is HOW to distinguish (in the real world) between a MBR and a PBR?

Point is that you cannot (and shouldn't) check for MBR code (as it may be different from OS to OS or from bootmanager to bootmanager), the only logical thing would be to check for a primary active partition in one of the 4 partition entries in the first sector.

Edited by LeMOGO, 02 February 2011 - 04:02 PM.

[Wonko the Sane]

About 3.2.5.6 it's OK as I see it , though maybe we should introduce a "weight" of some kind .
I mean:

• *any* BIOSes that support booting from USB a floppy will "like" 1.44
• *most* older BIOSes that support booting from USB a floppy may "like" 1.2
• *few* more recent BIOSes that support booting from USB a floppy may "like" 2.88

Or in other words, if you have a 1.44 Mb floppy or floppy-like device (NETAC pendrives with the switch - as an example) it is very likely that your BIOS will be able to boot from it, if you have a 1.2 or 2.88 Mb floppy it is pretty much unlikely.

I don't get the point of "Post 60".
Can you try expanding on it?

If I format my UFD as a floppy, and put a MBR on it, how will the BIOS see it?

It depends on the specific BIOS.... NO "one-size-fits-all" solutions.
HOWEVER this makes NO sense :
If you format your UFD as a floppy and put a MBR to it either it isn't anymore a floppy-like device, or it won't be bootable since you just overwrote it's PBR ny "putting a MBR on it", unless you use a "double way" MBR/PBR.


Wonko

[LeMOGO]

wonko, that was

C.3.2.5.6 AND C.3.2.2.1

I believe the weighting has been placed where it belongs!?
I expanded the branch anyway and added the notes. I also cross-referenced both.

[LeMOGO]

Additions as stated in previous post (#67).

It depends on the specific BIOS.... NO "one-size-fits-all" solutions.
HOWEVER this makes NO sense :
If you format your UFD as a floppy and put a MBR to it either it isn't anymore a floppy-like device, or it won't be bootable since you just overwrote it's PBR ny "putting a MBR on it", unless you use a "double way" MBR/PBR.


Wonko

Well, you came up with the idea!
Do we agree that our logic "should" revolve around the partition table?

...
If that does not matter, then our logic should revolve around the partition table, in which case, we need the change it accordingly and come up with something new.

or am I misunderstanding something? If so, what's the logic?


============================================================================================

I don't get the point of "Post 60".
Can you try expanding on it?

Objective: explain to the reader how to read (reason through) the branch:

The categorization in C.3.1 "Types of USB boot devices" needs some accompanying logic other than the gathering of data. I tried the following logic, but it does not cover EVERYTHING in the branch since it was designed as a "tree" of type of devices that may be supported by BIOSes:

There are different types of USB boot devices because USB is just a way to plug things. The same things that are used to boot a computer under "normal" circumstances could also be used to boot while plugged via USB, but it will depend on how your BIOS "sees" that device at boot time (i.e. what controller the BIOS is created to "plug" (wire) your USB device to). While "real" (non-emulated) devices are seen as being of their own type, hard drives and flash drives will be seen as (some) Optical or Magnetic/Solid State devices (C.3.1) following the logic in C.3.2.

Another valid logic would be "these are the devices that may be supported by your BIOS as boot devices", but then, how would that practically relate to the decisions we have to make?
BIOSes can support any subset of that branch. These are the possibilities, now what?
I guess the answer to that would be "you need to try to find out what your BIOS behaves like" (looking at that list).

AND wait for the author to shed some light on the "so what?" of the whole branch

There has to be a point to that list. What is it? How do we use it?

Edited by LeMOGO, 02 February 2011 - 05:48 PM.

[Wonko the Sane]

Well, you came up with the idea!

Well, NO.
The idea was a little different . and it was obviously a very unprobable case, to show you how checking size of device should come BEFORE checking the presence of the MBR.
I didn't say to put a MBR on a floppy, I said that theoretically I could partition a floppy (a real floppy) and if the BIOS lloks for the MBR it would find it is a hard disk!

Do we agree that our logic "should" revolve around the partition table?

Yes OUR logic needs to revolve around the device being partitioned or not (which equates to having or not a partition table).
But it is a theoretical or abstract idea, a logical categorization that misses a practical point:
HOW we determine if a device is partitioned or NOT?
But, much more than that, the point is to find a way to somehow evidentiate how THEIR logic (I mean that of the various more or less demented BIOS programmers) works (or fails to work).

The C.3.1.2.1 is OK AFAICU, (there is only a little glitch in "real USB floppies" with a "strange" 5.25).

That is a tentative map to put the reader before the available devices, put in a nice and logical arrangement.
So this is "available options" that both the BIOS programmer and "final user" have available.

The C.3.2 branch is on the other hand what we have been observing during this years about the effects of the way the same more or less demented BIOS programmers implemented USB booting.

In other words C.3.1 is "objective" and "evidence supprted", C.3.2 is more "subjective", and "theory supported".

I am thinking if there is a better way to organize C.3.2 in such a way that a path is more easy to spot.

Something like a "BIOS Rank" with at the top a BIOS with a rank of 100 that boots whatever you connect to it, no questions asked and at the bootom a BIOS with a rank of 0 (that has no USB boot capabilities) and immediately before a BIOS with a rank of 1 (such as many laptops) that ONLY boot from a device that is 1,474,560 bytes in size.

This way the reader could use the rank to decide himself which devices give the most probabilities to boot ....


Wonko

[LeMOGO]

I am thinking if there is a better way to organize C.3.2 in such a way that a path is more easy to spot.

Something like a "BIOS Rank" with at the top a BIOS with a rank of 100 that boots whatever you connect to it, no qustions asked and at the bootm a BIOS with a rank of 0 (that has no USB boot capabilities) and immediately before a BIOS with a rank of 1 (such as many laptops) that ONLY boot from a device that is 1,474,560 bytes in size.

This way the reader could use the rank to decide himself which devices give the most probabilities to boot ....


Wonko

u got d point. driving right now. will start branch with the given Outlook when i get home. of course, u don't have wait 4 me

[Wonko the Sane]

u got d point. driving right now. will start branch with the given Outlook when i get home. of course, u don't have wait 4 me

Well, but you may want to wait me.

I mean, we have to think over this (and sleep on it), as another possibility could be bootability rank (attributed to devices), something in which we have, once forked between BIOS that support USB booting and BIOS that doesn't, in the latter the USB 1.44 floppy as very likely - let's say at a bootability level of 99.99%, soon followed by a partitioned device <=8 Gb with "removable" bit flipped, at 93.78%, by a partitioned device <=128 Gb with "removable" bit flipped, at 91.47%, and so on, with the worst case being a >128 Gb pendrive formatted as super-floppy, with a bootability of 1.37% (highly improbable).... (figures clearly invented )


Wonko

[LeMOGO]

Well, NO.
The idea was a little different . and it was obviously a very unprobable case, to show you how checking size of device should come BEFORE checking the presence of the MBR.
I didn't say to put a MBR on a floppy, I said that theoretically I could partition a floppy (a real floppy) and if the BIOS lloks for the MBR it would find it is a hard disk!

... and if it is a hard disk, it is not a floppy/super-floppy!
So, we agree. I thought there was something else I did not know that might have been a factor, but as it stands, the logic is solid, so, there is no need for changes. And I think it still sticks even if:

The idea was a little different . and it was obviously a very unprobable case, to show you how checking size of device should come BEFORE checking the presence of the MBR.

Regardless of the order, the result would be the same.
So we stick to

Yes OUR logic needs to revolve around the device ... partition table

unless someone else can invalidate the logic.

---------------------------------------------------------------------------------------------

...the point is to find a way to somehow evidentiate how THEIR logic (I mean that of the various more or less demented BIOS programmers) works (or fails to work).

I thought that's what we were doing in C.3.2 "different BIOSes see USB devices at boot time based on". If you are coming from the evidential angle (as in serving as evidence), I'd like to see how you'll go about it! Make that I would LOVE to see THAT (beside what Steve already offered)!

----------------------------------------------------------------------------------------------

[Wonko the Sane]

Sorry, language barrier .
evidentiate was a latinism (possibly a false pair) in the sense of highlight, show up, make apparent, make evident, make stand out:
http://www.websters-.../stand out.html

We don't need to prove anything , if the other peeps do not trust our word for it , they can draw their own map, instead .


Wonko

[LeMOGO]

Sorry, language barrier .

No problem, I just wanted to understand.

We don't need to prove anything , if the other peeps do not trust our word for it , they can draw their own map, instead .

Well, we HAVE to at some point in the sense that at the end of the day, we need to turn that logic into a combination of tools/steps that make sense. There has to be a way to use some tools to "map" out the behavior of the BIOS and make some decisions based on the different branches.

[Wonko the Sane]

There has to be a way to use some tools to "map" out the behavior of the BIOS and make some decisions based on the different branches.

Sure, we do have the tools, namely:

• observation <- this faculty is mostly genetic
• Steve6375's and COD11's tools:
  http://reboot.pro/12436/

What we miss are testers (and their reports).

Maybe the map may provide a better path to willing testers that in a later phase may produce reports that may result in a bettered map that ...
...may provide a better path to willing testers that in a later phase may produce reports that may result in a bettered map that ...
...may provide a better path to willing testers that in a later phase may produce reports that may result in a bettered map that ...
...may provide a better path to willing testers that in a later phase may produce reports that may result in a bettered map that ...
...


Wonko