Jump to content











Photo
- - - - -

oscdimg and GRUB4DOS?


  • Please log in to reply
35 replies to this topic

#1 allanf

allanf

    Gold Member

  • .script developer
  • 1256 posts

Posted 11 November 2009 - 07:08 PM

Hi,

My first foray into the world of GRUB4DOS. Experimenting in VirtualBox, to try and create an .iso with oscdimg that boots Windows PE 2.1 using GRUB4DOS.

I followed diddy's Guide - Using grldr as no-emulation bootsector on CD/DVD, and this worked:

mkisofs -R -b grldr -no-emul-boot -boot-load-size 4 -o grldr.iso iso_root


... except my first and only entry in menu.lst was:

title pe21

chainloader \BOOTMGR

It failed to load, so I fumbled around and discovered that changing entry 'BOOTMGR' in the menu.list to lower case solved the problem. Fantastic!


That's all done for mkisofs. My oscdimg comes from WAIK for Vista SP1 and Server 2008. There is a bit of a guide here. But more can be found in the cmd-line help (oscdimg -help boot).

From the help:

-bootdata:<num>#defaultbootentry#bootentry2#bootentryN

BootEntryOptions:
b This option is used to specify the file that will be written in the
boot sector(s) of the disk. Example: -bc:\location\cdboot.bin
p This option specifies the value to use for the Platform ID in the
El Torito catalog. The default is 0x00 to represent the x86
platform. 0xEF represents an EFI-based system
e This option means not to use floppy disk emulation in the El Torito
catalog.

t Specifies the El Torito load segment. If not specified, defaults to

0x7C0

Example:
-bootdata:2#p0,bc:\location\etfsboot.com#pEF,bc:\location\ESPBootFile
This specifies a multi-boot image with the default image having an x86 boot
sector that launches the ETFSBOOT.com bootcode, and a secondary EFI boot
image that launches ESPBootFile when booted


This refers to multi-boot entries. However, it seems to work for a single-boot entry, and appears to be the only possibility of getting close to the second (alternative) mkisofs command in the Guide:

mkisofs -R -b grldr -no-emul-boot -boot-load-seg 0x1000 -o bootable.iso iso_root

oscdimg.exe -n -bootdata&#58;1#bgrldr,e,t0x1000 iso_root grldr.iso

The 'oscdimg ... -bootdata:1# ... t0x1000 ...' looks very similar to 'mkisofs ... -boot-load-seg 0x1000 ...'.

Anyway, the above oscdimg command took me all the way to the grub cmd-line. No menu list! Why?

From the cmd-line - using the handy [TAB] feature with 'chainloader /', I saw that this time 'BOOTMGR' filename was in uppercase. I chainloaded it from the cmd-line and it booted. Great! 'MENU.LST' filename was also uppercase.

Next:
oscdimg.exe -n -d -bootdata&#58;1#bgrldr,e,t0x1000 iso_root grldr.iso

... adding -d to allow lowercase filenames.

So this one brought up the menu list! Amazing!

From the grub cmd-line, 'chainloader /', [TAB], I see that this time 'bootmgr' filename is in lower case. So, after editing the menu.lst appropriately, I tried to boot/chainload bootmgr from the menu.

Black screen with white writing:

Windows failed to start........

File: \Boot\BCD
Status: 0xc000000f
Info: An error occured while attempting to read the boot configuration data.


Why not use tried-and-tested mkisofs? Why does a mountaineer climb a mountain?

Any ideas how to make this oscdimg go smoothly?

Thanks

#2 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 11 November 2009 - 08:19 PM

I'm rather sure that your junk manager will not pass this post to you :)

@Lancelot, you are familar with 'transferring logical issues', because you also got some 'transferred' messages some time ago :drunk: :
Can you try to explain Allanf:
Maybe I'm totally wrong, but it could be a question of mkisofs.
There are some interesting switches like
  • -U
  • -allow-lowercase
  • -force-uppercase
  • ...
Peter

#3 cdob

cdob

    Gold Member

  • Expert
  • 1469 posts

