Grub loading slowly with SSD

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
2
down vote

favorite












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?










share|improve this question























  • I edited my question. I replugged the sda drive on another SATA port, with the same results. I checked BIOS settings, did not see anything dubious... I don't have Intel Management Engine (I have an ASUS P5Q) motherboard.
    – greg0ire
    Mar 10 '13 at 2:46










  • I didn't try swapping the drives, not sure what you meant by that... swapping the SATA cables plug locations? Or modifying my grub configuration?
    – greg0ire
    Mar 10 '13 at 13:13










  • Ok, I'll try that (I think I might already have tried it by repluggining the drive in a different location). And yes unplugging the 250GB drive fixes the problem. It has a boot flag, is this really needed?
    – greg0ire
    Mar 10 '13 at 13:29











  • Tried booting with only SSD + HD160GB: same result. Tried swapping SDD and HD250GB, grub tells me "no such partition". I then think the old HD160GB still has a grub that points to nothing. I look in the BIOS, and it was not booting on the SSD anymore. Changed that back and... problem solved! Can you explain this mystery in an answer? I'll accept it and upvote you.
    – greg0ire
    Mar 10 '13 at 14:46










  • let us continue this discussion in chat
    – don_crissti
    Mar 10 '13 at 15:39














up vote
2
down vote

favorite












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?










share|improve this question























  • I edited my question. I replugged the sda drive on another SATA port, with the same results. I checked BIOS settings, did not see anything dubious... I don't have Intel Management Engine (I have an ASUS P5Q) motherboard.
    – greg0ire
    Mar 10 '13 at 2:46










  • I didn't try swapping the drives, not sure what you meant by that... swapping the SATA cables plug locations? Or modifying my grub configuration?
    – greg0ire
    Mar 10 '13 at 13:13










  • Ok, I'll try that (I think I might already have tried it by repluggining the drive in a different location). And yes unplugging the 250GB drive fixes the problem. It has a boot flag, is this really needed?
    – greg0ire
    Mar 10 '13 at 13:29











  • Tried booting with only SSD + HD160GB: same result. Tried swapping SDD and HD250GB, grub tells me "no such partition". I then think the old HD160GB still has a grub that points to nothing. I look in the BIOS, and it was not booting on the SSD anymore. Changed that back and... problem solved! Can you explain this mystery in an answer? I'll accept it and upvote you.
    – greg0ire
    Mar 10 '13 at 14:46










  • let us continue this discussion in chat
    – don_crissti
    Mar 10 '13 at 15:39












up vote
2
down vote

favorite









up vote
2
down vote

favorite











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?










share|improve this 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?







grub ssd






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Mar 10 '13 at 2:43

























asked Mar 9 '13 at 14:21









greg0ire

1,23621332




1,23621332











  • I edited my question. I replugged the sda drive on another SATA port, with the same results. I checked BIOS settings, did not see anything dubious... I don't have Intel Management Engine (I have an ASUS P5Q) motherboard.
    – greg0ire
    Mar 10 '13 at 2:46










  • I didn't try swapping the drives, not sure what you meant by that... swapping the SATA cables plug locations? Or modifying my grub configuration?
    – greg0ire
    Mar 10 '13 at 13:13










  • Ok, I'll try that (I think I might already have tried it by repluggining the drive in a different location). And yes unplugging the 250GB drive fixes the problem. It has a boot flag, is this really needed?
    – greg0ire
    Mar 10 '13 at 13:29











  • Tried booting with only SSD + HD160GB: same result. Tried swapping SDD and HD250GB, grub tells me "no such partition". I then think the old HD160GB still has a grub that points to nothing. I look in the BIOS, and it was not booting on the SSD anymore. Changed that back and... problem solved! Can you explain this mystery in an answer? I'll accept it and upvote you.
    – greg0ire
    Mar 10 '13 at 14:46










  • let us continue this discussion in chat
    – don_crissti
    Mar 10 '13 at 15:39
















  • I edited my question. I replugged the sda drive on another SATA port, with the same results. I checked BIOS settings, did not see anything dubious... I don't have Intel Management Engine (I have an ASUS P5Q) motherboard.
    – greg0ire
    Mar 10 '13 at 2:46










  • I didn't try swapping the drives, not sure what you meant by that... swapping the SATA cables plug locations? Or modifying my grub configuration?
    – greg0ire
    Mar 10 '13 at 13:13










  • Ok, I'll try that (I think I might already have tried it by repluggining the drive in a different location). And yes unplugging the 250GB drive fixes the problem. It has a boot flag, is this really needed?
    – greg0ire
    Mar 10 '13 at 13:29











  • Tried booting with only SSD + HD160GB: same result. Tried swapping SDD and HD250GB, grub tells me "no such partition". I then think the old HD160GB still has a grub that points to nothing. I look in the BIOS, and it was not booting on the SSD anymore. Changed that back and... problem solved! Can you explain this mystery in an answer? I'll accept it and upvote you.
    – greg0ire
    Mar 10 '13 at 14:46










  • let us continue this discussion in chat
    – don_crissti
    Mar 10 '13 at 15:39















