Discuss May 2016

discuss@lists.centos.org

155 participants
149 discussions

I want to connect to a l2tp server from centos.
by Eliezer Croitoru 22 Mar '17

22 Mar '17

I have a server currently connecting to a pptp remote server. This server(lns\lac) has the option for pptp connections and l2tp connections. The l2tp connections are not using ipsec encryption at all. I have seen couple guides\tutorials on the internet: - https://raymii.org/s/tutorials/IPSEC_L2TP_vpn_on_CentOS_-_Red_Hat_Enterpris… - https://wiki.archlinux.org/index.php/L2TP/IPsec_VPN_client_setup But all the guides that I have found are using ipsec with "secret". On ubuntu there is a gui applet that helps setting these kind of connections up but I am working with a CentOS server and not Ubuntu desktop. If someone used l2tp the same way I want to use on CentOS 7 please give me some advice. If you have a guide which might help me I will be more then happy to see this one. Thanks, Eliezer

4 8

CentOS-7-x86_64-GenericCloud.raw very unusual format
by Aliaksei Sheshka 15 Oct '16

15 Oct '16

Hello! Is anyone aware why CentOS-7-x86_64-GenericCloud.raw has such unusual format ? root@test-srv:~# wget http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.raw --2016-03-21 13:16:31-- http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.raw Resolving cloud.centos.org (cloud.centos.org)... 162.252.80.138 Connecting to cloud.centos.org (cloud.centos.org)|162.252.80.138|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 374668382 (357M) [application/x-gzip] Saving to: 'CentOS-7-x86_64-GenericCloud.raw' CentOS-7-x86_64-GenericCloud.raw 100%[=========================================================================>] 357.31M 12.9MB/s in 30s 2016-03-21 13:17:03 (11.9 MB/s) - 'CentOS-7-x86_64-GenericCloud.raw' saved [374668382/374668382] Download reports [application/x-gzip] for raw file And indeed root@test-srv:~# file CentOS-7-x86_64-GenericCloud.raw CentOS-7-x86_64-GenericCloud.raw: gzip compressed data, last modified: Sat Feb 27 02:14:37 2016, from Unix Ok, lets uncompress: root@test-srv:~# zcat -d CentOS-7-x86_64-GenericCloud.raw > CentOS-7-x86_64-GenericCloud.a And check again root@test-srv:~# file CentOS-7-x86_64-GenericCloud.a CentOS-7-x86_64-GenericCloud.a: POSIX tar archive (GNU) Ok. it's a tar archive. root@test-srv:~# tar -xf CentOS-7-x86_64-GenericCloud.a -v CentOS-7-x86_64-GenericCloud-1602.raw Now it's CentOS-7-x86_64-GenericCloud-1602.raw file which is indeed raw What is the point to pack single raw file into the tar.gz and to name it raw ? Or it's just a mistake ? Thanks!

8 16

[OT] disk utility showing message "the partition is misaligned by"
by g 26 Aug '16

26 Aug '16

greetings. centos 6.7 [current] 'disk utility' has started showing message; WARNING: The partition is misaligned by 2560 bytes. This may result in very poor performance. Repartitioning is suggested. for sdc5 - /home partition. /dev/sdc5 302243312 156348604 130534968 55% /home /dev/sdc7 80854912 57088 76683952 1% /hdd/c/07 other than time involved to backup sdc5, repartition is not a problem. to my thinking, but not recalling, with fsck; fsck -rN -t ext4 /dev/sdc5 * to check repairs fsck -r -t ext4 /dev/sdc5 * to repair gparted was used to partition drive. is pmagic live a better choice, or should i return fdisk because; =+=+= $ sudo fdisk -l /dev/sdc [sudo] password for geo: Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk identifier: 0x0009ede7 Device Boot Start End Blocks Id System /dev/sdc1 * 1 103 819200 83 Linux Partition 1 does not end on cylinder boundary. /dev/sdc2 103 230 1024000 82 Linux swap / Solaris Partition 2 does not end on cylinder boundary. /dev/sdc3 230 2107 15073280 83 Linux /dev/sdc4 2107 121602 959844352 5 Extended /dev/sdc5 2108 42019 320587970+ 83 Linux Partition 5 does not start on physical sector boundary. =+=+= suggestions for correcting above boundaries also appreciated. help needed and greatly appreciated. -- peace out. If Bill Gates got a dime for every time Windows crashes... ...oh, wait. He does. THAT explains it! -+- in a world with out fences, who needs gates. CentOS GNU/Linux 6.7 tc,hago. g .

