Bug#1076582: initramfs-tools-core: mkinitramfs failure zstd -q -9 -T0 70 (No space left on device)
On 24/07/2024 10.58, Diederik de Haas wrote: On Sunday, 21 July 2024 13:13:23 CEST Simon John wrote: [...] What IS a general solution is upgrading initramfs-tools to version 0.143 currently available in Experimental as that can handle symlinks to *directories*, whereas 0.142 could only deal with symlinks to files. I can confirm that 0.143 solve this issue case 1) initramfs-tools 0.142, no firmware-nvidia-graphics $ ls -lh /boot/efi//6.9.6/initrd.img-6.9.6 -rwxr-xr-x 1 root root 74M 2024-07-22 22:43 /boot/efi//6.9.6/initrd.img-6.9.6 ^^^ case 2) initramfs-tools 0.142, firmware-nvidia-graphics 20240610-1 installed $ sudo apt install firmware-nvidia-graphics $ sudo update-initramfs -k 6.9.6 -u $ ls -lh /boot/efi//6.9.6/initrd.img-6.9.6 -rwxr-xr-x 1 root root 244M 2024-07-24 18:51 /boot/efi//6.9.6/initrd.img-6.9.6 case 3) initramfs-tools-* 0.143, firmware-nvidia-graphics 20240610-1 installed $ ls -lh /boot/efi//6.9.6/initrd.img-6.9.6 -rwxr-xr-x 1 root root 114M 2024-07-24 18:56 /boot/efi//6.9.6/initrd.img-6.9.6 0.143 0.142 nvidia blobinitrd size === ====== case 1) X 74M case 2) XX 244M case 3) X X 114M size of initrd of case 3) is bigger that the size of initrd of case 1), but it is expected because in case 1) I don't have the nvidia binary at all. However case 3) is half of the case 2), and this is right because I have the nvidia binary but I don't have the multiple copy in the initrd. I already mentioned this in message #44, so it's rather disappointing that people insist on ranting about the problem, but not willing to try the suggested solution. Or they did and just didn't care to report the results back, which normally means it did fix the problem. To be fair you wrote: ) There was a relatively recent upload of initramfs-tools 0.143 to ) *Experimental* and I'm curious if that would help in this case. So it was not really clear that it was a solution; it seemed that it *could* be a possible solution; this to explain why nobody care it too much. Anyhow, 0.143 solve this issue. BR G.Baroncelli -- gpg @keyserver.linux.it: Goffredo Baroncelli Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
Bug#1076582: initramfs-tools-core: mkinitramfs failure zstd -q -9 -T0 70 (No space left on device)
On Fri, 19 Jul 2024 18:11:18 +0200 Diederik de Haas wrote: Control: affects -1 firmware-nvidia-graphics On Friday, 19 July 2024 17:56:30 CEST Chris Hofstaedtler wrote: > Control: retitle -1 initramfs-tools: duplicates nvidia firmware files > > On Fri, Jul 19, 2024 at 04:43:47PM +0200, Diederik de Haas wrote: > > > In any case, the upgrade should work for any user, including when > > > all these packages are needed. > > > > The real problem seems to be the size of /boot/ ... > > Not really. It's nice that we can *postpone* that problem a while longer. > A large part of the problem is that initramfs explodes > the size of the nvidia firmware. > > On the root file system, in /usr/lib/firmware, the nvidia firmware > files are 66MB (uncompressed!). > However, the initrd.img grows from 64M to 250M (compressed!) when > firmware-nvidia-graphics is installed. There is something seriously > wrong here. > > One of the things I've noticed: > > /usr/lib/firmware/nvidia/tu104/gsp is supposed to be a symlink to > /usr/lib/firmware/nvidia/tu102/gsp. However, in initrd.img, this is > a copy of the directory; accounting for 25M on its own. > > No wonder the initrd is way too large. Nice find! Adding firmware-nvidia-graphics as affects (which hopefully will warn users of that package of this problem) Hi all, I can confirm the problem. The firmware under /usr/lib/firmware/nvdia have some links between the directories. However the function "add_firmware" handles only the links between the files. This leads to duplicate files in the initramfs which are unique in /usr/lib/firmware in reality. In my case I solved removing the nvidia drivers because I don't use it. But in general, being the nvidia driver huge, this creates problem in small (!) EFI partition. BR G.Baroncelli -- gpg @keyserver.linux.it: Goffredo Baroncelli Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
Bug#981176: Rename the doas package as opendoas package
opendoas is a derived project from the openbsd doas project. The differences are quite important from a security point of view: it comes to me the pam and persistent support. Several other projects are derived from the original doas, like: - https://github.com/multiplexd/doas - https://github.com/slicer69/doas Each one has a different implementation either of pam or persistent support. In order to reduce the confusion, I think that it does make sense to rename the doas debian package in opendoas, to highlight the project from which the package is built. This would help also the tracking of the security issues. Regards Goffredo -- gpg @keyserver.linux.it: Goffredo Baroncelli Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
Bug#953537: Info received (xfsdump fails to install in /usr merged system.)
On 3/13/20 1:54 PM, Debian Bug Tracking System wrote: This a possible solution diff -Naur xfsdump-3.1.9/debian/xfsdump.postinst xfsdump-3.1.9+nmu1/debian/xfsdump.postinst --- xfsdump-3.1.9/debian/xfsdump.postinst 1970-01-01 01:00:00.0 +0100 +++ xfsdump-3.1.9+nmu1/debian/xfsdump.postinst 2020-03-13 13:54:21.0 +0100 @@ -0,0 +1,12 @@ +#!/bin/sh +set -e + +if [ "$1" = 'configure' ]; then + for file in xfsdump xfsrestore; do +if [ ! -e /usr/sbin/$file ]; then + ln -s /sbin/$file /usr/sbin/$file +fi + done +fi + +#DEBHELPER# diff -Naur xfsdump-3.1.9/debian/xfsdump.postrm xfsdump-3.1.9+nmu1/debian/xfsdump.postrm --- xfsdump-3.1.9/debian/xfsdump.postrm 1970-01-01 01:00:00.0 +0100 +++ xfsdump-3.1.9+nmu1/debian/xfsdump.postrm2020-03-13 13:54:41.0 +0100 @@ -0,0 +1,12 @@ +#!/bin/sh +set -e + +if [ "$1" = 'remove' ]; then + for file in xfsdump xfsrestore; do +if [ -L /usr/sbin/$file ]; then + rm /usr/sbin/$file +fi + done +fi + +#DEBHELPER# diff -Naur xfsdump-3.1.9/dump/Makefile xfsdump-3.1.9+nmu1/dump/Makefile --- xfsdump-3.1.9/dump/Makefile 2020-01-31 18:30:58.0 +0100 +++ xfsdump-3.1.9+nmu1/dump/Makefile2020-03-13 13:50:57.0 +0100 @@ -100,9 +100,6 @@ $(INSTALL) -m 755 -d $(PKG_ROOT_SBIN_DIR) $(LTINSTALL) -m 755 $(LTCOMMAND) $(PKG_ROOT_SBIN_DIR) $(INSTALL) -m 755 -d $(PKG_SBIN_DIR) - # skip symlink when /sbin is alread symlinked to /usr/sbin, like on Fedora - test $(PKG_ROOT_SBIN_DIR) -ef $(PKG_SBIN_DIR) || \ - $(INSTALL) -S $(PKG_ROOT_SBIN_DIR)/$(LTCOMMAND) $(PKG_SBIN_DIR)/$(LTCOMMAND) install-dev: .dep: $(COMMINCL) $(COMMON) $(INVINCL) $(INVCOMMON) diff -Naur xfsdump-3.1.9/restore/Makefile xfsdump-3.1.9+nmu1/restore/Makefile --- xfsdump-3.1.9/restore/Makefile 2020-01-31 18:30:58.0 +0100 +++ xfsdump-3.1.9+nmu1/restore/Makefile 2020-03-13 13:51:11.0 +0100 @@ -115,8 +115,6 @@ $(LTINSTALL) -m 755 $(LTCOMMAND) $(PKG_ROOT_SBIN_DIR) $(INSTALL) -m 755 -d $(PKG_SBIN_DIR) # skip symlink when /sbin is alread symlinked to /usr/sbin, like on Fedora - test $(PKG_ROOT_SBIN_DIR) -ef $(PKG_SBIN_DIR) || \ - $(INSTALL) -S $(PKG_ROOT_SBIN_DIR)/$(LTCOMMAND) $(PKG_SBIN_DIR)/$(LTCOMMAND) install-dev: .dep: $(COMMINCL) $(COMMON) $(INVINCL) $(INVCOMMON) -- gpg @keyserver.linux.it: Goffredo Baroncelli Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
Bug#953537: xfsdump fails to install in /usr merged system.
This bug was already addressed in the past by Marco d'Itri. Now it reappears. See the debian change log [...] xfsdump (3.1.6+nmu1) unstable; urgency=medium * Non-maintainer upload. * Create in postinst the xfsdump and xfsrestore compatibility symlinks. This is needed to support merged /usr systems (closes: #767926) -- Marco d'Itri Thu, 07 Jan 2016 22:44:28 +0100 [...] The problem is that the original xfsdump Makefile(s) (both the one under dump/ and the one under restore/) install the binary under /sbin and create a symlink to the binary under /usr/sbin. Of course this doesn't work when the system has /[s]bin and /usr/[s]bin merged. Looking at the past packages (3.1.6+nm1), the symlinking where dropped from the Makefile, and where added in the *.{postinst,postrm} hooks. I have to point out that the actual Makefile checks if the system is "/usr merged". However this check is performed only at build time and not at install time. So if the build host is not "/usr merged" and the target host is "/usr merged", the installation fails. So In my opinion, it should be re-enable the MD's change. BR G.Baroncelli -- gpg @keyserver.linux.it: Goffredo Baroncelli Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
Bug#882261: Acknowledgement (rsyslog: imjournal doesn't work)
The bug report contains the version "8.30.0-2ghigo1", because this is the one which I generated when I rebuild the packages rsyslogd with the upstream commit 4736e53d471ac45024333588fcdf5bce5f8c61b8 (which solve this issue). Sorry for the confusion.
Bug#882261: rsyslog: imjournal doesn't work
Package: rsyslog Version: 8.30.0-2ghigo1 Severity: important Tags: upstream When the imjournal module is used, rsyslog doesn't start. This is a know bug which is fixed by commit 4736e53d471ac45024333588fcdf5bce5f8c61b8. Note that if the imjournal is used, rsyslog hang and no log is recorded. Starting manually, I got the following error messages $ sudo rsyslogd rsyslogd: sd_journal_next() failed: 'No such file or directory' [v8.30.0] Depending by how systemd-journald is configured, this could means no log at all. This is the reason of the severity (important), even tough I have to admit that this is an uncommon configuration, so the occurence is very low. BR G.Baroncelli -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: armhf Kernel: Linux 4.13.7 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages rsyslog depends on: ii init-system-helpers 1.51 ii libc62.24-17 ii libestr0 0.1.10-2.1 ii libfastjson4 0.99.7-1 ii liblogging-stdlog0 1.0.6-1 ii liblognorm5 2.0.3-1 ii libsystemd0 235-3 ii libuuid1 2.30.2-0.1 ii lsb-base 9.20170808 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages rsyslog recommends: ii logrotate 3.11.0-0.1 Versions of packages rsyslog suggests: pn rsyslog-doc pn rsyslog-gnutls pn rsyslog-gssapi pn rsyslog-mongodb pn rsyslog-mysql | rsyslog-pgsql pn rsyslog-relp -- Configuration Files: /etc/rsyslog.conf changed: module(load="imjournal" PersistStateInterval="100" StateFile="/var/log/rsyslog-imjournal.state") #load imjournal module module(load="mmjsonparse") #load mmjsonparse module for structured logs template(name="CEETemplate" type="string" string="%timegenerated:::date-rfc3339% %HOSTNAME% %syslogtag% @cee: %$!all-json%\n" ) #template for messages action(type="mmjsonparse") action(type="omfile" file="/var/log/cee.log" template="CEETemplate") $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat $FileOwner root $FileGroup adm $FileCreateMode 0640 $DirCreateMode 0755 $Umask 0022 $WorkDirectory /var/spool/rsyslog $IncludeConfig /etc/rsyslog.d/*.conf auth,authpriv.* /var/log/auth.log *.*;auth,authpriv.none -/var/log/syslog daemon.*-/var/log/daemon.log kern.* -/var/log/kern.log lpr.* -/var/log/lpr.log mail.* -/var/log/mail.log user.* -/var/log/user.log mail.info -/var/log/mail.info mail.warn -/var/log/mail.warn mail.err/var/log/mail.err news.crit /var/log/news/news.crit news.err/var/log/news/news.err news.notice -/var/log/news/news.notice *.=debug;\ auth,authpriv.none;\ news.none;mail.none -/var/log/debug *.=info;*.=notice;*.=warn;\ auth,authpriv.none;\ cron,daemon.none;\ mail,news.none -/var/log/messages *.emerg :omusrmsg:* daemon.*;mail.*;\ news.err;\ *.=debug;*.=info;\ *.=notice;*.=warn |/dev/xconsole *.* /dev/tty12 -- no debconf information
Bug#817929: Bug in glibc
According to Florian Weimer [1] I filed a bug against glibc: https://sourceware.org/bugzilla/show_bug.cgi?id=19861 [1] https://sourceware.org/ml/libc-help/2016-03/msg00012.html BR G.Baroncelli -- gpg @keyserver.linux.it: Goffredo Baroncelli Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
Bug#817929: mosh fails to connect, giving a UDP error
On Mon, 21 Mar 2016 19:23:54 -0400 Matthew Gabeler-Lee wrote: > Package: mosh > Version: 1.2.5-1.1 > Followup-For: Bug #817929 > > Looks like upstream has a patch for this: > > https://github.com/mobile-shell/mosh/pull/732/commits/a47917b97606a03f6bbf0cafd1fcd495b0229790 > > Though it looks like that's a hack and they really want this fixed in > protobuf: > > https://github.com/google/protobuf/pull/1333 > > Which also has a patch. Please give a look to https://sourceware.org/ml/libc-help/2016-03/msg00010.html to me it seems that the real problem is in glibc. BR G.Baroncelli -- gpg @keyserver.linux.it: Goffredo Baroncelli Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
Bug#817929: Minimal test case
Ok, I was able to track down a __very__ minimal test case: the problem seems to be a "strange" interaction between the linker flag used during the creation of libutemper, and the inclusion of -lpthread[*] during the linking of mosh-server. It is not a problem related to mosh and/or libutempter. In fact I was able to create a test without involving these two. $ cat boom.c extern void dofork(); int main() { dofork(); } $ cat dofork.c #include void dofork() { fork(); } $ gcc -shared -Wl,-z,now -o libdofork.so dofork.o $ gcc -o boom boom.c -lpthread -L$(pwd) -ldofork $ LD_LIBRARY_PATH=$(pwd) ldd ./boom linux-vdso.so.1 (0x7ffe817dc000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f16b38ed000) libdofork.so => /home/ghigo/mosh/libdofork.so (0x7f16b36ec000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f16b3347000) /lib64/ld-linux-x86-64.so.2 (0x562eba12a000) $ LD_LIBRARY_PATH=$(pwd) ./boom Segmentation fault The key points are: - put a fork in a shared library - link the shared library with "-Wl,-z,now" - compile a program with libpthread and the library above (note: libpthread is not needed) - put libpthread before the library above Then I got a crash. The test was performed on a debian machine with libc6 2.22. Even on a fedora F23 (=libc-2.22) I got the crash. If I performed the same test on a debian machine with libc6 2.19 instead of libc6 2.22, the crash doesn't happen. If I remove "-lpthread" or "-Wl,-z,now" flag, the crash doesn't happen. If I put the fork() in the main(), the crash doesn't happen. My (limitated) knowledge doesn't suggest me any valid reason about why the crashes. However - if I remove "-Wl,-z,now" from libutempter mosh-server doesn't crash. - if I remove -lpthread from the linking of "mosh-server", mosh doesn't crash anymore. Pay attention that -lpthread is not needed, because the -pthread flag is sufficient. BR G.Baroncelli [*] BTW -lpthread was required by libprotobuf -- gpg @keyserver.linux.it: Goffredo Baroncelli Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
Bug#817929: mosh and libutempter
I am not sure that libutempter0 is the real culprit, however I find a very strange behavior: If I preload libutempter mosh-server didn't crashes. Instead if I run mosh-server alone, it crashes: $ ldd /usr/bin/mosh-server linux-vdso.so.1 (0x7ffce553b000) libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7f8966678000) libprotobuf.so.9 => /usr/lib/x86_64-linux-gnu/libprotobuf.so.9 (0x7f896634e000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f896613) libssl.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2 (0x7f8965ec7000) libcrypto.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2 (0x7f8965a64000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f896586) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f8965645000) --> libutempter.so.0 => /usr/lib/x86_64-linux-gnu/libutempter.so.0 (0x7f8965442000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f89650be000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f8964dc) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f8964baa000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f8964805000) /lib64/ld-linux-x86-64.so.2 (0x561792d06000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f8964601000) $ /usr/bin/mosh-server In dmesg I got "mosh-server[8320]: segfault at 0 ip" Instead if I do $ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libutempter.so.0 /usr/bin/mosh-server mosh-server didn't crash... I am inclined to think that preloading the library I change the library arrangement in memory; this could hide/show some wrong memory access. Any idea how debug this ? G.Baroncelli
Bug#817929: libutempter related problem ?
It seems that the problem is related to libutempter0. If commenting the call in the source of mosh-server, the problem disappear...
Bug#817929: mosh fails to connect, giving a UDP error
Package: mosh Version: 1.2.5-1.1 Followup-For: Bug #817929 I can confirm that. After a recent update (but I was sure which one) mosh stops to work. The problem seems to be in mosh-server which ends with a SIGSEGV after it forks: $ strace -f mosh-server execve("/usr/bin/mosh-server", ["mosh-server"], [/* 23 vars */]) = 0 brk(NULL) = 0x5614e69fc000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9e62de8000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=191871, ...}) = 0 mmap(NULL, 191871, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9e62db9000 close(3)= 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) [...] [...] mprotect(0x7f9e600e7000, 4096, PROT_READ) = 0 mprotect(0x7f9e602f9000, 4096, PROT_READ) = 0 munmap(0x7f9e62d81000, 191871) = 0 open("/etc/group", O_RDONLY|O_CLOEXEC) = 6 lseek(6, 0, SEEK_CUR) = 0 fstat(6, {st_mode=S_IFREG|0644, st_size=1105, ...}) = 0 mmap(NULL, 1105, PROT_READ, MAP_SHARED, 6, 0) = 0x7f9e62de6000 lseek(6, 1105, SEEK_SET)= 1105 munmap(0x7f9e62de6000, 1105)= 0 close(6)= 0 ioctl(5, TIOCSPTLCK, [0]) = 0 ioctl(5, TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(5, TIOCGPTN, [7]) = 0 stat("/dev/pts/7", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 7), ...}) = 0 open("/dev/pts/7", O_RDWR|O_NOCTTY) = 6 ioctl(6, TIOCSWINSZ, {ws_row=45, ws_col=115, ws_xpixel=0, ws_ypixel=0}) = 0 clone(strace: Process 18446 attached child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f9e62db1a10) = 18446 [pid 18446] set_robust_list(0x7f9e62db1a20, 24) = 0 [pid 18445] close(6 [pid 18446] close(5 [pid 18445] <... close resumed> ) = 0 [pid 18446] <... close resumed> ) = 0 [pid 18445] rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER|SA_RESTART, 0x7f9e62468d30}, [pid 18446] setsid( [pid 18445] <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) = 0 [pid 18446] <... setsid resumed> ) = 18446 [pid 18445] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} --- [pid 18446] ioctl(6, TIOCSCTTY, 0) = 0 [pid 18446] dup2(6, 0) = 0 [pid 18446] dup2(6, 1) = 1 [pid 18446] dup2(6, 2) = 2 [pid 18446] close(6)= 0 [pid 18446] rt_sigaction(SIGHUP, {SIG_DFL, ~[RTMIN RT_1], SA_RESTORER, 0x7f9e62468d30}, NULL, 8) = 0 [pid 18446] --- SIGHUP {si_signo=SIGHUP, si_code=SI_KERNEL} --- [pid 18445] +++ killed by SIGSEGV +++ +++ killed by SIGHUP +++ Enclose you can find the full strace. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.4.4 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mosh depends on: ii dpkg1.18.4 ii libc6 2.22-2 ii libgcc1 1:6-20160220-1 ii libprotobuf9v5 2.6.1-1.3 ii libssl1.0.2 1.0.2g-1 ii libstdc++6 6-20160220-1 ii libtinfo5 6.0+20160213-1 ii libutempter01.1.6-3 ii openssh-client 1:7.2p2-1 ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages mosh recommends: ii perl-base [libio-socket-ip-perl] 5.22.1-8 mosh suggests no packages. -- no debconf information ming and intelligent local echo ghigo@venice:~$ strace -f mosh-server execve("/usr/bin/mosh-server", ["mosh-server"], [/* 23 vars */]) = 0 brk(NULL) = 0x5614e69fc000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9e62de8000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=191871, ...}) = 0 mmap(NULL, 191871, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9e62db9000 close(3)= 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/x86_64-linux-gnu/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260\320\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0644, st_size=171752, ...}) = 0 mmap(NULL, 2268768, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f9e6299f000 mprotect(0x7f9e629c5000, 2093056, PROT_NONE) = 0 mmap(0x7f9e62bc4000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x25000) = 0x7f9e62bc4000 close(3)= 0 access("/etc/ld.so.n
Bug#737305: libvte9: please include scroll_region_updates.patch from vte3 package
I had the same problem which was reported in bug #684445 (unreliable refresh when scrolling in mosh), which in turn forward to this bugreport. This patch https://git.gnome.org/browse/vte/commit/?id=88e8e89560a62d0981ce2b18974a230d0a07dbdd solved this issue, so please apply. Arch linux also uses the same patch https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/vte (here the bug https://bugs.archlinux.org/task/37419) Ubuntu uses the same patch from vte 1:0.28.1-1ubuntu1 (https://launchpad.net/ubuntu/+source/vte/1:0.28.1-1ubuntu1) This is the bug report https://bugs.launchpad.net/ubuntu/+source/vte/+bug/246701 -- gpg @keyserver.linux.it: Goffredo Baroncelli Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
Bug#798083: systemd: Systemd assumes that ESP is mounted in /boot
Package: systemd Version: 225-1 Severity: normal Tags: patch systemd assumes that the ESP partition is mounted on /boot. Instead debian seems to suggest to mount it on /boot/efi/. (systemd) bootctl relies on this assumption. The user could override this default via the --path switch, but this is annoing. The patch below adds a check: if the /boot/efi/EFI directory exists, bootctl assumes that the ESP is mounted on /boot/efi, otherwise /boot. Anyway the user can still override the default using the --path switch. I proposed the patch upstream [1] but it was rejected becuase the systemd developers want to support only mounting ESP on /boot. BR G.Baroncelli [1] https://github.com/systemd/systemd/pull/1124 diff --git a/man/bootctl.xml b/man/bootctl.xml index 63ad939..0a96aae 100644 --- a/man/bootctl.xml +++ b/man/bootctl.xml @@ -102,7 +102,7 @@ --path -Path to the EFI system partition. The default is /boot. +Path to the EFI system partition. By default bootctl uses /boot/efi (if ESP is mounted here) or /boot. diff --git a/src/boot/bootctl.c b/src/boot/bootctl.c index ac1711b..319994e 100644 --- a/src/boot/bootctl.c +++ b/src/boot/bootctl.c @@ -936,7 +936,7 @@ static int help(void) { return 0; } -static const char *arg_path = "/boot"; +static const char *arg_path = NULL; static bool arg_touch_variables = true; static int parse_argv(int argc, char *argv[]) { @@ -996,6 +996,18 @@ static void read_loader_efi_var(const char *name, char **var) { log_warning_errno(r, "Failed to read EFI variable %s: %m", name); } +static void init_arg_path(void) { +struct stat st; + +if (stat("/boot/efi/EFI", &st) == 0 && (st.st_mode & S_IFMT) == S_IFDIR) { +/* Suse, debian, ubuntu, gentoo, fedora */ +arg_path = "/boot/efi"; +} else { +/* arch */ +arg_path = "/boot"; +} +} + static int bootctl_main(int argc, char*argv[]) { enum action { ACTION_STATUS, @@ -1036,6 +1048,9 @@ static int bootctl_main(int argc, char*argv[]) { if (geteuid() != 0) return log_error_errno(EPERM, "Need to be root."); +if (arg_path == NULL) +init_arg_path(); + r = verify_esp(arg_path, &part, &pstart, &psize, &uuid); if (r == -ENODEV && !arg_path) log_notice("You might want to use --path= to indicate the path to your ESP, in case it is not mounted on /boot."); -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.2.0 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) 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 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-2 ii libselinux1 2.3-2+b1 ii libsystemd0 225-1 ii mount 2.26.2-9 ii sysv-rc 2.88dsf-59.2 ii udev225-1 ii util-linux 2.26.2-9 Versions of packages systemd recommends: ii dbus1.8.20-1 ii libpam-systemd 225-1 Versions of packages systemd suggests: ii systemd-container 225-1 pn systemd-ui -- Configuration Files: /etc/systemd/journald.conf changed [not included] -- no debconf information bootctl-ESP.diff Description: inode/empty
Bug#778253: Library version
I noticed only now that the library version reported is the 3.1.2-11ghigo. This is a my mistake. 3.1.2-11ghigo is the library which I rebuild with the patch. The problem is related to the 3.1.2-10. BR G.Baroncelli -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778253: libarchive13: archive_read_disk_entry_from_file() and archive_write_disk_set_acls() don't preserv ACL.
Package: libarchive13 Version: 3.1.2-11ghigo Severity: normal Tags: patch libarchive in linux doesn't support properly the ACL. This is a bug alredy solved in upstream [1][2]. The problem is that the code which handles ACLs depend by the definition of the macro ACL_TYPE_NFS4. However in linux this macro is not defined. During the packaging build, dpkg-shlibdeps warns abou the fact the the "acl" library is unused: --- dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/libarchive13/usr/lib/x86_64-linux-gnu/libarchive.so.13.1.2 was not linked against libacl.so.1 (it uses none of the library's symbols) --- In upstream the problem is solved by the patch [2]. Fedora solved this issue cherry-picking the same patch [4]. I made a new version the libarchive package: I put the commit [2] in debian/patches/, I update debian/patches/series adding the new patch, and finally I updated the debian/changelog file. The package compiled and now my tests showed ACL seems supported. BR G.Baroncelli [1] https://code.google.com/p/libarchive/issues/detail?id=329 [2] See commit b45c3ae1825c8cedc7cde2972a04974f73b08315 [3] https://bugzilla.redhat.com/show_bug.cgi?id=993048 [4] http://pkgs.fedoraproject.org/cgit/libarchive.git/commit/?id=da58d4e8afce6acca54475be528f6b948aa2951a -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: armhf Kernel: Linux 3.18.5 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libarchive13 depends on: ii libacl12.2.52-2 ii libattr1 1:2.4.47-2 ii libbz2-1.0 1.0.6-7+b2 ii libc6 2.19-15 ii liblzma5 5.1.1alpha+20120614-2+b3 ii liblzo2-2 2.08-1.2 ii libnettle4 2.7.1-5 ii libxml22.9.2+dfsg1-3 ii multiarch-support 2.19-15 ii zlib1g 1:1.2.8.dfsg-2+b1 libarchive13 recommends no packages. Versions of packages libarchive13 suggests: pn lrzip -- no debconf information commit b45c3ae1825c8cedc7cde2972a04974f73b08315 Author: Tim Kientzle Date: Sat Jan 4 21:46:57 2014 -0800 Issue #329: https://code.google.com/p/libarchive/issues/detail?id=329 Fix POSIX.1e draft ACL handling on Linux systems that lack NFSv4 ACL libraries. diff --git a/libarchive/archive_read_disk_entry_from_file.c b/libarchive/archive_read_disk_entry_from_file.c index e984aaa..e81cbec 100644 --- a/libarchive/archive_read_disk_entry_from_file.c +++ b/libarchive/archive_read_disk_entry_from_file.c @@ -399,7 +399,7 @@ setup_mac_metadata(struct archive_read_disk *a, #endif -#if defined(HAVE_POSIX_ACL) && defined(ACL_TYPE_NFS4) +#ifdef HAVE_POSIX_ACL static int translate_acl(struct archive_read_disk *a, struct archive_entry *entry, acl_t acl, int archive_entry_acl_type); @@ -419,6 +419,7 @@ setup_acls(struct archive_read_disk *a, archive_entry_acl_clear(entry); +#ifdef ACL_TYPE_NFS4 /* Try NFS4 ACL first. */ if (*fd >= 0) acl = acl_get_fd(*fd); @@ -447,6 +448,7 @@ setup_acls(struct archive_read_disk *a, acl_free(acl); return (ARCHIVE_OK); } +#endif /* Retrieve access ACL from file. */ if (*fd >= 0) @@ -492,6 +494,7 @@ static struct { {ARCHIVE_ENTRY_ACL_EXECUTE, ACL_EXECUTE}, {ARCHIVE_ENTRY_ACL_WRITE, ACL_WRITE}, {ARCHIVE_ENTRY_ACL_READ, ACL_READ}, +#ifdef ACL_TYPE_NFS4 {ARCHIVE_ENTRY_ACL_READ_DATA, ACL_READ_DATA}, {ARCHIVE_ENTRY_ACL_LIST_DIRECTORY, ACL_LIST_DIRECTORY}, {ARCHIVE_ENTRY_ACL_WRITE_DATA, ACL_WRITE_DATA}, @@ -508,8 +511,10 @@ static struct { {ARCHIVE_ENTRY_ACL_WRITE_ACL, ACL_WRITE_ACL}, {ARCHIVE_ENTRY_ACL_WRITE_OWNER, ACL_WRITE_OWNER}, {ARCHIVE_ENTRY_ACL_SYNCHRONIZE, ACL_SYNCHRONIZE} +#endif }; +#ifdef ACL_TYPE_NFS4 static struct { int archive_inherit; int platform_inherit; @@ -519,21 +524,25 @@ static struct { {ARCHIVE_ENTRY_ACL_ENTRY_NO_PROPAGATE_INHERIT, ACL_ENTRY_NO_PROPAGATE_INHERIT}, {ARCHIVE_ENTRY_ACL_ENTRY_INHERIT_ONLY, ACL_ENTRY_INHERIT_ONLY} }; - +#endif static int translate_acl(struct archive_read_disk *a, struct archive_entry *entry, acl_t acl, int default_entry_acl_type) { acl_tag_t acl_tag; +#ifdef ACL_TYPE_NFS4 acl_entry_type_t acl_type; acl_flagset_t acl_flagset; + int brand, r; +#endif acl_entry_t acl_entry; acl_permset_t acl_permset; - int brand, i, r, entry_acl_type; + int i, entry_acl_type; int s, ae_id, ae_tag, ae_perm; const char *ae_name; +#ifdef ACL_TYPE_NFS4 // FreeBSD "brands" ACLs as POSIX.1e or NFSv4 // Make sure the "brand" on this ACL is consistent // with the default_entry_acl_type bits provided. @@ -560,6 +569,7 @@ translate_acl(struct archive_read_disk *a, return ARCHIVE_FAILED; break; } +#endif s = acl_get_entry(acl, ACL_FIRST_E
Bug#772752: btrfs-tools: [Wishlist item] Replace "btrfs device scan" in initramfs with a udev rule and "udevadm trigger -s block"
On 12/11/2014 10:40 PM, Dimitri John Ledkov wrote: > On 11 December 2014 at 21:17, Goffredo Baroncelli wrote: >>> and the premount script is >>> there precisely because at the moment udev based discovery is not >>> sufficient. >> >> I would like to know more about that: in which case udev based >> discovery is not sufficient ? Or are you referring about the >> fact that udev is not mandatory in initramfs. >> > > mosty yes, refereing to the fact that udev is not mandatory in the > Debian's initramfs. There is also ongoing bug stating that udev based > discovery is not sufficient in the initramfsless system, i have not > investigated it completely. I read something about that. The report stated that btrfs didn't honor the device=/dev/ mount options; In this case would be impossible to mount a multi-device filesystem. But I didn't understand the reason Goffredo -- gpg @keyserver.linux.it: Goffredo Baroncelli Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#772744: btrfs-tools: btrfs dev scan called multiple times from udev rules
On 12/11/2014 09:37 PM, Dimitri John Ledkov wrote: > On 10 December 2014 at 19:00, Goffredo Baroncelli wrote: [...] >> But also udev contains a btrfs rules >> >> - 64-btrfs.rules >> >> All rules do the same thing: invoke "btrfs device scan". Ok the >> udev rules uses an internal builtin, but the results is the same >> of the first two rules. >> > > 64-btrfs.rules does not call scan, it marks btrfs devices as ready > only. These are not equivalent. It does a "BTRFS_IOC_DEVICES_READY" ioctl (see udev-builtin-btrfs.c), which, despite its name, *registers* the passed device *and checks* if the number of registered device is sufficient. From fs/btrfs/super.c [...] /* * used by btrfsctl to scan devices when no FS is mounted */ static long btrfs_control_ioctl(struct file *file, unsigned int cmd, unsigned long arg) { [...] switch (cmd) { case BTRFS_IOC_SCAN_DEV: ret = btrfs_scan_one_device(vol->name, FMODE_READ, &btrfs_fs_type, &fs_devices); break; case BTRFS_IOC_DEVICES_READY: ret = btrfs_scan_one_device(vol->name, FMODE_READ, &btrfs_fs_type, &fs_devices); if (ret) break; ret = !(fs_devices->num_devices == fs_devices->total_devices); break; } As you can see BTRFS_IOC_DEVICES_READY acts ALSO as BTRFS_IOC_SCAN_DEV. (Yes, the name is very confusing, so only looking at the code this thing is clear) > >> I am asking to remove the btrfs-tools rules (80-... and 70-...) >> because the udev rule is sufficient and always present. >> > > All three do different things, under different conditions and are not > equivalent. The 64-btrfs.rules is able to superseed the two btrfs-tools package rules (80-... and 70-...). So it is not true that these rules do different thing. The 80-btrfs-lvm.rules and 70-btrfs.rules appeared before the 64-btrfs.rules (March 2012 vs September 2012). This explain the redundancy. BTW, ironically I was one of the first to suggest to put "btrfs device scan" in a btrfs rule (http://permalink.gmane.org/gmane.comp.file-systems.btrfs/5374) > >> As confirmation I checked fedora, and there is only one >> btrfs rule, the udev one. >> > > Fedora does not use initramfs-tools, but dracut which incidentally > ships a udev rule to call btrfs device scan. I checked a fedora initramfs and I was unable to find this rule (except the 64-btrfs.rules) I am referring the Fedora case to support my request to leave only 64-btrfs.rules: it is sufficient to cover all the cases. Otherwise we could drop the 64-btrfs.rules and leave the 70-... and 80-... But because these are less generic and Debian specific I don't see a valid reason for that. 64-btrfs.rules is also more efficient because it calls a built-in command and not an external one. > Thus even fedora has an > extra udev rule to call btrfs scan. No, it has only the 64-btrfs.rules. I re-checked now a fedora-20 initramfs ( initramfs-3.17.4-200.fc20.x86_64.img) and: - I was able to find the btrfs tools - I found /lib/udev/rules/64-btrfs.rules (which is the same shipped by the debian udev package) - I didn't find any "btrfs dev scan" invocation. > Do you have a bug with current package? If yes, please describe it, > otherwise I will be closing this bug report as won't fix. the problem tha I found was that we have three udev rules, when only one is sufficient; I am suggesting to adopt the rule shipped with udev. If you think that this is not a bug, please consider it as wishlist BTW, I noticed that the debian rules do the insmod the btrfs module. But this should be not necessary anymore. Udev is in charge to create the /dev/btrfs-control device. Any access to this device name starts the insmod of the btrfs module. (see https://lkml.org/lkml/2010/5/21/134) > > Regards, > > Dimitri. > BR Goffredo > >> BR >> G.Baroncelli >> >> >> -- System Information: >> Debian Release: 8.0 >> APT prefers unstable >> APT policy: (500, 'unstable') >> Architecture: amd64 (x86_64) >> >> Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) >> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) >> Shell: /bin/sh linked to /bin/dash >> Init: systemd (via /run/systemd/system) >> >> Versions of packages btrfs-tools depends on: >> ii e2fslibs 1.42.12-1 >> ii libblkid1 2.25.2-3 >> ii libc6 2.19-13 >> ii libcomerr2 1.42.12-1 >> ii liblzo2-2 2.08-1 >> ii libuuid12.25.2-3 >> ii zlib1g
Bug#772752: btrfs-tools: [Wishlist item] Replace "btrfs device scan" in initramfs with a udev rule and "udevadm trigger -s block"
On 12/11/2014 09:31 PM, Dimitri John Ledkov wrote: > On 10 December 2014 at 19:35, Goffredo Baroncelli wrote: >> Package: btrfs-tools >> Version: 3.17-1.1 >> Severity: wishlist >> >> >> btrfs-tools has a script for initramfs which load the btrfs module >> and does a "btrfs device scan". >> >> I suggest to replace the "btrfs device scan" with a udev rule (the >> one provided by the package udev, see Bug#772744) which uses >> the udev builtin method. >> Because the module may be inserted after that some devices appeared, >> after the module insert,we have to be do a "udevadm trigger -s block" >> to redoing a device rescan for btrfs. >> > > I disagree, udev in initramfs is optional If udev is optional in initramfs, my request has to be rejected. > and the premount script is > there precisely because at the moment udev based discovery is not > sufficient. I would like to know more about that: in which case udev based discovery is not sufficient ? Or are you referring about the fact that udev is not mandatory in initramfs. [...] BR G.Baroncelli -- gpg @keyserver.linux.it: Goffredo Baroncelli Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#772752: btrfs-tools: [Wishlist item] Replace "btrfs device scan" in initramfs with a udev rule and "udevadm trigger -s block"
Package: btrfs-tools Version: 3.17-1.1 Severity: wishlist btrfs-tools has a script for initramfs which load the btrfs module and does a "btrfs device scan". I suggest to replace the "btrfs device scan" with a udev rule (the one provided by the package udev, see Bug#772744) which uses the udev builtin method. Because the module may be inserted after that some devices appeared, after the module insert,we have to be do a "udevadm trigger -s block" to redoing a device rescan for btrfs. The goal of this change is to armonize how the btrfs device scan is done in intramfs to after the initramfs Below two patch to highlight this change. BR G.Baroncelli --- /usr/share/initramfs-tools/scripts/local-premount/btrfs 2014-11-22 15:01:04.0 +0100 +++ usr/share/initramfs-tools/scripts/local-premount/btrfs 2014-12-10 20:31:31.289746904 +0100 @@ -19,5 +19,5 @@ if [ -x /sbin/btrfs ] then modprobe btrfs - /sbin/btrfs device scan 2> /dev/null + udevadm trigger -s block fi --- /usr/share/initramfs-tools/hooks/btrfs 2014-11-22 15:01:04.0 +0100 +++ usr/share/initramfs-tools/hooks/btrfs 2014-12-10 20:34:07.181751787 +0100 @@ -26,4 +26,13 @@ then copy_exec /sbin/fsck.btrfs /sbin fi + + mkdir -p $DESTDIR/lib/udev/rules.d/ + for rules in 64-btrfs.rules; do + if [ -e /etc/udev/rules.d/$rules ]; then + cp -p /etc/udev/rules.d/$rules $DESTDIR/lib/udev/rules.d/ + elif [ -e /lib/udev/rules.d/$rules ]; then + cp -p /lib/udev/rules.d/$rules $DESTDIR/lib/udev/rules.d/ + fi + done fi -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages btrfs-tools depends on: ii e2fslibs1.42.12-1 ii libblkid1 2.25.2-3 ii libc6 2.19-13 ii libcomerr2 1.42.12-1 ii liblzo2-2 2.08-1 ii libuuid12.25.2-3 ii zlib1g 1:1.2.8.dfsg-2+b1 btrfs-tools recommends no packages. btrfs-tools suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#772744: btrfs-tools: btrfs dev scan called multiple times from udev rules
Package: btrfs-tools Version: 3.17-1.1 Severity: important Hi all, currently btrfs-tools contains two udev rules: - 80-btrfs-lvm.rules - 70-btrfs.rules But also udev contains a btrfs rules - 64-btrfs.rules All rules do the same thing: invoke "btrfs device scan". Ok the udev rules uses an internal builtin, but the results is the same of the first two rules. I am asking to remove the btrfs-tools rules (80-... and 70-...) because the udev rule is sufficient and always present. As confirmation I checked fedora, and there is only one btrfs rule, the udev one. BR G.Baroncelli -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages btrfs-tools depends on: ii e2fslibs1.42.12-1 ii libblkid1 2.25.2-3 ii libc6 2.19-13 ii libcomerr2 1.42.12-1 ii liblzo2-2 2.08-1 ii libuuid12.25.2-3 ii zlib1g 1:1.2.8.dfsg-2+b1 btrfs-tools recommends no packages. btrfs-tools suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725422: [Pkg-systemd-maintainers] Bug#725422: Bug#725422: Bug#725422: systemd set kernel.sysrq=16
On 2013-11-30 08:13, Goffredo Baroncelli wrote: > I am trying to send a patch to systemd-devel to split the content of the > systemd sysctl config file in smaller file to simplify the overriding of > the single file. http://lists.freedesktop.org/archives/systemd-devel/2013-December/015021.html -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725422: [Pkg-systemd-maintainers] Bug#725422: Bug#725422: Bug#725422: systemd set kernel.sysrq=16
On 2013-11-29 20:53, Zbigniew Jędrzejewski-Szmek wrote: > Hi Goffredo, > > On Thu, Nov 28, 2013 at 10:19:41PM +0100, Goffredo Baroncelli wrote: >> Hi Michael, >> >> On 2013-11-28 21:51, Michael Stapelberg wrote: >>> Hi Goffredo, >>> >>> Goffredo Baroncelli writes: >>>> Systemd has as main target Fedora. Debian is different from Fedora, so >>> Nope. >>> >>> systemd is not targeting one distribution as its main target. It is >>> running on many distributions, with no particular focus on any single >>> one of them. >> >> Let me rephrase this sentence: systemd is not sensible to the debian >> requirements; otherwise there would not be the problems to support the >> other debian kernels (like hurd and bsd). > Even if this were true, this bug report is not about hurd or bsd. > Since this is a bug report, let me ask again: is there anything to fix > with the sysctl stuff? As reported in my first report [1]: > Problem description: > After installing the systemd package some sysrq keys don't work any more. [...] > Expected behaviour: > The systemd package must not interact with the sysrq key setting I am trying to send a patch to systemd-devel to split the content of the systemd sysctl config file in smaller file to simplify the overriding of the single file. Worse, the workaround which I found [2] will be nullified with the new systemd versions because it is changing the processing order of the sysctl files configuration.. IMHO The big problem is that there is a sysctl setting as "side effect" of systemd. It would be a "debian" setting. Thanks in advance for your work (packaging, testing, talking with the bug highlighter :-) ). BR G.Baroncelli [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725422 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725422#29 > > Zbyszek > -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725422: [Pkg-systemd-maintainers] Bug#725422: Bug#725422: systemd set kernel.sysrq=16
Hi Michael, On 2013-11-28 21:51, Michael Stapelberg wrote: > Hi Goffredo, > > Goffredo Baroncelli writes: >> Systemd has as main target Fedora. Debian is different from Fedora, so > Nope. > > systemd is not targeting one distribution as its main target. It is > running on many distributions, with no particular focus on any single > one of them. Let me rephrase this sentence: systemd is not sensible to the debian requirements; otherwise there would not be the problems to support the other debian kernels (like hurd and bsd). Note, I am not suggesting that this is a fault of systemd. Only systemd has a different target than debian. BR Goffredo -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725422: [Pkg-systemd-maintainers] Bug#725422: Bug#725422: systemd set kernel.sysrq=16
Hi Zbyszek On 2013-11-28 20:57, Zbigniew Jędrzejewski-Szmek wrote: > So we're in agreement, except for this last point... > > On Thu, Nov 28, 2013 at 07:27:34PM +0100, Goffredo Baroncelli wrote: >> This is the point where we have a totally different opinion: >> - is job of systemd to set the sysctl values ? Yes. >> - is job of systemd decide *which values* have to be set ? IMHO no. This >> is a distribution responsibility. And I think that a distribution should >> not accept the systemd defaults, but should provide the own ones. > Why would Debian's defaults differ from any other general purpose > distro? Good question. But let me to rephrase this sentence: why change the default (== the one previous systemd) Debian value ? - before systemd, the value of kernel.syrq was 1 - after systemd, the value of kernel.syrq was 16 I think that it should be systemd (or its packager) to justify the gain to change these defaults. If it was done, please point me a link, and excuse me for the disturb. > If you think Debian should do something different than the > upstream default of '16', then most probably upstream should do so too. Systemd has as main target Fedora. Debian is different from Fedora, so may be that different defaults make sense; anyway I am working on a patch for systemd: basically I want to split the sysctl default in more files to simplify a possible override. > > Zbyszek > -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725422: [Pkg-systemd-maintainers] Bug#725422: Bug#725422: systemd set kernel.sysrq=16
Hi Zbyszek On 2013-11-28 17:24, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Nov 28, 2013 at 08:50:03AM +0100, Goffredo Baroncelli wrote: >> [1] I repeat I am not arguing about the values, I am arguing that a >> package which aim to replace the init must change a setting which aren't >> related to the package functionality. > Hi Goffredo, > > upstream value for the sysrq setting was chosen as a safe default. > If you thing that the default should be changed, it is definitely > reasonable to discuss it upstream on systemd-de...@l.fd.o. I was unable to find the discussion where these "safe default" was decided, so I don't know the rationale behind them; this seems to me a debate like "ctrl-alt-backspace" to kill X: a lot of people have different opinion about the meaning of "safe default". Anyway I am not complaining about the "systemd safe values", even I have a different opinion. > The mechanism to set the default is unlikely to change though. > Modulo the bugs with ordering that Michael pointed out, this > mechanism is nice and clean, and provides a safe way for the > administrator to locally override settings. Let me clear: I think that *how* systemd set the sysctl values *are the right one* (even tough they changed behaviour without regard the backward compatibility) > Also, this is a basic system setting, where it makes sense to change > the kernel default by default, so it is natural that systemd > does that. The goal of the systemd project is to take care of the > basic system setup. This is the point where we have a totally different opinion: - is job of systemd to set the sysctl values ? Yes. - is job of systemd decide *which values* have to be set ? IMHO no. This is a distribution responsibility. And I think that a distribution should not accept the systemd defaults, but should provide the own ones. > Zbyszek BR Goffredo -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725422: [Pkg-systemd-maintainers] Bug#725422: systemd set kernel.sysrq=16
HI Michael, On 2013-11-27 22:57, Michael Stapelberg wrote: > Hi Goffredo, > > Goffredo Baroncelli writes: >> As already written I am not complaining about the specific systemd >> sysctl values, nor the fact that systemd sets some values during the >> boot. I am complaining that if an user install systemd, he got some >> sysctl values changed. > Can you send a patch to upstream which will make systemd use a different > way of achieving that default? If you’ll get it accepted, I’ll gladly > cherry-pick it and include it in the next Debian upload. > > Otherwise, I don’t feel comfortable modifying the upstream software > package for such a minor detail. Thanks for your reply and for your time. However I cannot agree with your conclusion: having some setting changed only because I installed an unrelated package it seems me a bad behaviour and definitely not a "minor detail". So please don't close this bug. I agree with you, that it is a problem of systemd and of its tendency to force its "standard" everywhere. But it is its right to do so [1]. What I am expected by debian package is to filter these issues. I will highlight this also to upstream. But it would help me if you don't close this bug. BR G.Baroncelli [1] I repeat I am not arguing about the values, I am arguing that a package which aim to replace the init must change a setting which aren't related to the package functionality. -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725422: systemd set kernel.sysrq=16
On 2013-10-06 11:55, Goffredo Baroncelli wrote: > On 2013-10-06 11:45, Goffredo Baroncelli wrote: >> On 2013-10-06 01:00, Michael Biebl wrote: >>> tags 725422 + moreinfo >>> severity 725422 normal >>> thanks >>> > >> >> BTW, I am looking a way to change this default without changing this >> file. I supposed that adding a file in /etc/sysctl.d with the MY default >> would be sufficient, but it seems not the case > > Solved, the configuration file should be processed *before* the default > file. > So I named the file /etc/sysctl.d/01-sysrq.conf. Unfortunately the things are even more complex. Recently systemd changed behaviour: with the latest version (207) the configuration must be processed after the systemd default file: so the file will must be named /etc/sysctl.d/99-sysrq.conf. > > BR > G.Baroncelli > > >> >>> >>> Michael >>> >> G.Baroncelli >> > > -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725422: systemd set kernel.sysrq=16
On 2013-10-06 11:45, Goffredo Baroncelli wrote: > On 2013-10-06 01:00, Michael Biebl wrote: >> tags 725422 + moreinfo >> severity 725422 normal >> thanks >> > > BTW, I am looking a way to change this default without changing this > file. I supposed that adding a file in /etc/sysctl.d with the MY default > would be sufficient, but it seems not the case Solved, the configuration file should be processed *before* the default file. So I named the file /etc/sysctl.d/01-sysrq.conf. BR G.Baroncelli > >> >> Michael >> > G.Baroncelli > -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725422: systemd set kernel.sysrq=16
On 2013-10-06 01:00, Michael Biebl wrote: > tags 725422 + moreinfo > severity 725422 normal > thanks > > Am 05.10.2013 18:27, schrieb Goffredo Baroncelli: >> Package: systemd >> Version: 204-5 >> Severity: important >> Tags: upstream >> >> >> Problem description: >> After installing the systemd package some sysrq keys don't work any more. >> >> Expected behaviour: >> The systemd package must not interact with the sysrq key setting >> >> Analysis: >> The systemd package contains the file /usr/lib/sysctl.d/50-default.conf. In >> this file there is the following entry: >> >># System Request functionality of the kernel (SYNC) >>kernel.sysrq = 16 >> >> which changes the allowable sysrq key. This entry is present also in the >> upstream package. >> >> Suggested solution: >> Comment the entry "kernel.sysrq = 16" in the file >> /usr/lib/sysctl.d/50-default.conf. > > You failed to justify why kernel.sysrq = 16 is a bad default. > Can you elaborate? I didn't argue about the default value for kernel.sysrq. I am arguing that it is not the job of systemd to change/force a value of kernel.sysrq. Anyway I was not able to find the reason behind this value. May be it is good for the average user, I don't know. I want to have the ability to do a Sync, saK, Umount and reBoot when my system crashed. BTW, I am looking a way to change this default without changing this file. I supposed that adding a file in /etc/sysctl.d with the MY default would be sufficient, but it seems not the case > > Michael > G.Baroncelli -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725422: systemd set kernel.sysrq=16
Package: systemd Version: 204-5 Severity: important Tags: upstream Problem description: After installing the systemd package some sysrq keys don't work any more. Expected behaviour: The systemd package must not interact with the sysrq key setting Analysis: The systemd package contains the file /usr/lib/sysctl.d/50-default.conf. In this file there is the following entry: # System Request functionality of the kernel (SYNC) kernel.sysrq = 16 which changes the allowable sysrq key. This entry is present also in the upstream package. Suggested solution: Comment the entry "kernel.sysrq = 16" in the file /usr/lib/sysctl.d/50-default.conf. Further information: This bug is signalled also for suse [1] and mageia [2]. This entry was added by the following commit [3] in the systemd git repository. BR G.Baroncelli [1] Bug 820443 - https://bugzilla.novell.com/show_bug.cgi?id=820443 [2] Bug 10473 - https://bugs.mageia.org/show_bug.cgi?id=10473 [3] 0f59fe5171b5564fc6fb58f3281fbc259c45f7d0 - http://cgit.freedesktop.org/systemd/systemd/commit/sysctl.d/50-default.conf?id=0f59fe5171b5564fc6fb58f3281fbc259c45f7d0 -- Package-specific info: -- systemd-delta: -- 0 overridden configuration files found. -- systemctl dump: -- [cut .. cut .. cut] -- Contents of /var/lib/systemd/deb-systemd-helper-enabled: -- ==> /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/rsyslog.service <== ==> /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/lm-sensors.service <== ==> /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/bind9.service <== ==> /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/atd.service <== ==> /var/lib/systemd/deb-systemd-helper-enabled/syslog.service <== ==> /var/lib/systemd/deb-systemd-helper-enabled/gpsd.socket.dsh-also <== /etc/systemd/system/sockets.target.wants/gpsd.socket ==> /var/lib/systemd/deb-systemd-helper-enabled/sockets.target.wants/gpsd.socket <== ==> /var/lib/systemd/deb-systemd-helper-enabled/gpsd.service.dsh-also <== /etc/systemd/system/sockets.target.wants/gpsd.socket ==> /var/lib/systemd/deb-systemd-helper-enabled/lm-sensors.service.dsh-also <== /etc/systemd/system/multi-user.target.wants/lm-sensors.service ==> /var/lib/systemd/deb-systemd-helper-enabled/bind9-resolvconf.service.dsh-also <== /etc/systemd/system/bind9.service.wants/bind9-resolvconf.service ==> /var/lib/systemd/deb-systemd-helper-enabled/bind9.service.dsh-also <== /etc/systemd/system/multi-user.target.wants/bind9.service ==> /var/lib/systemd/deb-systemd-helper-enabled/rsyslog.service.dsh-also <== /etc/systemd/system/multi-user.target.wants/rsyslog.service /etc/systemd/system/syslog.service /etc/systemd/system/multi-user.target.wants/rsyslog.service /etc/systemd/system/syslog.service /etc/systemd/system/multi-user.target.wants/rsyslog.service /etc/systemd/system/syslog.service ==> /var/lib/systemd/deb-systemd-helper-enabled/atd.service.dsh-also <== /etc/systemd/system/multi-user.target.wants/atd.service ==> /var/lib/systemd/deb-systemd-helper-enabled/accounts-daemon.service.dsh-also <== /etc/systemd/system/graphical.target.wants/accounts-daemon.service ==> /var/lib/systemd/deb-systemd-helper-enabled/graphical.target.wants/accounts-daemon.service <== -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11.3 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages systemd depends on: ii initscripts 2.88dsf-43 ii libacl1 2.2.52-1 ii libaudit11:2.3.2-2 ii libc62.17-93 ii libcap2 1:2.22-1.2 ii libcryptsetup4 2:1.6.1-1 ii libdbus-1-3 1.6.14-1 ii libgcrypt11 1.5.3-2 ii libkmod2 9-3 ii liblzma5 5.1.1alpha+20120614-2 ii libpam0g 1.1.3-9 ii libselinux1 2.1.13-3 ii libsystemd-daemon0 204-5 ii libsystemd-journal0 204-5 ii libsystemd-login0204-5 ii libudev1 204-5 ii libwrap0 7.6.q-24 ii udev 204-5 ii util-linux 2.20.1-5.5 Versions of packages systemd recommends: ii libpam-systemd 204-5 Versions of packages systemd suggests: ii systemd-ui 2-2 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org