>> Uname: Linux 2.6.32-042stab128.2 x86_64
> you can't run this ancient kernel in a Xenial release
This is something I (and quite many others) can't do anything, as the
kernel is provided by OpenVZ. When I last time asked the service
provider, they estimated, that it would be on Q2/2019.
> tmpfil
For Dan:
> then, reboot (so the problem is reproduced) and get the output of
> $ journalctl -b
Attached.
** Attachment added: "journalctl.txt"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1818814/+attachment/5255102/+files/journalctl.txt
--
You received this bug notification bec
For Dimitri:
> In addition to debug output from systemd-tmpfiles-setup.service
> as above, it is also interesting to know the permiissions
> on / itself, ie. what's the output of:
> $ ls -la /
kalle@vspk:~$ ls -la /
total 1272
drwxr-xr-x 24 root root4096 Apr 11 15:18 .
drwxr-xr-x 24 root ro
Yes, tested, and sorry, it did not help. There are still the same errors
in syslog, and /var/run don't have proper directories for sshd etc.
The systemd (etc) version is now as follows:
kalle@vspk:~$ apt-cache policy systemd
systemd:
Installed: 229-4ubuntu21.21+bug1818814v20190411b1
Candidate:
** Attachment added: "find_run_ls_after_reboot.txt"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1818814/+attachment/5254877/+files/find_run_ls_after_reboot.txt
** Changed in: systemd (Ubuntu)
Status: Incomplete => New
--
You received this bug notification because you are a
** Attachment added: "sudo_find_run_ls.txt"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1818814/+attachment/5254876/+files/sudo_find_run_ls.txt
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
>> /var/run directories are not created properly
>what specifically do you mean by this? just that you see log errors?
Following directories were not created automatically, I had to create
them manually in order to enable services to start:
/var/run/fail2ban
/var/run/screen
/var/run/sshd
/var/ru
About var.conf, I wrote that in the initial bug report:
"My first idea was, that for some reason, systemd-tmpfiles was not able to
create the /var directory properly, so I renamed /usr/lib/tmpfiles.d/var.conf
to var.conf, but it was no help."
The output of "ls -lad" is as follows:
kalle
Now I tested on the original host. On that machine, update to
229-4ubuntu21.21 did not work - /var/run directories are not created
properly and e.g. OpenSSH server can't start, following is printed on
the log:
Apr 10 13:31:24 vspk systemd[1]: Starting OpenBSD Secure Shell server...
Apr 10 13:31:24
Correction to previous comment: /var/run directories seem to be pretty
much ok now, i.e. openssh starts, but mysql refuses still to start. I'll
try to find out reason for that and get back to here.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, whi
The problem still exists in the latest (229-4ubuntu21.21) version.
The grep result is attached as "grep_result.txt" file:
kalle@nxld:~$ grep . /etc/tmpfiles.d/* /run/tmpfiles.d/* /usr/lib/tmpfiles.d/*
> grep_result.txt
grep: /run/tmpfiles.d/*: No such file or directory
** Attachment added: "Gr
I got this fixed by manually downgrading packages libsystemd0 and
systemd to versions 229-4ubuntu21.10. I just downloaded those from here:
https://launchpad.net/~ubuntu-security-
proposed/+archive/ubuntu/ppa/+build/15710450
After rebooting the server, the system works again fine. Anyway, now I
hav
Additional information: the problem appeared after updating
libsystemd0:amd64 from 229-4ubuntu21.10 to 229-4ubuntu21.16
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1818814
Public bug reported:
1) The release of Ubuntu you are using, via 'lsb_release -rd' or System ->
About Ubuntu
Description:Ubuntu 16.04.6 LTS
Release:16.04
Just an update - this problem still exists in Ubuntu 16.04.3 LTS.
In case someone gets to this page due to this problem, there is a
workaround. Downside on this workaround is, that all network interface
names are then changed to eth0, eth1, eth2 etc, so one must change
settings on the /etc/network
This feature worked well in my earlier installation (16.04LTS), but when
I re-installed the system yesterday, adding an alias to my USB network
adapter didn't work any more.
---8<---8<---
$ sudo ifup enx0016:0
RTNETLINK answers: Numerical result out of range
Failed to bring up enx0
16 matches
Mail list logo
