Processed: moreinfo
Processing commands for cont...@bugs.debian.org: > tags 876102 + moreinfo Bug #876102 [udev] udev: boot fails x86 32-bit debian 9 w/ kernel 4.9.50 Added tag(s) moreinfo. > thanks Stopping processing here. Please contact me if you need assistance. -- 876102: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876102 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#876102: udev: boot fails x86 32-bit debian 9 w/ kernel 4.9.50
Am 18.09.2017 um 15:29 schrieb William Herrin: > Package: udev > Version: 232-25+deb9u1 > Severity: important > > Dear Maintainer, > >* What led up to the situation? > upgrade from debian 8 custom kernel 3.14.79 to debian 9 custom kernel 4.9.50 > >* What exactly did you do (or not do) that was effective (or > ineffective)? > apt-get dist-upgrade. dpkg -i kernel. reboot. > >* What was the outcome of this action? > boot failed; filesystems other than root not mounted. Drop to emergency shell. > >* What outcome did you expect instead? > boot succeeded > > details: udev created the basic hard disk devices (/dev/vd*) but did not > create the /dev/disk and /dev/block directory trees and did not mount the > the /home filesystem from /dev/vdc1 or activate the swap from /dev/vdb1 > even if the /dev/vd device was explicitly referenced in /etc/fstab. > > > This only happened on my sole remaining 32 bit VM. I did not experience the > problem on any of the x86_64 servers I upgraded. > > I did not experience the problem when booting debian 9 under kernel 3.14.79. > > The problem happened with both the x86 and x86_64 compiles of kernel 4.9.50 > when booting the 32-bit linux install. The same kernel 4.9.50 x86_64 image > booted successfully on other servers running debian 9 x86_64. > Is the problem reproducible with a Debian provided kernel? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: [bts-link] source package systemd
Processing commands for cont...@bugs.debian.org: > # > # bts-link upstream status pull for source package systemd > # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html > # > user bts-link-upstr...@lists.alioth.debian.org Setting user to bts-link-upstr...@lists.alioth.debian.org (was bts-link-de...@lists.alioth.debian.org). > # remote status report for #865081 (http://bugs.debian.org/865081) > # Bug title: udevadm: -y documentation wrong > # * https://github.com/systemd/systemd/issues/6792 > # * remote status changed: open -> closed > # * closed upstream > tags 865081 + fixed-upstream Bug #865081 [udev] udevadm: -y documentation wrong Added tag(s) fixed-upstream. > usertags 865081 - status-open Usertags were: status-open. Usertags are now: . > usertags 865081 + status-closed There were no usertags set. Usertags are now: status-closed. > # remote status report for #865450 (http://bugs.debian.org/865450) > # Bug title: systemd: tmpfs size mount option ignored when expressed in % > # * https://github.com/systemd/systemd/issues/6374 > # * remote status changed: open -> closed > # * closed upstream > tags 865450 + fixed-upstream Bug #865450 [systemd] systemd: tmpfs size mount option ignored when expressed in % Added tag(s) fixed-upstream. > usertags 865450 - status-open Usertags were: status-open. Usertags are now: . > usertags 865450 + status-closed There were no usertags set. Usertags are now: status-closed. > thanks Stopping processing here. Please contact me if you need assistance. -- 865081: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865081 865450: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865450 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
[bts-link] source package systemd
# # bts-link upstream status pull for source package systemd # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user bts-link-upstr...@lists.alioth.debian.org # remote status report for #865081 (http://bugs.debian.org/865081) # Bug title: udevadm: -y documentation wrong # * https://github.com/systemd/systemd/issues/6792 # * remote status changed: open -> closed # * closed upstream tags 865081 + fixed-upstream usertags 865081 - status-open usertags 865081 + status-closed # remote status report for #865450 (http://bugs.debian.org/865450) # Bug title: systemd: tmpfs size mount option ignored when expressed in % # * https://github.com/systemd/systemd/issues/6374 # * remote status changed: open -> closed # * closed upstream tags 865450 + fixed-upstream usertags 865450 - status-open usertags 865450 + status-closed thanks ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#876103: systemd-nspawn: --read-only is broken
Package: systemd-container Version: 232-25+deb9u1 Severity: normal Dear Maintainer, on stretch, 'systemd-nspawn --read-only' fails to start the container entirely. Trivial test case: # machinectl pull-tar https://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-root.tar.gz [ output omitted ] # systemd-nspawn -M xenial-server-cloudimg-amd64-root -- true # systemd-nspawn -M xenial-server-cloudimg-amd64-root --read-only -- true Spawning container xenial-server-cloudimg-amd64-root on /var/lib/machines/xenial-server-cloudimg-amd64-root. Press ^] three times within 1s to kill container. Failed to create directory /var/lib/machines/xenial-server-cloudimg-amd64-root/sys: Read-only file system (the first systemd-nspawn call is there to implicitly create some directories inside the container root that must exist for read-only to work) The expected behavior is that 'true' is executed in container and exit status 0 is returned; however, the container is not started and the exit status is 1. There is an upstream fix for this in https://github.com/systemd/systemd/pull/4693 -- acbbf69b718260755a5dff60dd68ba239ac0d61b is the commit that actually fixes read-only containers, but it requires two other commits to apply cleanly. I applied the following sequence to systemd-container on stretch: https://github.com/systemd/systemd/commit/bdb4e0cb646ff33ecbb1cf4b502870f84bf4016d https://github.com/systemd/systemd/commit/4f086aab52812472a24c9b8b627589880a38696e https://github.com/systemd/systemd/commit/acbbf69b718260755a5dff60dd68ba239ac0d61b and it solved my problem. Could you backport these patches to stretch? -- System Information: Debian Release: 9.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd-container depends on: ii dbus 1.10.18-1 ii libacl1 2.2.52-3+b1 ii libblkid12.29.2-1 ii libbz2-1.0 1.0.6-8.1 ii libc62.24-11+deb9u1 ii libcurl3-gnutls 7.52.1-5 ii libgcrypt20 1.7.6-2+deb9u2 ii libip4tc01.6.0+snapshot20161117-6 ii liblzma5 5.2.2-1.2+b1 ii libseccomp2 2.3.1-2.1 ii libselinux1 2.6-3+b1 ii systemd 232-25+deb9u1 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages systemd-container recommends: ii btrfs-progs4.7.3-1 ii libnss-mymachines 232-25+deb9u1 systemd-container suggests no packages. -- no debconf information ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
