Hello dear guest!

Boot Land is a community driven pc software site established since 2006 and focused on recovery/backup boot disks, research of Microsoft Windows 2000/XP/2003/Vista/7 install/deployment/lease/antivirus/antispam tools, customizing Microsoft Windows PE administration systems and even learning how to recover computer data from disaster situations!

How about joining our boot disk community? So do it. Life's short!

  - You get free access to our newsletter with all the interesting buzz about boot disks
  - We share publicity revenue with everyone who wishes to participate at the forums
  - Publicity is never, never, never displayed to members (along with many other cool things)
http://boot-land.net/register


karyonix

Members

***

Joined: 5-March 08
Profile Views: 40*
Last Seen: Today, 07:04 PM
Local Time: Jun 17 2010, 06:48 AM 251 posts (0.3 per day)

karyonix doesn't have a personal statement currently.

Profile
Personal Photo
Personal Info
Contact Information

 

karyonix
Frequent Member
27 years old
Male
Location Unknown
Born Aug-16-1982
AIM No Information
Yahoo No Information
ICQ No Information
MSN No Information
Contact Send Message
Contact Private

Topics
Posts
About Me
Files E2T
Comments
Friends
My Content
15 Jun 2010
Read Topic
Feature request: Non-contiguous map and more information in int13 handler
Here is some ideas for improvement of map command.
  • Currently, Grub4dos map command without --mem cannot map non-contiguous (fragmented) files.
    It will be easier for the users if Grub4dos can map these files.
    I think implementing this feature will not take a long time.
    But data structure of int13_handler will be different from prior version.
    If we change data structure, it may be incompatible with other programs or drivers that read data in Grub4dos int13_handler.
    drive map slot structure is here. It has only 8 slots. Each slot is 24 bytes long.
    We want to map non-contiguous file. The file may have many fragments. A variable-sized data area is desirable.
  • To use sector-mapped drives in protected mode OS, driver needs to know which drives the files are on.
    GRUB4DOS int13_handler read/write backing disk through BIOS. It only need BIOS drive number of backing disk.
    In protected mode OS, sector-mapped drives driver access the underlying disk through other drivers. It need more information to identify which drive the mapped file is on.
  • Using the sector-mapped drives after filesystem mount the backing volumes can cause loss of data if driver doesn't co-ordinate with filesystem driver properly.
    Protected mode driver for sector-mapped drives needs file paths to make sure the backing files are not moved around the disk while they are mounted or to switches mode from sector-mapped drives to file-mapped drives.
    Driver also needs information to identify volumes that backing files are on.

I think I will add variable-sized data to the end of int13_handler when hooked and have a pointer in data area around safeint13 structure point to this data.
It should contain the following information.
  • Size of data
  • Number of mapped drives.
  • Offset of additional user specified string (2 byte)
  • Drive map entry for each mapped drive
    • Size of drive map entry.
    • Drive number that caller of int13_handler will use when it call int13_handler.
    • Drive number that int13_handler will use when it call BIOS or next int13 routine.
    • Flags
    • Virtual drive size (512-byte sectors) (8 bytes)
    • Virtual drive type and geometry (4 byte)
      • type 1 byte, log2sectorsize 1 byte, sectors/track 1 byte, (heads/cyl-1) 1 byte
    • Backing drive type and geometry (4 byte)
      • type 1 byte, log2sectorsize 1 byte, sectors/track 1 byte, (heads/cyl-1) 1 byte
    • Offset of drive identification information (2 bytes)
    • Offset of additional user-specified string (2 bytes)
    • Number of fragment
    • For each fragment
      • Size of fragment (sectors) (8 bytes)
      • Logical block address of fragment in backing disk (sectors) (8 bytes)
    • Ending fragment
    • Backing physical drive identification information (BIOS drive)
      • Disk
        • Sum of 128 32-bit integers in first sector (4 bytes)
        • Unpartitioned disk : filesystem volume serial number or UUID (16 bytes)
        • MBR disk : MBR disk signature (4 bytes from offset 0x1B8 of sector LBA0)
        • GPT disk : disk id (16 bytes from offset 0x38 of sector LBA1)
      • CDROM
        • ISO9660 volume id (32 bytes from offset 0x28 of primary volume descriptor at sector 16)
    • Backing volume identification information (innermost volume in case of nested map)
      • Disk
        • Partition identification
          • Unpartitioned disk:
            • Zero
          • MBR disk partition:
            • MBR signature (4 bytes)
            • Partition start offset in bytes (8 bytes)
          • GPT disk partition:
            • GPT partition id (16 bytes)
        • Filesystem volume serial number or UUID (16 bytes)
          • FAT volume serial number (4 bytes)
          • NTFS volume serial number (8 bytes)
          • Ext2 volume UUID (16 bytes)
      • CDROM
        • ISO9660 volume id (32 bytes from offset 0x28 of primary volume descriptor at sector 16)
    • File path (inside backing volume)
      length of string (2 byte), string (2 byte/character), null character
    • Additional user-specified string for each mapped drive
      length of string (2 byte), string (2 byte/character), null character
    • Padding to 16-byte boundary
  • Additional user-specified string
    length of string (2 byte), string (2 byte/character), null character


