help with grubinst.exe

I am writing an autoit scrpit. It installs grub4dos bootsector on an USB disk partition.

RunWait(@ScriptDir & "\files\grubinst.exe -v --pause " & $trggrub, "", @SW_SHOW)

which in produces:
grubinst.exe -v --pause (hd3,0)

$trggrub is (hd3,0), I triple checked that.

The issue is the even though grubinst.exe reports :

Start sector: 0x3F
Image type: FAT12/FAT16
Install mode
The MBR/BS has been successfully installed
Press <ENTER> to continue ...

This is on the USB stick:


What is strange for me, is that if I make a new autoit file, containing only 2 lines:

$trggrub = "(hd3,0)"

RunWait(@ScriptDir & "\files\grubinst.exe -v --pause " & $trggrub, "", @SW_SHOW)

it works, grub4dos bootsector is written.

What could be wrong? Is the question rather related to AutoIt? If yes, why grubinst.exe reports success, but no BS is written? Open handles to that drive? Delayed writes because it's USB? What else it could be?

Using grubinst-1.1-bin-w32-2008-01-01 from http://download.gna.org/grubutil/

I read:

--duce disable the feature of unconditional entrance to the command-line.

and did understand it fully. Anyway I tried it- no change, bootsector still not written.

I can confirm- something is not as supposed to be either on grubinst.exe or Windows side.
Connected USB hard disk. Launched grubinst_GUI.exe. Wrote bootsector to first partition, verbose mode- reported success.
Used 'safely remove hardware' and waited until Windows allowed me to unplug it. No other write operation were performed on the disk.
Booted that disk on another computer- grub4dos bootsector was NOT written.

Tried again- connected it to my machine, grubinst_GUI in the same way, ejected, booted on the other machine- this time it worked, bootsector was written.

So there is nothing to do with AutoIt.
Why did it failed the first attempt?

Are you sure it always be (hd3) each time you plug the USB hard drive?

Yep, checked million times
It appears as such in grubinst_GUI though.

If that helps you- read operations are fine. I use grubinst.exe to make a backup of MBR and bootsector of the selected hard disk/partition. This goes fine, backups are made.
I may install syslinux to that partition, using "syslinux J:" for example. This gets written. Then I want to write back the backed up bootsector- this fails. Attempt to write grub4dos bootsector fails too. I end up with syslinux bootsector.
This is in a script, and the variable doesn't change, watching the console what exactly is sent to grubinst.exe.

Anyway, when grubinst_GUI was used, alone, outside of the script, it failed too the first time.
What could it be? I am playing third day with that, and still can't figure out why it fails on me. Any ideas are welcome.

----

For your USB hard drive it would be swap sdb1,2,3 you can also download supergrub disk if you are still battling with the bootmanager it's GUI and repairs Ext2,3 FAT and NTFS partitions' boot sectors as well as the master boot record whether it's of a Windows type or Linux.


Burn the iso to disc and boot off it


sda1

Thanks for your input, but please do read what is all about

1) grubinst.exe is launched in Windows.
2) Expected syntax is (hdX,Y), there is no sdXY
3) I need to install grub4dos bootsector from an AutoIt script. Where does supergrub disk fit?
4) You quoted Tynibit, who is among the grub4dos developers. Presumably, he knows how to fix his bootsector

It's strange, do you mean it would fail the first time ? Is this behavior consistent, or happen once in a while ?

Also, can you give a detailed description of the operation taken, let me see if I can reproduce the result in my side.

When grubinst.exe is called from the AutoIt script write operations fail, nearly all cases. Read operations seem fine, using -t switch to make backups of BS and MBR.

grubinst_GUI.exe was used alone, NOT from the AutoIt script. First time it failed, even though it reported success(see posts above) on a second attempt it succeeded. USB disk is properly ejected, using Safely remove hardware, and replugged between the attempts.
I restarted the PC just in case, System Restore is turned off on all drives.

What fails:
From the AutiIt script:
grubinst.exe -v --pause (hd3,0)

