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.
--
Current grub-pc takes several minutes to show men
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 I
@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
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.
--
Current grub-pc takes several minutes to show menu
https://bugs.launchpad.net/bugs/420933
You received thi
Am Samstag, den 31.10.2009, 09:23 + 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.
Has this been reported upstream? Does anyone have an upstream bug
reference?
--
Current grub-pc takes several minutes to show menu
https://bugs.launchpad.net/bugs/420933
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mai
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 ha
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
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.
--
Current grub-pc takes several minutes to show menu
https://bugs.launchpad.net/bugs/420933
You received t
"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.
Am Freitag, den 30.10.2009, 10:35 + 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 m
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 an
Am Freitag, den 30.10.2009, 08:45 + 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 GR
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 m
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:
/
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).
--
Current
For me the problem was resolved by changing the boot drive priority in
the bios (from pata drive to sata drive)
--
Current grub-pc takes several minutes to show menu
https://bugs.launchpad.net/bugs/420933
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscr
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
--
Current grub-pc takes several minutes to show menu
https://bugs.launchpad.net/bugs/420933
You received this bug notification because you a
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
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
Same problem here with 1.97 beta4.
--
Current grub-pc takes several minutes to show menu
https://bugs.launchpad.net/bugs/420933
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
htt
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 - s
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
Yea, "Disk Thrashing"...
http://ubuntuforums.org/showthread.php?t=1290221
--
Current grub-pc takes several minutes to show menu
https://bugs.launchpad.net/bugs/420933
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailin
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
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.
--
Current grub-pc takes several minutes to show menu
https://bugs.launchpad.net/bugs/420933
You received this bug notificat
Sorry Colin---early morning.
--
Current grub-pc takes several minutes to show menu
https://bugs.launchpad.net/bugs/420933
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https
** Changed in: grub2 (Debian)
Status: Unknown => New
--
Current grub-pc takes several minutes to show menu
https://bugs.launchpad.net/bugs/420933
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-
** Also affects: grub2 (Debian) via
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541145
Importance: Unknown
Status: Unknown
--
Current grub-pc takes several minutes to show menu
https://bugs.launchpad.net/bugs/420933
You received this bug notification because you are a member of
Hi,
On my dell mini9 I have only one partition as ext2 but brub is long.
It crashes more and open a root access!
--
Current grub-pc takes several minutes to show menu
https://bugs.launchpad.net/bugs/420933
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscr
Hi Colin-- I do not know what is happeningThe 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 interesti
** Changed in: grub2 (Ubuntu)
Status: Incomplete => Confirmed
--
Current grub-pc takes several minutes to show menu
https://bugs.launchpad.net/bugs/420933
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing lis
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.
--
Current grub-pc takes several minutes to show menu
https://bugs.launchpad.net/bugs/420933
You received this bug notification because yo
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
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 partit
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
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.
--
Current grub-pc takes several minutes to show menu
https:/
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 bitstill not very good, but better than
it was.
--
Curre
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.
--
Current grub-pc takes several minutes to show menu
https://bugs.launchpad.net/bugs/420933
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribe
I can confirm that jocko's workaround fixes the problem for me.
Something with grub on one drive and boot folder on another.
--
Current grub-pc takes several minutes to show menu
https://bugs.launchpad.net/bugs/420933
You received this bug notification because you are a member of Ubuntu
Bugs, w
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
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).
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
** Bug watch added: Debian Bug tracker #541145
http:/
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.
--
Current grub-pc takes several minutes to show menu
https://bugs.launchpad.net/bugs/420933
You received this bug notifi
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
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
deb
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 tha
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.
--
Current grub-pc takes several
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
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)
** Attachment added: "lspci-vvnn"
http://launchpadlibrarian.net/30961656/lspci-vvnn
--
Current grub-pc takes several minutes to show menu
https://bugs.launchpad.net/bugs/420933
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubun
** Attachment added: "Dependencies.txt"
http://launchpadlibrarian.net/30961568/Dependencies.txt
** Tags added: apport-collected
--
Current grub-pc takes several minutes to show menu
https://bugs.launchpad.net/bugs/420933
You received this bug notification because you are a member of Ubuntu
B
Same comments as Jocko
--
Current grub-pc takes several minutes to show menu
https://bugs.launchpad.net/bugs/420933
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.u
Oh... And my lsb_release and apt-cache info is identical to Dean's in
the report...
--
Current grub-pc takes several minutes to show menu
https://bugs.launchpad.net/bugs/420933
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-b
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
101 - 155 of 155 matches
Mail list logo