Posted 11 November 2009 - 08:32 PM

Bootmgr does read ISO9660 or UDF.
Bootmgr is case sensitive at ISO9660. Core boot files has to be uppercased: e.g.\BOOT\BCD
Core boot files may be lower case at UDF.

Grub4dos is case sensitive at CD.
Grub4dos does read Rock Ridge or ISO9660.
Grub4dos search file name menu.lst, that's lower case.

Example:
Given a ISO9660 MENU.LST and Rock Ridge extension menu.lst:
Grub4dos does find Rock Ridge menu.lst.

Remember: grub4dos documentation does request Rock Ridge extension.

One approach:
Patch grldr: menu.lst to MENU.LST.
Use uppercase names at oscdimg.


Another idea: lowercase ISO9660 and Joliet.
However

When using the -j1, -j2, or -js options, the -d, -n, and -nt options do not apply and cannot be used.


Edited by cdob, 11 November 2009 - 08:40 PM.


#4 allanf

allanf

    Gold Member

  • .script developer
  • 1256 posts

Posted 11 November 2009 - 10:05 PM

Bootmgr does read ISO9660 or UDF.
Bootmgr is case sensitive at ISO9660. Core boot files has to be uppercased: e.g.\BOOT\BCD


With mkisofs:
mkisofs -R -b grldr -no-emul-boot -boot-load-size 4 -o grldr.iso iso_root
... everything in the root of .iso is lowercase, including bootmgr, and it boots from the menu!

With oscdimg:
oscdimg.exe -n -d -bootdata&#58;1#bgrldr,e,t0x1000 iso_root grldr.iso
... again, everything in the root of the .iso is lowercase, including menu.lst which is found. But bootmgr goes to the black-screen BCD error. However, without the -d (allow lowercase) switch, everything is uppercase, including GRLDR (which I assume is found), and MENU.LST which is not found. And BOOTMGR boots from the grub cmd-line chainloader!

Sorry to repeat, but I am confused by this inconsistency (... total lack of knowledge here).

Grub4dos search file name menu.lst, that's lower case.

Thanks. I suspected that.

Remember: grub4dos documentation does request Rock Ridge extension.

