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.

[Felix Zielcke (fzielcke)]

Am Freitag, den 30.10.2009, 08:45 +0000 schrieb xenesis:
> 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.
>

If hd0 is your Vista, then you have problabe installed GRUB to the MBR
of that disk and not sdb.
In that case UUIDs get used for the $prefix where GRUB loads everything
it needs from itself, i.e. the modules.
Just run `sudo dpkg-reconfigure grub-pc' unselect /dev/sda and
select /dev/sdb
and then change your BIOS boot order to boot from sdb and not any more
from sda.

--
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

[mikeXYZ (qmikeq)]

A user shouldn't have to change the boot order to get the new-and-improved GRUB to work reasonably well.

Many users have Windows on a first-in-BIOS HDD "sda" and boot from that HDD by installing GRUB to its MBR, in preference to maintaining their Windows on a non-first HDD (requiring devicemap and being subject to various maintenance issues, especially as Windows receives updates). I do agree with posters above now that this is a show stopper. Not only is the delay between POST and boot menu unacceptably long (70 s in my case, with just two standard SATA disks), but there also may be a 2-6 second delay after selecting a menuentry from the menu. As GRUB improves along certain useful dimensions (e.g., loopback, GPT support, os-prober, etc.), many other new features will never be used by most users of GRUB; so let's not ask them to live with a regression of basic performance & features. (BTW, I'm a GRUB lover, too, and an active how-to writer these past several years, aka Qqmike@kubuntuforums).

[Felix Zielcke (fzielcke)]

Am Freitag, den 30.10.2009, 10:35 +0000 schrieb mikeXYZ:
> A user shouldn't have to change the boot order to get the new-and-
> improved GRUB to work reasonably well.
>
> Many users have Windows on a first-in-BIOS HDD "sda" and boot from that
> HDD by installing GRUB to its MBR, in preference to maintaining their
> Windows on a non-first HDD (requiring devicemap and being subject to
> various maintenance issues, especially as Windows receives updates). I
> do agree with posters above now that this is a show stopper. Not only
> is the delay between POST and boot menu unacceptably long (70 s in my
> case, with just two standard SATA disks), but there also may be a 2-6
> second delay after selecting a menuentry from the menu. As GRUB
> improves along certain useful dimensions (e.g., loopback, GPT support,
> os-prober, etc.), many other new features will never be used by most
> users of GRUB; so let's not ask them to live with a regression of basic
> performance & features. (BTW, I'm a GRUB lover, too, and an active how-
> to writer these past several years, aka Qqmike@kubuntuforums).
>

I can't image any reason why for Windows itself it makes a difference if
BIOS really booted from the same harddisk or if it's emulated via
drivemap command.
30_os-prober adds drivemap anyway always with Windows < Vista
And I don't get all why you said `especially as Windows receives
updates'
Windows update shouldn't at all affect this.

Well anyway, the only 2 fixes/workarounds for this you currently have is
to either install it to the MBR of the disk containing /boot/grub or
hack grub-install so it doestn't use the UUID= hack but instead
hardcodes the real grub device for /boot/grub.
But if then the BIOS disk order changes then you have to change
grub-install again.
And the changes get lost on the next package upgrade.

--
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

[mikeXYZ (qmikeq)]

"Windows update shouldn't at all affect this."

Actually, I've only been told this and read it from rabbit Windows users, just hearsay; namely that after certain updates that also tamper with their boot/bootmanager, they find problems with their dual booting and have to re-install GRUB to fix it. Anyway, thanks for your feedback.

[xenesis (wagner-sim88)]

Grub is already installed on /dev/sdb for me

The problem here is perhaps, that /dev/sdb7 contains my Ubuntu installation and that it is not in the first partition.
But I am just guessing.

[Alex (alexander-stehlik)]

OK, the problem is gone for me but unfortunately I can't exactly tell why. Thats what I did.

(see my harddisk/partition configuration in my prevoius post)

I reinstalled grup on /dev/sdb with `sudo dpkg-reconfigure grub-pc` like Felix suggested.
-> same problem.

