Re: [CentOS] puppetmaster after updating to 7.3
https://bugzilla.redhat.com/show_bug.cgi?id=1376893
On 1/3/2017 2:05 PM, Fred Wittekind wrote:
Any one else having issues starting the puppetmaster service after
updating to 7.3?
Looks like a SELinux issue, I couldn't find an existing bug report,
but, seems like I shouldn't be the first one to trip on this issue.
# grep puppet audit.log | audit2allow
#= puppetmaster_t ==
allow puppetmaster_t puppetagent_exec_t:file { execute
execute_no_trans getattr ioctl open read };
selinux-policy-3.13.1-102.el7_3.7.noarch
selinux-policy-targeted-3.13.1-102.el7_3.7.noarch
puppet-server-3.6.2-3.el7.noarch (from EPEL)
puppet-3.6.2-3.el7.noarch (from EPEL)
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
[CentOS] puppetmaster after updating to 7.3
Any one else having issues starting the puppetmaster service after
updating to 7.3?
Looks like a SELinux issue, I couldn't find an existing bug report, but,
seems like I shouldn't be the first one to trip on this issue.
# grep puppet audit.log | audit2allow
#= puppetmaster_t ==
allow puppetmaster_t puppetagent_exec_t:file { execute execute_no_trans
getattr ioctl open read };
selinux-policy-3.13.1-102.el7_3.7.noarch
selinux-policy-targeted-3.13.1-102.el7_3.7.noarch
puppet-server-3.6.2-3.el7.noarch (from EPEL)
puppet-3.6.2-3.el7.noarch (from EPEL)
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] 7.2 kernel panic on boot
On 12/3/2015 5:40 AM, Duncan Brown wrote:
On 03/12/2015 10:06, Leon Fauster wrote:
Am 03.12.2015 um 10:53 schrieb Duncan Brown :
On 03/12/2015 09:40, Bernard Lheureux wrote:
On 12/03/2015 10:29 AM, Duncan Brown wrote:
initramfs is missing...
check if /boot/initramfs-{kernelversion}.img is correctly there, if
not do a "yum reinstall kernel-{version}" and it should be ok !
Hi All
After upgrading to 7.2, I'm getting an immediate kernel panic on boot
Dropping back to 3.10.0-229.20.1.el7.x86_64 and the system boots fine
How can I go about diagnosing the problem here?
thanks
Duncan
No joy unfortunately, the correct initramfs is there
I tried reinstalling just in case, but no change
any additional kernel modules installed?
--
LF
Hi Leon
I'm running kmod-nvidia and kmod-forcedeth from elrepo
The nvidia-kmod had an update to work with the new kernel, the
forcedeth did not but as far as I can tell it didn't need one. (also
why on earth the forcedeth module has gone from the stock kernel in 7
I have no idea)
The first thing I tried however was uninstalling both, but I'm still
getting the same panic
Is there any way of logging it so I can see exactly what the panic says?
thanks all
Duncan
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Mine booted successfully after update to 7.2 CR. I am also using a
Nvidia kmod from elrepo, no forcedeth though.
kernel-3.10.0-327.el7.x86_64
kmod-nvidia-340xx-340.96-1.el7.elrepo.x86_64
Did you rebuild initrd after removing the kmod packages?
Fred Wittekind
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] beeps and a slow boot
Cracking the case shouldn't be feared, I've done it many times, and I've almost never damaged anything. Recommendations: Unplug it (I've seen this in previous posts), it used to be better to leave it plugged in pre-ATX, given ATX's always powered on to some extent, it's best to unplug it completely. How much static charge you have doesn't really matter, as long as you have the same charge as the equipment you are working on. Be very aware of this, you want to make sure to keep your charge equal to the equipment you are working on. This is the function of anti-static bracelets. Assuming you don't have one, just keep one hand on the chassis of the computer while you work, or touch the chassis often. And don't move around in such a way as to build up charge, and if you do, touch the chassis again. I/O card have chassis too, it's the hanger bracket. Anti-static bags also also a way to equalize charge with the component inside the bag, just by holding on to the bag. If you have to lay a part down on a table, lay it on a anti-static bag. Be careful, don't use too much force. If something seems to take a lot of force, your probably not doing it right. Dust can cause you many problems, keep the dust out of the equipment. Make sure connectors are free of dust before connecting them. Canned air is good for this purpose. Work slow and careful, be sure of what you are doing. If something takes longer to use a little extra care, then it takes longer. Fear of cracking a computer case can actually itself result in damage to expensive parts. I've inherited plenty of equipment because of problems caused by dust. On 7/8/2014 11:17 PM, Michael Hennebry wrote: > On Tue, 8 Jul 2014, Ljubomir Ljubojevic wrote: > >> I service PC's for 14 years (professionally), and never had anything >> zapped. And I do not use anti-static wrists. So it is strange to hear >> that you had part zapped on first opening. That is all. > Given my track record, you can see why I'd like to be > really sure it's necessary before cracking the case. > ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] bond of bonds
On 11/14/2011 3:15 PM, Paras pradhan wrote: > Hi, > > I am trying to use Link-aggregation with redundancy between switches > that doesnot support SMLT in switches. > > > I have 4 network ports. First two are connected to a switch and > LACP/LAG is enabled. Third and Fourth ports connect to another switch > with another LAG group. I was thinking create two mode 4 bonds and > bond those bonds to mode 1 (Active/Passive) bond. But it seems this > is not supported yet in kernel (?). How do you guys handle this kind > of situation. (And yes without using SMLT between switches). > > > > Thanks > Paras. > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos > You can bridge two bonds together, and enable STP to prevent a loop. Although, don't get it wrong on a production network, it's not pretty. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Air Conditioning - ON!
I understand how answering everyone's requests for progress updates can slow a development process, I've been on the development side of that before. I want a progress report as much as anyone I'm sure (and so does my boss), but, I'm not going to ask for it. I instead spend a little time, and do a bit of digging, and can find enough of an answer. I think though, I have had better luck finding progress information on CentOS than I did when I was waiting on upstream to release 6 (of course they had betas, and maybe I just didn't look in the right place, but I didn't find much status information). Committing to a product launch date, then trying to patch the product after the fact is IMHO a bad thing, and I'm glad upstream & CentOS do not do this. I can think of some suggestions of my own to maybe help the development process and community involvement (as I'm sure a so can a great many people), but I will keep those to myself for now. Trying to change anything major now will only significantly slow things down. CentOS team, you have my understanding, and my appreciation for your hard work, and I look forward to being able to use the product of that work when it's ready. On 2/21/2011 1:21 PM, John Hinton wrote: > All, > > (and please do not turn this into the next long thread) > > We have a small team which volunteers their time to create the CentOS > releases. They are pounded right now with getting that done... it is as > simple as that. Each of us 'chose' to use CentOS and with that choice > comes nothing more. > > Why are we complaining? To me, it is all very self-centered. Basically > we're all complaining because we 'want' something. And yes, I'm on edge > wanting something as well... but that is life with RedHat in general. > > Some of the suggestions made: > > 1. Send money. OK, so using a very loose or reapplied definition of a > word... we want to 'prostitute' the CentOS team. In other words, if we > send money we have the 'right' to gripe and press for rapid releases? > Demand services? > > 2. Add more staff. As a small business owner, the very last thing you > want to do is add more staff when you are in a slammed state. It takes > all of the 'productive' workers time to train the new staff and output > slows to a crawl. > > 3. Make any other number of 'helpful' suggestions. Well, I think by now > the CentOS team knows better than us how this needs to be done based on > infrastructure and team members. And even if they aren't doing it right, > we don't get to make demands that it be done differently as this is how > they have decided to do it. Remember, you chose CentOS based on how they > operate. You can go away if you like. > > 4. Bringing up other distros that are ahead of CentOS. This just an > attempt at indirect pressure on the CentOS team to get a competition > going. Only the team gets to choose their competition. CentOS 'rates' > how it rates and that is up to the CentOS team and their decisions. Some > cheerleading might be welcomed, as long as it doesn't become an "I cheer > for you therefore you owe me". > > 5. MOST IMPORTANT discussing this right now is the wrong time. The > CentOS team needs to be focused on the builds. They need to 'feel good'. > They do not need these distractions, complaints, suggestions, pressures > and generally negative comments at this moment in time. If it really > bothers you, save it for later and bring it up when things are back to > normal loads. Perhaps some good will come out of it, but not now. I know > that most mean well, but look inside of yourself and the rush is about > something you want... and YOU chose a FREE distro, which just so happens > to convert to the paid version very easily. > > 6,7,8,9 and 10 (fill in your own but keep them to yourself) > > If I were a member of the CentOS team right now, I'd likely be looking > at the door. I positively would be needing to step back and take some > time to myself to try to cool off and feel positive about what I'm > doing. To me and from what I have heard from the CentOS team, very > little of what is being said on the list is helping but instead is > counterproductive at the moment. Obviously the team is 'reading' the > list and 'obviously' some of us have pushed them further at a very high > stress time, than they have ever been pushed before. > > You may also note that upstream was also 'very late' with these new > releases. Could it be we are discovering why? (please don't try to > answer that) > > Please please please... ease up, give them the time they need. Make > notes for future conversations, but quit distracting them and making > them feel bad. Or, write your scathing reply to a thread... get really > down angry and in the dirt... then when you're done, just delete it. > > CentOS team, > > I do have just one suggestion (and I have no rights to ask this). It > seems that the list goes quiet and waits for a while and then explodes a >
[CentOS] GFS performance issue
Two web servers, both virtualized with CentOS Xen servers as host (residing on two different physical servers). GFS used to store home directories containing web document roots. Shared block device used by GFS is an ISCSI target with the ISCSI initiator residing on the Dom-0, and presented to Dom-U webservers as drives. Also, providing a second shared block device for quorum disk. If I hit the web site on just one of the nodes, it behaves as expected. If I try to load the websites from both nodes at the same time (two web browser instances), the load average on both nodes spikes, and page loads very slowly. The site I am trying to host is very high traffic, and if the servers can be nearly brought to there knees with two web browser instances running on a single workstation, that's not going to work. I am not seeing any error messages in the logs regarding the cluster. Any help or suggestions on how to troubleshoot this issue would be greatly appreciated. [r...@www3 www]# find ./ | wc -l 64815 [r...@www3 www]# gfs2_tool df /home/www /home/www: SB lock proto = "lock_dlm" SB lock table = "Web:homewww" SB ondisk format = 1801 SB multihost format = 1900 Block size = 4096 Journals = 2 Resource Groups = 316 Mounted lock proto = "lock_dlm" Mounted lock table = "Web:homewww" Mounted host data = "jid=1:id=393217:first=0" Journal number = 1 Lock module flags = 0 Local flocks = FALSE Local caching = FALSE Type Total Blocks Used BlocksFree Blocksuse% data 20707148 434723716359911 21% inodes 16426386 66475 16359911 0% [r...@www3 www]# gfs2_tool gettune /home/www new_files_directio = 0 new_files_jdata = 0 quota_scale = 1. (1, 1) logd_secs = 1 recoverd_secs = 60 statfs_quantum = 30 stall_secs = 600 quota_cache_secs = 300 quota_simul_sync = 64 statfs_slow = 0 complain_secs = 10 max_readahead = 262144 quota_quantum = 60 quota_warn_period = 10 jindex_refresh_secs = 60 log_flush_secs = 60 incore_log_blocks = 1024 [r...@www3 www]# cat /etc/cluster/cluster.conf |egrep '(dlm)|(gfs)' Fred Wittekind ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
