Re: How to reset the Linux root pw
On 10/4/2014 1:10 AM, Cameron Seay wrote: Thanks, Rob. That is the first time anyone suggested an automatic root login. Will try it. We do the same thing and it is well worth setting it up. Not much effort really, just a bit of inittab editing. Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SLES 11 SP3 problems
On 4/15/2014 2:38 PM, Mark Post wrote: On 4/8/2014 at 04:35 PM, Leland Lucius wrote: On 4/8/2014 3:11 PM, Mark Post wrote: On 4/8/2014 at 04:07 PM, Marcy Cortes wrote: Do you have any idea when the SP3 swap fix will reach a kernel in the service stream yet? Fairly soon, I would think. A new update should be coming out with the single bug fixed that caused the withdrawal as soon as QA gets done with it. (At least that's what I understand they're doing, so don't depend too much on what I say. Check the changelog after you get it.) Oooo...that's way better news than I got from support! I know it's not concrete but at least it gives me a tepid fuzzy. :-) It looks like the update has been released. Hopefully this will fix the problem without the nasty kernel bug we encountered previously. Please give it a test. So far so good. Everything is running along fine and I'm unable to reproduce the original kswapd issue. It's still a bit early, but we're fixin to give it a really good workout (SAP upgrade of some sort in sandbox), so that should tell us more. Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SLES 11 SP3 problems
On 4/15/2014 2:38 PM, Mark Post wrote: On 4/8/2014 at 04:35 PM, Leland Lucius wrote: On 4/8/2014 3:11 PM, Mark Post wrote: On 4/8/2014 at 04:07 PM, Marcy Cortes wrote: Do you have any idea when the SP3 swap fix will reach a kernel in the service stream yet? Fairly soon, I would think. A new update should be coming out with the single bug fixed that caused the withdrawal as soon as QA gets done with it. (At least that's what I understand they're doing, so don't depend too much on what I say. Check the changelog after you get it.) Oooo...that's way better news than I got from support! I know it's not concrete but at least it gives me a tepid fuzzy. :-) It looks like the update has been released. Hopefully this will fix the problem without the nasty kernel bug we encountered previously. Please give it a test. Will do. Thanks for the heads up! Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SLES 11 SP3 problems
On 4/8/2014 3:00 PM, Mark Post wrote: On 4/8/2014 at 03:54 PM, Leland Lucius wrote: Do you happen to have any more detail on what it does to the network? Is it something that is likely to occur? Symptoms? Just trying to figure out if it is worth the risk. :-) No, it's not. Kernel oops, processes dying, etc. Don't do it. Well, that's about as good a NO as I can ask for. :-) Thanks Mark. Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SLES 11 SP3 problems
On 4/8/2014 3:11 PM, Mark Post wrote: On 4/8/2014 at 04:07 PM, Marcy Cortes wrote: Do you have any idea when the SP3 swap fix will reach a kernel in the service stream yet? Fairly soon, I would think. A new update should be coming out with the single bug fixed that caused the withdrawal as soon as QA gets done with it. (At least that's what I understand they're doing, so don't depend too much on what I say. Check the changelog after you get it.) Oooo...that's way better news than I got from support! I know it's not concrete but at least it gives me a tepid fuzzy. :-) Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SLES 11 SP3 problems
On 4/8/2014 3:07 PM, Marcy Cortes wrote: It's gone from SMT so you may not find it even if you wanted to have some fun. Do you have any idea when the SP3 swap fix will reach a kernel in the service stream yet? Noper, I opened a ticket to ask and was told they don't know and can't give an estimate. :-( Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SLES 11 SP3 problems
Hi Mike, Do you happen to have any more detail on what it does to the network? Is it something that is likely to occur? Symptoms? Just trying to figure out if it is worth the risk. :-) Thanks, Leland On 3/31/2014 2:08 PM, Michael O'Reilly wrote: Marcy, Everyone should hold off testing this release, until a fixed one is released. Today SuSE says: You might have seen the note that a SLES11 SP3 kernel was released last week. Unfortunately this last SLE11-SP3 update kernel, has a fatal regression that can trigger a kernel Oops/BUG during network operation. The kernel was removed from the official update channel and is not available anymore. However customers might have downloaded it already or especially customers with a running SMT server are likely to still have a working copy of that problematic kernel. In case you know about customers who updated the kernel already or you come accross a kernel Oops, the problematic kernel version is: -3.0.101-0.18.1 Thank you for your help, Mike O'Reilly IBM Linux Change Team Marcy Cortes To Sent by: Linux on LINUX-390@vm.marist.edu, 390 Port cc Subject Re: SLES 11 SP3 problems 03/27/2014 05:05 PM Please respond to Linux on 390 Port For inquiring minds, the fix for this just hit the SUSE service stream. Marcy -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SLES 11 SP3 problems
Thanks Mike for the heads up and great timing! We were just about to roll it out to several of our SAP servers. Leland On 3/31/2014 2:08 PM, Michael O'Reilly wrote: Marcy, Everyone should hold off testing this release, until a fixed one is released. Today SuSE says: You might have seen the note that a SLES11 SP3 kernel was released last week. Unfortunately this last SLE11-SP3 update kernel, has a fatal regression that can trigger a kernel Oops/BUG during network operation. The kernel was removed from the official update channel and is not available anymore. However customers might have downloaded it already or especially customers with a running SMT server are likely to still have a working copy of that problematic kernel. In case you know about customers who updated the kernel already or you come accross a kernel Oops, the problematic kernel version is: -3.0.101-0.18.1 Thank you for your help, Mike O'Reilly IBM Linux Change Team Marcy Cortes To Sent by: Linux on LINUX-390@vm.marist.edu, 390 Port cc Subject Re: SLES 11 SP3 problems 03/27/2014 05:05 PM Please respond to Linux on 390 Port For inquiring minds, the fix for this just hit the SUSE service stream. Marcy -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Buildforge agent Port Conflict
On 3/27/2014 10:40 AM, Jake anderson wrote: Yes it is reserved in TCPIP PROFILE. Also instead of Userid root running the start up command, I would like to re-direct to another ID. So that /u/users/bfgagent -s is started by abc123 instead of root. I tried with su -abc123 /u/users/bfagent -s, but it is asking for the password of abc123. During IPL, is there a way to supply password during mount ? Oh, oh...I've been away from z/OS way too long to be able to answer that one. You'd be better off asking these questions on the IBM-MAIN mailing list since you're dealing with USS instead of Linux. Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Buildforge agent Port Conflict
On 3/27/2014 7:18 AM, Jake anderson wrote: Hi Leland, I tried this when TCPIP was fully functional. Then have you reserved port 5557 in the TCPIP PROFILE? Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Buildforge agent Port Conflict
On 3/27/2014 5:40 AM, Jake anderson wrote: Hi Peter/All, I tried executing the command from /etc/rc, But got the below error : Ý131513¨ bfdaemon: Ý::/5557¨: bind: EDC5111I Permission denied. Ý131513¨ bfdaemon: Ý0.0.0.0/5557¨: bind: EDC5111I Permission denied. Ý131513¨ bfdaemon: no listeners; exiting It ran before TCPIP was fully initialized (or even started). Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Linux file updates by timestamp and userid
On 3/13/2014 5:32 PM, Shan, Rita wrote: Could anyone kindly provide information on how we can monitor/log zLinux file updates by timestamp and by user ID? We have a number of staff maintaining zLinux system all with sudo privilege, we need to have a way to track file updates by date/time/user-ID. Does AIDE provides these kind of detailed level information? What kind of overhead it will generate if we turned it on? Is there an inexpensive vendor tool for this? You can use the "audit" package for this. Note that once the user sudos to root, then root will be the one logged as modifying the file. However, sudo usage is also logged, so you might be able to correlate the two events somehow. Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SLES 11 SP3 problems
Thanks much for the detail! This is more info than I've gotten from Novell in the last two weeks! Leland On 3/13/2014 3:25 PM, Michael O'Reilly wrote: Leland, SuSE told me that in bnc#859225. They dropped the changes meaning they don't revert the patch. Instead development added a series of fixes. The new set of patches were build March 11th, so the mailinglist was just not updated with that information yet. The crucial patch development added is patches.suse/mm-vmscan-Do-not-force-reclaim-file-pages-until-it-exceeds-anon.patch which reduces the impact of the swap protection by force scanning file LRU. It should act as a previous revert with the load we are seeing. Other patches shouldn't matter much for this load but they are good in general and they have passed development's testing with swap sensitive workloads so the risk of the regression is low. After the successful testing of a customer, the patches were pushed to the SLE11-SP3 branch. A future update is due soon and it will include the patches. Mike O'Reilly IBM Linux Change Team Leland Lucius To Sent by: Linux on LINUX-390@vm.marist.edu, 390 Port cc Subject Re: SLES 11 SP3 problems 03/13/2014 12:39 PM Please respond to Linux on 390 Port Wanted to follow up. Just today we FINALLY got the patched kernel (3.0.101-0.15.1.6580.16.PTF.859225) from Novell (unbelievable saga!!!). Changelog shows these changes: * Tue Mar 11 2014 sto...@suse.de - patches.suse/mm-vmscan-Update-rotated-and-scanned-when-force-reclaimed.patch patches.suse/mm-vmscan-fix-endless-loop-in-kswapd-balancing.patch patches.suse/mm-vmscan-Do-not-force-reclaim-file-pages-until-it-exceeds-anon.patch patches.suse/mm-page-writeback.c-do-not-count-anon-pages-as-dirtyable-memory.patch bnc#859225 I wonder why that differed from yours? Leland On 3/7/2014 4:51 PM, Marcy Cortes wrote: Ah thanks. And great to know that the future kernel doesn't suffer from this! Good work! Marcy. Sent from my BlackBerry. - Original Message - From: Leland Lucius [mailto:lluc...@homerow.net] Sent: Friday, March 07, 2014 04:24 PM Central Standard Time To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] SLES 11 SP3 problems On 3/7/2014 3:57 PM, Marcy Cortes wrote: weird, could the combo of the two of them be to blame? I'm sure they got it right. Especially since that bit of code has been effectively reverted in upstream as well at later kernel versions and why I wasn't able to make it happen in a 3.13.5 kernel. The method I used to try and figure out the cause probably changed things enough where the real problem was simply bypassed in some way. I can honestly say that the vmscan code is WAY over my head, so I was really just taking shots in the dark. Anything to try and push for a resolution to the problem. My method for recreating the problem was a little C program that simply allocated a bunch of memory over and over while I'm dropping the caches in another ssh session. Worked very reliably. But, with the patch reverted, I am no longer able to recreate the issue after many attempts. Thanks again, Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or vi
Re: SLES 11 SP3 problems
Wanted to follow up. Just today we FINALLY got the patched kernel (3.0.101-0.15.1.6580.16.PTF.859225) from Novell (unbelievable saga!!!). Changelog shows these changes: * Tue Mar 11 2014 sto...@suse.de - patches.suse/mm-vmscan-Update-rotated-and-scanned-when-force-reclaimed.patch patches.suse/mm-vmscan-fix-endless-loop-in-kswapd-balancing.patch patches.suse/mm-vmscan-Do-not-force-reclaim-file-pages-until-it-exceeds-anon.patch patches.suse/mm-page-writeback.c-do-not-count-anon-pages-as-dirtyable-memory.patch bnc#859225 I wonder why that differed from yours? Leland On 3/7/2014 4:51 PM, Marcy Cortes wrote: Ah thanks. And great to know that the future kernel doesn't suffer from this! Good work! Marcy. Sent from my BlackBerry. - Original Message - From: Leland Lucius [mailto:lluc...@homerow.net] Sent: Friday, March 07, 2014 04:24 PM Central Standard Time To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] SLES 11 SP3 problems On 3/7/2014 3:57 PM, Marcy Cortes wrote: weird, could the combo of the two of them be to blame? I'm sure they got it right. Especially since that bit of code has been effectively reverted in upstream as well at later kernel versions and why I wasn't able to make it happen in a 3.13.5 kernel. The method I used to try and figure out the cause probably changed things enough where the real problem was simply bypassed in some way. I can honestly say that the vmscan code is WAY over my head, so I was really just taking shots in the dark. Anything to try and push for a resolution to the problem. My method for recreating the problem was a little C program that simply allocated a bunch of memory over and over while I'm dropping the caches in another ssh session. Worked very reliably. But, with the patch reverted, I am no longer able to recreate the issue after many attempts. Thanks again, Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SLES 11 SP3 problems
On 3/7/2014 3:57 PM, Marcy Cortes wrote: weird, could the combo of the two of them be to blame? I'm sure they got it right. Especially since that bit of code has been effectively reverted in upstream as well at later kernel versions and why I wasn't able to make it happen in a 3.13.5 kernel. The method I used to try and figure out the cause probably changed things enough where the real problem was simply bypassed in some way. I can honestly say that the vmscan code is WAY over my head, so I was really just taking shots in the dark. Anything to try and push for a resolution to the problem. My method for recreating the problem was a little C program that simply allocated a bunch of memory over and over while I'm dropping the caches in another ssh session. Worked very reliably. But, with the patch reverted, I am no longer able to recreate the issue after many attempts. Thanks again, Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SLES 11 SP3 problems
On 3/7/2014 3:00 PM, Marcy Cortes wrote: Not yet. We just got another kernel to test this morning and so far in limited testing (not with WAS yet), it seems to be ok. Interestingly, this kernel supposedly has this patch removed: * Fri Mar 07 2014 sto...@suse.de - revert patch patches.fixes/mm-mmvmscan-only-evict-file-pages-when-we-have-plenty.patch bnc#859225 Puzzling... I removed it, rebuilt, and it's looking good here too!!! I've put it back in and rebuilding once more just to verify the problem returns, but I'm excited! Thanks much! Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SLES 11 SP3 problems
On 3/7/2014 3:00 PM, Marcy Cortes wrote: Not yet. We just got another kernel to test this morning and so far in limited testing (not with WAS yet), it seems to be ok. Interestingly, this kernel supposedly has this patch removed: * Fri Mar 07 2014 sto...@suse.de - revert patch patches.fixes/mm-mmvmscan-only-evict-file-pages-when-we-have-plenty.patch bnc#859225 Puzzling... Cool! I'll try building without that fella and see what happens here. Thanks, Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SLES 11 SP3 problems
Hi Marcy, Sorry to bother you about this, but did you ever get a resolution? We've seen this as well and haven't yet gotten much relief from Novell, so I started poking around myself and tracked it down to (in the kernel package changelog): * Thu May 23 2013 mgor...@suse.de - Refresh patches.fixes/mm-vmscan-Block-kswapd-if-it-is-encountering-pages-under-writeback-fix-2.patch - commit ee1efa5 I just kept removing patches until I got a kernel that didn't exhibit the problem. Removing that patch it works fine...put the patch back on and the problem comes back. The problem is that the patch is on in upstream as well, but upstream kernels do not have the problem either. I suspect it's because of this commit: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/mm/vmstat.c?id=6e543d5780e36ff5ee56c44d7e2e30db3457a7ed I'm going to try building a vanilla kernel without that and see if the problem returns. Unfortunately, that specific patch looks to be a bugger to backport to our SP3 kernel. :-( Thanks, Leland On 11/1/2013 12:30 PM, Marcy Cortes wrote: We're experiencing a problem with kernel 3.0.93 (SP3). It seems on servers that are memory constrained can go into a loop doing tons of i/o - 8000+ / second. It seems to happen with things like WAS deploys.We may have also been able to recreate use a simple perl array. Has anyone else seen this? Yes, we have a high priority SR opened with SUSE. Oddly we have seen something like this after a kernel update on SP2. That was solved by changing vm.swappiness to something > 0.We have put it back to 60 (the default) and still get the problem. Upping the memory solves it, but obviously, that's not something we want to be doing, especially in our constrained dev environment. Marcy -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: z90crypt and SLES 11 SP3
On 7/24/2013 1:00 PM, Mark Post wrote: On 7/23/2013 at 07:59 PM, Leland Lucius wrote: Has anyone else run into this after upgrading to SLES 11 SP3. This happens when the module is loaded and is on an EC12 with crypto cards: Unable to handle kernel pointer dereference at virtual kernel address 00431000 Oops: 0004 [#1] SMP Modules linked in: z90crypt(+) rng_core qeth_l3 qeth ipv6 ipv6_lib qdio ccwgroup vmur vmcp dm_mirror dm_region_hash dm_log linear dasd_eckd_mod dasd_mod scsi_dh_rdac scsi_dh_emc scsi _dh_hp_sw scsi_dh_alua scsi_dh scsi_mod dm_snapshot dm_mod ext3 mbcache jbd Supported: Yes CPU: 0 Not tainted 3.0.82-0.7-default #1 Process modprobe (pid: 698, task: 7e72c438, ksp: 7c2879e0) Krnl PSW : 070410018000 03e001ba0554 (zcrypt_msgtype_request+0x19c/0x268 [z90crypt] ) That doesn't look familiar to me. Hopefully you've opened up a service request for this. Yepper, sure did. Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
z90crypt and SLES 11 SP3
Has anyone else run into this after upgrading to SLES 11 SP3. This happens when the module is loaded and is on an EC12 with crypto cards: Unable to handle kernel pointer dereference at virtual kernel address 00431000 Oops: 0004 [#1] SMP Modules linked in: z90crypt(+) rng_core qeth_l3 qeth ipv6 ipv6_lib qdio ccwgroup vmur vmcp dm_mirror dm_region_hash dm_log linear dasd_eckd_mod dasd_mod scsi_dh_rdac scsi_dh_emc scsi _dh_hp_sw scsi_dh_alua scsi_dh scsi_mod dm_snapshot dm_mod ext3 mbcache jbd Supported: Yes CPU: 0 Not tainted 3.0.82-0.7-default #1 Process modprobe (pid: 698, task: 7e72c438, ksp: 7c2879e0) Krnl PSW : 070410018000 03e001ba0554 (zcrypt_msgtype_request+0x19c/0x268 [z90crypt] ) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:1 PM:0 EA:3 Krnl GPRS: 00431000 bf1ff0b1 0085d4c8 0028 0010 03e001ba83e0 03e001bacb6c 0001 03e001babae8 03e001bac108 03e001bac530 03e001b9b000 03e001ba74e8 03e001ba048e 7c287b58 Krnl Code: 03e001ba0546: e3100338 ag %r1,816 03e001ba054c: 58201000 l %r2,0(%r1) 03e001ba0550: a72a0001 ahi %r2,1 >03e001ba0554: 50201000 st %r2,0(%r1) 03e001ba0558: 58203008 l %r2,8(%r3) 03e001ba055c: 1222 ltr %r2,%r2 03e001ba055e: a784001e brc 8,3e001ba059a 03e001ba0562: e3a03024 lg %r10,32(%r3) Call Trace: ([<03e001ba048e>] zcrypt_msgtype_request+0xd6/0x268 [z90crypt]) [<03e001ba6d58>] zcrypt_cex4_probe+0x188/0x1ac [z90crypt] [<03e001b9d6a6>] ap_device_probe+0x46/0xf4 [z90crypt] [<003dd9ea>] really_probe+0x8a/0x25c [<003ddd32>] __driver_attach+0xca/0xd0 [<003dcdfe>] bus_for_each_dev+0x9e/0xdc [<003dc48e>] bus_add_driver+0x22a/0x2f4 [<003de52a>] driver_register+0x9e/0x1a0 [<03e001bb3094>] zcrypt_init+0x94/0xd0 [z90crypt] [<001000ba>] do_one_initcall+0x3a/0x170 [<0019f21a>] SyS_init_module+0xe6/0x234 [<00513d58>] sysc_noemu+0x16/0x1c [<03fffd4cf16a>] 0x3fffd4cf16a Last Breaking-Event-Address: [<03e001ba0490>] zcrypt_msgtype_request+0xd8/0x268 [z90crypt] ---[ end trace a0c8c38364dbdba1 ]--- Thanks, Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: GFS2 or OCFS2 on SLES11 SP3
On 7/11/2013 2:41 PM, Marcy Cortes wrote: Under z/VM right? OCFS2 is pretty simple if the amount of space you need fits on a minidisk. If you need cLVM, it's complicated. The HAE guide helps some, but doesn't really put it into cook book format. It's like a layer cake and you have to each layer working right first or you end up hanging or getting your servers in reboot loops. I intend to write up something if I can ever get it to work the same way twice without futzing with it. In my copious free time of course. Well, you've made me feel better. I thought I was being addle minded about the whole thing. What has complicated it for me even more is that I'm doing DRBD replication of a multi-minidisk VG between sites (active/active) with 2 nodes (active/passive) at each site using DRBD's floating IP scheme rather than stacking. I have gotten it to work once or twice, but, like you, just can't get consistent enough results to actually claim I was successful. :-) If I keep it active/passive between sites and leave out the OCFS2 (and pre/coreqs) everything works beautifully. Fortunately, Middleware is giving me a pass for a while and are gonna stick with active/passive for now. But, they will come a knockin', so I do need to get active/active to work. And I've sent corosync into more loops than the Blue Angels have done since their inception! Only way to stop the process is to kill it, at which point one of the other nodes will probably start doing the same thing. Wind up just doing a reboot (a clean stop of openais will usually hang) of all of the nodes. Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: GFS2 or OCFS2 on SLES11 SP3
On 7/11/2013 2:21 PM, Mark Post wrote: On 7/11/2013 at 03:07 PM, Leland Lucius wrote: Now that we have a choice, anyone have any pros/cons that they'd like to share? I would say the biggest thing to consider is this item from the SLE-ha-guide: Read-only GFS2 Support For easier migration from GFS2 to OCFS2, you can mount your GFS2 file systems in read-only mode to copy the data to an OCFS2 file system. OCFS2 is fully supported by SUSE Linux Enterprise High Availability Extension. HAHAHAHAHA!!! Totally missed the "read-only" bit. Darn these eyeballs!!! Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
GFS2 or OCFS2 on SLES11 SP3
Now that we have a choice, anyone have any pros/cons that they'd like to share? My first attempt at using OCFS2 in an active/active DRDB-backed 4-node cluster didn't pan out too well. But, I would have to say it wasn't necessarily OCFS2s fault...more like me struggling to get fencing working properly and convincing pacemaker to use DRBD floating IPs. Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SLES 11 SP3 is available for download
On 7/8/2013 10:25 AM, Leland Lucius wrote: One thing I do recall having difficulty with though is that zypper doesn't like the checksums in the mirrored repodata files. They contain a sha256 checksum, but zypper seems to truncate it to 40 bytes and it complains that it doesn't match the type. Running a createrepo to recreate it gets around the issue...but something is definitely off here. This appears to have been corrected now. Yippee! Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SLES 11 SP3 is available for download
On 7/8/2013 9:37 AM, Will, Chris wrote: As of this morning, the SUSE_SLES-SP3-migration patch is still not available, at least for s390x. Weird...I went through an upgrade on one of my play servers and it's now at 11.3. I did kind of rush through it just to satisfy that instant gratification issue I have, so maybe I "forced" the upgrade. :-) I do recall that it the product upgrade wasn't called the same as in the release notes...I believe it was just SUSE_SLES. I'll try it again on a different server to see what happens. One thing I do recall having difficulty with though is that zypper doesn't like the checksums in the mirrored repodata files. They contain a sha256 checksum, but zypper seems to truncate it to 40 bytes and it complains that it doesn't match the type. Running a createrepo to recreate it gets around the issue...but something is definitely off here. Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SLES 11 SP3 is available for download
On 7/2/2013 10:18 PM, Srivastava, Sagar wrote: I have been trying to find out the procedure for upgrading SLES11 SP2 to SP3 just like I did for SP1 to SP2(see below) http://www.novell.com/support/kb/doc.php?id=7010200 but without luck. I have SMT (subscription management server). Does anyone know the steps/documentation to follow for this upgrade? It's in the README on the ISO and here: https://www.suse.com/releasenotes/x86_64/SUSE-SLES/11-SP3/ Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SLES 11 SP3 is available for download
On 7/2/2013 10:14 PM, Leland Lucius wrote: Don't know if it's been announced, but if you log into support, you are able to download the ISOs. The RPMs are available for mirroring as well. Still a little head of the game as the available kernel version for SP2 is higher than the one available for SP3. No biggie...still a fun find. (Yes, I need a life!) Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
SLES 11 SP3 is available for download
Don't know if it's been announced, but if you log into support, you are able to download the ISOs. The RPMs are available for mirroring as well. Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: More words on "The Virtualization Cookbook" Redbook residency
On 6/13/2013 2:40 PM, Rick Troth wrote: Or maybe a compiled smiucv should also be on the Downloads page? ... I'll talk to Leland about shipping a prebuilt one, though -- no need to force a toolchain install if not needed. CORRECT. And for "external facing" or "cloud" guests, it's important to NOT have the toolchain available. You probably wouldn't want to have smaclient on an external facing or cloud guest either. We simply have a local build machine where we build stuff and then push the binaries out to the guests that need them. Prebuilding smiucv "should" be possible. I just wouldn't want to get into having to support multiple versions for multiple distros. Fortunately, it's about as basic an app can be, so it should be able to be built once and run everywhere. Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Appropriate hipersocket MFS size for use with SAP Apps Servers
On 6/13/2013 2:28 PM, Ron Foster wrote: Anyone have any experience running SAP apps servers under z/vm with a larger than 8k MTU size? We run with a 16K MFS and an 8K MTU. Like you, we use a single hipersocket CHPID. However, we're still on z/OS 1.12 with plans to upgrade to z/OS 1.13 soonish. So, thanks for the heads up. :-) Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: /dev/urandom issue that was fixed in suse kernel version 3.0.74
On 5/16/2013 10:15 AM, Will, Chris wrote: > We ran into this issue and are rolling out the fix provided by Novell. > Novell was telling us that it was due to a large number of ssh logins to a > host but this does not always seem to be the case. Anyone have a more > definitive reason for what caused the error and how it was fixed? > The ssh thing is just a way to recreate the problem. It's really just a matter of multiple simultaneous users of /dev/urandon and ssh was one way to do it. I was able to recreate it with: #!/bin/sh for ((c=0; c < 32; c++)) do for ((i=0; i < 256; i++)) do dd if=/dev/urandom of=/dev/null bs=1 count=4096 >/dev/null 2>&1 & done done dd if=/dev/urandom of=/dev/null bs=1 count=1 2>&1 | grep -q '0 bytes' && echo "badness" exit -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: /dev/urandom redux
We're up to 5 different servers now. I was told that they already knew about the problem and are waiting for IBM to fix it. I've been using the symlink trick instead. That way services still work but urandom remains broken in case Novell needs me to try anything. Leland On 4/18/2013 7:22 PM, Theodore Rodriguez-Bell wrote: Leland Lucius reported a problem where /dev/urandom was returning 0 bytes on a read. Well, it bit us too. I filed a support call with Novell/SuSE and got "if you can't give us a system where the bug is happening now, we can't help." Unfortunately I'd run Leland's little C program to fix it. Novell/SuSE couldn't find any reports of this in their bug database. Has it happened to anyone else? What distribution are you running, and what kernel? (It's SLES 11 SP2 and 3.0.58-0.6.6-default for us.) So far it's only happened on one server, and the consequences have been fairly minor. But of course until we understand what triggers it we're a little nervous about it. I'll summarize any answers sent directly to me. Thank you. Ted Rodriguez-Bell, te...@wellsfargo.com Company policy requires: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Empty /dev/urandom???
This appears to be a known issue that is being actively researched. Leland On Mon, Apr 8, 2013 at 1:13 PM, Philipp Kern wrote: > On Mon, Apr 08, 2013 at 11:50:53AM -0400, Mark Ver wrote: > > Can you check: > > chkconfig -l random > > > > I think, usually /etc/init.d/random is executed automatically on boot to > > seed /dev/urandom and to maintain the entropy you had prior to shutdown > > (similar to the process described in man random(4)). > > You don't need to seed urandom. True, the quality of the output wouldn't > be great, but what's seen here should never happen and is clearly a bug. > > Kind regards > Philipp Kern > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > -- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ > -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Empty /dev/urandom??? - Fixed (sort of)
A bit more info in case anyone is interested...
I enable tracing and found something interesting. It seems that the number of
entropy bits go negative at some point:
<...>-28916 [002] 535863.435655: extract_entropy: input pool: nbytes 8
entropy_count 3646 caller xfer_secondary_pool+0xaa/0x10c
<...>-28916 [002] 535863.435662: mix_pool_bytes_nolock: input pool: bytes 20
caller extract_buf+0xc0/0x154
<...>-28916 [002] 535863.435664: mix_pool_bytes: blocking pool: bytes 8 caller
xfer_secondary_pool+0xc6/0x10c
<...>-28916 [002] 535863.435665: credit_entropy_bits: blocking pool: bits 64
entropy_count 64 entropy_total 1024 caller xfer_secondary_pool+0xd4/0x10c
<...>-28916 [002] 535863.435672: mix_pool_bytes_nolock: blocking pool: bytes 20
caller extract_buf+0xc0/0x154
<...>-28919 [003] 535863.437207: extract_entropy_user: blocking pool: nbytes 4
entropy_count 32 caller random_read+0x60/0x150
<...>-28919 [003] 535863.437212: mix_pool_bytes_nolock: blocking pool: bytes 20
caller extract_buf+0xc0/0x154
<...>-28924 [001] 535863.439902: extract_entropy: nonblocking pool: nbytes 16
entropy_count -32 caller get_random_bytes+0x38/0x48
<...>-28926 [003] 535863.440827: extract_entropy: nonblocking pool: nbytes 16
entropy_count -32 caller get_random_bytes+0x38/0x48
And that's what's causing no data to be returned. Haven't figured out yet why
it goes negative.
But, I was able to semi-correct the issue by running the following:
#include
#include
#include
#include
#include
int
main(int argc, char *argv[])
{
int fd = open("/dev/urandom", O_RDWR);
if (fd)
{
ioctl(fd, RNDCLEARPOOL);
perror("error");
close(fd);
}
}
I now get data back:
pzsfs101:~ # dd if=/dev/urandom of=/dev/null count=10
10+0 records in
10+0 records out
5120 bytes (5.1 kB) copied, 0.00164344 s, 3.1 MB/s
And the dynamic UUID looks better now:
pzsfs101:~ # grep '' /proc/sys/kernel/random/*
/proc/sys/kernel/random/boot_id:--4000-8000-
/proc/sys/kernel/random/entropy_avail:2179
/proc/sys/kernel/random/poolsize:4096
/proc/sys/kernel/random/read_wakeup_threshold:64
/proc/sys/kernel/random/uuid:af2ccaee-221b-4128-ab5a-389eb7eaa3fd
/proc/sys/kernel/random/write_wakeup_threshold:1024
And it updates as it should each time the it is read.
Anyway, still no idea exactly what happened.
Leland
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
Re: Empty /dev/urandom???
On 4/5/2013 10:02 PM, Gregg Levine wrote: So why does the system need to be restarted? That's the strange part. What's causing it and why does it get fixed that way. And then why does it happen? I've got a workaround for now (softlink urandom to random) and will open a ticket with Suse RSN. Hopefully, they may be able to diagnose it before I need to reboot. Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Empty /dev/urandom???
On 4/5/2013 8:33 PM, Gregg Levine wrote: On Fri, Apr 5, 2013 at 9:26 PM, Leland Lucius wrote: On 4/5/2013 5:59 PM, Pedro Principeza wrote: Hi. Although it seems to have all the needed permissions and nodes. Have you tried to recreate it, using: mknod /dev/urandom c 1 9 Same result...still returning zero bytes. Leland Hello! Isn't the mechanism that works that thing connected to the I/O functions of the average System Z? I seem to recall that when an almost related problem surfaced a while back, the solution was to engage those I/O functions by doing some. Ideally why not have the system write something (or other) to files and then check to see if the thing is working. Feel free to disregard my suggestion if it doesn't work, or if its not at all applicable. Yepper, urandom and, I believe, the whole in-kernel entropy thing is related to various pseudo-random activities occurring within the system. Unless (or maybe in addition to) you have a hardware prng which we do on z. But, I believe the guest has lost his cookies. Here's what the current kernel random proc config looks like on a healthy server: pzsfs102:~ # grep '' /proc/sys/kernel/random/* /proc/sys/kernel/random/boot_id:2a009fed-694b-4ad1-a110-471f5310ed16 /proc/sys/kernel/random/entropy_avail:2782 /proc/sys/kernel/random/poolsize:4096 /proc/sys/kernel/random/read_wakeup_threshold:64 /proc/sys/kernel/random/uuid:6cf52c84-b907-42c8-a963-7ed9d4b252d9 /proc/sys/kernel/random/write_wakeup_threshold:1024 And here's the values on the sickly fella: pzsfs101:~ # grep '' /proc/sys/kernel/random/* /proc/sys/kernel/random/boot_id:--4000-8000- /proc/sys/kernel/random/entropy_avail:1380 /proc/sys/kernel/random/poolsize:4096 /proc/sys/kernel/random/read_wakeup_threshold:64 /proc/sys/kernel/random/uuid:--4000-8000- /proc/sys/kernel/random/write_wakeup_threshold:1024 The boot_id and uuid values make me believe that something is not quite right. Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Empty /dev/urandom???
On 4/5/2013 5:59 PM, Pedro Principeza wrote: Hi. Although it seems to have all the needed permissions and nodes. Have you tried to recreate it, using: mknod /dev/urandom c 1 9 Same result...still returning zero bytes. Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Empty /dev/urandom???
On Fri, Apr 5, 2013 at 3:59 PM, Pedro Principeza wrote: > Hi. > > Would you mind sending us the output of: > > # ls -l /dev/urandom > > Here ya go: pzsfs101:~ # ls -l /dev/urandom crw-rw-rw- 1 root root 1, 9 Mar 30 21:08 /dev/urandom -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Empty /dev/urandom???
Have recently run into an issue where /dev/urandom is empty: pzsfs101:~ # dd if=/dev/urandom of=/dev/null count=10 0+0 records in 0+0 records out 0 bytes (0 B) copied, 1.35e-05 s, 0.0 kB/s Has anyone else seen this? It causes sshd to fail logins and can only be corrected (as far as I can tell) with a reboot. This is on SLES11 SP2 (3.0.42-0.7-default). Thanks, Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SLES10 SP4 to SLES11 SP2 upgrade issue
Make sue you started an X server on you PC and make sure X11forwarding is enabled prior to logging in. On Mar 7, 2013 12:54 PM, "Smith, Ann (CTO Service Delivery)" < ann.sm...@thehartford.com> wrote: > We made it to SLES11 and at point of patching > Have hit an issue in that script uses YaST2 > Perhaps an export DISPLAY issue > Tried issuing 'export DISPLAY=myhostname:0.0' and 'echo $DISPLAY' to see > it took > But when I issue YaST2 get the message below: > Cannot open display > > Anyone else hit this issue going to SLES11? > > Ann Sm > > This communication, including attachments, is for the exclusive use of > addressee and may contain proprietary, confidential and/or privileged > information. If you are not the intended recipient, any use, copying, > disclosure, dissemination or distribution is strictly prohibited. If you > are not the intended recipient, please notify the sender immediately by > return e-mail, delete this communication and destroy all copies. > > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > -- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ > -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SLES10 SP4 to SLES11 SP2 upgrade issue
Okay, I just have to add my 2 cents. :-) Doesn't seem like you can use X there, so don't try to force it. We just upgraded ~230 servers without using X or VNC. We used the good old ncurses interface. I have to admit that these upgrades were completely automated and the script accessed the "upgrading" guest via ssh from another zLinux guest. However, if you're up for trying it... Make sure X11 forwarding is disabled in your ssh client. After connecting to the target guest, make sure the DISPLAY variable is NOT set: unset DISPLAY Then try the "/usr/lib/YaST2/startup/YaST2.ssh" command. Not saying this will work for you, but if you have the time, patience, and you don't mind the ncurses interface... Leland On Thu, Mar 7, 2013 at 3:09 PM, Smith, Ann (CTO Service Delivery) < ann.sm...@thehartford.com> wrote: > Providing more detail > > Upgrade to sles11 works and reboot of server- but maintenance not done > > Get message: > *** sshd has been started *** > You can login now and proceed with the installation > Run the command '/usr/lib/YaST2/startup/YaST2.ssh' > > When enter the command get > *** Starting YaST2 *** > Terminate called after throwing an instance of 'YUIException' > what(): Can't open display > YaST got signal 6 at YCP file Wizard.ycp:36 > /usr/lib/YaST2/startup/YaST2.call: line 511: 10647 Aborted > FBITERM y2base "$Y2_MODULE_NAME" $Y2_MODE_FLAGS $Y2_MODULE_ARGS ARGS > > Continue with booting ... > > You can login with the (new) root password or the > Newly created user account in a few seconds ... > > (/root) Ready(0)# > > > > > > > -Original Message- > From: Smith, Ann (CTO Service Delivery) > Sent: Thursday, March 07, 2013 3:27 PM > To: 'Linux on 390 Port' > Subject: RE: SLES10 SP4 to SLES11 SP2 upgrade issue > > myhostname is a vmware session running Windows XP > > Only have PuTTY for access > > No longer allowed to use Hummingbird Exceed Xwindows > > -Original Message- > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of > Rick Troth > Sent: Thursday, March 07, 2013 2:57 PM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: SLES10 SP4 to SLES11 SP2 upgrade issue > > Lots of tips/tricks here. If you already know, please excuse me. > > > Tried issuing 'export DISPLAY=myhostname:0.0' and 'echo $DISPLAY' to > > see it took But when I issue YaST2 get the message below: > > Cannot open display > > Be sure that "myhostname" is running an X server. (Is it your PC? Do > you have one of the X server programs for Windows? Or maybe it's > running Linux?) Also be sure that X traffic is not blocked. > > BETTER ... use X via SSH tunnel. > From a system with working X windows, run a command like ... > > ssh -X yourSLES11system > > ... and then 'xterm' from there (to confirm it works). > > If you follow the usual rules about not signing on as root, you may have > additional tricks to pull. We'll cross that bridge once you have X > display working. > > > > > > > > -- > -- R; <>< > > -- > For LINUX-390 subscribe / signoff / archive access instructions, send > email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > visit http://www.marist.edu/htbin/wlvindex?LINUX-390 > -- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ > > This communication, including attachments, is for the exclusive use of > addressee and may contain proprietary, confidential and/or privileged > information. If you are not the intended recipient, any use, copying, > disclosure, dissemination or distribution is strictly prohibited. If you > are not the intended recipient, please notify the sender immediately by > return e-mail, delete this communication and destroy all copies. > > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > -- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ > -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SLES 11 SP2 HAE - Licensing
We just went through this ourselves. You will need to open an SR with Novell and ask them to get you licensed for HAE. It took about a month between the time we opened the SR and when we could download the updates. (They actually asked us to show them why we though we were entitled...we directed them to their own product page.) Also, if you're looking for updated ocfs2 or gfs2 kernel modules, you may have to ask them to build one to match your kernel version. At the time we did this, January this year, the ocfs2 kernel modules had not yet been built for our kernel version and we had to convince them that the older ones would not work with our kernel version. Leland On 2/27/2013 4:18 AM, Florian Bilek wrote: Dear all, I would need to access the fixes repository for SLES 11 SP2 High Availability Extension on IBM zSeries. Looking to the available repositories with SMT does not show the s390x version. Therefore I would like to know how the SLES HA Extension is licensed for SLES 11 SP2 on IBM zSeries? We have a license covering the SLES 11 SP2 for z. Is the HA extension now part of this license or is it considered as a separate product with additional licensing? Thank you very much for your feedback. -- Best regards Florian Bilek -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Using dasd_configure in SLES11 SP2
On 2/18/2013 2:52 AM, Leland Lucius wrote:
> This would have been nice, but it doesn't work. :-(
>
> I will prevail though! :-)
>
I'm ashamed to say that I thought for a while it was going to beat me. It did
teach me more respect (not necessarily understanding) of these udev rules,
especially during initrd processing since different /sys entries are
created/completed at different points.
Anyway, I found the best way is to use the existing rules for onlining DASD,
but rather than create the rules at mkinitrd time, they get created at boot
time.
So, here's the script that gets placed in /lib/mkinitrd/scripts as
boot-dynamic-dasd.sh:
<>
for device in /sys/bus/ccw/devices/*
do
case "$(<${device}/devtype)" in
3380*|3390*|9345*) drv="dasd-eckd" ;;
3370*|9336*) drv="dasd_fba" ;;
*) continue ;;
esac
ccw="${device##*/}"
echo "Creating udev rule for ${ccw}"
cat > /etc/udev/rules.d/51-dasd-${ccw}.rules <>
Create a link:
ln -s ../scripts/boot-dynamic-dasd.sh /lib/mkinitrd/boot/03-dynamic-dasd.sh
Run mkinitrd one last time:
mkinitrd
A new "dynamic-dasd" feature will be present:
Kernel image: /boot/image-3.0.42-0.7-default
Initrd image: /boot/initrd-3.0.42-0.7-default
Root device:/dev/disk/by-path/ccw-0.0.1000-part1 (/dev/dasdh1) (mounted on
/ as ext3)
modprobe: Module ext3dm_mod not found.
WARNING: no dependencies for kernel module 'ext3dm_mod' found.
Kernel Modules: jbd scsi_mod scsi_dh scsi_dh_alua scsi_dh_hp_sw scsi_dh_emc
scsi_dh_rdac mbcache ext3 dasd_mod dasd_eckd_mod crc-t10dif sd_mod
Features: dynamic-dasd block dasd
23175 blocks
And zipl:
zipl
On next boot, expect messages similar to:
doing fast boot
device-mapper: uevent: version 1.0.3
device-mapper: ioctl: 4.20.0-ioctl (2011-02-02) initialised: dm-de...@redhat.co
Creating udev rule for 0.0.1000
Creating udev rule for 0.0.1001
Creating udev rule for 0.0.2000
Creating udev rule for 0.0.5000
Creating udev rule for 0.0.5001
Creating udev rule for 0.0.5002
Creating udev rule for 0.0.5100
SCSI subsystem initialized
alua: device handler registered
hp_sw: device handler registered
emc: device handler registered
rdac: device handler registered
Creating device nodes with udev
udev: starting version 147
dasd-eckd.2aa01a: 0.0.1000: New DASD 3390/0C (CU 3990/01) with 8189 cylinders,
dasd-eckd.412b53: 0.0.1000: DASD with 4 KB/block, 5896080 KB total size, 48 KB/
dasda:LNX1/ 0X9000: dasda1
dasd-eckd.2aa01a: 0.0.1001: New DASD 3390/0C (CU 3990/01) with 8189 cylinders,
dasd-eckd.412b53: 0.0.1001: DASD with 4 KB/block, 5896080 KB total size, 48 KB/
dasdb:LNX1/ 0X9000: dasdb1
dasd-eckd.2aa01a: 0.0.2000: New DASD 3390/0C (CU 3990/01) with 3338 cylinders,
dasd-eckd.412b53: 0.0.2000: DASD with 4 KB/block, 2403360 KB total size, 48 KB/
dasdc:LNX1/ 0X9000: dasdc1
dasd-eckd.2aa01a: 0.0.5000: New DASD 3390/0C (CU 3990/01) with 3338 cylinders,
dasd-eckd.412b53: 0.0.5000: DASD with 4 KB/block, 2403360 KB total size, 48 KB/
dasdd:LNX1/ 0X9000: dasdd1
dasd-eckd.2aa01a: 0.0.5001: New DASD 3390/0C (CU 3990/01) with 3338 cylinders,
dasd-eckd.412b53: 0.0.5001: DASD with 4 KB/block, 2403360 KB total size, 48 KB/
dasde:LNX1/ 0X9000: dasde1
dasd-eckd.2aa01a: 0.0.5002: New DASD 3390/0C (CU 3990/01) with 3338 cylinders,
dasd-eckd.412b53: 0.0.5002: DASD with 4 KB/block, 2403360 KB total size, 48 KB/
dasdf:LNX1/ 0X9000: dasdf1
dasd-eckd.2aa01a: 0.0.5100: New DASD 3390/0C (CU 3990/01) with 8189 cylinders,
dasd-eckd.412b53: 0.0.5100: DASD with 4 KB/block, 5896080 KB total size, 48 KB/
dasdg:LNX1/ 0X9000: dasdg1
Leland
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
Re: Using dasd_configure in SLES11 SP2
This would have been nice, but it doesn't work. :-( I will prevail though! :-) Leland On 2/17/2013 11:36 PM, Leland Lucius wrote: An addendum to my previous post... Ran into an issue this weekend where we'd added a new disk to the root VG of a system and that system wouldn't boot because we didn't recreate the initrd. Yes, really! We actually had to recreate the initrd just because we added a disk to the root VG. Being the non-conformist that I am, I couldn't abide that requirement, so a small script and 3 commands later, I now have that problem solved. Save this script as /lib/mkinitrd/scripts/setup-dasd_all.sh: <> #!/bin/bash # #%stage: device # cat > $tmp_mnt/etc/udev/rules.d/51-dasd-all.rules <> Tell mkinitrd to use it: (all one line...watch for wrappage) ln -s ../scripts/setup-dasd_all.sh /lib/mkinitrd/setup/$(basename /lib/mkinitrd/setup/*-dasd.sh | cut -f 1 -d -)-dasd_all.sh Recreate the initrd: mkinitrd -v You should see a line that says: [DASD] All DASD devices Now run zipl: (however you normally do it) zipl And now you're protected from missing disks in your root VG. Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Using dasd_configure in SLES11 SP2
An addendum to my previous post... Ran into an issue this weekend where we'd added a new disk to the root VG of a system and that system wouldn't boot because we didn't recreate the initrd. Yes, really! We actually had to recreate the initrd just because we added a disk to the root VG. Being the non-conformist that I am, I couldn't abide that requirement, so a small script and 3 commands later, I now have that problem solved. Save this script as /lib/mkinitrd/scripts/setup-dasd_all.sh: <> #!/bin/bash # #%stage: device # cat > $tmp_mnt/etc/udev/rules.d/51-dasd-all.rules <> Tell mkinitrd to use it: (all one line...watch for wrappage) ln -s ../scripts/setup-dasd_all.sh /lib/mkinitrd/setup/$(basename /lib/mkinitrd/setup/*-dasd.sh | cut -f 1 -d -)-dasd_all.sh Recreate the initrd: mkinitrd -v You should see a line that says: [DASD] All DASD devices Now run zipl: (however you normally do it) zipl And now you're protected from missing disks in your root VG. Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Using dasd_configure in SLES11 SP2
On 2/13/2013 6:56 PM, Leland Lucius wrote:
On 2/13/2013 10:07 AM, Peter Oberparleiter wrote:
On 13.02.2013 00:38, Leland Lucius wrote:
Create the following file and remove all of your existing
51-dasd*.rules.
cat /etc/udev/rules.d/51-dasd.rules
# Rule to add all eckd devices
ACTION=="add", SUBSYSTEM=="ccw", DRIVER=="dasd-eckd", ATTR{online}="1"
Note that adding kernel/module parameter dasd=autodetect should achieve
the same result.
That's really weird. We always specify dasd=autodetect. I even just
double checked to make sure. All of the disks are certainly detected,
they just don't come up online.
But, you've got me curious, so I'm going to modify an initrd and see if
the devices are online prior to any initrd processing. Mayhap something
in boot is putting them offline before udev is getting his mitts on 'em.
Probably not, but I just HAVE to know. :-)
Definitely detected but offline no matter if I specify dasd=autodetect
or a device range like dasd=0.0.-0.0.. Even tried
dasd=0.0.-0.0.,autodetect for the heck of it.
I just added:
grep -ir '.*' /sys/bus/ccw/devices/*/online
as the second line of the "init" script in the initrd. The only device
at this point that shows as being online is the console device (0009).
/sys/bus/ccw/devices/0.0.0009/online:1
/sys/bus/ccw/devices/0.0.000c/online:0
/sys/bus/ccw/devices/0.0.000d/online:0
/sys/bus/ccw/devices/0.0.000e/online:0
/sys/bus/ccw/devices/0.0.0190/online:0<--- disk
/sys/bus/ccw/devices/0.0.0191/online:0<--- disk
/sys/bus/ccw/devices/0.0.019d/online:0<--- disk
/sys/bus/ccw/devices/0.0.019e/online:0<--- disk
/sys/bus/ccw/devices/0.0.0592/online:0<--- disk
/sys/bus/ccw/devices/0.0.1000/online:0<--- disk
/sys/bus/ccw/devices/0.0.3000/online:0
/sys/bus/ccw/devices/0.0.3001/online:0
/sys/bus/ccw/devices/0.0.3002/online:0
/sys/bus/ccw/devices/0.0.3200/online:0
/sys/bus/ccw/devices/0.0.3201/online:0
/sys/bus/ccw/devices/0.0.3202/online:0
/sys/bus/ccw/devices/0.0.4000/online:0< disk
Leland
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
Re: Using dasd_configure in SLES11 SP2
Hi Tomas,
Did you catch this line in my other reply?
# Set them to readonly if linked R/O
ACTION=="add", SUBSYSTEM=="ccw", DRIVER=="dasd-eckd", PROGRAM="/bin/sh -c
'/sbin/modprobe vmcp;/sbin/vmcp q v dasd|grep ${DEVPATH##*.}|grep -q R/O'",
ATTR{readonly}="1"
Again...make sure it's all on one line.
Leland
On 2/13/2013 1:31 AM, Pavelka, Tomas wrote:
> Will your solution preserve read only attributes? I.e. if you bring all dasd
> online with a single udev rule, will those linked as read only have the
> correct read only attributes so the kernel knows that it cannot write to them?
>
> Example of what I mean by correct read only attributes:
>
>> vmcp q v dasd
> DASD 0200 3390 VMBL1V R/W353 CYL ON DASD 8460 SUBCHANNEL = 0001
> DASD 0201 3390 VMBL1J R/O683 CYL ON DASD 845C SUBCHANNEL = 0002
>
>> lsdasd
> Bus-ID Status Name Device Type BlkSz Size Blocks
> ==
> 0.0.0200 active dasda 94:0ECKD 4096 248MB 63540
> 0.0.0201 active(ro) dasdb 94:4ECKD 4096 480MB 122940
>
> We have ran into the same problem you are describing and ended up making
> individual rules for each dasd (e.g.
> /etc/udev/rules.d/51-dasd-0.0.0200.rules) to preserve read only attributes.
> But we are new to SUSE and haven't experimented with a single rule for all
> dasd which is why I am curious.
>
> Tomas
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> --
> For more information on Linux on System z, visit
> http://wiki.linuxvm.org/
>
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
Re: Using dasd_configure in SLES11 SP2
On 2/13/2013 10:07 AM, Peter Oberparleiter wrote:
On 13.02.2013 00:38, Leland Lucius wrote:
Create the following file and remove all of your existing 51-dasd*.rules.
cat /etc/udev/rules.d/51-dasd.rules
# Rule to add all eckd devices
ACTION=="add", SUBSYSTEM=="ccw", DRIVER=="dasd-eckd", ATTR{online}="1"
Note that adding kernel/module parameter dasd=autodetect should achieve
the same result.
That's really weird. We always specify dasd=autodetect. I even just
double checked to make sure. All of the disks are certainly detected,
they just don't come up online.
But, you've got me curious, so I'm going to modify an initrd and see if
the devices are online prior to any initrd processing. Mayhap something
in boot is putting them offline before udev is getting his mitts on 'em.
Probably not, but I just HAVE to know. :-)
Leland
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
Re: Using dasd_configure in SLES11 SP2
On Wed, Feb 13, 2013 at 12:49 PM, Mark Post wrote:
> >>> On 2/12/2013 at 06:38 PM, Leland Lucius wrote:
> > As a followup to a posting over on the IBM/VM mailing list about using
> > dasd_configure to bring a device online and create the necessary udev
> > rules, I wanted to contribute this as I think having a separate rule file
> > for every disk device attached to my guests is just wrong.
>
> I would disagree with the "wrong" bit. There are a number of reasons why
> you might want to do this. Keeping things fairly simple and therefore
> easier to understand is one of them.
Could just be my screwy grey matter (probably is ;-)), but I find the
static rule files more difficult to deal with (trust issues) and get much
more of a warm fuzzy knowing that if I add a disk to my Linux guests, it
will be there when I boot. I can only hope that it will be there with the
static rules.
> Trying to handle all the various attributes for all DASD from one file is
> not easy. Things like readonly, use_diag, eer_enabled, and so on.
>
Here's an addition to my previous post that updates the readonly attribute:
# Bring ECKD devices online
ACTION=="add", SUBSYSTEM=="ccw", DRIVER=="dasd-eckd", ATTR{online}="1"
# Set them to readonly if linked R/O
ACTION=="add", SUBSYSTEM=="ccw", DRIVER=="dasd-eckd", PROGRAM="/bin/sh -c
'/sbin/modprobe vmcp;/sbin/vmcp q v dasd|grep ${DEVPATH##*.}|grep -q R/O'",
ATTR{readonly}="1"
But I totally agree with you. Get anymore complicated and an external
script to (dynamically) handle all of the attributes would be the way to go.
>
> -snip-
> > All of our Linux disks are defined at address 1000 or greater. Anything
> > below that address is a CMS disk and is detached in the guests PROFILE
> > EXEC. So, Linux only sees the disks that we want him to see and
> everything
> > above 1000 SHOULD be seen without having to have another file to worry
> > whether it's there or not.
>
> That's fine in a well-controlled z/VM environment. I would definitely
> _not_ recommend this for anyone running any Linux in an LPAR. Too much
> potential for damage, and it will certainly slow down the boot process if
> all devices are visible to all LPARs as most sites have things defined
> these days.
>
Yepper, I thought about that last night and wished I'd put in a blurb about
z/VM only. That little udev rule would NOT be a good thing if running bare.
>
> -snip-
> > Yes, dasd_configure will still create additional rules files, but it
> won't
> > hurt.
>
> As will YaST, since it calls dasd_configure under the covers. So don't be
> surprised if they show up again even if don't use dasd_configure directly.
>
We're good to go there too as we never really use YaST and uninstall most
of the yast rpms (all of them that we can without breaking dependencies).
Leland
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
Re: Using dasd_configure in SLES11 SP2
On 2/13/2013 1:31 AM, Pavelka, Tomas wrote: Will your solution preserve read only attributes? I.e. if you bring all dasd online with a single udev rule, will those linked as read only have the correct read only attributes so the kernel knows that it cannot write to them? No, but it would be easy to add. Let me tinker a little for ya. Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Using dasd_configure in SLES11 SP2
As a followup to a posting over on the IBM/VM mailing list about using
dasd_configure to bring a device online and create the necessary udev
rules, I wanted to contribute this as I think having a separate rule file
for every disk device attached to my guests is just wrong.
Personally, I haven't used dasd_configure in years as I'd switched to
chccwdev usage probably around the time SLES10 SP3 (maybe SP2) came out.
All of our Linux disks are defined at address 1000 or greater. Anything
below that address is a CMS disk and is detached in the guests PROFILE
EXEC. So, Linux only sees the disks that we want him to see and everything
above 1000 SHOULD be seen without having to have another file to worry
whether it's there or not.
WARNING: This works here. It may NOT work for you and you may wind up
with an unbootable system. Use at your own risk!!!
Create the following file and remove all of your existing 51-dasd*.rules.
cat /etc/udev/rules.d/51-dasd.rules
# Rule to add all eckd devices
ACTION=="add", SUBSYSTEM=="ccw", DRIVER=="dasd-eckd", ATTR{online}="1"
Careful. The ACTION line should be on a single line...watch for wrappage.
Now, all eckd disks will automatically be brought online at boot time
whether you use chccwdev or dasd_configure.
Yes, dasd_configure will still create additional rules files, but it won't
hurt.
Cool thing is you no longer have to use dasd_configure and you've just
given yourself several more seconds of productive time each year. :-)
Leland
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
Re: Kernel internals question
Sorry, that should be "> 255"...stupid fingers! Leland On Tue, Jan 22, 2013 at 5:49 PM, Leland Lucius wrote: > > Not really. The different address spaces are handled inside the kernel. > You're looking at dealing with user mode progs, so they shouldn't care > what address space they run in. > > It looks like SVC 0 is used as a "router" for syscalls > 256 and the > actual syscall number defined in /usr/include/asm/unistd.h for the rest. > > Leland > > > On Tue, Jan 22, 2013 at 5:32 PM, John McKown > wrote: > >> Thanks. Kills my idea, I guess. >> On Jan 22, 2013 5:29 PM, "Mark Post" wrote: >> >> > >>> On 1/22/2013 at 04:13 PM, John McKown > > >> > wrote: >> > > OK, if I read and understood all the source, I wouldn't need to ask >> this. >> > > >> > > On Intel, the Kernel is invoked via an INT instruction. And it seems >> > > to only use a single INT number at that; number 0x80 (128 decimal). >> > > Does the zSeries version do the same, but using the SVC instruction >> > > instead? Does it also only use one SVC number (which one)? Does it use >> > > any of the more advanced facilities such as PC (non-ss or cp-ss), PR, >> > > or access registers? >> > >> > Linux on System z does use access registers because it sets up primary, >> > secondary, etc. address spaces to keep kernel and user space memory >> > isolated from each other. >> > >> > >> > Mark Post >> > >> > -- >> > For LINUX-390 subscribe / signoff / archive access instructions, >> > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 >> or >> > visit >> > http://www.marist.edu/htbin/wlvindex?LINUX-390 >> > -- >> > For more information on Linux on System z, visit >> > http://wiki.linuxvm.org/ >> > >> >> -- >> For LINUX-390 subscribe / signoff / archive access instructions, >> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or >> visit >> http://www.marist.edu/htbin/wlvindex?LINUX-390 >> -- >> For more information on Linux on System z, visit >> http://wiki.linuxvm.org/ >> > > -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Kernel internals question
Not really. The different address spaces are handled inside the kernel. You're looking at dealing with user mode progs, so they shouldn't care what address space they run in. It looks like SVC 0 is used as a "router" for syscalls > 256 and the actual syscall number defined in /usr/include/asm/unistd.h for the rest. Leland On Tue, Jan 22, 2013 at 5:32 PM, John McKown wrote: > Thanks. Kills my idea, I guess. > On Jan 22, 2013 5:29 PM, "Mark Post" wrote: > > > >>> On 1/22/2013 at 04:13 PM, John McKown > > wrote: > > > OK, if I read and understood all the source, I wouldn't need to ask > this. > > > > > > On Intel, the Kernel is invoked via an INT instruction. And it seems > > > to only use a single INT number at that; number 0x80 (128 decimal). > > > Does the zSeries version do the same, but using the SVC instruction > > > instead? Does it also only use one SVC number (which one)? Does it use > > > any of the more advanced facilities such as PC (non-ss or cp-ss), PR, > > > or access registers? > > > > Linux on System z does use access registers because it sets up primary, > > secondary, etc. address spaces to keep kernel and user space memory > > isolated from each other. > > > > > > Mark Post > > > > -- > > For LINUX-390 subscribe / signoff / archive access instructions, > > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > > visit > > http://www.marist.edu/htbin/wlvindex?LINUX-390 > > -- > > For more information on Linux on System z, visit > > http://wiki.linuxvm.org/ > > > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > -- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ > -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: disable autocleanup of /tmp
If you're running SLES, check /etc/sysconfig/cron. There's a setting called CLEAR_TMP_DIRS_AT_BOOTUP. It appears the default is NO. On Fri, Jan 18, 2013 at 2:42 PM, Mark Pace wrote: > Is there a way to disable autocleanup of /tmp at boot? I've found > /etc/rc.d/boot.cleanup but I'm unsure of what to change to make it not > cleanup. > > Thanks. > > -- > The postings on this site are my own and don’t necessarily represent > Mainline’s positions or opinions > > Mark D Pace > Senior Systems Engineer > Mainline Information Systems > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > -- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ > -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Twin penguins prospered for 417 days, then died
On 1/11/2013 4:55 PM, Marcy Cortes wrote: Has anybody been able to run SLES 11.1 s390x servers for more than 417 days without problems, and if so, what is/was the level of their kernel? Are you kidding? Some of us patch for security. Frequently. Very frequently. 90 days would be a cause for celebration. I want to come work with you. We have patch cycles scheduled quarterly, but the business always has something more important. Current uptime for our production servers: pzasap10:~ # uptime 5:41pm up 502 days 3:27, 1 user, load average: 0.00, 0.00 :-) -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: I/O scheduler on sles 11 sp2 on z
On 12/2/2012 1:43 PM, Leland Lucius wrote: Marcy, Did you get past this issue? Did 3.0.38 or fix it for you? or 3.0.42 :-) -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: I/O scheduler on sles 11 sp2 on z
Marcy, Did you get past this issue? Did 3.0.38 or fix it for you? Thanks much, Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Does SLES 11 High Availability Extension cost extra?
Thanks Mary. Not often we get something for free on z. :-) On Fri, Nov 30, 2012 at 4:14 PM, Marcy Cortes wrote: > Not on z - its zero charge there. > > -Original Message- > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of > Leland Lucius > Sent: Friday, November 30, 2012 12:53 PM > To: LINUX-390@VM.MARIST.EDU > Subject: [LINUX-390] Does SLES 11 High Availability Extension cost extra? > > I thought at one point Novell included all of the HA packages in the base > product. But, now it "seems" that HAE has to be purchased separately. > > Is that correct? > > Thanks, > > Leland > > -- > For LINUX-390 subscribe / signoff / archive access instructions, send > email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > -- > For more information on Linux on System z, visit http://wiki.linuxvm.org/ > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > -- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ > -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Does SLES 11 High Availability Extension cost extra?
I thought at one point Novell included all of the HA packages in the base product. But, now it "seems" that HAE has to be purchased separately. Is that correct? Thanks, Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: HyperPAV and LVM striping
On Wed, Oct 10, 2012 at 12:53 PM, Mark Post wrote: > > >>> On 10/10/2012 at 11:35 AM, "Duerbusch, Tom" > >>> wrote: > > > Just speaking to LVM... > > > > Striping the data across multiple volumes (which in modern dasd is already > > stripped in the Raid array), would give you the best performance. > > Especially if you can strip across multiple DS8000 (or other dasd > > subsystems). > > > > But you can also use LVM as a pool of DASD, with no striping involved. > > > > In case 1, if you need to expand the LVM pool, it is a hassle. It might > > mean backing up, reformatting and reloading the data. In any case, it > > involves a knowledgeable person and most likely, downtime. > > This is simply not true. Expanding a striped LV can be done dynamically with > no downtime. The only aspect that is different from a non-striped LV is that > you have to have enough free space on as many different PVs as the number of > stripes you have. That is, if you did an "lvcreate -i 2" then when you do an > lvextend/lvresize, you have to have free space available on 2 different PVs > in the pool. An "lvcreate -i 3" means you need free space on 3 PVs, etc. > Not "really" true either. Even if you originally stripe with 2 or 3 or whatever, you can always "lvextend -i 1" to add another segment. That's because striping is done at the segment level and each segment can be configured independently. Mind you that you loose the performance benefit for that specific segment, but that can be remedied later when you have more time or can take the outage. Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: HyperPAV and LVM striping
On Wed, Oct 10, 2012 at 12:53 PM, Mark Post wrote: > > >>> On 10/10/2012 at 11:35 AM, "Duerbusch, Tom" > >>> wrote: > > > Just speaking to LVM... > > > > Striping the data across multiple volumes (which in modern dasd is already > > stripped in the Raid array), would give you the best performance. > > Especially if you can strip across multiple DS8000 (or other dasd > > subsystems). > > > > But you can also use LVM as a pool of DASD, with no striping involved. > > > > In case 1, if you need to expand the LVM pool, it is a hassle. It might > > mean backing up, reformatting and reloading the data. In any case, it > > involves a knowledgeable person and most likely, downtime. > > This is simply not true. Expanding a striped LV can be done dynamically with > no downtime. The only aspect that is different from a non-striped LV is that > you have to have enough free space on as many different PVs as the number of > stripes you have. That is, if you did an "lvcreate -i 2" then when you do an > lvextend/lvresize, you have to have free space available on 2 different PVs > in the pool. An "lvcreate -i 3" means you need free space on 3 PVs, etc. > Not "really" true either. Even if you originally stripe with 2 or 3 or whatever, you can always "lvextend -i 1" to add another segment. That's because striping is done at the segment level and each segment can be configured independently. Mind you that you loose the performance benefit for that specific segment, but that can be remedied later when you have more time or can take the outage. Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Accessing Old Linux System After DASD Move
On Thu, Nov 3, 2011 at 3:10 PM, Alan Altmark > You aren't going > to be able to fix them from MVS. > I'm not saying you're wrong because you're absolutely right. But, I'm feeling a little nostalgic today and thought I point out a bit of code I'd done a while back. http://www.sinenomine.net/products/vm/ext2free I wrote it on USS and did most of the validation there. Then I simply copied the binaries to z/VM. A good showing of how compatible the runtimes environs are. Never did take it any further though. (I know, doesn't help out in this situation...) Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: z/VM Switch performance
On 10/27/11 11:07 AM, Marcy Cortes wrote: > Offer, I do get the erratic pings too. Not as high as 200, but some 50s. > > It was reported to me a few weeks ago by one of our more sophisticated users > that traceroute occasionally fails over the same vswitch. > Run it like 20 times 1 right after another to recreate or use the -q option > with something like -q 8. > > I checked with another customer and he also saw the same behavior. > > I opened a PMR with VM but they said to open one with Linux. I have not > gotten around to opening one with Novell yet. > > Could some of you others out there try this simple ping test? > > We are also vlan aware and it does happen on both LACP and non-LACP. > We have both aware and unaware VSWITCHes. Results of two guests connected to the same aware VSWITCH and on the same VLAN: pzawap01:~ # traceroute pzawap03 traceroute to pzawap03 (172.2.2.211), 30 hops max, 40 byte packets 1 pzawap03.svc (172.2.2.211) 0.114 ms 0.134 ms 0.016 ms pzawap01:~ # traceroute pzawap03 traceroute to pzawap03 (172.2.2.211), 30 hops max, 40 byte packets 1 pzawap03.svc (172.2.2.211) 0.055 ms 0.136 ms 0.024 ms pzawap01:~ # traceroute pzawap03 traceroute to pzawap03 (172.2.2.211), 30 hops max, 40 byte packets 1 pzawap03.svc (172.2.2.211) 0.000 ms * * Results of two guests connected to the same unaware VSWITCH: pzsdns01:~ # traceroute 192.1.1.28 traceroute to 192.1.1.28 (192.1.1.28), 30 hops max, 40 byte packets 1 192.1.1.28 (192.1.1.28) 0.199 ms 0.036 ms 0.074 ms pzsdns01:~ # traceroute 192.1.1.28 traceroute to 192.1.1.28 (192.1.1.28), 30 hops max, 40 byte packets 1 192.1.1.28 (192.1.1.28) 0.189 ms 0.492 ms * pzsdns01:~ # traceroute 192.1.1.28 traceroute to 192.1.1.28 (192.1.1.28), 30 hops max, 40 byte packets 1 192.1.1.28 (192.1.1.28) 0.140 ms 0.038 ms 0.087 ms pzsdns01:~ # traceroute 192.1.1.28 traceroute to 192.1.1.28 (192.1.1.28), 30 hops max, 40 byte packets 1 192.1.1.28 (192.1.1.28) 0.244 ms 0.044 ms 0.026 ms pzsdns01:~ # traceroute 192.1.1.28 traceroute to 192.1.1.28 (192.1.1.28), 30 hops max, 40 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 192.1.1.28 (192.1.1.28) 0.306 ms 0.196 ms 0.286 ms Results from a guest on an unaware VSWITCH to a guest on a different unaware VSWITCH (same LPAR) pzsdns01:~ # traceroute pzsadm01 traceroute to pzsadm01 (172.1.1.35), 30 hops max, 40 byte packets 1 192.1.1.1 (192.1.1.1) 0.289 ms 0.254 ms 0.230 ms 2 pzsadm01.svc (172.1.1.35) 0.271 ms 0.311 ms 0.324 ms pzsdns01:~ # traceroute pzsadm01 traceroute to pzsadm01 (172.1.1.35), 30 hops max, 40 byte packets 1 192.1.1.1 (192.1.1.1) 0.320 ms 0.276 ms 0.682 ms 2 pzsadm01.svc (172.1.1.35) 0.321 ms 0.263 ms 0.296 ms pzsdns01:~ # traceroute pzsadm01 traceroute to pzsadm01 (172.1.1.35), 30 hops max, 40 byte packets 1 192.1.1.1 (192.1.1.1) 0.322 ms 0.278 ms 0.259 ms 2 * * * 3 * * * 4 * * * 5 * * * 6 pzsadm01.svc (172.1.1.35) 0.755 ms * * Results from a guest on an aware VSWITCH to a guest on an aware VSWITCH on different LPARs (same VLAN) pzawap01:~ # traceroute pzawap04 traceroute to pzawap04 (172.3.3.212), 30 hops max, 40 byte packets 1 pzawap04.svc (172.3.3.212) 0.540 ms 0.298 ms 0.310 ms pzawap01:~ # traceroute pzawap04 traceroute to pzawap04 (172.3.3.212), 30 hops max, 40 byte packets 1 pzawap04.svc (172.3.3.212) 0.463 ms 0.312 ms 0.313 ms pzawap01:~ # traceroute pzawap04 traceroute to pzawap04 (172.3.3.212), 30 hops max, 40 byte packets 1 pzawap04.svc (172.3.3.212) 0.381 ms * * All guests are SLES10-SP3 (kernel 2.6.16.60-0.76.8-default) Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SLES 10 mkinitrd
On 4/13/11 2:58 AM, Mark Post wrote:
On 4/13/2011 at 03:00 AM, Leland Lucius wrote:
Yepper, that's exactly what it's supposed to do, but the word count
("$#") will not be 3, it will be 4 for "root=/dev/rootvg/lv01":
Looks like you're right. If it's causing you a problem, please open up a
service request.
Okay. It looked off to me, but I actually figured somebody was gonna
come back and tell me that I was using some archaic root= syntax or some
such.
Thanks,
Leland
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
Re: SLES 10 mkinitrd
On 4/12/11 11:48 PM, Mark Post wrote:
On 4/12/2011 at 10:39 PM, Leland Lucius wrote:
n 4/12/11 4:11 PM, Leland Lucius wrote:
Does anyone else find this bit of code produced by mkinitrd to be a little
off?
root=/dev/*)
set -- $(IFS=/ ; echo $o)
if [ "$#" = "3" ]&& [ "$2" != "cciss" ] ; then
vg_root=$2
fi
;;
This comes from the "init" script created by the mkinitrd command.
How about if '/proc/cmdline' has "root=/dev/rootvg/lv01" as one of the
arguments?
The intent seems to be to pick out the VG name, since a couple of lines below
that I see
if [ -z "\$vg_root" ]; then
vg_root=$vg_root
fi
Yepper, that's exactly what it's supposed to do, but the word count
("$#") will not be 3, it will be 4 for "root=/dev/rootvg/lv01":
root=
dev
rootvg
lv01
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
Re: SLES 10 mkinitrd
On 4/12/11 4:11 PM, Leland Lucius wrote: Does anyone else find this bit of code produced by mkinitrd to be a little off? root=/dev/*) set -- $(IFS=/ ; echo $o) if [ "$#" = "3" ]&& [ "$2" != "cciss" ] ; then vg_root=$2 fi ;; This comes from the "init" script created by the mkinitrd command. How about if '/proc/cmdline' has "root=/dev/rootvg/lv01" as one of the arguments? Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
SLES 10 mkinitrd
Does anyone else find this bit of code produced by mkinitrd to be a little off? root=/dev/*) set -- $(IFS=/ ; echo $o) if [ "$#" = "3" ] && [ "$2" != "cciss" ] ; then vg_root=$2 fi ;; This comes from the "init" script created by the mkinitrd command. Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Convert filesystems now or wait for SLES1x?
On 2/22/11 12:54 AM, Mark Post wrote: On 2/22/2011 at 01:42 AM, Leland Lucius wrote: Up til now we've used Reiser and would convert to ext3 as part of the rebuilds. But, should we leave all of this until the next upgrade? Will the next recommendation be btrfs or ext4? Will they still be too "new" to bet the house on? I would wait until a system gets replaced or upgraded. I doubt very much that ext4 will ever be a SUSE Linux standard. btrfs might be, but not in the short term, and certainly not for SLES11. SLES12 would be the earliest, if at all. Then we shall just stick with ext3. Thanks, Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Convert filesystems now or wait for SLES1x?
We're going to be upgrading to SLES11 and we have the desire to standardize all of our file systems layouts. We did start out with a standard, but that has evolved over the years and it's now pretty stable, so we figure we might as well take the opportunity... Up til now we've used Reiser and would convert to ext3 as part of the rebuilds. But, should we leave all of this until the next upgrade? Will the next recommendation be btrfs or ext4? Will they still be too "new" to bet the house on? Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: crypto with sshd
On 2/15/11 10:19 AM, Rogério Soares wrote:
>
> but, i shoud be able to see some increase on Per-device successfully
> completed request counts ?
>
> Thanks for you attention :)
>
Yes, they do increase for me each time I login via ssh:
pzsadm01:~ # cat /proc/driver/z90crypt
zcrypt version: 2.1.1
Cryptographic domain: 9
Total device count: 1
PCICA count: 0
PCICC count: 0
PCIXCC MCL2 count: 0
PCIXCC MCL3 count: 0
CEX2C count: 0
CEX2A count: 1
requestq count: 0
pendingq count: 0
Total open handles: 2
Online devices: 1=PCICA 2=PCICC 3=PCIXCC(MCL2) 4=PCIXCC(MCL3) 5=CEX2C 6=CEX2A
6000
Waiting work element counts
Per-device successfully completed request counts
0009
Here's what I have installed:
libica-1.3.8-0.7
libica-32bit-1.3.8-0.7
openCryptoki-2.2.4-0.12.10
openCryptoki-32bit-2.2.4-0.12.10
openCryptoki-64bit-2.2.4-0.12.10
openssh-4.2p1-18.40.35 <-- has been modified with the extra define
openssl-0.9.8a-18.42.2
openssl-32bit-0.9.8a-18.42.2
openssl-ibmca-1.0.0-7.16
openssl-ibmca-32bit-1.0.0-7.16
Here's what I get when querying crypto support from with a guest:
pzsadm01:~ # vmcp q crypto ap
AP 00 CEX2C Queue 12 is superseded by CEX2A
AP 01 CEX2A Queue 12 is installed
AP 02 CEX2C Queue 12 is superseded by CEX2A
AP 03 CEX2A Queue 12 is installed
Here's what my openssl.cnf file looks like. One thing that I recall running
into was the correct placement of the openssl_cnf line. Make sure it comes
before the [new_oids] section.
#
# OpenSSL example configuration file.
# This is mostly being used for generation of certificate requests.
#
# This definition stops the following lines choking if HOME isn't
# defined.
HOME= .
RANDFILE= $ENV::HOME/.rnd
# Extra OBJECT IDENTIFIER info:
#oid_file = $ENV::HOME/.oid
oid_section = new_oids
openssl_conf = openssl_def
# To use this configuration file with the "-extfile" option of the
# "openssl x509" utility, name here the section containing the
# X.509v3 extensions to use:
# extensions=
# (Alternatively, use a configuration file that has only
# X.509v3 extensions in its main [= default] section.)
<<>>
[openssl_def]
engines = engine_section
[engine_section]
foo = ibmca_section
[ibmca_section]
dynamic_path = /usr/lib64/engines/libibmca.so
engine_id = ibmca
default_algorithms = ALL
#default_algorithms = RAND,RSA
init = 1
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
Re: crypto with sshd
On 2/12/11 3:03 PM, Rogério Soares wrote: > Mike, i have installed all packages describe on paper.. appears like sshd is > not calling icalib, i just have recompile sshd with --ssl-engine, is just it > ? i do not understand very well on paper if the "PTF" is just is or > something more... > When I got this working, I never added "--ssl-engine". What I did add was one additional define to the CFLAGS and CXXFLAGS variables in the openssh.spec file: LDFLAGS="-pie" CFLAGS="-DOPENSSL_LOAD_CONF=1 $RPM_OPT_FLAGS $PIEFLAGS -fstack-protector" CXXFLAGS="-DOPENSSL_LOAD_CONF=1 $RPM_OPT_FLAGS $PIEFLAGS -fstack-protector" \ When OPENSSL_LOAD_CONF is set to 1, the routine that actually reads the config file gets called. Otherwise, the config file is never read and ssh will not use the dynamic engine support. Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
smcli - z/VM System Management command line utility
Some of you folks might find this useful. It implements all but 1 of the SMAPI functions in a single bash script. In addition, it supports TCP/IP via bash's builtin /dev/tcp support and IUCV via the embedded smiucv program that you can build using "smcli smiucv". Documentation is slim, so you'll have to use the builtin "usage" information for each function and the System Management Application Programming book from IBM. Anyway, grab it here: http://homerow.net/zvm/smcli I hope someone finds if useful. Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: crypto with sshd
Another way of telling is to transfer a LARGE file with your pre-crypto sshd and again with your post-crypto sshd. Just watch the difference it makes in your favorite z/VM performance monitor. You won't necessarily realize an improvement in throughput, but the amount of CPU consumed drops considerably. Leland 2011/2/11 Rogério Soares : > Hello dears, > > I have set up a test machine to use crpto card... my wish is using that > with sshd... so, i installed : > > • openssh > • openssl > • openssl-ibmca > • libica > • z90crypt > > made changes on openssl.cnf to use libica engine, load z90crypt module and > after that i get openssh from source rpm and rebuild then with --ssl-engine > , and then made a rpm -Uvhm restart the daemon.. > > on SLES10SP3 i don't have the icastats command, so, how can i be sure that > crypto card is used by openssh ? > > > i made several connections and take a look on /proc/driver/z90crypt, but the > number don't change... are this process is correct or i missing something? > > Thanks again. :) > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > -- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ > -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Automated Upgrade from SUSE Linux Enterprise 10 SP3 to 11 SP1
Just wanted to give folks a little hope. This does work. It's not entirely unattended as you still have to kick it off by running yast (I think this is at what is called stage 1 maybe???) and then run the "/usr/lib/YaST2/startup/YaST2.sh" after the upgrade is complete. (stage2???) But, other than that and depending on how you set up the upgrade xml file, it proceeds without asking any other questions. It can still stop and prompt you. For instance, our /boot partition is only 32MB and the upgrade complains about it needing to be 64MB. It also will complain if it has a problem installing any RPMs. In our case it has a problem installing "ruby" which I haven't looked into yet. If you set "only_installed_packages" to true it does update based on the installed packages and, in our case, cuts down on about 1GB of unnecessary packages. It still installs unneeded packages however, so there's still some post-upgrade activity that has to occur. I'm going to try and add these to the "remove_packages" list in the upgrade file to see if it will just skip installing them at all. It's not all roses however. The one main issue I ran into was that it doesn't automatically activate the DASD volumes, so prior to running the first "yast", I simply bring them online manually. I will be adding this to the initrd, so I won't have to remember to do it. :-) Anyway, it's not a bad start, especially for something that's at version 0.0.1. :-) Leland On 1/26/11 1:48 AM, Leland Lucius wrote: On 1/25/11 11:59 PM, Mark Post wrote: On 1/26/2011 at 12:02 AM, Leland Lucius wrote: Has anyone tried and gotten this to work: http://doc.opensuse.org/products/draft/SLES/SLES-deployment/cha.update.auto. html I would imagine not, since I'm not aware of the driver update (dud) being released that will make this work. Understand, Novell does not publish official SLES documentation via openSUSE.org web pages. Somebody must be working on it: pzsadm01:/depot/sles # rpm -q --info -p ./SLES11-SP1-Updates/sle-11-s390x/rpm/s390x/unattended_upgrade_dud-0.0.1-1.1.s390x.rpm Name: unattended_upgrade_dud Relocations: (not relocatable) Version : 0.0.1 Vendor: SUSE LINUX Products GmbH, Nuernberg, Germany Release : 1.1 Build Date: Thu Dec 9 09:10:48 2010 Install Date: (not installed) Build Host: s390z05 Group : System/YaST Source RPM: unattended_upgrade_dud-0.0.1-1.1.src.rpm Size: 257666 License: GPL Signature : RSA/8, Thu Dec 9 09:10:52 2010, Key ID e3a5c360307e3d54 Packager: http://bugs.opensuse.org Summary : DUD for unattended upgrade Description : - Distribution: SUSE Linux Enterprise 11 But, as usual, I always see to want something before it's actually ready. :-) I actually have made more progress getting it to work, but I have a feeling I'll only be able to get it to the 99% mark and fail to get that last 1%. :-) Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Automated Upgrade from SUSE Linux Enterprise 10 SP3 to 11 SP1
On 1/25/11 11:59 PM, Mark Post wrote: >>>> On 1/26/2011 at 12:02 AM, Leland Lucius wrote: >> Has anyone tried and gotten this to work: >> >> http://doc.opensuse.org/products/draft/SLES/SLES-deployment/cha.update.auto. >> html > > I would imagine not, since I'm not aware of the driver update (dud) being > released that will make this work. Understand, Novell does not publish > official SLES documentation via openSUSE.org web pages. > Somebody must be working on it: pzsadm01:/depot/sles # rpm -q --info -p ./SLES11-SP1-Updates/sle-11-s390x/rpm/s390x/unattended_upgrade_dud-0.0.1-1.1.s390x.rpm Name: unattended_upgrade_dud Relocations: (not relocatable) Version : 0.0.1 Vendor: SUSE LINUX Products GmbH, Nuernberg, Germany Release : 1.1 Build Date: Thu Dec 9 09:10:48 2010 Install Date: (not installed) Build Host: s390z05 Group : System/YaST Source RPM: unattended_upgrade_dud-0.0.1-1.1.src.rpm Size: 257666 License: GPL Signature : RSA/8, Thu Dec 9 09:10:52 2010, Key ID e3a5c360307e3d54 Packager: http://bugs.opensuse.org Summary : DUD for unattended upgrade Description : - Distribution: SUSE Linux Enterprise 11 But, as usual, I always see to want something before it's actually ready. :-) I actually have made more progress getting it to work, but I have a feeling I'll only be able to get it to the 99% mark and fail to get that last 1%. :-) Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Automated Upgrade from SUSE Linux Enterprise 10 SP3 to 11 SP1
Has anyone tried and gotten this to work: http://doc.opensuse.org/products/draft/SLES/SLES-deployment/cha.update.auto.html I've gotten half way there, but rather than spend (waste) too much more time on it, I thought I'd better ask to see if I'm banging my head against the wall for nothing. Are there other automated (meaning unattended) methods of upgrading 10SP3 to 11SP1? Thanks, Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Oracle client problem on SLES 10
If the Oracle client loads libraries dynamically, then I'd try to find out if you're missing any lib* packages that you may have installed on the SLES9 system. I wonder if you might have some 32bit libs missing... On Tue, Dec 14, 2010 at 12:12 PM, Marcy Cortes < marcy.d.cor...@wellsfargo.com> wrote: > We've been using the Oracle 10gr2 client on SLES 9 to talk to some > distributed oracle DB server. > > We're trying to get it to work on sles 10. It works except when security > is enabled. > > We are getting > > oracle error (#12657), which says: > > Cause: The near side of the connection required the use of a > service (either encryption or checksumming) when no > algorithms for that service were installed. > > Action: Remove the "ON" requirement for that service. > > > The following lines are in the Oracle sqlnet.ora file for our connection to > the Oracle database, which I believe uses this checksumming & encryption > settings... > > SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT= (MD5) > SQLNET.CRYPTO_CHECKSUM_CLIENT= requested > SQLNET.ENCRYPTION_TYPES_CLIENT= (DES, DES40) > SQLNET.ENCRYPTION_CLIENT= required > > Commenting out these lines works, but we need to have them in there. > Any idea why Oracle is complaining about not having the needed algorithms > installed? > > > Marcy Cortes > > > This message may contain confidential and/or privileged information. If you > are not the addressee or authorized to receive this for the addressee, you > must not use, copy, disclose, or take any action based on this message or > any information herein. If you have received this message in error, please > advise the sender immediately by reply e-mail and delete this message. Thank > you for your cooperation. > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > -- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ > -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Crypto on SLES 11 SP1 - ssl engine ibmca
Mark Post wrote: On 9/3/2010 at 09:59 PM, Marcy Cortes wrote: Has anyone tried it? Did I miss a needed package or something? Take a look at http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101690 When I read it, I stepped through it on our z10 and everything worked as described. From what I remember, you need to edit the /etc/ssl/openssl.cnf file to add the bits from /usr/share/doc/packages/openssl-ibmca/openssl.cnf.sample thats included in the openssl-ibmca package. Make sure you don't miss step 3 on page 7. That's an easy one to miss. Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Aug 25 Webcast -Linux on System z SLES11 SP1 Performance Report
Mark Post wrote: On 8/23/2010 at 07:09 PM, Pamela Christina in beautiful Endictt NY wrote: The next webcast is scheduled for Wed. Aug 25 with a choice of two times (9am EDT (NY) and 2PM EDT) Topic: Linux on System z SLES11 SP1 Performance Report Speaker: Christian Ehrhardt, IBM Boeblingen Julie, The web site says that links to recordings and PDFs for all LVCs will be posted on http://www.vm.ibm.com/education/lvc/ at a later time. I don't see any, even though I'm signed in with my IBM ID. What am I missing? It's there Mark. You must be using Firefox? Try View->Page Source. It doesn't like line 297: Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Suse SLES 11 / reiserfs / readonly problem
Wouldn't that be a good candidate for LVM snapshots? (Sorry, if that's not germane to the subject...I haven't followed the thread until now.) Leland On Wed, Aug 25, 2010 at 12:03 PM, Christian Paro wrote: > Not quite what I meant. > > I was thinking of situations where the original system would be temporarily > shut down during the cloning or backup operation. In this case, the "owner" > would access the file system read-write, but it'd be safer for the "cloner" > to only have read-only access to those disks. They would not, however, be > accessing these file systems at the same time. > > On Wed, Aug 25, 2010 at 12:34 PM, Edmund R. MacKenty < > ed.macke...@rocketsoftware.com> wrote: > > > On Wednesday, August 25, 2010 12:21:50 pm Mark Post wrote: > > > This would be a very dangerous practice, and one I always tell people > to > > > never use. If a file system is going to be shared between Linux > systems, > > > it needs to be mounted read-only by all systems, including the "owner" > of > > > it. > > > > Thanks Mark! I was writing a similar reply when yours arrived. Having a > > read-write mount to a shared Linux filesystem is just asking for it to be > > corrupted, because of multiple caches being unaware of each other. > > Please do not do that! > >- MacK. > > - > > Edmund R. MacKenty > > Software Architect > > Rocket Software > > 275 Grove Street - Newton, MA 02466-2272 - USA > > Tel: +1.617.614.4321 > > Email: m...@rs.com > > Web: www.rocketsoftware.com > > > > -- > > For LINUX-390 subscribe / signoff / archive access instructions, > > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > > visit > > http://www.marist.edu/htbin/wlvindex?LINUX-390 > > -- > > For more information on Linux on System z, visit > > http://wiki.linuxvm.org/ > > > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > -- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ > -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Suse SLES 11 / reiserfs / readonly problem
Wouldn't that be a good candidate for LVM snapshots? (Sorry, if that's not germane to the subject...I haven't followed the thread until now.) On Wed, Aug 25, 2010 at 12:03 PM, Christian Paro wrote: > Not quite what I meant. > > I was thinking of situations where the original system would be temporarily > shut down during the cloning or backup operation. In this case, the "owner" > would access the file system read-write, but it'd be safer for the "cloner" > to only have read-only access to those disks. They would not, however, be > accessing these file systems at the same time. > > On Wed, Aug 25, 2010 at 12:34 PM, Edmund R. MacKenty < > ed.macke...@rocketsoftware.com> wrote: > > > On Wednesday, August 25, 2010 12:21:50 pm Mark Post wrote: > > > This would be a very dangerous practice, and one I always tell people > to > > > never use. If a file system is going to be shared between Linux > systems, > > > it needs to be mounted read-only by all systems, including the "owner" > of > > > it. > > > > Thanks Mark! I was writing a similar reply when yours arrived. Having a > > read-write mount to a shared Linux filesystem is just asking for it to be > > corrupted, because of multiple caches being unaware of each other. > > Please do not do that! > >- MacK. > > - > > Edmund R. MacKenty > > Software Architect > > Rocket Software > > 275 Grove Street - Newton, MA 02466-2272 - USA > > Tel: +1.617.614.4321 > > Email: m...@rs.com > > Web: www.rocketsoftware.com > > > > -- > > For LINUX-390 subscribe / signoff / archive access instructions, > > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > > visit > > http://www.marist.edu/htbin/wlvindex?LINUX-390 > > -- > > For more information on Linux on System z, visit > > http://wiki.linuxvm.org/ > > > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > -- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ > -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Anyone having problems with SLES10 aaa_base-10-12.58.1?
And then there's all of the extra sourcing of profiles from stuff like /etc/profile.d, /etc/profile.local, .bash_profile, .profile, .bashrc, and probably a heap of other places that I'm sure I don't know about. But, yes, we were satisfied with the default profile chain that has worked the same for at least SLES9 and SLES10. But, this recent version of aaa_base has changed it...well, at least for us it has. The Novell tech hasn't been able to reproduce the problem as yet. I know what the problem is and can easily fix it, but I don't want to have to worry about it everytime I upgrade aaa_base. I could probably throw a workaround in /etc/profile.d I suppose... Leland On Mon, Aug 23, 2010 at 12:13 PM, Richard Troth wrote: > You saying that you had no issues until you upgraded that package? > > I cannot address that package specifically, but I can share tears and > whine with you over the lack of cluefulness about how profiling is > handled. It not just Linux, but it's worse in Linux than other > Unix/POSIX. When Project Athena gave us X Windows, there was some > provision to get it right, but that was lost on the distributors (and > evidently on both the GNome developers and the KDE developers), so the > problem is even worse in a GUI environment than pure shell. > > I guess the summary report would be: I have had so many problems with > the distributed profiling that I always discard the .bashrc and > .bash_profile mandated from /etc/skel and install my own .profile > (usually withOUT shell rc). If they follow the rules, every Bourne > compatible shell will source that when you "log in". (Definition of > "log in" may still vary, and sadly DOES NOT include logging in to most > graphical desktops.) With care (and I don't mean much) you can have > C-Shell variants also source $HOME/.profile and safely return to their > expected behavior. > > I usually set my default shell to /bin/sh in case the environment goes > multi-platform, but that still does not fix the profiling problems. > > -- R; <>< > > > > > > On Mon, Aug 23, 2010 at 10:40, Leland Lucius wrote: > > Specifically, has your default PS1 prompt behavior changed? How about > > the sourcing of your private .bashrc? Do you have your default shell > > set to /bin/sh? > > > > Just curious if anyone else is having issues. > > > > Thanks, > > > > Leland > > > > -- > > For LINUX-390 subscribe / signoff / archive access instructions, > > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > > visit > > http://www.marist.edu/htbin/wlvindex?LINUX-390 > > -- > > For more information on Linux on System z, visit > > http://wiki.linuxvm.org/ > > > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > -- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ > -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Anyone having problems with SLES10 aaa_base-10-12.58.1?
Specifically, has your default PS1 prompt behavior changed? How about the sourcing of your private .bashrc? Do you have your default shell set to /bin/sh? Just curious if anyone else is having issues. Thanks, Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SLES suse_register fails ?
Hi Lionel, I run a local update server and pull the updates down with YUP. We've never had any of our servers register themselves with Novell (not even sure they have firewall access even). I know this doesn't really help you in your current situation, but it might be an option for you in the future. I'm not sure what suse-register requires, but for pulling down the updates to the local update server, I had to hit the Novell "Mirror Credentials" site to get the required username/password: (login required) https://secure-www.novell.com/center/regadmin/jsps/mirrorcreds_app.jsp This'll also tell you the URLs you can use to download the patches, either to your local mirror OR manually via your web browser or wget/curl. Leland On Wed, Aug 11, 2010 at 3:55 PM, Lionel Dyck wrote: > I've a challenge that I'm hoping someone here can assist with. > > I've a server that failed to connect to the Novell center for updates. I > checked the novell center and it hadn't connected for over a year (I was > able to connect 4 months ago to do the SLES 10 sp2 to sp3 upgrade so I > don't know what the last contact date really means). > > Last week I checked YaST Online Updates and it would not connect. I called > the novell customer resolution center who suggested removing the server > from the novell center and then running suse_register again. I did that > with no luck. They then suggested following the guidelines in TID 3303599, > which basically says to delete all of the zmd files related to the > registration. I did that with no luck either. (Note I had another server > with a similar issue and the TID steps resolved things there). > > Has anyone any recommendations to resolve this as I need to connect to do > a YaST Online Update to get the latest kernel update. > > Thanks in Advance > > Lionel > > > Lionel B. Dyck <>< > z/Linux Specialist > IBM Corporation > Global Technology Services - Kaiser Account > Work: 925-926-5332 > E-Mail: ld...@us.ibm.com > AIM: lbdyck | Yahoo IM: lbdyck | GTalk: lbdyck > > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > -- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ > -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Shared root and shutdown
Edmund R. MacKenty wrote: BTW: We ended up doing shared-root a bit differently, because we wanted to have shared filesystems but also wanted / itself to be writable so we could create mount-points for new filesystems as needed. So we made the filesystem containing / writable, and put all of /bin, /boot, /lib, /lib64, /sbin on a read-only filesystem and bind-mounted those directories onto the writable filesystem. This gives us more flexibility to make changes as user needs evolve over time. But it's the same basic idea. Yepper, I gave that a try as well. I'd set up a small 8MB / and did all of the bind mounts as appropriate. I may still go this route, but it does add a tad bit more complexity to the setup. No biggie, just trying to keep it as simple as possible for my initial go round. Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Shared root and shutdown
Richard Troth wrote: There's a bigger picture: avoid open files in /etc altogether (when trying to unmount it). (Your points #2 and #3 in your "nevermind" post also sugggest this.) To that end, while FHS and LSB say that your init scripts should go under /etc/init.d, there's nothing stopping you from making that be a sym-link to /sbin/init.d. (Or any other directory outside of /etc, but there is historical precedent for that one.) YOU MAY NEED to change things like /etc/inittab to point to the "real" location for some things. For example, if you're really running /sbin/init.d/halt instead of /etc/init.d/halt during shutdown, things may go better. I did wind up having to use my "nevermind" method of unmounting the filesystems for another reason. It works pretty well, makes it extremely SLES dependent, but that should be okay for the foreseeable future. I also needed to roll my own killall5 to skip some processes that needed to survive to the final umounts. LVM really has no problem with RO root. What it has a problem with is not being able to write lock files (because the FS where it wants to put its locks is RO). Look in /etc/lvm/lvm.conf and make a suitable change. Yea, I misspoke before. It was /var/lock/lvm that needed to be bind mounted to somewhere else temporarily. Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Shared root and shutdown
Richard Troth wrote: And now I've strayed from Leland's question. Ooopppsss... Was still interesting though. :-) Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Shared root and shutdown
Michael MacIsaac wrote: Leland, For you "shared root crazies" out there, how did you get /etc to unmount ... Or perhaps a better question is "How did you get /etc to *mount*?" As I recall the install programs will not allow /etc to be a mounted file system. This makes some sense as the file system table (fstab) is in /etc/ - so there's a chicken-and-egg problem with /etc being specified as a file system in /etc. I've toyed with a few different ways and have settled on an RO mounted root with stuff like /etc, /var, and friends mounted as separate RW filesystems (well, some are bind mounted to one RW filesystem). Since I boot the RO root, fstab is already where it needs to be and contains only /, proc, sys, etc. (but none of the RW stuff) and "/etc/mtab" is a symlink to /proc/mounts. I have a "boot.sharedroot" script running just before boot.localfs that takes care of mounting things up the way I want them. The only thing (that matters) up to that point that doesn't like a RO root is LVM, but that was easy to resolve by adding INITRD_FEATURES="lvm2" to /etc/sysconfig/kernel. That gets the LVs activated while initrd is active, so it has an RW etc. But, this really wasn't necessary since it would just take a bind mount of /etc/lvm over to something like /dev/lvm just long enough to get the LVs active. I might even still do that to keep everything in the single boot.sharedroot script. The other main way I looked at was to have a very tiny (8MB) RW root filesystem (with nothing but the base directories) and use the "vendor script" capability of mkinitrd to get everything setup before control gets passed to "init", but it required several more bind mounts than the above method and would have been more tedious since we'd have to ensure we re-ran "mkinitrd -V vendor.sh" anytime updates were applied. Leland Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Shared root and shutdown
Nevermindnothing that a few double Sliders couldn't fix. :-) I was just being overly anal. If I'd just looked at the shutdown I'd have seen that boot.localfs kindly remounts the filesystem as readonly when it can't unmount it. Spits out a warning, but I can live with it. In case anyone wants to be anal about it: 1) In /etc/sysconfig/shutdown, set: HALT_POWERDOWN_INSERT="exit" 2) Create a script somewhere NOT in one of your mounted rw filessytems that unmounts any filesystems that could not be unmounted because they were in use by the rc scripts. 3) Run that script from inittab during runlevels 0 and 6 after the normal "rc" scripts. Leland Leland Lucius wrote: For you "shared root crazies" out there, how did you get /etc to unmount during shutdown? (on SLES10) I've been tinkering around with this and everything works well except that it won't unmount /etc during shutdown since it's in use by the "rc" script(s) when boot.localfs runs. And since /etc is a read/write mount, I'd rather not pull the rug out from under it. Well, I'm actually fibbing just a little since I did find a way to do it cleanly, but it's not pretty. So I was hoping to either find out I was doing something wrong or if it's just the way it is. Thanks, Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Shared root and shutdown
For you "shared root crazies" out there, how did you get /etc to unmount during shutdown? (on SLES10) I've been tinkering around with this and everything works well except that it won't unmount /etc during shutdown since it's in use by the "rc" script(s) when boot.localfs runs. And since /etc is a read/write mount, I'd rather not pull the rug out from under it. Well, I'm actually fibbing just a little since I did find a way to do it cleanly, but it's not pretty. So I was hoping to either find out I was doing something wrong or if it's just the way it is. Thanks, Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Error using zypper
Mark Post wrote: On 5/19/2010 at 11:48 AM, Leland Lucius wrote: I didn't realize there were packages included on the SLES10 media there weren't supported. I always thought that if it was included in the distro then we could use it without worry. The package itself is supported. It's direct use by a sysadmin is not. On SLES10, zypper was intended only to be used by other parts of the update system. That's why there's little to no documentation on how to use it. (We won't talk about just how much(?) documentation there is on how to use rug.) Think in terms of IBM's undocumented opcodes, control blocks, etc. Ouch...I wonder how many other packages we're using that we're not supposed to be. Is there a list of these "grey" packages? Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Error using zypper
Mark Post wrote: On 5/19/2010 at 11:28 AM, Leland Lucius wrote: Why not? We've used zypper on SLES10 ever since we upgraded to SLES10 some 2 years ago. It's a little slow, but it works nicely and doesn't require zmd. Because in SLES10 it's not a supported tool for use by system administrators, whereas rug and YaST are. YasT also does not require zmd. I didn't realize there were packages included on the SLES10 media there weren't supported. I always thought that if it was included in the distro then we could use it without worry. Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Error using zypper
Thang Pham wrote: Hi, I am trying to add an installation source using zypper: zypper sa file:/install/sles11/s390x/1 It fails with the following error: # zypper sa file:/install/sles11/s390x/1 Try adding a "/" to the end of the path. Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Error using zypper
Mark Post wrote: On 5/18/2010 at 03:53 PM, Thang Pham wrote: I am on SLES 10.3 and zypper does not have the addrepo option. Then you shouldn't be using the zypper command at all. Use "rug sa" instead. Why not? We've used zypper on SLES10 ever since we upgraded to SLES10 some 2 years ago. It's a little slow, but it works nicely and doesn't require zmd. Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: yast procedure for going from SLE-10-s390x-SP2 to SLE-10-s390x-SP3
I used yup-232-2.2.noarch.rpm and made a slight change to the script to get
it to pull the -Updates and -Online. It still had issues pulling the -Pool
stuff and since I only needed to do that once, I just pulled -Pool manually.
Here's the diff but I'm guessing it'll wrap, so basically just look for SP2
in /usr/sbin/yup and repeat the first "elif" block.
--- yup 2010-03-01 14:09:06.0 -0600
+++ /usr/sbin/yup 2010-01-20 15:36:53.0 -0600
@@ -339,6 +339,9 @@
elif [ "$SVN" = "SP2" ]; then
SVNSUFFIX="-SP2"
SUBCHANNELS=$YUP_SP_SUBCHANS
+ elif [ "$SVN" = "SP3" ]; then
+ SVNSUFFIX="-SP3"
+ SUBCHANNELS=$YUP_SP_SUBCHANS
fi
for CHLSUFFIX in $SUBCHANNELS; do
if [ "${SLE}." = "SLES10."
]; then
Leland
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: WWBD - One large VM LPAR or multiple smaller ones?
David Stuart wrote: Alan, CMS is like a porcupine in a balloon factory What imagery. Thanks for the laugh, first thing in the morning. The porcupine in the balloon factory isn't a problem until the balloon's are shipped and the customer tries to use them. :-) Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
WWBD - One large VM LPAR or multiple smaller ones?
I know the answer will be "It depends.", but I figure I might as well ask anyway. We're in the process of migrating Websphere workloads from AIX to zLinux and figure we will need to add additional IFLs and memory. But, rather than simply boosting the existing VM LPARs, we're wondering if it wouldn't be better to split them up into a few smaller LPARs instead. When I say large, I'm talking maybe a 300GB/15 IFL footprint for one of our VM LPARs. We'd split that into maybe 2 150GB or 3 100GB LPARs. We would also gain more operational freedom if we split the workloads correctly, so it's looking pretty good to us. But, we don't want to do it if there will be too much additional overhead in terms of resource usage. Thanks much, Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: When will CMMA be removed from the kernel?
Barton Robinson wrote: So you should probably measure the two before deciding on which one you want to keep. CMM-1 has very positive results, cmma not so positive. At the risk of bringing on the wrath of the performance gods, I just have to say that I'm not really interested in measuring whether CMMA is better then CMM-1. If the folks at IBM think that CMMA was worthwhile enough to implement, then I'll drink their Kool-Aid and be happy with it. Especially since CMMA is so much easier to manage...just turn the blasted thing on. And it just makes sense for the two OSes to "actively" communicate page states rather than the not-so-dynamic method of CMM-1. Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: When will CMMA be removed from the kernel?
Mark Post wrote: On 9/22/2009 at 11:35 PM, Leland Lucius wrote: Is it being removed entirely or will distros be providing it? First, let's distinguish between CMM-1 and CMM-2/CMMA. It is the latter that is being dropped by IBM. It will remain in the distribution versions in which it currently resides, as long as they are supported (I believe). Based on the comments from Shawn Wells, that means SLES only. So, SLES10 will be the last we will see of CMM-2/CMMA? Pity. I'd rather have seen CMM-1 buy the farm. Oh well. I guess we have to live with the upstream idiots!!! (Just my, not necessarily rational, opinion. Too bad if they don't like it.) Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
When will CMMA be removed from the kernel?
Is it being removed entirely or will distros be providing it? Leland -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
