#gen10plus

👇👇👇 👉 HPE MICROSVR GEN10+ ILO ✅Brand: HPE ✅SKU: P13788-B21 ✅Condition: New ✅Delivery: Can Ship Today Contact Us: 👇👇👇 📧[email protected] 🔗https://miatlantic.us/p13788-b21

👉 HPE ProLiant Micro Server Gen10 Plus E-2224 S100i 4LFF-NHP 1TB 180W External PS Server ✅Brand: HPE ✅SKU: P18584-001 ✅Condition: New ✅Delivery: Can Ship Today* Contact Us: 👇👇👇 📧[email protected] 🔗https://miatlantic.us/p18584-001

I've blogged about my HPE ProLiant MicroServer Gen10+ in the past. As boot drive, I put in a SK Hynix Gold S31 SSD in one of the 3.5" slots using an adapter. The remaining three disk slots are used for my spinning media OpenZFS pool. Two problems presented themselves, one I could predict, the other a bit unexpectedly. The former problem is that I have my home directory on the spinning media OpenZFS pool, this, by today's standards, is quite dreadfully slow, given I serve my home directory over NFS in certain situation. It's like being back at the late nineties. I'm not a huge fan of keeping this data on a single drive either, as I had planned to move my home directory over to the SSD and just keep copies of the home directory on the spinning media pool. Unless, the unexpected problem, the SSD comes to a screeching halt at times, for no apparent reason. Sometimes it performs well and sometimes it's single digit throughput (MB/s). Unusable. I opened a support case with SK Hynix who got back to me with the very unexpected response that I should install Windows. Bye-bye, SK Hynix, you are the absolute worst.

So, here I am.

Problem solving mode

Since I don't have two 2.5" slots to spare for mirrored boot and home directory, I needed to get creative. External drives? USB? eSATA? SAS? Thanks to the extremely well done research by Serve The Home, I did not have to look far. Since the Gen10+ has a spare PCIe slog, it's possible to put two NVMe drives using a PCIe to M.2 adapter card. Said and done, I picked up the StarTech PEX8M2E2 adapter along with two 1TB WD Blue SN550 M.2 2280 NVMe drives.

Presto!

Edit: As snarled at on reddit, bifurcation is not needed with the StarTech card.

Surgery options

The next decision I had to make was if I had to reinstall the system on these drives. If so, would I install on a RAID1 or try cobble the disks together with OpenZFS pre- or post-install? (Ubuntu installer does not yet support any advanced OpenZFS pool schemes, AFAIK). Friends don't let friends to OpenZFS on RAID, so I would end up doing post-install surgery and I simply took the challenge of doing in-place replacement of the SSD onto a NVMe drive and make the OpenZFS pools mirrored (there's one boot pool and one system pool with the default Ubuntu install). My Google Fu completely failed me and I could only find obscenely written guides or vague evidence on how to do this and I decided to DIY since my situation was fairly unique. Going from single SSD to two NVMe drives in one swift stroke.

I hereby present the 100% unofficial guide on how to transfer a Ubuntu 20.04 installation from a single device to two devices, mirrored.

A few pointers.

Keep backups of your data

What works on my computer might not work on yours

What will happen in subsequent updates of Ubuntu if packages touches /boot/efi is unknown at this time

The copy & paste verbiage below is from a VM I practiced on

The practice VM could successfully boot from a single drive if there was a failure

Let's get to it.

Device and partition duplication

As mentioned above, these steps were performed on a VM, not an actual Gen10+. Device names, partition schemes, size and who knows what, WILL differ on your system. Use these steps as guidance, not a copy & and paste template.

Note: All commands below are executed as root.

First, get an idea of what your partition layout looks like on your system with lsblk.

lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0 7:0 0 255.6M 1 loop /snap/gnome-3-34-1804/36 loop1 7:1 0 55.3M 1 loop /snap/core18/1885 loop2 7:2 0 49.8M 1 loop /snap/snap-store/467 loop3 7:3 0 62.1M 1 loop /snap/gtk-common-themes/1506 loop4 7:4 0 29.9M 1 loop /snap/snapd/8790 sda 8:0 0 20G 0 disk ├─sda1 8:1 0 512M 0 part /boot/efi ├─sda2 8:2 0 923M 0 part [SWAP] ├─sda3 8:3 0 998M 0 part └─sda4 8:4 0 17.6G 0 part sdb 8:16 0 20G 0 disk sdc 8:32 0 20G 0 disk sr0 11:0 1 2.6G 0 rom /media/mmattsson/Ubuntu 20.04.1 LTS amd64

The drive of interest here is sda. Dump the partition table to a file.

sfdisk -d /dev/sda > layout-sdb

Your layout-sdb file will initially look something like this.

label: gpt label-id: 0A00C51C-DF26-4237-90F2-28D80EB7542F device: /dev/sda unit: sectors first-lba: 34 last-lba: 41943006 /dev/sda1 : start= 2048, size= 1048576, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=427FBDD1-8CEF-4E2B-9BE1-837BBB3CC087, name="EFI System Partition" /dev/sda2 : start= 1050624, size= 1890304, type=0657FD6D-A4AB-43C4-84E5-0933C84B4F4F, uuid=165B2B55-3BC1-B345-B3EC-5285EBF368BA /dev/sda3 : start= 2940928, size= 2043904, type=6A82CB45-1DD2-11B2-99A6-080020736631, uuid=E43AE096-6764-1245-A9A7-FA091DE6FAEE /dev/sda4 : start= 4984832, size= 36958175, type=6A85CF4D-1DD2-11B2-99A6-080020736631, uuid=8850142A-8094-9B47-88EA-F1ECDB45C4AE

Edit the layout and have these steps in mind: - Change the label-id, I simply decreased the last hex value by one for each disk - Change the source device name to the destination device name - Remove the UUIDs (new ones will be generated)

The results should look like this:

label: gpt label-id: 0A00C51C-DF26-4237-90F2-28D80EB7542E device: /dev/sdb unit: sectors first-lba: 34 last-lba: 41943006 /dev/sdb1 : start= 2048, size= 1048576, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, name="EFI System Partition" /dev/sdb2 : start= 1050624, size= 1890304, type=0657FD6D-A4AB-43C4-84E5-0933C84B4F4F /dev/sdb3 : start= 2940928, size= 2043904, type=6A82CB45-1DD2-11B2-99A6-080020736631 /dev/sdb4 : start= 4984832, size= 36958175, type=6A85CF4D-1DD2-11B2-99A6-080020736631

Next, copy the edited layout to your next "disk".

cp layout-sdb layout-sdc

Change the values you just changed (decrease the label-id) to the new disk name. The result should look like this.

label: gpt label-id: 0A00C51C-DF26-4237-90F2-28D80EB7542D device: /dev/sdc unit: sectors first-lba: 34 last-lba: 41943006 /dev/sdc1 : start= 2048, size= 1048576, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, name="EFI System Partition" /dev/sdc2 : start= 1050624, size= 1890304, type=0657FD6D-A4AB-43C4-84E5-0933C84B4F4F /dev/sdc3 : start= 2940928, size= 2043904, type=6A82CB45-1DD2-11B2-99A6-080020736631 /dev/sdc4 : start= 4984832, size= 36958175, type=6A85CF4D-1DD2-11B2-99A6-080020736631

Next, "apply" the new partition tables onto your new disks.