I cannot find an equivalent switch in oscdimg for mkisofs -R. Is this the major difference that is causing the problem. (In a day, I'll try to find out what Rock Ridge actually is.)

I tried some oscding UDF switches. Nothing satisfactory. With -u1 (produces UDF and ISO 9660) plus -d (allow lowercase) everything in root is uppercase (!) and MENU.LST does not appear. But BOOTMGR boots.

I thought this may have been specifically related to GRUB4DOS - perhap this case is. However I have since found suggestions to make the ISO Source Boot files and folders uppercase before running oscdimg. It's a bit difficult to do programmatically with Winbuilder, but I'll try it.

Thanks for the info!

@psc, I inadvertantly read your post while I was logged out. I should have realised the damn filter doesn't work unless I'm logged in! Thanks anyway.

#5 cdob

cdob

    Gold Member

  • Expert
  • 1469 posts

Posted 12 November 2009 - 05:32 AM

With mkisofs:

mkisofs -R -b grldr -no-emul-boot -boot-load-size 4 -o grldr.iso iso_root
... everything in the root of .iso is lowercase

I doubt this. ISO9660 names should be upper cased, rock ridge extension may be lower case.
Can you run ISOBuster an open the ISO image?
Compare different file systems.

By the way: use -r instead of -R.

I cannot find an equivalent switch in oscdimg for mkisofs -R. Is this the major difference that is causing the problem.

Yes, that's the major difference.

I tried some oscding UDF switches. Nothing satisfactory. With -u1 (produces UDF and ISO 9660) plus -d (allow lowercase) everything in root is uppercase (!)

That's a pity.

oscdimg.exe -u2 -urmenu.lst . o.iso
result to a MENU.LST too.
I'm running out of ideas.

#6 dera

dera

    Gold Member

  • .script developer
  • 1335 posts
  •  
    Hungary

Posted 12 November 2009 - 06:31 AM

did you try oscdimg using the '-n -d' switch
and uppercase not only the files 'BOOTMGR' and 'BCD'
but uppercase also the folder name 'BOOT'?

#7 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7101 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 12 November 2009 - 07:48 AM

Limited to grub4dos:


chainloader /bootmgr || chainloader /BOOTMGR

Edit embedded menu.lst:
http://www.boot-land...?...=8634&st=13

...
configfile /menu.lst
configfile /MENU.LST
configfile /boot/grub/menu.lst
configfile /grub/menu.lst
....


jaclaz

#8 allanf

allanf

    Gold Member

  • .script developer
  • 1256 posts

Posted 12 November 2009 - 12:43 PM

did you try oscdimg using the '-n -d' switch
and uppercase not only the files 'BOOTMGR' and 'BCD'
but uppercase also the folder name 'BOOT'?

Thanks dera. I eventually found a post of yours on another thread which gave me the idea. Initially, I was searching with the terms 'oscdimg' and 'grldr' or 'grub4dos', but the problem is not specific to GRUB4DOS.

I tried it and it works! ... :drunk: ...

The drawback is that converting the Boot Files and Folders to uppercase needs to be done manually - a right pain in the rear! The files and folders are copied from the WAIK where they are all lowercase. Copying the file 'bootmgr' (no file extension) to 'BOOTMGR' would be a problem for Winbuilder, AFAICT. So I'm looking for an even better solution.


Limited to grub4dos:


chainloader /bootmgr || chainloader /BOOTMGR


OK. That seemed easy enough, and I've implemented it to cover both bases. The main problem is that when BOOTMGR is in uppercase, so is MENU.LST which is therefore not found anyway. (The exception being the solution from dera above, and probably your solution below.)

Edit embedded menu.lst:


OK. Sure. The only part I don't quite understand is the 'Edit embedded menu.lst' bit... :)

I'd appreciate it if you could guide me through it, or point to some reading that might be introductory to a topic such as 'hexediting grub.exe'. (I'm not even sure that I have a grub.exe?!) Most importantly, can the whole procedure be done by script?

Thanks
Thanks

#9 cdob

cdob

    Gold Member

  • Expert
  • 1469 posts

Posted 12 November 2009 - 04:04 PM

The drawback is that converting the Boot Files and Folders to uppercase needs to be done manually - a right pain in the rear! The files and folders are copied from the WAIK where they are all lowercase. Copying the file 'bootmgr' (no file extension) to 'BOOTMGR' would be a problem for Winbuilder, AFAICT. So I'm looking for an even better solution.

The classic BartPE solution use filecase.exe to uppercase names at hard disk. http://www.stevemiller.net/apps/

At RAM load solution has to upper case \BCD\* and \SOURCES\BOOT.WIM.
A flat file solution has to upper case more files. LiveXP does contain a example, has to be adjusted.

The main problem is that when BOOTMGR is in uppercase, so is MENU.LST

Change upper and lower case at hard disk, run -d to allow lower case at ISO9660 names.

Another approach

The only part I don't quite understand is the 'Edit embedded menu.lst' bit...

rem external application grubutil grubmenu.exe

rem http&#58;//nufans.net/grub4dos/grubutil/



grubmenu.exe import grldr embedded.lst
embedded.lst may be your full menu.lst: you don't have to call configfile /menu.lst.
Or use the given example to call menu.lst.

#10 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7101 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 12 November 2009 - 07:05 PM

OK. Sure. The only part I don't quite understand is the 'Edit embedded menu.lst' bit... :)

I'd appreciate it if you could guide me through it, or point to some reading that might be introductory to a topic such as 'hexediting grub.exe'. (I'm not even sure that I have a grub.exe?!) Most importantly, can the whole procedure be done by script?


Sure it can be done from .script.

The last part of both grldr and grub.exe is actually an embedded menu.lst.
See the already given post:
http://www.boot-land...?...=8634&st=13

Do it manually first, then script it.

