[systemd-devel] systemd-nspawn for ubuntu 12.04 with upstart

[Masoom Shaikh]

I have a container using debootstrap for Ubuntu 12.04

systemd-nspawn -D ubuntu_12.04 works


but I want it with boot option

systemd-nspawn -bD ubuntu_12.04

this doesn't give a console!


read somewhere, it might be related to older ubuntu's looking for /dev/tty1 
et.al. where as systemd provides /dev/console

no sure how to modify upstart to use /dev/console


does any body use systemd-spawn for older ubuntu? This is on ArchLinux.


I guess it is not surprise LXC works fine.


- Matt
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Stable interface names even when hardware is added or removed, not true

[Pekka Sarnila]

On 11/16/16 23:26, Dave Reisner wrote:



On Wed, Nov 16, 2016 at 4:19 PM, Pekka Sarnila > wrote:



On 11/16/16 18:11, Greg KH wrote:

On Wed, Nov 16, 2016 at 03:33:42PM +0200, Pekka Sarnila wrote:

On 'Predictable Network Interface Names' it states as a
benefit of the new
policy:

  Stable interface names even when hardware is added or
removed, i.e.
  no re-enumeration takes place

Unfortunately this is not true.

I'm running a mail server, kernel 4.8.6. Graphics card
started to fail.
Replaced it with new one (newer model). Booted the system.

All seemed to be fine, network seemed to work. But after
some time got angry
cries: 'can't read the mail !!!'. A big headache.

Although the new card was in the same slot as the old one
kernel had changed
the name enp6s0 -> enp3s0 (no firmware/BIOS index available
and kernel
policy was used as default). Since enp6s0 was not found our
server instead
of fixed ip address used our dhcp-server to get a random
temp address. Thus
network worked, but not in the mail-servers correct address.

To figure this out took some nervous time.

Now, I don't know why kernel driver got a different name for
this network
interface (ethernet hardware is on the motherboard, and it
is the only net
hardware on the system). But obviously it can happen.


That is because your PCI devices renumbered themselves, which is
quite
common when changing PCI devices around (or adding/removing
them).  Not
much systemd can do about this, sorry.

greg k-h


Well my first point was that the web page should not say

>>   Stable interface names even when hardware is added or removed, i.e.
>>   no re-enumeration takes place

But second was that in principle persistent naming would be possible
for systems with only one interface. And it should possible to
implement it in systemd-network, and make it systemd package default
for such case.


No, it's not. It sounds more like you want to disable the naming policy,
which means you get "eth0" for the first device that shows up.


No thats not at all what I'm suggesting. I have also had my time getting 
gray hair for this 'is it eth0 or eth1 this time'.


But on servers that have only one interface (and no one is allowed to 
hot plug anything what so ever) the old method was better: always eth0. 
And you didn't need to understand how the names are given even when 
upgrading hardware. Of course for other cases the old way was not good.


I still believe that people who's job is to see that servers hardware is 
running don't in most cases know how to configure systemd or much 
anything about the os to that matter.


I'm sure systemd could be developed to count the interfaces right after 
boot, and there could be in the configuration setting saying that if 
there is only one interface at the boot time a name in that 
configuration would be given to that interface.


So what I'm saying, it should be possible the have the good of the old 
and good of the new way in the same package. I don't believe it is alway 
win loose situation


Anyway no big deal.

pekka




pekka

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org

https://lists.freedesktop.org/mailman/listinfo/systemd-devel




___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Stable interface names even when hardware is added or removed, not true

[Lennart Poettering]

On Wed, 16.11.16 23:19, Pekka Sarnila (sarn...@adit.fi) wrote:

> Well my first point was that the web page should not say
> 
> >>   Stable interface names even when hardware is added or removed, i.e.
> >>   no re-enumeration takes place

I now added a small extension to this line: "(to the level the
firmware permits this)" ot clarify that we are bound by firmware
limitations for this.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Stable interface names even when hardware is added or removed, not true

[Lennart Poettering]

On Wed, 16.11.16 15:33, Pekka Sarnila (sarn...@adit.fi) wrote:

> On 'Predictable Network Interface Names' it states as a benefit of the new
> policy:
> 
>   Stable interface names even when hardware is added or removed, i.e.
>   no re-enumeration takes place
> 
> Unfortunately this is not true.

Yeah, some firmware will renumerate PCI devices when you plug in a
device. Ideally they wouldn't. We are making the best effort to
provide stable names, but when the lower layers fuck with us they fuck
with us, there's little we can do about this.

> Could there be general solution for this? On ordinary system MAC could be
> used, but on virtual one. And there are of course docking systems for
> laptops. So that is not general enough.
> 
> It would seem there is no general way to enumerate persistently network
> interfaces unless the network hardware itself directly gives its name (and
> have unique names over the world). Or is there?

Well, the firmware exposes APIs of this, and we make usre of it. But
if the firmware provided info isn't actually reliable, then there's
little we can do.

> However could there be a way for systemsd/udev to know that there is only
> one interface in the system? At least then always as a default the same name
> could be given.

You can plug in an USB device anytime. You newer know what will
eventually show up. And probing time for many devices is essentially
unbounded, so you might have a USB device soldered onto your
mainboard, and it may take any time it likes to initialize, and we
simply cannot know in advance whether we got them all yet, or not.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Munge start Error

[D.S. Ljungmark]

On 17/11/16 13:11, JEYARAJ wrote:
> Hi All,
> 
> Dear Sir,
> I ,am installing  job scheduling system for a single machine.munge also
> installed latest version.
> I start with Munge service .Error is showing;
> 
> Again I used the command:
> 
> Systemctl status munge.service 
> 
> Error is came.
> 
> Please help me sir..
> 

The solution is there in the image that you sent to the list. This is
not an error in systemd, nor is it systemd-specific.


See the line that says "munged[9101] : munged: Error: Failed to check
logfile".

That line is the one that is relevant.

"permission denied" means that either the directory it's attempting to
open, or the file it's attempting to open, is owned by someone else than
the user munged runs as .


I'd suggest you look at the munged mailinglist or forum for help with this.

Most probably, if the init scripts read the files as a "munge"
user, but you've manually launched it as root, you've created the log
files with the wrong permissions / owner, and then get to fix it first.


Good luck.

//D.S.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Munge start Error

[JEYARAJ]

Hi All,

Dear Sir,
I ,am installing  job scheduling system for a single machine.munge also
installed latest version.
I start with Munge service .Error is showing;

Again I used the command:

Systemctl status munge.service 

Error is came.

Please help me sir..

Regards,
Jeyaraj. M
Calligo Technologies
Bangalore.70
India.


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel