SEO

Hello,

I have a question about using linux volume groups. I'm using a Fedora 4
setup. I installed fedora 4 to my /dev/sda using more-or-less the
default options. This created a /dev/sda1 /boot partition, and a
VolGroup00 in /dev/sda2.

I want to system to be able to tolerate a failure of /dev/sda (i.e. if
sda fails, I can reboot from a backup image on sdb), so I created a
second /boot on /dev/sdb1 and a second volume group, VolGroupDup on
/dev/sdb2.

I used dd to copy the contents of /sda1 into /sdb1, thus duplicating
the boot partition. I created logical volumes in VolGroupDup that were
identical in structure to VolGroup00. I then used dd to copy the
contents of /VolGroup00/LogVol00 to /VolGroupDup/LogVol00. This created
a copy of the root partition.

I test-mounted the partitions to verify the copies were correct. I
edited the /etc/grub.conf and /etc/fstab in the duplicated file systems
to reference VolGroupDup instead of VolGroup00.

I then disconnected sda and rebooted. Grub starts and attempts to boot,
but Fedora fails with a message "Unable to Find VolGroup00", followed
by a couple of messages about being unable to open a console, some
failures of the dup() function and a kernel panic.

During the boot, I can see that grub is passing
"root=/dev/VolGroupDup/LogVol00". So grub is passing the right boot
parameter, but it looks to me like the kernel is still trying to use
VolGroup00.

Any ideas what went wrong with my approach? Is there a better way? In
the pre-LVM days I used to be able to simply 'dd' a couple of
partitions, but with these new LVM groups things seem pretty
complicated.

Thanks, and I hope I've made at least a little sense in my description
above.

Scott <smbaker@gmail.com> wrote:
> I have a question about using linux volume groups. I'm using a Fedora 4
> setup. I installed fedora 4 to my /dev/sda using more-or-less the
> default options. This created a /dev/sda1 /boot partition, and a
> VolGroup00 in /dev/sda2.
>
> I want to system to be able to tolerate a failure of /dev/sda (i.e. if
> sda fails, I can reboot from a backup image on sdb), so I created a
> second /boot on /dev/sdb1 and a second volume group, VolGroupDup on
> /dev/sdb2.
>
> I used dd to copy the contents of /sda1 into /sdb1, thus duplicating
> the boot partition. I created logical volumes in VolGroupDup that were
> identical in structure to VolGroup00. I then used dd to copy the
> contents of /VolGroup00/LogVol00 to /VolGroupDup/LogVol00. This created
> a copy of the root partition.
>
> I test-mounted the partitions to verify the copies were correct. I
> edited the /etc/grub.conf and /etc/fstab in the duplicated file systems
> to reference VolGroupDup instead of VolGroup00.
>
> I then disconnected sda and rebooted. Grub starts and attempts to boot,
> but Fedora fails with a message "Unable to Find VolGroup00", followed
> by a couple of messages about being unable to open a console, some
> failures of the dup() function and a kernel panic.
>
> During the boot, I can see that grub is passing
> "root=/dev/VolGroupDup/LogVol00". So grub is passing the right boot
> parameter, but it looks to me like the kernel is still trying to use
> VolGroup00.
>
> Any ideas what went wrong with my approach? Is there a better way? In
> the pre-LVM days I used to be able to simply 'dd' a couple of
> partitions, but with these new LVM groups things seem pretty
> complicated.
>
> Thanks, and I hope I've made at least a little sense in my description
> above.

You say that you 'want to system to be able to tolerate a failure of
/dev/sda'.

I think that your approach will not help you there - even if you get it
running, the copy of your system on the second hard disk will not change
if you change data on the first hard disk.
So you would have to repeat your copy procedure ever so often to keep the
second hard disk sort of synchronized. How cumbersome!

I would suggest the following approach: You use a hardware or software raid
to mirror the two hard disks and create your /boot and your volume group
on top of that.

If you cannot do that for whatever reason, I would suggest that you take
frequent backups (e.g., on CDROM) rather than what you plan to do. It will
protect you just as well, and it is more simple.

Yours,
Laurenz Albe

In comp.os.linux.setup Scott <smbaker@gmail.com>:
> Hello,

> I have a question about using linux volume groups. I'm using a Fedora 4
> setup. I installed fedora 4 to my /dev/sda using more-or-less the
> default options. This created a /dev/sda1 /boot partition, and a
> VolGroup00 in /dev/sda2.

> I want to system to be able to tolerate a failure of /dev/sda (i.e. if
> sda fails, I can reboot from a backup image on sdb), so I created a
> second /boot on /dev/sdb1 and a second volume group, VolGroupDup on
> /dev/sdb2.

You want to use softraid on the disks to get full redundancy, at
least RHEL can be setup in full raid 1 and boot from both hds.

See software raid howto (www.tldp.org) for more info.

[..]

BTW
Please read this before posting anything else:

http://cfaj.freeshell.org/google

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 39: terrorist activities

"Michael Heiming" <michael+USENET@www.heiming.de> wrote in message
newssjs93-ig.ln1@news.heiming.de...
> In comp.os.linux.setup Scott <smbaker@gmail.com>:
>> Hello,
>
>> I have a question about using linux volume groups. I'm using a Fedora 4
>> setup. I installed fedora 4 to my /dev/sda using more-or-less the
>> default options. This created a /dev/sda1 /boot partition, and a
>> VolGroup00 in /dev/sda2.
>
>> I want to system to be able to tolerate a failure of /dev/sda (i.e. if
>> sda fails, I can reboot from a backup image on sdb), so I created a
>> second /boot on /dev/sdb1 and a second volume group, VolGroupDup on
>> /dev/sdb2.
>
> You want to use softraid on the disks to get full redundancy, at
> least RHEL can be setup in full raid 1 and boot from both hds.
>
> See software raid howto (www.tldp.org) for more info.

This is a common approach: I dislike it because I find the "rm -rf /"
accident to be a far more common way to mess up a system than hardware
failures.

Instead I find it very helpful to do something like this:

[ Build partitions on second disk with necessary partition names changed
for mirrored disk. ]

mount /dev/[spare-root-partition] /mnt/secondroot
rsync -aHx -delete / /mnt/secondroot
remount -o ro /mnt/secondroot

[ Repeat as necessary for other partitions. ]
[ Set up a cron job to do the mirroring nightly during idle time. ]
[ Set up a second cron job for dumping live databases to local files
first, so those get copied correctly too. ]

That leaves your old filesystem copied, read-only, in an immediately
accessible location for recovering lost files. You may lose a day's recent
updates, but you have a copy of the far more likely lost files from
yesterday.