7 9

Broadcom BCM4313 support broken with kernel 2.6.32-573.7.1.el6.centos.plus.x86_64?
by wwp 24 Aug '16

24 Aug '16

Hello, I noticed that with latest kernel (2.6.32-573.7.1.el6.centos.plus.x86_64), my laptop's Wifi doesn't work, whereas with previous kernel (2.6.32-504.30.3.el6.centos.plus.x86_64), it works fine. Is this a known issue or did I miss something new? BTW, `lspci` says: Broadcom Corporation BCM4313 802.11bgn Wireless Network Adapter (rev 01) Regards, -- wwp

2 2

Any further developments on CentOS7 for i386?
by Kay Schenk 22 Jun '16

22 Jun '16

Well I haven't tested out the CentOS 7 for i386 yet as sent in the message of 06/02-- https://lists.centos.org/pipermail/centos-devel/2015-June/013426.html Nor have I seen any additional information. So how is this going? I'm almost ready to jump in as I would really prefer to be on Gnome 3. -- -------------------------------------------- MzK “The journey of a thousand miles begins with a single step.” --Lao Tzu

3 7

Slow RAID Check/high %iowait during check after updgrade from CentOS 6.5 -> CentOS 7.2
by Kelly Lesperance 14 Jun '16

14 Jun '16

