Date: Tue, 4 Oct 2016 17:26:45 -0700 From: "Jack L." <xxjack12xx@gmail.com> To: Warren Block <wblock@wonkity.com> Cc: Polytropon <freebsd@edvax.de>, "lokadamus@gmx.de" <lokadamus@gmx.de>, FreeBSD Questions <freebsd-questions@freebsd.org> Subject: Re: Clone a FBSD system with something in the likes of ghost Message-ID: <CALeGphzWwGpM4TfTDCGt5oSGx7=Q-MTmmg_hYhoX=eremMOWnA@mail.gmail.com> In-Reply-To: <alpine.BSF.2.20.1610031632530.59114@wonkity.com> References: <CAHieY7TSESodQXBLoZkkBGWZaCbEZessqiMvzp9dR8Y1CoAZtw@mail.gmail.com> <57EC9527.7020202@rcn.com> <alpine.BSF.2.20.1609282305130.7457@wonkity.com> <CAHieY7QV3xYPsNxXdZrYCGO7SA37Mxn_yy2njByR2EBd9DzX9A@mail.gmail.com> <CAN2YBg6qUBXd8qy25zT5FNe9LkyY=x3po1H3UoD1Y2fDxrBvQw@mail.gmail.com> <c0c912ce-e859-4afb-76fc-cf06da97d848@gmx.de> <alpine.BSF.2.20.1610031043260.59114@wonkity.com> <20161003192218.51a7f402.freebsd@edvax.de> <alpine.BSF.2.20.1610031632530.59114@wonkity.com>
next in thread | previous in thread | raw e-mail | index | archive | help
have you tried gpart backup src|gpart restore target? That's usually how I clone my partitions On Mon, Oct 3, 2016 at 3:41 PM, Warren Block <wblock@wonkity.com> wrote: > On Mon, 3 Oct 2016, Polytropon wrote: > > On Mon, 3 Oct 2016 10:49:06 -0600 (MDT), Warren Block wrote: >> >>> In the old MBR days, there was no serious problem with partition tables, >>> because there was only one partition table at the start of the disk. >>> GPT puts one at the start of the disk and the end of the disk, so binary >>> copying a smaller disk to a larger one puts the secondary partition >>> table somewhere before the end of the larger disk. It's not really >>> possible to copy a larger disk to a smaller one with dd(1), so that >>> problem does not come up. >>> >> >> Isn't it _technically_ possible to capture the 2nd GPT table (at the >> end of the source disk) and calculate its proper position in relation >> to the size of the target disk, and then put it there? >> > > Sure. 'gpart recover' does that, although it rebuilds the secondary table > from the primary table rather than copying it. > > Initial state: empty disk: >> >> /dev/da0 -------------------- >> >> Image smaller than this disk, including two GPT tables (1 and 2): >> >> source.img 1#######2 >> >> Copy the image: >> >> # dd if=source.img of=/dev/da0 >> >> /dev/da0 1#######2----------- >> >> Get the 2nd GPT table >> >> # dd if=source.img of=gpt2.img skip=1000 bs=1M count=1 >> >> gpt2.img 2 >> >> Put it at the end of the disk (the skip= value has to be calculated >> from the disk size): >> >> # dd if=gpt2.img of=/dev/da0 skip=1000 >> >> /dev/da0 1#######2----------2 >> >> Optional step: remove (useless or confusing) 2nd GPT table left >> behind by the image: >> >> # dd if=/dev/zero of=/dev/da0 skip=1000 bs=1M count=1 >> >> /dev/da0 1#######-----------2 >> >> Tadaa! >> > > It looks like a lot of work to do to use a tool that is not well suited > for copying modern disks, though. > > I assume that a 2nd GPT table somewhere inside the free space is >> not a problem (otherwise I'd suggest to add the additional step to >> overwrite it with zero bytes). >> >> However, even if this might work, it's a very ugly thing. Putting >> things "at the end of the disk" in the age of virtualized and easily >> resizable disks doesn't look very clever... >> > > Think about it for a bit, and you realize there are only two places on a > disk that are known for any size of disk, the start and end. If you put a > partition table somewhere aribtrary between those, it breaks up the space > for the user. A backup copy of the partition table could be put next to > the main one, but then both could get wiped out easily. > > I recommend backing up first, then setting up the target disk partitions >>> and bootcode: >>> http://www.wonkity.com/~wblock/docs/html/disksetup.html >>> >>> Then use dump/restore to copy from the original: >>> http://www.wonkity.com/~wblock/docs/html/backup.html >>> >> >> That's the easier approach, as it makes sure that all GPT data is >> going to be located at where it belings, but it involves more steps >> than the desired "clone" (in _one_ step). >> > > What you showed above wasn't one step, either. :) > > Sometimes brute-force is fine. I prefer to save that as a last resort for > disks. > > [...] or that it is one of the earlier FreeBSD versions >>> that did not boot at all if the secondary GPT table was not correct. >>> >> >> And _this_ is exactly where the oh so modern and comfortable GPT >> is going to shoot users in the foot. ;-) >> > > There are BIOS implementations that will not boot unless the MBR is just > right, either. > > All of this is kind of implying there is sort of a fixed cost to doing > many things, a "pay me now or pay me later" thing. > _______________________________________________ > freebsd-questions@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe > @freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALeGphzWwGpM4TfTDCGt5oSGx7=Q-MTmmg_hYhoX=eremMOWnA>