131 replies to this topic

[Fiction]

Ok, I'll start looking for it's size in bytes then. I'll use suggested method. Why the 255/63 geometry? Is this just 'agreed on' or something? If so, then perhaps the asus motherboard discussed earlier might have a different idea of how many sectors there are in a head, and how many heads there are per cylinder. This could then explain earlier behaviour. If so, how would I determine the geometry this bios uses and make the device 'balanced' according to this motherboard.

 

Or perhaps I am just jumping to conclusions now, impatient as always

 

*edit*

 

dsfo returns:

\\.\PHYSICALDRIVE1 - The drive cannot find the sector requested.
This error can probably be ignored.
OK, 3880452096 bytes, 281.472s, MD5 = 7e948aa5aeb933d27efc12e5eec3ee71

 

So if this error can indeed be ignored, then 3880452096/512=7579008 sectors, right?

Windows disk management tells me 3.61GiB and since 3.880GB/(1.024^3)=3.613 GiB, this seems about right, however we might not spot a sector more or less on this scale

.

And this thing sells for 4 GB =/ looks like a 0.2 GB rip-off to me.

Edited by Fiction, 04 February 2013 - 11:23 PM.

[Wonko the Sane]

So if this error can indeed be ignored, then 3880452096/512=7579008 sectors, right?

 

Yes.

The 255/63 is the most common geometry for anything bigger than 512 Mb AND it is the "default" one in Windows NT starting from 2K.

If you think about it a little, knowing that the max value of cylinder is 1024, and knowing that the most common HS geometries are:

255/63

128/63 <- rare

64/63 <- rare

16/63

64/32 <- original NT and some CF cards and the like

and the "queer" (a number of Lenovo's and a few HP's, mainly laptops use this one, but normally NOT for USB connected devices, only for "internal" disks):

240/63

 

You can draw some lines about maximum capacity that you can address in CHS:

1024*255*63*512=8,422,686,720 <- 7th size barrier at 7.88 GiB/8.46 GB <- 2nd GREAT CHS size barrier

1024*240*63*512=7,927,234,560 <- 6th size barrier at 7.38 GiB /7.93 GB

1024*128*63*512=4,227,858,432

1024*64*63*512=2,113,929,216

1024*16*63*512=528,482,304 <- 1st size barrier at 504 MiB /528 MB <- 1st GREAT CHS size barrier

1024*64*32*512=1,073,741,824

See also:

http://www.pcguide.c...d/bios/size.htm

(AND connected pages)

bolded ones are the most common and 16/63 tops at 528 Mb, which leaves us with only 255/63 as likely candidate.

 

Wonko

[Fiction]

Ok, so then what do you thing this motherboard is being 'sensitive' about? Is it just that other motherboards use LBA ALWAYS even though the xp bootsector suggests otherwise, or is it indeed possible that the ASUS bios decided on a different geometry. If so how would I determine what this geometry is?

[Wonko the Sane]

Ok, so then what do you thing this motherboard is being 'sensitive' about? Is it just that other motherboards use LBA ALWAYS even though the xp bootsector suggests otherwise, or is it indeed possible that the ASUS bios decided on a different geometry.

Some ASUS BIOS have been reported as being "queer", but there is no "definite answer".

If so how would I determine what this geometry is?

By experimenting.


Wonko

[steve6375]

You could install grub4dos on the boot drive, boot to grub4dos and then type

geometry

geometry --tune

chainloader /ntldr

boot

 

and see what you get (and if it fixes the problem)?

[Fiction]

Ill first try to get it 255/63 balanced

and perhaps then (if it does not work) a few more from wonko's list.

 

After that ill try the grub4dos from steve

[steve6375]

OK, if you install grub4dos, you can later uninstall it again and install standard MBR using RMPrepUSB Ctrl-B.

[Fiction]

What do you mean 'standard MBR'? BTW it looks as if RMPrepUSB formatted the drive 255/63 'balanced'. So apparently, this is not the geometry the bios is looking for.

 

Your method will tell me what geometry the bios uses?

[Wonko the Sane]

He means "Standard MBR CODE" (NOT "data", i.e. the partition table entries and disk signature that remain UNMODIFIED when you write ONLY a different CODE part).

I hoped that this point was clear.

Go back to DOS and fdisk /MBR command explanation:
http://support.micro.../kb/69013/en-us

 

Wonko

[steve6375]

As I understand the current situation, you have a solution (patch the bytes in bootsect.dat) - so the objective now is that for the sake of curiosity, you want to boot from USB and see what the disk geometry is reported by the BIOS as. Is this correct?

