On 8 March 2017 at 11:19, James Hogarth wrote:
> On 8 March 2017 at 11:15, Alice Wonder wrote:
>> On 03/08/2017 01:57 AM, Giles Coochey wrote:
>>>
>>>
The recommended configuration for EL7 is to use NetworkManager unless
you have a very specific edge case preventing you from doing so:
>
I few weeks back my server started having a problem where all shares are now
readonly. AFAIK nothing has changed except a 'yum update' which was probably
around the same time.
Everyone still has the shares on their Win7 PC's and can see the contents.
However, if they try to open a file it open
Gary Stainburn wrote:
> I few weeks back my server started having a problem where all shares are
> now readonly. AFAIK nothing has changed except a 'yum update' which was
> probably around the same time.
>
> Everyone still has the shares on their Win7 PC's and can see the contents.
> However, if t
On 3/5/2017 5:24 μμ, Nikolaos Milas wrote:
Using the supergrub2 disk I can boot and login successfully. Otherwise
(i.e. directly) the box won't boot.
In the meantime, I also tried rescatux
(https://sourceforge.net/projects/rescatux/) repair disk; it failed as
well. The situation remains the
On Wed, May 3, 2017 at 4:55 PM, Nikolaos Milas wrote:
> On 3/5/2017 10:41 μμ, Marcelo Roccasalva wrote:
>
>> Does the UUID of root filesystem in /etc/fstab match the actual UUID
>> as reported by blkid? And remove/etc/lvm/cache/.cache if it exists
>
>
> Thank you Marcelo for replying,
>
> The dire
On 4/5/2017 5:20 μμ, Marcelo Roccasalva wrote:
Dumb question: the file starts with a dot, doesn't show up in "ls" without "-a".
Of course, I check with ls -la.It is empty indeed.
Even dumber question: the erroring UUID exist in the origin of
thecloned guest? I guess you have rebuilt initramf
Marcelo Roccasalva wrote:
> On Wed, May 3, 2017 at 4:55 PM, Nikolaos Milas wrote:
>> On 3/5/2017 10:41 μμ, Marcelo Roccasalva wrote:
>>
>>> Does the UUID of root filesystem in /etc/fstab match the actual UUID
>>> as reported by blkid? And remove/etc/lvm/cache/.cache if it exists
>>
>> The director
On Thu, May 4, 2017 at 11:43 AM, Nikolaos Milas wrote:
> On 4/5/2017 5:20 μμ, Marcelo Roccasalva wrote:
>
>> Dumb question: the file starts with a dot, doesn't show up in "ls" without
>> "-a".
>
>
> Of course, I check with ls -la.It is empty indeed.
>
>> Even dumber question: the erroring UUID exi
hey folks, we are migrating our tomcat setup over to centos 7. Im
converting init-scripts over to systemd services and whatnot.. One thing
that Ive noticed is that my systemd startup script cant seem to write to
/var/run as a non-root user to drop a pidfile.. If I create a directory
in /var/run
On 4/5/2017 5:56 μμ, Marcelo Roccasalva wrote:
dracut -f /boot/initramfs-.img
I did:
# dracut -f /boot/initramfs-3.10.0-514.10.2.el7.x86_64.img
3.10.0-514.10.2.el7.x86_64
and it ended without reporting any error. However, when I rebooted,
nothing changed ("no such device: . Entering resc
On Thu, 4 May 2017, Jason Welsh wrote:
hey folks, we are migrating our tomcat setup over to centos 7. Im
converting init-scripts over to systemd services and whatnot.. One
thing that Ive noticed is that my systemd startup script cant seem
to write to /var/run as a non-root user to drop a pidfi
Pretty sure smb gets "control" of a directory via the group. For my
setup, each directory defined by a path in smb.conf has group
smbusers, and has rwx permissions. This is applied just to that
directory, it is not applied recursively. The files and folders in
that directory have the actual remote
Am 04.05.2017 um 18:35 schrieb Paul Heinlein:
The second method is to add an ExecStartPre to
/usr/lib/systemd/system/tomcat.service, e.g.,
Sorry, no. Better not touch the service files in /usr/lib/systemd/system
which ship with the associated packages. You create user custom service
files in
On Thu, 4 May 2017, Alexander Dalloz wrote:
Am 04.05.2017 um 18:35 schrieb Paul Heinlein:
The second method is to add an ExecStartPre to
/usr/lib/systemd/system/tomcat.service, e.g.,
Sorry, no. Better not touch the service files in
/usr/lib/systemd/system which ship with the associated pac
On Thu, May 4, 2017 at 1:12 PM, Nikolaos Milas wrote:
> On 4/5/2017 5:56 μμ, Marcelo Roccasalva wrote:
>
>> dracut -f /boot/initramfs-.img
>
>
> I did:
>
> # dracut -f /boot/initramfs-3.10.0-514.10.2.el7.x86_64.img
> 3.10.0-514.10.2.el7.x86_64
when you boot via supergrub2, you get this kernel ve
Are the correct volumes referenced in your /etc/default/grub file?
On May 4, 2017 11:12:11 AM CDT, Nikolaos Milas wrote:
>On 4/5/2017 5:56 μμ, Marcelo Roccasalva wrote:
>
>> dracut -f /boot/initramfs-.img
>
>I did:
>
># dracut -f /boot/initramfs-3.10.0-514.10.2.el7.x86_64.img
>3.10.0-514.10.2.e
16 matches
Mail list logo