followed the instruction below. 

Run the CMD app as admin, and then

 

J:\>make_bootable.bat
Make Bootable v1.5
 Volume in drive J is UNRAID
 Volume Serial Number is AECA-3701

Permit UEFI boot mode [Y/N]: y
Ready to make disk bootable!
Press any key to continue . . .
J:\syslinux\syslinux.exe -maf J:
Completed

Press any key to continue . . .

J:\>

 

No difference

2 hours ago, gnollo said:

followed the instruction below. 

Run the CMD app as admin, and then

 

J:\>make_bootable.bat
Make Bootable v1.5
 Volume in drive J is UNRAID
 Volume Serial Number is AECA-3701

Permit UEFI boot mode [Y/N]: y
Ready to make disk bootable!
Press any key to continue . . .
J:\syslinux\syslinux.exe -maf J:
Completed

Press any key to continue . . .

J:\>

 

No difference

Try again with

Permit UEFI boot mode [Y/N]: n

 

no difference

I restored the backup of the old key to the new key. Cleared the /previous folder on the old key.

Copied the bz* files across to both keys.

Rebooted the server. Now I am running 6.8. 

Both keys are in synch but the one recognised as the boot device is the one that is not booting on its own.
Not ideal, and I wonder what will happen once the other key blacklisting comes into effect.

I don't remember, did you ever try a different USB port?

I don't remember, did you ever try a different USB port?

Yep, tried several. The old key is recognized in the bios in every port, the other one is not.

Sent from my SM-A520F using Tapatalk

It might be worth changing the label on the 'old' key to be something other than 'UNRAID' and checking that the 'new' one is labelled as 'UNRAID' and see if the system then still boots OK.  If it does then that would confirm that the problem must lie with how the 'new' one is being made bootable as it would confirm that the initial stage of the boot ran from the 'old' key ant the later stages from the 'new' one.  

 

There have been reports of security software silently interfering with attempts to modify the MBR on a flash drive to make it bootable so I am wondering if there is a possibility of that being your problem.

It might be worth changing the label on the 'old' key to be something other than 'UNRAID' and checking that the 'new' one is labelled as 'UNRAID' and see if the system then still boots OK.  If it does then that would confirm that the problem must lie with how the 'new' one is being made bootable as it would confirm that the initial stage of the boot ran from the 'old' key ant the later stages from the 'new' one.  
 
There have been reports of security software silently interfering with attempts to modify the MBR on a flash drive to make it bootable so I am wondering if there is a possibility of that being your problem.

More testing tonight, including uninstalling antivirus, a bigger Cruzer, using Rufus to prepare the flash drive and using a cdrom bootloader

Sent from my SM-A520F using Tapatalk

On 12/16/2019 at 9:58 AM, gnollo said:

More testing tonight, including uninstalling antivirus, a bigger Cruzer, using Rufus to prepare the flash drive and using a cdrom bootloader

Sent from my SM-A520F using Tapatalk
 

Rebuild the second flash key with antivirus off, UEFI Boot mode NO, no change. Also tried the same with a new Sandisk Cruzer FIT 16 GB USB 2.0 Flash drive. Same difference. It is seen in the bootup but not available in the bios as hard disk.

When I reboot the machine, before it scans to list the disks available, this message appears

** This version supports only Hard Disk and CDROM drives **

I am stumped. I will try next to setup the key to look like a CD ROM, using a cdrom bootloader

Rufus worked for one of the flash drives I have been working on.

 

I created a syslinux 6.03 bootable flash with it, making sure I ticked compatibility with old motherboards.

Then I copied all the unraid files off the old flash, and we have liftoff.

 

Very kindly limetech support is helping me out with another key.

 

Let's hope 4GB will last me as long as the old flash did!

 

/saga over

 

Sent from my SM-A520F using Tapatalk