Separately, not using AutoIt:
grubinst_GUI.exe- selected the same disk/partition.


In all cases grubinst.exe reports success, so nothing wrong with the syntax or target drive/partition. Just in case I checked bootsectors on all other hard drives connected- none had grub4dos BS.

If you want to test on your side, I can send you a compiled snippet of the AutoIt program. Just give me a little time to prepare it.

edit: you've got a PM

Thanks for your input, but please do read what is all about

1) grubinst.exe is launched in Windows.
2) Expected syntax is (hdX,Y), there is no sdXY
3) I need to install grub4dos bootsector from an AutoIt script. Where does supergrub disk fit?
4) You quoted Tynibit, who is among the grub4dos developers. Presumably, he knows how to fix his bootsector

o.k. I am shutting up lol. sorry for not reading the complete post

@ ilko do you think you can pm me that as well ?

I'm sorry, but I can't reproduce the result on my side. I do notice that my grubinst.exe is different from yours. Perhaps you can try my version:

http://grub4dos.sour...-2008-06-29.zip

BTW, have you tried running grubinst.exe from command line ?

Weird, I just run the same test file on another machine. grubinst.exe was replaced with the version you posted. No grub4dos BS was written
Both machines are running XP SP2, Home and Pro.
USB stick was formatted prior to running the test file.

BTW, have you tried running grubinst.exe from command line ?

I made the script run it as called from command line too, that was the initial script- this fails too.

Also tried to use alternative syntax - "grubinst.exe -v --pause -p=0 (hd3)"- no joy

I believe the problem is caused by the autoit script. Something done previously must have locked the volume, cause write operation to fail. You can examine the script carefully, see if there is something wrong. For me, the target list look suspicious, how do you get the list, does it involve locking ? Perhaps you can try disable scanning, and set the disk name manually, see if it succeed.

I believe the problem is caused by the autoit script. Something done previously must have locked the volume, cause write operation to fail. You can examine the script carefully, see if there is something wrong. For me, the target list look suspicious, how do you get the list, does it involve locking ? Perhaps you can try disable scanning, and set the disk name manually, see if it succeed.

Here is the bugger. grub4dos bootsector is written indeed, however, if there are file copy operations to the same drive AFTER grubinst.exe, bootsectors reverts to the previous one. It has nothing to do with the AutoIt script.

Run this batch file:

test.bat:

grubinst.exe (hd3,0)

pause

copy grldr j:\ /y

copy menu.lst j:\ /y

pause

Right after grubinst.exe, during the first pause I check the BS with HDHacker- it is grub4dos one, close HDhacker. Hit any key to copy files, grldr and menu.lst are copied, second pause, check bootsector again- it's NT one

If I close the script during the first pause, grub4dos BS stays.

How the heck the bootsector is "reverted" ?

New game- let's try syslinux.exe

test.bat:

syslinux.exe -f j:

pause

copy grldr j:\ /y

copy menu.lst j:\ /y

pause

This works, after the first and second pause SysLinux BS is there, nothing is reverted.

Nice catch, I think this is Windows fault. It must cache the boot sector somewhere. After the copy operation, it modify the in-core copy of boot sector and write it back (like update free space info, etc), thus overwriting the grub4dos bs.

I think the bootsector operation is somehow 'ignored' if other file writes are performed afterwards to the same volume, windows just reverts to the previous BS, ignoring what grubinst.exe did.
The points are:
1) Why syslinux.exe doesn't fail? Using different procedures to write the BS?
2) How one install safely grub4dos bootsector and perform file writes to the same volume from a script?
Premade FAT32 grub4dos bootsector:

mkbt -x fst32grldr.dat j:

copy grldr j:

This causes severe lockups, explorer.exe crashes, programs (notepad++, PSPad...) won't visualize even though they are shown in task manager etc. Had to restart the PC.

Writing bootsector as a last operation in the script could be an option, but I'd rather look for a fix.

