On Community Edition for both 6.x and 7.x have used 'groupinstall' for 'Development Tools'... Just " --enablerepo=centos-unverified"
i.e. yum groupinstall "Developemtn Tools"--enablerepo=centos-unverified
Most convenient way to install them...
7.3 here (not upgraded yet to 7.4)
and here this is 6.9
In the unlikely event anybody is still using any of the kmod drivers from my site (haven't advertised them in a long time now) - please follow the directions in Nick's append - https://www.clearos.com/clearfoundation/social/community/clearos-7-4-community-edition-released#reply-192411
Sometimes a problem like this can resolved by changing a setting in the program you use to view the mail...
For example with Thunderbird
Edit -> Account Settings -> "Name of Account" -> Server Settings
There is a Section "When I delete a message" with options as follows
Move it to this folder (Default Folder is Trash)
Just mark it deleted
Remove it immediately
Note the current setting
Select "Remove it immediately" and save "OK"
See if you can now delete the email
Go back and restore your previous "When I delete a message" option
Seamonkey mail is almost the same - suspect others possibly have similar options
Thanks Nick - so Webconfig detects the problem if you go back to configure dhcp settings.. so ClearOS does some basic checking, that is good. Your suggestion to add more, even better... In the meantime, if you change your network, re-check the dhcpd settings screen...
Anything in the logs recorded at the time you changed the NIC address and subnet to indicate an invalid dhcp config now existed? If nothing, would indicate no monitoring by default within dnsmasq for an invalid situation arising during operation . ISC dhcpd detected the NIC/subnet change as a problem within the same minute it changed... Checked the dnsmasq man pages online, (as they are not on my system ) and only found a reference to a syntax check. That is good, but a configuration file that has correct syntax can still be completely invalid...
Regardless of what got changed - surely there should error displayed as soon as something becomes inconsistent...
While dhcpd was running, changed one of the sub-nets where dynamic addresses are assigned but no current leases in effect. Almost instantly dhcpd provided this error message and continued running, recognising the sub-net had disappeared... Had changed 192.168.8.0/24 to 192.168.9.0/24 - my 'play' VLAN
Oct 18 21:26:16 karien dhcpd: receive_packet failed on enp2s0.8: Network is down
Re-starting dhcpd now gives this helpful advice
Oct 18 21:39:18 karien dhcpd: No subnet declaration for enp2s0.8 (192.168.9.98).
Oct 18 21:39:18 karien dhcpd: ** Ignoring requests on enp2s0.8. If this is not what
Oct 18 21:39:18 karien dhcpd: you want, please write a subnet declaration
Oct 18 21:39:18 karien dhcpd: in your dhcpd.conf file for the network segment
Oct 18 21:39:18 karien dhcpd: to which interface enp2s0.8 is attached. **
If dnsmasq does no checking - then maybe webconfig could do some basic checks when the dnsmasq dhcp entries are displayed, created or updated? That would help avoid the situation the OP is faced with... No idea what the webconfig screen(s) look like...
A bit OT... The real reason didn't use dnsmasq in the first place? Couldn't find how to operate two dnsmasq dhcpd servers on the same sub-nets co-operating with each other. Same with dns. The ISC dhcpd server does this with a master and slave that communicate. Both therefore 'know' which leases it has assigned, as well as those by its 'partner'. If one goes down, the other will do everything. Then, when the failed system comes back up, it is brought 'up to date' by its partner... Similarly with BIND for dns. You can have a master and as many slaves as you want. Any changes made to the master get synced to the slave(s). The slave(s) will continue operating if the master goes down. Thus can take down a ClearOS server wjhile the rest of the systems still function fully with dns and dhcp available.
yuk... as Nick pointed out the below is totally wrong (amongst other problems) - trying to assign dhcp addresses outside the subnet
Have to assume you did a copy-and-paste and this is not a typo
Doesn't dnsmasq run any verification checks before it runs? - if not, that is really bad - should not even start with something configured like that... Is there no dnsmasq utility either to verify the configuration files used by dnsmasq..
Don't use dnsmasq here (and seeing this really glad not using it), but the following
Use several VLANS here and tried to configure an incorrect range for dhcpd on a VLAN
It would not start and spit out this helpful error message
-- Unit dhcpd.service has begun starting up.
Oct 18 11:37:25 karien.sraellis.com dhcpd: Internet Systems Consortium DHCP Server 4.2.5
Oct 18 11:37:25 karien.sraellis.com dhcpd: Copyright 2004-2013 Internet Systems Consortium.
Oct 18 11:37:25 karien.sraellis.com dhcpd: All rights reserved.
Oct 18 11:37:25 karien.sraellis.com dhcpd: For info, please visit https://www.isc.org/software/dhcp/
Oct 18 11:37:25 karien.sraellis.com dhcpd: bad range, address 192.168.9.64 not in subnet 192.168.8.0 netmask 255.255.255.0
That's the type of technique was hinting at... As long as it works and discards the type of entries you decided were not needed - then be happy Of course, you could add or delete entries in that file if circumstances change... followed by a rsyslog restart.
Did you have this problem with the USB drive before adding the extra disk for the plexfiles? (sdb1 in your fstab)?
It is really not really the best practice to mount disks using using the dev/sdxy device name; /dev/sdb1 in your case. Disks can 'move'. Wonder whether the USB drive, when inserted before boot, is becoming /dev/sda1 or /dev/sdb1 and hence you are dropping into emergency mode as it cannot perform the mount as per your /etc/fstab as your 'plex' disk is no longer /dev/sdb1. It is much preferred to use the UUID. Your fstab is uisng UUID for the boot drive... If something like this is occurring - then the instructions below should help...
If you run ' ls -l /dev/disk/by-uuid ' - you can see the UUID for your disk partitions...
Check that you can see the one for your /boot partition to verify that you understand the output, matching it to your fstab ... suspect it is /dev/sda1
Then find the UUID for /dev/sdb1 and amend your fstab - using the entry for /boot as a template for the format...
Check first without the USB drive - then reboot with it inserted? Fixed? If so, is the USB drive still /dev/sdc1 when you boot with it inserted? If it moved then checking /var/log/messages is one of several ways to find its new device name...
There are other causes for your problem - but this is the first solution that should be attempted...
7.3 has a text mode install - tedious and slow, but works - done two installations this way now...