Jump to content











Photo

How to boot Windows Installer/WTG through BIOS off GPT partitioned Removable USB Drive ?

gpt mbr bios uefi bootmgr grub4dos wtg

  • Please log in to reply
135 replies to this topic

#101 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15070 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 26 December 2018 - 10:18 AM

As said earlier, some OS have the access to the PBR protected, I don't remember the details, most probably you can put the disk offline and then write the created PBR, this happens in some cases since VISTA :ph34r::

http://reboot.pro/to...tfs-bootsector/

 

Since 7, if I recall correctly, one can put the disk offline (while keeping the possibility to directly write to it)

 

Then you copy the LBA2048Disk3.mod file produced by the batch to the PBR of the FAT32 partition

dsfi \\.\PhysicalDrive3 1048576 512 LBA2048Disk3.mod

 

Or you can boot to another grub4dos and use its dd to copy the PBR, given the disk is (hd0), and that the file is copied on (hdx,y)/LBA2048Disk3.mod that will be:

dd if=(hdx,y)/LBA2048Disk3.mod of=(hd0)2048+1 bs=512 count=1

or

dd if=(hdx,y)/LBA2048Disk3.mod of=(hd0,0)0+1 bs=512 count=1

 

:duff:

Wonko



#102 devdevadev

devdevadev

    Frequent Member

  • Advanced user
  • 477 posts
  •  
    India

Posted 26 December 2018 - 02:47 PM

http://reboot.pro/to...tfs-bootsector/

 

Since 7, if I recall correctly, one can put the disk offline (while keeping the possibility to directly write to it)

 

Then you copy the LBA2048Disk3.mod file produced by the batch to the PBR of the FAT32 partition

dsfi \\.\PhysicalDrive3 1048576 512 LBA2048Disk3.mod

Thanks....for the hint....

ECHO Writing new PBR ...
"%~dp0LockDismount.exe" -force %tdisk% dsfi \\.\PhysicalDrive%tdisk% 1048576 512 LBA2048Disk%tdisk%.mod
REM use touchdrv to ensure MBR changes are not removed by Windows!
touchdrv E:
ECHO.

Output-

Writing new PBR ...
Locking volume E: ...OK
Dismounting volume E: ...OK
Successfully locked and/or dismounted all volumes on PhysicalDrive3
Executing dsfi \\.\PhysicalDrive3 1048576 512 LBA2048Disk3.mod...

OK, written 512 bytes at offset 1048576

Exit Code: 0

Unlocking all volumes...OK

PBR (LBA2048Disk3.mod) successfully written in 32 GB GPT FAT32 Removable USB Drive within from Windows 10 RS5 1903 using following mkgrldrGPT.cmd

Spoiler

::let's write the optional BPB to the MBR (in order to have available as root (hd0) besides the GPT (hd0,0))
::this part can probably be REMmed out as it is not strictly needed
ECHO NOT Applying the BPB to the MBR ...
REM dsfi LBA0Disk%tdisk%.mod 0 87 LBA2048Disk%tdisk%.mod

Attached File  1.png   13.87KB   1 downloads

ECHO Applying the BPB to the MBR ...
dsfi LBA0Disk%tdisk%.mod 0 87 LBA2048Disk%tdisk%.mod

Attached File  2.png   41.02KB   0 downloads

 

In both cases root is (hd0,0) as default. If we to apply the BPB to the MBR then (hd0) also become available.

In which case (hd0) will be required as root ?

Does grub4dos treat (hd0) as superfloppy so that bootmgr can be chainloaded within from it in BIOS boot through GPT ?



#103 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15070 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 26 December 2018 - 10:21 PM

The MBR (intended as LBA0) can contain at the same time the information for 

1) a "superfloppy" this is a "chimera", the BPB is on LBA0, all the area up and including the "real" bootsector on sector 2048 AND what were before the "hidden sectors"  is mapped as "hidden sectors"

2) the (preexisting) GPT partitioned hard disk 

 

How the grub4dos (or anything else for that matters) maps the device may depend on a number of factors, including the particular BIOS and the size of the FAT32 partition (and probably some other things that I am not considering).

 

Since we don't know in advance how the device will be mapped, providing the BPB in the "double effect" MBR adds a possible way to access the contents of the device, but since without it the device is mapped correctly to first hard disk or (hd0) and the GPT partition in it correctly as (hd0,0), there is no need (nor any advantage or disadvantage) to write the BPB to the MBR. 

 

You know, like:

 

 

::let's write the optional BPB to the MBR (in order to have available as root (hd0) besides the GPT (hd0,0))
::this part can probably be REMmed out as it is not strictly needed

 

It is possible that till now that BIOS (when using the "underfloppy" method) mapped the device as (fd0) because the "perceived" size of the device was that of only 2048  (63+1985) sectors, and now, since the size of the "superfloppy" is much larger it automagically maps it as (hd0), the difference is that in the "underfloppy" method there is:

1) a hard disk like partition written on offset 414 and read ONLY by the booting code
2) a floppy like volume written to the BPB 

3) unless you write the 63-2047 partition to the GPT partition table, NO GPT mapped extents corresponding to the underfloppy

So, when it boots, the grub4dos has ONLY the information it can find in the BPB inside the MBR and thus it can only root to the whole "boot" device (that different BIOSes may map to first floppy (fd0) or to first hard disk (hd0)).

 

In this case there are:
1) a hard disk like partition written on offset 414 and read ONLY by the booting code

2) a floppy like volume written to the BPB 

3) a perfectly valid GPT partition covering exactly the same extents used in the booting code

So, when it boots the grub4dos has the information from the GPT partitoin table, and since it covers exactly the extents of the volume it was booted from "finds" it and establishes root to it.

 

But no, I don't think the BOOTMGR will treat something mapped as (hd0) as superfloppy, you will need to remap the (hd0,0) to (fd0) just like it was needed for doveman:

http://reboot.pro/to...otice/?p=208771

then it has to be seen if there are any issues with the size of this superfloppy. 

 

:duff:

Wonko



#104 devdevadev

devdevadev

    Frequent Member

  • Advanced user
  • 477 posts
  •  
    India

Posted 29 December 2018 - 10:12 PM

In this case there are:

1) a hard disk like partition written on offset 414 and read ONLY by the booting code

2) a floppy like volume written to the BPB 

3) a perfectly valid GPT partition covering exactly the same extents used in the booting code

So, when it boots the grub4dos has the information from the GPT partitoin table, and since it covers exactly the extents of the volume it was booted from "finds" it and establishes root to it.

I have created 4GiB FAT32 GPT (< 8.4GB limit) partition 1 in 4TB GPT USB-HDD 

PTN1:/grldr

and then applied mkgrldrGPT.cmd script without writing BPB to the MBR 

REM dsfi LBA0Disk%tdisk%.mod 0 87 LBA2048Disk%tdisk%.mod

and with writing BPB to the MBR also

dsfi LBA0Disk%tdisk%.mod 0 87 LBA2048Disk%tdisk%.mod

But in both cases Sony VAIO show following error message ?

 

Attached File  1.jpeg   124.23KB   0 downloads

 

Any idea why Grub4dos code in PBR unable to find PTN1:/grldr while PTN1 is within 8.4 GB limit ?

 

It's looking no method ( makebootfat , Syslinux, UMBR, Grub2, Clover) except underfloppy method will work in Sony VAIO BIOS ? 



#105 tinybit

tinybit

    Gold Member

  • Developer
  • 1158 posts
  •  
    China

Posted 31 December 2018 - 12:33 AM

grub4dos PBR boot-sector code may fail in one of these cases:

 

1.  One of the GRLDR occupied sectors is unaccesssible because of BIOS limit. The error message will be "Disk error".

 

2.  Wrong BPB in the partition's boot sector, especially the "hidden sectors" field. And, both the "number of heads" and the "number of sectors per track" must match your current BIOS. And the sector size must be 512 bytes with your current BIOS. In such cases (wrong or mismatching), it even cannot get the root directory, thus cannot find the GRLDR entry. The message will say "NO GRLDR".

 

3.  The code (that calls/invokes the grub4dos PBR) did not setup the correct drive number. If the BIOS drive number is 0 (for floppy), the DL register must set to 0 before the PBR code gains control. If it was incorrectly set to 0x80, then the PBR code will try to load the GRLDR sectors from the hard drive. Generally the hard drive is large enough. So you would not get "disk error". But it will say "NO GRLDR", because the PBR code is designed to look for GRLDR in the partition that owns the same PBR sector.

 

4.  An old buggy version of grub4dos PBR was used. In such a case, it might say "Disk error" or "NO GRLDR", or even hang up without any message.

 

For details of BPB fields, refer to grub4dos readme.

 

 

EDIT: OK, for FAT32, here it is:

 

I should/must add a note for "hidden sectors" field (offset 1Ch):

 

if , and only if, this boot sector (PBR or say VBR) is LBA 0, then hidden sectors = 0. Generally, if this boot sector (PBR/VBR) is LBA XXXXXXXX, then hidden sectors should/must be exactly the same value as XXXXXXXX

 

 

3. FAT32 Boot Sector/Boot Record Layout (for loading grldr)
------------------------------------------------------------------------------
A FAT32 volume can be GRUB-bootable. Copy grldr and an optional menu.lst to
the root dir of the FAT32 volume, The first sector in accordance with grldr.dbr,
Create a boot sector. And then the FAT32 volume is GRUB-bootable.

Update:    bootlace.com is a DOS/Linux utility that can install the GRLDR boot
record onto the boot sector of an FAT32 volume.

Offset    Length    Description
======    ======    ==============================================================
00h    2    Machine code for short jump over the data.

02h    1    0x90

        Update(2006-07-31): Though GRLDR won't use this LBA-indicator
        byte, Windows 98 uses it. Usually this byte should be 0x90 for
        CHS mode(especially for floppies). If this byte is not set
        properly, Windows 98 will not recognize the floppy or
        partition. This problem was reported by neiljoy. Many thanks!

03h    8    OEM name string (of OS which formatted the disk).

0Bh    2    Bytes per sector. Must be 512.

0Dh    1    Sectors per cluster. Valid values are 1, 2, 4, 8, 16, 32, 64
        and 128. But a cluster size larger than 32K should not occur.

0Eh    2    Reserved sectors(number of sectors before the first FAT,
        including the boot sector), usually 1.

10h    1    Number of FATs(nearly always 2).

11h    2    (Maximum number of root directory entries)Must be 0.

13h    2    (Total number of sectors for small disks only)Must be 0.

15h    1    Media descriptor byte, pretty meaningless now (see below).

16h    2    (Sectors per FAT)Must be 0.

18h    2    Sectors per track.

1Ah    2    Total number of heads/sides.

1Ch    4    Number of hidden sectors (those preceding the boot sector).

        Also referred to as the starting sector of the partition.

        For floppies, it should be 0.

 

20h    4    Total number of sectors for large disks.

24h    4    FAT32 sectors per FAT.

28h    2    If bit 7 is clear then all FATs are updated, otherwise bits
        0-3 give the current active FAT, all other bits are reserved.

2Ah    2    High byte is major revision number, low byte is minor revision
        number, currently both are 0.

2Ch    4    Root directory starting cluster.

30h    2    File system information sector.

32h    2    If non-zero this gives the sector which holds a copy of the
        boot record, usually 6.

34h    12    Reserved, set to 0.

40h    1    BIOS drive number of the boot device.

        80h is first HDD, 00h is first FDD.

        Actually this byte is ignored for read. The boot code will
        write DL onto this byte. The BIOS or the caller should set
        drive number in
DL.

        We assume all BIOSes pass correct drive number in DL.
        Buggy BIOSes are not supported!!


41h    1    Partition number of this filesystem in the boot drive.

        This byte is ignored for read. The boot code will write
        partition number onto this byte. See offset 5Dh below.
        Update: This field is ignored

42h    1    Signature (must be 28h or 29h to be recognised by NT).

43h    4    Volume serial number.

47h    11    Volume label.

52h    8    File system ID. "FAT32   ".

5Ah    418    The rest of the machine code.

1FCh    4    Boot Signature AA550000h. (Win9x uses 4 bytes as magic value)

 


  • wimb likes this

#106 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15070 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 03 January 2019 - 09:15 AM