I edited my question. I replugged the sda drive on another SATA port, with the same results. I checked BIOS settings, did not see anything dubious... I don't have Intel Management Engine (I have an ASUS P5Q) motherboard.
– greg0ire
Mar 10 '13 at 2:46




I edited my question. I replugged the sda drive on another SATA port, with the same results. I checked BIOS settings, did not see anything dubious... I don't have Intel Management Engine (I have an ASUS P5Q) motherboard.
– greg0ire
Mar 10 '13 at 2:46












I didn't try swapping the drives, not sure what you meant by that... swapping the SATA cables plug locations? Or modifying my grub configuration?
– greg0ire
Mar 10 '13 at 13:13




I didn't try swapping the drives, not sure what you meant by that... swapping the SATA cables plug locations? Or modifying my grub configuration?
– greg0ire
Mar 10 '13 at 13:13












Ok, I'll try that (I think I might already have tried it by repluggining the drive in a different location). And yes unplugging the 250GB drive fixes the problem. It has a boot flag, is this really needed?
– greg0ire
Mar 10 '13 at 13:29





Ok, I'll try that (I think I might already have tried it by repluggining the drive in a different location). And yes unplugging the 250GB drive fixes the problem. It has a boot flag, is this really needed?
– greg0ire
Mar 10 '13 at 13:29













Tried booting with only SSD + HD160GB: same result. Tried swapping SDD and HD250GB, grub tells me "no such partition". I then think the old HD160GB still has a grub that points to nothing. I look in the BIOS, and it was not booting on the SSD anymore. Changed that back and... problem solved! Can you explain this mystery in an answer? I'll accept it and upvote you.
– greg0ire
Mar 10 '13 at 14:46




Tried booting with only SSD + HD160GB: same result. Tried swapping SDD and HD250GB, grub tells me "no such partition". I then think the old HD160GB still has a grub that points to nothing. I look in the BIOS, and it was not booting on the SSD anymore. Changed that back and... problem solved! Can you explain this mystery in an answer? I'll accept it and upvote you.
– greg0ire
Mar 10 '13 at 14:46












let us continue this discussion in chat
– don_crissti
Mar 10 '13 at 15:39




let us continue this discussion in chat
– don_crissti
Mar 10 '13 at 15:39










2 Answers
2






active

oldest

votes

















up vote
2
down vote



accepted










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.






share|improve this answer





























    up vote
    1
    down vote













    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.






    share|improve this answer




















    • Hey you're very nice, but I fixed this 5 years and no longer have this machine. See above. Your answer might help somebody else though, so have my upvote.
      – greg0ire
      Dec 7 at 10:30










    Your Answer








    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "106"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader:
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    ,
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );













    draft saved

    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f67403%2fgrub-loading-slowly-with-ssd%23new-answer', 'question_page');

    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    2
    down vote



    accepted










    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.






    share|improve this answer


























      up vote
      2
      down vote



      accepted










      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.






      share|improve this answer
























        up vote
        2
        down vote



        accepted







        up vote
        2
        down vote



        accepted






        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.






        share|improve this answer














        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.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        answered Mar 10 '13 at 15:58


























        community wiki





        don_crissti























            up vote
            1
            down vote













            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.






            share|improve this answer




















            • Hey you're very nice, but I fixed this 5 years and no longer have this machine. See above. Your answer might help somebody else though, so have my upvote.
              – greg0ire
              Dec 7 at 10:30














            up vote
            1
            down vote













            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.






            share|improve this answer




















            • Hey you're very nice, but I fixed this 5 years and no longer have this machine. See above. Your answer might help somebody else though, so have my upvote.
              – greg0ire
              Dec 7 at 10:30












            up vote
            1
            down vote










            up vote
            1
            down vote









            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.






            share|improve this answer












            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.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Dec 6 at 13:40









            Xavier Van Dessel

            111




            111











            • Hey you're very nice, but I fixed this 5 years and no longer have this machine. See above. Your answer might help somebody else though, so have my upvote.
              – greg0ire
              Dec 7 at 10:30
















            • Hey you're very nice, but I fixed this 5 years and no longer have this machine. See above. Your answer might help somebody else though, so have my upvote.
              – greg0ire
              Dec 7 at 10:30















            Hey you're very nice, but I fixed this 5 years and no longer have this machine. See above. Your answer might help somebody else though, so have my upvote.
            – greg0ire
            Dec 7 at 10:30




            Hey you're very nice, but I fixed this 5 years and no longer have this machine. See above. Your answer might help somebody else though, so have my upvote.
            – greg0ire
            Dec 7 at 10:30

















            draft saved

            draft discarded
















































            Thanks for contributing an answer to Unix & Linux Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid


            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.

            To learn more, see our tips on writing great answers.





            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


            Please pay close attention to the following guidance:


            • Please be sure to answer the question. Provide details and share your research!

            But avoid


            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.

            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f67403%2fgrub-loading-slowly-with-ssd%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown






            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Displaying single band from multi-band raster using QGIS

            How many registers does an x86_64 CPU actually have?