Hi everyone, this is my first post here. I couldn't find an answer to this issue.
I have a DELL inspiron n5110 which came with windows 7, after some years I changed my hdd to an ssd and installed Ubuntu Studio instead, it was nice, very efficient, and very fast. But I wanted to try something different.

I completely wiped my SSD, I used parted magic and erased everything. I partitioned my 120 GB SSD to install windows and debian. 70 GB to windows, 50 to debian. I installed windows 8.1 first, and it made another boot partition of 350 MB, but it was a primary partition. So it then left me with only two primary partitions left to install debian. I made one of 4gb for swap and the rest for root.

The problem I have is that my laptop now takes a very long time to POST, It takes like a minute to load GRUB. This shoudn't happen on an SSD. I think this may be because of the partitions, maybe I have to make a /boot partition? I read that it was not necessary, and since I was a noob when I had ubuntu studio I don't remember how I had my SSD partitioned.

I don't mind completely wiping everything and making new partitions (my windows key should still work if I reinstall right?), I only care for it to boot fast. If I have to, I would keep debian instead of windows, but I prefer to dual boot. Thanks in advance.
(sorry for long post, I wanted to be very specific)

I don't know whether this has any bearing on your situation--I've not heard of that particular issue before--but you can install Linux quite nicely to an extended partition. Windows cares; Linux doesn't.

1 members found this post helpful.

So I can make a primary partition of 500 mb and make it /boot? and the other an extended partition with swap and root?
When I only had windows it was okay, when I had only ubuntu studio it was also okay, it is only by dual booting that my computer takes so long to post.

I've only dual-booted two computers, but in neither one did the dual-boot affect POST, as the boot loader loads after POST is completed.

When I installed Mint to my Win7 box (it's now running Mageia and Win7), Windows was already using four primary partitions, just because it could. I shrunk the biggest one, created extended partitions (one for the OS and one for swap), and installed Mint to them. It had no effect on POST, but one person's experience is hardly a representative sample.

As establishing dual-boot is the one thing that had changed when this problem began, your conclusion that the POST problem is somehow related to it makes sense. I just wish I have some idea as to what the cause may be, but I don't.

In a last desperate flail, I shall ask, have you entered the BIOS and checked the settings to make sure they are okay?

1 members found this post helpful.

The only setting for boot that I can change in the BIOS is AHCI/ATA but if I select ATA it won't even boot. One thing I should mention is that when I restart my laptop it POST time is super fast. It is only when I completly turn it off that it takes ages to POST.

There is no fast boot setting, boot devices setting, order of boot devices setting etc...?
Is it EFI bios?

1 members found this post helpful.

Partitions misaligned perhaps?

1 members found this post helpful.

I have not previously heard the term, "partitions misaligned" so I did a little searching.

This link looks useful: https://www.partition-magic-server.c...alignment.html

1 members found this post helpful.

Partition alignment is an issue in particular with larger drives, while they have 4096 sector size they lie to the OS the sector is 512 - to keep Windows users happy. New partitioning tools like gdisk align partitions correctly, older fdisk versions may require user intervention to get it right.

1 members found this post helpful.

Partition misalignment should have negligible effect on read operations. It's write operations that are impacted severely.

I had something similar happen after a kernel update. I would get the GRUB prompt right away, but loading the kernel and initrd seemed to take forever. The expected prompt for the root filesystem encryption key took a substantial fraction of a minute rather than appearing almost immediately after the kernel started running. On a hunch (and pretty much shooting blind), I saved away the contents of the /boot partition, re-created the filesystem, and restored the files. Problem solved!

My theory was that a badly fragmented file might be forcing the boot loader to do a lot of tiny reads, and that without the optimizations of a running kernel that process could be slow. I don't know whether that's true, but reorganizing the filesystem fixed the problem. The only other cause I could think of would be a bad spot on the disk that was causing the drive to do a lengthy error recovery, but reading from the partition once the kernel was running encountered no such delay.

1 members found this post helpful.

well yes, of course you can change the priority of devices, no fast boot option, and the bios is "normal"(is it called legacy?) , not uefi.

Is internal HD the first in the list in boot devices setting?

1 members found this post helpful.

I just checked, the first priority was USB, I changed the hardrive to the first optino , but still takes the same time.

When you say it's super fast to restart vs shutdown and power on, you mean with Windows OS, Linux or both?