I am building three identical systems. Well they will have different host names, and with time the software setups will drift. But at install time they are identical.
Is there some way, (with dd I might guess) to do a hardare level copy?
All three drives are Hitachi DK23DA-40F (40Gb). Supposedly factory reconditioned (they are in sealed bags with a drive sticker stating: "Refurbished to Hitachi Global Storage Technologies Specifications").
I would want to copy the paritition table and my 3 partitions (/boot, swap, LVM (/ and /home ext3 partitions in the LVM)) and all their contents.
Thing is I only have one USB drive enclosure so I would be running from the drive I want to copy from.
I would hope this is faster than 2 more installs.
On Thursday July 3 2008, Robert Moskowitz wrote:
I am building three identical systems. Well they will have different host names, and with time the software setups will drift. But at install time they are identical.
Is there some way, (with dd I might guess) to do a hardare level copy?
All three drives are Hitachi DK23DA-40F (40Gb). Supposedly factory reconditioned (they are in sealed bags with a drive sticker stating: "Refurbished to Hitachi Global Storage Technologies Specifications").
I would want to copy the paritition table and my 3 partitions (/boot, swap, LVM (/ and /home ext3 partitions in the LVM)) and all their contents.
Thing is I only have one USB drive enclosure so I would be running from the drive I want to copy from.
I would hope this is faster than 2 more installs.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Kickstart the system 2 & 3 after the install on #1
Robert Moskowitz wrote:
I am building three identical systems. Well they will have different host names, and with time the software setups will drift. But at install time they are identical.
Is there some way, (with dd I might guess) to do a hardare level copy?
All three drives are Hitachi DK23DA-40F (40Gb). Supposedly factory reconditioned (they are in sealed bags with a drive sticker stating: "Refurbished to Hitachi Global Storage Technologies Specifications").
I would want to copy the paritition table and my 3 partitions (/boot, swap, LVM (/ and /home ext3 partitions in the LVM)) and all their contents.
Thing is I only have one USB drive enclosure so I would be running from the drive I want to copy from.
Boot from the install CD with 'linux rescue' at the boot prompt so you can do the dd copy with none of the partitions mounted.
On Thu, 2008-07-03 at 21:11 -0400, Robert Moskowitz wrote:
<snip>
Is there some way, (with dd I might guess) to do a hardare level copy?
I've seen many posts on this list that recommend Clonezilla for this sort of thing. You run off CD and it is said to be faster than DD because it is hardware aware (forgive the alliteration) and so only copies actual data.
I've not had occassion to use it though.
<snip>
I would want to copy the paritition table and my 3 partitions (/boot, swap, LVM (/ and /home ext3 partitions in the LVM)) and all their contents.
Thing is I only have one USB drive enclosure so I would be running from the drive I want to copy from.
I would hope this is faster than 2 more installs.
<snip sig stuff>
HTH
How about installing one, and using the anaconda-ks that is generated to install the other two?
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of William L. Maltby Sent: Friday, July 04, 2008 4:23 AM To: CentOS mailing list Subject: Re: [CentOS] Three Identical systems - short cut to setting up thedrives?
On Thu, 2008-07-03 at 21:11 -0400, Robert Moskowitz wrote:
<snip>
Is there some way, (with dd I might guess) to do a hardare level copy?
I've seen many posts on this list that recommend Clonezilla for this sort of thing. You run off CD and it is said to be faster than DD because it is hardware aware (forgive the alliteration) and so only copies actual data.
I've not had occassion to use it though.
<snip>
I would want to copy the paritition table and my 3 partitions (/boot, swap, LVM (/ and /home ext3 partitions in the LVM)) and all their
contents.
Thing is I only have one USB drive enclosure so I would be running
from
the drive I want to copy from.
I would hope this is faster than 2 more installs.
<snip sig stuff>
HTH
Daniel_Curry@Dell.com wrote:
How about installing one, and using the anaconda-ks that is generated to install the other two?
That was my first plan. But that just saves the time going through the install selection and getting the same stuff installed.
I would still have to do the yum update (though there was the post about how to include the update repo in a kickstart install. Then I have the powerk8 kernel patch to install (these are old systems with new drives), followed by a number of config file changes (setting up IPtables, changing SSHD, configing VNC, etc). All that is a lot to work out for a kickstart install.
The pointer of running dd fromLinux Rescue sounded good. But Clonezilla calls for some real investigation.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of William L. Maltby Sent: Friday, July 04, 2008 4:23 AM To: CentOS mailing list Subject: Re: [CentOS] Three Identical systems - short cut to setting up thedrives?
On Thu, 2008-07-03 at 21:11 -0400, Robert Moskowitz wrote:
<snip>
Is there some way, (with dd I might guess) to do a hardare level copy?
I've seen many posts on this list that recommend Clonezilla for this sort of thing. You run off CD and it is said to be faster than DD because it is hardware aware (forgive the alliteration) and so only copies actual data.
I've not had occassion to use it though.
<snip>
I would want to copy the paritition table and my 3 partitions (/boot, swap, LVM (/ and /home ext3 partitions in the LVM)) and all their
contents.
Thing is I only have one USB drive enclosure so I would be running
from
the drive I want to copy from.
I would hope this is faster than 2 more installs.
<snip sig stuff>
HTH
Robert Moskowitz wrote:
Daniel_Curry@Dell.com wrote:
How about installing one, and using the anaconda-ks that is generated to install the other two?
That was my first plan. But that just saves the time going through the install selection and getting the same stuff installed.
I would still have to do the yum update (though there was the post about how to include the update repo in a kickstart install. Then I have the powerk8 kernel patch to install (these are old systems with new drives), followed by a number of config file changes (setting up IPtables, changing SSHD, configing VNC, etc). All that is a lot to work out for a kickstart install.
The pointer of running dd fromLinux Rescue sounded good. But Clonezilla calls for some real investigation.
have you tried using Norton Ghost? I've used this many times and works nicely replicating complete systems. Upon boot though, unless the hardware/chipsets are identical as well, you'll go through some minor gyrations while kudzu removes and adds drivers for the systems.
Understood. However, the investment in ks, now, may reap greater dividends in the future. My opinion, only.
Daniel
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Robert Moskowitz Sent: Friday, July 04, 2008 6:35 AM To: CentOS mailing list Subject: Re: [CentOS] Three Identical systems - short cut to setting upthedrives?
Daniel_Curry@Dell.com wrote:
How about installing one, and using the anaconda-ks that is generated
to
install the other two?
That was my first plan. But that just saves the time going through the install selection and getting the same stuff installed.
I would still have to do the yum update (though there was the post about
how to include the update repo in a kickstart install. Then I have the powerk8 kernel patch to install (these are old systems with new drives),
followed by a number of config file changes (setting up IPtables, changing SSHD, configing VNC, etc). All that is a lot to work out for a kickstart install.
The pointer of running dd fromLinux Rescue sounded good. But Clonezilla calls for some real investigation.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of William L. Maltby Sent: Friday, July 04, 2008 4:23 AM To: CentOS mailing list Subject: Re: [CentOS] Three Identical systems - short cut to setting
up
thedrives?
On Thu, 2008-07-03 at 21:11 -0400, Robert Moskowitz wrote:
<snip>
Is there some way, (with dd I might guess) to do a hardare level
copy?
I've seen many posts on this list that recommend Clonezilla for this sort of thing. You run off CD and it is said to be faster than DD because it is hardware aware (forgive the alliteration) and so only copies actual data.
I've not had occassion to use it though.
<snip>
I would want to copy the paritition table and my 3 partitions (/boot,
swap, LVM (/ and /home ext3 partitions in the LVM)) and all their
contents.
Thing is I only have one USB drive enclosure so I would be running
from
the drive I want to copy from.
I would hope this is faster than 2 more installs.
<snip sig stuff>
HTH
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Daniel_Curry@Dell.com wrote:
Understood. However, the investment in ks, now, may reap greater dividends in the future. My opinion, only.
Unless, of course, you'd like to copy a windows image or some other distribution that doesn't use kickstart. Clonezilla is pretty agnostic about the contents that it clones.
Daniel_Curry@Dell.com wrote:
Understood. However, the investment in ks, now, may reap greater dividends in the future. My opinion, only.
Given the reminder about LVM volume names, I am back to planning on doing the 3rd drive with ks.
Daniel
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Robert Moskowitz Sent: Friday, July 04, 2008 6:35 AM To: CentOS mailing list Subject: Re: [CentOS] Three Identical systems - short cut to setting upthedrives?
Daniel_Curry@Dell.com wrote:
How about installing one, and using the anaconda-ks that is generated
to
install the other two?
That was my first plan. But that just saves the time going through the install selection and getting the same stuff installed.
I would still have to do the yum update (though there was the post about
how to include the update repo in a kickstart install. Then I have the powerk8 kernel patch to install (these are old systems with new drives),
followed by a number of config file changes (setting up IPtables, changing SSHD, configing VNC, etc). All that is a lot to work out for a kickstart install.
The pointer of running dd fromLinux Rescue sounded good. But Clonezilla calls for some real investigation.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of William L. Maltby Sent: Friday, July 04, 2008 4:23 AM To: CentOS mailing list Subject: Re: [CentOS] Three Identical systems - short cut to setting
up
thedrives?
On Thu, 2008-07-03 at 21:11 -0400, Robert Moskowitz wrote:
<snip>
Is there some way, (with dd I might guess) to do a hardare level
copy?
I've seen many posts on this list that recommend Clonezilla for this sort of thing. You run off CD and it is said to be faster than DD because it is hardware aware (forgive the alliteration) and so only copies actual data.
I've not had occassion to use it though.
<snip>
I would want to copy the paritition table and my 3 partitions (/boot,
swap, LVM (/ and /home ext3 partitions in the LVM)) and all their
contents.
Thing is I only have one USB drive enclosure so I would be running
from
the drive I want to copy from.
I would hope this is faster than 2 more installs.
<snip sig stuff>
HTH
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Fri, 2008-07-04 at 05:22 -0400, William L. Maltby wrote:
On Thu, 2008-07-03 at 21:11 -0400, Robert Moskowitz wrote:
<snip>
<snip>
because it is hardware aware (forgive the alliteration) and so only
s/hardware/file system/ # I *knew* I needed coffee first.
copies actual data.
<snip>
William L. Maltby wrote:
On Thu, 2008-07-03 at 21:11 -0400, Robert Moskowitz wrote:
<snip>
Is there some way, (with dd I might guess) to do a hardare level copy?
I've seen many posts on this list that recommend Clonezilla for this sort of thing. You run off CD and it is said to be faster than DD because it is hardware aware (forgive the alliteration) and so only copies actual data.
Now this sounds of real interest. Off to google Clonezilla. Thanks.
I've not had occassion to use it though.
<snip>
I would want to copy the paritition table and my 3 partitions (/boot, swap, LVM (/ and /home ext3 partitions in the LVM)) and all their contents.
Thing is I only have one USB drive enclosure so I would be running from the drive I want to copy from.
I would hope this is faster than 2 more installs.
<snip sig stuff>
HTH
Robert Moskowitz wrote:
Is there some way, (with dd I might guess) to do a hardare level copy?
I've seen many posts on this list that recommend Clonezilla for this sort of thing. You run off CD and it is said to be faster than DD because it is hardware aware (forgive the alliteration) and so only copies actual data.
Now this sounds of real interest. Off to google Clonezilla. Thanks.
Clonezilla-live is the one you want. It is a bootable iso and if you have a place on the network to hold the image you won't have to get the drives connected to the same machine.
Robert Moskowitz wrote:
I am building three identical systems. Well they will have different host names, and with time the software setups will drift. But at install time they are identical.
..snip...
I would hope this is faster than 2 more installs.
its not
do the install over the network from a http server, given the same network, it would be many times faster to do the 2nd and 3rd install using the ks.cfg generated from the 1st one ( as Terry Polzin already pointed out ).
It will be many times faster than doing DD images of entire drives. eg. in my case here, i can provision a new machine in 2 min and 43 seconds for a base+core minimal centos-5 install. installing over http from a machine on a GiB/sec link and installing to a 2 disk raid-1
- KB
Karanbir Singh wrote:
Robert Moskowitz wrote:
I am building three identical systems. Well they will have different host names, and with time the software setups will drift. But at install time they are identical.
..snip...
I would hope this is faster than 2 more installs.
its not
do the install over the network from a http server, given the same network, it would be many times faster to do the 2nd and 3rd install using the ks.cfg generated from the 1st one ( as Terry Polzin already pointed out ).
It will be many times faster than doing DD images of entire drives. eg. in my case here, i can provision a new machine in 2 min and 43 seconds for a base+core minimal centos-5 install. installing over http from a machine on a GiB/sec link and installing to a 2 disk raid-1
There is much good to say about using kickstart method than learning a new approach like Clonezilla. I have not used kickstart since Centos 4.something, so I have no good notes and will have to dig again. But this is pretty much a one-time clone and Clonezilla does not seem to set up the partitioning info on the new drive so that would be one more thing to learn.
So I take the anaconda-ks.cfg file, add stuff so it will boot off the network and use the update repo as well as the base. Then rediscover the command to run linux from a kickstart file on a diskette.
Piece of CAKE!
:)
Robert Moskowitz wrote:
It will be many times faster than doing DD images of entire drives. eg. in my case here, i can provision a new machine in 2 min and 43 seconds for a base+core minimal centos-5 install. installing over http from a machine on a GiB/sec link and installing to a 2 disk raid-1
There is much good to say about using kickstart method than learning a new approach like Clonezilla. I have not used kickstart since Centos 4.something, so I have no good notes and will have to dig again. But this is pretty much a one-time clone and Clonezilla does not seem to set up the partitioning info on the new drive so that would be one more thing to learn.
You are reading the wrong thing about clonezilla. In disk image mode it will duplicate the partitioning for you and it knows enough about most filesystems to just copy the used portions. There are options to just take one partition if you want, but if you do the whole disk it will set up the partitions for you. It understands LVM, but not multi-disk software raid. I'd expect it to be faster than any other way to duplicate systems if you don't count downloading the iso and making your initial image copy from the master.
So I take the anaconda-ks.cfg file, add stuff so it will boot off the network and use the update repo as well as the base. Then rediscover the command to run linux from a kickstart file on a diskette.
Piece of CAKE!
Clonezilla can also be network-booted if you have enough machines to be worth the trouble to set up (and it can clone windows and other linux distributions as well). There is a companion project called DRBL that handles network booting and provides NFS storage for the clients to save and load images.
I am building the Clonezilla live CD now....
Les Mikesell wrote:
Robert Moskowitz wrote:
It will be many times faster than doing DD images of entire drives. eg. in my case here, i can provision a new machine in 2 min and 43 seconds for a base+core minimal centos-5 install. installing over http from a machine on a GiB/sec link and installing to a 2 disk raid-1
There is much good to say about using kickstart method than learning a new approach like Clonezilla. I have not used kickstart since Centos 4.something, so I have no good notes and will have to dig again. But this is pretty much a one-time clone and Clonezilla does not seem to set up the partitioning info on the new drive so that would be one more thing to learn.
You are reading the wrong thing about clonezilla. In disk image mode it will duplicate the partitioning for you and it knows enough about most filesystems to just copy the used portions. There are options to just take one partition if you want, but if you do the whole disk it will set up the partitions for you. It understands LVM, but not multi-disk software raid. I'd expect it to be faster than any other way to duplicate systems if you don't count downloading the iso and making your initial image copy from the master.
So I take the anaconda-ks.cfg file, add stuff so it will boot off the network and use the update repo as well as the base. Then rediscover the command to run linux from a kickstart file on a diskette.
Piece of CAKE!
Clonezilla can also be network-booted if you have enough machines to be worth the trouble to set up (and it can clone windows and other linux distributions as well). There is a companion project called DRBL that handles network booting and provides NFS storage for the clients to save and load images.
Robert Moskowitz wrote:
I am building the Clonezilla live CD now....
is there any reason why your system sends multiple References: headers:
References: 486D78DB.8020904@htt-consult.com References: 486E268B.7030504@htt-consult.com References: 486E704A.8010305@gmail.com
This is invalid according to RFC2822, section 3.6, where there is
references 0* 1 SHOULD occur in some replies - see 3.6.4
which means there may be at most one such header.
sorry to nitpick...
Karanbir Singh wrote:
Robert Moskowitz wrote:
I am building three identical systems. Well they will have different host names, and with time the software setups will drift. But at install time they are identical.
..snip...
I would hope this is faster than 2 more installs.
its not
do the install over the network from a http server, given the same network, it would be many times faster to do the 2nd and 3rd install using the ks.cfg generated from the 1st one ( as Terry Polzin already pointed out ).
It will be many times faster than doing DD images of entire drives. eg. in my case here, i can provision a new machine in 2 min and 43 seconds for a base+core minimal centos-5 install. installing over http from a machine on a GiB/sec link and installing to a 2 disk raid-1
Yes, dd is actually pretty slow in wall clock time. Where it wins is in human time since you just type a short command line and go away, and it duplicates any setup work you've done in addition too installing the packages.
On Fri, 2008-07-04 at 11:41 -0500, Les Mikesell wrote:
<snip>
Yes, dd is actually pretty slow in wall clock time. Where it wins is in human time since you just type a short command line and go away, and it duplicates any setup work you've done in addition too installing the packages.
But it's not as slow as most think. They just don't take advantage of capabilities, like bs=16384. This makes a *huge* difference in both system overhead and wall clock time.
William L. Maltby wrote:
On Fri, 2008-07-04 at 11:41 -0500, Les Mikesell wrote:
<snip>
Yes, dd is actually pretty slow in wall clock time. Where it wins is in human time since you just type a short command line and go away, and it duplicates any setup work you've done in addition too installing the packages.
But it's not as slow as most think. They just don't take advantage of capabilities, like bs=16384. This makes a *huge* difference in both system overhead and wall clock time.
Well Clonezilla is busy cloning the drive, but there is a problem here cloning to a USB attached drive.
One of the partitions is LVM and since this is a drive clone, including the partition table and boot sector, both LVMs (source and target) have the same name. So Clonezilla switches to using DD with probably some bad parameters. After running an hour, it has only copied 4Gb out of 37Gb. Note that the USB port is v1.1.
Now actually, I would have perfered renaming the LVM partition and its internal ext3 partitions. I even had a naming convention laid out if I had do this via Install instead.
On Fri, 2008-07-04 at 17:38 -0400, Robert Moskowitz wrote:
William L. Maltby wrote:
On Fri, 2008-07-04 at 11:41 -0500, Les Mikesell wrote:
<snip>
Yes, dd is actually pretty slow in wall clock time. Where it wins is in human time since you just type a short command line and go away, and it duplicates any setup work you've done in addition too installing the packages.
But it's not as slow as most think. They just don't take advantage of capabilities, like bs=16384. This makes a *huge* difference in both system overhead and wall clock time.
Well Clonezilla is busy cloning the drive, but there is a problem here cloning to a USB attached drive.
One of the partitions is LVM and since this is a drive clone, including the partition table and boot sector, both LVMs (source and target) have the same name. So Clonezilla switches to using DD with probably some bad parameters. After running an hour, it has only copied 4Gb out of 37Gb. Note that the USB port is v1.1.
Now actually, I would have perfered renaming the LVM partition and its internal ext3 partitions. I even had a naming convention laid out if I had do this via Install instead.
I've not ever read up on clonezilla, so I don't know if this is a good thought or not.
If you can tell clonezilla to just make the partitions and copy the non-LVM stuff, it might then be faster to do a manual dd of the LVM PV because you can specify a large blocksize (bs=xxxxx, I usually do a cyl size as the blocksize) and it might go much faster.
WARNING: if you have more than one PV in the volgroup this can be dicey because of the LV records stored on the PVs. I would not recommend it.
OTOH, if it is cranking away and you are now free to do other things, you might want to just let it run.
Now, I wanted to make you aware of a recent experience I had using a usb external drive. I don't know if it will/does affect you.
I moved all my CentOS torrent stuff to a brand new Tosh 80GB external usb drive. Then on CentOS 4.6, I fired up the torrents and started sharing with the world. Nothing else was running.
Three consecutive days, the rtorrent screen became unresponsive. The machine was not locked up. But there was a lock in the wait channel for the drive and it could not be broken. None of the kills (HUP, USR1, KILL) would break the lock and kill the process.
This is usb 2.x and, again CentOS 4.6.
I have no idea of the cause or if it may behave the same in 5.x or if it is unique to rtorrent or the Tosh drive or 4.6. I'm going to try it on 5.2 this P.M.
Sleep well! >:-)
<snip sig stuff>
HTH
On Fri, 2008-07-04 at 17:38 -0400, Robert Moskowitz wrote:
<snip>
Now actually, I would have perfered renaming the LVM partition and its internal ext3 partitions. I even had a naming convention laid out if I had do this via Install instead.
If it's a boot drive, remember to rebuild your initrd and modify the init file to ignore lvm lock failures with the new VG name. Otherwise you'll be fighting some more battles.
<snip sig stuff>
William L. Maltby wrote:
On Fri, 2008-07-04 at 17:38 -0400, Robert Moskowitz wrote:
<snip>
Now actually, I would have perfered renaming the LVM partition and its internal ext3 partitions. I even had a naming convention laid out if I had do this via Install instead.
If it's a boot drive, remember to rebuild your initrd and modify the init file to ignore lvm lock failures with the new VG name. Otherwise you'll be fighting some more battles.
ARGH!!!!
Yes, I remember getting burned by this once.
And I don't have any notes of what I did to do all this. :(
<snip sig stuff>
On Sat, 2008-07-05 at 23:58 -0400, Robert Moskowitz wrote:
William L. Maltby wrote:
On Fri, 2008-07-04 at 17:38 -0400, Robert Moskowitz wrote:
<snip>
Now actually, I would have perfered renaming the LVM partition and its internal ext3 partitions. I even had a naming convention laid out if I had do this via Install instead.
If it's a boot drive, remember to rebuild your initrd and modify the init file to ignore lvm lock failures with the new VG name. Otherwise you'll be fighting some more battles.
ARGH!!!!
Yes, I remember getting burned by this once.
And I don't have any notes of what I did to do all this. :(
Man gzip and cpio in case I misremember.
In a work directory:
gzip -dc <initrd name> | cpio -idmc
Down in the resulting directory, there is an init file.
Locate the ignorelockingfailure and change the VG name there.
Still in the top level working directory (<the created initrd dir/..>)
find <initdirname> | cpio -oac | gzip --best ><new initrd name>
Move it to the boot dir, change grub.conf appropriately. More perilous, but possible: make it the same name (pls save the original somewhere) and no grub name change needed.
<snip>
HTH
On Sun, 2008-07-06 at 06:36 -0400, William L. Maltby wrote:
<snip>
Still in the top level working directory (<the created initrd dir/..>)
find <initdirname> | cpio -oac | gzip --best ><new initrd name>
Just checked. "find *" is what you want.
Also, there are a couple ignorelocking failures and a mkrootdev. Change the ignore... that has the VG mentioned and the mkrootdev.
<snip>
Hi,
On Sun, Jul 6, 2008 at 6:36 AM, William L. Maltby CentOS4Bill@triad.rr.com wrote:
If it's a boot drive, remember to rebuild your initrd and modify the init file to ignore lvm lock failures with the new VG name. Otherwise you'll be fighting some more battles.
Yes, I remember getting burned by this once.
Man gzip and cpio in case I misremember.
To set the "ignorelockingfailure" and others on the initrd file, can't you just use "mkinitrd"? I was looking into the /sbin/mkinitrd script (on CentOS 5.2), and I saw that it contains code for that, for instance:
if [ -n "$vg_list" ]; then emit "echo Scanning logical volumes" emit "lvm vgscan --ignorelockingfailure" emit "echo Activating logical volumes" emit "lvm vgchange -ay --ignorelockingfailure $vg_list" fi
I just don't know if vg_list will be populated with the right devices. Anyway, it might be worth a try, specially if you want to do that over and over again, messing with the internals of initrd (gzip, cpio, etc., and specially rebuilding it) is not something you would want to do on a daily basis.
HTH, Filipe
On Sun, 2008-07-06 at 11:04 -0400, Filipe Brandenburger wrote:
Hi,
On Sun, Jul 6, 2008 at 6:36 AM, William L. Maltby CentOS4Bill@triad.rr.com wrote:
If it's a boot drive, remember to rebuild your initrd and modify the init file to ignore lvm lock failures with the new VG name. Otherwise you'll be fighting some more battles.
Yes, I remember getting burned by this once.
Man gzip and cpio in case I misremember.
To set the "ignorelockingfailure" and others on the initrd file, can't you just use "mkinitrd"? I was looking into the /sbin/mkinitrd script (on CentOS 5.2), and I saw that it contains code for that, for instance:
if [ -n "$vg_list" ]; then emit "echo Scanning logical volumes" emit "lvm vgscan --ignorelockingfailure" emit "echo Activating logical volumes" emit "lvm vgchange -ay --ignorelockingfailure $vg_list" fi
I just don't know if vg_list will be populated with the right devices. Anyway, it might be worth a try, specially if you want to do that over and over again, messing with the internals of initrd (gzip, cpio, etc., and specially rebuilding it) is not something you would want to do on a daily basis.
He is trying to copy an existing install, transport the drive and boot. Until he gets a boot that allows the new root to be detected *as* the new root, I don't know if that would work. But as I frequently say, I'm not expert at any of this stuff.
However, I can tell you that this lets me keep a fallback on a second drive in case the first fails or gets scrogged by you-know-who. It is tested and works. 1. Change BIOS boot sequence *if* required 2. Root file system on 2nd drive is VolGroupAA 3. Punch magic button. 4. Back in business.
HTH, Filipe
<snip>
On Sun, Jul 6, 2008 at 3:28 PM, William L. Maltby CentOS4Bill@triad.rr.com wrote:
He is trying to copy an existing install, transport the drive and boot. Until he gets a boot that allows the new root to be detected *as* the new root, I don't know if that would work.
You can actually do that by using "chroot" from a rescue CD. I usually want to do that on my systems, when I clone from a machine with hardware RAID to a machine on which I will use software RAID. After copying the image (using dd or whatever), I mount the partitions under /mnt/sysimage and /mnt/sysimage/boot, then I do a chroot /mnt/sysimage, and then I do mkinitrd, using -f to overwrite the old one and specifying the exact version of the kernel grub is configured to boot with.
For adding/removing drivers, mkinitrd works like a charm. For renaming VGs, I don't know if it would detect them right. As it is on the destination machine, I'm guessing it would, but as I didn't really test it, I cannot be sure.
Anyway, if you get to it and test mkinitrd to correct the name of the VGs inside initrd and it works, let us know!
Thanks, Filipe
On Sun, 2008-07-06 at 18:41 -0400, Filipe Brandenburger wrote:
<snip>
You can actually do that by using "chroot" from a rescue CD. I usually want to do that on my systems, when I clone from a machine with hardware RAID to a machine on which I will use software RAID. After copying the image (using dd or whatever), I mount the partitions under /mnt/sysimage and /mnt/sysimage/boot, then I do a chroot /mnt/sysimage, and then I do mkinitrd, using -f to overwrite the old one and specifying the exact version of the kernel grub is configured to boot with.
For adding/removing drivers, mkinitrd works like a charm. For renaming VGs, I don't know if it would detect them right. As it is on the destination machine, I'm guessing it would, but as I didn't really test it, I cannot be sure.
Anyway, if you get to it and test mkinitrd to correct the name of the VGs inside initrd and it works, let us know!
Thanks, Filipe
<snip sig stuff>
Thanks for the info! I'm going to stash this where I can find it quickly. I *might* have occasion to test this myself in another month or so.
Meanwhile, if Robert hasn't progressed to far with his other scheme, he might have an opportunity to try it. But I suspect he's short of time ATM.
Robert Moskowitz wrote:
William L. Maltby wrote:
On Fri, 2008-07-04 at 11:41 -0500, Les Mikesell wrote:
<snip>
Yes, dd is actually pretty slow in wall clock time. Where it wins is in human time since you just type a short command line and go away, and it duplicates any setup work you've done in addition too installing the packages.
But it's not as slow as most think. They just don't take advantage of capabilities, like bs=16384. This makes a *huge* difference in both system overhead and wall clock time.
Well Clonezilla is busy cloning the drive, but there is a problem here cloning to a USB attached drive.
One of the partitions is LVM and since this is a drive clone, including the partition table and boot sector, both LVMs (source and target) have the same name. So Clonezilla switches to using DD with probably some bad parameters. After running an hour, it has only copied 4Gb out of 37Gb. Note that the USB port is v1.1.
Now actually, I would have perfered renaming the LVM partition and its internal ext3 partitions. I even had a naming convention laid out if I had do this via Install instead.
If you have any other system on the network that could hold a compressed image copy you would be better off working with the disks in their target machines instead of the USB adapter. Clonezilla can use smb, nfs, or ssh to connect to network storage, so you can use space from windows or linux. After saving the master image, you would just boot the clone machines from the CD, connect to the same network location, and restore to the local drive. That would elminate both the duplicate LVM problem and the slowness of USB 1.1.
on 7-4-2008 2:38 PM Robert Moskowitz spake the following:
William L. Maltby wrote:
On Fri, 2008-07-04 at 11:41 -0500, Les Mikesell wrote:
<snip>
Yes, dd is actually pretty slow in wall clock time. Where it wins is in human time since you just type a short command line and go away, and it duplicates any setup work you've done in addition too installing the packages.
But it's not as slow as most think. They just don't take advantage of capabilities, like bs=16384. This makes a *huge* difference in both system overhead and wall clock time.
Well Clonezilla is busy cloning the drive, but there is a problem here cloning to a USB attached drive.
One of the partitions is LVM and since this is a drive clone, including the partition table and boot sector, both LVMs (source and target) have the same name. So Clonezilla switches to using DD with probably some bad parameters. After running an hour, it has only copied 4Gb out of 37Gb. Note that the USB port is v1.1.
Now actually, I would have perfered renaming the LVM partition and its internal ext3 partitions. I even had a naming convention laid out if I had do this via Install instead.
You might want to think about the fact that the drive could map differently from the LBA between the usb adapter and directly hooked up to a system. I had a laptop that did that, and access was extremely slow until I re-formatted it and re-built the OS. Especially on older systems like you say you are using.
-
Daniel_Curry＠Dell.com -
Filipe Brandenburger -
Karanbir Singh -
Les Mikesell -
Mark Weaver -
mkn0014 -
mouss -
Robert Moskowitz -
Scott Silva -
Terry Polzin -
William L. Maltby