hmmm... This doesn't work if your running the Samba client only.
try smbclient -V
-v , -V or --version usually works...
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with
Sounds like a bad kernel update got released. In your position, I would
downgrade to the prior known good kernel, and report the problem to SUSE (or
whomever is your support provider).
Mark Post
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of
[EMAIL
I was pretty sure that Oracle 10g was going to be 64-bit only. Does anyone
have any information to confirm or refute this?
Mark Post
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Tom
Duerbusch
Sent: Monday, December 27, 2004 5:26 PM
To:
Hi all,
When I initially installed my Linux Instances, I used MOD-3's. I would now
like to move them to MOD-9's because my boss wants to reconfigure all the DASD
to MOD-9's. How can I accomplish moving root to a new volume and get it to IPL
off that new volume?
Thanks
Gene
I did report it to SuSE yesterday but haven't heard back from them yet. I
can still communicate with the guest OS since the virtual qdio device that
connects to my VSWITCH isn't impacted (just the backend virtual hipersocket
device). It's an interesting problem though, I can only verify it with
On Dec 28, 2004, at 8:42 AM, Gene Walters wrote:
Hi all,
When I initially installed my Linux Instances, I used MOD-3's. I
would now like to move them to MOD-9's because my boss wants to
reconfigure all the DASD to MOD-9's. How can I accomplish moving root
to a new volume and get it to IPL off
Here is a list of the steps I did to move my root disk. YMMV. Good Luck.
Shut down my target system
From a second system, CP LINK to the old root system and the new root
disk
dasdfmt -b 4096 -v -f /dev/dasdd [This prepares the disk to
receive the data. ]
fdasd -a -b
Once again, you're right on. Thank you.
tom
- - - - - - - - - - - -
Toto, I have a feeling we're not in the mainframe world any more.
_/) Tom Shilson
~GEDW VM System Services
Aloha Tel: 651-733-7591 tshilson at mmm dot com
You might be right about that.
On the Oracle download side, it shows 10g for z/Linux (I read that as
zSeries which is 64 bit).
For Oracle 9, it shows for Linux/390 (which I read as 31 bit).
So, we may have ordered the wrong one.
Or more likely, we ordered 10g for Linux/390 and someone at
Oracle 10g is 64-bit only. There will not be a 32-bit release for
zSeries/390. If it's important I can get someone from Oracle to document
it.
-Original Message-
From: Tom Duerbusch [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 28, 2004 12:43 PM
To: LINUX-390@VM.MARIST.EDU
Subject:
Taking the system out of service for such a long period of time can easily
be avoided by:
1. Adding the new disk to the existing system dynamically
2. Doing the same dasdmft, fdasd and mke2fs.
3. Following the HOWTO at http://linuxvm.org/Info/HOWTOs/movefs.html from
steps 3 to 4, but doing the cd
Oh, and:
5.5 Re-run mkinitrd if needed as well
I guess it may be time to update the HOWTO to take that into account.
Mark Post
-Original Message-
From: Mark Post [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 28, 2004 3:03 PM
To: 'Linux on 390 Port'
Subject: RE: Moving root to a new
From Barry Perkins, a VP at Oracle, and manages z/OS and Linux for zSeries
releases.
Chris,
Sure...
Oracle Database 10g for z/Linux is 64-bit with no plans for a 31-bit
implementation. It currently is supported with SLES8 (64-bit) and will
support RHAS4 and SLES9 with the 10.1.04 patchset
What is the fastest way to find out what is filling up disk space? I've been
searching directories
manually and can see nothing that big. It was 70% now it is 100%.
TIA
Dave
--
For LINUX-390 subscribe / signoff / archive access
On Dec 28, 2004, at 5:02 PM, David Heilman wrote:
What is the fastest way to find out what is filling up disk space?
I've been searching directories
manually and can see nothing that big. It was 70% now it is 100%.
Probably /var/log.
inline: graycol.gifinline: pic08638.gifinline: ecblank.gif
So much to learn
I was worried that some change would be made to the original root disk and
not picked up on the new root disk.
tom
Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 12/28/2004 02:03:15
PM:
Taking the system out of service for such a long period of time can
easily
be
The find command can be a big help. I also like du -sk * . It lists
all files and directories and their size (including subdirectories.) It
*really* helps to know what your systems are like normally.
Logs are usually the problem unless something is in a loop. Try top to
see what's
du -x -h --max-depth=1 /
It will then show you the space used by 1st level of directories. Then drill
down using the same command with a different argument. Take a look in /var/log.
I find /var/log/sa fills things up quite quickly (which is why I usually put it
on a device of its own).
19 matches
Mail list logo