If this is so, install grub4dos on your USB disk and boot to grub4dos and use commands I suggested.

 

You can never fix it by changing the USB partition geometry - if you fix it for one BIOS, it will probably not work on a different BIOS. The 4 byte bootsect.dat patch is the best solution.

[Fiction]

Indeed, I want to be able to boot the device without the 4byte patch, as a conformation of 'good understanding'. I am trying to install grub4dos right now, but have not done this before so I'm not sure how this should be done. I'm trying a mixture of trial and error and bits and pieces from all over the web. I got something working a few minutes back, but it was just an ordinary bootloader, no command screen to type these commands in. When I succeed I'll let you know.

[steve6375]

To install grub4dos

 

1. Run RMPrepUSB

2. Click on the Install grub4dos button  (the clue is in the name!)

3. Follow the prompts (choose MBR and hit Enter to copy grldr file)

 

Not too difficult is it?  

[Fiction]

Yeah, I just saw the button right before you posted. I wanted to edit the post, but you out-posted me. I feel a bit silly now.

 

Anyway the commands return:

 

 

geometry

drive 0x80(LBA): C/H/S=471/255/63, Sector Count/Size=7572096/512

    Partition num: 0, active, Filesystem type is fat, partition type 0x0C

geometry --tune returns the exact same thing

 

 

chainloader /ntldr

Error 15: File not found

This is probably because I recently reformatted the drive. This command is to manually load the ntldr bootloader is it not? Then this will not tell me mutch about the geometry will it?

 

boot

Error 8: Kernel must be loaded before booting

possibly the same reason.

 

So what does this tell us? That this bios actually DOES use the 255/63 geometry?

 

*edit*

BTW while running this, the MBR according to jaclaz MBRview looks like:

 

 

 

Edited by Fiction, 05 February 2013 - 09:56 PM.

[steve6375]

It seems that way. The article states that ntldr not found occurs when the partition is within 1024/255/63 and the BIOS geometry does not match the parameters in the PBR.

The BIOS geometry seems to be 255/63.

So you need to generate the 'ntldr not found'  state on the USB drive and then look at the PBR heads/sectors values in the bootsect.dat (and the USB PBR too) or attach the file to a post.

[Wonko the Sane]

Hold your horses.
 
The chainloader /ntldr giving error 15 has NOTHING to do with geometry, MBR or PBR (it means that the file is NOT on the drive which is currently root)
 
try instead:
 
 

ls

 
and:
 
 

find --set-root /ntldr
root
ls

 
@Fiction
When talking of Partition Tables entries, the PTview is more suited   .
 

Wonko

[steve6375]

I have been experimenting with WinToFlash a little and written up my findings.

Please see tutorial 102

It shows how you can convert the USB stick to NTFS so that the Stage 1 text mode install will run faster.

[Fiction]

Thanks but I prefere FAT32 since it can be 'optimized for quick removal'.

 

@Wonko

 

The device was partitioned as follows:

bC 0

bH 1

bS 1

eC 470

eH 254

eS 63

Start 63

Num 7566552

 

You excel sheet suggested changing de eS 63 to eS 1, but this did not work (using tiny hexer). The table cell was coloured red, so perhaps this cell's value needs to stay 63 for compadibility reasons. My next try was:

 

I changed that (using tiny hexer) to

bC 0

bH 1

bS 1

eC 470

eH 254

eS 63

 

Start 63

Num 7566614

 

Since we did conclude earlier that there are 7579008 available sectors, so I thought this might work. It did not.

 

Is it actually possible to change these values using tiny hexer like i did, or am I supposed to reformat the thing afterwards?

[Wonko the Sane]

Well, you don't actually need the spreadsheet to verify a set of values (if you prefer, converting CHS to LBA is trivial, LBA to CHS is slightly more complex).

0/1/1 is LBA 63 

 

(470+1)=471

(254+1) =255

63=63

 

471*255*63=7566615 <- this is absolute end sector (i.e. it is the sector at offset 756614 or - if you prefer - there are 756614 sectors before this)

But there are 63 sectors before, so the size (number of sectors in the partition) is:

7566615-63=7566552

 

A balanced setup with 255/63 geometry is:

0/1/1 - 470/254/63 - 63/756552

 

And my spreadsheet does give these same values.

So, I am wondering if there is a misunderstanding somewhere.

 

Wonko

[Fiction]