While GRUB4DOS is running it must have a working copy of these data, separated from hooked int13_handler data.
Where in memory should we use for storing this variable-sized data ?
I think we may limit its size to less than 64KB.
13 Jun 2010
Read Topic
USB BIOS 128GB size limit
I just discover the size limit of USB functionality of my computer BIOS while testing booting from USB hard disk.
When GRUB4DOS read data (through BIOS) beyond the limit it does not show any error message. It just give me corrupted data.
It take me whole day to find out the limit. It's 0x10000000 sectors = 128GB.
When my docking station (with 250GB or 640GB hard disk) is connected with SATA, GRUB4DOS can read data (through BIOS) beyond 128GB correctly.
Windows can access the data on whole disk when the docking station is connected with either USB or SATA, so I think it is not docking station's limit. It is BIOS' limit.

My motherboard is ASUS P5Q PRO (chipset Intel P45 ICH10R). It is not old.
It's a surprise to see this small USB size limit while SATA (on same motherboard) does not have the same limit.
This problem may affect other people too.
23 Jan 2010
Read Topic
Windows 7 RC x86 in 4.75 GB RAM disk
I installed 8GB RAM in my computer and used GRUB4DOS to check size of RAM regions.
CODE
grub> displaymem
....
Usable RAM: Base: 0x100000000, Length: 0x130000000

The length of Usable RAM range at address 4G is 0x130000000 = 5100273664 or 4864M (or 4096M+768M).
I want to create RAM drive that ALMOST FILL UP this range.

The current GRUB4DOS map --mem will allocate RAM with 4KB granularity.
The maximum size that will not fill up the entire range is (4864M - 4K).

I will create image file in fixed size VHD format for ease of use.
Fixed size VHD have 512byte footer. The footer will be included in GRUB4DOS mapped drive.
Maximum size for disk area inside VHD is (4864M - 4K - 512).
If one partition is create at sector LBA 1, maximum partition size is (4864M - 5K).

I chose simple numbers that will be easy to remember/calculate for disk size and partition size.
Virtual disk size will be 4863M=9959424 sectors
with one active partition at offset 1M=2048 sectors and size 4862M=9957376 sectors.
Including footer, VHD file size will be (4863M+512).
When loaded by map --mem it will use (4863M+4K) bytes, leaving 1020K unused RAM above address 4G.

Windows 7 RC 32-bit Setup require 8???M free space in Windows partition, so I needed larger virtual disk.
I used diskpart in Windows 7 to create 9000MB fixed-size VHD and create active primary partition.
CODE
C:\>diskpart
DISKPART> create vdisk file="c:\data\vw7.vhd" maximum=9000
DISKPART> attach vdisk
DISKPART> convert mbr
DISKPART> create partition primary
DISKPART> format fs=ntfs unit=4096 quick label="vw7"
DISKPART> active
DISKPART> detach vdisk

