Unable to open BOOTIT.DAT in 1.03

[tas3086]

Installed the 1.03 BIU update and now get "Unable to open message" When trying to go to maintenance mode to create boot menu.
Any ideas?
FYI:Running with UEFIRenDirSafe=1 because system does not support UEFI rename correctly.

[TeraByte Support(PP)]

See this KB article:
https://www.terabyteunlimited.com/kb/article.php?id=626

[tas3086]

Paul,
Using UEFIRenDirSafe=1 and UEFINoRemount=1 makes BIU almost unusable.

That happened between version 1.02 and 1.03? It was working pretty good with UEFIRenDirSafe=1 until 1.03 came along.
Disappointed...

[TeraByte Support]

Just the opposite. For those getting Unable to open BOOTIT.DAT, you
couldn't do ANYTHING unless setting UEFIRenDirSafe=1 which is fine unless
your system can't handle renaming. If UEFIRenDirSafe=1 then the value
of UEFINoRemount is ignored. I think you got your setting backwards.

Anyway, On a system that requires UEFINoRemount=1 then there are the
following limitations:

* When upgrading a BootIt UEFI installation you will need to use the
Reinstall BootIt UEFI option (the upgrade option will not be shown).
* Scripts can't be run from the desktop.
* Scripts in Boot Items won't be run.
* TBOSDT will not have a C: prompt (file system is not available).
Partitions can be mounted for access. Scripts may have errors or conflicts
if run from a mounted partition.
* Image for UEFI GUI isn't supported. Refer to the applicable section at the
end of this article if you would like to use the CUI version.
* Image for UEFI options will have default values (custom settings will not
be read).
* If you need to disable the UEFINoRemount option you will need to do it
manually by editing the installation's BOOTIT.INI file.

What you will be able to do:

* Use the Boot Menu, Direct Boot Menu, and Maintenance Mode.
* Use Boot Edit to manage boot items.
* Use Partition Work.
* Use TBOSDT.
* Use Image for UEFI CUI.


"tas3086" wrote in message news:15441@public.bootitbm...

Paul,
Using UEFIRenDirSafe=1 and UEFINoRemount=1 makes BIU almost unusable.

That happened between version 1.02 and 1.03? It was working pretty good
with UEFIRenDirSafe=1 until 1.03 came along.
Disappointed...

[tas3086]

TeraByte Support wrote:
> Just the opposite. For those getting Unable to open BOOTIT.DAT, you
> couldn't do ANYTHING unless setting UEFIRenDirSafe=1 which is fine unless
> your system can't handle renaming. If UEFIRenDirSafe=1 then the value
> of UEFINoRemount is ignored. I think you got your setting backwards.

Not true at all. Originally booting from the install Pen drive locked the system. You told me to add UEFI RenDirSafe=1 to the bootit.ini file.
The install then went fine. Ran a rename test and yes, the renamed file no longer was available.
Installed 1.02 Update with RenDirSafe=1 and BIU continued to work fine.
Installed 1.03 Update with RenDir Safe=1 now BIU boots, but any operation generated UNABLE TO OPEN BOOTIT.DAT message.
Per your suggestion I added UEFINoRemount=1 to the ini. BUI now boots, can go into maintenance, but due to limitations, can not do anything useful, nor will any scripts work. So it is useless.
So something did change between 1.01 and 1.03 that required the no remount option to be added. And therefore "If UEFIRenDirSafe=1 then the value
of UEFINoRemount is ignored." is not true … It is not ignored.

If UEFINoRemount is required, BIU is not usable for anything other than being a multi Boot selector, which I can already do from my UEFI bios.
So I will try TBOS UEFI booting and see if scripting still works. I already know that the old uefi partwork works, and may otherwise have to stick with the original versions of BIU.

[TeraByte Support]

"tas3086" wrote in message news:15459@public.bootitbm...

>Originally booting from the install Pen drive locked the system. You told
>me to add UEFI RenDirSafe=1 to the bootit.ini file.

The UEFIRenDirSafe=1 was given as an option to you getting the "UNABLE TO
FIND BOOTIT.DAT" with the caveat that the system UEFI needs to support
renaming of directories properly.

You then had the Windows directories from \EFI disappearing. The answer
to that was simple, your system doesn't correctly rename directories so
UEFIRenDirSafe=1 isn't safe.

Eric gave you an option that you could disable the "rename" option on the
boot items. That way you could use UEFIRenDirSafe=1 so it does not dismount
the BootIt partition and therefore not need to remount it, and it won't try
to rename the directories when you boot (however, it would if you installed
a new OS, so watch out there, you'd have to go back to UEFIRenDirSafe=0,
before returning to UEFIRenDirSafe=1).

The new option UEFINoRemount=1, which only means anything when
UEFIRenDirSafe=0, allows basic functionally for systems with UEFI that can't
properly remount partition that were unmounted due to UEFIRenDirSafe=0 being
used. You can do all the important stuff like multi-booting, partition
work operations, disk imaging, including run scripting. What you can't do
is run scripts from a boot item or from the desktop (I don't believe). To
run scripts, you would choose scripting, then use the mount command to mount
a partition and run it from there, but the more advanced scripts may need a
particular drive 0: 1: 2:, etc.. so there is a potential conflict, we'll
make a list available.

Once you install with UEFINoRemount=1, you have to manually edit the
installed version and remove it (plus build a boot disk without it). It
will always pull it in if it finds it anywhere (installed or boot media).

Do note that your installed settings are pull in to the boot version when it
can be. Only the video settings are taken from the boot disk if already
installed.

[tas3086]

TeraByte Support wrote:
> You can do all the important stuff like multi-booting, partition
> work operations, disk imaging, including run scripting. What you can't do
> is run scripts from a boot item or from the desktop (I don't believe). To
> run scripts, you would choose scripting, then use the mount command to
> mount a partition and run it from there, but the more advanced scripts may need a
> particular drive 0: 1: 2:, etc.. so there is a potential conflict, we'll
> make a list available.

Thank you, I understand all of that. But with systems with many multiple hard drives, and many partitions on each, it is very difficult to keep track of drive numbers and partition id's in order to do a OPEN FS drive: phydrivenum [partitionid] (MOUNT)command. Especially when drives are constantly being added and removed. For this reason I created a script to determine/show all disk and partition numbers, and pass those as parameters to a number of other scripts that handle various mounting configurations and work efforts.

Again, with only the UEFIRenDirSafe=1 option everything worked with stated limitations, in version 1.01 . 1.03 introduced the bootit.dat problem and the required the UEFINoRemount=1 option to at least get into maintenance mode, where scripts are not easily available without yet another mount.
Like I said, I'm disappointed in BIU and UEFI not being kept current and standard by the motherboard manufacturers.

Luckily my motherboard allows easy selection of booting BIBM or BIU, so I may be able to use BIBM to setup BIU configurations and then boot over to BIU to test things out. Time will tell. Keep us informed of the evolving conflicts. Maybe AsRock will update their Bios someday too, as UEFI applications like yours continue to be developed.

Thank you for your information. Your products and support are still the best in the industry.

[TeraByte Support]

We tested on a system that has the same problem as yours and using
UEFIRenDirSafe=1 doesn't cause the Unable to open BOOTIT.DAT message. May
want to double check your bootit.ini file settings of the booted installed
version (ensure you don't have another install booting somewhere).