It appears that I can fix this by editing the unit file and changing:
ProtectSystem=strict
to:
ProtectSystem=full
I'm not sure why that is but a resolution is good enough for me. Following
up on my own thread in case this helps someone else in the future.
Best,
Sean
On Thu, Dec 14, 20
Sorry, perhaps apparmor is not completely disabled, but I don't think it's
enforcing. I tried shutting it off completely with:
systemctl stop apparmor
And that doesn't seem to have made a difference.
Best,
Sean
On Thu, Dec 14, 2023 at 11:57 AM Sean Caron wrote:
> Hi Mant
tems.
I'm unfortunately not very conversant with everything that systemd does
behind the scenes with this namespacing stuff. Does this raise any obvious
flags? Any ideas for how I could further debug and/or resolve this would be
so greatly appreciated!
Best,
Sean
On Wed, Dec 13, 2
from Ubuntu 18 to Ubuntu 20 broke it, or if some security configuration
broke it. Or perhaps there is a missing dependency package on the broken
systems?
Could anyone out there please provide a little bit more guidance on how I
might troubleshoot this and determine the root cause of the issue? I
really hate to bother folks here but I'm feeling stuck.
Thank you!
Sean
On Tue, Nov 09, 2021 at 09:30:05AM +0100, Sean Nyekjaer wrote:
> On Mon, Nov 08, 2021 at 03:00:42PM +0100, Sean Nyekjaer wrote:
> > On Mon, Nov 08, 2021 at 03:47:36PM +0200, Uoti Urpala wrote:
> > > On Mon, 2021-11-08 at 12:05 +0100, Sean Nyekjaer wrote:
> > >
On Mon, Nov 08, 2021 at 03:00:42PM +0100, Sean Nyekjaer wrote:
> On Mon, Nov 08, 2021 at 03:47:36PM +0200, Uoti Urpala wrote:
> > On Mon, 2021-11-08 at 12:05 +0100, Sean Nyekjaer wrote:
> > > Regarding,
> > > https://github.com/systemd/systemd/issues/21203
> >
On Mon, Nov 08, 2021 at 03:47:36PM +0200, Uoti Urpala wrote:
> On Mon, 2021-11-08 at 12:05 +0100, Sean Nyekjaer wrote:
> > Regarding,
> > https://github.com/systemd/systemd/issues/21203
> >
> > I think the point of the issue missed when the issue got closed.
> &g
`systemctl reboot`,
when our max uptime have been exeeced.
If restart of systemd-networkd happens while a reboot is in progress,
the system will hang "forever" (and continue to pet the watchdog).
This is not a thing that eventually will timeout and reboot the
system...
/Sean
f there are any circumstances where it might be expected before I get out my
shovel and start digging.
Thanks!
-Sean McKay
___
systemd-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
I wondered… I saw the changed text in the first paragraph last night and wondered how I missed that.Thank you very much!-Sean From: Lennart PoetteringSent: Wednesday, February 24, 2021 9:33 AMTo: Sean McKayCc: [email protected]: Re: [systemd-devel] What's the best w
Much obliged!I’ll see if I can carve out a little bit of time to put together a PR for the documentation with the wording I would have expected, and we can see what the maintainers think of my wording and go from there.Thanks again!-Sean From: Lennart PoetteringSent: Tuesday, February 23, 2021 1
oper ordering against the ones it's modifying)
to generate those .conf files and call daemon-reload during boot? If the
latter, are there any expected risks associated with calling daemon-reload
during boot?
Thanks!
--
~Sean McKay
___
to be modified is in the manager_set_show_status
function. That function has a debug log in it, but when I enable debug logging,
it's nowhere to be found in the journal despite the value being toggled from
auto to temporary.
Cheers!
-Sean
-Original Message-
From: Lennart Poettering
ting).
Nothing around it seems like a failure, but I'm still digging.
Any suggestions are still welcome
Thanks!
-Sean
From: systemd-devel On Behalf Of
McKay, Sean
Sent: Wednesday, April 29, 2020 4:26 PM
To: [email protected]
Subject: Re: [systemd-devel] How to figure out wh
from digging through the source code. So I figured I'd
ask.
Thanks!
-Sean McKay
P.S. We're still waaay back on 229. Frantically trying to get things
upgraded, but not there yet. I don't think that's relevant (I doubt this is a
systemd
I apparently failed to finish a sentence. Fixed. My apologies!
From: McKay, Sean
Sent: Wednesday, April 29, 2020 4:15 PM
To: [email protected]
Subject: How to figure out what's causing systemd to start printing messages
partway through boot?
Hi all,
Hopefully quick que
ber of tests included with the particular
commit I was pointed to in addition to the code change itself. I'd like to make
sure that I know what sort of tests are expected in a commit and how to run
them (and any other things I might need to do to ensure things are in order
before submi
we're the first ones to want to do something so foolish?
Any insight that you could provide would be greatly appreciated! Thanks.
-Sean McKay
___
systemd-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On 04/20/2017 07:05 AM, Lennart Poettering wrote:
> On Wed, 19.04.17 07:12, Sean Dague ([email protected]) wrote:
>
>> I just upgraded to Ubuntu 17.04 (systemd 232) where systemd-resolved is
>> turned on by default, which means DNSSEC validation on by default.
>
> The DNSSE
ke to avoid doing if I could.
Thanks in advance,
-Sean
--
Sean Dague
http://dague.net
___
systemd-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
r the dmsetup or the 2 cryptsetup lines
commented in, it will hang the machine.
I am hoping I have just put something in the wrong place. pre-mount is
where we previously ran the script from.
Cheers,
Sean
dmtest.tar.gz
Description: GNU Zip compressed
oot.local Compatibility.
Starting Wait for Plymouth Boot Screen to Quit...
Starting Terminate Plymouth Boot Screen...
--
Sean. XinRong Fu
Dedicate System Engineer
SUSE
[email protected]
(P)+86 18566229618
line
SUSE
[0.00] Initializing cgroup subsys cpuset
[0.00] Init
On Fri, 2015-07-17 at 06:55 +0300, Andrei Borzenkov wrote:
> В Wed, 15 Jul 2015 23:03:02 +0800
> sean пишет:
>
> > Hi All:
> > I am trying to test the latest upstream kernel, But i encounter a
> > strange issue about systemd.
> > When the "systemd&q
age -hda ./qemu_platform/hda.img
-initrd ./qemu_platform/initrd-4.1.0-rc2-7-desktop+ -device
e1000,netdev=network0 -netdev user,id=network0 -serial
file:/home/sean/work/source/upstream/kernel.org/ttys0.txt
Job initrd-switch-root.target/start finished, result=done
Accepted new private conne
This also makes the source port less predicatable.
---
src/timesync/timesyncd-manager.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/src/timesync/timesyncd-manager.c b/src/timesync/timesyncd-manager.c
index 3ae01eb..03cfb24 100644
--- a/src/timesync/tim
Here is my new attempt for interface naming for cards in non-zero domains.
Oddly enough, I still get an f0 at the end of mine even though it is not
PCI multifunction.
sean@hanyuu ~ $ udevadm test-builtin net_id /sys/class/net/enP2p32s15f0
2>/dev/null | grep PATH
ID_NET_NAME_PATH=enP2p32
Onboard network controllers are not always on PCI domain 0.
---
src/udev/udev-builtin-net_id.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/src/udev/udev-builtin-net_id.c b/src/udev/udev-builtin-net_id.c
index 5719021..c8d3ad3 100644
--- a/src/udev/ud
On Monday, June 10, 2013, Kay Sievers wrote:
> On Fri, Jun 7, 2013 at 11:46 PM, Sean McGovern wrote:
>> This is definitely not a common case as almost all of the other Linux
machines I have access to expose a network controller in domain 0.
>
> Yeah, I've only seen doma
by the PCI specifications. Regardless, here
is the information you requested:
sean@hanyuu ~ $ uname -a
Linux hanyuu 3.8.13-gentoo #7 Thu Jun 6 00:45:03 EDT 2013 ppc 7447A, altivec
supported PowerMac10,1 GNU/Linux
sean@hanyuu ~ $ /usr/sbin/lspci
:00:0b.0 Host bridge: Apple Inc. UniNorth 2 AGP
:0
Ignore this patch then -- I can't change the PCI geography of my older G4 Mac
Mini, and without this patch predictable interface naming does not work for it.
I'll just keep it locally.
-- Sean McGovern
--Original Message--
From: Kay Sievers
To: McGovern, Sean
Cc: sys
Onboard network controllers are not always on PCI domain 0.
---
src/udev/udev-builtin-net_id.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/src/udev/udev-builtin-net_id.c b/src/udev/udev-builtin-net_id.c
index 5719021..3e77f30 100644
--- a/src/udev/udev-built
31 matches
Mail list logo