I examined its partition table. The partition size was 8998M.
I will have to shrink it 4136M after setup to get the desired size 4862M.

I added vw7.vhd to VirtualBox and attach it to a virtual machine.
DVD drive of virtual machine is set to Windows 7 RC 32-bit Setup ISO.
I chose Custom (advanced) installation type and select Disk 0 Partition 1: vw7.

After setup reboot, I made it boot from DVD again and pressed Shift+F10 to bring up cmd.exe.
CODE
dir c:\

It has 3986141184 bytes free.
The used space is approximately 5197M. I have to decrease the used space by approximately 350M to get below 4862M.
CODE
c:\windows\system32\compact.exe /?
c:\windows\system32\compact.exe /c /s:c:\windows\winsxs /a /i

4,139,460,144 total bytes of data are stored in 2,887,118,792 bytes.
CODE
dir c:\

5,174,657,024 bytes free
It looks good.

I rebooted virtual machine, booted from hard disk, continue setup.
After Windows desktop appeared, I checked c:\ and found large 1GB page file. It is too larged.
I openned Advanced system settings, decrease paging file size for C: to 200MB and restarted.
After restart I ran diskpart.
CODE
DISKPART> selct disk 0
DISKPART> select partition 1
DISKPART> shrink querymax
The maximum number of reclaimable bytes is: 3886 MB

Not good.
I changed paging file size to 20MB and tried again, reclaimable bytes was 3866 MB. Not good.

I restarted again and boot from Windows Setup DVD.
Pressed Shift+F10 to open cmd.exe.
CODE
dir /a c:\
del /a c:\pagefile.sys
diskpart
DISKPART> select disk 0
DISKPART> select partition 1
DISKPART> detail partition
DISKPART> shrink querymax
The maximum number of reclaimable bytes is: 5017 MB

Good, it is possible to shrink 4136 MB.
CODE
DISKPART> shrink desired=4136
DISKPART> detail partition

The size is 4862 MB as expected.
CODE
DISKPART> exit


I restarted virtual machine, boot from hard disk. Windows seemed to work normally. No problem found.

I shutdown virtual machine, opened vw7.vhd in hex editor, verified that partition 1 is at LBA 0x00000800 (1MB) Length 0x0079F000 sectors (4862MB).
Partition 1 end position is at 7993344 sectors = 4863MB = 5099225088 bytes.
I copied 4863MB to a new file vw7s.vhd by using dd for Windows.
And used raw2vhd to append VHD footer to it.
CODE
C:\data>c:\util\dd bs=1M count=4863 if=vw7.vhd of=vw7s.vhd
C:\data>c:\util\raw2vhd vw7s.vhd


I detached vw7.vhd from virtual machine and attached vw7s.vhd.
I started VM. Windows seems to be OK.
I created another VHD mini1.vhd 128MB. I copied grldr, grldr.mbr into it, installed GRUB4DOS MBR, and copied firadisk 0.0.1.18 + my test-signing certificate in a folder.
I created another VHD mini2.vhd 16MB, created partition, and copied it inside mini1.vhd.
I attached mini1.vhd to VM. (primary master=vw7s.vhd, primary slave=mini1.vhd)
I booted into Windows, install my test-siging certificate, install firadisk and shutdown.
This is x86 version, so I don't have to enable Test Mode.
I changed order of virtual disk. (primary master=mini1.vhd, primary slave=vw7s.vhd)
I started VM. At GRUB4DOS commandline I created a small RAM drive and booted Windows.
CODE
map (hd1) (hd0)
map (hd0) (hd1)
map --mem /mini2.vhd (hd2)
map --hook
chainloader /bootmgr
boot

Windows installed drivers for new hardware: FiraDisk and RAM disk.
It seemed to be ready. I shutdown VM.

