История изменений
Исправление fehhner, (текущая версия) :
Восстановил впринципе всё на старый диск, за исключением одного проекта, профиля фаерфокса, и хотелось с гуя полазить и посмотреть, возможно я что-то нужное ещё скачал. Поэтому хотелось бы примонтировать дамп к живой системе. Возникли проблемы с одинаковыми UUID. В случае с LVM, проблема решилась так. Примонтировал диск с загрузочной флешки и сделал для бекапа
vgchange -a n /dev/lvmvg
pvchange -u /dev/mapper/root
vgrename lvmvg lvmvgcp
btrfstune -u /dev/sdaX
Должен менять UUID, но сабвольюмов менять он не умеет. Здесь задавали вопрос насчёт смены их UUID: http://unix.stackexchange.com/questions/246976/btrfs-subvolume-uuid-clash, на что был дан ответ tldr: It's ok, no possible data corruption.
Asked at the mailing list too, and they explained that the subvol UUID is just used a sanity check for btrfs send and btrfs receive.
... The UUIDs on subvols are only really used internally to that filesystem, so the kernel doesn't have a chance to get confused. The main thing that could be confused is send/receive, but that's a matter of possibly losing some validation (thus allowing you to do something that will fail) rather than causing active damage, as in the duplicate-FS-UUID case. ...
from http://thread.gmane.org/gmane.comp.file-systems.btrfs/50909/focus=50917
Но есть проблема. Как только я в работающей системе открываю контейнер LUKS c бекапом, он всё равно начинает пытаться работать с ФС оттуда, вместо основной. Например, пытаюсь выполнить команду $mount ...
, выдаёт Input/Output error: mount
, ls
лс срабатывает, но показывает содержимое бекапной директории, вместо основной (с некоторыми повреждёнными файлами), ну и разные куски плазмы падают. Как понял, это баг и побороть не смогу?
Исходная версия fehhner, :
Восстановил впринципе всё на старый диск, за исключением одного проекта, профиля фаерфокса, и хотелось с гуя полазить и посмотреть, возможно я что-то нужное ещё скачал. Поэтому хотелось бы примонтировать дамп к живой системе. Возникли проблемы с одинаковыми UUID. В случае с LVM, проблема решилась так. Примонтировал диск с загрузочной флешки и сделал для бекапа
vgchange -a n /dev/lvmvg
pvchange -u /dev/mapper/root
vgrename lvmvg lvmvgcp
btrfstune -u /dev/sdaX[/quote] Должен менять UUID, но сабвольюмов менять он не умеет. Здесь задавали вопрос насчёт смены их UUID: [url]http://unix.stackexchange.com/questions/246976/btrfs-subvolume-uuid-clash[/url], на что был дан ответ [quote]tldr: It's ok, no possible data corruption.Asked at the mailing list too, and they explained that the subvol UUID
is just used a sanity check for btrfs send and btrfs receive.
...
The UUIDs on subvols are only really used internally to that filesystem, so the kernel doesn't have a chance to get confused. The main thing that could be confused is send/receive, but that's a matter of possibly losing some validation (thus allowing you to do something that will fail) rather than causing active damage, as in the duplicate-FS-UUID case.
...
from [url]http://thread.gmane.org/gmane.comp.file-systems.btrfs/50909/focus=50917[/url] [/quote]
Но есть проблема. Как только я в работающей системе открываю контейнер LUKS c бекапом, он всё равно начинает пытаться работать с ФС оттуда, вместо основной. Например, пытаюсь выполнить команду $mount ...
, выдаёт Input/Output error: mount
, ls
лс срабатывает, но показывает содержимое бекапной директории, вместо основной (с некоторыми повреждёнными файлами), ну и разные куски плазмы падают. Как понял, это баг и побороть не смогу?