For syslinux, it opens the drive J:, so windows know when we make change to it. But for grubinst, it open the physical disk and parse mbr itself. The disk layout is below file system, so the change is not detected by windows.

Can you think of workaround?
What about 2) ?

BTW mkbt followed by file copy screwed up my flash drive, it's no longer recognized from Windows as a USB device, Lexer's BootIt won't recognize it either, Apacer's Handy Stemo fails too.
If anyone is attempting the same steps DO NOT play with mkbt followed by file writes on the same volume.

edit: The only tool succeeded was TinyHexer, after a loooong delay it displayed it as physical disk and managed to writes zeroes on it. After that formatting worked normal.

I just create a small tool touchdrv.exe, which reads the bs and write back. Use it immediately after grubinst would fix the bs overwrite problem. For example:

grubinst (hd3,0)
touchdrv F:
copy grldr F:\

Try this:

grubinst.exe (hd3,0)
dsfo \\.\j: 0 512 j:\fst32grldr.dat
pause
(check if j:\fst32grldr.dat is the grub4dos bootsector)
dsfi \\.\j: 0 512 j:\fst32grldr.dat
pause
(check if j:\ has the grub4dos bootsector)
copy grldr j:\ /y
copy menu.lst j:\ /y
pause
(check if j:\ has the grub4dos bootsector)

or alternatively:

grubinst.exe (hd3,0)
dsfo \\.\j: 0 512 j:\fst32grldr.dat
pause
(check if j:\fst32grldr.dat is the grub4dos bootsector)
copy grldr j:\ /y
copy menu.lst j:\ /y
pause
(check if j:\ has the grub4dos bootsector)
dsfi \\.\j: 0 512 j:\fst32grldr.dat
pause
(check if j:\ has the grub4dos bootsector)

jaclaz

P.S.: Sorry, cross-posting, I see that Bean123 already provided a solution.

Well, it works, what can I say... million thanks, all the best

Will it work on Vista or x64 Windows?

Well, it works, what can I say... million thanks, all the best

Will it work on Vista or x64 Windows?

I haven't tried it yet, but it should be ok.

BTW, the previous touchdrv.exe has some debug output, I remove them now.

Added the second touchdrv.exe to AutoIt script right after grubinst.exe, now everything is working fine
You should see the smile on my face, it's been a week digging into this.
Thanks again.

Try this:...

Sorry, I missed that post as it went on a previous page.
I'll will be doing check for grldr BS anyway, thinking to use grubinst.exe backup functionality and examine the produced file for grldr.
The reason to use grubinst.exe is that I'd prefer to stick to a limited number of external tools. If any of them fails, then I'd use another.

Thanks, I wondered were you been since page 1, expected you to suggest dsfo solution

I tried it for the record, at first file copy operation it's stuck, had to close the batch. Explorer didn't crash this time, but after ejecting the stick using "safely remove..." and replugging it, it's again not recognised by silly Windows, reporting "write delay failed....". Back to TinyHexer.

dsfi \\.\j: 0 512 fat32grldr.dat

pause

copy grldr j:\ /y

copy menu.lst j:\ /y

pause

I played a bit more with this. The problem must lie in windows caching, switched USB drive to "optimize for performance" and the tasks

-backup BS
-install syslinux BS
-get the syslinux BS and copy it to the same drive
-write back original BS

using grubinst.exe became impossible, even with the help of touchdrv.exe, which works brilliant when only grub4dos BS is installed, thanks.
Run in all kind of variants, before each line, just after writes, just after grubinst.exe writes, with 5-10 second pauses etc. File copy was moved at the end- no joy. The original BS was not written back.

So here came the light:

syslinux.exe -f j: j:\syslin.dat

Syslinux 3.63.
This writes the syslinux BS to syslin.dat. BS in drive J: is not touched. If file is omitted, then BS will go to the partition. This is not in SysLinux documentation, neither in their site, nor in the docs, coming with the package, which I checked so many times for something similar. Downloaded the latest 3.70- still not a word that it can write it's BS to a file, instead to a partition.