I installed GRUB4DOS 0.4.5a 2010-01-23 to external hard disk.
I started real machine (with 8GB RAM), told BIOS to boot from external hard disk.
In GRUB4DOS, I loaded vw7s.vhd and booted into Windows.
CODE
map --mem (hd1,0)/data/vw7s.vhd (hd0)
map --hook
chainloader /bootmgr
boot


It can boot to desktop on my PC.
Mouse stopped working temporarily a few times while Windows were installing drivers for new hardware.
Attached Image
17 Jan 2010
Read Topic
GRUB4DOS map mem and VirtualBox VT-x problem
GRUB4DOS map --mem have compatibility problem with VirtualBox with VT-x enabled.

In VirtualBox create a virtual machine with 2 virtual hard disks
(hd0) have grldr.mbr installed in MBR
(hd0,0) contain grldr, grldr.mbr, hddimg.img
(hd1,0) contain Windows XP
Start virtual machine. GRUB4DOS is loaded.
Create GRUB4DOS RAM drive before booting Windows XP.
CODE
map (hd0) (hd1)
map (hd1) (hd0)
map --mem (hd0,0)/hddimg.img (hd2)
map --hook
chainloader (hd0,0)/ntldr
boot

NTLDR's boot menu appear normally.
The problem comes after selecting Windows XP entry from boot menu.
If VT-x is disabled, the virtual machine boot normally. But if VT-x is enabled, the virtual machine crash.

Do you have the same problem ?
28 Dec 2009
Read Topic
Grub4dos with PAE support
I have spent a few weeks implementing PAE support for GRUB4DOS.
It is based on grub4dos-0.4.4-2009-10-16-src.zip from http://nufans.net/grub4dos/ .

Modification:
  • Implemented PAE support in int13_handler and in map, dd, cat commands.
  • Added map option --mem-max=MAX and --mem-min=MIN.
    Allow user to prevent map --mem command from using memory address above MAX or memory address below MIN.
  • Added map option --add-mbt= .
    If =0, map --mem will not add master boot track to memdrive.
    If =1, map --mem will add master boot track to memdrive.
    Changed default behavior to add master boot track only if image have BPB with recognized filesystem.
  • Allow map to reuse memory above existing memdrives in same block.
  • Changed probed_total_sectors value to use last partition ending instead of calculated from geometry.
    map --mem will not warn when image size is not multiple of cylinder size.
  • Parse and print 64-bit integer.
  • Parse number-of-sectors with K,M,G suffix.
  • Display progress while reading large file.

I will test a little more and post it here tonight if no serious bug found.
--------

This is not official GRUB4DOS release. It is a modified version.
It is still in alpha stage, not well tested, may be buggy, or may cause loss of data.
Not recommended for inexperienced user.
-- removed due to serious bug found --
Bug: direct map does not work.

RAM above and below 4GB address are split to different blocks.
If you have 4GB RAM it may be split to 3.25GB (below 4GB address) and 0.75GB (above 4GB address).
If you have 6GB RAM it may be split to 3.25GB (below 4GB address) and 2.75GB (above 4GB address).
If you have 8GB RAM it may be split to 3.25GB (below 4GB address) and 4.75GB (above 4GB address).

Normally, map --mem will use the first block that have enough space.
To force mem drive to above 4GB address, use --mem-min= option.
CODE
map --mem-min=4G
map --mem (hd0,0)/hddimg1.img (hd1)
map --mem-min=0
map --mem (hd0,0)/hddimg2.img (hd2)


This modified GRUB4DOS does not support large mem drive that span across two blocks.

Extras
Options
Options
Interests
No Information
Other Information
Country:: Thailand
Last Visitors


Today, 03:15 PM
supaJ


Yesterday, 09:45 AM


8 Jun 2010 - 3:00


3 Jun 2010 - 15:09
MEstes


29 May 2010 - 22:36
Comments
Other users have left no comments for karyonix.
Friends
There are no friends to display.
* Profile views updated each hour