Clonezilla и BTRFS, GRUB и загрузчик

Быстрый поиск в Google показывает, что tacacs требуется центральный сервер аутентификации. Может ли виртуальная машина по-прежнему взаимодействовать с этим сервером с новой конфигурацией сети? Возможно, вам нужно обновить конфигурацию tacacs либо на виртуальной машине, либо на центральном сервере?

Если вы не хотите, чтобы система вообще использовала tacacs, вам необходимо проверить и изменить конфигурацию Pam.

Проверьте журнал безопасности системы и проверьте конфигурацию Pam и, возможно, sshd.

0
12.10.2019, 22:19
1 ответ

Итак, в соответствии с вашим lsblkвыводом и вашим /etc/fstab, у вас есть практически вся-btrfsсистема, за исключением системного раздела EFI.

Обратите внимание, что одна файловая система btrfsможет распространяться за пределы одного раздела или даже на несколько дисков :, так как ваш вывод lsblkне говорит, для чего используется ваш /dev/sdc, он может использоваться как расширение вашего btrfs, которое содержит ваш подтом /home. Это может объяснить, почему его нет на клоне, или, возможно, вы просто не смогли смонтировать все различные подтома. Вы можете использовать btrfs filesystem show, чтобы увидеть, какие устройства/разделы принадлежат каждой смонтированной btrfsфайловой системе.

Когда вы запустили btrfstune -m /dev/sdb3, как вы упомянули в комментариях к другому вопросу, который вы связали, он изменил UUID клонированной файловой системы, поэтому записи UUID в /etc/fstabв клонированной файловой системе больше не являются правильными. Вам придется исправить их в файле /etc/fstabклона и, возможно, также в его конфигурации GRUB и/или initramfs. Вы можете использовать lsblk -o +UUIDдля просмотра нового UUID файловой системы . Этот UUID используется GRUB и ядром Linux, но не прошивкой UEFI. Он хранится в метаданных файловой системы.

Вы должны сделать что-то вроде этого:

mount /dev/sdb3 /mnt
mount -o subvol=/@/boot/grub2/x86_64-efi /dev/sdb3 /mnt/boot/x86_64-efi
mount /dev/sdb1 /mnt/boot/efi

, а затем:

  • отредактируйте /mnt/etc/fstabдля замены UUID файловой системы в каждой строке, относящейся к файловой системе btrfs

  • отредактируйте/mnt/boot/grub/grub.cfg(или, возможно, /mnt/boot/efi/EFI/opensuse/grub.cfgв зависимости от того, где OpenSuSE помещает свою фактическую конфигурацию GRUB )для замены UUID файловой системы в строке параметров загрузки ядра

  • отредактируйте /mnt/etc/default/grubдля замены UUID файловой системы, чтобы старый UUID не возвращался случайно при установке обновления ядра или повторном создании конфигурации GRUB по какой-либо другой причине
  • возможно, полностью воссоздайте файл initramfs

Если окажется, что файл initramfs необходимо воссоздать (, если он полностью зависит от параметров загрузки ядра для поиска корневой файловой системы, в этом может не быть необходимости ), вы можете сделать это следующим образом:

mount -t proc none /mnt/proc
mount -t sysfs none /mnt/sys
mount -o bind /dev /mnt/dev
chroot /mnt /bin/bash
mkinitrd   # or whatever is the appropriate command for OpenSuSE
exit
  • окончательно размонтировать все, что вы смонтировали

Чтобы система действительно загружалась с клонированного диска, вам потребуется определить для него загрузочную переменную UEFI. Из вашего efibootmgr -vвывода загрузочная запись OpenSuSE ссылается на системный раздел EFI с помощью UUID раздела . Это отдельный UUID, который используется только прошивкой UEFI. Он хранится в таблице разделов GPT.

Boot0000* opensuse-secureboot   HD(1,GPT,e099a79f-8b66-412d-89ae-a4869876f500,0x800,0x100000)/File(\EFI\opensuse\shim.efi)

Вы можете просмотреть UUID разделов с помощью lsblk -o +PARTUUID.

Наличие двух дисков с одинаковыми UUID разделов может привести к путанице в прошивке вашей системы, или прошивка может просто выбрать первый диск с совпадающим UUID. Если вы планируете хранить оба диска на одном компьютере, возможно, вам придется изменить UUID раздела с помощью sgdisk --partition-guid=1:R /dev/sdb(. Эта команда сгенерирует новый случайный UUID раздела для раздела #1 на/dev/sdb).

После завершения вам потребуется создать новую загрузочную переменную UEFI для клонированного диска. Команда для этого будет что-то вроде efibootmgr -c -d /dev/sdb -l \\EFI\\opensuse\\shim.efi -L opensuse-clone. Обратите внимание на двойную обратную косую черту,потому что обратная косая черта является специальным escape-символом для оболочки; файловой системой ESP является FAT32, поэтому прошивка UEFI использует обратную косую черту в стиле MS -DOS/Windows в качестве разделителя пути вместо прямой косой черты в стиле Unix -. Полезно то, что эта команда автоматически считывает UUID раздела с указанного диска, поэтому вам не придется его вводить.

(Вы можете использовать efibootmgr -B -b XXXX, где XXXX — это номер BootXXXX одной из ваших прошлых установок Linux, чтобы очистить системную NVRAM от устаревших загрузочных переменных UEFI.)

Но если вы планируете переместить диск на другой компьютер, изменение UUID раздела не требуется, но загрузочная переменная UEFI должна быть создана в системе, которая является получателем клонированного диска. Для этого вы можете использовать какой-нибудь загрузочный носитель Linux Live, но убедитесь, что вы загружаетесь именно с носителя в стиле UEFI , иначе вы не сможете получить доступ к загрузочным переменным UEFI.

В качестве альтернативы, если вам нужно, чтобы клонированный диск был загрузочным в любой системе UEFI без каких-либо значительных приготовлений, вы должны настроить копию загрузчика UEFI в \EFI\Boot\bootx64.efi, путь загрузчика резервного/съемного носителя в разделе ESP клонированный диск. К сожалению, у меня нет информации о точном наборе -загрузчика OpenSuSE UEFI, поэтому я не могу дать вам точные шаги для этого.

Чтобы получить доступ к ESP на клонированном диске, вам нужно сначала смонтировать его, например:

mount /dev/sdb1 /mnt

, а затем вы можете поместить резервный загрузчик в /mnt/EFI/BOOT/bootx64.efi, что теперь соответствует пути в стиле DOS -\EFI\BOOT\bootx64.efi, используемому прошивкой UEFI.

2
28.01.2020, 02:29

Теги

Похожие вопросы