Get LATEST grub4dos:
http://nufans.net/gr...-2009-10-16.zip

Open either grldr or grub.exe with a hex editor.

Search in it the string:

default 0


It is placed at offset 220370 dec / 0x035CD2 hex in grldr and at offset 233170 dec / 0x038ED0 hex in grub.exe.

EVERYTHING from the "d" of "default" till the end of the files is "game" :) i.e. it's the actual "embedded" menu.lst , padded with digital 00's till the end.

Copy from the "d" of "default till the 2nd "0A" after "halt".
Open a new document in the hexeditor.
Paste in it what you copied.
Save as (for example) "embedded.ori".
Open a new Wordpad document.
Paste in it what you copied.
Save as "plain text", as an example as "embedded.txt".
Open "embedded.txt" in the hex editor and compare it's contents with "embedded.ori".
You will see that every "0A" in the "embedded.ori" has been replaced by "0D0A", this is because under DOS/Windows to go to a new line CR+LF is used (Carriage Return + Line Feed) whilst under Unix/Linux only LF is used, in other words CHR$(13)+CHR$(10) vs. CHR$(10) only, Wordpad "understands" the Linux standard but saves in Windows one.
http://en.wikipedia.org/wiki/Newline
Edit the menu.lst in Wordpad as you wish.
Get any of the "conversion" programs, example:
http://www.joachim-g...ftware/crlf.php
(there are hundreds of similar tools, GUI or command line)
or do it with the hex editor, then pad the file with as many "00"'s are needed to get the same size of the original file and use it to replace the "tail" of either grub4dos or grub.exe.
or do it via .script.

Hope the above is clear enough.

:drunk:

jaclaz

#11 allanf

allanf

    Gold Member

  • .script developer
  • 1256 posts

Posted 13 November 2009 - 12:49 AM

@cdob and @jaclaz

All clear!

It looks like I have some work to do. One thing nagging in the back of my mind is the statement in the various GRUB4DOS guides that setting the boot load segment to 0x1000 is not the best method because of tricky BIOSes. Keeps me wondering if it is worth the effort.

Ultimately, I'd like to do this without the use of third-party tools, or, if tools are absolutely necessary, to do some procedure at a very early boot stage of Win PE 21. Am I asking too much?

Thanks

#12 cdob

cdob

    Gold Member

  • Expert
  • 1469 posts

Posted 13 November 2009 - 07:48 AM

boot load segment to 0x1000 is not the best method because of tricky BIOSes.

Yes, some BIOS fail at that. Traditional default is 0x7C0 and boot load size 4.
All ISO creation tools and burning applications support this. Well, there is one exception.

Idea, not tested:
rename grldr to BOOTMGR. Use boot file etfsboot.com.
rename bootmgr to bootfile. Adjust menu.lst.


Ultimately, I'd like to do this without the use of third-party tools

I'm confused: grub4dos is a third-party tool too. Why can't you use a another third-party tool?
What's your requirements? Which build environment do you use?
Cmd.exe can rename files to upper case. There are a fixed file list at WinPE RAM load. A batch can rename the files.

#13 allanf

allanf

    Gold Member

  • .script developer
  • 1256 posts

Posted 13 November 2009 - 09:11 AM

I'm hoping that the eventual method will apply in all Windows environments from XP onward, and both x86 and x64. I use XP SP3 x86 and also test in Win7 RC1 x86. It's a winbuilder project (pe21.003) I'm working on.

There was a winbuilder script by NetFanTom for PXE booting that I was interested in. It uses GRUB4DOS.

So far my project uses no tools external to Windows and WAIK when building the project - except winbuilder, of course. I'd like to keep it that way. Though, happy to use anything at all in the booted PE!

Yes, some BIOS fail at that. Traditional default is 0x7C0 and boot load size 4.
All ISO creation tools and burning applications support this. Well, there is one exception.

When using GRUB4DOS, if the El Torito load segment is not specified (as 0x1000) in oscdimg, the Virtual Machine boots the .iso immediately to a black screen with a static (non-blinking) grey underscore in the top left corner. CPU hits 100% until the VM is closed.

