People,
I am interested to see if it is possible to boot on an existing disk - say /dev/sda ("A") - and then manually create everything required on a second disk - /dev/sdb ("B") eg:
- create the partition table and partitions on B
- dd the existing boot track(s) from A to a file and then dd that to B - or create it from scratch somehow?
- rsync the the first level directories into the appropriate places on the new drive and partitions (maybe by temporarily booting on a Live USB so we are not copying from a running system?)
If this is possible, what else would need to be done on B so that when drive A is removed, the remaining B (the new "A") drive will be able to boot and run normally?
Thanks!
Phil.
Philip Rhoades wrote:
I am interested to see if it is possible to boot on an existing disk - say /dev/sda ("A") - and then manually create everything required on a second disk - /dev/sdb ("B") eg:
create the partition table and partitions on B
dd the existing boot track(s) from A to a file and then dd that to B -
or create it from scratch somehow?
- rsync the the first level directories into the appropriate places on
the new drive and partitions (maybe by temporarily booting on a Live USB so we are not copying from a running system?)
If this is possible, what else would need to be done on B so that when drive A is removed, the remaining B (the new "A") drive will be able to boot and run normally?
Presumably you would have to (at least) 1. Correct /etc/fstab 2. Install grub on second disk
Philip Rhoades wrote:
I am interested to see if it is possible to boot on an existing disk - say /dev/sda ("A") - and then manually create everything required on a second disk - /dev/sdb ("B") eg:
Generally speaking, if you want to clone drives, you're much better off booting from some third thing, and copying from source to destination without any interference from an OS currently running from the drive you're copying.
i.e. Boot from a live disc, probably a disk managing one, rather than a full bloated live OS.
Theoretically, you can dd the whole partition, not have to do it in stages (dd partition details, *then* copy files over).
create the partition table and partitions on B
dd the existing boot track(s) from A to a file and then dd that to B -
or create it from scratch somehow?
- rsync the the first level directories into the appropriate places on
the new drive and partitions (maybe by temporarily booting on a Live USB so we are not copying from a running system?)
If this is possible, what else would need to be done on B so that when drive A is removed, the remaining B (the new "A") drive will be able to boot and run normally?
If new drive is identical to old drive, then simply swapping them ought to be enough. But if new drive is bigger than old drive, then your dd of one to the other, will only occupy a portion of the new drive. You'd probably want to expand it to fit. Unless you wanted to keep some unused space.
Timothy Murphy:
Presumably you would have to (at least)
- Correct /etc/fstab
Depends on how it calls partitions.
- Install grub on second disk
If he used "dd" to copy partitions, then it should copy the partitions in their entirety (including all things stored in partition headers). In essence, cloning them. And that's where a problem will lay, he'll now how have two (or more) identical partitions on the system, on different drives. You couldn't mount them without some headaches, and if the current way of addressing them isn't unique (i.e. uses /dev/sd..., which will be unique per drive, but names and IDs will be duplicated), then you may be in for grief until you unplug one of the drives.
On Mon, 28 Dec 2015 01:14:48 +1030 Tim wrote:
Generally speaking, if you want to clone drives, you're much better off booting from some third thing, and copying from source to destination without any interference from an OS currently running from the drive you're copying.
Yep. I do that pretty frequently, using rsync to copy everything off the inactive drives to new partitions on the new disk (which can be much bigger than the old disk). It is also how I install fedora these days - install in a virtual machine first, guestmount the image and rsync to the partition I want it to live in (with no possibility anaconda will do anything to overwrite other partitions :-).
You can then chroot into the copied disk and run grub2-install in there to make it bootable.
Alternatively, you can make a grub2 "configfile" entry in the existing bootable disk which you can then use to boot the new disk and run grub2-install after booting it. A configfile entry looks like this:
menuentry "Boot Fedora 23 via configfile" { insmod part_msdos insmod ext2 set root='hd0,msdos2' configfile /boot/grub2/grub.cfg }
You'll need to adjust the hd0,msdos2 appropriately to point to the new disk (and probably make a unique file in the root of the new disk so you can check and see it is there after booting and you really did boot the new disk and not the old one :-).