LINUX.ORG.RU

История изменений

Исправление fehhner, (текущая версия) :

Восстановил впринципе всё на старый диск, за исключением одного проекта, профиля фаерфокса, и хотелось с гуя полазить и посмотреть, возможно я что-то нужное ещё скачал. Поэтому хотелось бы примонтировать дамп к живой системе. Возникли проблемы с одинаковыми UUID. В случае с LVM, проблема решилась так. Примонтировал диск с загрузочной флешки и сделал для бекапа

vgchange -a n /dev/lvmvg
pvchange -u /dev/mapper/root
vgrename lvmvg lvmvgcp
Т.е., я сменил UUID и имя LVM тома. Проверил через blkid, они реально сменились. UUID группы btrfs при этом так же заменён, а его элементов - нет. 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
Т.е., я сменил UUID и имя LVM тома. Проверил через blkid, они реально сменились. UUID группы btrfs при этом так же заменён, а его элементов - нет. 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лс срабатывает, но показывает содержимое бекапной директории, вместо основной (с некоторыми повреждёнными файлами), ну и разные куски плазмы падают. Как понял, это баг и побороть не смогу?