jptechnical
newbie
Reged: 08/18/05
Posts: 40
|
|
I am setting up a new server to be a gateway. I have 2 18gb HDs in a software RAID and have been really pushing them hard trying to test some recovery scenarious (ghost and other backups) since I want this to be a permanent fixture.
I have done a ton of STF and googling and have successfully ghosted, restored and sanity checked the server.
The thing I am currently stuck on is an error in fdisk -l (output below) refereing to the partition table. From my research I am assuming that because the one drive is larger and because I told the "/" partiton to take all remaining space that the issue is that the raid volumes are difference sizes. But what I read said that this is not really a big deal, and I am not inclined to agree).
I have run "tune2fs -j /dev/XXX" and it says "The filesystem already has a journal." so I don't think that Ghost had turned it into ext2 (this was a long shot since I am using a really new corporate edition).
I was considering starting up in the rescue mode and recreating the journals, but my experience with rescue mode is then when I try to login I get a kernel panic about the VFS.
Should I blow this install away and do it again? I would rather do it right from the beginning and I am used to multiple installs on Win Servers until you 'get it right'. I like the piece of mind it anyone thinks it is neccessary.
Here are my outputs:
Code:
# fdisk -l
Disk /dev/hda: 20.0 GB, 20000000000 bytes 255 heads, 63 sectors/track, 2431 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System /dev/hda1 * 1 13 104391 fd Linux raid autodetect /dev/hda2 14 46 265072+ 82 Linux swap /dev/hda3 47 2431 19157512+ fd Linux raid autodetect
Disk /dev/hdc: 20.0 GB, 20020396032 bytes 255 heads, 63 sectors/track, 2434 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System /dev/hdc1 * 1 13 104391 fd Linux raid autodetect /dev/hdc2 14 46 265072+ 82 Linux swap /dev/hdc3 47 2434 19181610 fd Linux raid autodetect
Disk /dev/md0: 106 MB, 106823680 bytes 2 heads, 4 sectors/track, 26080 cylinders Units = cylinders of 8 * 512 = 4096 bytes
Disk /dev/md0 doesn't contain a valid partition table
Disk /dev/md1: 19.6 GB, 19617218560 bytes 2 heads, 4 sectors/track, 4789360 cylinders Units = cylinders of 8 * 512 = 4096 bytes
Disk /dev/md1 doesn't contain a valid partition table
Code:
# cat /proc/mdstat Personalities : [raid1] md1 : active raid1 hdc3[1] hda3[0] 19157440 blocks [2/2] [UU]
md0 : active raid1 hdc1[1] hda1[0] 104320 blocks [2/2] [UU]
unused devices: <none>
Code:
# cat /etc/fstab /dev/md1 / ext3 defaults 1 1 /dev/md0 /boot ext3 defaults 1 2 none /dev/pts devpts gid=5,mode=620 0 0 none /dev/shm tmpfs defaults 0 0 none /proc proc defaults 0 0 none /sys sysfs defaults 0 0 /dev/hdc2 swap swap defaults 0 0 /dev/hda2 swap swap defaults 0 0
|
Ilari
old hand
  
Reged: 04/23/05
Posts: 836
Loc: Singapore
|
|
Lot's of stuff there ...
1) What does "successfully ghosted, restored and ..." mean in practise? ie. how did you end up in such situation with your partition table complaints? (fdisk output looks ok.)
2) what is the output of # mount
3) With journals I understand ext3, ext2 is not journaled, but ext3 is. So, if your filesystem is already journaled(ext3), it cannot be converted to ext3 anymore.
|
whwelch
The PHP Oompa-Loompa.
   
