Current grub-pc takes several minutes to show menu

[Dean Loros]

With the latest grub-pc update, grub2 takes several minutes to get to the menu. During this time there is almost constant hard drive activity...this did not happen with the last update which would take 5 to 10 seconds at the most. This is with a i7-920/SATA2 system.

Please advise as to further information needed.

lsb_release -rd
Description: Ubuntu karmic (development branch)
Release: 9.10

apt-cache policy grub-pc
grub-pc:
  Installed: 1.96+20090826-3ubuntu3
  Candidate: 1.96+20090826-3ubuntu3
  Version table:
 *** 1.96+20090826-3ubuntu3 0
        500 http://archive.ubuntu.com karmic/main Packages
        100 /var/lib/dpkg/status

[jocko (jomnal00)]

The same problem here too, but no where near minutes.
The "[minimal BASH-like..." message, which before the last grub-pc update would only flash by in half a second, now stays up for eleven seconds with constant noises from the hard drive. After the boot menu comes up everything appears to work normally (or perhaps there is a very slight delay for the actual boot to start after I hit enter, but that may just be in my imagination).

This is on an old nforce2 system (gigabyte GA-7nnxp) with a SiI 3112 SATA controller.

[jocko (jomnal00)]

Oh... And my lsb_release and apt-cache info is identical to Dean's in the report...

[dino99 (9d9)]

Same comments as Jocko

[dino99 (9d9)]

Architecture: i386
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: nvidia
Package: grub-pc 1.96+20090826-3ubuntu3
PackageArchitecture: i386
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=fr_FR.UTF-8
ProcVersionSignature: Ubuntu 2.6.31-8.28-generic
Uname: Linux 2.6.31-8-generic i686
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

[Colin Watson (cjwatson)]

I'm not sure if this will help, but could you please put "set debug=all" (without the quotes, of course) at the top of /boot/grub/grub.cfg, reboot, and say whether there's anything interesting on the screen? If there is, perhaps a photo of the screen would be useful.

[Dean Loros (autocrosser)]

Useful--Yes I took 5 screenshots. First--My tower has 4 drives inside--total of 1.5TB & I have 2 testing installs + a stable 9.04 & a 64bit 9.04. Grub first goes thru all the UUID info & then checks all 4 drives for filesystem type several times--first time through is a very quick look & then it seems to change to a "high-resolution mode" & repeats this several more times--I left my system grinding away for 20 minutes with iterations of the last 2 screenshots & then forced a reboot & had to use a LiveCD to "fix" grub.cfg so I could have my "normal" 4~5 minute wait for grub to let me in. I'm compressing the files--there are 5 shots in the folder.

[Dean Loros (autocrosser)]

Just installed the new 1,97 beta1 & am still having the same problem--It is possible that it took a "slightly" shorter time to menu as I did not time it, but it still takes several minutes for the menu to appear with a large amount of drive thrash in the process.

[dino99 (9d9)]

Same issue too with 1,97:
first, appear on screen "minimal bash-like line ..." comments
        i suppose that grub "search" uuids but make hdd noisy

second, 1,97 release is on karmic but Jaunty still have 1,96 : may be not a good thing as each of my distro own his grub

The good thing: except that long time & noisy hdd, karmic boot without error.

The bad things:
  - i always need to unplug to make grub able to run
  - when i shutdown my system, it work, but if i ask to reboot, system is closed but not stopped and finally never reboot: again need to unplug.

[Colin Watson (cjwatson)]

I noticed that after an initial installation of Karmic in kvm, the first (warm) reboot spends ages scanning the CD, but subsequent reboots are fine. This is a bit perplexing.

It might be worth putting 'set debug=disk' at the top of /boot/grub/grub.cfg to see what disk it's looking at. The 'set debug=all' that Dean already tried is not without use, but it all scrolls past so quickly that it's hard to see what's going on.

[Dean Loros (autocrosser)]