I have created ...

 
And - as always - you completely fail to post the relevant info. :frusty:
 
In post #102 the device was mapped as (hd0) or (hd0,0).
 
In post #104 suddenly a "(fd0) comes out of NOWHERE.
 
Did this change because you changed the size of the partition to 4 GB?
And WHY exactly did you change it?
And WHY exactly did you change it to (roughly) 4 GB?
 
Anyway, you can try using:
1) the newest FAT32 bootsector for grub4dos, you can extract it from the grldr.pbr:
http://reboot.pro/to...nd-gpt-support/
http://reboot.pro/to...pport/?p=208507
2) the "standard" Windows FAT32 bootsector (the one invoking NTLDR, aka bootsect /NT52) renaming grldr to ntldr
 
Besides, please consider how in the batch the whole BPB is copied from the existing one:

::let's create the new FAT32 PBR invoking grldr
::BPB first
IF EXIST LBA2048BPBDisk%tdisk%.ori DEL LBA2048BPBDisk%tdisk%.ori
ECHO Creating the BPB file LBA2048BPBDisk%tdisk%.ori
dsfo LBA2048Disk%tdisk%.ori 11 87 LBA2048BPBDisk%tdisk%.ori
ECHO.

::copy of GRLDR FAT32 bootsector
IF EXIST LBA2048Disk%tdisk%.mod DEL LBA2048Disk%tdisk%.mod
ECHO Creating the new PBR file LBA2048Disk%tdisk%.mod from template
dsfo FAT32grldr.bss 0 512 LBA2048Disk%tdisk%.mod
ECHO.

::replace BPB
ECHO Applying the BPB to the PBR ...
dsfi LBA2048Disk%tdisk%.mod 11 87 LBA2048BPBDisk%tdisk%.ori
ECHO.

 
so, it is possible that some parameters (namely the disk number, 0x80 for hard disk or 0x00 for floppy at offset 0x40) may need to be changed.
 
:duff:
Wonko

#107 devdevadev

devdevadev

    Frequent Member

  • Advanced user
  • 477 posts
  •  
    India

Posted 03 January 2019 - 04:22 PM

In post #102 the device was mapped as (hd0) or (hd0,0).

in post #102, Focus was how (LBA2048Disk3.mod) will be successfully written in PBR so I have used 32 GB GPT FAT32 Removable USB Drive (NOT 4TB GPT USB-HDDto test updated mkgrldrGPT.cmd in Windows 10 RS5 1903 . AND the device was mapped as (hd0) or (hd0,0) because test was done in QEMU (I think VAIO bios will also map the device as (hd0) or (hd0,0) because it treat 32GB GPT Removable USB Drive normally but it's behavior changed for 4TB GPT USB-HDD).

 

In post #104 suddenly a "(fd0) comes out of NOWHERE.
 
Did this change because you changed the size of the partition to 4 GB?
And WHY exactly did you change it?
And WHY exactly did you change it to (roughly) 4 GB?

In post #104, I was testing in 4TB GPT USB-HDD, It's WHY I got FDD - "NO GRLDR" error message.. I thought it will be nice to First test in 4 GB FAT32 GPT PTN1 so that PBR Grub4dos code can easily find and load PTN1:/grldr without any issue of 8.4 GB limit. And if it worked then I would test in 29 GB FAT32 GPT PTN1. But test become failed....!!!

 

so, it is possible that some parameters (namely the disk number, 0x80 for hard disk or 0x00 for floppy at offset 0x40) may need to be changed.



#108 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15070 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 03 January 2019 - 07:30 PM

Hmmm.

 

In post #102 focus was seemingly not on the success on testing another device in another system (QEMU, BTW without saying that), the focus was IMHO on the questions you asked in it:

 

 

In both cases root is (hd0,0) as default. If we to apply the BPB to the MBR then (hd0) also become available.

In which case (hd0) will be required as root ?

Does grub4dos treat (hd0) as superfloppy so that bootmgr can be chainloaded within from it in BIOS boot through GPT ?

 

Anyway, the given (suggested) things to try still stand:

 

 

 
Anyway, you can try using:
1) the newest FAT32 bootsector for grub4dos, you can extract it from the grldr.pbr:
http://reboot.pro/to...nd-gpt-support/
http://reboot.pro/to...pport/?p=208507
2) the "standard" Windows FAT32 bootsector (the one invoking NTLDR, aka bootsect /NT52) renaming grldr to ntldr

 

:duff:

Wonko



#109 cdob

cdob

    Gold Member

  • Expert
  • 1440 posts

Posted 03 January 2019 - 10:37 PM

Sorry, heaily truncated quote. What about another approach? Given a BIOS, try MBR.

It's looking no method ... will work in Sony VAIO BIOS ?

.
Actually I wonder:
How behave the Sony VAIO BIOS given a 4 TB USB MBR disk? That'a not a GPT disk.
Oboiously a 4 TB USB is not supported by the manufacturer, try the behaviour.
Does the VAIO BIOS map a floppy still? Does the VAIO BIOS map the hard disk to a hard disk?
Create up to three MBR partitions withing first 2 TB. Bootable within 8 GB up to 2 TB?
And add a data partition from 2 TB to 4 TB.

#110 devdevadev

devdevadev

    Frequent Member

  • Advanced user
  • 477 posts
  •  
    India

Posted 04 January 2019 - 03:23 PM

Create up to three MBR partitions withing first 2 TB. Bootable within 8 GB up to 2 TB?
And add a data partition from 2 TB to 4 TB.

:offtopic:

OK...I will use MBR4TB to create the last partition starting at 2097151 MB upto 4TB on disk.

AFAIK, We can use Disk Management and diskpart to create upto 3 partitions in the first 2TB area on the disk. 

Now tell me how many total partitions I should create in first 2TB area on the disk size wise.

At least suggest me sizes of first two partitions in first 2TB area on the disk ....

After creating MBR partitions should I install Grub4dos in MBR sector to see if Grub4dos show disk as floppy or harddisk....  



#111 cdob

cdob

    Gold Member

  • Expert
  • 1440 posts

Posted 04 January 2019 - 05:00 PM

Make small steps and validate the result. Start with a single 4 GiB partition.
Add grub4dos. Boot from the hard disk at the VAIO.
Does grub4dos boot? Open command line and check the mapping.
Again small steps, try grub4dos to PBR first. And grub4dos to MBR next.

#112 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15070 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 04 January 2019 - 06:28 PM

Ok.

I am lost [1].

 

This thread started with:

How to boot Windows Installer/WTG through BIOS off GPT partitioned Removable USB Drive ?

 

Then as soon as that was (almost or fully :dubbio:) solved, it became:

How to boot Windows Installer/WTG through BIOS off GPT partitioned Removable USB Drive ? BUT NOT using the given solution that actually works

 

Around here:

http://reboot.pro/to...drive/?p=208760

 

And now, before and without having finalized the other experiments, it becomes:

How to boot Windows Installer/WTG through BIOS off NON GPT partitioned but rather MBR partitioned [2] Removable USB Drive ?

 

:duff:

Wonko

 

[1] Actually not lost, I know perfectly where I am (and also where my towel is ;)) but lost view of the actual goal 

[2] Using a very experimental and not properly/fully tested approach, originally intended (i should know as AFAICT I was the first one to propose it) here:

https://msfn.org/boa...comment=1135913

and later tested briefly starting here:

https://msfn.org/boa...comment=1142727

more as a POC than anything else



#113 devdevadev

devdevadev

    Frequent Member

  • Advanced user
  • 477 posts
  •  
    India

Posted 05 January 2019 - 02:42 AM

Anyway, you can try using:
1) the newest FAT32 bootsector for grub4dos, you can extract it from the grldr.pbr:
http://reboot.pro/to...nd-gpt-support/
http://reboot.pro/to...pport/?p=208507

3. FAT32 boot sector / boot record layout (for loading grldr)

-------------------------------------------------- ----------------------------
A FAT32 volume is GRUB bootable. Copy grldr and optional menu.lst file to the root of this FAT32 volume
Directory, and build its boot sector according to the first sector of grldr.pbr. Then this FAT32 volume is GRUB bootable.

I have tried to extract First Sector of grldr.pbr using

dsfo grldr.pbr 0 512 LBA2048Disk%tdisk%.mod

