I’ve booted to Grub a couple of times in the last two months, i.e., the system failed to boot vmlinux from the SATA DOM.
If the hardware is solid, that should be impossible unless there is a hardware problem with the SATA DOM I’m using in the Supermicro to boot from, right?
The boot-pool is always mounted read only by truenas so I don’t understand how it can be corrupted from TrueNAS (and I’m not running anything else on the box).
Either there is a software bug (in which case everyone will have the problem), or my SATA DOM (SuperDOM) is flakey.
I’m leaning to the latter. Am I correct?
Second question: Can I just dd the SATA DOM device to a second SATA DOM device? Or are there specific customizations?
That way if one fails, I can just dd the working one to the failed one (assuming it is still alive).
There’s no reason to. Just install fresh and load your exported config file, and you’re back in business. No need to juggle with the boot devices or do any sort of cloning or imaging.
(This is a good time to make sure you indeed have an up-to-date config file exported and safely secured somewhere. Same for your encrypted dataset keys.)
It may just be coincidence, but I had two hangs with a week or two in between and had to do a hard reset, and when I tried to reboot my boot drive’s GPT primary partition table had been corrupted.
I am just wondering whether they might have a common cause - though I have no idea what the cause is on my system.
In my case it doesn’t boot because the BIOS cannot find the EUFI boot details on a drive which it cannot read because the Primary GPT Partition Table is corrupt. So it never gets to GRUB.
I suspect that the prior hang is a result of the operating system detecting that the GPT Partition Table has changed and attempting to reload it, losing the details of the boot drive and then HALTing. But I don’t keep a monitor attached to the HDMI port and powered on so I cannot see what happened.
