52 replies to this topic

[allanf]

This expect a friendly BIOS. Syslinux request to adjust the boot info table: -boot-info-table
http://syslinux.zyto...ex.php/ISOLINUX

OK. I'll look into it. Any idea which BIOSes - old, new, manufacturer, etc? What is the error/warning message? Which version of oscdimg have you tried? Which version of ISOLINUX have you tried?

After a quick first web search, it was alarming to find that mkisofs actually alters the source boot-sector file specified by -b parameter of mkisofs!

http://fy.chalmers.s.../mkisofs.8.html

-boot-info-table
... If this option is given, the boot file is modified in the source filesystem, so make sure to make a copy if this file cannot be easily regenerated!

Fortunately, I never used mkisofs with -b<isolinux.bin>. I guess that if anyone ever has used mkisofs -boot-info-table -b<isolinux.bin>, then that could cause a problem if the same altered isolinux.bin is used again without a fresh boot-info-table.

I'll adjust my winbuilder project so that, for each build, it will unzip a new copy from the original downloaded archive.

(Off Topic:
Unfortunately, I have used mkisofs (although not with -boot-info-table) on my orignal etfsboot.com in the WAIK, and wondering if mkisofs has made any alterations to that file without my knowledge. I guess I need to re-install the WAIK again to be sure I have the file in its original condition!)

Thanks for the warning about mkisofs! ... ...

EDIT: Dear Admin,
This and the previous post are perhaps off the topic of memdisk, but certainly worth a discussion. A new topic "oscdimg and ISOLINUX", or "ISOLINUX and boot info table" might be a better place for it.
Thanks

[cdob]

Any idea which BIOSes - old, new, manufacturer, etc?

I've no idea. I'm using the syslinux manufacturer request.

it was alarming to find that mkisofs actually alters the source boot-sector file specified by -b parameter of mkisofs!

Only if you request this by -boot-info-table. That's the documented feature.
It's works that way since more than ten years. There hasn't been a problem so far.

I have used mkisofs (although not with -boot-info-table) on my orignal etfsboot.com in the WAIK, and wondering if mkisofs has made any alterations to that file without my knowledge.

You didn't request a change. Therefore etfsboot.com is not changed of course.
Read the source code. http://cdrecord.berlios.de/

Thanks for the warning about mkisofs!

Thanks, it's my pleasure.

[Icecube]

@ allanf
You don't need a new isolinux.bin file each time you use mkisofs with the -boot-info-table switch. The -boot-info-table editing is wanted for isolinux.bin. When you install ISOLINUX in the bootsector of a CD (2048 bytes), the boot info table inside this 2048 bytes allows ISOLINUX to find the rest of the file (isolinux.bin), by looking up the LBA of isolinux.bin file and the filesize of this file. It also reads the checksum value and compares them with the calcuted checksum of the file (to confirm that the right file is read).

El Torito Boot Information Table
When the -boot-info-table option is given, mkisofs will modify the boot file specified by the -b option by inserting a 56-byte "boot information table" at offset 8 in the file. This modification is done in the source filesystem, so make sure you use a copy if this file is not easily recreated! This file contains pointers which may not be easily or reliably obtained at boot time.

The format of this table is as follows; all integers are in section 7.3.1 ("little endian") format.

Offset Name Size Meaning
8 bi_pvd 4 bytes LBA of primary volume descriptor
12 bi_file 4 bytes LBA of boot file
16 bi_length 4 bytes Boot file length in bytes
20 bi_csum 4 bytes 32-bit checksum
24 bi_reserved 40 bytes Reserved

The 32-bit checksum is the sum of all the 32-bit words in the boot file starting at byte offset 64. All linear block addresses (LBAs) are given in CD sectors (normally 2048 bytes).

http://linux.die.net/man/8/mkisofs

When you chainload isolinux.bin from grub4dos:

title Boot ISOLINUX
chainloader /isolinux.bin

grub4dos patches this boot info table, so ISOLINUX can find the file contents of isolinux.bin again.

[allanf]

Hi Icecube,

