fixed emojis on media server article

1 files changed, 2 insertions, 2 deletions

diff --git a/content/projects/media_server.md b/content/projects/media_server.md
index ae737a6..e581a15 100644
--- a/content/projects/media_server.md
+++ b/content/projects/media_server.md
@@ -37,8 +37,8 @@ Now, for full redundancy, I had to make sure *everything* got replicated, becaus
 
 The method in which we setup our server is a bit unconventional (At least I think, I've never heard of a setup like this before). I used the beginning 500MB partitions as the EFI boot partition, duplicated among all 6 drives using mdadm's RAID1 and **metadata version 1.** The metadata version is the most important part of this setup. By using version 1, you avoid putting the mdadm headers at the beginning of the partition, meaning you can have your filesystem headers at the beginning instead, which is important if the motherboard firmware is to recognize these as proper boot partitions. Since the metadata is not at the front, I simply mounted the `/dev/md0` entry that was created after adding them all to an array and wrote my FAT32 filesystem with the proper flags set to it. Lo and behold, when I went back to look at the separate partitions, they all appeared to be "formatted" using the same FAT32 filesystem with the exact same data. Perfect! Our bootloader is fully redundant. I just added an entry for each drive in the motherboard's firmware so it will just run through all the drives and boot using the first one that's aailable, falling back if necessary.
 
-For the actual operating system, I used ZFS in a raidz1 setup. This is akin to a RAID5 array. It gives you one drive failure before you begin to lose any data. Since I was basing this install on Arch (I wanted to install the least number of packages possible, this is simply a base OS for KVM to manage virtual machines.), I installed the zfs-dkim package from the AUR and let it compile for my kernel. Once it was fully installed, I created the pool using the second partition from all the drives I had available. We were just going to make one big partition that contained the system and the VM images all in one. Once I made the volume that the system would reside on, I followed the Arch install guide just like any other regular install. The only deviations made were for generating the fstab entries and generating the initcpio image. I followed the Root on ZFS guide from the Arch wiki to generate those properly. Once my system was fully installed, I rebooted and..... nothing :(. I booted back into the live usb I created a few more times, changing various settings to no avail. For whatever reason, the Arch initcpio wouldn't automatically mount our root partition and pivot into it. I could mount it manually just fine, but automounting did not work. Case in point, after a few hours, the fix was simple: just add `zfs=bootfs` to your grub boot entry. That solved our issue and we booted right to the OS.
+For the actual operating system, I used ZFS in a raidz1 setup. This is akin to a RAID5 array. It gives you one drive failure before you begin to lose any data. Since I was basing this install on Arch (I wanted to install the least number of packages possible, this is simply a base OS for KVM to manage virtual machines.), I installed the zfs-dkim package from the AUR and let it compile for my kernel. Once it was fully installed, I created the pool using the second partition from all the drives I had available. We were just going to make one big partition that contained the system and the VM images all in one. Once I made the volume that the system would reside on, I followed the Arch install guide just like any other regular install. The only deviations made were for generating the fstab entries and generating the initcpio image. I followed the Root on ZFS guide from the Arch wiki to generate those properly. Once my system was fully installed, I rebooted and..... nothing :slight_frown:. I booted back into the live usb I created a few more times, changing various settings to no avail. For whatever reason, the Arch initcpio wouldn't automatically mount our root partition and pivot into it. I could mount it manually just fine, but automounting did not work. Case in point, after a few hours, the fix was simple: just add `zfs=bootfs` to your grub boot entry. That solved our issue and we booted right to the OS.
 
 ## Conclusion
 
-This was a really fun project for me to work on over the break. It really got me out of my comfort zone and put me into a new territory of Linux I've never explored before. Coming up with a solution completely on my own, figuring out how to execute it properly, and watching it slowly come to fruition has been very rewrading to say the least. I'm sure at some point we will expand this server again, and I'll probably have to re-learn a lot of things, but hopefully this article taught you (and me when I inevitably have to read through it to figure out what I did) something new :). At the very least, I hope it was an enjoyable read and really put you into my shoes, if not just for a little bit.
+This was a really fun project for me to work on over the break. It really got me out of my comfort zone and put me into a new territory of Linux I've never explored before. Coming up with a solution completely on my own, figuring out how to execute it properly, and watching it slowly come to fruition has been very rewrading to say the least. I'm sure at some point we will expand this server again, and I'll probably have to re-learn a lot of things, but hopefully this article taught you (and me when I inevitably have to read through it to figure out what I did) something new :slight_smile:. At the very least, I hope it was an enjoyable read and really put you into my shoes, if not just for a little bit.