An Exercise: Manually creating a new boot disk from an existing one

[Philip Rhoades]

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

PO Box 896
Cowra  NSW  2794
Australia
E-mail:  phil(a)pricom.com.au

[Timothy Murphy]

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

-- 
Timothy Murphy  
gayleard /at/ eircom.net
School of Mathematics, Trinity College, Dublin

[Tim]

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)
>  1. Correct /etc/fstab 
Depends on how it calls partitions.

>  2. 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.

-- 
[tim@localhost ~]$ uname -rsvp
Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14 01:31:27 UTC 2013 x86_64

All mail to my mailbox is automatically deleted, there is no point
trying to privately email me, I will only read messages posted to the
public lists.

If you don't understand how e-mail threading works, then follow the
instructions given by those who do, and don't argue with them.

[Tom Horsley]

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 :-).

[Joe Zeff]

On 12/27/2015 06:44 AM, Tim wrote:
>  Generally speaking, if you want to clone drives, you're much
> better off
>  booting from some third thing, 
Clonezilla.