Thanks for your reply. I'm still unsure about the requirement to edit or insert a boot information table. It does not seem necessary in the few tests that I have done.

I use ISOLINUX files from syslinux-3.83.zip downloaded from:
http://www.kernel.or.../boot/syslinux/

I don't use mkisofs at all. To create the .iso, I use oscdimg from the Windows Automated Installation Kit for Vista SP1 and Server 2008. oscdimg does not have a parameter or switch for inserting or editing a boot information table.

oscdimg.exe -m -n -b<path to isolinux.bin> <ISO source directory> <ISO file>

where, in my case, <path to isolinux.bin> is not the path to isolinux.bin inside the ISO source directory. It is the path to isolinux.bin in some other folder where the syslinux-3.83.zip files are extracted. The files are extracted for each and every build (using winbuilder scripting) so that I know they are original as downloaded from the developer.

There is no problem. IT WORKS - straight out of the box! ... ...
IT WORKS with no editing or inserting of a boot information table.

...
When you chainload isolinux.bin from grub4dos:

grub4dos patches this boot info table, so ISOLINUX can find the file contents of isolinux.bin again.

So, in that case, it is not necessary at all to edit or insert the boot information table when creating the .iso, because GRUB4DOS does it when chainloading. Is this correct?

Another question: Does the original isolinux.bin as unzipped from syslinux-3.83.zip contain a fairly standard boot information table that is sufficient to work in the majority of cases where ISOLINUX is the primary bootloader? Or is there no boot information table at all in the original isolinux.bin?

Regards

[was_jaclaz]

Or is there no boot information table at all in the original isolinux.bin?

Unrelated, but not much and JFYI:
http://www.911cd.net...showtopic=22898



jaclaz

[allanf]

Unrelated, but not much and JFYI:
http://www.911cd.net...showtopic=22898

Yes. Thanks. That thread is asking similar sorts of questions. I dunno. Can't seem to find an answer though.

I guess my real question is: How likely is it that isolinux.bin will be unable to find itself?

Using my method, it seems that there would never be a problem with the actual checksum of the file because the file is unaltered (AFAIK), and I haven't receive an error.

The first three items in the boot info table - relating to the location of isolinux.bin - are the real worry. If they're wrong, how is isolinux.bin finding itself?

If this issue can't be resolved programmatically in a simple and dignified manner (and not requiring the use of mkisofs or some other third-party program), I may have to move on to the next bootloader for my attempt at a multi-boot project. I see that CD Shell does not need any special switches when creating an .iso. To me, however, ISOLINUX looks to be the pick of the bunch, but I need to find some answers.

BTW. I opened the isolinux.bin file with a hex editor hoping to see a nicely laid-out boot-info table or a space where one could go. Haha! There's just a huge pile of jumbled up numbers and letters that made no sense to me whatever.

[Icecube]

@ jaclaz
Maybe you can add a link to http://www.boot-land...?showtopic=9582 on the topic that you linked too.
The patch for chain.c32 is in Syslinux 3.83. It is not directly related to BCDW, but might still be useful.

@ allanf
Instead of looking at the isolinux.bin file, you could look at the source code (/core/isolinux.asm):

_start:  &#59; Far jump makes sure we canonicalize the address

		cli

		jmp 0:_start1

		times 8-($-$$) nop  &#59; Pad to file offset 8



  &#59; This table hopefully gets filled in by mkisofs using the

  &#59; -boot-info-table option.  If not, the values in this

  &#59; table are default values that we can use to get us what

  &#59; we need, at least under a certain set of assumptions.

		bi_pvd:	  dd 16	&#59; LBA of primary volume descriptor

		bi_file:	 dd 0	&#59; LBA of boot file

		bi_length:   dd 0xdeadbeef&#59; Length of boot file

		bi_csum:	 dd 0xdeadbeef&#59; Checksum of boot file

		bi_reserved: times 10 dd 0xdeadbeef; Reserved

		bi_end:

