Met dd gekloonde schijf wil niet juist booten.

[harry64]

Ik probeer een onbekende werkende linux installatie te kopiëren vanaf een QUANTUM FIREBALL540a (500MB) harde schijf, deze bestaat uit 2 partities en ongebruikte ruimte.

Met dd=if/dev/hda of=/dev/hdb krijg ik een ogenschijnlijk exacte kopie, maar deze is niet bootable. Wanneer ik deze in het systeem plaats en als bootschijf gebruik krijg ik de melding mA en gebeurd er verder niets.

Met dd=if/dev/hda of=/dev/hdb bs=512 conv=notrunc,noerror krijg ik eenzelfde kopie. Deze heb ik gecontroleerd dmv van een md5 checksum en deze zijn identiek. Bij het booten vanaf deze schijf krijg ik nadat het os ongeveer 3 seconden aan het laden is de volgende melding.

kernel panic:VFS:Unable to mount root fs on 03:02

Als doel harde schijf heb ik een Maxtor 7850AV (800MB) en een Fujitsu MPD3084AT (8GB) gebruikt.

Ik heb bijna alle mogelijke oplossingen uitgeprobeerd maar het wil niet lukken, ik ga zelf denken dat het misschien in het type harde schijf kan zitten, iemand die me misschien verder kan helpen?

Mocht er belangrijke info missen dan plaats ik dit zo snel mogelijk.

[blaataaps]

code:

kernel panic:VFS:Unable to mount root fs on 03:02

Werkt het wel als je handmatig de juiste root-partitie meegeeft? Als hij nog van hda probeert te lezen, en de schijf heet inmiddels hdb werkt dat niet (als je nog geen UUID gebruikt ten minste, maar ik neem aan van niet aan de melding te zien).

[harry64]

blaataaps schreef op maandag 29 maart 2010 @ 20:15:

code:

kernel panic:VFS:Unable to mount root fs on 03:02

Werkt het wel als je handmatig de juiste root-partitie meegeeft? Als hij nog van hda probeert te lezen, en de schijf heet inmiddels hdb werkt dat niet (als je nog geen UUID gebruikt ten minste, maar ik neem aan van niet aan de melding te zien).

Ik weet niet of ik daarmee de mist in ga maar als ik de harddisk kloon en deze als master enkel in het systeem plaats dan wordt dit toch automatisch hda?

[MartinMeijerink]

misschien ff de bootloader opnieuw installeren, dus ff booten van cd, dan je schijf mounten in een of ander mapje, deze chrooten, en dan lilo intikken:

code:

mkdir /maxtor
mount /dev/hda1 /maxtor
chroot /maxtor
lilo
grub-install /dev/hda

(hierbij ga ik er ff vanuit dat /dev/hda1 je filesystem-partitie is, en /dev/hda2 je swappartitie)
Let op: regel 4 en 5 niet allebei uitvoeren, maar alleen 4 doen als je lilo gebruikt en alleen 5 als je grub gebruikt.
Als je niet weet welke bootloader wordt gebruikt, kun je het na 3 ff checken welke gebruikt wordt door door ls -l /etc/lilo.conf en ls -l /etc/grub* te doen...

PS: ja, hij wordt automatisch /dev/hda!

[ Voor 3% gewijzigd door MartinMeijerink op 29-03-2010 21:25 . Reden: ja, hij wordt automatisch /dev/hda! :) ]

[Joepho]

Wat nu vaak gebeurt is dat ze in plaats van /dev/hda de UUID gebruiken om de hardeschijf aan te wijzen, kijk dus even in je udevd regels, fstab en je menu.lst of dat niet het geval is... is dat zo dan zet je er gewoon /dev/hda neer.

[Theimon]

Wat nu als je probeert alle bestanden over te zetten met "cp -a" (zonder quotes) in plaats van dd? Ik had dit zelf namelijk een keer toen ik een bestaande installatie wilde overzetten naar een nieuwe schijf. Dat ging van een 74GB naar een 300GB schijf. Op een of andere manier leek het wel of dd ook de geometry gegevens van de oude schijf overnam, waardoor de kernel de nieuwe schijf niet goed herkende.

[Mijzelf]

Schijven van 500MB gebruiken een CHS adressering. Als in de partitietabel ook deze adressering wordt gebruikt, kun je deze niet 1op1 kopieren naar een schijf met een andere CHS indeling.

Workaround: maak de partitietabel met fdisk, en dd de partities.

[Joepho]

wat ook werkt:

booten met een livecd

tar -xvzf partitie.tar.gz /mnt/partitie

en dan de tar extracten op de nieuwe schijf.

[harry64]

Eindelijk eens tijd om verder te kijken maar zover nog geen succes.