Reged: 06/18/03
Posts: 2107
Loc: The Inventing Room
|
|
The articles I saw say "Ghost is not compatible with computers that use RAID."
You might need to run thru Disk Druid and rebuild the array, but do NOT format the partitions, then abort the install.
Edited by whwelch (11/25/05 10:23 AM)
|
jptechnical
newbie
Reged: 08/18/05
Posts: 40
|
|
You would be surprised with what Ghost is compatible with. I have used it for years and the only time it has failed me is with a drive with the max-blast overlay software on it.
Will it work with a software raid? Well, it seems to, yes. I ghosted it to a file and then back again onto the drive and it worked just fine. I did the sector copy so it copies the entire boot track instead of just referencing it.
The whole purpose of this exercise was to see if I could ghost it and depend on that ghost image. I ghost all of my successful installs for later restore and I use them quite alot. Using GhostPE (that is ghost corporate edition designed to run under windows or winpe, very, very expensive... but I got it through a non-profit) I imaged hda and then restored the image back to the drive. After doing so the raid was still working and the system worked.
Then I was doing some sanity checking and just trying out different scenarios and managed to kill the raid, but it had nothing to do with the Ghost. I added the hdc to grub and pulled hda and booted up just fine. Then I swapped the controllers on the drives so hda was on the 2nd controller and visa versa. I think this was a bad idea. After I booted with hdc on the primary controller (and no second drive) the raid was broken when I put the second drive back in.
It seems that you cannot swap drives between controllers. Again, I was just seeing what I could get away with. So after putting hdc on the primary controller and running it for a while, I shut it down and put hda back on the primary and hdc back on the secondary and started it up to see which drive it would boot from. Much to my surprise it bootedup with hdc in the raid and hda as just raid partitions but not associated with a raid.
So I tried to add them back in with raidhotadd but raidhotadd isnt in the path or in /sbin as another forum post (here) said it was. I still can't find it, so I assume you manage the raid some other way. But all of my searching google and the forums for rebuilding a software raid uses raidhotadd, wo how else are you supposed to do it?
After playing around with it I rebuilt the system from scratch (backed up my settings though). I deleted all partitions, recreated them with the / partition the exact same size as each other (instead of filling up remaining space on the drive). I installed it and it all worked great with the exception of the error message about the partition table. This is on a totally clean install and no poking around. The last time it was the same deal, the partitions were marked like that before I did any poking around. Code:
Disk /dev/md0 doesn't contain a valid partition table
So, does that error in fdisk -l mean anything important? Can I ignore it? Or should I treat it like it is broken?
Thanks.
Here is the output of the drives (clean install, partitions removed and recreated):
Code:
# fdisk -l
Disk /dev/hda: 20.0 GB, 20000000000 bytes 255 heads, 63 sectors/track, 2431 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System /dev/hda1 * 1 13 104391 fd Linux raid autodetect /dev/hda2 14 46 265072+ 82 Linux swap /dev/hda3 47 2430 19149480 fd Linux raid autodetect
Disk /dev/hdc: 20.0 GB, 20020396032 bytes 255 heads, 63 sectors/track, 2434 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System /dev/hdc1 * 1 13 104391 fd Linux raid autodetect /dev/hdc2 14 46 265072+ 82 Linux swap /dev/hdc3 47 2430 19149480 fd Linux raid autodetect
Disk /dev/md0: 19.6 GB, 19608961024 bytes 2 heads, 4 sectors/track, 4787344 cylinders Units = cylinders of 8 * 512 = 4096 bytes
Disk /dev/md0 doesn't contain a valid partition table
Disk /dev/md1: 106 MB, 106823680 bytes 2 heads, 4 sectors/track, 26080 cylinders Units = cylinders of 8 * 512 = 4096 bytes
Device Boot Start End Blocks Id System Code:
# cat /proc/mdstat Personalities : [raid1] md1 : active raid1 hdc1[1] hda1[0] 104320 blocks [2/2] [UU]
md0 : active raid1 hdc3[1] hda3[0] 19149376 blocks [2/2] [UU]
unused devices: <none> Code:
]# cat /etc/fstab /dev/md0 / ext3 defaults 1 1 /dev/md1 /boot ext3 defaults 1 2 none /dev/pts devpts gid=5,mode=620 0 0 none /dev/shm tmpfs defaults 0 0 none /proc proc defaults 0 0 none /sys sysfs defaults 0 0 /dev/hda2 swap swap defaults 0 0 /dev/hdc2 swap swap defaults 0 0 Code:
# mount /dev/md0 on / type ext3 (rw) none on /proc type proc (rw) none on /sys type sysfs (rw) none on /dev/pts type devpts (rw,gid=5,mode=620) usbfs on /proc/bus/usb type usbfs (rw) /dev/md1 on /boot type ext3 (rw) none on /dev/shm type tmpfs (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
|
jptechnical
newbie
Reged: 08/18/05
Posts: 40
|
|
Quote:
The articles I saw say "Ghost is not compatible with computers that use RAID."
You might need to run thru Disk Druid and rebuild the array, but do NOT format the partitions, then abort the install.
Sorry, I should have clarified. Ghost, in my experience, works with hardware raid as long as you put the image back on the same drive you took it off of (not so good for drive failure, but then that is what the HW raid is for).
I know I used ghost on a windows software raid and I am pretty sure it failed. I know for a fact that ghosting an nt4 software raid ends up in an unusable file of gibberish. But then windows software raid is a steaming pile of you know what as far as I am concerned.
It looks to me like the linux raid is actually very simple. The raid manager assigns the drives to the raid and mounts the volume, this is all during boot time I think. I am sure there is some voodoo going on in the mbr and fat, but It seems like it is no where near as potentially destructive as the windows software raid variety.
The articles about ghosting I found pertained to ext3 and what version of ghost will work with it (older versions reading ext3 as ext2 and then restoring it as ext2). So, I figured since I have a newer edition of ghost I would just give it a try on the linux software raid. I ghosted it to image (when in doubt: sector copy) and then restored the image and booted up the machine and it acted as if nothing had ever happened.
Far be it from me to contradict what Symantec says, but it worked for me in this instance. At the very least, it did backup all the data, even if the mbr is toast the data is saved.
|
track
Pooh-Bah
  