The recommended method for mkisofs is to specify the boot load size rather than the boot load segment:
mkisofs -R -b grldr -no-emul-boot -boot-load-size 4 -o grldr.iso iso_root
But there is no equivalent, that I can find, in oscdimg.


Idea, not tested:
rename grldr to BOOTMGR. Use boot file etfsboot.com.
rename bootmgr to bootfile. Adjust menu.lst.

Looks interesting. I'll try it, just to see if it works.

Cmd.exe can rename files to upper case. There are a fixed file list at WinPE RAM load. A batch can rename the files.

You mentioned earlier that booting a flat WinPE requires more. I'll look around for the lists. Using cmd.exe could be the simplest way out.

In the meantime, I was looking at MS debug.exe to edit grldr - then discovered it had been discontinued for x64 OSes. :drunk:

Thanks again. :)

#14 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7101 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 13 November 2009 - 09:19 AM

Idea, not tested:

Idea, tested :).

Use bootfix.bin :
http://www.911cd.net...showtopic=19124

@allanf
Check this thread:
http://www.boot-land...?showtopic=5000
the tools that Lancelot used to "adapt" to x64 are all you need.

But I would also like to better understand the "requisite" of not using third party tools.

Something you may want to explore is the possibility of grldr/grub.exe to self-modify themselves, the topic has been only hinted here:
http://www.boot-land...?showtopic=8599
if you are interested, I will try and help you.

:drunk:

jaclaz

#15 cdob

cdob

    Gold Member

  • Expert
  • 1469 posts

Posted 13 November 2009 - 02:31 PM

So far my project uses no tools external to Windows and WAIK when building the project - except winbuilder, of course. I'd like to keep it that way. Though, happy to use anything at all in the booted PE!

Well, that's strange requirements.

strange requirements result strange solutions:
boot loader chain: BCDW -> isolinux -> grub.exe with MENU.LST
bcdw.ini
/isolinux/isolinux.bin; grub4dos&#59;&#59; /images/grub.exe --config-file=&#34;configfile /MENU.LST&#34;
Default hex files are used.
oscdimg should support BCDW boot sector file.
All files are upper case at CD.

Drawback: BCDW isn't supported since several years.
Works at almost all BIOS, except some strange DEL(L)ete BIOS.

Oscdimg dosn't support isolinux requirements used as a boot sector.
May work at etfsboot.com and file renaming: bootmgr or bootfix.bin

The recommended method for mkisofs is to specify the boot load size rather than the boot load segment:

Traditional boot load segment 0x7C0 is used by default.
The Boot CD specification does describe this. http://www.phoenix.c.../specscdrom.pdf

Load Segment. This is the load address for the initial boot image. If this value is 0 the system will use the traditional segment of 7C0. If this value is non-zero the system will use the specified address.

Some BIOS ignore this specification and use 0x7C0 always.

Boot load size 4 asks the BIOS to load four virtual sectors to RAM at boot load segment. And run the code.

Sector Count. This is the number of virtual sectors the system will store at Load Segment during the initial boot procedure.

Some BIOS ignore this specification and use four virtual sectors always.

First part of grldr search itself at CD.
Next load the whole file grldr to RAM and continue the code.

But there is no equivalent, that I can find, in oscdimg.

Yes, oscdimg dosn't support the CD boot specification.

You mentioned earlier that booting a flat WinPE requires more. I'll look around for the lists. Using cmd.exe could be the simplest way out.

Windows Home Server Home Computer Restore CD contain dual boot RAM load and flat WinPE. All ISO9660 names are upper cased.
http://www.microsoft...;displaylang=en


Idea, tested :drunk:.

Use bootfix.bin :

Objection: tested with XP/2003 boot sector.
Yes, should work with Vista etfsboot.com too.
Thanks for the reminder.

#16 allanf

allanf

    Gold Member

  • .script developer
  • 1256 posts

Posted 13 November 2009 - 03:11 PM

