主页 / ubuntu / 问题 / 1199536
Accepted
Greelan
Asked: 2019-12-31 03:45:00 +0800 CST

使用 LVM 将 MBR/BIOS RAID 1 根分区迁移到 GPT/UEFI

  • 772

我一直在思考这个问题，并搜索了各种帖子，但找不到与我的情况相符的东西。

我目前在 RAID 1 中的几个 SSD 上运行 18.04.3 LTS（以及在一堆 HDD 上使用 LVM 的单独数据 RAID 6）。几年前我设置了这个（当时是 14.04 LTS），当时我的主板只支持 MBR/BIOS。

从那以后，我将主板升级为支持 UEFI 的主板。我现在也正在升级 SSD（更大的 M.2 单元）。

而不是在保持当前设置的同时更换 SSD，我一直在考虑：

  • 将设置更改为 GPT/UEFI，以及
  • 在 RAID 1 上安装 LVM。

我正在尝试找出执行上述任何一项或两项的最佳方法。我考虑过在新的 SSD 上进行全新的安装（这很吸引人，可以作为摆脱多年来积累的垃圾的一种方式），但一想到要重新配置所有东西，我就不寒而栗（有很多... ）。

还有其他方法吗？

在迁移到 GPT/ UEFI方面，我研究了使用Boot-Repair. 我考虑的另一个选择是使用我想要的方案（简单的 EFI 引导分区和根分区）对新的 SSD 进行分区，然后将它们依次引入阵列 - 有点像这样。

但我不完全清楚是否可以工作，例如可以Boot-Repair在不破坏数据的情况下修改实时系统（并且会在磁盘启动时插入 EFI 引导分区mdadm），以及如何在手动创建的 EFI 上安装 EFI 引导加载程序如果我不重新安装操作系统，启动分区？

至于在现有 RAID 1 上安装 LVM 的问题，我正在努力思考如何实现。

一些当前设置（就相关而言 - 我已经删除了多余的信息）以获取更多上下文：

$ cat /proc/mdstat

md1 : active raid1 sdg5[2] sdh5[3]
      16757632 blocks super 1.2 [2/2] [UU]
      
md0 : active raid1 sdg1[2] sdh1[3]
      100386688 blocks super 1.2 [2/2] [UU]

和：

$ sudo fdisk -l

Disk /dev/sdg: 111.8 GiB, 120034123776 bytes, 234441648 sectors                                                                                                                                         
Units: sectors of 1 * 512 = 512 bytes                                                                                                                                                                   
Sector size (logical/physical): 512 bytes / 512 bytes                                                                                                                                                   
I/O size (minimum/optimal): 512 bytes / 512 bytes                                                                                                                                                       
Disklabel type: dos                                                                                                                                                                                     
Disk identifier: 0x0001cb75                                                                                                                                                                             
                                                                                                                                                                                                        
Device     Boot     Start       End   Sectors  Size Id Type                                                                                                                                             
/dev/sdg1  *         2048 200906751 200904704 95.8G fd Linux RAID autodetect                                                                                                                            
/dev/sdg2       200908798 234440703  33531906   16G  5 Extended                                                                                                                                         
/dev/sdg5       200908800 234440703  33531904   16G fd Linux RAID autodetect                                                                                                                            
                                                                                                                                                                                                                                                                                                                                                                                                                   
Disk /dev/sdh: 111.8 GiB, 120034123776 bytes, 234441648 sectors                                                                                                                                         
Units: sectors of 1 * 512 = 512 bytes                                                                                                                                                                   
Sector size (logical/physical): 512 bytes / 512 bytes                                                                                                                                                   
I/O size (minimum/optimal): 512 bytes / 512 bytes                                                                                                                                                       
Disklabel type: dos
Disklabel type: dos                                                                                                                                                                                     
Disk identifier: 0x0001cb75

Device     Boot     Start       End   Sectors  Size Id Type
/dev/sdh1  *         2048 200906751 200904704 95.8G fd Linux RAID autodetect
/dev/sdh2       200908798 234440703  33531906   16G  5 Extended
/dev/sdh5       200908800 234440703  33531904   16G fd Linux RAID autodetect

/dev/md0挂载在 root (ext4) 上，并被/dev/md1分配为交换分区。

如果我能够将系统转换为 LVM，我将取消物理交换分区，只创建一个 LVM 交换分区。我想这也可能有助于迁移过程，因为它会释放当前 SSD 上的一些空间。