sfdisk /dev/sdb ../../sda3 lrwxrwxrwx 1 root root 10 Aug 16 12:36 8850142a-8094-9b47-88ea-f1ecdb45c4ae -> ../../sda4 lrwxrwxrwx 1 root root 10 Aug 16 12:36 165b2b55-3bc1-b345-b3ec-5285ebf368ba -> ../../sda2 lrwxrwxrwx 1 root root 10 Aug 16 12:36 427fbdd1-8cef-4e2b-9be1-837bbb3cc087 -> ../../sda1 lrwxrwxrwx 1 root root 10 Aug 16 12:44 e3115c86-4bc9-b14a-ab62-90efdb67a5af -> ../../sdb3 lrwxrwxrwx 1 root root 10 Aug 16 12:44 edde5235-ceac-f54b-b9cd-279b46c0a996 -> ../../sdb4 lrwxrwxrwx 1 root root 10 Aug 16 12:45 a749fd64-615e-da4b-9ba4-86023a5d7542 -> ../../sdc3 lrwxrwxrwx 1 root root 10 Aug 16 12:45 581ed7e7-1d93-0c4b-b9ce-b690763b0b38 -> ../../sdc4 lrwxrwxrwx 1 root root 10 Aug 16 12:56 183e59f6-84af-124a-9904-07a824ece292 -> ../../sdb1 lrwxrwxrwx 1 root root 10 Aug 16 12:56 f8c90bc4-0a48-094b-8967-46f8e65fde03 -> ../../sdc1 lrwxrwxrwx 1 root root 10 Aug 16 12:56 693f6ba7-499f-d841-9631-2a3d089e602f -> ../../sdb2 lrwxrwxrwx 1 root root 10 Aug 16 12:56 3ab0018f-ba13-6f40-905a-af49456f6788 -> ../../sdc2

In the output above we can see that the UUID maps to sda3. The next set of UUIDs that matter is the ones that use sdb3 and sdc3, as these correspond to the partition UUIDs on our new drives.

When we got the UUIDs, attach the new devices to the current device (this will effectively mirror them).

zpool attach bpool e43ae096-6764-1245-a9a7-fa091de6faee e3115c86-4bc9-b14a-ab62-90efdb67a5af zpool attach bpool e43ae096-6764-1245-a9a7-fa091de6faee a749fd64-615e-da4b-9ba4-86023a5d7542

Checking the status of the pool, we should observe a three=way mirror.

zpool status bpool pool: bpool state: ONLINE scan: resilvered 92.3M in 0 days 00:00:01 with 0 errors on Sun Aug 16 13:05:13 2020 config: NAME STATE READ WRITE CKSUM bpool ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 e43ae096-6764-1245-a9a7-fa091de6faee ONLINE 0 0 0 e3115c86-4bc9-b14a-ab62-90efdb67a5af ONLINE 0 0 0 a749fd64-615e-da4b-9ba4-86023a5d7542 ONLINE 0 0 0 errors: No known data errors

It's now safe to remove the old device from the pool.

zpool detach bpool e43ae096-6764-1245-a9a7-fa091de6faee

Now bpool is done. Repeat the exact same procedure for rpool. Once that is done, power off the system, remove the old disk, make sure the boot order is correct in the BIOS and boot into the new system. Grub will throw an exclamation upon boot saying that it's falling back to defaults, this seems to be what should be happening as the system will come up and behave just fine on subsequent boots.

Summary

Do not try this without understanding how to help yourself to back out of the situation and do not perform any of these procedures on devices where you care about the data (have backups if you do).

My Gen10+ ended up with bpool and rpool looking like this after first boot.

zpool status pool: bpool state: ONLINE scan: resilvered 937M in 0 days 00:00:01 with 0 errors on Sun Aug 16 13:39:05 2020 config: NAME STATE READ WRITE CKSUM bpool ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 nvme0n1p3 ONLINE 0 0 0 nvme1n1p3 ONLINE 0 0 0 errors: No known data errors pool: rpool state: ONLINE scan: resilvered 24.3G in 0 days 00:00:41 with 0 errors on Sun Aug 16 13:41:43 2020 config: NAME STATE READ WRITE CKSUM rpool ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 nvme0n1p4 ONLINE 0 0 0 nvme1n1p4 ONLINE 0 0 0 errors: No known data errors

I also snapped a picture of the snug fit with the StarTech NVMe card in the Gen10+