Grub start heel traag op

[zordaz]

Ik heb het volgende probleem:
Vanwege een defecte / instabiele harde schijf (160gb, Samsung, P-ATA) heb ik een nieuwe schijf gekocht (160gb, WD Caviar, P-ATA). Deze nieuwe schijf heb ik op exact dezelfde wijze gepartitioneerd als de oude.

Vervolgens heb ik de inhoud van de oude schijf overgezet via cp -pR naar de nieuwe schijf (die op dat moment even als secundaire hdd in het systeem hing). Daarna heb ik de nieuwe schijf bootable gemaakt middels Grub-Install (via de MBR dus) en hem als primaire hdd aangesloten.

Indeling (allemaal ext3, m.u.v. SWAP):
/dev/hda1: boot
/dev/hda2: root
/dev/hda3: home
/dev/hda4: extended
/dev/hda5: data
/dev/hda6: data
/dev/hda7: swap
Het systeem is geen dual boot en draait Debian Testing, kernel 2.6.12.

Het overzetten is perfect gelukt, echter: GRUB laadt op de nieuwe schijf ontzettend traag. Na opstarten verschijnt eerst:

Grub: Loading stage 1.5, dit duurt iets van 20 - 30 seconden
en daarna:
Grub: Loading menu, dit duurt ook dik 20 seconden.

Daarna verschijnt het bekende GRUB-menu, kan ik het systeem gewoon starten en werkt het verder allemaal als een zonnetje.

De oude schijf had / heeft dit probleem helemaal niet, daar duren deze twee stappen maar 2 seconden o.i.d.

In de bios worden beide schijven identiek gedetecteerd, het leegmaken van de MBR van de trage hdd maakte niets uit. Aansluiten op een andere IDE-kabel of IDE-slot ook niet. Om uit te sluiten dat ik een GRUB-installatie fout heb gemaakt, heb ik de kapotte/instabiele schijf als test leeggemaakt en op dezelfde manier weer voorzien van het OS en GRUB en dan laadde GRUB ook gewoon snel.

Google en dit forum bieden verder geen soelaas, heeft iemand nog een suggestie?

[Radiant]

Klinkt bekend, ik heb dit ook gehad met een WD schijf.. Duurt het toevallig ook erg lang in je BIOS om de schijf te detecteren?
Zo niet dan kan je misschien kijken (als je geen floppy drive hebt) of er toevallig een fd0 device in je devices.map staat, dit kan het ook nog wel eens erg vertragen.

[zordaz]

Radiant schreef op woensdag 28 december 2005 @ 12:09:
Klinkt bekend, ik heb dit ook gehad met een WD schijf.. Duurt het toevallig ook erg lang in je BIOS om de schijf te detecteren?
Zo niet dan kan je misschien kijken (als je geen floppy drive hebt) of er toevallig een fd0 device in je devices.map staat, dit kan het ook nog wel eens erg vertragen.

Een detectie in de BIOS gaat gewoon snel. Ik heb een grub-install gedaan met een devices.map met en eentje zonder fd0 erin. Dat hielp ook niet. Voor de instabiele Samsung HDD maakt het allemaal niets uit.

[ Voor 7% gewijzigd door zordaz op 28-12-2005 12:16 ]

[daft_dutch]

nou beheer een server en als er een tapeje in de tape streamer zit duurt het 20 min voordat stage 2 opkomt. Ik weet niet waar het aan ligt.

[DeMoN]

Ik heb dit 2 maanden geleden ook gehad op mijn Debian 64 SID desktop systeempje.
Van alles geprobeerd maar het wilde niet helpen. Volgens mij is dit gewoon een irritante bug want had er daarvoor nooit last van. Heb wel e.e.a. kunnen vinden met google toen maar dat hielp ook niet

Aangezien ik toch weer naar 32 bit wilde heb ik mijn hele systeem geformat / mbr gewist en nu werkt het weer perfect op mijn 32 bits Debian SID bak.

Dit is echt zo'n " " geval.
Met mijn HDD had ik verder geen problemen of zo btw..

EDIT: Het ging bij mij ook om een WD schijf
Deze: http://www.wdc.com/en/products/Products.asp?DriveID=38

[ Voor 15% gewijzigd door DeMoN op 29-12-2005 10:26 ]

[jurp5]

ik heb dit probleem ook sinds ik nieuw mobo + processor gekocht heb(asus k8v-mx + sempron 3000+).
Heb ook een WD hd

[deepbass909]

Misschien een hele domme vraag, maar je zegt dat je je schijf bootable hebt gemaakt met grub, maar heb je (c)fdisk de bootpartitie van je nieuwe schijf ook wel bootable gemaakt? Zo nee, dat gebruik je namelijk nog steeds de mbr van je oude, defecte schijf.

[zordaz]

deepbass909 schreef op donderdag 29 december 2005 @ 13:10:
Misschien een hele domme vraag, maar je zegt dat je je schijf bootable hebt gemaakt met grub, maar heb je (c)fdisk de bootpartitie van je nieuwe schijf ook wel bootable gemaakt? Zo nee, dat gebruik je namelijk nog steeds de mbr van je oude, defecte schijf.

Ik had de bootpartitie netjes bootable gemaakt (met fdisk). Daarnaast speelt de traagheid ook als de nieuwe schijf als enige aangesloten is, er is dus niet per ongeluk gebruik gemaakt van de verkeerde mbr lijkt me.

[ Voor 4% gewijzigd door zordaz op 29-12-2005 15:59 ]

[deepbass909]

Je nieuwe schijf wordt door de bios ook wel netjes als UDMA 100/133 gedetecteerd?

[SPee]

Heb je de schijf op dezelfde aanlsuiting als die oude aangesloten? Of op een nieuwe aansluiting.
Dit kan ook het probleem zijn, dat hij naar ide[0].device[0] kijkt, maar de schijf op ide[0].device[1] zit. (denk ik)

[Pastinakel]

Maakt master / slave / CS niets uit?

Vervolgens heb ik de inhoud van de oude schijf overgezet via cp -pR naar de nieuwe schijf (die op dat moment even als secundaire hdd in het systeem hing). Daarna heb ik de nieuwe schijf bootable gemaakt middels Grub-Install (via de MBR dus) en hem als primaire hdd aangesloten.

Dus als ik het goed begrijp had je grub geinstalleerd toen de nieuwe schijf niet de primaire bootschijf was. Misschien dat GRUB daardoor in de war is geraakt?

[ Voor 92% gewijzigd door Pastinakel op 29-12-2005 17:02 ]

[zordaz]

FF wat antwoorden:
- De BIOS detecteert beide schijven (de kapotte en de nieuwe) identiek, dus ook de goede snelheid (UDMA100 bij mij)

- Ik heb GRUB verschillende keren opnieuw geinstalleerd:
(1) De schijf aangesloten op IDE0 en later op IDE1;
(2) Als Master en later als Slave
(3) Terwijl de oude schijf wel en later niet aangesloten was.

Het zou kunnen dat ik ergens een combinatie vergeten ben, maar de mbr heb ik leeggemaakt toen de schijf als enige en als primair master device aangesloten was. Dat maakte dus ook niets uit.