In a moment of epic stupidity, having ran out of space on the root partition of a server due to /var chewing up the space, I added a separate drive for the purpose of mounting it as /var To do so, I mounted the new drive as /var2, cp -R (in hindsight should had rsync to preserve attributes), deleted the original /var to free up space, edited fstab and rebooted... unsurprisingly to a fubar'd server. The thing is it still boots, I can get into single user mode but a full init get stuck at starting the syslogger. What is the best way to rescue the server now from my own stupidity and keeping all the existing configuration and data?
2012/8/3 Emmanuel Noobadmin <centos.admin at gmail.com>:> In a moment of epic stupidity, having ran out of space on the root > partition of a server due to /var chewing up the space, I added a > separate drive for the purpose of mounting it as /var > > To do so, I mounted the new drive as /var2, cp -R (in hindsight should > had rsync to preserve attributes), deleted the original /var to free > up space, edited fstab and rebooted... unsurprisingly to a fubar'd > server. > > The thing is it still boots, I can get into single user mode but a > full init get stuck at starting the syslogger. What is the best way to > rescue the server now from my own stupidity and keeping all the > existing configuration and data? > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centosDid you rewrite the selinux policy on /var or have you tried disabling selinux if you haven't do so already?
On Friday, August 03, 2012 06:24:46 AM Emmanuel Noobadmin wrote:> In a moment of epic stupidity, having ran out of space on the root > partition of a server due to /var chewing up the space, I added a > separate drive for the purpose of mounting it as /var... This sort of things pops up from time to time.... from a thread back in April..... On Wednesday, April 11, 2012 05:38:13 PM Jason Pyeron wrote:> > -----Original Message----- > > From: centos-bounces at centos.org > > [mailto:centos-bounces at centos.org] On Behalf Of Alexander Dalloz > > Sent: Wednesday, April 11, 2012 17:12 > > To: CentOS mailing list > > Subject: Re: [CentOS] How to fix a chown oops... > > > > Am 11.04.2012 23:02, schrieb Jason Pyeron: > > > chown -R 7.0 /sbin/ > > > chown -R 98.98 // > > > > > > Is there a rpm way fix all the permissions of files managed by rpms? > > > > http://wiki.centos.org/TipsAndTricks/YumAndRPM#head-20a3ecce3d > > 0762b9cdd3307ef2632e0c274a2bfd > > rpm -qa | while read line; do echo $line && rpm --setperms $line; done >... By extension: rpm -qa | while read line; do echo $line && rpm --setugids $line; done should handle ownerships. Then, reenable selinux in permissive mode, and set it to relabel on the next boot.
On 08/03/12 3:24 AM, Emmanuel Noobadmin wrote:> In a moment of epic stupidity, having ran out of space on the root > partition of a server due to /var chewing up the space, I added a > separate drive for the purpose of mounting it as /var > > To do so, I mounted the new drive as /var2, cp -R (in hindsight should > had rsync to preserve attributes), deleted the original /var to free > up space, edited fstab and rebooted... unsurprisingly to a fubar'd > server. > > The thing is it still boots, I can get into single user mode but a > full init get stuck at starting the syslogger. What is the best way to > rescue the server now from my own stupidity and keeping all the > existing configuration and data?if you had any database servers like postgresql or mysql, and their data files were in the default locations under /var, your databases are undoubtably corrupted, unless you stopped the DB server(s) before doing this copy. -- john r pierce N 37, W 122 santa cruz ca mid-left coast
On Friday, August 03, 2012 12:03:01 PM Karanbir Singh wrote:> Hi, > > On 08/03/2012 04:25 PM, Lamar Owen wrote: > > rpm -qa | while read line; do echo $line && rpm --setugids $line; done > > should handle ownerships. Then, reenable selinux in permissive mode, and set it to relabel on the next boot. > > maybe add --setperms as wellHmm, I thought by including that in my quoted text that it was implied that one should do both.... My bad. It was a long day.... I'm not sure if both can be used on a single command line, since both --setperms and --setugids are implemented via popt aliases; I reserve the right to be wrong, of course. I also forgot to specify in my reply that these commands would only repair files owned by packages; any non-package-owned files in /var won't be helped by either --setperms or --setugids; but it will give the OP a good start.