Bug#797039: Additional informations
As you can see in my fstab, the last line is : #Data /mnt/Data vboxsf defaults 0 0 Data exist from time to time /mnt/Data always exists. I have to comment that line in order to boot my system. Else, instead of showing the mount error, and continue booting, the system shows an emergency prompt, and is unable to boot. I think that is a real problem that a sysetm is unable to boot just because a data partition is not accessible. The behaviour with sysvinit was smarter. Regards. ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#618862: marked as done (systemd: ignores keyscript in crypttab)
Your message dated Thu, 27 Aug 2015 10:14:01 +0200 with message-id <20150827081401.ga9...@piware.de> and subject line Re: Bug#756202: systemd: Slow bootup (more than 3 minutes), comment swap line in fstab has caused the Debian Bug report #756202, regarding systemd: ignores keyscript in crypttab to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 756202: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756202 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: systemd Version: 19-1 Severity: normal Hi, my root and swap partition are encrypted with cryptsetup; root uses a custom keyscript and swap uses the cryptsetup-provided "decrypt_derived" keyscript. systemd seems to be unable to work with keyscripts at all, and requires password input for every volume that wasn't activated already. Luckily, my root FS is activated by the initramfs. I don't want to have to type in a password for every encrypted volume: on some of my machines this would mean having to type five or more passwords on boot. Is there any way of using keyscripts or some equivalent with systemd? FYI, some (abbreviated) info on my machine. /etc/fstab: /dev/mapper/root / ext3 relatime,user_xattr,errors=remount-ro 0 1 /dev/sda1 /boot ext3 noatime 0 2 /dev/mapper/swap none swap sw0 0 /etc/crypttab: rootUUID=... /dev/... luks,keyscript=/usr/local/lib/cryptsetup/scripts/decrypt_dev swapUUID=... root luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived /var/log/syslog: systemd-initctl[10973]: Received environment initctl request. This is not implemented in systemd. systemd-fsck[452]: root: clean, 444366/13107200 files, 47184313/52427870 blocks systemd-cryptsetup[735]: Encountered unknown /etc/crypttab option 'keyscript=/usr/local/lib/cryptsetup/scripts/decrypt_dev', ignoring. systemd-cryptsetup[735]: Volume root already active. systemd-cryptsetup[781]: Password file path root is not absolute. Ignoring. systemd-cryptsetup[781]: Encountered unknown /etc/crypttab option 'keyscript=/lib/cryptsetup/scripts/decrypt_derived', ignoring. systemd-fsck[738]: /dev/sda1: clean, 255/65952 files, 57208/263056 blocks systemd-cryptsetup[781]: Invalid packet systemd-cryptsetup[781]: Timed out systemd-cryptsetup[781]: Failed to query password: Timer expired systemd-cryptsetup[1102]: Password file path root is not absolute. Ignoring. systemd-cryptsetup[1102]: Encountered unknown /etc/crypttab option 'keyscript=/lib/cryptsetup/scripts/decrypt_derived', ignoring. systemd-cryptsetup[1102]: Timed out systemd-cryptsetup[1102]: Failed to query password: Timer expired systemd-cryptsetup[1399]: Password file path root is not absolute. Ignoring. systemd-cryptsetup[1399]: Encountered unknown /etc/crypttab option 'keyscript=/lib/cryptsetup/scripts/decrypt_derived', ignoring. systemd-cryptsetup[1399]: Timed out systemd-cryptsetup[1399]: Failed to query password: Timer expired -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages systemd depends on: ii libaudit01.7.13-1+b2 Dynamic library for security audit ii libc62.11.2-13 Embedded GNU C Library: Shared lib ii libcap2 1:2.20-1support for getting/setting POSIX. ii libcryptsetup1 2:1.2.0-2 libcryptsetup shared library ii libdbus-1-3 1.4.6-1 simple interprocess messaging syst ii libpam0g 1.1.2-2 Pluggable Authentication Modules l ii libselinux1 2.0.96-1SELinux runtime shared libraries ii libudev0 166-1 libudev shared library ii util-linux 2.17.2-9.1 Miscellaneous system utilities Versions of packages systemd recommends: ii libpam-systemd19-1 system and service manager - PAM m Versions of packages systemd suggests: ii systemd-gui 19-1 system and service manager - GUI -- no debconf information --- End Message --- --- Begin Message --- Hello, this is a desired change and won't be relaxed again. Ignoring fstab entries has led to too many bugs. See https://www.debian.org/releases/stable/amd64/release-notes/ch-information.de.html#systemd-auto-mounts-incompat Thanks,
Bug#761021: Unclear behaviour if filesystems referenced in fstab are unavailable
Hello Jean-Philippe, this is a desired change and won't be relaxed again. Ignoring fstab entries has led to too many bugs. See https://www.debian.org/releases/stable/amd64/release-notes/ch-information.de.html#systemd-auto-mounts-incompat Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: closing 761021
Processing commands for cont...@bugs.debian.org: > close 761021 Bug #761021 [systemd] Unclear behaviour if filesystems referenced in fstab are unavailable Marked Bug as done > thanks Stopping processing here. Please contact me if you need assistance. -- 761021: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761021 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#797039: Additional informations
Demolins Martial [2015-08-27 9:56 +0200]: > As you can see in my fstab, the last line is : > > #Data /mnt/Data vboxsf defaults 0 0 > > Data exist from time to time > /mnt/Data always exists. So mark it as "defaults,nofail" to tell that this isn't a critical partition. > The behaviour with sysvinit was smarter. I'm afraid it wasn't. It even ignored unavailable /var or /home or other critical partitions, and thus led to any kind of weakly defined behaviour, ranging from failing to boot later on up to data loss. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#786393: systemd: should not try to open encrypted devs that were already opened succesfully, workaround
unmerge 756202 reopen 786393 reopen 618862 thanks Meh, #756202 is something entirely different than #786393 and #618862. Unmerging and reopening the latter two. Sorry for the noise! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: Re: Bug#786393: systemd: should not try to open encrypted devs that were already opened succesfully, workaround
Processing commands for cont...@bugs.debian.org:
> unmerge 756202
Bug #756202 {Done: Martin Pitt } [systemd] systemd: Slow
bootup (more than 3 minutes), comment swap line in fstab
Bug #618862 {Done: Martin Pitt } [systemd] systemd: ignores
keyscript in crypttab
Bug #786393 {Done: Martin Pitt } [systemd] systemd: keyscript
crypttab ignore, but booting ok with a annoying 1m30 delay
Disconnected #756202 from all other report(s).
> reopen 786393
Bug #786393 {Done: Martin Pitt } [systemd] systemd: keyscript
crypttab ignore, but booting ok with a annoying 1m30 delay
Bug #618862 {Done: Martin Pitt } [systemd] systemd: ignores
keyscript in crypttab
Bug reopened
Ignoring request to alter fixed versions of bug #786393 to the same values
previously set
Ignoring request to alter fixed versions of bug #618862 to the same values
previously set
> reopen 618862
Bug #618862 [systemd] systemd: ignores keyscript in crypttab
Bug #786393 [systemd] systemd: keyscript crypttab ignore, but booting ok with a
annoying 1m30 delay
Bug 618862 is not marked as done; doing nothing.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
618862: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618862
756202: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756202
786393: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786393
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#797039: systemd: Jessie won't boot if a filesystem in /etc/fstab is missing
First, thanks for your quick answer ! >I suppose this was the wrong entry? "Data" is not a valid device name. It is in a Virtualbox context. Once booted, "mount -a" mounts this partition to /mnt/Data, without any poblem. But it fails at boot, so I need to comment it, then modify /etc/fstab, then 'mount -a'. >So mark it as "defaults,nofail" to tell that this isn't a critical partition. Thanks for the hint. I have tested that, and it works, the virtual machine is able to boot now. But when doing a "mount -a" right after the boot, I get that : root@blah:/home/folco# mount -a unknown mount option `nofail' valid options: [...] So I still have to modify ym fstab in order to use my partition. Why can't it be mounted while booting ? ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#618862: Bug#786393: systemd: should not try to open encrypted devs that were already opened succesfully, workaround
Am 27.08.2015 um 10:28 schrieb Martin Pitt: > unmerge 756202 > reopen 786393 > reopen 618862 > thanks > > Meh, #756202 is something entirely different than #786393 and #618862. Yes and no. At least the bug report in [1] has cryptswap UUID=x-xxx---xdc3 sda4_crypt luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived,swap in his crypttab. So it's the same keyscript issue. But yeah, for the original bug reporter it might actually just be a broken UUID for the swap line in /etc/fstab. Michael [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756202#10 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#797048: systemd: obsolete conffile /etc/dbus-1/system.d/org.freedesktop.machine1.conf
Package: systemd Version: 224-2 User: debian...@lists.debian.org Usertags: adequate obsolete-conffile The package left obsolete conffile after upgrade: /etc/dbus-1/system.d/org.freedesktop.machine1.conf This bug was brought to you by adequate: https://packages.debian.org/unstable/main/adequate -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'experimental') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 4.1.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages systemd depends on: ii adduser 3.113+nmu3 ii libacl1 2.2.52-2 ii libapparmor12.9.2-3 ii libaudit1 1:2.4.4-1 ii libblkid1 2.26.2-9 ii libc6 2.19-19 ii libcap2 1:2.24-11 ii libcap2-bin 1:2.24-11 ii libcryptsetup4 2:1.6.6-5 ii libgcc1 1:5.2.1-12 ii libgcrypt20 1.6.3-2 ii libkmod221-1 ii liblzma55.1.1alpha+20120614-2.1 ii libmount1 2.26.2-9 ii libpam0g1.1.8-3.1 ii libseccomp2 2.2.3-1 ii libselinux1 2.3-2+b1 ii libsystemd0 224-2 ii mount 2.26.2-9 ii sysv-rc 2.88dsf-59.2 ii udev224-2 ii util-linux 2.26.2-9 -- Jakub Wilk ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#797048: systemd: obsolete conffile /etc/dbus-1/system.d/org.freedesktop.machine1.conf
Hi Jakub, Am 27.08.2015 um 12:09 schrieb Jakub Wilk: > Package: systemd > Version: 224-2 > User: debian...@lists.debian.org > Usertags: adequate obsolete-conffile > > The package left obsolete conffile after upgrade: > /etc/dbus-1/system.d/org.freedesktop.machine1.conf This is due to the package split in 224-2 and we were well aware of that before the upload. TTBOMK, there is no mechanism in Debian how you can transfer conffiles safely from on package to another. I'd be delighted to learn otherwise. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#797048: systemd: obsolete conffile /etc/dbus-1/system.d/org.freedesktop.machine1.conf
On 27 August 2015 at 07:48, Michael Biebl wrote: > Hi Jakub, > > Am 27.08.2015 um 12:09 schrieb Jakub Wilk: >> Package: systemd >> Version: 224-2 >> User: debian...@lists.debian.org >> Usertags: adequate obsolete-conffile >> >> The package left obsolete conffile after upgrade: >> /etc/dbus-1/system.d/org.freedesktop.machine1.conf > > This is due to the package split in 224-2 and we were well aware of that > before the upload. TTBOMK, there is no mechanism in Debian how you can > transfer conffiles safely from on package to another. > I'd be delighted to learn otherwise. > I think that rm_conffile in systemd + versioned depends in systemd-container will do it. A snippet should be added to systemd-container postinst that copies back the .dpkg-bak file if it exists to preserve user modifications. So, it should be: debian/systemd.maintscript: rm_conffile /etc/dbus-1/system.d/org.freedesktop.machine1.conf 224-2~ debian/systemd-container.postinst: if [ "$1" = configure ] && [ -z "$2" ] && \ [ -f /etc/dbus-1/system.d/org.freedesktop.machine1.conf.dpkg-bak ] ; then # copy stale file from systemd package on new installs mv /etc/dbus-1/system.d/org.freedesktop.machine1.conf.dpkg-bak \ /etc/dbus-1/system.d/org.freedesktop.machine1.conf fi systemd-container already conflicts older systemd versions, and depends on systemd, so this should work. I haven't tested this though, and the postinst condition could be expanded to include the nonconforming upload done but I'm not sure it is worth the trouble. -- Saludos, Felipe Sateler ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#797048: systemd: obsolete conffile /etc/dbus-1/system.d/org.freedesktop.machine1.conf
Am 27.08.2015 um 14:52 schrieb Felipe Sateler: > On 27 August 2015 at 07:48, Michael Biebl wrote: >> Hi Jakub, >> >> Am 27.08.2015 um 12:09 schrieb Jakub Wilk: >>> Package: systemd >>> Version: 224-2 >>> User: debian...@lists.debian.org >>> Usertags: adequate obsolete-conffile >>> >>> The package left obsolete conffile after upgrade: >>> /etc/dbus-1/system.d/org.freedesktop.machine1.conf >> >> This is due to the package split in 224-2 and we were well aware of that >> before the upload. TTBOMK, there is no mechanism in Debian how you can >> transfer conffiles safely from on package to another. >> I'd be delighted to learn otherwise. >> > > I think that rm_conffile in systemd + versioned depends in > systemd-container will do it. > > A snippet should be added to systemd-container postinst that copies > back the .dpkg-bak file if it exists to preserve user modifications. > > So, it should be: > > debian/systemd.maintscript: > rm_conffile /etc/dbus-1/system.d/org.freedesktop.machine1.conf 224-2~ > > debian/systemd-container.postinst: > > if [ "$1" = configure ] && [ -z "$2" ] && \ >[ -f /etc/dbus-1/system.d/org.freedesktop.machine1.conf.dpkg-bak ] ; then > # copy stale file from systemd package on new installs > mv /etc/dbus-1/system.d/org.freedesktop.machine1.conf.dpkg-bak \ > /etc/dbus-1/system.d/org.freedesktop.machine1.conf > fi > > systemd-container already conflicts older systemd versions, and > depends on systemd, so this should work. > > I haven't tested this though, and the postinst condition could be > expanded to include the nonconforming upload done but I'm not sure it > is worth the trouble. Some more background: https://lists.debian.org/debian-devel/2006/12/msg00647.html https://lists.debian.org/debian-devel/2012/02/msg00349.html Still an unsolved problem afaics. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: Re: dh_systemd: should preserve static masks between remove and purge
Processing commands for cont...@bugs.debian.org: > reassign 796884 dh-systemd 1.23 Bug #796884 [systemd] dh_systemd: should preserve static masks between remove and purge Bug reassigned from package 'systemd' to 'dh-systemd'. No longer marked as found in versions 1.23. Ignoring request to alter fixed versions of bug #796884 to the same values previously set Bug #796884 [dh-systemd] dh_systemd: should preserve static masks between remove and purge Marked as found in versions init-system-helpers/1.23. > thanks Stopping processing here. Please contact me if you need assistance. -- 796884: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796884 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Bug#796603: keyboard-configuration: Has init script in runlevel S but no matching service file
On 23 August 2015 at 09:56, Cyril Brulebois wrote: > Hi, > > fsate...@debian.org (2015-08-22): >> Package: keyboard-configuration >> Severity: important >> User: pkg-systemd-maintainers@lists.alioth.debian.org >> Usertags: init-rcs-service > > (maintonly considered slightly annoying.) > >> Hi, >> >> Your package keyboard-configuration has an initscript that is enabled >> in runlevel S, but it does not provide a corresponding systemd >> service unit. >> >> Systemd generates units for all sysv init scripts that do not have a >> corresponding systemd unit. By default, it sets >> DefaultDependencies=yes, which means they get ordered after early >> boot has finished. >> >> The problem is that to preserve the runlevel S semantics, systemd in >> debian is currently[1] ordering all S services Before=sysinit.target. >> This target is particularly early in the boot sequence, which means >> that it is most of the time too strict. In turn, this means it is >> fairly easy to end up with dependency cycles. For an example, see bug >> [763315]. Do note that the cycle still exists with sysvinit, it is >> just that systemd complains more loudly. >> >> Please add a systemd unit for the given service with the appropriate >> dependencies, which most of the time will be less strict than >> Before=sysinit.target. In other cases, the script is simply not >> applicable in systemd, in which case the package should ship a >> symlink to /dev/null as /lib/systemd/system/.service. >> >> We have prepared a transition wiki page[2] explaining the issue in >> more detail, and outlining some general guidance. Please refer to it >> as it will have useful information. >> >> If you have any other doubts, feel free to ask in >> pkg-systemd-maintainers@lists.alioth.debian.org > > (Talking more as d-i RM than possible comaintainer, which I'm not.) > > src:console-setup could probably do with more hands on it, especially > given (very friendly) bug reports like #763695. If you guys had any time > to spend on making sure boot time dependencies are correct, and possibly > that boot time performances improve over time, that would be much > appreciated. Does console-setup actually need to be run before user services are started? My guess is that it only needs to run before getty, but it should not block other services that want to start. If someone could answer that question it should be very simple to provide a patch for this. -- Saludos, Felipe Sateler ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#797108: init-system-helpers: deb-systemd-helper doesn't remove old links when changing WantedBy= at package upgrade
Package: init-system-helpers
Version: 1.23
Severity: normal
Tags: patch
Dear Maintainer,
if a package in version 1 had WantedBy=a.target and this is changed
to WantedBy=b.target in version 2 of that package, deb-systemd-helper
will properly create the links in b.target.wants/, but will not remove
the links in a.target.wants/. Same goes with changes in Alias= and
changes in Also=.
I've attached a patch to this bug report that fixes this.
Note that any additional links that were manually created by the
administrator will not be touched, only those that were created by
deb-systemd-helper in the first place. The only use case that is
not covered by this patch is if an administrator wanted to keep a
link that was auto-created (there is no way to distinguish them),
but that seems to be quite unlikely (and the administrator could
re-create it later - and it would then stay, even if the same
version of the package were to be installed again - only upgrades
will remove links).
I've also attached a trivial package in two versions to test this.
They change all 3 options (WantedBy=, Also= and Alias=) to test
everything at the same time. Just extract the source tarballs and
build the native packages if you want to test this.
Please change the commit message of the patch so that it reflects
the bug number it closes when you apply it to git.
Regards,
Christian
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.1.0-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages init-system-helpers depends on:
ii perl-base 5.20.2-6
init-system-helpers recommends no packages.
init-system-helpers suggests no packages.
-- no debconf information
From 38aa3cc8c1390a9ae5ba047faf4cae3b3674286c Mon Sep 17 00:00:00 2001
From: Christian Seiler
Date: Thu, 27 Aug 2015 22:13:15 +0200
Subject: [PATCH] deb-systemd-helper: Remove obsolete links on package upgrades
For changes in WantedBy=, Also= and Alias= it could be the case that
links become optional when a package is upgraded and deb-systemd-helper
is called. Specifically, if something is removed from those lists,
the old links would stay around.
This patch addresses that by calculating the list of links in the state
file on upgrades that are not present in the newly calculated link
closure. Those links were part of the old link closure, so they were in
WantedBy=, Also= or Alias= lines of the old package - so they should
now be removed, since they are not anymore part of those lines.
Any additional links that the administrator may have added themselves
in other places (other .wants/ directories, for example) will not be
touched by this logic.
Closes: #...
---
script/deb-systemd-helper | 21 +
1 file changed, 21 insertions(+)
diff --git a/script/deb-systemd-helper b/script/deb-systemd-helper
index 2a87cb4..0210814 100755
--- a/script/deb-systemd-helper
+++ b/script/deb-systemd-helper
@@ -224,12 +224,16 @@ sub make_systemd_links {
my $dsh_state = dsh_state_path($scriptname);
my @links = get_link_closure($scriptname, $service_path);
+my @oldlinks = state_file_entries($dsh_state);
+
for my $link (@links) {
my $service_path = $link->{dest};
my $service_link = $link->{src};
record_in_statefile($dsh_state, $service_link);
+@oldlinks = grep { $_ ne $service_link } @oldlinks;
+
my $statefile = $service_link;
$statefile =~ s,^/etc/systemd/system/,$enabled_state_dir/,;
next if -e $statefile;
@@ -251,6 +255,23 @@ sub make_systemd_links {
close($fh);
}
+debug "Old links to remove (due to modified service file): " .
+Data::Dumper::Dumper([ @oldlinks ]);
+
+# On package upgrade, some old links might be in need of removal
+# (because e.g. WantedBy= changed), so remove those, if they exist.
+for my $link (@oldlinks) {
+# If the administrator deleted the real link themselves, don't
+# remove the state links (to remember enablement state).
+next unless -l $link;
+
+my $link_state = $link;
+$link_state =~ s,^/etc/systemd/system/,$enabled_state_dir/,;
+unlink($link_state);
+
+unlink($link) or
+print STDERR "$0: unable to remove '$link': $!\n";
+}
}
# In contrary to make_systemd_links(), which only modifies the state file in an
--
2.5.0
testpkg_42.tar.xz
Description: application/xz
testpkg_43.tar.xz
Description: application/xz
signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#732209: systemd, gnome, gnome-settings-daemon
Hello, Sorry for my English - it's not my native language. I can reproduce bug in 3 machines: 1. PC: C2D E6400 with GF 8400GS (PCIE) 2. Notebook: i5-2430M with GF 520MX. 3. VMWare Player 7 on notebook with W8.1, i5-5200U, Intel HD (no NV GPU) File: debian-8.1.0-amd64-CD-1.iso (stable) In my case (the same install procedure for 3 machines): Debian 8.1 installed from USB (created by RUFUS, on VM directly from ISO). What I do: 1. Install Debian without graphic desktop. 2. Login. 3. Install sysvinit, sysvinit-core, sysvinit-utils. 4. Reboot. 5. Install MC. 6. Remove CD from repo list in /etc/apt/sources.lst with mcedit. 7. Remove systemd with --purge and --auto-remove. 8. Ban package 'systemd-sysv' with local-pin-init file (as described in update guide) with mcedit. 9. Install gnome. 10. Reboot. 11. Login as regular user (user name: u or user). What I know: 1. I don't think, that all above needs to be done. Other users report bug on standard installation (with systemd). 2. It's hard to reproduce bug because (probably?) there must be an issue with gnome menu to make this bug "working". How to find out, if machine has a bug? When you run game Nibbles, there is no menu there! The same thing for keyboard layout, other games and apps (but not all - maybe its QT, GTK issue etc). Example: http://i.imgur.com/RLedPOM.png 3. Gnome hangs only when you're using root permission with "remember for this session". 4. Maybe (I',m not sure) there must be autologin option turned on. 5. It works (probably) only on standard GNOME (not gnome classic, not gnome wayland). 6. Removing '/usr/lib/gnome-settings-daemon-3.0/keyboard.gnome-settings-plugin' (as described in web) will NOT fix that. How to reproduce? It's quite easy: 1. After login, run root terminal (enter root password, check remember for session - here is your strange root permission/uid for the file created). Probably now you could close terminal, but let it stay on. 2. Open Nibbles and click coupe times in place, where menu should be, move window, click once again. Close it. 3. Open language list from system bar, click show layout. Should be menu there? Probably yes. Click couple times, move window, close. 4. Click on terminal. 5. Click top left corner (superbutton/supermenu or as you called) 6. And it's gene... Animation is stopped (for example file download/GDebi progress bar) or whatever you do in background, mouse working. I can do Ctrl+Alt+F(x) do open another tty. I can log on as root. In HTOP I see high cpu usage by gnome-settings-daemon. Stopping this process don't change anything - gnome not responding. I also see dconf errors described above. Temporary solution is do this: 1. (optionally?) remove '/run/user/1000/dconf/user' file 2. kill gnome-shell process. Then switch to Ctrl+Alt+F7, wait few seconds and gnome start working. Extra info: In gnome-tweak-tool I've switched on minimize/maximize buttons. In theme section, in last position "shell theme" select box is empty, and there is red exclamation sign next to the select box. Bug is also in MATE an Cinnamon, because both has systemd in depend tree (like gnome) - LXDE/XFCE dont use it, so both are safe. Need proof? When you try to use this instruction (with systemd lock): https://community.spiceworks.com/how_to/117634-gnu-linux-debian-without-systemd This will happen: - your gnome would be removed with systemd - after systemd lock, you would not be able to install gnome, mate, cinnamon due dependencies (lxde,xfce install without problem) Regards, Wiktor ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#787191: Bug#776192: Linux null-pointer deref in 3.16.7-ctk2-1 (was: Bug#776192: upgrade-reports wheezy to jessie boot problem)
Please, oh please, oh, please, can you get this in before 8.2 ?? I'm dealing with this problem yet again today, as another failed Jessie install was done by someone else on an affected system (it's now currently non-booting with no known workaround using stock Jessie). --stephen -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/ ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#797131: udev kernel check during Wheezy->Jessie upgrade should happen earlier
Package: udev Version: 175-7.2 Severity: serious Justification: Policy 7.2 Dear Maintainer, * What led up to the situation? Upgrading my armhf system Wheezy->Jessie. Did the usual searches for dependencies and what-not. Did a pre-download, then ran the upgrade. About half the packages were churned, and then udev declares: Since release 198, udev requires support for the following features in the running kernel: - inotify(2)(CONFIG_INOTIFY_USER) - signalfd(2) (CONFIG_SIGNALFD) - accept4(2) - open_by_handle_at(2) (CONFIG_FHANDLE) - timerfd_create(2) (CONFIG_TIMERFD) - epoll_create(2) (CONFIG_EPOLL) Please upgrade your kernel before or while upgrading udev. and the upgrade fails. I'd be happy to reconfigure my kernel, but with half my files upgraded and the other half not, my system was not well enough to do anything. * What exactly did you do (or not do) that was effective (or ineffective)? I'm not an idiot; I had a full backup and restored my system. * What was the outcome of this action? Failed upgrade. New required kernel features (it'd be nice if that was listed somewhere). * What outcome did you expect instead? If the kernel is not acceptable for the upgrade, it should be detected before the upgrade starts. The kernel check should not happen after the filesystem has been modified with some upgraded content. An upgrade should never start if it can be determined that it can't complete successfully. -- System Information: Debian Release: 7.8 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: armhf (armv7l) Kernel: Linux 3.4.75+ (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/dash Versions of packages udev depends on: ii debconf [debconf-2.0] 1.5.49 ii libc6 2.13-38+deb7u8 ii libgcc11:4.7.2-5 ii libselinux12.1.9-5 ii libudev0 175-7.2 ii lsb-base 4.1+Debian8+deb7u1 ii procps 1:3.3.3-3 ii util-linux 2.20.1-5.3 Versions of packages udev recommends: ii pciutils 1:3.1.9-6 ii usbutils 1:005-3 udev suggests no packages. -- debconf information: udev/new_kernel_needed: false udev/title/upgrade: udev/reboot_needed: udev/sysfs_deprecated_incompatibility: ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#797131: udev kernel check during Wheezy->Jessie upgrade should happen earlier
Control: severity 797131 minor On Aug 28, Andy Valencia wrote: > If the kernel is not acceptable for the upgrade, it should be detected > before the upgrade starts. The kernel check should not happen after the > filesystem has been modified with some upgraded content. An upgrade > should never start if it can be determined that it can't complete > successfully. I do not think that there is anything else that udev can do, since the check is done in udev.preinst. Also, I suspect that you were running a custom kernel, so this would not happen during normal upgrades. -- ciao, Marco pgpF0oBI2cCeP.pgp Description: PGP signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: Re: Bug#797131: udev kernel check during Wheezy->Jessie upgrade should happen earlier
Processing control commands: > severity 797131 minor Bug #797131 [udev] udev kernel check during Wheezy->Jessie upgrade should happen earlier Severity set to 'minor' from 'serious' -- 797131: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797131 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#797108: init-system-helpers: deb-systemd-helper doesn't remove old links when changing WantedBy= at package upgrade
On 27 August 2015 at 17:19, Christian Seiler wrote: > > Package: init-system-helpers > Version: 1.23 > Severity: normal > Tags: patch > > Dear Maintainer, > > if a package in version 1 had WantedBy=a.target and this is changed > to WantedBy=b.target in version 2 of that package, deb-systemd-helper > will properly create the links in b.target.wants/, but will not remove > the links in a.target.wants/. Same goes with changes in Alias= and > changes in Also=. > > I've attached a patch to this bug report that fixes this. > > Note that any additional links that were manually created by the > administrator will not be touched, only those that were created by > deb-systemd-helper in the first place. The only use case that is > not covered by this patch is if an administrator wanted to keep a > link that was auto-created (there is no way to distinguish them), > but that seems to be quite unlikely (and the administrator could > re-create it later - and it would then stay, even if the same > version of the package were to be installed again - only upgrades > will remove links). > > I've also attached a trivial package in two versions to test this. > They change all 3 options (WantedBy=, Also= and Alias=) to test > everything at the same time. Just extract the source tarballs and > build the native packages if you want to test this. The test packages only have test-changes.service differ, the other 2 are the same in both versions... But I checked that the link is removed if it was existing, a new one I created is preserved, and if I remove an enable link, then the disabled state is preserved to the new name (ie, when moving from targetA to targetB if I disable in targetA then it won't be enabled in targetB). However, (and I don't know if this is new or not), the state does not seem to be removed on package purge: I removed a target, purged the package, then reinstalled the package and the enable link was not generated. -- Saludos, Felipe Sateler ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