Idea, tested :drunk:.

Use bootfix.bin :

... and tested again using the basic oscdimg command:
oscdimg.exe -n -d -betfsboot.com ISODirectory file.iso
with the -d to keep menu.lst in lowercase. It works provided that the Vista Boot Files and Folders are manually changed to uppercase. Also tested the 'grldr --> BOOTMGR' and 'bootmgr --> bootfile'.That works too! bootfile is OK in lowercase, but other Vista Boot Files and Folders need to be uppercase - not sure precisely which ones because I uppercased the lot.

I don't quite get it. oscdimg -e (no emulation) and -t (boot load segment) are required when grldr is used as the boot sector file, but are not required when etfsboot.com is used?

Something you may want to explore is the possibility of grldr/grub.exe to self-modify themselves...

I was thinking along those lines. However the primary task is to keep menu.lst in lowercase - otherwise it just won't appear. To keep it in lowercase with the oscdimg -d switch, the Vista Boot Files and Folders become the problem as they also stay lowercase. So, rather than modifying grldr, I thought it would be necessary to modify the Boot Files and Folders to uppercase by using something in the Grub4Dos menu - if possible. Unless you have another idea...

#17 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7101 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 13 November 2009 - 03:32 PM

I was thinking along those lines. However the primary task is to keep menu.lst in lowercase - otherwise it just won't appear. To keep it in lowercase with the oscdimg -d switch, the Vista Boot Files and Folders become the problem as they also stay lowercase. So, rather than modifying grldr, I thought it would be necessary to modify the Boot Files and Folders to uppercase by using something in the Grub4Dos menu - if possible. Unless you have another idea...

I think we are talking of two different things.

Instead of using any external tool, it is possible to use grldr or grub.exe to self-modify the embedded menu.lst when on read/write media BEFORE using it/them on the CD, this has actually nothing to do with the menu.lst/MENU.LST problem you asked help for, that one is solved by editing the embedded menu.lst, manually or through a .script.


I am completely lost now at understanding WHAT is your goal.

If you want to use oscdimg (for the reasons you stated, which quite frankly I do not understand ) keep it easy, use oscdimg without the -d option and use a grldr (with hexedited embedded menu.lst) and renamed to BOOTFIX.BIN.

WHAT :) is the problem? :drunk:

:)

jaclaz

#18 cdob

cdob

    Gold Member

  • Expert
  • 1469 posts

Posted 13 November 2009 - 03:37 PM

oscdimg -e (no emulation) and -t (boot load segment) are required when grldr is used as the boot sector file

No, neither -e nor -t is required when grldr is used as the boot sector file.
Oscdimg set no emulation mode by default.

Some BIOS load whole grldr to RAM 0x7C0, booting does work.
Other BIOS freeze.

but are not required when etfsboot.com is used?

Vista etfsboot.com file size is 4 sectors. This is the tradional default.
And oscdimg use no emulation mode.
BIOS use load segment 0x7C0.
This are the classic NT boot conditions since 15 years. A lot of BIOS support this conditons nowdays.

I thought it would be necessary to modify the Boot Files and Folders to uppercase by using something in the Grub4Dos menu - if possible.

I don't know a appropiate approach.
There is dd and write at grub4dos. But how to uppercase file names?

#19 allanf

allanf

    Gold Member

  • .script developer
  • 1256 posts

Posted 13 November 2009 - 03:47 PM

Traditional boot load segment 0x7C0 is used by default.
The Boot CD specification does describe this. http://www.phoenix.c.../specscdrom.pdf
Some BIOS ignore this specification and use 0x7C0 always.

Boot load size 4 asks the BIOS to load four virtual sectors to RAM at boot load segment. And run the code.Some BIOS ignore this specification and use four virtual sectors always.

First part of grldr search itself at CD.
Next load the whole file grldr to RAM and continue the code.


I think I am beginning to understand! Thanks. I had thoughts that boot load segment 0x1000 was effectively the same as boot load size 4, because either one was necessary and they seemed interchangeable. But they are not the same. What's the secret of 0x1000?


