[systemd-devel] Fwd: pci card network interfaces incorrectly named as onboard
I've got a system on which systemd is incorrectly naming plug-in PCIe network card interfaces as onboard (eg, eno33) instead of with the PCI slot number (eg, ens2f0). Looking at the source, it looks like the network device naming will, by default, generate an onboard network name for any device that has an acpi_index in sysfs. However, acpi_index is present for any network device which has a _DSM in ACPI for naming the PCI/PCIe device (as described in section 4.6.7 of the PCI Firmware Spec v3.2)--and this _DSM is not intended to be used only for onboard network interfaces. (The implementation note for this _DSM in the firmware spec shows, as an example, what this _DSM might return for a network card plugged into a PCIe slot.) The best solution that I've thought of so far is to make systemd prefer the naming for the slot (ID_NET_NAME_SLOT) over the naming for an onboard device (ID_NET_NAME_ONBOARD), if both exist. Does that sound like a reasonable solution? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-networkd Zeroconf address
Hi Team, I came across a requirement why the link local address exist with other IP addresses for IPv4. Suppose if I enable the link local address through systemd-networkd then as per the existing behavior, link local address(169.254.*.*) will always exist on the interface irrespective of whether static/dynamic address exist or not. The expectation is if either static/dhcp address exist then zeroconfig address should not come even if the zeroconf functionality is enabled. Is it correct expectation? is it aligned with other operating system which is not using systemd-networkd as the network manager? Ratan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] vconsole for handicapped or older people
Am Montag, den 22.07.2019, 13:20 +0200 schrieb hp4everything: > Hi, > > getting older I'm nearly not able to read the text on a virtual > console. > I'm working with opensuse tumbleweed on a laptop and was able to > configure the KDE screen for my needs, but not the vconsole. > > Google told me that probably systemd is responsible for vconsole- > configuration, but in vconsole.conf there seem to be options for me > to make the text readable: > > - the preconfigured font "eurlatgr" has no fontsize-option > - vconsole.conf has no fontsize-parameter > - vconsole.conf has no screen-resolution parameter > - vconsole.conf has no parameter to select a framebuffer, e.g > 1052x768 > > > can anybody help with links to more detailed documentation or with > hints > how to configure vconsole in systemd/Opensuse Tumbleweed? > > Thanks > Hans-Peter Hi, I think your best try would by kmscon [1], which replaces your normal TTY with something using proper font scaling and such. HTH Silvio [1]: https://www.freedesktop.org/wiki/Software/kmscon/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] vconsole for handicapped or older people
On Mon, Jul 22, 2019 at 2:20 PM hp4everything wrote: > Hi, > > getting older I'm nearly not able to read the text on a virtual console. > I'm working with opensuse tumbleweed on a laptop and was able to > configure the KDE screen for my needs, but not the vconsole. > > Google told me that probably systemd is responsible for vconsole- > configuration, but in vconsole.conf there seem to be options for me > to make the text readable: > > - the preconfigured font "eurlatgr" has no fontsize-option > - vconsole.conf has no fontsize-parameter > The console fonts aren't scalable – each font file in /usr/share/kbd/consolefonts has exactly one size AFAIK. So there is no point in having a separate fontsize option because that's already part of the file name (fontname). For example, if you install the Terminus font, you select the size using FONT=ter-v20n, FONT=ter-v22b, FONT=ter-v24n, etc. It's up to each font to provide these variants. (The largest "stock" font is probably sun12x22, but its charset coverage isn't great.) > - vconsole.conf has no screen-resolution parameter > - vconsole.conf has no parameter to select a framebuffer, e.g 1052x768 > The kernel will activate a framebuffer automatically as soon as a KMS video driver is loaded (such as i915 or radeon). You can specify the screen resolution using the "video=1024x768" kernel boot option (e.g. via GRUB). This doesn't require systemd-vconsole and generally happens automatically as soon as udev starts. (Possibly even during the initramfs? I use early-KMS on Arch, no idea how that's done on SuSE.) On the other hand, if you're using the proprietary nVidia drivers, I'm not sure if those support a framebuffer at all? -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] vconsole for handicapped or older people
Hi, getting older I'm nearly not able to read the text on a virtual console. I'm working with opensuse tumbleweed on a laptop and was able to configure the KDE screen for my needs, but not the vconsole. Google told me that probably systemd is responsible for vconsole- configuration, but in vconsole.conf there seem to be options for me to make the text readable: - the preconfigured font "eurlatgr" has no fontsize-option - vconsole.conf has no fontsize-parameter - vconsole.conf has no screen-resolution parameter - vconsole.conf has no parameter to select a framebuffer, e.g 1052x768 can anybody help with links to more detailed documentation or with hints how to configure vconsole in systemd/Opensuse Tumbleweed? Thanks Hans-Peter ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Antw: Re: journald deleting logs on LiveOS boots
>>> Chris Murphy schrieb am 18.07.2019 um 17:55 in Nachricht : > On Thu, Jul 18, 2019 at 4:50 AM Uoti Urpala wrote: >> >> On Mon, 2019-07-15 at 14:32 -0600, Chris Murphy wrote: >> > So far nothing I've tried gets me access to information that would >> > give a hint why systemd-journald thinks there's no free space and yet >> > it still decides to create a single 8MB system journal, which then >> > almost immediately gets deleted, including all the evidence up to that >> > point. >> >> Run journald under strace and check the results of the system calls >> used to query space? (One way to run it under strace would be to change >> the unit file to use "strace -D -o /run/output systemd-journald" as the >> process to start.) > > It's a good idea but strace isn't available on Fedora live media. So I > either have to learn how to create a custom live media locally (it's a > really complicated process) or convince Fedora to add strace to live > media... Wouldn't it be easer to scp the binary from a compatible system? > > -- > Chris Murphy > ___ > systemd-devel mailing list > systemd-devel@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
[systemd-devel] Antw: Re: Antw: sd_journal_send non-blocking call
>>> vaibhav dahiya schrieb am 19.07.2019 um 00:29 in Nachricht : > Since sd_journal_send uses > > fd = journal_fd(); > which has > > fd = socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0); > this socket is opened without a non-blocking call. > > This might cause the unix socket daemon to block this . > > The other approach could be passing a nonblocking flag to > > k = sendmsg(fd, , MSG_NOSIGNAL); > > *MSG_DONTWAIT* flag . > > ARE ANY OF THESE APPROACHES TRIED OR is there a plan to support this > complete non blocking sd_journal_print call ? If I understand things right, using the non-block flags will prevent these calls from blocking, but they will fail instead, so you'll have to retry to succeed. Is there anything gained then? > > regards > > > On Thu, Jul 18, 2019 at 2:52 AM Mantas Mikulėnas wrote: > >> On Thu, Jul 18, 2019 at 12:44 PM Ulrich Windl < >> ulrich.wi...@rz.uni-regensburg.de> wrote: >> >>> >>> Mantas Mikulenas schrieb am 18.07.2019 um 10:06 >>> in >>> Nachricht >>> : >>> > On Thu, Jul 18, 2019 at 10:32 AM Ulrich Windl < >>> > ulrich.wi...@rz.uni-regensburg.de> wrote: >>> > >>> >> >>> Vaibhav Dahiya schrieb am 18.07.2019 um 02:53 >>> in >>> >> Nachricht >>> >> <5d2fc2f0.1c69fb81.214d0.1...@mx.google.com>: >>> >> > Hello, >>> >> > >>> >> > I am using sd_journal_send api() api call to log messages on syslog >>> >> server. >>> >> > I see that this uses >>> >> > sendmsg(fd, , MSG_NOSIGNAL) call. >>> >> >>> >> Aren't syslog messages UDP anyway? When would an UDP send block? >>> >> >>> > >>> > No, program APIs use Unix sockets (/dev/log, >>> /run/systemd/journal/socket). >>> > You only get UDP when your local syslog daemon is configured to forward >>> > elsewhere. >>> > >>> > That said, both are datagram sockets, I'm not sure whether sending to >>> Unix >>> > dgram sockets can block or not? >>> >>> ??? Datagram _is_ UDP >>> >> >> UDP is datagram, but datagram is not always UDP. >> >> "UDP" specifically means the datagram transport protocol that runs over >> IPv4/IPv6, nothing else. Unix sockets (AF_UNIX) have a datagram mode but >> they do not use UDP (or IP). Netlink is datagram-based but it isn't >> UDP-based. >> >> -- >> Mantas Mikulėnas >> ___ >> systemd-devel mailing list >> systemd-devel@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