MartinMeijerink schreef op maandag 29 maart 2010 @ 21:23:
misschien ff de bootloader opnieuw installeren, dus ff booten van cd, dan je schijf mounten in een of ander mapje, deze chrooten, en dan lilo intikken:

code:

mkdir /maxtor
mount /dev/hda1 /maxtor
chroot /maxtor
lilo
grub-install /dev/hda

(hierbij ga ik er ff vanuit dat /dev/hda1 je filesystem-partitie is, en /dev/hda2 je swappartitie)
Let op: regel 4 en 5 niet allebei uitvoeren, maar alleen 4 doen als je lilo gebruikt en alleen 5 als je grub gebruikt.
Als je niet weet welke bootloader wordt gebruikt, kun je het na 3 ff checken welke gebruikt wordt door door ls -l /etc/lilo.conf en ls -l /etc/grub* te doen...

PS: ja, hij wordt automatisch /dev/hda!

Er wordt iig lilo gebruikt. Alle commandos gaan goed tot de laatste, moest tussendoor wel fsck uitvoeren.

Theimon schreef op dinsdag 30 maart 2010 @ 14:12:
Wat nu als je probeert alle bestanden over te zetten met "cp -a" (zonder quotes) in plaats van dd? Ik had dit zelf namelijk een keer toen ik een bestaande installatie wilde overzetten naar een nieuwe schijf. Dat ging van een 74GB naar een 300GB schijf. Op een of andere manier leek het wel of dd ook de geometry gegevens van de oude schijf overnam, waardoor de kernel de nieuwe schijf niet goed herkende.

Helaas geen succes, Disk boot failure bij het booten, lili.conf staat goed.

Mijzelf schreef op dinsdag 30 maart 2010 @ 14:32:
Schijven van 500MB gebruiken een CHS adressering. Als in de partitietabel ook deze adressering wordt gebruikt, kun je deze niet 1op1 kopieren naar een schijf met een andere CHS indeling.

Workaround: maak de partitietabel met fdisk, en dd de partities.

Dezelfde melding, Disk boot failure

Joepho schreef op dinsdag 30 maart 2010 @ 11:56:
Wat nu vaak gebeurt is dat ze in plaats van /dev/hda de UUID gebruiken om de hardeschijf aan te wijzen, kijk dus even in je udevd regels, fstab en je menu.lst of dat niet het geval is... is dat zo dan zet je er gewoon /dev/hda neer.

Ik zal deze nog een keertje nakijken.

Joepho schreef op dinsdag 30 maart 2010 @ 17:06:
wat ook werkt:

booten met een livecd

tar -xvzf partitie.tar.gz /mnt/partitie

en dan de tar extracten op de nieuwe schijf.

Dit zal ik straks een proberen.

[harry64]

Joepho schreef op dinsdag 30 maart 2010 @ 11:56:
Wat nu vaak gebeurt is dat ze in plaats van /dev/hda de UUID gebruiken om de hardeschijf aan te wijzen, kijk dus even in je udevd regels, fstab en je menu.lst of dat niet het geval is... is dat zo dan zet je er gewoon /dev/hda neer.

Mijn fstab

code:

/dev/hda1      /              ext2      defaults   1   1
/dev/hda2      /target      ext2      defaults,noauto   1   1
none                            proc      defaults   1   1

Mijn lilo.conf

code:

# LILO configuration file
boot = /dev/hda
vga = normal     # force sane state
image = /kernel
  root = /dev/hda1
  label = loading
  read-only
image = /target/kernel
  root = /dev/hda2
  label = 2
  read-only
# Linux bootable partition config ends

De udevd(udev?) regels en de menu.lst kan ik niet vinden.

[Mijzelf]

Is het logisch dat hij van /dev/hda2 wil booten? De melding "Unable to mount root fs on 03:02" wijst daarop, major 3 minor 2. Het schijnt te helpen bij dit soort vage mount problemen om de major,minor in lilo mee te geven, ipv de devicenaam.
Oftewel probeer in lilo.conf eens
root = 0302
ipv
root = /dev/hda2

[harry64]

Mijzelf schreef op maandag 05 april 2010 @ 19:07:
Is het logisch dat hij van /dev/hda2 wil booten? De melding "Unable to mount root fs on 03:02" wijst daarop, major 3 minor 2. Het schijnt te helpen bij dit soort vage mount problemen om de major,minor in lilo mee te geven, ipv de devicenaam.
Oftewel probeer in lilo.conf eens
root = 0302
ipv
root = /dev/hda2

Hij start op, maar ik weet niet of het helemaal juist is vanwege de vreemde resolutie die ik op deze manier krijg. De etc/lilo.conf verwijst naar boot/lilo11.conf hier staan er meerdere oa lilo22.conf. Ik zal eens gaan testen.