found_drive:

	&#59; Alright, we have found the drive.  Now, try to find the

	&#59; boot file itself.  If we have a boot info table, life is

	&#59; good; if not, we have to make some assumptions, and try

	&#59; to figure things out ourselves.  In particular, the

	&#59; assumptions we have to make are:

	&#59; - single session only

	&#59; - only one boot entry (no menu or other alternatives)



		cmp dword [bi_file],0	&#59; Address of code to load

		jne found_file		&#59; Boot info table present :)



%ifdef DEBUG_MESSAGES

		mov si,noinfotable_msg

		call writemsg

%endif



	&#59; No such luck.  See if the spec packet contained one.

		mov eax,[sp_lba]

		and eax,eax

		jz set_file		&#59; Good enough



%ifdef DEBUG_MESSAGES

		mov si,noinfoinspec_msg

		call writemsg

%endif



	&#59; No such luck.  Get the Boot Record Volume, assuming single

	&#59; session disk, and that we're the first entry in the chain.

		mov eax,17		&#59; Assumed address of BRV

		mov bx,trackbuf

		call getonesec



		mov eax,[trackbuf+47h]	&#59; Get boot catalog address

		mov bx,trackbuf

		call getonesec		&#59; Get boot catalog



		mov eax,[trackbuf+28h]	&#59; First boot entry

	&#59; And hope and pray this is us...



	&#59; Some BIOSes apparently have limitations on the size

	&#59; that may be loaded (despite the El Torito spec being very

	&#59; clear on the fact that it must all be loaded.)  Therefore,

	&#59; we load it ourselves, and *bleep* the BIOS.



set_file:

		mov [bi_file],eax



found_file:

	&#59; Set up boot file sizes

		mov eax,[bi_length]

		sub eax,SECTOR_SIZE-3	&#59; ... minus sector loaded

		shr eax,2		&#59; bytes->dwords

		mov [ImageDwords],eax	&#59; boot file dwords

		add eax,(2047 >> 2)

		shr eax,9		&#59; dwords->sectors

		mov [ImageSectors],ax	&#59; boot file sectors



		mov eax,[bi_file]	&#59; Address of code to load

		inc eax			&#59; Don't reload bootstrap code

[was_jaclaz]

@icecube
Will do thanks.

@allanf
I know I may be opening a can of worms , but JFYI :
http://www.msfn.org/...-...53.html&hl=



jaclaz

[Krokodox]

Thanks

Do you know of any examples in getting the Etherboot PXE (gPXE) images to work with the memdisk ISO version? tftp is very slow and the http functionalities of the Etherboot images offer a great way to circumvent this for large ISO files.

Yes it works. I am currently setting up a slimmed W2K3 RAM based image that the server downloads via PXE / GPXE using HTTP as transport instead of TFTP. It is a fast and very nice way of downloading and also makes it possible to create a high-availibility solution since the HTTP server can be load-balanced

I will document my setup as soon as I have all bits working smoothly. I use the latest Syslinux, in there you will find a gpexlinux.0, use this instead of the etherboot's gpxe-undi driver for the PXE part of the boot. Once booted, use the ISO capable Memdisk that can be found here somewhere for download, not the one in the current Syslinux package.

The .ISO file needs to boot into GRLDR and map the contained disk image. The W2K3 disk image needs to have been setup with Firadisk driver. I use nLite to shrink the W2K3 setup eliminating all unnecessary junk and then let W2K3 install itself in a VirtualBox VM. Once I finish the config of the machine I capture it using VSS to a disk image, that then goes into the .ISO.

It is a bit tricky and needs a lot of tinkering but once you see it boot fast like hell via PXE / GPXE / HTTP you never regret that you did not start messing around with iSCSI

[Icecube]

The ISO booting capable MEMDISK is now available in Syslinux 3.84-pre3:
http://www.kernel.or...slinux/Testing/

[Last Chance]

Doesn't seem to work with XP images. Anyone have this working yet?

[allanf]

@ allanf
Instead of looking at the isolinux.bin file, you could look at the source code (/core/isolinux.asm):

