There are several sources that recommend removing the boot archive before re-creating it. See below. But, I agree that it shouldn't be necessary. It doesn't seem to hurt in any way.
http://www.seedsofgenius.net/solaris/solaris-tips-repairing-the-boot-archive http://sun.drydog.com/faq/7.html See #7.17 from Pradhap Devarajan Neil G. Brookins Identity and Authentication Solutions - IT Global Solutions Towers Watson 1500 Market Street | Philadelphia, PA 19102 Phone: +1 215 246 6046 neil.brook...@towerswatson.com<mailto:neil.brook...@towerswatson.com> From: pca-boun...@lists.univie.ac.at [mailto:pca-boun...@lists.univie.ac.at] On Behalf Of Fred Sent: Monday, March 05, 2012 4:18 PM To: PCA (Patch Check Advanced) Discussion Subject: Re: [pca] PCA w/ LU 'n boot_archive I've never been through this procedure, and I've done a lot of patching using ZFS root on x86 with pca and live upgrade. (Thanks for the article though, I've got it nicely tucked away in case this ever happens to me). Your method seems sound, but I'm wondering if removing the boot-archive with rm is necessary. Doing a bootadm update-archive with the appropriate -R alternate root argument should suffice. Completely removing the boot-archive makes me nervous. Fred On Mon, Mar 5, 2012 at 3:57 PM, Brookins, Neil (Philadelphia) <neil.brook...@towerswatson.com<mailto:neil.brook...@towerswatson.com>> wrote: I recently patched several servers following the general steps shown here: http://probably.co.uk/patching-a-live-solaris-10-system-with-lu-zfs-and-pca.html After experiencing a problem on one out of six servers, I found this page: https://blogs.oracle.com/patch/entry/heads_up_on_kernel_patch which states that manual update of boot archive is needed. (See issue #2 in the blog) So, modifying the steps shown in the first web page above, with the new revelations from the second page, I derive these possible steps: ... # pca -i -R /.alt.patching # rm -f /.alt.patching/platform/`uname -m`/boot_archive # /.alt.patching/usr/sbin/bootadm -R /.alt.patching update-archive # luumount patching ... Can anyone confirm that I'm on the right track here? I'm using ZFS root and non-global zones. I need to use LU to reduce end-user downtime. BTW, the problem that I experienced after rebooting to the patched server, was that it printed many errors, and then it did panic and rebooted. It seems to stay up now, but I don't trust it as much since the panic. I'm guessing that the file /kernel/drv/ipsecah.conf was not valid due to the boot archive not getting updated as a part of the patching process. The error shown below repeated, each time with a different character inside the '' marks. ... genunix: [ID 107833 kern.warning] WARNING: Unexpected token '^H' on line 1 of /kernel/drv/ipsecah.conf ... ... genunix: [ID 107833 kern.warning] WARNING: Unexpected token '' on line 2 of /kernel/drv/ipsecah.conf ... last message repeated 1724 times ... ... savecore: [ID 570001 auth.error] reboot after panic: BAD TRAP: type=31 rp=2a10146eba0 addr=58 mmu_fsr=0 occurr ed in module "ip" due to a NULL pointer dereference ... Neil G. Brookins Identity and Authentication Solutions - IT Global Solutions Towers Watson 1500 Market Street | Philadelphia, PA 19102 Phone: +1 215 246 6046<tel:%2B1%20215%20246%206046> neil.brook...@towerswatson.com<mailto:neil.brook...@towerswatson.com> Notice of Confidentiality This transmission contains information that may be confidential. It has been prepared for the sole and exclusive use of the intended recipient and on the basis agreed with that person. If you are not the intended recipient of the message (or authorized to receive it for the intended recipient), you should notify us immediately; you should delete it from your system and may not disclose its contents to anyone else. This e-mail has come to you from Towers Watson Delaware Inc. -- Fred Chagnon fchag...@gmail.com<mailto:fchag...@gmail.com> Notice of Confidentiality This transmission contains information that may be confidential. It has been prepared for the sole and exclusive use of the intended recipient and on the basis agreed with that person. If you are not the intended recipient of the message (or authorized to receive it for the intended recipient), you should notify us immediately; you should delete it from your system and may not disclose its contents to anyone else. This e-mail has come to you from Towers Watson Delaware Inc.
