Continuing in https://github.com/systemd/systemd/issues/30695
On Tue, Jan 2, 2024 at 2:06 PM Lennart Poettering
wrote:
>
> On Di, 02.01.24 13:49, Nils Kattenbeck (nilskem...@gmail.com) wrote:
>
> > > I'd be fine with adding MaxVersion=. Happy to review a patch, merge
> > > something like this
On 02.01.2024 18:47, Max Gautier wrote:
Hi,
Is masking `swap.target` a reliable/supported way to disable all swaps
(partition, file, whatever) ?
I used that approach in Kubespray[1] (a k8s installer) while refactoring
our "disable swap" steps, but it looks likes it does not work on Centos
7
Hi,
Is masking `swap.target` a reliable/supported way to disable all swaps
(partition, file, whatever) ?
I used that approach in Kubespray[1] (a k8s installer) while refactoring
our "disable swap" steps, but it looks likes it does not work on Centos
7 [2] (more specifically, systemd 219) ; and
On Mo, 25.12.23 02:39, Patrick Schleizer (patrick-mailingli...@whonix.org)
wrote:
> Hi,
>
> I am maintaining a systemd, Debian-based Linux distribution (Kicksecure) and
> am considering moving to mkosi as the "base image creation tool".
>
> It seems mkosi is a fine OS image builder. With
On Di, 02.01.24 14:40, Nils Kattenbeck (nilskem...@gmail.com) wrote:
> > > does sysupdate currently support any way to slowly roll out updates
> > > where the server providing the files can be in control? [...]
> >
> > This is currently not available, no.
> >
> > The idea so far was always that
> > does sysupdate currently support any way to slowly roll out updates
> > where the server providing the files can be in control? [...]
>
> This is currently not available, no.
>
> The idea so far was always that the server is dumb, and the client
> picks the release it wants.
I feel like it
On Di, 02.01.24 13:11, Simon McVittie (s...@collabora.com) wrote:
> Prior art: Debian/Ubuntu apt does slow rollout for packages like
> this, with simple filesystem-based http mirrors combined with "smart"
> clients. It works by adding a Phased-Update-Percentage field to the
> metadata of each
On Tue, 02 Jan 2024 at 11:16:15 +0100, Lennart Poettering wrote:
> The idea so far was always that the server is dumb, and the client
> picks the release it wants.
>
> I have thought about this usecase a while back, and my thinking was
> that such a staged update logic should be driven by the
On Di, 02.01.24 13:49, Nils Kattenbeck (nilskem...@gmail.com) wrote:
> > I'd be fine with adding MaxVersion=. Happy to review a patch, merge
> > something like this (at least file an RFE issue)
>
> Should that be inclusive or exclusive? Naming it MaxVersion would
> imply it to be inclusive though
> I'd be fine with adding MaxVersion=. Happy to review a patch, merge
> something like this (at least file an RFE issue)
Should that be inclusive or exclusive? Naming it MaxVersion would
imply it to be inclusive though an exclusive bound would likely be
more useful most of the time. One could
On So, 31.12.23 14:43, Nils Kattenbeck (nilskem...@gmail.com) wrote:
> Hello,
>
> we are currently using sd-sysupdate to roll out updates and we're wondering
> if there is any possibility to limit updates to consider at most one next
> major version. This would allow us to write the software to
On Mi, 20.12.23 19:04, Nils Kattenbeck (nilskem...@gmail.com) wrote:
> Hey everyone,
>
> does sysupdate currently support any way to slowly roll out updates
> where the server providing the files can be in control? This would be
> used to slowly make a new version available and have it at e.g. 1%
12 matches
Mail list logo