有什么想法吗？谢谢。

lvm raid uefi

1 个回答

  1. Best Answer

    好吧，我设法完成了这次迁移，尽管尝试了几次。

    方法总结

    我最终没有采用我最初考虑的任何方法。相反，我的方法涉及：

    • 在新 SSD 上创建新分区方案（EFI 引导分区加根分区）
    • 在 EFI 引导分区上安装 UEFI 引导加载程序
    • 在根分区上创建 RAID 1 阵列
    • 使用 RAID 1 阵列创建 LVM 物理卷并使用该卷创建 LVM 卷组
    • 在该卷组上创建 LVM 根逻辑卷
    • 将根分区的内容从旧 SSD 复制到新 SSD
    • 在 RAID 1 阵列上的卷组上创建 LVM 交换逻辑卷
    • 整理

    我的第一次尝试涉及手动创建分区并在这些分区上手动安装 UEFI 引导加载程序。在此过程中发生了一些小失误后，最终在新 SSD 上建立了一个可引导系统，但使用了错误的引导加载程序（后备BOOTX64.EFI而不是 Ubuntugrubx64.efi或shimx64.efi引导加载程序）。

    有可能我可以通过执行下面的步骤 27 来解决这个问题，但这是我在执行第二次尝试之前没有发现的步骤。但现在请参阅此答案的附录。

    所以我重新开始了整个过程。

    第二次尝试涉及使用 Ubuntu Live USB 在其中一个新 SSD 上执行全新安装（使用我的新分区方案，但没有 RAID 或 LVM）。我认为这会给我一个反映 Ubuntu 默认值（大小、内容）的 EFI 引导分区。

    这种方法还让我有机会记下默认安装包含哪些参数/etc/fstab，因此我可以在新安装中正确复制这些参数。

    Ubuntu Live USB 完成默认安装后，我将 EFI 引导分区复制到另一个 SSD。然后我删除了已安装的根分区并用新分区替换它，以擦除已安装的操作系统。然后我在另一个 SSD 上复制了该分区，并继续我的其余步骤（创建 RAID 阵列等）。

    正如您将看到的，这样做的结果是系统最初没有启动，但我设法将其从系统中解救出来grub，现在一切都很好。

    请继续阅读详细步骤。我必须承认，这些步骤在某种程度上是对我所做工作的重构，因为我在此过程中遇到了一些小曲折，但从根本上说，我在下面概述的内容是对我所做工作实质的准确反映。

    参考

    在准备和实施我的两次尝试时，我参考了一些教程，特别包括：

    没有一个完全符合我的用例，并且概述的一些步骤实际上给我带来了问题，但它们确实以各种方式提供了帮助。

    所有细节

    设置场景：

    • 我的安装是 Ubuntu 18.04.3 LTS
    • 我的旧安装在我的旧 SSD 上打开/dev/md0了一个交换分区/dev/md1
    • 我还在单独的 HDD 上有一个 RAID 6 数据阵列 ( /dev/md2)，我想在新安装时保留它
    • 我的新 SSD 是/dev/nvme0n1和/dev/nvme1n1

    现在的步骤：

    步骤1

    这第一步我实际上并没有做，但事后看来它可能有所帮助。它涉及通过安装在 UEFI 下运行时需要的一些软件包来准备我的旧 Ubuntu 安装（我最终会复制的那个）。因此，当启动到我的旧安装时：

    $ sudo apt-get update
$ sudo apt-get install grub-efi-amd64 efibootmgr

    第2步

    在继续之前，我在旧安装中禁用了交换分区，只是为了避免在复制根分区内容时保留任何旧设置。我不确定这是否是一个实际问题，但想确定：

    $ sudo swapoff /dev/md1

    然后我在我最喜欢的文本编辑器中更新/etc/fstab以注释掉交换条目，然后：

    $ sudo mount -a

    第 3 步

    然后我在 UEFI 模式下启动到 Ubuntu Live USB（桌面版本，而不是服务器版本，虽然我的安装是服务器），并选择了“安装 Ubuntu”。您可能需要调整主板固件设置以确保以 UEFI 模式启动。

    我想我也可以在此步骤中使用服务器版本，但考虑到我需要桌面版本来执行后续步骤，我决定让事情变得简单。

    我选择了引导式安装，选择使用我的第一个新 SSD ( /dev/nvme0n1) 并使用整个驱动器进行安装。我没有设置 RAID 或 LVM。这导致 (a) 一个 EFI 引导分区和 (b) 一个根分区，占用了安装 Ubuntu Desktop 的驱动器的其余部分。

    第4步

    完成后，我以 UEFI 模式重新启动到 Ubuntu Live USB，这次选择“尝试 Ubuntu 而不安装”。您可以通过打开终端 (Ctrl-Alt-T) 并运行以下命令来测试您是否处于 UEFI 模式：

    $ ls /sys/firmware/efi

    如果这显示了许多文件，则您处于 UEFI 模式。

    第 5 步

    在终端提示符下，我升级了 Ubuntu Live 并安装了所需的软件包：

    $ sudo apt-get update && sudo apt-get dist-upgrade
