I am migrating an installation of Solus from a single, LUKS-encrypted disk to a LUKS-encrypted MD mirror. Other than /boot, SWAP and root filesystems are LVs on a single VG. The old drive is a 60GB SSD. The new drives are 128GB SATADOMs. I know Solus is kind of a nonstandard choice, but everything I’m dealing with here is pretty distro-agnostic.
Here’s what I did:
I partitioned the drives (GPT), and set up 2 MD mirrors, one for /boot (with metadata=.90 option) ,and one for LUKS. I setup LUKS on the second mirror, and added the new LUKS device to /etc/crypttab.
I used dd to migrate /boot to the unencrypted mirror. I unmounted the old /boot and mounted the new one. No problems.
I extended the VG to the new LUKS device and used pvmove to migrate root and SWAP LVs to the new MD/LUKS device. I then removed the original, single-disk LUKS device from the VG. /boot, root and SWAP all migrated at this point. All good. I removed the original PV, LUKS and zero’d the disk. I am now positively running on the new mirrored drives.
I updated fstab with appropriate UUIDs. I installed GRUB on both SATADOMs (after adding requisite biosboot partitions). I updated the LUKS UUID in grub.cfg, rebooted and changed boot device in the BIOS.
Now the system is in endless reboot cycle. I am not seeing any evidence of GRUB loading up at all.
What do I do now? VG and LV UUIDs are unchanged, so I shouldn’t have had to change those anywhere. Something must not be right with GRUB, right?
I’m booting BIOS, not UEFI, although if switching to UEFI is an easier option at this point, I’m ok with it. I currently have no /boot/efi partition though.
If you have an MBR (Master Boot Record) type partition table, all you need to do is to set a boot flag on the root filesystem /. However, if you have a GPT partition table, you need to create a separate BIOS boot partition and install GRUB to it.
I did:
create a separate BIOS boot partition and install GRUB to it
on both drives in the mirror. Is that right?
It’s funny, I know this is kind of basic stuff, but until now, I’ve only dealt with servers with static hardware configs and VM’s, so I’ve just never had to do this before.
Creating a partition and installing GRUB is definitely something that needs to happen, but the boot flag is something that usually gets set by the tool that you use to format the disk.
Hop into a Linux live CD. Fire up a terminal and cfdisk your new drive, assuming sda.
cfdisk /dev/sda
You should be able to quickly identify which partition is your boot partition, as it’s generally the smallest (and usually at the top of the list). Make sure it’s highlighted, and in the menu at the bottom of the screen navigate to the [ bootable ] menu item, and hit enter. When you toggle the boot option on a partition, you should see an asterisk appear/disappear. If it’s there, the partition is bootable, if it is not there, the partition is not bootable. Make sure the asterisk is there, and then [ write ] and [ quit ].
Yeah, no problem. I have done this to setup bootable USB’s, but I thought it wasn’t necessary when you add the biosboot partition to a GPT drive.
Admittedly, I usually just use MBR unless I’m using a large system drive, so I don’t have a lot of experience with GPT. I went with GPT here because it’s generally more robust, and I expect my workstation to take more abuse than a single-purpose server.
You need to create a BIOS Boot (biosboot) partition to install on a BIOS system where the disk containing the boot loader uses GPT. The biosboot partition should be 1 MiB in size. However, you do not need the biosboot partition if the disk containing the boot loader uses MBR.
You still have to point out to the BIOS that you have a bootable partition. I thought that the BIOSBOOT was for CMS. or Bios Comapitbility Mode (for UEFI)
I finally migrated to using UEFI 3 years ago. All of my drives have GPT and all of my new drives have GPT. Before, I could only get BIOS to boot from drives with MBR.
I’ve made a lot of progress here. I think I just have one last obstacle. It’s actually been a great learning experience since I had virtually no experience with EFI/GPT.
I’ve gotten to the point of getting into the initramfs, but mdadm is missing, so it isn’t able to assemble my root mirror and boot into the OS.
I’ve opened a ticket with Solus to see what I should do. They use a monolithic tool called clr-boot-manager to handle all the booting stuff, so there’s no update-initramfs for me to play with.
I finally arrived at a solution. MD is simply not supported by Solus, so I just migrated from one drive to another. My original /boot partition was history, so it was just a matter of generating a new one that would point to my old installation on the new drive.
In Solus, generating the contents of the /boot partition from scratch by chrooting in and running clr-boot-manager update (and updating fstab), got me as far as booting into a black screen with a blinking cursor. This would happen regardless of MBR/EFI and LUKS (yes, proper partition flags were in place).
Here’s the process that worked for me.
From a Solus live USB:
Decrypt and chroot into the existing installation (don’t forget to mount --bind/proc, /dev, /sys and /run). Run eopkg up -y.
Rename the volume group of the to-be-recovered installation: vgrename SolusSystem OldSolusSystem
Install a fresh LUKS/LVM Solus onto the new drive.
chroot into the fresh installation and run eopkg up -y
Copy /etc/fstab and /etc/grub* from the fresh installation to the to-be-recovered installation.
Block copy over the root LV of the fresh install: dd if=/dev/mapper/OldSolusSystem-Root of=/dev/mapper/SolusSystem-Root bs=1M
chroot into the root partition that was just copied over (SolusSystem-Root) and run clr-boot-manager update
Take out the old drive (or reformat it if you’re feeling ballsy)
Reboot and grub should boot into the recovered OS. Run lsblk to confirm, and resize2fs or whatever, and then all is good.