But got strange screen in QEMU...

 

Attached File  1.png   26.56KB   0 downloads

 

Can anybody please tell me how EXACTLY we will extract newest FAT32 bootsector for grub4dos from the grldr.pbr ?

 

I know " bootsect /nt52 U: /force " will be more simple (and working also for 32 GB FAT32 GPT Removable USB Drive) way but I am curious about real usage of first sector of grldr.pbr. Will be nice if one can provide newest FAT32 bootsector for grub4dos from the first sector of grldr.pbr .

 

Regards...



#114 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15070 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 05 January 2019 - 02:31 PM

Have you updated the BPB to the actual real values of your volume?

 

There is a difference between the "old" PBR and the new one.

 

The old one started with the OEM field filled with "GRLDR   ", the new one has the field filled with 0.

 

This shouldn't actually affect the booting :unsure:, but maybe it does. :dubbio:

 

Anyway, post the bootsector you are using.

 

:duff:

Wonko



#115 devdevadev

devdevadev

    Frequent Member

  • Advanced user
  • 477 posts
  •  
    India

Posted 05 January 2019 - 06:08 PM

Does the VAIO BIOS map a floppy still? Does the VAIO BIOS map the hard disk to a hard disk?

 

Make small steps and validate the result. Start with a single 4 GiB partition.
Add grub4dos. Boot from the hard disk at the VAIO.
Does grub4dos boot? Open command line and check the mapping.

First I have created 4GiB FAT32 Partition 1 and 50GiB NTFS Partition 2 in 4TB MBR USB-HDD. And then installed Grub4dos to MBR using RMprepUSB tool. Still VAIO BIOS treat 4TB MBR USB-HDD as floppy.

 

Attached File  1.jpeg   159.73KB   0 downloads

 

Again small steps, try grub4dos to PBR first.

Re-created 4GiB FAT32 Partition 1 and 50GiB NTFS Partition 2 in 4TB MBR USB-HDD. And then installed Grub4dos to 

PBR first. Have to make 4GB FAT32 Partition 1 as ACTIVE using DISKPART (Disk Mgmt was unable to make it ACTIVE ?) to boot in QEMU. But got following error message when booted in VAIO BIOS.

 

Attached File  2.jpeg   107KB   0 downloads

 

 And grub4dos to MBR next.

After installing PBR, I have also installed Grub4dos in MBR using RMprepUSB tool.... and Grub4dos booted fine as follows....

 

Attached File  3.jpeg   181.1KB   0 downloads Attached File  4.jpeg   170.64KB   0 downloads                 Attached File  5.jpeg   132.12KB   0 downloads Attached File  6.jpeg   138.13KB   0 downloads

 

Grub4dos can access 50GB NTFS Partition 2 only if I execute usb --init command.



#116 devdevadev

devdevadev

    Frequent Member

  • Advanced user
  • 477 posts
  •  
    India

Posted 05 January 2019 - 07:03 PM

Have you updated the BPB to the actual real values of your volume?

Spoiler

 

Anyway, post the bootsector you are using.

Attached File  LBA2048Disk3.zip   604bytes   1 downloads



#117 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15070 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 06 January 2019 - 11:32 AM

I see, there are a few mistakes in the batch :w00t: :ph34r:.

 

The BPB for FAT32 is - strictly speaking - 60 bytes:

https://thestarman.p...AT32brHexEd.htm

but it is prepended by (besides the 3 "jump bytes", or more properly by the 2 "jump bytes" + 1 NOP) the "System Volume" field, 8 bytes, and followed by the "Volume Label", 11 bytes (which is not really-really used) and by the "System ID", 8 bytes, so:

Offset 0, length 3 "Jump Bytes" <- NOT part of the BPB

BPB (loosely speaking):

Offset 3, length 8 "System Volume"
Offset 11, length 60 "BPB data (strictly speaking)"

Offfset 71, length 11 "Volume Label"

Offset 82, length 8 "System ID"

 

The "whole stuff" is either 90 bytes starting at offset 0 or 87 bytes starting at offset 3 if we exclude the "Jump Bytes".

 

For *some reasons* :ermm: , in the batch:

dsfo LBA2048Disk%tdisk%.ori 11 87 LBA2048BPBDisk%tdisk%.ori

I was taking the data without the "System Volume" (it was already set in the destination as "GRLDR   ") AND taking more length than needed[1], that should become:

dsfo LBA2048Disk%tdisk%.ori 3 87 LBA2048BPBDisk%tdisk%.ori

 

And later, inserted the data in a wrong way:

dsfi LBA2048Disk%tdisk%.mod 11 87 LBA2048BPBDisk%tdisk%.ori

should become:

dsfi LBA2048Disk%tdisk%.mod 3 87 LBA2048BPBDisk%tdisk%.ori

 

And, later:

dsfi LBA0Disk%tdisk%.mod 0 87 LBA2048Disk%tdisk%.mod

should become:

dsfi LBA0Disk%tdisk%.mod 0 90 LBA2048Disk%tdisk%.mod

 

Try again with these modifications, or try using the attached ".mod.mod" bootsector.

 

:duff:

Wonko

 

 

 

[1] That, with the old grubdos PBR code didn't cause corruption as the actual booting code substantially began at offset 101, but in the new PBR code it really starts at offset 90 (or 92, the initial FAFC can evidently be skipped)

 

Attached Files


  • devdevadev likes this

#118 devdevadev

devdevadev

    Frequent Member

  • Advanced user
  • 477 posts
  •  
    India

Posted 06 January 2019 - 05:22 PM

2) the "standard" Windows FAT32 bootsector (the one invoking NTLDR, aka bootsect /NT52) renaming grldr to ntldr

NTLDR.cmd

Spoiler

I have tested above NTLDR.cmd in 4GB FAT32 Partition of 4TB GPT USB-HDD in Sony VAIO BIOS. But no luck...

 

Attached File  1.jpeg   119.5KB   0 downloads

 

Why getting this FDD error while 4GB Partition is within 8.4GB limit boundary ?  

Does "standard" Windows FAT32 bootsector not support GPT Partition ?

 

Try again with these modifications, or try using the attached ".mod.mod" bootsector.

PBR.cmd

Spoiler

Wow...

When I have tested above PBR.cmd in 4GB FAT32 Partition of 4TB GPT USB-HDD in Sony VAIO BIOS. It booted to Grub4dos just fine. But what is (fd0,32) in following screenshot. 

 

Attached File  2.jpeg   175.87KB   0 downloads   Attached File  3.jpeg   184.56KB   0 downloads



#119 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15070 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 06 January 2019 - 07:07 PM

Why getting this FDD error while 4GB Partition is within 8.4GB limit boundary ?  

Does "standard" Windows FAT32 bootsector not support GPT Partition ?

It could be a number of reasons, including the known issue with CHS/LBA access, you might need to patch the bootsector code to only use LBA? :unsure:

Or maybe in the case of the original MS bootsector you actually need to have the BPB copied in the MBR? :dubbio:

Or, as hinted here:

http://reboot.pro/to...drive/?p=208842

the drive number actually matters (it should be 0x80 in the BPB, but sinc the stupid BIOS maps the thingy as fd0, it may be needed a 0x00 instead).

 

Really, you are never happy :w00t:, you were given two possible alternatives to try, one seemingly works just fine (almost), why do you focus to the one that doesn't work? :frusty:

 

Anyway, no particular idea about the (fd0,32), it is probably an "artefact" of some kind.

 

I am much more perplexed by the fails in

root 

and in

ls (fd0)

maybe there is still something wrong in the batch?

 

Post BOTH the MBR and PBR, maybe I can find something that isn't like it should. :dubbio:

 

:duff:

Wonko



#120 devdevadev

devdevadev

    Frequent Member

  • Advanced user
  • 477 posts
  •  
    India

Posted 07 January 2019 - 01:50 AM

Post BOTH the MBR and PBR, maybe I can find something that isn't like it should. :dubbio:

Attached File  LBA0Disk1.zip   577bytes   1 downloads

Attached File  LBA2048Disk1.zip   606bytes   1 downloads



#121 tinybit

tinybit

    Gold Member

  • Developer
  • 1158 posts
  •  
    China

Posted 07 January 2019 - 05:33 AM