Windows Home Server Home Computer Restore CD contain dual boot RAM load and flat WinPE. All ISO9660 names are upper cased.

I see. All filenames in upercase should be OK for RAM and flat.

Thanks :drunk:

#20 cdob

cdob

    Gold Member

  • Expert
  • 1469 posts

Posted 13 November 2009 - 04:07 PM

What's the secret of 0x1000?


Update 5: Now GRLDR can be used as a no-emulation-mode bootable CD-ROM
boot image. Example for Linux users:

mkdir iso_root
cp grldr iso_root
mkisofs -R -b grldr -no-emul-boot -boot-load-seg 0x1000 -o bootable.iso iso_root

As an alternative, grldr can also be used the same way as
stage2_eltorito. The -boot-info-table option is allowed but you
can omit it:

mkdir iso_root
cp grldr iso_root
mkisofs -R -b grldr -no-emul-boot -boot-load-size 4 -o grldr.iso iso_root

Also note that the bootable.iso above must be created with the
-boot-load-seg 0xHHHH option where HHHH is greater than or
equal to 1000(hex). If HHHH < 1000(hex), QEMU will hang. This
is a bug in QEMU. The grldr.iso can be created with or without
-boot-load-seg 0xHHHH option.



#21 allanf

allanf

    Gold Member

  • .script developer
  • 1256 posts

Posted 13 November 2009 - 04:33 PM

Instead of using any external tool, it is possible to use grldr or grub.exe to self-modify the embedded menu.lst when on read/write media BEFORE using it/them on the CD, this has actually nothing to do with the menu.lst/MENU.LST problem you asked help for, that one is solved by editing the embedded menu.lst, manually or through a .script.


I didn't quite grasp the idea of self-modifying the embedded menu.lst before using it on CD.

What's my problem? No problem. It's been solved. But always looking out for better solutions.

#22 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7101 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 13 November 2009 - 04:59 PM

I didn't quite grasp the idea of self-modifying the embedded menu.lst before using it on CD.

As said the idea is NOT suited for your particular problem, if you build the CD in DOS or a in a VM, you can use it.


It can also be used ONCE you have booted to either grldr or grub.exe, and of course you need a Read/Write accessible media.
Example:
floppy image --mem mapped

I.e. BIOS->
etfsboot.com->
BOOTFIX.BIN(actually grldr disguised ;))->
modified embedded menu.lst:

find --set-root /GRLDR.IMA
map --mem /GRLDR.IMA (fd0)
map --hook
root (fd0)
<insert here any modification to menu.lst or embedded menu.lst on the floppy>
chainloader +1

->grldr or DOS+grub.exe on floppy->
self-modified menu.lst or embedded menu.lst

(pretty much pointless ;))


What's my problem? No problem. It's been solved.

Good. :)

But always looking out for better solutions.

Better solutions but WITHOUT using third party files? :drunk: You are already "lucky" enough we were able to give you a working solution! :)

;)

jaclaz

#23 allanf

allanf

    Gold Member

  • .script developer
  • 1256 posts

Posted 13 November 2009 - 05:25 PM

I.e. BIOS->
etfsboot.com->
BOOTFIX.BIN(actually grldr disguised :drunk:)->
modified embedded menu.lst:
... [example menu.lst] ...
->grldr or DOS+grub.exe on floppy->
self-modified menu.lst or embedded menu.lst


I'd like to pursue this some time.

@cdob

Going back to an earlier post that I crossec over.

oscdimg -bootdata parameter seems to require e (no emulation) and t (boot load segment) switches.

I'll try to do a roundup of everything I've tested.

Regards ;)

#24 allanf

allanf

    Gold Member

  • .script developer
  • 1256 posts

Posted 13 November 2009 - 08:29 PM

Files and folders used are as originally downloaded from the developer, unpacked and copied to the ISO source folder.
WAIK - bootmgr and /boot folder and contents are lowercase. Created /sources folder and boot.wim are lowercase. Mounted winpe.wim (boot.wim) files and folders are mixed case.
Grub4Dos - grldr is lowercase.

