Re: [systemd-devel] Resolving systemd naming problems on multi-port PCI cards
On Thu, Apr 7, 2016 at 6:08 PM, Jordan Hargrave wrote: > The current systemd naming scheme for Network cards has a problem > correctly naming multi-port NIC devices in a PCI slot. > > Systemd currently generates names of the form: > > enpAsBfCdD > > pA = PCI bus number > sB = PCI device number (confusingly called 'SLOT') Geographical addressing uses sometimes slot sometimes device. The kernel uses "slot" https://github.com/torvalds/linux/blob/master/arch/x86/pci/early.c > fC = PCI function number > [dD = NIC device port (sysfs dev_port)] > > eg. enp5s0f0 for a NIC at 05:00.0, dev_port = 0 > > These names already aren't necessarily persistent if PCI bus topology > changes (Bus number changes due to adding cards across reboot, etc). Sure, geographical addressing is not expected to cover hardware reconfiguration or firmwares which just do "random" renumbering at reboot time. > --or-- > ensBfCdD > > sB = _SUN slot > fC = PCI function number > [dD = NIC device port (sysfs dev_port)] > > eg. ens2f0d1 for a single-port NIC at 0?:00.0 in PCI slot 2, dev_port = 1 > > The problem is the 2nd naming scheme cannot handle multi-port NICs. > Multi-port NICs often have one or more bridges before the PCI slot > number itself. > > eg. for my quad-port Intel NIC in PCI slot 2 the devices are actually: > 44:00.0 > 44:00.1 > 45:00.0 > 45:00.1 > > Using the 2nd naming scheme, the names generated are: > ens2f0 > ens2f1 > ens2f0 > ens2f1 > > Oops. Problem. There is a name collision. > So depending on who gets > initialized first I'll see either: > > ens2f0 > ens2f1 > enp69s0f0 > enp69s1f0 > > or > enp68s0f0 > enp68s1f0 > ens2f0 > ens2f1 How does /sys/bus/pci/slots/ look in that case? When is the PCI hotplug driver loaded? Before or after the network card driver? > There is a way to fix this by combining the two naming schemes, with a > bit of a hack. > > enpAsBfCdD > > pA = PCI bus # (no change) > sB = _SUN slot # (no change) > fC = This is what changes. Instead of C = function number (0..7) it is > Device:Function (0..31) > dD = Device port (no change) > > On my system this generates new names: > enp4s0 at /sys/devices/pci:00/:00:03.0 SLOT 3 => enp3s4f0 > enp4s0d1 at /sys/devices/pci:00/:00:03.0 1 SLOT 3 => enp3s4f0d1 > enp4s0f1 at /sys/devices/pci:00/:00:03.0 SLOT 3=> enp3s4f1 > enp4s0f1d1 at /sys/devices/pci:00/:00:03.0 SLOT 3 => enp3s4f1d1 > enp4s0f2 at /sys/devices/pci:00/:00:03.0 SLOT 3=> enp3s4f2 > enp4s0f2d1 at /sys/devices/pci:00/:00:03.0 SLOT 3 => enp3s4f2d1 > enp4s0f3 at /sys/devices/pci:00/:00:03.0 SLOT 3=> enp3s4f3 > enp4s0f3d1 at /sys/devices/pci:00/:00:03.0 SLOT 3 => enp3s4f3d1 > enp4s0f4 at /sys/devices/pci:00/:00:03.0 SLOT 3=> enp3s4f4 > enp4s0f4d1 at /sys/devices/pci:00/:00:03.0 SLOT 3 => enp3s4f4d1 > enp4s0f5 at /sys/devices/pci:00/:00:03.0 SLOT => enp3s4f5 > enp4s0f5d1 at /sys/devices/pci:00/:00:03.0 SLOT 3 => enp3s4f5d1 > enp4s0f6 at /sys/devices/pci:00/:00:03.0 SLOT 3=> enp3s4f6 > enp4s0f6d1 at /sys/devices/pci:00/:00:03.0 SLOT 3 => enp3s4f6d1 > enp4s0f7 at /sys/devices/pci:00/:00:03.0 SLOT 3=> enp3s4f7 > enp4s0f7d1 at /sys/devices/pci:00/:00:03.0 SLOT 3 => enp3s4f7d1 > enp4s1 at /sys/devices/pci:00/:00:03.0 SLOT 3 => enp3s4f8 > (Device 1:0 => Function 8) > enp4s1d1 at /sys/devices/pci:00/:00:03.0 SLOT 3=> > enp3s4f8d1 (Device 1:0 => Function 8) > > enp68s0f0 at /sys/devices/pci:40/:40:03.0 SLOT 2 => enp68s2f0 > enp68s0f1 at /sys/devices/pci:40/:40:03.0 SLOT 2 => enp68s2f1 > enp69s0f0 at /sys/devices/pci:40/:40:03.0 SLOT 2 => enp69s2f0 > enp69s0f1 at /sys/devices/pci:40/:40:03.0 SLOT 2 => enp69s2f1 > > This way it is always able to determine the physical PCI slot the device is > in. > > This scheme still does have a limitation... the names may not be > persistent if PCI topology changes due to the PCI bus number still > being part of the name. I don't think the two should be mixed. The point of the hotplug slots was to be independent of the geography. If what you describe can't be fixed, the slot numbering scheme should just be turned off by default. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fwd: [PATCH] Add support for detecting NIC partitions on Dell Servers
On Tue, Nov 10, 2015 at 5:49 AM, Jordan Hargrave wrote: > Cleaned up linux coding style > > This patch will integrate some of the features of biosdevname into systemd. > The code detects the port and index for detecting NIC partitions. This creates > a new environment variable, ID_NET_NAME_PARTITION of the format > _ > > The patch will also decode SMBIOS slot number for NIC, and store in the > variable > ID_NET_NAME_SMBIOS_SLOT. Systemd does not have a method for naming > ports on a multi-port card plugged into a slot. Again, I don't think systemd should carry an SMBIOS parser. Sorry, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fwd: [PATCH] Add support for detecting NIC partitions on Dell Servers
On Mon, Nov 9, 2015 at 11:43 PM, Lennart Poettering wrote: > On Mon, 09.11.15 12:42, Jordan Hargrave (jhar...@gmail.com) wrote: > >> From: Jordan Hargrave >> >> This patch will integrate some of the features of biosdevname into systemd. >> The code detects the port and index for detecting NIC partitions. This >> creates >> a new environment variable, ID_NET_NAME_PARTITION of the format >> _ > > "partitions"? What's that supposed to be? SR-IOV? > >> The patch will also decode SMBIOS slot number for NIC, and store in >> the variable ID_NET_NAME_SMBIOS_SLOT. Systemd does not have a method >> for naming ports on a multi-port card plugged into a slot. > > Hmm, isn't this stuff the same as exported by the kernel as the > "index" field, i.e. SMBIOS Type 41? Can you elaborate on the relation > of that field and the stuff this patch adds? Sorry, systemd will not parse any smbios code. If these fields are generally useful, please add them as properties to the sysfs device, and systemd can possibly read them. Unrelated to the way we retrieve the information, the functionality sounds out-of-scope for udev's rather simple netdev naming; and for now, I see the simplicity rather as a feature than a limitation. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kernel and systemd boot sequence
On Thu, Oct 29, 2015 at 3:26 AM, kennedy wrote: > the boot sequence is it right ? > kernel --> initramfs --> switch_root --> systemd --> init & mount /etc/fstab > --> user login http://www.freedesktop.org/software/systemd/man/bootup.html Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Proposal: Add biosdevname naming scheme to systemd
On Tue, Oct 20, 2015 at 6:46 AM, Jordan Hargrave wrote: > On Mon, Mar 2, 2015 at 1:17 PM, Tom Gundersen wrote: >> Hi Jordan, >> >> On Mon, Mar 2, 2015 at 4:45 PM, Jordan Hargrave wrote: >>> There are currently two competing naming mechanisms for network cards, >>> biosdevname and systemd. Systemd currently has some limitations on naming >>> cards that use network partitioning or support SR-IOV. >> >> Could you point to an example so we can fix it? I thought all bug >> reports had been handled, but maybe I lost track of something. >> > > I have a quad-port NIC: > :40:00.0 = PCIE bridge (SMBIOS Slot 2) > :41:00.0 = Ethernet Device (port1) > :41:00.1 = Ethernet Device (port2) > :42:00.0 = Ethernet Device (port3) > :42:00.1 = Ethernet Device (port4) > > biosdevname would name these p2p1, p2p2, p2p3, p2p4 respectively. > > With systemd, it's ugly. I added the patch to get SMBIOS slot numbers > and I see systemd get RANDOM names depending on boot. > > Either: > s2f0 (p1) > s2f1 (p2) > p66s0f0 (p3) > p66s0f1 (p4) > > I also saw the opposite: > p65s0f0 (p1) > p65s0f1 (p2) > s2f0 (p3) > s2f1 (p4) That looks like an issue with the PCI hotplug drivers. You either need to load them early enough, or not at all. Or just disable the slot naming policy in a networkd link file. > Since systemd doesn't have a concept of a 'port', whichever devices > get named first (they are named in parallel, race conditions), the > other devices have name collision (function 0,1 are duplicate, but on > different bus). Systemd cannot have a concept of a port across otherwise independent devices. It would mean to mainain a counter across devices which again will depend and introduce names based on enumeration order. >>> Proposal is to add >>> support for biosdevname-like names as part of systemd. The names would be >>> created as a new environment variable ID_NET_NAME_BIOSDEVNAME. This could >>> then be used in the udev rules scripts to replace the external biosdevname >>> handler. This is unlikely going to happen. Biosdevname "invents" counters which are unreliable and introduce inter-device probe-order depenedencies. It causes the same problem as the the kernel's ethX, just less likely. Systemd cannot do that. >> I don't think this makes much sense. If biosdevname had been >> acceptable, the udev naming scheme would not have been introduced in >> the first place. Right, the udev naming would not have been there or used the same names if biosdevname was reliable, which it unfortunately isn't for the above mentioned reasons, > biosdevname is going away in new version of RHEL, so we will lose the > capability to detect if two 'virtual' NICs are actually the same > physical NIC. The naming in systemd doesn't have the capabilty of > showing relationship between physical/virtual (SR-IOV) NIC location > name. > >>> At least on Dell systems, systemd generates unusable names (PCI B:D:F vs >>> Slot#) for add-in cards as our PCIe slots do not have the ACPI _SUN method, >>> but they do have a SMBIOS slot number. >> >> Wouldn't the better approach be to simply add SMBIOS support to udev >> then? I must admit I don't know what challenges that entails, but >> seems like a natural first step. > > That could be possible. I've tried submitting a patch upstream for > kernel but hasn't been accepted yet. So SMBIOS parsing would have to > be part of systemd. The kernel would need to export the parsed result of SMBIOS at the PCI device, which systemd can use. Systemd itself will unlikely parse SMBIODS directly. In any case, there can be no concept introduction of any cross-device counters though. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SMACK runtime vs build-time checks? (aka: tmp.mount broke my boot)
On Sun, Oct 18, 2015 at 6:01 AM, Mantas Mikulėnas wrote: > So far all existing SELinux and SMACK options had runtime checks – if > systemd was built with +SMACK but the kernel wasn't, it still worked fine. > (Arch uses such a configuration.) > > But then https://github.com/systemd/systemd/issues/1571 added an option to > tmp.mount which only depends on the build-time option, which creates > problems when booting a non-SMACK kernel... > > Any ideas on how to fix it? All previous such fixes were for API filesystems > in mount-setup.c and could do flexible checks, but that clearly won't work > for mount units. I have reverted it. It needs a different solution. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] network interface names flipping
On Fri, Oct 16, 2015 at 4:44 PM, Olaf Hering wrote: > Since the introducion of the (un)predictable network interface names the > name of the single onboard interface on my Shuttle changes if I boot my > own .config or the kernel.rpm provided by openSUSE. I just threw up > hands and continue to boot with netnames=0 (or whatever). > > Now that same thing starts to happen on my Probook, and that makes me > wonder if the whole code should just be dropped from udev because it > obviously fails to work. Unless of course the goal is "UNpredictable" > > So, with my own kernel "eth0" becomes "enp2s0". And as I noticed just > now, with kernel.rpm its always named "ens1". > > What is udev doing wrong? > See http://pastebin.com/raw.php?i=Y5NJWJGF for some data. Your own kernel might not support PCI hotplug? The slot names might not be available if the support for them is missing. Btw, predictable means it will not change between reboots, that names will not depend on enumeration order within the same setup. It does not mean or promise, that added kernel/driver/firmware features will not result in different names. That is expected behavior. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Block device shutdown "hook"
On Fri, Oct 16, 2015 at 1:55 AM, Ian Pilcher wrote: > Does systemd provide any sort of "hook" mechanism to call a script > program when a block device is unmounted (or otherwise no longer being > used) on shutdown? > > I'm toying with the idea of creating an alternative way of managing > dm-cache devices -- something that will operate a bit more like bcache, > rather than LVM cache. It seems to be pretty straightforward, except > for the need to properly shutdown the dm-cache once any filesystems, > VGs, etc., on it are no longer in use. > > Is there a way to tell systemd how to "shut down" a block device? There is no facility to watch individual block devices, and there will probably never be such a thing in systemd. Systemd, as the very last step at system reboot/shutdown tries to stop/disassemle/unmount all active mounts/mapper/loop/... devices, but that works only for simple storage setups and has no hooks for other tools. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd and kernel process
On Thu, Oct 1, 2015 at 9:30 PM, Steve Dickson wrote: > > > On 10/01/2015 09:24 AM, Kay Sievers wrote: >> On Wed, Sep 30, 2015 at 10:49 PM, Steve Dickson wrote: >>> Is there a way for systemd to monitor kernel process? >>> By monitor I mean the existence. >> >> No, and there is no plan to do anything like that. >> >> Kernel tasks are kernel internals, and userspace must not make any >> assumptions about them. They can come and go at any time between any >> kernel versions. >> >> Custom tools can do what they need, but systemd should not offer to do >> that to users. > First all thanks for the response > > kernel process in question is nfsd. The number of thread > is kept in /proc/fs/nfsd/threads. > > So the idea would be doing a systemctl status nfsd > and number in /proc/fs/nfsd/threads is zero the > service would be deactive. An non-zero number the > service would active. > > Is this something systemd could be used for? No, not directly. There is no facility to watch /proc or any other similar interface for such changes. Plain /proc directories are just not capable of providing event information to userspace. The kernel's nfs implementation would need a character device where events are send out, or possibly a poll()able file in /proc, or something in /sys/devices/, or a similar approach, where udev can react to. Such interface could be used to signal systemd that userspace should react to state changes in the kernel. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] failed to change interface name (systemd-networkd)
On Thu, Oct 1, 2015 at 7:21 PM, James wrote: > Hello, just following up to see if there were any ideas on what may be > causing this. > > Any thoughts appreciated. > > On Wed, Sep 23, 2015 at 10:17 PM, James wrote: >> Hello, >> >> Hoping someone can point me in the right direction. I'm attempting to >> change the interface name (eth0 -> wired) on one of my servers. >> >> Here's the output from the journal: >> >> ~# journalctl --no-pager | grep -i wired >> Sep 23 17:11:15 vivid systemd-udevd[399]: error changing net interface >> name 'eth0' to 'wired0': Device or resource busy >> Sep 23 17:11:15 vivid systemd-udevd[399]: could not rename interface >> '2' from 'eth0' to 'wired0': Device or resource busy >> Sep 23 17:11:17 vivid sh[566]: Unknown interface wired0 >> Sep 23 17:11:17 vivid systemd[1]: Started ifup for wired0. >> Sep 23 17:11:17 vivid systemd[1]: Starting ifup for wired0... >> >> Here's what the .link contains: >> >> # cat 10-ethernet.link >> [Match] >> MACAddress=fa:16:3e:31:7a:4b >> [Link] >> Name=wired0 >> MACAddress=fa:15:33:55:33:44 >> >> And the .network: >> >> # cat 20-ethernet.network >> [Match] >> Name=wired* >> [Network] >> DNS=8.8.8.8 >> DNS=8.8.4.4 >> [Address] >> Address=10.1.1.190/24 >> [Route] >> Destination=0.0.0.0/0 >> Gateway=10.1.1.1 >> >> The MAC address of the interface changes properly, so I know that the >> unit is at least being read and parsed. >> >> As an aside, this is happening on Ubuntu 15.04. I've disabled >> NetworkManager and am relying, obviously, on systemd-networkd and >> systemd-resolved. I've also temporarily disabled dhcpd thinking that >> may have had something to do with the interface being busy, to no >> avail. >> >> Any thoughts on why the interface is busy resulting in the name change >> failing? Most likely you have some other daemon running, or a script executed by udev, or the interface is found by some init script, something that brings the interface up before the attempt to rename it by udev/networkd. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd and kernel process
On Wed, Sep 30, 2015 at 10:49 PM, Steve Dickson wrote: > Is there a way for systemd to monitor kernel process? > By monitor I mean the existence. No, and there is no plan to do anything like that. Kernel tasks are kernel internals, and userspace must not make any assumptions about them. They can come and go at any time between any kernel versions. Custom tools can do what they need, but systemd should not offer to do that to users. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] how to bind to other drivers using systemd
On Mon, Sep 28, 2015 at 8:48 PM, Flavio Leitner wrote: > On Mon, Sep 28, 2015 at 08:06:50PM +0200, Kay Sievers wrote: >> On Sun, Sep 27, 2015 at 11:37 PM, Flavio Leitner wrote: >> > I am looking for guidance on how to properly resolve driver binding >> > with systemd (which seems to me the best place to do that). >> >> This seems to be a too exotic and niche use case, nothing >> general-purpose enough to implement high-level knobs in systemd. > > These alternative drivers might be new yet, so there is no much around > them, but we need to start right to avoid problems in the future. > > Accelerated userspace datapath is one use case that changes the default > NIC driver to UIO or VFIO driver. Then you use DPDK applications for > fast packet processing or use DPDK integrated Open vSwitch for switching. > > Consider that Open Stack (WIP), Open Shift and maybe containers can use > the above setup, so isn't really a niche use case. It's pretty much a > requirement for NFV projects as well. > >> As you mention, you could use custom udev rules to actually bind a >> specific driver. I don't think we want anything more abstract in >> systemd. > > The problem with that is we can't stop the service to roll back the > driver. Or more importantly, create a dependency to, let's say, > start Open vSwitch only after the ports are bound to the right driver. > Or start an application that requires the NIC to be bound first. Sure, I understand all that. I would still call all that a niche and I still don't think it's systemd's job to solve such a problem. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] how to bind to other drivers using systemd
On Sun, Sep 27, 2015 at 11:37 PM, Flavio Leitner wrote: > I am looking for guidance on how to properly resolve driver binding > with systemd (which seems to me the best place to do that). This seems to be a too exotic and niche use case, nothing general-purpose enough to implement high-level knobs in systemd. As you mention, you could use custom udev rules to actually bind a specific driver. I don't think we want anything more abstract in systemd. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] bootctl: default mount point for the ESP partition.
On Tue, Sep 1, 2015 at 8:08 PM, Tomasz Torcz wrote: > On Tue, Sep 01, 2015 at 05:47:57PM +0100, Simon McVittie wrote: >> On 01/09/15 17:21, Goffredo Baroncelli wrote: >> > I discovered that bootctl assume as default mount point for the ESP >> > partition the /boot directory. Instead it seems to me that the most part >> > of distributions prefers /boot/efi. >> >> For some context, the reasoning for /boot/efi is: >> >> In some distributions (presumably including the (Fedora-based?) ones >> where this feature was developed), /boot is traditionally treated as >> mutable and unpackaged, like /var; so the packages include the kernel in >> /usr or /lib or something, and copy it into /boot. The cost of this is >> one extra copy of the kernel on-disk, which used to be a significant >> amount of space, although on modern disks it doesn't really matter. > > Not in Fedora: > $ rpm -ql kernel-core > /boot/.vmlinuz-4.2.0-0.rc7.git2.1.fc24.x86_64.hmac > /boot/System.map-4.2.0-0.rc7.git2.1.fc24.x86_64 > /boot/config-4.2.0-0.rc7.git2.1.fc24.x86_64 > /boot/initramfs-4.2.0-0.rc7.git2.1.fc24.x86_64.img > /boot/vmlinuz-4.2.0-0.rc7.git2.1.fc24.x86_64 They are %ghost files only. All actual content is in /usr where it belongs. > We even go as far as to provide dummy initramfs file (seen above). > It is replaced by proper initramfs generated during kernel install. > Existence of dummy file in package let RPM remove the generated initramfs > during package remove. > > >> AIUI, /boot/efi also makes it a bit easier to have the ESP remain >> unmounted or read-only when not in active use, which is good for its own >> robustness; a system crash corrupting an unmounted partition is less >> likely than corrupting a mounted filesystem. > > That's why systemd's generator creates automount unit (with timeout) > for /boot. Right, the ESP at /boot is never mounted unless it is accessed. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [ANNOUNCE] systemd v224
Here's the next version of systemd, v224: https://github.com/systemd/systemd/archive/v224.tar.gz This is mostly a bugfix release, containing many important fixes for kdbus. IMPORTANT: Please don't forget to sign up quickly to systemd.conf 2015, if you plan to attend. There's only a limited number of tickets available. For details see: https://systemd.events/ CHANGES WITH 224: * The systemd-efi-boot-generator functionality was merged into systemd-gpt-auto-generator. * systemd-networkd now supports Group Policy for vxlan devices. It can be enabled via the new boolean configuration option called 'GroupPolicyExtension='. Contributions from: Andreas Kempf, Christian Hesse, Daniel Mack, David Herrmann, Herman Fries, Johannes Nixdorf, Kay Sievers, Lennart Poettering, Peter Hutterer, Susant Sahani, Tom Gundersen -- Berlin, 2015-07-31 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Clarification around a segmentation fault from an udevd worker
On Sun, Jul 26, 2015 at 3:22 PM, SF Markus Elfring wrote: >> It should print the backtrace with the location where the error happened. > > Unfortunately, no. > > > Sonne:/home/elfring/Projekte/Bau/systemd # systemctl stop > systemd-udevd.service systemd-udevd-kernel.socket > systemd-udevd-control.socket && gdb systemd-udevd > … > worker [5347] terminated by signal 11 (Segmentation fault) > worker [5347] failed while handling > '/devices/pci:00/:00:02.0/usb3/3-2/3-2:1.0' > udev_monitor_send_device:/home/elfring/Projekte/systemd/lokal/src/libudev/libudev-monitor.c:770: > passed device to netlink monitor 0x55671520 > ^CUnloaded link configuration context. > [Inferior 1 (process 5339) exited normally] > (gdb) bt full > No stack. > > > Sonne:~ # journalctl -xe > … > Jul 26 15:03:38 Sonne systemd-udevd[5347]: auid=1000 uid=0 gid=0 > ses=1 pid=5347 comm="systemd-udevd" > exe="/home/elfring/Projekte/Bau/systemd/systemd-udevd" sig > Jul 26 15:03:38 Sonne kernel: systemd-udevd[5347]: segfault at 438 ip > 76fefc78 sp 7fffc6b0 error 4 in > libc-2.21.so[76fa7000+196000] Does: $ addr2line -e home/elfring/Projekte/Bau/systemd/systemd-udevd 0x76fefc78 show something? Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Clarification around a segmentation fault from an udevd worker
On Sat, Jul 25, 2015 at 6:11 PM, SF Markus Elfring wrote: > Hello, > > I would like to clarify the setting of device file permissions > for my needs. > > So I extended the debug output at some source code places to see > also better which lines are executed during my tests. > I built these extensions for calls of the function "log_debug" > on the current source files (last commit: > 3460810e8c61986a4605ad80c9e4805eb95cb5a1) > with the software "GCC 5.2.0" on my openSUSE Tumbleweed system. > > I am experimenting a bit with this fresh server program. > > Sonne:~ # systemctl stop systemd-udevd.service systemd-udevd-kernel.socket > systemd-udevd-control.socket && > /home/elfring/Projekte/Bau/systemd/systemd-udevd --debug > > > Now I wonder about an error message like the following. > > … > adding watch on '/dev/dm-0' > … > seq 2633 forked new worker [19879] > seq 2633 running > IMPORT builtin 'usb_id' /usr/lib/udev/rules.d/40-libgphoto2.rules:9 > unable to access usb_interface device of > '/sys/devices/pci:00/:00:02.0/usb3/3-2/3-2:1.0' > IMPORT builtin 'usb_id' returned non-zero > IMPORT builtin 'hwdb' /usr/lib/udev/rules.d/50-udev-default.rules:11 > worker [19879] terminated by signal 11 (Segmentation fault) > worker [19879] failed while handling > '/devices/pci:00/:00:02.0/usb3/3-2/3-2:1.0' > … > > I would appreciate your advices. Can you try to run it under gdb? $ gdb /home/elfring/Projekte/Bau/systemd/systemd-udev Type "r" at the prompt to run it. if it shows the same error here as when it runs without gdb, type "bt full" at the prompt It should print the backtrace with the location where the error happened. Please paste that output into an email. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Completion of error handling
On Sat, Jul 25, 2015 at 8:11 AM, SF Markus Elfring wrote: >> We accept contributions only in git-format-patch frmatted patches, >> best via github PRs. > > The higher level patch formats I'm trying to make you aware of will also > result in file changes which can be integrated by this content management > interface depending on your general acceptance for corresponding > software evolution. > > Examples: > * Scripts in the semantic patch language can be processed for occasional > patch generation by the Coccinelle software. > http://coccinelle.lip6.fr/papers.php > > * Aspect files could be transformed during an enhanced build process > by the AspectC++ software. > http://aspectc.org/Publications.php > > >>> Would you like to give thoughts for the extension of the software >>> development >>> toolbox a chance? >> >> I am sorry, your questions are not useful, because too generic. > > I hope that the software situation can also be improved by development > methodology > and technology you are more familiar with at the moment. > Would you like to reopen a specific bug report for example? No, systemd does not plan to do anything here. > https://github.com/systemd/systemd/issues/644 > > Update candidates: > * How do you think about to look at calls for functions from the application > programming interface "POSIX threads" again? > > * Does the usage of file output functions need another look? No, nothing needs more discussion or attention in the context of systemd. None of the above seems contain anything useful or is expected to contribute anything useful in the future. This is a development mailing list, we discuss patches and actual code, and not vague questions like you ask. Please stop posting this stuff or asking any more questions like this. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] About github repo and release tarball change
On Thu, Jul 9, 2015 at 11:43 AM, Armin K. wrote: > I discovered a commit 2c8849add40805256156a36d7ef8c54cf019e29e > by Kay Sievers which literally broke the make dist > target. A lot of += were removed, making a target that appears > more than once redefine itself each time instead of appending > the new lines to an already existing target which made > make dist ommit a few essential files in a tarball. Specifics please. "Few essential files" is a pretty useless information. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADSUP] systemd-222 around the corner
On Tue, Jul 7, 2015 at 10:10 AM, Michael Olbrich wrote: > On Mon, Jul 06, 2015 at 07:54:41PM +0200, David Herrmann wrote: >> We intend to release v222 tomorrow. If anyone has open issues that >> need to be in that release, please speak up. Right now, the release >> consists almost exclusively of bug-fixes, and we want to get those >> into distributions. > > This will be a release without 'distcheck' tarballs, right? Without any tarballs at all. We will only sign the git tag. Putting unsigned tarballs on a plain file server is not enough today, and we do not want be required to sign them. Therefore, tarballs need to be downloaded from github or the user creates them from the git repository. > If that's the > case, then please merge https://github.com/systemd/systemd/pull/505 or make > libgcrypt optional in some other way. Hmm, this seems a bit out-of-scope for the systemd build system. Why don't you just add the usually used stub lines for things you want to optimize out: echo 'AC_DEFUN([AM_PATH_LIBGCRYPT],[:])' > m4/gcrypt.m4 , Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Remove accelerometer helper
On Fri, May 22, 2015 at 3:42 PM, Bastien Nocera wrote: > It's moved to the iio-sensor-proxy D-Bus service. > --- > .gitignore | 1 - > Makefile.am| 15 -- > rules/61-accelerometer.rules | 3 - > src/udev/accelerometer/Makefile| 1 - > src/udev/accelerometer/accelerometer.c | 303 https://github.com/systemd/systemd/pull/387 Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] ata_id: unbotch format specifier
On Wed, Jun 24, 2015 at 1:48 AM, Jan Engelhardt wrote:
> Commit v218-247-g11c6f69 broke the output of the utility. "%1$" PRIu64
> "x" expands to "%1$lux", essentially "%lux", which shows the problem.
> u and x cannot be combined, u wins as the type character, and x gets
> emitted verbatim to stdout.
>
> References: https://bugzilla.redhat.com/show_bug.cgi?id=1227503
> ---
> src/udev/ata_id/ata_id.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/udev/ata_id/ata_id.c b/src/udev/ata_id/ata_id.c
> index cc1bf45..7ba0b7f 100644
> --- a/src/udev/ata_id/ata_id.c
> +++ b/src/udev/ata_id/ata_id.c
> @@ -639,8 +639,8 @@ int main(int argc, char *argv[])
> */
> word = identify.wyde[108];
> if ((word & 0xf000) == 0x5000)
> -printf("ID_WWN=0x%1$"PRIu64"x\n"
> - "ID_WWN_WITH_EXTENSION=0x%1$"PRIu64"x\n",
> +printf("ID_WWN=0x%1$" PRIx64 "\n"
> + "ID_WWN_WITH_EXTENSION=0x%1$" PRIx64 "\n",
Modern isn't always better. :) Applied.
Thanks,
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Reload manager defaults at daemon-reload
On Tue, Jun 23, 2015 at 2:47 PM, Thomas Blume wrote: > > "systemctl daemon-reload" should also update the manager defaults from > /etc/systemd/system.conf. > For details, see: > http://lists.freedesktop.org/archives/systemd-devel/2015-June/033062.html Any specific reason not to use github? Patches can still be handled on the mailing list, but it's much easier for everybody to use github and track things there and get automatic build testing before a possible merge. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] FR: different gcrypt options for joornald and importd
On Mon, Jun 8, 2015 at 7:58 PM, Lennart Poettering wrote: > On Mon, 08.06.15 19:24, Alexey Shabalin (a.shaba...@gmail.com) wrote: >> > You can build systemd twice to do this. On Fedora we build it twice >> > for example to get python2 as well as python3 modules. >> > >> > But: what's the reason for this? THis sounds like a weird choice? >> > >> We are still support separate /usr, but libgcrypt in /usr/lib now (i am >> open request to mantainer for move libgcrypt to /lib) >> libgcrypt in /usr/lib critical for journal and not important for importd. > > I am not sure this is really something to support upstream. I mean, > LUKS support generally needs libgcrypt too, and hence it's really > wrong to assume gcrypt can be located in /usr if you use split > usr... I am not sure we want to support systems with split usr and > gcrypt in /usr. This topic came up in a different thread too: https://github.com/systemd/systemd/pull/331 I'm convinced we should limit configure options to avoid external dependencies, but not add options for individual tools. The matrix of options we want to support upstream should be minimal and not cover rather exotic requirement or setups. Also this should still be valid as much as possible and indicate the systemd-wide flags: $ /usr/lib/systemd/systemd --version systemd 221 +PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] no tar balls at release time
On Tue, Jun 23, 2015 at 4:02 AM, Dave Reisner wrote: > On Tue, Jun 23, 2015 at 01:21:36AM +0200, Kay Sievers wrote: >> We currently considering to stop creating release tar balls. > > What's the motivation for this change? We focus on git, and git only. We do not want to sign tar balls to distribute, but rely on signed git tags only. Pre-building stuff to put into tar balls creates too many restrictions. It is just plain wrong to pre-build and ship things like man pages, which depend on common configure options. > I suspect that with this, 'make > distcheck' will never again be run and it will eventually break > build configurations which don't align with what the CI tests. We synced the "make dist" and "git archive" tar balls as much as possible now. Even the autotools created one will not contain any pre-built stuff anymore besides the autofoo itself. We might continue to run distcheck in the CI, but we don't know anything for sure at that point in time, only that tar balls are not part of the release anymore. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] no tar balls at release time
We currently considering to stop creating release tar balls. For build systems which still require them, they can be created locally from the upstream git repository with: git archive --format=tar --prefix=systemd-$(VERSION)/ $(VERSION) | \ xz > systemd-$(VERSION).tar.xz These tar balls will not include the "500k of shell scripts" added by autotools. These files need to be added to the extracted tarball by running ./autogen.sh. These tar balls will also not include any generated content like fonts, man, html pages. This is intentional. Please test these setups locally if that model will work in your setups, and what would possibly need to be fixed in the git tree to make that easier for you. The Fedora build setup was happy without any adjustments to take the git created tar ball instead of the autotools created one. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v221
On Sat, Jun 20, 2015 at 6:08 PM, cee1 wrote: > 2015-06-20 2:06 GMT+08:00 Lennart Poettering : >> On Fri, 19.06.15 16:06, Lennart Poettering (lenn...@poettering.net) wrote: >> >>> Heya! >>> >>> It's primarily a bugfix release, but we also make sd-bus.h and >>> sd-event.h public. (A blog story on sd-bus and how to use it will >>> follow shortly.) >> >> The blog story is online now: >> >> http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html >> >> Enjoy, > Glad to see this :) > > BTW, what about libabc? Would libsystemd be part of libabc? Also > libsystemd is a linux-specific library, will it further ports and > integrates some kernel libraries to libabc?? Assuming you mean this: https://git.kernel.org/cgit/linux/kernel/git/kay/libabc.git Libabac is an example stub that does absolutely nothing, and in the future it will keep doing nothing. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v221
On Fri, Jun 19, 2015 at 5:07 PM, Filipe Brandenburger wrote: > Guys let's try to be constructive here... > > This time it shouldn't be too painful for downstreams since the revert > was the last patch to the man subtree so just a git revert of that > should get your trees to the state you need to get v221 packages for > Debian and Ubuntu. In that sense, I think we're still (slightly) > better off than we were in v220 and I think we have all we need to > solve this one for good in v222. > > And let's use the momentum to try to solve this soon, in which case > you could even replace the revert of that commit with the backport of > the next one (which will probably remove the disted manpages). I was involved in the decision to revert it. And I'm sure we should not add the patch back. The split-usr option is not much more than an "upgrade path" for traditional unix layouts to merge the operating system into a single directory. The split-usr option is nothing upstream systemd could fully suport. We need the unified layout for several options systemd offers, and more and more new things will rely on it. Split-usr will not got away anytime soon, but it will get less and less support regarding new features we add to systemd. The last-minute revert was not properly communicated, I am sorry for that, but the technical reasons for the revert are still true. Not dist'ing the man pages does not make the feature itself correct. We should not provide options to render the man page content inconsistently. The search paths would need to be mangled too, or none of them. But again, I am against upstream support for man split-usr man pages because systemd cannot fully support split-usr anyway, and should not pretend it does. Please do that downstream where the classic file system layout is supported. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Why we need to read/save random seed?
On Wed, Jun 17, 2015 at 2:28 PM, Reindl Harald wrote: > > Am 17.06.2015 um 14:21 schrieb cee1: >> >> 2015-06-17 16:40 GMT+08:00 Reindl Harald : systemd-random-seed.service will load the "seed on disk" to /dev/urandom, and save a "seed" to disk when shutdown, right? The article at http://www.2uo.de/myths-about-urandom/ suggests us saving the seed as soon as there is enough entropy(means read from /dev/random? if returns, there's enough entropy), >>> >>> >>> well, so you read the seed and inject it to /dev/random followed by read >>> /dev/random and overwrite the seed for the next boot - don't sounds that >>> good >> >> >> What I means is: >> 1. Load a saved seed to /dev/urandom. >> 2. The service read /dev/random, which will block until kernel thinks >> there's enough entropy - then the Random Number should be good? >> 3. Save the random number returned in step 2 on disk > > > oh yeah block at boot sounds what we want. The suggestion is reasonable and part of a useful technical discussion. Your reply is not constructive or funny, and even plain wrong in its assumptions. Please keep such comments to yourself or you will be moderated again. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
On Wed, Jun 3, 2015 at 7:06 PM, David Timothy Strauss wrote: > On Tue, Jun 2, 2015 at 5:03 PM Kay Sievers wrote: >> >> Could you please check your old repos at: >> https://github.com/systemd >> and move or delete them if they are no longer needed. One of them at >> least has a comment like "This is old. Actual repo is on my >> davidstrauss account. Will clean up soon. (2012)" >> >> We should only keep repos here for code that we actually host. Cloned >> repos should only be there if they are supposed to be shared by >> multiple people to work on them at the same time, everything else >> should be done in a user repo. > > This is now done. Great. > The only remaining forked repository is the Linux kernel, > which appears to be for kdbus work. Yeah, for now we use that as the public interface for the kdbus work, for people to pull our changes from. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to create a user instance service that requires a network connection?
On Wed, Jun 3, 2015 at 6:32 PM, Will S wrote: > My understanding is that the system and user instances of systemd are > completely isolated from each other. So I can not create a user unit file > with the option Requires=network-online.target. Is there any way for a user > instance service to get this functionality of waiting for the network to be > online before starting? From what I can tell, the systemd user instance is > relatively new. If it is not possible now, is there any planned feature that > would allow this functionality in the future that I should watch for? No. And there are no plans. Better make your application network aware and adjust to the environment during runtime. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
On Wed, Jun 3, 2015 at 1:51 AM, David Timothy Strauss wrote: > Looks like everything's in place now at the new github.com/systemd/systemd > home. > > I've halted the Jenkins CI from pushing to that repository (which was > formerly the mirror updated whenever CI passed). I'll probably update CI to > merely push a branch like "master-passing" so there's still a way to get the > latest passing commit, but it's just disabled for now. Great. Thanks. Could you please check your old repos at: https://github.com/systemd and move or delete them if they are no longer needed. One of them at least has a comment like "This is old. Actual repo is on my davidstrauss account. Will clean up soon. (2012)" We should only keep repos here for code that we actually host. Cloned repos should only be there if they are supposed to be shared by multiple people to work on them at the same time, everything else should be done in a user repo. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
On Tue, Jun 2, 2015 at 4:34 PM, Martin Pitt wrote: > David Herrmann [2015-06-02 13:06 +0200]: >> Our preferred way to send future patches is "the github way". This >> means sending pull-requests to the github repo. Furthermore, all >> feature patches should go through pull-requests and should get >> reviewed pre-commit. This applies to everyone. Exceptions are >> non-controversial patches like typos and obvious bug-fixes. > > Makes sense. On the operational level, should we use the > "automatically merge" feature of git hub once approving? On the plus > side it's very convenient, but you'll get one "Merge" commit for every > PR (which is often just one commit), so we'd almost double the entries > in "git log". Or can github be told to not do that? > > Merging manually is quite a bit of work, as you have to add a new > remote every time, fetch that, and pull from it. But it does keep a > cleaner git log history. Use github. With the decision to move to github, we need to accept the github model and with that accept possible cosmetic issues. If it turns out to be too crazy, we have to question github, not fiddle around with local rebases. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] Makefile.am
On Fri, May 29, 2015 at 6:53 PM, Lennart Poettering wrote: > On Fri, 29.05.15 09:45, Filipe Brandenburger (filbran...@google.com) wrote: > >> Hi, >> >> I was thinking about this one recently... >> >> I really think the "correct" solution is for man/custom-entities.ent >> to be generated by configure from a man/custom-entities.ent.in >> template instead. I haven't really checked if that's viable though, if >> configure knows about every variable it will need, etc. but I was >> planning to look into it at some point in the near future. > > iirc one should not generate sources with autoconf .in stuff, but > always with explicit sed invocations. There was was something avout > this in the autoconf docs, don't really remember where. "Similarly, you should not rely on AC_CONFIG_FILES to replace bindir and friends in your shell scripts and other files; instead, let make manage their replacement. For instance Autoconf ships templates of its shell scripts ending with ‘.in’, and uses a makefile snippet similar to the following to build scripts like autoheader and autom4te" http://www.gnu.org/software/autoconf/manual/autoconf.html#Installation-Directory-Variables Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] 60-persistent-storage.rules: add NVMe disks and partitions (again)
On Thu, May 14, 2015 at 6:12 PM, Lennart Poettering wrote: > On Thu, 14.05.15 09:10, Per Bergqvist (p...@bst.lu) wrote: > >> There was a request for addition of NVMe disks Feb 10 2014 by Harald Hoyer >> which was >> sort of rejected by Kay Sievers by referring to “we should find out what to >> do for nvme before >> adding new users of scsi_id”. > > Well, nothing changed really: we'd like to remove scsi_id from > systemd/udev upstream. Please ask sg_utils to pick it up > instead. We'll continue to support the status quo for a while longer, > but it can't stay this way, and we shouldn't add new features to > it while it's in limbo. Yeah, not sure how much NVMe has to do with SCSI. It might make more sense to export the primary values to identify these devices by the kernel driver in /sys, instead of excapsulating/emulating the SCSI behavior. The kernel does that for other block device types like mmc too. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] About the exit of systemd-udevd
On Tue, Apr 14, 2015 at 4:47 PM, Tom Yan wrote: > Under certain conditions, I discovered that commands like `udevadm > control --exit` or `systemctl stop systemd-udevd` (with the sockets > stopped beforehand) will kill udevd before it finish its jobs which > triggered by `udevadm trigger` (I presume applying a written udev rule > is one of them). > > Is this acceptable/expected? If so, is there any way to guarantee the > jobs is done before it gets killed? It is expected, udevd will finish everything that is currently already running and do a clean shutdown, but not process any new events which might be triggered and pending. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] automount: add expire support
On Tue, Apr 21, 2015 at 8:45 PM, Lennart Poettering wrote: > On Tue, 14.04.15 22:01, Michael Olbrich (m.olbr...@pengutronix.de) wrote: > > I added some more logging (so that automount_dispatch_expire() can > never fail without this being logged) and applied it! > > I only gave this superficial testing though, please check if this all > still works fine for you now! I added 120 seconds for the EFI FAT /boot mount: http://cgit.freedesktop.org/systemd/systemd/commit/?id=163ab2961268232e1cb49e990a8ccefe24b7649f $ journalctl -b -u boot.mount Apr 22 00:49:22 ank systemd[1]: Mounting EFI System Partition... Apr 22 00:49:22 ank systemd[1]: Mounted EFI System Partition. Apr 22 00:51:24 ank systemd[1]: Unmounting EFI System Partition... Apr 22 00:51:24 ank systemd[1]: Unmounted EFI System Partition. Apr 22 00:51:48 ank systemd[1]: Mounting EFI System Partition... Apr 22 00:51:48 ank systemd[1]: Mounted EFI System Partition. Apr 22 00:53:51 ank systemd[1]: Unmounting EFI System Partition... Apr 22 00:53:51 ank systemd[1]: Unmounted EFI System Partition. Michael, thanks a lot for adding that feature. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] rules: Enable runtime device power management on Intel HDA controllers
On Mon, Apr 20, 2015 at 8:11 PM, David Herrmann wrote: > Hi > > On Sun, Apr 19, 2015 at 11:46 PM, Matthew Garrett wrote: >> On Sun, Apr 19, 2015 at 11:37:31PM +0200, Kay Sievers wrote: >>> I'm not convinced that any such broad matches for power management >>> belong into udev at all. Udev can carry specific device matches, or >>> carry data that cannot be determined from the device itself, like the >>> mouse resolution and such, but like in these rules, reading the vendor >>> from the kernel and unconditionally flipping a bit back into the >>> kernel does not look like a task for udev or userspace in general. >> >> Is there any possibility that you can be convinced? > > I'd much prefer if this was hwdb based. This way, we have a sane > database that just sets something like POWER_CONTROL=foobar, which we > can then apply via udev. Given that the power-control issues seem to > be totally random, hwdb really sounds like the nicer solution. > > Any reason why hwdb would not work? The question here is more why systemd/udev should get into the power management business at all. So far, applying unconditional policy sounds like a job for the kernel, not userspace. Either it can be safely ensabled, then it can be done right away by the kernel driver, or it isn't safe, then using udev does not solve any problem. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev interface naming for SR-IOV VFs
On Tue, Apr 14, 2015 at 12:11 PM, Ido Barkan wrote: > Hi all, > > I am VDSM developer in the Ovirt project. > > We are implementing support for SR-IOV network cards. Afer the changing of > the number of VFs on the card and programmatically querying for all links > (we use libnl for this) we observe that *during the iteration* over the links > some of them were renamed by udev and still were not. Meanning, some of them > are called 'ethN' and some are called 'enp2sNf2' (where N is an arbitrary > number). Also, there are times that not all of the devices are returned from > libnl. > After a _while_ everything stabilizes (# of interfaces and names). > > My questions: > 1. Is this what you would expect from udev? Meaning, this is just async > behavior? Udev has no specific knowledge, there is nothing really it could provide here. > 2. Is there a way to _know_ programmticaly that everything was probed and > renamed? >Not a heuristic? Only if you know which devices to expect and listen to udev monitor events when they appear and react to them. The device handling is finished before the event is sent out. Udev generally has no idea when things have been probed or what to wait for. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] rules: Enable runtime device power management on Intel HDA controllers
On Sat, Apr 18, 2015 at 9:39 PM, Matthew Garrett wrote: > (Resending from the correct address) > > On Sat, Apr 18, 2015 at 07:51:26PM +0200, Kay Sievers wrote: > >> It looks like an unconditional static assignment. >> >> Why should udev carry this? We generally do not want to do things like >> that. Udev can help if there is conditional policy or complex >> cross-subsystem knowledge is needed, but this looks just like a job >> for the kernel and not userspace. > > 1) having this in udev makes it easier for users to alter the > configuration - the kernel can then afford to be conservative until we > enable power management, rather than potentially breaking the device the > moment pm is enabled without any ability to recover it. There is no significant difference between a default unconditional udev setting and a kernel command line option to control such behavior if needed. > 2) this config is currently static, but the appropriate policy may turn > out to be more complicated in some scenarios (interactions between > devices and their upstream bridges, for instance, or USB Bluetooth > controllers that are on-die with a PCI wifi controller without having a > common exposed bus topology yet still having pm interactions). Splitting > this between udev and the kernel makes it more difficult to determine > the source of the policy and debug it. Either the setting is safe to use or not, the source of this policy is not really relevant here. The loop through userspace does not sound useful. > 3) we already have examples of this in udev, so people already expect to > find it here. Which should be a reason to carefully check these examples if they should stay in udev, not a reason to justify to add more. I'm not convinced that any such broad matches for power management belong into udev at all. Udev can carry specific device matches, or carry data that cannot be determined from the device itself, like the mouse resolution and such, but like in these rules, reading the vendor from the kernel and unconditionally flipping a bit back into the kernel does not look like a task for udev or userspace in general. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] rules: Enable runtime device power management on Intel HDA controllers
On Sat, Apr 18, 2015 at 6:11 PM, Matthew Garrett wrote:
> From: Matthew Garrett
>
> PCI power management seems to work fine on Intel HDA controllers, so let's
> turn that on. We can expand this to other vendors based on user feedback.
> +ACTION=="add", SUBSYSTEM=="pci", ATTR{class}=="0x040300",
> ATTR{vendor}=="0x8086", ATTR{power/control}="auto"
It looks like an unconditional static assignment.
Why should udev carry this? We generally do not want to do things like
that. Udev can help if there is conditional policy or complex
cross-subsystem knowledge is needed, but this looks just like a job
for the kernel and not userspace.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] fsck: Add support for EFI variable based fsck indication
On Thu, Apr 9, 2015 at 6:58 PM, Reindl Harald wrote: > > Am 09.04.2015 um 18:52 schrieb Kay Sievers: >> >> On Thu, Apr 9, 2015 at 3:02 PM, "Jóhann B. Guðmundsson" >> wrote: >> >>>> We generally follow the rule: we develop for the future, not for the >>>> past. A file system like ext234 is clearly not the future, >>> >>> >>> A filesystem like ext is being actively developed,maintained and new >>> features being added to it. >>> >>> While filesystems are being supported and actively developed,maintained >>> and >>> new features added to them you hardly can consider them not part of the >>> future now can you despite their "shortcomings" compared to eachother. >> >> >> It is more about that: >> >> A filesystem which requires an out-of-kernel fsck, but has no proper >> indication in the superblock to indicate that, and integrates that way >> with its own fsck tool, is nothing systemd needs to work around. >> >> If the filesystem wants better integration, it has to provide the >> needed features not rely on hacks on mis-use of other facilities like >> EFI or the kernel cmdline, or flag files, to cover for the missing >> feature. >> >> At a general level, an out-of-kernel fsck for a filesystem used as the >> rootfs soulds really really weird in the year 2015. And this is not >> neccessarily about btrfs, xfs solved that problem many many years ago > > > http://linux.die.net/man/8/xfs_check > > "If the filesystem is very large (has many files) then xfs_check might run > out of memory. In this case the message out of memory is printed" sounds > really so much better than ext4 Yeah, that is why Red Hat Enterprise Linux uses XFS as the default. Too bad for them that they did not ask for you valuable expert advise. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] fsck: Add support for EFI variable based fsck indication
On Thu, Apr 9, 2015 at 3:02 PM, "Jóhann B. Guðmundsson" wrote: >> We generally follow the rule: we develop for the future, not for the >> past. A file system like ext234 is clearly not the future, > > A filesystem like ext is being actively developed,maintained and new > features being added to it. > > While filesystems are being supported and actively developed,maintained and > new features added to them you hardly can consider them not part of the > future now can you despite their "shortcomings" compared to eachother. It is more about that: A filesystem which requires an out-of-kernel fsck, but has no proper indication in the superblock to indicate that, and integrates that way with its own fsck tool, is nothing systemd needs to work around. If the filesystem wants better integration, it has to provide the needed features not rely on hacks on mis-use of other facilities like EFI or the kernel cmdline, or flag files, to cover for the missing feature. At a general level, an out-of-kernel fsck for a filesystem used as the rootfs soulds really really weird in the year 2015. And this is not neccessarily about btrfs, xfs solved that problem many many years ago. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] bootloader time on a non-EFI bootloader
On Thu, Apr 9, 2015 at 11:28 AM, Lennart Poettering wrote: > On Mon, 16.03.15 11:29, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: >> >> I would like to pass the time it was spent in bootloader to systemd. >> Is there a kernel command line to pass this information on non EFI >> bootloader? Or is there an another way? > > I am open to add this, but I really don't want to see tons of > different "drivers" to read this data added to systemd. Right, mis-using the kernel command line does not look like an option for support in systemd. > Hence the way > I think this should work, is adding a generic interface to the kernel > to /sys/firmware/timing or so, where this information can be read > from. We'd then make systemd read that. And wherever the information > comes from would be a kernel internal decision, and could be > implemented in a myriad of different ways for different architectures. Yeah, something like that. For the non-EFI setups, the kernel boot protocol could have an extension where the boot loader or the firmware can pass generic key/value pairs to the starting kernel and the kernel exports them; just like the volatile variables of EFI provide us. > Also note that ACPI 5.0 exports this timing information in a generic > way anyway. Given that ACPI is fairly standard and apparently is even > what embedded is standardizing on I'd be open to adding native support > for parsing this info from ACPI to systemd, if it's easy enough. The ACPI "Firmware Basic Boot Performance Data Record" provides some values on more recent firmware versions: $ sudo ./test-boot-timestamp ACPI FPDT: loader start=7.994s exit=8.115s duration=120ms EFI Loader: start=7.994s exit=8.080s duration=86ms Firmware began 8.115550s before kernel. Loader began 120.791ms before kernel. The ACPI values are accessible after the system booted up, just like EFI variables are. For platforms which do not have anything like that, the kernel boot protocol still sounds like the closest thing to fill the gap. > However, beyond that: please abstract this in the kernel, I don#t want > to see tons of drivers for this in systemd. Yeah, we should not invent things here to cover for missing core features. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/5] udev.pc: install to pkgconfiglibdir
On Wed, Apr 8, 2015 at 8:50 PM, Marc-Antoine Perennou
wrote:
> Well, on one hand, we may have the need for multilib stuff to find the
> native binaries, as you said.
>
> On the other hand we have my case. Just a bit of background so that
> you understand where these patches come from:
> I'm developper for the Exherbo distribution, and we recently changed
> completely our filesystem layout when we introduced full
> cross-compilation support.
> We now have everything in /usr/arch (when you put stuff into /usr/lib/arch).
> We thus have complete trees for each arch with
> /usr/arch/{bin,sbin,lib,libexec,include} and want those to be
> completely independant.
> We try to keep as vanilla as possible and I think we're quite good at
> it, but inevitably we reach corner cases where it's impossible.
Yeah, that all makes sense. And we can have both. :)
> If you think it might make sense to have everything in
> libdir/pkgconfig (depite the redundancy of information), I'd be very
> happy.
> If instead you go and put everything into /usr/share/pkgconfig, it
> won't hurt that much for us to keep this patch downstream.
Right, we have to find out what we want to support here, cross-compile
or secondary arch things.
Only one thing is clear at the moment, that the current status makes
no sense. :)
We got $libdir for the secondary arch:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=eb39a6239c631873db62f6a942e6cb3dab0a2db4
But then we took $libdir as the reason to move the file and make it
inaccessible for the secondary arch:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=aec432c6134146e138124c4130be2ee89dca07fa
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/5] udev.pc: install to pkgconfiglibdir
On Wed, Apr 8, 2015 at 8:10 PM, Marc-Antoine Perennou wrote: > On 8 April 2015 at 20:02, Kay Sievers wrote: >> On Wed, Apr 8, 2015 at 7:52 PM, Marc-Antoine Perennou >> wrote: >>> On 8 April 2015 at 19:46, Kay Sievers wrote: >>>> On Wed, Apr 8, 2015 at 7:34 PM, Marc-Antoine Perennou >>>> wrote: >>>>> On 8 April 2015 at 18:47, Kay Sievers wrote: >>>>>> On Tue, Apr 7, 2015 at 8:54 PM, Marc-Antoine Perennou >>>>>> wrote: >>>>>>> --- >>>>>>> Makefile.am | 3 +-- >>>>>>> 1 file changed, 1 insertion(+), 2 deletions(-) >>>>>>> >>>>>>> diff --git a/Makefile.am b/Makefile.am >>>>>>> index 9fa4223..9b769ee 100644 >>>>>>> --- a/Makefile.am >>>>>>> +++ b/Makefile.am >>>>>>> @@ -3725,8 +3725,7 @@ udevconfdir = $(sysconfdir)/udev >>>>>>> dist_udevconf_DATA = \ >>>>>>> src/udev/udev.conf >>>>>>> >>>>>>> -sharepkgconfigdir = $(datadir)/pkgconfig >>>>>>> -sharepkgconfig_DATA = \ >>>>>>> +pkgconfiglib_DATA += \ >>>>>>> src/udev/udev.pc >>>>>> >>>>>> This is all backwards. The systemd.pc file is also in the wrong location. >>>>>> >>>>>> These GENERIC files are supposed to be found by the primary AND the >>>>>> secondary arch at the same time, at the GENERIC location, not in a >>>>>> arch-specific libdir. >>>>>> >>>>>> How would the 32bit build find this file on a 64bit compat-arch/multilib >>>>>> system? >>>>>> >>>>>> Kay >>>>> >>>>> Well, let's imagine a full cross-compilation toolchain, with >>>>> CHOST-prefixed tools. >>>>> >>>>> x86_64 stuff will get built with x86_64-pc-linux-gnu-gcc >>>>> i686 stuff will get built with i686-pc-linux-gnu-gcc >>>>> (and you could add a lot of non-native archs here like arm, mips & co) >>>>> >>>>> x86_64-pc-linux-gnu-pkg-config will look into /usr/lib64/pkgconfig and >>>>> /usr/share/pkgconfig >>>>> i686-pc-linux-gnu-pkg-config will look into /usr/lib32/pkgconfig and >>>>> /usr/share/pkgconfig >>>>> >>>>> You says that systemd is in the wrong location, so let's see what's >>>>> going on with its >>>>> current location, and then if we move it to /usr/share >>>>> >>>>> Current location, libdir/pkgconfig/systemd.pc >>>>> >>>>> x86_64-pc-linux-gnu-pkg-config finds /usr/lib64/pkgconfig/systemd.pc >>>>> containing, >>>>> amongst other things, libdir which is arch specific, /usr/lib64 and >>>>> systemdutildir >>>>> which contains arch-specific binaries (yes, /usr/lib64/systemd/systemd >>>>> *is* an >>>>> ELF64 binary using an x86_64 interpreter. >>>>> >>>>> i686-pc-linux-gnu-pkg-config finds /usr/lib32/pkgconfig/systemd.pc (since >>>>> it has >>>>> been cross-compiled too) and is pretty happy with that. >>>>> >>>>> arm-whatever-pkg-config finds /usr/arm-whatever/lib/systemd.pc and is >>>>> happy with it. >>>>> >>>>> If you move it to /usr/share/pkgconfig >>>>> >>>>> x86_64-pc-linux-gnu-pkg-config finds /usr/share/pkgconfig/systemd.pc >>>>> and is happy with it >>>>> >>>>> i686-pc-linux-gnu-pkg-config finds /usr/share/pkgconfig/systemd.pc and >>>>> tries linking to >>>>> x86_64 libraries >>>>> >>>>> arm-whatever-pkg-config finds /usr/share/pkgconfig/systemd.pc and >>>>> tries linking to >>>>> x86_64 libraries + it gets the path towards binaries its target won't >>>>> even be able to execute. >>>>> >>>>> >>>>> Hope that helps understanding the rational of putting pkgconfig files >>>>> pointing to >>>>> arch-specific libs/bins into an arch-specific place. >>>>> >>>>> >>>>> A good example of a pkgconfig file that is ok to install into >>>>> /usr/share/pkgconfig is >>>>> xorg-macros.pc w
Re: [systemd-devel] [PATCH 2/5] udev.pc: install to pkgconfiglibdir
On Wed, Apr 8, 2015 at 7:52 PM, Marc-Antoine Perennou wrote: > On 8 April 2015 at 19:46, Kay Sievers wrote: >> On Wed, Apr 8, 2015 at 7:34 PM, Marc-Antoine Perennou >> wrote: >>> On 8 April 2015 at 18:47, Kay Sievers wrote: >>>> On Tue, Apr 7, 2015 at 8:54 PM, Marc-Antoine Perennou >>>> wrote: >>>>> --- >>>>> Makefile.am | 3 +-- >>>>> 1 file changed, 1 insertion(+), 2 deletions(-) >>>>> >>>>> diff --git a/Makefile.am b/Makefile.am >>>>> index 9fa4223..9b769ee 100644 >>>>> --- a/Makefile.am >>>>> +++ b/Makefile.am >>>>> @@ -3725,8 +3725,7 @@ udevconfdir = $(sysconfdir)/udev >>>>> dist_udevconf_DATA = \ >>>>> src/udev/udev.conf >>>>> >>>>> -sharepkgconfigdir = $(datadir)/pkgconfig >>>>> -sharepkgconfig_DATA = \ >>>>> +pkgconfiglib_DATA += \ >>>>> src/udev/udev.pc >>>> >>>> This is all backwards. The systemd.pc file is also in the wrong location. >>>> >>>> These GENERIC files are supposed to be found by the primary AND the >>>> secondary arch at the same time, at the GENERIC location, not in a >>>> arch-specific libdir. >>>> >>>> How would the 32bit build find this file on a 64bit compat-arch/multilib >>>> system? >>>> >>>> Kay >>> >>> Well, let's imagine a full cross-compilation toolchain, with >>> CHOST-prefixed tools. >>> >>> x86_64 stuff will get built with x86_64-pc-linux-gnu-gcc >>> i686 stuff will get built with i686-pc-linux-gnu-gcc >>> (and you could add a lot of non-native archs here like arm, mips & co) >>> >>> x86_64-pc-linux-gnu-pkg-config will look into /usr/lib64/pkgconfig and >>> /usr/share/pkgconfig >>> i686-pc-linux-gnu-pkg-config will look into /usr/lib32/pkgconfig and >>> /usr/share/pkgconfig >>> >>> You says that systemd is in the wrong location, so let's see what's >>> going on with its >>> current location, and then if we move it to /usr/share >>> >>> Current location, libdir/pkgconfig/systemd.pc >>> >>> x86_64-pc-linux-gnu-pkg-config finds /usr/lib64/pkgconfig/systemd.pc >>> containing, >>> amongst other things, libdir which is arch specific, /usr/lib64 and >>> systemdutildir >>> which contains arch-specific binaries (yes, /usr/lib64/systemd/systemd *is* >>> an >>> ELF64 binary using an x86_64 interpreter. >>> >>> i686-pc-linux-gnu-pkg-config finds /usr/lib32/pkgconfig/systemd.pc (since >>> it has >>> been cross-compiled too) and is pretty happy with that. >>> >>> arm-whatever-pkg-config finds /usr/arm-whatever/lib/systemd.pc and is >>> happy with it. >>> >>> If you move it to /usr/share/pkgconfig >>> >>> x86_64-pc-linux-gnu-pkg-config finds /usr/share/pkgconfig/systemd.pc >>> and is happy with it >>> >>> i686-pc-linux-gnu-pkg-config finds /usr/share/pkgconfig/systemd.pc and >>> tries linking to >>> x86_64 libraries >>> >>> arm-whatever-pkg-config finds /usr/share/pkgconfig/systemd.pc and >>> tries linking to >>> x86_64 libraries + it gets the path towards binaries its target won't >>> even be able to execute. >>> >>> >>> Hope that helps understanding the rational of putting pkgconfig files >>> pointing to >>> arch-specific libs/bins into an arch-specific place. >>> >>> >>> A good example of a pkgconfig file that is ok to install into >>> /usr/share/pkgconfig is >>> xorg-macros.pc which only leads to arch-independants macros. >> >> The point is, the purpose of that file is not cross-compiling. It is >> meant to provide information for the i686 toolchain which is nativly >> compiled on a x86_64 primary host. >> >> How is the i686 tool supposed to find the primary values of the >> installed native x86_64 tools if things are moved like you propose? >> > > Why would it need to? Because it is the purpose of that file. The version of systemd which is installed is described in that file. Tools that build on this host want the values of this systemd. >> The entire idea of adding $libdir to a file that is installed in >> $libdir to point to itself makes no sense at all, but that was the >> reason it was moved in the first place. > > Agreed about the redundancy, but what if the arm tool wants to find > installed arm tools, and not x86_64? This is not a systemd problem. Systemd is the base system, and that is described in that file, not something that is foreign to the base system. With the original intended purpose of these files, they just belong into one single common location describing the currently running/primary/common system values. $libdir was added to indicate the primary architecture. That only makes sense when the file is in a common location, not in libdir. Like described in the man page: http://www.freedesktop.org/software/systemd/man/file-hierarchy.html#/usr/lib/arch-id Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2 2/4] udev: Update pointingstick rules to allow setting ibm trackpoint sensitivity
On Tue, Apr 7, 2015 at 7:06 AM, Peter Hutterer wrote:
> On Fri, Apr 03, 2015 at 04:11:58PM +0200, Hans de Goede wrote:
>> +TEST=="../../../sensitivity", ENV{POINTINGSTICK_SENSITIVITY}!="", \
>> + ATTR{../../../sensitivity}="$env{POINTINGSTICK_SENSITIVITY}"
>>
>> LABEL="pointingstick_end"
>
> hmm, not the nicest rule but I couldn't find anything simpler. Kay, any idea
> how do do this with fewer relative path specs?
We cannot really ship any "../../../". This would encode a fixed
number of steps from the child device to the parent device, but the
kernel must be free to insert more devices in the chain of devices
without breaking our logic.
This stuff probably needs to be implemented in code looking up a
specific parent, and not just using udev rules.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 5/5] build: use $(OBJCOPY)
On Wed, Apr 8, 2015 at 7:36 PM, Marc-Antoine Perennou wrote: > On 8 April 2015 at 19:03, Kay Sievers wrote: >> On Tue, Apr 7, 2015 at 8:54 PM, Marc-Antoine Perennou >> wrote: >>> --- >>> Makefile.am | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/Makefile.am b/Makefile.am >>> index 9b769ee..397a71c 100644 >>> --- a/Makefile.am >>> +++ b/Makefile.am >>> @@ -2596,7 +2596,7 @@ $(systemd_boot_solib): $(systemd_boot_objects) >>> nm -D -u $@ | grep ' U ' && exit 1 || : >>> >>> $(systemd_boot): $(systemd_boot_solib) >>> - $(AM_V_GEN) objcopy -j .text -j .sdata -j .data -j .dynamic \ >>> + $(AM_V_GEN)$(OBJCOPY) -j .text -j .sdata -j .data -j .dynamic \ >> >> This does not build here. I don't see who would define OBJCOPY. >> >> Kay > > Someone with a full CHOST-prefixed compilation toolchain would. > I agree there should be a default value here, though, will send another > fixed patch for this. Please just test such stuff for the common setup before sending it out, which is NOT cross-compilation. :) Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/5] udev.pc: install to pkgconfiglibdir
On Wed, Apr 8, 2015 at 7:34 PM, Marc-Antoine Perennou wrote: > On 8 April 2015 at 18:47, Kay Sievers wrote: >> On Tue, Apr 7, 2015 at 8:54 PM, Marc-Antoine Perennou >> wrote: >>> --- >>> Makefile.am | 3 +-- >>> 1 file changed, 1 insertion(+), 2 deletions(-) >>> >>> diff --git a/Makefile.am b/Makefile.am >>> index 9fa4223..9b769ee 100644 >>> --- a/Makefile.am >>> +++ b/Makefile.am >>> @@ -3725,8 +3725,7 @@ udevconfdir = $(sysconfdir)/udev >>> dist_udevconf_DATA = \ >>> src/udev/udev.conf >>> >>> -sharepkgconfigdir = $(datadir)/pkgconfig >>> -sharepkgconfig_DATA = \ >>> +pkgconfiglib_DATA += \ >>> src/udev/udev.pc >> >> This is all backwards. The systemd.pc file is also in the wrong location. >> >> These GENERIC files are supposed to be found by the primary AND the >> secondary arch at the same time, at the GENERIC location, not in a >> arch-specific libdir. >> >> How would the 32bit build find this file on a 64bit compat-arch/multilib >> system? >> >> Kay > > Well, let's imagine a full cross-compilation toolchain, with > CHOST-prefixed tools. > > x86_64 stuff will get built with x86_64-pc-linux-gnu-gcc > i686 stuff will get built with i686-pc-linux-gnu-gcc > (and you could add a lot of non-native archs here like arm, mips & co) > > x86_64-pc-linux-gnu-pkg-config will look into /usr/lib64/pkgconfig and > /usr/share/pkgconfig > i686-pc-linux-gnu-pkg-config will look into /usr/lib32/pkgconfig and > /usr/share/pkgconfig > > You says that systemd is in the wrong location, so let's see what's > going on with its > current location, and then if we move it to /usr/share > > Current location, libdir/pkgconfig/systemd.pc > > x86_64-pc-linux-gnu-pkg-config finds /usr/lib64/pkgconfig/systemd.pc > containing, > amongst other things, libdir which is arch specific, /usr/lib64 and > systemdutildir > which contains arch-specific binaries (yes, /usr/lib64/systemd/systemd *is* an > ELF64 binary using an x86_64 interpreter. > > i686-pc-linux-gnu-pkg-config finds /usr/lib32/pkgconfig/systemd.pc (since it > has > been cross-compiled too) and is pretty happy with that. > > arm-whatever-pkg-config finds /usr/arm-whatever/lib/systemd.pc and is > happy with it. > > If you move it to /usr/share/pkgconfig > > x86_64-pc-linux-gnu-pkg-config finds /usr/share/pkgconfig/systemd.pc > and is happy with it > > i686-pc-linux-gnu-pkg-config finds /usr/share/pkgconfig/systemd.pc and > tries linking to > x86_64 libraries > > arm-whatever-pkg-config finds /usr/share/pkgconfig/systemd.pc and > tries linking to > x86_64 libraries + it gets the path towards binaries its target won't > even be able to execute. > > > Hope that helps understanding the rational of putting pkgconfig files > pointing to > arch-specific libs/bins into an arch-specific place. > > > A good example of a pkgconfig file that is ok to install into > /usr/share/pkgconfig is > xorg-macros.pc which only leads to arch-independants macros. The point is, the purpose of that file is not cross-compiling. It is meant to provide information for the i686 toolchain which is nativly compiled on a x86_64 primary host. How is the i686 tool supposed to find the primary values of the installed native x86_64 tools if things are moved like you propose? The entire idea of adding $libdir to a file that is installed in $libdir to point to itself makes no sense at all, but that was the reason it was moved in the first place. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 5/5] build: use $(OBJCOPY)
On Tue, Apr 7, 2015 at 8:54 PM, Marc-Antoine Perennou wrote: > --- > Makefile.am | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Makefile.am b/Makefile.am > index 9b769ee..397a71c 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -2596,7 +2596,7 @@ $(systemd_boot_solib): $(systemd_boot_objects) > nm -D -u $@ | grep ' U ' && exit 1 || : > > $(systemd_boot): $(systemd_boot_solib) > - $(AM_V_GEN) objcopy -j .text -j .sdata -j .data -j .dynamic \ > + $(AM_V_GEN)$(OBJCOPY) -j .text -j .sdata -j .data -j .dynamic \ This does not build here. I don't see who would define OBJCOPY. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/5] udev.pc: install to pkgconfiglibdir
On Tue, Apr 7, 2015 at 8:54 PM, Marc-Antoine Perennou wrote: > --- > Makefile.am | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/Makefile.am b/Makefile.am > index 9fa4223..9b769ee 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -3725,8 +3725,7 @@ udevconfdir = $(sysconfdir)/udev > dist_udevconf_DATA = \ > src/udev/udev.conf > > -sharepkgconfigdir = $(datadir)/pkgconfig > -sharepkgconfig_DATA = \ > +pkgconfiglib_DATA += \ > src/udev/udev.pc This is all backwards. The systemd.pc file is also in the wrong location. These GENERIC files are supposed to be found by the primary AND the secondary arch at the same time, at the GENERIC location, not in a arch-specific libdir. How would the 32bit build find this file on a 64bit compat-arch/multilib system? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fsckd needs to go -- possible compromise?
On Wed, Apr 8, 2015 at 4:18 PM, Martin Pitt wrote: > Lennart Poettering [2015-04-07 16:14 +0200]: >> Well, the asnc IO socket handling thing was not dealt with. The newest >> patches still use fgets(). >> [...] >> The killer issue really is the safety issue. We shouldn't include >> code in systemd that makes dangerous things like killing running >> fscks an easily accessible operation, that has a graphical UI and >> requires no authentication. > > So, would you reconsider your position if we address the two things > above? I. e. replace fgets() by our own async buffering, and entirely > remove the cancel support? Then we'd still get a proper feedback > during boot instead of leaving the user in the dark why booting is > stuck, but it stays noninteractive. I don't think there is enough justification for a fsck daemon. Large filesystems which need fsck in userspace are a thing from the past and insufficiently developed technology for today's operating system tasks. Basic filesystem consistency and maintenance tasks belong into the kernel and nowhere else. We made it just fine into the year 2015 with the support for the legacy filesystems, and we did not need a specialized daemon so far. Therefore, we can except that the current level of support will be sufficient for the coming years. We will support them well enough until everybody will finally realize that they do not solve the problems we face today, and that they need to be replaced. Please keep things like fsckd in the distribution that wants to make such promises about legacy technology. Systemd upstream should focus on current and future technologies and not pimp up outdated facilities, waste our time and and add more complex logic and rules in the basic boot process. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] Add reboot to EFI support
On Thu, Apr 2, 2015 at 8:18 PM, Lennart Poettering wrote: > On Thu, 02.04.15 15:51, Jan Janssen (medhe...@web.de) wrote: > >> Hi, >> >> On 2015-04-02 11:34, Lennart Poettering wrote: >> >On Thu, 26.03.15 16:09, Jan Janssen (medhe...@web.de) wrote: >> > >> >Heya, >> > >> >Hmm, so we already support passing special reboot() parameters, and >> >this is done by manipulating a file in /run, without introducing any >> >new targets. To me it appears that boot-into-firmware-setup is >> >something hat should be handled the same way, i.e. as a special >> >parameter for the *normal* poweroff path, instead of introducing a new >> >poweroff path for it. Of course, instead of manipulating /run for this >> >we should directly manipulate the respective EFI variable. >> > >> >I hence think this should be a new switch --firmware-setup or so to >> >systemctl. Of course, that sounds awfully specific and I don't really >> >like too much adding a new switch just for this flag, but it's the >> >least best option I see. >> >> That was my original approach. Kay said "--firmware" sounded weird. > > Yeah, he initially said that but 6 hours later suggested suggested > "--firmware" again. No, I did not. The mail contains only references about the order of options. I dislike the global options for local verbs systemctl does, it is confusing even in the man page, and does not scale. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-vconsole-setup fails very slowly
On Thu, Apr 2, 2015 at 12:00 AM, Andy Lutomirski wrote: > On Wed, Apr 1, 2015 at 2:47 PM, Kay Sievers wrote: >> On Wed, Apr 1, 2015 at 11:38 PM, Andy Lutomirski wrote: >>> On Wed, Apr 1, 2015 at 2:36 PM, Kay Sievers wrote: >> >>>> They should only get created when something accesses the corresponding >>>> tty. deallocvt(1) can kill unused ones and the device nodes should >>>> disappear. >>>> >>> >>> deallocvt doesn't seem to kill those device nodes for me. >> >> Seems to work here: >> >> # ls -l /dev/vcs[6789] >> crw-rw 1 root tty 7, 6 Apr 1 22:21 /dev/vcs6 >> # cat /dev/tty7 >> ^C >> # cat /dev/tty9 >> ^C >> # ls -l /dev/vcs[6789] >> crw-rw 1 root tty 7, 6 Apr 1 22:21 /dev/vcs6 >> crw-rw 1 root tty 7, 7 Apr 1 23:42 /dev/vcs7 >> crw-rw 1 root tty 7, 9 Apr 1 23:42 /dev/vcs9 >> # deallocvt 7 >> # ls -l /dev/vcs[6789] >> crw-rw 1 root tty 7, 6 Apr 1 22:21 /dev/vcs6 >> crw-rw 1 root tty 7, 9 Apr 1 23:42 /dev/vcs9 >> # deallocvt 9 >> # ls -l /dev/vcs[6789] >> crw-rw 1 root tty 7, 6 Apr 1 22:21 /dev/vcs6 > > Aha. It seems that I have something holding tty1-tty4 open. I'll fix > that on my end. Will that make vconsole-setup stop calling setfont? Oh, no. That was just in reply to the "vc_screen.c code seems to create those devices unconditionally". These devices should all be fully dynamic, handled inside the kernel. It will not influence the setfont behavior of vconsole-setup. To fix your issue, setfont should be changed, or we find and add some dummy font-related ioctl to vconsole-setup, to check if setfont would fail anyway on the current VT and we skip it. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-vconsole-setup fails very slowly
On Wed, Apr 1, 2015 at 11:38 PM, Andy Lutomirski wrote: > On Wed, Apr 1, 2015 at 2:36 PM, Kay Sievers wrote: >> They should only get created when something accesses the corresponding >> tty. deallocvt(1) can kill unused ones and the device nodes should >> disappear. >> > > deallocvt doesn't seem to kill those device nodes for me. Seems to work here: # ls -l /dev/vcs[6789] crw-rw 1 root tty 7, 6 Apr 1 22:21 /dev/vcs6 # cat /dev/tty7 ^C # cat /dev/tty9 ^C # ls -l /dev/vcs[6789] crw-rw 1 root tty 7, 6 Apr 1 22:21 /dev/vcs6 crw-rw 1 root tty 7, 7 Apr 1 23:42 /dev/vcs7 crw-rw 1 root tty 7, 9 Apr 1 23:42 /dev/vcs9 # deallocvt 7 # ls -l /dev/vcs[6789] crw-rw 1 root tty 7, 6 Apr 1 22:21 /dev/vcs6 crw-rw 1 root tty 7, 9 Apr 1 23:42 /dev/vcs9 # deallocvt 9 # ls -l /dev/vcs[6789] crw-rw 1 root tty 7, 6 Apr 1 22:21 /dev/vcs6 >>> The offending qemu command line args appear to be -vga none -display >>> none. I assume I have "CGA" because it's the fallback case in >>> vgacon.c if nothing matches. >> >> Hehe, blast from the past. :) If you give kvm a VGA device, it all works >> fine? > > I just tried it. setfont succeeds, and the VGA device matches > /dev/vcs's contents. Ah, nice. If we figure out some dummy font-related call to check if the kernel supports font handling at all, we could just add that to vconsole-setup, I guess. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-vconsole-setup fails very slowly
On Wed, Apr 1, 2015 at 11:19 PM, Andy Lutomirski wrote: > On Wed, Apr 1, 2015 at 1:53 PM, Kay Sievers wrote: >> On Wed, Apr 1, 2015 at 10:45 PM, Andy Lutomirski wrote: >>> On Apr 1, 2015 12:56 PM, "Kay Sievers" wrote: >> >>>> Do you have an idea why the VM does not accept the custom font? If >>>> that is something obvious, and we can detect it, we could make >>>> vconsole-setup check for it. But then again, fixing setfont seems like >>>> the obvious fix here. >>> >>> I assume it's because the VM has no graphical console at all. >> >> We check the existence of the corresponding /dev/vcs%i, to check if >> the tty is allocated where we want to apply the font to. Do these >> devices exist on the running machine? > > Yes: > > # ls /dev/vcs* > /dev/vcs /dev/vcs2 /dev/vcs4 /dev/vcsa1 /dev/vcsa3 > /dev/vcs1 /dev/vcs3 /dev/vcsa /dev/vcsa2 /dev/vcsa4 > > Looking at the code, the vc_screen.c code seems to create those > devices unconditionally. They should only get created when something accesses the corresponding tty. deallocvt(1) can kill unused ones and the device nodes should disappear. >> And what does this say? >> grep . /sys/class/tty/tty0/active /sys/class/tty/console/active > > # grep . /sys/class/tty/tty0/active /sys/class/tty/console/active > /sys/class/tty/tty0/active:tty1 > /sys/class/tty/console/active:ttyS0 > > vcs1 has, roughly: > > early console in decompress_kernel > Decompressing Linux... Parsing ELF... done. > Booting the kernel. > > Now I'm wondering how that buffer came to be. > > In any event, some tracing of the code suggests that I have > vga_video_type == VIDEO_TYPE_CGA, and that fails "if (vga_video_type < > VIDEO_TYPE_EGAM)" in vgacon_font_set. > > Indeed, /proc/ioports has: > > 03d4-03d5 : cga > > and dmesg says: > > [0.00] Console: colour *CGA 80x25 > > I don't see this information in sysfs anywhere. Perhaps checking for > an active console and detecting -EINVAL from vgacon_font_get would > work. Hmm, yeah, maybe we could try one of the font-related ioctls to find out if the driver supports that before we spawn setfont. > /proc/fb is empty on this VM, so maybe that would help. Grr, this > stuff is really old and crufty. > > The offending qemu command line args appear to be -vga none -display > none. I assume I have "CGA" because it's the fallback case in > vgacon.c if nothing matches. Hehe, blast from the past. :) If you give kvm a VGA device, it all works fine? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-vconsole-setup fails very slowly
On Wed, Apr 1, 2015 at 10:45 PM, Andy Lutomirski wrote: > On Apr 1, 2015 12:56 PM, "Kay Sievers" wrote: >> Do you have an idea why the VM does not accept the custom font? If >> that is something obvious, and we can detect it, we could make >> vconsole-setup check for it. But then again, fixing setfont seems like >> the obvious fix here. > > I assume it's because the VM has no graphical console at all. We check the existence of the corresponding /dev/vcs%i, to check if the tty is allocated where we want to apply the font to. Do these devices exist on the running machine? And what does this say? grep . /sys/class/tty/tty0/active /sys/class/tty/console/active Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-vconsole-setup fails very slowly
On Wed, Apr 1, 2015 at 9:36 PM, Andy Lutomirski wrote:
> On Wed, Apr 1, 2015 at 12:32 PM, Kay Sievers wrote:
>> On Wed, Apr 1, 2015 at 8:56 PM, Andy Lutomirski wrote:
>>> On Thu, Jan 22, 2015 at 6:29 PM, Andy Lutomirski
>>> wrote:
>>>> On Thu, Jan 22, 2015 at 6:13 PM, Lennart Poettering
>>>> wrote:
>>>>> On Wed, 21.01.15 19:15, Andy Lutomirski (l...@amacapital.net) wrote:
>>>>>
>>>>>> Hi all-
>>>>>>
>>>>>> When running virtme (a simple vm gadget) on Fedora 21, the slowest
>>>>>> part of bootup by far appears to be systemd-vconsole-setup:
>>>>>>
>>>>>> # time /usr/lib/systemd/systemd-vconsole-setup
>>>>>> putfont: PIO_FONT trying ...
>>>>>> ...
>>>>>> setfont: putfont: 512,8x16: failed: -1
>>>>>> putfont: PIO_FONT: Invalid argument
>>>>>> /usr/bin/setfont failed with error code 71.
>>>>>
>>>>> setfont is not part of systemd, we just invoke it. If that fails, this
>>>>> is a problem somewhere between the VM, the kernel and console-tools.
>>>>>
>>>>
>>>> Aha -- I missed that systemd-vconsole-setup calls setfont. I can
>>>> trigger the same problem by just typing setfont. For whatever reason,
>>>> my other Fedora 21 computer only has this problem if I type setfont
>>>> and not if I run systemd-vconcole-setup.
>>>>
>>>>> My uneducated guess is that your virtual machine boots up with a
>>>>> non-graphical console, and the tool thus tries to upload the fonts
>>>>> into the good old VGA hw text mode glyph tables, and qemu is very slow
>>>>> at that... Or something like that.
>>>>
>>>> setfont is doing this:
>>>>
>>>> nanosleep({0, 25000}, NULL) = 0
>>>> ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
>>>> write(2, ".", 1.)= 1
>>>> nanosleep({0, 25000}, NULL) = 0
>>>> ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
>>>> write(2, ".", 1.)= 1
>>>> nanosleep({0, 25000}, NULL) = 0
>>>> ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
>>>> write(2, ".", 1.)= 1
>>>> nanosleep({0, 25000}, NULL) = 0
>>>> ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
>>>> write(2, ".", 1.)= 1
>>>> nanosleep({0, 25000}, NULL) = 0
>>>> ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
>>>> write(2, ".", 1.)= 1
>>>>
>>>> This thing has only a serial console:
>>>>
>>>> # cat /proc/consoles
>>>> ttyS0-W- (EC a)4:64
>>>>
>>>> setfont does this:
>>>>
>>>> /* we allow ourselves to hang here for ca 5 seconds, xdm may
>>>> be playing tricks on us. */
>>>> while ((loop++ < 20) && (i = ioctl(fd, PIO_FONT, buf)))
>>>> {
>>>> if (loop <= 1)
>>>> fprintf(stderr, "putfont: PIO_FONT trying ...\n");
>>>> else
>>>> fprintf(stderr, ".");
>>>> usleep(25);
>>>> }
>>>> fprintf(stderr, "\n");
>>>>
>>>> Alexey, would it make sense to remove this loop or to add a way to turn it
>>>> off?
>>>
>>> Ping, everyone?
>>>
>>> This issue still exists. AFAICT systemd is relying on a really old
>>> tool, that that really old tool (setfont) is sometimes delaying boot
>>> by a very large amount. Can we either fix the tool (Alexey) or stop
>>> using it (systemd people)?
>>
>> Hmm, why is the "vm gadget" you run configuring a custom console font
>> at all? If there is no custom font specified in t he config, systemd
>> will not run setfont.
>
> It's not intentionally configuring a custom font, but it might be
> inheriting Fedora's settings.
Ideally, /etc/vconsole.conf does not even exist in a default setup. It
is only needed for foreign language keyboard support or more exotic
font req
Re: [systemd-devel] systemd-vconsole-setup fails very slowly
On Wed, Apr 1, 2015 at 8:56 PM, Andy Lutomirski wrote:
> On Thu, Jan 22, 2015 at 6:29 PM, Andy Lutomirski wrote:
>> On Thu, Jan 22, 2015 at 6:13 PM, Lennart Poettering
>> wrote:
>>> On Wed, 21.01.15 19:15, Andy Lutomirski (l...@amacapital.net) wrote:
>>>
Hi all-
When running virtme (a simple vm gadget) on Fedora 21, the slowest
part of bootup by far appears to be systemd-vconsole-setup:
# time /usr/lib/systemd/systemd-vconsole-setup
putfont: PIO_FONT trying ...
...
setfont: putfont: 512,8x16: failed: -1
putfont: PIO_FONT: Invalid argument
/usr/bin/setfont failed with error code 71.
>>>
>>> setfont is not part of systemd, we just invoke it. If that fails, this
>>> is a problem somewhere between the VM, the kernel and console-tools.
>>>
>>
>> Aha -- I missed that systemd-vconsole-setup calls setfont. I can
>> trigger the same problem by just typing setfont. For whatever reason,
>> my other Fedora 21 computer only has this problem if I type setfont
>> and not if I run systemd-vconcole-setup.
>>
>>> My uneducated guess is that your virtual machine boots up with a
>>> non-graphical console, and the tool thus tries to upload the fonts
>>> into the good old VGA hw text mode glyph tables, and qemu is very slow
>>> at that... Or something like that.
>>
>> setfont is doing this:
>>
>> nanosleep({0, 25000}, NULL) = 0
>> ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
>> write(2, ".", 1.)= 1
>> nanosleep({0, 25000}, NULL) = 0
>> ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
>> write(2, ".", 1.)= 1
>> nanosleep({0, 25000}, NULL) = 0
>> ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
>> write(2, ".", 1.)= 1
>> nanosleep({0, 25000}, NULL) = 0
>> ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
>> write(2, ".", 1.)= 1
>> nanosleep({0, 25000}, NULL) = 0
>> ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
>> write(2, ".", 1.)= 1
>>
>> This thing has only a serial console:
>>
>> # cat /proc/consoles
>> ttyS0-W- (EC a)4:64
>>
>> setfont does this:
>>
>> /* we allow ourselves to hang here for ca 5 seconds, xdm may
>> be playing tricks on us. */
>> while ((loop++ < 20) && (i = ioctl(fd, PIO_FONT, buf)))
>> {
>> if (loop <= 1)
>> fprintf(stderr, "putfont: PIO_FONT trying ...\n");
>> else
>> fprintf(stderr, ".");
>> usleep(25);
>> }
>> fprintf(stderr, "\n");
>>
>> Alexey, would it make sense to remove this loop or to add a way to turn it
>> off?
>
> Ping, everyone?
>
> This issue still exists. AFAICT systemd is relying on a really old
> tool, that that really old tool (setfont) is sometimes delaying boot
> by a very large amount. Can we either fix the tool (Alexey) or stop
> using it (systemd people)?
Hmm, why is the "vm gadget" you run configuring a custom console font
at all? If there is no custom font specified in t he config, systemd
will not run setfont.
Or did you mean to have vconsole-setup detect that it should not even
try to run setfont? Not sure how to find that out.
I don't really see how vconsole-setup could get rid of calling setfont
from systemd, it is needed in many setups.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemd-bootchart: Prevent closing random file descriptors
On Sun, Mar 29, 2015 at 5:17 PM, Daniel Mack wrote:
> On 03/29/2015 03:04 PM, Alexander Sverdlin wrote:
>> On 29/03/15 13:44, Daniel Mack wrote:
@@ -184,6 +185,7 @@ vmstat_next:
> n = pread(schedstat, buf, sizeof(buf) - 1, 0); if (n <= 0) {
> close(schedstat); +schedstat = 0;
>>> Note that 0 is a valid file descriptor number. You should really
>>> rather reset the variables to -1 and check for '>= 0'. This applies
>>> to all hunks of this patch, which also needs a rebase onto the
>>> current git HEAD.
>>
>> I believe, it was HEAD as of time of patch submission, but I can of
>> course rebase it once again. Regarding 0: everywhere in the program
>> it relies on the fact that newly allocated memory is zeroed and files
>> are only opened if the corresponding file descriptor field of a
>> structure is 0. So do you propose to change the logic everywhere
>> where the files are opened?
>
> I see. As that code doesn't close stdin, 0 can't be returned by any
> open*(), so that's not a real issues, but all code should still be
> written in a way that it treats 0 as valid descriptor. So we need to
> explicitly initialize fd variables to -1 after new0(), and refactor code
> to where necessary.
Right, we rely on uninitialized fds to be negative. Even when it is
not commonly used, the _cleanup_close_ logic and other commonly
used fd handling functions, which should probably used in bootchart
too, rely on it:
http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/util.c#n272
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] Makefile.am src/shared src/timedate
On Thu, Mar 26, 2015 at 12:06 PM, Lennart Poettering wrote: > On Thu, 26.03.15 11:57, Kay Sievers (k...@vrfy.org) wrote: > >> > Now, to make calendar time triggers complete I think we must enable >> > people to at least trigger on threse three kinds of anomalies in the >> > time scale. As such I think it would make a *ton* of sense to add: >> > >> > OnTimeZoneChange= >> > OnClockChange= >> >> These are useful, sure. >> >> > OnDSTChange= >> >> This is absolutely not needed and we should not get into that >> business. > > That's just a statement of an opinion. I see no explanation for this. I see only repeated made-up arguments to add an exotic feature, which I don't see adding any real value. DST for the machine is "presentation only". Tools handling it turn the "presentation" into the actual machine's time and be done with it. Glibc does that for us today already and it already works sufficiently for systemd's calendar time support. If the system's time zone changes, or the time is adjusted manually, we just re-arm all timers, and all should be fine. I see no need or use to support explicit triggers on the event of DST changes, the system or calendar time support just does not need them. >> There is no need to fiddle with the raw tzfile data here. > > Well, it's good that things are so simple for you. I'm not willing to discuss things in that tone. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] Makefile.am src/shared src/timedate
On Thu, Mar 26, 2015 at 11:48 AM, Lennart Poettering wrote: > On Tue, 24.03.15 07:04, Kay Sievers (k...@kemper.freedesktop.org) wrote: > >> Makefile.am|2 >> src/shared/time-dst.c | 329 >> - >> src/shared/time-dst.h | 26 --- >> src/timedate/timedatectl.c | 56 --- >> 4 files changed, 413 deletions(-) >> >> New commits: >> commit 16c6ea29348ddac73998f339166f863bee0dfef6 >> Author: Kay Sievers >> Date: Tue Mar 24 13:52:04 2015 +0100 >> >> timedate: remove daylight saving time handling and tzfile parser >> >> We planned to support (the conceptually broken) daylight saving >> time/local time features in the kernel, SCSI, networking, FAT >> filesystem, but it turned out to be a race we cannot win and do >> not want to get involved. Systemd should not fiddle with daylight >> saving time or parse timezone information itself. >> >> Leave everything to glibc or tools like date(1) and do not make any >> promises or raise expectations that systemd should handle anything >> like this. > > For what's it worth, I strongly disagree with the removal of this. > > We do provide OnCalendar= triggers in timer units. They trigger on > calendar time, not on UTC time, and are hence subject to local clock > changes, to local timezone changes, and to the DST changes of the > local timezone. Their time scale is non-linear due to this: it > *mostly* is linear, but under any of these three conditions it will > not be linear anymore, it will jump. > > Now, to make calendar time triggers complete I think we must enable > people to at least trigger on threse three kinds of anomalies in the > time scale. As such I think it would make a *ton* of sense to add: > > OnTimeZoneChange= > OnClockChange= These are useful, sure. > OnDSTChange= This is absolutely not needed and we should not get into that business. > settings to .timer units, so that users can explictly watch for any of > them, either separately of the actual calendar expressions, or in > addition to them. > > If we do have all four of OnCalendar=, OnTimeZoneChange=, > OnClockChange= and OnDSTChange= in place, then for the first time we > actually can express timer events in a complete way, and the anomalies > of the wallclock time scale becomes *manageable*, for the first time. > > Just removing this code blindly appears misguided to me. It just means > sticking the head in the sand, ignoring completely the fact that we > *do* already provide OnCalendar= timer units, and ignoring that their > time scale is so weirdly non-monotonic. And we leave our users in the > cold, because we provide them with no way to manage the fuckup that > DST is. > > I strongly believe that it is our duty to make the non-monotonicity of > the calendar time scale as managable as possible for admins, and that > not only includes triggers on DST changes, but in fact the DST changes > are probably the most important kind of anomaly on the calendar scale, > since even a completely NTP controlled, physically fixed system will > experience them regularly, in contrast to the other kinds of > anomalies. DST support works all fine already today. I don't see any need for parsing the tz files here to solve an actual existing problem. > So yeah, Kay, I think this should be readded and be made useful for > timer units. And if we make use of this for the timer units we might > as well show it in timedatectl... No, it shouldn't. We should stay out of the DST business. Glibc calculates everything just fine for all needed tasks and we arm the timers accordingly. There is no need to fiddle with the raw tzfile data here. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] automount: add expire support
On Sun, Mar 22, 2015 at 1:36 PM, Michael Olbrich wrote: > --- > man/systemd.automount.xml | 8 ++ > man/systemd.mount.xml | 9 ++ > src/core/automount.c | 209 > -- > src/core/automount.h | 6 +- > src/core/dbus-automount.c | 1 + > src/core/load-fragment-gperf.gperf.m4 | 1 + > src/core/mount.c | 20 +--- > src/fstab-generator/fstab-generator.c | 27 + > 8 files changed, 253 insertions(+), 28 deletions(-) Great to have that feature, and it is really needed not to constantly trash the EFI FAT32 partition with the Linux vfat driver when things go wrong. It seems to do what it is supposed to do: Mar 25 00:47:24 ank systemd[1]: Got automount request for /boot, triggered by 1057 (ls) Mar 25 00:48:47 ank systemd[1]: Unmounting EFI System Partition... Mar 25 00:50:05 ank systemd[1]: Got automount request for /boot, triggered by 1206 (ls) Mar 25 00:50:36 ank systemd[1]: Unmounting EFI System Partition... I'll let someone else take another look, seems all fine from my side. Thanks a lot for doing this, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] rules: storage - whitelist partitioned MS & MMC devices
On Mon, Mar 23, 2015 at 8:55 AM, Mantas Mikulėnas wrote: > On Tue, Mar 17, 2015 at 11:50 PM, Kay Sievers wrote: >> >> On Tue, Mar 17, 2015 at 5:00 PM, Mantas Mikulėnas >> wrote: >> > Accidentally dropped in 1aff20687f4868575. >> > --- >> > rules/60-persistent-storage.rules | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> >> > +KERNEL!="loop*|mmcblk[0-9]*|mspblk[0-9]*|nvme*|sd*|sr*|vd*", >> > GOTO="persistent_storage_end" >> >> We can't do that, we need to ignore the mmc*rpmb devices: >> >> http://cgit.freedesktop.org/systemd/systemd/commit/?id=b87b01cf83947f467f3c46d9831cd67955fc46b9 >> >> Maybe "mmcblk*[0-9]" will work? > > > Yeah, that would probably work (the names are like mmcblk0p1 etc.) Made that change. > ~ On a related note, is it intentional that all these rules are limited to a > single digit? No specific reason, it is just a limit of the in this case too simple glob matching. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] rules: storage - support MemoryStick (non-Pro) cards
On Tue, Mar 17, 2015 at 5:00 PM, Mantas Mikulėnas wrote: > These are handled by a different driver than MemoryStick Pro. Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] timedatectl: check for getenv("TZDIR")
On Tue, Mar 24, 2015 at 7:39 PM, Shawn Landden wrote:
> On Tue, Mar 24, 2015 at 11:32 AM, Kay Sievers wrote:
>> On Tue, Mar 24, 2015 at 7:11 PM, Shawn Landden wrote:
>>
>>> /* Enforce the values of /etc/localtime */
>>> if (getenv("TZ")) {
>>> -fprintf(stderr, "Warning: Ignoring the TZ variable.\n\n");
>>> +fprintf(stderr, "Warning: Ignoring the %s variable.\n\n",
>>> "TZ");
>>
>> What style is that? A second static string inserted with %s?
>> Wanto de-duplicate the first static string? :)
> yep
Come on, we are not starting to smart-out the compiler and trade size
against runtime at the same time. Not that it matters, but it makes no
sense for systemd or that tool. Please do not do that.
>>
>>> -xstrftime(a, "%a %Y-%m-%d %H:%M:%S UTC", gmtime_r(&sec,
>>> &tm));
>>> +xstrftime(a, "%a %Y-%m-%d %H:%M:%S UTC", gmtime);
>>
>> Why this change?
> localtime_r() and gmtime_r() are called multiple times.
And what's the problem? If this is again to optimize things, please
don't do that in systemd code unless it makes things better readable
at the same time, the *_r functions are generally preferred.
>>> + " RTC in UTC by calling 'timedatectl
>>> set-local-rtc 0'\n
>>> + " For more details see
>>> http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html"; ANSI_HIGHLIGHT_OFF
>>> ".\n", stdout);
>>
>> Hmm, I find links to "random" web pages in error output a bit too
>> unconventional.
> OK, but the page has been around for years and does tell Windows users
> what registry entry to set to use UTC for their RTC.
Hmm, this is nothing to suggest to Windows users. Windows will stop to
touch the RTC and never adjust it again. This would only work for
Linux boxes where Windows is only booted for a short while and then
booted back to Linux. We can't know that.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] timedatectl: check for getenv("TZDIR")
On Tue, Mar 24, 2015 at 7:11 PM, Shawn Landden wrote:
> /* Enforce the values of /etc/localtime */
> if (getenv("TZ")) {
> -fprintf(stderr, "Warning: Ignoring the TZ variable.\n\n");
> +fprintf(stderr, "Warning: Ignoring the %s variable.\n\n",
> "TZ");
What style is that? A second static string inserted with %s?
Wanto de-duplicate the first static string? :)
> -xstrftime(a, "%a %Y-%m-%d %H:%M:%S UTC", gmtime_r(&sec,
> &tm));
> +xstrftime(a, "%a %Y-%m-%d %H:%M:%S UTC", gmtime);
Why this change?
> + " RTC in UTC by calling 'timedatectl
> set-local-rtc 0'\n
> + " For more details see
> http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html"; ANSI_HIGHLIGHT_OFF ".\n",
> stdout);
Hmm, I find links to "random" web pages in error output a bit too
unconventional.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] timedatectl: check for getenv("TZDIR")
On Tue, Mar 24, 2015 at 7:11 PM, Shawn Landden wrote: > I liked having the DST information. It is a pity glibc doesn't export > this information. Yeah, date(1) could use and show that information too, I think. Adding custom parsers to work-around glibc's development style was needed in the past, but maybe all that would be fine today. Glib has a parser and an API to use it too: https://developer.gnome.org/glib/stable/glib-GTimeZone.html Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] Makefile.am src/shared src/timedate
On Tue, Mar 24, 2015 at 4:07 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Mar 24, 2015 at 03:32:31PM +0100, Kay Sievers wrote: >> On Tue, Mar 24, 2015 at 3:24 PM, Zbigniew Jędrzejewski-Szmek >> wrote: >> > On Tue, Mar 24, 2015 at 07:04:11AM -0700, Kay Sievers wrote: >> >> Makefile.am|2 >> >> src/shared/time-dst.c | 329 >> >> - >> >> src/shared/time-dst.h | 26 --- >> >> src/timedate/timedatectl.c | 56 --- >> >> 4 files changed, 413 deletions(-) >> >> >> >> New commits: >> >> commit 16c6ea29348ddac73998f339166f863bee0dfef6 >> >> Author: Kay Sievers >> >> Date: Tue Mar 24 13:52:04 2015 +0100 >> >> >> >> timedate: remove daylight saving time handling and tzfile parser >> >> >> >> We planned to support (the conceptually broken) daylight saving >> >> time/local time features in the kernel, SCSI, networking, FAT >> >> filesystem, but it turned out to be a race we cannot win and do >> >> not want to get involved. Systemd should not fiddle with daylight >> >> saving time or parse timezone information itself. >> >> >> >> Leave everything to glibc or tools like date(1) and do not make any >> >> promises or raise expectations that systemd should handle anything >> >> like this. >> > >> > That just doesn't make sense. This was *extremely* useful functionality. >> >> Sure, it was useful, it was still not the right place to solve it. >> With the decision not to support any DST stuff in systemd itself, DST >> parsing did not belong here. Maybe in date(1) or any other tool. > > But we cannot pretend timezones don't exists. timedatectl *is* a > high-level tool — the whole point of it's existence was to provide a > nice wrapper around the dbus api to set the timezone. The fact that it > could be used to set timezones and query it in an easy way made it > worthwhile. I don't see anything wrong with the fact that a tool > which allows setting the system timezone also allows displaying some > useful details about the time and timezone. There was nothing wrong > with this functionality in general, only a small issue with conversion > of remote-to-local, which we should work out instead of throwing out > the baby with the bathwater. Well, we need to limit what we do or we will end up in a total mess. With your usual rush to apply not thought-through things people ask for, and your arguments based on the actual status quo instead of a definition/vision what we want to solve in general and where we want to go, I needed to make things simpler to stop giving the wrong impression here. With the feature removed, it is clear, that systemd has no business in localtime presentation or DST handling and that is for sure enough justification to remove it. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] Makefile.am src/shared src/timedate
On Tue, Mar 24, 2015 at 3:24 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Mar 24, 2015 at 07:04:11AM -0700, Kay Sievers wrote: >> Makefile.am|2 >> src/shared/time-dst.c | 329 >> - >> src/shared/time-dst.h | 26 --- >> src/timedate/timedatectl.c | 56 --- >> 4 files changed, 413 deletions(-) >> >> New commits: >> commit 16c6ea29348ddac73998f339166f863bee0dfef6 >> Author: Kay Sievers >> Date: Tue Mar 24 13:52:04 2015 +0100 >> >> timedate: remove daylight saving time handling and tzfile parser >> >> We planned to support (the conceptually broken) daylight saving >> time/local time features in the kernel, SCSI, networking, FAT >> filesystem, but it turned out to be a race we cannot win and do >> not want to get involved. Systemd should not fiddle with daylight >> saving time or parse timezone information itself. >> >> Leave everything to glibc or tools like date(1) and do not make any >> promises or raise expectations that systemd should handle anything >> like this. > > That just doesn't make sense. This was *extremely* useful functionality. Sure, it was useful, it was still not the right place to solve it. With the decision not to support any DST stuff in systemd itself, DST parsing did not belong here. Maybe in date(1) or any other tool. Systemd's job is not to cover exotic features missing in other tools. It was removed to stop misguiding people that systemd should to provide any of these things on the bus or in its APIs, just because it could provide it. In the longer-term this would just end up in a half-baked mess, which we need to make sure will not happen. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] timedated: Add a LocalOffset property for timezone offset
On Tue, Mar 24, 2015 at 3:17 PM, Stef Walter wrote: > On 24.03.2015 15:11, Kay Sievers wrote: >> On Tue, Mar 24, 2015 at 2:15 PM, Zbigniew Jędrzejewski-Szmek >> wrote: >>> Exactly because they do not require being upgraded in lock-step, doing >>> conversion to the local time locally is "racy". Assuming we have up-to-date >>> timezone database locally, with the patch that was merged today we can >>> answer the question "what the local time should be remotely", but not >>> necessarily "what the local time is remotely". >>> >>> If we go to the trouble of displaying the remote local time, imho we >>> should do it as the remote does. >> >> No, we should care about the *state* of the system, and that is its >> time value and its configured location on earth. > > Then stop displaying incorrect "presentation" data in timedatectl. Isn't it fixed with Shawn patch? >> Systemd has no business in "fixing" the *presentation* logic of these >> values. It is not an API for the timezone database. These tools >> already exist. >> >> Please stop trying to add insufficient and half-thought-through APIs >> to cover problems which just do not exist in reality or do not need to >> be worked-around by systemd. > > This gives us what we need: > > $ date '+%s:%:z' > > So we'll use that instead of timedated. I'll update the wiki page for > the timedated DBus interface to note parts of it are just not remotable. Which parts are not not-remotable? You get the exact values you need for a machine, it's current time and location. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] timedated: Add a LocalOffset property for timezone offset
On Tue, Mar 24, 2015 at 2:15 PM, Zbigniew Jędrzejewski-Szmek wrote: > Exactly because they do not require being upgraded in lock-step, doing > conversion to the local time locally is "racy". Assuming we have up-to-date > timezone database locally, with the patch that was merged today we can > answer the question "what the local time should be remotely", but not > necessarily "what the local time is remotely". > > If we go to the trouble of displaying the remote local time, imho we > should do it as the remote does. No, we should care about the *state* of the system, and that is its time value and its configured location on earth. Systemd has no business in "fixing" the *presentation* logic of these values. It is not an API for the timezone database. These tools already exist. Please stop trying to add insufficient and half-thought-through APIs to cover problems which just do not exist in reality or do not need to be worked-around by systemd. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] timedatectl: fix when queried system has differn't timezone
On Mon, Mar 23, 2015 at 12:44 PM, Shawn Landden wrote: > Also allow getting time from time(2) when BUS_TRANSPORT_MACHINE. > > v2: check for error Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] timedated: add LocalTimeUSec via dbus
On Tue, Mar 24, 2015 at 5:34 AM, Shawn Landden wrote:
> On Mon, Mar 23, 2015 at 6:52 PM, Zbigniew Jędrzejewski-Szmek
> wrote:
>> On Mon, Mar 23, 2015 at 04:24:38AM -0700, Shawn Landden wrote:
>>> ---
>>> src/timedate/timedated.c | 24
>>> 1 file changed, 24 insertions(+)
>>>
>>> diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c
>>> index ca771d5..f83b99c 100644
>>> --- a/src/timedate/timedated.c
>>> +++ b/src/timedate/timedated.c
>>> @@ -38,6 +38,7 @@
>>> #include "bus-common-errors.h"
>>> #include "event-util.h"
>>> #include "selinux-util.h"
>>> +#include "time-util.h"
>>>
>>> #define NULL_ADJTIME_UTC "0.0 0 0\n0\nUTC\n"
>>> #define NULL_ADJTIME_LOCAL "0.0 0 0\n0\nLOCAL\n"
>>> @@ -361,6 +362,28 @@ static int property_get_time(
>>> return sd_bus_message_append(reply, "t", now(CLOCK_REALTIME));
>>> }
>>>
>>> +/* gmtime(LocalTimeUSec % USEC_PER_SEC) is useful as long as you ignore GNU
>>> + * extensions of tm_gmtoff and tm_zone, and their ourgrowth in strftime(3)
>>> + */
>>> +static int property_get_local_time(
>>> +sd_bus *bus,
>>> +const char *path,
>>> +const char *interface,
>>> +const char *property,
>>> +sd_bus_message *reply,
>>> +void *userdata,
>>> +sd_bus_error *error)
>>> +{
>>> +struct tm tm;
>>> +struct timespec ts;
>>> +usec_t t;
>>> +
>>> +t = now(CLOCK_REALTIME);
>>> +(void)timespec_store(&ts, t);
>>> +assert_se(localtime_r(&dummy, &ts.tv_sec));
>>> +return sd_bus_message_append(reply, "t", t + (tm->tm_gmtoff *
>>> USEC_PER_SEC));
>>> +}
>>> +
>>> static int property_get_ntp_sync(
>>> sd_bus *bus,
>>> const char *path,
>>> @@ -671,6 +694,7 @@ static const sd_bus_vtable timedate_vtable[] = {
>>> SD_BUS_PROPERTY("NTP", "b", bus_property_get_bool,
>>> offsetof(Context, use_ntp), SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
>>> SD_BUS_PROPERTY("NTPSynchronized", "b", property_get_ntp_sync, 0,
>>> 0),
>>> SD_BUS_PROPERTY("TimeUSec", "t", property_get_time, 0, 0),
>>> +SD_BUS_PROPERTY("LocalTimeUSec", "t", property_get_local_time, 0,
>>> 0),
>>> SD_BUS_PROPERTY("RTCTimeUSec", "t", property_get_rtc_time, 0, 0),
>>> SD_BUS_METHOD("SetTime", "xbb", NULL, method_set_time,
>>> SD_BUS_VTABLE_UNPRIVILEGED),
>>> SD_BUS_METHOD("SetTimezone", "sb", NULL, method_set_timezone,
>>> SD_BUS_VTABLE_UNPRIVILEGED)
>>
>> This patch seems the most reasonable of the proposed solutions.
>> It answers the question "What does the remote host think local time is?"
>> unambigously.
>>
>> The other patch proposed by Shawn mixes the remote UTC time with local
>> information about timezones, which doesn't seem as clean.
> These are not for the same problem. We need both. I want to ship a
> checksum of the zoneinfo file with the timezone, but its hard to do
> this cleanly as using coreutils from C is a PITA.
Again, systemd is NOT a "remote glibc" API. We are not doing that.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] timedated: add LocalTimeUSec via dbus
On Tue, Mar 24, 2015 at 2:52 AM, Zbigniew Jędrzejewski-Szmek
wrote:
> On Mon, Mar 23, 2015 at 04:24:38AM -0700, Shawn Landden wrote:
>> ---
>> src/timedate/timedated.c | 24
>> 1 file changed, 24 insertions(+)
>>
>> diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c
>> index ca771d5..f83b99c 100644
>> --- a/src/timedate/timedated.c
>> +++ b/src/timedate/timedated.c
>> @@ -38,6 +38,7 @@
>> #include "bus-common-errors.h"
>> #include "event-util.h"
>> #include "selinux-util.h"
>> +#include "time-util.h"
>>
>> #define NULL_ADJTIME_UTC "0.0 0 0\n0\nUTC\n"
>> #define NULL_ADJTIME_LOCAL "0.0 0 0\n0\nLOCAL\n"
>> @@ -361,6 +362,28 @@ static int property_get_time(
>> return sd_bus_message_append(reply, "t", now(CLOCK_REALTIME));
>> }
>>
>> +/* gmtime(LocalTimeUSec % USEC_PER_SEC) is useful as long as you ignore GNU
>> + * extensions of tm_gmtoff and tm_zone, and their ourgrowth in strftime(3)
>> + */
>> +static int property_get_local_time(
>> +sd_bus *bus,
>> +const char *path,
>> +const char *interface,
>> +const char *property,
>> +sd_bus_message *reply,
>> +void *userdata,
>> +sd_bus_error *error)
>> +{
>> +struct tm tm;
>> +struct timespec ts;
>> +usec_t t;
>> +
>> +t = now(CLOCK_REALTIME);
>> +(void)timespec_store(&ts, t);
>> +assert_se(localtime_r(&dummy, &ts.tv_sec));
>> +return sd_bus_message_append(reply, "t", t + (tm->tm_gmtoff *
>> USEC_PER_SEC));
>> +}
>> +
>> static int property_get_ntp_sync(
>> sd_bus *bus,
>> const char *path,
>> @@ -671,6 +694,7 @@ static const sd_bus_vtable timedate_vtable[] = {
>> SD_BUS_PROPERTY("NTP", "b", bus_property_get_bool,
>> offsetof(Context, use_ntp), SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
>> SD_BUS_PROPERTY("NTPSynchronized", "b", property_get_ntp_sync, 0,
>> 0),
>> SD_BUS_PROPERTY("TimeUSec", "t", property_get_time, 0, 0),
>> +SD_BUS_PROPERTY("LocalTimeUSec", "t", property_get_local_time, 0,
>> 0),
>> SD_BUS_PROPERTY("RTCTimeUSec", "t", property_get_rtc_time, 0, 0),
>> SD_BUS_METHOD("SetTime", "xbb", NULL, method_set_time,
>> SD_BUS_VTABLE_UNPRIVILEGED),
>> SD_BUS_METHOD("SetTimezone", "sb", NULL, method_set_timezone,
>> SD_BUS_VTABLE_UNPRIVILEGED)
>
> This patch seems the most reasonable of the proposed solutions.
> It answers the question "What does the remote host think local time is?"
> unambigously.
>
> The other patch proposed by Shawn mixes the remote UTC time with local
> information about timezones, which doesn't seem as clean.
>
> Kay said:
>> Transmitting several absolute time stamps sounds wrong.
> The second timestamp is what the user sees, so in some way it is a
> very significant thing. It is the outcome of the remote knowledge
> about the time and its config and timezone database. We aren't making
> any promises about the accuracy of that, but just trying to accurately
> convey that information. Seems fine to me to transmit this bit of
> information.
No, it is not fine, and we are not going to do that.
We do not transmit several timestamps, the local time on the remote
machine is UTC + its configured location. Tools who represent that
need to convert it into their presentation and not systemd.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] timedated: Add a LocalOffset property for timezone offset
On Mon, Mar 23, 2015 at 4:56 PM, Kay Sievers wrote: > On Mon, Mar 23, 2015 at 3:49 PM, Stef Walter wrote: >> It seems that timedatectl itself needs information about remote local >> time, since when connecting remotely over DBus it gets the local time >> wrong. [1] > > Yeah, it's currently a mix of local vs. remote data. If timedatctl > should work correctly on a remote host, it needs to fixed. Btw, we had plans to support the kernel' side of localtime (really broken by design) for FAT and SCSI and network stuff, but it turned out to be an unsupportable mess, and we just declared FAT timestamps as UTC (like Android does). Unless someone has an idea how to fix and use all that reliably, I'll just go and remove the DST timezone data parser src/shared/time-dst.c and its user in timedatctl. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] timedated: Add a LocalOffset property for timezone offset
On Mon, Mar 23, 2015 at 3:49 PM, Stef Walter wrote: > On 23.03.2015 15:26, Kay Sievers wrote: >> On Mon, Mar 23, 2015 at 1:46 PM, David Herrmann >> wrote: >>> Hi >>> >>> On Mon, Mar 23, 2015 at 6:32 AM, Lennart Poettering >>> wrote: >>>> On Thu, 19.03.15 14:39, David Herrmann (dh.herrm...@gmail.com) wrote: >>>> >>>>> Hmm, so this is a convenience call. You could just set tm.tm_zone >>>>> locally and use mktime() with the value retrieved by "Timezone"? Yeah, >>>>> the time-api is awful with global variables, but that's not really our >>>>> fault, is it? >>>> >>>> This would not work, as struct tm's .tm_zone field is not sufficient >>>> to indicate a timezone. The code would have to set $TZ and call tzset(). >>> >>> I see. The Unix-way of doing things! >>> >>>> Given the simplicity of this I'd probably just merge Stef's >>>> patch... It *is* kinda nice given that the timezone database is >>>> constantly updated and having this exposed on the bus so that it is >>>> accessible remotely has the benefit that you get the actual timezone >>>> information in effect on the remote system, and not a possible >>>> out-of-date timezone from the local database. If you follow what I mean... >>> >>> ..locale data is also updated regularly but we don't export >>> locale-files on the bus ;) >>> >>> Anyway, if we add pseudo-redundant APIs, I'd go with a "LocalTime" >>> field as Shawn suggested. This is what the bus-user is interested in, >>> right? If they need more data (like DST), they should just parse >>> zoneinfo. And with "LocalTime" we avoid any ambiguity regarding DST. >> >> Transmitting several absolute time stamps sounds wrong. >> Transmitting the offset sounds as wrong as tz_minuteswest is and it got >> killed >> for that reason. >> >> Why does anybody ever need anything else than the actual UTC time and >> the configured timezone of the machine? > > Yes, we do. In Cockpit we want to show the server's local time, in the > server's timezone. This is similar to how GNOME shows you the local time > in the local timezone. > > But we don't have easy access to libc and its zoneinfo file parser from > javascript running in a browser. We do have access to DBus [0] But it is not systemd's task to cover for missing functionality in the cockpit architecture. We should not add redundant interfaces just provide data for a specific user. The data systemd provides over the bus is the the same as the running system provides to the local user: the UTC time + the time zone. Everything else should be a task of the presentation, in this case cockpit. > So obviously we could invent a DBus service called timedated2 (or > whatever) to do what we need ... but I figured I'd see if timedated > could do what we needed first. I don't think so. Systemd covers operating system data, but I doubt it should provide "remote glibc" functionality. > It seems that timedatectl itself needs information about remote local > time, since when connecting remotely over DBus it gets the local time > wrong. [1] Yeah, it's currently a mix of local vs. remote data. If timedatctl should work correctly on a remote host, it needs to fixed. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] timedated: Add a LocalOffset property for timezone offset
On Mon, Mar 23, 2015 at 1:46 PM, David Herrmann wrote: > Hi > > On Mon, Mar 23, 2015 at 6:32 AM, Lennart Poettering > wrote: >> On Thu, 19.03.15 14:39, David Herrmann (dh.herrm...@gmail.com) wrote: >> >>> Hmm, so this is a convenience call. You could just set tm.tm_zone >>> locally and use mktime() with the value retrieved by "Timezone"? Yeah, >>> the time-api is awful with global variables, but that's not really our >>> fault, is it? >> >> This would not work, as struct tm's .tm_zone field is not sufficient >> to indicate a timezone. The code would have to set $TZ and call tzset(). > > I see. The Unix-way of doing things! > >> Given the simplicity of this I'd probably just merge Stef's >> patch... It *is* kinda nice given that the timezone database is >> constantly updated and having this exposed on the bus so that it is >> accessible remotely has the benefit that you get the actual timezone >> information in effect on the remote system, and not a possible >> out-of-date timezone from the local database. If you follow what I mean... > > ..locale data is also updated regularly but we don't export > locale-files on the bus ;) > > Anyway, if we add pseudo-redundant APIs, I'd go with a "LocalTime" > field as Shawn suggested. This is what the bus-user is interested in, > right? If they need more data (like DST), they should just parse > zoneinfo. And with "LocalTime" we avoid any ambiguity regarding DST. Transmitting several absolute time stamps sounds wrong. Transmitting the offset sounds as wrong as tz_minuteswest is and it got killed for that reason. Why does anybody ever need anything else than the actual UTC time and the configured timezone of the machine? Localtime is "presentation only", if the databases are out-of-date, then they are out-of-date, who cares? We are not in the business to support unmaintained boxes with a bus api. It doesn't makes sense to play games here or make wild promises for stuff that does not even solve a real problem. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] rules: storage - whitelist partitioned MS & MMC devices
On Tue, Mar 17, 2015 at 5:00 PM, Mantas Mikulėnas wrote: > Accidentally dropped in 1aff20687f4868575. > --- > rules/60-persistent-storage.rules | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > +KERNEL!="loop*|mmcblk[0-9]*|mspblk[0-9]*|nvme*|sd*|sr*|vd*", > GOTO="persistent_storage_end" We can't do that, we need to ignore the mmc*rpmb devices: http://cgit.freedesktop.org/systemd/systemd/commit/?id=b87b01cf83947f467f3c46d9831cd67955fc46b9 Maybe "mmcblk*[0-9]" will work? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] systemctl: Add reboot to firmware support
On Tue, Mar 17, 2015 at 1:12 PM, Jan Janssen wrote: > Dimitri John Ledkov intel.com> writes: > > Also, the fact that there have been people asking questions about how to get > to the EFI/BIOS has always been there. With this you can just tell them to > "systemctl --firmware reboot" on any modern computer and be done with it. It should be: systemctl reboot --firmware Local options of a verb should only work locally and throw an error if used before the verb. It is not a problem of this patch, but systemctl should be fixed to work like that (like udevadm), and not mess all local things into global command line switching handling. The documentation is also confusing, where it describes in a global section the local verb-specific options. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] systemctl: Add reboot to firmware support
On Tue, Mar 17, 2015 at 9:10 AM, Jan Janssen wrote: > I certainly see the point of not adding fsck mode indication, but I'd still > like to see > this one go in. If your firmware and/or bootloader won't give you a chance > to, the os is > your only chance should you still be able to boot to it. And it's quite hard > to even find > out how to reboot to firmware unless you know that it's called os indication. > There isn't > even any convenient tool out there that allows you to do so, the best thing > is fiddling > with the variable yourself using the shell[1]. Right, it is a firmware specific task, part of the EFI spec, and might be the only way to enter a firmware. The "don't configure services/tasks with EFI" obviously does not apply here. The global option --firmware sounds weird, but maybe it is just a documentation task, and the options which belong only to a specific verb should be documented with the verb itself. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] fsck: Add support for EFI variable based fsck indication
On Tue, Mar 17, 2015 at 9:15 AM, Jan Janssen wrote: >> Gesendet: Sonntag, 15. März 2015 um 19:58 Uhr >> Nobody would write to the flash on kernel updates, we only possibly >> write to the ESP filesystem. The flash is not meant for such use >> cases, it is known to brick all sorts of machines, and not to be >> mis-used for such features. > As far as I remember, the bricking mainly happened because the kernel was > writing kilobytes (maybe megabytes) worth of crashdumbs. This feature only > touches a couple of bytes. I have a machine that refuses accept any more variable setup just after committing many small variable changes. It is probably the garbage collection or anything in the simple flash storage management that goes wrong. It can only be reset by resetting the entire firmware to the defaults in the firmware menu, sometimes only after a couple of tries. The EFI variable storage is better left alone and not to be used for anything else than the boot loader or at installation time. The reboot-to-firmware sounds ok, there might be no other way of doing that on EFI, it is a firmware specific task, "normal" services should not start using EFI for configuration. > Though, I do see the other reservations against this. Though, someone might > wanna close https://bugs.freedesktop.org/show_bug.cgi?id=88330 then. Changed the subject and added a comment. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] bootloader time on a non-EFI bootloader
On Mon, Mar 16, 2015 at 11:29 AM, Umut Tezduyar Lindskog wrote: > I would like to pass the time it was spent in bootloader to systemd. > Is there a kernel command line to pass this information on non EFI > bootloader? Or is there an another way? No, there isn't anything I know of. The kernel boot protocol should probably be extended to accept a block of values to be passed from the loader to the OS, and be exported somewhere by the kernel itself to userspace. Overloading the kernel command line with that does not sound like the right approach. We should not support anything like that from systemd. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] fsck: Add support for EFI variable based fsck indication
On Sun, Mar 15, 2015 at 8:08 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Sun, Mar 15, 2015 at 07:58:35PM +0100, Kay Sievers wrote: >> If the filesytem is too dumb to have that info in the superblock flags >> to store, to request a forced fsck, it is the problem of the file >> system to fix and nothing we need to solve in systemd. > Are there filesystems which have such a flag? Some have the "not cleanly unmounted" flag, or mount counters for regular checks. I don't know any details. Maybe this flag or counter could be mis-used to force such a check. In any case, the superblock and corresponding fsck tool would be the right place to put such a force check flag/logic, the info would be stored locally with the actual filesystem, but would not require a r/w mount to place that information. Working around such missing basic filesystem features in systemd code does not sound like the right approach. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] fsck: Add support for EFI variable based fsck indication
On Sun, Mar 15, 2015 at 7:59 PM, Andrei Borzenkov wrote: > В Sun, 15 Mar 2015 19:48:10 +0100 > Zbigniew Jędrzejewski-Szmek пишет: >> > No, they are absolutely not. Changing the EFI flash comes with >> > unpredictable risks, the flash is not meant to or designed for be >> > written to during any normal operation. >> Requesting fsck is not a normal operation. If the flash is suitable >> to be written whenever the kernel is updated, it should be also OK >> to request a fsck through it. For users of many distributions (and >> kernel developers certainly), requesting fsck is a much rarer operation. >> > > That is rather an argument to *not* store kernel in ESP :) Storing the kernel in the ESP has no relation to EFI variables. EFI variables are only changed if the bootloader gets installed, not when the kernel is updated. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Enabling timesyncd in virtual machines
On Sun, Mar 15, 2015 at 7:50 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Sun, Mar 15, 2015 at 07:47:46PM +0100, Kay Sievers wrote: >> On Fri, Mar 13, 2015 at 8:25 PM, Michael Marineau >> wrote: >> > Greetings, >> > >> > Currently systemd-timesyncd.service includes >> > ConditionVirtualization=no, disabling it in both containers and >> > virtual machines. Each VM platform tends to deal with or ignore the >> > time problem in their own special ways, KVM/QEMU has the kernel time >> > source kvm-clock, Xen has had different schemes over the years, VMware >> > expects a userspace daemon sync the clock, and other platforms are >> > content to drift with the wind as far as I can tell. >> > >> > I don't know of a robust way to know if a platform needs a little >> > extra help from userspace to keep the clock sane or not but it seems >> > generally safer to try than to risk drifting. Does anyone know of a >> > reason to leave timesyncd off by default? Otherwise switching to >> > ConditionVirtualization=!container should be reasonable. >> >> Sounds reasonable. Until someone has a better or clear idea how to >> solve that reliably, I turned the option around. > What about adding > > ConditionVirtualization=!kvm ? Even there, things like leap seconds are not covered. And I'm not sure if the "paravirtualized clock" is always configured. I guess it's safest bet to just keep timesyncd running, until someone knows for sure when we can optimize it away for which environment. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] fsck: Add support for EFI variable based fsck indication
On Sun, Mar 15, 2015 at 7:48 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Sun, Mar 15, 2015 at 06:48:24PM +0100, Kay Sievers wrote: >> It is legacy and does not need new features. It worked in the past and >> will continue to work in the future, but it does not need new >> questionable and possibly unreliable or dangerous features. The recent >> merging of fsckd was already the wrong thing to do. > Calling it legacy does not make it go away. If we had a stable non-fsck-using > filesystem available, we could start discussing removing fsck support. > But we don't. It's one thing to remove stuff once we have something > better, and completely different to remove support for widely used > things. Nobody talks about things going away, we just should not add more non-trivial legacy support, that is all. >> >> the kernel command line should be sufficient enough. >> > The kernel command line is not a good fit for a few reasons. >> >> The kernel commandline woked fine in the past and will be fine today, >> especially for such a legacy feature. > Support for /forcefsck (or whatever it was called) was removed with the > promise to provide a replacement which does not require touching the fs. > Kernel commandline is just too unwieldy for users. Writing to the file system content to request a check, which would happen when things are already inconsistent, is a really stupid idea. If the filesytem is too dumb to have that info in the superblock flags to store, to request a forced fsck, it is the problem of the file system to fix and nothing we need to solve in systemd. >> No, they are absolutely not. Changing the EFI flash comes with >> unpredictable risks, the flash is not meant to or designed for be >> written to during any normal operation. > Requesting fsck is not a normal operation. It is just a normal system operation. It needs to be fixed properly if needed, not with dirty work-arounds like this. > If the flash is suitable > to be written whenever the kernel is updated, it should be also OK > to request a fsck through it. For users of many distributions (and > kernel developers certainly), requesting fsck is a much rarer operation. Nobody would write to the flash on kernel updates, we only possibly write to the ESP filesystem. The flash is not meant for such use cases, it is known to brick all sorts of machines, and not to be mis-used for such features. >> To avoid any possible misunderstanding here: >> >> Systemd will not use the fragile EFI flash store to configure services >> or request system operation modes. The kernel command line is good >> enough here. >> >> You will not apply this patch. > I'd prefer to have a discussion and reach conclusions, not the other > way around. Sorry, there is nothing to discuss, systemd will not mis-use the fragile firmware flash for normal operations, and especially not to support legacy features. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Enabling timesyncd in virtual machines
On Fri, Mar 13, 2015 at 8:25 PM, Michael Marineau wrote: > Greetings, > > Currently systemd-timesyncd.service includes > ConditionVirtualization=no, disabling it in both containers and > virtual machines. Each VM platform tends to deal with or ignore the > time problem in their own special ways, KVM/QEMU has the kernel time > source kvm-clock, Xen has had different schemes over the years, VMware > expects a userspace daemon sync the clock, and other platforms are > content to drift with the wind as far as I can tell. > > I don't know of a robust way to know if a platform needs a little > extra help from userspace to keep the clock sane or not but it seems > generally safer to try than to risk drifting. Does anyone know of a > reason to leave timesyncd off by default? Otherwise switching to > ConditionVirtualization=!container should be reasonable. Sounds reasonable. Until someone has a better or clear idea how to solve that reliably, I turned the option around. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shutdown: add kexec loading, avoid calling `kexec` binary unnessecarily
On Sun, Mar 15, 2015 at 7:31 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> On Wed, Mar 11, 2015 at 05:22:18PM -0700, Shawn Landden wrote:
>> Still use helper when Xen Dom0, to avoid duplicating some hairy code.
>>
>> I think the rbtree version was far more understandable as greedy_realloc0()
>> is very messy to do correctly.
>>
>> Take fopenat() from lsof.
>> Add opendirat()
>>
>> Future: generate BootLoaderSpec files for other kernel install locations
>>
>> v5: fix syscall invocation from draft version
>> v6: usr either /boot/efi or /boot
>> +static int fopen_to_open(const char *m) {
>> +int flags;
>> +
>> +if (strchr(m, '+'))
>> +flags = O_RDWR;
>> +else if (m[0] == 'r')
>> +flags = O_RDONLY;
>> +else if (m[0] == 'w' || m[0] == 'a')
>> +flags = O_WRONLY;
>> +else
>> +return(0);
>> +
>> +if (m[0] == 'a')
>> +flags |= O_APPEND|O_CREAT;
>> +if (m[0] == 'w')
>> +flags |= O_TRUNC|O_CREAT;
>> +
>> +flags |= O_NONBLOCK;
>> +
>> +return flags;
>> +}
> I really dislike this part. The open() interface is so much better
> than fopen().
We first need a clear definition of what this functionality is
supposed to solve and how and why we want that in systemd, and that we
can hold the promise we are making here. Unless that is done and looks
reasonable and acceptable, I see no way of this being merged.
Please do not waste any more time with style questions. The whole
approach in this patch does not seem convincing, and the idea of
parsing boot loader specifics with systemd code can't work out from my
point of view.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] fsck: Add support for EFI variable based fsck indication
On Sun, Mar 15, 2015 at 4:44 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Sun, Mar 15, 2015 at 03:23:19PM +0100, Kay Sievers wrote: >> On Sun, Mar 15, 2015 at 11:56 AM, Jan Janssen wrote: >> > --- >> > man/systemctl.xml | 26 >> > shell-completion/bash/systemctl.in | 8 - >> > shell-completion/zsh/_systemctl.in | 2 ++ >> > src/fsck/fsck.c| 63 >> > + >> > src/shared/efivars.h | 21 +++-- >> > src/systemctl/systemctl.c | 64 >> > +- >> >> Fsck is really something from the past, it should not be extended >> beyond its current support. > Filesystems which require fsck are in wide use and will be in wide use > for the forseeable future. It is legacy and does not need new features. It worked in the past and will continue to work in the future, but it does not need new questionable and possibly unreliable or dangerous features. The recent merging of fsckd was already the wrong thing to do. >> the kernel command line should be sufficient enough. > The kernel command line is not a good fit for a few reasons. The kernel commandline woked fine in the past and will be fine today, especially for such a legacy feature. > and yet another is that changing the commandline is a problem in the > scheme in which kernel+initrd+cmdline are signed together. Such kernels will just not be used with a rootfs that needs fsck. It makes no sense to sign andn seal the kernel for a legacy unsigned file system. > EFI variables are the right solution for EFI systems. No, they are absolutely not. Changing the EFI flash comes with unpredictable risks, the flash is not meant to or designed for be written to during any normal operation. To avoid any possible misunderstanding here: Systemd will not use the fragile EFI flash store to configure services or request system operation modes. The kernel command line is good enough here. You will not apply this patch. >> Using non-volatile EFI variables for normal system operations does not >> sound right, we should not start using that fragile subsystem for >> things like this > Volatile indeed sounds better. Are there volatile variables which are survive > a reboot but are then erased automatically? No, there is only volatile (in RAM from the bootloader to the OS), or non-volatile (writing to the flash). Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev breaks hostap linkage of raw/user interfaces, causing wpa_supplicant problems
On Sun, Mar 15, 2015 at 4:07 PM, Thomas Richter wrote: > On 15.03.2015 15:38, Kay Sievers wrote: > >> grep ./sys/class/net/*/name_assign_type > > grep: /sys/class/net/eth0/name_assign_type: Invalid argument > grep: /sys/class/net/lo/name_assign_type: Invalid argument > grep: /sys/class/net/wifi0/name_assign_type: Invalid argument > grep: /sys/class/net/wlan0/name_assign_type: Invalid argument > > Thus, apparently, nothing useful right now. This is run as root, and I > currently fixed /etc/udev/rules.d/70-persistent-net.rules manually to get > wifi0 and wlan0 as above. > > This is a Debian wheezy, with a custom 3.18.7 kernel. The original debian > kernel is too old (yes, really!) for this old laptop as it did not support > the i830 graphics reliably. The kernel driver can tell userspace what kind of name it used to create the device. Maybe the driver you use add that information. Here is the relevant kernel side: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=685343fc3ba61a1f6eef361b786601123db16c28 Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev breaks hostap linkage of raw/user interfaces, causing wpa_supplicant problems
On Sun, Mar 15, 2015 at 1:40 PM, Thomas Richter wrote: > udev seems to create a problem here with the hostap (prism2) kernel driver. > Unlike many wifi devices, the hostap device driver always creates paired > interfaces, a raw interface (wifiX) and a network interface (wlanX) that > represents the configured network. > > Unfortunately, udev (or hostap?) does not seem to be aware of this linkage, > and hence, if you have two wifi radios in your system, may rename the second > (wlanX) without the first (wifiX), and hence causing a name mismatch between > the two. > > In general, this is not a problem, however, wpa_supplicant seems to depend > on the linkage of the names. Hence, if wifiX does not match wlanX, > wpa_supplicant will be unable to provide a WPA2 connection over a hostap > driven wifi connection. > > Even worse, the complete procedure is completely untransparent to the user, > i.e. neither wpa_supplicant (nor network-manager, depending on > wpa_supplicant) nor network-manager provide a useful error message. > > Any chance of fixing this problem? Is this "only" a configuration issue? Is > this an issue of hostap? Is this an issue of wpa_supplicant? What does: $ grep . /sys/class/net/*/name_assign_type print? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] fsck: Add support for EFI variable based fsck indication
On Sun, Mar 15, 2015 at 11:56 AM, Jan Janssen wrote: > --- > man/systemctl.xml | 26 > shell-completion/bash/systemctl.in | 8 - > shell-completion/zsh/_systemctl.in | 2 ++ > src/fsck/fsck.c| 63 + > src/shared/efivars.h | 21 +++-- > src/systemctl/systemctl.c | 64 > +- Fsck is really something from the past, it should not be extended beyond its current support. Using non-volatile EFI variables for normal system operations does not sound right, we should not start using that fragile subsystem for things like this, the kernel command line should be sufficient enough. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] rules: Fix by-path of mmc RPMB partitions and don't blkid them
On Fri, Feb 13, 2015 at 10:35 AM, Martin Pitt wrote: > Kay Sievers [2015-02-13 10:12 +0100]: >> This looks awful. We should not litter generic rules with exotic niche >> use cases like this. It will end up in a mess. > > Fully agreed :/ It is a rather small whitelist for now, which should not catch any newly added device driver added in the future. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to factory reset?
On Thu, Mar 12, 2015 at 11:30 AM, David Herrmann wrote: > On Thu, Mar 12, 2015 at 4:57 AM, Andrei Borzenkov wrote: >> В Wed, 11 Mar 2015 18:50:23 +0100 >> Kay Sievers пишет: >> >>> On Wed, Mar 11, 2015 at 6:32 PM, Chris Murphy >>> wrote: >>> > On Wed, Mar 11, 2015 at 2:22 AM, Tobias Hunger >>> > wrote: >>> >>> If you're concerned about bootloader configuration modification as a >>> >>> threat vector, then it needs to go on an encrypted volume. This >>> >>> suggests an initial bootloader configuration that only enables the >>> >>> user to supply a passphrase/key file to unlock that volume, and then >>> >>> load a new bootloader configuration file. >>> >> >>> >> I am still hoping secure boot and sd-boot will solve this issue >>> >> mid-term by making sure all the early boot components are signed >>> >> properly. >>> > >>> > The bootloader configuration files aren't signed. Maybe the should be. >>> >>> With systemd-boot, there will be no config to sign: >>> >>> https://harald.hoyer.xyz/2015/02/25/single-uefi-executable-for-kernelinitrdcmdline/ >>> >> >> How exactly putting files in a container solves the problem that they >> are not signed? This is not quite obvious from blog post. > > The config/etc. snippets are now part of the _signed_ EFI binary, > which is always verified by the firmware. Therefore, we don't need to > verify the other snippets separately. http://people.freedesktop.org/~kay/efistub.txt Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build: generate pkg-config files during configure
On Thu, Mar 12, 2015 at 5:09 AM, Lucas De Marchi
wrote:
> On Tue, Mar 10, 2015 at 3:04 PM, Jeff Waugh wrote:
>> Generate pkg-config files during configure as God (Havoc) intended. This
>> fixes
>> all of systemd's pkg-config files when cross-compiling (and possibly other
>> use
>> cases).
> Kay, please take a look on this. There's a similar patch pending to
> kmod on [1]. I'm still not sure what exactly it's fixing... seems like
> just that it would not replace/expand all occurrences of the
> variables...
AC_CONFIG_FILES is usually meant to create/prepare autoconf/automake
related files needed for the build process, and not to produce plain
package content to ship.
Not that quoting autoconf manuals would make the autotools mess any
better, but there is also this. :)
"Similarly, you should not rely on AC_CONFIG_FILES to replace bindir
and friends in your shell scripts and other files; instead, let make
manage their replacement. For instance Autoconf ships templates of its
shell scripts ending with ‘.in’, and uses a makefile snippet similar
to the following to build scripts like autoheader and autom4te:
edit = sed \
-e 's|@bindir[@]|$(bindir)|g' \
-e 's|@pkgdatadir[@]|$(pkgdatadir)|g' \
-e 's|@prefix[@]|$(prefix)|g'
autoheader autom4te: Makefile
rm -f $@ $@.tmp
srcdir=''; \
test -f ./$@.in || srcdir=$(srcdir)/; \
$(edit) $${srcdir}$@.in >$@.tmp
chmod +x $@.tmp
chmod a-w $@.tmp
mv $@.tmp $@
autoheader: $(srcdir)/autoheader.in
autom4te: $(srcdir)/autom4te.in"
http://www.gnu.org/software/autoconf/manual/autoconf.html#Installation-Directory-Variables
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shutdown: add kexec loading, avoid calling `kexec` binary unnessecarily
On Thu, Mar 12, 2015 at 2:36 AM, Shawn Landden wrote: > On Wed, Mar 11, 2015 at 6:24 PM, Kay Sievers wrote: >> >> On Thu, Mar 12, 2015 at 2:07 AM, Shawn Landden >> wrote: >> > On Wed, Mar 11, 2015 at 5:51 PM, Kay Sievers wrote: >> >> >> >> On Thu, Mar 12, 2015 at 1:22 AM, Shawn Landden >> >> wrote: >> >> > Still use helper when Xen Dom0, to avoid duplicating some hairy code. >> >> > >> >> > I think the rbtree version was far more understandable as >> >> > greedy_realloc0() >> >> > is very messy to do correctly. >> >> > >> >> > Take fopenat() from lsof. >> >> > Add opendirat() >> >> >> >> We have that in util.c :: xopendirat() >> >> >> >> > Future: generate BootLoaderSpec files for other kernel install >> >> > locations >> >> >> >> This approach duplicates, the potentially complex, boot manager kernel >> >> selection logic. >> >> >> >> The recent systemd-boot boot loader and efi stub loader which carries >> >> the kernel, the cmdline, the initrd in one single EFI binary will also >> >> not use any boot loader snippets, it will be discovered by the loader >> >> itself, which parses the PE/COFF files and looks for specific content. >> >> >> >> The snippets are meant to unify the boot loader *configuration*, but >> >> they do not mean that every bootable kernel will or should have one. >> >> There might be many ways for kernels to be found by the boot loader, >> >> the snippets are just one source for that. >> >> >> >> I'm not sure what exact problem this patch tries to solve, >> > >> > rebooting with kexec is faster than a full reboot. Currently we do not >> > support kexec very well. Lennart asked for something like this, but >> > perhaps >> > we no longer want to support kexec loading? >> >> I kind of miss a description what this change is supposed to support >> in the end. It can't be described with "replacing a call to a binary". >> >> Automatic searching and deciding what kernel to boot, and how to >> search for these kernels, and how all that should continue to work >> reliably in the longer run, while the boot loaders underneath improve >> and change; that is something we should define before and have a clear >> idea, before we copy only parts of that logic from the current tools. >> > I thought you wrote a specification? > freedesktop.org/wiki/Specifications/BootLoaderSpec/ It does not specify how to find or select new kernels, and it probably never will. Boot loaders are free to add anything they want to offer. The boot loader spec mainly tries to unify the explicit *configuration*, but not the logic inside the boot loaders. Even gummiboot has its own config file, which specifies the pattern for the default selection logic, that is all intentionally not part of the spec, but it changes the way the selection logic works inside the loader. Now with the boot loader merged into system tree, we could potentially share some code here, but I still don't see how all that fits together, and we should find that out before we make any promises like that. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shutdown: add kexec loading, avoid calling `kexec` binary unnessecarily
On Thu, Mar 12, 2015 at 2:07 AM, Shawn Landden wrote: > On Wed, Mar 11, 2015 at 5:51 PM, Kay Sievers wrote: >> >> On Thu, Mar 12, 2015 at 1:22 AM, Shawn Landden >> wrote: >> > Still use helper when Xen Dom0, to avoid duplicating some hairy code. >> > >> > I think the rbtree version was far more understandable as >> > greedy_realloc0() >> > is very messy to do correctly. >> > >> > Take fopenat() from lsof. >> > Add opendirat() >> >> We have that in util.c :: xopendirat() >> >> > Future: generate BootLoaderSpec files for other kernel install locations >> >> This approach duplicates, the potentially complex, boot manager kernel >> selection logic. >> >> The recent systemd-boot boot loader and efi stub loader which carries >> the kernel, the cmdline, the initrd in one single EFI binary will also >> not use any boot loader snippets, it will be discovered by the loader >> itself, which parses the PE/COFF files and looks for specific content. >> >> The snippets are meant to unify the boot loader *configuration*, but >> they do not mean that every bootable kernel will or should have one. >> There might be many ways for kernels to be found by the boot loader, >> the snippets are just one source for that. >> >> I'm not sure what exact problem this patch tries to solve, > > rebooting with kexec is faster than a full reboot. Currently we do not > support kexec very well. Lennart asked for something like this, but perhaps > we no longer want to support kexec loading? I kind of miss a description what this change is supposed to support in the end. It can't be described with "replacing a call to a binary". Automatic searching and deciding what kernel to boot, and how to search for these kernels, and how all that should continue to work reliably in the longer run, while the boot loaders underneath improve and change; that is something we should define before and have a clear idea, before we copy only parts of that logic from the current tools. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shutdown: add kexec loading, avoid calling `kexec` binary unnessecarily
On Thu, Mar 12, 2015 at 2:12 AM, Shawn Landden wrote: > On Wed, Mar 11, 2015 at 5:51 PM, Kay Sievers wrote: >> >> On Thu, Mar 12, 2015 at 1:22 AM, Shawn Landden >> wrote: >> > Still use helper when Xen Dom0, to avoid duplicating some hairy code. >> > >> > I think the rbtree version was far more understandable as >> > greedy_realloc0() >> > is very messy to do correctly. >> > >> > Take fopenat() from lsof. >> > Add opendirat() >> >> We have that in util.c :: xopendirat() >> >> > Future: generate BootLoaderSpec files for other kernel install locations >> >> This approach duplicates, the potentially complex, boot manager kernel >> selection logic. >> > > Hopefully it could be unified in some way. I find it disturbing that systemd > will have a great deal of EFI-specific code. Well, I find it a lot more disturbing that we "want" kexec, which is in many cases just a pretty dirty short-cut for a reboot. And we need to teach that short-cut all sorts of logic and more dirty tricks is has no business with, just to be able to do its short-cutting. :) Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
