Making replacement system mirror drive bootable

[cmh]

Couple weeks/months ago I had questions about replacing a failed boot USB that was part of a two-drive mirror - was trying to figure out which one had failed. Well, I figured it out and replaced it, and it resilvered. I had asked an aside about making sure it was bootable, didn't get an answer but didn't really push it.

Well, tonight I upgraded to the latest version, and the system never came back. Had to run out to the shop and turn on the monitor and see the dreaded blinking cursor on the black screen. Power cycled the system and it went through the BIOS back to the blinking cursor. Tried again just to make sure, then got brave and pulled the newly replaced boot drive. System booted, and I put the drive back in so it'd be present for the mirror once the system was booted.

As the system was booting, I noticed it was doing a grub-install on da1 (the new drive) and then on da0. (the existing drive) Once it was done with that, it rebooted, and booted fine with both drives installed.

So, is there a step that I skipped when I replaced the failed drive, or did I have to manually run the grub-install?

(Yes - I searched the forums and found a bunch of hits that weren't related to OS mirroring and hits that were relevant were not newer than almost three years ago.)

 

[melloa]

Had replaced several failed usb from my FNs and never had this or any other problem.

 

[DrKK]

There's a thing that was a thing.

Back when we first set it up so that boot could be a mirrored pool, it turned out someone forgot to have it do the grub-install on the new device. So, you could resilver the data for the boot device, but the device itself would not be bootable. For some reason, we went back and forth on what to do about this for months in the bug tracker. I had assumed something was done, and that one of the options we spoke of was implemented. I didn't following the endgame very closely.

Apparently, according to your report, there is a combination of events where the grub-install does not occur automatically/sensibly.

So maybe you can find the bug in bugs.freenas.org, and re-open it by describing your exact circumstances?

 

[cmh]

So maybe you can find the bug in bugs.freenas.org, and re-open it by describing your exact circumstances?

I can certainly try. I am unsure if I will be able to provide exactly my procedure, but I'll provide what data I can.

I also asked on the FB group, responses were along the line of melloa. I might have hit an edge case.

 

[melloa]

I can certainly try. I am unsure if I will be able to provide exactly my procedure, but I'll provide what data I can.

I also asked on the FB group, responses were along the line of melloa. I might have hit an edge case.

Not every case is the same, so I'd try to duplicate and re-open that ticket. I did add usb sticks to my FNs and had a failure, but had three and the failed one wasn't the original I've installed at. That could be one difference.
My test box is running 10 on SSD, otherwise I would test as well.

 

[Ericloewe]

There's a thing that was a thing.

Back when we first set it up so that boot could be a mirrored pool, it turned out someone forgot to have it do the grub-install on the new device. So, you could resilver the data for the boot device, but the device itself would not be bootable. For some reason, we went back and forth on what to do about this for months in the bug tracker. I had assumed something was done, and that one of the options we spoke of was implemented. I didn't following the endgame very closely.

Apparently, according to your report, there is a combination of events where the grub-install does not occur automatically/sensibly.

So maybe you can find the bug in bugs.freenas.org, and re-open it by describing your exact circumstances?

It was, I remember this being solved by late mid-2015. I think it was even borked in the 9.10 transition and got fixed again.