On 6/7/2017 12:53 PM, Bruce Ferrell wrote:
On 6/7/17 12:42 PM, Johnny Hughes wrote:
On 06/07/2017 02:02 PM, John R Pierce wrote:
On 6/7/2017 11:28 AM, Always Learning wrote:
In the case of CentOS-7 .. you don't need to create a whole new
distro, you can just petition the CentOS Project Board t
On 06/07/2017 12:39 PM, Johnny Hughes wrote:
On 06/06/2017 02:53 AM, John Hodrien wrote:
On Mon, 5 Jun 2017, m.r...@5-cent.us wrote:
Mmmm... looks like I may go for C6, then, since unlike that Ubuntu, I
will
want to do updates at least every time I get ready for a trip (other
times, it sits
On 06/07/2017 01:27 PM, Warren Young wrote:
On Jun 7, 2017, at 1:02 PM, John R Pierce wrote:
every RPM that interacts with systemd will need to be 'fixed' to do it the old
way, with init.d scripts. repositories like postgres, EPEL, etc won't work,
either, as their C7 packaged daemons are all
On Jun 7, 2017, at 2:24 PM, Always Learning wrote:
>
> What is the advantage of patches over a virgin version that can be
> subsequently patched ?
Doing the change as a patch to the upstream RPM means that, most of the time,
you can just apply your patch again whenever the upstream RPM changes.
On Jun 7, 2017, at 1:02 PM, John R Pierce wrote:
>
> every RPM that interacts with systemd will need to be 'fixed' to do it the
> old way, with init.d scripts. repositories like postgres, EPEL, etc won't
> work, either, as their C7 packaged daemons are all configured to use systemd.
That’s jus
On Wed, 2017-06-07 at 12:02 -0700, John R Pierce wrote:
> but will you contribute to building the non-systemd packages, and
> working out how to retrofit old sysV init back into everything via
> patches, etc ?every RPM that interacts with systemd will need to be
> 'fixed' to do it the old
Johnny Hughes wrote:
> On 06/07/2017 02:02 PM, John R Pierce wrote:
>> On 6/7/2017 11:28 AM, Always Learning wrote:
In the case of CentOS-7 .. you don't need to create a whole new
distro, you can just petition the CentOS Project Board to create a
Special Interest Group to get access
On 06/02/2017 04:32 AM, hw wrote:
What may cause the high CPU load?
Offhand, it's hard to say. I don't see similar behavior. Can you post
the libvirt XML definitions for those VMs somewhere? pastebin maybe?
What's the output of "rpm -qa qemu\*"?
_
On 6/7/17 12:42 PM, Johnny Hughes wrote:
On 06/07/2017 02:02 PM, John R Pierce wrote:
On 6/7/2017 11:28 AM, Always Learning wrote:
In the case of CentOS-7 .. you don't need to create a whole new
distro, you can just petition the CentOS Project Board to create a
Special Interest Group to get acc
On Wed, June 7, 2017 2:02 pm, John R Pierce wrote:
> On 6/7/2017 11:28 AM, Always Learning wrote:
>>> In the case of CentOS-7 .. you don't need to create a whole new
>>> distro, you can just petition the CentOS Project Board to create a
>>> Special Interest Group to get access to CentOS Project co
On 06/07/2017 02:02 PM, John R Pierce wrote:
> On 6/7/2017 11:28 AM, Always Learning wrote:
>>> In the case of CentOS-7 .. you don't need to create a whole new
>>> distro, you can just petition the CentOS Project Board to create a
>>> Special Interest Group to get access to CentOS Project controlle
On 6/7/2017 11:28 AM, Always Learning wrote:
In the case of CentOS-7 .. you don't need to create a whole new
distro, you can just petition the CentOS Project Board to create a
Special Interest Group to get access to CentOS Project controlled
resources to build packages (and get them rolled into o
On Wed, 2017-06-07 at 11:23 -0500, Johnny Hughes wrote:
> If you want to create a CentOS-7 variant that does not use systemd,
> then start a Special Interest Group and create modified packages
> to use something else instead ..., much like the this group did
> with Debian:
>
> https://devuan
Kenneth Porter wrote:
> On 6/7/2017 10:09 AM, Louis Lagendijk wrote:
>> I would not call fstab rudimentary.
>
> Perhaps I phrased that poorly. The idea is that fstab provides a minimal
> set of mounts to get off the ground. (My understanding, not saying
> that's how it's designed or intended.)
>
>
On 6/7/2017 10:09 AM, Louis Lagendijk wrote:
I would not call fstab rudimentary.
Perhaps I phrased that poorly. The idea is that fstab provides a minimal
set of mounts to get off the ground. (My understanding, not saying
that's how it's designed or intended.)
This follows the packaging patt
On Wed, 2017-06-07 at 12:47 -0400, m.r...@5-cent.us wrote:
> Kenneth Porter wrote:
> > On 6/7/2017 8:31 AM, m.r...@5-cent.us wrote:
> > > Not sure what you mean when you say "jacked up filesystem".
> > > Here's
> > > fstab:
> >
> > In systemd fstab takes care of only rudimentary mounting. Most
> >
On Wed, Jun 07, 2017 at 12:47:58PM -0400, m.r...@5-cent.us wrote:
> You. Have. To. Be. Joking. WHY? Why doesn't systemd *look* at fstab and
> create what it needs on the fly? Why does it only "rudimentary mount"?
It does that. Read the man page for 'systemd-fstab-generator', and
'systemd.generato
Kenneth Porter wrote:
> On 6/7/2017 8:31 AM, m.r...@5-cent.us wrote:
>> Not sure what you mean when you say "jacked up filesystem". Here's
>> fstab:
>
> In systemd fstab takes care of only rudimentary mounting. Most mounting
> is done through *.mount unit files. Type "mount" and you'll see a bunch
On 06/06/2017 02:53 AM, John Hodrien wrote:
> On Mon, 5 Jun 2017, m.r...@5-cent.us wrote:
>
>> Mmmm... looks like I may go for C6, then, since unlike that Ubuntu, I
>> will
>> want to do updates at least every time I get ready for a trip (other
>> times, it sits in the closet turned off).
>
> I w
On 06/07/2017 09:10 AM, m.r...@5-cent.us wrote:
> I just updated a system - as in minutes ago, and log back in after it
> reboots, and this is in dmesg:
> [ 88.202272] systemd-readahead[484]:
> open(/var/tmp/dracut.fP4yj1/initramfs/usr/bin/loginctl) failed: Too many
> levels of symbolic links
> [
On 6/7/2017 8:31 AM, m.r...@5-cent.us wrote:
Not sure what you mean when you say "jacked up filesystem". Here's fstab:
In systemd fstab takes care of only rudimentary mounting. Most mounting
is done through *.mount unit files. Type "mount" and you'll see a bunch
of other mounts that were impl
On Wed, June 7, 2017 10:43 am, Warren Young wrote:
> On Jun 7, 2017, at 9:31 AM, Mark Haney wrote:
>>
>> On 06/07/2017 11:24 AM, James Hogarth wrote:
>>>
>>> Mark stop with the flame baiting please.
>>>
>>> This is nothing systemd specific - and keep in mind /var/tmp is a
>>> persistent temp area
On Jun 7, 2017, at 9:31 AM, Mark Haney wrote:
>
> On 06/07/2017 11:24 AM, James Hogarth wrote:
>>
>> Mark stop with the flame baiting please.
>>
>> This is nothing systemd specific - and keep in mind /var/tmp is a
>> persistent temp area unlike /tmp which as it's tmpfs by default is of
>> cours
On 06/06/2017 15:07, Jason Welsh wrote:
ugh, the upgrade changed the owner from named to root on /var/named
where my zone files are and
therefore named could not read the zone files.. How embarrassing.. ;)
Jason
That will happen every time named is restarted (it is part of the start
up
Mark Haney wrote:
> On 06/07/2017 11:24 AM, James Hogarth wrote:
>>
>> Mark stop with the flame baiting please.
>>
>> This is nothing systemd specific - and keep in mind /var/tmp is a
>> persistent temp area unlike /tmp which as it's tmpfs by default is of
>> course emptie don boot.
> I would whole
Mark Haney wrote:
>
>> Thanks for the info. Now, why it shouldn't have cleaned itself up when I
>> gave it the reboot command... I see too many (that's defined as more
>> than zero) cases where systemd WANTS TO BOOT FAST, and doesn't wait for
>> things to finish - sush as not getting the hostname f
On Wed, Jun 07, 2017 at 11:31:06AM -0400, Mark Haney wrote:
> I would wholeheartedly disagree. This IS something systemd
> specific. I have never seen init.d blow itself up over bloody
> symlinks. The readahead, while /possibly/ nice isn't at all
> necessary on modern hardware. I want my hardwa
On 06/07/2017 11:24 AM, James Hogarth wrote:
Mark stop with the flame baiting please.
This is nothing systemd specific - and keep in mind /var/tmp is a
persistent temp area unlike /tmp which as it's tmpfs by default is of
course emptie don boot.
I would wholeheartedly disagree. This IS somethi
Thanks for the info. Now, why it shouldn't have cleaned itself up when I
gave it the reboot command... I see too many (that's defined as more than
zero) cases where systemd WANTS TO BOOT FAST, and doesn't wait for things
to finish - sush as not getting the hostname from dhcp, and so having to
ha
On 7 June 2017 at 16:13, wrote:
> Matthew Miller wrote:
>> On Wed, Jun 07, 2017 at 10:10:14AM -0400, m.r...@5-cent.us wrote:
>>> I just updated a system - as in minutes ago, and log back in after it
>>> reboots, and this is in dmesg:
>>> [ 88.202272] systemd-readahead[484]:
>>> open(/var/tmp/dr
Matthew Miller wrote:
> On Wed, Jun 07, 2017 at 10:10:14AM -0400, m.r...@5-cent.us wrote:
>> I just updated a system - as in minutes ago, and log back in after it
>> reboots, and this is in dmesg:
>> [ 88.202272] systemd-readahead[484]:
>> open(/var/tmp/dracut.fP4yj1/initramfs/usr/bin/loginctl) f
Bowie Bailey wrote:
> On 6/6/2017 5:29 PM, m.r...@5-cent.us wrote:
>> Jerry Geis wrote:
>>> I have older systems out there that work fine, just for what ever
>>> reason
>>> would be great to upgrade from a C5 -> C7 (due to no longer supported)
>>> or
>>> C6 > C7 (for updated packages).
>>>
>>> Soun
On Wed, Jun 07, 2017 at 10:10:14AM -0400, m.r...@5-cent.us wrote:
> I just updated a system - as in minutes ago, and log back in after it
> reboots, and this is in dmesg:
> [ 88.202272] systemd-readahead[484]:
> open(/var/tmp/dracut.fP4yj1/initramfs/usr/bin/loginctl) failed: Too many
> levels of
On 6/6/2017 5:29 PM, m.r...@5-cent.us wrote:
Jerry Geis wrote:
I have older systems out there that work fine, just for what ever reason
would be great to upgrade from a C5 -> C7 (due to no longer supported) or
C6 > C7 (for updated packages).
Sounds like the upgrade tool is not quite an option..
I'm not sure why it's trying to open anything in /var/tmp to be
honest. Jacked up filesystem maybe? Granted I know very little about
systemd except it sucks on levels that I can't begin to explain.
On 06/07/2017 10:10 AM, m.r...@5-cent.us wrote:
I just updated a system - as in minutes ago,
I just updated a system - as in minutes ago, and log back in after it
reboots, and this is in dmesg:
[ 88.202272] systemd-readahead[484]:
open(/var/tmp/dracut.fP4yj1/initramfs/usr/bin/loginctl) failed: Too many
levels of symbolic links
[ 88.202515] systemd-readahead[484]:
open(/var/tmp/dracut.f
Hi,
I have a new install of c7 with the gnome desktop. I run it with 12 workspaces.
Normally I create the shortcuts so that ctrl+f1 maps to workspace 1 ctrl+f2
maps to f2, etc. When I goto applications -> settings -> keyboard -> shortcuts
-> navigation, I only have the ability to define "Switch t
I am sorry, wrong list.
Jobst
On Wed, Jun 07, 2017 at 04:13:30PM +1000, Jobst Schmalenbach
(jo...@barrett.com.au) wrote:
> Hi
>
> I have had this problem for a while, but waited to post this until I upgraded
> to see whether the upgrade would fix it.
> I upgraded samba to the 4.2.X stream fro
38 matches
Mail list logo
