It's not clear precisely what your symptoms are. If I'm reading correctly, you were initially unable to boot either OS, but after running a boot repair utility, you're now able to boot, but not log in, to at least one OS. Which OS(es) are bootable is unclear to me. I'm guessing you can boot but not log into Linux and are unable to boot Windows. I have some observations:
- Windows 8 includes a "fast boot" feature that involves leaving disks in an unclean state on shutdown. This may work fine on a Windows-only computer, but on a dual-boot system, it's a problem waiting to happen. I recommend you disable it by typing
powercfg /h off in a Windows Administrator command prompt. With any luck that action will clean up the errors associated with /dev/sda5 in your Boot Info Script output.
- Your disk (
/dev/sda; it looks like /dev/sdb is a USB flash drive) is set up with a GUID Partition Table (GPT), and if Windows ever booted from this disk that means that Windows was booting in EFI mode.
- Your disk (again,
/dev/sda) has GRUB BIOS-mode boot code in the MBR. If your computer is booting in EFI mode, this is unnecessary at best. On some systems, it can cause boot problems because some EFI implementations look at the MBR and decide which boot mode to use based on the presence or absence of BIOS boot code in the MBR. That said, if you're successfully booting Ubuntu in EFI mode, you should probably leave this alone.
- Your
grub.cfg file lacks an entry for Windows, but you've got two such entries in /etc/grub.d/25_custom. You might be able to incorporate them into your GRUB menu by typing sudo grub-mkconfig -o /boot/grub/grub.cfg. Alternatively, you could try another boot manager, such as rEFInd or gummiboot. In fact, these can both boot Linux kernels directly, bypassing GRUB, but you'll need to do some extra configuration to get this to work. For rEFInd, once it's set up you won't need to do any more changes in the future; but for gummiboot, you'll need to edit your boot configuration manually whenever you update your kernel.
As LovinBuntu says, a boot repair utility shouldn't have touched your password. If you're desperate enough, you can boot with an emergency disc and edit /etc/shadow on your main installation directly with a text editor. Back up the original file before proceeding, in case you make a mistake. The second colon-delimited field (right after username:, where username is your username) holds the password. It's hashed, so it will be unintelligible and quite long. Delete the password only (up to the next colon on that line) and when you reboot your account will have no password. Log in and change it immediately. Of course, it's best to check the simple obvious-in-hindsight possibilities like the stuck Caps Lock key that LovinBuntu suggested first!
