On Mon, Jun 24, 2019 at 6:11 AM Lennart Poettering
wrote:
> That said, I don't really grok zram, and not sure why there's any need
> to detach it at all. I mean, if at shutdown we lose compressed RAM
> or lose uncompressed RAM shouldn't really matter. Hence from my
> perspective there's no need
Thanks for the pointer, Lennart!
I've done some initial review of the commit you pointed me to, and it seems
like it should be pretty straightforward to use that understanding to implement
the other functions. Might take a bit depending on my local management's
perspective on the priority of
On 6/24/19 7:53 PM, Andrei Borzenkov wrote:
> 24.06.2019 17:41, Conrad Hoffmann пишет:
>> Hi,
>>
>> TL;DR: I was wondering what happens if a unit executed early during the
>> boot process changes the current dependency graph by either enabling or
>> even starting another unit that was previously
24.06.2019 17:41, Conrad Hoffmann пишет:
> Hi,
>
> TL;DR: I was wondering what happens if a unit executed early during the
> boot process changes the current dependency graph by either enabling or
> even starting another unit that was previously disabled. Is this defined
> behaviour, and if so
Hi,
TL;DR: I was wondering what happens if a unit executed early during the
boot process changes the current dependency graph by either enabling or
even starting another unit that was previously disabled. Is this defined
behaviour, and if so what are the rules?
Longer version:
I am looking at
On Mon, Jun 24, 2019 at 02:11:03PM +0200, Lennart Poettering wrote:
> On Sa, 22.06.19 10:42, Chris Murphy (li...@colorremedies.com) wrote:
>
> > Hi,
> >
> > I've got a commit to add 'Conflicts=umount.target' to this zram
> > service based on a bug comment I cited in the comment. But I'm not
> >
On Sa, 22.06.19 10:42, Chris Murphy (li...@colorremedies.com) wrote:
> Hi,
>
> I've got a commit to add 'Conflicts=umount.target' to this zram
> service based on a bug comment I cited in the comment. But I'm not
> certain I understand if it's a good idea or necessary.
>
>