I’ve posted this on the forums at https://www.centos.org/forums/viewtopic.php?f=47&t=57926&p=244614#p244614 - posting to the list in the hopes of getting more eyeballs on it. We have a cluster of 23 HP DL380p Gen8 hosts running Kafka. Basic specs: 2x E5-2650 128 GB RAM 12 x 4 TB 7200 RPM SATA drives connected to an HP H220 HBA Dual port 10 GB NIC The drives are configured as one large RAID-10 volume with mdadm, filesystem is XFS. The OS is not installed on the drive - we PXE boot a CentOS image we've built with minimal packages installed, and do the OS configuration via puppet. Originally, the hosts were running CentOS 6.5, with Kafka 0.8.1, without issue. We recently upgraded to CentOS 7.2 and Kafka 0.9, and that's when the trouble started. What we're seeing is that when the weekly raid-check script executes, performance nose dives, and I/O wait skyrockets. The raid check starts out fairly fast (20000K/sec - the limit that's been set), but then quickly drops down to about 4000K/Sec. dev.raid.speed sysctls are at the defaults: dev.raid.speed_limit_max = 200000 dev.raid.speed_limit_min = 1000 Here's 10 seconds of iostat output, which illustrates the issue: [root@r1k1log] # iostat 1 10 Linux 3.10.0-327.18.2.el7.x86_64 (r1k1) 05/24/16 _x86_64_ (32 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 8.80 0.06 1.89 14.79 0.00 74.46 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn sda 52.59 2033.16 10682.78 1210398902 6359779847 sdb 52.46 2031.25 10682.78 1209265338 6359779847 sdc 52.40 2033.21 10683.53 1210433924 6360229587 sdd 52.22 2031.16 10683.53 1209212513 6360229587 sdf 52.20 2031.17 10682.06 1209216701 6359354331 sdg 52.62 2033.22 10684.17 1210437080 6360606756 sdh 52.57 2031.21 10684.17 1209242746 6360606756 sde 51.67 2033.17 10682.06 1210408935 6359354331 sdj 51.90 2031.13 10684.48 1209191501 6360795559 sdi 52.47 2033.16 10684.48 1210399262 6360795559 sdk 52.09 2033.15 10684.36 1210396915 6360724971 sdl 51.95 2031.20 10684.36 1209235241 6360724971 md127 138.20 74.49 64101.35 44348810 38161468777 avg-cpu: %user %nice %system %iowait %steal %idle 8.57 0.09 1.33 26.19 0.00 63.81 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn sda 28.00 512.00 8416.00 512 8416 sdb 28.00 512.00 8416.00 512 8416 sdc 25.00 448.00 8876.00 448 8876 sdd 24.00 448.00 8364.00 448 8364 sdf 23.00 448.00 8192.00 448 8192 sdg 24.00 512.00 7680.00 512 7680 sdh 24.00 512.00 7680.00 512 7680 sde 23.00 448.00 8192.00 448 8192 sdj 23.00 512.00 7680.00 512 7680 sdi 23.00 512.00 7680.00 512 7680 sdk 23.00 512.00 7680.00 512 7680 sdl 23.00 512.00 7680.00 512 7680 md127 101.00 0.00 48012.00 0 48012 avg-cpu: %user %nice %system %iowait %steal %idle 6.50 0.00 1.04 24.27 0.00 68.19 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn sda 26.00 512.00 9216.00 512 9216 sdb 26.00 512.00 9216.00 512 9216 sdc 27.00 576.00 9204.00 576 9204 sdd 28.00 576.00 9716.00 576 9716 sdf 31.00 768.00 9728.00 768 9728 sdg 28.00 512.00 10240.00 512 10240 sdh 28.00 512.00 10240.00 512 10240 sde 31.00 768.00 9728.00 768 9728 sdj 28.00 512.00 9744.00 512 9744 sdi 28.00 512.00 9744.00 512 9744 sdk 27.00 512.00 9728.00 512 9728 sdl 27.00 512.00 9728.00 512 9728 md127 114.00 0.00 57860.00 0 57860 avg-cpu: %user %nice %system %iowait %steal %idle 9.24 0.00 1.32 20.02 0.00 69.42 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn sda 50.00 512.00 20408.00 512 20408 sdb 50.00 512.00 20408.00 512 20408 sdc 48.00 512.00 19984.00 512 19984 sdd 48.00 512.00 19984.00 512 19984 sdf 50.00 704.00 19968.00 704 19968 sdg 47.00 512.00 19968.00 512 19968 sdh 47.00 512.00 19968.00 512 19968 sde 50.00 704.00 19968.00 704 19968 sdj 48.00 512.00 19972.00 512 19972 sdi 48.00 512.00 19972.00 512 19972 sdk 48.00 512.00 19980.00 512 19980 sdl 48.00 512.00 19980.00 512 19980 md127 241.00 0.00 120280.00 0 120280 avg-cpu: %user %nice %system %iowait %steal %idle 7.98 0.00 0.98 18.42 0.00 72.63 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn sda 39.00 640.00 14076.00 640 14076 sdb 39.00 640.00 14076.00 640 14076 sdc 36.00 512.00 14324.00 512 14324 sdd 36.00 512.00 14324.00 512 14324 sdf 36.00 576.00 13824.00 576 13824 sdg 43.00 1024.00 13824.00 1024 13824 sdh 43.00 1024.00 13824.00 1024 13824 sde 36.00 576.00 13824.00 576 13824 sdj 44.00 1024.00 14104.00 1024 14104 sdi 44.00 1024.00 14104.00 1024 14104 sdk 45.00 1024.00 14336.00 1024 14336 sdl 45.00 1024.00 14336.00 1024 14336 md127 168.00 0.00 84488.00 0 84488 avg-cpu: %user %nice %system %iowait %steal %idle 7.39 0.00 1.01 19.48 0.00 72.13 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn sda 22.00 896.00 4096.00 896 4096 sdb 22.00 896.00 4096.00 896 4096 sdc 19.00 640.00 4344.00 640 4344 sdd 19.00 640.00 4344.00 640 4344 sdf 18.00 512.00 5120.00 512 5120 sdg 18.00 512.00 5120.00 512 5120 sdh 18.00 512.00 5120.00 512 5120 sde 18.00 512.00 5120.00 512 5120 sdj 18.00 512.00 4624.00 512 4624 sdi 18.00 512.00 4624.00 512 4624 sdk 18.00 512.00 4608.00 512 4608 sdl 18.00 512.00 4608.00 512 4608 md127 57.00 0.00 27912.00 0 27912 avg-cpu: %user %nice %system %iowait %steal %idle 10.92 0.00 1.58 21.84 0.00 65.66 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn sda 23.00 576.00 7168.00 576 7168 sdb 23.00 576.00 7168.00 576 7168 sdc 29.00 896.00 7680.00 896 7680 sdd 29.00 896.00 7680.00 896 7680 sdf 31.00 1024.00 7680.00 1024 7680 sdg 31.00 1024.00 7680.00 1024 7680 sdh 31.00 1024.00 7680.00 1024 7680 sde 31.00 1024.00 7680.00 1024 7680 sdj 30.00 1024.00 7168.00 1024 7168 sdi 31.00 1024.00 7680.00 1024 7680 sdk 32.00 1024.00 7424.00 1024 7424 sdl 32.00 1024.00 7424.00 1024 7424 md127 89.00 0.00 44800.00 0 44800 avg-cpu: %user %nice %system %iowait %steal %idle 13.89 0.03 2.63 21.54 0.00 61.91 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn sda 30.00 960.00 7680.00 960 7680 sdb 30.00 960.00 7680.00 960 7680 sdc 32.00 1024.00 7684.00 1024 7684 sdd 32.00 1024.00 7684.00 1024 7684 sdf 31.00 1024.00 7680.00 1024 7680 sdg 31.00 1024.00 7680.00 1024 7680 sdh 31.00 1024.00 7680.00 1024 7680 sde 31.00 1024.00 7680.00 1024 7680 sdj 32.00 1024.00 8192.00 1024 8192 sdi 31.00 1024.00 7680.00 1024 7680 sdk 26.00 704.00 7680.00 704 7680 sdl 26.00 704.00 7680.00 704 7680 md127 92.00 0.00 46596.00 0 46596 avg-cpu: %user %nice %system %iowait %steal %idle 14.24 0.00 2.22 19.89 0.00 63.65 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn sda 33.00 1024.00 7244.00 1024 7244 sdb 33.00 1024.00 7244.00 1024 7244 sdc 31.00 1024.00 7668.00 1024 7668 sdd 31.00 1024.00 7668.00 1024 7668 sdf 31.00 1024.00 7680.00 1024 7680 sdg 26.00 768.00 6672.00 768 6672 sdh 26.00 768.00 6672.00 768 6672 sde 31.00 1024.00 7680.00 1024 7680 sdj 21.00 512.00 6656.00 512 6656 sdi 21.00 512.00 6656.00 512 6656 sdk 27.00 832.00 7168.00 832 7168 sdl 27.00 832.00 7168.00 832 7168 md127 88.00 0.00 43088.00 0 43088 avg-cpu: %user %nice %system %iowait %steal %idle 8.02 0.13 1.42 23.90 0.00 66.53 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn sda 30.00 1024.00 7168.00 1024 7168 sdb 30.00 1024.00 7168.00 1024 7168 sdc 29.00 960.00 7168.00 960 7168 sdd 29.00 960.00 7168.00 960 7168 sdf 23.00 512.00 7668.00 512 7668 sdg 28.00 768.00 7680.00 768 7680 sdh 28.00 768.00 7680.00 768 7680 sde 23.00 512.00 7668.00 512 7668 sdj 30.00 1024.00 6672.00 1024 6672 sdi 30.00 1024.00 6672.00 1024 6672 sdk 30.00 1024.00 7168.00 1024 7168 sdl 30.00 1024.00 7168.00 1024 7168 md127 87.00 0.00 43524.00 0 43524 Details of the array: [root@r1k1] # cat /proc/mdstat Personalities : [raid10] md127 : active raid10 sdf[5] sdi[8] sdh[7] sdk[10] sdb[1] sdj[9] sdc[2] sdd[3] sdl[11] sde[13] sdg[12] sda[0] 23441323008 blocks super 1.2 512K chunks 2 near-copies [12/12] [UUUUUUUUUUUU] [======>..............] check = 30.8% (7237496960/23441323008) finish=62944.5min speed=4290K/sec unused devices: <none> [root@r1k1] # mdadm --detail /dev/md127 /dev/md127: Version : 1.2 Creation Time : Thu Sep 18 09:57:57 2014 Raid Level : raid10 Array Size : 23441323008 (22355.39 GiB 24003.91 GB) Used Dev Size : 3906887168 (3725.90 GiB 4000.65 GB) Raid Devices : 12 Total Devices : 12 Persistence : Superblock is persistent Update Time : Tue May 24 15:32:56 2016 State : active, checking Active Devices : 12 Working Devices : 12 Failed Devices : 0 Spare Devices : 0 Layout : near=2 Chunk Size : 512K Check Status : 30% complete Name : localhost:kafka UUID : b6b98e3e:65ee06c3:3599d781:98908041 Events : 2459193 Number Major Minor RaidDevice State 0 8 0 0 active sync set-A /dev/sda 1 8 16 1 active sync set-B /dev/sdb 2 8 32 2 active sync set-A /dev/sdc 3 8 48 3 active sync set-B /dev/sdd 13 8 64 4 active sync set-A /dev/sde 5 8 80 5 active sync set-B /dev/sdf 12 8 96 6 active sync set-A /dev/sdg 7 8 112 7 active sync set-B /dev/sdh 8 8 128 8 active sync set-A /dev/sdi 9 8 144 9 active sync set-B /dev/sdj 10 8 160 10 active sync set-A /dev/sdk 11 8 176 11 active sync set-B /dev/sdl We've tried changing the I/O scheduler, queue_depth, queue_type, read-ahead, etc, but nothing has helped. We've also upgraded all of the firmware, and installed HP's mpt2sas driver. We have 4 other Kafka clusters, however they're HP DL180 G6 servers. We completed the same CentOS 6.5 -> 7.2/Kafka 0.8 -> 0.9 upgrade on those clusters, and there has been no impact to their performance. We've been banging our heads against the wall for a few weeks now, really hoping someone from the community can point us in the right direction. Thanks, Kelly Lesperance

6 26

Re: [CentOS] Fwd: EPEL-ANNOUNCE Re: Upcoming OwnCloud changes in EPEL
by James Hogarth 09 Jun '16

09 Jun '16

On 22 Apr 2016 18:11, "James Hogarth" <james.hogarth(a)gmail.com> wrote: > > In the event that there are CentOS users making use of the EPEL owncloud packages, but not following the EPEL mailing lists, please read the mail below with regards to your installations. > > Thanks > > James > > ---------- Forwarded message ---------- > From: "James Hogarth" <james.hogarth(a)gmail.com> > Date: 22 Apr 2016 16:21 > Subject: EPEL-ANNOUNCE Re: Upcoming OwnCloud changes in EPEL > To: "EPEL Development List" <epel-devel(a)lists.fedoraproject.org> > Cc: <epel-announce(a)lists.fedoraproject.org> > > > > > > > On 5 April 2016 at 09:22, James Hogarth <james.hogarth(a)gmail.com> wrote: > >> > >> Hi all, > >> > >> Following on the process of bringing OwnCloud up to date in Fedora we're turning our attention to the EPEL users. > >> > >> Unfortunately EL6's use of php53 means we cannot update any further there given the minimum requirement of php54. > >> > >> As such the maintenance update of 7.0.13 that is in epel-testing now for EPEL6 will be the final one there to be followed by the retiring of the package. > >> > >> If you wish to update from that please either migrate to an EL7 base system or switch to the OwnCloud upstream packages which make use of SCL to satisfy the php54+ requirement. > >> > >> On the EPEL7 side of things 8.1.6 is due to hit testing very shortly. This is a mandatory update as a precursor to the 8.2.3 update in due course. Once this reaches live please ensure that updates are carried out and your OwnCloud installation is fully tested prior to the 8.2.3 update. > >> > >> This is due to a requirement from upstream that updates follow the path 8.0 -> 8.1 -> 8.2 -> 9.0. > >> > >> Related to this when updating the EL6 install from the 7.0 version to an EL7 or upstream SCL version please do make sure you follow the upgrade chain correctly - it is not possible to skip a step. > >> > >> Once the 8.2 goal is reached a discussion will be had then for EPEL as to whether to provide owncloud82 and owncloud90 packages or to just stay on the current major update - but that discussion is some time away as of yet. > >> > >> The reason for picking owncloud82 as the possible base for this is that this is the first version that has no php libraries bundled so will be the easiest to provide the long term maintained base from in a clean fashion complying to guidelines as closely as possible. > >> > >> Kind regards, > >> > >> James > >> > >> > > > > Following on from the previous message EPEL6 has it's final update with the EOL message. Please arrange to move to the upstream SCL packages or to migrate to EL7 if you are using owncloud on EPEL6 - be aware when you do migrate off of this that it is important to follow the chain through 8.0->8.1->8.2 checking your installation at each step. > > > > EPEL7 has had some time in testing and received a positive test so the 8.1.6 update there is being pushed today. > > > > When that has gone stable an 8.2.3 update will be pushed to epel-testing. Please ensure that your installation is updated to 8.1.6 and fully tested before applying the 8.2.3 update. > > For any OwnCloud users on CentOS who utilise the EPEL packages please be aware of important changes this week: The EPEL6 package has now been retired as end of life. If using the EPEL6 packaging of OwnCloud please ensure you migrate to a supported version as discussed above. On the EPEL7 side of things 8.2.4 has just been submitted to stable. Please ensure that the previous 8.1.6 update has been applied and fully tested before carrying out the 8.2.4 update. For those willing to do some early preliminary testing of 9.0.2 it has been uploaded to my Fedora people space, along with its dependencies.