Reged: 06/24/05
Posts: 2290
Loc: Sydney, Australia
|
|
Quote:
So I tried to add them back in with raidhotadd but raidhotadd isnt in the path
mdadm is the tool to use...
Code:
[root@azza1 ~]# mdadm --manage --help Usage: mdadm arraydevice options component devices... This usage is for managing the component devices within an array. The --manage option is not needed and is assumed if the first argument is a device name or a management option. The first device listed will be taken to be an md array device, and subsequent devices are (potential) components of that array. Options that are valid with management mode are: --add -a : hotadd subsequent devices to the array --remove -r : remove subsequent devices, which must not be active --fail -f : mark subsequent devices a faulty --set-faulty : same as --fail --run -R : start a partially built array --stop -S : deactivate array, releasing all resources --readonly -o : mark array as readonly --readwrite -w : mark array as readwrite [root@azza1 ~]#
-------------------- http://kirstie.poweredbyclear.com
|
trackguy
journeyman
Reged: 06/14/04
Posts: 86
Loc: Northwest UK
|
|
If it helps, my hdc has the same entry:
Code:
[root@lurch]# fdisk -l
Disk /dev/hda: 81.9 GB, 81964302336 bytes 255 heads, 63 sectors/track, 9964 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System /dev/hda1 * 1 13 104391 83 Linux /dev/hda2 14 1288 10241437+ 82 Linux swap /dev/hda3 1289 9964 69689970 83 Linux
Disk /dev/hdc: 250.0 GB, 250059350016 bytes 255 heads, 63 sectors/track, 30401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes
Disk /dev/hdc doesn't contain a valid partition table
... and mounts, reads, writes and unmounts quite happily. My vote would be: so, no partition table - so?
-------------------- Home:
CC home 3.1
AMD Duron 900, 1Gb Ram, 80Gb hda, 114Gb md0 (raid 5)
mods: remote power switch for attic deployment
Work
|
trackguy
journeyman
Reged: 06/14/04
Posts: 86
Loc: Northwest UK
|
|
Bit of digging later, and it transpires all that I had failed to do was actually tell fdisk to write the partition table using the w(rite) command:
Code:
[root@lurch log]# fdisk /dev/hdc Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
*edit*
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)
Command (m for help): p
Disk /dev/hdc: 250.0 GB, 250059350016 bytes 255 heads, 63 sectors/track, 30401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
Command (m for help): w The partition table has been altered!
Calling ioctl() to re-read partition table. Syncing disks.
[root@lurch log]# fdisk -l
Disk /dev/hda: 81.9 GB, 81964302336 bytes 255 heads, 63 sectors/track, 9964 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System /dev/hda1 * 1 13 104391 83 Linux /dev/hda2 14 1288 10241437+ 82 Linux swap /dev/hda3 1289 9964 69689970 83 Linux
Disk /dev/hdc: 250.0 GB, 250059350016 bytes 255 heads, 63 sectors/track, 30401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
= end of warning!
-------------------- Home:
CC home 3.1
AMD Duron 900, 1Gb Ram, 80Gb hda, 114Gb md0 (raid 5)
mods: remote power switch for attic deployment
Work
|
|
0 registered and 1 anonymous users are browsing this forum.
Moderator: pointclark
Print Topic
|
Forum Permissions
You cannot start new topics
You cannot reply to topics
HTML is disabled
UBBCode is enabled
|
Rating:
Topic views: 16170
|
|
|
|
|
|
Powered by UBB.threads™ 6.5.5
|