For these basic tests, menu.lst is not used at all, so that Grub4Dos will boot to the grub command prompt. Reason is to avoid the "spanner in the works" of an inappropriately uppercased menu.lst and hence to avoid the complexities of using the -d (allow lowercase) switch. There's only one thing to load - bootmgr, so the only command required is "chainloader /BOOTMGR"

Scripts are run by winbuilder076, which basically copies files from the WAIK folder to the ISO source folder, then makes a copy of WAIK's winpe.wim, mounts the copy, prepares it, unmounts it committing changes, and exports the finished wim to /sources/boot.wim in the ISO source folder. Winbuilder then runs a batch file to set local for the path to oscdimg, and to run the oscdimg command creating the .iso file.

The file is booted from the virtual CD Drive of VirtualBox with no HDD attached.

Results are either successful boot of WinPE 2.1, an immediate black screen with frozen cursor and 100% CPU usage, or a black screen with 'CDBOOT : Cannot boot from CD - Code: 3, and a frozen cursor'.

ISO is the path to the ISO source folder.

1. Frozen
oscdimg.exe -n -bgrldr ISO pe21.iso


2. Success
oscdimg.exe -n -bootdata&#58;1#bgrldr,e,t0x1000 ISO pe21.iso


3. Frozen
oscdimg.exe -n -bootdata&#58;1#bgrldr,e ISO pe21.iso


4. Success
oscdimg.exe -n -bootdata&#58;1#bgrldr,t0x1000 ISO pe21.iso


5.Frozen
oscdimg.exe -n -bootdata&#58;1#bgrldr ISO pe21.iso


The following is with grldr renamed to bootfix.bin in /boot folder of ISO source.

6. Success
oscdimg.exe -n -betfsboot.com ISO pe21.iso


7. Cannot boot from CD
oscdimg.exe -n -bootdata&#58;1#betfsboot.com,e,t0x1000 ISO pe21.iso


8.Success
oscdimg.exe -n -bootdata&#58;1#betfsboot.com,e ISO pe21.iso


9. Cannot boot from CD
oscdimg.exe -n -bootdata&#58;1#betfsboot.com,t0x1000 ISO pe21.iso


10.Success
oscdimg.exe -n -bootdata&#58;1#betfsboot.com ISO pe21.iso

I think I see the pattern.

The other result, 'Windows failed to start... [BCD error]' happened while mucking around with menu.lst, the -d (allow lowercase) switch and manually (clumsily) changing the Vista Boot Files and Folders to uppercase. That result happened twice when I removed the e switch but was probably caused by something else.

BTW, the mkisofs command
mkisofs.exe -R -b grldr -no-emul-boot -boot-load-size 4 -o pe21.iso ISO
does leave the boot files and folders in their original lowercase form. Other files and folders from the winpe.wim custom files and folders, such as Program Files and Tools are in their original mixed-case form. So, it seems the command keeps the original case. It still boots. I'd say it has something to do with Rock Ridge. I can't spot any difference between the -R and -r switches, but then again, I'm a bit bleary-eyed ATM.

EDIT: The wim is not open in the .iso.

:drunk:

#25 cdob

cdob

    Gold Member

  • Expert
  • 1469 posts

Posted 13 November 2009 - 10:21 PM

BTW, the mkisofs command

mkisofs.exe -R -b grldr -no-emul-boot -boot-load-size 4 -o pe21.iso ISO
does leave the boot files and folders in their original lowercase form.

I don't think so. Did you edited mkisofs source code and compiled a own version?

ISO9660 names should be upper cased, rock ridge extension may be lower case.

Or rephrased: there are two names for each file: a ISO9660 name and a rock ridge name.
The Rock Ridge extension names are: leave the boot files and folders in their original lowercase form.
ISO9660 names are changed.

I can't spot any difference between the -R and -r switches

It's about rock ridge permissions. You may ignore this as long the booted OS ignore rock ridge permissions.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users