4 7

CenOS 6.8 and libGL failures
by isdtor 06 Jun '16

06 Jun '16

Ever since I upgraded to CentOS 6.8, some software has stopped working alogether. This is related to OpenGL/mesa and can be demonstrated with glxgears: $ glxgears libGL error: No matching fbConfigs or visuals found libGL error: failed to load driver: swrast X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 154 (GLX) Minor opcode of failed request: 3 (X_GLXCreateContext) Value in failed request: 0x0 Serial number of failed request: 33 Current serial number in output stream: 35 $ This appears to be a common problem, but I found no solutions that apply here since I believe everything is installed and set up correctly. It all worked with CentOS 6.x, x<8. https://www.centos.org/forums/viewtopic.php?t=56273 https://ask.fedoraproject.org/en/question/38116/issues-with-libgl-on-fedora…

7 12

Console screen changed on updating from CentOS 6.7 to CentOS 6.8?
by Walter H. 31 May '16

31 May '16

Hello, I have several CentOS 6 VMs, I have updated the first one successfully, but there is one thing I miss or I don't like; How do I get the standard console with 80x25 back? Hello, this is /boot/grub/grub.conf default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title CentOS (2.6.32-642.el6.x86_64) root (hd0,0) kernel /vmlinuz-2.6.32-642.el6.x86_64 ro root=UUID=a27dc9a0-ea3a-497d-a9c3-80c7bbba31fa rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_NO_DM rd_NO_LVM KEYBOARDTYPE=pc KEYTABLE=de config_NO_HZ vga=0x0300 initrd /initramfs-2.6.32-642.el6.x86_64.img I've added 'vga=0x0300', but this results in 100x37? Thanks for Help, Walter

2 1

NFS problem: getattr ERROR: Request couldn't be completed in time
by Matthias Leopold 31 May '16

31 May '16

i posted this also to linux-nfs, maybe this is a more appropriate place as it's clearly a "user" problem ### hi, i'm trying to mount a NFS 4 share with "sec=sys" from a NetApp FAS3250 on a CentOS KVM guest. this doesn't work, the mount doesn't complete and hangs. mount command is: /bin/mount -v -t nfs -s -o vers=4.1,sec=sys 10.110.96.90:/home /home/cir what i'm seeing in tcpdump is: 08:36:48.875019 IP 10.110.96.112.2456702824 > 10.110.96.90.2049: 212 getattr fh 0,1/53 08:36:48.875355 IP 10.110.96.90.2049 > 10.110.96.112.2456702824: reply ok 96 getattr ERROR: Request couldn't be completed in time server: 10.110.96.90 client: 10.110.96.112 status of nfs services: nfslock: running rpcbind: running rpcidmapd: stopped this happens with a centos 6 _and_ a centos 7 client (both KVM guests). NFS 3 mount of the share doesn't work either. other kvm guests (centos 6) on the same physical host can mount the share with no problem. the netapp admin tells me there's "no problem" on his side. iptables is disabled of course. ### what could be the problem on my (client) side? could this be a kvm problem? kvm host is centos 6. network mode is "bridge". network driver is "virtio". thx for any advice matthias

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss May 2016