Re: Bug#782712: pre-upload unblock request: systemd/215-17 for RC bug #751707
Martin Pitt [2015-04-16 14:53 -0500]: > Hello Cyril, > > Cyril Brulebois [2015-04-16 19:40 +0200]: > > Anyway, asking for home encryption indeed leads to swap encryption, > > through a ecryptfs-setup-swap call, which in turn triggers: I just tried the current rc2 installer (netinst image/graphical) and it does not actually ask me whether I want to encrypt my home direction. It seems you got this option? If the installer calls ecryptfs-setup-swap, then IMHO we should also fix ecryptfs-utils by the release. If the installer doesn't offer this, but people run ecryptfs-setup-swap manually after installation, then a post-release fix is fine of course. But either way I'd rather like to see the systemd fix in the release proper, as it breaks existing installations with that config. BTW, 215-16 still didn't hit testing, so I didn't upload -17 yet. I'll do as soon as it migrates. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Bug#782712: pre-upload unblock request: systemd/215-17 for RC bug #751707
Martin Pitt (2015-04-17): > I just tried the current rc2 installer (netinst image/graphical) and > it does not actually ask me whether I want to encrypt my home > direction. It seems you got this option? I tried to follow the code path in Ubuntu, which offers this option, to track down where the offset can come from; and see whether Debian was affected. I didn't mean to imply that Debian proposes the same option, as it does not. > BTW, 215-16 still didn't hit testing, so I didn't upload -17 yet. I'll > do as soon as it migrates. systemd| 215-16 | testing systemd| 215-16 | unstable Mraw, KiBi. signature.asc Description: Digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Bug#782712: pre-upload unblock request: systemd/215-17 for RC bug #751707
On 17/04/15 13:51, Martin Pitt wrote: > BTW, 215-16 still didn't hit testing, so I didn't upload -17 yet. I'll > do as soon as it migrates. systemd| 215-16 | testing | source, amd64, arm64, armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x systemd| 215-16 | unstable | source, amd64, arm64, armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x, sparc Emilio ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#732209: unable to create file '/run/user/1000/dconf/user': Permission denied
On Mon, 16 Feb 2015 20:37:26 +0100 Miklos Quartus wrote: > Package: libpam-systemd > Version: 215-11 > Followup-For: Bug #732209 > > Hi Vlad, > > Yes, I am still able to reproduce this bug in my GNOME session in my > latest Jessie, indeed. After opening the root terminal window and in > focus, I can use three ways to trigger: > > 1. In a standar user terminal open a shell and run "gksu gedit". > 2. Type Super key and search dconf-Editor and run it. > 3. Type Super key and search for Files file manager and run it. Using GNOME here as well. I'm not able to reproduce the problem with the steps you outlined. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processing of systemd_215-17_amd64.changes
systemd_215-17_amd64.changes uploaded successfully to localhost along with the files: systemd_215-17.dsc systemd_215-17.debian.tar.xz systemd_215-17_amd64.deb systemd-sysv_215-17_amd64.deb libpam-systemd_215-17_amd64.deb libsystemd0_215-17_amd64.deb libsystemd-dev_215-17_amd64.deb libsystemd-login0_215-17_amd64.deb libsystemd-login-dev_215-17_amd64.deb libsystemd-daemon0_215-17_amd64.deb libsystemd-daemon-dev_215-17_amd64.deb libsystemd-journal0_215-17_amd64.deb libsystemd-journal-dev_215-17_amd64.deb libsystemd-id128-0_215-17_amd64.deb libsystemd-id128-dev_215-17_amd64.deb udev_215-17_amd64.deb libudev1_215-17_amd64.deb libudev-dev_215-17_amd64.deb udev-udeb_215-17_amd64.udeb libudev1-udeb_215-17_amd64.udeb libgudev-1.0-0_215-17_amd64.deb gir1.2-gudev-1.0_215-17_amd64.deb libgudev-1.0-dev_215-17_amd64.deb python3-systemd_215-17_amd64.deb systemd-dbg_215-17_amd64.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Bug#782712: pre-upload unblock request: systemd/215-17 for RC bug #751707
Hello all, Cyril Brulebois [2015-04-17 14:15 +0200]: > I tried to follow the code path in Ubuntu, which offers this option, to > track down where the offset can come from; and see whether Debian was > affected. I didn't mean to imply that Debian proposes the same option, > as it does not. Ah ok, that explains the confusion. So let's fix ecryptfs in a post-release update, I'll file a bug with the references and explanations. > systemd| 215-16 | testing > systemd| 215-16 | unstable -17 uploaded with the originally attached patch. The only difference is the s/UNRELEASED/unstable/ and the timestamp in the changelog. Thanks, and sorry for the late timing again! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#732209: unable to create file '/run/user/1000/dconf/user': Permission denied
I'm able to reproduce this bug using Mate. In my case it always boils down to right-clicking a file or dir and try to delete it in caja (bypasing the 'prullenbak' in Dutch, probably something like trash bin in English), then caja crashes and /run/user/1000/dconf/user is owned by root. Timestamp of /run/user/1000/dconf/user (owned by root) is usualy at least 2 hours before the crash occurs, strange (UTC? my timezone differs 2 hours with utc). Typical this crash happens when doing this right-click and delete in caja more the 10 times. Don't know if that means anything though... Op 17-04-15 om 15:01 schreef Michael Biebl: On Mon, 16 Feb 2015 20:37:26 +0100 Miklos Quartus wrote: Package: libpam-systemd Version: 215-11 Followup-For: Bug #732209 Hi Vlad, Yes, I am still able to reproduce this bug in my GNOME session in my latest Jessie, indeed. After opening the root terminal window and in focus, I can use three ways to trigger: 1. In a standar user terminal open a shell and run "gksu gedit". 2. Type Super key and search dconf-Editor and run it. 3. Type Super key and search for Files file manager and run it. Using GNOME here as well. I'm not able to reproduce the problem with the steps you outlined. ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
systemd_215-17_amd64.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 16 Apr 2015 10:26:46 -0500 Source: systemd Binary: systemd systemd-sysv libpam-systemd libsystemd0 libsystemd-dev libsystemd-login0 libsystemd-login-dev libsystemd-daemon0 libsystemd-daemon-dev libsystemd-journal0 libsystemd-journal-dev libsystemd-id128-0 libsystemd-id128-dev udev libudev1 libudev-dev udev-udeb libudev1-udeb libgudev-1.0-0 gir1.2-gudev-1.0 libgudev-1.0-dev python3-systemd systemd-dbg Architecture: source amd64 Version: 215-17 Distribution: unstable Urgency: high Maintainer: Debian systemd Maintainers Changed-By: Martin Pitt Description: gir1.2-gudev-1.0 - libgudev-1.0 introspection data libgudev-1.0-0 - GObject-based wrapper library for libudev libgudev-1.0-dev - libgudev-1.0 development files libpam-systemd - system and service manager - PAM module libsystemd-daemon-dev - systemd utility library (transitional package) libsystemd-daemon0 - systemd utility library (deprecated) libsystemd-dev - systemd utility library - development files libsystemd-id128-0 - systemd 128 bit ID utility library (deprecated) libsystemd-id128-dev - systemd 128 bit ID utility library (transitional package) libsystemd-journal-dev - systemd journal utility library (transitional package) libsystemd-journal0 - systemd journal utility library (deprecated) libsystemd-login-dev - systemd login utility library (transitional package) libsystemd-login0 - systemd login utility library (deprecated) libsystemd0 - systemd utility library libudev-dev - libudev development files libudev1 - libudev shared library libudev1-udeb - libudev shared library (udeb) python3-systemd - Python 3 bindings for systemd systemd- system and service manager systemd-dbg - system and service manager (debug symbols) systemd-sysv - system and service manager - SysV links udev - /dev/ and hotplug management daemon udev-udeb - /dev/ and hotplug management daemon (udeb) Closes: 751707 Changes: systemd (215-17) unstable; urgency=high . * cryptsetup: Implement offset and skip options. (Closes: #751707, LP: #953875) Checksums-Sha1: a806a18326ebc78c82e5eb2140570264b5531211 4107 systemd_215-17.dsc c7f4fda8c6ee7fb2b02e6c18e8003d4ccd39e1be 206064 systemd_215-17.debian.tar.xz bd4a62bf8e117b1ed757f94f47550077e4cd52c4 2543010 systemd_215-17_amd64.deb cbe099a2f9eb25ece0dde36b30f7938fb3385e21 33914 systemd-sysv_215-17_amd64.deb 6cc89bde7afbce4f59334e56ef5c1932ff15ade5 123390 libpam-systemd_215-17_amd64.deb fa637535795c946c5d0dd593c8d916c70ed0ab11 86636 libsystemd0_215-17_amd64.deb 56d37ea2980a0094ea3e9ee10fadbda3743cfa98 92814 libsystemd-dev_215-17_amd64.deb b76889c94cc75e541c72c54aae198cb33a278185 46990 libsystemd-login0_215-17_amd64.deb 7cebf001e89a0d6f9ef710c4ce0917c1d35e7c7b 29498 libsystemd-login-dev_215-17_amd64.deb f2a7acc2b7712c655e877716ef4b89eaf2344153 36090 libsystemd-daemon0_215-17_amd64.deb 87a645a44234d89c6f99646eef050d9496db94aa 29516 libsystemd-daemon-dev_215-17_amd64.deb c640839f53642a3839aeacf6d3eadd487c9a891b 72142 libsystemd-journal0_215-17_amd64.deb 38394256f7388b127247f89f3d8a2e1e03bd52e8 29488 libsystemd-journal-dev_215-17_amd64.deb 250aacde145a3d20d4432718466cdbf96d055e92 35068 libsystemd-id128-0_215-17_amd64.deb c2fbaeae705c740898d0f5443e1dd02f32db0573 29482 libsystemd-id128-dev_215-17_amd64.deb 079c300a7df5703c6dafb3ed25a9108f10728230 874212 udev_215-17_amd64.deb 241ffd584e22678dfe8061e000c925532816deb8 54980 libudev1_215-17_amd64.deb 67ce6e7259294aaaf044e731d512a2faaf1acbce 23128 libudev-dev_215-17_amd64.deb a4089c1dd554eee972b2cd86071384f5f41916f9 195502 udev-udeb_215-17_amd64.udeb 59c1f4398c5f0f5fd5d1cd817c769452fa33f0d4 24736 libudev1-udeb_215-17_amd64.udeb b7d97a12b996ec3b0183f5ebf4853559946935f1 39828 libgudev-1.0-0_215-17_amd64.deb 32d5603df4c89aa4d9a9e795f2b754cc7a6a58d7 2830 gir1.2-gudev-1.0_215-17_amd64.deb 31ada59bc028a101a251d8a4d54c285e2ae0f6e0 24498 libgudev-1.0-dev_215-17_amd64.deb 0839b11d326b6d839829fb2b8d14dd916826a917 59300 python3-systemd_215-17_amd64.deb fea9585c0bbe15357ce3463508a35e72ce922f6e 15974894 systemd-dbg_215-17_amd64.deb Checksums-Sha256: 83e2eeb01b02ddfa5ab5977605d58f6329a72149e9edd4c664ba27e6afaa773c 4107 systemd_215-17.dsc bdfad7816d0341e3377ae02972613382a72c85b59812e0f1a445add005f4fa2a 206064 systemd_215-17.debian.tar.xz 0be0f9414cf0c52dcc31c49ddb68788d1428d7a19e6580da59edb2e098c8c141 2543010 systemd_215-17_amd64.deb aa7059998e9523283ec59d4e3863b71a5248c118ab8db0f8abc9c4ca782f98c0 33914 systemd-sysv_215-17_amd64.deb f4515c3eff4bb32147cfeffd4ecc34d4ea0ff95aaf6f3c1dd8527439f22e6fef 123390 libpam-systemd_215-17_amd64.deb 93061c997a8e57f1b763c240c4aa4cd2dc58a050fa50dac890a7406d79629a9b 86636 libsystemd0_215-17_amd64.deb e45a30586fa68642a9f2f4b9dea584ef1710aacc11e698df7b8e999ae267d540 92814 libsystemd-dev_215-17_amd64.deb f9bcd7db8c48c1021ddab2861f0795e8a6f3f3d41bbb2b70a22bf259a00ee69b 46990 libsystemd-login0_215-17_amd64.d
Bug#751707: marked as done (systemd: offset is ignored in /etc/crypttab)
Your message dated Fri, 17 Apr 2015 15:49:31 + with message-id and subject line Bug#751707: fixed in systemd 215-17 has caused the Debian Bug report #751707, regarding systemd: offset is ignored in /etc/crypttab to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 751707: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751707 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: systemd Version: 204-10 Severity: normal Dear Maintainer, My /etc/crypttab contains swap_raw /dev/disk/by-uuid/1e0707ec-4420-49b7-96db-b3a5e72325be /dev/urandom swap,cipher=aes-cbc-essiv:sha256,size=128,hash=sha256,offset=4096 and this worked fine with cryptdisks_start however the option "offset" is not understood by systemd. I did "apt-get upgrade" which installed systemd, and now, after a couple of reboots, I don't have any swap and my device /dev/disk/by-uuid/1e0707ec-4420-49b7-96db-b3a5e72325be has vanished. The use case for "offset=4096" is to be able to use a UUID to identify the partition I want to have encrypted swap on. Putting enscrypted swap on a partition unconditionally erases the partition. Using any other way to identify a partition can thus cause data loss if I reformat the partition being used for the swap and forget to update /etc/crypttab. Please make systemd understand "offset". I was also bitten by the bug 618862 (systemd: ignores keyscript in crypttab) but on a different partition. thanks, Stuart Pook -- Package-specific info: -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages systemd depends on: ii acl 2.2.52-1 ii adduser 3.113+nmu3 ii initscripts 2.88dsf-53.2 ii libacl1 2.2.52-1 ii libaudit11:2.3.7-1 ii libc62.19-1 ii libcap2 1:2.22-1.2 ii libcap2-bin 1:2.22-1.2 ii libcryptsetup4 2:1.6.4-4 ii libdbus-1-3 1.8.4-1 ii libgcrypt11 1.5.3-4 ii libkmod2 17-2 ii liblzma5 5.1.1alpha+20120614-2 ii libpam0g 1.1.8-3 ii libselinux1 2.3-1 ii libsystemd-daemon0 204-10 ii libsystemd-journal0 204-10 ii libsystemd-login0204-10 ii libudev1 204-10 ii libwrap0 7.6.q-25 ii sysv-rc 2.88dsf-53.2 ii udev 204-10 ii util-linux 2.20.1-5.8 Versions of packages systemd recommends: ii libpam-systemd 204-10 Versions of packages systemd suggests: pn systemd-ui -- no debconf information [OVERRIDDEN] /etc/systemd/system/syslog-ng.service → /lib/systemd/system/syslog-ng.service --- /lib/systemd/system/syslog-ng.service 2014-03-19 09:46:00.0 +0100 +++ /etc/systemd/system/syslog-ng.service 2013-03-02 16:18:33.0 +0100 @@ -1,15 +1 @@ -[Unit] -Description=System Logger Daemon -Documentation=man:syslog-ng(8) - -[Service] -Type=notify -Sockets=syslog.socket -ExecStart=/usr/sbin/syslog-ng -F -ExecReload=/bin/kill -HUP $MAINPID -StandardOutput=null -Restart=on-failure - -[Install] -WantedBy=multi-user.target -Alias=syslog.service +.include /lib/systemd/system/syslog-ng.service 1 overridden configuration files found. ==> /var/lib/systemd/deb-systemd-helper-enabled/lvm2-activation-early.service.dsh-also <== /etc/systemd/system/local-fs.target.wants/lvm2-activation-early.service ==> /var/lib/systemd/deb-systemd-helper-enabled/cups.service.dsh-also <== /etc/systemd/system/sockets.target.wants/cups.socket /etc/systemd/system/multi-user.target.wants/cups.path /etc/systemd/system/printer.target.wants/cups.service ==> /var/lib/systemd/deb-systemd-helper-enabled/dbus-org.freedesktop.Avahi.service <== ==> /var/lib/systemd/deb-systemd-helper-enabled/cups.path.dsh-also <== /etc/systemd/system/multi-user.target.wants/cups.path ==> /var/lib/systemd/deb-systemd-helper-enabled/pppd-dns.service.dsh-also <== /etc/systemd/system/multi-user.target.wants/pppd-dns.service ==> /var/lib/systemd/deb-systemd-helper-enabled/dbus-org.bluez.service <== ==> /var/lib/systemd/deb-systemd-helper-enabled/cron.service.dsh-also <== /etc/systemd/system/multi-user.target.wants/cron.service ==> /var/lib/systemd/deb-systemd-helper-enabled/NetworkManager-wait-online.service.dsh-also <== /etc/systemd/system/multi-user.target.wants/NetworkManager-wait-onli
Re: Bug#782712: pre-upload unblock request: systemd/215-17 for RC bug #751707
On 2015-04-17 15:44, Martin Pitt wrote: > Hello all, > > Cyril Brulebois [2015-04-17 14:15 +0200]: >> I tried to follow the code path in Ubuntu, which offers this option, to >> track down where the offset can come from; and see whether Debian was >> affected. I didn't mean to imply that Debian proposes the same option, >> as it does not. > > Ah ok, that explains the confusion. So let's fix ecryptfs in a > post-release update, I'll file a bug with the references and > explanations. > >> systemd| 215-16 | testing >> systemd| 215-16 | unstable > > -17 uploaded with the originally attached patch. The only difference > is the s/UNRELEASED/unstable/ and the timestamp in the changelog. > > Thanks, and sorry for the late timing again! > > Martin > Hi, Just to clarify, are we still intending to do a systemd update prior to Jessie with -17 and then now also a p-u (i.e. for 8.1) for ecryptfs? If we are /not/ pulling systemd for Jessie release next release, we can document the issue for the release notes (possibly as a "non-standard" setup given d-i in Debian does not create this kind of disks, if I understand the discussion correctly). Thanks, ~Niels ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Bug#782712: pre-upload unblock request: systemd/215-17 for RC bug #751707
Martin Pitt wrote: > P. S. Swap partitions, will you please just die. Most systems don't > need them any more, and those who do are better of with the > "swapspace" package or similar. But that's waay out of reach for > Jessie :-) Personally, I don't care about swap for memory purposes, but I like being able to hibernate. Last I checked, the mechanisms used to hibernate to a swap file were fragile, even more so if you want to hibernate to a swap file inside an encrypted root filesystem, and they still required a pre-allocated swap file. I'd love to see a mechanism that allowed hibernation to a file that's created at hibernate time, inside an encrypted partition. - Josh Triplett ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
systemd 215-16 MIGRATED to testing
FYI: The status of the systemd source package in Debian's testing distribution has changed. Previous version: 215-14 Current version: 215-16 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See https://release.debian.org/testing-watch/ for more 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
Re: Bug#782712: pre-upload unblock request: systemd/215-17 for RC bug #751707
Hello Niels, Niels Thykier [2015-04-17 17:55 +0200]: > Just to clarify, are we still intending to do a systemd update prior to > Jessie with -17 and then now also a p-u (i.e. for 8.1) for ecryptfs? That's still my intent, yes, primarily to avoid people who have this set up in wheezy already (#751707 has at least two reporters) upgrade and find their swap partition gone and boot stuck. > If we are /not/ pulling systemd for Jessie release next release, we can > document the issue for the release notes (possibly as a "non-standard" > setup given d-i in Debian does not create this kind of disks, if I > understand the discussion correctly). That's possible as well, of course. In this case you should revert to sysvinit (or upstart) straight after upgrading, *before* you reboot (after it's too late). I documented the manual upgrade fix on the LP bug a while ago: https://launchpad.net/bugs/953875 (in the description). Maybe some bits could also be stolen from there. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#762953: Bug still present in latest Sid
I’ve seen this bug today. System drops into emergency mode for reasons that have nothing to do with this bug. Network is active when in emergency shell. I type root password then immediately exit, system continues to boot. When boot is finished, network is not active. system journal of full boot is attached. Hope this helps! Rick -- Logs begin at Fri 2015-04-17 04:55:26 PDT, end at Fri 2015-04-17 13:39:47 PDT. -- Apr 17 04:55:26 cube systemd-journal[163]: Runtime journal is using 5.0M (max allowed 40.4M, trying to leave 60.6M free of 399.0M available â current limit 40.4M). Apr 17 04:55:26 cube systemd-journal[163]: Runtime journal is using 5.0M (max allowed 40.4M, trying to leave 60.6M free of 399.0M available â current limit 40.4M). Apr 17 04:55:26 cube kernel: Booting Linux on physical CPU 0x0 Apr 17 04:55:26 cube kernel: Initializing cgroup subsys cpuset Apr 17 04:55:26 cube kernel: Initializing cgroup subsys cpu Apr 17 04:55:26 cube kernel: Initializing cgroup subsys cpuacct Apr 17 04:55:26 cube kernel: Linux version 3.16.0-4-armmp (debian-ker...@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt9-2 (2015-04-13) Apr 17 04:55:26 cube kernel: CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d Apr 17 04:55:26 cube kernel: CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache Apr 17 04:55:26 cube kernel: Machine model: SolidRun Cubox-i Dual/Quad Apr 17 04:55:26 cube kernel: Memory policy: Data cache writealloc Apr 17 04:55:26 cube kernel: On node 0 totalpages: 524288 Apr 17 04:55:26 cube kernel: free_area_init_node: node 0, pgdat c09dc700, node_mem_map ee7f8000 Apr 17 04:55:26 cube kernel: DMA zone: 1520 pages used for memmap Apr 17 04:55:26 cube kernel: DMA zone: 0 pages reserved Apr 17 04:55:26 cube kernel: DMA zone: 194560 pages, LIFO batch:31 Apr 17 04:55:26 cube kernel: HighMem zone: 2576 pages used for memmap Apr 17 04:55:26 cube kernel: HighMem zone: 329728 pages, LIFO batch:31 Apr 17 04:55:26 cube kernel: PERCPU: Embedded 9 pages/cpu @ee7b3000 s12608 r8192 d16064 u36864 Apr 17 04:55:26 cube kernel: pcpu-alloc: s12608 r8192 d16064 u36864 alloc=9*4096 Apr 17 04:55:26 cube kernel: pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 Apr 17 04:55:26 cube kernel: Built 1 zonelists in Zone order, mobility grouping on. Total pages: 522768 Apr 17 04:55:26 cube kernel: Kernel command line: console=ttymxc0,115200 quiet Apr 17 04:55:26 cube kernel: PID hash table entries: 4096 (order: 2, 16384 bytes) Apr 17 04:55:26 cube kernel: Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Apr 17 04:55:26 cube kernel: Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Apr 17 04:55:26 cube kernel: Memory: 2054820K/2097152K available (6404K kernel code, 828K rwdata, 2204K rodata, 684K init, 393K bss, 42332K reserved, 1318912K highmem) Apr 17 04:55:26 cube kernel: Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xffc0 - 0xffe0 (2048 kB) vmalloc : 0xf000 - 0xff00 ( 240 MB) lowmem : 0xc000 - 0xef80 ( 760 MB) pkmap : 0xbfe0 - 0xc000 ( 2 MB) modules : 0xbf00 - 0xbfe0 ( 14 MB) .text : 0xc0008000 - 0xc08702e4 (8609 kB) .init : 0xc0871000 - 0xc091c140 ( 685 kB) .data : 0xc091e000 - 0xc09ed3d0 ( 829 kB) .bss : 0xc09ed3d0 - 0xc0a4f874 ( 394 kB) Apr 17 04:55:26 cube kernel: Hierarchical RCU implementation. Apr 17 04:55:26 cube kernel: RCU dyntick-idle grace-period acceleration is enabled. Apr 17 04:55:26 cube kernel: NR_IRQS:16 nr_irqs:16 16 Apr 17 04:55:26 cube kernel: L2C-310 erratum 769419 enabled Apr 17 04:55:26 cube kernel: L2C-310 enabling early BRESP for Cortex-A9 Apr 17 04:55:26 cube kernel: L2C-310 full line of zeros enabled for Cortex-A9 Apr 17 04:55:26 cube kernel: L2C-310 ID prefetch enabled, offset 1 lines Apr 17 04:55:26 cube kernel: L2C-310 dynamic clock gating enabled, standby mode enabled Apr 17 04:55:26 cube kernel: L2C-310 cache controller enabled, 16 ways, 1024 kB Apr 17 04:55:26 cube kernel: L2C-310: CACHE_ID 0x41c7, AUX_CTRL 0x76070001 Apr 17 04:55:26 cube kernel: Switching to timer-based delay loop Apr 17 04:55:26 cube kernel: sched_clock: 32 bits at 66MHz, resolution 15ns, wraps every 65075262448ns Apr 17 04:55:26 cube kernel: Console: colour dummy device 80x30 Apr 17 04:55:26 cube kernel: Calibrating delay loop (skipped), value calculated using timer frequency.. 132.00 BogoMIPS (lpj=264000) Apr 17 04:55:26 cube kernel: pid_max: default: 32768 minimum: 301 Apr 17 04:55:26 cube kernel: Security Framework initialized Apr 17 04:55:26 cube kernel: A
Bug#762953: Bug still present in latest Sid
Am 17.04.2015 um 22:49 schrieb Rick Thomas: > > I’ve seen this bug today. > > System drops into emergency mode for reasons that have nothing to do with > this bug. Network is active when in emergency shell. I type root password > then immediately exit, system continues to boot. When boot is finished, > network is not active. > > system journal of full boot is attached. I assume you use ifupdown to configure your network? Do you use allow-hotplug or auto? Can you attach your /etc/network/interfaces file? Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#762953: Bug still present in latest Sid -- /etc/network/interfaces
interfaces Description: Binary data This is “fresh out of the box” as it comes from the debian installer process. I have made no changes. Rick On Apr 17, 2015, at 2:57 PM, Michael Biebl wrote: > Am 17.04.2015 um 22:49 schrieb Rick Thomas: >> >> I’ve seen this bug today. >> >> System drops into emergency mode for reasons that have nothing to do with >> this bug. Network is active when in emergency shell. I type root password >> then immediately exit, system continues to boot. When boot is finished, >> network is not active. >> >> system journal of full boot is attached. > > I assume you use ifupdown to configure your network? > Do you use allow-hotplug or auto? Can you attach your > /etc/network/interfaces file? > > Michael > > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? > ___ 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#782793: systemd: ext4 filesystem on lvm on raid causes boot to enter emergency shell
Am 17.04.2015 um 23:43 schrieb Rick Thomas: > Package: systemd > Version: 215-16 > Severity: important > > When /etc/fstab has an ext4 filesystem on a logical volume which is itself > on a software raid, the system times out waiting for (I think!) fsck on that > filesystem. > This causes the boot to drop into the emergency shell. > If I just type "^D" and allow the boot to continue, the filesystem is mounted > but > never fsck-ed. > > systemd journal of boot is attached. > /etc/fstab is attached. > /etc/modules is attached > /etc/modprobe.d/mdadm.conf is attached > /etc/mdadm/mdadm.conf is attached > > The filesystem in question is "/backup" which is on logical-volume > "vg1-backup", which is on RAID device "/dev/md127" When you are dropped into emergency shell, can you get the following data ls -al /dev/disk/by-label udevadm info -e mdadm --info /dev/md127 lvscan pvscan vgscan -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#782793: systemd: ext4 filesystem on lvm on raid causes boot to enter emergency shell
On Apr 17, 2015, at 3:17 PM, Michael Biebl wrote: > Am 17.04.2015 um 23:43 schrieb Rick Thomas: >> Package: systemd >> Version: 215-16 >> Severity: important >> >> When /etc/fstab has an ext4 filesystem on a logical volume which is itself >> on a software raid, the system times out waiting for (I think!) fsck on that >> filesystem. >> This causes the boot to drop into the emergency shell. >> If I just type "^D" and allow the boot to continue, the filesystem is >> mounted but >> never fsck-ed. >> >> systemd journal of boot is attached. >> /etc/fstab is attached. >> /etc/modules is attached >> /etc/modprobe.d/mdadm.conf is attached >> /etc/mdadm/mdadm.conf is attached >> >> The filesystem in question is "/backup" which is on logical-volume >> "vg1-backup", which is on RAID device "/dev/md127" > > When you are dropped into emergency shell, can you get the following data > ls -al /dev/disk/by-label > udevadm info -e > mdadm --info /dev/md127 > lvscan > pvscan > vgscan See attached. typescript Description: Binary data ___ 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#782793: systemd: ext4 filesystem on lvm on raid causes boot to enter emergency shell
Am 18.04.2015 um 00:36 schrieb Rick Thomas: > > On Apr 17, 2015, at 3:17 PM, Michael Biebl wrote: > >> Am 17.04.2015 um 23:43 schrieb Rick Thomas: >>> Package: systemd >>> Version: 215-16 >>> Severity: important >>> >>> When /etc/fstab has an ext4 filesystem on a logical volume which is itself >>> on a software raid, the system times out waiting for (I think!) fsck on >>> that filesystem. >>> This causes the boot to drop into the emergency shell. >>> If I just type "^D" and allow the boot to continue, the filesystem is >>> mounted but >>> never fsck-ed. >>> >>> systemd journal of boot is attached. >>> /etc/fstab is attached. >>> /etc/modules is attached >>> /etc/modprobe.d/mdadm.conf is attached >>> /etc/mdadm/mdadm.conf is attached >>> >>> The filesystem in question is "/backup" which is on logical-volume >>> "vg1-backup", which is on RAID device "/dev/md127" >> >> When you are dropped into emergency shell, can you get the following data >> ls -al /dev/disk/by-label >> udevadm info -e >> mdadm --info /dev/md127 >> lvscan >> pvscan >> vgscan > Thanks for the data. Looks like an lvm issue to me: root@cube:~# lvscan inactive '/dev/vg1/backup' [87.29 GiB] inherit and as a result, /dev/disk/by-label/BACKUP is missing. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#782793: systemd: ext4 filesystem on lvm on raid causes boot to enter emergency shell
On Apr 17, 2015, at 3:44 PM, Michael Biebl wrote: > > Thanks for the data. > Looks like an lvm issue to me: > > root@cube:~# lvscan > inactive '/dev/vg1/backup' [87.29 GiB] inherit > > and as a result, /dev/disk/by-label/BACKUP is missing. Yes, that’s true, of course. But the question is, what is keeping lvm from activating the volume? It works fine for a logical volume on a single physical disk. And /proc/mdstat shows that the RAID device, /dev/md127, _is_ active. Or, at least it is when we get to emergency mode… I don’t know if it’s active when the fsck times out, of course… If you know how to figure that out from the systemd journal I attached to the original bug report, or any other way that I can try, I’d appreciate any assistance you can give! Thanks! Rick PS: In the meantime, can you do whatever magic is involved with passing this on the the LVM2 maintainers? 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
