Ubuntu

Current grub-pc takes several minutes to show menu

Reported by Dean Loros on 2009-08-29
394
This bug affects 78 people
Affects Status Importance Assigned to Milestone
grub
Unknown
Unknown
grub2 (Debian)
Confirmed
Unknown
grub2 (Ubuntu)
Low
Unassigned
Nominated for Karmic by kokx

Bug Description

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

Related branches

jocko (jomnal00) wrote :

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) wrote :

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

dino99 (9d9) wrote :

Same comments as Jocko

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

dino99 (9d9) wrote :
tags: added: apport-collected
dino99 (9d9) wrote :
Colin Watson (cjwatson) wrote :

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.

Changed in grub2 (Ubuntu):
status: New → Incomplete
Dean Loros (autocrosser) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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.

zeimusu (james-kilfiger) on 2009-09-23
Changed in grub2 (Ubuntu):
status: Incomplete → Confirmed
Dean Loros (autocrosser) wrote :

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) wrote :

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

Changed in grub2 (Debian):
status: Unknown → New
Dean Loros (autocrosser) wrote :

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) wrote :

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

Dean Loros (autocrosser) wrote :

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) wrote :
mikeXYZ (qmikeq) wrote :

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.

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) wrote :

Same problem here with 1.97 beta4.

TToft (ttoft) wrote :

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) wrote :

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) wrote :

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) wrote :

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

rpgmaker (justmc) wrote :

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).

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) wrote :

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.

Changed in grub2 (Debian):
status: New → Fix Released
Changed in grub2 (Ubuntu):
status: Confirmed → Fix Committed
status: Fix Committed → Confirmed
Russell Green (r.green) on 2009-12-27
Changed in grub2 (Ubuntu):
status: Confirmed → Fix Committed
Cyril (i3s7) on 2009-12-30
Changed in grub2 (Ubuntu):
status: Fix Committed → Fix Released
Felix Zielcke (fzielcke) on 2009-12-30
Changed in grub2 (Ubuntu):
status: Fix Released → Confirmed
58 comments hidden view all 138 comments
Xelis (xelis) wrote :

Felix, thank you for your clarification.
I hope the fix could enter in the Ubuntu repository soon. In the meanwhile I'm using the package in your PPA.

Ross Younger (crazyscot) wrote :

I had the same issues with a fresh install of karmic on my amd64 box. (Two SATA drives, first for XP, second for karmic - though I was seeing only a 10-15 second delay on boot and another few seconds pause on selecting an image to boot.) Telling the BIOS to prefer to boot from the second drive didn't initially help until I noticed that sdb1 - as set up by the karmic installer - hadn't been marked as bootable...! Manually setting the bootable flag fixed it.

I temporarily undid the fix and tried 1.98~experimental.20100105-0ubuntu1~ppa1 from Felix's PPA, which also fixed the issue.

Finally, a word of warning to any newbies reading this thread: don't put "set debug=all" in your grub config unless you are prepared to deal with a very slow boot. I tried it, out of interest, but got bored after about 15 minutes (there was a mind-boggling amount of uninteresting screen output) and ended up using a livecd to undo the change.

Andrew (andrewabc) wrote :

I just checked my SSD that karmic is installed to, and it doesn't have the boot flag either. Only my winxp partition on hard drive has boot flag. Not even my Jaunty partition on hard drive has boot flag.