$ sudo apt-get install -y mdadm

    第 6 步

    然后我检查了新安装的分区方案，以便可以在另一个 SSD 上正确复制它：

    $ sudo parted /dev/nvme0n1
(parted) unit MiB print
Model: Samsung SSD 970 EVO Plus 500GB (nvme)
Disk /dev/nvme0n1: 476940MiB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start    End        Size       File system  Name                  Flags
 1      1.00MiB  513MiB     512MiB     fat32        EFI System Partition  boot, esp
 2      513MiB   476939MiB  476426MiB  ext4         

(parted) quit

    这表明默认 EFI 分区的大小为 512 MiB，从驱动器的开头开始 1 MiB，具有 FAT32 文件系统。

    第 7 步

    然后，我还检查了默认挂载参数/etc/fstab（UUID 在下面被屏蔽为“NUMBER”）：

    $ sudo mkdir -p /mnt/newroot
$ sudo mount /dev/nvme0n1p2 /mnt/newroot
$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
## / was on /dev/nvme0n1p2 during installation

UUID=NUMBER /               ext4    errors=remount-ro 0       1

# /boot/efi was on /dev/nvme0n1p1 during installation

UUID=NUMBER  /boot/efi       vfat    umask=0077      0       1

/swapfile                                 none            swap    sw              0       0

$ sudo umount /mnt/newroot

    我记下了这些参数，以便以后可以复制它们。

    第 8 步

    然后我删除了我的第一个 SSD 上已安装的根分区，以删除桌面安装，并在其位置创建了一个新分区（相同大小）。请注意，我没有使用任何文件系统类型创建它，因为 RAID 阵列和 LVM 卷组将覆盖在顶部：

    $ sudo parted -a optimal /dev/nvme0n1
(parted) rm
Partition number? 2
(parted) mkpart primary 513MiB 100%
(parted) name 2 "Ubuntu Filesystem"
(parted) align-check optimal 2
(parted) set 2 raid on

    第 9 步

    在 parted 交互提示符下，我选择了另一个新的 SSD ( /dev/nvme1n1) 来复制分区方案：

    (parted) select /dev/nvme1n1
(parted) mklabel gpt
(parted) mkpart primary fat32 1MiB 513MiB
(parted) set 1 esp on
(parted) set 1 boot on
(parted) mkpart primary 513MiB 100%
(parted) name 2 "Ubuntu Filesystem"
(parted) align-check optimal 2
(parted) set 2 raid on
(parted) unit MiB print
Model: Samsung SSD 970 EVO Plus 500GB (nvme)
Disk /dev/nvme1n1: 476940MiB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start    End        Size       File system  Name                  Flags
 1      1.00MiB  513MiB     512MiB     fat32        EFI System Partition  boot, esp
 2      513MiB   476939MiB  476426MiB  ext4         Ubuntu Filesystem     raid

(parted) quit

    第 10 步

    然后我在根分区上创建了一个 RAID 1 阵列，/dev/nvme0n1p2并且/dev/nvme1n1p2. 我调用它是/dev/md3为了将它与我的旧系统下已经创建的 RAID 阵列区分开来，并避免在迁移过程中发生命名冲突，目的是稍后在新系统启动并运行时对其进行重命名：

    $ sudo mdadm --create --bitmap=internal /dev/md3 --level=1 --raid-devices=2 /dev/nvme0n1p2 /dev/nvme1n1p2

    我等到 RAID 阵列完成同步后再继续，通过检查：

    $ cat /proc/mdstat

    第 11 步

    然后，我从 RAID 1 阵列中创建了一个 LVM 物理卷，其中一个卷组（称为vgmain）使用该物理卷，然后在该卷组上创建了一个 LVM 根逻辑卷（称为lvroot，大小为 100 GiB）：

    $ sudo pvcreate /dev/md3