I wish that it was a one-time happening for me--I am really not wanting to reboot due to this issue..the last time I ran debug I needed to remove one video card (separate problem doing with SLI & LiveCD's) & fiddle for over an hour to edit a line back out to get back to "normal"--If LiveCD's would config mutiple video cards it would be much easier....But that is my problem that I created for myself...in any case, I am going on holiday next week, so I will try a run as you outline between now & Tuesday next.

[dino99 (9d9)]

hi Colin,

how can i help you about this problem ? I can't find an explanation about that need of "unplug" to be able to boot & restart.
Tell me what script to run , thanks.

[jocko (jomnal00)]

I found a similar bug report in debian's bug tracker. Apparently the person who reported the bug managed to fix it by reverting to an older version and then upgrading grub-pc again...
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541145

[jocko (jomnal00)]

And now I found a workaround that fixed it for me.

To start with I had set up my computer like this:
SATA connector 1 --> 250Gb hard drive (sda) with grub 2 in the mbr, Gutsy installed on the first partition (sda1).
SATA connector 2 --> 1Tb hard drive (sdb), Karmic on the first partition (sdb1).
This setup had the delay (only 11s for me) before the boot menu loaded. When I added "set debug=all" to grub.cfg I got the same as in Dean's screenshots, and I never get the menu to load (gave up after an hour or so).

My workaround:
1. Installed grub 2 to the mbr 1Tb hard drive from within Karmic:
          sudo grub-install /dev/sdb
2. Switched the SATA cables around.
          connected the 1Tb drive to SATA connector 1. This is the only way I can change which SATA drive to boot from.
3. Now when I booted, I got the grub 2 boot menu to load without delay directly after the bios summary screen.
(4. To fix gutsy boot, which was broken by the switch, I simply had to run sudo update-grub from within karmic.)

Can't say that I know what caused the delay, but either grub 2 doesn't like my old 250 Gb drive or there's a problem with having grub 2 on the mbr on one drive when the boot folder is on another drive...

[jocko (jomnal00)]

Hmm... Just noticed that there must have been a grub-pc update today (to 1.97~beta1-1ubuntu4). I ran sudo apt-get update && sudo apt-get upgrade both before and during my experimenting and got a few updates, but I didn't notice when the grub update came, so maybe my "fix" was just that I installed the update...

[John Yates (andyfranyates)]

I can confirm that jocko's workaround fixes the problem for me. Something with grub on one drive and boot folder on another.

[Dean Loros (autocrosser)]

OK--I did not do the workaround & did do the update to grub.....I can confirm that the time to grub menu went down by about 50%--in other words, from 4~5 minutes to about 2~3 minutes, so the update "improved" the respond time at least a bit....still not very good, but better than it was.

[Dean Loros (autocrosser)]

I can also state that my Grub is on SDA & the /boot is on SDC--so it looks like that is where the problem is.

[Dean Loros (autocrosser)]

Just updated grub again & timed the wait to menu--took 3 min 50 sec to get there--I'm back when I started earlier this last month--I still have grub install on sda & my /boot on sdc1--so grub is still having a hard time finding things.

[Koen Verweij (kfverweij)]

My grub2 had a short (compared to Dean's) delay varying from 6-10 seconds too. Not wanting to try jocko's workaround I changed the boot priority of my hard drives so it would boot the drive where grub2 is installed on first. Now there is no delay (or maybe 0.5 seconds or sth).
Now I'm not even sure why it loaded grub2 before I changed this, since it is not suppose to be installed on the other drives.

[Shinji (thorsten-reichelt)]

I have "grub 1.97~beta3-1ubuntu5" installed and the same problem.
It takes several minutes before the menu show up while there ist constant hard drive activity.

Grub is installed inside the MBR auf /dev/sda and my Kubuntu systems resides on /dev/sdc1.

/dev/sdc1 (EXT4) <== Kubuntu root partition
/dev/sdc2 (SWAP)
/dev/sdc5 (NTFS)
/dev/sdc6 (NTFS)

/dev/sda1 (NTFS) <== MBR with grub
/dev/sda5 (NTFS)
/dev/sda6 (NTFS)

/dev/sdb2 (NTFS)

[Dean Loros (autocrosser)]

Hi Colin--

I would guess that you have also read Vladimir's respond to my question on grub2 list--for others on this bug, his answer is as follows:

We have theoretically discussed this problem with Robert but weren't
sure if instances of it exist. The problem is that (UUID=..) syntax
rescans all drives on every access. We devised a solution to split
search.mod into search_uuid.mod, search_file.mod and so on but we agreed
that it will be done after 1.97 due to amount of changes it requires.
I'm ok to implement it, it's not much work but I can't make any promises
about my current disponibility.
As a workaround for time being you can use one or more of the following:
1) Increase cache size. Can this be done in 1.97?
Change include/grub/disk.h and replace
#define GRUB_DISK_CACHE_NUM 1021
with a bigger number
2) Modify scripts to hardcode boot device and not use UUID. If you
change disk order it will result in boot failure but it may be a local
workaround
3) add search -s -u <UUID> as first command of your grub.cfg

