thomas.raines wrote:I recently installed Mint 16 on my Acer Aspire 5560 laptop. Before, I was running Mint 15 with no problems, and did an upgrade to Mint 16. I was having some issues, so I decided to do a fresh install. Now, when I try to boot my system, I get a blank screen and the hard drive stops spinning. I hold the power button to shut it down, then press it again to boot. The grub menu appears, and I select Mint 16, and it boots fine.
Paraphrasing, to be sure I understand: You try to boot and it fails with a blank screen. (What appears before
this failure -- do you see a firmware POST display, a GRUB menu, etc.?) You power off and power back up, which results in a GRUB menu followed by a successful boot. If I'm misunderstanding, please clarify.
Those symptoms are rather peculiar. I would expect a cold boot to work identically no matter what; however, one possibility does occur to me: GRUB can be configured to track successful vs. failed boots, and to boot differently when it's launched after a failed boot. Thus, you may be seeing something where the default GRUB configuration is failing, so it only works when GRUB detects that fact and boots in a fallback configuration. I'm only passingly familiar with this GRUB feature, though, and I don't know how Mint sets it up, so I can't offer much more guidance on this. It might be something you could investigate, though. There's a chance that Boot Repair
would fix this -- but there's also a chance that it would make it worse (say, by disabling the boot-after-failure pathway that's now your only way to boot).
A little background, my computer natively came with Windows 7, but when Windows 8 was released, Acer made a "hasty" UEFI BIOS to make the laptop compatable. I say hasty because there is NO way to boot into teh UEFI or control/change any settings of any type related to EFI. It is the same BIOS as before the update. Now I have no way of turning off/on the secure boot or anything else.
Windows 8 will work fine on a computer with a traditional BIOS. It's conceivable that Acer released an updated EFI firmware to add Secure Boot support or for some other reason, but it's unlikely that such an update was required for Windows 8 compatibility.
Computers that ship with Windows 8 and that have a Windows 8 sticker are required (by contract with Microsoft) to provide a way to disable Secure Boot. This requirement probably doesn't apply to a firmware update for a computer that shipped with Windows 7, so it's conceivable that such a computer will boot only in Secure Boot mode; however, if you don't see any Secure Boot options, I'd say it's more likely that it doesn't support Secure Boot at all, since a Secure-Boot-only policy would also prevent the computer from booting Windows 7. You could test this by trying to boot a CD-R or USB flash drive version of my rEFInd boot manager.
The CD-R and USB flash drive images I provide don't support Secure Boot, so if they boot, your computer is set to boot without Secure Boot (or it doesn't support Secure Boot at all). If the computer refuses to boot my rEFInd media, then it might
be set with Secure Boot active (or there could be some other explanation for a failure).
I'd really like to use Mint 16. But I think, in order to make it work, I need to remove the efi partition and make my main partition the boot partition. But I have no idea of how to accomplish this.
As others have said, do not
delete your EFI System Partition (ESP)! Your computer relies on that partition to boot, so removing it will remove your only boot path, and you'll need to fix that in one way or another. It is possible to convert to a BIOS/CSM/legacy boot path, but there are moderately common firmware bugs that can crop up with such a conversion, so this approach isn't really likely to be any easier than sticking with EFI and getting it working better than it is now.
I recommend you read my page on Linux EFI-mode installations
for important background information and advice on avoiding certain common pitfalls. It sounds like you've run into an un
common pitfall, though, so my page will be more helpful for the background information, which should give you a better mental model with which to approach the problem.
Beyond that, try reading up on EFI boot loader options for Linux.
It's possible that you'll have better luck with another boot loader. The aforementioned rEFInd is likely to be relatively easy to try. Chances are you'll be able to test it from a CD-R or USB flash drive without installing it to your hard disk or adjusting the default configuration, so it's fairly safe to test. ELILO and Fedora's patched GRUB Legacy might also be worth trying. Keep in mind, though, that if my hypothesis about a failing default boot path and a successful fallback boot path is correct, the issue is likely to be one of bad options being passed to the kernel by GRUB (or alternatively, a lack of necessary options being passed by GRUB). The same bad (or good) options can be passed to the kernel by any other boot loader, so the key with any
boot loader would be to identify which boot option(s) is/are causing the boot failure.
One more comment: Your fdisk output indicates that your /dev/sda uses GPT but your /dev/sdb uses MBR. This is perfectly legal in both EFI and Linux; however, many manufacturers have released extremely buggy EFIs, and it's conceivable that your EFI is flaking out and causing boot problems because of the MBR hard disk. If so, converting the disk from MBR to GPT will fix the problem. You can do such a conversion with my GPT fdisk (gdisk),
which is part of the "gdisk" package in Mint. See the gdisk documentation
for details. This possibility strikes me as a long shot, though; it seems more likely that the problem is caused by a bad kernel option. Still, it might be worth investigating, particularly if you can launch rEFInd or some other EFI boot loader but have problems booting from that software. The trouble is that testing this hypothesis will require an MBR-to-GPT conversion. Such a conversion is theoretically easy, but there's always the chance of creating a disastrous problem when doing such a conversion. Thus, I'd hold off on doing it and keep this approach in mind in case others don't pan out.