Re: Setup the NTP on Slew Mode.
Thank you for answers. (B (BNtp is running on Step Mode only change /etc/ntp.conf. (BI want to run on Slew Mode. (B (BI need to run "ntpd -x" command to run Slew Mode on RedHat (BLinux on xSeries. (B (BPlease teach me, again. (B (B- (BK.M. (B (B__ (BSave the earth (Bhttp://pr.mail.yahoo.co.jp/ondanka/ (B (B-- (BFor LINUX-390 subscribe / signoff / archive access instructions, (Bsend email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit (Bhttp://www.marist.edu/htbin/wlvindex?LINUX-390
Re: MINIX-fs: blocksize too small for device
I actually shutdown the Linux guest, and then performed all my activities from another Linux Guest running the same version of everything. The method I am using is the same method that used to convert the reiserfs root to ext2 to begin with. It is: From z/VM format the mini disk Logoff linux guest Logon to different Linux guest link to old root using hcp link linu ? link to new root using hcp link linu ? chccwdev ?e 0.0.015a chccwdev ?e 0.0.0155 format new root using dasdfmt ?v ?f /dev/dasdf ?d cdl ?l root01 ?b 4096 ?p add partition using fdasd /dev/dasdf mkreiserfs /dev/dasdf1 mount /dev/dasdf1 /mnt/to mount /dev/dasdk1 /mnt/from cd /mnt/from tar -clpSf - . | (cd /mnt/to ; tar -xpSf - ) change ext2 to reiserfs in /mnt/to/etc/fstab mkinitrd /mnt/to chroot /mnt/to zipl exit umount /mnt/from umount /mnt/to chccwdev ?d 0.0.015a chccwdev ?d 0.0.0155 hcp det 15a hcp det 155 logon to my linux z/VM guest det 150 det 155 link * 155 150 mr ipl 150 cl At this point, I am open to any ideas. Peter Ranga Nathan <[EMAIL PROTECTED]> Sent by: Linux on 390 Port 06/10/2005 06:27 PM Please respond to Linux on 390 Port To LINUX-390@VM.MARIST.EDU cc Subject Re: MINIX-fs: blocksize too small for device Peter: Converting the root to another file system is tricky. Bring down to single user create a new partition (you did that) format it as reiserfs (you did that) mount it as /mnt/root for example (you did that) umount any file systems under the root such as /boot, /usr, /var etc. ( so we dont not copy these file systems) cp -ax /* /mnt/root to copy from current root to the new partition unmount the current root unmount /mnt/root, the new one mount the new partition as root mount /usr, /var etc Bring up to network level check everything Change the fstab Do zipl Do mkinitrd reboot and pray! __ Ranga Nathan / CSG Systems Programmer - Specialist; Technical Services; BAX Global Inc. Irvine-California Tel: 714-442-7591 Fax: 714-442-2840 "Peter E. Abresch Jr. - at Pepco" <[EMAIL PROTECTED]> Sent by: Linux on 390 Port 06/10/2005 02:39 PM Please respond to Linux on 390 Port To LINUX-390@VM.MARIST.EDU cc Subject Re: MINIX-fs: blocksize too small for device Ok, now I am charting unknow teritory, how do I do that, and what am I looking for. Peter "Post, Mark K" <[EMAIL PROTECTED]> Sent by: Linux on 390 Port 06/10/2005 05:11 PM Please respond to Linux on 390 Port To LINUX-390@VM.MARIST.EDU cc Subject Re: MINIX-fs: blocksize too small for device You may need to force the pre-load of the reiserfs module. Try mounting the initrd on a loopback device and examining what it has included. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Peter E. Abresch Jr. - at Pepco Sent: Friday, June 10, 2005 5:07 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: MINIX-fs: blocksize too small for device Yes, I already thought of that and went back, recreated it, and added the mkinitrd before the zipl. The same problem. When I mount it on other Linux systems, it looks fine, I just cannot boot from it for some reason. I am at a loss. Peter "Post, Mark K" <[EMAIL PROTECTED]> Sent by: Linux on 390 Port 06/10/2005 04:57 PM Please respond to Linux on 390 Port To LINUX-390@VM.MARIST.EDU cc Subject Re: MINIX-fs: blocksize too small for device Did you re-run mkinitrd before doing the zipl command? Most likely you don't have reiserfs support in the initrd, and it's seeing the reiserfs as minix file system instead. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Peter E. Abresch Jr. - at Pepco Sent: Friday, June 10, 2005 4:02 PM To: LINUX-390@VM.MARIST.EDU Subject: MINIX-fs: blocksize too small for device I wanted to convert my ext2 root filesystem to resierfs. I made a new minidisk, formatted it, put a partition on it, and then performed a mkreiserfs. I mounted it and use the following command to copy everything over. tar -clpSf - . | (cd mnt ; tar -xpSf - ) I chroot to /mnt and performed a zipl. I updated FSTAB and reboot. Here is what I get: Loading kernel/drivers/s390/block/dasd_mod.ko dasd=150-15f Loading kernel/drivers/s390/block/dasd_eckd_mod.ko dasd(eckd): 0.0.0150: 3390/0A(CU:3990/01) Cyl:3338 Head:15 Sec:224 Using cfq io scheduler dasd(eckd): 0.0.0150: (4kB blks): 2403360kB at 48kB/trk compatible disk layout dasda:VOL1/ ROOT01: dasda1 dasd(eckd): 0.0.0151: 3390/0A(CU:3990/01) Cyl:3338 Head:15 Sec:224 dasd(eckd): 0.0.0151: (4kB blks): 2403360kB at 48kB/trk compatible disk layout dasdb:VOL1/ LVM001: dasdb1 dasd(eckd): 0.0.0152: 3390/0A(CU:3990/01) Cyl:3338 Head:15 Sec:224 dasd(eckd): 0.0.0152: (4kB blks): 2403360kB at 48kB/trk compatible disk layout dasdc:VOL1/ LVM002: dasdc1 dasd(eckd): 0.0.015f: 3390/0A(CU:3990/01) Cyl:500 Head:15 Sec:224 dasd(eckd): 0.0.015f: (4kB blks): 36kB at 48kB/trk compatible disk layout das
Re: MINIX-fs: blocksize too small for device
Peter:
Converting the root to another file system is tricky.
Bring down to single user
create a new partition (you did that)
format it as reiserfs (you did that)
mount it as /mnt/root for example (you did that)
umount any file systems under the root such as /boot, /usr, /var etc. (
so we dont not copy these file systems)
cp -ax /* /mnt/root to copy from current root to the new partition
unmount the current root
unmount /mnt/root, the new one
mount the new partition as root
mount /usr, /var etc
Bring up to network level
check everything
Change the fstab
Do zipl
Do mkinitrd
reboot
and pray!
__
Ranga Nathan / CSG
Systems Programmer - Specialist; Technical Services;
BAX Global Inc. Irvine-California
Tel: 714-442-7591 Fax: 714-442-2840
"Peter E. Abresch Jr. - at Pepco" <[EMAIL PROTECTED]>
Sent by: Linux on 390 Port
06/10/2005 02:39 PM
Please respond to
Linux on 390 Port
To
LINUX-390@VM.MARIST.EDU
cc
Subject
Re: MINIX-fs: blocksize too small for device
Ok, now I am charting unknow teritory, how do I do that, and what am I
looking for.
Peter
"Post, Mark K" <[EMAIL PROTECTED]>
Sent by: Linux on 390 Port
06/10/2005 05:11 PM
Please respond to
Linux on 390 Port
To
LINUX-390@VM.MARIST.EDU
cc
Subject
Re: MINIX-fs: blocksize too small for device
You may need to force the pre-load of the reiserfs module. Try mounting
the initrd on a loopback device and examining what it has included.
Mark Post
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
Peter E. Abresch Jr. - at Pepco
Sent: Friday, June 10, 2005 5:07 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: MINIX-fs: blocksize too small for device
Yes, I already thought of that and went back, recreated it, and added
the mkinitrd before the zipl. The same problem. When I mount it on other
Linux systems, it looks fine, I just cannot boot from it for some
reason. I am at a loss.
Peter
"Post, Mark K" <[EMAIL PROTECTED]>
Sent by: Linux on 390 Port
06/10/2005 04:57 PM
Please respond to
Linux on 390 Port
To
LINUX-390@VM.MARIST.EDU
cc
Subject
Re: MINIX-fs: blocksize too small for device
Did you re-run mkinitrd before doing the zipl command? Most likely you
don't have reiserfs support in the initrd, and it's seeing the reiserfs
as minix file system instead.
Mark Post
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
Peter E. Abresch Jr. - at Pepco
Sent: Friday, June 10, 2005 4:02 PM
To: LINUX-390@VM.MARIST.EDU
Subject: MINIX-fs: blocksize too small for device
I wanted to convert my ext2 root filesystem to resierfs. I made a new
minidisk, formatted it, put a partition on it, and then performed a
mkreiserfs. I mounted it and use the following command to copy
everything over.
tar -clpSf - . | (cd mnt ; tar -xpSf - )
I chroot to /mnt and performed a zipl. I updated FSTAB and reboot. Here
is what I get:
Loading kernel/drivers/s390/block/dasd_mod.ko dasd=150-15f Loading
kernel/drivers/s390/block/dasd_eckd_mod.ko
dasd(eckd): 0.0.0150: 3390/0A(CU:3990/01) Cyl:3338 Head:15 Sec:224 Using
cfq io scheduler
dasd(eckd): 0.0.0150: (4kB blks): 2403360kB at 48kB/trk compatible disk
layout dasda:VOL1/ ROOT01: dasda1
dasd(eckd): 0.0.0151: 3390/0A(CU:3990/01) Cyl:3338 Head:15 Sec:224
dasd(eckd): 0.0.0151: (4kB blks): 2403360kB at 48kB/trk compatible disk
layout dasdb:VOL1/ LVM001: dasdb1
dasd(eckd): 0.0.0152: 3390/0A(CU:3990/01) Cyl:3338 Head:15 Sec:224
dasd(eckd): 0.0.0152: (4kB blks): 2403360kB at 48kB/trk compatible disk
layout dasdc:VOL1/ LVM002: dasdc1
dasd(eckd): 0.0.015f: 3390/0A(CU:3990/01) Cyl:500 Head:15 Sec:224
dasd(eckd): 0.0.015f: (4kB blks): 36kB at 48kB/trk compatible disk
layout dasdp:VOL1/ SWAP01: dasdp1 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
MINIX-fs: blocksize too small for device.
Kernel panic: VFS: Unable to mount root fs on dasda1
HCPGIR450W CP entered; disabled wait PSW 000A 80446B76
What does that mean? What did I miss? Thank for any info.
Peter
--
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
This Email message and any attachment may contain information that is
proprietary, legally privileged, confidential and/or subject to
copyright belonging to Pepco Holdings, Inc. or its affiliates ("PHI").
This Email is intended solely for the use of the person(s) to which it
is addressed. If you are not an intended recipient, or the employee or
agent responsible for delivery of this Email to the intended
recipient(s), you are hereby notified that any dissemination,
distribution or copying of this Email is strictly prohibited. If you
have received this message in error, pleas
Re: MINIX-fs: blocksize too small for device
Ok, now I am charting unknow teritory, how do I do that, and what am I
looking for.
Peter
"Post, Mark K" <[EMAIL PROTECTED]>
Sent by: Linux on 390 Port
06/10/2005 05:11 PM
Please respond to
Linux on 390 Port
To
LINUX-390@VM.MARIST.EDU
cc
Subject
Re: MINIX-fs: blocksize too small for device
You may need to force the pre-load of the reiserfs module. Try mounting
the initrd on a loopback device and examining what it has included.
Mark Post
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
Peter E. Abresch Jr. - at Pepco
Sent: Friday, June 10, 2005 5:07 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: MINIX-fs: blocksize too small for device
Yes, I already thought of that and went back, recreated it, and added
the mkinitrd before the zipl. The same problem. When I mount it on other
Linux systems, it looks fine, I just cannot boot from it for some
reason. I am at a loss.
Peter
"Post, Mark K" <[EMAIL PROTECTED]>
Sent by: Linux on 390 Port
06/10/2005 04:57 PM
Please respond to
Linux on 390 Port
To
LINUX-390@VM.MARIST.EDU
cc
Subject
Re: MINIX-fs: blocksize too small for device
Did you re-run mkinitrd before doing the zipl command? Most likely you
don't have reiserfs support in the initrd, and it's seeing the reiserfs
as minix file system instead.
Mark Post
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
Peter E. Abresch Jr. - at Pepco
Sent: Friday, June 10, 2005 4:02 PM
To: LINUX-390@VM.MARIST.EDU
Subject: MINIX-fs: blocksize too small for device
I wanted to convert my ext2 root filesystem to resierfs. I made a new
minidisk, formatted it, put a partition on it, and then performed a
mkreiserfs. I mounted it and use the following command to copy
everything over.
tar -clpSf - . | (cd mnt ; tar -xpSf - )
I chroot to /mnt and performed a zipl. I updated FSTAB and reboot. Here
is what I get:
Loading kernel/drivers/s390/block/dasd_mod.ko dasd=150-15f Loading
kernel/drivers/s390/block/dasd_eckd_mod.ko
dasd(eckd): 0.0.0150: 3390/0A(CU:3990/01) Cyl:3338 Head:15 Sec:224 Using
cfq io scheduler
dasd(eckd): 0.0.0150: (4kB blks): 2403360kB at 48kB/trk compatible disk
layout dasda:VOL1/ ROOT01: dasda1
dasd(eckd): 0.0.0151: 3390/0A(CU:3990/01) Cyl:3338 Head:15 Sec:224
dasd(eckd): 0.0.0151: (4kB blks): 2403360kB at 48kB/trk compatible disk
layout dasdb:VOL1/ LVM001: dasdb1
dasd(eckd): 0.0.0152: 3390/0A(CU:3990/01) Cyl:3338 Head:15 Sec:224
dasd(eckd): 0.0.0152: (4kB blks): 2403360kB at 48kB/trk compatible disk
layout dasdc:VOL1/ LVM002: dasdc1
dasd(eckd): 0.0.015f: 3390/0A(CU:3990/01) Cyl:500 Head:15 Sec:224
dasd(eckd): 0.0.015f: (4kB blks): 36kB at 48kB/trk compatible disk
layout dasdp:VOL1/ SWAP01: dasdp1 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
MINIX-fs: blocksize too small for device.
Kernel panic: VFS: Unable to mount root fs on dasda1
HCPGIR450W CP entered; disabled wait PSW 000A 80446B76
What does that mean? What did I miss? Thank for any info.
Peter
--
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
This Email message and any attachment may contain information that is
proprietary, legally privileged, confidential and/or subject to
copyright belonging to Pepco Holdings, Inc. or its affiliates ("PHI").
This Email is intended solely for the use of the person(s) to which it
is addressed. If you are not an intended recipient, or the employee or
agent responsible for delivery of this Email to the intended
recipient(s), you are hereby notified that any dissemination,
distribution or copying of this Email is strictly prohibited. If you
have received this message in error, please immediately notify the
sender and permanently delete this Email and any copies. PHI policies
expressly prohibit employees from making defamatory or offensive
statements and infringing any copyright or any other legal right by
Email communication. PHI will not accept any liability in respect of
such communications.
--
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
This Email message and any attachment may contain information that is
proprietary, legally privileged, confidential and/or subject to copyright
belonging to Pepco Holdings, Inc. or its affiliat
Re: MINIX-fs: blocksize too small for device
You may need to force the pre-load of the reiserfs module. Try mounting
the initrd on a loopback device and examining what it has included.
Mark Post
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
Peter E. Abresch Jr. - at Pepco
Sent: Friday, June 10, 2005 5:07 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: MINIX-fs: blocksize too small for device
Yes, I already thought of that and went back, recreated it, and added
the mkinitrd before the zipl. The same problem. When I mount it on other
Linux systems, it looks fine, I just cannot boot from it for some
reason. I am at a loss.
Peter
"Post, Mark K" <[EMAIL PROTECTED]>
Sent by: Linux on 390 Port
06/10/2005 04:57 PM
Please respond to
Linux on 390 Port
To
LINUX-390@VM.MARIST.EDU
cc
Subject
Re: MINIX-fs: blocksize too small for device
Did you re-run mkinitrd before doing the zipl command? Most likely you
don't have reiserfs support in the initrd, and it's seeing the reiserfs
as minix file system instead.
Mark Post
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
Peter E. Abresch Jr. - at Pepco
Sent: Friday, June 10, 2005 4:02 PM
To: LINUX-390@VM.MARIST.EDU
Subject: MINIX-fs: blocksize too small for device
I wanted to convert my ext2 root filesystem to resierfs. I made a new
minidisk, formatted it, put a partition on it, and then performed a
mkreiserfs. I mounted it and use the following command to copy
everything over.
tar -clpSf - . | (cd mnt ; tar -xpSf - )
I chroot to /mnt and performed a zipl. I updated FSTAB and reboot. Here
is what I get:
Loading kernel/drivers/s390/block/dasd_mod.ko dasd=150-15f Loading
kernel/drivers/s390/block/dasd_eckd_mod.ko
dasd(eckd): 0.0.0150: 3390/0A(CU:3990/01) Cyl:3338 Head:15 Sec:224 Using
cfq io scheduler
dasd(eckd): 0.0.0150: (4kB blks): 2403360kB at 48kB/trk compatible disk
layout dasda:VOL1/ ROOT01: dasda1
dasd(eckd): 0.0.0151: 3390/0A(CU:3990/01) Cyl:3338 Head:15 Sec:224
dasd(eckd): 0.0.0151: (4kB blks): 2403360kB at 48kB/trk compatible disk
layout dasdb:VOL1/ LVM001: dasdb1
dasd(eckd): 0.0.0152: 3390/0A(CU:3990/01) Cyl:3338 Head:15 Sec:224
dasd(eckd): 0.0.0152: (4kB blks): 2403360kB at 48kB/trk compatible disk
layout dasdc:VOL1/ LVM002: dasdc1
dasd(eckd): 0.0.015f: 3390/0A(CU:3990/01) Cyl:500 Head:15 Sec:224
dasd(eckd): 0.0.015f: (4kB blks): 36kB at 48kB/trk compatible disk
layout dasdp:VOL1/ SWAP01: dasdp1 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
MINIX-fs: blocksize too small for device.
Kernel panic: VFS: Unable to mount root fs on dasda1
HCPGIR450W CP entered; disabled wait PSW 000A 80446B76
What does that mean? What did I miss? Thank for any info.
Peter
--
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
This Email message and any attachment may contain information that is
proprietary, legally privileged, confidential and/or subject to
copyright belonging to Pepco Holdings, Inc. or its affiliates ("PHI").
This Email is intended solely for the use of the person(s) to which it
is addressed. If you are not an intended recipient, or the employee or
agent responsible for delivery of this Email to the intended
recipient(s), you are hereby notified that any dissemination,
distribution or copying of this Email is strictly prohibited. If you
have received this message in error, please immediately notify the
sender and permanently delete this Email and any copies. PHI policies
expressly prohibit employees from making defamatory or offensive
statements and infringing any copyright or any other legal right by
Email communication. PHI will not accept any liability in respect of
such communications.
--
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: MINIX-fs: blocksize too small for device
Yes, I already thought of that and went back, recreated it, and added the
mkinitrd before the zipl. The same problem. When I mount it on other Linux
systems, it looks fine, I just cannot boot from it for some reason. I am
at a loss.
Peter
"Post, Mark K" <[EMAIL PROTECTED]>
Sent by: Linux on 390 Port
06/10/2005 04:57 PM
Please respond to
Linux on 390 Port
To
LINUX-390@VM.MARIST.EDU
cc
Subject
Re: MINIX-fs: blocksize too small for device
Did you re-run mkinitrd before doing the zipl command? Most likely you
don't have reiserfs support in the initrd, and it's seeing the reiserfs
as minix file system instead.
Mark Post
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
Peter E. Abresch Jr. - at Pepco
Sent: Friday, June 10, 2005 4:02 PM
To: LINUX-390@VM.MARIST.EDU
Subject: MINIX-fs: blocksize too small for device
I wanted to convert my ext2 root filesystem to resierfs. I made a new
minidisk, formatted it, put a partition on it, and then performed a
mkreiserfs. I mounted it and use the following command to copy
everything over.
tar -clpSf - . | (cd mnt ; tar -xpSf - )
I chroot to /mnt and performed a zipl. I updated FSTAB and reboot. Here
is what I get:
Loading kernel/drivers/s390/block/dasd_mod.ko dasd=150-15f Loading
kernel/drivers/s390/block/dasd_eckd_mod.ko
dasd(eckd): 0.0.0150: 3390/0A(CU:3990/01) Cyl:3338 Head:15 Sec:224 Using
cfq io scheduler
dasd(eckd): 0.0.0150: (4kB blks): 2403360kB at 48kB/trk compatible disk
layout dasda:VOL1/ ROOT01: dasda1
dasd(eckd): 0.0.0151: 3390/0A(CU:3990/01) Cyl:3338 Head:15 Sec:224
dasd(eckd): 0.0.0151: (4kB blks): 2403360kB at 48kB/trk compatible disk
layout dasdb:VOL1/ LVM001: dasdb1
dasd(eckd): 0.0.0152: 3390/0A(CU:3990/01) Cyl:3338 Head:15 Sec:224
dasd(eckd): 0.0.0152: (4kB blks): 2403360kB at 48kB/trk compatible disk
layout dasdc:VOL1/ LVM002: dasdc1
dasd(eckd): 0.0.015f: 3390/0A(CU:3990/01) Cyl:500 Head:15 Sec:224
dasd(eckd): 0.0.015f: (4kB blks): 36kB at 48kB/trk compatible disk
layout dasdp:VOL1/ SWAP01: dasdp1 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
MINIX-fs: blocksize too small for device.
Kernel panic: VFS: Unable to mount root fs on dasda1
HCPGIR450W CP entered; disabled wait PSW 000A 80446B76
What does that mean? What did I miss? Thank for any info.
Peter
--
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
This Email message and any attachment may contain information that is
proprietary, legally privileged, confidential and/or subject to copyright
belonging to Pepco Holdings, Inc. or its affiliates ("PHI"). This Email is
intended solely for the use of the person(s) to which it is addressed. If
you are not an intended recipient, or the employee or agent responsible for
delivery of this Email to the intended recipient(s), you are hereby notified
that any dissemination, distribution or copying of this Email is strictly
prohibited. If you have received this message in error, please immediately
notify the sender and permanently delete this Email and any copies. PHI
policies expressly prohibit employees from making defamatory or offensive
statements and infringing any copyright or any other legal right by Email
communication. PHI will not accept any liability in respect of such
communications.
--
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: MINIX-fs: blocksize too small for device
Did you re-run mkinitrd before doing the zipl command? Most likely you don't have reiserfs support in the initrd, and it's seeing the reiserfs as minix file system instead. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Peter E. Abresch Jr. - at Pepco Sent: Friday, June 10, 2005 4:02 PM To: LINUX-390@VM.MARIST.EDU Subject: MINIX-fs: blocksize too small for device I wanted to convert my ext2 root filesystem to resierfs. I made a new minidisk, formatted it, put a partition on it, and then performed a mkreiserfs. I mounted it and use the following command to copy everything over. tar -clpSf - . | (cd mnt ; tar -xpSf - ) I chroot to /mnt and performed a zipl. I updated FSTAB and reboot. Here is what I get: Loading kernel/drivers/s390/block/dasd_mod.ko dasd=150-15f Loading kernel/drivers/s390/block/dasd_eckd_mod.ko dasd(eckd): 0.0.0150: 3390/0A(CU:3990/01) Cyl:3338 Head:15 Sec:224 Using cfq io scheduler dasd(eckd): 0.0.0150: (4kB blks): 2403360kB at 48kB/trk compatible disk layout dasda:VOL1/ ROOT01: dasda1 dasd(eckd): 0.0.0151: 3390/0A(CU:3990/01) Cyl:3338 Head:15 Sec:224 dasd(eckd): 0.0.0151: (4kB blks): 2403360kB at 48kB/trk compatible disk layout dasdb:VOL1/ LVM001: dasdb1 dasd(eckd): 0.0.0152: 3390/0A(CU:3990/01) Cyl:3338 Head:15 Sec:224 dasd(eckd): 0.0.0152: (4kB blks): 2403360kB at 48kB/trk compatible disk layout dasdc:VOL1/ LVM002: dasdc1 dasd(eckd): 0.0.015f: 3390/0A(CU:3990/01) Cyl:500 Head:15 Sec:224 dasd(eckd): 0.0.015f: (4kB blks): 36kB at 48kB/trk compatible disk layout dasdp:VOL1/ SWAP01: dasdp1 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 MINIX-fs: blocksize too small for device. Kernel panic: VFS: Unable to mount root fs on dasda1 HCPGIR450W CP entered; disabled wait PSW 000A 80446B76 What does that mean? What did I miss? Thank for any info. Peter -- 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: CDL and LVM Disk VTOC
> On Fri, 2005-06-10 at 16:04 -0400, David Boyes wrote: > > FDR physical dumps will not capture data Linux caches in memory > Ah, light comes on. > I saw your statement that an idle system is not good enough for a > consistent backup, and that a LVM snapshot is required. I guess that > snapshot flushes the cache? Yep, as best it can. > How is that different (other than elapsed > time) from a sync followed by idling the system? sync is basically advisory, a "do this if you can" sort of thing (which is the source of the historic ritual BSD "sync;sync;sync;reboot" mantra). Also, unless you take the system to single-user mode (at which point you might as well have shut down), you've still got some background stuff going on with logging, etc, so you can't get the system to completely idle (unless you tolerate data loss in logs, and/or are willing to run fsck on everything after restoring it). The LVM snapshot tries to get everything to a consistent point, make the snap shot, and then continues on about it's business, leaving you a essentially "offline" copy that nothing is actually updating. You can dump that fairly safely. It (LVM snapshots) are still not as good as a Linux-based backup client strategy, but it's better than just physical dumps. -- 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: CDL and LVM Disk VTOC
On Fri, 2005-06-10 at 16:04 -0400, David Boyes wrote: > FDR physical dumps will not capture data Linux caches in memory Ah, light comes on. I saw your statement that an idle system is not good enough for a consistent backup, and that a LVM snapshot is required. I guess that snapshot flushes the cache? How is that different (other than elapsed time) from a sync followed by idling the system? -- David Andrews A. Duda and Sons, Inc. [EMAIL PROTECTED] -- 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
Thought on DASD backup.
OK, this is old-style "blue skying". I've read a LOT recently about backups of Linux DASD on z/OS using FDR or DFDSS "full volume" backups. The main problem is that Linux caches DASD updates in memory and so the DASD resident image may (likely is) incorrect. Using Linux backup utilities is said by some to be "too slow" and "network intensive" because many such do the backup on z/OS by sending the data over IP. Why not a combination? Have a daemon process on Linux. When the z/OS backup process starts, it establishes an IP connection to this daemon. The z/OS process then starts doing the backup by directly reading the DASD. As I understand it, the "concurrent copy" hardware informs the z/OS backup process of all tracks that are changed after it has backed them up and the z/OS backup process then rereads those tracks. Is this true? If so, then the only thing missing is the data which which is in the cache which had not been commited to DASD since the start of the z/OS backup process. When the z/OS backup process signals the Linux daemon that it is about to finish, the Linux daemon sends only the "dirty" data in the cache over TCP to z/OS. I have no idea how to do anything about z/VM's MDC, if that is involved. This also assumes that a each logical DASD volume under z/VM is a physical DASD volume. The DASD would likely need to be CDL formatted as well. This is just an idea. It may well be too stupid to even refute. I'm not a DASD backup specialist. If any vendor wants the idea, it is free-as-in-beer. -- John McKown Senior Systems Programmer UICI Insurance Center Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its' content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- 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: CDL and LVM Disk VTOC
> I was able to get to them prior to the DBA using YAST2 to set up his > LVM's and doing a format. > Can I go back and reformat them? It seems as though the > YAST2 setup and > format of the LVM did something to them. If you do, you'll erase what's on them. Also, it's not a question of accesing the disks -- you'll still be able to do that regardless of what's on them -- but the real question is whether the backup will be any good for restoring. FDR physical dumps will not capture data Linux caches in memory. If the data hasn't been committed to disk, FDR won't get it because it's not aware of it even being there. -- 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
MINIX-fs: blocksize too small for device
I wanted to convert my ext2 root filesystem to resierfs. I made a new
minidisk, formatted it, put a partition on it, and then performed a
mkreiserfs. I mounted it and use the following command to copy everything
over.
tar -clpSf - . | (cd mnt ; tar -xpSf - )
I chroot to /mnt and performed a zipl. I updated FSTAB and reboot. Here is
what I get:
Loading kernel/drivers/s390/block/dasd_mod.ko dasd=150-15f
Loading kernel/drivers/s390/block/dasd_eckd_mod.ko
dasd(eckd): 0.0.0150: 3390/0A(CU:3990/01) Cyl:3338 Head:15 Sec:224
Using cfq io scheduler
dasd(eckd): 0.0.0150: (4kB blks): 2403360kB at 48kB/trk compatible disk
layout
dasda:VOL1/ ROOT01: dasda1
dasd(eckd): 0.0.0151: 3390/0A(CU:3990/01) Cyl:3338 Head:15 Sec:224
dasd(eckd): 0.0.0151: (4kB blks): 2403360kB at 48kB/trk compatible disk
layout
dasdb:VOL1/ LVM001: dasdb1
dasd(eckd): 0.0.0152: 3390/0A(CU:3990/01) Cyl:3338 Head:15 Sec:224
dasd(eckd): 0.0.0152: (4kB blks): 2403360kB at 48kB/trk compatible disk
layout
dasdc:VOL1/ LVM002: dasdc1
dasd(eckd): 0.0.015f: 3390/0A(CU:3990/01) Cyl:500 Head:15 Sec:224
dasd(eckd): 0.0.015f: (4kB blks): 36kB at 48kB/trk compatible disk
layout
dasdp:VOL1/ SWAP01: dasdp1
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
MINIX-fs: blocksize too small for device.
Kernel panic: VFS: Unable to mount root fs on dasda1
HCPGIR450W CP entered; disabled wait PSW 000A 80446B76
What does that mean? What did I miss? Thank for any info.
Peter
This Email message and any attachment may contain information that is
proprietary, legally privileged, confidential and/or subject to copyright
belonging to Pepco Holdings, Inc. or its affiliates ("PHI"). This Email is
intended solely for the use of the person(s) to which it is addressed. If
you are not an intended recipient, or the employee or agent responsible for
delivery of this Email to the intended recipient(s), you are hereby notified
that any dissemination, distribution or copying of this Email is strictly
prohibited. If you have received this message in error, please immediately
notify the sender and permanently delete this Email and any copies. PHI
policies expressly prohibit employees from making defamatory or offensive
statements and infringing any copyright or any other legal right by Email
communication. PHI will not accept any liability in respect of such
communications.
--
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: CDL and LVM Disk VTOC
I was able to get to them prior to the DBA using YAST2 to set up his LVM's and doing a format. Can I go back and reformat them? It seems as though the YAST2 setup and format of the LVM did something to them. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Friday, June 10, 2005 3:48 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: CDL and LVM Disk VTOC > VERY VERY new to Linux. Want to use FDR to backup Linux disks > (Physical backup). This was working until we created LVM's on them > under LINUX as EXT3. I see info about doing an fdasd to them to > change them to CDL. I just want to verify that this will not harm my > data or LVM in anyway. Unless you explicitly created them as LDL disks, they already are CDL format. Be aware that if you want a consistent backup using FDR (and you do not have their Linux backup extension), the Linux guest MUST be shut down (not just idle, SHUT DOWN) before you do the backup, or you must do a LVM snapshot to get a consistent image. -- 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: CDL and LVM Disk VTOC
> VERY VERY new to Linux. Want to use FDR to backup Linux > disks (Physical > backup). This was working until we created LVM's on them > under LINUX as > EXT3. I see info about doing an fdasd to them to change them > to CDL. I > just want to verify that this will not harm my data or LVM in anyway. Unless you explicitly created them as LDL disks, they already are CDL format. Be aware that if you want a consistent backup using FDR (and you do not have their Linux backup extension), the Linux guest MUST be shut down (not just idle, SHUT DOWN) before you do the backup, or you must do a LVM snapshot to get a consistent image. -- 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: XVNC/VNC server strangeness
I will try this to see if it fixes our problem with SLES 9/LPAR. When I run Yast2 from a client, the last row is missing. It makes it tricky to see the OK/CANCEL buttons. Regards, [EMAIL PROTECTED] NCCI Boca Raton, Florida 561.893.2415 greetings / avec mes meilleures salutations / Cordialmente mit freundlichen Grüßen / Med vänlig hälsning Michael MacIsaac <[EMAIL PROTECTED]To: LINUX-390@VM.MARIST.EDU om> cc: Sent by: Linux onSubject: Re: XVNC/VNC server strangeness 390 Port <[EMAIL PROTECTED] IST.EDU> 06/10/2005 02:49 PM Please respond to Linux on 390 Port James, > I get that wire frame skelton > thing that allows you to place the window before it really opens. This is the behavior of twm which is the tiny window manager (I'm trying to think of a more descriptive adjective than tiny :)). I'd recommend a different window manager. Some people like fvwm, I like mwm - Motif (from the good 'ol AIX days). To change it here's what I do: -) Run "vncserver" from Linux and set a password -) Immediately kill that session: "vncserver -kill :1" -) Be sure motif is installed: "[yast -i|up2date] openmotif" -) Change twm to mwm in /root/.vnc/xstartup -) Run "vncserver" again - I'm sure you'll like the windows better. Hope this helps. "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 The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message may be an attorney-client communication and/or work product and as such is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. -- 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
Apache2 php4 problem
Hi All, We have just installed SuSE SLES9 under VM and are trying to get the LAMP environment up, but are having trouble getting php4 to load with Apache2. We have noticed that Apache2 doesn't bring up PHP4: Starting httpd2 (prefork) ..done On SLES8, when Apache1.3 comes up, we see the following: Starting httpd ( Mailman PERL PHP4 Python) ..done Our manuals seem to say that we can't use the SLES8 form of the httpd start with "prefork". Apache2 seems to start but we can't find anything in the various error logs to point us on our way and the php4 test script just stalls. Any suggestions? Breck Campbell Systems Developer II 133 State Street Montpelier, VT 05633-6601 Telephone (802) 828-4692 E-mail [EMAIL PROTECTED] -- 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: XVNC/VNC server strangeness
Michael, that helped a lot thank! I agree that mwm is much less ugly than twm. The problem turned out to be a JRE level difference actually, but MWM allowed me to see enough of the window to recognize the difference in rendering of the windows to be able to tell it was a JRE problem. -J Michael MacIsaac <[EMAIL PROTECTED] om>To Sent by: Linux on LINUX-390@VM.MARIST.EDU 390 Port cc <[EMAIL PROTECTED] IST.EDU> Subject Re: XVNC/VNC server strangeness 06/10/2005 01:49 PM Please respond to Linux on 390 Port <[EMAIL PROTECTED] IST.EDU> James, > I get that wire frame skelton > thing that allows you to place the window before it really opens. This is the behavior of twm which is the tiny window manager (I'm trying to think of a more descriptive adjective than tiny :)). I'd recommend a different window manager. Some people like fvwm, I like mwm - Motif (from the good 'ol AIX days). To change it here's what I do: -) Run "vncserver" from Linux and set a password -) Immediately kill that session: "vncserver -kill :1" -) Be sure motif is installed: "[yast -i|up2date] openmotif" -) Change twm to mwm in /root/.vnc/xstartup -) Run "vncserver" again - I'm sure you'll like the windows better. Hope this helps. "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
Re: RHEL 4
> I made a minimal installation (i.e. no X I always try to use minimal install for SLES9 which includes enough packages to run X clients. However, RHEL4 minimal is just a bit too minimal. Let's face it eventually you will need to run an X app so it's convenient to have the rat's nest of X packages available. So when installing RHEL4, I check the "X" group (first group at top of list) and uncheck all other packages groups. This yields a root file system of about 1GB. Hope this helps. "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: XVNC/VNC server strangeness
James, > I get that wire frame skelton > thing that allows you to place the window before it really opens. This is the behavior of twm which is the tiny window manager (I'm trying to think of a more descriptive adjective than tiny :)). I'd recommend a different window manager. Some people like fvwm, I like mwm - Motif (from the good 'ol AIX days). To change it here's what I do: -) Run "vncserver" from Linux and set a password -) Immediately kill that session: "vncserver -kill :1" -) Be sure motif is installed: "[yast -i|up2date] openmotif" -) Change twm to mwm in /root/.vnc/xstartup -) Run "vncserver" again - I'm sure you'll like the windows better. Hope this helps. "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
CDL and LVM Disk VTOC
VERY VERY new to Linux. Want to use FDR to backup Linux disks (Physical backup). This was working until we created LVM's on them under LINUX as EXT3. I see info about doing an fdasd to them to change them to CDL. I just want to verify that this will not harm my data or LVM in anyway. -- 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: MTU consideration for dummy/eth interfaces
> According to everything I have read about the various OSA > adapters, the maximum frame size supported is 8992. Are you > rounding up to 9,000, or am I missing something? 8992 plus frame headers and some misc stuff. > If I have the OSA with MTU=8992 in a small private network, > and a node on the network has the MTU defined as 9000, I > assume there could be some switch overhead in translating the > frames. Is there a benefit to having every node at 8992 as > opposed to 9000, which seems to be a common 'default' for a > net with jumbo frames? As long as every device has a *bigger* MTU, you're fine and there's no real benefit other than maybe a few wasted cycles in the switch copying the extra 8 bytes when the frame is sent. The killer is if one device has a *smaller* MTU, forcing fragmentation and reassembly. -- 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: Setup the NTP on Slew Mode.
> I have SLES9s for NTP-Server(NTPSVR) NTP-client(NTPCLT). > I want to synchronize between NTPSVR and NTPCLT on Slew > Mode. > But I don't know which files should I change. > Please teach me. /etc/ntp.conf Comments in the file document what to change (essentially the "server... " lines that identify what time server to contact). You can also use the YaST NTP client configuration tool. -- 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: MTU consideration for dummy/eth interfaces
rounding up. Regards, [EMAIL PROTECTED] NCCI Boca Raton, Florida 561.893.2415 greetings / avec mes meilleures salutations / Cordialmente mit freundlichen Grüßen / Med vänlig hälsning "Ledbetter, Scott E" <[EMAIL PROTECTED]To: LINUX-390@VM.MARIST.EDU AGETEK.COM> cc: Sent by: Linux on 390Subject: Re: MTU consideration for dummy/eth interfaces Port <[EMAIL PROTECTED] EDU> 06/10/2005 11:15 AM Please respond to Linux on 390 Port According to everything I have read about the various OSA adapters, the maximum frame size supported is 8992. Are you rounding up to 9,000, or am I missing something? Also, perhaps a nework guru out there can answer this question: If I have the OSA with MTU=8992 in a small private network, and a node on the network has the MTU defined as 9000, I assume there could be some switch overhead in translating the frames. Is there a benefit to having every node at 8992 as opposed to 9000, which seems to be a common 'default' for a net with jumbo frames? Thanks, Scott Ledbetter StorageTek -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Uriel Carrasquilla Sent: Friday, June 10, 2005 7:50 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: MTU consideration for dummy/eth interfaces If you are using OSA interface, you may want to consider an MTU of 9,000. On NIC/1-G ethernet cards, 9,000 is the recommended value. I also had the same problem with my zebra/ospfd+dummy and the network guys did not want to change the router's MTU to 9000 so I live with 1500. It is early for me to tell if it is rock solid but I realize that my entire network connection to my zLinux now depends on how stable zebra/ospfd proves to be. Regards, [EMAIL PROTECTED] NCCI Boca Raton, Florida 561.893.2415 greetings / avec mes meilleures salutations / Cordialmente mit freundlichen Grüßen / Med vänlig hälsning Max <[EMAIL PROTECTED]To: LINUX-390@VM.MARIST.EDU .it> cc: Sent by: Linux onSubject: MTU consideration for dummy/eth interfaces 390 Port <[EMAIL PROTECTED] IST.EDU> 06/09/2005 04:35 AM Please respond to Linux on 390 Port Guys, I've configured two ethernet interfaces with a dummy interface in order to have an High Availability network. I'm using Zebra for dynamic routing. I was able to work with this system only changing the ethernet MTU from 1492 (Linux default) to 1500... Seems related to my router configuration (4507)... Do you think that I can experience some problem with 1500 MTU size or I need to change some value on router for compatibility with zLinux systems? Ciao Max ___ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it -- 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/wl
Re: Setup the NTP on Slew Mode.
http://www.google.com/search?q=ntp+configure Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of mainframe_s390 Sent: Friday, June 10, 2005 12:01 PM To: LINUX-390@VM.MARIST.EDU Subject: Setup the NTP on Slew Mode. Hi,all Now,I use SLES9 for z. I have SLES9s for NTP-Server(NTPSVR) NTP-client(NTPCLT). I want to synchronize between NTPSVR and NTPCLT on Slew Mode. But I don't know which files should I change. Please teach me. Thank you. - K.M. __ Save the earth http://pr.mail.yahoo.co.jp/ondanka/ -- 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
RHEL 4
Hi I installed RHEL 4 on zSeries. I made a minimal installation (i.e. no X, Gnome etc) Now I want to config my packages with system-config-packages. But it stops and says that my system has no fonts installed. Is there a possibility to configure the packages with a ncurses based tool? -- cheers, reen -- 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: MTU consideration for dummy/eth interfaces
According to everything I have read about the various OSA adapters, the maximum frame size supported is 8992. Are you rounding up to 9,000, or am I missing something? Also, perhaps a nework guru out there can answer this question: If I have the OSA with MTU=8992 in a small private network, and a node on the network has the MTU defined as 9000, I assume there could be some switch overhead in translating the frames. Is there a benefit to having every node at 8992 as opposed to 9000, which seems to be a common 'default' for a net with jumbo frames? Thanks, Scott Ledbetter StorageTek -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Uriel Carrasquilla Sent: Friday, June 10, 2005 7:50 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: MTU consideration for dummy/eth interfaces If you are using OSA interface, you may want to consider an MTU of 9,000. On NIC/1-G ethernet cards, 9,000 is the recommended value. I also had the same problem with my zebra/ospfd+dummy and the network guys did not want to change the router's MTU to 9000 so I live with 1500. It is early for me to tell if it is rock solid but I realize that my entire network connection to my zLinux now depends on how stable zebra/ospfd proves to be. Regards, [EMAIL PROTECTED] NCCI Boca Raton, Florida 561.893.2415 greetings / avec mes meilleures salutations / Cordialmente mit freundlichen Grüßen / Med vänlig hälsning Max <[EMAIL PROTECTED]To: LINUX-390@VM.MARIST.EDU .it> cc: Sent by: Linux onSubject: MTU consideration for dummy/eth interfaces 390 Port <[EMAIL PROTECTED] IST.EDU> 06/09/2005 04:35 AM Please respond to Linux on 390 Port Guys, I've configured two ethernet interfaces with a dummy interface in order to have an High Availability network. I'm using Zebra for dynamic routing. I was able to work with this system only changing the ethernet MTU from 1492 (Linux default) to 1500... Seems related to my router configuration (4507)... Do you think that I can experience some problem with 1500 MTU size or I need to change some value on router for compatibility with zLinux systems? Ciao Max ___ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it -- 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 The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message may be an attorney-client communication and/or work product and as such is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this com
Setup the NTP on Slew Mode.
Hi,all (B (BNow,I use SLES9 for z. (BI have SLES9s for NTP-Server(NTPSVR) NTP-client(NTPCLT). (BI want to synchronize between NTPSVR and NTPCLT on Slew (BMode. (BBut I don't know which files should I change. (BPlease teach me. (B (BThank you. (B- (BK.M. (B (B (B__ (BSave the earth (Bhttp://pr.mail.yahoo.co.jp/ondanka/ (B (B-- (BFor LINUX-390 subscribe / signoff / archive access instructions, (Bsend email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit (Bhttp://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Amanda for backups
Hipersockets under z/VM 4.2. But no MVS here. No HSM either. Tom Duerbusch THD Consulting >>> [EMAIL PROTECTED] 06/10/05 10:03 AM >>> Tom: are we talking a real network or hipersockets for LPAR's or VM? I am in the process of implementing Amanda for 4xLPAR's running zLinux with a zOS NFS Mount Point where HSM does the heavy lifting with the Tape Drives. We are also in the process of switching HSM to use our Virtual Tape System (STK). No tape drives are used in our zLinux environment (don't need to). Depending on contention, I will use dedicated hipersockets for general purpose applications and a set of hipersockets for system applications. we run something similar to Amanda for our Open System over a real network with one server doing all of the server functions (dedicated). We set up a parallel IP network just for the purpose of backups (IP). We are also looking into a parallel SAN network for serverless backups. I agree, I would not want to be on general IP network for my backups. Regards, [EMAIL PROTECTED] NCCI Boca Raton, Florida 561.893.2415 greetings / avec mes meilleures salutations / Cordialmente mit freundlichen Grüßen / Med vänlig hälsning Tom Duerbusch <[EMAIL PROTECTED]To: LINUX-390@VM.MARIST.EDU net> cc: Sent by: Linux onSubject: Re: Amanda for backups 390 Port <[EMAIL PROTECTED] IST.EDU> 06/09/2005 02:24 PM Please respond to Linux on 390 Port Thanks The kind of stuff I was looking for. Being old, I do not favor transmitting data over communications. It usually is higher overhead then transmission over hardware. i.e. transmission over IP, to get to escon-tape, instead of just writting to tape. And that got reinforced with my experiences with real LAN systems. I would be trying to fix a mainframe problem, by dialing into an IP connection, and find I can't get anything done because the LAN people are backing up servers over the LAN. So either the mainframe sat, or I had to come in for a coax session. In this case, I finally talked a LAN guy to come in at midnight - 1 AM and check the network performance. The light-weight tools he had showed collisions being 90+ percent of the transmissions. No wonder it seemed that I never got any tn3270 packets. But it took them 2 years to do anything about it, so I'm still really negative about using communications to do transfers. But Ill get over it, eventually. Like I said, the more I read about Amanda, the more I want to use it the way it was ment to be. But I'm still not convinced that Amanda is/will be our backup solution. TSM initially sounded good, but it required scsi attached tape drives (i.e. FCP attached), and at this point, I don't want to have separate FICON and FCP attached tape drives. Right now, due to cost and I don't perceive the need. In a year or two, that may change. Tom Duerbusch THD Consulting David Boyes wrote: > On Tue, Jun 07, 2005 at 12:54:38PM -0500, Tom Duerbusch wrote: > >>Using Amanda in a traditional network world, Amanda would be running on >>a server with tape drives and the clients will be running on other >>images and the backups are
XVNC/VNC server strangeness
I am attempting to install WebSphere Studio Application Monitor which oh so brilliantly elects to run a GUI installer on z/Linux. Mostly this is working but I have one server that the behaviour seems to be different on. Both servers are launching Xvnc via the vncserver wrapper with the following properties: vncserver -depth 24 -geometry 1024x768 :0 The one that is giving me problems seems to show a slightly different color scheme for one, which is odd to me. Secondly, when it gets around to doing the installer popup window, which is after the window that asks me to select language (which I noticed the color difference on this linux instance vs the one I installed on yesterday) I get that wire frame skelton thing that allows you to place the window before it really opens. When I do that the window is roughly half the size of the skeleton, and cannot be resized. It is effectively cutting off the 'buttons' and other selection objects in the gui popup that I need to do things with. Has anyone seen this happen before? I've tried a color depth of 16 but what I get is unreadable. I've tried a color depth of 20 and the installer dies. Same with a color depth of 28. Color depth of 32 doesn't everr produce a gui it just pegs the CPU until I kill it. I am wondering if there are alternate xwindows export things I could try, or if someone might be able to advise on how to invoke Xvnc directly to get around this problem -- 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: Amanda for backups
Tom: are we talking a real network or hipersockets for LPAR's or VM? I am in the process of implementing Amanda for 4xLPAR's running zLinux with a zOS NFS Mount Point where HSM does the heavy lifting with the Tape Drives. We are also in the process of switching HSM to use our Virtual Tape System (STK). No tape drives are used in our zLinux environment (don't need to). Depending on contention, I will use dedicated hipersockets for general purpose applications and a set of hipersockets for system applications. we run something similar to Amanda for our Open System over a real network with one server doing all of the server functions (dedicated). We set up a parallel IP network just for the purpose of backups (IP). We are also looking into a parallel SAN network for serverless backups. I agree, I would not want to be on general IP network for my backups. Regards, [EMAIL PROTECTED] NCCI Boca Raton, Florida 561.893.2415 greetings / avec mes meilleures salutations / Cordialmente mit freundlichen Grüßen / Med vänlig hälsning Tom Duerbusch <[EMAIL PROTECTED]To: LINUX-390@VM.MARIST.EDU net> cc: Sent by: Linux onSubject: Re: Amanda for backups 390 Port <[EMAIL PROTECTED] IST.EDU> 06/09/2005 02:24 PM Please respond to Linux on 390 Port Thanks The kind of stuff I was looking for. Being old, I do not favor transmitting data over communications. It usually is higher overhead then transmission over hardware. i.e. transmission over IP, to get to escon-tape, instead of just writting to tape. And that got reinforced with my experiences with real LAN systems. I would be trying to fix a mainframe problem, by dialing into an IP connection, and find I can't get anything done because the LAN people are backing up servers over the LAN. So either the mainframe sat, or I had to come in for a coax session. In this case, I finally talked a LAN guy to come in at midnight - 1 AM and check the network performance. The light-weight tools he had showed collisions being 90+ percent of the transmissions. No wonder it seemed that I never got any tn3270 packets. But it took them 2 years to do anything about it, so I'm still really negative about using communications to do transfers. But Ill get over it, eventually. Like I said, the more I read about Amanda, the more I want to use it the way it was ment to be. But I'm still not convinced that Amanda is/will be our backup solution. TSM initially sounded good, but it required scsi attached tape drives (i.e. FCP attached), and at this point, I don't want to have separate FICON and FCP attached tape drives. Right now, due to cost and I don't perceive the need. In a year or two, that may change. Tom Duerbusch THD Consulting David Boyes wrote: > On Tue, Jun 07, 2005 at 12:54:38PM -0500, Tom Duerbusch wrote: > >>Using Amanda in a traditional network world, Amanda would be running on >>a server with tape drives and the clients will be running on other >>images and the backups are taken over the network. Sure, saves on tape >>drives. >>But on a mainframe, each image can own the tape drives. >>I'm wondering (pros and
Re: LVM fragility?
On Jun 10, 2005, at 7:19 AM, Phil Smith III wrote: At a customer site yesterday I found something that's either an amazing level of fragility in LVM or else I'm just not understanding it. (This is LVM V1; I understand V2 is a complete rewrite and probably avoids this, but that doesn't help with production on older 2.4 kernels.) 2) Is there an easy way to recover? Yes. Always add your new dasd definitions at the END of dasd= in your parmline. That line can be out of address order. Specifying the address in the parmline, whether there's a disk there or not, reserves the slot. Adam -- 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: MTU consideration for dummy/eth interfaces
If you are using OSA interface, you may want to consider an MTU of 9,000. On NIC/1-G ethernet cards, 9,000 is the recommended value. I also had the same problem with my zebra/ospfd+dummy and the network guys did not want to change the router's MTU to 9000 so I live with 1500. It is early for me to tell if it is rock solid but I realize that my entire network connection to my zLinux now depends on how stable zebra/ospfd proves to be. Regards, [EMAIL PROTECTED] NCCI Boca Raton, Florida 561.893.2415 greetings / avec mes meilleures salutations / Cordialmente mit freundlichen Grüßen / Med vänlig hälsning Max <[EMAIL PROTECTED]To: LINUX-390@VM.MARIST.EDU .it> cc: Sent by: Linux onSubject: MTU consideration for dummy/eth interfaces 390 Port <[EMAIL PROTECTED] IST.EDU> 06/09/2005 04:35 AM Please respond to Linux on 390 Port Guys, I've configured two ethernet interfaces with a dummy interface in order to have an High Availability network. I'm using Zebra for dynamic routing. I was able to work with this system only changing the ethernet MTU from 1492 (Linux default) to 1500... Seems related to my router configuration (4507)... Do you think that I can experience some problem with 1500 MTU size or I need to change some value on router for compatibility with zLinux systems? Ciao Max ___ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it -- 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 The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message may be an attorney-client communication and/or work product and as such is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. -- 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: LVM fragility?
*** Reply to note of Fri, 10 Jun 2005 08:32:46 -0400 (EDT) *** by LINUX-390@VM.MARIST.EDU The nice thing about LVM is that you can change the DASD addresses (disk letters) and still works as each physical LVM volume gets it own unique id (uuid). For example if you have an LVM group with 2 disks, dasdt1 (400) and dasdu1 (401), you can change them to dasdv1(402) and dasdx1(404) with no problems. Sal Neale Ferguson <[EMAIL PROTECTED]> writes: >Change the order of dasd= in zipl.conf so that the new minidisk is last >in the list so that the existing disks don't get their ids changed. > >-Original Message- >At a customer site yesterday I found something that's either an amazing >level of fragility in LVM or else I'm just not understanding it. (This >is LVM V1; I understand V2 is a complete rewrite and probably avoids >this, but that doesn't help with production on older 2.4 kernels.) > >They had a logical volume created from (say) dasdt1, dasdu1, dasdv1. >Then we added a minidisk at a lower virtual address. > >This "pushed" the existing minidisks "down", so the virtual devices in >the LVM were now dasdu1, dasdv1, dasdw1! > >So I have several questions: >1) Have others observed this, or did we do something weird? >2) Is there an easy way to recover? >3) Is there another way to address the devices -- one of our guys >suggested /dev/dasd/4001, /dev/dasd/4002, etc. instead of /dev/dasdt1, >/dev/dasdu1, etc. (I plan to try this today, but thought I'd ask). >4) If the previous suggestion works, is there a reasonable way to change >an existing LVM from the 'old' addressing scheme to the 'new' one? > >-- >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
More on LVM fragility
Something I didn't know until now: those /dev/dasd// device nodes are created by Levanta, so while this may be a solution for us, it wont mean anything to the rest of you... -- ...phsiii Phil Smith III Levanta, Inc. [EMAIL PROTECTED] (703) 476-4511 (office) (703) 568-6662 (cell) Levanta. Managing Data Center Scale-Out. -- 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: SLES9 primary_router
To dynamically set the primary router flag, you write a string to the "route4" file:: echo "primary_router" >/sys/devices/qeth/0.0.0100/route4 You can check the setting by displaying the contents of that file. To make it active when the device is initialized, you put: QETH_OPTIONS="route4=primary_rotuer" in your /etc/sysconfig/hardware/hwcfg-qeth-bus-ccw-0.0.0100 file. On 6/10/05, Troyski <[EMAIL PROTECTED]> wrote: > Hi all, > > Just a quickie (I hope). > > How to I tell eth0 to register with z/VM as a primary router? > > I understand you can add the "primary_router" command to > /etc/chandev.conf in SLES8, but of course we have no such file in > SLES9. I also know in SLES8 you can do this dynamically using echo > "primary_router eth0" > /proc/qethbut this doesn't seem to work - > I don't see a message in dmesg output and I don't see the linux guest > showing router in "q vswitch det" under z/VM. > > I've also tried adding QETH_OPTIONS="primary_router" to > /etc/sysconfig/hardware/hwcfg-qeth-bus-ccw-0.0.0100. > > Any clues much appreciated. > > -- > ---oOo--- > Troyski (Public Email) > . > :: Web/PGP Key:: http://troyski.homeip.net :: > :: MSN [EMAIL PROTECTED] :: YIM troy_muller :: > :: ICQ #31206542 :: AIM trymul :: > :: GS500E XJ600S :: LCDR Troyski:: > . > :: NCOS || CQC || SCI100 || SCI101 :: > :: NUR101 || SCC#60975:: > . > \'He who dies with the most toys - wins.\' > > ---oOo--- > > -- > 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 > -- Bruce Hayden IBM Global Services zSeries Linux Endicott, NY -- 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
SLES9 primary_router
Hi all, Just a quickie (I hope). How to I tell eth0 to register with z/VM as a primary router? I understand you can add the "primary_router" command to /etc/chandev.conf in SLES8, but of course we have no such file in SLES9. I also know in SLES8 you can do this dynamically using echo "primary_router eth0" > /proc/qethbut this doesn't seem to work - I don't see a message in dmesg output and I don't see the linux guest showing router in "q vswitch det" under z/VM. I've also tried adding QETH_OPTIONS="primary_router" to /etc/sysconfig/hardware/hwcfg-qeth-bus-ccw-0.0.0100. Any clues much appreciated. -- ---oOo--- Troyski (Public Email) . :: Web/PGP Key:: http://troyski.homeip.net :: :: MSN [EMAIL PROTECTED] :: YIM troy_muller :: :: ICQ #31206542 :: AIM trymul :: :: GS500E XJ600S :: LCDR Troyski:: . :: NCOS || CQC || SCI100 || SCI101 :: :: NUR101 || SCC#60975:: . \'He who dies with the most toys - wins.\' ---oOo--- -- 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: LVM fragility?
This is a behavior that is "strange" to us mainframers. When you add more dasd add it to the end of the "dasd=" string, wherever you have that defined. With linux, regardless of the physical address, the first dasd defined is the dasda device, the second b, etc. By putting new devices at the end of the definition string they will take the next slot. In future systems you can put extra addresses in the dasd= string to reserve slots for devices to possibly be added later on. Good Luck! Dennis |+-> || Phil Smith III | || <[EMAIL PROTECTED]| || .com> | || Sent by: Linux | || on 390 Port| || <[EMAIL PROTECTED]| || ARIST.EDU> | || | || | || 06/10/2005 | || 07:19 AM | || Please respond | || to Linux on 390| || Port | || | |+-> >---| | | | To: LINUX-390@VM.MARIST.EDU | | cc: | | Subject: LVM fragility? | >---| At a customer site yesterday I found something that's either an amazing level of fragility in LVM or else I'm just not understanding it. (This is LVM V1; I understand V2 is a complete rewrite and probably avoids this, but that doesn't help with production on older 2.4 kernels.) They had a logical volume created from (say) dasdt1, dasdu1, dasdv1. Then we added a minidisk at a lower virtual address. This "pushed" the existing minidisks "down", so the virtual devices in the LVM were now dasdu1, dasdv1, dasdw1! So I have several questions: 1) Have others observed this, or did we do something weird? 2) Is there an easy way to recover? 3) Is there another way to address the devices -- one of our guys suggested /dev/dasd/4001, /dev/dasd/4002, etc. instead of /dev/dasdt1, /dev/dasdu1, etc. (I plan to try this today, but thought I'd ask). 4) If the previous suggestion works, is there a reasonable way to change an existing LVM from the 'old' addressing scheme to the 'new' one? Thanks, -- ...phsiii Phil Smith III Levanta, Inc. [EMAIL PROTECTED] (703) 476-4511 (office) (703) 568-6662 (cell) Levanta. Managing Data Center Scale-Out. -- 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: LVM fragility?
Change the order of dasd= in zipl.conf so that the new minidisk is last in the list so that the existing disks don't get their ids changed. -Original Message- At a customer site yesterday I found something that's either an amazing level of fragility in LVM or else I'm just not understanding it. (This is LVM V1; I understand V2 is a complete rewrite and probably avoids this, but that doesn't help with production on older 2.4 kernels.) They had a logical volume created from (say) dasdt1, dasdu1, dasdv1. Then we added a minidisk at a lower virtual address. This "pushed" the existing minidisks "down", so the virtual devices in the LVM were now dasdu1, dasdv1, dasdw1! So I have several questions: 1) Have others observed this, or did we do something weird? 2) Is there an easy way to recover? 3) Is there another way to address the devices -- one of our guys suggested /dev/dasd/4001, /dev/dasd/4002, etc. instead of /dev/dasdt1, /dev/dasdu1, etc. (I plan to try this today, but thought I'd ask). 4) If the previous suggestion works, is there a reasonable way to change an existing LVM from the 'old' addressing scheme to the 'new' one? -- 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: LVM fragility?
1) Have others observed this, or did we do something weird? This seems normal to me. You should only add disks to the back of the list. 2) Is there an easy way to recover? Removing the new added dasd and add it with a higher VDEV number to the end of the list. 3) Is there another way to address the devices -- one of our guys suggested /dev/dasd/4001, /dev/dasd/4002, etc. instead of /dev/dasdt1, /dev/dasdu1, etc. (I plan to try this today, but thought I'd ask). We started our LVM disks with VDEV 300 and only add to this list. 4) If the previous suggestion works, is there a reasonable way to change an existing LVM from the 'old' addressing scheme to the 'new' one? You'll have to add the disks in the same order with new VDEV adresses. Regards, Kurt. Securex ICT Belgium - Confidentiality Notice - This communication and the information it contains is intended (a) for the person(s) or organization(s) named above and for no other person or organization, and (b) may be confidential, legally privileged and protected by law. Unauthorized use, copying or disclosure of any of it may be unlawful! If you receive this communication in error, please notify us immediately, destroy any copies and delete it from your computer system. Please consult our disclaimer on our site www.securex.be Thank you. -- 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
LVM fragility?
At a customer site yesterday I found something that's either an amazing level of fragility in LVM or else I'm just not understanding it. (This is LVM V1; I understand V2 is a complete rewrite and probably avoids this, but that doesn't help with production on older 2.4 kernels.) They had a logical volume created from (say) dasdt1, dasdu1, dasdv1. Then we added a minidisk at a lower virtual address. This "pushed" the existing minidisks "down", so the virtual devices in the LVM were now dasdu1, dasdv1, dasdw1! So I have several questions: 1) Have others observed this, or did we do something weird? 2) Is there an easy way to recover? 3) Is there another way to address the devices -- one of our guys suggested /dev/dasd/4001, /dev/dasd/4002, etc. instead of /dev/dasdt1, /dev/dasdu1, etc. (I plan to try this today, but thought I'd ask). 4) If the previous suggestion works, is there a reasonable way to change an existing LVM from the 'old' addressing scheme to the 'new' one? Thanks, -- ...phsiii Phil Smith III Levanta, Inc. [EMAIL PROTECTED] (703) 476-4511 (office) (703) 568-6662 (cell) Levanta. Managing Data Center Scale-Out. -- 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: PHP connectivity to Oracle
Hi , You need the Oracle Client 10g ( all the products , we tried just clients and don't works ) and after compile php with a config like this : ./configure '--prefix=/usr' '--datadir=/usr/share/php' '-- mandir=/usr/share/man' '--bindir=/usr/bin' '--libdir=/usr/share' '-- includedir=/usr/include' '--with-_lib=lib64' '--with-config-file- path=/etc' '--with-exec-dir=/usr/lib64/php/bin' '--enable-debug' '-- enable-inline-optimization' '--enable-memory-limit' '--enable-magic- quotes' '--enable-safe-mode' '--enable-session' '--with-mysql' '-- enable-sigchild' '--without-pear' '--without-openssl' '--with- apxs2=/usr/sbin/apxs2-prefork' '--with-sablot' '--with- oci8=/usr/local/ora-client' '--with-xslt-sablot=/usr/local/sablot' '-- enable-bcmath' '--enable-track-vars' So we will have Oracle support in PHP . Em Qui, 2005-06-09 C s 15:29 -0500, McKown, John escreveu: > > -Original Message- > > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On > > Behalf Of Thomas Kern > > Sent: Thursday, June 09, 2005 11:24 AM > > To: LINUX-390@VM.MARIST.EDU > > Subject: PHP connectivity to Oracle > > > > > > Not being a database person I need to ask this rather general > > question. > > > > What do I need in my SLES9 system to allow PHP to get data > > from an Oracle > > database that is running on another system (z/OS or Sun)? > > > > /Tom Kern > > > > I am not an Oracle person either. You might want to review: > > http://www.php.net/manual/en/ref.oci8.php > > >From my initial reading, I think you'll need to get the Oracle Client > software for your SLES9 system. Some other possible links: > > http://www.eweek.com/article2/0,1759,1815794,00.asp which refers to: > > http://www.oracle.com/technology/tech/php/index.html which has a good > reference at: > > http://www.oracle.com/technology/pub/notes/technote_php_instant.html > > Unfortunately, they only talk about i386 (Intel) on these pages. > > > -- > John McKown > Senior Systems Programmer > UICI Insurance Center > Information Technology > > This message (including any attachments) contains confidential > information intended for a specific individual and purpose, and its' > content is protected by law. If you are not the intended recipient, you > should delete this message and are hereby notified that any disclosure, > copying, or distribution of this transmission, or taking any action > based on it, is strictly prohibited. > > -- > 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
