Re: [systemd-devel] [systemd‑devel] Removing bold fonts from boot messages
Ulrich Windl wrote: Stupid question: If you see bold face at the end of the serial line, wouldn't changing the terminal type ($TERM) do? Maybe construct your own terminal capabilities. I'd need a TERM that has colors but disallows bold fonts. For some reason I wasn't even able to construct a terminfo that would disallow colors when using that $TERM inside xterm (and starting a new bash). It seems that xterm always has certain capabilities, i.e. "ls --color" is always showing colors in xterm, also with TERM=xterm-mono and everything else I tried. Anway, settings a translation to bind "allow-bold-fonts(toggle)" to a key in xterm resources allows to block bold fonts whenever watching systemd boot messages via ipmi or AMT in a xterm... -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. BioinformatikMail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr. 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: +49 89 2180-99-4049 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
[systemd-devel] loose thoughts around portable services
Hi, we have been playing around more with the portable services and lots of loose thoughts came up. Hopefully we can initiate discussions. The PrivateUsers and DynamicUsers are turned off for the trusted profile in portable services but none of the passwd/group and nss files are mapped to the sandbox by default essentially preventing the sandbox to do a user look up. Is this a use case that should be offered by the “trusted” profile or should this be handled by the services that would like to do a look-up? Is there a way to have PrivateUsers=yes and map more host users to the sandbox? We have dynamic, uid based authorization on dbus methods. Up on receiving a method, the server checks the sender uid against a set of rule files. Would it benefit others if the “profile” support was moved out of the portable services and be part of the unit files? For example part of the [Install] section. Has there been any thought about nesting profiles? Example, one profile can include other profiles in it. Systemd analyze security is great! We believe it would be easier to audit if we had a way to compare a service file’s sandboxing directives against a profile and find the delta. Then score the service file against delta. Thank you for your comments Umut
Re: [systemd-devel] firmware times reported were incorrect.
Looks like boot-timestamps.c first tries to read the ACPI FPDT table (it seems acpi-fpdt.c uses the "OS Loader StartImage Start" and "ExitBootServices Exit" fields), but if that's unavailable, then it uses timestamps stored by systemd-boot in EFI variables (/sys/firmware/efi/efivars/LoaderTime*). The latter seems to be estimating it from RDTSC (src/boot/efi/util.c). On Wed, Oct 13, 2021 at 3:05 PM jiansong Xu wrote: > *This is bios from oracle, we noticed that the firmware times reported > were incorrect.* > > *Startup finished in** 59min 7.944s** (firmware) + 33.051s (loader) + > 4.428s* > *(kernel) + 1min 18.870s (initrd) + 44.494s (userspace) = 1h 1min 48.789s* > > > > *May I ask what is the source of the **firmware** ? is it read from acpi > table? * > > > -- Mantas Mikulėnas
[systemd-devel] firmware times reported were incorrect.
This is bios from oracle, we noticed that the firmware times reported were incorrect. Startup finished in 59min 7.944s (firmware) + 33.051s (loader) + 4.428s (kernel) + 1min 18.870s (initrd) + 44.494s (userspace) = 1h 1min 48.789s May I ask what is the source of the firmware ? is it read from acpi table?
