Jason Andresen
2005-Apr-25 07:20 UTC
gvinum causing kernel panic when referencing nonexistent partition
I have a machine that I tried upgrading from 4-STABLE to 5-STABLE. In the process I lost one of the disks and had to replace it. The problem is, that gvinum "knows" about the disk, but I can't seem to either create the media volume (kernel panic) nor erase that entry from the vinum list (kernel panic). I also can't seem to get resetconfig to work--it doesn't seem to be defined in gvinum :(. All I need to do is clear media.p0.s3 out of this and I think I'll be able to recreate the volume I need (including grabbing the new disk): gvinum -> list 9 drives: D media1 State: up /dev/ad6s1 A: 76316/76316 MB (100%) D media3 State: up /dev/ad8s1 A: 76316/76316 MB (100%) D media9 State: up /dev/ad10s1 A: 76316/76316 MB (100%) D media2 State: up /dev/ad12s1 A: 76316/76316 MB (100%) D mediaa State: up /dev/ad14s1 A: 76316/76316 MB (100%) D media5 State: up /dev/ad16s1 A: 76316/76316 MB (100%) D media6 State: up /dev/ad18s1 A: 76316/76316 MB (100%) D media8 State: up /dev/ad20s1 A: 76316/76316 MB (100%) D media7 State: up /dev/ad22s1 A: 76316/76316 MB (100%) 1 volume: V media State: up Plexes: 0 Size: 0 B 1 plex: P media.p0 R5 State: down Subdisks: 0 Size: 0 B 1 subdisk: S media.p0.s3 State: up D: media4 Size: 74 GB Is there maybe a special place on each drive I could dd /dev/zero to clear out all of the vinum information? I tried clobbering the vinum slices on every drive and newfsing them as individual filesystems, but that didn't seem to do the trick.
Matthias Schündehütte
2005-Apr-26 07:53 UTC
gvinum causing kernel panic when referencing nonexistent partition
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Jason, Am 25.04.2005 um 16:19 schrieb Jason Andresen:> [...] > Is there maybe a special place on each drive I could dd /dev/zero to > clear out all of the vinum information? I tried clobbering the vinum > slices on every drive and newfsing them as individual filesystems, but > that didn't seem to do the trick.Well, I ran into this as well... it's a bit weird to solve this issue. The gvinum-infos are on sector #8 ff. of the drive-slices. In your case 'ad{x}s1'. If you have a valid backup of your data (which should be no problem to get as a RAID5-plex should survive *one* faulty disk) I would recommend to erase all sectors #8-16 of all gvinum-drives as your missing drive is noted in all of these sectors. Then you have to rebuild the whole gvinum stuff from scratch. If that's not possible, do a 'dd if=/dev/ad6s1 of=ad6s1.sec bs=512 count=16' and look at the file 'ad6s1.sec' with your favorite hex-editor. Or better: make a copy of that file and look at the copy :-) You have to do this for all your gvinum-drives. The gvinum meta-data starts with the string 'IN VINO', IIRC at sector #8, that is 4096 bytes offset in the file. The metadata follows this 'magic' string and is plain ascii. So, now you can either remove all references to 'media4' or perhaps you try to rename all occurences of 'mediaa' to 'media4' and see what happens. The structure of the metadata is defined in /sys/geom/vinum/geom_vinum_var.h - look at this file first! I managed to repair my gvinum installation this way but there's no guarantee, you do it on your own risk! Please contact le@freebsd.org, perhaps he is willing to assist you during that operation. He is the 'father' of gvinum so his advice is sure better than mine... Good luck - matthias - -- Ciao/BSD - Matthias Matthias Schuendehuette <msch [at] snafu.de>, Berlin (Germany) PGP-Key at <pgp.mit.edu> and <wwwkeys.de.pgp.net> ID: 0xDDFB0A5F -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCblWDf1BNcN37Cl8RAkHiAJ9DIuoud82AOsrQ8fouLVh4O0J+UQCeLhEn Xfbb2/sk4c6vBwzil7CGi3g=4NCN -----END PGP SIGNATURE-----