Re: [systemd-devel] How to unset "uaccess" tag in udev rule?
Hi On Sun, Mar 26, 2017 at 8:07 PM, Manuel Reimer wrote: > On 03/25/2017 05:16 PM, David Herrmann wrote: So far I did this by creating an empty file with the same name in /etc/udev/rules.d which works well, but for no reason the name was changed some time ago which overrides my empty file and reactivates the problematic rule. >>> >>> That's the only way. Tags cannot be unset. >> >> >> Use TAG-="foobar". > > > I've tried that and it doesn't work. The `-=' operator was introduced for exactly this use-case (which the commit I quoted should explain). If it does not work, it has to be fixed. Last time I checked, it worked. Hence, if you need help using it, please give us as much information as possible. Please verify the operator works with something that is not already used (set some random TAG and remove it again, check with `udevadm` whether it works). If you have no clue how to debug it yourself, please specify _what_ you changed, what systemd version / distro / etc., you're running, so we can reproduce it and help you further. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?
On Mon, Mar 27, 2017 at 10:20 PM, Chris Murphy wrote: > Ok so the dirty file system problem always happens with all pk offline > updates on Fedora using either ext4 or XFS with any layout; and it's > easy to reproduce. > > 1. Clean install any version of Fedora, defaults. > 2. Once Gnome Software gives notification of updates, Restart & Install > 3. System reboots, updates are applied, system reboots again. > 4. Now check the journal filtering for 'fsck' and you'll see it > replayed the journals; if using XFS check the filter for "XFS" and > you'll see the kernel did journal replace at mount time. > > Basically systemd is rebooting even though the remoun-ro fails > multiple times, due to plymouth running off root fs and being exempt > from being killed, and then reboots anyway, leaving the file system > dirty. So it seems like a flaw to me to allow an indefinite exemption > from killing a process that's holding a volume rw, preventing > remount-ro before reboot. > > So there's a risk that in other configurations this makes either ext4 > and XFS systems unbootable following an offline update. So on the one hand it's probably a Plymouth bug or misconfiguration (it shouldn't mark itself exempt unless it runs off an in-memory initramfs). But on the other hand, are filesystems really so fragile? Even though it's after a system upgrade (which updated many files), I was sure systemd at least tries to *sync* all remaining filesystems before reboot, doesn't it? -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?
Ok so the dirty file system problem always happens with all pk offline updates on Fedora using either ext4 or XFS with any layout; and it's easy to reproduce. 1. Clean install any version of Fedora, defaults. 2. Once Gnome Software gives notification of updates, Restart & Install 3. System reboots, updates are applied, system reboots again. 4. Now check the journal filtering for 'fsck' and you'll see it replayed the journals; if using XFS check the filter for "XFS" and you'll see the kernel did journal replace at mount time. Basically systemd is rebooting even though the remoun-ro fails multiple times, due to plymouth running off root fs and being exempt from being killed, and then reboots anyway, leaving the file system dirty. So it seems like a flaw to me to allow an indefinite exemption from killing a process that's holding a volume rw, preventing remount-ro before reboot. So there's a risk that in other configurations this makes either ext4 and XFS systems unbootable following an offline update. Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
