21 replies to this topic

[reboot12]

I try boot Debian 6.0.5 ISO on MS VPC 2007 from HDD NTFS partition. ISO file is on first partition on HDD:

 

menu.lst

title My linux (boot from ISO)
set ISO=debian-moje.iso
# check and make an empty table entry in 4th position in ptn table
parttype (hd0,3) | set check=
set check=%check:~-5,4%
if "%check%"=="0x00" partnew (hd0,3) 0 0 0
if not "%check%"=="0x00" echo WARNING: PTN TABLE 4 IS ALREADY IN USE! && pause && configfile /menu.lst
ls (hd0,0)/%ISO%  && partnew (hd0,3) 0x00 /%ISO%
map /%ISO% (0xff)
echo -e \r\n
map --hook
root (0xff)
chainloader (0xff)

It works but if now boot e.g. Debian Live from real CD (VPC) I have my ISO in two places:

• one on first partition (hd0,0) as file debian-moje.iso
• second as partition (hd0,3) on HDD (I can mount the partition /dev/sda4 and have access to files)

Is this normal? Is GRUB4DOS wrote ISO image on hard drive?

[steve6375]

partnew (hd0,3) 0x00 /%ISO%

This creates a partition table entry which points to the ISO file.

So yes, it is normal.

The partition is type 0 and so is ignored by Windows.

Most linux distros do not care about the Type byte and will attempt to mount the partition as a iso9660 filesystem, thus the files in the ISO are accessible to linux.

You can remove the partition entry using

partnew (hd0,3) 0 0 0 

in grub4dos, type 

help partnew

for details

[Wonko the Sane]

See here:

http://reboot.pro/to...os-isohybrided/

starting around here:

http://reboot.pro/to...brided/?p=88531

 

Wonko

[reboot12]

partnew (hd0,3) 0x00 /%ISO%

This creates a partition table entry which points to the ISO file.

So yes, it is normal.

The partition is type 0 and so is ignored by Windows.

OK, but which command write the ISO image to disk? Please answer my questions simply yes or no:

 

1. After use partnew, ISO image take up additional space on whole hard drive?
2. Do partition C: in WinXP becomes less about the size of the ISO (in my case 342MB)?

 

If change partition type e.g. to 07h then open it on e.g. WinHex then see that ISO data placed on HDD. Look at this: https://www.dropbox..../movie.avi?dl=0

[steve6375]

The only change made to the disk is that an entry is added to the partition table (4th entry in table - 16 bytes on first sector of disk).

 

The entry in the partition table points to the start of the ISO file. So the ISO file and the partition both point to the same sectors on the disk.

 

e.g.  if you patched the start of the ISO file first byte - changed from 00 to FF, then both  the ISO file and the first byte of the (hd0,3) partition would now be FF. The directory entry for the ISO file and the partition table entry both point to the same sector (the start of the ISO file) on the disk.

[reboot12]

The only change made to the disk is that an entry is added to the partition table (4th entry in table - 16 bytes on first sector of disk).

This is not true because in WinXP can extract the ISO file from hard drive like this:

• change partition type e.g. to 07h (NTFS) to WinXP see partition (reboot needed)
• open this partition in WinHex, copy all data Ctrl+A and save as file ISO_image.iso
• now possible use this iso file

look at this: https://www.dropbox....u7/new.avi?dl=0

 

This means that GRUB4DOS also write ISO image to HDD (not only add entry in partition table)

 

Maybe this is only in MS VPC 2007 and in a real machine is different?

[steve6375]

Imagine a library containing many books (==files)

 

One book is called  XX.ISO

The library has index cards so that we can find any book in the library.

There is an index card which tells you which shelf and position the XX.ISO book is on.

 

Now we copy the index card and make a duplicate. We now have two index cards which both point the same book on the same shelf.

We have not copied the book or changed it in any way. All we did was make another index card.

 

It is the same for partnew. It has made a new 'index card', but instead of the index card being a directory entry, it is a partition table entry.

[reboot12]

Imagine a library containing many books (==files)

 

One book is called  XX.ISO

The library has index cards so that we can find any book in the library.

There is an index card which tells you which shelf and position the XX.ISO book is on.

 

Now we copy the index card and make a duplicate. We now have two index cards which both point the same book on the same shelf.

We have not copied the book or changed it in any way. All we did was make another index card.

 

It is the same for partnew. It has made a new 'index card', but instead of the index card being a directory entry, it is a partition table entry.

steve6375 - Did you watch my videos in the links I gave on dropbox?

 

Following your example with the library where books=files and shelf = (hd0,0):

• book named debian-moje.iso is located on the shelf (hd0,0)
• GRUB4DOS make only copy index not book

Please explain to me why, if now someone borrowed a book from the library - now the book is not in the shelf the book still have access via WinHex in WinXP?

 

I delete debian-moje.iso from partition (hd0,0) and ISO data still available e.g. on WinHex

[steve6375]

Who borrowed the book - when did the file get removed? The book is still there - if you destroy the index card in the library, the book is still there.

To remove the file, you would need to fill the sectors on the disk where the ISO file is located with 00's.

Deleting a file in Windows just removes the directory entry. That is why you can 'undelete' files using special software - because the file is still on the disk as long as it is not overwritten by more files which are added later.

[reboot12]

OK, how fill the sectors on the disk where the ISO file is located with 00's e.g. on Debian console?

[steve6375]

Let us say the ISO file is at sector  12345 on the disk (sectors 12345  to 12399)

 

There are two 'index cards'

 

1. A directory entry on hd0,0 which points to sector 12345

2. A partition table entry on hd0  MBR (LBA 0 - first sector of disk) which says start of partition 4 = start of file = sector 12345

 

both point to same sector on disk  12345.

[reboot12]

Yes, right - deleting file from disk only delete index - right, of course :-). I corrected the previous post :-).

OK, how fill the sectors on the disk where the ISO file is located with 00's e.g. on Debian console?

[steve6375]

dd if=/dev/zero of=xxx.iso bs=1024 count=999999

 

adjust count to size of ISO in KB

[Wonko the Sane]

A file (contiguous) occupies an extent on disk.

 

This extent (defined by an absolute start and a length) is normally indexed in the filesystem structure that spans the disk comprising that extent as a file.

 

The partnew command adds a second indexing to that same extent (in the partition table as a primary partition/volume).

 

More generally any file can be accessed either through the filesystem or from the RAW extent it occupies, by accessing the "physical" drive directly see this (seemingly unrelated):

http://reboot.pro/to...s-now-possible/

what the partnew (used in this way) does is to offer to the OS (and/or to the bootloader/bootmanager) a second "logical" way of access to the file.

 

Strictly speaking you do not really *need* to have the .iso residing inside an existing volume/filesystem, you can copy it RAW to the unpartitioned space at the end of the disk and then use partnew to index it in the partition table just once.

 

Wonko

[reboot12]

dd if=/dev/zero of=xxx.iso bs=1024 count=999999

 

adjust count to size of ISO in KB

Unfortunately, I made zero and the data is still available in WinHex after boot WinXP. I boot virtual machine from Debian Live - from real CD mounted on MS VPC and I did like this:

mount /dev/sda1 /mnt/mp
cd /mnt/mp
du debian-moje.iso
dd if=/dev/zero of=debian-moje.iso bs=1024 count=351112

After reboot to WinXP file C:\debian-moje.iso is empty - right, but data on sda4 (hd0,3) (disk F:) still available in WinHex - not 00's In offset 8800 still have string CD 001 EL TORITO SPECIFICATION

[steve6375]

It may have created a new file rather than filling the old file with 00's.

If you re-run the partnew command it should then show 00's.

 

Why not just run WINHEX and edit the first few bytes of the ISO, then check the first few bytes of the hd0,3 partition rather than use dd?

[reboot12]

It may have created a new file rather than filling the old file with 00's.

If you re-run the partnew command it should then show 00's.

 

Why not just run WINHEX and edit the first few bytes of the ISO, then check the first few bytes of the hd0,3 partition rather than use dd?

No, command dd working OK and fill 00's to file ISO - after open file ISO in WinHex have only 000000000000......

 

but on disk F: (hd0,3) sda4 still have ISO data

[steve6375]

yes, but dd  probably created a new file

 

e.g.

 

old  XXX.ISO started at sector 12345

 dd command created new XXX.ISO at say sector   98765  (full of 0's)

 

so hd0,3 still points to 12345, but directory entry for XXX.ISO points to 98765

[reboot12]

yes, but dd  probably created a new file

 

e.g.

 

old  XXX.ISO started at sector 12345

 dd command created new XXX.ISO at say sector   98765  (full of 0's)

 

so hd0,3 still points to 12345, but directory entry for XXX.ISO points to 98765

In that case, the dd command does not zero the place where the original ISO file.

[steve6375]

It may depend on the size that you specified (count). If it was bigger than the original ISO file then it may make a new file? You could try again but just use count=1024  for a 1MB fill.  I am not sure what linux does exactly with the dd command - it may also depend on the filesystem (NTFS/FAT32/ext)???

[reboot12]

I make test in MS VPC 2007:

• make virtual machine WinXP - dynamic VHD one partition primary 6GB, NTFS
• install GRUB4DOS on C: - rename ntldr to ntldrxp, copy grldr and rename to ntldr
• copy to C: menu.lst with partnew for boot Debian ISO debian-moje
• install WinHex
• open physical HDD in WinHex and search string: debian-moje
  • (find only in menu.lst)
• copy debian-moje.iso to C:
• open physical HDD in WinHex and search string: debian-moje
  • find in offset: A33E28 and 6C3FBE28 (ISO begin 8022h bytes before) (not understand why file is in two places    )
• now boot machine from GRUB4DOS and select from menu Debian Live ISO (partnew command)
• reboot machine to WinXP
• open physical HDD in WinHex and search string: debian-moje
  • He found a string in the same offsets as before A33E28 & 6C3FBE28

This means that the command partnew actually does not write the ISO image

Write (copy) the ISO file would have to take some time but Debian starts up very quickly - this means that ISO is not copied.

 

P.S. There is now a new issue - why ISO is in two places on HDD before run partnew command with GRUB4DOS?

[reboot12]

I tested on a real machine where the ISO image is on the second logical drive. To boot from this image need make changes in menu.lst:

• in set ISO= add full path to ISO image
• in ls change (hd0,0) to (hd0,5)
• also add (hd0,5) in map command