All the workarounds look equally viable--I do not want to hardcode my discs, so I will edit my grub.cfg with option #3 & test--I would recommend anyone else to pick a option, test & report with findings.

[Dean Loros (autocrosser)]

Further update: Option #3 only makes a 20sec change to my system, so we are talking on Grub2 dev list about a fix for this. More information as is available.

[Dean Loros (autocrosser)]

Hi Colin-- I do not know what is happening....The patched grub from your PPA "seems" to still look of UUID's & it would appear that Vladimir wants that removed. I have updated to the current Grub2, grub-common & grub-pc & am back to the 3min 50 sec time to menu. Any thoughts would be very interesting at this time....I am glad that I re-boot this unit only every couple of days.

[ubuntosaure (ubuntosaure)]

Hi,
On my dell mini9 I have only one partition as ext2 but brub is long.
It crashes more and open a root access!

[Dean Loros (autocrosser)]

Hi Cloin, have you had any time to think about this? I plan to resort my system this weekend & will be changing the boot order--I will see what impact this has on the bug.

[Dean Loros (autocrosser)]

Sorry Colin---early morning.....

[Dean Loros (autocrosser)]

I went ahead & totally changed my system last nite...Installed the beta release to the first partition on the first drive & so now grub2 is on the same as the MBR---result: Grub2 now takes 5sec to menu & boots at once to the selected kernel--I would say that this will be a big headache when 9.10 is released.....Anyone with a multi-boot/multi-disk system will have a varied problem with boot-to-menu times, my case most likely shows the extreme--Grub2 was on the 3rd drive/1st partition in a 1.5TB system.

[emarkay (mrk)]

Yea, "Disk Thrashing"...
http://ubuntuforums.org/showthread.php?t=1290221

[mikeXYZ (qmikeq)]

Me, too.

With both 1.97 beta3 and beta4. Dual boot/two drives. 70-second delay.

The "problem installation":
Dual booting two hard drives (on an Intel D915GAVL mobo).
GRUB 2 is installed to the MBR of sda, and sda is the first BIOS boot drive.
The Kubuntu 9.10 OS (where /boot/grub is) is on sdb2.
Delay between the end of POST and the appearance of the boot menu is 70 seconds.
During that time, lots of hard disk drive activity going on.

But no problems here:
-- No problem dual booting OSs using my Intel DG33FBC system and only ONE hard drive (and 1.97 beta3 & beta4).

Haven't had much time to look at this, still testing/playing with GRUB 2, but wanted to post an fyi. Annoying delay, especially since I don't have all my OSs included on a grub.cfg and I manually intervene to boot them (with "c" key then chainloader, etc.); or need to boot a non-default OS now and then.

[wraithmonk (geoffitton-deactivatedaccount)]

Grub 1.97 beta3, long delay on booting:

Description:-
Dual booting two Maxtor 80GB SATA drives.
GRUB 2 is installed to the MBR of sda, and sda is the second BIOS boot drive after CDRW drive.
(Making it the first BIOS boot drive makes no difference).
Kubuntu 9.04 64-bit is installed on dev/sda - sda1 /home ; sda5 swap ; sda6 root
Kubuntu 9.10 64-bit is installed on dev/sdb - sdb1 root ; sdb5 swap ; sdb6 /home

The delay between the end of POST & the boot menu appearing, is about 40 seconds.
The is a lot of hard disk activity going on during this time.

[TToft (ttoft)]

Same problem here with 1.97 beta4.

[TToft (ttoft)]

My guess is that a lot of Ubuntu users will run screaming away if this is not fixed before release. How come this is marked undecided importance? Since I'm just testing the RC I'll survive but for every day use this is more or less a show stopper. I hope GRUB-legacy is used in Karmic final if this isn't fixed so it wont hold users back from choosing Ubuntu.

[chrislecole (chrislecole)]

in addition: One other origin of this bug (long time with grub loading) may be that on Linux is installed on my rmovable SATA drive (where is the MBR) i had install 2 linux partitions one with the latest Debian testing (ext4) and the other with the beta issue of Karmic Koala (also ext4)...each of them install grub2 so this may be the origin of conflicts...