Thanks for the tip. Much more pleasant reading, including the sprinklings of humour and the odd prayer or two.

I note the assumptions made when boot info table is not present (default?). Sadly, my ability to test on real (not virtual)devices is limited - one XP laptop with plenty of RAM and disk space, but broken optical drive and display; second Win7 laptop with 256 RAM and damaged HDD partitioned up into small functional chunks, and running the first laptop through Remote Desktop. Neither have USB booting. Oh! What fun!

I know I may be opening a can of worms , but JFYI :
http://www.msfn.org/...-...53.html&hl=

Ordinarily, I like worms.

I tested it out following the KB article, just to see if it works and what it does - expecting some sort of screen to make a selection even though I don't have the right platform. No luck; and no luck with x86 boot options either. In both cases, booting went straight into the first entry (default).

Anyway, might leave this thread to get back on track.

Regards

[Sha0]

MEMDISK El Torito emulation has been merged into Syslinux' 3.84-pre4 development branch, meaning MEMDISK El Torito users can benefit from all the other fixes/enhancements which H. Peter Anvin (and possibly others) has (or have) committed to MEMDISK "proper." Two recent commits deal with PC-DOS and the PloP boot-loader .ISO, by the way. Enjoy.

http://git.zytor.com...x.git;a=summary

now that is an excellent improvement . thanks a lot icecube for the head up .

im wondering if i can use this MEMDISK with G4D and syslinux at the same time ? well i guess i can .

Yes. MEMDISK and GRUB4DOS both install INT 13h "hooks". These hooks typically keep track of the previous hook, so you end up will a pile of hooks. You can hook to your heart's content, or until you run out of available memory.

MEMDISK only does RAM disk mapping at this time. GRUB4DOS does RAM disk mapping as well as mapping to a contiguous range of sectors on another device.

ice cube , i was wondering if u have tested ram based live xp iso with syslinux yet ?

i mean with memdisk approach..

If the OS uses INT 13h to access its boot disk, MEMDISK will provide this service. OSs like XP and Linux do not use INT 13h, so you need a special driver to look for whatever RAM disk that was setup by MEMDISK. I'm developing WinVBlock to accomplish this, but ISO support is not there yet. karyonix has developed Firadisk, but as far as I know it only works with GRUB4DOS.

Just tried LiveXP_RAM.iso (50Meg cab compressed Boot Cd created with the BootSDI script) and it booted OK.

Please note that when you load an .ISO into RAM as a RAM disk, you need enough memory for the image.
When you're booting an XP which itself loads a RAM disk, then you need enough additional RAM for this "sub-image". Drivers like WinVBlock and Firadisk help to avoid this redundancy by allowing the OS to find the original RAM disk.

Thanks

Do you know of any examples in getting the Etherboot PXE (gPXE) images to work with the memdisk ISO version? tftp is very slow and the http functionalities of the Etherboot images offer a great way to circumvent this for large ISO files.

From the gPXE CLI, you do:

initrd http://webserver/some.iso

chain http://webserver/memdisk-iso iso

where the chain command is given the path to your El Torito-capable MEMDISK and also given iso as a "kernel command-line argument." The above commands can go into a gPXE script, also. See ROM-O-Matic and the gPXE Wiki pages for command-line and script reference material.

You could also chain to PXELINUX from gPXE, if you are more comfortable with PXELINUX' familiar config-files. Some folks are not aware that fairly recent ( >= 3.70) PXELINUces can use HTTP when booted from gPXE. Simply use http://webserver/somefile-style file paths in your config-files.

As noted in another post, gpxelinux.0 is exactly

undionly.kkpxe (gPXE) -> pxelinux.0 (PXELINUX)

So you simply drop in gpxelinux.0 where you used to use pxelinux.0 and you should have HTTP abilities.

Doesn't seem to work with XP images. Anyone have this working yet?

... And where does it fail, exactly? Please include detail in reports of this nature. As mentioned in a recent post, you need a driver for an OS like XP. Without one, you will either get a Blue Screen of Death or you will have to use XP's /RDPATH= functionality and load a second RAM disk image (meaning a greater memory requirement.)