What I did: I pasted 7566552 inside of (#0 LBA>CHS row of PTtables) the 'End addr LBA' column of the, this value is called 'num sectors' in PT view. The sheets suggested to me: 470/254/1 But displayed the 1 in red. I tried this and it did not work. Then I thought, perhas the red cell means it could couse some sort of problems for a value like that, so I filled in 470/254/63 in the CHS>LBA the LBA end adress became 7566614. However I now realize the 'LBA end adress should probbably be the absolute adress, not the relative one. The LBA value in PT view is relative then? I thought the sheets would be made so peaple could just copy stuff from PT view over. Appereantly I should have added the offset fist.

Anyway if that value is balanced, then I'm nowhere anyway, since these are the values the device had from the start, I'm possitive they do not work =/ Any idea what the bios might be doing, if the CHS would actually BE balanced, but would still not work?

 

*edit*

 

You add this '1' to the cylinders and the heads because they do start at 0, while the sectors start at 1?

 

*edit 2*

if i understand correctly now, the 'LBA end adress' as it is called in the sheet is the not just the absolute value, but the absolute value -1, because it is an adress and these start at 0?

Edited by Fiction, 06 February 2013 - 10:40 PM.

[steve6375]

@Fiction - did you take a look at my Tutorial 102? 

It has a way of avoiding using bootsect.dat and ntldr for the 1st stage Setup - thus no need to patch it and it should work on all systems.

re. using NTFS - in my case using standard FAT32, the copyfiles 1st stage took over 70 minutes - when I converted the same stick to NTFS, the same stage took 4 minutes!

[Wonko the Sane]

The columns of data that you actually have in a partition table are:

 

Type/Boot/bCyl/bHead/bSect/eCyl/eHead/eSect/Start Sector/Num Sectors

all the other ones are not there.

I think I can see the misunderstanding that happened.

 

The CHS data has two sets of values that are BOTH  "addresses" (the begin address and the end address, each one in CHS notation).

Each of the set of values identify a sector.

The LBA data has instead two values that are not addresses.

Start Sector (which is often referred to as "Sectors before") can be thought as an address, but as a matter of fact is the number of sectors before a given one.

Num Sectors is not an address at all, it is a quantity, the number of sectors included in the partition.

An LBA address is an offset (or if you prefer an address 0 based), whilst Start Sector (or "Sectors Before") represents also a LBA address, Num Sectors does not.

 

The first LBA sector in your partition is LBA sector 63 = Sectors Before 63 = Start Sector 63.

The last LBA sector in your partition is LBA sector 7556614 (i.e. 63+756652-1).

 

First sector in LBA notation is LBA 0, or if you prefer is the sector that has 0 sectors before it.

Second sector in LBA notation is LBA 1 (or the sector that has 1 sectors before it), etc.

64th sector (CHS 0/1/1) in LBA notation is LBA 63 (or the sector that has 63 sectors before it).

 

So you have something that starts on 64th sector (LBA 63), and is 756652 sectors long.

It's final LBA address will be 63+756652-1=7556614 (there are 7556614 sectors before it).

 

The CHS data in a partition table represent (both sets) addresses.

The LBA data in a partition table represent (respectively) an address (Start Sector) and a length (Num Sectors) <- it is not "pure" LBA data.

 

The three sets in the spreadsheet are needed because you can have:

• CHS address data (both addresses)
• LBA address data (both addresses) <- "pure" LBA data
• "NumSec" which are one address and one length. <- "mixed" LBA data as actually written in a partition table entry

 

The LBA data that you can read in (or want to write to) a partition table entry are "mixed" data, composed of one address and one length/extension.

 

I hope that now the idea is more clear. 

 

Wonko

 

 

 

 

 

 

[Fiction]

I think it is.

 

The last LBA sector in your partition is LBA sector 7556614 (i.e. 63+756652-1).

You mean the sector with 63+756652-1 sectors 'in front of it' right? That's where the '-1' comes from.

 

I think I already did understand most of the other stuff you just said, I just mixed up the 'Num sec' and 'lba end adress' columns while using the sheets.

This is why: I thought the sheets would be made in such a way, to allow data from PT view to be copied in directly. However, in PT view we have 'num sec' which is calculaded automatically by the sheets. In stead I need to fill in the 'lba end adress'. Which in this case would be numsec+63-1 indeed.

 

So now the sheets agree and 0\1\1 470\254\63 63\7566552 is 'balanced'. However I tried using this geometry a couple of times before. I'm quite sure this one does not work on the asus motherboard. But according to grub4dos the geometry the bios uses is 255\63 and we are using this now. So why won't it work? Is it possible this bios simply cannot use CHS properly altogether? How would I test this?

[Wonko the Sane]

I think it is.
 
You mean the sector with 63+756652-1 sectors 'in front of it' right? That's where the '-1' comes from.

Yes and no.
 
LBA addresses sectors with "base" 0.
In technical terms, this means that a LBA address is an offset.
In layman terms this equates to say that a LBA address is "how many sectors are before it".
 
When you count items, you start by 1.
The mentioned formula should actually be written as 63+(756652-1).
Example, imagine a (small) device made of 6 sectors:
1st sector is LBA 0 
2nd sector is LBA 1
3rd sector is LBA 2
4th sector is LBA 3
5th sector is LBA 4
6th sector is LBA 5
Imagine to have 1 hidden sector and two (very small) partitions, each two sectors long.
The length (extensions) will be:
Hidden sectors: 1
1st partition: 2
2nd partition: 2
Unused sectors: 1
1+2+2+1=6
 
The beginning of the hidden sectors is at LBA address 0.
The beginning (first sector) of the 1st partition is at LBA 1
The end (last sector) of the first partition is at LBA 2
The beginning (first sector) of the 2nd partition is at LBA 3.
The end (last sector) of the first partition is at LBA 4
 
In the partition table you will have this LBA data:
1st partition 1/2
2nd partition 3/2
 
The green numbers are already LBA addresses, the red ones are the extensions of the partitions.
 
CHS numbering uses for S numbering starting from 1, of course in this case Heads and Cylinders will be 0.
So you will have:
1st partition 0/0/2 - 0/0/3
2nd partition 0/0/4 - 0/0/5
these are ALL addresses,
If you want to know the extension of the partition from the CHS data, you need to:
1st partition 3-2+1=2
2nd partition 5-4+1=2
Because when you calculate the number of items in a range you have to add 1.
When yoy do the reverse, i.e. calculate an end of a range, as an address, you need to subtract it.
 
Back to main topic, now.
WHAT is the problem?
You have now a "balanced" CHS and LBA address.
This will allow to have *any* kind of BIOS that recognizes to that device a BIOS HS geometry of 255/63 to recognize the partition correctly, NO matter if it uses the CHS or the LBA data (or both) in the partition table.
NO doubt that *any* MBR code with this data will be able to get to the PBR or bootsector (BUT a number of BIOSes night have issues with the MBR code itself, as they "look for a given "pattern" in the CODE).
The usual recommendation is to use a "known" MBR code (like the "standard" DOS one or the "standard" Windows 2K/XP one).
The idea (mine) is that BIOS programmers with more than one neuron (but not exceeding the limit of two) while might have senselessly written some check on the code, has actually tested the bootability  with the most common MBR code found around.
See:
http://reboot.pro/to...d-i-have-found/
AND a number of BIOSes may NOT "like" USB devices bigger than (say) 256 Mb or 512 Mb or 1 Gb or 2 Gb (admittedly oldish motherboards only).
 
Let's say that the MBR code is executed correctly by the BIOS and that it will "land" on the right sector (the PBR or bootsector of first, active partition).
What code is there?
Which data is in the BPB (BIOS PARAMETER BLOCK)?
How these will result when combined with what the *whatever* the BIOS might (or might not) do?
In theory, the BIOS should have detected a HS geometry of 255/63, and if in the PBR BPB containf the same 255/63 everything should be fine and dandy.
But if either the HS geometry has been set by BIOS diffeerently or *something else* happened, a bootsector code that actually checks the HS data may be the reason for failure in booting.
And we get back to:
http://blog.clemens....ndows_3170.html
by removing the check for HS data in the bootsector, we remove this possibility, and only the "sectors before" field of the BPB is used (but still *something else* in the BIOS may happen).
So, the check is not performed, the partition start is set correctly, the next step is loading the operating system "system file" or bootloader/bootmanager.
And here there may be another hiccup, the code in this latter may (as an example) be unable to "find itself" if the file is positioned beyond a given "limit" (this could be one of the CHS limits, 4 Gb on CDFS or another arbitrary limit).
 
The "right" procedure (before entering "special" partitioning/formatting like fbinst might do or the three-ways approach and without using other "dedicated" apps) is the following:

• partition the stick from 2K/XP Disk Manager (you will need to install a filter driver) or use MBRBATCH or an image of the stick in a VM
• format the stick from 2K/XP
• copy to the newly made partition just NTLDR and BOOT.INI (the boot.ini needs to have at least two entries, I would suggest one of the two pointing to grldr (and add grldr to root also)
• try booting from it and see if you get to the BOOT.INI choices
• verify that the CHS and LBA are balanced (they will be)
• patch the bootsector code to remove the CHS check
• try booting from it and see if you get to the BOOT.INI choices
• patch the MBR with the HP Patch
• try booting from it and see if you get to the BOOT.INI choices

This is all you can do (again set aside "special" tools and approaches) to have a "most compatible" stick.
 
BUT (isn't there always a but) there might be still an issue, which is those BIOS that believe a stick to be a "hard disk like" device ONLY if they find in it's partition table TWO entries (two partitions).
 
So you need to actually (BTW this is what RMPREPUSB does) "shrink" a little bit the first partition and add a small "fake" partition, one cylinder in size (between steps #1 and #2 above).
You have now:
0/1/1 - 470/254/63 - 63/756552
this must be changed to:
0/1/1 - 469/254/63 - 63/7550487
470/0/1 - 470/254/63 -7550550/16065

 

Wonko

 

 

[Fiction]

partition the stick from 2K/XP Disk Manager (you will need to install a filter driver) or use MBRBATCH or an image of the stick in a VM

What is 'a filter driver' and how do I install it? And why should this format be done from inside 2K/XP?

try booting from it and see if you get to the BOOT.INI choices

I don't think there will be a different behaviour form how the device is formatted right now, wich is: it boots when the 4MBR bytes are patched, it does not when they are not.

 

... with the HP Patch

This is the same Patch as the one from Clemens? Why do you call it 'HP' then?

 

BTW the website states:

Instead of using the BIOS reported geometry to break the absolute sector down into its CHS components, the boot loader uses a geometry stored in the so called BIOS parameter block.

Does this mean there is a 'suggested geometry' for the bootloader to use, that might not nessisarily be 255/63, stored in te BPB. If so I should probbably check these value's first and perhaps change them to 255/63? As stated before: the device would boot fine when patching the 4 bytes.

I do not have access to the flashdrive right now but I'll have a look at this as soon as I get home.

So you need to actually (BTW this is what RMPREPUSB does) "shrink" a little bit the first partition and add a small "fake" partition, one cylinder in size (between steps #1 and #2 above).

I will try, but I dont think it will change anything, given that the CHS values happened to be correct in the first place, and I think WinToFlash does use this as well. And as stated before: this would not work. So I will try this, but it does not sound that promissing.

 

*edit*

If the BPB would be to blame, then wy would it work on a different pc in the first place, considering that the bootsector code points to/uses these value's?

Edited by Fiction, 08 February 2013 - 12:53 PM.

[Wonko the Sane]

Sometimes I feel like

 

You don't have to partition under 2K/XP, you can manually write the XP/2K MBR code and manually write the partition table entry(ies).

We have talked - I thought at length enough - about the 4 bytes patch "by Clemens" that is a patch to the PBR code and about the HP patch, which is 3 bytes and it is a patch to the (2K/XP) MBR code:

http://reboot.pro/to...board/?p=166219

 

Explanation:

On some BIOSes the booting does not "reach" the PBR unless the code is the "right" one AND the partitioning is the "right" one AND the MBR code is "patched".

 

In layman's terms, if you left your car parked for a few months AND you lost it's keys, your PRIMARY need is to find them keys, BEFORE checking if the battery is still live, or if you prefer, you solve issues in the order they present themselves.

 

The booting goes like this:

BIOS->MBR->PBR->System file or bootloader/bootmanager

 

If there is any issue when "jumping" from MBR to PBR, it makes little sense to have a patched PBR (that would theoretically work IF ONLY the booting could reach it).

 

Your particular BIOS, coupled with that particular stick, needs just the "ignore CHS", or "Clemens", or "4 byte patch to the PBR", another BIOS might NOT need it, but it might need the MBR patch (or the second fake partition or "balanced CHS/LBA", or *something else*).

 

The idea is all these "patches" and "settings/data" remain compatible with "good" BIOSes, whilst each of them addresses (and hopefully solves) a particular issue found with a specific BIOS.

 

For that specific BIOS, you evidently need only one of these (the "ignore CHS" patch), your specific issue is solved for that specific motherboard (which is good ), but the idea was to provide you with means to make the stick "more compatible" with "more motherboards", not just that specific one.

 

You chose the RED pill, remember?

 

Another couple rabbit holes:

http://homepage.ntlw...name-field.html

http://homepage.ntlw...eter-block.html

 

Wonko