On 29 August 2018 at 11:24, Wojtek Swiatek wrote:
[..]
> How should I create a filesystem which has only the files required by the
> packages (= the ones it brings in, as well as all the dependencies)?
This is a good question and one which is on my list of things to look
at soon for various
On 29 August 2018 at 15:43, Steve Dodd wrote:
> I'm kind of surprised a tool for this hasn't crossed my path already, [..] I
> also wonder if there might be any
> Docker based tools that do this sort of inspection.
Bingo:
- https://github.com/djosephsen/skinnywhale/blob/master/skinn
On 29 August 2018 at 16:14, Wojtek Swiatek wrote:
> Le mer. 29 août 2018 à 17:11, Steve Dodd a écrit :
>> Shouldn't be that hard to adapt one of the above for nspawn?
> nspawn is not the problem - portable services are. I use a minimal image
> with nspawn which is OK but po
ARM has two sync_file_range syscalls, sync_file_range and sync_file_range2.
The former is apparently not used, and glibc calls the latter whenever a
userspace program calls sync_file_range. I'm guessing systemd-nspawn
doesn't know this, because the follow code consistently fails in an nspawn
I'm running Ubuntu bionic, with systemd 237, so I haven't filed a bug
report, but I'm wondering if it rings any bells with anyone.. I've tried
searching github issues, but my keywords either get too few or too many
results to be useful.
I have machine with the following nspawn file:
--
[Network]
[apologies for off-list dupe, I hate gmail...]
On Mon, 19 Aug 2019 at 07:56, Zbigniew Jędrzejewski-Szmek
wrote:
Please test https://github.com/systemd/systemd/pull/13352.
>
I backported to my distro's stable version and it solves the problem:
On Mon, 19 Aug 2019 at 14:38, Steve Dodd wrote:
[..]
> if I start it with systemctl start systemd-nspawn@name, all works as
> expected.
>
> If I start manually with systemd-nspawn -M name -b, I seem to correctly
> get a new network namespace (ip link output in container is cor
On Fri, 26 Jun 2020 at 16:53, Lennart Poettering
wrote:
> > We implement a system call allow list, i.e. everything that isn't
> > > explicitly allowed is denied. You can use --system-call-filter=openat2
> > > to allow a specific syscall on top of our defaults, i.e. extend the
> > > allow list,
On Sun, 16 Aug 2020 at 16:32, Steve Dodd wrote:
Ah, looks like we need to seccomp_attr_get(, SCMP_FLTATR_CTL_LOG, ..)
> somewhere for this to work. Not sure if that should be done
> unconditionally...
>
https://github.com/systemd/systemd/pull/16752 makes it conditional on an
en
On Sun, 16 Aug 2020 at 15:47, Lennart Poettering
wrote:
I think it would be wise to use do fallback logic for EPERM too. It's
> the error that nspawn uses since day #1 basically. I am a bit puzzled
> noone noticed this before, afaik glibc test cases at least on Fedora
> (where most glibc
On Sun, 16 Aug 2020 at 16:05, Steve Dodd wrote:
That's interesting .. it's possible things don't work quite the way I think
> they do, but I will try to find previous examples - I remember borgbackup
> was affected on armhf fairly recently, for example.
>
Ah, the borgbackup thing was
On Sun, 16 Aug 2020 at 14:54, Lennart Poettering
wrote:
> > I've just been bitten by this - last time I looked into a similar
> problem,
> > it seemed the calling code was confused by getting EPERM instead of
> ENOSYS.
> > Could we distinguish between these two cases and generate the right
On Fri, 24 Dec 2021 at 10:11, Jonathan Kelly wrote:
> No. I'm in the middle here ... trying to compile unicon and it borks ... the
> unicon people don't know anything about random-util.c ... it not part of
> their software.
Only thing I can think of is that something used in the compilation
13 matches
Mail list logo