$ sudo vgcreate vgmain /dev/md3
$ sudo lvcreate -L 100G -n lvroot vgmain

    第 12 步

    然后我在根逻辑卷上创建了一个 EXT4 文件系统：

    $ sudo mkfs.ext4 -b 4096 -E stride=128,stripe-width=256 /dev/vgmain/lvroot

    第 13 步

    此时我组装了旧的 RAID 设备，以便我的旧根分区 ( /dev/md0) 可用于从中复制数据。显然，要做到这一点，我的旧 SSD 仍然必须连接并通电：

    $ sudo mdadm --assemble --scan

    第 14 步

    组装后，我安装了旧的根分区：

    $ sudo mkdir -p /mnt/oldroot
$ sudo mount /dev/md0 /mnt/oldroot

    第 15 步

    我还挂载了新的根分区（请记住之前在步骤 7 中已创建挂载点）：

    $ sudo mount /dev/vgmain/lvroot /mnt/newroot

    第 16 步

    现在我可以将旧根分区的内容复制到新分区：

    $ sudo rsync -axHAX --progress /mnt/oldroot/ /mnt/newroot

    第 17 步

    完成后，可以卸载旧的根分区并停止旧的 RAID 阵列：

    $ sudo umount /mnt/oldroot
$ sudo mdadm --stop /dev/md0

    步骤 18

    现在跑题了。事后看来，如果我此时执行了第 27 步，我最后遇到的引导问题可能是可以避免的。为此，我将执行以下操作：

    $ sudo mkdir -p /mnt/newroot/boot/efi
$ sudo mount /dev/nvme0n1p1 /mnt/newroot/boot/efi
$ for d in /dev /dev/pts /sys /proc; do sudo mount -B $d /mnt/newroot$d; done
$ sudo chroot /mnt/newroot
# grub-install
# update-grub
# umount /dev/nvme0n1p1

    我不确定这是否会解决以后遇到的问题，但确实如此。但现在请参阅此答案的附录。

    步骤 19

    回到我实际上做了什么。将旧根分区的内容复制到新的根分区（当然是在 RAID 1 阵列中镜像）后，我需要将 EFI 引导分区的内容从第一个 SSD 复制到第二个 SSD：

    $ sudo dd if=/dev/nvme0n1p1 of=/dev/nvme1n1p1

    为了检查这是否成功，我检查了每个上的 UUID 在完成后是否相同：

    $ sudo blkid

    步骤 20

    为了完整起见，我还想让第二个 SSD 进入启动链，以确保我可以愉快地从任一 SSD 启动。在这个阶段，新的根分区仍然挂载，但我还需要从 Ubuntu Live USB 挂载其他目录（如果我已经实施了第 18 步，我就不必在此处挂载这些目录）：

    $ for d in /dev /dev/pts /sys /proc; do sudo mount -B $d /mnt/newroot$d; done
$ sudo chroot /mnt/newroot
# efibootmgr -v

## Comment: The above command showed me the file entry for "ubuntu", which in my case was
## \EFI\ubuntu\grubx64.efi (I could have also used \EFI\ubuntu\shimx64.efi).
## I then used that in the next command

