Re: [systemd-devel] Strange partition layout from systemd-repart
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'll fix the image generation. Maybe there is some way to improve the reporting done by systemd-repart in such a case? Best Regards, Tobias On Thu, Jun 4, 2020 at 4:42 PM Tobias Hunger wrote: > > 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 > > 10_root.conf > [Partition] > Type=root > > 20_vrty.conf > [Partition] > Type=root-verity > > 30_data.conf > [Partition] > Type=home > > I had expected that the three existing partitions stay as they are and > a new partition of Type home would be created, taking the remaining > space. > > But systemd-repart wants to do something else: > > It wants to keep the esp and root at the size they have already. That > is expected. > > The verity partition is supposed to get assigned (almost) all the > remaining space, resizing that from 20MB to about 27GB. > > The new home partition is then pressed into the remaining space and gets 1MB. > > The actual output is this: > > > TYPE LABEL UUIDFILE > NODE SIZE PADDING > espEFI System Partiti… a755fc66-70f7-994d… 00_esp.conf > /dev/sdb1 59.0M 0B > root-x86-64clrm_20200604.1554 308e3eb0-84b4-f6e0… > 10_root.conf /dev/sdb2 2.3G 0B > root-x86-64-verity vrty_20200604.1554 eb01acbc-0dde-cc9b… > 20_vrty.conf /dev/sdb3 20.0M → 27.4G 27.3G → 0B > home home7f4c8a40-c486-4b2b… > 30_data.conf /dev/sdb4 → 1.0M→ 0B > >Σ = 29.8G Σ = 0B > > > I tried adding Weights and such, but to no avail. > > Any ideas what I can do to get the desired behavior? > > Best Regards, > Tobias ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Strange partition layout from systemd-repart
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 10_root.conf [Partition] Type=root 20_vrty.conf [Partition] Type=root-verity 30_data.conf [Partition] Type=home I had expected that the three existing partitions stay as they are and a new partition of Type home would be created, taking the remaining space. But systemd-repart wants to do something else: It wants to keep the esp and root at the size they have already. That is expected. The verity partition is supposed to get assigned (almost) all the remaining space, resizing that from 20MB to about 27GB. The new home partition is then pressed into the remaining space and gets 1MB. The actual output is this: TYPE LABEL UUIDFILE NODE SIZE PADDING espEFI System Partiti… a755fc66-70f7-994d… 00_esp.conf /dev/sdb1 59.0M 0B root-x86-64clrm_20200604.1554 308e3eb0-84b4-f6e0… 10_root.conf /dev/sdb2 2.3G 0B root-x86-64-verity vrty_20200604.1554 eb01acbc-0dde-cc9b… 20_vrty.conf /dev/sdb3 20.0M → 27.4G 27.3G → 0B home home7f4c8a40-c486-4b2b… 30_data.conf /dev/sdb4 → 1.0M→ 0B Σ = 29.8G Σ = 0B I tried adding Weights and such, but to no avail. Any ideas what I can do to get the desired behavior? Best Regards, Tobias ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Grouping services in systemd..
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 see it takes more time than before to complete the > boot. Note that if you didn't use cpu controller for anything else before, you introduced whole new grouping of tasks (i.e. imagine all were in -.slice previously), that may affect timing interactions. Furthermore, group scheduling works relative to siblings, i.e. system-netns.slice would be prioritized against siblings in in system.slice only. Finally, when prioritizing certain services you may have taken CPU time from other services that are dependencies (priority inversion). It makes sense to prioritize services on critical path but if there's nothing else to prioritize against, that's just the amount of work that has to be done anyway as others pointed out. > So by setting it to 8192 am I reducing the CPUShare and hence seeing > an increase in time? No, this is a special value that represents unset CPUShare= internally. Such units would still apply 1024 cpu.shares. > The DefaultCPUAccounting also seems to be enabled for the system. Aha, then my point about cpu controller regrouping is moot probably. HTH, Michal signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-user-sessions.service: Failed to create cgroup /system.slice/systemd-user-sessions.service: No such file or directory
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 with potential file corruption could cause this error. Furthermore, failure of systemd-user-sessions.service should fail the whole boot up transaction. I think this error message is a red herring resolving the post-outage issues. (Is systemd-user-sessions.service the only service that fails like this? What systemd version is that? What cgroup setup do you use (e.g. hybrid vs unified)? Are there any other programs that would modify cgroup hierarchy?) Regards, Michal signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kernel messages not making it to journal
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 whether you run journalctl as root or non-privileged user that may not have access to the system-wide kernel messages. If you don't see the messages in journal as root and you can reproduce it, I suggest you file an issue on Github [1]. HTH, Michal [1] https://github.com/systemd/systemd/issues/new?template=Bug_report.md signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: [EXT] Re: Q: ypbind-systemd-pre[1756]: \nError: NIS domain not specified.\n
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". ... > So some script may have started the service manually. I wonder: How > complicated and efficient would it be if "systemctl status" would output the > reason (e.g.: "manual|dependency") for the last service start (or maybe even > stop)? > Enabled unit is started by dependency as well. There is no difference. "enabled" means exactly "add dependency to another unit"; it is not distinguishable from "other unit has dependency on this unit". There is systemctl list-dependencies which may help. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Antw: [EXT] kernel messages not making it to journal
>>> 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.journal > corrupted or uncleanly shut down, renaming and replacing. > [ 22.953883] systemd‑journald[629]: Creating journal file > /var/log/journal/26336922e1044e80ae4bd42e1d6b9099/user‑1000.journal on > a btrfs file system, and copy‑on‑write is e I saw a similar message for some "secure boot stick" when the journal daemon crashed during boot with syssegv... > > 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. > > systemd‑245.4‑1.fc32.x86_64 > > Thanks, > > ‑‑ > Chris Murphy > ___ > systemd‑devel mailing list > systemd‑de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd‑devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