The screen shot ideally shows "LBA", compared to the previous "CHS". Is it just because you used "usb --init" ?



#122 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15070 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 07 January 2019 - 08:36 AM

The batch - having been originally intended for smallish "EFISYS" volumes (100/200/300 MB) - was made with the assumption that the number of "Reserved sectors" was max 255:

::Set the reserved sectors to current value+2048
::Here we assume that the number of reserved sectors are originally less than 255
ECHO Increasing Reserved Sectors +2048
hexalter LBA0Disk%tdisk%.mod 15=0x08
ECHO.


Since the original "Reserved sectors" in your stupidly large partition is seemingly 0x1800 = 6144 the number of "Reserved sectors" in the BPB in the MBR is wrong (as it comes out as simply 0x0800 = 2048).
 
It is needed to replace in the batch the simple hexalter line with some commands that read the value (0x1800 in this case), sum to it the actual offset to the volume (0x0800 in this case), convert the result 6144+2048=8192 to hex 0x2000 and then write the bytes in the MBR.
 
For this test (and for this test only) you can write:
0x20 at offset 0x0F, i.e.:
 

::Set the reserved sectors to current value+2048
::Here we assume that the number of reserved sectors are originally less than 255
ECHO Increasing Reserved Sectors +2048
REM hexalter LBA0Disk%tdisk%.mod 15=0x08
::For this test only we write the specific value
hexalter LBA0Disk%tdisk%.mod 15=0x20
ECHO.


And try again.
The:
root
and
ls (fd0)
commands should work, no idea if this will solve the (fd0,32) issue.

:duff:
Wonko

#123 devdevadev

devdevadev

    Frequent Member

  • Advanced user
  • 477 posts
  •  
    India

Posted 07 January 2019 - 05:49 PM

The screen shot ideally shows "LBA", compared to the previous "CHS". Is it just because you used "usb --init" ?

Thanks...I had used ''usb --init'' by mistake in between....Following screenshots are without using it..... 

 

For this test (and for this test only) you can write:
0x20 at offset 0x0F, i.e.:
 

And try again.
The:
root
and
ls (fd0)
commands should work, no idea if this will solve the (fd0,32) issue.

Spoiler

 

Attached File  1.jpeg   168.08KB   0 downloadsAttached File  2.jpeg   182.42KB   0 downloadsAttached File  3.jpeg   188.27KB   0 downloadsAttached File  4.jpeg   203.13KB   0 downloads

Attached File  LBA0Disk1.zip   577bytes   1 downloads

Attached File  LBA2048Disk1.zip   606bytes   1 downloads



#124 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15070 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 07 January 2019 - 06:47 PM

Well, now everything is fine and it works, probably as much as it can work.

Now you have both the (fd0) and (fd0,0) working in the same way.

It is entirely possible that unlike what normally happens the (fd0) is not automatically set as root because it is too large. :unsure:

You should be able to manually root to either (fd0) or (fd0,0).

The (fd0,32) is clearly an artifact of some kind, but it doesn't seemingly cause any particular issue.

You can now try to have not the BPB in the MBR, so that you don't have anymore the (fd0) accessible, as said before it was just a way to have (in case of need) access to the files should there be any issues with (hd0,0) (fd0,0) in your case.

 

:duff:

Wonko
 



#125 devdevadev

devdevadev

    Frequent Member

  • Advanced user
  • 477 posts
  •  
    India

Posted 07 January 2019 - 07:02 PM

You can now try to have not the BPB in the MBR, so that you don't have anymore the (fd0) accessible, as said before it was just a way to have (in case of need) access to the files should there be any issues with (hd0,0) (fd0,0) in your case.

::let's write the optional BPB to the MBR (in order to have available as root (hd0) besides the GPT (hd0,0))
::this part can probably be REMmed out as it is not strictly needed
ECHO Applying the BPB to the MBR ...
REM dsfi LBA0Disk%tdisk%.mod 0 90 LBA2048Disk%tdisk%.mod
ECHO.

I had also tested by REMed out above code but no luck here...

 

Attached File  5.jpeg   141.64KB   0 downloads 







Also tagged with one or more of these keywords: gpt, mbr, bios, uefi, bootmgr, grub4dos, wtg

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users