# efibootmgr -c -d /dev/nvme1n1 -p 1 -L ubuntu -l '\EFI\ubuntu\grubx64.efi'

    显然，achroot对新 SSD 的影响是我进入了那个环境，就好像我被引导进入它一样，所以我在监狱中运行的命令是在 SSD 上执行的，而不是在 Ubuntu Live USB 上执行的。在chroot监狱中，命令以 root 身份运行（如“#”提示符所示），因此sudo不是必需的。当然，考虑到 SSD 并未真正启动，我不得不从 Ubuntu Live USB 挂载一些关键目录，以提供所需的功能。

    （顺便说一句，我必须注意，由于我实际上没有完成第 1 步，所以当我尝试运行时efibootmgr发现它没有安装，因为我已经复制了我的旧版安装，即 MBR/BIOS 安装。所以我必须在这个阶段安装它。为此，我发现我还需要/run从 Ubuntu Live USB 挂载，才能访问互联网。我也安装了grub-efi-amd64。）

    步骤 21

    我还通过/dev/nvme0n1p1检查. 如有必要，可以通过使用每个相关磁盘或分区的 4 位代码运行以下命令来固定顺序，按所需顺序，例如：/dev/nvme1n1p1efibootmgr -v

    # efibootmgr -o 0000,0001,0002,0005,0004

    步骤 22

    然后，我使用我最喜欢的文本编辑器进行了更新/etc/fstab，以包含根挂载点和/boot/efi挂载点的新 UUID（由 确定blkid）。我使用了第 7 步中的参数，添加noatime到根挂载点（与我的旧安装一致）。

    当然，我保留了旧数据 RAID 6 阵列的挂载点条目，因为它将继续用于新安装以及挂载点保护/tmp。

    步骤 23

    新 SSD 上 mdadm 的配置详细信息也需要更新，我/dev/md3通过以下命令添加新阵列的详细信息，然后使用我的文本编辑器手动编辑以/etc/mdadm/mdadm.conf确保旧的旧/dev/md0条目/dev/md1删除：

    # mdadm --examine --scan >> /etc/mdadm/mdadm.conf

    清理配置文件后，我运行：

    # update-initramfs -u

    步骤 24

    在这一点上我基本上已经完成了（或者我是这么认为的）。所以为了一个干净的完成，我退出chroot并卸载了所有东西：

    # exit
$ for d in /dev /dev/pts /sys /proc; do sudo umount /mnt/newroot$d; done
$ sudo umount /mnt/newroot

    步骤 25

    最后，关键时刻——我移除了 Ubuntu Live USB，并重新启动了系统，检查了我的主板固件，启动顺序在顶部有我的第一个新 SSD，这样我就可以从/dev/nvme0n1p1. 如有必要，您可以在启动时检查从哪个驱动器启动，方法是运行efibootmgr -v.

    步骤 26

    不过，此时我遇到了启动问题。系统无法启动，并在grub提示符处停止。为了解决这个问题，我在提示符处执行了以下操作：

    grub> ls

## Comment: The above command showed me the available partitions and directories, so I knew
## what my root partition was called and could use it in the next command

grub> set root=(lvm/vgmain-lvroot)
grub> linux /vmlinuz root=/dev/mapper/vgmain-lvroot
grub> initrd /initrd.img
grub> boot

    步骤 27

    这样做让我进入了新的 SSD。那时，我运行了以下命令，如果我在第 18 步执行了这些操作，则可能没有必要：

    $ sudo grub-install
$ sudo update-grub

    我发现运行这些命令后，in 的大小发生grubx64.efi了/boot/efi/EFI/ubuntu变化，因此原始引导加载程序安装似乎有问题。但现在请参阅此答案的附录。

    步骤 28

    然后我重复步骤 19 和 20 中的相关命令，将更新后的 EFI 引导分区的内容从 复制/dev/nvme0n1p1到/dev/nvme1n1p1，并更新引导链。如果您发现有旧条目也需要删除，请使用：

    $ sudo efibootmgr -b 0003 -B  # Eg to delete entry Boot0003

    步骤 29

    最后我重新创建了我的交换分区，这次是一个 LVM 逻辑卷：

    $ sudo lvcreate -L 16G -n lvswap vgmain
$ sudo mkswap /dev/vgmain/lvswap
$ sudo swapon /dev/vgmain/lvswap

    并/etc/fstab使用相关的 UUID 和步骤 7 中确定的参数进行更新：

    UUID=NUMBER none    swap    sw  0   0

    就是这样！我现在拥有一个完全迁移且正常运行的系统。我最终会将我的新 RAID 1 重命名为md0（仅出于强迫症的原因），但那是另一天。

    附录

    项目 1

    我在尝试迁移之前研究的预备教程说，在开始之前应该在主板固件上禁用安全启动。我没有这样做，因为我发现我的主板（华硕）很难做到这一点（我已经研究过它，发现可以通过删除安全启动密钥来完成）。我的启动问题可能是由于安全启动仍在运行引起的。

    第 2 项

    在 UEFI 模式下引导迁移的系统时，您会发现它会在 grub 菜单中暂停 30 秒，然后再继续。这显然是为了让用户有时间访问菜单，因为在某些情况下它可能会变得无法访问。如果您对启动时间的额外延迟感到恼火，您可以通过将以下内容添加到以下内容来减少这种情况/etc/default/grub：

    GRUB_RECORDFAIL_TIMEOUT=5  # Eg to reduce to five seconds

    不要将其减少到零。接着：

    $ sudo update-grub
    • 0

相关问题