SUSE Real Time Linux on S390X?
I read that SUSE Real Time Linux is available for Intel and AMD. Will it be offered for System Z? -- 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: SUSE Real Time Linux on S390X?
On Tue, Jul 22, 2008 at 10:28 AM, in message [EMAIL PROTECTED] , Bruce Furber [EMAIL PROTECTED] wrote: I read that SUSE Real Time Linux is available for Intel and AMD. Will it be offered for System Z? My understanding is that it will not, at least for now. It doesn't even compile for me. Even if it was available, it would only make sense (to me), in an LPAR with dedicated processors. Not exactly an ideal situation. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Lost putty SSH Session - is there a way to associate the new session back the user/activity of the lost session?
If an Putty SSH Session is lost for what ever reason. Is there a way to associate/connect the new Putty SSH session back to the user/activity ongoing of the lost session? Thank you Paul -- 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: SUSE Real Time Linux on S390X?
Interesting, but what type of work load are you anticipating needing this for on a Z? Kevin -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Furber Sent: Tuesday, July 22, 2008 10:29 AM To: LINUX-390@VM.MARIST.EDU Subject: SUSE Real Time Linux on S390X? I read that SUSE Real Time Linux is available for Intel and AMD. Will it be offered for System Z? -- 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
Cloning of SLES10 image and logon IDs
Is there an easy way to utilize a cloning system where I can copy the Linux user accounts and passwords? My system needs are quite small , maybe 5 user Id's whose sole purpose is to administer (shutdown/reboot) and start/stop WebSphere. The server image I deploy runs just the minimum services to support WebSphere (no NFS, SAMBA, Mail, LDAP, etc). I want to hopefully achieve a maintenance scheme whereby I can just change-out the Linux IPL volume with a new updated/patched version and not have to make individual YAST updates to each server. WebSphere already permits this shared binary approach to its software, I'm kind of looking for the same thing here. Mark W. -- 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: Lost putty SSH Session - is there a way to associate the new session back the user/activity of the lost session?
-Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Sienicki, Paul K Sent: Tuesday, July 22, 2008 9:48 AM To: LINUX-390@VM.MARIST.EDU Subject: Lost putty SSH Session - is there a way to associate the new session back the user/activity of the lost session? If an Putty SSH Session is lost for what ever reason. Is there a way to associate/connect the new Putty SSH session back to the user/activity ongoing of the lost session? Thank you Paul I doubt it. When the session dies, then the shell will likely die with a SIGHUP. What I do in this situation is use the screen command. You make the SSH connection, which gets you a shell. You then run screen. This gives you another shell. The screen command itself runs nohup and so if your SSH session dies, your screen session's shell continues on. You then reconnect using SSH, getting another shell session of course. You then do a screen -r to reconnect to the screen session that was running. Of course, this means that you must consistently use screen when you first connect to the system. screen also allows for multiple shell sessions. But you can only view one session at a time. But you can switch between them. Somewhat like 3270 session managers such as CA-TPX or Tubes, if you are familiar with them. The above does you little good if you are doing X work because the X session will die when the SSH connection dies. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing 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
Re: Cloning of SLES10 image and logon IDs
Use Kerberos or NIS, or run either Winbind or PAM to get the user info from a remote source. Since you need to coordinate userids and UIDs across images anyway, that scales better, and you only have to update in one place. For a small number of ids, NIS is probably simpler to set up, but Kerberos will scale better (and allow you to play nice with AD if you need to). Is there an easy way to utilize a cloning system where I can copy the Linux user accounts and passwords -- 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: SUSE Real Time Linux on S390X?
It is to run a Rules Engine as a service to other application servers. Someone was asking about it saying it was available with Redhat and wanted to know about SUSE. They wanted to make sure they did not have to switch distros. I think they are mistaken though the RedHat MRG Realtime is only available on x86 and x86-64 -- Original message -- From: Evans, Kevin R [EMAIL PROTECTED] Interesting, but what type of work load are you anticipating needing this for on a Z? Kevin -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Furber Sent: Tuesday, July 22, 2008 10:29 AM To: LINUX-390@VM.MARIST.EDU Subject: SUSE Real Time Linux on S390X? I read that SUSE Real Time Linux is available for Intel and AMD. Will it be offered for System Z? -- 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 -- 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: SUSE Real Time Linux on S390X?
So, are you after consistent times, high-resolution timers or something else? Kevin -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Furber Sent: Tuesday, July 22, 2008 11:22 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: SUSE Real Time Linux on S390X? It is to run a Rules Engine as a service to other application servers. Someone was asking about it saying it was available with Redhat and wanted to know about SUSE. They wanted to make sure they did not have to switch distros. I think they are mistaken though the RedHat MRG Realtime is only available on x86 and x86-64 -- Original message -- From: Evans, Kevin R [EMAIL PROTECTED] Interesting, but what type of work load are you anticipating needing this for on a Z? Kevin -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Furber Sent: Tuesday, July 22, 2008 10:29 AM To: LINUX-390@VM.MARIST.EDU Subject: SUSE Real Time Linux on S390X? I read that SUSE Real Time Linux is available for Intel and AMD. Will it be offered for System Z? -- 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 -- 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: Cloning of SLES10 image and logon IDs
I guess my point is, if I deploy from a gold image, I'll probably want to change passwords on the various clones. If I put patches/fixes onto my gold image and want to redeploy it, I'll go back to the original passwords. So, when I redploy, could I simply take a backup of the /etc/passwd, group, shadow and copy them back over the original members that existed on the gold image ? Mark W. . The only place Linux stores local user information is in /etc/passwd, /etc/shadow, and /etc/group. Without special schemes to get around it, /etc lives in your root file system. So, any method you come up with to copy one system to another will automatically bring with it the same userids and passwords. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- 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: SUSE Real Time Linux on S390X?
Yes It is to run a Rules Engine as a service to other application servers. Someone was asking about it saying it was available with Redhat and wanted to know about SUSE. They wanted to make sure they did not have to switch distros. I think they are mistaken though the RedHat MRG Realtime is only available on x86 and x86-64 -- Original message -- From: Evans, Kevin R [EMAIL PROTECTED] So, are you after consistent times, high-resolution timers or something else? Kevin -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Furber Sent: Tuesday, July 22, 2008 11:22 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: SUSE Real Time Linux on S390X? It is to run a Rules Engine as a service to other application servers. Someone was asking about it saying it was available with Redhat and wanted to know about SUSE. They wanted to make sure they did not have to switch distros. I think they are mistaken though the RedHat MRG Realtime is only available on x86 and x86-64 -- Original message -- From: Evans, Kevin R Interesting, but what type of work load are you anticipating needing this for on a Z? Kevin -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Furber Sent: Tuesday, July 22, 2008 10:29 AM To: LINUX-390@VM.MARIST.EDU Subject: SUSE Real Time Linux on S390X? I read that SUSE Real Time Linux is available for Intel and AMD. Will it be offered for System Z? -- 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 -- 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 -- 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: Cloning of SLES10 image and logon IDs
On Tue, Jul 22, 2008 at 11:35 AM, in message [EMAIL PROTECTED], Whiteman, Mark [EMAIL PROTECTED] wrote: I guess my point is, if I deploy from a gold image, I'll probably want to change passwords on the various clones. If I put patches/fixes onto my gold image and want to redeploy it, I'll go back to the original passwords. So, when I redploy, could I simply take a backup of the /etc/passwd, group, shadow and copy them back over the original members that existed on the gold image ? Yes. Or, you could use public-private key pairs and not even worry about passwords. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Cloning of SLES10 image and logon IDs
I would guess that, for a system to be useful, /etc/passwd and shadow would change over time to include other userids for whatever task or application is taking place there. That would preclude copying and old copy over the current one producing any useful results. The approach we've used is to connect pam on each image to an LDAP server which maintains the accounts. Each server has an associated netgroup, and users of that server have that netgroup included in their LDAP profiles, allowing them to log into the server. Doing maintenance by writing over the /, /usr, or /boot directories is a Very Bad Idea . Even if you only do /boot, there are kernel changes which necessitate changes to the programs that interface to the kernel function. Maintenance is an all-inclusive thing, where changes are made in /etc, /boot, /usr/bin, /usr/share and many other locations, all at once. These things, most times, need to be in sync in order for the system to run correctly. I've not seen a way to correctly propagate all the necessary pieces of a maintenance run, other than using YaST itself. Down other paths lie insanity. There are system management and provisioning products that claim to be able to do it... Look at them closely and make them prove that they work before you commit your systems to them. -- Robert P. Nix Mayo Foundation.~. RO-OE-5-55 200 First Street SW/V\ 507-284-0844 Rochester, MN 55905 /( )\ -^^-^^ In theory, theory and practice are the same, but in practice, theory and practice are different. On 7/22/08 10:35 AM, Whiteman, Mark [EMAIL PROTECTED] wrote: I guess my point is, if I deploy from a gold image, I'll probably want to change passwords on the various clones. If I put patches/fixes onto my gold image and want to redeploy it, I'll go back to the original passwords. So, when I redploy, could I simply take a backup of the /etc/passwd, group, shadow and copy them back over the original members that existed on the gold image ? Mark W. . The only place Linux stores local user information is in /etc/passwd, /etc/shadow, and /etc/group. Without special schemes to get around it, /etc lives in your root file system. So, any method you come up with to copy one system to another will automatically bring with it the same userids and passwords. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- 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: Lost putty SSH Session - is there a way to associate the new session back the user/activity of the lost session?
On Jul 22, 2008, at 9:48 AM, Sienicki, Paul K wrote: If an Putty SSH Session is lost for what ever reason. Is there a way to associate/connect the new Putty SSH session back to the user/activity ongoing of the lost session? Thank you The basic answer is only if you were running under screen. But if you don't know screen. You should. Anything long that would be a pain if it hung up, run under screen. http://www.gnu.org/software/screen/ 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: Lost putty SSH Session - is there a way to associate the new session back the user/activity of the lost session?
On Tue, Jul 22, 2008 at 11:55 AM, in message [EMAIL PROTECTED], Adam Thornton [EMAIL PROTECTED] wrote: -snip- http://www.gnu.org/software/screen/ Or, in Paul's particular case, /suse/s390x/screen-4.0.2-62.14.s390x.rpm I use screen a lot when doing long-running package builds for Slack/390. It's a wonderful tool. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Lost putty SSH Session - is there a way to associate the new session back the user/activity of the lost session?
On Tuesday 22 July 2008 12:01, Mark Post wrote: Or, in Paul's particular case, /suse/s390x/screen-4.0.2-62.14.s390x.rpm I use screen a lot when doing long-running package builds for Slack/390. It's a wonderful tool. Screen is fantastic! It was the core of my standard working environment back in the 80's, when I had a VT102 with a serial line to a UNIX box. I'd keep about 10 screens active for weeks or months, with shells in most and Emacs in a couple of others. I could connect to the same screens remotely too, so I'd have all that context available no matter where I was. Now I keep my context in about 20 xterms spread over 12 desktops on my laptop. Same idea, but screens kept my context on the server, where it was safer. - MacK. - Edmund R. MacKenty Software Architect Rocket Software, Inc. Newton, MA USA -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Cloning of SLES10 image and logon IDs
On Jul 22, 2008, at 10:35 AM, Whiteman, Mark wrote: I guess my point is, if I deploy from a gold image, I'll probably want to change passwords on the various clones. If I put patches/ fixes onto my gold image and want to redeploy it, I'll go back to the original passwords. So, when I redploy, could I simply take a backup of the /etc/passwd, group, shadow and copy them back over the original members that existed on the gold image ? Yes. Although, as David points out, for scalability, it really is better to keep this stuff centralized somewhere. LDAP+krb5 (plus Microsoft schema extensions, alas) is pretty much the way to do this these days. Not that AD is the *best* answer necessarily, but it's an OK answer, and it's pretty ubiquitous. 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: z/Linux cloning
Our cloning process sounds similar to yours. I have an EXEC which takes care of poking VM:Secure correctly, FLASHCOPYing the necessary MDISKs, and then updating our internal recordkeeping. One command, about two seconds, then another thirty or so to IPL (assuming DNS is updated ahead of time). It's fairly well customized to our site requirements, but the basic building blocks could be easily adapted to other sites. I also suspect now that SLES10 SP2 includes support for the VMUR driver, even though I haven't yet looked closely at the options, we'll be able to get even more fancy with our automation. I can also share details with any interested parties. Some of the drawbacks of doing it from Linux (instead of from CMS) are that FLASHCOPY needs privilege class B, and you're more likely to aggravate LVM. ok r. -Original Message- From: RPN01 [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2008 10:09 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: z/Linux cloning We have a cloning process that is down to a single zVM command to create a new image, and we can create new images in about 8 minutes time from zVM command to being able to log into the new image. The master images occupy disk space, but are not running at any time. Since the disk copies are done from zVM via Flashcopy, the cloning process is independent of filesystem choice and works with LVM managed disks. As far as I know, we're the only ones using the process at the moment. If there's an interest, I can share it with you. -- Robert P. Nix Mayo Foundation.~. RO-OE-5-55 200 First Street SW/V\ 507-284-0844 Rochester, MN 55905 /( )\ -^^-^^ In theory, theory and practice are the same, but in practice, theory and practice are different. On 7/18/08 10:36 AM, Quay, Jonathan (IHG) [EMAIL PROTECTED] wrote: What's the current best practices cloning solution for z/Linux under z/VM? We've used the one found in Running z/VM to Host Linux - Installation and Customization class documentation (the CLONER and CLONEDDR virtual machines). Is there one that's newer, better or better supported? We have multiple CECs, z/Linux lpars, and both Suse and Redhat, if that makes a difference. We don't anticipate creating hundreds of clones, maybe 20 or so in the first wave. -- 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 -- 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: z/Linux cloning
On Tuesday, 07/22/2008 at 06:46 EDT, Stricklin, Raymond J [EMAIL PROTECTED] wrote: Some of the drawbacks of doing it from Linux (instead of from CMS) are that FLASHCOPY needs privilege class B, and you're more likely to aggravate LVM. You can move class B FLASHCOPY to any privclass you want. Alan Altmark z/VM Development IBM Endicott -- 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: #autoinst - parmfile - SLES install will not consider CTC as valid even though connected.
Mark, I mis stated yast in the earlier email. It is the SLES IPL 00C installation with full specifications including autoinst, that gives up on finding the source before the CTC connects. The console shows the CTC0 connecting after the install program has shifted to a manual install. After this no matter how I attempt to select CTC and give it response the install program will not proceed but reverts right back to the network device question even though the CTC selected even though it is already connected. It is like it thinks it is bad selection and will not reconsider it. I have tried several things to reset or get it to accept/proceed with the CTC response information. Some are: tapping off the answers and taking the defaults that are being presented, giving bogus address responses, selecting other connection methods different not connected responses. Re-IPLing 00C clear, etc. The only way I have been successful to get the CTC to be accepted is to replace the parmfile SUSE with the simple 1 line parmfile (knocking out the autoinst along with the other stuff). Even then I have throw away the SLES ipl of 00C and reipl 00C. Followed by giving bad addresses for the ctc and failing and then on the 2nd iteration giving the right information. Some how the defaults are remembered through a logoff/logon different parmfile SLES invocation. I will paste the 2 parmfiles and a given console of the network device selection prompt loop. Autoinst attempted parmfile: ramdisk_size=65536 root=/dev/ram1 ro init=/linuxrc TERM=dumb instnetdev=ctc pointopoint=199.42.190.45 hostip=199.42.190.3 Gateway=199.42.190.45 Nameserver=127.0.0.1 Netmask=255.255.255.255 dhcp=2 readchannel=0.0.0e00 writechannel=0.0.0e01 ctcprotocol=0 install=ftp://199.42.190.8/ autoyast=http://199.42.190.48/suse/autoinst.xml usessh=1 sshpassword=temp Simple parmfile: ramdisk_size=65536 root=/dev/ram1 ro init=/linuxrc TERM=dumb Console of SLES install giving up and looping through prompts on the CTC network device prompts: sles 003 FILES PURGED RDR FILE 0006 SENT FROM CLIENT PUN WAS 0006 RECS 076K CPY 001 A NOHOLD NOKEEP RDR FILE 0007 SENT FROM CLIENT PUN WAS 0007 RECS 0010 CPY 001 A NOHOLD NOKEEP RDR FILE 0008 SENT FROM CLIENT PUN WAS 0008 RECS 104K CPY 001 A NOHOLD NOKEEP 003 FILES CHANGED 003 FILES CHANGED Linux version 2.6.16.46-0.12-default ([EMAIL PROTECTED]) (gcc version 4.1.2 20070115 (prerelease) (SUSE Linux)) #1 SMP Thu May 17 14:0 0:09 UTC 2007 We are running under VM (64 bit mode) Detected 1 CPU's Boot cpu address 0 Built 1 zonelists Kernel command line: ramdisk_size=65536 root=/dev/ram1 ro init=/linuxrc TERM=dumbinstnetdev=ctc pointopoint=199. 42.190.45 hostip=199.42.190.3Gateway=199.42.190.45 Nameserver=127.0.0.1 Netmask=255.255.255.255 dhc p=2 PID hash table entries: 4096 (order: 12, 131072 bytes) Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) Memory: 496640k/524288k available (4494k kernel code, 0k reserved, 1221k data, 204k init) Security Framework v1.0.0 initialized Mount-cache hash table entries: 256 checking if image is initramfs... it is Freeing initrd memory: 8128k freed cpu 0 phys_idx=0 vers=FF ident=04912A machine=2066 unused= Brought up 1 CPUs migration_cost=1000 NET: Registered protocol family 16 debug: Initialization complete cio: Channel measurements not available, continuing. audit: initializing netlink socket (disabled) audit(1216779850.524:1): initialized VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 512 (order 0, 4096 bytes) Initializing Cryptographic API io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered (default) io scheduler cfq registered RAMDISK driver initialized: 16 RAM disks of 65536K size 1024 blocksize md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27 md: bitmap version 4.39 Channel measurement facility using basic format (autodetected) NET: Registered protocol family 2 IP route cache hash table entries: 32768 (order: 6, 262144 bytes) TCP established hash table entries: 131072 (order: 9, 2097152 bytes) TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) TCP: Hash tables configured (established 131072 bind 65536) TCP reno registered NET: Registered protocol family 1 Freeing unused kernel memory: 204k freed Moving into tmpfs... done. SUSE Linux Enterprise Server 10 installation program v2.0.67 (c) 1996-2007 SUSE Linux Products GmbH Starting udev ... ... udev running SCSI subsystem initialized NET: Registered protocol family 17 loop: loaded (max 8 devices) Starting hardware detection...
