Grub loading slowly with SSD

Question

Since yesterday, I added a brand new SSD in my PC, and I am experiencing a very fast boot from grub menu. The problem is before arriving to this menu, I must wait for a long time (~30s in most cases). I installed grub on the SSD. After the BIOS, I sometimes see "Grub loading" immediately, sometimes just a blinking cursor, but the time to reach the menu seems to be the same. I tried adding debug=disk (and even debug=all to my grub.cfg), but logs appear only after the unexplained period of time waiting ends.

I have 3 disks: - sda, marked as bootable with a windows boot loader on it - sdb, which is the SSD - sdc, which holds the swap partition and a data partition. It had my previous installation of Fedora 18 until yesterday

parted description:

Model: ATA ST3250410AS (scsi)
Disk /dev/sda: 250GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End    Size   Type     File system  Flags
 1      32.3kB  250GB  250GB  primary  ntfs         boot


Model: ATA M4-CT128M4SSD2 (scsi)
Disk /dev/sdb: 128GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  1075MB  1074MB  primary  ext4         boot
 2      1075MB  11.8GB  10.7GB  primary  ext4
 3      11.8GB  33.7GB  21.9GB  primary  ext4


Model: ATA ST3160827AS (scsi)
Disk /dev/sdc: 160GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system     Flags
 1      1049kB  2149MB  2147MB  primary  linux-swap(v1)
 2      52.4GB  160GB   107GB   primary  fat32           lba

When going under Windows (on sda1), I also have unexplained hanging times when shutting down, but this has occurred first one year ago.

EDIT Unplugging the 250GB drive makes the latency go away. The HDD LED does not blink during the waiting time.

What is going on?

Answer 1

Try to plug the SSD in the first SATA port and select it as the first boot device in BIOS. Otherwise it's usually a matter of fiddling with the drives and making sure GRUB configuration matches the actual drives numbering, i.e. hd0 designates HD0 in BIOS etc.

Answer 2

I'm pretty sure I know the root cause and a fix to this one, as I have the same on one of my laptops, however I haven't found a decent long term fix.

Please check the /boot/grub2 folder where the grub.cfg resides. If I'm right, the grub.cfg has a really huge file size. For info, a normal grub.cfg is about 10k (on a real heavy multi boot this could be up to 50k) but file sizes of megabytes or above are definitely a sign of corruption.

The root cause is this: after an install or a major upgrade, the last step is a run of grub2-mkconfig, which regenerates the grub.cfg file. This is a serious process that scans all disks etc, so it takes some time. After the writing of this file, the system almost always does a straight reboot, so that all your changes get activated. What happens with SSD disks is that the disk gets a hard reset due to the reboot, whilst the written data to the grub.cfg has not yet been safely commited to its NAND cells. In most cases, the data is there, but the file close (which sets the file length etc.) has not occured, and that results in huge empty space (or old disk data) that follows the normal grub.cfg file.

The effect of this action is then at follows: grub2 reads the grub.cfg file, but after the normal data (which is the list of available boot systems) it takes some time (up to 30 seconds) to just parse through the dummy data (often 0x00 bytes or similar), sometimes issuing errors. But in the end, it finds the end of the file, and gives you the correct list of OS'es found.

Fix: Make sure all disks are available, and run a manual grub2-mkconfig with output to the grub.cfg file. Alternatively, use a hex editor to find the real end of the data and then use a copy tool to copy exactly the right number of bytes to a new file, and then replace the faulty grub.cfg with the good one.

But there should be a more permanent fix, as with each system upgrade the same problem may pop up. It means that the system shutdown should ensure that ALL SSD disks have commited all data persistently.