SCIENTIFIC-LINUX-USERS Archives

August 2014

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
David Webb <[log in to unmask]>
Reply To:
David Webb <[log in to unmask]>
Date:
Mon, 4 Aug 2014 16:49:45 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (28 lines)
For the information of anyone who has a similar problem or tries copying 
Scientific Linux to a SSD.

I found that the errors during the boot process were due to SELinux refusing 
daemons access to files on the new disk.  When SELinux was turned off by 
adding the command 'enforcing=0' to the grub kernel line the problem went 
away.

After I had the system running, I removed this command and instead changed the 
system default enforcing mode to 'permissive'.  The system boots OK and sends 
SELinux messages to "/var/log/ audit".  Once I understand what needs to be 
done, the information should allow me to modify the SELinux permissions and 
switch the system back to enforcing mode.

With the root directory on an SSD, it is best if /var and /tmp are on a non-
SSD disk.  The permissions of the new directories need to be correct - but 
there is an additional problem in that the Logical Volume Manager uses /var 
before any of the non-root volumes are mounted.  

I have got around this by creating a new directory "/var_lvm", with the same 
permissions as the original "/var", and by modifying "/etc/lvm/lvm.conf" so 
that the locking_directory line now reads:
  locking_dir = "/var_lvm/lock/lvm

Regards,

David Webb.

ATOM RSS1 RSS2