- Shao Miller

[Icecube]

@ sha0
I did merge all your posts. There where to many of them .
Thanks for working again on MEMDISK .

@ all
A new MEMDISK is attached to my first post. MEMDISK of Syslinux 3.84-pre4 + 2 patches which allow MEMDISK to boot ISO's which use floppy emulation (PloP iso) or hard disk emulation (Dell Diagnostics iso) instead of a no-emulation boot sector.

[Sha0]

@ sha0
I did merge all your posts. There where to many of them .
Thanks for working again on MEMDISK .

Thanks, Icecube. I was meaning to do that this morning, but you beat me to it.

@ all
A new MEMDISK is attached to my first post. MEMDISK of Syslinux 3.84-pre4 + 2 patches which allow MEMDISK to boot ISO's which use floppy emulation (PloP iso) or hard disk emulation (Dell Diagnostics iso) instead of a no-emulation boot sector.

I apologize for the confusion concerning Syslinux 3.84-pre4 versus Syslinux 3.84-pre4 + 2 patches... H. Peter has included these two patches into the top of Syslinux 3.84-pre4, so that means that's the current state of Syslinux 3.84-pre4. "+ 2 patches" might confuse people, in case they think they need to apply patches or something (which they don't,) so I'm just clarifying here.

Future MEMDISK directions (in my opinion):

• An ACPI table that an OS' driver can use to re-establish the RAM disk without using INT 13h (much like iSCSI's iBFT and AoE's aBFT)
• Mapping a BIOS drive number to a contiguous range of sectors on another BIOS drive (more "MAPDISK" then "MEMDISK" )
• Implementing MEMDISK as one or more COM32 modules, re-using the current MEMDISK hooks

- Shao Miller

[Last Chance]

MEMDISK El Torito emulation has been merged into Syslinux' 3.84-pre4 development branch, meaning MEMDISK El Torito users can benefit from all the other fixes/enhancements which H. Peter Anvin (and possibly others) has (or have) committed to MEMDISK "proper." Two recent commits deal with PC-DOS and the PloP boot-loader .ISO, by the way. Enjoy.
.....

- Shao Miller

What I want is to just plop an XP CD image in my tftpboot path and call it with Memdisk. We have working RIS and whatnot, I soley want the ability to call an ISO of an XP Cd for in-place repairs, as I run a local shop and want to do it without CD. Our machines have plenty of ram to handle the size of the image, we just want to fire an XP CD image off of a server to do repair installs, something that the myriad of PE installs don't do conveniently (setting up the iniq id in the registry and whatnot).

[Sha0]

What I want is to just plop an XP CD image in my tftpboot path and call it with Memdisk.

The latest WinVBlock should be capable of this. You would need to hack your XP CD image to include and load the WinVBlock driver:

http://www.boot-land...?...ost&p=86594

Note that if you recompile the XP CD, you will likely want to use the mkisofs (and options used) from Bart's PE Builder, since I believe it is a special version whose results attempt to closely match the details of the XP CD from Microsoft.

- Sha0

[allanf]

With GRUB4DOS...

For both pmagic-4.0.iso variants, you also start the grub4dos menu with:

title Parted Magic 4.0 (iso in / and direct mapping and loading new grub4dos configfile)
find --set-root /pmagic-4.0.iso
map /pmagic-4.0.iso (hd32)
map --hook
root (hd32)
configfile /boot/grub/grub4dos.lst


In this case, no other bootloader takes over the command. So in this case, the /boot/grub/grub4dos.lst config file, will be loaded by the grub4dos version with which you mapped the iso.

This will also work when you have memory mapped the iso.

From: http://partedmagic.c...so-booting.html

Can MEMDISK do this to find the appropriate SYSLINUX config file?

Thanks

[Icecube]

Can MEMDISK do this to find the appropriate SYSLINUX config file?

Thanks

No.
MEMDISK only emulates the image and boots it. MEMDISK doesn't understand filesystems. Currently MEMDISK does the same as the following grub4dos code:

map --meme /pmagic-4.0.iso (hd32)

map --hook

root (hd32)

chainloader (hd32)

When you boot the normal ISOLINUX iso of Parted Magic with MEMDISK, ISOLINUX will be booted (in boot sector) and ISOLINUX will find the isolinux.cfg. When you boot the grub4dos iso of Parted Magic with MEMDISK, Grub4dos (in boot sector) will be booted.

Syslinux 4 has filesystems written in C instead of assembly code. So it might be possible in the future that the mapping functions of MEMDISK are ported to Syslinux and that you can load a specific file from an emulated image (like grub4dos currently can).

[Icecube]

All MEMDISK iso patches are in Syslinux 3.84-pre5 (and later).

[fuxxi]

edit : confirmed, this works with gpxelinux & http as well and this is blasting fast !

label Parted Magic 42 memdisk + http
KERNEL memdisk
APPEND iso initrd=http://192.168.1.100/images/pmagic/pmagic-4.2.iso

This does not work for me, using memdisk of Syslinux 3.85, saying:

"Could not find ramdisk image: [url="http://192.168.0.2/memtest.iso""]http://192.168.0.2/memtest.iso"[/url]

I googled and found various other syntax for using http loading in gpxe, but no success at all.

The documentation about this stuff is very limited.

Any idea of what Iam doing wrong?

[fuxxi]

This does not work for me, using memdisk of Syslinux 3.85, saying:

"Could not find ramdisk image: [url="http://192.168.0.2/memtest.iso""]http://192.168.0.2/memtest.iso"[/url]

I googled and found various other syntax for using http loading in gpxe, but no success at all.

The documentation about this stuff is very limited.

Any idea of what Iam doing wrong?

OK, I got it working.

After fast install, setup of HFS ~ HTTP File Server (http://www.rejetto.com/hfs/) I was able to download files via http. Wow, its like 20 times (or even more) faster then stupid tftp.

Is there any other solution grabbing the files via http then using http file server?

[chung1721]

Sorry, I'm new here and also Linux.

I'm testing in VirtualBox with GRUB4DOS/Isolinux and see that GRUB4DOS can load .iso files very fast, successful but isolinux load too long then say not enough memory. Is there any way to make isoniux load .iso files like GRUB4DOS?

Thanks.

[Icecube]

I'm testing in VirtualBox with GRUB4DOS/Isolinux and see that GRUB4DOS can load .iso files very fast, successful but isolinux load too long then say not enough memory. Is there any way to make isoniux load .iso files like GRUB4DOS?

Currently MEMDISK supports only booting images from memory. MEMDISK is seen like a linux kernel by the bootloader (Syslinux like bootloaders, GRUB, GRUB4DOS, GRUB2, ...). MEMDISK doesn't read any data from disk (or network). This is done by the booloader, which will pass the image (floppy, hard disk, ISO) to MEMDISK as an initrd.
Grub4dos can read its own files and thus can use direct mapping (image not loaded in memory) and memory mapping.

So MEMDISK currently can't do what you want.

Shao Miller started working on a COM32 module for Syslinux, which reads its image files by itself. In the future it might be possible that direct mapping of images is possible with this memdisk.c32 module.
http://syslinux.zyto...rch/013850.html

[chung1721]

Currently MEMDISK supports only booting images from memory. MEMDISK is seen like a linux kernel by the bootloader (Syslinux like bootloaders, GRUB, GRUB4DOS, GRUB2, ...). MEMDISK doesn't read any data from disk (or network). This is done by the booloader, which will pass the image (floppy, hard disk, ISO) to MEMDISK as an initrd.
Grub4dos can read its own files and thus can use direct mapping (image not loaded in memory) and memory mapping.

So MEMDISK currently can't do what you want.

Shao Miller started working on a COM32 module for Syslinux, which reads its image files by itself. In the future it might be possible that direct mapping of images is possible with this memdisk.c32 module.
http://syslinux.zyto...rch/013850.html

Thanks for your reply and waiting for Shao Miller.