[aapgorilla (aapgorilla)]

I have the same problem, I have 2 drives one with 3 partitions (which also has mandriva which had previously installed it's own lagacy-grub) and one with 2

[chrislecole (chrislecole)]

For me the problem was resolved by changing the boot drive priority in the bios (from pata drive to sata drive)

[Regular User (dot.ru)]

A similar situation here but nowhere near minutes, a couple of seconds like 6.... and after that the boot process IS NOT faster than the previous iteration of ubuntu and it's kind of a mess IMHO (the first apple-like boot screen and then the windows-like one... is redundant and ugly).

[Alex (alexander-stehlik)]

I can confirm this problem for the official Karmic release that shipps with version 1.97~beta4-1ubuntu3.

Before the grub menu appears the harddisks are frequently accessed for about 30secs. After I selected a system to boot, it's the same. Harddisc access for 30secs.

My Harddisk constellation:

/dev/sda (on IDE Controller, 320GB)
/dev/sda1 (320GB, encrpted)

/dev/sdb (on SATA Controller, 80GB)
/dev/sdb1 (Windows, NTFS, 40GB)
/dev/sdb2 (/boot, ext4, 200MB)
/dev/sdb3 (/, LVM encrypted, ext4, 40GB)

/dev/sdc (on SATA Controller, 500GB)
/dev/sdc1 (Ubuntu 9.04, ext3, 50GB)
/dev/sdc2 (Data, ext3, 450 GB)

Can I provide more information that may help?

[xenesis (wagner-sim88)]

Confirming this bug for me too.

If I set debug=disk in grub.cfg I can see GRUB agressivly reading from the harddisk. It especially searches hd0, where Windows Vista lives.

I removed every search command in grub.cfg, still it is searching the HD, I think, thats because it is looking for the GRUB modules.

I had grub2 installed under Intrepid, that worked like a charm (but that was 1.96 not 1.97). Since the update I have this annoying problem.

fdisk -l output:
Platte /dev/sda: 160.0 GByte, 160041885696 Byte
255 Köpfe, 63 Sektoren/Spuren, 19457 Zylinder
Einheiten = Zylinder von 16065 × 512 = 8225280 Bytes
Disk identifier: 0x30000000

   Gerät boot. Anfang Ende Blöcke Id System
/dev/sda1 1 15 120456 de Dell Utility
/dev/sda2 16 1321 10485760 7 HPFS/NTFS
/dev/sda3 * 1321 19131 143060992 7 HPFS/NTFS
/dev/sda4 19131 19458 2621440 f W95 Erw. (LBA)
/dev/sda5 19131 19458 2620416 dd Unbekannt

Platte /dev/sdb: 160.0 GByte, 160041885696 Byte
255 Köpfe, 63 Sektoren/Spuren, 19457 Zylinder
Einheiten = Zylinder von 16065 × 512 = 8225280 Bytes
Disk identifier: 0xad5de7fd

   Gerät boot. Anfang Ende Blöcke Id System
/dev/sdb2 * 1 19457 156288321 5 Erweiterte
/dev/sdb5 1 498 4000122 82 Linux Swap / Solaris
/dev/sdb6 499 1020 4192933+ 83 Linux
/dev/sdb7 1021 16686 125837110+ 83 Linux
/dev/sdb8 16687 19457 22258026 83 Linux

Please make this bug critical.

[Jayson (jayson)]

I can't understand how the status of this bug has been changed to "Fix Released". When I did a search on packages.ubuntu.com, the fix (1.98~20100101-1ubuntu1) has only been released to Lucid! Who here is using Lucid on a production machine?

When will a fix be released for Ubuntu 9.10 Karmic Koala?

[ahmad (aanbar)]

How much it will take for the fix to be pushed through Ubuntu 9.10 updates?

the package inside 'Lucid' is dummy so I cannot install it manually too.

[John Vivirito (gnomefreak)]

On 01/13/10 08:41, ahmad wrote:
> How much it will take for the fix to be pushed through Ubuntu 9.10
> updates?
>
> the package inside 'Lucid' is dummy so I cannot install it manually too.
>
from what i can tell grub-pc in Lucid is not a dummy package
at least show and search do not show it as a dummy package

--
Sincerely Yours,
    John Vivirito

https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246

"How can i get lost, if i have no where to go"
    -- Metallica from Unforgiven III

[ahmad (aanbar)]

Sorry, I missed that, Thanks john.

I have installed it & it appears to be working fine.

[John Vivirito (gnomefreak)]

On 01/13/10 12:15, ahmad wrote:
> Sorry, I missed that, Thanks john.
>
> I have installed it & it appears to be working fine.
>
no problem

--
Sincerely Yours,
    John Vivirito

https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246

"How can i get lost, if i have no where to go"
    -- Metallica from Unforgiven III

[habtool (clive-wagenaar)]

I added this ppa to my karmic install (on sdc2 ocz ssd) and it is working perfectly again, many thanks Felix.
https://launchpad.net/~fzielcke/+archive/grub-ppa

[Najmudin (hussain-hammady-gmail)]

Thanks habtool , the ppa worked for me too.

[Andrew (andrewabc)]

I got tired of waiting for fix to be pushed in karmic, so I used PPA.
Sadly it did not fix the problem. Still takes 10 seconds for GRUB to appear while my hard drive is thrashing. Ubuntu 9.10 is on SSD. Ubuntu 9.04 and winxp is on hard drive.

I deleted my ubuntu 9.04 partition on hard drive and now grub only takes 3 seconds of hard drive thrashing to load.

I switched first boot device to SSD and grub doesn't load (like I earlier explained in this bug). As explained earlier this is because MBR is on hard drive. So hard drive has to be first boot device. So MBR on hard drive points to grub on SSD...

So does this mean the only solution for me is to somehow move MBR to SSD? How is this done? Is there a simple tutorial? I still need to boot to winxp on hard drive as well. If I were to unplug hard drive would that mean ubuntu on SSD would not even boot since MBR is on hard drive? In future I might be replacing hard drive with newer one.

Were other peoples MBR on hard drive? Or were they on SSD(2nd device), but grub was telling them to look on hard drive first which was causing the delay? Was that specifically this bug? My bug is specifically MBR on hard drive which is not where grub is?

[Andrew (andrewabc)]

After updating grub to PPA, then deleting ubuntu on hard drive, it seems that loading grub only hard disk thrash for 1 second, then 2 silent seconds, then grub options appear.
I doubt it will get any better than this. I think ubuntu on hard drive is what caused most of the hard drive thrashing (had to search 5 partitions instead of current 2 for grub).

[Felix Zielcke (fzielcke)]

benzino I don't think you're familiar with how Ubuntu uses the LP bug status field, since you just registered today.
This is fixed in lucid and so it's Fix Released and not Fix Commited:
Please see https://wiki.ubuntu.com/Bugs/Status

My ppa doestn't contain any other fix for this which is not in lucid.

[Jayson (jayson)]

Will the fixed package be released in the Karmic repositories?

If not, and I add Felix's PPA to my installation, will I run into any problems when I upgrade to Lucid and the latest grub-pc as included in those repos in the spring?

Also, should this PPA be removed from my software sources before I perform the upgrade to Lucid in April?

Thanks!

[Felix Zielcke (fzielcke)]

Am Mittwoch, den 20.01.2010, 19:09 +0000 schrieb Jayson:
> Will the fixed package be released in the Karmic repositories?

I can't tell you.

> If not, and I add Felix's PPA to my installation, will I run into any
> problems when I upgrade to Lucid and the latest grub-pc as included in
> those repos in the spring?

My PPA tracks the experimental branch, whereas the normal Ubuntu
packages track trunk. And note that the version number of the packages
from my PPA will (probable) be always higher then the normal packages.

So if you want to switch back to the normal packages the best would be
to remove grub-pc and grub-common and then install the normal ones.
I don't think you need to purge them so the changes to /etc/default/grub
and /etc/grub.d/* files should be kept or dpkg should tell you if
they're differences.

> Also, should this PPA be removed from my software sources before I
> perform the upgrade to Lucid in April?
>
> Thanks!

The PPA also provides the packages for lucid, but currently they're just
copies of the karmic packages. Maybe I should do seperate uploads so
that they get seperately built.
LP doestn't seem to anymore allow it to rebuild then in karmic due to
the same version number.

Feel free to sent me a mail in private for any questions about my PPA.

--
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

[mmm286 (mmm286)]

Problem upditing grub!!

Hi,

I have kubuntu 9.10. This morning I update the Grub v.1.98 experimental and now when I reboot and I can't boot with ubuntu or windows xp.

In ubuntu gives me : "Error:file not found" and with XP gives me "Error: invalid file name".

Pleaseee any help!?
Thanks a lot and sorry for my english!

[Simone Donadello (simone-donadello)]

Felix, I've been using grub on your ppa for weeks, and it worked well. Until the update of yesterday, as reported from mmm286 (telling the truth, yesterday there were several packages updated).
Now the boot don't start, because of an error when loading kernel: after "loading Linux etc etc..." and "loading initial ramdisk" I get "error: file not found", "press any key to continue". Pressing a key brings me back to the menu.
If I enter in the edit mode from the gurb menu (pressing e) I noticed that in the last row is missing the last letter of the kernel name: "...generi". If I add the letter "c" I can boot (with ctrl-x), but this edit is temporarily and every boot I need to do this. I already tried to do a grub-update, but without results.
Maybe could you add the previous version of grub to your ppa, Felix?
Thank, have a nice day!

[Najmudin (hussain-hammady-gmail)]

I got the same Error as "mmm286 & dona.web" ,didn't know how to solve the problem ,so i reinstalled ubuntu and i'm using the default grub package now.
Waiting for Felix to solve the problem so i can install his package again :)

[hmpl (hmplfgrmp)]

I have the same problem.
Although initrd-Filenames are written correct in /boot/grub/grub.cfg, the last character of the initrd-filenames is missing in the actual Grub-entries.

[Simone Donadello (simone-donadello)]

I confirm that /boot/grub/grub.cfg is ok, but in the boot menu is missing the last character: you have to add it manually every times. There is no need to reinstalled Ubuntu: just add that character when you turn on, or force Grub version in the original repository (but with the original bug).
Is possible to revert to the previous working version of Grub that was in the PPA of Felix?

[ceg (ceg)]

Here /boot is on /dev/md0 (raid1), the installer installed grub2 into sda and sdb, and I am seeing the huge delay.
Grub2 finds /boot always/never to be on the same drive?

Does the proposed patch fix the delay in this case?

[ceg (ceg)]

Instead of using the PPA from experimental branch, should manually installing the grub2 package from lucid be ok?

[Dave Westaway (drwestaway)]

As a user since breezy badger, this karmic koala GRUB2 update is the biggest pain, I have never had boot problems with any other release. My GRUB2 takes over 30 seconds before displaying the menu. I've looked through tons of posts, all say it's fixed AND IT IS NOT!

Can't you guys tell us how to install the fix? Mr. Vivirito, just pasting a link to your personal web page doesn't cut it. Have I missed the solution? All I see are MONTHS of complaints about a small piece of the OS without resolution.

I have a multi boot system, with XP on sdb1 and 9.10 on sda6. I cannot boot to sda, since it is sata in nforce2 and not selectable for boot. My /boot and / are all on the sda (sata) device.

[dino99 (9d9)]

hi Dave,

why did you check Incomplete instead of New for this bug ?

I'm having this issue now for the first time with lucid uptodate: latest grub2 installed and menu pop up after 20 seconds of total black screen, then the boot process goes well.

I've a system with 1 sda & 2 ide: i set my bios with ahci to wipe some issues. What i've seen with latest grub2 vs previous: order and naming of my disks ave been modified and dont respect the real situation, very confusing.

[John Vivirito (gnomefreak)]

I'm not entirely sure this will get pushed into Karmic since it is not a security bug. However i am not the maintainer of grub*

Dino99,
Incomplete is marked for a few reasons one of them being waiting for an answer from devs when asking to fix it in <ubuntu release*>
However i'm going to change status to triaged since the info needed to proceed is here

[John Vivirito (gnomefreak)]

I'm not real sure if we kept grub2 up to date in Karmic since it was released

Staus change due to above comment i made

[Dave Westaway (drwestaway)]

hi john and dino99,

I apologize for my rude message last month to john. I now realize it was my ignorance causing most of my frustration, not understanding the inter relationships and how hard you all are working to fix bugs, without enough thanks.

dino99 - I also did not know that I selected "Incomplete" in my fumbling, please repair or let me know how I can change it, and to what?

After re-reading Felix's comments, I see that my choices are

(1) put up with 30 seconds from end of bios to menu, or

(2) boot from my /dev/sda (hd1) - sata, 5 partitions with karmic 9.10 sda6, except my ancient 2002 Asus a7n8x nforce2 motherboard can't select the sata for boot, only the pata.

(3) place /boot/grub on my /dev/sdb (hd0) - pata, Win XP sdb1, fat32 sdb2, except Felix states there's a known bug when "/" isn't on the same disk as /boot/grub.

So my questions are
(1) will just updating to lucid 10.04 and/or a new version of grub2 solve this?
(2) could you point me to where I can find if the bug is fixed to allow me to have /boot/grub on my boot-able drive?

thank you
dave

[Dean Montgomery (dmonty)]

I had slow grub startup and after "set debug=disk" i noticed it was stalling out on (fd0)... So because my machine does not have a floppy disk I made sure it was disabled in the BIOS. After disabling the floppy in the BIOS all my slow grub problems went away.

[dino99 (9d9)]

in my opinion, the 2 latest grub2 updates have removed most of the time booting issues, which concern this report, so the work continue on other grub2 reports now with Colin & Steve about the others issues and future features.

[ceg (ceg)]

What latest 2 updates? Have those come to current buggy production lucid?

There are unfortunately still minutes to wait each day due to grub with Raid1 Bug #577369

[dino99 (9d9)]

1.98+20100614-2ubuntu3 used on my end, but i've not raid on my system

[ceg (ceg)]

Thanks dino, that does not seem to be lucid then, every case where "stable" means no bugfix for core parts is unfortunate.

[eric (obrowny06)]

For me, the problem have started 2 weeks ago after an update i guess.
It takes 3 to 4 minutes to get to grub's menu....
sda is windows seven
sdb1 is / (grub is on that one)
sdb2 is extended
sdb5 is / home
sdb6 is swap
sdb3 is fat32

Ubuntu version 10.10

grub-pc:
  Installé : 1.98+20100804-5ubuntu3
  Candidat : 1.98+20100804-5ubuntu3
 Table de version :
 *** 1.98+20100804-5ubuntu3 0
        500 http://archive.ubuntu.com/ubuntu/ maverick/main amd64 Packages
        100 /var/lib/dpkg/status

[eric (obrowny06)]

I have just found the reason why it took so much time... There was a dvd in the player and for some reason it was working for few minutes before grub menu appears... (the player is not set to boot first)

[dino99 (9d9)]

Well that report is old but the problem still there even with the new grub 2.0

Tested on a system with 2 pata & 1 sata; each having a different grub version due to several installed distros ( no legacy grub, only 1.98+). With such config only one mbr grub is the "master" (need to update it to get an updated grub menu if the other distro have had kernel upgrades).

So if the booting grub (related to the hdd selected into the bios) is not on the same hdd than the distro loaded, now grub 2.0 is so confused (cant find the pathes) that the process is killed even before getting the grub menu (before grub 2.0, a black screen was shown for a while before getting the menu).

[dino99 (9d9)]

comments about the post #135 above:

finally found that mess was due to grub-customizer that i've had used in the past and purged everywhere; but sadly it left some modified settings behind. But thanks to boot-repair to cleanly removed that garbage and cleanly reinstalled grub 2.0 working smootly now, except that the menu still does not appear at the beginning (blackscreen for about 5 to 10 seconds, then the menu is shown)

[dino99 (9d9)]

Even with fresh reformatted partitions, the grub2 menu is still delayed with the latest RR/SS grub2 versions.

[dino99 (9d9)]

Delay still persist with 2.02 beta2-2 on Trusty

[dino99 (9d9)]

savannah report has been closed long time ago, due to 'Fixed in experimental branch' in 2009/11

[dino99 (9d9)]

The versions used with ubuntu has all been upgraded with time; and there is no duplicate of that report since ages, nor comments recently. So closing it now.

[Paul Dufresne (paulduf)]

I have an hypothesis.
I have seen that when I do a grub ls on my bios_boot (flag in GPARTED) partition, it takes about
3 mins to list it. I believe this is due to the fact that I put clear partition typed for that
partition in gparted. So I belive that when grub 2.0.2 do a search on that partition, it try to
'mount' it with all known partition types to figure out what it is.

So what I am thinking to do is to add on my search commands, the undocumented hint=[guess to what
the search should return as partition answer], that way, I expect search to try that partition
first, and then avoid passing by the bios_boot partition without a known type that make things
very slow.

[Aku Cidro (akucidro)]

Loving the information on this website, you have a great job on the posts.

http://www.jasalantaiepoxy.com

[Aku Cidro (akucidro)]

Your site has the same post as another author but i like yours much better.

https://fazurautama.co.id