Truenas Scale mirroring the boot pool

[Sepol]

Good morning,

I have a little Scale server, build for a homelab and nextcloud. I started with one boot drive but since I have another X-25M 80GB, same model and size, also very old, but both almost unused, I figure I could use it for boot redundcy. I searched here and on other places and I found the info for Core, but couldn't find for Scale.
Can someone help me on how can I do this, or give me link of a toturial ?

Merry Christmas all.

 

[jgreco]

Are you looking for actual boot redundancy (the words you used) or just to avoid losing your boot device (not necessarily bootable)?

Highly Available Boot Pool Strategy

I've pounded a few versions of this out over the years, but I hate explaining over and over. TrueNAS allows a ZFS boot mirror pool to be created to increase the reliability of the NAS. This sounds great in theory, but there's a flaw. Due to...

www.truenas.com

 

[Sepol]

Ok, I have read your post, and I now underststand why not to use mirror for boot on the motherboard, and only on a LSI RAID card IT flashed, so thank you.
As you asked, yes I only want to avoid losing my boot disk. Because it's a hobby lab I really don't need real redundancy, without downtimes.
So for production 24/7 it's a no no. But I could still make a boot mirror and when the system can't boot by drive failure, I can use the mirror copy ?

 

[jgreco]

You will probably have to mess around in the BIOS to get it to boot from the backup copy, but yes, it's perfectly fine to have a redundant SSD for boot.

 

[Sepol]

In the end that's what I want. A pitty the boot mirror not working as it could or should. Thank you, and a Merry Christmas.

 

[jgreco]

In the end that's what I want. A pitty the boot mirror not working as it could or should. Thank you, and a Merry Christmas.

@Ericloewe (I believe) has been going on about recent evolutions in open source firmware for host systems. We need firmware that is evolved to a point where it can pick up on redundant boot sources and use them if needed. It isn't exactly rocket science, but I'm not expecting to see this for some years at least.

 

[Davvo]

@Ericloewe (I believe) has been going on about recent evolutions in open source firmware for host systems. We need firmware that is evolved to a point where it can pick up on redundant boot sources and use them if needed. It isn't exactly rocket science, but I'm not expecting to see this for some years at least.

To think we went to the moon with 2KB of RAM but today we can't get a BIOS to understand the concept of redundancy.

 

[Ericloewe]

o think we went to the moon with 2KB of RAM

It's actually closer to 4 KB (2K 15-bit+parity words), and the program is read directly from ROM, so there's a bit of an advantage there.

@Ericloewe (I believe) has been going on about recent evolutions in open source firmware for host systems. We need firmware that is evolved to a point where it can pick up on redundant boot sources and use them if needed. It isn't exactly rocket science, but I'm not expecting to see this for some years at least.

There are two independent efforts that are promising:

1. Most relevant to most of us is just UEFI, but implemented with open-source software. Somewhat nascent and not that much in practical use - though I expect significant spillover from the OpenBMC effort, which has gained serious traction for the semi-upcoming AMD Epyc Gen 4 and Intel Xeon Scalable Gen 4 (Supermicro is adopting it in force, for instance). Worth noting that both the system firmware and BMC firmware were "liberated" (in the Soviet sense of the word) by AMI in much of the market - as far as I can tell, all of the x86 server market apart from the big three who push their own extra-proprietary, but somewhat more functional crap; plus significant chunks of the high-end switch market and related enterprise gear.
2. The folks at Oxide are selling a rack-scale system (so not immediately useful to many of us), where, among other things, they boot AMD Epyc Gen 3 servers directly into Illumos from AMD's super-low-level firmware. They basically store the minimum viable kernel, plus NVMe plus ZFS, inside the 32 MB SPI flash that would normally hold the UEFI system firmware. They load up the kernel, initialize PCIe devices and finish booting from NVMe SSDs. This is far more intellectually interesting than "UEFI, but open-source", but is not immediately applicable due to the nature of the work. My hope is that this inspires someone to lift Oxide's code and replicate this functionality on less-integrated systems.
3. (I didn't expect the Spanish Inquisition...) Someone could, theoretically, port ZFS (read-only, mirrors only, etc.) to UEFI and it wouldn't even be that difficult. The greater difficulty is storing the driver - the internal USB Type A header in most systems comes to mind...

Overall, OpenBMC has AMI scared enough of losing a revenue stream that they've had to make conciliatory statements regarding OpenBMC, so things are moving.