I checked /dev/sda in Palimpsest an it was marked as bootable. I removed the bootable flag an REBOOTED (didn't switch power of!).
-> same problem

I SHUTDOWN the pc an removed /dev/sda (IDE drive)
-> problem was gone

I put /dev/sda back in again
-> problem still gone

My guess is, that the system hadn't recognized the removal of the "bootable"-flag after the reboot, but after powering off the system on powering it back on again.

[Andrew (andrewabc)]

I also have this problem. It says:
Grub Loading.
then hard drive thrashing for about 7 seconds, then GRUB appears, I select what to boot (or wait 10 seconds) and hard drive thrashes for 1-2 more seconds.

I have ubuntu 9.10 on OCZ vertex 60gb SSD with ext4 / partition and swap partition.
On my hard drive I have winxp partition. ntfs data partition. small recovery fat32 partition. ubuntu 9.04 / partition, /home partition, swap partition.

With me having SSD, and ubuntu booting from SSD and supposedly GRUB should be on there, I should not have any hard drive thrashing at all.
I had 9.04 installed on SSD and old grub worked fine with hard drive, no thrashing at all.

/6 second bootchart

[zeimusu (james-kilfiger)]

Has this been reported upstream? Does anyone have an upstream bug reference?

[Felix Zielcke (fzielcke)]

Am Samstag, den 31.10.2009, 09:23 +0000 schrieb zeimusu:
> Has this been reported upstream? Does anyone have an upstream bug
> reference?

There's no bug report on Savannah for this.
Only discussion and a WIP patch on the mailing list:

http://lists.gnu.org/archive/html/grub-devel/2009-09/msg00313.html

--
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

[Jorge (jordimen)]

I also have this problem, but after change grub to the second hard disk where I have ubuntu and change the boot disk priority to boot from fron the second hard disk, the problem has gone.

[Andrew (andrewabc)]

@jorge
How do you change grub to a different drive?

I went into BIOS, and changed my SSD to boot before HDD (boot priority), and my computer would not boot into anything. So that makes me think that my grub or MBR is on the hard drive even though I installed ubuntu to my SSD. If grub were moved to SSD and I have SSD as first priority it should work properly according to your post. Suggestions please on how to move grub to my SSD (or make sure that is where it is).

[manksman (manksman)]

This has been a bad experience for me too, after upgrading from 9.04 to 9.10 I lost sound- the hardware just vanished, so I decided to do a fresh install from CD. This has left me with a 50 second wait whilst the hard disks are thrashed and then with a grub menu that has left out Fedora. I have 3 IDE drives and a total of 7 os instalations. I can just about see what the idea behind this all is, but it just does not work in a user friendly way. Boot time is now so slow I am wishing I had never tried 9.10.

[Ben Bridgwater (bbridgwater)]

I had been running 9.04 with no problems, then today tried installing the 9.10 release (two hard drives, Ubuntu on the 2nd) and got this "GRUB loading" very slow boot. On top of that Firefox hangs, as does Seamonkey. I've just reverted to 9.04.

[xenesis (wagner-sim88)]

Installing GRUB into another partition: sudo dpkg-reconfigure grub-pc

According to the GRUB Mailing List, they are aware of this problem and a patch will soon be merged: http://lists.gnu.org/archive/html/grub-devel/2009-10/msg00519.html

[zeimusu (james-kilfiger)]

Now reported at savannah: https://savannah.gnu.org/bugs/index.php?27900

[halfsane (gorillabeast)]

Is there an ETA ?

[Evžen Šubrt (evzen-subrt)]

I confirm the bug too. Dual boot Koala & Windows. Two disks, PATA and SATA. Grub on different partition than /boot.
Hopefully, thys wil be solved soon. Although it is not boot-denying error, few second disc trashing is very cheap and anoying.

I will not move the grub to another disc just because of some bug - that is stupid workaround and users should not allow developert to get used to such "easy solution"

[Desh Danz (nicoluno)]

Same bug on my system:

sda --> Win XP (and MBR) (NTFS)
sdb --> data & backup partition (NTFS)
sdc --> Karmic 64 with /boot (ext4)

45-50 seconds of spotless disk trashing at boot, then Karmic starts. Karmic itself should even be really fast to boot but the Grub2 useless waiting time defeats any benefit Karmic can bring.

Any news on bugfixing state?

[kokx (pieter-kokx)]

Besides that GRUB is also loading slow for me, it also won't load the menu.

I have about the same disk configuration like everyone else: first disk is a Windows installation, and on the second disk i got my Ubuntu installation.

I am going back to grub-legacy, and i hope that this bug will be fixed soon.

[Fabio Varesano (fabio-varesano)]

I'm also having this problem.. here grub takes 6-10 seconds to display the menu.. pretty boring.

[daemacles (daemacles)]

Also have this problem. Why again is grub2 so much better?

[daemacles (daemacles)]

Sorry, complaints don't fix anything ... this is just frustrating.

[Jayson (jayson)]

I upgraded to Grub2 in Jaunty (version 1.96) some time before my upgrade to Karmic thinking it would make the transition easier. XP on sda, Ubuntu on sdb, MBR on sda (same as others here), Grub2 loaded almost instantaneously (both drives are IDE in old HP PC).

After the Karmic upgrade and Grub 1.97 I now stare at "Grub loading" for 15 seconds before the menu appears. Additionally Karmic takes longer to get to the desktop than Jaunty even without the Grub issue.

I could try the workaround and install grub to sdb, but I'm afraid I may break something, and anyway I shouldn't have to since Grub 1.96 worked perfectly! This is a regression that needs to be fixed!

[buizerd (havik)]

Same problem here with 1.97 beta4.
it takes 30 seconds to show
sudo dpkg-reconfigure grub-pc gives no result

[mmm286 (mmm286)]

Same problem here with 1.97

/dev/sda (grub) --> Windows
/dev/sdb --> linux

Grub takes 10 seconds to display the menu.. pretty boring.

[Felix Zielcke (fzielcke)]

Am Sonntag, den 15.11.2009, 08:33 +0000 schrieb buizerd:
> Same problem here with 1.97 beta4.
> it takes 30 seconds to show
> sudo dpkg-reconfigure grub-pc gives no result

What does `gives no result' mean?
You need to choose the device where your /boot/grub is on and also
select that disk in your BIOS boot order.
If you don't do both things then nothing changes.

--
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

[buizerd (havik)]

>You need to choose the device where your /boot/grub is on and also
>select that disk in your BIOS boot order.
>f you don't do both things then nothing changes.

I did both
but my system will not boot from IDE-1 where ubuntu is (Whole disk)
How can I make the disk bootable

[Rafael Buchbinder (rafi-bk)]

Well, I am affected too:
/dev/sda - XP
/dev/sdb - Ubuntu 9.10

grub2 takes about 40 seconds to show the selection window, and another 5 seconds to start loading a selected OS.
During this 'wait' time the hard disk works so loud that I can hear it from outside the room :)

Anyway, I have followed the instructions here https://help.ubuntu.com/community/Grub2
and reverted to the old grub. Works like a charm!

I hope, this bug is resolved soon so I can install grub2 again and set up a nice Ubuntu theme.

If not this bug, my Ubuntu 9.10 experience would be perfect...

[Fabio Varesano (fabio-varesano)]

This bug is affecting a lot of users. If you want to help speeding up this bug resolution you can vote for it on the upstream bug report so that Grub2 developers will focus on it sooner.

To do so, go to http://savannah.gnu.org/bugs/?27900 , register, and then vote for this bug.

[xenesis (wagner-sim88)]

Hm, I tested it in a virtual machine.
With the ubuntu version of Grub2 I could reproduce the problem.

After the installation of the current Grub2 trunk from source, the problem went away. So the problem seems to be fixed in trunk?

[Felix Zielcke (fzielcke)]

Am Montag, den 16.11.2009, 16:07 +0000 schrieb xenesis:
> Hm, I tested it in a virtual machine.
> With the ubuntu version of Grub2 I could reproduce the problem.
>
> After the installation of the current Grub2 trunk from source, the
> problem went away. So the problem seems to be fixed in trunk?
>

No. Vladimir didn't commit yet his patch. But he wants to do this now
soon.
Did you really test this right?
I.e. you installed GRUB into MBR of a different disk then /boot/grub is
on and booted from that one?
And running `make install' doestn't run grub-install so
neither /boot/grub nor MBR gets changed.

--
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

[Lê Kiến Trúc (le-kien-truc)]

There are some guys reported that if he remove his CD/DVD Drive then he restarted and the Grub Menu showed up immediately.

[xenesis (wagner-sim88)]

I did experiment with the disk layout until I had the "long boot" layout.

I have now two virtual hard disks.
The first does contain a bunch of parititions, but no real OS
The second does contain Ubuntu 9.10 with grub2 package installed

Grub is installed in both, the first and the second virtual hard disk (done via dpkg-reconfigure grub-pc, marking /dev/sda and /dev/sdb).

If I choose to boot from the first hard drive -> long boot time for grub
If I choose the second hard drive -> short boot

Afterwards I did "make install" and then grub-install /dev/sdb. I then booted the system from the first hard drive, so I used in fact the old grub. But the problem was fixed. Somehow strange, but that would mean that it is the modules which are not playing well, since these were the only "new" parts that were used.

So yes, I assume the bug is somehow fixed, at least in trunk.

I can reproduce this behaviour easily, I have taken a snapshot so I can go back before the install. So if I can help, tell me what to do. Connecting to the serial interface of the VM should be possible.

[Xelis (xelis)]

My system affected too and in a similar configuration: karmic on the third hard disk and mbr on the first.
Grub loading hangs for 30-40 seconds on the boot, then loads the grub menu.

[Bob (tpf)]

Two weeks after upgrading to Ubuntu 9.10 - which went smoothly - installed Grub 2. This took a while to settle down.
The 800x600 choice was not a good one , although default and 1280x1024 worked well.

I have several linux versions installed and win too. The most recent Ubuntu , 9.10, is on the sata drive and win was on the pata drive. Pata has MBR, so similar setup to those above. Previous experience with booting problems because of early SATA mobo led me to experiment with swapping setting in device.map. This led to further issues as I had set win as default and it failed to load. It was vi for me again and a bit of a struggle to fight my way back.
I am impressed by the ability of Grub 2 to find and build multiboot access ( as I renamed the config files to force it to work from scratch. It got a good list up and chose better settings than I sometimes did. It found five oses, some with several kernels. This reached a max of about thirty entries.
It was about then that I googled about the delay and found bug reported. (That which should be done first !)

The normal time for the disk thrashing is about two minutes before the Grub selection screen comes up.
Seeing the suggestion above, I removed one, then both optical disk drives and replaced them. This did not favorably affect grub.

As this is an aging rig, I thought it might be of interest.

BTW, I have network a Celeron box with 10 g HD 133 mhz, 33 DMA, running Ubuntu 910. Installed from alt cd while it had 128mb mem. Took about 2 hours but installed sucessfully. It struggled to even open a task so added 256 mb and it is quite usable. Has just under 6 g partition with you know who next door, dual boot with Grub 2. Works great

Look forward to early resolution of bug. It is going to be a great loader.

Ubuntu 9.10 (karmic) Gnome 2.28.1 (Ubuntu 2009-11-03)
AMD Athlon(tm) XP 2600+
MB Name A7N8X-E ASUSTeK Computer INC.
1002 MiB memory
2117 MiB swap ( overkill )
GeForce4 MX 440 with AGP8X
120 G PATA HD ATA ST3120026A
320 G SATA HD ATA ST3320620AS
DVD ASUS DRW-0402P/D
CD HL-DT-ST CD-RW GCE-8160B
cheers
bob

[wjamoore (aaron-moore-alsatis)]

Hi All,

I've been quietly watching for that last month and I am (still) as confused as hell over this.

I have:

(hd0) /dev/sda
(hd1) /dev/sdb
(hd2) /dev/sdc

sda is windows 2k and another partition of data

sdb has loads of partions

sdb1 is 9-10 Karmic
sdb2 NTFS data
sdb3 NTFS data
sdb4 to 10 are old 9-04 and linux swap partitions that i am not using (just in case I need to go back). i might format them to 1 partition for clarity

MBR is on sda

sdc is ? i have no idea. And Grub 2 does lots of looking at that if when I did grub update for example and gives a pile of errors.

Is it the DVD drive?

So how do I fix the boot problem.

Is there a concise step by step guide. I do not wish to screw up my PC and so far i've been to scared to do anything for fear of no boot. I need this for my work.. (although I have my data backed up, I have no intention of reloading OS's and all my extra SW again if i can possibly avoid it)

Otherwise 9-10 works quite well. except for occasional black screens when many windows are open :-(

any advice appreciated

aaron

[Felix Zielcke (fzielcke)]

My PPA contains now Vladimir's fix for this problem:
https://launchpad.net/~fzielcke/+archive/grub-ppa

But currently there's a bug if you /boot is a seperate partition then /.
The linux menu entries wrongly have /boot/ added when they should not.

[zeimusu (james-kilfiger)]

Thanks Felix. I can confirm that your ppa build fixes this issue for me.

Two things I noticed about your build. I get a very brief error message appearing between "grub loading" and the grub menu. It seems to be complaining about an unrecognized character. Secondly update-grub takes a very long time to do anything.

But my system now boots twice as fast :-)

[Bob (tpf)]

Thanks from me as well, Felix.
Grub is booting much quicker.

I noticed an unrecognised character just prior to menu appearing as well.
As I had manually modified default/grub, changed the execute bit on a couple of the grub.d files and edited one of them, I had put it down to a typo of mine. Since Zeimusu had seen something as well, I checked my entries again and could see no punctuation or other flaws ( which is different to saying there are none - grin).

Most importantly, Grub 2 is cracking along nicely - and I have reduced the menu to just a few items, so I'm chuffed!
cheers
bob

[Fabio Varesano (fabio-varesano)]

Bug fixed in grub2 experimental branch

[Bart Verwilst (verwilst)]

So, any idea when this will hit Karmic repo's?

[Bart Verwilst (verwilst)]

I'm using 1.97+experimental.20091127-1ubuntu1~ppa1, but still loading grub takes a long time for me, over 10 seconds, like it did before.. Am I missing something? :)

[wjamoore (aaron-moore-alsatis)]

 I second Bart Verwilst on the request for fix info...

I was hoping for a fix in the updates but sadly not. What is slightly annoying about Ubuntu generally is that when a bug is found and verified there is no real way to know when it will get fixed.

On the plus point it seems some video issues have been fixed

[Felix Zielcke (fzielcke)]

Am Sonntag, den 06.12.2009, 11:13 +0000 schrieb Bart Verwilst:
> I'm using 1.97+experimental.20091127-1ubuntu1~ppa1, but still loading
> grub takes a long time for me, over 10 seconds, like it did before..
> Am
> I missing something? :)

Did the grub-pc postinst ran grub-install to the correct device?
Check what `echo GET grub-pc/install_devices | debconf-communicate'
says.
To be safe that GRUB has been updated just run grub-install /dev/sda.
Of course change the device to the one your BIOS boots from.

--
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

[tonyappuk (forum-pensilva)]

My Mint8 (derived of course from Ubuntu) is on sdd my fourth drive and I installed Grub2 to the mbr on sda, where XP lives. All my drives are PATA after Legacy Grub had problems with a mix of PATA and SATA. This works but gives the long dwell on Grub Loading, about four minutes in my case. I then tried the trick of installing Grub2 to the mbr of sdd and switched the bios drive priority. The boot time is reduced to a few seconds although the time to act on a menu selection is too long (10-12 seconds). However in this state it won't boot Windows XP complaining that it can't find the device with the listed uuid. A bit more Googling and it seems others have this problem but have no reason for it. The solution may be to insert the old drive notation rather than the uuid in grub.cfg (or the approved .d or .40 file?) taking care I suppose to use the new Grub2 labelling. Haven't tried that yet but I may do. On the other hand I may just go back to Legacy Grub. It does seem for multidrive systems Mint8 (Ubuntu) with Grub2 is a disaster.
Tony

[Bruce Miller (brm0423)]

Have just installed Lucid Alpha 1 this morning and performed an immediate "full-upgrade".

Both on first boot after installation and on subsequent OS restarts, grub2 has displayed its "Loading Grub" message for 90 seconds before briefly going blank and displaying the pick scree.

[Bob (tpf)]

Tonyappuk,,

I suggest you reorganise your mbr so that windows boots, then use Vladimir's fix for this problem:
https://launchpad.net/~fzielcke/+archive/grub-ppa .

I can't guarantee it will work for you, but it did the trick for me
cheers
bob

[Jayson (jayson)]

Just chiming in again. It's been 10 days since the last post & I'm concerned that the correction of this regression will just float off into the ether.

This issue has apparently been fixed upstream and in experimental builds, but why not in Ubuntu 9.10+? Also, I'm concerned that Ubuntu is using a beta copy of Grub2 while the latest build on gnu.org is 1.97.1 final.

I love my Ubuntu/XPsp3 box and don't want to break it by switching my MBR to sdb (plus my wife will kill me :P ). Ubuntu 9.04 started perfectly with Grub2 1.96.

I am seriously considering rolling back to Grub Legacy in the New Year. Please escalate the priority of releasing a fix for this troubling issue. If Ubuntu ever hopes to compete with M$...

[Fabio Marzocca (thesaltydog)]

I believe that Jayson's last post is shared by most of us.

[litleubu (cke)]

I agree Fabio, many bugs are not that bad...but 30s before starting booting it's not usable ... i'll stay in 9.04

[Desh Danz (nicoluno)]

Agree, it's a shame.....

[tonyappuk (forum-pensilva)]

Bob
Thanks for your comment but I took the easy way out and went back to Legacy Grub. A few edits of Menu.lst and I have a useable multidrive, multi os system that boots and selects quickly. If Linux is to challenge MS as an OS for the non technical man in the street I understand that the multiboot system must find all the drives and OS's and write the boot manager automatically but Grub2 is not able to do that yet. It might do in the future but until that day distros should carry a big warning about using Grub2 in anything but a single drive Windows plus one Linux Distro set up, and include Legacy Grub as an option.
Tony

[Russell Green (r.green)]

This has been fixed by the grub developers, it will find its way into ubuntu soon.

[Bart Verwilst (verwilst)]

"find its way into ubuntu soon" as in Ubuntu 10.04 or as a backport in 9.10? :)

[Russell Green (r.green)]

Once an offical release has been made upstream then its up to the developers to backport the fix into 9.10, my guess is this will happen.

It will definitely be in 10.04 as soon as the the grub developers make their next release.

[Xelis (xelis)]

I don't think it has been fixed in Debian release either, after all..

My system has
sda: xp
sdb: debian sid
sdc: ubuntu karmic

I use the testing version of grub, the one included in Sid, and marked as "1.98~20091222-1".
It is installed in the sda MBR but the boot still is extremely slow and the disks thrash a lot before being able to start.

Some time ago I've installed the version "1.98~20091213-1 experimental" and that one was the only one that resolved the issue. But next upgrade reverted the situation and took the bug back again.

[Felix Zielcke (fzielcke)]

Am Montag, den 28.12.2009, 16:33 +0000 schrieb Xelis:
> I don't think it has been fixed in Debian release either, after all..
>
> My system has
> sda: xp
> sdb: debian sid
> sdc: ubuntu karmic
>
> I use the testing version of grub, the one included in Sid, and marked
> as "1.98~20091222-1".
> It is installed in the sda MBR but the boot still is extremely slow
> and the disks thrash a lot before being able to start.
>
> Some time ago I've installed the version "1.98~20091213-1
> experimental"
> and that one was the only one that resolved the issue. But next
> upgrade
> reverted the situation and took the bug back again.

Yes because that upload was meant for experimental as you can see from
the version number and not unstable.
Was my mistake and that got reverted. Though actually the wrong sid
upload had 1.97+experimental.20091213-1 as version.
The 1.98~ is now used due to that.
Upstream merged this fix into the trunk branch after the latest sid
upload.
So for now you either have to use the Debian experimental package which
is also avaible via my PPA with the Ubuntu changes merged in or compile
it yourself.
--
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

[Felix Zielcke (fzielcke)]

Am Mittwoch, den 30.12.2009, 18:09 +0000 schrieb Cyril:
> ** Changed in: grub2 (Ubuntu)
> Status: Fix Committed => Fix Released

Why do you mark this for Ubuntu Fix Released?
On LP you aren't in any Teams and Ubuntu does not have a fixed package
yet in lucid.
Just because it's fixed in my PPA and in Debian doestn't mean it's fixed
in an official Ubuntu repository.
Please see here:
https://wiki.ubuntu.com/Bugs/Status

--
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

[Xelis (xelis)]

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

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

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.

[Felix Zielcke (fzielcke)]

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

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

[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