When I set my SSD as first boot device in BIOS the screen would stay black and nothing happen (grub wouldn't show up). Would this be because of no boot flag on SSD? Or because grub maybe isn't on the SSD? Or is the long grub load time because my HDD is first boot priority and grub is on SSD?

I'm waiting for an official fix. Don't want to screw anything up.

Am Donnerstag, den 07.01.2010, 14:39 +0000 schrieb Andrew:
> When I set my SSD as first boot device in BIOS the screen would stay
> black and nothing happen (grub wouldn't show up). Would this be
> because
> of no boot flag on SSD? Or because grub maybe isn't on the SSD?

Yes, it is not in the MBR of your SSD. With GRUB the boot flag doestn't
matter at all, as long as GRUB is installed on the MBR.

> Or is
> the long grub load time because my HDD is first boot priority and grub
> is on SSD?

Yes, if you mean that GRUB is in the MBR of your hdd and your /boot/grub
is on the SSD

--
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

Launchpad Janitor (janitor) wrote :
Download full text (4.4 KiB)

This bug was fixed in the package grub2 - 1.98~20100101-1ubuntu1

---------------
grub2 (1.98~20100101-1ubuntu1) lucid; urgency=low

  * Resynchronise with Debian. Remaining changes:
    - Adjust for default Ubuntu boot options ("quiet splash").
    - Default to hiding the menu; holding down Shift at boot will show it.
    - Set a monochromatic theme for Ubuntu.
    - Apply Ubuntu GRUB Legacy changes to legacy update-grub script: title,
      recovery mode, quiet option, tweak how memtest86+ is displayed, and
      use UUIDs where appropriate.
    - Conflict with grub (<< 0.97-54) as well as grub-legacy.
    - Fix backslash-escaping in merge_debconf_into_conf.
    - Remove "GNU/Linux" from default distributor string.
    - Add crashkernel= options if kdump and makedumpfile are available.
    - If other operating systems are installed, then automatically unhide
      the menu. Otherwise, if GRUB_HIDDEN_TIMEOUT is 0, then use keystatus
      if available to check whether Shift is pressed. If it is, show the
      menu, otherwise boot immediately. If keystatus is not available, then
      fall back to a short delay interruptible with Escape.
    - Allow Shift to interrupt 'sleep --interruptible'.
    - Don't display introductory message about line editing unless we're
      actually offering a shell prompt. Don't clear the screen just before
      booting if we never drew the menu in the first place.
    - Remove some verbose messages printed before reading the configuration
      file.
    - If the environment variable "quiet" is set to something other than 0,
      suppress progress messages as the kernel and initrd load. Set this for
      non-recovery kernel menu entries.
    - Add GRUB_DEFAULT=saved, as well as grub-set-default and grub-reboot
      utilities. Provides functionality essentially equivalent to GRUB
      Legacy's savedefault.
    - Keep the loopback file open so that subsequent changes to the "root"
      environment variable don't affect it.
    - Change prepare_grub_to_access_device to handle filesystems
      loop-mounted on file images.
    - Ignore devices loop-mounted from files in 10_linux.
    - Show the boot menu if the previous boot failed, that is if it failed
      to get to the end of one of the normal runlevels.
    - Handle RAID devices containing virtio components.
  * Update savedefault patch from current Bazaar branch, fixing grub-reboot
    to have distinct behaviour from grub-set-default (LP: #497326).
  * Fix grub-mkisofs compilation error with FORTIFY_SOURCE.
  * Convert recordfail boilerplate in each menu entry to use a function.

grub2 (1.98~20100101-1) unstable; urgency=high

  * New Bazaar snapshot.
    - Fix FTBS on sparc.

  [ Robert Millan ]
  * rules: Auto-update version from debian/changelog.

  [ Felix Zielcke ]
  * Add -O0 to CFLAGS on powerpc to avoid the `_restgpr_31_x in boot is
    not defined' FTBFS.

grub2 (1.98~20091229-1) unstable; urgency=high

  * New Bazaar snapshot.
    - Fix slowness when $prefix uses an UUID.
      (Closes: #541145, LP: #420933)
    - Correctly set TARGET_CFLAGS. (Closes: #562953)

  [ Robert Millan ]
  * grub-rescue-pc.postinst: Build USB rescue image.
  * rules...

Read more...

Changed in grub2 (Ubuntu):
status: Confirmed → Fix Released
Jayson (jayson) wrote :

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) 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.

John Vivirito (gnomefreak) wrote :

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) wrote :

Sorry, I missed that, Thanks john.

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

John Vivirito (gnomefreak) wrote :

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) wrote :

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

Thanks habtool , the ppa worked for me too.

Andrew (andrewabc) wrote :

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) wrote :

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).

benzino (benzino) on 2010-01-18
Changed in grub2 (Ubuntu):
status: Fix Released → Fix Committed
Felix Zielcke (fzielcke) wrote :

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.

Changed in grub2 (Ubuntu):
status: Fix Committed → Fix Released
Jayson (jayson) wrote :

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) wrote :

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) wrote :

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!

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!

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 :)

Mike Grace (mjgrace) on 2010-02-05
Changed in grub2 (Ubuntu):
status: Fix Released → Fix Committed
status: Fix Committed → Fix Released
hmpl (hmplfgrmp) wrote :

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.

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) wrote :

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?

Changed in grub2 (Ubuntu):
status: Fix Released → In Progress
ceg (ceg) wrote :

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

Changed in grub2 (Ubuntu):
status: In Progress → Fix Released
Changed in grub2 (Ubuntu):
status: Fix Released → Incomplete
Dave Westaway (drwestaway) wrote :

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) wrote :

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) wrote :

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) wrote :

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

Changed in grub2 (Ubuntu):
status: Incomplete → Triaged
Dave Westaway (drwestaway) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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

ceg (ceg) wrote :

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

eric (obrowny06) wrote :

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) wrote :

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)

Changed in grub2 (Debian):
status: Fix Released → Confirmed
dino99 (9d9) wrote :

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) wrote :

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) wrote :

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

tags: added: raring saucy
Changed in grub2 (Ubuntu):
importance: Undecided → Low
dino99 (9d9) wrote :

Delay still persist with 2.02 beta2-2 on Trusty

tags: added: trusty
Displaying first 40 and last 40 comments. View all 138 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.