Re: Implementing a Shared Root File System
Am Wed, 12 Nov 2008 10:01:39 -0500 schrieb Craig Loubser <[EMAIL PROTECTED]>: > It is SLES10 SP2 (kernel 2.6.16.60-0.21). SLES10 SP2 is definitely > behaving differently to SLES9. Under SLES9, prior to passing control to > /sbin/init, it would mount the root file system as R/O and this is > without marking the boot device as "ro" in the kernel command line. Right. The behavior of Sles9 is as expected, and as documented in our device driver book. > Since we have a support contract with > IBM for Linux on z, I will raise a PMR just to see what they say. Once > again, thanks to everyone on this list. Ok good, I've already given the dasd driver owner an heads-up. so long, Carsten -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Implementing a Shared Root File System
Hi Carsten, It is SLES10 SP2 (kernel 2.6.16.60-0.21). SLES10 SP2 is definitely behaving differently to SLES9. Under SLES9, prior to passing control to /sbin/init, it would mount the root file system as R/O and this is without marking the boot device as "ro" in the kernel command line. Thanks to Mark and Florian, though, I was able to get around this. The key was to add the additional "ro" parameter to the kernel command line and also update /etc/fstab to mount the root file system as "ro" (I had forgotten to put this back in). Since we have a support contract with IBM for Linux on z, I will raise a PMR just to see what they say. Once again, thanks to everyone on this list. Regards, Craig. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Carsten Otte Sent: Wednesday, November 12, 2008 3:11 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Implementing a Shared Root File System Am Mon, 10 Nov 2008 19:16:19 -0700 schrieb Mark Post <[EMAIL PROTECTED]>: The fsck is not what is causing the I/O errors. When you see "fsck succeeded" it's done and over with. Let me guess, though. Is this an ext3 file system (or reiserfs), and are you mounting it as ext3 instead of ext2? If so, then I suspect the system is trying to replay the journal, resulting in the I/O errors. There's no point in having a journaling file system that is only going to be mounted read-only. Use ext2 instead. Neither should the file system nor fsck be able to write to the volume in the first place, if it is marked (ro). Also, it should be mounted read-only by default even if you forget the additional ro in the kernel command line as long as the device itself is read-only - and that should be the case here, due to the dasd=100(ro) in the kernel command line. This clearly is a kernel bug, Craig should open a PMR for that. What distribution/kernel version are you running? so long, Carsten -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Implementing a Shared Root File System
Am Mon, 10 Nov 2008 19:16:19 -0700 schrieb Mark Post <[EMAIL PROTECTED]>: The fsck is not what is causing the I/O errors. When you see "fsck succeeded" it's done and over with. Let me guess, though. Is this an ext3 file system (or reiserfs), and are you mounting it as ext3 instead of ext2? If so, then I suspect the system is trying to replay the journal, resulting in the I/O errors. There's no point in having a journaling file system that is only going to be mounted read-only. Use ext2 instead. Neither should the file system nor fsck be able to write to the volume in the first place, if it is marked (ro). Also, it should be mounted read-only by default even if you forget the additional ro in the kernel command line as long as the device itself is read-only - and that should be the case here, due to the dasd=100(ro) in the kernel command line. This clearly is a kernel bug, Craig should open a PMR for that. What distribution/kernel version are you running? so long, Carsten -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Implementing a Shared Root File System
Hi, Craig. I'm sorry that I missed your original post. Mike MacIsaac forwarded some of this thread to me. (And then I signed back up to the list. Long story!) The usual thing that happens in Linux (and most Unix) is for the root filesystem to be mounted read-only when /sbin/init gets control. (In the days of INITRD, this happens AFTER the initial RAM disk has loaded whatever modules are required and then brought the root device online.) At that point, with your root mounted read-only, an 'fsck' can run without damaging the filesystem. If the filesystem was moutned R/W when 'fsck' ran, the two could easily collide, and probably would collide, and you would have filesystem damage ranging from minor to catastrophic. Making the root disk read-only from the VM perspective does not change this. Marking the root disk read-only in the boot parms does not change it (and is recommended anyway). Setting your root disk read-only in /etc/fstab also does not turn off this root 'fsck' step. If you want to coax Linux into working with read-only root, you MUST intercept /etc/init.d/boot.roofsck (or whatever equivialent; my most recent experience on this point centers around SLES). You will have to either modify that script or replace it with a script of your own design. If you like, you can swipe a copy of what I use at home: http://www.casita.net/pub/ror/etc/init.d/boot.roroot It expects to have a /local disk or filesystem (but is not documented). I run with read-only root on a regular basis. It makes the manglement of multiple systems tolerable. -- Rick; <>< On Tue, Nov 11, 2008 at 8:08 AM, Craig Loubser <[EMAIL PROTECTED]> wrote: >> The fsck is not what is causing the I/O errors. When you see "fsck > succeeded" it's done and over with. Let me guess, though. > Well I guess I can rule out the "fsck" then. Why the difference between > SLES9 and SLES10 though? > >> Is this an ext3 file system (or reiserfs), and are you mounting it as > ext3 instead of ext2? > > Is is an ext2 file system. > > Thanks. > > Regards, > Craig. > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Implementing a Shared Root File System
> The fsck is not what is causing the I/O errors. When you see "fsck succeeded" it's done and over with. Let me guess, though. Well I guess I can rule out the "fsck" then. Why the difference between SLES9 and SLES10 though? > Is this an ext3 file system (or reiserfs), and are you mounting it as ext3 instead of ext2? Is is an ext2 file system. Thanks. Regards, Craig. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Implementing a Shared Root File System
Craig, You should also update the FSTAB in the following way: /dev/disk/by-path/ccw-0.0.0xxx-part1/ ext2ro,acl,user_xattr 0 0 For me this works fine. The xxx has also an ext2 filesystem on it. I had also ext3 in the beginning and disabled journaling with tunefs. 0 0 at te end avoid checking. Before I use the R/O image I check that it was cleanly unmounted and performed a manual fsck on it. But please note that you need the /dev directory on a r/w disk. Before the switch from the initrd system, where the /dev lives in memory, the boot sequence does a /bin/mount --move /dev /root/dev When the /dev is not r/w then you have the i/o errors. I have circumvented that because I slightly modified the init script. Immediately after the mount the init script calls a vendor specific script (vendor_init.sh). I copied this call and build this vendor_init.sh in such a way that it accepts a parameter. In this script I can mount the minidisk with /dev filesystem and the above command works. And the boot sequence continues normally. Personally I find it a pity that SLES makes it more difficult to have a R/O filesystem than earlier releases. Regards, Florian On Tue, Nov 11, 2008 at 3:16 AM, Mark Post <[EMAIL PROTECTED]> wrote: > >>> On 11/10/2008 at 7:56 PM, Craig Loubser <[EMAIL PROTECTED]> > wrote: > > Hi Mark, > > > > I updated zipl.conf to add the "ro" to the end of the kernel parameters > > and that did fix that but it is still performing a "fsck" on the root > > file system prior to mounting it as R/O. As a result, I still end up > > with I/O errors on the root file system due to lost page writes. > > The fsck is not what is causing the I/O errors. When you see "fsck > succeeded" it's done and over with. Let me guess, though. Is this an ext3 > file system (or reiserfs), and are you mounting it as ext3 instead of ext2? > If so, then I suspect the system is trying to replay the journal, resulting > in the I/O errors. There's no point in having a journaling file system that > is only going to be mounted read-only. Use ext2 instead. > > > Mark Post > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > -- Best regards Florian Bilek -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Implementing a Shared Root File System
>>> On 11/10/2008 at 7:56 PM, Craig Loubser <[EMAIL PROTECTED]> wrote: > Hi Mark, > > I updated zipl.conf to add the "ro" to the end of the kernel parameters > and that did fix that but it is still performing a "fsck" on the root > file system prior to mounting it as R/O. As a result, I still end up > with I/O errors on the root file system due to lost page writes. The fsck is not what is causing the I/O errors. When you see "fsck succeeded" it's done and over with. Let me guess, though. Is this an ext3 file system (or reiserfs), and are you mounting it as ext3 instead of ext2? If so, then I suspect the system is trying to replay the journal, resulting in the I/O errors. There's no point in having a journaling file system that is only going to be mounted read-only. Use ext2 instead. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Implementing a Shared Root File System
Hi Mark, I updated zipl.conf to add the "ro" to the end of the kernel parameters and that did fix that but it is still performing a "fsck" on the root file system prior to mounting it as R/O. As a result, I still end up with I/O errors on the root file system due to lost page writes. I reviewed the latest "Device Drivers, Features, and Commands - November 2007" but there does not appear to be a kernel parameter to stop it performing a "fsck" during initrd. This only seems to be the case with SLES10. I rebooted a SLES9 z/Linux guest to check what it does during initrd. It does not appear to "fsck" the root file system and mounts it R/O even though I do not specify "ro" in the kernel parameters. Is there a way to tell initrd not to "fsck" the root file system no matter what? This is from the SLES10 boot log: Waiting for device /dev/dasda1 to appear: ok rootfs: major=94 minor=1 devn=24065 fsck 1.38 (30-Jun-2005) /dev/dasda1: clean, 46695/903168 files, 1171324/1802856 blocks fsck succeeded. Mounting root device read-only. Mounting root /dev/dasda1 end_request: I/O error, dev dasda, sector 192 Buffer I/O error on device dasda1, logical block 0 lost page write due to I/O error on dasda1 Regards, Craig. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Implementing a Shared Root File System
>>> On 11/10/2008 at 5:05 PM, Craig Loubser <[EMAIL PROTECTED]> wrote: > Hi Carsten, > > I had already done that. This is an extract of the log showing the kernel > parameters: > > Kernel command line: root=/dev/dasda1 dasd=100(ro),101-105,200-22F TERM=dumb > BOOT_IMAGE=0 You need to have a separate "ro" somewhere on your command line for the root file system to be mounted as read-only just before exiting the initrd. So, that would be root=/dev/dasda1 dasd=100(ro),101-105,200-22F TERM=dumb BOOT_IMAGE=0 ro Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Implementing a Shared Root File System
Hi Carsten, I had already done that. This is an extract of the log showing the kernel parameters: Kernel command line: root=/dev/dasda1 dasd=100(ro),101-105,200-22F TERM=dumb BOOT_IMAGE=0 . . dasd(eckd): 0.0.0100: 3390/0C(CU:3990/01) Cyl:10016 Head:15 Sec:224 dasd(eckd): 0.0.0100: (4kB blks): 7211520kB at 48kB/trk compatible disk layout dasda:VOL1/ 0X0100: dasda1 . . Waiting for device /dev/dasda1 to appear: ok rootfs: major=94 minor=1 devn=24065 fsck 1.38 (30-Jun-2005) Ý/bin/fsck.ext2 (1) -- /¨ fsck.ext2 -a /dev/dasda1 /dev/dasda1: clean, 46694/903168 files, 1171321/1802856 blocks fsck succeeded. Mounting root device read-write. Mounting root /dev/dasda1 end_request: I/O error, dev dasda, sector 192 Buffer I/O error on device dasda1, logical block 0 lost page write due to I/O error on dasda1 end_request: I/O error, dev dasda, sector 5243312 Regards, Craig. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Implementing a Shared Root File System
Am Fri, 7 Nov 2008 15:46:56 -0500 schrieb Craig Loubser <[EMAIL PROTECTED]>: > Waiting for device /dev/dasda1 to appear: ok > rootfs: major=94 minor=1 devn=24065 > fsck 1.38 (30-Jun-2005) > Ý/bin/fsck.ext2 (1) -- /¨ fsck.ext2 -a /dev/dasda1 > /dev/dasda1: clean, 51899/874368 files, 299859/1748676 blocks > fsck succeeded. Mounting root device read-write. > Mounting root /dev/dasda1 > end_request: I/O error, dev dasda, sector 192 The disk backing dasda1 is apparently read-only in VM, but has not been marked ro in linux. Try dasd=devno(ro) for this volume in your kernel command line. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Implementing a Shared Root File System
Hi Mike, The boot.rootfsck script has changed slightly between SLES10 and SP2 so I had to update the new boot.rootfsck script with your changes manually. The root file system is being mounted as R/W even before boot.rootfsck is executed though. Once again I've included an extract of the boot log with comments: Waiting for device /dev/dasda1 to appear: ok rootfs: major=94 minor=1 devn=24065 fsck 1.38 (30-Jun-2005) Ý/bin/fsck.ext2 (1) -- /¨ fsck.ext2 -a /dev/dasda1 /dev/dasda1: clean, 51899/874368 files, 299859/1748676 blocks fsck succeeded. Mounting root device read-write. <<<=== Mounted R/W Mounting root /dev/dasda1 end_request: I/O error, dev dasda, sector 192 Buffer I/O error on device dasda1, logical block 0 lost page write due to I/O error on dasda1 end_request: I/O error, dev dasda, sector 13107640 Buffer I/O error on device dasda1, logical block 1638431 lost page write due to I/O error on dasda1 mount: you must specify the filesystem type INIT: version 2.86 booting System Boot Control: Running /etc/init.d/boot Mounting procfs at /proc..done Mounting sysfs at /sys..done Mounting debugfs at /sys/kernel/debug..done Initializing /dev..done Mounting devpts at /dev/pts..done Boot logging started on /dev/ttyS0(/dev/console (deleted)) at Fri Oct 24 18:13:38 2008 Adding 215896k swap on /dev/disk/by-path/ccw-0.0.0102-part1. Priority:-1 extents:1 across:215896k kjournald starting. Commit interval 5 seconds EXT3 FS on dasde1, internal journal EXT3-fs: recovery complete. EXT3-fs: mounted filesystem with ordered data mode. # EXECUTING boot.rootfsck <<<=== Modified boot.rootfsck called Read-only root: In modified /etc/init.d/boot.rootfsck Regards, Craig -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Implementing a Shared Root File System
Craig, > I have been trying to implement a R/O root file system with SLES10 SP2 The paper was based on SLES 10 "vanilla", and the changes are specific to that version, I believe. Especially, on page 36 of the paper, the modifySystem() function in the mkror.sh script has the lines: patch $TGT/etc/init.d/boot.rootfsck < $rorDiffs if [ "$?" != 0 ]; then exit 49; fi So if the boot.rootfsck script changed between SLES10 and SLES 10 SP2, then I would expect that the patch command would fail. By chance does mkror.sh exit with a return code of 49? You write: > You can see later on where boot.rootfsck, modified for the Read-Only root, gets executed, but at that point it is too late... That would seem to imply that mkror.sh has run and has succeeded. Then you write: > I start getting file system errors, because the minidisk containing the root file system is defined as R/O to the Linux guest. Well now I'm confused. We want a read-only root file system correct? I'm also a bit confused as to why you cite SLES 9. I know the steps in the paper are repeatable for a SLES 10 vanilla system. Have you tried the steps on that flavor of the distro? Maybe starting with SLES 10, which is the basis of the paper is a good place to start. This is part of the problem with writing a technical paper using a specific version of an OS as a basis - the specifics get stale quite quickly. Maybe if Rick T. is listening - has boot.rootfsck changed between SLES 10 and SLES 10 SP2? "Mike MacIsaac" <[EMAIL PROTECTED]> (845) 433-7061 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Implementing a Shared Root File System
Wouldn't some of the tricks used by Knoppix (and Ubuntu, DSL, et al) to handle a read-only root volume work? Granted, you don't want all of the symlinks in a RAM-based F/S, but something of the like should be workable. The problem, of course, is the patching of that image... Isn't GPFS or something of that ilk more reasonable? So that you can have a small local image of changes to the shared (r/o) space? Or am I mis-remembering? -- John R. Campbell Speaker to Machines souperb at gmail dot com MacOS X proved it was easier to make Unix user-friendly than to fix Windows -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Implementing a Shared Root File System
Hi List, I have been trying to implement a R/O root file system with SLES10 SP2 following the IBM Redpaper "Sharing and maintaining Linux under z/VM" at http://www.redbooks.ibm.com/redpieces/abstracts/redp4322.html?Open but I have found an issue with the way that SLES10 SP2 tries to fsck and mount the root file system as R/W before passing control to /sbin/init . You can see later on where boot.rootfsck, modified for the Read-Only root, gets executed, but at that point it is too late... I start getting file system errors, because the minidisk containing the root file system is defined as R/O to the Linux guest. Eventually the root file system becomes unreadable. I checked this process on a SLES9 system It mounts the root file system as R/O just before passing control to /sbin/init. I am wondering if this is an intentional change in SLES10 or this is a "bug". Here is an extract of the log from a SLES10 SP2 system during boot processing: Waiting for device /dev/dasda1 to appear: ok rootfs: major=94 minor=1 devn=24065 fsck 1.38 (30-Jun-2005) Ý/bin/fsck.ext2 (1) -- /¨ fsck.ext2 -a /dev/dasda1 /dev/dasda1: clean, 51899/874368 files, 299859/1748676 blocks fsck succeeded. Mounting root device read-write. Mounting root /dev/dasda1 end_request: I/O error, dev dasda, sector 192 Buffer I/O error on device dasda1, logical block 0 lost page write due to I/O error on dasda1 end_request: I/O error, dev dasda, sector 13107640 Buffer I/O error on device dasda1, logical block 1638431 lost page write due to I/O error on dasda1 mount: you must specify the filesystem type INIT: version 2.86 booting System Boot Control: Running /etc/init.d/boot Mounting procfs at /proc..done Mounting sysfs at /sys..done Mounting debugfs at /sys/kernel/debug..done Initializing /dev..done Mounting devpts at /dev/pts..done Boot logging started on /dev/ttyS0(/dev/console (deleted)) at Fri Oct 24 18:13:38 2008 Adding 215896k swap on /dev/disk/by-path/ccw-0.0.0102-part1. Priority:-1 extents:1 across:215896k kjournald starting. Commit interval 5 seconds EXT3 FS on dasde1, internal journal EXT3-fs: recovery complete. EXT3-fs: mounted filesystem with ordered data mode. # EXECUTING boot.rootfsck Read-only root: In modified /etc/init.d/boot.rootfsck For comparison, here is a SLES9 log: Waiting for device /dev/dasda1 to appear: ok rootfs: major=94 minor=1 devn=24065 rootfs: /sys/block/dasda/dasda1 major=94 minor=1 devn=24065 kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Trying to move old root to /initrd ... /initrd does not exist. Ignored. Unmounting old root Trying to free ramdisk memory ... failed Freeing unused kernel memory: 116k freed INIT: version 2.85 booting System Boot Control: Running /etc/init.d/boot Mounting /proc filesystem..done Mounting sysfs on /sys..done Mounting /dev/pts..done Boot logging started on /dev/ttyS0(/dev/console) at Fri Oct 24 18:19:21 2008 Mounting shared memory FS on /dev/shm..done Activating swap-devices in /etc/fstab... Adding 129972k swap on /dev/dasdb1. Priority:-1 extents:1 Adding 215896k swap on /dev/dasdc1. Priority:-2 extents:1 Ý1A..doneChecking root file system... Thanks in advance, Craig. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Draft Redpaper: "z/VM and Linux on IBM System z: Implementing a Shared Root File System"
On Monday 05 November 2007 08:42, Michael MacIsaac wrote: >Jae Hwa, > >> How about rpm update works(except kernel updates) for these >> systems using shared root fs? Are there any ways to apply >> the updates to many cloned system? > >Good question. The short answer is that I defer to either Steve Womer, if >he cares to comment, or to the current thread "Applying updates to >multiple servers". The core problem here is how to install (or update) and RPM on a cloned Linux guest when it shares filesystems with other guests. Shared filesystems have to be read-only, so attempting to install an RPM that contains files that are to go into a shared filesystem on the cloned system will fail. What you have to do is shut down all guests that share the filesystem so that you can then bring up one guest that mounts the filesystem read-write. You then install the RPMs on that guest, figure out which files were changed in all the non-shared filesystems, and write them into the filesystems of all the other guests. Finally, you shut down the guest that mounted the shared filesystem read-write, and start all the guests so that they are sharing the altered filesystem read-only again, and have the updates on their non-shared filesystems. I'm quite familier with this problem because I've implemented a variation of the above in Mainstar's Provisioning Expert for Linux on z/VM to automate updates to many guests. We found a way to avoid taking all the guests down for a long time, though, so you can apply the same update to individual guests or groups of guests and it takes each one down only while altering its non-shared filesystems, which is usually just a few minutes. It's not a trivial thing to do, and automating it with a tool is pretty much the only way to get it done right. I've heard that Nationwide built scripts to push out updates, but I don't know if they do that for their "shared root" guests or not. - MacK. - Edmund R. MacKenty Software Architect Rocket Software, Inc. Newton, MA USA -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Draft Redpaper: "z/VM and Linux on IBM System z: Implementing a Shared Root File System"
Jae Hwa, > How about rpm update works(except kernel updates) for these > systems using shared root fs? Are there any ways to apply > the updates to many cloned system? Good question. The short answer is that I defer to either Steve Womer, if he cares to comment, or to the current thread "Applying updates to multiple servers". But I will at least elaborate. The paper was originally written at Nationwide Insurance based on their "real-world" experiences. I helped the ITSO (the Redbook group at IBM) convert it to a more general Redpaper. There were steps written to address the type of maintenance that you ask about. We had hoped to write up an example on how to move cloned servers from SLES 10 to SLES 10 SP1. However, we ran out of time and pages (we were near the number of pages that the ITSO considers a book, not a paper). So we compromised and generalized the details into the section "Maintenance Options". Everyone seems to agree that this section is just too thin to be of use. I know this is probably not the answer you were looking for, but this is what it is. "Mike MacIsaac" <[EMAIL PROTECTED]> (845) 433-7061 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Draft Redpaper: "z/VM and Linux on IBM System z: Implementing a Shared Root File System"
Michael, How about rpm update works(except kernel updates) for these systems using shared root fs? Are there any ways to apply the updates to many cloned system? Regards, Jae-hwa 2007/10/30, Michael MacIsaac <[EMAIL PROTECTED]>: > Nigel, > > > any plans for a version based on Red Hat ? > The short answer is no - we had relatively few cycles on the "residency" > which was really just two people for one week. > > However, thinking about it, the mkror.sh script should only need a few > small changes. I'm not sure how different SuSE and Red Hat are with their > statup scripts (/etc/init.d/boot and /etc/init.d/boot.rootfsck in SLES > 10), but there would almost certainly be work to do there. If someone were > to get this working quickly on RHEL and report back the changes needed, > there is some chance the paper and tar file could be updated. > > "Mike MacIsaac" <[EMAIL PROTECTED]> (845) 433-7061 > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > -- Jae-hwa Park <[EMAIL PROTECTED]> THE CHALLENGES, that's why I choose LINUX!!! For more information on me, visit http://php.sarang.net -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Draft Redpaper: "z/VM and Linux on IBM System z: Implementing a Shared Root File System"
Nigel, > any plans for a version based on Red Hat ? The short answer is no - we had relatively few cycles on the "residency" which was really just two people for one week. However, thinking about it, the mkror.sh script should only need a few small changes. I'm not sure how different SuSE and Red Hat are with their statup scripts (/etc/init.d/boot and /etc/init.d/boot.rootfsck in SLES 10), but there would almost certainly be work to do there. If someone were to get this working quickly on RHEL and report back the changes needed, there is some chance the paper and tar file could be updated. "Mike MacIsaac" <[EMAIL PROTECTED]> (845) 433-7061 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Draft Redpaper: "z/VM and Linux on IBM System z: Implementing a Shared Root File System"
Hi any plans for a version based on Red Hat ? Thanks Nigel -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Michael MacIsaac Sent: Monday, October 29, 2007 2:08 PM To: LINUX-390@vm.marist.edu Subject: Draft Redpaper: "z/VM and Linux on IBM System z: Implementing a Shared Root File System" Hello all "linux-390" and "ibmvm"ers, A draft Redpaper "Sharing and maintaining Linux under z/VM" is now up on http://www.redbooks.ibm.com/redpieces/abstracts/redp4322.html?Open Here is the abstract: "Large operating systems, such as z/OS(r), have, for several decades, leveraged shared file structures. The benefits are reduced disk space, simplified maintenance and simplified systems management. This Redpaper describes how to create a Linux(r) solution with shared file systems on IBM(r) System z? hardware (the mainframe) running under z/VM(r). It also describes a maintenance system where the same Linux image exists on a test, maintenance and gold virtual servers. This redpaper is based on z/VM 5.3 and SLES 10." The associated tar file of sample scripts and EXECs should be on ftp://www.redbooks.ibm.com/redbooks/REDP4322 (It seems that directory has not yet been created, but should be soon.) Any feedback off-list (or on-list) would be appreciated. "Mike MacIsaac" <[EMAIL PROTECTED]> (845) 433-7061 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Draft Redpaper: "z/VM and Linux on IBM System z: Implementing a Shared Root File System"
Hello all "linux-390" and "ibmvm"ers, A draft Redpaper "Sharing and maintaining Linux under z/VM" is now up on http://www.redbooks.ibm.com/redpieces/abstracts/redp4322.html?Open Here is the abstract: "Large operating systems, such as z/OS®, have, for several decades, leveraged shared file structures. The benefits are reduced disk space, simplified maintenance and simplified systems management. This Redpaper describes how to create a Linux® solution with shared file systems on IBM® System z? hardware (the mainframe) running under z/VM®. It also describes a maintenance system where the same Linux image exists on a test, maintenance and gold virtual servers. This redpaper is based on z/VM 5.3 and SLES 10." The associated tar file of sample scripts and EXECs should be on ftp://www.redbooks.ibm.com/redbooks/REDP4322 (It seems that directory has not yet been created, but should be soon.) Any feedback off-list (or on-list) would be appreciated. "Mike MacIsaac" <[EMAIL PROTECTED]> (845) 433-7061 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
