Discuss

discuss@lists.centos.org

2 participants
34758 discussions

CentOS 7 and sound
by Jerry Geis 16 May '17

16 May '17

Hello, I have a need to get CentOS 7 sound working on a console only machine. X is not running. Currently when I try aplay: aplay /usr/share/sounds/alsa/Front_Center.wav ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection refused aplay: main:786: audio open error: Connection refused aplay -l **** List of PLAYBACK Hardware Devices **** card 1: PCH [HDA Intel PCH], device 0: ALC283 Analog [ALC283 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 So sound is present - I presume pulseaudio is not running as X is not running, Can I run audio without X ? Next steps ? running in an ALSA mode is fine with me - but how? Thanks, Jerry

2 2

CentOS-announce Digest, Vol 147, Issue 3
by centos-announce-request＠centos.org 16 May '17

16 May '17

Send CentOS-announce mailing list submissions to centos-announce(a)centos.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request(a)centos.org You can reach the person managing the list at centos-announce-owner(a)centos.org When replying, please edit your Subject line so it is more specific than "Re: Contents of CentOS-announce digest..." Today's Topics: 1. CESA-2017:1208 Important CentOS 6 jasper Security Update (Johnny Hughes) 2. CESA-2017:1230 Important CentOS 6 ghostscript Security Update (Johnny Hughes) 3. CESA-2017:1230 Important CentOS 7 ghostscript Security Update (Johnny Hughes) 4. CESA-2017:1208 Important CentOS 7 jasper Security Update (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Mon, 15 May 2017 15:59:23 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CESA-2017:1208 Important CentOS 6 jasper Security Update Message-ID: <20170515155923.GA7088(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2017:1208 Important Upstream details at : https://rhn.redhat.com/errata/RHSA-2017-1208.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 065e0d1bf12c76b8c069e195cc766f413513de631fc2068102c6274bf32a5331 jasper-1.900.1-21.el6_9.i686.rpm fb061499b5f77715cc8edcb8be8bb9e7be45a5471eafcec4f2b108a8a66a6caf jasper-devel-1.900.1-21.el6_9.i686.rpm 2e159a9085ea69dc5494e61caa75a2baad3b313d4c9aaa28d210019d39e1dcc1 jasper-libs-1.900.1-21.el6_9.i686.rpm 6bff2a512a3a02648e7a7e576430def2da83ce3b9e04d9d4645d272028bf74b5 jasper-utils-1.900.1-21.el6_9.i686.rpm x86_64: f2796377490accb35ffc0e76528f712659d30add0842887ce504b8d6645fd220 jasper-1.900.1-21.el6_9.x86_64.rpm fb061499b5f77715cc8edcb8be8bb9e7be45a5471eafcec4f2b108a8a66a6caf jasper-devel-1.900.1-21.el6_9.i686.rpm c5df9adf35d20e7a849fbf7e377cb0cb8902f01f2bcb94c94e31001c9ca058ab jasper-devel-1.900.1-21.el6_9.x86_64.rpm 2e159a9085ea69dc5494e61caa75a2baad3b313d4c9aaa28d210019d39e1dcc1 jasper-libs-1.900.1-21.el6_9.i686.rpm 2d59e1277757dc31c39400a7276f08d8afd03504ce8440facce1f84bb4be714f jasper-libs-1.900.1-21.el6_9.x86_64.rpm b61bc76d97dad867740d8774637fc055cc28289fa4f02b3e6dcaf5d8b3ffa76c jasper-utils-1.900.1-21.el6_9.x86_64.rpm Source: ef8e5d52a2bc6ad50c48ef1ebe4490a67bb92df075afacc102b16d8f076fb162 jasper-1.900.1-21.el6_9.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net Twitter: @JohnnyCentOS ------------------------------ Message: 2 Date: Mon, 15 May 2017 15:59:50 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CESA-2017:1230 Important CentOS 6 ghostscript Security Update Message-ID: <20170515155950.GA7362(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2017:1230 Important Upstream details at : https://rhn.redhat.com/errata/RHSA-2017-1230.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 5a76fb12c6c3c14c0961c03320e8d7770ce72c09a21e614a7aed3864d87943e5 ghostscript-8.70-23.el6_9.2.i686.rpm d8ce9d3bc452838b99d3613f71dafdcaefe8ba989f48f7933bf3aa81b7531f5b ghostscript-devel-8.70-23.el6_9.2.i686.rpm dcc02d7bd26fa4b2c1eb3a9c9066780f327325917f6f6a7d1c95f7bca715248e ghostscript-doc-8.70-23.el6_9.2.i686.rpm 1ae49f1a618b81c2fc128ad0eaf399e3c0f11742a5517106ae84260001d48582 ghostscript-gtk-8.70-23.el6_9.2.i686.rpm x86_64: 5a76fb12c6c3c14c0961c03320e8d7770ce72c09a21e614a7aed3864d87943e5 ghostscript-8.70-23.el6_9.2.i686.rpm a5f9fe8c575085bba8c5b5e437e7b82cac128ec023617ca75766fef175b271db ghostscript-8.70-23.el6_9.2.x86_64.rpm d8ce9d3bc452838b99d3613f71dafdcaefe8ba989f48f7933bf3aa81b7531f5b ghostscript-devel-8.70-23.el6_9.2.i686.rpm 9e9079054a2e805d877c3d6f8b039649170ed6721cfd9178fa158ce5e7aaaa7b ghostscript-devel-8.70-23.el6_9.2.x86_64.rpm 9e2d67a2fd1be67f0d0637baea8f71fa077a69803e95d7a5240473edbef4762c ghostscript-doc-8.70-23.el6_9.2.x86_64.rpm 7a9b3f8e415a5d88701631590a58d0dd40f105c13b215739115e6b8b8ed99b4e ghostscript-gtk-8.70-23.el6_9.2.x86_64.rpm Source: 1d42f1dfb0b4fac0fb35bd46b712b429691c0f56d9637d3cc6bb23092681053e ghostscript-8.70-23.el6_9.2.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net Twitter: @JohnnyCentOS ------------------------------ Message: 3 Date: Mon, 15 May 2017 16:45:50 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CESA-2017:1230 Important CentOS 7 ghostscript Security Update Message-ID: <20170515164550.GA11623(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2017:1230 Important Upstream details at : https://rhn.redhat.com/errata/RHSA-2017-1230.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 13b528fab28b799cb7821c627dba7610b800724b72013a457d0b8e307a51dd97 ghostscript-9.07-20.el7_3.5.i686.rpm 98164b6667981379add6d5aaca6e636afc09705f28876bbbd55b39662b1355ae ghostscript-9.07-20.el7_3.5.x86_64.rpm 08099c3554cc5cc69e6b39fb46653b521c78d5f7dd898299bb8509b46c60da5c ghostscript-cups-9.07-20.el7_3.5.x86_64.rpm d8955de29347efbb508e0347f733c5fcc9cea0fcd6c67b38f9cee4753a5af259 ghostscript-devel-9.07-20.el7_3.5.i686.rpm dfc06dd01dfd83596c32838d1299bd7627ff4448638d4965a5b18d374c426ba2 ghostscript-devel-9.07-20.el7_3.5.x86_64.rpm 17930cd40d86834840e4f647512d9d90c7aba63b752910d7cc72594e329c9441 ghostscript-doc-9.07-20.el7_3.5.noarch.rpm 71928ee68a7cfbad0f986b1af5e1d534b37625a2f3b7190841b51a6b9150dfe5 ghostscript-gtk-9.07-20.el7_3.5.x86_64.rpm Source: ba98ea2b439b24ff44f59cb96fef42bdc616f6834aa9b97e7baa6d22194b7960 ghostscript-9.07-20.el7_3.5.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net Twitter: @JohnnyCentOS ------------------------------ Message: 4 Date: Mon, 15 May 2017 16:46:03 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CESA-2017:1208 Important CentOS 7 jasper Security Update Message-ID: <20170515164603.GA11713(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2017:1208 Important Upstream details at : https://rhn.redhat.com/errata/RHSA-2017-1208.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: bf4bec0731557d9200609d59f46d1b66da039a1887828d2d477be9b93675a137 jasper-1.900.1-30.el7_3.x86_64.rpm 094699ed29af7ed7ba8dffbdbcd8cd345339acf9b4da7a519d1bfcea7bef23b0 jasper-devel-1.900.1-30.el7_3.i686.rpm d7c8e089c540c9d1ed779130e51a7637fd242cdea676c545216a2cb49fdd77a9 jasper-devel-1.900.1-30.el7_3.x86_64.rpm 33528f9a2f5eaffc09abaed6f5b81f336815820969406a24dfb7526d587ed54b jasper-libs-1.900.1-30.el7_3.i686.rpm 63ee65983ed5bd9f8d2516f4066d3642cdff69f63b5251a52470094e7a816150 jasper-libs-1.900.1-30.el7_3.x86_64.rpm a7863af6605c1c32063a611a530c0b4da2312b98fb2da4138e4071fa8f6762c2 jasper-utils-1.900.1-30.el7_3.x86_64.rpm Source: 37135c918505fca6233f9ab55193602bb9ed97dcde43a50ed6f2dae3a45038fc jasper-1.900.1-30.el7_3.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net Twitter: @JohnnyCentOS ------------------------------ Subject: Digest Footer _______________________________________________ CentOS-announce mailing list CentOS-announce(a)centos.org https://lists.centos.org/mailman/listinfo/centos-announce ------------------------------ End of CentOS-announce Digest, Vol 147, Issue 3 ***********************************************

1 0

kickstart: dracut-initqueue fails due to unresolvable hostname even though network config looks perfectly ok
by Frank Thommen 16 May '17

16 May '17

Hi, kickstarting fails due to problems with host resolution, even though the network seems to be properly configured through DHCP. eno1 and eno2 are both attached to the network, but only eno1 gets an IP via DHCP. Still `curl` cannot resolve the mirror host and the kickstart host during dracut-initqueue: rdsosreport.txt ------------------------------------------------ [...] [ 14.780428] localhost kernel: IPv6: ADDRCONF(NETDEV_UP): eno1: link is not ready [ 19.977052] localhost kernel: tg3 0000:0b:00.0 eno1: Link is up at 1000 Mbps, full duplex [ 19.977118] localhost kernel: tg3 0000:0b:00.0 eno1: Flow control is off for TX and off for RX [ 19.978880] localhost kernel: tg3 0000:0b:00.0 eno1: EEE is disabled [ 19.980693] localhost kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eno1: link becomes ready [ 19.829468] localhost dracut-initqueue[992]: dhcp: PREINIT eno1 up [ 19.853734] localhost dhclient[1393]: DHCPDISCOVER on eno1 to 255.255.255.255 port 67 interval 6 (xid=0x4df19201) [ 26.030151] localhost dhclient[1393]: DHCPDISCOVER on eno1 to 255.255.255.255 port 67 interval 13 (xid=0x4df19201) [ 26.033472] localhost dhclient[1393]: DHCPREQUEST on eno1 to 255.255.255.255 port 67 (xid=0x4df19201) [ 26.033668] localhost dhclient[1393]: DHCPOFFER from 10.128.196.98 [ 26.038851] localhost dhclient[1393]: DHCPACK from 10.128.196.98 (xid=0x4df19201) [ 26.067534] localhost dracut-initqueue[992]: dhcp: BOND setting eno1 [ 28.082735] localhost dhclient[1393]: bound to 10.128.196.20 -- renewal in 21301 seconds. [ 28.456131] localhost kernel: tg3 0000:0b:00.1: irq 153 for MSI/MSI-X [ 28.456149] localhost kernel: tg3 0000:0b:00.1: irq 154 for MSI/MSI-X [ 28.456165] localhost kernel: tg3 0000:0b:00.1: irq 155 for MSI/MSI-X [ 28.456180] localhost kernel: tg3 0000:0b:00.1: irq 156 for MSI/MSI-X [ 28.456196] localhost kernel: tg3 0000:0b:00.1: irq 157 for MSI/MSI-X [ 28.570450] localhost kernel: IPv6: ADDRCONF(NETDEV_UP): eno2: link is not ready [ 34.024621] localhost kernel: tg3 0000:0b:00.1 eno2: Link is up at 1000 Mbps, full duplex [ 34.026347] localhost kernel: tg3 0000:0b:00.1 eno2: Flow control is off for TX and off for RX [ 34.028069] localhost kernel: tg3 0000:0b:00.1 eno2: EEE is disabled [ 34.029776] localhost kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eno2: link becomes ready [ 33.803606] localhost dracut-initqueue[992]: dhcp: PREINIT eno2 up [ 33.827664] localhost dhclient[1570]: DHCPDISCOVER on eno2 to 255.255.255.255 port 67 interval 7 (xid=0x1e8bdc4b) [ 41.000199] localhost dhclient[1570]: DHCPDISCOVER on eno2 to 255.255.255.255 port 67 interval 15 (xid=0x1e8bdc4b) [ 55.588353] localhost dhclient[1570]: DHCPDISCOVER on eno2 to 255.255.255.255 port 67 interval 18 (xid=0x1e8bdc4b) [ 74.172423] localhost dhclient[1570]: DHCPDISCOVER on eno2 to 255.255.255.255 port 67 interval 12 (xid=0x1e8bdc4b) [ 86.446514] localhost dhclient[1570]: DHCPDISCOVER on eno2 to 255.255.255.255 port 67 interval 9 (xid=0x1e8bdc4b) [ 95.253443] localhost dhclient[1570]: No DHCPOFFERS received. [ 95.253648] localhost dhclient[1570]: No working leases in persistent database - sleeping. [ 95.282175] localhost dracut-initqueue[992]: dhcp: FAIL [ 95.353255] localhost dracut-initqueue[992]: RTNETLINK answers: File exists [ 102.502688] localhost dracut-initqueue[992]: Warning: can't find installer mainimage path in .treeinfo [ 102.517568] localhost dracut-initqueue[992]: % Total % Received % Xferd Average Speed Time Time Time Current [ 102.525942] localhost dracut-initqueue[992]: Dload Upload Total Spent Left Speed [ 102.534277] localhost dracut-initqueue[992]: 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0Warning: Transient problem: timeout Will retry in 1 seconds. 3 retries left. [ 103.527190] localhost dracut-initqueue[992]: 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0Warning: Transient problem: timeout Will retry in 2 seconds. 2 retries left. [ 105.533677] localhost dracut-initqueue[992]: 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0Warning: Transient problem: timeout Will retry in 4 seconds. 1 retries left. [ 109.542329] localhost dracut-initqueue[992]: 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (6) Could not resolve host: our.centos.mirror; Unknown error [ 109.551613] localhost dracut-initqueue[992]: Warning: Downloading 'http://our.centos.mirror/7.2.1511/os/x86_64/LiveOS/squashfs.img' failed! [ 109.615143] localhost dracut-initqueue[992]: % Total % Received % Xferd Average Speed Time Time Time Current [ 109.624698] localhost dracut-initqueue[992]: Dload Upload Total Spent Left Speed [ 109.625018] localhost dracut-initqueue[992]: 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0Warning: Transient problem: timeout Will retry in 1 seconds. 3 retries left. [ 110.624800] localhost dracut-initqueue[992]: 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0Warning: Transient problem: timeout Will retry in 2 seconds. 2 retries left. [ 112.631351] localhost dracut-initqueue[992]: 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0Warning: Transient problem: timeout Will retry in 4 seconds. 1 retries left. [ 116.639935] localhost dracut-initqueue[992]: 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (6) Could not resolve host: our.kickstart.server; Unknown error [ 116.650727] localhost dracut-initqueue[992]: Warning: failed to fetch kickstart from http://our.kickstart.server/ks.cgi [ 242.126427] our.client dracut-initqueue[992]: Warning: dracut-initqueue timeout - starting timeout scripts [... 120 times this warning ...] [ 304.648460] our.client systemd[1]: Received SIGRTMIN+20 from PID 991 (plymouthd). [ 304.650862] our.client dracut-initqueue[992]: Warning: /dev/root does not exist [ 304.659840] our.client systemd[1]: Starting Dracut Emergency Shell... [ 304.684459] our.client systemd[1]: Received SIGRTMIN+21 from PID 991 (plymouthd). [... exiting to emergency shell ...] dropped to the emergency shell, the network config looks absolutely ok: $ ip route default via 10.128.196.97 dev eno1 10.128.196.0/24 dev eno1 proto kernel scope link src 10.128.196.20 169.254.95.0/24 dev enp0s20u1u5 proto kernel scope link src 169.254.95.120 $ `ip a` shows the correct IP address for eno1 and /etc/resolv.conf has all required nameservers. From the emergency shell both hostnames (our.centos.mirror and our.kickstart.server) are perfectly resolvable and accessible. The used PXE config is: LABEL CentOS-7 kernel centos-7.2/vmlinuz append initrd=centos-7.2/initrd.img ip=dhcp inst.repo=http://our.centos.mirror/7.2.1511/os/x86_64 inst.ks.sendmac inst.ks=http://our.kickstart.server/ks.cgi Any idea, why curl cannot resolve the two hostnames or how I can debug this further? Cheers frank

3 5

Re: [CentOS] centos 7- boot doesn't wait for startup script to complete
by KM 15 May '17

15 May '17

Hello,Nothing I have found has solved this issue. the service starts on boot, but the booting process continues. When I log in my startup script is still running and finishes up. that is good at least, but I'd still like to know how to make it wait. Any feedback is appreciated. Thanks in advance.KM From: KM <info4km(a)yahoo.com> To: CentOS mailing list <centos(a)centos.org> Sent: Tuesday, August 9, 2016 3:38 PM Subject: Re: [CentOS] centos 7- boot doesn't wait for startup script to complete FYI - I just found the following post, https://www.centos.org/forums/viewtopic.php?f=47&t=48140 , which I hadn't seen before. It has to do with adding an entry to rc.local. This has worked for me. I know the correct way would be to set up a systemd service file as I started doing. I will consider all of this while we are supporting different flavors of CentOS/RedHat. Any feedback on this let me know, and as always.... thanks in advance.KM From: KM <info4km(a)yahoo.com> To: CentOS mailing list <centos(a)centos.org> Sent: Tuesday, August 9, 2016 3:07 PM Subject: Re: [CentOS] centos 7- boot doesn't wait for startup script to complete I am taking a step back. I have a normal rc script that is installed with our product. All of the CentOS 7 documentation says the script should work on startup/shutdown. But it doesn't. If I run the script manually it works as it should of course. When I restart the server, nothing happens or starts up. So my question is should it be working as it was without me changing anything? The only way I was able to make it work was to add a service file for it in the systemd directory which is what led to my email in the trail attached below. Any way to see what it is doing? I'll try debugging into out application logs again, but haven't had much luck with that.Thanks in advanceKM From: Jonathan Billings <billings(a)negate.org> To: CentOS mailing list <centos(a)centos.org> Sent: Thursday, August 4, 2016 5:10 PM Subject: Re: [CentOS] centos 7- boot doesn't wait for startup script to complete > On Aug 4, 2016, at 14:35, KM <info4km(a)yahoo.com> wrote: > > thank you for the feedback. I tried using Before=systemd-user-sessions.service. At first glance it seems to work, but then the oracle DB shuts down. Note that myservices starts oracle and then does a few things for our application. > When I remove that entry, it goes right to the login as I originally described, but the oracle DB does not shut down. maybe I have the wrong combination of timeout options with this other option or something, although the timeouts seemed to work also. > Just thought I'd throw it out there. In either case, thanks for helping. > I looked online for an explanation of the options for these files, other that the systemd manual page which is hard to use. I really couldn't find one. Any suggestions? > Thanks again.KM Is your service still a oneshot type? If you are starting daemonized services, systemd is probably terminating them. You should use a 'forking' type for services that will keep around processes. > From: Jonathan Billings <billings(a)negate.org> > To: CentOS mailing list <centos(a)centos.org> > Sent: Tuesday, August 2, 2016 9:28 AM > Subject: Re: [CentOS] centos 7- boot doesn't wait for startup script to complete > >> On Tue, Aug 02, 2016 at 12:56:21PM +0000, KM wrote: >> # used to set up the Myservices onstartup >> [Unit] >> Description=Start and stop Myservices >> >> [Service] >> Type=oneshot >> ExecStart=/etc/init.d/Myservices start >> ExecStop=/etc/init.d/Myservices stop >> RemainAfterExit=yes >> >> [Install] >> WantedBy=multi-user.target > > Reformatting so it is readable. > > What you probably want to do is to add something to the [Unit] section > to make the completion of the be a requirement for the user login > service. Something like: > > Before=systemd-user-sessions.service > > You will most likely also need to add a TimeoutStartSec= to your > [Service] section to give it a longer time to run before systemd times > out the service start. > > > -- > Jonathan Billings <billings(a)negate.org> > _______________________________________________ > CentOS mailing list > CentOS(a)centos.org > https://lists.centos.org/mailman/listinfo/centos > > > > _______________________________________________ > CentOS mailing list > CentOS(a)centos.org > https://lists.centos.org/mailman/listinfo/centos _______________________________________________ CentOS mailing list CentOS(a)centos.org https://lists.centos.org/mailman/listinfo/centos

2 1

How can kickstart be (re)started manually from the dracut emergency shell?
by Frank Thommen 15 May '17

15 May '17

Hi, this is a side question to my other thread regarding dracut-initqueue network issues. Once I'm thrown into a dracut emergency shell (PXE booted system): How can I restart the kickstart installation process manually from there? Can I at all? Background is, that I'd like to add some debugging output to some of the dracut scripts and rerun the installation process to see why it fails. Thanks frank

1 0

Supersize io operations (IO block size more than 4KiB) is split in to number of 4KiB blocks
by Son Son 15 May '17

15 May '17

Concern: Supersize io operations (IO block size more than 4KiB) is split in to number of 4KiB blocks Supersize io operations (IO block size more than 4KiB) is split in to number of 4KiB blocks OS: CentOS 7.3 kernel Version: 3.10.0-514.el7.x86_64 Any IO (write) block size more than 4KiB is split in to number of 4KiB blocks on Centos 7.3 ( where I don't see similar issue on 7.2). I have a setup that involves TWO CentOS 7.3 servers. I tried to run 4MB IO on FC LUN(s) on these servers discovered through Emulex LPe 16000 HBAs. Changed ‘options lpfc lpfc_sg_seg_cn =>1024’ and ‘max_secors_kb =>4MB’ params towards attaining supersize IO ( 4MB block size) , however there are no improvements in getting more than 4K block size IO. There was no impact from these changes. Looking for a help to tune the system to attain supersize IO operation (4MB writes) Regards, Sk

1 0

SCSI drives and Centos 7
by Gregory P. Ennis 14 May '17

14 May '17

Everyone, about 4 years ago, I tried to install CentOS 6 on a Supermicro server with SCSI drives using a LSI raid system. I could never figure out or find a way to make the installation disc of Centos 6 identify the SCSI drives. The installation disc for Centos 5 identified the SCSI drives without a problem. I finally gave up on Centos 6 and installed Centos 5 and the system has worked very well for the last 4 years Now that Centos 5 has been retired, I would like to install Centos 7 on this server. Does the install disc for Centos 7 have the same issues with SCSI drives as Centos 6? Has anyone used Centos 7 on SCSI drives, or am I going to need to get an upgrade of the server? The server is working great. Greg Ennis -- Gregory P. Ennis, M.D., M.R.O. Medical Director EcCare Health Centers www.EcCare.com 972-659-1234

7 13

Virt-Manager and full-screen display
by Nicolas Kovacs 13 May '17

13 May '17

Hi, I have CentOS 7 with Qemu/KVM and Libvirt running on a headless HP Proliant Server. Virtual hosts are managed via Virt-Manager installed on a CentOS 7 + KDE client via SSH. Things are running quite nicely for now, I only have a few small minor details to adjust. On my main workstation running Slackware64 14.1, I also have Qemu/KVM and Virt-Manager installed. When I launch a virtual host and switch to full-screen display, the host is a "real" full screen. But when I do the same thing with CentOS, I don't have a real full-screen display. There's still two grey bars left on the upper and lower end of the screen. Any idea how I can get rid of these and have a 100% full-screen display for a KVM host? Cheers, Niki -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Web : http://www.microlinux.fr Mail : info(a)microlinux.fr Tél. : 04 66 63 10 32

2 1

CentOS 6 / Intel CPU support
by Leon Fauster 12 May '17

12 May '17

https://access.redhat.com/support/policy/intel shows mainly Xeon CPUs. What about Intel Core i7-6700 Quad-Core Skylake has the current EL6 variant support for it? Any experience? Feedback would be greatly appreciated. Thanks, LF

5 8

sshd and problems with network vs NetworkManager
by Gianluca Cecchi 12 May '17

12 May '17

Hello, I'm registering a strange new behavior after updating openssh on my CentOS 7.3 server. Firt of all difference of systemd service configuration between new openssh-server-6.6.1p1-35.el7_3.x86_64 and old openssh-server-6.6.1p1-33.el7_3.x86_6 [root@c7service ~]# diff new_sshd.service old_sshd.service 8c8,9 < Type=notify --- > Type=forking > PIDFile=/var/run/sshd.pid 10c11 < ExecStart=/usr/sbin/sshd -D $OPTIONS --- > ExecStart=/usr/sbin/sshd $OPTIONS 15d15 < RestartPreventExitStatus=255 It changed the Type and it was also added the RestartPreventExitStatus directove. The effects I'm noticing are: 1) If using NetworkManager and no ListenAddress entry in sshd_config --> all ok (listen on ipv4 and ipv6) 2) If using NetworkManager and I put ListenAddress=ip in sshd_config --> all ok 3) If NetworkManager disabled and using only network service and no ListenAddress entry in sshd_config --> ok (listen on ipv4 and ipv6) 4) If NetworkManager disabled and using only network service and I put ListenAddress=ip in sshd_config --> ko with 255 error and so no restart 5) If NetworkManager disabled and using only network service and I put ListenAddress=0.0.0.0 --> ok 6) If NetworkManager disabled and using only network service and I put ListenAddress=ip and comment out the RestartPreventExitStatus line --> ko with 255 error and after 42s restart and ok of sshd Can anyone replicate on an RH EL and report? Do you think I can opena a bugzilla for this or NetworkManager is supposed to be kept running as official support? I have a server with two network interfaces where I want to enable sshd only on the second and I'm blocked if I disable NetworkManager. In the mean time I have commented out the service line related to restart n case of 255 error... I see here that actually 255 is the common exit code for many sshd errors and some discussions about Type of sshd service: https://bugzilla.redhat.com/show_bug.cgi?id=1398360 In changelog of rpm between old and new eleases I only see: * Wed Mar 01 2017 Jakub Jelen <jjelen(a)redhat.com> - 6.6.1p1-35 + 0.9.3-9 - Do not send SD_NOTIFY from forked childern (#1381997) * Fri Feb 24 2017 Jakub Jelen <jjelen(a)redhat.com> - 6.6.1p1-34 + 0.9.3-9 - Add SD_NOTIFY code to help systemd to track running service (#1381997) Thanks in advance, Gianluca

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss