1 |
Am 2015-10-06 um 14:32 schrieb Rich Freeman: |
2 |
> On Tue, Oct 6, 2015 at 3:52 AM, Stefan G. Weichinger <lists@×××××.at> wrote: |
3 |
>> Am 2015-10-06 um 09:45 schrieb Neil Bothwick: |
4 |
>>> On Tue, 6 Oct 2015 09:35:40 +0200, Stefan G. Weichinger wrote: |
5 |
>>> |
6 |
>>>>> How about btrfs send/receive? I've never used them but used |
7 |
>>>>> the equivalent with ZFS and it was simple to do. |
8 |
>>>> |
9 |
>>>> I think "btrfs-replace" is my friend. Will try that later. |
10 |
>>> |
11 |
>>> If you want to keep the system live, replace will do the trick, but |
12 |
>>> when I tried it to replace a drive that was showing SMART errors it |
13 |
>>> was VERY slow. btrfs send serialises your whole filesystem to a |
14 |
>>> file so it should be much faster. |
15 |
>> |
16 |
>> btrfs send would also have the benefit that I won't lose the |
17 |
>> source-dev in the process. btrfs-replace would "empty" my hdd, if then |
18 |
>> things fail I don't have that backup again to start from. |
19 |
>> |
20 |
>> I just have to find out how to keep the UUID to keep the copy booting etc |
21 |
>> |
22 |
>> I will try that later this day, after some job work. |
23 |
>> |
24 |
> |
25 |
> I doubt send/receive would preserve the UUID. |
26 |
> |
27 |
> I'd probably use btrfs-replace. |
28 |
> |
29 |
> If you do want to keep the same UUID via any mechanism make sure the |
30 |
> original drive isn't visible or btrfs may try to use it instead of the |
31 |
> new one. That is more of a concern in raid configs, but it might |
32 |
> apply to single volume. Btrfs can't tell the difference between the |
33 |
> active volume you unmounted yesterday and the lvm snapshot of it from |
34 |
> six months ago, and will potentially try to mix-and-match them |
35 |
> resulting in carnage. |
36 |
> |
37 |
> Btrfs does support resizing if you just want to shrink the filesystem |
38 |
> and then dd it over to the new partition. Just make sure the old one |
39 |
> isn't attached when you try to mount it. Just shrink your btrfs |
40 |
> partition down to a size smaller than where it is going, use dd to |
41 |
> copy it, then you can run btrfs resize to expand it back to the full |
42 |
> size. The syntax is slightly different but it works the same as |
43 |
> resize2fs, and I believe it works either online or offline. |
44 |
> |
45 |
> However, if you're able to figure out how to use btrfs and migrate it |
46 |
> from one drive to another, you could probably just edit the UUID in |
47 |
> your grub config if necessary. It just takes a text editor, and maybe |
48 |
> a run of grub2-mkconfig if you're using that. You'll also want to |
49 |
> update your fstab, and if you're using dracut you should update that |
50 |
> as well (as long as it gets a decent UUID from the command line I |
51 |
> think it will figure things out on its own though - dracut saves a |
52 |
> copy of your fstab to help find things when you build it but then it |
53 |
> will remount filesystems using the real fstab before it finishes). |
54 |
|
55 |
I do a plain rsync into a new btrfs on the ssd now and edited the UUID |
56 |
within copied gummiboat loader entries .... some GBs left to sync before |
57 |
I can test booting! |
58 |
|
59 |
;) |
60 |
|
61 |
I don't use grub2 anymore, just gummiboot .. and even this might be |
62 |
replaced by bootctl soon. step by step, you know. |