Did I stutter? I said "I'm leaving out details" which left the door open
for someone to throw a n..n..ay, nay, nay.
It's the equivalent of a 190/490 flip. (My age is showing, and don't you
say a word about my metalic blonde hair.)
+ You don't upgrade the linked copy. Ever.
+ You upgrade the maintenance copy. Always.
+ With a shared OS, you then *point* instead of c..c..copy, copy, copy.
I've given up fighting the myriad maintenance models for Linux. (You
thought there was only One True Maint Model?)
Follow the steps Jay outlined (roughly) and apply maintenance to the
master copy. Call it Gold.
Within the 'chroot', run the _stock maint_ ('zypper up' in this case).
How does this "not fit the maintenance model for Linux"?
You want to be able to shutdown a single target guest, point it at the
updated OS disk and reboot.
I'm still leaving out details. Lord of the Protocols should return
another sparring move so we can continue the handshake.
Greg --
Keep it simple.
I find that shared OS saves me time and effort and defends my sanity.
But it's not something you'll get guidance for from your distributor.
You'll have to own the process and do some figgering out. You certainly
won't get help with shared OS from your storage vendor. (They seem to be
keen on boosting their flash capable systems business and can't think
outside that box.)
You got bitten by embedded WWPNs in the INITRD, which I also hate.
-- R; <><
On 09/09/2017 08:52 PM, Alan Altmark wrote:
> No, don't. You can't upgrade the linked copy without umounting it from all
> the servers using it. While cool and highly efficient, it just doesn't fit
> the maintenance model for Linux.
>
> You want to be able to shutdown a single target guest, flashcopy the golden
> master to the target disk and reboot.
> Alan
>
> Sent from my iPhone using IBM Verse
>
> On Sep 9, 2017, 6:14:02 PM, r...@casita.net wrote:
>
> From: r...@casita.net
> To: LINUX-390@VM.MARIST.EDU
> Cc:
> Date: Sep 9, 2017, 6:14:02 PM
> Subject: Re: [LINUX-390] Gold On LUN
>
>
> Don't clone! Just link!
> I do, and have done, a fair bit of cloning. But I don't recommend it for
> production systems. (dev, test, recovery, sure)
> Instead, _share the OS disk or LUN_. Give each "client" (for lack of a
> better term) its own root.
> Less to backup, less to push with Puppet, more consistent flock o
> penguins, more reliable results.
> Good tips from several people, including this from Jay.
> On 09/08/2017 04:28 PM, Robert J Brenneman wrote:
> > Even if you had NPIV you would still have to mount the new clone and fix
> > the ramdisk so that it points to the new target device instead of the
> > golden image.
> INITRD gets too much info stamped into it.
> But if the OS is configured to share then you can boot any number of
> times from the same LUN, no problem!
> > ...
> >
> > The gist of your issue is that you need to:
> > mount the new clone volume on a running Linux instance
> > chroot into it so that your commands are 'inside' that cloned linux
> environment
> > fix the udev rules to point to the correct lun number
> > fix the grub kernel parameter to point to the correct lun if needed
> > fix the /etc/fstab records to point to the new lun if needed
> > ?? re-generate the initrd so that it does not contain references to
> the master image ??
> Re-gen the INITRD so it points to the shared boot disk. But find,
> activate, and mount the "real root", whether minidisk, EDEV, or LUN.
> I'm leaving out details, but it's not rocket surgery. Bind or sym-link
> /bin, /lib, and others, swing the OS to a sub-dir, and run.
> -- R; <><
> ----------------------------------------------------------------------
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.marist.edu_htbin_wlvindex-3FLINUX-2D390&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=XX3LPhXj6Fv4hkzdpbonTd1gcy88ea-vqLQGEWWoD4M&m=-pp4eUuJSsuOhrDEP5ZEgbahpLsO1xiq95OzcroSNzE&s=HLErO0gdQJ-npqjE80wp7vaGmoU11ncrDxyEbpe2-50&e=
> ----------------------------------------------------------------------
> For more information on Linux on System z, visit
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.linuxvm.org_&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=XX3LPhXj6Fv4hkzdpbonTd1gcy88ea-vqLQGEWWoD4M&m=-pp4eUuJSsuOhrDEP5ZEgbahpLsO1xiq95OzcroSNzE&s=JfVfMkaUZrgq09nxfn7wORqQaDY9ceGis4OZmuzmid4&e=
>
> ----------------------------------------------------------------------
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> ----------------------------------------------------------------------
> For more information on Linux on System z, visit
> http://wiki.linuxvm.org/
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
