SOLVED Intended recovery process for failed boot device?

[pjc]

I was planning on testing out how 9.3-BETA handles a failed mirrored boot device, but then I realized I have no idea how to "fix" it after I cause errors on one of the devices.

There's a writeup of how to handle failed pools that aren't boot devices -- should that same process work for boot devices, or is the intent that you schedule downtime, reinstall on fresh boot devices, reboot and restore your configuration?

 

[dlavigne]

If the boot device is mirrored, follow the instructions in http://doc.freenas.org/9.3/freenas_system.html#boot. Otherwise, it's your last sentence.

 

[pjc]

Wow, that was a fast response. Thanks for the pointer to the new section of documentation. I'll give it a try. (I have a mirrored boot device. I'll try pulling it and then replacing it.)

 

[pjc]

So given this bug https://bugs.freenas.org/issues/6839, there doesn't seem to be a way to resilver a degraded boot volume from the GUI. So I did the following:

Code:

# zpool replace freenas-boot /dev/gptid/... /dev/da7
Make sure to wait until resilver is done before rebooting.

If you boot from pool 'freenas-boot', you may need to update
boot code on newly attached disk '/dev/da7'.

Assuming you use GPT partitioning and 'da0' is your new boot disk
you may use the following command:

    gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0

I don't think 9.3-BETA is using GPT partitioning, so what do I actually need to do once this is done?

 

[solarisguy]

Any reason you did not follow this?

If this system had a mirrored boot device and one device had a “Status” of OFFLINE, one could click the device to replace, then click its “Replace” button. Note that you cannot replace the boot device if it is the only boot device as it contains the operating system itself.

I understood that you were to remove one of the boot devices, so its status was surely OFFLINE.

 

[pjc]

Any reason you did not follow this?I understood that you were to remove one of the boot devices, so its status was surely OFFLINE.

Did you read my post? Bug 6839 breaks the GUI so that you can't get the list of mirrored boot devices nor click "replace". That was the entire premise of my question.

 

[solarisguy]

I'm sorry. I have read the bug reports, but your comment was not there, yet.

If I had seen it before posting, I would have plain asked, what is the command line equivalent of hitting the Replace in the GUI...

I am not knowledgeable enough (and too lazy) to read the source code

 

[rogerh]

I presume that if the mirrored device was removed to simulate a fault that its boot sector(s) would already be in the required state? Or is this not a safe assumption?

 

[pjc]

That's a fair presumption, but unfortunately due to https://bugs.freenas.org/issues/6857 I nuked the first and last sectors of the device to get rid of the lingering GPT table.

(Yes, I'm way out of standard config at this point just wondering if there's a way to get it back to sanity...)

While I'm at it, how do I give the new device a gpt_id so that zfs refers to it by ID instead of by /dev/da7?

 

[pjc]

what is the command line equivalent of hitting the Replace in the GUI...

I am not knowledgeable enough (and too lazy) to read the source code

Good call. Here's the answer, from /usr/local/www/freenasUI/middleware/notifier.py bootenv_replace_disk():

• zero out the first and last 1MB
• gpart create -s gpt /dev/(device)
• gpart add -t bios-boot -i 1 -s 512k (device)
• gpart add -t freebsd-zfs -i 2 -a 4k (device)
• gpart set -a active (device)
• zpool replace freenas-boot (old label) (device)p2
  
• /usr/local/sbin/grub-install (device)

It's a little weird to me that functional code like this is crammed into "notifier", but that's a topic for another day.

 

[solarisguy]

zero out the first and last 1MB

Possibly this could be used instead?

Code:

zpool labelclear -f /dev/daORadaNUMBER

[CFR][ZFS] Add "zpool labelclear" command.
http://lists.freebsd.org/pipermail/freebsd-fs/2011-June/011767.html

zpool labelclear destroys GPT data
http://lists.freebsd.org/pipermail/freebsd-stable/2013-June/073780.html
http://lists.freebsd.org/pipermail/freebsd-stable/2013-June/073791.html