Ubuntu – Please do not forget to make your BIOS boot on sda6/EFI/ubuntu/shimx64.efi file!

Secure Boot is usually OK, but can sometimes cause problems, so it's best to disable it during troubleshooting. Ideally, it will provide some added protection against pre-boot malware (which usually targets Windows but can theoretically affect any OS), so it's worth having -- IF it doesn't cause any other problems. It's possible that Secure Boot is causing your problems, but I suspect a defective firmware.

Your Boot Repair output indicates that Ubuntu should be booting; however, some EFIs have known problems that prevent the system from booting anything but the Windows boot loader (or a program with the same name as the Windows boot loader). There are a number of ways you can overcome this problem:

• Look for an updated firmware from your computer's manufacturer. (They'll probably call it a "BIOS update" or words to that effect, although it's technically not a BIOS.) After doing this, you may need to re-install a boot manager (see below).
• Using Boot Repair, click the Advanced item and select the option to back up and replace the Windows boot loader. (I don't recall the precise phrasing of this option.) Once this is done, GRUB should theoretically come up.
• Download the CD-R or USB flash drive image of my rEFInd boot manager and prepare an image with it. If that image starts, it should boot Ubuntu just fine. If that works, you can either continue booting with rEFInd on the external medium or install the Debian package in Ubuntu. If that works as-is, then great. If rEFInd also fails to start from hard disk, then you can boot to Ubuntu using the USB drive or CD-R, open a Terminal window, and type mvrefind.sh /boot/efi/EFI/refind /boot/efi/EFI/BOOT. (Note the doubling-up of efi, once in lowercase and once in uppercase.) This mvrefind.sh command essentially does what the Boot Repair option to replace the Windows boot loader does, but with rEFInd rather than GRUB.
• Since the computer is new, return it to the store and buy another model. Make it clear (in a letter to Toshiba, if nothing else) why you're returning it. Manufacturers have had more than enough time to fix these problems in their firmware, and yet they keep delivering garbage. They do this because few people complained about the garbage in the first couple generations of EFI firmware, and they'll continue delivering it for years more if people keep accepting it.
• Enter the firmware setup utility and find whatever options exist to control the boot mode. Set the computer to boot in BIOS/CSM/legacy mode and to disable (if possible) EFI/UEFI mode. You can then re-install Ubuntu in BIOS mode, which should set up a BIOS-mode version of GRUB; or run Boot Repair in BIOS mode to do the same without actually re-installing anything.

Some key things I've noticed about your output:

• You have two EFI System Partitions (ESPs), /dev/sda1 and /dev/sdb1. This is legal, but makes it harder to troubleshoot the computer.
• Your /dev/sda1 ESP seems to be empty -- or at least, Boot Info Script has not identified any boot files on it. This could be a bug in Boot Info Script (it misses things sometimes), or it could be it was accidentally wiped, has filesystem damage, etc.
• Your /dev/sdb1 seems to have files that normally reside on a Linux root (/) filesystem and seems to be missing the usual ESP files. This makes me think you accidentally copied those files or something went badly wrong when specifying mount points in the installation process.
• Your main Ubuntu installation seems to be on /dev/sdb2. This is fine; I'm just pointing it out in case you believed it was somewhere else.
• Some of your GRUB entries seem to point to an installation on /dev/sda2, but there's no evidence of an Ubuntu installation at that location.

The Failed to... messages you report are from Shim, which is Ubuntu's way of dealing with Secure Boot. They indicate failures to launch various follow-on programs. In your case, they probably indicate a badly broken GRUB installation.

Overall, it's not clear to me how your system got into its current state. At a minimum, its GRUB installation is badly messed up. At worst, critical system files may be mis-placed or missing, which could be very difficult to track down and repair.

I recommend the following actions for repair:

1. If you have any critical user files on the computer, back them up.
2. Delete all the partitions on both disks.
3. Use GParted, parted, gdisk, or some other tool to create new partitions.
   • If you use parted, gdisk, or something else that does not create filesystems, create new filesystems, too. (If you happen to create a new partition with the same start point as the old one, the old filesystem will re-appear, and you do not want that to happen, hence the instruction to create fresh filesystems.)
   • Create one ESP on one disk (probably /dev/sda).
   • There are many ways to use two disks -- you can set up separate partitions for filesystems like /home or /var, use LVM, etc. Decide ahead of time what to do and set it up appropriately.
4. Re-install Ubuntu on the freshly-partitioned disks. If you used another program to create partitions, you should use the "Something Else" installation/partitioning option and manually specify mount points. See here for the basics of how to use the "Something Else" option. (Note that if you install the server version of Ubuntu, the installer is different, so these details will be different, too.)
5. If necessary, restore the user data you backed up at the start.

The point of this procedure is to eliminate all the peculiarities with your current setup. It's unclear to me how some of these peculiarities came to be, and they could be signs of even more fundamental problems. Thus, tracking down the true cause(s) and repairing what you've got could be quite time-consuming. Because you mentioned that you've done a fresh install, chances are you won't be throwing away a lot of customizations by doing another re-install, so that's almost certain to be the quicker and easier course of action.