Poking around a bit more: I have 4096 unused sectors before the first
partiton instead of just 2048. Systemd-repart then tries to put all my
new partitions into the sectors 2048-4095 and completely ignores the
GBs of free space that is available elsewhere.
So this can be considered a user error. I
Hello!
I have a 32GB USB stick and used dd to put a ~2.5GB image onto it. The
image contains three partitions (ESP, root, root-verity). I would like
to make the remaining space on the USB stick available to users.
So I created a set of files for systemd-repart:
00_esp.conf:
[Partition]
Type=esp
Hi.
(Not sure if it's still pertinent.)
On Tue, Apr 07, 2020 at 10:23:22AM +0530, nitish nagesh
wrote:
> In fact i did try a similar approach of assigning CPUShares to a slice.
> Basically i separated these critical services into a new slice &
> assigned a CPUShare=8192.
> However with this i
Hi.
Is this still relevant?
On Sun, May 10, 2020 at 08:51:09AM -0700, Nebu Pookins
wrote:
> Specifically, the systemd-user-sessions service is failing with the
> following messages:
The cgroup hierarchy is built in-memory on each boot based on your
configuration. I'm skeptical how the outage wi
Hi.
On Mon, Jun 01, 2020 at 07:11:15PM -0600, Chris Murphy
wrote:
> But journalctl does not show it at all. Seems like it might be a bug,
> I expect it to be recorded in the journal, not only found in dmesg.
Journald fetches dmesg messages too (see jounrald.conf:ReadKMsg=). It's
not clear whethe
On Thu, Jun 4, 2020 at 9:05 AM Ulrich Windl
wrote:
>
> But if so, why would it be started if that service is disabled?
Because "disabled" in systemd just means that links in the [Install]
section have not been created. It does not mean "this unit won't be
started under any circumstances".
...
>
>>> Chris Murphy schrieb am 02.06.2020 um 03:11 in
Nachricht
<24912_1591060304_5ED5A750_24912_140_1_CAJCQCtS0r0O9KdvGpV_B9ku5-ure+nGOpRrYYm=V
yggps1...@mail.gmail.com>:
> dmesg shows this:
>
> [ 22.947118] systemd‑journald[629]: File
> /var/log/journal/26336922e1044e80ae4bd42e1d6b9099/user‑1000