Carsten Otte wrote:
Wrong. Due to caching, as correctly described by David Boyes, the
system may change on-disk content even when the application is not
running. Example: the syslogd generates a mark every 20 minutes.
John Summerfied wrote:
syslogd's mark message has nothing to do with
Alan Altmark wrote:
On Monday, 07/24/2006 at 06:35 ZE2, Carsten Otte [EMAIL PROTECTED] wrote:
But rather than focus on that edge condition, we are all, I think,
in
violent agreement that you cannot take a volume-by-volume physical
backup
from outside a running Linux system and expect to have
Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 25.07.2006 11:23:02:
Alan Altmark wrote:
But, Carsten, the application may start up just fine, however it may be
using old data. I have an application running on my workstation right
now
that saves its configuration data only when you
Ingo Adlung wrote:
Whether the file system is consistent in itself after a restart is
irrelevant form an application perspective if the application has e.g.
state that is independent from the file system content. You can only
capture that by application collaboration or by forcing that state
- Start Original Message -
Sent: Tue, 25 Jul 2006 11:48:09 +0200
From: Ingo Adlung [EMAIL PROTECTED]
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Bad Linux backups
Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 25.07.2006 11:23:02:
Alan Altmark wrote:
But, Carsten, the application
FDR says working as designed. They back up the entire volume and restore
the entire volume. I have restored 3 systems and they DO NOT BOOT.
Lea Stahr
Sr. System Administrator
Linux/Unix Team
630-753-5445
[EMAIL PROTECTED]
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL
Stahr, Lea wrote:
FDR says working as designed. They back up the entire volume and restore
the entire volume. I have restored 3 systems and they DO NOT BOOT.
How does FDR copy the volume? Do they sequentially copy track-by-track
or use flashcopy?
cheers,
Carsten
OK, now that the IPL issue is worked out, when I try to install the RPM
for this kernel it tells me:
error: Failed dependencies:
mkinitrd = 1.2 is needed by kernel-s390x-2.6.5-7.267
I have an existing RPM database entry for mkinitrd-1.0-199.61. There
doesn't appear to be an RPM
I think I might have an idea as to where your problem MAY be - I'm guessing at
this point so I'd like you to fill in some blanks
Are your Linux guests device number consistent across Linuxen? As in,
/dev/dasdb1 is always device 601 and /{root file system} is 600, etc? Or is it
on Linux A
Did you try the fdr from cyl / to cyl options on the backups? This sounds
eerily familar to our label issue.
Stahr, Lea [EMAIL PROTECTED]
Sent by: Linux on 390 Port LINUX-390@VM.MARIST.EDU
07/25/2006 08:17 AM
Please respond to
Linux on 390 Port LINUX-390@VM.MARIST.EDU
To
What happens when you try to boot a restored system?
Jon
snip
FDR says working as designed. They back up the entire volume and restore
the entire volume. I have restored 3 systems and they DO NOT BOOT.
/snip
--
For LINUX-390
All systems are clones of an original, so all device assignments in
Linux are the same across systems. Here is my ZIPL and FSTAB. I cannot
generate the error messages as I had to re-clone the system and get it
back online.
I was receiving errors on different filesystems and I ran FSCK's on
them,
Here is my FDR restore job step for a volume:
//DISK5DD UNIT=SYSALLDA,VOL=SER=VML061,DISP=OLD
//TAPE5DD DSN=DRP.OPR.SOV.M3DMP.VML061(-3),
//SUBSYS=SOV,DISP=SHR
//SYSPRIN5 DD SYSOUT=*
Lea Stahr
Sr. System Administrator
Linux/Unix Team
630-753-5445
[EMAIL PROTECTED]
Therefore, dm-snapshot and
flashcopy are two sides of the same medal once the entire filesystem
is on a single dasd.
That's a pretty large assumption, especially since the recommended
wisdom for most advanced applications -- like DB/2 and WAS -- is *not*
to put things like data and logs on the
Gentlemen, I must agree with the validity of external backups, but only
when the Linux is down. Any backup taken internally OR externally while
the system is running may not work due to extensive caching by the
system itself and by the applications. If I cannot restore my
application to a current
I agree. I think you should make your backups with the Linux system down. You
should test this to make sure that there is not some other operational error
causing problems.
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of
Stahr, Lea
Sent: Tuesday, July
David Boyes wrote:
Therefore, dm-snapshot and
flashcopy are two sides of the same medal once the entire filesystem
is on a single dasd.
That's a pretty large assumption, especially since the recommended
wisdom for most advanced applications -- like DB/2 and WAS -- is *not*
to put things
Not even remotely close to what I was thinking Greater minds than mine
any ideas?
Stahr, Lea [EMAIL PROTECTED]
Sent by: Linux on 390 Port
LINUX-390@VM.MARIST.EDU
This is somewhat OT because: (1) this is not Linux per-se; (2) the
problem is not on a zSeries. Please ignore (or flame me off-list, if
necessary) if I am being a pest.
Has anybody out there had yast and/or yast2 do a segfault when you
select software to install? This happens both with the
SLES9 SP3 has mkinitrd-1.2-27.21.s390x.rpm
Paul Giordano
Technical Sales Specialist - Linux zSeries
e-business Solutions Technical Sales, Americas
(312) 529-1347
(630) 207-9435 (cell)
email: [EMAIL PROTECTED]
Check http://www.ibm.com/linux for the latest in Linux news and
information
Rich
Then that looks like a bug in the YaST installer, and should be reported
to Novell/SUSE.
Mark Post
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
Nico Potgieter
Sent: Tuesday, July 25, 2006 2:44 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: SLES10 GA
Duh! I thought these s390x images had SP3 installed, it turns out they
are only SP1.
Thanks, Gio.
Paul Giordano wrote:
SLES9 SP3 has mkinitrd-1.2-27.21.s390x.rpm
Paul Giordano
Technical Sales Specialist - Linux zSeries
e-business Solutions Technical Sales, Americas
(312) 529-1347
(630)
On Jul 25, 2006, at 8:49 AM, Carsten Otte wrote:
James Melin wrote:
Not even remotely close to what I was thinking Greater minds
than mine any ideas?
Oh not me. The oops seems to be issued in the filesystem code,
probably reiserfs. Lea, could you run the oops message through
ksymoops
Earlier in this thread there was mention of using clustering
services to avoid outages while doing backups. Wouldn't that involve
the same sort of data-in-flight issues?
J. Leslie Turriff
VM Systems Programmer
Central Missouri State University
Room 400
Ward Edwards Building
Warrensburg
J Leslie Turriff wrote:
Earlier in this thread there was mention of using clustering
services to avoid outages while doing backups. Wouldn't that involve
the same sort of data-in-flight issues?
If the data is shared among the nodes, like with nfs or a cluster
filesystem, yes.
with kind
In all of this, isn't the UNIONFS still a live deal? If as many client
systems as possible use a set of backing F/Ss that are Read Only, wouldn't
the local copy ONLY consist of changed files? And wouldn't the local copy
(I'm not sure, UNIONFS _does_ handle having a R/W copy on a hard disk,
On 7/25/06, John Campbell [EMAIL PROTECTED] wrote:
In all of this, isn't the UNIONFS still a live deal? If as many client
systems as possible use a set of backing F/Ss that are Read Only, wouldn't
Yes, it's mostly working. I have done quite a lot with it on s390. You
probably don't want to
I'm sure you are all sick of these notes by now, so I really hope this will
be the last one (at least for this SHARE). We still have lots of good
sessions available that need the support of a good chairperson. There are
Linux sessions, there are VM sessionssomething for everyone.
So, if you
On Tuesday, 07/25/2006 at 02:19 ZE2, Carsten Otte [EMAIL PROTECTED]
wrote:
Stahr, Lea wrote:
FDR says working as designed. They back up the entire volume and
restore
the entire volume. I have restored 3 systems and they DO NOT BOOT.
How does FDR copy the volume? Do they sequentially copy
Martha,
I'll cover 9257 on Tues at 3pm, 9206 on Tues at 4:30pm, 9249 on Wed at
11am and 9266 on Wed at 3pm if no one else volunteer. People will sure
get tired of seeing my face.
Betsie
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
Martha McConaghy
I'm -sure- these files did not change while I issued these commands.
What explains why MD5SUM's results differ?
([EMAIL PROTECTED]) /mnt/nfs/usilst22/sles10/iso md5sum
SLES-10-CD-s390x-GMC-CD1.iso
5152b2aac4d371d64138171f0d47988e SLES-10-CD-s390x-GMC-CD1.iso
([EMAIL PROTECTED])
On Jul 25, 2006, at 1:08 PM, Scully, William P wrote:
I'm -sure- these files did not change while I issued these commands.
What explains why MD5SUM's results differ?
NFS is giving you corrupt data?
That's really, really alarming.
Adam
In the past when I've seen this result it was either bad RAM or a disk
starting to go bad. If this really was an NFS mount, then you have the
added possibility of network packets being dropped or mangled. In any
case, get out your worry beads.
Mark Post
-Original Message-
From: Linux
I haven't finished all the replies to this thread, so I apologize if I'm
duplicating someone else's comment/question. The thing that comes to my
mind is, what _exactly_ do you mean by not boot. Nothing happens at
all? The system starts to come up, but can't find the root file system?
The root
34 matches
Mail list logo
