Hello @Brian K, In your reply, you say to "copy bootit.ini (or bootitbm.ini) and ifl.ini to the folder containing makedisk.exe". I have a few questions... Where would I "copy" from (as I can not find these files)? Or would I just create my own bootit.ini file and ifl.ini file? If I need to create my own, would the ifl.ini I posted below work for what I want? Code: [Options] TimeZone=USA+5EST ISO8601=1 MDUseDirData=1 GlobalGeoAlign2K=1 [LICENSE] ProductKey=xxxx-xxxx-xxxx-xxxx-xxxx-xxxx User=My Name [BACKUP_DEFAULTS] UseMetaData=1 CreateHash=1 Encryption=3 [RESTORE_DEFAULTS] UseMetaData=1 Would the bootit.ini that I posted below work for creating the BIU UFD (includes the settings you originally had me change when I installed and set-up BIU)? Code: [Options] TimeZone=USA+5EST ISO8601=1 GlobalGeoAlign2K=1 [LICENSE] ProductKey=xxxx-xxxx-xxxx-xxxx-xxxx-xxxx User=My Name Am I correct in that I would place both ifl.ini and bootit.ini into the C:\Program Files (x86)\TeraByte Drive Image Backup and Restore Suite\IFL folder? And I could place the bootit.ini file into whatever folder i use to create the BIU UFD? Would I then just leave all of the information blank when I use makedisk.exe to create the IFL UFD and BIU UFD and everything will be picked up from the .ini files? I apologize for all of the questions but the process of doing this for IFL is completely different that doing it for IFW and I just want to verify that I totally understand what I need to do.
Hello @Brian K, I had been planning on switching to the 64-bit version of IFL so I decided to do a test run creating a recovery media with both the ifl.ini and bootit.ini files. I discovered that makedisk.exe prompted me with both files and asked if I want to include them. I checked both files and proceeded. Since I chose both .ini files, I was not prompted to select any settings or options. The IFL UFD booted fine and all worked as expected except my BIU license was not accepted. When trying to use some of the "BootIt features", I was prompted for my BIBM license. If I set-up everything correctly as I outlined in my above post, it would appear that TeraByte has not gotten all of the new BootIt licensing incorporated into all of their products yet. If you could please look over my questions and .ini files in the above post to verify whether I did everything correctly or not, it would be greatly appreciated. I assume the licensing issue is on TeraByte's end and will be fixed soon. I had this same issue when trying to do something else but at the moment, I do not remember exactly what it was except it concerned the migration from BIBM licenses to the new BootIt Collection licensing.
I just checked this and it looks like the setup still requires the file to be named BOOTITBM.INI rather than bootit.ini. Just change the filename from bootit.ini to BOOTITBM.INI and run makedisk.exe again. Let me know if it works.
Kent, I arrived home yesterday from a fishing trip. Sorry I've missed your previous questions. You don't really need to do the below instructions as you have workable ini. OK. Create an IFL boot disk with makedisk.exe and fill in all your intended options and registration information. Boot the disk (CD or UFD). Run IFL. Run through a pretend Backup (and Restore) as far as the Options page. Click Save Defaults. Open IFL, Settings, make any changes you deem necessary. Open Partition Work, Settings. Make any changes you deem necessary. Mount a HD partition from the mnt icon. Choose any partition you know you can access from Windows. Click the MC icon. Midnight Commander maximize MC on the right side of the screen select /mnt1 and press Enter in the left side of the screen select ifl.ini press F5 on the keyboard (Copy) you should see copy ifl.ini to /tbu/mnt1 click OK in the left side of the screen select BOOTITBM.INI press F5 on the keyboard you should see copy BOOTITBM.INI to /tbu/mnt1 click OK press F10 on the keyboard to close MC Boot into Windows and copy both ini to the IFL folder containing makedisk.exe.
A few words on the 64-bit version of IFL. If your current IFL works you don't really need 64-bit. 64-bit is needed for a few computers that won't boot the standard IFL. My son's Dell XPS laptop for example. If you want to run BootNow in IFL you need 64-bit. If you want to run UEFI lines such as "list uefi bootitems" you need 64-bit. See page 27 in the TBOSDT user-guide regarding mounting efivarfs.
Hello @Brian K, No problems at all. You had not been around for awhile so I had assumed that you were probably on vacation. It also gave me a chance to do some playing around and learning on my own and just have you verify what I have done was correct. Yes, it does work. I guess that I should use bootitbm.ini wherever necessary unless an issue comes up and then try bootit.ini. I will see which one to use for BIU next time an update is released. OK. I will mark this post for future reference. I knew that when you saved anything while you were booted in IFL that it was only saved virtually and would be gone as soon as you rebooted. I had not thought of doing the copying of the files from virtual space to a actual hard drive. Thanks for that tidbit of information as it may come in handy in the future. I have also been playing with Midnight Commander as at least for me it has a bit of a learning curve to use it. I am only using BootNow from Windows currently and probably will not use it elsewhere. Since I have already made the change to IFL 64-bit, I will just stick with it unless I change my mind and decide to use BootNow from within IFL. And as always , thanks for your help !
This is how I run BootNow in IFL to boot Cinnamon and Win10 (as examples). You can have many items. Copy cinn19.sh, win10.sh and bootnowu to the IFL scripts folder. This can be done on the UFD or the IFL partition. Or prior to using makedisk. The scripts are... Code: #! /bin/sh mount -t efivarfs none /sys/firmware/efi/efivars cd scripts ./bootnowu cinn19 Code: #! /bin/sh mount -t efivarfs none /sys/firmware/efi/efivars cd scripts ./bootnowu win10 Right click the desktop, Display User Scripts Menu, select your item.
Mr.X, I'm seeing something similar and TeraByte is working on a fix. C:\Program Files (x86)\TeraByte Drive Image Backup and Restore Suite\IFL is now 64-bit so I made my UFD from there and it works fine. It's only the extra (Custom) IFL downloads that have a problem.
When you install IFW it installs an updated IFL. I always update IFL but it's not essential if the image format hasn't changed. However, the format does change every few updates. The format hasn't changed with 3.33 so an updated IFL isn't essential for restoring a 3.33 image. 3.32 IFL will still work. 3.33 IFL in the C:\Program Files (x86)\TeraByte Drive Image Backup and Restore Suite\IFL folder is now 64-bit so that's handy for me as my BootNow scripts require a 64-bit environment.
Off topic but I copy the IFL UFD to a partition on my SSD. IFL boots from the SSD and media is no longer needed. I do my Windows restores from the SSD IFL partition. This works with MBR and UEFI systems. You can use this method with many PEs. I recall Macrium, AOMEI, EaseUS Todo, Acronis.
In my best Yoda speak... "Something obvious, missing am I." Was playing around with Bionic Puppy (Linux) today and built a System on a hard disk. Decided to image a successful build using IFL. Then decided to restore that single partition System to a clean SSD. Ran the restore and made sure that FIRST TRACK and SET ACTIVE were done prior to beginning the restoration. The process went well but the result failed to BOOT (some silly "Wee" msg from Puppy upon attempt). Imaged both the whole disk and just the partition, same result. Any ideas (Brian, et al)...?
TRF, Several years ago someone noted that grub2 was spread across the first 128 sectors and not the first 63. I thought TeraByte fixed "Restore First Track" to allow for this but what I'd try is not use Auto for RFT but use a set number of sectors, say 200. Don't use Set Active either. Are you doing the restore in the same computer that previously contained Puppy? Does that work? Edit... If it fails try using Assume Original HD as well.
It's in the same machine that Puppy was built in, just swapping the HDD build to an SSD. I'll try your suggestions and report back, thanx!
Brian... nail, head, bullseye! The AUTO restore feature is still short of restored sectors when using GRUB and its extended counterparts. I've used IFL many times in the past for 100s of Windows restores but very little, if any, for LINUX restores. The few times in the past I've restored LINUX Systems I always used Macrium Reflect 'cause the Recovery Media was always very handy and always nearby. Thanks for the heads up on the restored length needed (I used 200, 128 would probably work just as well) for full GRUB functionality... all is well at "The Pond" once again.
If I was restoring to the original HDD I built to, it would have worked just fine 'cause the extended MBR would have still be on the disk following the shortened one put back by "Restore First Track (AUTO)." Since I was restoring to a BLANK (Secure Erased) SSD, there was no DATA anywhere on the device... therefore failure with a shortened GRUB loader. Ya sure can get fooled sometimes... that's why we have this Forum and people like @Brian K