From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-user+bounces-167862-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
by finch.gentoo.org (Postfix) with ESMTP id 68F8713888F
for <garchives@archives.gentoo.org>; Tue, 6 Oct 2015 12:32:38 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id F164F21C01D;
Tue, 6 Oct 2015 12:32:11 +0000 (UTC)
Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id 8471021C038
for <gentoo-user@lists.gentoo.org>; Tue, 6 Oct 2015 12:32:09 +0000 (UTC)
Received: by qgez77 with SMTP id z77so172905498qge.1
for <gentoo-user@lists.gentoo.org>; Tue, 06 Oct 2015 05:32:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:date:message-id:subject
:from:to:content-type;
bh=6heFKzT5IQ8kfQ7Z9brLPy4VDYvbVb0VjOU5BRhaAxY=;
b=Kmipqvo5hre2u7805iAVYGB3QEOYx+rUXvbvfHdlHSwHhoN68XOw9xwV6+ip6KR5+t
pNb/WbPS6GL7QYdkaeFo9ZNwPFyLVkf7nOkwrDkt6f+pmRcsgbGDGYcQataeZfC8nnuT
8Uy/DBcnWd45U/xqAAK4fAxDcWs8XSHS6Wpw8OZt+0GXc/ez1cwgnjqJJMtGeTaZQuNM
lrcPCHDETRUohlpi9O/kX76q45/df8yCXEuyjVHnd/hx5zuYXgWm+Iii5E1npuzmjRln
uvQlUxafELQyoQuSlgbJKqJOBxjrxYkZyCPL1TluB/uv+749MF7d808BL+SeQSiEW/3Z
DyTw==
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
X-BeenThere: gentoo-user@lists.gentoo.org
Reply-to: gentoo-user@lists.gentoo.org
MIME-Version: 1.0
X-Received: by 10.140.129.22 with SMTP id 22mr48790850qhb.74.1444134723430;
Tue, 06 Oct 2015 05:32:03 -0700 (PDT)
Sender: freemanrich@gmail.com
Received: by 10.140.38.106 with HTTP; Tue, 6 Oct 2015 05:32:03 -0700 (PDT)
In-Reply-To: <56137DB2.8000808@xunil.at>
References: <5612ED69.7060905@xunil.at>
<CAGQH77dDppCwPuGdj=r7idvbLcE+dzyvMXjKMGENyyoZQd1SmA@mail.gmail.com>
<5613754F.4060309@xunil.at>
<20151006082856.4f6fbab6@digimed.co.uk>
<561379CC.7000704@xunil.at>
<20151006084500.0b9f4b65@digimed.co.uk>
<56137DB2.8000808@xunil.at>
Date: Tue, 6 Oct 2015 08:32:03 -0400
X-Google-Sender-Auth: Srn2-l4shisiCTe0tQTWX9Y9lIQ
Message-ID: <CAGfcS_mds-j9wnxFXWt=g_cSaeZbcY8i8hGUgriCxT+_tvKcAA@mail.gmail.com>
Subject: Re: [gentoo-user] resizing EFI partition, btrfs context
From: Rich Freeman <rich0@gentoo.org>
To: gentoo-user@lists.gentoo.org
Content-Type: text/plain; charset=UTF-8
X-Archives-Salt: fb1dda84-962e-4ece-96da-c8b5a56006be
X-Archives-Hash: 4d758348cbc68bafbe148bece4cbd571
On Tue, Oct 6, 2015 at 3:52 AM, Stefan G. Weichinger <lists@xunil.at> wrote:
> Am 2015-10-06 um 09:45 schrieb Neil Bothwick:
>> On Tue, 6 Oct 2015 09:35:40 +0200, Stefan G. Weichinger wrote:
>>
>>>> How about btrfs send/receive? I've never used them but used
>>>> the equivalent with ZFS and it was simple to do.
>>>
>>> I think "btrfs-replace" is my friend. Will try that later.
>>
>> If you want to keep the system live, replace will do the trick, but
>> when I tried it to replace a drive that was showing SMART errors it
>> was VERY slow. btrfs send serialises your whole filesystem to a
>> file so it should be much faster.
>
> btrfs send would also have the benefit that I won't lose the
> source-dev in the process. btrfs-replace would "empty" my hdd, if then
> things fail I don't have that backup again to start from.
>
> I just have to find out how to keep the UUID to keep the copy booting etc
>
> I will try that later this day, after some job work.
>
I doubt send/receive would preserve the UUID.
I'd probably use btrfs-replace.
If you do want to keep the same UUID via any mechanism make sure the
original drive isn't visible or btrfs may try to use it instead of the
new one. That is more of a concern in raid configs, but it might
apply to single volume. Btrfs can't tell the difference between the
active volume you unmounted yesterday and the lvm snapshot of it from
six months ago, and will potentially try to mix-and-match them
resulting in carnage.
Btrfs does support resizing if you just want to shrink the filesystem
and then dd it over to the new partition. Just make sure the old one
isn't attached when you try to mount it. Just shrink your btrfs
partition down to a size smaller than where it is going, use dd to
copy it, then you can run btrfs resize to expand it back to the full
size. The syntax is slightly different but it works the same as
resize2fs, and I believe it works either online or offline.
However, if you're able to figure out how to use btrfs and migrate it
from one drive to another, you could probably just edit the UUID in
your grub config if necessary. It just takes a text editor, and maybe
a run of grub2-mkconfig if you're using that. You'll also want to
update your fstab, and if you're using dracut you should update that
as well (as long as it gets a decent UUID from the command line I
think it will figure things out on its own though - dracut saves a
copy of your fstab to help find things when you build it but then it
will remount filesystems using the real fstab before it finishes).
--
Rich