Sponsored Content
Operating Systems Solaris How to use live-upgrade with single disk, pre-patching steps? Post 303033436 by samthewildone on Friday 5th of April 2019 08:20:12 AM
Old 04-05-2019
On Solaris 10 you would use
Code:
lucreate

This allows the system to create an alternative boot environment; BE.

This new BE created on the disk but, the new BE can be patched. Once patched you
are able to active with new BE with cluster patch, then when you bounce the system
you'll be booted into the patched BE.

From here you'll be able to test applications and zones to see if the patch had
any negative affects. If so, simply revert back to the original BE and bounce system
to pre-patch state. Open a SR with Oracle if you have a contract.

There's tons of documentation on
Code:
lucreate

 

7 More Discussions You Might Find Interesting

1. UNIX for Dummies Questions & Answers

Typical steps to be followed while applying an application patch upgrade on linux

what are the typical steps used by system adminstrators while applying an application patch upgrade (1 Reply)
Discussion started by: ramky79
1 Replies

2. Solaris

Live Upgrade Patching Error: Unable to write vtoc

Attempting to patch several servers using live upgrade Release: Oracle Solaris 10 8/11 s10x_u10wos_17b X86 Error I'm receiving is in the message in the log below tail -15 /var/svc/log/rc6.log Legacy init script "/etc/rc0.d/K50pppd" exited with return code 0. Executing legacy init... (5 Replies)
Discussion started by: Siralos
5 Replies

3. Solaris

Help me with Pre Installation Steps for Patching on Solaris Servers

What are the Pre-installation steps for patching on Solaris servers in real time ? :confused: (6 Replies)
Discussion started by: vijaykrishna
6 Replies

4. Solaris

Solaris patching issue with Live Upgrade

I have Solaris-10 sparc box with ZFS file-system, which is running two non global zones. I am in process of applying Solaris Recommended patch cluster via Live Upgrade. Though I have enough space in root file-system of both zones, everytime I run installcluster, it fails with complaining less... (7 Replies)
Discussion started by: solaris_1977
7 Replies

5. Solaris

Live upgrade first steps

Hello Guys, I am a little confused about the first step in the live upgrade process. I will be glad if someone can clarify this for me. The pre-live upgrade patch, when do you add this patch to the OS you want to upgrade? 1. before creating the new boot environment? or 2. after creating... (1 Reply)
Discussion started by: cjashu
1 Replies

6. Solaris

Solaris 10 patching using live upgrade with VxVM

Hello, I was assigned some Solaris machines and need to patch them to N-1, where N is the latest OS realease, which means, upgrade till one version before the latest one. I do not now a lot about Solaris. What I only know is that need to make use of live upgrade and be careful with VxVM... (4 Replies)
Discussion started by: feroccimx
4 Replies

7. Solaris

Patching using live upgrade - with non-globalzone

Hi all, I would like to ask what will be the best practice for the following setup / - c0t0d0s0 - current BE (named First) / - c0t0d1s0 - alternate BE (name Second) i have a non-global zone with zonepath in /zones/myzone /mnt/opt - c0t0d2s6 (shared between the 2 BE)... (3 Replies)
Discussion started by: javanoob
3 Replies
DPATCH.MAKE(7)							      dpatch							    DPATCH.MAKE(7)

NAME
dpatch.make - simplistic wrapper around dpatch(1) for make(1). SYNOPSIS
include /usr/share/dpatch/dpatch.make DESCRIPTION
For backwards compatibility and ease of use, dpatch.make is provided along with dpatch(1). Its purpose is to implement generic patch and unpatch rules that can be reused in debian/rules scripts. WARNING
dpatch is deprecated, please switch to the `3.0 (quilt)' Debian source package format instead. See http://wiki.debian.org/Projects/Deb- Src3.0#FAQ for a short guide on how to do it. USAGE
Using dpatch.make is rather straightforward: one has to include the file in debian/rules, change the appropriate targets to depend on patch and unpatch, and that is all it takes. Figuring out what the appropriate target is, requires some thought. Generally, one has a build target, or config.status, or configure (or any of these with a -stamp suffix). Most of the time these are called first during the build, so one of these (the one that exists, and is not depended upon by another one) has to be modified to depend on the patch target in dpatch.make. Doing the same for the clean target is easier. One only has to rename the old rule to, say, clean-patched, then make a new one that has clean-patched and unpatch in its list of prerequisites. CUSTOMISATION
There are a few variables which are used by dpatch.make, which can be set before including it, in order to change the systems behaviour a little. These variables are: DEB_SOURCE_PACKAGE This is the name of the source package, used when creating the stamp file. By default, it is empty. DPATCH_STAMPDIR This is the directory where stamp files will be put. Default is debian/patched. DPATCH_STAMPFN The name of the stamp file, which contains the patch descriptions and other possible meta-data. Default value is patch-stamp. DPATCH_PREDEPS A list of make targets to call before applying the dpatch. DPATCH_WORKDIR The target directory to apply patches to. By default, it is the current directory. PATCHLIST The list of patches to apply. This is an alternative to debian/patches/00list - that is, if this variable is not empty, the contents of 00list will be ignored, and this variable will be used instead. EXAMPLE
include /usr/share/dpatch/dpatch.make build: build-stamp build-stamp: patch-stamp ${MAKE} touch build-stamp clean: clean1 unpatch clean1: ${MAKE} clean rm -rf debian/files debian/substvars debian/imaginary-package .PHONY: patch unpatch ... . . . SIDE EFFECTS
Using dpatch.make instead of calling dpatch directly has one side effect: it will create a file called patch-stamp containing some meta-information extracted from the scriptlets. Depending on a phony patch target directly from build target may cause build target to be reevaluated even when there is no change to be done. Instead, try making build-stamp depend on patch-stamp as specified in this example. AUTHOR
Originally by Gergely Nagy. Modified by Junichi Uekawa. SEE ALSO
dpatch(1), dpatch(7), dpatch-edit-patch(1), dpatch-list-patch(1), dpatch-convert-diffgz(1) DPATCH 2 Dec 13 2011 DPATCH.MAKE(7)
All times are GMT -4. The time now is 11:48 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy