[pca] patching broke my server!

[Rajiv Gunja]

No PCA does not automatically generate the patch list. We have to do
it manually.

Sorry to hear that you have to reinstall.

Here is what I do for installing Patches:

1. Backup current configuration:
cd /tmp
mkdir `hostname`
cd `hostname`
uname -a > uname.out
showrev -p > showrev.out
pkginfo -x > pkginfo.out
cd /tmp
tar -cvf `hostname`.tar `hostname`
cp `hostname`.tar /var/sadm/pca

2. Create patch_order file:
pca --format="%p-%c" -l missing > /var/pca/patch_order
tail -r /var/pca/patch_order > /var/pca/uninstall_patch_order

3. Break Veritas Mirror and unencapsulate the rootdisk

4. Format and reslice rootmirror disk

5. Run lucreate to copy the current BE to ABE. Once done change
/.alt.Solaris/etc/vfstab to point to the ABE disk.

6. Either use luupgrade and point it to the patch directory and
patch_order file OR
run PCA with --root option.

Good luck

-GGR
Rajiv G Gunja

On 08/08/2008, Greg Matthews <gmatt at nerc.ac.uk> wrote:
> Rajiv Gunja wrote:
>> Greg,
>> I know this is very hard situation, but do you have a list of patches
>> you installed on the server? i.e. using PCA? If so, you can create a
>> reverse list of patches to un-install.
>>
>> tail -r patch_order > uninstall_patch_order
>
> but pca doesn't create a patch_order file does it? I considered backing
> out all the patches but I wasn't clear on how to generate the
> patch_order/uninstall_patch_order file.
>
>> Boot your system via CD or DVD and mount your root and /var on /a of
>> the CDROM, write a script (for loop, reading uninstall_patch_order)
>> and remove all the patches you installed.
>> -----
>> for eachpatch in `cat /a/var/uninstall_patch_order`
>> do
>> patchrm -R /a $eachpatch
>> done | tee -a /a/var/uninstall_patch_log
>> -----
>>
>> See if this helps.
>
> I'm afraid I ran out of time. I've had to start from scratch with a
> reinstall. The site needs the server working in order to run backups
> tonight.
>
>> If you need more information about LU patching please let me know. We
>> have about 4000+ Solaris servers and we mostly use LU patching which
>> saves time and any patch issues.
>
> this is something we are way overdue on. It looks pretty straightforward
> tho so I'm hoping we will start to implement LU on all new Solaris installs.
>
> thanks anyway...
>
> GREG
>
>>
>> -GGR
>> Rajiv G Gunja
>>
>>
>> On 08/08/2008, Greg Matthews <gmatt at nerc.ac.uk> wrote:
>>> Greg Matthews wrote:
>>>> Its patching as I type but I didnt see anything in the list of missing
>>>> patches that looks a likely candidate for this problem.
>>> As I feared, it didnt fix the problem but it did change it slightly, the
>>> boot failure now looks like:
>>>
>>> Rebooting with command: boot -srv
>>> Boot device: /pci at 1e,600000/pci at 0/pci at a/pci at 0/pci at 8/scsi at 1/disk at 0,0:a
>>> File and args: -srv
>>> module /platform/sun4u/kernel/sparcv9/unix: text at [0x1000000,
>>> 0x107f8c7] data at 0x1800000
>>> module misc/sparcv9/krtld: text at [0x107f8c8, 0x1099c97] data at
>>> 0x184ccc8
>>> module /platform/sun4u/kernel/sparcv9/genunix: text at [0x1099c98,
>>> 0x12066a7] data at 0x1852a00
>>> module /platform/SUNW,Sun-Fire-V245/kernel/misc/sparcv9/platmod: text at
>>> [0x12066a8, 0x1206f8f] data at 0x18aa5e0
>>> module /platform/sun4u/kernel/cpu/sparcv9/SUNW,UltraSPARC-IIIi: text at
>>> [0x1207000, 0x1217f8f] data at 0x18aae40
>>> SunOS Release 5.10 Version Generic_120011-14 64-bit
>>> Copyright 1983-2007 Sun Microsystems, Inc.  All rights reserved.
>>> Use is subject to license terms.
>>> Ethernet address = 0:14:4f:70:4a:da
>>> /kernel/drv/sparcv9/sd: undefined symbol 'ddi_prop_op_nblocks_blksize'
>>> WARNING: mod_load: cannot load module 'sd'
>>> sd: cannot load driver
>>> Cannot load drivers for
>>> /pci at 1e,600000/pci at 0/pci at a/pci at 0/pci at 8/scsi at 1/disk at 0,0:a
>>> Can't load the root filesystem
>>> Type  'go' to resume
>>> {1} ok
>>>
>>> It is now complaining about a different symbol in a different module!
>>>
>>>> G
>>>>
>>>>> Martin.
>>>>>
>>>>>
>>>>
>>>
>>> --
>>> Greg Matthews           01491 692445
>>> Head of UNIX/Linux, iTSS Wallingford
>>>
>>> --
>>> This message (and any attachments) is for the recipient only. NERC
>>> is subject to the Freedom of Information Act 2000 and the contents
>>> of this email and any reply you make may be disclosed by NERC unless
>>> it is exempt from release under the Act. Any material supplied to
>>> NERC may be stored in an electronic records management system.
>>>
>>>
>>>
>>
>>
>
>
> --
> Greg Matthews           01491 692445
> Head of UNIX/Linux, iTSS Wallingford
>
> --
> This message (and any attachments) is for the recipient only. NERC
> is subject to the Freedom of Information Act 2000 and the contents
> of this email and any reply you make may be disclosed by NERC unless
> it is exempt from release under the Act. Any material supplied to
> NERC may be stored in an electronic records management system.
>
>
>