Bug#803265: bluetooth.service: sap-server: Operation not permitted (1)
In the context of Bluetooth, "sap" refers to the SIM Access Profile, designed to allow mobile phones to lend the use of their SIM or USIM cards over Bluetooth to car handsfree kits that have their own mobile phone radio module, which may have greater transmitter power and a better antenna for use on the road than a hand-held phone in the user's pocket. The BlueZ stack attempts to register a SAP server, which will be useful only if the system has a mobile phone SIM or USIM card and the user is willing to lend its use to external devices. As packaged, the SAP server component no longer has any actual implementation to access a card reader: the upstream removed the last actual implementation (for the long-dead STE U8500 platform) in 2017-07-13. Only the dummy implementation in sap-dummy.c is left: https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/profiles/sap?id=3a140aa35b7b7dc1d7b031eec40590187f70a980 The dummy implementation will attempt to register a D-Bus interface "org.bluez.SimAccessTest1", which is not covered by the packaged D-Bus configuration file (src/bluetooth.conf). As a result, registering the SIM Access Profile will always fail. The failure of the SAP driver won't normally stop BlueZ bluetoothd from operating, but it often results in the first error message from BlueZ even in situations where the Bluetooth radio is not operable (e.g. because of missing firmware), so it tends to confuse users who don't know what the Bluetooth SAP profile is, and lead them astray in their troubleshooting. Sharing access to a SIM/USIM card is a security-sensitive operation, as with it, an external device equipped with a mobile phone radio module could place and receive calls and/or transfer data over the mobile phone network, which could incur costs to the card owner. The SIM/USIM keys can sometimes also be used to allow access to WiFi networks (see wpa_supplicant and its EAP-SIM functionality). It could also provide access to contacts information stored on the card, which is often highly personal data. The SAP profile allows raw APDU access to the SIM card, so it would enable any arbitrary SIM card operations to be performed. For all these reasons, it might be a good idea to default to have the SIM Access Profile cleanly disabled unless the user explicitly wants to enable it. Starting bluetoothd with the option "--noplugin=sap" by default (as already suggested) would be one way to do it. Another way would be to patch the `bootstrap-configure` file in the source root directory, to change `--enable-sap` to `--disable-sap`. In its current form, the SIM Access Profile support of BlueZ is only useful for developers, and even that requires modifying /etc/dbus-1/system.d/bluetooth.conf before it will do anything other than display an error message on Bluetooth service start-up. This is true of both the version in bullseye and the current unstable version. -- matti.kurk...@iki.fi
Bug#994726:
Sorry about the late reply. It seems my spam filter ate the messages from bugs.debian.org - I'll fix that. I can't test the https://github.com/miniupnp/miniupnp/pull/562 PR right now, but reading through it, it certainly appears to achieve the same goal, while also including some miniupnpd source code changes for merging the two miniupnpd-related NAT chains into one. That will allow the scripts to be even more straightforward than my patched version. Looks good to me. I hope it gets merged soon. -- matti.kurk...@iki.fi
Bug#995452: libpam-ssh breaks the agent-forwarding of normal ssh
Looks like my spam filter ate the notification that you answered, and/or since my post was "additional information only", I did not get a notification in the first place. My /etc/pam.d/sddm: (lines wrapped by email client marked with \) - #%PAM-1.0 # Block login if they are globally disabled authrequisite pam_nologin.so authrequiredpam_succeed_if.so user != root quiet_success # authsufficient pam_succeed_if.so user ingroup nopasswdlogin @include common-auth # gnome_keyring breaks QProcess -auth optionalpam_gnome_keyring.so -auth optionalpam_kwallet5.so -auth optionalpam_ssh.so use_first_pass @include common-account # SELinux needs to be the first session rule. This ensures that any # lingering context has been cleared. Without this it is possible that a # module could execute code in the wrong domain. session [success=ok ignore=ignore module_unknown=ignore default=bad] \ pam_selinux.so close # Create a new session keyring. session optionalpam_keyinit.so force revoke session requiredpam_limits.so session requiredpam_loginuid.so @include common-session # SELinux needs to intervene at login time to ensure that the process \ starts # in the proper default security context. Only sessions which are \ intended # to run in the user's context should be run after this. session [success=ok ignore=ignore module_unknown=ignore default=bad] \ pam_selinux.so open -session optional pam_gnome_keyring.so auto_start -session optional pam_kwallet5.so auto_start -session optional pam_ssh.so @include common-password # From the pam_env man page # Since setting of PAM environment variables can have side effects to \ other modules, this module should be the last one on the stack. # Load environment from /etc/environment session requiredpam_env.so # Load environment from /etc/default/locale and ~/.pam_environment session requiredpam_env.so envfile=/etc/default/locale \ user_readenv=1 - And my /etc/pam.d/login: - # # The PAM configuration file for the Shadow `login' service # # Enforce a minimal delay in case of failure (in microseconds). # (Replaces the `FAIL_DELAY' setting from login.defs) # Note that other modules may require another minimal delay. (for \ example, # to disable any delay, you should add the nodelay option to pam_unix) auth optional pam_faildelay.so delay=300 # Outputs an issue file prior to each login prompt (Replaces the # ISSUE_FILE option from login.defs). Uncomment for use # auth required pam_issue.so issue=/etc/issue # Disallows other than root logins when /etc/nologin exists # (Replaces the `NOLOGINS_FILE' option from login.defs) auth requisite pam_nologin.so # SELinux needs to be the first session rule. This ensures that any # lingering context has been cleared. Without this it is possible # that a module could execute code in the wrong domain. # When the module is present, "required" would be sufficient \ (When SELinux # is disabled, this returns success.) session [success=ok ignore=ignore module_unknown=ignore default=bad] \ pam_selinux.so close # Sets the loginuid process attribute sessionrequired pam_loginuid.so # Prints the message of the day upon successful login. # (Replaces the `MOTD_FILE' option in login.defs) # This includes a dynamically generated part from /run/motd.dynamic # and a static (admin-editable) part from /etc/motd. sessionoptional pam_motd.so motd=/run/motd.dynamic sessionoptional pam_motd.so noupdate # SELinux needs to intervene at login time to ensure that the process # starts in the proper default security context. Only sessions which are # intended to run in the user's context should be run after this. # pam_selinux.so changes the SELinux context of the used \ TTY and configures # SELinux in order to transition to the user context with the next \ execve() # call. session [success=ok ignore=ignore module_unknown=ignore default=bad] \ pam_selinux.so open # When the module is present, "required" would be sufficient (When \ SELinux # is disabled, this returns success.) # This module parses environment configuration file(s) # and also allows you to use an extended config # file /etc/security/pam_env.conf. # # parsing /etc/environment needs "readenv=1" session required pam_env.so readenv=1 # locale variables are also kept into /etc/default/locale in etch # reading this file *in addition to /etc/environment* does not hurt session required pam_env.so readenv=1 envfile=/etc/default\ /locale # Standard Un*x authentication. @include common-auth # This allows certain extra groups to be granted to a user # based on things like time of day, tty, service, and user. # Please edit /etc/security/group.conf to fit your needs # (Replaces the `CONSOLE_GROUPS' option in login.defs) auth
Bug#995452: libpam-ssh breaks the agent-forwarding of normal ssh
The workaround/fix for this would be to not let pam-auth-update add pam_ssh.so into common-auth and common-session, but add the necessary lines *selectively* only to services that handle local logins like /etc/pam.d/login and /etc/pam.d/*dm, but *not* to /etc/pam.d/sshd. That should allow libpam-ssh to start the agent on initial login, but leave the SSH sessions and their agent forwarding alone. If you need the "authentication by SSH key passphrase" functionality on SSH connections, you could add only the "auth optional pam_ssh.so try_first_pass" line to /etc/pam.d/sshd. (Note that this line should not be the first authentication module, to prevent an information leak, as described in the pam_ssh(8) man page.)
Bug#994726: miniupnpd-nftables scripts eat iptables-nft NAT rules on exit
Package: miniupnpd-nftables
Version: 2.2.1-1
Severity: normal
Tags: patch
Dear Maintainer,
I have a manually-crafted set of firewall rules, currently using
iptables-nft but still heavily based on classic iptables way of doing
things.
On update from Debian 10 to 11, miniupnpd transitioned to the use of
miniupnpd-nftables, as expected. But I was surprised to find that after
the transition, my existing NAT rules unrelated to miniupnpd had started
vanishing every time I stopped the miniupnpd service.
On examination of the nft_removeall.sh script, it turns out it runs "nft
delete table nat", which removes any NAT rules created using
iptables-nft's "iptables -t nat" command. As the comment at the
beginning of the script says "Do not disturb other existing structures
in nftables", this must not have been the intention.
I also noticed that the stub chains generated by /etc/miniupnpd/nft_init.sh
seem to be completely unused by the actual daemon, and the rules the
daemon creates won't match the stub chains. In fact, it looks like the
daemon might be able to work just fine without the nft_init script at
all.
On further investigation, I found that the daemon creates three
Netfilter tables, all named "miniupnpd":
* an ip6 table with two NAT chains
* an ip (=IPv4-only) table with two NAT chains
* an inet (=IPv4/v6) table with a single filter chain
The default names for the tables and the chains did match neither what the
scripts used, nor the commented-out values in the miniupnpd.conf file.
The defaults can be found in the source code file
miniupnpd-2.2.1/netfilter_nft/nftnlrdr_misc.c, lines 66-69.
The name of the tables created by the daemon is clearly intended to be
configurable in the source code, but the configuration file processing
code does not yet define an option to change it away from default.
I cleaned up the scripts to match the assumed intent and the actual
behavior of miniupnpd-nftables, and now it seems to work fine: see patch below.
I created variables at the beginning of each script to match the chain
name configuration options in miniupnpd.conf. I also added a variable
for the table name, in the assumption that the actual configuration
option might eventually be added.
I made the nft commands in the scripts explicitly specify the address
family in each case, to make it more obvious what the scripts will do.
Since existing documentation is rather sparse, this might be the
next best thing.
diff -rup miniupnpd-2.2.1/netfilter_nft/scripts.orig/nft_delete_chain.sh
miniupnpd-2.2.1/netfilter_nft/scripts/nft_delete_chain.sh
--- miniupnpd-2.2.1/netfilter_nft/scripts.orig/nft_delete_chain.sh
2019-06-26 00:30:54.0 +0300
+++ miniupnpd-2.2.1/netfilter_nft/scripts/nft_delete_chain.sh 2021-09-20
01:05:14.457155573 +0300
@@ -1,5 +1,14 @@
#!/bin/sh
-nft delete chain nat MINIUPNPD
-nft delete chain nat MINIUPNPD-POSTROUTING
-nft delete chain filter MINIUPNPD
+# If you modify the corresponding settings in miniupnpd.conf,
+# change these variables in the scripts too.
+upnp_table=miniupnpd
+upnp_forward_chain=forward
+upnp_nat_chain=prerouting
+upnp_nat_postrouting_chain=postrouting
+
+nft delete chain ip ${upnp_table} ${upnp_nat_chain}
+nft delete chain ip ${upnp_table} ${upnp_nat_postrouting_chain}
+nft delete chain inet ${upnp_table} ${upnp_forward_chain}
+nft delete chain ip6 ${upnp_table} ${upnp_nat_chain}
+nft delete chain ip6 ${upnp_table} ${upnp_nat_postrouting_chain}
diff -rup miniupnpd-2.2.1/netfilter_nft/scripts.orig/nft_display.sh
miniupnpd-2.2.1/netfilter_nft/scripts/nft_display.sh
--- miniupnpd-2.2.1/netfilter_nft/scripts.orig/nft_display.sh 2019-06-26
00:26:46.0 +0300
+++ miniupnpd-2.2.1/netfilter_nft/scripts/nft_display.sh2021-09-20
01:05:24.707083374 +0300
@@ -1,8 +1,19 @@
#!/bin/sh
-# Prerouting
-nft list chain ip nat MINIUPNPD
-# Postrouting
-nft list chain ip nat MINIUPNPD-POSTROUTING
-# Filter
-nft list chain inet filter MINIUPNPD
+# If you modify the corresponding settings in miniupnpd.conf,
+# change these variables in the scripts too.
+upnp_table=miniupnpd
+upnp_forward_chain=forward
+upnp_nat_chain=prerouting
+upnp_nat_postrouting_chain=postrouting
+
+# IPv6 prerouting
+nft list chain ip6 ${upnp_table} ${upnp_nat_chain}
+# IPv6 postrouting
+nft list chain ip6 ${upnp_table} ${upnp_nat_postrouting_chain}
+# IPv4 prerouting
+nft list chain ip ${upnp_table} ${upnp_nat_chain}
+# IPv4 postrouting
+nft list chain ip ${upnp_table} ${upnp_nat_postrouting_chain}
+# IPv4/v6 filter
+nft list chain inet ${upnp_table} ${upnp_forward_chain}
diff -rup miniupnpd-2.2.1/netfilter_nft/scripts.orig/nft_flush.sh
miniupnpd-2.2.1/netfilter_nft/scripts/nft_flush.sh
--- miniupnpd-2.2.1/netfilter_nft/scripts.orig/nft_flush.sh 2019-06-26
00:30:54.0 +0300
+++ miniupnpd-2.2.1/netfilter_nft/scripts/nft_flush.sh 2021-09-20
01:05:35.473674198 +0300
@@ -1,5 +1,14 @@
#!/bin/sh
-nft flush chain ip nat MINIUPNPD
-nft flush chain ip nat MINIUPNPD-POSTROUTING
Bug#981236: miniupnpd: Syslogging is overly verbose due to the -d option
"Extremely verbose" indeed - it can produce gigabytes of log data in a single day. Before I applied the workaround below, it filled the root disk of my home server system three times. Unfortunately it looks like the version in Bullseye does not have the "start_daemon" configuration file option. As a workaround, you might want to create a /etc/systemd/system/miniupnpd.service.d/override.conf file with the following contents: cut here [Service] Type=forking ExecStart= ExecStart=/usr/sbin/miniupnpd -f /etc/miniupnpd/miniupnpd.conf \ $MiniUPnPd_OTHER_OPTIONS cut here (Note: backslash denotes a line split because of email formatting restriction.) After creating the override file (and probably also the miniupnpd.service.d directory to hold it), run "systemctl daemon-reload", then "systemctl restart miniupnpd". The use of "Type=forking" is not optimal, but that's probably best you can do unless you're willing to rebuild the package from source.
Bug#992350: ifupdown-extra: Hardcoded "wlan0" in /etc/network/if-up.d/10check-duplicate-ip6
Package: ifupdown-extra
Version: 0.32
Severity: normal
Tags: ipv6 patch
Dear Maintainer,
When adding package "ifup-extra" on a fresh installation of Debian 11,
I started getting error messages referring to "wlan0" at ifup time.
This was unexpected as this system had no interface named "wlan0"
at the time.
An easy grep revealed that /etc/network/if-up.d/10check-duplicate-ip6
had a hard-coded reference to network interface "wlan0" where a
variable was supposed to be used.
Here's a patch to fix it:
--- 10check-duplicate-ip6.old 2021-08-17 18:22:03.02908 +0300
+++ 10check-duplicate-ip6 2021-08-17 18:22:53.037696969 +0300
@@ -70,7 +70,7 @@ do_ndisc() {
# First determine physical interface in case aliased interfaces are used
real_iface=$(echo "$IFACE" | sed -e 's|:[[:digit:]]\+||')
-link_address=$(ip link show wlan0 | grep link | awk '{print
toupper($2)}')
+link_address=$(ip link show "$real_iface" | grep link | awk '{print
toupper($2)}')
if [ -z "`ip link show $real_iface up`" ]; then
return
-- System Information:
Debian Release: 11.0
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 5.10.0-8-686 (SMP w/1 CPU thread)
Locale: LANG=en_US.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages ifupdown-extra depends on:
ii bind9-host [host]1:9.16.15-1
ii curl 7.74.0-1.3+b1
ii dpkg 1.20.9
ii iproute2 5.10.0-4
ii iputils-arping 3:20210202-1
ii iputils-ping [ping] 3:20210202-1
ii lsb-base 11.1.0
ii net-tools1.60+git20181103.0eebece-1
ii netcat-openbsd 1.217-3
Versions of packages ifupdown-extra recommends:
ii ethtool 1:5.9-1
ii ndisc6 1.0.4-2
ifupdown-extra suggests no packages.
-- Configuration Files:
/etc/network/if-up.d/10check-duplicate-ip6 changed:
DEFAULT=/etc/default/network-test
[ -r "$DEFAULT" ] && . $DEFAULT
[ "$DO_ARPING" = "no" ] && exit 0
NDISC=/usr/bin/ndisc6
[ ! -x "$NDISC" ] && exit 0 # Silent exit if ndisc is not installed
DO_SYSLOG=${DO_SYSLOG:-yes}
VERBOSITY=${VERBOSITY:-0}
LC_ALL=C
export LC_ALL
if [ "$DO_SYSLOG" = "yes" ] ; then
OUTPUT="logger -i -p daemon.err -s"
else
OUTPUT="echo"
fi
do_ndisc() {
real_iface=$(echo "$IFACE" | sed -e 's|:[[:digit:]]\+||')
link_address=$(ip link show $real_iface | grep link | awk '{print
toupper($2)}')
if [ -z "`ip link show $real_iface up`" ]; then
return
fi
for ADDR in $IF_ADDRESS; do
# Only check IP address if it is IPv6
if echo ${ADDR} | grep -q ":" ; then
[ "$VERBOSITY" -eq 1 ] && $OUTPUT "DEBUG: Sending arp pings
through $real_iface (for $IFACE) to detect other systems using $ADDR"
dup_link_address=$($NDISC -q $ADDR $real_iface)
if [ $? -eq 0 ] ; then
# If the link address is the same as our address this is
not a problem
# (ndisc returns it in at least Wireless interfaces), only
report if the link
# address does not match
if [ "$link_address" != "$dup_link_address" ] ; then
$OUTPUT "ERROR: Duplicate address $ADDR assigned in the
network where $real_iface is connected to."
fi
fi
fi
done
}
find_ip6() {
export IF_ADDRESS
IF_ADDRESS=$(ip addr show "$IFACE" 2>/dev/null | sed -rne
's|^[[:blank:]]*inet6[[:blank:]]+([^/]+)/.*|\1|p')
return 0
}
if [ -z "$IFACE" ] ; then
echo "ERROR: Do not know what interface to check. IFACE environment
variable is not defined!" >&2
exit 1
fi
case $IFACE in
sl* | ww* | lo*) exit 0 ;;
*) ;;
esac
[ -z "$IF_ADDRESS" ] && find_ip6
[ -z "$IF_ADDRESS" ] && exit 0
do_ndisc
exit 0
-- no debconf information
Bug#625758: [Adduser-devel] Bug#625758: 'adduser --disabled-login' does not behave as documented.
As far as I understand, different implementations had different ways to specify the semantics of “disabling the account”. So the developers of the passed command went to look for details that would be un-ambiguous in all implementations, and this seems to be what they found: - neither an asterisk nor an exclamation mark in the first character of the password hash file alone can be unambiguously interpreted as “disabling the account”, because there are conflicting implementations - however, setting the account expiration date to a non-null value that is in the past was found to be a totally unambiguous way to disable an account without losing any account details that might be under user’s (limited) control, like the user’s shell setting. - setting the account’s shell to a non-usable value should not be the only way to mark the account as “no logins of any type allowed”, since there are plenty of valid use cases for accounts with a valid shell but logins disabled. So the resulting password/account management options relevant to this discussion after all was said and done are now: - an exclamation mark in the first (or only) character of the password hash field = a (possibly-temporary) administrative lock on password authentication for his user. *Can be unlocked* without changing the existing password, even if the existing password is null. - an asterisk as the first (or only) character of the password hash field = a (possibly-permanent) lock on password authentication. Undoing this with standard commands requires setting a new password, or an explicit decision to set a null password. - a non-null “account expiration date” value that is not 0 and is in the past = account is disabled. This can (and probably should) be used together with one of the previous options when creating an application account that should never have an ability to login, but is usable with sudo or a similar mechanism. As a result, the —disabled-login option of the adduser command won’t do what it claims to do, if authentication mechanisms other than password authentication are in use. Example: if the sysadmin uses “adduser --disabled-login” to create an application user account, and an attacker manages to fool the application into writing a valid ~/.ssh/authorized_keys file, it turns out that the supposedly-disabled account now allows SSH key authenticated login for the attacker. This is unexpected. The fix: “adduser --disabled-login" needs to perform an explicit “usermod --expiredate 1” or equivalent in addition to what it does now. After the changes made to the passwd command in 2008, “passwd -l” will no longer do that for you.
Bug#799295: Workaround for stretch
While waiting for a solution, the following workaround seems to work for
Stretch at least:
Step 1.)
Copy /usr/share/initramfs-tools/scripts/local-top/cryptroot to
/etc/initramfs-tools/scripts/local-top/cryptroot.
# cp /usr/share/initramfs-tools/scripts/local-top/cryptroot \
/etc/initramfs-tools/scripts/local-top/
Step 2.)
Modify the copied version as follows:
--- /usr/share/initramfs-tools/scripts/local-top/cryptroot
2017-05-09 14:50:59.0 +0300
+++ /etc/initramfs-tools/scripts/local-top/cryptroot2018-07-04
13:29:15.787061513 +0300
@@ -172,8 +172,9 @@
fi
# Detect and activate available volume groups
- /sbin/lvm vgscan
- /sbin/lvm vgchange -a y --sysinit
+ # Workaround: disable use of lvmetad since it's not running yet
+ /sbin/lvm vgscan --config 'global{use_lvmetad=0}'
+ /sbin/lvm vgchange -a y --sysinit --config 'global{use_lvmetad=0}'
return $?
}
In other words, add a --config 'global{use_lvmetad=0}' option to any LVM
commands that are executed before mounting the root filesystem and
starting lvmetad.
The modified version in /etc/initramfs-tools will override the
corresponding standard file in /usr/share/initramfs-tools.
Step 3.)
Rebuild your initramfs.
# update-initramfs -u -k $(uname -r)
--
matti.kurk...@fi.fujitsu.com Tel: 045 7880 5596 Mobile: 046 878 5596
Fujitsu Finland Oy FJ EMEIA DTS HI&NTS ST, EMEIA
Bug#877505: zfs-fuse.service causes a systemd service ordering cycle
Package: zfs-fuse Version: 0.7.0-16 Severity: normal Dear Maintainer, When installed on up-to-date stable Debian 9.1 system using systemd, the zfs-fuse package causes an ordering cycle at boot time: Oct 02 12:15:47 finmatkurk1 systemd[1]: sysinit.target: Found ordering cycle on sysinit.target/start Oct 02 12:15:47 finmatkurk1 systemd[1]: sysinit.target: Found dependency on zfs-fuse.service/start Oct 02 12:15:47 finmatkurk1 systemd[1]: sysinit.target: Found dependency on remote-fs.target/start Oct 02 12:15:47 finmatkurk1 systemd[1]: sysinit.target: Found dependency on remote-fs-pre.target/start Oct 02 12:15:47 finmatkurk1 systemd[1]: sysinit.target: Found dependency on nfs-server.service/start Oct 02 12:15:47 finmatkurk1 systemd[1]: sysinit.target: Found dependency on rpc-statd.service/start Oct 02 12:15:47 finmatkurk1 systemd[1]: sysinit.target: Found dependency on nss-lookup.target/start This seems to be because zfs-fuse.service is defined to start after remote-fs.target, but before sysinit.target: fimatkurk@finmatkurk1:~$ systemctl cat zfs-fuse # /lib/systemd/system/zfs-fuse.service [Unit] Documentation=man:zfs-fuse(8) Description=Daemon for ZFS support via FUSE DefaultDependencies=no Before=sysinit.target Before=shutdown.target After=remote-fs.target Conflicts=shutdown.target As a result, systemd attempts to break the loop. Usually it finds the right target: Oct 02 12:15:47 finmatkurk1 systemd[1]: zfs-fuse.service: Job zfs-fuse.service/start deleted to break ordering cycle starting with sysinit.target/start However, occasionally it seems to get it wrong: Oct 01 23:12:21 finmatkurk1 systemd[1]: dbus.socket: Found ordering cycle on dbus.socket/start Oct 01 23:12:21 finmatkurk1 systemd[1]: dbus.socket: Found dependency on sysinit.target/start Oct 01 23:12:21 finmatkurk1 systemd[1]: dbus.socket: Found dependency on zfs-fuse.service/start Oct 01 23:12:21 finmatkurk1 systemd[1]: dbus.socket: Found dependency on remote-fs.target/start Oct 01 23:12:21 finmatkurk1 systemd[1]: dbus.socket: Found dependency on remote-fs-pre.target/start Oct 01 23:12:21 finmatkurk1 systemd[1]: dbus.socket: Found dependency on nfs-server.service/start Oct 01 23:12:21 finmatkurk1 systemd[1]: dbus.socket: Found dependency on nfs-mountd.service/start Oct 01 23:12:21 finmatkurk1 systemd[1]: dbus.socket: Found dependency on network.target/start Oct 01 23:12:21 finmatkurk1 systemd[1]: dbus.socket: Found dependency on NetworkManager.service/verify-active Oct 01 23:12:21 finmatkurk1 systemd[1]: dbus.socket: Found dependency on dbus.socket/start Oct 01 23:12:21 finmatkurk1 systemd[1]: dbus.socket: Breaking ordering cycle by deleting job sysinit.target/start Oct 01 23:12:21 finmatkurk1 systemd[1]: sysinit.target: Job sysinit.target/start deleted to break ordering cycle starting with dbus.socket/start And when sysinit.target is not started, the system gets stuck at boot with no ways to log in. -- System Information: Debian Release: 9.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.52 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages zfs-fuse depends on: ii fuse 2.9.7-1 ii init-system-helpers 1.48 ii libaio1 0.3.110-3 ii libc62.24-11+deb9u1 ii libfuse2 2.9.7-1 ii libssl1.11.1.0f-3 ii lsb-base 9.20161125 ii zlib1g 1:1.2.8.dfsg-5 zfs-fuse recommends no packages. Versions of packages zfs-fuse suggests: ii kpartx 0.6.4-5 ii nfs-kernel-server 1:1.3.4-2.1 -- no debconf information
Bug#733094: Still exists in Jessie
If /var or /var/log is a separate filesystem, the udev rule for this can often run before that filesystem is mounted, causing the /var/log/uvcdynctrl-udev.log file to be "hidden" under the mountpoint - where it is also unreachable by logrotate and similar tools, and thus might grow forever until the root filesystem is full. One way to remove the unreachable file would be to reboot into single user mode - but there is an easier way: bind mount the root filesystem to some other location. Bind mounts ignore submounts, and thus make the files stuck under mount points accessible. Here's an example from my system: # ls -l /var/log/uvcdynctrl-udev.log -rw-r--r-- 1 root root 0 Nov 6 12:28 /var/log/uvcdynctrl-udev.log # mount --bind / /mnt # ls -l /mnt/var/log/uvcdynctrl-udev.log -rw-r--r-- 1 root root 97805 Nov 4 21:15 /mnt/var/log/uvcdynctrl-udev.log Apparently /lib/udev/uvcdynctrl and /lib/udev/rules.d/80-uvcdynctrl.rules are not marked as conffiles, so updates will overwrite any manual edits. A permanent workaround can be achieved by also overriding the udev rule to make it read the script from elsewhere, so the modified script won't be overwritten on updates: # sed -e '/^debug=/s/1/0/' < /lib/udev/uvcdynctrl >/etc/udev/uvcdynctrl # sed -e 's|/lib/udev/uvcdynctrl|/etc/udev/uvcdynctrl|' \ < /lib/udev/rules.d/80-uvcdynctrl.rules \ /etc/udev/rules.d/80-uvcdynctrl.rules A minimal patch would be to add a configuration file to the package, e.g. /etc/default/uvcdynctrl, and have the /lib/udev/uvcdynctrl read the value of the "debug" variable from there. -- Matti.Kurkela (at) iki.fi (or welho.com)
Bug#616733: os-prober: Does not detect MS-DOS reliably
On Mon, 7 Mar 2011, Christian PERRIER wrote: Thanks for this patch. I committed it. (alternative approach to MS-DOS/Win3.1 detection) I agree this would be more reliable. Do you think that you could propose a patch for such improvement? Certainly; however, I'm currently travelling and so have very limited opportunity to do it right now. I might be able to do it by the next Sunday. -- Matti.Kurkela (at) iki.fi (tai welho.com) Puhelin 050 566 5564 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#616733: os-prober: Does not detect MS-DOS reliably
Package: os-prober Version: 1.42 Severity: normal Configuration: - system is partitioned as follows: /dev/sda1 = Linux /boot /dev/sda2 = DOS 6.22 /dev/sda3 = extended partition /dev/sda5 = Linux LVM PV, containing swap and Linux filesystems - /dev/sda2 is mounted on /dos (so the DOS 6.22 system directory is "/dos/dos" ) Commands issued as root: # cd /root # update-grub2 # cd /dos # update-grub2 Expected results: update-grub2 runs grub-mkconfig, which uses os-prober via /etc/grub.d/30_os-prober script. It finds the DOS partition and adds it to GRUB boot menu. The results should be the same no matter in which directory update-grub2 is run. Actual results: When the current directory is /root, the DOS partition is not detected. When the current directory is /dos, the DOS partition is detected successfully. # cd /root # update-grub2 Found linux image: /boot/vmlinuz-2.6.36.4-c7 Found initrd image: /boot/initrd.img-2.6.36.4-c7 Found linux image: /boot/vmlinuz-2.6.32-5-686 Found initrd image: /boot/initrd.img-2.6.32-5-686 Found memtest86 image: /memtest86.bin Found memtest86+ image: /memtest86+.bin done # cd /dos # update-grub2 Generating grub.cfg ... Found linux image: /boot/vmlinuz-2.6.36.4-c7 Found initrd image: /boot/initrd.img-2.6.36.4-c7 Found linux image: /boot/vmlinuz-2.6.32-5-686 Found initrd image: /boot/initrd.img-2.6.32-5-686 Found memtest86 image: /memtest86.bin Found memtest86+ image: /memtest86+.bin Found MS-DOS 5.x/6.x/Win3.1 on /dev/sda2 done Analysis: os-prober's MS-DOS test in /usr/lib/os-probes/mounted/20microsoft does not use an absolute path when it verifies that "dos" is a directory. Patch attached. Further suggestions: Testing for the presence of "dos" directory is not a very reliable test for MS-DOS: the directory might exist also on systems updated from MS-DOS/Win3.1 to Windows 9x, and the name of the MS-DOS system directory was relatively easy to customize. A better test would be to look for initial boot files: "IO.SYS" and "MSDOS.SYS": their location is fixed at the root of the MS-DOS/Windows system partition. Step 1) If both IO.SYS and MSDOS.SYS exist, and no other versions of MS-Windows are detected, the OS is either MS-DOS/Win3.1 or Windows 9x/ME. Step 2) If MSDOS.SYS is a binary, the OS is MS-DOS/Win3.1; if MSDOS.SYS contains only text with CRLF line terminators (although not necessarily ASCII only: localized versions may have included national characters in CP850 or other Microsoft proprietary extended-ASCII encodings), the OS is Windows 9x/ME. -- System Information: Debian Release: 6.0 APT prefers squeeze-updates APT policy: (500, 'squeeze-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.36.4-c7 Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages os-prober depends on: ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib os-prober recommends no packages. os-prober suggests no packages. -- no debconf information --- /usr/lib/os-probes/mounted/20microsoft.distrib 2010-08-27 02:39:38.0 +0300 +++ /usr/lib/os-probes/mounted/20microsoft 2011-03-07 00:33:43.0 +0200 @@ -64,7 +64,7 @@ fi fi # MS-DOS -elif [ -d "$(item_in_dir dos "$2")" ]; then +elif [ -d "$2"/"$(item_in_dir dos "$2")" ]; then long="MS-DOS 5.x/6.x/Win3.1" short=MS-DOS # 95/98/Me
Bug#421744: xsensors: undeclared dependency on libsysfs.so.1
Package: xsensors Version: 0.50-1 Severity: normal Trying to run xsensors causes this error message: $ xsensors xsensors: error while loading shared libraries: libsysfs.so.1: cannot open shared object file: No such file or directory Etch contains libsysfs.so.2, so it looks like xsensors is compiled with an old version of libsysfs. However, the dependency on libsysfs is not declared in the package at all. $ ldd /usr/bin/xsensors linux-gate.so.1 => (0xb7f6b000) libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb7c5f000) libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb7bde000) libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb7bc3000) libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb7bad000) libm.so.6 => /lib/tls/libm.so.6 (0xb7b88000) libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb7b8) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb7b55000) libXext.so.6 => /usr/lib/libXext.so.6 (0xb7b47000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb7b3e000) libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb7b3b000) libXi.so.6 => /usr/lib/libXi.so.6 (0xb7b33000) libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb7b3) libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb7b27000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb7b22000) libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb7ae7000) libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb7a85000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb7999000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb795f000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb795c000) libdl.so.2 => /lib/tls/libdl.so.2 (0xb7958000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb78c5000) libsensors.so.3 => /usr/local/lib/libsensors.so.3 (0xb7897000) libc.so.6 => /lib/tls/libc.so.6 (0xb7765000) /lib/ld-linux.so.2 (0xb7f6c000) libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb773a000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb76d) libz.so.1 => /usr/lib/libz.so.1 (0xb76bb000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb769b000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb7698000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7675000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb767) librt.so.1 => /lib/tls/librt.so.1 (0xb7667000) libsysfs.so.1 => not found libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb7655000) -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (990, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.20.7-k8 Locale: LANG=en_US.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Versions of packages xsensors depends on: ii libatk1.0-0 1.12.4-3 The ATK accessibility toolkit ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libcairo2 1.2.4-4 The Cairo 2D vector graphics libra ii libfontconfig1 2.4.2-1.2generic font configuration library ii libglib2.0-02.12.4-2 The GLib library of C routines ii libgtk2.0-0 2.8.20-7 The GTK+ graphical user interface ii libpango1.0-0 1.14.8-5 Layout and rendering of internatio ii libsensors3 1:2.10.1-3 library to read temperature/voltag ii libx11-62:1.0.3-7X11 client-side library ii libxcursor1 1.1.7-4 X cursor management library ii libxext61:1.0.1-2X11 miscellaneous extension librar ii libxfixes3 1:4.0.1-5X11 miscellaneous 'fixes' extensio ii libxi6 1:1.0.1-4X11 Input extension library ii libxinerama11:1.0.1-4.1 X11 Xinerama extension library ii libxrandr2 2:1.1.0.2-5 X11 RandR extension library ii libxrender1 1:0.9.1-3X Rendering Extension client libra ii lm-sensors 1:2.10.1-3 utilities to read temperature/volt xsensors recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
