[systemd-devel] journald does not support syslog?
Hello all! As per the systemd-journald man page, It creates and maintains structured, indexed journals based on logging information that is received from a variety of sources: Simple system log messages, via the libc syslog(3) call Unfortunately I did not find any configuration parameter to make systemd-journald listen on a unix/network socket for syslog messages, making me high suspicious of this claim. So final question is -- How do you make journald listen for syslog messages via syslog protocol? ___ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journald does not support syslog?
On 09/06/2015 06:00 PM, Michael Chapman wrote: On Sun, 6 Sep 2015, dE wrote: Hello all! As per the systemd-journald man page, It creates and maintains structured, indexed journals based on logging information that is received from a variety of sources: Simple system log messages, via the libc syslog(3) call Unfortunately I did not find any configuration parameter to make systemd-journald listen on a unix/network socket for syslog messages, making me high suspicious of this claim. So final question is -- How do you make journald listen for syslog messages via syslog protocol? See the systemd-journal-dev-log.socket unit on your system (it's mentioned in that manpage). This socket is passed to journald when it's started. The socket unit should be enabled and acive on any standard systemd installation. - Michael Yes, I got that socket (/run/systemd/journal/dev-log). However /dev/log is not present (it's not made by default) and ss -xnlp does not list /run/systemd/journal/dev-log or it's corresponding inode as being listened by any program. Anyway, thanks for helping out. I've made the /dev/log symlink and now it works. ___ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journald does not support syslog?
On 09/06/2015 07:05 PM, Lennart Poettering wrote: On Sun, 06.09.15 18:20, dE ([email protected]) wrote: On 09/06/2015 06:00 PM, Michael Chapman wrote: On Sun, 6 Sep 2015, dE wrote: Hello all! As per the systemd-journald man page, It creates and maintains structured, indexed journals based on logging information that is received from a variety of sources: Simple system log messages, via the libc syslog(3) call Unfortunately I did not find any configuration parameter to make systemd-journald listen on a unix/network socket for syslog messages, making me high suspicious of this claim. So final question is -- How do you make journald listen for syslog messages via syslog protocol? See the systemd-journal-dev-log.socket unit on your system (it's mentioned in that manpage). This socket is passed to journald when it's started. The socket unit should be enabled and acive on any standard systemd installation. - Michael Yes, I got that socket (/run/systemd/journal/dev-log). However /dev/log is not present (it's not made by default) and ss -xnlp does not list /run/systemd/journal/dev-log or it's corresponding inode as being listened by any program. Anyway, thanks for helping out. I've made the /dev/log symlink and now it works. If the symlink is missing then something on your system must be actively deleting it. systemd-journald-dev-log.socket contains Symlinks=/dev/log to ensure the symlink is created as ĺong as the socket for it is up. Lennart Yeah, that's the problem. That's why I said /dev/log is not present. For the record I'm using Gentoo. So maybe some build time FEATURE is missing. ___ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] List of unit states.
Hi. I dont have a better term. When you look at the status of a unit or check the output of list-units, there's a 'load/loaded' column/field also there's an active field/column. What do these mean? I suspect load/loaded states weather they've been enabled at startup and active should show if they're running or not. Is there any documentation that explains these and it's all possible values? Also what's the SUB field about in list-units? ___ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] List of unit states.
On 01/06/15 11:58, Andrei Borzenkov wrote: В Tue, 06 Jan 2015 10:52:17 +0530 dE пишет: Hi. I dont have a better term. When you look at the status of a unit or check the output of list-units, there's a 'load/loaded' column/field also there's an active field/column. What do these mean? I suspect load/loaded states weather they've been enabled at startup and active should show if they're running or not. LOAD tells whether unit definition was seen. Units can be incomplete when they are referred to by other units. E.g. After=foo.service when foo.service itself does not exist. In this case systemd creates stub for foo.service and its LOAD state would be not-found. ACTIVE tells current running state - whether it is stopped, started, failed etc. SUB is unit-type specific qualifier (or explanation) of active state which hopefully makes it more clear what "active" means (mounted, running etc). I do not think there is exhaustive list somewhere beyond sources. Ok, thanks for the info. ___ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] unit's configuration directory
Hi! I was reading systemd.unit man which states -- |/etc/systemd/system As a directory for unit configuration, or something similar to conf.d But in Fedora, this directory just contains symlinks to other units (.service and .target) and empty directories -- . default.target multi-user.target.wants syslog.service .. default.target.wants printer.target.wants system-update.target.wants bluetooth.target.wants display-manager.service sockets.target.wants dbus-org.bluez.service getty.target.wants spice-vdagentd.target.wants dbus-org.freedesktop.Avahi.service graphical.target.wants sysinit.target.wants Making me suspicious of this directory. So where can I get documentation of unit configuration? | ___ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Add unit to arbitrary target.
On enabling a unit, by default systemd will put it in a target which has been specified in by the unit itself. Is there any way by which I can make the unit start in any custom target? Manual linking or using systemctl? ___ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Add unit to arbitrary target.
On 01/29/14 16:51, Lennart Poettering wrote: On Wed, 29.01.14 10:53, dE ([email protected]) wrote: On enabling a unit, by default systemd will put it in a target which has been specified in by the unit itself. Is there any way by which I can make the unit start in any custom target? Manual linking or using systemctl? Manual linking is the only way to do this for now. There has been a TODO list item though to maybe introduce "add-wants" though, to implement something more high-level for this... Lennart Thanks everyone for the reply! ___ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] issues with [email protected] after in 251-rc3
I'd also recommend opening an issue on the upstream issue tracker (https://github.com/systemd/systemd/issues). It'd be great if you could include a full journal (just zip up /var/log/journal) and the contents of [email protected] if possible to help with debugging. Cheers, Daan On Thu, 19 May 2022 at 08:05, Paul Menzel wrote: > > Dear Dusty, > > > Am 19.05.22 um 05:32 schrieb Dusty Mabe: > > I'm requesting help to try to find a problematic commit between > > v251-rc2..v251-rc3. > > > > We have a test in Fedora CoreOS [1] that tests luks and this test > > started failing in our rawhide stream with the introduction of > > 251-rc3. Reverting back to 251-rc2 makes the failing test go away. I > > briefly looked at the commits from v251-rc2..v251-rc3 but nothing > > jumped out at me. > > > > Any commits in there that we think might be risky or ones we should > > look at closer? > > Please bisect. It’s the most efficient way, and you can do it yourself, > especially as you have a test to reproduce the issue. > > > Here's the original bug [2] I opened against Fedora CoreOS: > > > Kind regards, > > Paul > > > > [1] > > https://github.com/coreos/fedora-coreos-config/tree/testing-devel/tests/kola/root-reprovision/luks > > [2] https://github.com/coreos/fedora-coreos-tracker/issues/1200
Re: [systemd-devel] hwdb: inconsistency in 60-sensor.hwdb accel_mount_matrix
Hi,
On 6/27/22 21:50, Gwendal Grignou wrote:
> In 60-sensor.hwdb, we can specify a matrix to rotate sensor output to
> match the expected 'natural' orientation [1].
>
> When behind a screen, accelerometers are usually soldered upside down,
> so a rotation matrix is needed to rotate their raw output into the
> 'natural' orientation when read directly.
>
> When flat on a table, standalone accelerometers/IMUs report the force
> exercised by the table to prevent the sensor from falling down
> further. In the 'natural' orientation, this is [0, 0, 1g]. See for
> instance the BMI160 specification[2], page 107).
>
> However, Gnome expects the sensor to return the gravity force itself,
> as specified by windows and the HID specification: When flat on a
> table, the expected value is [0, 0 , -1g].
>
> Therefore, the matrix, in addition to rotating the sensors, should
> also invert the axes.
That depends on the handedness of the sensor itself though, if the
sensor already is using Windows style handedness then the matrix
would be a pure rotation matrix and different sensors may have
a different handedness at the raw hardware level.
Also currently userspace is not really using the Z-axis.
Most quirks are user-submitted based on fixing auto-rotation which
only uses the X and Y axis, so the Z-axis sign might very well be
wrong in some cases.
> When a matrix inverts the axes, its determinant is -1 [3].
> Out of the 160 matrices defined, 136 invert the axes, 29 does not and
> one as a determinant equals to 0.
>
> That matrix, for Hometech device is obviously not correct: the sensor
> input vector X component is is used for both Y and Z axes of the
> output vector:
>
> #
> # Hometech
>
>
> # Nobody bothered to use Linux on any device of this manufacturer
> # so current marks might be too general and need fixes.
> # These values are based on Wi101 model.
> sensor:modalias:acpi:BMA250E*:dmi:*:svnInsyde*:pni101c:*
> ACCEL_MOUNT_MATRIX=0,1,0;-1,0,0;-1,0,0
Yes that is obviously wrong, as said above current userspace
doesn't really use the Z-axis much, which is why this is still
working fine.
>
> Remains 29 matrices where axes are not inverted:
> 9 (':acpi:BOSC0200*', 1.0)
> 3 (':acpi:INVN6500*', 1.0)
> 2 (':acpi:KIOX010A*', 1.0)
> 2 (':acpi:KIOX020A*', 1.0)
> 1 (':acpi:KIOX0009*', 1.0)
> 1 (':acpi:SMO8500:*', 1.0)
> 1 (':acpi:MXC6655*', 1.0)
> 1 (':acpi:ACCE0001*', 1.0)
> 1 (':acpi:KIOX000A*', 1.0)
> 1 (':i2c:bmc150_accel', 1.0)
> 1 (':acpi:NCPE0388*', 1.0)
> 1 (':acpi:SMO8500*', 1.0)
>
> Interestingly, some matrices for the same sensors are inverting axes:
> KIOX000A* sensors axes are inverted 36 times.
>
> The reason is the expectation that in convertible devices the
> accelerometers return the same data after rotation when the lid angle
> is 0:
I don't think so the KIOX000A sensor hw-id is not used in
devices with 2 sensors, those use KIOX001A and KIOX002A as
hw-ids for the 2 sensors IIRC.
> # A note about setting ACCEL_MOUNT_MATRIX for ACCEL_LOCATION=base sensors,
> # [...] This means that the
> # base-accelerometer's mount-matrix must be such, that after applying
> # the mount-matrices to both sensors, the base-accelerometer's readings must
> # be identical to the display-accelerometer's readings (when the lid is
> # closed).
>
> It means that one of 2 accelerometers is expected to not return data
> in the 'normal' orientation.
*No*, both sensors are expected to return data, but when the lid is closed
(or the display fully folded against the back of the keyboard) then the
readings of the 2 sensors are expected to be the same, IOW substracting
the 2 vectors given by the 2 sensors is expected to result in a 0, 0, 0
vector, or something close to it.
> W3C device orientation specs [4] implies the sensors use the same
> device coordinate frame, and therefore should return the same data
> when the lid angle is 180 degree.
W3C is for browsers Linux is an OS *not* a browser! So W3C has *zero*
relevance for Linux/systemd.
We don't care about W3C. What we do instead is try to do is follow what
the factory installed OS on the same hw is doing, so that we can re-use
the existing firmware provided info for the factory installed OS.
Specifically the reason why the base mount-matrix is defined in hwdb
as it is is because that is how the base mount-matrix looks like in
ACPI on x86 Windows devices which use 2 accel sensors and which
have their mount-matrices available in ACPI.
Also note that all the mount-matrices available in ACPI (which Linux
supports and adds as a kernel provided mount-matrix) are using the
Windows/HID handedness!
I must say that I'm getting very tired of this whole discussion,
please just accept that the Linux/systemd mount-matrices do not
follow the W3C axis definitions and adjust the read data accordingly
inside chrome-the-browser and/or inside the android-sensor-hal.
What is next? Complaining that USB-devic
[systemd-devel] DMI modalias based module autoloading broken (6.0.0-rc? - systemd 251.4) ?
Hi All, I'm sending this to both systemd-devel and lkml since I'm not sure what is causing this. For some reason the msi-laptop module is not autoloading on a MSI S270 (yes that is a very old laptop). Here is some debugging info: $ cat /sys/class/dmi/id/modalias dmi:bvnAmericanMegatrendsInc.:bvrA1013AMSV4.30:bd01/09/2006:svnMICRO-STARINT'LCO.,LTD:pnMS-1013:pvr0131:cvnMICRO-STARINT'LCO.,LTD:ct10:cvrN/A: $ cat /sys/class/dmi/id/uevent MODALIAS=dmi:bvnAmericanMegatrendsInc.:bvrA1013AMSV4.30:bd01/09/2006:svnMICRO-STARINT'LCO.,LTD:pnMS-1013:pvr0131:cvnMICRO-STARINT'LCO.,LTD:ct10:cvrN/A: $ modinfo msi-laptop | grep MS-1013 alias: dmi*:svn*MICRO-STARINT'LCO.,LTD*:pn*MS-1013*:pvr*0131*:cvn*MICRO-STARINT'LCO.,LTD*: And this does work to load the module: $ sudo modprobe `cat /sys/class/dmi/id/modalias` Things already tried: - checked for relevant selinux denial messages, none found - checked for modprobe[.d] conf files blacklisting msi-laptop, none found which is unsurprising since this is a clean Fedora 37 install I am more then happy to test any patches or do more debugging to help solve this. Regards, Hans
Re: [systemd-devel] mkosi dnf install packages failed
See the hacking guide, we depend on very latest mkosi from git. On Fri, 17 Mar 2023, 22:55 William Roberts, wrote: > I am on Fedora 37, I did a dnf up and rebooted to make sure that's not > the issue. > > With the mkosi from the pkg manager, I am getting: > mkosi > mkosi: error: unrecognized arguments: > --kernel-command-line-extra=systemd.crash_shell > systemd.log_level=debug > udev.log_level=info > systemd.journald.forward_to_console > systemd.journald.max_level_console=warning > systemd.mask=auditd > > Which reports as mkosi version 14 > mkosi --version > mkosi 14 > > I grabbed the current main and installed it > python3 -m pip install --user git+https://github.com/systemd/mkosi.git > > And when I run the mkosi command, I ensure its picking up the right one: > sudo -E $(which mkosi) > > And it seems to be building along, but then it gets to a point where > the packages are > being verified with dnf (see below). I am not really sure how to proceed. > > Thanks for any help. > Bill > > > xfsprogs-6.1.0-1.fc37.x86_64 > xkeyboard-config-2.36-3.fc37.noarch > xxhash-libs-0.8.1-3.fc37.x86_64 > xz-5.4.1-1.fc37.x86_64 > xz-libs-5.4.1-1.fc37.x86_64 > zchunk-libs-1.3.0-1.fc37.x86_64 > zlib-1.2.12-5.fc37.x86_64 > zsh-5.9-2.fc37.x86_64 > Failed: > NetworkManager-1:1.40.10-1.fc37.x86_64 > ca-certificates-2023.2.60-1.0.fc37.noarch dbus-broker-33-1.fc37.x86_64 > dhcp-server-12:4.4.3-4.P1.fc37.x86_64 dnsmasq-2.89-1.fc37.x86_64 > gdb-13.1-1.fc37.x86_64 groff-base-1.22.4-10.fc37.x86_64 > kexec-tools-2.0.25-1.fc37.x86_64 > libutempter-1.2.1-7.fc37.x86_64 polkit-121-4.fc37.x86_64 > rpm-4.18.0-1.fc37.x86_64 tpm2-tss-3.2.2-1.fc37.x86_64 > > Error: Transaction failed > ‣ Error: "dnf -y > --config=/home/test/systemd2/.mkosi.tmp5lla7668/dnf.conf --best > --allowerasing --releasever=37 > --installroot=/home/test/systemd2/.mkosi.tmp5lla7668/root > --setopt=keepcache=1 --setopt=install_weak_deps=0 > '--setopt=cachedir=/home/test/systemd2/mkosi.cache/fedora~37' > --setopt=reposdir= > --setopt=varsdir=/home/test/systemd2/.mkosi.tmp5lla7668/vars > --noplugins --nodocs install acl alsa-lib bash-completion btrfs-progs > compsize coreutils cryptsetup dhcp-server diffutils dnf dnsmasq > dosfstools dracut dracut-config-generic e2fsprogs f2fs-tools findutils > fuse gcc gdb glib2 glibc-minimal-langpack gnutls grep iproute > iproute-tc kbd kernel-core kernel-modules kexec-tools kmod less > libasan libbpf libcap-ng libcap-ng-utils libfido2 libgcrypt > libmicrohttpd libmnl libubsan libxcrypt libxkbcommon mtools nano > netcat nftables numactl-libs openssl pam passwd polkit popt procps-ng > python3 'python3dist(pefile)' qrencode quota rpm sed strace systemd > tpm2-tss tree util-linux util-linux valgrind vim-common > wireguard-tools xfsprogs zsh '(systemd-networkd if systemd)' > '(systemd-udev if systemd)'" returned non-zero exit code 1. >
Re: [systemd-devel] systemd enables custom service units on firstboot
Systemd does a preset on first boot when there's no machine ID yet. If no
preset from a preset file applies, the default is to enable it. Since
debian does not ship a 99-disable.preset with disable * in it, all services
are enabled on firstboot on Debian.
Cheers,
Daan
On Sat, 29 Apr 2023, 17:27 Martin Petzold, wrote:
> Dear Paul,
>
> Am 29.04.23 um 17:13 schrieb Paul Menzel:
> > Dear Martin,
> >
> >
> > Am 29.04.23 um 16:12 schrieb Martin Petzold:
> >
> >> we are building our OS with debootstrap (Debian bullseye). Our image
> >> shall be flashed on embedded devices. In order to get a unique
> >> machine-id we removed '/etc/machine-id' as instructed in [1] and also
> >> removed '/var/lib/dbus/machine-id' as instructed in [2]) from the
> >> golden image.
> >>
> >> After we flash the image and boot it, new machine-ids are created and
> >> identical.
> >>
> >> However, now we realized that some of our systemd service units added
> >> to '/lib/systemd/system' are enabled and starting on boot. We did not
> >> enable them, we just copied them to that location at the end of our
> >> rootfs build. They are just there to be used in some special test cases.
> >>
> >> We already checked '/lib/systemd/system-preset/*'. But there is only
> >> a single file '90-systemd.preset' and there is no rule which matches
> >> our service units.
> >>
> >> 1. Why are our service units placed in '/lib/systemd/system' enabled?
> > Sorry, you provide not enough information.
> >
> > Please provide an example `systemctl status X` and `systemctl cat X`
> > for service X, that is started but does not. Does that happen with all
> > services you add?
> =
>
> tavla@tavla:~$ sudo systemctl status tavla-test
>
> × tavla-test.service - TAVLA Platform OS Tester Service
> Loaded: loaded (/lib/systemd/system/tavla-test.service; enabled;
> preset: enabled)
> Active: failed (Result: signal) since Sat 2023-04-29 15:52:12
> CEST; 17min ago
> Process: 388 ExecStart=/opt/tavla/bin/test (code=killed, signal=HUP)
> Main PID: 388 (code=killed, signal=HUP)
> CPU: 118ms
>
> Apr 29 15:52:12 tavla systemd[1]: Starting tavla-test.service - TAVLA
> Platform OS Tester Service...
> Apr 29 15:52:12 tavla systemd[1]: tavla-test.service: Main process
> exited, code=killed, status=1/HUP
> Apr 29 15:52:12 tavla systemd[1]: tavla-test.service: Failed with result
> 'signal'.
> Apr 29 15:52:12 tavla systemd[1]: Failed to start tavla-test.service -
> TAVLA Platform OS Tester Service.
>
> =
>
> tavla-test.service is 'enabled' (and started), but I never enabled it.
> It was enabled after I removed machine-id and did a reboot. Before that,
> it was disabled. The service unit
> ('/lib/systemd/system/tavla-test.service') was copied to this location
> during image build after debootstrap and apt installation of systemd.
>
> Here is the only preset ('90-systemd.preset'):
>
> =
>
> enable remote-fs.target
> enable remote-cryptsetup.target
> enable machines.target
>
> enable [email protected]
> enable systemd-timesyncd.service
> enable systemd-networkd.service
> enable systemd-network-generator.service
> enable systemd-resolved.service
> enable systemd-homed.service
> enable systemd-userdbd.socket
> enable systemd-pstore.service
> enable systemd-boot-update.service
>
> disable console-getty.service
> disable debug-shell.service
>
> disable halt.target
> disable kexec.target
> disable poweroff.target
> enable reboot.target
> disable rescue.target
> disable exit.target
>
> disable systemd-networkd-wait-online.service
> disable systemd-time-wait-sync.service
> disable systemd-boot-check-no-failures.service
> disable proc-sys-fs-binfmt_misc.mount
>
> disable syslog.socket
>
> disable systemd-journal-gatewayd.*
> disable systemd-journal-remote.*
> disable systemd-journal-upload.*
>
> =
>
> >
> >> Platform:
> >>
> >> systemd 252.5-2~bpo11+1 (from bullseye-backports)
> >> systemd-resolved and systemd-networkd with iwd (all from
> >> bullseye-backports)
> >> Custom Debian bullseye (with some packages from bullseye-backports)
> >> Custom Kernel 5.10
> >> U-Boot
> >>
> >> [1] https://systemd.io/BUILDING_IMAGES/
> >> [2] https://wiki.debian.org/MachineId
>
> Best regards,
>
> Martin
>
>
Re: [systemd-devel] systemd enables custom service units on firstboot
Disabling manually will still get overridden by preset on first boot.
Debian does not ship 99-disable.preset because deb-systemd-helper relies on
systemctl preset to enable services on install. Shipping that file would
break backwards compat because no services would be enabled anymore.
If I were you I would ship 99-disable.preset and add 85-mydevice.preset
enabling only the services you want to be enabled.
Cheers,
Daan
On Sat, 29 Apr 2023, 17:47 Martin Petzold, wrote:
> Dear Daan,
> Am 29.04.23 um 17:43 schrieb Daan De Meyer:
>
> Systemd does a preset on first boot when there's no machine ID yet. If no
> preset from a preset file applies, the default is to enable it. Since
> debian does not ship a 99-disable.preset with disable * in it, all services
> are enabled on firstboot on Debian.
>
> What would you then suggest:
>
> a. Disable every single service unit after copy to the /lib/systemd/system
> location manually?
> b. Add a 99-disable.preset file with 'disable *'? (I wonder why Debian
> does not have it and if it then may brake something)
>
> Thanks,
>
> Martin
>
>
> On Sat, 29 Apr 2023, 17:27 Martin Petzold,
> wrote:
>
>> Dear Paul,
>>
>> Am 29.04.23 um 17:13 schrieb Paul Menzel:
>> > Dear Martin,
>> >
>> >
>> > Am 29.04.23 um 16:12 schrieb Martin Petzold:
>> >
>> >> we are building our OS with debootstrap (Debian bullseye). Our image
>> >> shall be flashed on embedded devices. In order to get a unique
>> >> machine-id we removed '/etc/machine-id' as instructed in [1] and also
>> >> removed '/var/lib/dbus/machine-id' as instructed in [2]) from the
>> >> golden image.
>> >>
>> >> After we flash the image and boot it, new machine-ids are created and
>> >> identical.
>> >>
>> >> However, now we realized that some of our systemd service units added
>> >> to '/lib/systemd/system' are enabled and starting on boot. We did not
>> >> enable them, we just copied them to that location at the end of our
>> >> rootfs build. They are just there to be used in some special test
>> cases.
>> >>
>> >> We already checked '/lib/systemd/system-preset/*'. But there is only
>> >> a single file '90-systemd.preset' and there is no rule which matches
>> >> our service units.
>> >>
>> >> 1. Why are our service units placed in '/lib/systemd/system' enabled?
>> > Sorry, you provide not enough information.
>> >
>> > Please provide an example `systemctl status X` and `systemctl cat X`
>> > for service X, that is started but does not. Does that happen with all
>> > services you add?
>> =
>>
>> tavla@tavla:~$ sudo systemctl status tavla-test
>>
>> × tavla-test.service - TAVLA Platform OS Tester Service
>> Loaded: loaded (/lib/systemd/system/tavla-test.service; enabled;
>> preset: enabled)
>> Active: failed (Result: signal) since Sat 2023-04-29 15:52:12
>> CEST; 17min ago
>> Process: 388 ExecStart=/opt/tavla/bin/test (code=killed, signal=HUP)
>> Main PID: 388 (code=killed, signal=HUP)
>> CPU: 118ms
>>
>> Apr 29 15:52:12 tavla systemd[1]: Starting tavla-test.service - TAVLA
>> Platform OS Tester Service...
>> Apr 29 15:52:12 tavla systemd[1]: tavla-test.service: Main process
>> exited, code=killed, status=1/HUP
>> Apr 29 15:52:12 tavla systemd[1]: tavla-test.service: Failed with result
>> 'signal'.
>> Apr 29 15:52:12 tavla systemd[1]: Failed to start tavla-test.service -
>> TAVLA Platform OS Tester Service.
>>
>> =
>>
>> tavla-test.service is 'enabled' (and started), but I never enabled it.
>> It was enabled after I removed machine-id and did a reboot. Before that,
>> it was disabled. The service unit
>> ('/lib/systemd/system/tavla-test.service') was copied to this location
>> during image build after debootstrap and apt installation of systemd.
>>
>> Here is the only preset ('90-systemd.preset'):
>>
>> =
>>
>> enable remote-fs.target
>> enable remote-cryptsetup.target
>> enable machines.target
>>
>> enable [email protected]
>> enable systemd-timesyncd.service
>> enable systemd-networkd.service
>> enable systemd-network-generator.service
>> enable systemd-resolved.service
>> enable systemd-homed.service
&g
Re: [systemd-devel] USB installer for mkosi
Unfortunately there's no ready made answer yet here. We're busy designing and implementing a solution for these problems. https://github.com/systemd/systemd/pull/27792 has more details. Cheers, Daan On Fri, 18 Aug 2023, 19:44 Nils Kattenbeck, wrote: > Hi, > > currently I am building a minimalistic Linux image using mkosi which > should be installed on bare-metal hardware. > For the installation I am trying to create a USB-stick installer which > simply installs the resulting image on the hardware. > > First and foremost: > Does someone maybe know of an existing tool which generates such a USB > installer? > For now I have found the installer script[1] from Yocto, and FAI > (Fully automatic installation)[2]. > I would like to avoid using Yocto and the script seems to also perform > partitioning etc. which I do not need as mkosi already generates a > ready-to-use raw disk image with partitions set up. > FAI on the other hand seems to focus on network installs and prefers > to build its own images instead of using an arbitrary .raw/ISOs. > > So I fear that I will have to write my own installer... > I do not require fancy GUI shenanigans; a simple CLI application > prompting for the destination disk should suffice. > > Based on my understanding the primary steps are `cp /dev/usb-stick > /dev/target-disk` (or dd for the old fashioned), followed by a `parted > --script --fix /dev/target-disk print` to resolve GPT warnings due to > the header not being at the end when the disk is larger than the USB > stick. > Is it possible to replace the second step with `systemd-parted`. > Especially given that mkosi v15 now uses it for itself, this would > likely be a lot cleaner than invoking parted. > > The major problem I am facing with that approach is how do I know > whether I am booting from a USB stick or already from the final disk > drive. > One technique which comes to mind would be to create two images, one > of which will be placed into the mkosi.extra/ directory of the other. > This way I could have one auto-start the install script whereas the > other image would be completely free of that logic. > Am I missing a more obvious way to perform this? > > Any help would be greatly appreciated! > Kind regard, Nils > > [1] > https://github.com/yoctoproject/poky/blob/13734bb520732882a95da7ee6efe1e5b98568acc/meta/recipes-core/initrdscripts/initramfs-module-install-efi_1.0.bb > [2] https://fai-project.org/ >
Re: [systemd-devel] How to debug systemd-pcrphase-initrd.service failure
Note that we also have `InitrdPackages=` in the latest mkosi release which allows you to add extra packages to the default initrd without having to build one separately. Cheers, Daan On Wed, 6 Dec 2023 at 14:26, Renjaya Raga Zenta wrote: > > Yes, I think now I understand that mkosi will build default initrd image > without tpm2-tss libraries. Perhaps because the package names are different > for each distro. > > I need to build the initrd image separately at first, then use it to build OS > image with --initrd flag. > > Thanks. > > On Wed, Dec 6, 2023 at 8:02 PM Lennart Poettering > wrote: >> >> On Mi, 06.12.23 18:28, Renjaya Raga Zenta ([email protected]) wrote: >> >> > Hi, >> > >> > I am exploring OS image building with mkosi. It works great until I add TPM >> > 2.0 in qemu. >> > >> > I found that the systemd-pcrphase-initrd.service failed. There are 3 >> > pcrphase service: >> > >> > 1. systemd-pcrphase-initrd.service (failed) >> > 2. systemd-pcrphase.service (ok) >> > 3. systemd-pcrphase-sysinit.service (ok) >> >> So the latter two run from the host fs, the first one from the initrd fs. >> >> > Related journal log: >> > systemd[1]: Failed to start systemd-pcrphase-initrd.service - TPM2 PCR >> > Barrier (initrd). >> > ... >> > systemd-pcrphase[130]: Failed to load TPM2 libraries: Operation not >> > supported >> > ... >> >> It appears you are lacking the tpm2-tss libraries in your initrd image. >> >> Lennart >> >> -- >> Lennart Poettering, Berlin > > > > -- > Renjaya Raga Zenta > Mobile: > +62 811 572 4400
Re: [RFC] initoverlayfs - a scalable initial filesystem
> We have been working on a new initial filesystem called initoverlayfs. > It is a new filesystem that provides a more scalable approach to > initial filesystems as opposed to just using initrds. We are writing > this RFC to the systemd and dracut mailing lists (feel free to forward > to UAPI group also) because although this solution works without > changing the code in these projects, it operates in the same area as > systemd, udev, dracut, etc. and uses these tools. I like the concept of using erofs instead of a compressed cpio and we have been discussing doing something similar within systemd. I very much dislike the implementation though. I believe this should be implemented natively within the Linux kernel instead of hacking around the missing kernel support in userspace. If the kernel would add support for supplying an erofs initramfs instead of a cpio initramfs, put a writable tmpfs on top of it and would unpack any extra cpios provided by the bootloader on top of the tmpfs, then there wouldn't be any need for initoverlayfs. Before adopting anything like this I believe there should be a serious effort to get this implemented within Linux itself. Only if that turns out to be impossible should we fall back to exploring userspace only solutions. Cheers, Daan On Sat, 9 Dec 2023 at 16:08, Eric Curtin wrote: > > On Sat, 9 Dec 2023 at 14:56, Andrei Borzenkov wrote: > > > > On 09.12.2023 17:42, Eric Curtin wrote: > > > On Sat, 9 Dec 2023 at 12:46, Luca Boccassi wrote: > > >> > > >> On Fri, 8 Dec 2023 at 19:00, Eric Curtin wrote: > > >>> > > >>> We have been working on a new initial filesystem called initoverlayfs. > > >>> It is a new filesystem that provides a more scalable approach to > > >>> initial filesystems as opposed to just using initrds. We are writing > > >>> this RFC to the systemd and dracut mailing lists (feel free to forward > > >>> to UAPI group also) because although this solution works without > > >>> changing the code in these projects, it operates in the same area as > > >>> systemd, udev, dracut, etc. and uses these tools. > > >> > > >> It seems to me everything you described already exists? If you want to > > >> avoid having an initrd -> rootfs transition, you can already do that - > > > > > > You need a initrd -> rootfs transition for generic linux operating > > > systems right? > > > > No, you do not. Nothing stops you from running off initramfs (today you > > do not really have init*RAM Disk* - the content of initrd is unpacked > > into initramfs. > > Apologies if I am misinterpreting this response, I use terms initrd > and initramfs > interchangeably (not technically correct, but it's common to do this). The > point is to avoid unpacking as much as possible, because in many initrds > the majority of the software need not be unpacked, but is designed to work > with throwaway initial filesystems. > > > > > > Or else you start building all sorts of things directly > > > into the kernel which isn't really scalable. > > > > > > > See above. > > >
Re: [systemd-devel] mkosi config to build minimal Ubuntu 22.04 VM image?
Hi Paul, Please see the config included in the mkosi repository itself: https://github.com/systemd/mkosi/blob/main/mkosi.conf and https://github.com/systemd/mkosi/tree/main/mkosi.conf.d. This should help you get started. https://mkosi.systemd.io/bootable.html shows how to build a minimal bootable image for different distributions. mkosi doesn't concern itself with which packages are installed in the image. Please refer to your distribution of choice for that. Cheers, Daan On Thu, 29 Feb 2024 at 23:36, Paul Menzel wrote: > > Dear systemd and mkosi folks, > > > I would like to create a minimal Ubuntu 22.04 (Jammy) virtual machine > image for QEMU/KVM with VirtIO. Inside the VM only systemd, sshd, a > shell and curl or Wget should be installed. (From this base, one goal is > then to install BigBlueButton for example.) I found one blog post from > 2020 [1], but mkosi changed a lot since then. > > > Thank you in advance and kind regards, > > Paul > > > [1]: https://krystof.litomisky.com/2020/09/08/mkosi-for-ubuntu/
Re: [systemd-devel] enable systemd-resolved in early boot (dracut)
Hi Aleksandar, > I want to enable systemd-resolved in early boot so that `clevis` can > resolve `tang` address by mdns. This will simplify local network > configuration by not relying on static IP addresses. > But it seems that is not enabled by default. > Is there a way to tell dracut to also include and start > `systemd-resolved` as part of early boot network start? This is something to ask on the dracut mailing list or whatever their equivalent is. Cheers, Daan On Tue, 19 Mar 2024 at 11:44, Aleksandar Kostadinov wrote: > > Hello, > > I want to enable systemd-resolved in early boot so that `clevis` can > resolve `tang` address by mdns. This will simplify local network > configuration by not relying on static IP addresses. > > But it seems that is not enabled by default. > > Is there a way to tell dracut to also include and start > `systemd-resolved` as part of early boot network start? > > Thank you. >
Re: [systemd-devel] repart: How to use CopyBocks= with usr-verity?
Hi Nils, Pretty sure nobody ever tried this. The root hash might be changing because we format the verity hash partition with different parameters than it was originally formatted with in your case. I assume the roothash will only stay the same if the verity format arguments are exactly the same. We'd probably accept PRs to allow configuring more verity arguments to support this use case. Cheers, Daan On Fri, 29 Mar 2024 at 19:55, Nils Kattenbeck wrote: > > Hello everyone, > > I am having trouble with getting CopyBlocks= to work with a verify enabled > usr partition. The documentations says that it should automatically work > automatically but it does not describe which properties have to be set for > which partition, i.e. repart.d file. > So far I have tried several variations of Verity=/VerityMatchKey=, settings > it only on one partition, both etc., setting CopyBlocks= on only usr or usr > and usr-verity. Setting CopyBlocks= on both does not work and systemd-repart > fails with the message that it was unable to find the correct partition for > usr-verity. The other approach was setting CopyBlocks= only on the usr > partition but regardless of what I try with Verity= the root hash changes > (and thus also the partition UUIDs). Or more specifically the usr partition > retains the correct/original PARTUUID whereas the PARTUUID of the usr-verity > partition changes. > > Maybe someone has an idea what might cause this or better yet already has a > similar working solution which they could share. > > Kind regards, > Nils >
Re: [systemd-devel] mkosi config to build minimal Ubuntu 22.04 VM image?
Hi Paul, Ubuntu 22.04 is too old to run mkosi on. Your best bet is to use the tools tree functionality. By adding ToolsTree=default and ToolsTreeDistribution=debian, mkosi will build a debian image and use that image to do the final build. That will help you get around the lack of bootctl on Ubuntu Jammy. Do note that mkosi is a fast moving project and you might be better off running a distribution such as Fedora or Arch Linux which will generally have more up to date tooling than the latest Ubuntu LTS release. Cheers, Daan On Wed, 3 Apr 2024 at 14:48, Paul Menzel wrote: > > Dear Daan, > > > Thank you very much for your reply. > > > Am 04.03.24 um 15:52 schrieb Daan De Meyer: > > > Please see the config included in the mkosi repository itself: > > https://github.com/systemd/mkosi/blob/main/mkosi.conf and > > https://github.com/systemd/mkosi/tree/main/mkosi.conf.d. This should > > help you get started. https://mkosi.systemd.io/bootable.html shows how > > to build a minimal bootable image for different distributions. mkosi > > doesn't concern itself with which packages are installed in the image. > > Please refer to your distribution of choice for that. > > Thank you for the pointers. I started to try it again, but Ubuntu 22.04 > (Jammy Jellyfish) does not have `bootctl`, that means *systemd-boot* is > not in the official package archive [1]. > > > Kind regards, > > Paul > > > [1]: https://packages.ubuntu.com/search?keywords=systemd-boot
[systemd-devel] How to suppress "A start job is running for offline-updates" knight-rider status output?
Hi All, As part of improving the boot experience: https://fedoraproject.org/wiki/Changes/FlickerFreeBoot https://hansdegoede.livejournal.com/20119.html I took a look at how applying offline updates looks when pressing ESC to get the detailed view, pk-offline-update then prints "dnf update" like output, but at the same time systemd is printing: [ ***] A start job is running for offline-updates Messages to the console, the 2 get intermixed and this looks quite bad and makes the status update of the actual update process almost impossible to follow. Is there something which I can put in the /lib/systemd/system/system-update.target.wants/packagekit-offline-update.service service file to suppress the knightrider status updates ? I've looked at: https://www.freedesktop.org/software/systemd/man/systemd.unit.html https://www.freedesktop.org/software/systemd/man/systemd.service.html But I could not find anything for this there. Regards, Hans ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to suppress "A start job is running for offline-updates" knight-rider status output?
Hi, On 27-02-19 12:50, Lennart Poettering wrote: On Mi, 27.02.19 10:40, Mantas Mikulėnas ([email protected]) wrote: On Tue, Feb 26, 2019 at 7:29 PM Hans de Goede wrote: Hi All, As part of improving the boot experience: https://fedoraproject.org/wiki/Changes/FlickerFreeBoot https://hansdegoede.livejournal.com/20119.html I took a look at how applying offline updates looks when pressing ESC to get the detailed view, pk-offline-update then prints "dnf update" like output, but at the same time systemd is printing: [ ***] A start job is running for offline-updates Messages to the console, the 2 get intermixed and this looks quite bad and makes the status update of the actual update process almost impossible to follow. Is there something which I can put in the /lib/systemd/system/system-update.target.wants/packagekit-offline-update.service service file to suppress the knightrider status updates ? I think the official name is "cylon eye status updates". Hmm, I *thought* it was possible to disable this by something like flock()'ing the console device, and systemd-fsck was supposed to do that in order to avoid the job status from mixing with the "fsck: x% complete" output. But it looks like that functionality was lost, or never present, and indeed even systemd-fsck's output is trashed by the "job is running" messages, from what I remember. There was a plan to use BSD locks for that. But that was only a plan. It's listed in the TODO list still though, but noone worked on that yet. Looking at source code (manager_get_show_status, unit_needs_console, exec_context_may_touch_console), the output should be disabled if at least one currently active unit has a tty as its stdin/stdout, and/or any of the tty_reset/tty_vhangup options enabled. So maybe StandardOutput=tty, TTYPath=/dev/console would achieve this? So, this should work, though is a bit ugly I'd say. My suggestion would be: the status msg indicates that start-up of the offline-updates service takes awfully long, i.e. that it apparently runs everything as Type=oneshot? I find that a curious choice: why that? Why not use Type=simple or Type=notify or so? i.e. why delay the boot transaction like this? If you don't then the status message wouldn't be shown. Thank you both for your input. https://www.freedesktop.org/software/systemd/man/systemd.offline-updates.html Says: "The upgrade scripts should exit only after the update is finished. It is expected that the service which performs the upgrade will cause the machine to reboot after it is done. If the system-update.target is successfully reached, i.e. all update services have run, and the /system-update symlink still exists, it will be removed and the machine rebooted as a safety measure." Which AFAIK means that if we make the service consider being "started" sooner then the system-update.target will be considered reached and the "the machine rebooted as a safety measure." So maybe using StandardOutput=tty + TTYPath=/dev/console is not such a bad idea in this case? Regards, Hans ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to suppress "A start job is running for offline-updates" knight-rider status output?
Hi, On 27-02-19 17:04, Lennart Poettering wrote: On Mi, 27.02.19 15:56, Hans de Goede ([email protected]) wrote: Hi, On 27-02-19 12:50, Lennart Poettering wrote: On Mi, 27.02.19 10:40, Mantas Mikulėnas ([email protected]) wrote: On Tue, Feb 26, 2019 at 7:29 PM Hans de Goede wrote: Hi All, As part of improving the boot experience: https://fedoraproject.org/wiki/Changes/FlickerFreeBoot https://hansdegoede.livejournal.com/20119.html I took a look at how applying offline updates looks when pressing ESC to get the detailed view, pk-offline-update then prints "dnf update" like output, but at the same time systemd is printing: [ ***] A start job is running for offline-updates Messages to the console, the 2 get intermixed and this looks quite bad and makes the status update of the actual update process almost impossible to follow. Is there something which I can put in the /lib/systemd/system/system-update.target.wants/packagekit-offline-update.service service file to suppress the knightrider status updates ? I think the official name is "cylon eye status updates". Hmm, I *thought* it was possible to disable this by something like flock()'ing the console device, and systemd-fsck was supposed to do that in order to avoid the job status from mixing with the "fsck: x% complete" output. But it looks like that functionality was lost, or never present, and indeed even systemd-fsck's output is trashed by the "job is running" messages, from what I remember. There was a plan to use BSD locks for that. But that was only a plan. It's listed in the TODO list still though, but noone worked on that yet. Looking at source code (manager_get_show_status, unit_needs_console, exec_context_may_touch_console), the output should be disabled if at least one currently active unit has a tty as its stdin/stdout, and/or any of the tty_reset/tty_vhangup options enabled. So maybe StandardOutput=tty, TTYPath=/dev/console would achieve this? So, this should work, though is a bit ugly I'd say. My suggestion would be: the status msg indicates that start-up of the offline-updates service takes awfully long, i.e. that it apparently runs everything as Type=oneshot? I find that a curious choice: why that? Why not use Type=simple or Type=notify or so? i.e. why delay the boot transaction like this? If you don't then the status message wouldn't be shown. Thank you both for your input. https://www.freedesktop.org/software/systemd/man/systemd.offline-updates.html Says: "The upgrade scripts should exit only after the update is finished. It is expected that the service which performs the upgrade will cause the machine to reboot after it is done. If the system-update.target is successfully reached, i.e. all update services have run, and the /system-update symlink still exists, it will be removed and the machine rebooted as a safety measure." Which AFAIK means that if we make the service consider being "started" sooner then the system-update.target will be considered reached and the "the machine rebooted as a safety measure." So maybe using StandardOutput=tty + TTYPath=/dev/console is not such a bad idea in this case? Another option is to do this in your soruces btw: ```c (void) kill(1, SIGRTMIN+21); ``` Sending SIGRTMIN+21 to PID 1 will disable the status output explicitly. If you are sure you don't want it you can just do that, in one line. Plymouth also sends that signal, hence make sure you don't run into races with that. That won't work, the primary use-case for the offline-updates status display is a user pressing ESC while plymouth is showing this: https://fedorapeople.org/~jwrdegoede/flickerfree-videos/installing.png So that the user can see details if he/she wants that. In this case plymouth will send SIGRTMIN+22 when switching back to text-mode to have systemd resume its status messages, so having pk-offline-update send SIGRTMIN+21 when it starts will not help. So shall I try using StandardOutput=tty + TTYPath=/dev/console and see if that works around this for now ? Regards, Hans ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to suppress "A start job is running for offline-updates" knight-rider status output?
Hi, On 28-02-19 10:27, Colin Guthrie wrote: Hans de Goede wrote on 27/02/2019 19:12: On 27-02-19 17:04, Lennart Poettering wrote: Another option is to do this in your soruces btw: ```c (void) kill(1, SIGRTMIN+21); ``` Sending SIGRTMIN+21 to PID 1 will disable the status output explicitly. If you are sure you don't want it you can just do that, in one line. Plymouth also sends that signal, hence make sure you don't run into races with that. That won't work, the primary use-case for the offline-updates status display is a user pressing ESC while plymouth is showing this: https://fedorapeople.org/~jwrdegoede/flickerfree-videos/installing.png So that the user can see details if he/she wants that. In this case plymouth will send SIGRTMIN+22 when switching back to text-mode to have systemd resume its status messages, so having pk-offline-update send SIGRTMIN+21 when it starts will not help. Could the plymouth theme somehow suppress the sending of SIGRTMIN+22? e.g. in the case of the offline updates it's presumably integrating with the pk-offline-update to get progress reports anyway, so it knows the context in which it's run. I could simply suppress the sending of SIGRTMIN+22 and leave just the pk-offline-update messages? Obviously would need a tweak to plymouth, but perhaps it's not too crazy? Just a thought. That only fixes the case when plymouth is running, but we really cannot assume that that is always the case. Regards, Hans ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] vconsole.conf, systemd-localed and the console keymap in the initrd
Hi All, When using full-disk encryption the console keymap is used in the initrd to enter the disk-crypt password. There are a couple of issues with this: 1) keymap changes do not become effective until a new kernel (which generated a new initrd which includes the updated vconsole.conf) gets installed: https://bugzilla.redhat.com/show_bug.cgi?id=1405539 Note this one is part of: https://fedoraproject.org/wiki/Fedora_Program_Management/Prioritized_bugs_and_issues We could have the tools re-generate the existing initrds when the keymap changes but that is not 100% bullet proof, if some bug has snuck in which causes new initrds to not boot, then we've just overwritten the older fallback initrds with ones which will also not boot... Also in the future we want to move to using a single generic pre-generated initrd everywhere and silverblue is already doing this, which brings me to 2: 2) When using a generic initrd which does not include /etc/vconsole.conf the keymap will also be "us" independent of what the system is configured to use. I believe that the best way to fix is this is probably to specify the keymap on the kernel commandline using vconsole.keymap= on the kernel commandline. So 2 questions: 1) What is your (systemd devs) take on this, does using vconsole.keymap= on the kernel commandline sound like the right solution, or do you have other suggestions? 2) I wonder what will happen when runtime changing the keymap when vconsole.keymap=foo is specified on the kernel commandline? systemd-vconsole-setup will use the values on the kernel commandline over those in /etc/vconsole.conf, and until we reboot those 2 will no longer be in sync. systemd-vconsole-setup runs when a new vtconsole gets added, but that should (normally) not happen after boot so that is not a problem. But I wonder how systemd-localed applies changes to the current vtconsole(s) does it do this itself, or does it use systemd-vconsole-setup for this ? I ask because if it uses systemd-vconsole-setup and that prefers the kernel commandline value then the change will not happen until reboot. Which I believe would be a regression compared to how things work now... Regards, Hans ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] vconsole.conf, systemd-localed and the console keymap in the initrd
Hi, On 30-07-19 10:49, Hans de Goede wrote: Hi All, When using full-disk encryption the console keymap is used in the initrd to enter the disk-crypt password. There are a couple of issues with this: 1) keymap changes do not become effective until a new kernel (which generated a new initrd which includes the updated vconsole.conf) gets installed: https://bugzilla.redhat.com/show_bug.cgi?id=1405539 Note this one is part of: https://fedoraproject.org/wiki/Fedora_Program_Management/Prioritized_bugs_and_issues We could have the tools re-generate the existing initrds when the keymap changes but that is not 100% bullet proof, if some bug has snuck in which causes new initrds to not boot, then we've just overwritten the older fallback initrds with ones which will also not boot... Also in the future we want to move to using a single generic pre-generated initrd everywhere and silverblue is already doing this, which brings me to 2: 2) When using a generic initrd which does not include /etc/vconsole.conf the keymap will also be "us" independent of what the system is configured to use. I forgot to put a link to the issue for this here, for those who are interested this is being tracked / discussed here: https://github.com/fedora-silverblue/issue-tracker/issues/3 Regards, Hans I believe that the best way to fix is this is probably to specify the keymap on the kernel commandline using vconsole.keymap= on the kernel commandline. So 2 questions: 1) What is your (systemd devs) take on this, does using vconsole.keymap= on the kernel commandline sound like the right solution, or do you have other suggestions? 2) I wonder what will happen when runtime changing the keymap when vconsole.keymap=foo is specified on the kernel commandline? systemd-vconsole-setup will use the values on the kernel commandline over those in /etc/vconsole.conf, and until we reboot those 2 will no longer be in sync. systemd-vconsole-setup runs when a new vtconsole gets added, but that should (normally) not happen after boot so that is not a problem. But I wonder how systemd-localed applies changes to the current vtconsole(s) does it do this itself, or does it use systemd-vconsole-setup for this ? I ask because if it uses systemd-vconsole-setup and that prefers the kernel commandline value then the change will not happen until reboot. Which I believe would be a regression compared to how things work now... Regards, Hans ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] vconsole.conf, systemd-localed and the console keymap in the initrd
Hi Lennart, On 31-07-19 14:07, Lennart Poettering wrote: On Di, 30.07.19 10:49, Hans de Goede ([email protected]) wrote: I believe that the best way to fix is this is probably to specify the keymap on the kernel commandline using vconsole.keymap= on the kernel commandline. As you found out, our current logic is to let kernel cmdline settings override everything else. To implement what you are looking for we probably should add a new setting vconsole.default_keymap= or so which can set the default which is used when there's no vconsole.conf or so defined. Hmm, that would fix the silverblue case, but not the regular Fedora case unless we patch dracut to omit vconsole.conf. I was thinking myself about maybe making systemd-vconsole-setup recognize rd.vconsole.keymap but only when it is running from the initrd (*). This is what dracut initrds use when not using systemd in the initrd, so it would add some backward compatibility to kernel commandlines which use those old options and it should nice solve the keymap in initrd issue. *) This requires systemd-vconsole-setup being able to reliable tell it is running from the initrd, I'm not 100% sure if that is possible. That said, I wonder if it wouldn't be easier to just define some basic EFI variables for this kind of super basic settings, and then read those. It appears to me that everything doing early boot stuff might want to do this, and it shouldn't require kernel cmdline patching. Of course, that would solve it for EFI only, but I fiugre that's like 99% of the machines you want to cover? Sorry, and EFI only solution is not going to cut it, there are still a lot of users out there using classic BIOS boot and we still support systems which only support BIOS boot (not to mention non x86 archs). Also AFAIK the Fedora bootloader people do not want to muck with EFI vars too much, because some implementations are buggy they "fragment" their internal storage when changing vars to a different size value and then do nasty stuff (crash) when they run out of storage instead of just returning an error. Note that on secureboot envs you cannot really change the kernel cmdline options though, can you? i mean if you could, then you could add any rubbish you'd like too, no? Actually the grubenv and grub.cfg are not protected in anyway ATM, which is an area where out secureboot story needs to improve. But since the kernel cmdline typically includes a root= argument which may well be a UUID or something else system specific, if we start signing these files we need a way to locally sign them and which point we can also update the keymap settings on the kernel cmdline. TL;DR: I believe that passing the keymap for the initrd on the kernel cmdline is the best option. 1) What is your (systemd devs) take on this, does using vconsole.keymap= on the kernel commandline sound like the right solution, or do you have other suggestions? My preference would be to go the EFI variable way, but the "vconsole.default_keymap=" thing works too I guess for the non-SecureBoot cases, if that's al you care about? See above for the secureboot part of your question. Yes vconsole.default_keymap= would work, but I would prefer rd.vconsole.keymap also for it being backward compat with older (pre systemd in initrd) initrds. 2) I wonder what will happen when runtime changing the keymap when vconsole.keymap=foo is specified on the kernel commandline? Nothing, they are ignored. is not a problem. But I wonder how systemd-localed applies changes to the current vtconsole(s) does it do this itself, or does it use systemd-vconsole-setup for this ? The latter, but that's an implementation detail I guess. I ask because if it uses systemd-vconsole-setup and that prefers the kernel commandline value then the change will not happen until reboot. Which I believe would be a regression compared to how things work now... Yupp, that would be. Ok, so we need to find a way around that :) Regards, Hans ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/fstab obsolete?
On 28-08-19 10:46, Reindl Harald wrote: Am 28.08.19 um 09:33 schrieb Ulrich Windl: systemd in SLES 12 is causing endless frustration here: a good start for a discussion as always :-) just the topic "/etc/fstab obsolete?" alone makes one puke given that /etc/fstab is mentioned dozens of times in the manuals and yes you get generated units for years now, but hey who needs to read any manual when he can also write useless posts with "causing endless frustration here" and "That is why I hate systemd" CTRL+F "fstab" here: https://www.freedesktop.org/software/systemd/man/systemd.mount.html Yesterday I was migrating some filesystems to a new device (multipath, MD-RAID, LVM, filesystem, mountpoints, etc.), updating /etc/fstab and other files as needed. After migration was successful, I also cleaned up the now obsolete resources (multipath, MD-RAID, filesystem, mountpoints, etc.) Everything looked OK... "looked ok" But some time later the application was stopped, as the new filesystems were unmounted by systemd (even though active processes were using it) WITHOUT giving a reason for "Stopped target Local File Systems" in syslog. Instead systemd tried to mount the filesystems that had been removed from /etc/fstab! in other words your poor univesity either can not afford testing systems or competent sysadmins using them and RTFM or why do you go ahead on production servers with a procedere obviously no tested before? any sane sysadmin (especially when he admits that he is new to the system) has testing setups and in times of virtualizatioin there is no longer any excuse It seems systemd does not like root to unmount a filesystem that is still present in /etc/fstab. no, it just don't like when you edit config, doing steps manually and don't issue "daemon-reload" So I tried to "start local filesystems" after realizing the problem this morning. Then disaster (named "systemd") strikes back: It tried to mount the old filesystems that do no longer exist (and are no longer present in /etc/fstab), resulting in a "dependency failed", and in turn it transitioned a fully running server from multi-user mode to emergency mode, shutting down all services, network, etc. the from the old fstab generated units where partially still there That is why I hate systemd! believe it: systemd hates you too honestly, after all that threads in the past months i would recommend your employer to replace you with someone with better reading comprehence and some solid education you obviously don't have for the SLES your are supposed to maintain I did a "daemon-reload" in the emergency shell, and then I was able to start the default target again. if you only would have done it in the production system after mangle /etc/fstab ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel Unnecessary use of shaming and hurting words. Although the intention was good, systemd is - in my view - overly complex. And yes, when starting with it, one should read the manuals at least once, as a matter of preparation. But I also understand that one can get lost in the jungle called systemd. So, don't pass judgment if you have only a portion of the information. Rather, start asking questions to get the full picture. I hate the self righteous posture of some people, just because they */think/* they know it all/better. --- Frans. ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/fstab obsolete?
On 28-08-19 11:54, Reindl Harald wrote: Am 28.08.19 um 11:24 schrieb Frans de Boer: Unnecessary use of shaming and hurting words. Although the intention was good, systemd is - in my view - overly complex. And yes, when starting with it, one should read the manuals at least once, as a matter of preparation. But I also understand that one can get lost in the jungle called systemd. So, don't pass judgment if you have only a portion of the information. Rather, start asking questions to get the full picture. I hate the self righteous posture of some people, just because they */think/* they know it all/better. look in the archive how this guy started with systemd to get the whole picture, his inital greeting on 2019-05-09 started with that attitude: "I had to subscribe to this list, even though I'm no systemd fan. Still I'll have to deal with it as the distribution we use switched to systemd..." "Cause of the trouble (and possible reason for systemd's unpopularity) seems to be rather arbitrary restrictions without reasoning (which is completely against the GNU spirit of seeking for limitless software)" ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel So, that makes it alright for you to go shaming and bashing? --- Frans. ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/fstab obsolete?
On 28-08-19 14:41, Lennart Poettering wrote: On Mi, 28.08.19 09:33, Ulrich Windl ([email protected]) wrote: Hi! systemd in SLES 12 is causing endless frustration here: Yesterday I was migrating some filesystems to a new device (multipath, MD-RAID, LVM, filesystem, mountpoints, etc.), updating /etc/fstab and other files as needed. After migration was successful, I also cleaned up the now obsolete resources (multipath, MD-RAID, filesystem, mountpoints, etc.) Everything looked OK... But some time later the application was stopped, as the new filesystems were unmounted by systemd (even though active processes were using it) WITHOUT giving a reason for "Stopped target Local File Systems" in syslog. Instead systemd tried to mount the filesystems that had been removed from /etc/fstab! You need to issue "systemctl daemon-reload" when updating this file, systemd only takes notice of changed configuration files when you issue that. This is documented widely, for example here: https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ Moreover, well-meaning distributions would most likely include a comment about this in /etc/fstab to make this discoverable easily by the admin. On Fedora you'll find this comment at the top of the file for example: # After editing this file, run 'systemctl daemon-reload' to update systemd # units generated from this file. systemd does not automatically reload configuration files when they change since that is inherently racy: systemd reads a larger number of unit files and other configuration files and simply by watching file changes with inotify we cannot know when the right time is to reload configuration: we might end up seeing some of the old unit/configuration files and some of the new unit/configuration files, as they are manipulated if we reload at the wrong time. For example, consider the case where you rename a unit file: there is likely a timeframe where enumerating all unit files might see just the old name, and one where it would see just the new name. It might also happen that enumeration sees the file both under the old and the new name, or under neither (simply because file enumeration is a long process). In all these cases we'd end up reading a borked configuration, hence we just don't do that. It is expected for the admin to issue "systemctl daemon-reload" explicitly at the correct time, i.e. when a set of changes to configuration and unit files is complete and before the next set of changes is begun. Only the admin really knows when that is. (I mean, the alternative would be if we'd have a transactional file system on Linux, but we do not, and I don#t see that coming either.) (Another example where things might go very wrong if we'd start reading configuration files at the wrong time: consider RPM removing/updating/installing a bunch of unit files in one go: if we'd wake-up whenever even one file changes we'd very likely wake up at the wrong time and see a file removed with its replacement not there yet, or the opposite. So if we did that and you update a bunch of RPMs at once you'd basically get the guarantee that you will hit this case.) So I tried to "start local filesystems" after realizing the problem this morning. Then disaster (named "systemd") strikes back: It tried to mount the old filesystems that do no longer exist (and are no longer present in /etc/fstab), resulting in a "dependency failed", and in turn it transitioned a fully running server from multi-user mode to emergency mode, shutting down all services, network, etc. That is why I hate systemd! So, there are changes between systemd and pre-systemd, non trivial ones, even. They are documented though, and generally well communicated. Yes, there's a learning curve, and yes you have to read some docs if you have a non-trivial setup you want to convert to systemd. But I am not sure why you unload this on our doorstep. There are technical reasons for these choices, documented ones even. If you convert a machine from pre-systemd systems to systemd, please read the docs thoroughly, and understand the incompatibilities that there are. We write these docs because we know how important this is, not so that you then ignore all we did and blame us anyway. And no, doing a live-update between major OS releases of production infrastructure without reading the docs is a very very bad idea, but not one we came up with, did we? I mean, short of actually *being* sysvinit there's literally nothing we could do to make you happy, can we? Anyway, please vent your frustrations elsewhere, this is not helpful nor new. And: RTFM! Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel Compliments to Lennart, for writing a civilized and clear reaction. In the past, I had my share of frustration with systemd too. To little
[systemd-devel] logind: 242~rc2 break VT/tty switching on Fedora 31
Hi All, I already filed a github issue for $subject: https://github.com/systemd/systemd/issues/13437 But I'm not sure how close github issues are watched hence this email. It would be nice if we can get this fixed for F31 beta, or if some more time is needed, at least get this regression fixed for F31 gold. Regards, Hans ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd backlight:acpi_video0 fails, no such device
Hi, On 02-09-19 07:17, Mantas Mikulėnas wrote: On Mon, Sep 2, 2019 at 7:34 AM Chris Murphy mailto:[email protected]>> wrote: systemd-243~rc2-2.fc31.x86_64 kernel-5.3.0-0.rc6.git1.1.fc32.x86_64 This might be a regression, at least I don't remember this happening before. I can use the expected keys for built-in display brightness, and built-in keyboard brightness. But the service unit fails with an out of the box installation. [chris@fmac ~]$ sudo systemctl status systemd-backlight@backlight:acpi_video0.service ● systemd-backlight@backlight:acpi_video0.service - Load/Save Screen Backlight Brightness of backlight:acpi_video0 Loaded: loaded (/usr/lib/systemd/system/[email protected]; static; vendor preset: disabled) Active: failed (Result: exit-code) since Sun 2019-09-01 19:57:37 MDT; 8min ago Docs: man:[email protected](8) Process: 667 ExecStart=/usr/lib/systemd/systemd-backlight load backlight:acpi_video0 (code=exited, status=1/FAILURE) Main PID: 667 (code=exited, status=1/FAILURE) Sep 01 19:57:37 fmac.local systemd[1]: Starting Load/Save Screen Backlight Brightness of backlight:acpi_video0... Sep 01 19:57:37 fmac.local systemd-backlight[667]: Failed to get backlight or LED device 'backlight:acpi_video0': No such device Sep 01 19:57:37 fmac.local systemd[1]: systemd-backlight@backlight:acpi_video0.service: Main process exited, code=exited, status=1/FAILURE Sep 01 19:57:37 fmac.local systemd[1]: systemd-backlight@backlight:acpi_video0.service: Failed with result 'exit-code'. Sep 01 19:57:37 fmac.local systemd[1]: Failed to start Load/Save Screen Backlight Brightness of backlight:acpi_video0. [chris@fmac ~]$ # find /sys -name "*video0*" /sys/class/video4linux/video0 /sys/devices/pci:00/:00:1a.7/usb1/1-2/1-2:1.0/video4linux/video0 # ls -l /sys/class/backlight/ total 0 lrwxrwxrwx. 1 root root 0 Sep 1 19:57 gmux_backlight -> ../../devices/pnp0/00:03/backlight/gmux_backlight lrwxrwxrwx. 1 root root 0 Sep 1 19:57 intel_backlight -> ../../devices/pci:00/:00:02.0/drm/card0/card0-LVDS-1/intel_backlight Could it be that acpi_backlight is loaded at first, but gets replaced by intel_backlight before systemd could react? Maybe, the gmux_backlight suggests that this is a macbook. On normal machines, what you say will not happen because linux/drivers/acpi/acpi_video.c has: static int __init acpi_video_init(void) { ... if (intel_opregion_present()) return 0; And then later the i915 kms driver tells acpi_video it is ok to actual register by calling acpi_video_register() But on mac Books there also is the gmux, and I see that the gmux code also calls acpi_video_register(), possibly before the i915 driver is setup, which would trigger the race you suggest where acpi_video.c registers it backlight interface, which is only done if there are no "native" preferred backlight interfaces and then i915 comes along, registers its "native" backlight interface and the acpi backlight code removes its acpi_video0 in response to that. So yes this seems like a race, which only gets seen on macbooks. Regards, Hans ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bad accelerometer values cause incorrect screen rotation
Hi Daniel, On 05-09-19 11:05, Daniel Drake wrote: Hi, so sometimes we even apply the wrong quirks. Two recent examples: https://bugzilla.redhat.com/show_bug.cgi?id=1717712 (more on this case below) I see the latest development of having the hwdb specify whether the accelerometer is in the base or the display of the device. This was implemented for dealing with a device with accelerometers in both positions (https://github.com/hadess/iio-sensor-proxy/pull/262) - clearly the screen rotation should only follow thy display-mounted accelerometer in that case. The ACCEL_LOCATION attribute was always intended not only for 360 degree hinges 2-in-1s but also for clamshells with only a sensor in the base and the intention was always for iio-sensor-proxy to ignore sensors in the base for display rotation. See the very first systemd issue filed about this: https://github.com/systemd/systemd/issues/6557 The subject of this is "Add "orientation ignore" property for accelerometers" which says it all. Using sensors in the base for rotation simply make no sense, for 1 normal clamshell devices can only be used in one orientation (without getting creative) so not doing rotation on them makes the most sense. Also there is no way to reliably translate base accel results to display accel results since we do not know the angle between the 2 we could blindly assume 90 degrees, but that would just be a guess really. However now that iio-sensor-proxy ignores "base" accelerometers (regardless of whether or not there's another accelerometer in the display), that's being misused at least in this case: https://bugzilla.redhat.com/show_bug.cgi?id=1717712 It is not being misused, since this is not a tablet or 2-in-1 disabling rotation is the right thing to do. This is a HP laptop and it looked like the policy was once "we will not accept quirks for HP machines that use the lis3lv02d device, they should go in the hp_accel.c driver instead" (https://github.com/systemd/systemd/commit/0d1a2be93e16aa03026f1c36e81951097e8dad2c) but that doesn't seem to have been followed here. Getting the orientation right is an orthogonal problem to specifying the location. Someone can still submit a kernel patch for this. Although I wonder if in the cases where people can play neverball with the accelerometer we are not dealing with tablets, so that the sensor is actually in the screen. Although in this case the quirk just states that the sensor is in the base of the laptop, which now causes iio-sensor-proxy to ignore it. But since the kernel data was wrong in the first place, the user is now left with an accelerometer that can't be used to play neverball, nor can be used to rotate the screen. The laptop in question weighs 2.3 kilos holding that in front of you so that you can play neverball seems something which you will grow tired of very quickly. In the single accelerometer case, for an ordinary clamshell laptop, it doesn't actually matter if the accelerometer is in the display or not. Since the accelerometer measures all 3 dimensions and screen position relative to the base is known, a mount matrix can be applied to deal with any positioning scheme. First of all screen position relatively to the base is not known it can be anywhere from 90 to 180 degrees angle. Second of all using accelerometer based rotation on a clamshell is almost always wrong. What if we had an ordinary clamshell laptop producing "bad" data where the accelerometer is actually mounted behind the display (was this even checked here?) - would a ACCEL_POSITION=base quirk still then be accepted? No the laptop was not opened to check the location of the accelerometer, nor was an elaborate dance done to check things at different display open angles. I purely guessed the location of the sensor, but that seems like a pretty safe check, since the primary use of this sensor in HP laptops is for freefall detection / HD protection. Also they can either put it on the mainboard, or route an extra cable through the hinges to put it on an extra PCB behind the display, which just is not logical to do. Although this fix seems somewhat technically incorrect, perhaps it has its roots in the same things I'm trying to say here: I disagree that the fix is technically incorrect. when the bug bites it's really quite serious, it's tricky and annoying to fix the root cause, and why do we even care about automatic screen rotation on standard clamshell laptops anyway - the product itself is totally unusable when in any position other than "sitting flat on the desk" - just try typing or using the touchpad... So we seem to be in agreement that having automatic screen rotation on clamshells is useless. The problem is we cannot reliably identify clamshells, DMI chassis-type info is not reliable enough for this. One possible solution which I see is to have iio-sensor-proxy use a white-list like this: 1) Is ACCEL_ORIENTATION set ? Yes -> ok 2) Is this a HID bases sensor
Re: [systemd-devel] Bad accelerometer values cause incorrect screen rotation
Hi, On 05-09-19 12:49, Bastien Nocera wrote: On Thu, 2019-09-05 at 18:38 +0800, Daniel Drake wrote: On Thu, Sep 5, 2019 at 6:07 PM Bastien Nocera wrote: I've read through this, and I'm happy blacklisting the hp_accel driver in code. For the other devices, I'd rather leave it as-is. That would indeed avoid most problem cases that I've seen, and the current case, probably enough to stop me grumbling for another year or so until this happens again in some other context :) So I support that idea. Do you have any preference on where we blacklist it? In the hwdb it's quite easy to match DMI vendor HP & driver lis3lv02d. But we'd really want a new way of saying "ignore the accelerometer" as ACCEL_POSITION=base doesn't seem like the right way to express that. Or we could blacklist it in iio-sensor-proxy but since there's no mention of hp_accel in the udev properties for the device (you just get the driver as li3lv02d) then you'd need to grab the DMI vendor name from /sys/class/dmi/id or something like that. Maybe making this driver export enough data so we can blacklist it would be the best way to go about it, along with a new udev property. We should make this driver export enough data so we can differentiate it, then we can install a udev property private to iio-sensor-proxy about ignoring specific accelerometers such as this one. This way, the sensor hwdb only contains quirks, not policy decisions about whether the hp_accel driver is worthy. I think a good question to ask here is, why do we want to blacklist the lis3lv02d when used in HP laptops and I think the answer is because it usually sits in the base of the device. So a simpler answer here might be to just do this: diff --git a/hwdb/60-sensor.hwdb b/hwdb/60-sensor.hwdb index 3976d9a76a..de5e1b95a2 100644 --- a/hwdb/60-sensor.hwdb +++ b/hwdb/60-sensor.hwdb @@ -288,13 +288,6 @@ sensor:modalias:acpi:KIOX000A*:dmi:bvnAmericanMegatrendsInc.:bvr5.11:bd05/25/201 # is then applied below. sensor:modalias:platform:lis3lv02d:dmi:*svn*Hewlett-Packard*:* ACCEL_MOUNT_MATRIX=1, 0, 0; 0, 0, -1; 0, 1, 0 - -# HP laptops which have the lis3lv02d device in the base, tell iio-sensor-proxy -# about this so that the sensor is not used for display orientation -sensor:modalias:platform:lis3lv02d:dmi:*svn*Hewlett-Packard*:*pnHPProBook4535s* - ACCEL_LOCATION=base - -sensor:modalias:platform:lis3lv02d:dmi:*:svnHewlett-Packard:pnHPENVY17NotebookPC:* ACCEL_LOCATION=base sensor:modalias:acpi:SMO8500*:dmi:*:svnHewlett-Packard:pnHPStream7Tablet:* So in the default hwdb rule for HP laptops with the lis3lv02d sensor mark the sensor as being in the base. This will have the same result as marking it as hp_accel + blacklisting hp_accel in iio-sensor-proxy. With the added advantage that we can whitelist it if we encounter a HP tablet or 2-in-1 where we do actually want to use it for auto-rotation. And this would not require adding any extra code anywhere, so I believe this would be a nice KISS solution. Regards, Hans ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bad accelerometer values cause incorrect screen rotation
Hi, On 05-09-19 13:28, Bastien Nocera wrote: On Thu, 2019-09-05 at 13:13 +0200, Hans de Goede wrote: Hi, On 05-09-19 12:49, Bastien Nocera wrote: On Thu, 2019-09-05 at 18:38 +0800, Daniel Drake wrote: On Thu, Sep 5, 2019 at 6:07 PM Bastien Nocera wrote: I've read through this, and I'm happy blacklisting the hp_accel driver in code. For the other devices, I'd rather leave it as-is. That would indeed avoid most problem cases that I've seen, and the current case, probably enough to stop me grumbling for another year or so until this happens again in some other context :) So I support that idea. Do you have any preference on where we blacklist it? In the hwdb it's quite easy to match DMI vendor HP & driver lis3lv02d. But we'd really want a new way of saying "ignore the accelerometer" as ACCEL_POSITION=base doesn't seem like the right way to express that. Or we could blacklist it in iio-sensor-proxy but since there's no mention of hp_accel in the udev properties for the device (you just get the driver as li3lv02d) then you'd need to grab the DMI vendor name from /sys/class/dmi/id or something like that. Maybe making this driver export enough data so we can blacklist it would be the best way to go about it, along with a new udev property. We should make this driver export enough data so we can differentiate it, then we can install a udev property private to iio-sensor-proxy about ignoring specific accelerometers such as this one. This way, the sensor hwdb only contains quirks, not policy decisions about whether the hp_accel driver is worthy. I think a good question to ask here is, why do we want to blacklist the lis3lv02d when used in HP laptops and I think the answer is because it usually sits in the base of the device. So a simpler answer here might be to just do this: diff --git a/hwdb/60-sensor.hwdb b/hwdb/60-sensor.hwdb index 3976d9a76a..de5e1b95a2 100644 --- a/hwdb/60-sensor.hwdb +++ b/hwdb/60-sensor.hwdb @@ -288,13 +288,6 @@ sensor:modalias:acpi:KIOX000A*:dmi:bvnAmericanMegatrendsInc.:bvr5.11: bd05/25/201 # is then applied below. sensor:modalias:platform:lis3lv02d:dmi:*svn*Hewlett-Packard*:* ACCEL_MOUNT_MATRIX=1, 0, 0; 0, 0, -1; 0, 1, 0 - -# HP laptops which have the lis3lv02d device in the base, tell iio- sensor-proxy -# about this so that the sensor is not used for display orientation -sensor:modalias:platform:lis3lv02d:dmi:*svn*Hewlett- Packard*:*pnHPProBook4535s* - ACCEL_LOCATION=base - -sensor:modalias:platform:lis3lv02d:dmi:*:svnHewlett- Packard:pnHPENVY17NotebookPC:* ACCEL_LOCATION=base sensor:modalias:acpi:SMO8500*:dmi:*:svnHewlett- Packard:pnHPStream7Tablet:* So in the default hwdb rule for HP laptops with the lis3lv02d sensor mark the sensor as being in the base. This will have the same result as marking it as hp_accel + blacklisting hp_accel in iio-sensor-proxy. With the added advantage that we can whitelist it if we encounter a HP tablet or 2-in-1 where we do actually want to use it for auto-rotation. And this would not require adding any extra code anywhere, so I believe this would be a nice KISS solution. That works for me, although the mount matrix would now be wrong and should probably be removed (or moved). True, I will remove it. I'd check the existing entries for tablets and 2-in-1 at the same time though, and those ones would use the mount matrix, right? Yes those should use the mount matrix, but there are no existing model specific entries for the lis3lv02d other then 2 which set ACCEL_LOCATION=base Which are rendered obsolete by us now setting this for the generic quirk. Regards, Hans ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bad accelerometer values cause incorrect screen rotation
Hi, On 05-09-19 14:11, Hans de Goede wrote: Hi, On 05-09-19 13:28, Bastien Nocera wrote: On Thu, 2019-09-05 at 13:13 +0200, Hans de Goede wrote: Hi, On 05-09-19 12:49, Bastien Nocera wrote: On Thu, 2019-09-05 at 18:38 +0800, Daniel Drake wrote: On Thu, Sep 5, 2019 at 6:07 PM Bastien Nocera wrote: I've read through this, and I'm happy blacklisting the hp_accel driver in code. For the other devices, I'd rather leave it as-is. That would indeed avoid most problem cases that I've seen, and the current case, probably enough to stop me grumbling for another year or so until this happens again in some other context :) So I support that idea. Do you have any preference on where we blacklist it? In the hwdb it's quite easy to match DMI vendor HP & driver lis3lv02d. But we'd really want a new way of saying "ignore the accelerometer" as ACCEL_POSITION=base doesn't seem like the right way to express that. Or we could blacklist it in iio-sensor-proxy but since there's no mention of hp_accel in the udev properties for the device (you just get the driver as li3lv02d) then you'd need to grab the DMI vendor name from /sys/class/dmi/id or something like that. Maybe making this driver export enough data so we can blacklist it would be the best way to go about it, along with a new udev property. We should make this driver export enough data so we can differentiate it, then we can install a udev property private to iio-sensor-proxy about ignoring specific accelerometers such as this one. This way, the sensor hwdb only contains quirks, not policy decisions about whether the hp_accel driver is worthy. I think a good question to ask here is, why do we want to blacklist the lis3lv02d when used in HP laptops and I think the answer is because it usually sits in the base of the device. So a simpler answer here might be to just do this: diff --git a/hwdb/60-sensor.hwdb b/hwdb/60-sensor.hwdb index 3976d9a76a..de5e1b95a2 100644 --- a/hwdb/60-sensor.hwdb +++ b/hwdb/60-sensor.hwdb @@ -288,13 +288,6 @@ sensor:modalias:acpi:KIOX000A*:dmi:bvnAmericanMegatrendsInc.:bvr5.11: bd05/25/201 # is then applied below. sensor:modalias:platform:lis3lv02d:dmi:*svn*Hewlett-Packard*:* ACCEL_MOUNT_MATRIX=1, 0, 0; 0, 0, -1; 0, 1, 0 - -# HP laptops which have the lis3lv02d device in the base, tell iio- sensor-proxy -# about this so that the sensor is not used for display orientation -sensor:modalias:platform:lis3lv02d:dmi:*svn*Hewlett- Packard*:*pnHPProBook4535s* - ACCEL_LOCATION=base - -sensor:modalias:platform:lis3lv02d:dmi:*:svnHewlett- Packard:pnHPENVY17NotebookPC:* ACCEL_LOCATION=base sensor:modalias:acpi:SMO8500*:dmi:*:svnHewlett- Packard:pnHPStream7Tablet:* So in the default hwdb rule for HP laptops with the lis3lv02d sensor mark the sensor as being in the base. This will have the same result as marking it as hp_accel + blacklisting hp_accel in iio-sensor-proxy. With the added advantage that we can whitelist it if we encounter a HP tablet or 2-in-1 where we do actually want to use it for auto-rotation. And this would not require adding any extra code anywhere, so I believe this would be a nice KISS solution. That works for me, although the mount matrix would now be wrong and should probably be removed (or moved). True, I will remove it. So looking at the mount-matrix closer, the comment describes it as mapping "from "can play neverball" to "matches Windows 8 orientation"" but what it really does translates base-coordinates to display-coordinates assuming the display is at an angle of exact 90 degrees to the base (swap Y and Z axis). So dropping the MOUNT_MATRIX very much is the right thing, as this will leave us with sensor readings in base-coordinates matching the ACCEL_LOCATION=base udev attribute. I think that this will greatly help with the problem Daniel described, as least for HP laptops which seem to be a major source of bug reports about this problem. I've submitted a pullreq with the discussed changes here: https://github.com/systemd/systemd/pull/13479 Regards, Hans ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
Hi all, Currently, at least in Fedora, but I do not believe that this problem is unique to Fedora, there are 2 problems with keymap handling in the initrd. 1: If the keymap in vconsole.conf is changed then this does not apply to the initrd without rebuilding it. This means that any changes are only applied after installing a new kernel This has been reported a long time ago https://bugzilla.redhat.com/show_bug.cgi?id=1405539 and is also listed on the list of Fedora high prio bugs: https://fedoraproject.org/wiki/Fedora_Program_Management/Prioritized_bugs_and_issues 2: With silverblue, which ships with a generic pre-generated initrd we end up with always using the keymap as defined when building the initrd on the buildsys (KEYMAP=us), also see: https://github.com/fedora-silverblue/issue-tracker/issues/3 Now arguably 1. could be fixed by regenerating the initrd, but that is tricky, because if some component has changed on the system since the last time the initrd was generated this will change more then just the embedded vconsole.conf possibly stopping the system from booting (this should never happen, but in reality this is a real risk). Also do we want localed to trigger initrd rebuilds? And if we do not want that, then should tools calling the localed DBUS API do this? If all the tools need to do that then it seems to me that the API is incomplete / not fully functional, so that seems undesirable. And for 2. we really do not want to rebuild the initrd ever, and for the "normal" distro case at least for Fedora we also want to move to pre-generated initrds so that we can sign them, etc. TL;DR: IMHO regenerating the initrd is not the answer here. I believe that the best alternative is to have localed append / update a rd.vconsole.keymap=foo argument to the kernel commandline, to override the vconsole.conf KEYMAP setting, but only in the initrd (so that later runtime changes when booted still work). The way I see this working is that localed does a read-modify-write of all the BLS .conf files under /boot/loader/entries and updates their "options" line to have rd.vconsole.keymap=foo appended or updated if already present. I'm willing to write localed patches implementing this (targetting Fedora 32) but before I spend time on this, it would be good to have consensus that this is the best way to handle this. Note I'm open to other suggestions. Regards, Hans ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
Hi, On 26-09-2019 11:10, Michael Chapman wrote: On Thu, 26 Sep 2019, Hans de Goede wrote: [...] I believe that the best alternative is to have localed append / update a rd.vconsole.keymap=foo argument to the kernel commandline, to override the vconsole.conf KEYMAP setting, but only in the initrd (so that later runtime changes when booted still work). The way I see this working is that localed does a read-modify-write of all the BLS .conf files under /boot/loader/entries and updates their "options" line to have rd.vconsole.keymap=foo appended or updated if already present. To be honest, I really do think having the initrd rebuilt completely is a better approach... but I do not think localed should be directly responsible for that. As I already mentioned there are 2 issues with rebuilding the initrd: 1) It might break booting the system and, assuming we rebuild the initrd for all installed kernels on a locale change, then their will not be an older one to fallback to as there normally is, which is BAD. 2) We are moving (and in case of rpmostree based distros already shipping) to pre-generated (on the distros buildsys) initrds, which likely will also be signed. How do you propose to solve these 2 issues? There are a lot of reasons the initrd needs to be rebuilt. Changing the system locale is just one of them. It seems unreasonable to have every tool know how to append boot parameters. Actually there are not that many reasons, Note that all other config info needed for the initrd, like the rootfs UUID, which raid/lvm members to assemble, etc. is already on the kernel commandline, so it seems logical to put the locale (which is config info) there too and pre systemd at least Fedora was already doing this. I would be a lot happier seeing a "well-known" binary that various things can call to rebuild the initrd, somewhat akin to the kernel-install we have already. That way distributions can plug in whatever tooling they use for initrds (e.g. dracut, initramfs-tools, ...) So maybe we need a well-known binary to update the kernel-commandline ? Regards, Hans ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
Hi, On 26-09-2019 11:53, Michael Chapman wrote: On Thu, 26 Sep 2019, Hans de Goede wrote: Hi, On 26-09-2019 11:10, Michael Chapman wrote: On Thu, 26 Sep 2019, Hans de Goede wrote: [...] I believe that the best alternative is to have localed append / update a rd.vconsole.keymap=foo argument to the kernel commandline, to override the vconsole.conf KEYMAP setting, but only in the initrd (so that later runtime changes when booted still work). The way I see this working is that localed does a read-modify-write of all the BLS .conf files under /boot/loader/entries and updates their "options" line to have rd.vconsole.keymap=foo appended or updated if already present.Hi, To be honest, I really do think having the initrd rebuilt completely is a better approach... but I do not think localed should be directly responsible for that. As I already mentioned there are 2 issues with rebuilding the initrd: 1) It might break booting the system and, assuming we rebuild the initrd for all installed kernels on a locale change, then their will not be an older one to fallback to as there normally is, which is BAD. 2) We are moving (and in case of rpmostree based distros already shipping) to pre-generated (on the distros buildsys) initrds, which likely will also be signed. How do you propose to solve these 2 issues? Hmm, these are good points. I do like the idea of using a locally-generated overlay initrd though. Ok, looking at: https://github.com/fedora-silverblue/issue-tracker/issues/3 It seems that this might be the preference of the silverblue developers too and Javier also seems to favor that, so I guess the first thing to do is to give that approach a try. I've added a comment to: https://github.com/fedora-silverblue/issue-tracker/issues/3 asking the silverblue devs to confirm that the overlay initramfs is still their preferred approach, once that is confirmed I will give this a try by manually creating on overlay initramfs and then we will see from there. Regards, Hans ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
Hi, On 26-09-2019 14:13, Alberto Ruiz wrote: Hello Hans, Thanks for starting this discussion. Looking at this from a Fedora/Dracut POV, I think we should look at this as the start of implementing a configuration-only initramfs, (something Matthew Garret has been advocating for a while) rather than making this a vconsole.conf/plymouth specific solution. Yes there seems to be consensus that the best way to handle this is using an overlay initramfs. Let me copy and paste my comment on the silverblue issue about this here: "So my plan for regular Fedora for this is as follows: 1. Have a /boot/initramfs-config.img which for now will just contain /etc/vconsole.conf (chances are this will get more files added over time) 2. Modify mkbls from /usr/lib/kernel/install.d/20-grub.install to add an initrd line for this image to the generated bls .conf file if the image is present 3. Add a new update-config-initramfs command to the install-kernel script, which generates /boot/initramfs-config.img 4. Make systemd-localed call "install-kernel update-config-initramfs: on locale (and keymap) setting changes" I am waiting for feedback from the silverblue people to see if this will also work for them. If they are happy with this then I plan to start implementing this when I'm done with the plymouth keyboard layout indicator stuff. Regards, Hans On Thu, Sep 26, 2019 at 12:43 PM Hans de Goede mailto:[email protected]>> wrote: Hi, On 26-09-2019 11:53, Michael Chapman wrote: > On Thu, 26 Sep 2019, Hans de Goede wrote: >> Hi, >> >> On 26-09-2019 11:10, Michael Chapman wrote: >>> On Thu, 26 Sep 2019, Hans de Goede wrote: >>> [...] >>>> I believe that the best alternative is to have localed append / update >>>> a rd.vconsole.keymap=foo argument to the kernel commandline, to override >>>> the vconsole.conf KEYMAP setting, but only in the initrd (so that later >>>> runtime changes when booted still work). >>>> >>>> The way I see this working is that localed does a read-modify-write of >>>> all the BLS .conf files under /boot/loader/entries and updates their >>>> "options" line to have rd.vconsole.keymap=foo appended or updated if >>>> already present.Hi, >>> >>> To be honest, I really do think having the initrd rebuilt completely is a >>> better approach... but I do not think localed should be directly >>> responsible for that. >> >> As I already mentioned there are 2 issues with rebuilding the initrd: >> >> 1) It might break booting the system and, assuming we rebuild the initrd >> for all installed kernels on a locale change, then their will not be >> an older one to fallback to as there normally is, which is BAD. >> >> 2) We are moving (and in case of rpmostree based distros already shipping) >> to pre-generated (on the distros buildsys) initrds, which likely will >> also be signed. >> >> How do you propose to solve these 2 issues? > > Hmm, these are good points. I do like the idea of using a > locally-generated overlay initrd though. Ok, looking at: https://github.com/fedora-silverblue/issue-tracker/issues/3 It seems that this might be the preference of the silverblue developers too and Javier also seems to favor that, so I guess the first thing to do is to give that approach a try. I've added a comment to: https://github.com/fedora-silverblue/issue-tracker/issues/3 asking the silverblue devs to confirm that the overlay initramfs is still their preferred approach, once that is confirmed I will give this a try by manually creating on overlay initramfs and then we will see from there. Regards, Hans -- Alberto Ruiz Engineering Manager - Desktop Hardware Enablement Red Hat ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
Hi, On 9/27/19 1:49 PM, Lennart Poettering wrote: On Mi, 25.09.19 16:50, Hans de Goede ([email protected]) wrote: Hi all, Currently, at least in Fedora, but I do not believe that this problem is unique to Fedora, there are 2 problems with keymap handling in the initrd. Hmm, why do you need a correct initrd in the early boot? I can see two reasons: 1. full disk encryption with the user typing in the password on the kbd. Ack that is the main use-case for this. But isn't the answer to this to link the root OS to the tpm instead, and use user-keyed crypto only for $HOME? The OS itself doesn't need to be protected after all, everbody should have the same files there anyway, it's $HOME that needs protection. Well until we make sure nothing ever writes outside of the user homedir security conscious users will likely still want to use full-disk encryption and there is also plenty of hw which Fedora supports which does not have a TPM2 2. debugging in the initrd. Does this really matter though? Aren't people who can usefully debug the initrd also smart enough to load the kbd mappings themselves (or work with american keybindings for a bit)? I agree that this is a non-issue. Aren't you making something here a problem that actually doesn't matter much? We have a bug open for this for a long long time and it is even listed on: https://fedoraproject.org/wiki/Fedora_Program_Management/Prioritized_bugs_and_issues That said, if it is worth fixing this, I think it is safe to say that the people involved from the Fedora side have decided it is indeed worth fixing this. why stop at the initrd here, shouldn't the bootloader get right keymaps too? After all, most boot loaders I know have a line editor... That is a very interesting point, on one hand using the bootloader line-editor sort of matches your dracut-debug scenario, IOW not so important to fix. OTOH I agree that if we are looking into fixing the kbd layout for the initrd it would be interesting to see if we can also fix it for the bootloader. Which hence raises the question: isn't this something the boot loader should manage initially, and then just pass to the kernel/initrd? i.e. on EFI systems, shouldn't this just be an efi var, that the boot ldr can read, and then pass on to the kernel (or alternatively, read by the initrd?) Alternatively, if you care about non-EFI, isn't this also something you want to tell the boot ldr about, and then have the boot loader pass to the kernel, maybe via a struct boot_param entry? (or simply by appending something to the kernel cmdline if that doesn't fly). We definitely care about non EFI and we care about a scala on bootloaders, modifying them all for this really does not scale, so I believe we really need a solution outside of the bootloader and parallel to that we can think about also passing this info to the bootloader somehow. TL;DR: IMHO regenerating the initrd is not the answer here. Yeah, leave the initrd alone, it should be immutable outside of kernel updates, I am sure. I'm willing to write localed patches implementing this (targetting Fedora 32) but before I spend time on this, it would be good to have consensus that this is the best way to handle this. Note I'm open to other suggestions. I'd be happy to merge patches that just use an EFI variable for this, so that boot loader, initrd and GNOME can all make use of this. I know you love EFI variables and I understand why you do, but unfortunately there are still e.g. a lot of 64 bit core2 duo laptops and desktops which still run fine and are still being used, so we still need to support legacy BIOS for those and there are also other more exotic platforms which do not have EFI. TL;DR: we do not live in an EFI only world, so using EFI is not the answer. Regards, Hans ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] user slice changes for uid ranges
hi all, i'm looking for an "easy" way to set resource limits on a group of users. we are lucky enough that this group of users is within a (although large) high enough range, so a range of uids is ok for us. generating a user-.slice file for every user (or symlink them or whatever) looks a bit cumbersome, and probably not really performance friendly if the range is in eg 100k (possible) uids. e.g. if this range was 100k-200k, i was more looking for a way to do e.g. user-1X.slice or user-10:20.slice (i think this is different from/not covered by the templated/prefix user slice patch https://github.com/systemd/systemd/commit/5396624506e155c4bc10c0ee65b939600860ab67) many thanks for any suggestion, stijn ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
Hi, On 9/27/19 1:59 PM, Lennart Poettering wrote: On Fr, 27.09.19 10:20, Hans de Goede ([email protected]) wrote: "So my plan for regular Fedora for this is as follows: 1. Have a /boot/initramfs-config.img which for now will just contain /etc/vconsole.conf (chances are this will get more files added over time) 2. Modify mkbls from /usr/lib/kernel/install.d/20-grub.install to add an initrd line for this image to the generated bls .conf file if the image is present 3. Add a new update-config-initramfs command to the install-kernel script, which generates /boot/initramfs-config.img 4. Make systemd-localed call "install-kernel update-config-initramfs: on locale (and keymap) setting changes" Uh wah? Na, let's not hook invocations of install-kernel into localed. that's just a mess. This is not thought to the end. Secondly, the boot loader specification (the original one, not the weird templating/macro language fedora grub adopted) allows multiple initrds to be specified, with any path you like (as long as it's relative to $BOOT). > Hence, you can just just use a fixed path there pointing to an initrd that is shared between all boot loader entries, and then you don't need to regenerate anything, but this one initrd file that is shared. Right, that is what this is about, regenerating the shared initrd when localed changes /etc/vconsole.conf. Since localed is the process modifying /etc/vconsole.conf, it should also trigger the regenerate of the shared initrd. If you do not like doing this through calling install-kernel, then I'm open to other suggestions for how localed can trigger / start the regeneration of the shared initrd. Then, what about SecureBoot? I mean, do you intend to sign this second initrd? Just overlaying an unverified unvalidated initrd above the actual one is dangerous as it can be, there needs to be some validation beforehand. Well ATM we do not verify the initrd at all, nor do we verify the kernel commandline. The commandline currently contains system specific info; and with your bootloader appends keymap argument proposal, would change on a keymap change. IOW it looks like we need some way to sign (with a local key) locally generated data, such as a shared config-initrd or the kernel commandline. This is a pre-existing problem which is not really made (much) worse by adding a config initrd. Doing efi vars for this at least means the various bits and pieces have to validate things explicitly for each, it's not a blanket license to insert anything randomly into the initrd... Anyway, this all sounds like it's not thought to the end. Why care for the initrd only, not the boot loader keymap? Per your own argument of why this would not be necessary for the initrd when used only for debugging, it also is not really necessary for the bootloader cmdline, since normal use-cases do not involve the bootloader cmdline. Is this actually necessary at all? Yes! Why isn't an EFI-specific solution with EFI vars for this enough? How do you handle signing/validation of this? Lennart, please stop with ALWAYS suggesting EFI only solutions, we have had the EFI only discussion a zillion times already and it is NOT productive. Please let it sink in that as long as legacy boot and non EFI architectures are officially supported by Fedora, an EFI only solution is never going to fly (for Fedora), Let's maybe think about all that first, before sending any patches... Thinking before sending patches is exactly why I started this discussion, so thank you for your input, but again please let go of the whole EFI only mindset it is very unhelpful and unproductive. Regards, Hans ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
Hi, On 29-09-2019 12:08, Lennart Poettering wrote: On Fr, 27.09.19 16:00, Hans de Goede ([email protected]) wrote: Anyway, even if you insist that the Fedora desktop should care about non-EFI, which I can accept, isn't the lesson to learn to add some concept like EFI vars to those archs too? i.e. apparently OSes and boot loaders want to communicate, so why not make that happen on those archs too? I mean, the concept of EFI vars is simple and semantically it's not even essential to have NVRAM to store them in — a fact to which the EFI firmware typically used by qemu/kvm is document, as it actually stores those EFI vars in the ESP, so that they are included in the VM image. So what you are arguing for is replacing the overlay initramfs with a key-value config file which gets used by both the bootloader and the OS. That is an interesting concept, esp. since it limits (as you advocate) what can be done in the overlay from "everything" to "set specific config variables to a value". So yes I can get behind this. i.e maybe write down a spec, that declares how to store settings shared between host OS, boot loader and early-boot kernel environment on systems that have no EFI NVRAM, and then we can make use of that. i.e. come up with semantics inspired by the boot loader spec for finding the boot partition to use, then define a couple of files in there for these params. In fact, sd-boot nowadays stores the boot-time random seed it manages to initialize the kernel's entropy pool with in $BOOT/loader/random-seed. It would only be natural to build on that, and introduce $BOOT/loader/kbdmap and so on. i.e. generating initrd images with cpio and so on is hacky, gluey, Linux-specific. If you just use plain simple, standardized config files at clearly defined locations, then reading and writing them is simple, they can be shared between all players, are not Linux specific and so on. I think systemd could certainly commit to updating those files then. This sounds interesting, although I'm not sure I like the one file per setting approach why not have a $BOOT/loader/config file which has key=value pairs and kbdmap would be a key in that file? Putting together such a spec isn't difficult even. Could be as short as: "This spec builds on the boot loader spec. The keyboard map is stored in $BOOT/loader/kbdmap, using ISO-3166-1 alpha-2 country codes. We suggest boot loaders use this for their own key maps, and pass it to the OS, for example via the kernel command line." I'm afraid that will not work, some countries have multiple variants, we actually have a bunch of Fedora bugs open about the disk unlock support in plymouth and the "de-neo" keymap and there also are the somewhat popular dvorak variants. So we could do this as say a base setting but then we would need to add a kbdmap_variant setting which when sets makes the keymap loaded $kbdmap-$variant.map (in Linux Console terms) I guess we could specify that setting a variant this way is allowed, but that variant settings are OS / bootloader specific and may be ignored? Regards, Hans ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
Hi, On 30-09-2019 13:23, Hans de Goede wrote: Hi, On 29-09-2019 12:08, Lennart Poettering wrote: On Fr, 27.09.19 16:00, Hans de Goede ([email protected]) wrote: Anyway, even if you insist that the Fedora desktop should care about non-EFI, which I can accept, isn't the lesson to learn to add some concept like EFI vars to those archs too? i.e. apparently OSes and boot loaders want to communicate, so why not make that happen on those archs too? I mean, the concept of EFI vars is simple and semantically it's not even essential to have NVRAM to store them in — a fact to which the EFI firmware typically used by qemu/kvm is document, as it actually stores those EFI vars in the ESP, so that they are included in the VM image. So what you are arguing for is replacing the overlay initramfs with a key-value config file which gets used by both the bootloader and the OS. That is an interesting concept, esp. since it limits (as you advocate) what can be done in the overlay from "everything" to "set specific config variables to a value". So yes I can get behind this. While discussing this with Alberto an interesting problem came up. If we put this file in /boot/loader as you suggest, then the boot-loader can get to it and use it to set its keymap (and in the future probably also other stuff) but how does the localed in the initrd get to this file? I agree with you that having a generic mechanism to share config between the OS and early-boot (so bootloader + initrd) is useful, but are we then going to make the initrd mount /boot (or the ESP) ? One wild idea I had is to have the bootloader generate an initrd on the fly with just the file in there named as say /bootloader-config and then have the bootloader pass that dynamic initrd as extra initrd to the kernel. This assumes that for TPM stuff the bootloader is the one doing the initrd measurement and that it then will NOT measure this extra initrd. This to me seems the best way to keep this flexible and avoids the pitfalls of having to mount /boot in the initrd, which I'm sure is going to break for some crazy setups (like encrypted /boot which is unlocked from within grub). This will require modifying the bootloaders we care about to do this, but that is doable. Regards, Hans ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] user slice changes for uid ranges
hello mantas, jeremy, all, wrt the pam script magic, i'm not a big fan, esp because it is optional. i'd rather have those users not login than that they don't have the constraints. (but obvioulsy, i really don't want to lock myself out, so i totally see what you need the optional keyword) wrt the generators, i'll have a look how those really work and what i could do with them. i like the idea that the user slice settings are only generated when needed (and maybe even cleaned upwhen there are too many old ones to avoid performance issues) searching for info on generators and user slices, i stumbled on https://github.com/systemd/systemd/issues/2556 where this was also mentioned. unfortunaltey, no examples, so if someone can share some examples, that would be great ! anyway, thanks a lot, stijn On 9/29/19 4:07 PM, Jérémy ROSEN wrote: > I don't have a complete solutions, but here are a couple of tools that you > might be able to assemble into something that work > * dropins, you could do a dropin for every existing UID that sets the > Slice= field > * generators : could be used to generate those dropins > * also note that if a unit is named a-b-c.service, systemd will look for > dropins named a-b-.service and a-.service... there might be something to do > with that, but I havn't given it much thought > > Le ven. 27 sept. 2019 à 18:28, Mantas Mikulėnas a > écrit : > >> On Fri, Sep 27, 2019 at 5:03 PM Stijn De Weirdt >> wrote: >> >>> hi all, >>> >>> i'm looking for an "easy" way to set resource limits on a group of users. >>> >>> we are lucky enough that this group of users is within a (although >>> large) high enough range, so a range of uids is ok for us. >>> >>> generating a user-.slice file for every user (or symlink them or >>> whatever) looks a bit cumbersome, and probably not really performance >>> friendly if the range is in eg 100k (possible) uids. >>> >>> e.g. if this range was 100k-200k, i was more looking for a way to do >>> e.g. user-1X.slice or user-10:20.slice >>> >> >> As far as I know there isn't a good systemd-native method for this, but >> you can dynamically set slice parameters during PAM processing, as in this >> blog post: >> https://utcc.utoronto.ca/~cks/space/blog/linux/Ubuntu1804SystemdUserLimits >> >> -- >> Mantas Mikulėnas >> ___ >> systemd-devel mailing list >> [email protected] >> https://lists.freedesktop.org/mailman/listinfo/systemd-devel > > > ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Reasoning behind sd_bus_error argument to sd_bus_call?
Hi, I'm documenting sd_bus_call and its async variant and I was wondering about the sd_bus_error output parameter that's passed to it. Is it specifically meant for use cases where we're doing a nested D-Bus method call from a service so we have an error object to send back from the initial D-Bus method call? I don't see immediately see the benefit of the sd_bus_error parameter in a D-Bus client since I can simply check the return value instead which seems to contain the same information looking at the implementation. Regards, Daan De Meyer ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Reasoning behind sd_bus_error argument to sd_bus_call?
I completely agree that for errors returned by the service, a D-Bus error
is a lot better. However, from what I understand of sd-bus, any errors
returned by the service are encoded in the reply returned by sd_bus_call
and you use sd_bus_message_is_method_error and sd_bus_message_get_error on
the reply to get the actual service error. Where does that leave the
sd_bus_error argument of sd_bus_call? Is it simply another way to get the
error? It seems to be always be set when a local or remote error occurs,
but it can only contain information that I can get by checking the return
value of the function or by checking whether the reply object passed to
sd_bus_call contains an error.
How I would imagine using sd_bus_call:
r = sd_bus_call(..., reply, ...);
if (r < 0) {
// Local error
}
if (sd_bus_message_is_method_error(reply)) {
const sd_bus_error *error = sd_bus_message_get_error(reply);
// Service error
}
But if this is the intended usage, what's the use of the sd_bus_error
argument of sd_bus_call since the above code already handles both the local
error and the remote service error failure paths?
Daan
On Wed, 18 Mar 2020 at 11:57, Simon McVittie wrote:
> On Tue, 17 Mar 2020 at 20:17:05 +0100, Daan De Meyer wrote:
> > I'm documenting sd_bus_call and its async variant and I was wondering
> about the
> > sd_bus_error output parameter that's passed to it. [...] I don't
> > see immediately see the benefit of the sd_bus_error parameter in a D-Bus
> client
> > since I can simply check the return value instead which seems to contain
> the
> > same information looking at the implementation.
>
> The return value is a single int, which according to systemd conventions
> is probably a negative errno value. That's a lot less information than
> a D-Bus error (systemd sd_bus_error, libdbus DBusError or equivalent):
> D-Bus errors consist of a machine-readable name (namespaced by a reversed
> domain name) and a human-readable message.
>
> For the information about *whether* an error occurred, sure, you get the
> same information, but for information about *which* error occurred and why,
> a sd_bus_error is a lot better.
>
> Let's pretend your D-Bus client is interacting with a D-Bus service that
> resembles systemd-timedated. An errno value can give you, at best,
> something like this (where *** marks the part that came from the service's
> reply):
>
> my-client: Error: Unable to set time zone to America/Gotham:
> ***No such file or directory (errno 2)***
>
> whereas a D-Bus error (sd_bus_error) from a well-implemented service can
> give you something a lot more detailed. For example, after you ispect
> the sd_bus_error, you might find that the error above was either of these:
>
> my-client: Error: Unable to set time zone to America/Gotham:
> ***No time zone file for "America/Gotham" found (tried
> "/usr/share/zoneinfo/America/Gotham",
> "/usr/local/share/zoneinfo/America/Gotham")
> (error code com.example.NotTimedated.Error.NoSuchTimezone)***
>
> my-client: Error: Unable to set time zone to America/Gotham:
> ***No time zone data installed (tried "/usr/share/zoneinfo",
> "/usr/local/share/zoneinfo")
> (error code com.example.NotTimedated.Error.TzdataNotInstalled)***
>
> In this example a programmatic client would also be able
> to respond differently to the distinct machine-readable
> errors com.example.NotTimedated.Error.NoSuchTimezone and
> com.example.NotTimedated.Error.TzdataNotInstalled if it wanted to;
> for example it could respond to the second error by trying to use
> PackageKit to install tzdata, which obviously wouldn't be appropriate
> for the first error.
>
> D-Bus errors were inspired by GLib's GError, which is basically a triple
> { domain: interned string, code: int, message: string }, where the domain
> provides extensible uniqueness, and the code is a member of an enum
> determined by the domain.
>
> smcv
> ___
> systemd-devel mailing list
> [email protected]
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sd-bus signal callback return value
Hi, I've opened a pull request to clarify the return values of the callbacks and their effect: https://github.com/systemd/systemd/pull/15253. It's not complete yet but the idea is to add answers for all your questions to the docs. Regards, Daan On Tue, 24 Mar 2020 at 21:44, Stanislav Angelovič wrote: > Hi folks, > > Please, what is the difference in sd-bus behavior when my D-Bus signal > callback returns a zero return value versus a positive return value? > > And what's the difference between those return values in D-Bus method > callback, D-Bus async method reply callback, D-Bus property get callback, > and D-Bus property set callback? > > Which shall I return in normal cases? Zero? > > Thanks a lot in advance for your response... Take care & stay healthy, > > Stanislav. > > ___ > systemd-devel mailing list > [email protected] > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] GNOME boot-complete.target integration ?
Hi All, For Fedora 33 I would like to get rid of some ugly hacks we have wrt the grub-hidden-menu feature Fedora has been shipping for a while now. One part of this will be setting SYSTEMD_REBOOT_TO_BOOT_LOADER_ENTRY in logind's environment, and add /run/systemd/reboot-to-boot-loader-menu support to the Fedora grub-packages (the hidden-boot-menu stuff is not in upstream grub yet) and make GNOME use the dbus protocol to request rebooting into the boot menu. Another, harder part is boot-success or in systemd terms boot-complete support. ATM the Fedora GNOME packages contain a downstream patch which directly invokes "grub2-set-bootflag boot success". The plan is to have a grub2-bless-boot.service which will be a copy of systemd-bless-boot.service which will do grub's equivalent of calling /usr/lib/systemd/systemd-bless-boot good (we do not want automatic-boot-assesment, we just want the menu to show or not show on the next boot). This bit is east too. The tricky part is having grub2-bless-boot.service not run until GNOME says that it is ok. The thinking behind this (and current behavior) is that even if everything looks ok from the all services are running pov, then things might still be wrong. E.g. the kbd and mouse could be non-functional leaving the user with a non-functional system. So we only want to mark the boot successful after: 1. The user has logged in successfully and the session lasts at least 2 minutes (could be a bit shorter, we want to catch the case where the session immediately exits / crashes after login); or 2. The user selects reboot/shutdown from the GNOME system-control menu. In both these cases we want to block the boot-complete.target from being considered finished/ready until GNOME says it is. I can easily achieve this by not adding the grub2-bless-boot.service to any targets, and then manually starting it (with a polkit rule to allow a regular user to do this) when either condition becomes true, but then I still have the GNOME code doing something grub (Fedora's grub even) specific. So what I really want to do is delay the the boot-complete.target from being considered finished/ready until GNOME says it is. So the question really is, is there a way to have a unit wait with starting until a certain event happens? I guess I could use a Oneshot type service and have a little helper app which waits until it is signalled that the boot is complete? Any other ideas? Regards, Hans ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] GNOME boot-complete.target integration ?
Hi, On 6/30/20 11:36 AM, Lennart Poettering wrote: On Mo, 29.06.20 11:02, Hans de Goede ([email protected]) wrote: Hi All, For Fedora 33 I would like to get rid of some ugly hacks we have wrt the grub-hidden-menu feature Fedora has been shipping for a while now. One part of this will be setting SYSTEMD_REBOOT_TO_BOOT_LOADER_ENTRY in logind's environment, and add /run/systemd/reboot-to-boot-loader-menu support to the Fedora grub-packages (the hidden-boot-menu stuff is not in upstream grub yet) and make GNOME use the dbus protocol to request rebooting into the boot menu. Another, harder part is boot-success or in systemd terms boot-complete support. ATM the Fedora GNOME packages contain a downstream patch which directly invokes "grub2-set-bootflag boot success". The plan is to have a grub2-bless-boot.service which will be a copy of systemd-bless-boot.service which will do grub's equivalent of calling /usr/lib/systemd/systemd-bless-boot good (we do not want automatic-boot-assesment, we just want the menu to show or not show on the next boot). This bit is east too. The tricky part is having grub2-bless-boot.service not run until GNOME says that it is ok. The thinking behind this (and current behavior) is that even if everything looks ok from the all services are running pov, then things might still be wrong. E.g. the kbd and mouse could be non-functional leaving the user with a non-functional system. So we only want to mark the boot successful after: 1. The user has logged in successfully and the session lasts at least 2 minutes (could be a bit shorter, we want to catch the case where the session immediately exits / crashes after login); or 2. The user selects reboot/shutdown from the GNOME system-control menu. In both these cases we want to block the boot-complete.target from being considered finished/ready until GNOME says it is. I can easily achieve this by not adding the grub2-bless-boot.service to any targets, and then manually starting it (with a polkit rule to allow a regular user to do this) when either condition becomes true, but then I still have the GNOME code doing something grub (Fedora's grub even) specific. So what I really want to do is delay the the boot-complete.target from being considered finished/ready until GNOME says it is. So the question really is, is there a way to have a unit wait with starting until a certain event happens? I guess I could use a Oneshot type service and have a little helper app which waits until it is signalled that the boot is complete? Any other ideas? Why not have a tiny service that is started as part of boot. It hangs around for 2min or, and then exits with failure. If however it is contacted by D-Bus before that it exist immediately with success. Then, make GNOME just ping that service if all is good. The service would then become part of the usual boot process, ordered before the boot blessing. Wouldn#t that suffice? That will break in the following scenario: 1. User powers on the machine goes to grab coffee 2. User returns after 5 min. logs in and goes to work Notice that the contacting by DBUS you suggest would not happen until after 2, at which point the timeout has happened. Currently for "boot-success" marking we rely on confirmation of successful interaction with the user (so working gfx output + kbd + mouse) and we want to keep doing that. If we remove the timeout from your proposal then it should work fine though. So I think we agree on needing a tiny service for this, which gets contacted by the GNOME session when the GNOME session considers the boot successful. The main difference between our proposals seems to be that I want to add the service to the boot-complete.target and you suggest adding it to the usual boot process, which I assume would be multi-user.target. To me adding it to boot-complete.target feels like it makes more sense, since the whole purpose of the mini service is just to delay boot-blessing, and AFAIK that is exactly what boot-complete.target is for ? Regards, Hans ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] vt220 default for serial console still relevant?
Hi, I was playing around with mkosi's qemu support, more specifically adding the -nographic option to have the virtual machine output in my terminal instead of a separate window. After figuring out that I had to add console=ttyS0 to mkosi's kernel command line, I got the output from the vm in my terminal as expected. However, because systemd defaults to TERM=vt220 for serial consoles, the output is not colorized. I searched around a bit and found that this is done for compatibility reasons. Will there ever be a point where we can switch the default to something that supports colors (like TERM=linux)? I managed to get around the problem by overriding serial-getty@ttyS0 and setting Environment=TERM=linux explicitly but it's a bit of a pain and has to be added to every rootfs that wants to support colored output on its serial console. Cheers, Daan ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] vt220 default for serial console still relevant?
> TERM=linux means Linux console, but that's just too much, as it not > only implies a multitude of ESC sequences specific to the Linux > console, but also indicates that certain ioctls might work. In our own > code we also bind certain behaviour to TERM=linux, as indicator if we > are on the Linux console. > > I am not aware of any widely-supported TERM value that would be a > reasonable subset of all currently used terminals and does color. I did some more research and it turns out VT220 does support colors. My terminal emulator (Konsole) just doesn't seem to support it. I installed xterm (which explicitly advertises support for VT220 escape codes) and got colored output as expected. I guess this means it's up to Konsole to support more of VT220 if I want this to work seamlessly (or I switch terminals to xterm). Thanks for the extra info and context. Daan On Sat, 11 Jul 2020 at 20:04, Lennart Poettering wrote: > On Sa, 11.07.20 17:51, Daan De Meyer ([email protected]) wrote: > > > Hi, > > > > I was playing around with mkosi's qemu support, more specifically adding > > the -nographic option to have the virtual machine output in my terminal > > instead of a separate window. After figuring out that I had to add > > console=ttyS0 to mkosi's kernel command line, I got the output from the > vm > > in my terminal as expected. However, because systemd defaults to > TERM=vt220 > > for serial consoles, the output is not colorized. I searched around a bit > > and found that this is done for compatibility reasons. Will there ever > be a > > point where we can switch the default to something that supports colors > > (like TERM=linux)? > > TERM=linux means Linux console, but that's just too much, as it not > only implies a multitude of ESC sequences specific to the Linux > console, but also indicates that certain ioctls might work. In our own > code we also bind certain behaviour to TERM=linux, as indicator if we > are on the Linux console. > > I am not aware of any widely-supported TERM value that would be a > reasonable subset of all currently used terminals and does color. > > > I managed to get around the problem by overriding serial-getty@ttyS0 and > > setting Environment=TERM=linux explicitly but it's a bit of a pain and > has > > to be added to every rootfs that wants to support colored output on its > > serial console. > > Unfortunately we can't guess the right terminal, we cannot propagate > TERM=xterm or TERM=linux depending if you invoke qemu on an xterm or > from a Linux console, hence the best thing we can do is stick to a > reasonably powerful subset that is likely going to exist everywhere, > and that's vt220 right now, as noone had a better suggestion so far... > > Lennart > > -- > Lennart Poettering, Berlin > ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] vt220 default for serial console still relevant?
Nevermind that, I just forgot to remove my override file that set TERM=linux for serial-getty@ttyS0. Daan On Sat, 11 Jul 2020 at 20:31, Daan De Meyer wrote: > > TERM=linux means Linux console, but that's just too much, as it not > > only implies a multitude of ESC sequences specific to the Linux > > console, but also indicates that certain ioctls might work. In our own > > code we also bind certain behaviour to TERM=linux, as indicator if we > > are on the Linux console. > > > > I am not aware of any widely-supported TERM value that would be a > > reasonable subset of all currently used terminals and does color. > > I did some more research and it turns out VT220 does support colors. My > terminal emulator (Konsole) just doesn't seem to support it. I installed > xterm (which explicitly advertises support for VT220 escape codes) and got > colored output as expected. I guess this means it's up to Konsole to > support more of VT220 if I want this to work seamlessly (or I switch > terminals to xterm). > > Thanks for the extra info and context. > > Daan > > On Sat, 11 Jul 2020 at 20:04, Lennart Poettering > wrote: > >> On Sa, 11.07.20 17:51, Daan De Meyer ([email protected]) wrote: >> >> > Hi, >> > >> > I was playing around with mkosi's qemu support, more specifically adding >> > the -nographic option to have the virtual machine output in my terminal >> > instead of a separate window. After figuring out that I had to add >> > console=ttyS0 to mkosi's kernel command line, I got the output from the >> vm >> > in my terminal as expected. However, because systemd defaults to >> TERM=vt220 >> > for serial consoles, the output is not colorized. I searched around a >> bit >> > and found that this is done for compatibility reasons. Will there ever >> be a >> > point where we can switch the default to something that supports colors >> > (like TERM=linux)? >> >> TERM=linux means Linux console, but that's just too much, as it not >> only implies a multitude of ESC sequences specific to the Linux >> console, but also indicates that certain ioctls might work. In our own >> code we also bind certain behaviour to TERM=linux, as indicator if we >> are on the Linux console. >> >> I am not aware of any widely-supported TERM value that would be a >> reasonable subset of all currently used terminals and does color. >> >> > I managed to get around the problem by overriding serial-getty@ttyS0 >> and >> > setting Environment=TERM=linux explicitly but it's a bit of a pain and >> has >> > to be added to every rootfs that wants to support colored output on its >> > serial console. >> >> Unfortunately we can't guess the right terminal, we cannot propagate >> TERM=xterm or TERM=linux depending if you invoke qemu on an xterm or >> from a Linux console, hence the best thing we can do is stick to a >> reasonably powerful subset that is likely going to exist everywhere, >> and that's vt220 right now, as noone had a better suggestion so far... >> >> Lennart >> >> -- >> Lennart Poettering, Berlin >> > ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemctl reboot is allowed as normal user, where is this configured
Hi All, $subject is somewhat misleading, what I actually want is to make: systemctl reboot --boot-loader-menu=60 Work as a regular user (who is physically present at the console). So I looked at: /usr/share/polkit-1/actions/org.freedesktop.login1.policy, which has: Reboot the system Authentication is required to ... auth_admin_keep auth_admin_keep yes This doesexplain why "systemctl reboot" works for "active" (aka console) users. But the snippet for reboot --boot-loader-menu looks the same, but yet that is not allowed as regular user ? : Indicate to the boot loader to boot to the boot loader menu Authentication is required to ... auth_admin_keep auth_admin_keep yes org.freedesktop.login1.reboot [hans@x1 ~]$ systemctl reboot --boot-loader-menu=60 Cannot indicate to boot loader to enter boot loader entry menu: Access denied /usr/share/polkit-1/rules.d/ Does not contain any rules explaining why org.freedesktop.login1.reboot is allowed, while org.freedesktop.login1.set-reboot-to-boot-loader-menu is not allowed ? Maybe selinux ? Regards, Hans ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl reboot is allowed as normal user, where is this configured
Hi again, On 7/13/20 4:11 PM, Hans de Goede wrote: Hi All, $subject is somewhat misleading, what I actually want is to make: systemctl reboot --boot-loader-menu=60 Work as a regular user (who is physically present at the console). So I looked at: /usr/share/polkit-1/actions/org.freedesktop.login1.policy, which has: Reboot the system Authentication is required to ... auth_admin_keep auth_admin_keep yes This doesexplain why "systemctl reboot" works for "active" (aka console) users. But the snippet for reboot --boot-loader-menu looks the same, but yet that is not allowed as regular user ? : Indicate to the boot loader to boot to the boot loader menu Authentication is required to ... auth_admin_keep auth_admin_keep yes org.freedesktop.login1.reboot [hans@x1 ~]$ systemctl reboot --boot-loader-menu=60 Cannot indicate to boot loader to enter boot loader entry menu: Access denied /usr/share/polkit-1/rules.d/ Does not contain any rules explaining why org.freedesktop.login1.reboot is allowed, while org.freedesktop.login1.set-reboot-to-boot-loader-menu is not allowed ? Maybe selinux ? Answering my own question, yes of course it is selinux. I was thinking that logind was saying "Access Denied", but that is not what is happening logind is encountering a selinux denial when creating: /run/systemd/reboot-to-boot-loader-menu And is forwarding the -PERM error from that, which caused me to focus on the polkit stuff... I've filed a bug for this against Fedora's selinux policy: https://bugzilla.redhat.com/show_bug.cgi?id=1856399 Regards, Hans ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] GNOME boot-complete.target integration ?
Hi, On 7/14/20 10:03 AM, Lennart Poettering wrote: On Di, 30.06.20 12:17, Hans de Goede ([email protected]) wrote: 1. The user has logged in successfully and the session lasts at least 2 minutes (could be a bit shorter, we want to catch the case where the session immediately exits / crashes after login); or 2. The user selects reboot/shutdown from the GNOME system-control menu. In both these cases we want to block the boot-complete.target from being considered finished/ready until GNOME says it is. I can easily achieve this by not adding the grub2-bless-boot.service to any targets, and then manually starting it (with a polkit rule to allow a regular user to do this) when either condition becomes true, but then I still have the GNOME code doing something grub (Fedora's grub even) specific. So what I really want to do is delay the the boot-complete.target from being considered finished/ready until GNOME says it is. So the question really is, is there a way to have a unit wait with starting until a certain event happens? I guess I could use a Oneshot type service and have a little helper app which waits until it is signalled that the boot is complete? Any other ideas? Why not have a tiny service that is started as part of boot. It hangs around for 2min or, and then exits with failure. If however it is contacted by D-Bus before that it exist immediately with success. Then, make GNOME just ping that service if all is good. The service would then become part of the usual boot process, ordered before the boot blessing. Wouldn#t that suffice? That will break in the following scenario: 1. User powers on the machine goes to grab coffee 2. User returns after 5 min. logs in and goes to work Notice that the contacting by DBUS you suggest would not happen until after 2, at which point the timeout has happened. So on the low level we actually have a concept for marking a boot as "neutral", but I think we only expose that in sd-boot, and badly. i.e. the idea is that a boot can be considered "bad", "good" or "neutral". I guess we could model things for you so that initially the boot is marked as "bad", up to the point where gdm decides it managed to start up. In that case we'd mark things as "neutral". As soon as gdm then received user input so that the log in starts, it would mark things as "bad" again. And when GNOME in the user's session finally is done with everything we'd mark things as "good" and everything is complete. From a boot loader that boots up and finds the boot success state as "bad" it will increment the fail counter of the boot item. If it finds it as "good" it will mark the boot item as "good" forever. But if it finds it in "neutral" it will do neither. Such a logic would work for you, right? No I do not think such a logic would work for the current Fedora workstation hidden menu stuff. The good/neutral/bad way of thinking seems to be very much oriented around the automatic fallback to a previous boot-loader-menu entry (typically an older kernel, but could also be a whole other os with a/b booting). But that is not how things currently work in Fedora Workstation and also not a direction which we want to go in. Currently Fedora WS hides the boot-menu be default, we do good/bad detection to decide if need to show the menu on the next boot to give the user easy access to it (without key pounding at boot) when the previous boot as bad. That is all that is done, there is no automatic fallback and no permanently marking boot-menu-entries as bad/good. So to go to your example how this could work: 1. Early at boot something (e.g. the bootloader itself) marks the boot as bad 2. Once GDM starts mark the boot as neutral 3. Re-mark as bad before doing login If we then lack a functioning keyboard due to driver issues (which is rare but does happen), we never reach 3, the user then power-cycles to recover and we see a neutral state and this don't show the menu ? Your example could work for Fedora ws if we treat neutral the same as bad. But this whole discussion seems somewhat orthogonal to the original problem. I guess your idea behind this is to not delay the marking of neutral with some helper as discussed before and to still reach boot-complete.target once gdm starts without waiting for user input ? But then how would gdm re-mark as bad when starting to login the user and how would the user-session mark things as good, in a way that does not require root rights ? Regards, Hans ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] vt220 default for serial console still relevant?
I just tried vt241 and didn't get colorized output in konsole. I looked around a bit and it doesn't really seem supported at all by terminal emulators (or at least none that I found). I also tried TERM=xterm-256color with 8 different terminal emulators and got colors with all of them. My workflow is simply "mkosi qemu -nographic" (with a modified mkosi that adds console=ttyS0 and overrides TERM for serial-getty@ttyS0 in the vm)." That connects my terminal emulator to the serial console of the vm. I then execute "ls -l --color /" in the vm and get colored output every time in whatever terminal emulator that I try. I'm probably missing something but I'm wondering what an example terminal emulator would be where xterm-256color would not work at all (even st worked perfectly and that is supposed to be pretty barebones afaik). Or is it just that color is a commonly supported subset of xterm and stuff breaks down with other escape codes instead? Or maybe qemu is doing some kind of translation that magically makes every TERM setting work in whatever terminal emulator I try? Apologies if this seems ignorant, I have no experience at all with this domain. Daan On Tue, 14 Jul 2020 at 18:22, Christopher Cox wrote: > On 7/14/20 3:19 AM, Lennart Poettering wrote: > > On Mo, 13.07.20 18:16, Christopher Cox ([email protected]) wrote: > > > >>> No vt220 does not support colour. I used to work on one and it is > >>> monochrome hardware. > >>> Xterm and konsole support extensions beyond vt220 that add in the > colour support. > >> > >> Not sure how much (offtopic) history we want to get into. I used the > VT240 > >> in my college graphics class. The VT241 was the color variant. > >> > >> See: http://terminals-wiki.org/wiki/index.php/DEC_VT240 > >> > >> I still meet programmers what hard code ansi sequences rather than > querying > >> termcap/terminfo. You know what they say about those who "assume". > > > > Hmm, if vt241 is a bettre featured terminal type, and both xterm and > > the Linux console a superset of it, and the terminal widely available > > in termcaps and stuff we can certainly change our default TERM to be > > vt241. > > > > Daan, if this all is the case, could you prep a PR? > > I would think shooting for something low is actually good. Let the > individual > configure for something "better". > > I'm not sure I'm ready to say monochrome is obsolete. There can be beauty > in > simplicity and function. My preference, aim low, and allow easy > configuration > upward. You could take the opposite stance of course, it's just that it > could > cause some frustration. > > Just my opinion though. I'm old and I think about a lot of things like > terminals, "proxies" and callback modems... things of value, but most do > not > understand or care about anymore. > > > ___ > systemd-devel mailing list > [email protected] > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] vt220 default for serial console still relevant?
> About your other comments, systemd sits in user space and can query (depend > upon) terminfo. Then, it should be able to support "whatever" terminfo has > defined which could include custom terminals by the way that an end user has > added. And while all of that sounds incredibly ancient/old, I was on a project > post 2000 that had to do exactly that (of course, even that might sound too old). Interestingly enough, systemd's colors work even when TERM is set to vt220, probably because it uses ansi escape codes regardless of the TERM setting. I think there's probably lots of applications doing this except for ls in coreutils which has an explicit list of terminals with color support encoded in the dircolors configuration file. If TERM isn't one of those, you don't get colors. There's probably others that do this as well. I don't think changing the default in systemd is a good idea since it might break other stuff. I'm going to submit a mkosi PR instead that adds an option that overrides serial-getty@ttyS0 with whatever terminal the user wants. Colors won't work out of the box but at least it shouldn't be too hard to find out how to get them to work when using mkosi. Thanks for all the info as well. It's always fun to read how stuff was done back in the early days. Daan On Tue, 14 Jul 2020 at 21:04, Christopher Cox wrote: > On 7/14/20 1:48 PM, Daan De Meyer wrote: > > I just tried vt241 and didn't get colorized output in konsole. I looked > around a > > bit and it doesn't really seem supported at all by terminal emulators > (or at > > least none that I found). I also tried TERM=xterm-256color with 8 > different > > terminal emulators and got colors with all of them. My workflow is > simply "mkosi > > qemu -nographic" (with a modified mkosi that adds console=ttyS0 and > overrides > > TERM for serial-getty@ttyS0 in the vm)." That connects my terminal > emulator to > > the serial console of the vm. I then execute "ls -l --color /" in the vm > and get > > colored output every time in whatever terminal emulator that I try. > > > > I'm probably missing something but I'm wondering what an example > terminal > > emulator would be where xterm-256color would not work at all (even st > worked > > perfectly and that is supposed to be pretty barebones afaik). Or is it > just that > > color is a commonly supported subset of xterm and stuff breaks down with > other > > escape codes instead? Or maybe qemu is doing some kind of translation > that > > magically makes every TERM setting work in whatever terminal emulator I > try? > > Apologies if this seems ignorant, I have no experience at all with this > domain. > > So, some info (not necessarily direction). Old guys like to talk... > > So, speaking of things of old, but not ancient old, when handling server > equipment via serial, you normally do three things. You route the BIOS > (legacy) > out the serial port, you send the kernel boot messages out the serial port > and > you establish a getty for login on the serial port. > > Just being honest, the "server world" decided everything was Microsoft > Hyperterminal (up to Windows XP, what many considered to be "ansi", 80x25) > during the PC revolution. > > So.. Windows doesn't come with Hyperterminal anymore, which makes sense > since > PCs in general don't have serial ports (apart from USB-serial dongles). > > So, can you, or should you adopt a serial console solution (ansi, 80x25)? > IMHO, > this is still interesting. Especially in the Linux world. Consider that > network equipment still speaks serial for console, the concept (still, > even > though this in a old concept) of using, for example, ssh to serial console > controllers for full out of band access might still be appealing. > > Why? Well, for many reasons. Cabling is much less (that is, less dense) > as you > can use flat velum for quite some distance for serial. Since you're > having to > somehow deal with network devices anyway, by have all done serially, you > have > "one stop" shopping for out of band (more on this in a bit) console access. > > Bonus, no high cost of licensing, for example, iLO or iDrac ent. But > noting > that you don't get virtual media with a serial console head solution > either. > > But still, if running remote facilities and you need true out of band, and > by > that I mean the ability to reconfigure everything, including the network, > it > could be just the thing you need. > > But ssh? Network reconfigure? That's not going to work. Often times > those same > s
Re: [systemd-devel] vt220 default for serial console still relevant?
> Well, --color means you request color no matter what, so this is not surprising. I actually only got color because TERM was set to xterm-256color. ls won't output color if TERM is set to vt220. It checks against a hardcoded list of terminals to determine whether it'll output colors or not. See https://github.com/coreutils/coreutils/blob/6a3d2883fed853ee01079477020091068074e12d/src/dircolors.hin > Again, I'd be happy to switch to a different default for serial > terminals if we can find a reasonable one that is available widely in > termcap, that does color, and is a subset of both TERM=linux and > TERM=xterm. So the vt220 was the first of the vt200 series and was a black and white terminal. The vt241 was the model in that series that added colors. Problem is that the vt241 is not in my terminfo database. The other problem is that vt241 is not actually in ls's list of terminals that it should output colors for so using that one is probably not a good idea. What would work is vt100 since for some weird reason that one is in ls's list of terminals with colors even though https://invisible-island.net/ncurses/ncurses.faq.html#vt100_color explicitly says the vt100 does not support colors. Switching to vt100 would break pageup/pagedown however so that's not really an option either. I didn't find any other alternatives that seemed viable. I suppose I could make a coreutils PR that adds vt220 to the list of terminals that support colors. vt100 is already in there and it doesn't support colors so who knows maybe they'll add vt220 as well for the pragmatic reason that systemd can't use anything else but it would still be nice to have colors out of the box. I don't think that's likely to be accepted though and it only fixes ls and not programs like ncurses which adhere to whatever's in the terminfo database. For now, the pragmatic solution for my use case (mkosi test VMs that only I will ever use) is to simply make it easy to override TERM in the VM to whatever TERM is in my host terminal via mkosi. Daan On Wed, 15 Jul 2020 at 17:09, Lennart Poettering wrote: > On Di, 14.07.20 22:15, Daan De Meyer ([email protected]) wrote: > > > > About your other comments, systemd sits in user space and can query > > (depend > > > upon) terminfo. Then, it should be able to support "whatever" terminfo > > has > > > defined which could include custom terminals by the way that an end > > user has > > > added. And while all of that sounds incredibly ancient/old, I was on a > > project > > > post 2000 that had to do exactly that (of course, even that might sound > > too old). > > > > Interestingly enough, systemd's colors work even when TERM is set to > vt220, > > probably because it uses ansi escape codes regardless of the TERM > setting. > > I think there's probably lots of applications doing this except for ls in > > coreutils which has an explicit list of terminals with color support > > encoded in the dircolors configuration file. If TERM isn't one of those, > > you don't get colors. There's probably others that do this as well. I > don't > > think changing the default in systemd is a good idea since it might break > > other stuff. I'm going to submit a mkosi PR instead that adds an option > > that overrides serial-getty@ttyS0 with whatever terminal the user wants. > > Colors won't work out of the box but at least it shouldn't be too hard to > > find out how to get them to work when using mkosi. > > Again, I'd be happy to switch to a different default for serial > terminals if we can find a reasonable one that is available widely in > termcap, that does color, and is a subset of both TERM=linux and > TERM=xterm. > > Lennart > > -- > Lennart Poettering, Berlin > ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Shut down system after all sshd instances terminate
Hi, After following http://0pointer.de/blog/projects/socket-activated-containers.html which details how to set up a socket activated container, I'm looking into ways to have the container automatically shut down when the last ssh connection terminates. My idea was to have each sshd instance take an inhibitor lock (the blocking kind) that prevents poweroff and make each sshd instance pull in poweroff.target. The problem is that the inhibitor documentation mentions that poweroff operations will fail if a blocking inhibitor lock is taken. For this to work, I need poweroff.target to wait indefinitely until all locks are released. Is this possible at the moment? Any other suggestions on how to achieve this are appreciated as well. Cheers, Daan ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Shut down system after all sshd instances terminate
Nvm, that wouldn't work at all because inhibitor locks are ignored if the user is privileged enough. So getting the system to shut down after an sshd instance exits is easy enough with SuccessAction. Waiting for all sshd instances to finish before shutting down turns out to be extremely hard. I've been trying out stuff for multiple hours now and haven't come even close. There definitely seems to be at least a documentation issue here so if there's a solution I intend to make a PR that clarifies this somewhere in the official documentation. My last (failed) attempt is this ([email protected]) : ``` [Unit] Description=SSH Server for {args.devserver_name} devserver After=network.target After=exit.target [Service] ExecStart=/usr/sbin/sshd -i KillMode=none TimeoutStopSec=infinity StandardInput=socket SuccessAction=exit FailureAction=exit ``` When an ssh connection comes in, an instance of this template is started to handle the connection. Now, what I want to achieve is that when all instances of this sshd template exit after at least one instance has started, the system shuts down. Daan On Sun, 23 Aug 2020 at 14:47, Daan De Meyer wrote: > > Hi, > > After following > http://0pointer.de/blog/projects/socket-activated-containers.html > which details how to set up a socket activated container, I'm looking > into ways to have the container automatically shut down when the last > ssh connection terminates. > > My idea was to have each sshd instance take an inhibitor lock (the > blocking kind) that prevents poweroff and make each sshd instance pull > in poweroff.target. The problem is that the inhibitor documentation > mentions that poweroff operations will fail if a blocking inhibitor > lock is taken. For this to work, I need poweroff.target to wait > indefinitely until all locks are released. Is this possible at the > moment? > > Any other suggestions on how to achieve this are appreciated as well. > > Cheers, > > Daan ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Shut down system after all sshd instances terminate
That works! Thanks so much for the quick response.
I still feel it's a bit unintuitive though. I did find multiple open
issues asking for inhibitors that work with root as well. I think that
would be necessary for an intuitive solution.
Ideally, the following unit file would work:
```
[Unit]
Description=SSH Server for {args.devserver_name} devserver
After=network.target
After=exit.target
[Service]
ExecStart=/usr/sbin/sshd -i
StandardInput=socket
SuccessAction=exit
FailureAction=exit
Inhibit=exit:delay
InhibitDelaySec=infinite
```
This would tell systemd to start a normal exit when the first instance
exits. The Inhibit options tell systemd to delay exit infinitely if
any instance is still running.
For now, your solution is a great alternative.
Daan
On Sun, 23 Aug 2020 at 16:13, Benjamin Berg wrote:
>
> Hi,
>
> you can use Wants= to pull in another service, and then use
> StopWhenUnneeded= to make that shutdown after the last [email protected]
> disappears.
>
> So, I guess something like the below:
>
> [email protected] drop-in:
> ```
> [Unit]
> Wants=sshd-running.service
> ```
>
> sshd-running.service
> ```
> [Unit]
> StopWhenUnneeded=true
>
> [Service]
> Type=oneshot
> RemainAfterExit=yes
>
> # Not sure if SuccessAction works
> # probably does but you might need a dummy ExecStart=/sbin/true then
> ExecStop=systemctl poweroff
> #SuccessAction=exit
> ```
>
> Benjamin
>
> On Sun, 2020-08-23 at 16:02 +0100, Daan De Meyer wrote:
> > Nvm, that wouldn't work at all because inhibitor locks are ignored if
> > the user is privileged enough.
> >
> > So getting the system to shut down after an sshd instance exits is
> > easy enough with SuccessAction. Waiting for all sshd instances to
> > finish before shutting down turns out to be extremely hard. I've been
> > trying out stuff for multiple hours now and haven't come even close.
> > There definitely seems to be at least a documentation issue here so
> > if
> > there's a solution I intend to make a PR that clarifies this
> > somewhere
> > in the official documentation.
> >
> > My last (failed) attempt is this ([email protected]) :
> >
> > ```
> > [Unit]
> > Description=SSH Server for {args.devserver_name} devserver
> > After=network.target
> > After=exit.target
> >
> > [Service]
> > ExecStart=/usr/sbin/sshd -i
> > KillMode=none
> > TimeoutStopSec=infinity
> > StandardInput=socket
> > SuccessAction=exit
> > FailureAction=exit
> > ```
> >
> > When an ssh connection comes in, an instance of this template is
> > started to handle the connection. Now, what I want to achieve is that
> > when all instances of this sshd template exit after at least one
> > instance has started, the system shuts down.
> >
> > Daan
> >
> > On Sun, 23 Aug 2020 at 14:47, Daan De Meyer > > wrote:
> > > Hi,
> > >
> > > After following
> > > http://0pointer.de/blog/projects/socket-activated-containers.html
> > > which details how to set up a socket activated container, I'm
> > > looking
> > > into ways to have the container automatically shut down when the
> > > last
> > > ssh connection terminates.
> > >
> > > My idea was to have each sshd instance take an inhibitor lock (the
> > > blocking kind) that prevents poweroff and make each sshd instance
> > > pull
> > > in poweroff.target. The problem is that the inhibitor documentation
> > > mentions that poweroff operations will fail if a blocking inhibitor
> > > lock is taken. For this to work, I need poweroff.target to wait
> > > indefinitely until all locks are released. Is this possible at the
> > > moment?
> > >
> > > Any other suggestions on how to achieve this are appreciated as
> > > well.
> > >
> > > Cheers,
> > >
> > > Daan
> > ___
> > systemd-devel mailing list
> > [email protected]
> > https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> >
___
systemd-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] mkosi question: third party repos + dnf modules
Hi, --repositories in mkosi is currently a bit limited. For Fedora and CentOS, we only support passing names of existing repositories that should be enabled. https://github.com/systemd/mkosi/issues/536 reported a similar problem. We should definitely make this work better than it does now but it's going to require a bit of thinking on how to properly support this in a way that works for all major supported distros. For now, I think postinst is the best solution. Cheers, Daan On Mon, 7 Dec 2020 at 10:28, Colin Guthrie wrote: > > Hiya, > > Trying to create some CentOS 8 images with mkosi 8 > > Is it possible to use the --repositories argument to mkosi to enable a > third party repository? If so can you tell me the secret syntax? > > I've tried: > > --repositories=https:///mirrorlist > --repositories=https:///directlink > > both say: unknown repo > > > I've tried copying in the appropriate *.repo files via > mkosi.skeleton/etc/yum.repos.d/*.repo and then referring to the repo by > name rather than URL and it doesn't work either (also tried full path > within container and file:// prefixed path) with the same unknown repo > error. > > > I know I could do this with a postinst script but I feel like this > should be possible via the --repositories argument! > > (NB, I'm actually using Repositories= in the [Distribution] section of > an mkosi.default file rather than the command line directly but this > /shouldn't/ make a difference!] > > The next question is: can we setup dnf modules as part of the initial > install? If not, then I'll likely have to go down the postinst route > anyway in this case, but the above is still interesting for e.g. custom > COPR repos etc. > > Cheers > > Col > > ___ > systemd-devel mailing list > [email protected] > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [usb-storage] Re: Amazon Kindle disconnect after Synchronize Cache
Hi,
On 3/16/21 5:26 PM, Alan Stern wrote:
> On Tue, Mar 16, 2021 at 06:26:30AM +0100, Matthias Schwarzott wrote:
>> I implemented solution 3b. This is the pullrequest for udev (systemd
>> repository):
>>
>> https://github.com/systemd/systemd/pull/19002
>>
>> Now Lennart asks if udev is the best place for such hacks/work-arounds?
>>
>> Well, I implemented it as suggested by Alan (see above). This was the
>> simplest of the considered alternatives. Different quirks in kernel has been
>> considered, but are more effort to be implemented.
>
> Lennart probably isn't aware how the usb-storage driver works. It does
> not create commands on its own; it merely sends the commands that it
> gets from higher SCSI layers.
>
> It may be possible to modify the SCSI core, to make it send a TEST UNIT
> READY command immediately following any SYNCHRONIZE CACHE to a Kindle.
>
> However, there may be an easier solution. usb-storage does indeed send
> a command of its own, REQUEST SENSE, to get error data when a command
> fails. The patch below will make it do the same thing whenever it sends
> a SYNCHRONIZE CACHE to a Kindle, failure or not.
>
> The only question is whether the Kindle will regard REQUEST SENSE as a
> sufficient indication that it shouldn't do an eject. The only way to
> find out is by testing the patch.
>
> Alan Stern
Thank you for this patch, yes if this works it would IMHO be
a much better solution then the udev rule.
One question though, if this works to fix the undesired ejects,
will an actual eject (using e.g. the eject utility as say
"sudo eject /dev/sda") still be seen as an eject by the kindle
after this ?
Because that is actually kind of important for everyone using their
Kindle with Calibre, breaking that would not be good.
Regards,
Hans
>
>
>
> Index: usb-devel/drivers/usb/storage/transport.c
> ===
> --- usb-devel.orig/drivers/usb/storage/transport.c
> +++ usb-devel/drivers/usb/storage/transport.c
> @@ -656,6 +656,13 @@ void usb_stor_invoke_transport(struct sc
> need_auto_sense = 1;
> }
>
> + /* Some devices (Kindle) require another command after SYNC CACHE */
> + if (us->fflags & US_FL_CHECK_AFTER_SYNC &&
> + srb->cmnd[0] == SYNCHRONIZE_CACHE) {
> + usb_stor_dbg(us, "-- sense after SYNC CACHE\n");
> + need_auto_sense = 1;
> + }
> +
> /*
>* If we have a failure, we're going to do a REQUEST_SENSE
>* automatically. Note that we differentiate between a command
> Index: usb-devel/drivers/usb/storage/unusual_devs.h
> ===
> --- usb-devel.orig/drivers/usb/storage/unusual_devs.h
> +++ usb-devel/drivers/usb/storage/unusual_devs.h
> @@ -2212,6 +2212,18 @@ UNUSUAL_DEV( 0x1908, 0x3335, 0x0200, 0x0
> US_FL_NO_READ_DISC_INFO ),
>
> /*
> + * Reported by Matthias Schwarzott
> + * The Amazon Kindle treats SYNCHRONIZE CACHE as an indication that
> + * the host may be finished with it, and automatically ejects its
> + * media unless it receives another command within one second.
> + */
> +UNUSUAL_DEV( 0x1949, 0x0004, 0x, 0x,
> + "Amazon",
> + "Kindle",
> + USB_SC_DEVICE, USB_PR_DEVICE, NULL,
> + US_FL_CHECK_AFTER_SYNC ),
> +
> +/*
> * Reported by Oliver Neukum
> * This device morphes spontaneously into another device if the access
> * pattern of Windows isn't followed. Thus writable media would be dirty
> Index: usb-devel/include/linux/usb_usual.h
> ===
> --- usb-devel.orig/include/linux/usb_usual.h
> +++ usb-devel/include/linux/usb_usual.h
> @@ -86,6 +86,8 @@
> /* lies about caching, so always sync */\
> US_FLAG(NO_SAME, 0x4000)\
> /* Cannot handle WRITE_SAME */ \
> + US_FLAG(CHECK_AFTER_SYNC, 0x8000) \
> + /* Check sense after SYNCHRONIZE_CACHE */ \
>
> #define US_FLAG(name, value) US_FL_##name = value ,
> enum { US_DO_ALL_FLAGS };
> ___
> systemd-devel mailing list
> [email protected]
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [usb-storage] Re: Amazon Kindle disconnect after Synchronize Cache
Hi, On 3/16/21 6:04 PM, Alan Stern wrote: > On Tue, Mar 16, 2021 at 05:43:34PM +0100, Hans de Goede wrote: >> Hi, >> >> On 3/16/21 5:26 PM, Alan Stern wrote: >>> On Tue, Mar 16, 2021 at 06:26:30AM +0100, Matthias Schwarzott wrote: >>>> I implemented solution 3b. This is the pullrequest for udev (systemd >>>> repository): >>>> >>>>https://github.com/systemd/systemd/pull/19002 >>>> >>>> Now Lennart asks if udev is the best place for such hacks/work-arounds? >>>> >>>> Well, I implemented it as suggested by Alan (see above). This was the >>>> simplest of the considered alternatives. Different quirks in kernel has >>>> been >>>> considered, but are more effort to be implemented. >>> >>> Lennart probably isn't aware how the usb-storage driver works. It does >>> not create commands on its own; it merely sends the commands that it >>> gets from higher SCSI layers. >>> >>> It may be possible to modify the SCSI core, to make it send a TEST UNIT >>> READY command immediately following any SYNCHRONIZE CACHE to a Kindle. >>> >>> However, there may be an easier solution. usb-storage does indeed send >>> a command of its own, REQUEST SENSE, to get error data when a command >>> fails. The patch below will make it do the same thing whenever it sends >>> a SYNCHRONIZE CACHE to a Kindle, failure or not. >>> >>> The only question is whether the Kindle will regard REQUEST SENSE as a >>> sufficient indication that it shouldn't do an eject. The only way to >>> find out is by testing the patch. >>> >>> Alan Stern >> >> Thank you for this patch, yes if this works it would IMHO be >> a much better solution then the udev rule. > > I think it would be mildly better, but not a whole lot. Since the > Kindle describes itself as having removable media, the kernel normally > probes it periodically to make sure the media remains present. The > default probing interval is 2 seconds. Reducing it to 0.9 seconds > doesn't represent an exorbitant additional load IMO -- especially since > Kindles don't tend to spend huge amounts of time connected to computers. Ah, I did not know that the default polling interval was that low(ish), given that the default indeed is already that low, then changing it to 0.8 seconds would not be a big change. And we probably have a lot of lower hanging fruit for unnecessary wakeups then that. Regards, Hans ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [usb-storage] Re: Amazon Kindle disconnect after Synchronize Cache
Hi, On 3/17/21 6:56 PM, Matthias Schwarzott wrote: > Am 17.03.21 um 16:17 schrieb Alan Stern: >> On Wed, Mar 17, 2021 at 01:21:50PM +0100, Hans de Goede wrote: >>> Hi, >>> >>> On 3/16/21 6:04 PM, Alan Stern wrote: >>>> I think it would be mildly better, but not a whole lot. Since the >>>> Kindle describes itself as having removable media, the kernel normally >>>> probes it periodically to make sure the media remains present. The >>>> default probing interval is 2 seconds. Reducing it to 0.9 seconds >>>> doesn't represent an exorbitant additional load IMO -- especially since >>>> Kindles don't tend to spend huge amounts of time connected to computers. >>> >>> Ah, I did not know that the default polling interval was that low(ish), >>> given that the default indeed is already that low, then changing it to >>> 0.8 seconds would not be a big change. And we probably have a lot of >>> lower hanging fruit for unnecessary wakeups then that. >> >> So we need to make a decision: Should the patch be merged, or should we >> punt the issue to userspace tools? >> >> On the plus side, the patch is rather small and non-invasive (although >> it does allocate the last remaining bit in the 32-bit fflags field). >> There's also the advantage of sending the extra command only when it is >> needed, as opposed to increasing the overall frequency of TUR polling. >> >> Any opinions? > > I would vote to do in kernel as that is a cleaner solution: > > 1. It will work out of the box. > 2. It only sends one extra command when needed. > 3. It makes the block-device not break if user-space adjusts the poll > interval to higher values. FWIW my vote goes to the in kernel fix too. Regards, Hans ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] usb-storage: Add quirk to defeat Kindle's automatic unload
Hi,
On 3/17/21 8:06 PM, Alan Stern wrote:
> Matthias reports that the Amazon Kindle automatically removes its
> emulated media if it doesn't receive another SCSI command within about
> one second after a SYNCHRONIZE CACHE. It does so even when the host
> has sent a PREVENT MEDIUM REMOVAL command. The reason for this
> behavior isn't clear, although it's not hard to make some guesses.
>
> At any rate, the results can be unexpected for anyone who tries to
> access the Kindle in an unusual fashion, and in theory they can lead
> to data loss (for example, if one file is closed and synchronized
> while other files are still in the middle of being written).
>
> To avoid such problems, this patch creates a new usb-storage quirks
> flag telling the driver always to issue a REQUEST SENSE following a
> SYNCHRONIZE CACHE command, and adds an unusual_devs entry for the
> Kindle with the flag set. This is sufficient to prevent the Kindle
> from doing its automatic unload, without interfering with proper
> operation.
>
> Another possible way to deal with this would be to increase the
> frequency of TEST UNIT READY polling that the kernel normally carries
> out for removable-media storage devices. However that would increase
> the overall load on the system and it is not as reliable, because the
> user can override the polling interval. Changing the driver's
> behavior is safer and has minimal overhead.
>
> Reported-and-tested-by: Matthias Schwarzott
> Signed-off-by: Alan Stern
> CC:
Thanks, patch looks good to me:
Reviewed-by: Hans de Goede
Regards,
Hans
>
> ---
>
>
> [as1953]
>
>
> drivers/usb/storage/transport.c|7 +++
> drivers/usb/storage/unusual_devs.h | 12
> include/linux/usb_usual.h |2 ++
> 3 files changed, 21 insertions(+)
>
> Index: usb-devel/drivers/usb/storage/transport.c
> ===
> --- usb-devel.orig/drivers/usb/storage/transport.c
> +++ usb-devel/drivers/usb/storage/transport.c
> @@ -656,6 +656,13 @@ void usb_stor_invoke_transport(struct sc
> need_auto_sense = 1;
> }
>
> + /* Some devices (Kindle) require another command after SYNC CACHE */
> + if ((us->fflags & US_FL_SENSE_AFTER_SYNC) &&
> + srb->cmnd[0] == SYNCHRONIZE_CACHE) {
> + usb_stor_dbg(us, "-- sense after SYNC CACHE\n");
> + need_auto_sense = 1;
> + }
> +
> /*
>* If we have a failure, we're going to do a REQUEST_SENSE
>* automatically. Note that we differentiate between a command
> Index: usb-devel/drivers/usb/storage/unusual_devs.h
> ===
> --- usb-devel.orig/drivers/usb/storage/unusual_devs.h
> +++ usb-devel/drivers/usb/storage/unusual_devs.h
> @@ -2212,6 +2212,18 @@ UNUSUAL_DEV( 0x1908, 0x3335, 0x0200, 0x0
> US_FL_NO_READ_DISC_INFO ),
>
> /*
> + * Reported by Matthias Schwarzott
> + * The Amazon Kindle treats SYNCHRONIZE CACHE as an indication that
> + * the host may be finished with it, and automatically ejects its
> + * emulated media unless it receives another command within one second.
> + */
> +UNUSUAL_DEV( 0x1949, 0x0004, 0x, 0x,
> + "Amazon",
> + "Kindle",
> + USB_SC_DEVICE, USB_PR_DEVICE, NULL,
> + US_FL_SENSE_AFTER_SYNC ),
> +
> +/*
> * Reported by Oliver Neukum
> * This device morphes spontaneously into another device if the access
> * pattern of Windows isn't followed. Thus writable media would be dirty
> Index: usb-devel/include/linux/usb_usual.h
> ===
> --- usb-devel.orig/include/linux/usb_usual.h
> +++ usb-devel/include/linux/usb_usual.h
> @@ -86,6 +86,8 @@
> /* lies about caching, so always sync */\
> US_FLAG(NO_SAME, 0x4000)\
> /* Cannot handle WRITE_SAME */ \
> + US_FLAG(SENSE_AFTER_SYNC, 0x8000) \
> + /* Do REQUEST_SENSE after SYNCHRONIZE_CACHE */ \
>
> #define US_FLAG(name, value) US_FL_##name = value ,
> enum { US_DO_ALL_FLAGS };
>
___
systemd-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Fwd / FYI: [PATCH kernel] firmware/dmi: Move product_sku info to the end of the modalias
Hi, I BCc-ed systemd-devel on this, to avoid reply-to-all from kernel folks getting bounces because of them not being subscribed, but it seems the list does not like being in the BCc, so hence this forward. Note this is just FYI, as mentioned I'll also prepare a systemd pull-req (also) fixing this on the systemd/hwdb side. Regards, Hans Forwarded Message Subject: [PATCH regression fix] firmware/dmi: Move product_sku info to the end of the modalias Date: Tue, 31 Aug 2021 15:05:08 +0200 From: Hans de Goede To: Jean Delvare CC: Hans de Goede , [email protected], [email protected], Kai-Chuan Hsieh , Erwan Velu Commit e26f023e01ef ("firmware/dmi: Include product_sku info to modalias") added a new field to the modalias in the middle of the modalias, breaking some existing udev/hwdb matches on the whole modalias without a wildcard ('*') in between the pvr and rvn fields. All modalias matches in e.g. : https://github.com/systemd/systemd/blob/main/hwdb.d/60-sensor.hwdb deliberately end in ':*' so that new fields can be added at *the end* of the modalias, but adding a new field in the middle like this breaks things. Move the new sku field to the end of the modalias to fix some hwdb entries no longer matching. The new sku field has already been put to use in 2 new hwdb entries: sensor:modalias:platform:HID-SENSOR-200073:dmi:*svnDell*:sku0A3E:* ACCEL_LOCATION=base sensor:modalias:platform:HID-SENSOR-200073:dmi:*svnDell*:sku0B0B:* ACCEL_LOCATION=base The wildcard use before and after the sku in these matches means that they should keep working with the sku moved to the end. Note that there is a second instance of in essence the same problem, commit f5152f4ded3c ("firmware/dmi: Report DMI Bios & EC firmware release") Added 2 new br and efr fields in the middle of the modalias. This too breaks some hwdb modalias matches, but this has gone unnoticed for over a year. So some newer hwdb modalias matches actually depend on these fields being in the middle of the string. Moving these to the end now would break 3 hwdb entries, while fixing 8 entries. Since there is no good answer for the new br and efr fields I have chosen to leave these as is. Instead I'll submit a hwdb update to put a wildcard at the place where these fields may or may not be present depending on the kernel version. BugLink: https://github.com/systemd/systemd/issues/20550 Link: https://github.com/systemd/systemd/pull/20562 Fixes: e26f023e01ef ("firmware/dmi: Include product_sku info to modalias") Cc: [email protected] Cc: Kai-Chuan Hsieh Cc: Erwan Velu Signed-off-by: Hans de Goede --- drivers/firmware/dmi-id.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/firmware/dmi-id.c b/drivers/firmware/dmi-id.c index 4d5421d14a41..940ddf916202 100644 --- a/drivers/firmware/dmi-id.c +++ b/drivers/firmware/dmi-id.c @@ -73,6 +73,10 @@ static void ascii_filter(char *d, const char *s) static ssize_t get_modalias(char *buffer, size_t buffer_size) { + /* +* Note new fields need to be added at the end to keep compatibility +* with udev's hwdb which does matches on "`cat dmi/id/modalias`*". +*/ static const struct mafield { const char *prefix; int field; @@ -85,13 +89,13 @@ static ssize_t get_modalias(char *buffer, size_t buffer_size) { "svn", DMI_SYS_VENDOR }, { "pn", DMI_PRODUCT_NAME }, { "pvr", DMI_PRODUCT_VERSION }, - { "sku", DMI_PRODUCT_SKU }, { "rvn", DMI_BOARD_VENDOR }, { "rn", DMI_BOARD_NAME }, { "rvr", DMI_BOARD_VERSION }, { "cvn", DMI_CHASSIS_VENDOR }, { "ct", DMI_CHASSIS_TYPE }, { "cvr", DMI_CHASSIS_VERSION }, + { "sku", DMI_PRODUCT_SKU }, { NULL, DMI_NONE } }; -- 2.31.1
[systemd-devel] [PATCH regression fix] firmware/dmi: Move product_sku info to the end of the modalias
Commit e26f023e01ef ("firmware/dmi: Include product_sku info to modalias")
added a new field to the modalias in the middle of the modalias, breaking
some existing udev/hwdb matches on the whole modalias without a wildcard
('*') in between the pvr and rvn fields.
All modalias matches in e.g. :
https://github.com/systemd/systemd/blob/main/hwdb.d/60-sensor.hwdb
deliberately end in ':*' so that new fields can be added at *the end* of
the modalias, but adding a new field in the middle like this breaks things.
Move the new sku field to the end of the modalias to fix some hwdb
entries no longer matching.
The new sku field has already been put to use in 2 new hwdb entries:
sensor:modalias:platform:HID-SENSOR-200073:dmi:*svnDell*:sku0A3E:*
ACCEL_LOCATION=base
sensor:modalias:platform:HID-SENSOR-200073:dmi:*svnDell*:sku0B0B:*
ACCEL_LOCATION=base
The wildcard use before and after the sku in these matches means that they
should keep working with the sku moved to the end.
Note that there is a second instance of in essence the same problem,
commit f5152f4ded3c ("firmware/dmi: Report DMI Bios & EC firmware release")
Added 2 new br and efr fields in the middle of the modalias. This too
breaks some hwdb modalias matches, but this has gone unnoticed for over
a year. So some newer hwdb modalias matches actually depend on these
fields being in the middle of the string. Moving these to the end now
would break 3 hwdb entries, while fixing 8 entries.
Since there is no good answer for the new br and efr fields I have chosen
to leave these as is. Instead I'll submit a hwdb update to put a wildcard
at the place where these fields may or may not be present depending on the
kernel version.
BugLink: https://github.com/systemd/systemd/issues/20550
Link: https://github.com/systemd/systemd/pull/20562
Fixes: e26f023e01ef ("firmware/dmi: Include product_sku info to modalias")
Cc: [email protected]
Cc: Kai-Chuan Hsieh
Cc: Erwan Velu
Signed-off-by: Hans de Goede
---
drivers/firmware/dmi-id.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/dmi-id.c b/drivers/firmware/dmi-id.c
index 4d5421d14a41..940ddf916202 100644
--- a/drivers/firmware/dmi-id.c
+++ b/drivers/firmware/dmi-id.c
@@ -73,6 +73,10 @@ static void ascii_filter(char *d, const char *s)
static ssize_t get_modalias(char *buffer, size_t buffer_size)
{
+ /*
+* Note new fields need to be added at the end to keep compatibility
+* with udev's hwdb which does matches on "`cat dmi/id/modalias`*".
+*/
static const struct mafield {
const char *prefix;
int field;
@@ -85,13 +89,13 @@ static ssize_t get_modalias(char *buffer, size_t
buffer_size)
{ "svn", DMI_SYS_VENDOR },
{ "pn", DMI_PRODUCT_NAME },
{ "pvr", DMI_PRODUCT_VERSION },
- { "sku", DMI_PRODUCT_SKU },
{ "rvn", DMI_BOARD_VENDOR },
{ "rn", DMI_BOARD_NAME },
{ "rvr", DMI_BOARD_VERSION },
{ "cvn", DMI_CHASSIS_VENDOR },
{ "ct", DMI_CHASSIS_TYPE },
{ "cvr", DMI_CHASSIS_VERSION },
+ { "sku", DMI_PRODUCT_SKU },
{ NULL, DMI_NONE }
};
--
2.31.1
Re: [systemd-devel] Fwd / FYI: [PATCH kernel] firmware/dmi: Move product_sku info to the end of the modalias
Hi, On 8/31/21 3:08 PM, Hans de Goede wrote: > Hi, > > I BCc-ed systemd-devel on this, to avoid reply-to-all from kernel folks > getting bounces because of them not being subscribed, but it seems the > list does not like being in the BCc, so hence this forward. > > Note this is just FYI, as mentioned I'll also prepare a systemd pull-req > (also) fixing this on the systemd/hwdb side. > > Regards, > > Hans > > > Forwarded Message > Subject: [PATCH regression fix] firmware/dmi: Move product_sku info to the > end of the modalias > Date: Tue, 31 Aug 2021 15:05:08 +0200 > From: Hans de Goede > To: Jean Delvare > CC: Hans de Goede , [email protected], > [email protected], Kai-Chuan Hsieh , Erwan > Velu > > Commit e26f023e01ef ("firmware/dmi: Include product_sku info to modalias") > added a new field to the modalias in the middle of the modalias, breaking > some existing udev/hwdb matches on the whole modalias without a wildcard > ('*') in between the pvr and rvn fields. > > All modalias matches in e.g. : > https://github.com/systemd/systemd/blob/main/hwdb.d/60-sensor.hwdb > deliberately end in ':*' so that new fields can be added at *the end* of > the modalias, but adding a new field in the middle like this breaks things. > > Move the new sku field to the end of the modalias to fix some hwdb > entries no longer matching. > > The new sku field has already been put to use in 2 new hwdb entries: > > sensor:modalias:platform:HID-SENSOR-200073:dmi:*svnDell*:sku0A3E:* > ACCEL_LOCATION=base > > sensor:modalias:platform:HID-SENSOR-200073:dmi:*svnDell*:sku0B0B:* > ACCEL_LOCATION=base > > The wildcard use before and after the sku in these matches means that they > should keep working with the sku moved to the end. > > Note that there is a second instance of in essence the same problem, > commit f5152f4ded3c ("firmware/dmi: Report DMI Bios & EC firmware release") > > Added 2 new br and efr fields in the middle of the modalias. This too > breaks some hwdb modalias matches, but this has gone unnoticed for over > a year. So some newer hwdb modalias matches actually depend on these > fields being in the middle of the string. Moving these to the end now > would break 3 hwdb entries, while fixing 8 entries. > > Since there is no good answer for the new br and efr fields I have chosen > to leave these as is. Instead I'll submit a hwdb update to put a wildcard > at the place where these fields may or may not be present depending on the > kernel version. In case anyone is interested here is the systemd pull-req fixing this from the hwdb side: https://github.com/systemd/systemd/pull/20599 Regards, Hans > BugLink: https://github.com/systemd/systemd/issues/20550 > Link: https://github.com/systemd/systemd/pull/20562 > Fixes: e26f023e01ef ("firmware/dmi: Include product_sku info to modalias") > Cc: [email protected] > Cc: Kai-Chuan Hsieh > Cc: Erwan Velu > Signed-off-by: Hans de Goede > --- > drivers/firmware/dmi-id.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/drivers/firmware/dmi-id.c b/drivers/firmware/dmi-id.c > index 4d5421d14a41..940ddf916202 100644 > --- a/drivers/firmware/dmi-id.c > +++ b/drivers/firmware/dmi-id.c > @@ -73,6 +73,10 @@ static void ascii_filter(char *d, const char *s) > > static ssize_t get_modalias(char *buffer, size_t buffer_size) > { > + /* > + * Note new fields need to be added at the end to keep compatibility > + * with udev's hwdb which does matches on "`cat dmi/id/modalias`*". > + */ > static const struct mafield { > const char *prefix; > int field; > @@ -85,13 +89,13 @@ static ssize_t get_modalias(char *buffer, size_t > buffer_size) > { "svn", DMI_SYS_VENDOR }, > { "pn", DMI_PRODUCT_NAME }, > { "pvr", DMI_PRODUCT_VERSION }, > - { "sku", DMI_PRODUCT_SKU }, > { "rvn", DMI_BOARD_VENDOR }, > { "rn", DMI_BOARD_NAME }, > { "rvr", DMI_BOARD_VERSION }, > { "cvn", DMI_CHASSIS_VENDOR }, > { "ct", DMI_CHASSIS_TYPE }, > { "cvr", DMI_CHASSIS_VERSION }, > + { "sku", DMI_PRODUCT_SKU }, > { NULL, DMI_NONE } > }; > >
Re: [systemd-devel] [PATCH] nfs.man: document incompatibility between "bg" option and systemd.
On Tue, May 30, 2017 at 08:19:16AM +1000, NeilBrown wrote: > > Systemd does not, and will not, support "bg" correctly. > It has other, better, ways to handle "background" mounting. > > Explain this. > > See also https://github.com/systemd/systemd/issues/6046 > > Signed-off-by: NeilBrown > --- > utils/mount/nfs.man | 18 +- > 1 file changed, 17 insertions(+), 1 deletion(-) > > diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man > index cc6e992ed807..7e76492d454f 100644 > --- a/utils/mount/nfs.man > +++ b/utils/mount/nfs.man > @@ -372,6 +372,21 @@ Alternatively these issues can be addressed > using an automounter (refer to > .BR automount (8) > for details). > +.IP > +When > +.B systemd > +is used to mount the filesystems listed in > +.IR /etc/fstab , > +the > +.B bg > +option is not supported, and may be stripped from the option list. > +Similar functionality can be achieved by providing the > +.B x-system.automount > +option. This will cause > +.B systemd > +to attempt to mount the filesystem when the mountpoint is first > +accessed, rather than during system boot. The mount still happens in > +the "background", though in a different way. > .TP 1.5i > .BR rdirplus " / " nordirplus > Selects whether to use NFS v3 or v4 READDIRPLUS requests. > @@ -1810,7 +1825,8 @@ such as security negotiation, server referrals, and > named attributes. > .BR rpc.idmapd (8), > .BR rpc.gssd (8), > .BR rpc.svcgssd (8), > -.BR kerberos (1) > +.BR kerberos (1), > +.BR systemd.mount (5) . > .sp > RFC 768 for the UDP specification. > .br > -- > 2.12.2 > I like this, it makes it so much easier for users to find the better alternative. FWIW, Reviewed-by: Niels de Vos ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn/machinectl with LUKS/LVM
On 04/10/17 11:31, Lennart Poettering wrote: > The image dissection logic can deal with either. The GPT approach is a > bit nicer I think since the root partition can be marked as such, and All right, makes sense. >> 2) machinectl list-images doesn't detect the images in LVs; am I >> supposed to (auto)mount them in /var/lib/machines/ ? > > Yeah, that's how discovery works. You can alos place a symlink there. So I tried to create a symlink to the LV block device (/dev/vg/containername – containing a GPT) in /var/lib/machines/. I tried naming the symlink "containername" or "containername.raw". But "machinectl list-images -a" doesn't seem to detect this image either way. This is with systemd 234 on Debian stretch, by the way. > It should work, if you make them available in /var/lib/machines, > either by mounting them there or by symlinking them there. I'd like to avoid mounting the image if I can. To avoid having to manually detect the gpt partitions, unlocking LUKS, etc, and to avoid having to expose the container data to the host unnecessarily. But it seems I'm doing something wrong with my symlinks. -- M ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn/machinectl with LUKS/LVM
On 04/10/17 13:09, Lennart Poettering wrote: > Ah, uh, I forgot that your image is a block device. We are missing > some support there for that. /var/lib/machines may only contain > dirs/subvols and raw files right now, we don't support block > devices. But adding support for that should be easy, too. Can you file > an RFE bug on github about this please? Gladly, see: https://github.com/systemd/systemd/issues/6990 Thank you, -- M ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Running a service *just* before unmounting filesystems
Hi All, So as you may have heard, I'm working on hiding the grub-menu by default on single OS Fedora Workstation. Part of the plan here is to detect if a previous boot was successful and cleanly shutdown the machine and show the menu (not hide the menu) if the previous boot has failed to set either the boot_success or shutdown_success flags: https://fedoraproject.org/wiki/Changes/HiddenGrubMenu So now I'm working on writing a unit file which will be added to poweroff.target.wants, reboot.target.want, etc. and which will call: grub2-editenv - set shutdown_success=1 *just* before unmounting file systems, so clearly this needs a: Before: umount.target That will guarantee that grub2-editenv can write to /boot, but if I'm not mistaken then this will cause my grub-shutdown.service to run as soon as "systemctl poweroff" is called. One solution to this would be to add a: After shutdown.target So we get After: shutdown.target Before: umount.target According to: https://www.freedesktop.org/software/systemd/man/bootup.html shutdown, and umount run in parallel, now in practice almost all services will have a Requires sysinit.target which requires localfs.target, which requires all the local mounts, so umounting won't happen until all the services are stopped. Still me adding a unit with a: After: shutdown.target Before: umount.target Implicitly serializes this, which goes against: https://www.freedesktop.org/software/systemd/man/bootup.html So I'm not sure that that is a good idea. For now I will continue working on this using just: Before: umount.target But I'm curious if using: After: shutdown.target Before: umount.target Would be ok and/or if there are other suggestions for doing this. Regards, Hans ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Running a service *just* before unmounting filesystems
Hi, On 11-06-18 13:31, Lennart Poettering wrote: On Mo, 11.06.18 12:48, Hans de Goede ([email protected]) wrote: Hi All, So as you may have heard, I'm working on hiding the grub-menu by default on single OS Fedora Workstation. Part of the plan here is to detect if a previous boot was successful and cleanly shutdown the machine and show the menu (not hide the menu) if the previous boot has failed to set either the boot_success or shutdown_success flags: https://fedoraproject.org/wiki/Changes/HiddenGrubMenu So now I'm working on writing a unit file which will be added to poweroff.target.wants, reboot.target.want, etc. and which will call: Uurks. Quite frankly, it appears strange to me to delay this for this long. I mean we reworked most code that delayed worked to shutdown like this these days to happen as early as possible to make sure we don't lose state unnecessarily. For example the RTC syncing is generally done when the RTC is changed instead of synced back during shutdown. Hence, why not simply write this out when the boot is successful? There are 2 flags / grub environment variables in play here: boot_success shutdown_success The idea being that we also want to show the grub menu if the system did not shutdown cleanly (or somewhat cleanly given that by the time we know we really have a clean shutdown we can no longer write the grubenv). E.g. the system hangs and the user presses the power-button for 4 seconds. The feedback I've been getting on the fedora-devel list is that people are somewhat worried about not being able to get to the grub menu, so we are being very careful here and err-ing on the side of showing the menu too often, rather then possibly not often enough. Note that /boot or /efi is very likely an automount point, (that's at least how we recommend things to be set up, as this provides the best guarantees that the ESP remains is a clean state, as it will be very quickly after the last access, and hence only be in dirty state during a very short timeframe around accesses), and in that case "right before unmount" doesn't make much sense in general, as that would be pretty much all the time (that said, I don't think fedora/Anaconda makes use automount points for /boot and /esp, or even systemd's auto-discovery of the ESP currently, they haven't seen the light there yet, but they really really should) Right Fedora still uses a regular fstab entry for the ESP and changing that is out of scope for what I'm working on. Hence, my recommendation would be: write a small service that is pulled in by default.target, but orders itself after it. Then make your changes from there. i.e. do it as final steps during boot, rather than delay it to shutdown. See above, currently this is for Fedora Workstation only, and the plan is actually to do set boot_success from the systemd user session (using pkexec with a user on console check to execute a new grub2-set-bootflag binarty which only supports changing a limited no env variables), so that we know that the user has actually logged in successfully before setting the flag. note that there have been plans of introducing some generic framework for such "boot completion" tests, as it is useful for a number of usecases, for example Atomic would like to use that. Such a framework would be very minimal most likely: add a new generically named target, before which all "is all good" checkers would be ordered, and after which all "mark the boot as successful" servers ared ordered. Your grub service would fit in perfectly in the latter then. So something like this would make sense for server / container scenarios but not really for Fedora WS, if gdm starts but the keyboard is not functional so the user cannot log in we still want to show the menu the next boot so that the user can say try an older kernel. And even in server / container scenarios ideally asserting success would come from a service which checks that say a http connection can be made or whatever depending on the role of the server... ### I cannot help but notice that you've not answered my original question. So given that the plan is to have both a boot_success and a shutdown_success flag how would you go about implementing the service for this? As explained my current plan is a grub_shutdown.service which gets added to /lib/systemd/system/poweroff.target, etc. and has a: Before=umount.target But I'm thinking about also adding a: After=shutdown.target Which I think you won't like, in which case I can live with just the Before=umount.target but I wonder what your thoughts are on this? Regards, Hans ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Running a service *just* before unmounting filesystems
Hi, On 11-06-18 16:37, Lennart Poettering wrote: On Mo, 11.06.18 15:37, Hans de Goede ([email protected]) wrote: Uurks. Quite frankly, it appears strange to me to delay this for this long. I mean we reworked most code that delayed worked to shutdown like this these days to happen as early as possible to make sure we don't lose state unnecessarily. For example the RTC syncing is generally done when the RTC is changed instead of synced back during shutdown. Hence, why not simply write this out when the boot is successful? There are 2 flags / grub environment variables in play here: boot_success shutdown_success The idea being that we also want to show the grub menu if the system did not shutdown cleanly (or somewhat cleanly given that by the time we know we really have a clean shutdown we can no longer write the grubenv). Well, speaking from the receiving end of the bug report hose, I can tell you that shutdown hangs are almost exclusively happening way after we regularly unmount directories such as /efi or /boot. i.e. such hangs happen in the second phase of shutdown where we clean-up everything that couldn't be cleaned up during normal unit shutdown. (Or in fact even later, after the system returned back into the initrd.) It am very sure it's not worth trying to maintain a shutdown_sucess variable that is determined that early. That's a pointless excercise, you won't catch 99% of relevant issues that way... Ok, I had a quick chat with the rest of the laptop team about this and will just drop the shutdown_success flag. The feedback I've been getting on the fedora-devel list is that people are somewhat worried about not being able to get to the grub menu, so we are being very careful here and err-ing on the side of showing the menu too often, rather then possibly not often enough. sd-boot solves that by always showing the menu if any key is pressed while sd-boot initializes. This means you can hold down any key you like during early boot and the menu is guaranteed to be shown. Why not do that in grub, too? So in grub this is somewhat hard to do "any key" because of its architecture, but I have written patches as part of the hidden menu effort, which will show the menu when SHIFT is hold down during boot. But we also (Fedora 30 timeframe) want to support fastboot, where we don't check for a keypress at all. The problem is that scanning the USB bus can take quite long and some firmware skips this if their "fastboot" option is enabled (typically the default now a days), but if we then ask for keypress / state info in grub most firmwares (*) will do the USB scan at that point, causing easily 2-3 seconds extra boot time. So we want to get to a setup where we don't check for any key at all (by default, this will all be configurable). *) Some firmwares are stupid and simply return "no key", so the grub menu already does not work there now a days I mean, if you are looking for a reliable way to get the menu back if things are bad, then such a shutdown hook is not going to help you, it's not useful to write out shutdown sucess info so early... Ack. Note that /boot or /efi is very likely an automount point, (that's at least how we recommend things to be set up, as this provides the best guarantees that the ESP remains is a clean state, as it will be very quickly after the last access, and hence only be in dirty state during a very short timeframe around accesses), and in that case "right before unmount" doesn't make much sense in general, as that would be pretty much all the time (that said, I don't think fedora/Anaconda makes use automount points for /boot and /esp, or even systemd's auto-discovery of the ESP currently, they haven't seen the light there yet, but they really really should) Right Fedora still uses a regular fstab entry for the ESP and changing that is out of scope for what I'm working on. Well, but it might be worth supporting such setups anyway, no? i mean, I am pretty sure it would be wise to not focus on legacy environments when designing new stuff. Ack. Hence, my recommendation would be: write a small service that is pulled in by default.target, but orders itself after it. Then make your changes from there. i.e. do it as final steps during boot, rather than delay it to shutdown. See above, currently this is for Fedora Workstation only, and the plan is actually to do set boot_success from the systemd user session (using pkexec with a user on console check to execute a new grub2-set-bootflag binary which only supports changing a limited no env variables), so that we know that the user has actually logged in successfully before setting the flag. Are you sure that powering up a system and powering it down right-after should trigger the boot menu? I know that that is not ideal, but who would do that anyways? This should happen very rarely and
Re: [systemd-devel] Running a service *just* before unmounting filesystems
Hi, On 11-06-18 17:48, Jérémy Rosen wrote: We solve a problem which is kinda similar in the embedded world when we do A/B update I'll describe how we do it so you see if this can help * Have a single "last boot went wrong" flag When grub starts * if the flag is set, show the boot menu (or a timer) * if the flag is not set * skip the menu, don't initialize USB, fastboot * set the flag. * At some point during the boot (late enough that it is possible to get a console) reset the flag. this way, your system is "unstable" : either you reach the point where a console is available or you will have a menu at the next reboot. The trick is to have grub first read the flag then set it to "bad" for the next boot. Linux set it to "good" if the boot was good enough Yes that is what we are doing except that the flag has a different name, we call it boot_success and grub clears it on boot and at some point userspace sets it to indicate the boot went ok. Regards, Hans ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Running a service *just* before unmounting filesystems
Hi, On 12-06-18 10:24, Lennart Poettering wrote: On Mo, 11.06.18 17:40, Hans de Goede ([email protected]) wrote: It am very sure it's not worth trying to maintain a shutdown_sucess variable that is determined that early. That's a pointless excercise, OB> > you won't catch 99% of relevant issues that way... Ok, I had a quick chat with the rest of the laptop team about this and will just drop the shutdown_success flag. Excellent! Thanks for reconsidering. I mean, if there was a nice place we could store shutdown state info at a very late point of shutdown we'd totally do that, but nothing good has appeared so far. There are EFI variables and pstore, but given the low quality of the memory of those things it's probably not a good idea to write to them on every shutdown. Yes, I have considered using an EFI variable too, but I too I'm afraid this will damage the crappy backing store for the EFI variables. But we also (Fedora 30 timeframe) want to support fastboot, where we don't check for a keypress at all. The problem is that scanning the USB bus can take quite long and some firmware skips this if their "fastboot" option is enabled (typically the default now a days), but if we then ask for keypress / state info in grub most firmwares (*) will do the USB scan at that point, causing easily 2-3 seconds extra boot time. The other option of course is to emphasize the "reboot into firmware" feature of EFI more. Yes we need "reboot into firmware" support for machines which have fastboot enabled in the firmware, because otherwise there is no way to get into the firmware. We actually already need this today. But this does not really help with getting the grub menu when it is necessary to rescue the system: 1) AFAICT this will not help with getting into grub when grub's fastboot support is enabled and it won't even check for a key. 2) The system may be broken in such a way that the user is unable to run the command / click the menu item for this. In systemd there's "systemctl reboot --firmware" to get into the firmware setup that way. Ah I was working on a minimal hack to do this inside grub, but I will drop that then. In sd-boot we also implicitly add a menu item if the functionality is available. And I've cherry-picked a patch from Ubuntu to do the same in grub (if the menu is shown) which is something which we should have done a long time ago. I figure gdm could try to expose that feature somewhere, maybe in the top-right menu or so? Yes I need to talk to the GNOME designers about adding some advanced reboot options somewhere: 1) Reboot into firmware setup 2) Show boot menu next menu Any others? I'm thinking myself to do something like what Windows does (assuming that will help with discoverability) where shift + click on reboot shows this menu. I figure if there's need for it we could even have some mini daemon whose only job is to provide a reboot-into-firmware hotkey during early boot time. i.e. something that just listens to some otherwise silent keycombo (maybe shift+alt+ctrl), and when it's pressed within the first minute of bootup we'll instantly reboot into firmware or so... In theory that could even be systemd-logind (which already watches input devices for SW_DOCK and SW_LID events), but logind is started quite late, hence maybe a seperate mini daemon might be wise... Hmm, how soon during boot is the ctrl+alt+up target available ? We could add a .service file there which forces showing the grub menu next time (and the grub menu will also allow entering firmware). I already have a menu_show_once grubenv variable which gets checked in grub.cfg-s generated (*) by the new grub2-mkconfig code I'm working on for the auto-hide stuff, so the service file would just need to call grub2-editenv to set that. *) yes grub is ugly Are you sure that powering up a system and powering it down right-after should trigger the boot menu? I know that that is not ideal, but who would do that anyways? This should happen very rarely and the side-effect is completely harmless. I have the suspicion that this can happen pretty regularly. Think: university computer pools, internet cafes and suchlike, which boot up in the morning, and shutdown in the night, and might not see anyone actually log in. (That said, not sure if computer pools and internet cafes still exist event — maybe in some less connected country, dunno) Maybe an approach like this could work: define two image states: "known-good" and "dont-know". A newly installed image comes up as "dont-know", and as soon as the system level stuff is happy is marked as "known-good". This part is obvious I guess. But now we'd allow the system be moved back to "dont-know", and iterate through this again. The first login on the system would use this, and se
[systemd-devel] Adding support for "systemctl reboot --bootmenu" ?
Hi, The mention of "systemctl reboot --firmware" in the other thread made me realize that it would be good to also have a "systemctl reboot --bootmenu". First a question about "systemctl reboot --firmware" is this available to a normal user (through policykit and the user being on a physical attached console) ? Because adding an option to the gdm / usersession reboot menu would require this to be possible. So about "systemctl reboot --bootmenu", the idea here is that it would reboot the system into showing $bootloaders bootmenu, with the countdown disabled. This is of course intended for systems with the menu hidden or with a really short timeout. Since how to tell $bootloader to show its menu will be bootloader specific I'm thinking about using a special target for this, which gets started before doing the reboot and then bootloaders can drop a (oneshot) .service file in that target which does whatever is necessary to get the bootmenu next boot. So is this something worth considering? Regards, Hans ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Running a service *just* before unmounting filesystems
Hi, On 13-06-18 05:40, Alexander E. Patrakov wrote: Hans de Goede : Hi All, So as you may have heard, I'm working on hiding the grub-menu by default on single OS Fedora Workstation. Part of the plan here is to detect if a previous boot was successful and cleanly shutdown the machine and show the menu (not hide the menu) if the previous boot has failed to set either the boot_success or shutdown_success flags: https://fedoraproject.org/wiki/Changes/HiddenGrubMenu I think that I have a possibly better idea regarding shutdown. The idea is to modify GRUB so that it can see whether a filesystem has been cleanly unmounted, and use this condition in the "if" blocks. If the root filesystem has not been cleanly unmounted, then the shutdown has likely failed, possibly because the user has pressed a power button for 5 seconds. The problem with this solution is that, upon hibernation, the filesystem will be always dirty (i.e.: false positive), but we can probably manage it with another flag in grubenv. Thank you for the suggestion, that certainly is an interesting idea, but it would require grub to scan all block devices and check all filesystems which will slow things down significantly and if their then is some old left-over partition somewhere which is not used, it will always get a false positive. That combined with the hibernate issue makes me think that this is more trouble then it is worth. I've accepted that we won't be able to detect unclean shutdowns and we can live with that. Still as said, thank you for thinking along with us. Regards, Hans ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Running a service *just* before unmounting filesystems
Hi, On 12-06-18 19:11, Lennart Poettering wrote: On Di, 12.06.18 11:33, Hans de Goede ([email protected]) wrote: AFAIK the service actually doing the updates is supposed to call systemctl reboot --force when it is done, so any targets after system-update.target won't get started ? True, the service in question could split the reboot call of course, if it wanted, so that you can plug things in between. Since in this case we want to increment a boot_indeterminate counter to indicate the last boot was not a normal boot, so no clear success status is available I'm fine with the service doing the increment before the updates run. So I was thinking about adding a system-update-pre.target and then in system-update.target add: Wants=system-update-pre.target After=system-update-pre.target Would that be an acceptable solution? I would rather not modify the existing offline-updates services because there are 3 of them and I believe it would be better to do this in a single place. Regards, Hans ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Running a service *just* before unmounting filesystems
Hi, On 13-06-18 17:05, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Jun 13, 2018 at 04:55:27PM +0200, Hans de Goede wrote: Hi, On 12-06-18 19:11, Lennart Poettering wrote: On Di, 12.06.18 11:33, Hans de Goede ([email protected]) wrote: AFAIK the service actually doing the updates is supposed to call systemctl reboot --force when it is done, so any targets after system-update.target won't get started ? True, the service in question could split the reboot call of course, if it wanted, so that you can plug things in between. Since in this case we want to increment a boot_indeterminate counter to indicate the last boot was not a normal boot, so no clear success status is available I'm fine with the service doing the increment before the updates run. So I was thinking about adding a system-update-pre.target and then in system-update.target add: Wants=system-update-pre.target After=system-update-pre.target Yep, that sounds reasonable. Ok, so as you've already seen I've just send a pull-req with this change: https://github.com/systemd/systemd/pull/9334 Given that we're going to need system-update-pre.target for Fedora 29: https://fedoraproject.org/wiki/Changes/HiddenGrubMenu It would be great if this could still make the upcoming 239 release. But I guess it is too late for that? Assuming this is too late, I would like to request to carry this as a downstream patch in the Fedora pkgs for now. Regards, Hans ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Running a service *just* before unmounting filesystems
Hi, On 13-06-18 17:05, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Jun 13, 2018 at 04:55:27PM +0200, Hans de Goede wrote: Hi, On 12-06-18 19:11, Lennart Poettering wrote: On Di, 12.06.18 11:33, Hans de Goede ([email protected]) wrote: AFAIK the service actually doing the updates is supposed to call systemctl reboot --force when it is done, so any targets after system-update.target won't get started ? True, the service in question could split the reboot call of course, if it wanted, so that you can plug things in between. Since in this case we want to increment a boot_indeterminate counter to indicate the last boot was not a normal boot, so no clear success status is available I'm fine with the service doing the increment before the updates run. So I was thinking about adding a system-update-pre.target and then in system-update.target add: Wants=system-update-pre.target After=system-update-pre.target Yep, that sounds reasonable. So one more question about this, as discussed in the pull-req, updates services being linked from system-update.target.wants now need a "After=system-update-pre.target" in their .service files. I plan to file bugs against the existing .service files there for this (*). Will those service files potentially having After=system-update-pre.target on systems with an older systemd which does not have that target be a problem, or will systemd just ignore this? Regards, Hans *) and in the case of fwupd-offline-update.service also to add: DefaultDependencies=false Requires=sysinit.target After=sysinit.target Which it is all missing ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Systemd boot failure in a VM
Dear Reader, I am building my own linux system with systemd, following the directions given by de LFS (linux from scratch) project. Until some time ago all went well, but after systemd 232 (i think) - anyhow right at the time that they start using meson/ninja to build systemd - I could not boot the system anymore due to systemd freezing right after it has established that it is on a VM with a x86_64 architecture. Nowadays I also get a libc error before the system freezes. I wonder if you have any reports like this when using meson/ninja or just another systemd 233-8? I have looked at the requirement page on freedesk and my config for the kernel matches. Also, I had modules and an initramfs before, which I now have all included in the kernel, just in case. Does de above give you any clue where to start looking? Regards, Frans. ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd boot failure in a VM - SOLVED
On 07/20/2018 09:28 PM, Frans de Boer wrote: Dear Reader, I am building my own linux system with systemd, following the directions given by de LFS (linux from scratch) project. Until some time ago all went well, but after systemd 232 (i think) - anyhow right at the time that they start using meson/ninja to build systemd - I could not boot the system anymore due to systemd freezing right after it has established that it is on a VM with a x86_64 architecture. Nowadays I also get a libc error before the system freezes. I wonder if you have any reports like this when using meson/ninja or just another systemd 233-8? I have looked at the requirement page on freedesk and my config for the kernel matches. Also, I had modules and an initramfs before, which I now have all included in the kernel, just in case. Does de above give you any clue where to start looking? Regards, Frans. ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel Solved by systemd-239. --- Frans ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] hwdb: Add trackpoint sensitivity setting for Thinkpad X230 tablet
This model needs the trackpoint sensitivity to be boosted to not be too slow to be usable, see: https://bugzilla.redhat.com/show_bug.cgi?id=1200717 --- hwdb/70-pointingstick.hwdb | 2 ++ 1 file changed, 2 insertions(+) diff --git a/hwdb/70-pointingstick.hwdb b/hwdb/70-pointingstick.hwdb index 72c1a3b..a8c21a2 100644 --- a/hwdb/70-pointingstick.hwdb +++ b/hwdb/70-pointingstick.hwdb @@ -87,6 +87,8 @@ evdev:name:*DualPoint Stick:dmi:bvn*:bvr*:bd*:svnDellInc.:pnLatitudeE6400*:pvr* # Lenovo # +# Lenovo Thinkpad X230 tablet +evdev:name:TPPS/2 IBM TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadX230Tablet:* # Lenovo Thinkpad X240 evdev:name:TPPS/2 IBM TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadX240:* # Lenovo Thinkpad T440s -- 2.4.0 ___ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
On Tue, Jun 2, 2015 at 11:53 AM, Kay Sievers wrote: > 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. Have you guys found a way to preserve the comments on pull requests? I don't see it as a cosmetic issue but this was rather the reason I moved projects away from github in the past. As a maintainer of other projects I need to point to a discussion on a single patch and be able to see the previous iterations of a patch. And also check what was the conclusion on a patch set that was accepted in the repository. It's also nice for developers to check if there was any attempt already in implementing some feature and it was denied by any reason. Last time I checked this is impossible with github because you lose the comments on each patch when a second version arrives. Of course this is a non-issue for several projects in github which don't have proper commit review. It's not the case of systemd and it seems it's even the reason why you are moving to github. So I'm just curious if anything changed in this regard or you solved it in another way. thanks -- Lucas De Marchi ___ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
On Fri, Jun 5, 2015 at 7:02 AM, David Herrmann wrote: > Hi > > On Wed, Jun 3, 2015 at 7:48 PM, Lucas De Marchi > wrote: >> Of course this is a non-issue for several projects in github which >> don't have proper commit >> review. It's not the case of systemd and it seems it's even the reason >> why you are moving >> to github. So I'm just curious if anything changed in this regard or >> you solved it in another >> way. > > github attaches code-reviews to the actual git commits. The PR > displays all comments on the commits in the given branch. As long as > those commits stay part of the PR, the comments will remain. However, > if people force-push corrected commits, the old commits are no longer > linked in any way to the PR and thus will not be shown. You can still > access them by directly looking at the old commit, though. > > With their model, I understand why old reviews are lost on force-push. > You can work around this, by including the sha256 in your PR comments > after a review. Those comments remain and you can look at the old > reviews this way. They'll not be linked in a shiny way (but that's the > same if you resend your mails on an ML..). I can be proven wrong, but I don't think you can actually do what you're saying. If you force push a branch you actually lose the comments on the previous set. Being able to access the old commit is pure luck while there isn't a gc on the remote repository. Also, comments on a commit of a pull request are attached to the *forked repository*, not the repository in which the pull request was made. So if the remote is deleted, upstream can't see them anymore. Upstream still have the commits under refs/pull//head (the last iteration of the patch set), but comments are gone. -- Lucas De Marchi ___ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
On Tue, Jun 9, 2015 at 7:01 PM, Lennart Poettering wrote: > Well, but it's really weird... If you start out with a patch things > are tracked as PR. If you start out without a patch things are tracked > as an issue. And they have quite different workflows, as PRs cannot be > reopened and issues can, for example. > > I am pretty sure issues should be at the core of things... > > WHat really surprises me about the whole discussion is that we cannot > be the first ones running into this. Given the success of github this > must be a common issue. And if it is, then either github is actually > prety bad, or I am too stuck in my bugzilla mindset and haven't really > grokked the github way of doing things yet. You really aren't. I commented on this thread before and on my quest to try to understand the github model I found several people with the same problems. It's worth reading https://github.com/torvalds/linux/pull/17#issuecomment-5654674 - Those are not the same problems you are facing and those I really care about, but there is much about the "github model" there. Projects with proper per-commit review have a hard time with github because it's not the github model. The github model is you push a lots of things people may suggest some changes and the original author just pushes new code on top. The pullrequest in github ui is just a chronological view of out-of-place comments and new pushes. There are exceptions to this, but it pretty much covers the vast majority of projects really using the issues/pr featues in github. Of course there are the petty projects in which losing comments doesn't matter much and reviews are pretty much superficial. It's really hard to see projects in github with good commit messages and proper commit reviews. And I'd say some of the github limitations that pushes for this kind o behavior. Since I care about comments in each patch what I'm doing in projects I maintain (and I do have some private repositories) is to have something similar to what you suggest: opening a second pullrequest and reference the first one. Bear in mind though the comments are *always attached to the commit* not the pullrequest. So in the extreme case the person sending the pullrequest removes *his* remote, you lost the comments. This may not hurt now, but it really does after one year when you are trying to find that comment. Then people will try to convince you to comment on the pullrequest rather the individual commits. It's rather a sick place to be in for whom are used to proper reviews. Github does has nice features, integration with other tools, etc. But I was really shocked when their review system was *the* reason systemd was getting aboard. Oh... not to mention the pullrequest doesn't show commits in order (https://help.github.com/articles/why-are-my-commits-in-the-wrong-order/). I was bitten by this back in 2013 when I was using github much more and I had forgotten. Looks like things didn't change since then. Now when I'm reviewing pullrequests I never trust to review them directly in the browser but I rather pull all the pullrequests with a variant of your "git pullnotes": alias.pullpr = fetch origin refs/pull/*:refs/pull/* -- Lucas De Marchi ___ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sd 221 regression: login - nonexistent sessions via lightdm
I can confirm lightdm greeter leaves some proccesses behind when it's
closed (like dbus-launch, dbus-daemon, at-spi-bus-launcher...) They are
only definitely terminated when user logs out from that seat.
2015-07-07 14:10 GMT-03:00 David Herrmann :
> Hi
>
> On Tue, Jul 7, 2015 at 6:55 PM, Martin Pitt
> wrote:
> > Hey David,
> >
> > David Herrmann [2015-07-07 18:31 +0200]:
> >> > Revert "login: re-use VT-sessions if they already exist" - commit
> 0204c4b
> >> > http://cgit.freedesktop.org/systemd/systemd/commit/?id=0204c4b
> >>
> >> Can someone elaborate what exactly lightdm does here? We really want
> >> to prevent multiple sessions on the same VT. This is just nasty and
> >> never made any sense. So I'm really interested why lightdm doesn't
> >> kill it's manager-session before it starts the new session. Any
> >> particular reason here?
> >
> > I'll let Robert answer with the details, but something I noticed:
> >
> > It's not that simple to reproduce, but sometimes it seems the lightdm
> > "greeter" session (running as user lightdm, where you select user/type
> > password and so on) doesn't completely terminate, but some processes
> > stay around in it. Thus the greeter session stays around in state
> > "Closing", and then the "real" session starts on the same VT.
> >
> > I asked the reporter of https://launchpad.net/bugs/1472259 to attach
> > systemd-cgls, so that we can see what's running in the session.
>
> So it might indeed just be a race in lightdm. Hmm..
> Anyway, this patch here should also fix the issue (if it does, I'll
> commit something proper).
>
> Thanks
> David
>
> diff --git a/src/login/logind-dbus.c b/src/login/logind-dbus.c
> index 0cc2cdf..bced693 100644
> --- a/src/login/logind-dbus.c
> +++ b/src/login/logind-dbus.c
> @@ -690,8 +690,11 @@ static int method_create_session
> }
>
> manager_get_session_by_pid(m, leader, &session);
> -if (!session && vtnr > 0 && vtnr < m->seat0->position_count)
> +if (!session && vtnr > 0 && vtnr < m->seat0->position_count) {
> session = m->seat0->positions[vtnr];
> +if (session && session->class == SESSION_GREETER)
> + session = NULL;
> +}
> if (session) {
> _cleanup_free_ char *path = NULL;
> _cleanup_close_ int fifo_fd = -1;
> ___
> systemd-devel mailing list
> [email protected]
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
--
*Laércio de Sousa*
*Orientador de Informática*
*Escola Municipal "Professor Eulálio Gruppi"*
*Rua Ismael da Silva Mello, 559, Mogi Moderno*
*Mogi das Cruzes - SPCEP 08717-390*
Telefone: (11) 4726-8313
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd
Hi Tomasz, On Fri, Apr 10, 2015 at 9:17 AM, Tomasz Bursztyka wrote: > Hi, > > As it has been discussed in the systemd hackfest during the Linux Conference > Europe, one daemon could centralize the management of all network proxy > configurations. Idea is something user can do per-application (like in > firefox for instance) or broader (per-DM like in Gnome), user could do it > once and for all through such daemon and applications would then request it > to know whether or not a proxy has to be used and which one. > > As a notice, this is nothing new. Such standalone daemon has been already > done by the past, pacrunner. systemd-proxy-discoveryd will more or less > implement the same ideas with improvements. It will get rid of big JS > engines like spidermonkey or v8 which are overkill for the tiny PAC files > to be executed on, for instance. From pacrunner experience, APIs will be > also improved. > > This one is using - at least in this RFC - the duktape JS engine to run > the PAC files. Note it is not provided in this patchset. Latest version > 1.2.x was used. > > Next features to come are a bit detailed in the TODO (last patch). > > Tomasz Bursztyka (6): > proxy-discoveryd: Basic core added > proxy-discoveryd: Add the basics for parsing the default configuration > proxy-discoveryd: Add PAC support through duktape js engine > proxy-discoveryd: Execute the PAC based proxy in a thread > proxy-discoveryd: Add the basic parts for handling DBus methods > update TODO What happened to this patch set? Are you going to send a new version? Lucas De Marchi ___ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Multi seats
Hi Arnaud!
I've been researching systemd-based multi-seat setups with non-KMS video
drivers for a couple of years.
In principle, yes, you can set up a multi-seat system with proprietary
NVIDIA drivers, provided you:
* provide a suitable udev rule to tag your NVIDIA card as "master-of-seat"
(they are tagged by default if using Nouveau drivers). Examples:
SUBSYSTEM=="drm", KERNEL=="card[0-9]*", ATTRS{vendor}=="0x10de", DRIVERS
=="nvidia", TAG+="master-of-seat"
SUBSYSTEM=="pci", ATTRS{vendor}=="0x10de", DRIVER=="nvidia", TAG+="seat"
, TAG+="master-of-seat"
* Have xorg-server 1.16 or newer installed
* Provide a suitable xorg.conf for your NVIDIA card, not forgetting to put
MatchSeat entries in Device/Screen/ServerLayout sections.
* Have LightDM 1.12 or newer installed (if you don't use GNOME)
Att.
2015-08-28 7:58 GMT-03:00 arnaud gaboury :
> One year ago, I tried to setup multi seats, see this thread[0]. By
> that time, I gave up as my configuration was not made for such a
> fetaure.
> Now I am back with all the needed tools to do it easily (I think so):
> - Fedora 22
> - lightdm & GDM
> - an USB 3 plugable dockin station
>
> As good how-to on this topic are few, I wonder a few things:
> - is the proprietary Nvidia driver Ok or shall I indeed use Nouveau
> (my card is Nvidia one)?
> - are the lightdm/Xorg setup configuring accordingly or shall I edit
> manually the conf files?
>
> I understand the whole principle to $ loginctl attach seatNumber
> /device/apth.
>
> Thank you for a few hints.
>
>
> [0]
> http://lists.freedesktop.org/archives/systemd-devel/2014-August/022403.html
>
> --
>
> google.com/+arnaudgabourygabx
> ___
> systemd-devel mailing list
> [email protected]
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
--
*Laércio de Sousa*
*Orientador de Informática*
*Escola Municipal "Professor Eulálio Gruppi"*
*Rua Ismael da Silva Mello, 559, Mogi Moderno*
*Mogi das Cruzes - SPCEP 08717-390*
Telefone: (11) 4726-8313
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Multi seats
You're right. If you use GNOME, GDM is ready for you. In any other case,
use LightDM >= 1.12. Automatic multi-seat support for SDDM (used by KDE and
LXQt) is still WIP.
2015-08-28 8:42 GMT-03:00 arnaud gaboury :
> On Fri, Aug 28, 2015 at 1:37 PM, Laércio de Sousa
> wrote:
> > Hi Arnaud!
> >
> > I've been researching systemd-based multi-seat setups with non-KMS video
> > drivers for a couple of years.
> >
> > In principle, yes, you can set up a multi-seat system with proprietary
> > NVIDIA drivers, provided you:
> >
> > * provide a suitable udev rule to tag your NVIDIA card as
> "master-of-seat"
> > (they are tagged by default if using Nouveau drivers). Examples:
> >
> > SUBSYSTEM=="drm", KERNEL=="card[0-9]*", ATTRS{vendor}=="0x10de",
> > DRIVERS=="nvidia", TAG+="master-of-seat"
> >
> > SUBSYSTEM=="pci", ATTRS{vendor}=="0x10de", DRIVER=="nvidia",
> > TAG+="seat", TAG+="master-of-seat"
> >
> > * Have xorg-server 1.16 or newer installed
> >
> > * Provide a suitable xorg.conf for your NVIDIA card, not forgetting to
> put
> > MatchSeat entries in Device/Screen/ServerLayout sections.
> >
> > * Have LightDM 1.12 or newer installed (if you don't use GNOME)
>
> In fact I was wrong in my presentation. Login window is now managed by
> GDM in Fedora 22, not Lightdm. I guess I do not need to install and
> log with Lightdm, am I right?
> >
> > Att.
> >
> > 2015-08-28 7:58 GMT-03:00 arnaud gaboury :
> >>
> >> One year ago, I tried to setup multi seats, see this thread[0]. By
> >> that time, I gave up as my configuration was not made for such a
> >> fetaure.
> >> Now I am back with all the needed tools to do it easily (I think so):
> >> - Fedora 22
> >> - lightdm & GDM
> >> - an USB 3 plugable dockin station
> >>
> >> As good how-to on this topic are few, I wonder a few things:
> >> - is the proprietary Nvidia driver Ok or shall I indeed use Nouveau
> >> (my card is Nvidia one)?
> >> - are the lightdm/Xorg setup configuring accordingly or shall I edit
> >> manually the conf files?
> >>
> >> I understand the whole principle to $ loginctl attach seatNumber
> >> /device/apth.
> >>
> >> Thank you for a few hints.
> >>
> >>
> >>
> >> [0]
> http://lists.freedesktop.org/archives/systemd-devel/2014-August/022403.html
> >>
> >> --
> >>
> >> google.com/+arnaudgabourygabx
> >> ___
> >> systemd-devel mailing list
> >> [email protected]
> >> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> >
> >
> >
> >
> > --
> > Laércio de Sousa
> > Orientador de Informática
> > Escola Municipal "Professor Eulálio Gruppi"
> > Rua Ismael da Silva Mello, 559, Mogi Moderno
> > Mogi das Cruzes - SP
> > CEP 08717-390
> > Telefone: (11) 4726-8313
>
>
>
> --
>
> google.com/+arnaudgabourygabx
>
--
*Laércio de Sousa*
*Orientador de Informática*
*Escola Municipal "Professor Eulálio Gruppi"*
*Rua Ismael da Silva Mello, 559, Mogi Moderno*
*Mogi das Cruzes - SPCEP 08717-390*
Telefone: (11) 4726-8313
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] help : loginctl won't add new seat
Hi Benoit! I guess you forgot to tag your seat1 card as "master-of-seat". 2015-09-02 6:52 GMT-03:00 Benoit Barthelet : > long story short I had a working multiseat setup with 2 GPU / 2 mices > and 2 keyboards > > I changed GPU drivers from open-source radeon to fglrx and it stopped > working > > before the driver change I had configured the 2nd seat to used the gpu > / mice / keys with : > > loginctl attach seat1 > /sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/ > etc.. > > the issue with the new drivers it seems is that I can't find the card0 > in the /sys hierarchy, > > for instance, it seems to be one of my card, but no seat tag : > udevadm info --query=all > --path=/sys/devices/pci:00/:00:07.0/:03:00.0 > > P: /devices/pci:00/:00:07.0/:03:00.0 > E: DEVPATH=/devices/pci:00/:00:07.0/:03:00.0 > E: DRIVER=fglrx_pci > E: ID_MODEL_FROM_DATABASE=Tahiti PRO [Radeon HD 7950/8950 OEM / R9 280] > E: ID_PCI_CLASS_FROM_DATABASE=Display controller > E: ID_PCI_INTERFACE_FROM_DATABASE=VGA controller > E: ID_PCI_SUBCLASS_FROM_DATABASE=VGA compatible controller > E: ID_VENDOR_FROM_DATABASE=Advanced Micro Devices, Inc. [AMD/ATI] > E: MODALIAS=pci:v1002d679Asv174BsdE207bc03sc00i00 > E: PCI_CLASS=3 > E: PCI_ID=1002:679A > E: PCI_SLOT_NAME=:03:00.0 > E: PCI_SUBSYS_ID=174B:E207 > E: SUBSYSTEM=pci > E: USEC_INITIALIZED=4263516 > > So I tried to create manually a udev rule > > /etc/udev/rules.d/71-ati.rules > > SUBSYSTEM=="pci", > DEVPATH=="/devices/pci:00/:00:01.0/:01:00.0", TAG+="seat", > TAG+="master-of-seat" > SUBSYSTEM=="pci", > DEVPATH=="/devices/pci:00/:00:07.0/:03:00.0", TAG+="seat", > TAG+="seat1" > > and now loginctl seat-status seat0 gives a master tag after udevadm > trigger : > ├─/sys/devices/pci:00/:00:01.0/:01:00.0 > │ [MASTER] pci::01:00.0 > > but I can never have a seat1, it never appears so the display manager > never tries to launch 2nd X session ) > > I'm at a loss here. any help appreciated > ___ > systemd-devel mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- *Laércio de Sousa* *Orientador de Informática* *Escola Municipal "Professor Eulálio Gruppi"* *Rua Ismael da Silva Mello, 559, Mogi Moderno* *Mogi das Cruzes - SPCEP 08717-390* Telefone: (11) 4726-8313 ___ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] hwdb: Add Thinkpad T550 / W550s to 70-pointingstick.hwdb
Like many other recent thinkpads the factory default pointingstick sensitivity on these devices is quite low, making the pointingstick very slow in moving the cursor. This extends the existing hwdb rules for tweaking the sensitivity to also apply to the T550 / W550s models. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1200717 --- hwdb/70-pointingstick.hwdb | 2 ++ 1 file changed, 2 insertions(+) diff --git a/hwdb/70-pointingstick.hwdb b/hwdb/70-pointingstick.hwdb index a8c21a2..9d15173 100644 --- a/hwdb/70-pointingstick.hwdb +++ b/hwdb/70-pointingstick.hwdb @@ -95,6 +95,8 @@ evdev:name:TPPS/2 IBM TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadX240 evdev:name:TPPS/2 IBM TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadT440s:* # Lenovo Thinkpad T540p evdev:name:TPPS/2 IBM TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadT540p:* +# Lenovo Thinkpad T550 / W550s +evdev:name:TPPS/2 IBM TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadT550:* POINTINGSTICK_SENSITIVITY=200 POINTINGSTICK_CONST_ACCEL=1.0 -- 2.4.3 ___ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Multi seats setup How-to
gt; E: MAJOR=226
> E: MINOR=2
> E: SUBSYSTEM=drm
> E: TAGS=:seat:seat1:uaccess:
> E: USEC_INITIALIZED=160111782
>
>
> $ cat /etc/udev/rules.d/99-displaylink.rules
> (shipped with the displaylink .rmp driver)
> ---
> ACTION=="add", SUBSYSTEM=="usb", ENV{ID_VENDOR}=="DisplayLink",
> MODE="0660", RUN+="/bin/systemctl start displaylink.service"
> ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_VENDOR}=="DisplayLink",
> RUN+="/bin/systemctl stop displaylink.service"
> --
>
> $ cat /etc/udev/rules.d/99-nvidia_seats.rules
> --
> # provide a suitable udev rule to tag your NVIDIA card as "master-of-seat"
> SUBSYSTEM=="drm", KERNEL=="card[0-9]*", ATTRS{vendor}=="0x10de",
> DRIVERS=="nvidia", TAG+="master-of-seat"
>
> SUBSYSTEM=="pci", ATTRS{vendor}=="0x10de", DRIVER=="nvidia",
> TAG+="seat", TAG+="master-of-seat"
>
>
> cat /etc/udev/rules.d/72-seat-drm-platform-evdi_1.rules
> ---
> TAG=="seat", ENV{ID_FOR_SEAT}=="drm-platform-evdi_1", ENV{ID_SEAT}="seat1"
> -
>
> cat /etc/udev/rules.d/72-seat-input-pci-_00_14_0-usb-0_10_4_1_1_1.rules
> --
>
> TAG=="seat", ENV{ID_FOR_SEAT}=="input-pci-_00_14_0-usb-0_10_4_1_1_1",
> ENV{ID_SEAT}="seat1"
> ---
>
>
>
> # systemctl restart systemd-udev-trigger.service (or even reboot)
>
> $ loginctl show-session (two users logged in)
> SESSIONUID USER SEAT
> 2 1001 Martin seat0
> 1 1000 Louisseat0
> c1 42 gdm seat0
> 3 sessions listed.
>
> $ loginctl list-seats
>
> SEAT
> seat0
>
> 1 seats listed.
>
> xx
>
> What am I missing? Why can't I create seat1 ?
> Maybe # rm /etc/udev/rules.d/72* and try again ?
>
>
>
>
> Thank you for help.
>
>
> >
> > Will try this later when I will get hand on the Fedora box.
> > Thank you so much for your clarifications.
> >
> > success,
> >
> > floris
> > ___
> > systemd-devel mailing list
> > [email protected]
> > http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> >
> >
>
>
>
> --
>
> google.com/+arnaudgabourygabx
> ___
> systemd-devel mailing list
> [email protected]
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
--
*Laércio de Sousa*
*Orientador de Informática*
*Escola Municipal "Professor Eulálio Gruppi"*
*Rua Ismael da Silva Mello, 559, Mogi Moderno*
*Mogi das Cruzes - SPCEP 08717-390*
Telefone: (11) 4726-8313
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Hook more properties for transient units
systemd-run can now launch units with PrivateTmp, PrivateDevices,
PrivateNetwork, NoNewPrivileges set.
---
src/core/dbus-execute.c | 54 ++---
src/shared/bus-util.c | 3 ++-
2 files changed, 22 insertions(+), 35 deletions(-)
diff --git a/src/core/dbus-execute.c b/src/core/dbus-execute.c
index ed55fcf..fd13c6d 100644
--- a/src/core/dbus-execute.c
+++ b/src/core/dbus-execute.c
@@ -931,51 +931,37 @@ int bus_exec_context_set_transient_property(
unit_write_drop_in_private_format(u, mode, name,
"StandardError=%s\n", exec_output_to_string(p));
}
return 1;
-} else if (streq(name, "IgnoreSIGPIPE")) {
+} else if (STR_IN_SET(name,
+ "IgnoreSIGPIPE", "TTYVHangup", "TTYReset",
+ "PrivateTmp", "PrivateDevices", "PrivateNetwork",
+ "NoNewPrivileges")) {
int b;
r = sd_bus_message_read(message, "b", &b);
if (r < 0)
return r;
if (mode != UNIT_CHECK) {
-c->ignore_sigpipe = b;
-
-unit_write_drop_in_private_format(u, mode, name,
"IgnoreSIGPIPE=%s\n", yes_no(b));
-}
-
-return 1;
-
-} else if (streq(name, "TTYVHangup")) {
-int b;
-
-r = sd_bus_message_read(message, "b", &b);
-if (r < 0)
-return r;
-
-if (mode != UNIT_CHECK) {
-c->tty_vhangup = b;
-
-unit_write_drop_in_private_format(u, mode, name,
"TTYVHangup=%s\n", yes_no(b));
-}
-
-return 1;
-
-} else if (streq(name, "TTYReset")) {
-int b;
-
-r = sd_bus_message_read(message, "b", &b);
-if (r < 0)
-return r;
-
-if (mode != UNIT_CHECK) {
-c->tty_reset = b;
-
-unit_write_drop_in_private_format(u, mode, name,
"TTYReset=%s\n", yes_no(b));
+if (streq(name, "IgnoreSIGPIPE"))
+c->ignore_sigpipe = b;
+else if (streq(name, "TTYVHangup"))
+c->tty_vhangup = b;
+else if (streq(name, "TTYReset"))
+c->tty_reset = b;
+else if (streq(name, "PrivateTmp"))
+c->private_tmp = b;
+else if (streq(name, "PrivateDevices"))
+c->private_devices = b;
+else if (streq(name, "PrivateNetwork"))
+c->private_network = b;
+else if (streq(name, "NoNewPrivileges"))
+c->no_new_privileges = b;
+
+unit_write_drop_in_private_format(u, mode, name,
"%s=%s\n", name, yes_no(b));
}
return 1;
} else if (streq(name, "UtmpIdentifier")) {
diff --git a/src/shared/bus-util.c b/src/shared/bus-util.c
index 36c4422..c19dc97 100644
--- a/src/shared/bus-util.c
+++ b/src/shared/bus-util.c
@@ -1421,11 +1421,12 @@ int bus_append_unit_property_assignment(sd_bus_message
*m, const char *assignmen
return bus_log_create_error(r);
if (STR_IN_SET(field,
"CPUAccounting", "MemoryAccounting",
"BlockIOAccounting",
"SendSIGHUP", "SendSIGKILL", "WakeSystem",
"DefaultDependencies",
- "IgnoreSIGPIPE", "TTYVHangup", "TTYReset",
"RemainAfterExit")) {
+ "IgnoreSIGPIPE", "TTYVHangup", "TTYReset",
"RemainAfterExit",
+ "PrivateTmp", "PrivateDevices", "PrivateNetwork",
"NoNewPrivileges")) {
r = parse_boolean(eq);
if (r < 0) {
log_error("Failed to parse boolean assignment %s.",
assignment);
return -EINVAL;
--
2.6.0.rc0.29.g24f8d8a
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] hwdb: Add Thinkpad X1 carbon 3rd gen to 70-pointingstick.hwdb
Like many other recent thinkpads the factory default pointingstick sensitivity on these devices is quite low, making the pointingstick very slow in moving the cursor. This extends the existing hwdb rules for tweaking the sensitivity to also apply to the X1 carbon 3rd gen model. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1200717 --- hwdb/70-pointingstick.hwdb | 2 ++ 1 file changed, 2 insertions(+) diff --git a/hwdb/70-pointingstick.hwdb b/hwdb/70-pointingstick.hwdb index 8e674b1..9d288e3 100644 --- a/hwdb/70-pointingstick.hwdb +++ b/hwdb/70-pointingstick.hwdb @@ -100,6 +100,8 @@ evdev:name:TPPS/2 IBM TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadT440 evdev:name:TPPS/2 IBM TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadT540p:* # Lenovo Thinkpad T550 / W550s evdev:name:TPPS/2 IBM TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadT550:* +# Lenovo Thinkpad X1 Carbon 3rd gen +evdev:name:TPPS/2 IBM TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadX1Carbon3rd:* POINTINGSTICK_SENSITIVITY=200 POINTINGSTICK_CONST_ACCEL=1.0 -- 2.4.3 ___ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
