Bug#877234: schroot: FTBFS with current debhelper: dh_install reports missing files
On 29/09/17 20:01, Andreas Beckmann wrote: Source: schroot Version: 1.7.2-3 Severity: serious Justification: fails to build from source (but built successfully in the past) This could be removed from experimental; it's not been updated in years and is a development release for testing. Regards, Roger
Bug#786566: this is affecting us
On 05/01/17 10:08, Roger Leigh wrote: On 05/01/17 09:23, Brian May wrote: Peter Palfrader writes: It's a serious bug that makes it break in many cases, requiring the sysadmin to clean up and/or reboot the system. Whether or not it's RC in the end is the decision of the release team, but this severity was set after discussing this on #debian-release. Is anything being done to fix this? What is the hold up? Apparently there is a patch for this RC bug and the other RC bug #817236. I'm not personally working on any fix in schroot, since it's not an schroot bug. It is kind of looking like stretch will get released without schroot support, or any packages that depend on it. Maybe time to forgot schroot and look for alternatives??? schroot is not responsible for setting up device nodes in a debootstrapped chroot. We expect them to be set up correctly. This isn't a Debian-specific constraint; we expect all chroots of any sort to be in a sane and directly usable state. schroot's requirements are not any different here from that of the basic chroot(8). Is chroot(8) equally broken here? The mounts and other features schroot offers on top of that are entirely optional, and implementation wise is nothing more than a wrapper around chroot(2) to perform exactly the same job as chroot(8) with some sudo-like PAM authentication and authorisation. While we could add additional mounts to the schroot fstab templates, it's important to understand that this is optional functionality, and has always been optional. It's not a mechanism for working around external breakage. Looking for alternatives to schroot is entirely your choice, but breaking basic system-level functionality which has been working for over two decades, and used for over 11 years by schroot, is I think something which needs careful consideration. I'm prepared to do some work to ensure that schroot interoperates with contemporary systems, but working around breakage like this is perhaps a step too far. Very sorry, replying to the wrong ticket here. Got confused with #817236. For this specific issue with mount options, I've been following along but so far the discussion and proposed patches in this bug haven't reached a definitive conclusion with a consensus, so I'm waiting on an informed decision before I apply anything upstream. I don't myself have the expertise to judge what the right action is here, so I'll defer to others for what's best. Speaking frankly, I'm appalled that such gratuitous breakage through incompatible changes to the functioning of the base system was and is considered at all acceptable. There's over 20 years of software development and admin experience on Debian, 11 for schroot, and there's a lot of code, and a lot of sysadmin-related scripting and expectations which makes assumptions about how mount(2) and mount(8) will behave. schroot is just one tool amongst many which expects them to work in the traditional, documented and most of all portable way. Changing fundamental default system-wide behaviour on a whim is not what I would expect for a mature and established system. I'd expect rather more considered and measured incremental change, which is something I've tried to pay proper attention to in my own work. As an opt-in option for certain mounts, it would be fine, but enforcing it system wide is somewhat cavalier and inconsiderate of the multi-decade established semantics which we expect. This significant change in attitude is one of the factors behind my no longer actively using or developing on Debian. Like it or not, it's become a mature system, and that brings with it some responsibility toward backward compatibility even when we might want to rip it all out and start over with something new and exciting. Too late to fix that now, so I'll consider applying upstream whatever makes most sense. However, I must stress that schroot must remain portable to non-systemd-Linux, GNU/Hurd, GNU/kFreeBSD and FreeBSD, and any patches must not break this support. Roger
Bug#786566: this is affecting us
On 05/01/17 09:23, Brian May wrote: Peter Palfrader writes: It's a serious bug that makes it break in many cases, requiring the sysadmin to clean up and/or reboot the system. Whether or not it's RC in the end is the decision of the release team, but this severity was set after discussing this on #debian-release. Is anything being done to fix this? What is the hold up? Apparently there is a patch for this RC bug and the other RC bug #817236. I'm not personally working on any fix in schroot, since it's not an schroot bug. It is kind of looking like stretch will get released without schroot support, or any packages that depend on it. Maybe time to forgot schroot and look for alternatives??? schroot is not responsible for setting up device nodes in a debootstrapped chroot. We expect them to be set up correctly. This isn't a Debian-specific constraint; we expect all chroots of any sort to be in a sane and directly usable state. schroot's requirements are not any different here from that of the basic chroot(8). Is chroot(8) equally broken here? The mounts and other features schroot offers on top of that are entirely optional, and implementation wise is nothing more than a wrapper around chroot(2) to perform exactly the same job as chroot(8) with some sudo-like PAM authentication and authorisation. While we could add additional mounts to the schroot fstab templates, it's important to understand that this is optional functionality, and has always been optional. It's not a mechanism for working around external breakage. Looking for alternatives to schroot is entirely your choice, but breaking basic system-level functionality which has been working for over two decades, and used for over 11 years by schroot, is I think something which needs careful consideration. I'm prepared to do some work to ensure that schroot interoperates with contemporary systems, but working around breakage like this is perhaps a step too far. Regards, Roger
Bug#789155: [buildd-tools-devel] Bug#789155: schroot: FTBFS: g++-4.8: error: unrecognized command line option '-fstack-protector-strong'
On 26/07/2015 20:28, Jakub Wilk wrote: * Roger Leigh , 2015-07-26, 17:22: I assume that some other package is providing the -fstack-protector-strong argument schroot (1.7.2-1) experimental; urgency=medium [...] * debian/rules: - Build using g++-4.8, needed for C++11 compatibility until the default compiler for all architectures supports C++11. Now that GCC 4.9 is the default compiler, I guess this change should be reverted. Will be fixed in: https://github.com/codelibre-net/schroot/pull/9/files Regards, Roger -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#789155: [buildd-tools-devel] Bug#789155: schroot: FTBFS: g++-4.8: error: unrecognized command line option '-fstack-protector-strong'
On 18/06/2015 11:30, Jakub Wilk wrote: Source: schroot Version: 1.7.2-2 Severity: serious Justification: fails to build from source schroot FTBFS: | cd debian/build/gtest/ ; \ | CXX="g++-4.8 -std=c++11" cmake /usr/src/gtest ; \ | /usr/bin/make VERBOSE=1 | -- The CXX compiler identification is unknown | -- The C compiler identification is GNU 4.9.2 | -- Check for working CXX compiler: /usr/bin/g++-4.8 | -- Check for working CXX compiler: /usr/bin/g++-4.8 -- broken [...] | g++-4.8: error: unrecognized command line option '-fstack-protector-strong' Was this a historical issue on the buildds e.g. still using GCC 4.8 with a newer hardening-wrapper? I can't reproduce in current unstable. I assume that some other package is providing the -fstack-protector-strong argument and that GCC 4.8 doesn't support it. But I'm not sure that it's an schroot problem unless there is some versioned build dependency that needs correcting? Or is it a dependency problem is some part of build-essential? Regards, Roger -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778112: [buildd-tools-devel] Bug#778112: schroot: ftbfs with GCC-5
tags 778112 + patch thanks On 15/07/2015 14:50, Cyril Brulebois wrote: Matthias Klose (2015-02-12): The following tests FAILED: Errors while running CTest 2 - sbuild-chroot-chroot (Failed) 6 - sbuild-run-parts (Failed) make[2]: *** [test] Error 8 Makefile:117: recipe for target 'test' failed make[2]: Leaving directory '/«PKGBUILDDIR»/debian/build' make[1]: *** [install-arch] Error 2 debian/rules:83: recipe for target 'install-arch' failed make[1]: Leaving directory '/«PKGBUILDDIR»' make: *** [binary-arch] Error 2 debian/rules:39: recipe for target 'binary-arch' failed dpkg-buildpackage: error: fakeroot debian/rules binary-arch gave error exit status 2 FWIW this isn't specific to gcc-5, the same happens with 4.9 in a sid development chroot. A patch to work around the issue has been merged here: https://github.com/codelibre-net/schroot/pull/4 (mainline at https://github.com/codelibre-net/schroot/pull/2) The primary change is to update the cmake regex tests to identify a broken std::regex and fall back to boost::regex. I also updated the unit tests for good measure in case anything passes the cmake tests but is still broken. There's also a test tweak to fix an additional issue with GCC5 in converting a stream to bool. Feel free to pick up the above two commits in the first pull request to patch schroot in unstable. Regards, Roger -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778112: [buildd-tools-devel] Bug#778112: Bug#778112: Bug#778112: schroot: ftbfs with GCC-5
On 26/07/2015 08:50, Matthias Klose wrote: On 07/26/2015 12:09 AM, Roger Leigh wrote: On 25/07/2015 22:07, Roger Leigh wrote: On 25/07/2015 21:45, Roger Leigh wrote: OK, some further investigation has shown what the exact error is. It looks like a GCC bug. Please see the attached source file testcase. This regex is failing: std::regex("^[a-z0-9][a-z0-9-]*$", std::regex::extended); however this one works: std::regex("^[a-z0-9][-a-z0-9]*$", std::regex::extended); In the same vein, the attached sample using basic rather than extended expressions fails in the opposite way. In this case both compile but the latter expression fails to match correctly. Since the expression should be valid and behave the same in both cases, it looks like there are two bugs here, the first being unable to compile a valid extended regex, the second here being unable to match (which is likely also a compile failure, but not a fatal one). Note this latter issue is seen with GCC 4.9 but appears to work with GCC 5. now forwarded as https://gcc.gnu.org/PR67015 however I can't see different behaviour with 4.9 and 5 (making sure to use the corresponding library using -static-libstdc++). Also I see regex2.cc always succeeding. Note I used GCC 4.9.2 in jessie. This fails every time with or without -static-libstdc++. GCC 4.9.3 in sid does not exhibit this behaviour, so it was likely just fixed with the 4.9.3 release. Regards, Roger -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778112: [buildd-tools-devel] Bug#778112: Bug#778112: Bug#778112: schroot: ftbfs with GCC-5
On 25/07/2015 22:07, Roger Leigh wrote: On 25/07/2015 21:45, Roger Leigh wrote: OK, some further investigation has shown what the exact error is. It looks like a GCC bug. Please see the attached source file testcase. This regex is failing: std::regex("^[a-z0-9][a-z0-9-]*$", std::regex::extended); however this one works: std::regex("^[a-z0-9][-a-z0-9]*$", std::regex::extended); In the same vein, the attached sample using basic rather than extended expressions fails in the opposite way. In this case both compile but the latter expression fails to match correctly. Since the expression should be valid and behave the same in both cases, it looks like there are two bugs here, the first being unable to compile a valid extended regex, the second here being unable to match (which is likely also a compile failure, but not a fatal one). Note this latter issue is seen with GCC 4.9 but appears to work with GCC 5. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778112: [buildd-tools-devel] Bug#778112: Bug#778112: Bug#778112: schroot: ftbfs with GCC-5
On 25/07/2015 21:45, Roger Leigh wrote: OK, some further investigation has shown what the exact error is. It looks like a GCC bug. Please see the attached source file testcase. This regex is failing: std::regex("^[a-z0-9][a-z0-9-]*$", std::regex::extended); however this one works: std::regex("^[a-z0-9][-a-z0-9]*$", std::regex::extended); In the same vein, the attached sample using basic rather than extended expressions fails in the opposite way. In this case both compile but the latter expression fails to match correctly. Since the expression should be valid and behave the same in both cases, it looks like there are two bugs here, the first being unable to compile a valid extended regex, the second here being unable to match (which is likely also a compile failure, but not a fatal one). Regards, Roger #include #include #include #include int main() { try { // These three are OK: static std::regex lanana_namespace("^[a-z0-9]+$"); static std::regex lsb_namespace("^_?([a-z0-9_.]+-)+[a-z0-9]+$"); static std::regex debian_dpkg_conffile_cruft("dpkg-(old|dist|new|tmp)$"); } catch(const std::regex_error& e) { std::cout <<"E0: " << e.what() << std::endl; } try { // This fails with regex_error: static std::regex debian_cron_namespace("^[a-z0-9][a-z0-9-]*$"); assert(std::regex_match("test", debian_cron_namespace)); assert(!std::regex_match("-a", debian_cron_namespace)); assert(std::regex_match("a-", debian_cron_namespace)); } catch(const std::regex_error& e) { std::cout <<"E1: " << e.what() << std::endl; } try { // This modified version works by moving the hyphen to the start of // the square bracket, even though the meaning is the same: static std::regex debian_cron_namespace_ok("^[a-z0-9][-a-z0-9]*$"); assert(std::regex_match("test", debian_cron_namespace_ok)); assert(!std::regex_match("-a", debian_cron_namespace_ok)); assert(std::regex_match("a-", debian_cron_namespace_ok)); } catch(const std::regex_error& e) { std::cout <<"E2: " << e.what() << std::endl; } }
Bug#778112: [buildd-tools-devel] Bug#778112: Bug#778112: schroot: ftbfs with GCC-5
On 15/07/2015 15:30, Matthias Klose wrote: On 07/15/2015 05:21 PM, rle...@codelibre.net wrote: Matthias Klose (2015-02-12): The following tests FAILED: Errors while running CTest 2 - sbuild-chroot-chroot (Failed) 6 - sbuild-run-parts (Failed) make[2]: *** [test] Error 8 Makefile:117: recipe for target 'test' failed make[2]: Leaving directory '/«PKGBUILDDIR»/debian/build' make[1]: *** [install-arch] Error 2 debian/rules:83: recipe for target 'install-arch' failed make[1]: Leaving directory '/«PKGBUILDDIR»' make: *** [binary-arch] Error 2 debian/rules:39: recipe for target 'binary-arch' failed dpkg-buildpackage: error: fakeroot debian/rules binary-arch gave error exit status 2 FWIW this isn't specific to gcc-5, the same happens with 4.9 in a sid development chroot. I have tried reproducing this in an unstable VM, and I can certainly do so. It's throwing instantiating a static regex instance. However, I can't reproduce as a minimal testcase. Constructing the same regex, either as an auto or static variable in a function scope or as a global works perfectly. std::regex was broken in earlier GCC releases, so we used boost::regex, could you recheck with GCC 5? I won't say that it is completely fixed, but there were a lot of fixes and updates. but I thought it was functional in these compiler versions. The fact that the minimal testcase works hints that it's a problem in schroot, but I'm unable to see why the code is problematic. IIRC it's throwing here: https://github.com/codelibre-net/schroot/blob/76a85f0fb34d39f796185d296fadde81b79a3948/lib/schroot/util.cc#L157 or here: https://github.com/codelibre-net/schroot/blob/76a85f0fb34d39f796185d296fadde81b79a3948/lib/schroot/util.cc#L157 We are wrapping the regex implementation here: https://github.com/codelibre-net/schroot/blob/76a85f0fb34d39f796185d296fadde81b79a3948/lib/schroot/regex.h (to support boost/tr1/std regex) but the failure is in the constructor of the wrapped type, and I couldn't reproduce with the wrapper or a std::regex. fwiw, I also tried with boost1.57 from experimental, and got the same test failures. OK, some further investigation has shown what the exact error is. It looks like a GCC bug. Please see the attached source file testcase. This regex is failing: std::regex("^[a-z0-9][a-z0-9-]*$", std::regex::extended); however this one works: std::regex("^[a-z0-9][-a-z0-9]*$", std::regex::extended); GCC 4.9 (Debian 8): fails GCC 5 (Debian sid): fails clang++ 3.4 (FreeBSD 10.1-RELEASE): works clang++ 3.4 (FreeBSD ports): works clang++ 3.5 (FreeBSD ports): works clang++ 3.6 (FreeBSD ports): works clang++ 3.6 (MacOS): works Note it fails when std::regex::extended is used, but works correctly without. So looks like it can be patched with the above change in the interim, but this bug should likely be cloned and assigned to gcc? Regards, Roger #include #include #include #include int main() { try { // These three are OK: static std::regex lanana_namespace("^[a-z0-9]+$", std::regex::extended); static std::regex lsb_namespace("^_?([a-z0-9_.]+-, std::regex::extended)+[a-z0-9]+$"); static std::regex debian_dpkg_conffile_cruft("dpkg-(old|dist|new|tmp, std::regex::extended)$"); } catch(const std::regex_error& e) { std::cout <<"E0: " << e.what() << std::endl; } try { // This fails with regex_error: static std::regex debian_cron_namespace("^[a-z0-9][a-z0-9-]*$", std::regex::extended); assert(std::regex_match("test", debian_cron_namespace)); assert(!std::regex_match("-a", debian_cron_namespace)); assert(std::regex_match("a-", debian_cron_namespace)); } catch(const std::regex_error& e) { std::cout <<"E1: " << e.what() << std::endl; } try { // This modified version works by moving the hyphen to the start of // the square bracket, even though the meaning is the same: static std::regex debian_cron_namespace_ok("^[a-z0-9][-a-z0-9]*$", std::regex::extended); assert(std::regex_match("test", debian_cron_namespace_ok)); assert(!std::regex_match("-a", debian_cron_namespace_ok)); assert(std::regex_match("a-", debian_cron_namespace_ok)); } catch(const std::regex_error& e) { std::cout <<"E2: " << e.what() << std::endl; } }
Bug#763157: initramfs-tools: Mounting /usr by initramfs-tools breaks checkfs.sh
On Sun, Sep 28, 2014 at 08:20:52PM +0100, Ben Hutchings wrote: > On Sun, 2014-09-28 at 19:44 +0100, Roger Leigh wrote: > > On Sun, Sep 28, 2014 at 06:49:49PM +0100, Ben Hutchings wrote: > > > Roger, please can you look at this? > > > > > > Ben. > > > > > > On Sun, 2014-09-28 at 11:41 +0200, Robert Luberda wrote: > > > > Package: initramfs-tools > > > > Version: 0.117 > > > > Severity: critical > > > > Justification: breaks the whole system > > > > > > > > Hi > > > > > > > > After /usr is being mounted from initramfs, system is no longer > > > > bootable, because checkfs.sh script fails with: > > > > > > > > [] Checking file systems...fsck from util-linux 2.20.1 > > > > /home2: clean, 166826/610800 files, 2350575/2441880 blocks > > > > /home: clean, 120720/1831424 files, 3611320/3662820 blocks > > > > /dev/sda5 is mounted. > > > > e2fsck: Cannot continue, aborting. > > > > > > > > > > > > fsck exited with status code 8 > > > > [] File system check failed. A log is being saved in > > > > /var/log/fsck/checkfs if that location is writable. Please repair the > > > > f[FAILystem manually. ... failed! > > > > > > > > The contents of /var/log/fsck/checkfs is: > > > > > > > > Log of fsck -C -R -A -a > > > > Has there been an update to util-linux to make the above -R option > > skip checking /usr in addition to the rootfs? That was a > > prerequisite for mounting /usr in the initramfs. > > Argh. No. And that doesn't fix the problem because we have to > support partial upgrades. > > Where is the bug report on util-linux? Ah, found it as: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697002 For some reason it's been reassigned to initscripts. Not sure I agree with the rationale of not patching util-linux; this looks like it breaks the non-initramfs boot case since it won't fsck a mounted rootfs with -M? It was never the intention of this work to make an initramfs mandatory. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#763157: initramfs-tools: Mounting /usr by initramfs-tools breaks checkfs.sh
On Sun, Sep 28, 2014 at 06:49:49PM +0100, Ben Hutchings wrote: > Roger, please can you look at this? > > Ben. > > On Sun, 2014-09-28 at 11:41 +0200, Robert Luberda wrote: > > Package: initramfs-tools > > Version: 0.117 > > Severity: critical > > Justification: breaks the whole system > > > > Hi > > > > After /usr is being mounted from initramfs, system is no longer > > bootable, because checkfs.sh script fails with: > > > > [] Checking file systems...fsck from util-linux 2.20.1 > > /home2: clean, 166826/610800 files, 2350575/2441880 blocks > > /home: clean, 120720/1831424 files, 3611320/3662820 blocks > > /dev/sda5 is mounted. > > e2fsck: Cannot continue, aborting. > > > > > > fsck exited with status code 8 > > [] File system check failed. A log is being saved in > > /var/log/fsck/checkfs if that location is writable. Please repair the > > f[FAILystem manually. ... failed! > > > > The contents of /var/log/fsck/checkfs is: > > > > Log of fsck -C -R -A -a Has there been an update to util-linux to make the above -R option skip checking /usr in addition to the rootfs? That was a prerequisite for mounting /usr in the initramfs. Looking at the mount options, it occurs to me that maybe we should use -M in place of -R when we know we have run fsck in the initramfs. Then it will skip /usr as a matter of course, but it would also skip fsck of the rootfs so won't be appropriate when not using an initramfs. You could if you wanted try using -M in checkfs as a workaround if the above is the case. Or maybe check util-linux is up-to-date in case it just needs upgrading. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#757335: [buildd-tools-devel] Bug#757335: Bug#757335: postgresql-debversion: No package for postgresql 9.4
On Fri, Aug 08, 2014 at 02:50:01PM +0100, Roger Leigh wrote: > On Thu, Aug 07, 2014 at 10:13:54PM +0200, Andreas Tille wrote: > > Hi, > > > > sorry, but the given patch applies to what? It does not help > > when trying to apply to `apt-get source postgresql-debversion` > > and I also tried > > > > gbp-clone git://git.debian.org/git/buildd-tools/postgresql-debversion > > > > just to realise that this is outdated for years. :-( > > > > Is there any current Git repository where impatient people could just > > git-buildpackage?? > > Hmm, it looks like this might have been reverted back when Alioth got > restored from backup last year. I've got a local copy at home; I'll push > the current state later today. All the buildd-tools repos are missing > from the main gitweb page as well. Actually it was fine, you were just looking on the wrong branch. master contains the upstream main releases; the debian revisions are on the debian branch. Since there were no code changes required to support new PostgreSQL versions for some time, there hasn't been any need to make any new upstream release. We could require extensions and drop 9.0 support, but there's no pressing need to do so. I've uploaded a 1.0.7-4 which will support 9.4 (or in fact any version since this is now generalised). Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#757335: [buildd-tools-devel] Bug#757335: postgresql-debversion: No package for postgresql 9.4
On Thu, Aug 07, 2014 at 10:13:54PM +0200, Andreas Tille wrote: > Hi, > > sorry, but the given patch applies to what? It does not help > when trying to apply to `apt-get source postgresql-debversion` > and I also tried > > gbp-clone git://git.debian.org/git/buildd-tools/postgresql-debversion > > just to realise that this is outdated for years. :-( > > Is there any current Git repository where impatient people could just > git-buildpackage?? Hmm, it looks like this might have been reverted back when Alioth got restored from backup last year. I've got a local copy at home; I'll push the current state later today. All the buildd-tools repos are missing from the main gitweb page as well. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739053: rpcbind LSB initscript runlevels are incorrect
On Mon, May 05, 2014 at 01:15:48PM -0700, Steve Langasek wrote: > Control: reopen -1 > > Roger, > > > Please could you apply the following patch. We are planning to upgrade > > the version of insserv, and testing shows that the new version breaks > > on the dependencies declared by rpcbind (which doesn't match the > > dependent nfs-common). This change adjusts the start runlevels to > > match nfs-common. > > What do you mean, it doesn't match? The nfs-common init script has: > > # Default-Start: S > # Default-Stop: 0 1 6 I'm not sure myself. I can't recall the details offhand I'm afraid; I've spent the intervening months dealing with RSI and haven't done any work on this since then. > Anibal has reverted my deliberate change to rpcbind's init script, in > response to this bug report which makes no sense. Why did you think it was > appropriate to mark rpcbind for start in both runlevel S and runlevels 2 3 4 > 5? I was asked to test insserv from experimental, sometime before opening this bug. I found that the rpcbind LSB headers caused insserv to fail, and this fixed things. IIRC I discussed this with the insserv maintainer but I could be wrong. The reasons for this I'm not sure. It may be there needed a corresponding change to nfs-common, but I don't think that was the case. During this period I couldn't even hold the pages of a book open, let alone type properly, so it's possible I've missed something. Sorry I can't help more here. I really can't recall the specifics, and I'm not able to do more investigation at present due to my hands. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743976: php5-json: Missing package dependencies prevent package removal
Package: php5-json Version: 1.3.4-1 Severity: serious Justification: Broken deps prevent deinstall % sudo apt-get remove php5-json Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: php5-common php5-json 0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded. After this operation, 1,046 kB disk space will be freed. Do you want to continue? [Y/n] (Reading database ... 514336 files and directories currently installed.) Removing php5-common (5.5.11+dfsg-2) ... Removing php5-json (1.3.4-1) ... /var/lib/dpkg/info/php5-json.prerm: 13: /var/lib/dpkg/info/php5-json.prerm: php5dismod: not found dpkg: error processing package php5-json (--remove): subprocess installed pre-removal script returned error exit status 127 /var/lib/dpkg/info/php5-json.postinst: 11: /var/lib/dpkg/info/php5-json.postinst: php5enmod: not found dpkg: error while cleaning up: subprocess installed post-installation script returned error exit status 127 Errors were encountered while processing: php5-json E: Sub-process /usr/bin/dpkg returned an error code (1) php5-common has a dependency upon php5-json php5-json does not have a dependency upon php5-common This results in php5-common being removed first, and php5-json's prerm failing due to php5dismod not being found: it's already been removed by this point. Note that when dpkg tries to abort the transaction, the rerun of the postinst *also* fails due to php5enmod also being removed, so this isn't strictly a removal bug, it's also a bug for installation as well. I'm not familiar with the php5 packaging, but it's clear that the dependencies are incorrect here, and this leads to an inability to deinstall, hence the serious severity. Suggestions, in decending order of usefulness: - can the dependencies be inverted? That is, make php5-json depend on php5-common? - can the prerm be made to clean up properly in the absence of php5dismod? likewise the prerm and php4enmod - if the dependencies are mutual, should the packages be merged? Regards, Roger -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (550, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages php5-json depends on: ii libc62.18-4 ii libjson-c2 0.11-3 pn phpapi-20121212 ii ucf 3.0027+nmu1 php5-json recommends no packages. php5-json suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739604: sysvinit: The new skeleton does not work on kFreeBSD
On Thu, Feb 20, 2014 at 01:00:45PM +0100, Petter Reinholdtsen wrote: > [Gergely Nagy] > > The change introduced in sysvinit 2.88dsf-50, which turns > > /etc/init.d/skeleton into a script that has /lib/init/init-d-script > > as interpreter fails on kFreeBSD, because on that platform, > > interpreters cannot be other scripts. > > Oh. I tested on Linux and Hurd, and did not imagine that kFreeBSD was > that different from these two. :) > > > If you want to do this kind of thing, you will either need a binary > > wrapper at least on kFreeBSD, or you'll need to use sourcing. > > Right. Back to the drawing board. :) An alternative solution here would be to have a tiny executable which runs the shell, i.e. similar to openrc's runscript. It might be worth looking at the runscript sources. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739053: rpcbind LSB initscript runlevels are incorrect
Package: rpcbind Version: 0.2.1-2 Severity: serious Tags: patch Justification: Breaks upgrades Please could you apply the following patch. We are planning to upgrade the version of insserv, and testing shows that the new version breaks on the dependencies declared by rpcbind (which doesn't match the dependent nfs-common). This change adjusts the start runlevels to match nfs-common. Marking as serious because this will break upgrades if left unfixed. Thanks, Roger --- /etc/init.d/rpcbind.old 2014-02-10 18:55:20.645945248 + +++ /etc/init.d/rpcbind 2014-02-15 11:23:32.000400663 + @@ -6,7 +6,7 @@ # Provides: rpcbind # Required-Start:$network $local_fs # Required-Stop: $network $local_fs -# Default-Start: S +# Default-Start: 2 3 4 5 S # Default-Stop: 0 1 6 # Short-Description: RPC portmapper replacement # Description: rpcbind is a server that converts RPC (Remote -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (550, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.12-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages rpcbind depends on: ih initscripts 2.88dsf-51 ii insserv 1.16.0-1 ii libc62.17-97 ii libtirpc10.2.2-5 ii libwrap0 7.6.q-25 ii lsb-base 4.1+Debian12 rpcbind recommends no packages. rpcbind suggests no packages. -- Configuration Files: /etc/init.d/rpcbind changed [not included] -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#694986: flash-kernel: postinst modifies /etc/default/rcS
On Tue, Feb 04, 2014 at 11:43:05AM +0100, Petter Reinholdtsen wrote: > > I read this bug report, but fail to understand what exactly it is > expected for the sysvinit maintainers to do here. Anyone care to > explain what more can be done in this case? Roger, you cloned it > instead of reassigning it. What did you have in mind? Sorry, I can't remember. Possibly it related to changing the FSCKFIX default and/or defaulting FSCKFIX if unconfigured depending upon if we could detect an interactive console. I understand the latter isn't always possible on arm systems-- there may be a console but it's not necessarily interactive. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#722012: [buildd-tools-devel] Bug#722012: another Perl problem in sbuild-createchroot
severity 722012 serious forcemerge 722012 724858 thanks On Sun, Sep 08, 2013 at 02:02:34PM +0200, Václav Ovsík wrote: > Hi, > I'm not certain to start another bug report... > > bobek:~# sbuild-createchroot > --make-sbuild-tarball=/var/lib/sbuild/sid-amd64.tar.gz sid `mktemp -d` > http://br0.localdomain:/debian > ... > Calculating upgrade... Done > 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. > 'tempfile' can't be called as a method at /usr/sbin/sbuild-createchroot line > 395. Thanks for this patch; merging with #724858 which also contained a similar patch. This will be in the next upload. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Bug#724858: [buildd-tools-devel] Bug#724858: PATCH for sbuild-createschroot
tags 724858 + pending thanks On Sat, Sep 28, 2013 at 04:12:24PM -0400, Alex Chernyakhovsky wrote: > Please find attached a patch for sbuild-createschroot which allows it > to work on jessie/sid. Many thanks for the patch. I've applied it to git, and it's queued for the next upload. Thanks again, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#717473: BUG: Null pointer deref in amd64_edac_mod/amd64_probe_one_instance during boot
On Tue, Jul 23, 2013 at 06:05:57PM +0200, Borislav Petkov wrote: > On Mon, Jul 22, 2013 at 08:19:26PM +0100, Roger Leigh wrote: > > Ben's patch does allow me to boot the system with the memory in this > > configuration on a 3.10 kernel. > > Ok, I actually think we can fix it the way below. It should be > equivalent to Ben's patch in current functionality with the difference > that it is a bit simpler and keeps the special handling for K8 which I > want to have there as a future info. > > In addition, it still provides for the data structures to be initialized > so some day, when memory hotplug is supported, it should work out of the > box when all of a sudden a second channel appears. > > I think it should apply cleanly to 3.8 or 3.9 too as we haven't had a > whole lot of movement in that area :-) I've tested it against 3.10 and I can confirm that it works. I've booted the system with the DRAM on the same channel, and on separate channels, and it's working without problems in both cases. Many thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Bug#717473: Acknowledgement (BUG: Null pointer deref in amd64_edac_mod/amd64_probe_one_instance during boot)
If the bug is in amd64_edac_mod, there are only two possible commits which could cause the problem: 1eef12825 amd64_edac: Correct DIMM sizes 94c1acf2c amd64_edac: Add Family 16h support Which are the only commits between 3.8 and 3.9 (and none made since). Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#716923: [Pkg-sysvinit-devel] Bug#716923: sysv-rc 2.88dsf-42 breaks {, c}debootstrapping
On Sun, Jul 14, 2013 at 02:55:49PM -0700, Steve Langasek wrote: > On Sun, Jul 14, 2013 at 10:04:54PM +0100, Roger Leigh wrote: > > tags 716923 + patch > > thanks > > > On Sun, Jul 14, 2013 at 10:41:18PM +0200, Stefan Lippers-Hollmann wrote: > > > Trying to bootstrap a system using cdebootstrap (or debootstrap) fails > > > since sysv-rc 2.88dsf-42 entered the archive (it did succeed just > > > minutes before with the previous mirror sync, using sysv-rc 2.88dsf-41) > > > with this error message: > > > > # cdebootstrap -v --arch=amd64 --flavour=minimal sid /mnt/ > > > http://ftp.de.debian.org/debian/ > > > […] > > > O: dpkg: warning: ignoring pre-dependency problem! > > > O: Unpacking util-linux (from .../util-linux_2.20.1-5.5_amd64.deb) ... > > > P: Unpacking package util-linux > > > O: Can't locate File/Path.pm in @INC (@INC contains: /etc/perl > > > /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 > > > /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 > > > /usr/local/lib/site_perl .) at /usr/sbin/update-rc.d line 8. > > > O: BEGIN failed--compilation aborted at /usr/sbin/update-rc.d line 8. > > > O: dpkg: error processing > > > /var/cache/bootstrap/util-linux_2.20.1-5.5_amd64.deb (--unpack): > > > O: subprocess new pre-installation script returned error exit status 2 > > > O: Selecting previously unselected package e2fsprogs. > > > Does the following patch help? It looks like it might have always been > > missing the perl dependency. > > Absolutely not. sysv-rc is transitively essential as a Pre-Depends of > sysvinit; making it depend on perl for core functionality will introduce > dependency loops, because perl is deliberately NOT part of the transitively > essential set. update-rc.d should only require interfaces provided by > perl-base. > > The claim in the comment that File::Path is 'in core since Perl 5.001' is > bogus. The only modules that are permitted are the ones in perl-*base*. > File::Path is in perl-*modules*. Why are people making changes unsupervised > to sysvinit without understanding how the Debian base system works? Michael, Please could you take a look at this? In your commit ae90465c you introduced the File::Path dependency to update-rc.d. It's only used for make_path, and it should be fairly simple to implement this in an alternative manner. If you don't need recursion (and it looks like this might be the case), then you can just use plain mkdir. But if you do, can still use plain mkdir for the recursion, e.g. my @dirs = (); my @path = split /\//, $path; map { push @dirs, $_; mkdir join('/', @dirs), 0777 } @path; as a starting point; you'd probably want to check if it already exists before creating and double check the perms you need. Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#716923: sysv-rc 2.88dsf-42 breaks {,c}debootstrapping
On Sun, Jul 14, 2013 at 11:35:58PM +0200, Stefan Lippers-Hollmann wrote: > Hi > > On Sunday 14 July 2013, Roger Leigh wrote: > […] > > Does the following patch help? It looks like it might have always been > > missing the perl dependency. > > I did try "cdebootstrap -v --arch=amd64 --flavour=minimal > --include=perl-modules sid /mnt/ http://ftp.de.debian.org/debian/";, > which had no effect. Unfortunately neither cdebootstrap nor debootstrap > allow using additional mirrors to supersede or override particular > packages from the bootstrapping phase, which makes it a little > difficult to test; even trying to sneak it into the downloaded packages > before their respective unpacking didn't help here. I've had this problem before as well, and had to IIRC make my own mirror for testing. Since the missing perl dependency is a bug anyway, I'll make the upload as in the patch and then it should be testable on the mirrors tomorrow. If not, please just reopen the bug and we can look at it further. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#716923: sysv-rc 2.88dsf-42 breaks {,c}debootstrapping
tags 716923 + patch thanks On Sun, Jul 14, 2013 at 10:41:18PM +0200, Stefan Lippers-Hollmann wrote: > Trying to bootstrap a system using cdebootstrap (or debootstrap) fails > since sysv-rc 2.88dsf-42 entered the archive (it did succeed just > minutes before with the previous mirror sync, using sysv-rc 2.88dsf-41) > with this error message: > > # cdebootstrap -v --arch=amd64 --flavour=minimal sid /mnt/ > http://ftp.de.debian.org/debian/ > […] > O: dpkg: warning: ignoring pre-dependency problem! > O: Unpacking util-linux (from .../util-linux_2.20.1-5.5_amd64.deb) ... > P: Unpacking package util-linux > O: Can't locate File/Path.pm in @INC (@INC contains: /etc/perl > /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 > /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 > /usr/local/lib/site_perl .) at /usr/sbin/update-rc.d line 8. > O: BEGIN failed--compilation aborted at /usr/sbin/update-rc.d line 8. > O: dpkg: error processing > /var/cache/bootstrap/util-linux_2.20.1-5.5_amd64.deb (--unpack): > O: subprocess new pre-installation script returned error exit status 2 > O: Selecting previously unselected package e2fsprogs. Does the following patch help? It looks like it might have always been missing the perl dependency. diff --git a/debian/changelog b/debian/changelog index d4a5972..07a7426 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +sysvinit (2.88dsf-43) UNRELEASED; urgency=low + + [ Roger Leigh ] + * sysv-rc: Add ${perl:Depends} to ensure correct dependency on perl. +Closes: #716923. + + -- Roger Leigh Sun, 14 Jul 2013 22:02:11 +0100 + sysvinit (2.88dsf-42) unstable; urgency=low [ Roger Leigh ] diff --git a/debian/control b/debian/control index 7dd998d..2834f6b 100644 --- a/debian/control +++ b/debian/control @@ -58,7 +58,7 @@ Conflicts: file-rc Replaces: file-rc Suggests: sysv-rc-conf, bum Depends: - ${misc:Depends}, + ${misc:Depends}, ${perl:Depends}, sysvinit-utils (>= 2.86.ds1-62), insserv (>> 1.12.0-10) Breaks: initscripts (<< 2.86.ds1-63) -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#701956: btrfs can't fsck /run/rootdev on boot
On Wed, Jul 03, 2013 at 11:27:07PM +1000, Ben Klein wrote: > Bug still occurs with > * btrfs-tools 0.19+20130315-2 > * sysv-rc 2.88dsf-41 > * sysvinit 2.88dsf-41 > * sysvinit-utils 2.88dsf-41 > * initscripts 2.88dsf-41 > > I notice this bug has been reduced in severity from "critical" to > "important" again. Sorry, but I have to agree that it IS a critical > bug, unless systemd has suddenly become the standard init system. Totally agreed; it's been set back to critical. I've been suffering from it also. > Even worse, systemd is behaving incorrectly in this case, as it is > SKIPPING fsck instead of finding the root device some other way and > running fsck on that (though this would still trigger bug #712078). So > ultimately, the issue is either: > * in mountpoint's syscall for getting the device node, or > * in checkroot.sh which needs some btrfs-specific method to find the > correct argument to pass to btrfsck/btrfs check (taking subvolumes > into account) > > I've attached an alternative patch for checkroot.sh that explicitly > checks for btrfs and, more importantly, triggers a warning when it is > detected. I didn't see an attachment. I'll be happy to look over it and apply it --it needs to be worked around in the short term irrespective of it being fixed down the line. Though I hope the btrfs tools are fixed since they are currently horribly broken. Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#708061: libc6: ABI breakage: loss of symbol __secure_getenv
Package: libc6 Version: 2.17-1 Severity: serious Justification: ABI breakage __secure_getenv is being used by util-linux in libblkid.a. Any program linked against libblkid.a will have a dependency upon this symbol. This includes e2fsprogs, which currently FTBFSes. There may be additional users; this is just the one I'm aware of. The new glibc has secure_getenv to replace __secure_getenv but the old symbol is not retained. I've NMUed util-linux to force it to be rebuilt. This should fix the immediate issues. But the wider question is how widespread was usage of this symbol, and do we need to rebuild everything or could the symbol be restored for backward compatibility? Regards, Roger -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (550, 'unstable'), (400, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc6 depends on: ii debconf [debconf-2.0] 1.5.50 ii libgcc11:4.8.0-6 libc6 recommends no packages. Versions of packages libc6 suggests: ii glibc-doc 2.17-1 ii locales2.17-1 ii locales-all [locales] 2.17-1 -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#701385: Block
On Sun, May 12, 2013 at 02:35:07PM -0400, Theodore Ts'o wrote: > On Sun, May 12, 2013 at 03:09:42PM +0100, Roger Leigh wrote: > > > > This is due to libblkid.a using a symbol removed in the new glibc. > > It needs either a straight rebuild and/or updating to the latest > > upstream. > > Any reason to keep this open? Once util-linux is recompiled, the > FTBFS will be resolved automatically. Or is eglibc buggy by not being > backwards compatible, such that binaries compiled against the old > glibc won't run if eglibc is installed, requiring a rebuild from > source of the entire universe, and meaning that any old binaries from > say, Steam, will all break? > > If so, I'd call this a huge, horrendous eglibc bug that should > disqualify it from being installed as the default C library until it > is fixed. Though Shalt Not Break Backwards Compatibility. I've uploaded an NMU of util-linux. This fixes the immediate issue. I'll also file a bug against eglibc. There's an additional issue with e2fsprogs: texi2html -split_chapter /tmp/bt/e2fsprogs-1.42.5/doc/libext2fs.texinfo ** menu entry without previous node: Introduction to the EXT2FS Library (l. 110) ** menu entry without previous node: EXT2FS Library Functions (l. 111) ** menu entry without previous node: Concept Index (l. 112) ** menu entry without previous node: Function Index (l. 113) ** node_up `Top' for `Introduction to the EXT2FS Library' not found ** node_prev `Top' for `Introduction to the EXT2FS Library' not found ** node_up `Top' for `Introduction to the EXT2FS Library' not found ** node_prev `Top' for `Introduction to the EXT2FS Library' not found ** node_up `Top' for `EXT2FS Library Functions' not found ** node_up `Top' for `Concept Index' not found ** node_up `Top' for `Function Index' not found ** `EXT2FS Library Functions' doesn't appear in menus ** `Concept Index' doesn't appear in menus ** `Function Index' doesn't appear in menus if test -d libext2fs ; then \ mv libext2fs/* . ; rmdir libext2fs ; \ fi make[1]: Leaving directory `/tmp/bt/e2fsprogs-1.42.5/debian/BUILD-STD/doc' ( cd /tmp/bt/e2fsprogs-1.42.5/debian/BUILD-STD/lib/et && /usr/bin/make V=1 com_err.info com_err_abt.html ) make[1]: Entering directory `/tmp/bt/e2fsprogs-1.42.5/debian/BUILD-STD/lib/et' makeinfo /tmp/bt/e2fsprogs-1.42.5/lib/et/com_err.texinfo -o com_err.info /tmp/bt/e2fsprogs-1.42.5/lib/et/com_err.texinfo:309: warning: missing name for @deftypefun /tmp/bt/e2fsprogs-1.42.5/lib/et/com_err.texinfo:324: warning: missing name for @deftypefun /tmp/bt/e2fsprogs-1.42.5/lib/et/com_err.texinfo:141: raising the section level of @section which is too low make[1]: *** [com_err.info] Error 1 This is presumably the result of some texinfo or some related package in unstable being updated. Note that it also affects the e2fsprogs in experimental. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#701385: Block
On Sun, May 12, 2013 at 02:35:07PM -0400, Theodore Ts'o wrote: > On Sun, May 12, 2013 at 03:09:42PM +0100, Roger Leigh wrote: > > > > This is due to libblkid.a using a symbol removed in the new glibc. > > It needs either a straight rebuild and/or updating to the latest > > upstream. > > Any reason to keep this open? Once util-linux is recompiled, the > FTBFS will be resolved automatically. Or is eglibc buggy by not being > backwards compatible, such that binaries compiled against the old > glibc won't run if eglibc is installed, requiring a rebuild from > source of the entire universe, and meaning that any old binaries from > say, Steam, will all break? > > If so, I'd call this a huge, horrendous eglibc bug that should > disqualify it from being installed as the default C library until it > is fixed. Though Shalt Not Break Backwards Compatibility. That's a good question. It may well be the case that whatever e2fsprogs linked statically against libblkid.a is broken until rebuilt due to the missing symbol. I think it's fair to say that util-linux was using what appears to be an internal symbol, so questionable whether it was using public API/ABI; what was __secure_getenv is now secure_getenv. If it's clear that this has caused breakage then __secure_getenv should probably be re-introduced. If the existing packages are still fully functional, and it's only an issue for rebuilding, then I think the bug should be safe to close. If I don't get a reply from the (inactive) maintainer of util-linux by tonight, I'll NMU it--it's just a rebuild with no source changes. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#701385: Block
block 701385 by 707996 thanks This is due to libblkid.a using a symbol removed in the new glibc. It needs either a straight rebuild and/or updating to the latest upstream. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#707996: util-linux: Needs rebuild against new glibc; causes other packages to FTBFS
Package: util-linux Version: 2.20.1-5.4 Severity: serious Justification: ftbfs >From the e2fsprogs build: make[1]: Entering directory `/«PKGBUILDDIR»/debian/BUILD-STD/e2fsck' gcc -Wl,-z,relro -static -o e2fsck.static crc32.o dict.o unix.o e2fsck.o super.o pass1.o pass1b.o pass2.o pass3.o pass4.o pass5.o journal.o b adblocks.o util.o dirinfo.o dx_dirinfo.o ehandler.o problem.o message.o quota.o recovery.o region.o revoke.o ea_refcount.o rehash.o profile.o prof_err.o logfile.o sigcatcher.o ../lib/libquota.a ../lib/libext2fs.a ../lib/libcom_err.a -lpthread -lblkid -luuid -luuid-luuid ../lib/libe2p.a logfile.o: In function `expand_percent_expression': /«PKGBUILDDIR»/e2fsck/logfile.c:133: warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries f rom the glibc version used for linking /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libblkid.a(env.o): In function `safe_getenv': (.text+0x1be): undefined reference to `__secure_getenv' collect2: error: ld returned 1 exit status make[1]: *** [e2fsck.static] Error 1 This is due to util-linux having libblkid.a built against the old glibc and this is no longer compatible with the new glibc. It just needs a rebuild. According to jcristau this needs a sourceful upload, i.e. not a binNMU, due to it being m-a: same. Regards, Roger -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (550, 'unstable'), (400, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages util-linux depends on: ii debconf [debconf-2.0] 1.5.50 ii dpkg 1.16.10 ii initscripts2.88dsf-41+jessie1 ii install-info 5.1.dfsg.1-3 ii libblkid1 2.20.1-5.4 ii libc6 2.17-1 ii libncurses55.9+20130504-1 ii libselinux12.1.13-1 ii libslang2 2.2.4-15 ii libtinfo5 5.9+20130504-1 ii libuuid1 2.20.1-5.4 ii lsb-base 4.1+Debian9 ii tzdata 2013b-2 ii zlib1g 1:1.2.8.dfsg-1 util-linux recommends no packages. Versions of packages util-linux suggests: ii dosfstools 3.0.16-2 ii kbd 1.15.5-1 ii util-linux-locales 2.20.1-5.4 -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#705649: Document solutions for re-enabling static mtab
tags 705649 + patch On Tue, Apr 16, 2013 at 10:37:37PM +0100, Roger Leigh wrote: > I've not made any changes as yet. Given that this will only affect > users who are using e.g. nbd as their rootfs, and not any regular > use of network nfsroot etc., the best option may be to simply > document how to re-enable a static mtab in the release notes, for > users who are dependent upon _netdev working. This would > essentially be to > - comment out the mtab_migrate conditional in /etc/init.d/checkroot.sh > - rm /etc/mtab > - cat /proc/mounts > /etc/mtab > and to reboot; the _netdev flag will then be stored in mtab correctly. Patch for the release notes attached. I've gone through the process locally and confirmed that this all works as documented. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 Index: en/issues.dbk === --- en/issues.dbk (revision 9741) +++ en/issues.dbk (working copy) @@ -186,6 +186,73 @@ + +/etc/mtab and _netdev + + +The file /etc/mtab, used to store the list of +currently mounted filesystems, has been changed to be a symbolic link +to /proc/mounts. For almost every case, this +change will result in a more robust system since the list can never +become inconsistent with reality. However, if you use the +_netdev option in /etc/fstab +to indicate that a filesystem is a network filesystem requiring +special handling, this will no longer be set in +/proc/mounts after rebooting. This will +not cause problems for standard network +filesystems such as NFS, which do not rely on the +_netdev option. Filesystems which are +unaffected by this issue are +ceph, cifs, +coda, gfs, +ncp, ncpfs, +nfs, nfs4, +ocfs2 and smbfs. For +filesystems which do rely on +_netdev for correct unmounting at shutdown, for +example when using an NBD, a static mtab will be +the only way to use _netdev in wheezy. If you have +such a setup, then after completing the upgrade to wheezy restore a +static /etc/mtab by doing the following: + + + + +Edit /etc/init.d/checkroot.sh, and comment out +these lines: + + +if [ "$rootmode" != "ro" ]; then +mtab_migrate +fi + + + + + + +If you have rebooted the system, and /etc/mtab is +now a symbolic link: + + +# rm /etc/mtab +# cp /proc/mounts /etc/mtab + + +Re-add the _netdev option by remounting the +affected filesystems: + + +# mount -o remount filesystem + + +/etc/mtab will be recreated fully next time you +reboot the system. + + + + + The pdksh to mksh transition Index: en/release-notes.dbk === --- en/release-notes.dbk (revision 9741) +++ en/release-notes.dbk (working copy) @@ -394,6 +394,10 @@ Mail Transport Agent +NBD +Network Block Device + + NFS Network File System
Bug#702935: 'mount -f' does not update /run/mount/utab
On Tue, Apr 16, 2013 at 07:43:32PM +0100, Adam D. Barratt wrote: > > The attached patch does the latter. It looks to see if _netdev is in > > use, and if so will refuse to migrate to a symlink. Though it will > > do nothing if a symlink already exists, so it won't revert back to > > a static file (this could be added easily; I'm just attaching what I've > > done so far prior to going away for the week in case you want to push > > a fix for this before I get back). > > What's the current status here? I've not made any changes as yet. Given that this will only affect users who are using e.g. nbd as their rootfs, and not any regular use of network nfsroot etc., the best option may be to simply document how to re-enable a static mtab in the release notes, for users who are dependent upon _netdev working. This would essentially be to - comment out the mtab_migrate conditional in /etc/init.d/checkroot.sh - rm /etc/mtab - cat /proc/mounts > /etc/mtab and to reboot; the _netdev flag will then be stored in mtab correctly. If we want to do anything more sophisticated, I'm happy to look at something like the proposed patch. This would be a relatively safe change to make. Likewise if there are any alternative proposals, I'll be happy to look at that. But if the release notes are an acceptable stopgap, I'll draft something. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#702935: 'mount -f' does not update /run/mount/utab
On Tue, Mar 12, 2013 at 09:19:06PM -0700, Steve Langasek wrote: > The use of a symlink for /etc/mtab in wheezy means that 'mount -f' no longer > works. As a consequence, extra mount options that libmount *should* record > in /run/mount/utab are not recorded for any filesystem that is mounted > before the rootfs is marked rw, including but not limited to _netdev. This > potentially leaves the system with no way to cleanly unmount some > network-dependent filesystems at shutdown time. [...] > This is a significant regression in handling of network-based block devices, > such as iscsi and nbd, compared with squeeze. I think it's important that > this be resolved before release. Hi Steve, I'm afraid I'm away and without internet access until next weekend. I've attached what I've done so far to work around this in initscripts. While bugs in mount/libmount/findmnt are certainly the cause of the lack of _netdev, I'm doubtful that these are addressable in time for wheezy. And we would have to adapt the initscripts to use mount or findmnt in order to merge in the utab content rather than looking at mtab directly (which is easy--I've already done it locally, but it needs the changes in util-linux from newer upstream releases, and possibly additional work). Certainly do-able for jessie. In initscripts, we make the choice of a dynamic or static mtab in the mtab_migrate function called from checkroot.sh. This is only ever run on read-write root, since it's not possible to change things if it's read-only (here, the admin is responsible). As discussed on IRC, we can't realistically change this at upgrade time due to loss of information such as nfs/cifs extended mount options. At boot time, we currently migrate mtab to a symlink where possible. Other alternatives are - migrating back to a static file (not recommended; this would reintroduce more problems than it solves) - making the choice of symlink or static file based upon particular criteria The attached patch does the latter. It looks to see if _netdev is in use, and if so will refuse to migrate to a symlink. Though it will do nothing if a symlink already exists, so it won't revert back to a static file (this could be added easily; I'm just attaching what I've done so far prior to going away for the week in case you want to push a fix for this before I get back). This isn't an ideal solution, and I certainly wouldn't want to keep it for jessie, but it will cover the majority of the _netdev usecases fairly simply as an immediate workaround for wheezy. I'm not sure of the scope of this problem, but given that it took around 15-16 months before this came up as an issue, I don't think it's particularly large, especially when considering the scope of the bugs affecting static mtab files, which was vastly larger and could cause worse problems. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 diff --git a/debian/src/initscripts/lib/init/mount-functions.sh b/debian/src/initscripts/lib/init/mount-functions.sh index 2ad4528..c5e0386 100644 @@ -414,6 +420,28 @@ run_migrate () # # Migrate /etc/mtab to a compatibility symlink # +_mtab_migrate () +{ + echo netdev=false + fstab_files | while read file; do +if [ -f "$file" ]; then +while read MNT_FSNAME MNT_DIR MNT_TYPE MNT_OPTS MNT_FREQ MNT_PASS MNT_JUNK; do +case "$MNT_FSNAME" in + ""|\#*) + continue; + ;; +esac +case "$MNT_OPTS" in + _netdev|_netdev,*|*,_netdev|*,_netdev,*) +echo netdev=true +break + ;; +esac + done < "$file" + fi + done +} + mtab_migrate () { # Don't symlink if /proc/mounts does not exist. @@ -421,6 +449,11 @@ mtab_migrate () return 1 fi + eval "$(_mtab_migrate)" + if [ "$netdev" = "true" ]; then + return 1 + fi + # Create symlink if not already present. if [ -L "/etc/mtab" ] && [ "$(readlink "/etc/mtab")" = "/proc/mounts" ]; then :
Bug#688140: file-rc: File-rc doesn't restore rcX.d dirs at remove, breaks sysv-rc installation.
On Thu, Mar 21, 2013 at 01:26:30PM +, Roger Leigh wrote: > On Thu, Mar 21, 2013 at 06:50:51AM +0100, Alexander Wirt wrote: > > On Wed, 20 Mar 2013, Roger Leigh wrote: > > > Alexander, is this approach OK with you? If you're happy with > > > what this is doing, can this go into wheezy? > > its basically your feature, so if you think its working - I am happy with > > it. > > Yes, I'm happy that this allows file-rc to sysv-rc migration. > Would you prefer to upload with the patch applied, or should I > do it? I'm away for the next week, so would you be able to upload this in the meantime? Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#688140: file-rc: File-rc doesn't restore rcX.d dirs at remove, breaks sysv-rc installation.
On Thu, Mar 21, 2013 at 06:50:51AM +0100, Alexander Wirt wrote: > On Wed, 20 Mar 2013, Roger Leigh wrote: > > Alexander, is this approach OK with you? If you're happy with > > what this is doing, can this go into wheezy? > its basically your feature, so if you think its working - I am happy with it. Yes, I'm happy that this allows file-rc to sysv-rc migration. Would you prefer to upload with the patch applied, or should I do it? Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#688140: file-rc: File-rc doesn't restore rcX.d dirs at remove, breaks sysv-rc installation.
On Wed, Mar 20, 2013 at 05:04:57PM +0100, Michael Stapelberg wrote: > at this point I cannot spend any more time on this bug report. I've tested your patch, and it appears to work correctly in all the cases I've tried. I've updated it slightly (attached) to log what's happening during transition to dependency-based boot, particularly if things go wrong, but it's otherwise functionally identical to your patch. It also runs insserv in verbose mode so that any errors/warnings are not hidden (as for sysv-rc). Alexander, is this approach OK with you? If you're happy with what this is doing, can this go into wheezy? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 diff -urN file-rc-0.8.14.original/debian/changelog file-rc-0.8.15/debian/changelog --- file-rc-0.8.14.original/debian/changelog 2012-08-19 19:56:20.0 +0100 +++ file-rc-0.8.15/debian/changelog 2013-03-20 22:39:54.191661297 + @@ -1,3 +1,16 @@ +file-rc (0.8.15) unstable; urgency=low + + [ Michael Stapelberg ] + * Call rcfile2link.sh followed by insserv to properly restore links +when removing file-rc. (Closes: #688140) + + [ Roger Leigh ] + * When migrating to dependency-based boot in the prerm, log +what's happening, and if insserv fails issue an informative + message (taken from sysv-rc postinst). + + -- Roger Leigh Wed, 20 Mar 2013 21:31:30 + + file-rc (0.8.14) unstable; urgency=low * Depend on insserv, this prevents upgrade problems with systems diff -urN file-rc-0.8.14.original/debian/prerm file-rc-0.8.15/debian/prerm --- file-rc-0.8.14.original/debian/prerm 2012-07-30 06:49:08.0 +0100 +++ file-rc-0.8.15/debian/prerm 2013-03-20 22:35:07.459268780 + @@ -16,12 +16,32 @@ # for details, see http://www.debian.org/doc/debian-policy/ or # the debian-policy package +# Make sure insserv is in path +PATH=/sbin:$PATH case "$1" in remove) +echo "info: restoring rc.d links" 1>&2 +/usr/share/file-rc/rcfile2link.sh +echo "info: running insserv" 1>&2 +if insserv -v ; then +echo "success: Enabled dependency based boot system." 1>&2 +else +echo "error: Something failed while migrating." 1>&2 +cat 1>&2 <http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot for +more information about dependency based boot sequencing. To +reattempt the migration process run 'insserv -v' after correcting +the cause of the problem, and then retry removing file-rc. + +EOF +fi ;; upgrade|deconfigure) - ;; +;; failed-upgrade) ;; *)
Bug#688140: file-rc: File-rc doesn't restore rcX.d dirs at remove, breaks sysv-rc installation.
On Wed, Mar 20, 2013 at 05:04:57PM +0100, Michael Stapelberg wrote: > Hi, > > at this point I cannot spend any more time on this bug report. > > Given that the bug report is without maintainer reply since more than > half a year, and there are merely 160 people voting for it via popcon, I > wonder if we should just drop file-rc from Debian in order to reduce > init system complexity. > > release-team: what do you think? I don't want to speak for the file-rc maintainers, but just from the POV of sysvinit and jessie: - in wheezy, we switched to requiring insserv for dependency-based boot; previously it was the default (but optional) and prior to that it was opt-in. So we've got to the point of dependency-based boot being required over several stable releases. - we have retained static runlevel ordering in maintainer scripts and update-rc.d for backward compatibility. These are going to be removed in jessie, since we now no longer use them at all (file-rc was the last user). - file-rc was converted (by me) to use insserv in its update-rc.d implementation, primarily to allow the removal of static ordering since it's now bitrotting badly--no one is using or testing the static ordering. I'll be adding lintian checks and updating update-rc.d and dh_installinit etc. to initially ignore and ultimately (jessie+1/2) error out if static ordering is used. Given the low number of users, and that fact that it's pretty much tied to static runlevel ordering, even with the insserv usage, file-rc will not work gracefully with dependency-based boot (if you do manual edits, but if you don't why not just use sysv-rc?), I'm unsure if it can remain viable. That is to say it will only work reliably if you don't edit the runlevel ordering, which is pretty much equivalent to sysv-rc but without any parallelisation. I'm very sure that for jessie we will have a large discussion about which init system (or systems) we will be supporting for the future. Of all the major contenders, all of them support dynamic boot ordering and none support static ordering, and for good reason. As far as I'm aware, file-rc is the only system using static ordering (even when the ordering is now generated from insserv). The other problem is Hurd, which doesn't use an init system at all (which is a major issue in its own right). WRT this bug, I think your patch is better included even if there are corner cases it doesn't currently handle--we can always fix those later. It's more important that migration back to sysv-rc is working, even if it's imperfect. The admin can always fix up any problems after, whereas the alternative is an unbootable system. It would be good if the file-rc maintainers could take the time to make sure if this is working properly; I'll be happy to make any changes to the sysv-rc maintainer scripts if required to assist in this. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#688140: file-rc: File-rc doesn't restore rcX.d dirs at remove, breaks sysv-rc installation.
On Wed, Mar 20, 2013 at 12:22:52PM +0100, Michael Stapelberg wrote: > Hi Roger, > > Roger Leigh writes: > > So maybe what's missing is a call to insserv to recreate the > > default links, or to create the links and run insserv to > > correctly reorder them in dependency order. The old link > > recreation behaviour used the pre-insserv static ordering IIRC, > > and that's certainly wrong. > I’m not too sure if I understood you right, and I certainly don’t get > all the details of how this stuff works, but this is my proposed fix: > > --- file-rc-0.8.14/debian/changelog 2012-08-19 20:56:20.0 +0200 > +++ file-rc-0.8.15/debian/changelog 2013-03-20 12:12:49.0 +0100 > @@ -1,3 +1,11 @@ > +file-rc (0.8.15) unstable; urgency=low > + > + * Non-maintainer upload. > + * Call rcfile2link.sh followed by insserv to properly restore links when > +removing file-rc (Closes: #688140) > + > + -- Michael Stapelberg Wed, 20 Mar 2013 12:12:48 > +0100 > + > file-rc (0.8.14) unstable; urgency=low > >* Depend on insserv, this prevents upgrade problems with systems > diff -Nru file-rc-0.8.14/debian/prerm file-rc-0.8.15/debian/prerm > --- file-rc-0.8.14/debian/prerm 2012-07-30 07:49:08.0 +0200 > +++ file-rc-0.8.15/debian/prerm 2013-03-20 12:21:39.0 +0100 > @@ -19,6 +19,8 @@ > > case "$1" in > remove) > +/usr/share/file-rc/rcfile2link.sh > +/sbin/insserv > ;; > upgrade|deconfigure) > ;; > > I’ve tested installing file-rc in squeeze, then upgrading to wheezy, > upgrading to file-rc 0.8.15, then installing sysv-rc, and the links come > back correctly. > > Roger, what do you think? Is this an acceptable fix? I /think/ so, but IIRC there were some corner cases where this previously caused problems. Possibly with disabled services, where the K links should exist but not S. Maybe disable some services, and then check that you can round trip from sysv-rc to file-rc and back to sysv-rc maintaining the state. And likewise for disabling/enabling a service in file-rc and preserving this when moving to sysv-rc. You might want to look at /var/lib/dpkg/info/sysv-rc.postinst to see how it expects the links to appear before running insserv (rcfile2link.sh could be updated to match the behaviour if it hasn't been already). This is basically - no S links in rc0/rc6 - no K links in any runlevel containing an equivalent S link or else insserv might complain. This may be rectified after running insserv, but is worth checking. Maybe take a copy of /etc at each stage then you can diff the changes. Some state might be lost going back to sysv-rc since any manual edits to the file-rc config not done via update-rc.d will not be preserved since they aren't in the LSB script header. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#701936: Bug#701956: btrfs can't fsck /run/rootdev on boot
On Sun, Mar 17, 2013 at 01:56:22PM +0100, Nis Martensen wrote: > On Fri, Mar 01, 2013 at 07:50:37AM +0100, Daniel Baumann wrote: > > works with systemd, it's sysvinit specific. > > Systemd skips the root file system check if the major device number of > the root file system is 0 (which is what btrfs reports): > http://cgit.freedesktop.org/systemd/systemd/tree/src/fsck/fsck.c#n297 > > The same could be done in sysvinit. Possible (untested) patch attached. Thanks for the patch. This will have to be deferred until after wheezy is released, but if we have to work around the btrfs fsck issues in this way, it looks like a reasonable approach. I would hope however that this would not be necessary, and that the btrfs fsck will become compatible with the standard /sbin/fsck options and behaviour, including being able to fsck a read-only mount, or else some users of btrfs won't be able to check their filesystems. Daniel, if you haven't done do already, it would be great if these issues could be brought to the attention of the upstream developers. As it stands, fsck.btrfs is not a compatible fsck, and this will break any tool expecting it to work like /sbin/fsck, not just sysvinit. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#701936: btrfs can't fsck /run/rootdev on boot
On Wed, Mar 06, 2013 at 09:16:01PM +0100, Daniel Baumann wrote: > > 2) fsck.btrfs fails to fsck a mounted filesystem > > > > fsck.btrfs won't check a mounted filesystem, even if mounted > > read-only. We need to be able to do this, since we are running > > fsck from the rootfs. We do this for all other filesystem types. > > the common workaround that e.g. other distributions do is to do this in > initramfs. probably debian should do that for all filesystems in future too. What about *right now*, today. What we "should" do is irrelevant to the problem right now. And it's not like doing it in the initramfs is the only "correct" way to do this. We've done it the existing way since forever. And you broke that. That's unacceptable. > > 3) fsck.btrfs does not support the standard fsck options > > easy fixable, but hasn't much to do with the current remaining problem > in sid. Yes, it does. We use those options. And that breaks things. > > 4) fsck.btrfs error codes > > > > I haven't tested this due to point (2) above > > me neither, but that's easy fixable too and hasn't much to do with the > current remaining problem in sid. Yes, it does. If they don't work, then it will again break the checkroot script. Please do check this. > > • systems with a btrfs root filesystem are currently *unbootable* > > without using "fastboot" to skip fsck > > *iff* sysvinit is used. It's the default init system for crying out loud. You broke booting with the default init system for all people using a btrfs rootfs. And even if it was not the default, it's still massively broken. Would breaking booting with systemd or upstart be any more acceptable? No, it would not. End this ridiculous line of reasoning right now. > > • even if the checkroot script is "fixed", fsck.btrfs remains > > broken and all the unbootable systems remain unbootable > > the current package works fine on systems with systemd (not yet fixed > points 3 and 4 from above are not breaking it). That does not solve the problem for the vast majority who are not using systemd. Think for a minute about how much breakage you've just caused. > > I would recommend that this be immediately reverted in unstable. > > i disagree. If you are not going to revert this, then please tell me what you are going to do to fix this, today. Leaving people's systems in a broken state is not on. It must be fixed, and fixed very quickly. There are lots of people who can't boot their computers thanks to this recklessness. Please, revert it today. Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#688140: file-rc: File-rc doesn't restore rcX.d dirs at remove, breaks sysv-rc installation.
On Tue, Mar 05, 2013 at 08:28:32PM +0100, Michael Stapelberg wrote: > Roger Leigh writes: > > The reason for this change is that with file-rc now using insserv > > to maintain the links in part, it is not really meaningful to > > "restore" the links. Both file-rc and sysv-rc use insserv, and so > Could you elaborate on that, please? I don’t see where the file-rc > package invokes insserv to maintain any links. On the contrary, after > installing file-rc, /etc/rc*.d/ is deleted and there are no links at > all. It /should/ all be contained within update-rc.d. The file-rc version of update-rc.d takes its defaults from "/sbin/insserv -s". Looking more closely, this is from the files in /etc/init.d, but will also use the rc?.d links as well if present. So if the links are deleted, you'll just get the defaults from the scripts, I think. So maybe what's missing is a call to insserv to recreate the default links, or to create the links and run insserv to correctly reorder them in dependency order. The old link recreation behaviour used the pre-insserv static ordering IIRC, and that's certainly wrong. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#701776: fsck.btrfs do not accept -a so the system will not boot anymore
On Thu, Feb 28, 2013 at 07:16:25AM -0600, Tim Cuthbertson wrote: > I confirm Axel Beckert's statement in message #60. My system cannot boot > with the latest patch 0.19+20130131-2 Note that for compatibility with fsck you must support at a minimum (even if you ignore them) the following options: -y -a -C -V which are all required by checkroot.sh. However, you should really accept *all* options which can be passed to fsck; we could well use additional options in the future, so you can't guarantee that the minimal set required right now will be all that is required. For such a critical tool, this needs to be done right. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#700051: Acknowledgement (sysvinit: fails to create /etc/inittab from a fresh debootstrap)
forcemerge 700048 700051 thanks On Thu, Feb 07, 2013 at 05:11:00PM -0500, David Comeau (SaturnNiGHTS) wrote: > i don't know why this created again. really sorry about that. > please close as already filed. No worries, I'll just merge them so they are closed together. -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#700047: sysvinit: fails to create /etc/inittab from a fresh debootstrap
On Thu, Feb 07, 2013 at 03:58:16PM -0500, David Comeau (SaturnNiGHTS) wrote: > It appears that with the new package that has been pushed to > sid/unstable [sysvinit 2.88dsf-40], performing a debootstrap install > results in an installation with no /etc/inittab. This appears to > occur due to a section of sysvinit.postinst not running, due to > being in a fakeroot/chroot/install environment, and having no init > process to reinitialize. That section of the postinst looks like it > doesn't execute [do_restart()], which unfortunately also includes: > > if [ ! -f /etc/inittab ] > then > cp -p /usr/share/sysvinit/inittab /etc/inittab > fi Awfully sorry that this has happened, this is certainly wrong. I'll have a -41 upload done later this evening. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#694928: asks for confirmation on config-file change on /etc/default/rcS, while file didn't change
On Wed, Feb 06, 2013 at 04:59:04PM +0100, Michael Stapelberg wrote: > On Sun, 2 Dec 2012 23:47:37 + > Roger Leigh wrote: > > Please don't apply it just yet--we'll presumably need to get > > approval from the release team to change this in initscripts > > at the same time. I'll have a patch for initscripts shortly; > > might be a bit later in the week to allow for comprehensive > > testing. > What’s the status on this? It’s been 2 months :-). I did send a mail to -release a week or so back, but haven't seen a response yet. Doing the change in initscripts is fairly trivial, but introducing a configuration file change at this point is probably not a great idea. If it's needed, I'll be happy to do it though. While editing a conffile isn't a good idea in general, the actual impact here is very low, and it's limited to ARM users, so if the consensus is that it's ignorable for wheezy, I'll be equally happy to postpone this for jessie and we can do the needed changes early in the jessie release cycle. Bottom line: I'll be happy to do whatever is needed. Just need some feedback on what is acceptable here. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#688140: file-rc: File-rc doesn't restore rcX.d dirs at remove, breaks sysv-rc installation.
On Wed, Feb 06, 2013 at 12:49:02AM +0100, Michael Stapelberg wrote: > On Tue, 6 Nov 2012 20:46:25 +0100 > Andreas Beckmann wrote: > > On Wednesday, 19. September 2012 21:05:03 Piotr Borkowski wrote: > > > File-rc doesn't restore rcX.d dirs at remove. This breaks sysv-rc > > > legacy_bootordering postinst function. After sysv-rc installation > > > this leads to empty rcX.d dirs and broken system. Maybe file-rc > > > should call > > > > I can reproduce this problem in piuparts distupgrade tests, e.g. > > setup squeeze (or wheezy) chroot > > switch to file-rc > > distupgrade to wheezy (or sid) > > switch back to sysv-rc > > > > but not within a distro: > > setup a squeeze (or wheezy or sid) chroot > > switch to file-rc > > switch back to sysv-rc > > > > curiously it also happens after a wheezy->sid distuprade, even if the > > versions of sysv-rc and file-rc are the same in both sid and wheezy > I haven’t tried to reproduce this issue yet, but I have figured out > that in file-rc 0.8.13, the call to rcfile2link.sh was removed from > debian/prerm: > > --- file-rc-0.8.12/debian/prerm 2010-04-07 21:30:54.0 +0200 > +++ file-rc-0.8.13/debian/prerm 2012-07-30 07:49:08.0 +0200 > @@ -19,7 +19,6 @@ > > case "$1" in > remove) > - /usr/share/file-rc/rcfile2link.sh > ;; > upgrade|deconfigure) > ;; > > > The changelog mentions: > >* Removed long obsolete logic (prior to oldstable) from maintainer > scripts, which is no longer useful for upgrades. > > Roger: Your name was above the changes in the changelog of file-rc > 0.8.13. Was this change intentional? If so, could you explain how the > conversion from file to links is supposed to work in the current > version so that we can debug further? Hi Michael, I'm afraid I can't remember the specifics off the top of my head; I'd have to review this work again to refresh my memory of the details. The reason for this change is that with file-rc now using insserv to maintain the links in part, it is not really meaningful to "restore" the links. Both file-rc and sysv-rc use insserv, and so when we switch between them, the state should remain identical. That is to say, that the changes effected by insserv (wrapped by update-rc.d/file-rc) are the state which should be preserved, which in practice means not doing anything at all. However... my memory may be bad here--I can't recall the extent to which we use insserv in file-rc for handling the links. I think the question to ask here is, why does the pattern of links make legacy_bootordering true, and why does activate_insserv fail? Is this at the point of running convert_rc_s_to_k or when running insserv? A little more detail about exactly what is failing here would be helpful. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#699090: base-files: nsswitch.conf does not include gshadow entry
On Sun, Jan 27, 2013 at 12:18:30PM +, Roger Leigh wrote: > Hi Santiago, > > I've attached a patch for adding support for the "gshadow" > (group shadow) NSS database to nsswitch.conf. Without this, > the libc getsg* family of functions will not work, hence > marking serious or else these functions will be broken for > new installations; would also be nice if it was possible to > add for upgrades as well? Do we have any mechanism for > making NSS updates? > > Note that it's using the "files" service rather than "compat" > here because "compat" does not support gshadow, but "files" > does (can be tested by running "getent gshadow" as root). Updated patch attached. This will upgrade nsswitch.conf in-place on upgrade to add support for gshadow for existing installations, while new installs will get the new nsswitch.conf by default. Note that it's only run for upgrades from base-files << 7.2, so will only be run once. The sed script will insert the new entry after the shadow entry if present, to make it identical to the default nsswitch.conf, otherwise it will be inserted after the group entry which it matches. On #debian-devel, we discussed the security implications of enabling this by default, but the consensus was that since this is only readable by root, it's not an issue (restricting the upgrade to only group:(compat|files) was considered, but thought to not be worthwhile over enabling it for all cases). Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 diff -urN base-files-7.1.original/debian/changelog base-files-7.2/debian/changelog --- base-files-7.1.original/debian/changelog 2013-01-27 11:59:40.147903916 + +++ base-files-7.2/debian/changelog 2013-01-27 13:55:10.111292346 + @@ -1,3 +1,13 @@ +base-files (7.2) unstable; urgency=low + + * Add an entry for the "gshadow" database to the nsswitch.conf; +also add this entry to existing nsswitch.conf files on upgrade. +This is needed for the glibc getsg* family of functions which +operate on the group shadow database to function correctly. +Closes: #699090. + + -- Roger Leigh Sun, 27 Jan 2013 13:51:41 + + base-files (7.1) unstable; urgency=low * Added Multi-Arch: foreign. This is needed even if base-files is diff -urN base-files-7.1.original/debian/postinst.in base-files-7.2/debian/postinst.in --- base-files-7.1.original/debian/postinst.in 2013-01-27 11:59:40.147903916 + +++ base-files-7.2/debian/postinst.in 2013-01-27 14:01:37.541714235 + @@ -122,3 +122,17 @@ install_from_default /usr/share/base-files/staff-group-for-usr-local \ /etc/staff-group-for-usr-local fi + +# Add gshadow to nsswitch.conf on upgrade +if dpkg --compare-versions "$2" lt-nl "7.2"; then + if ! grep -q '^[[:space:]]*gshadow:[[:space:]]' /etc/nsswitch.conf; then +match=group +if grep -q '^[[:space:]]*shadow[[:space:]]*:' /etc/nsswitch.conf; then + match=shadow +fi +sed -i -e "1,/^[[:space:]]*$match[[:space:]]*:.*\$/ {/^[[:space:]]*$match[[:space:]]*:.*\$/a\ +gshadow: files +}" /etc/nsswitch.conf +echo Updating /etc/nsswitch.conf to add the gshadow database. + fi +fi diff -urN base-files-7.1.original/share/nsswitch.conf base-files-7.2/share/nsswitch.conf --- base-files-7.1.original/share/nsswitch.conf 2013-01-27 11:59:40.147903916 + +++ base-files-7.2/share/nsswitch.conf 2013-01-27 12:04:44.534176087 + @@ -7,6 +7,7 @@ passwd: compat group: compat shadow: compat +gshadow: files hosts: files dns networks: files
Bug#699090: base-files: nsswitch.conf does not include gshadow entry
Package: base-files Version: 7.1 Severity: serious Tags: patch Hi Santiago, I've attached a patch for adding support for the "gshadow" (group shadow) NSS database to nsswitch.conf. Without this, the libc getsg* family of functions will not work, hence marking serious or else these functions will be broken for new installations; would also be nice if it was possible to add for upgrades as well? Do we have any mechanism for making NSS updates? Note that it's using the "files" service rather than "compat" here because "compat" does not support gshadow, but "files" does (can be tested by running "getent gshadow" as root). Thanks, Roger -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.32.33-kvm-i386-2028-dirty (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages base-files depends on: ii gawk [awk] 1:4.0.1+dfsg-2 ii mawk [awk] 1.3.3-17 base-files recommends no packages. base-files suggests no packages. -- no debconf information diff -urN base-files-7.1.original/share/nsswitch.conf base-files-7.1/share/nsswitch.conf --- base-files-7.1.original/share/nsswitch.conf 2013-01-27 11:59:40.147903916 + +++ base-files-7.1/share/nsswitch.conf 2013-01-27 12:04:44.534176087 + @@ -7,6 +7,7 @@ passwd: compat group: compat shadow: compat +gshadow: files hosts: files dns networks: files
Bug#663009: happens on all upgrades
On Wed, Jan 16, 2013 at 08:12:13PM +0100, Bastian Blank wrote: > Control: found -1 2.88dsf-34 > Control: severity -1 serious > > I upgraded several machines in the last days and _every_ one failed to > reboot after that: Does the following patch help with this? Also, it would help greatly to have some information about the systems you upgraded. Were these running native, or using some form of container/virtualisation? This patch should help for environment where pidof fails to detect init, but unless I understand the problem better, I'm not going to be able to just guess. Does pidof "/sbin/init" work on these systems? Does it have a nonzero exit status? --- a/debian/postinst +++ b/debian/postinst @@ -19,7 +19,7 @@ do_restart() { # PID of init; may not always be 1. Use for sending signals # and checking if init is running. - PID="$(pidof /sbin/init || true)" + PID="$(pidof /sbin/init || echo 1)" # Create /run/initctl if not present, and also create compatibility # symlinks --- a/debian/src/initscripts/etc/init.d/mountall.sh +++ b/debian/src/initscripts/etc/init.d/mountall.sh @@ -55,7 +55,7 @@ do_start() { mknod -m 600 "$INITCTL" p # Reopen control channel. - PID="$(pidof /sbin/init || true)" + PID="$(pidof /sbin/init || echo 1)" [ -n "$PID" ] && kill -s USR1 "$PID" fi Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#663009: happens on all upgrades
On Wed, Jan 16, 2013 at 08:12:13PM +0100, Bastian Blank wrote: > Control: found -1 2.88dsf-34 > Control: severity -1 serious > > I upgraded several machines in the last days and _every_ one failed to > reboot after that: > > | # reboot > | > | Broadcast message from root@s1 (pts/23) (Wed Jan 16 20:07:09 2013): > | > | The system is going down for reboot NOW! > | shutdown: timeout opening/writing control channel /run/initctl > | init: timeout opening/writing control channel /run/initctl > > Adding a symlink from /dev/initctl to /run/initctl makes reboot work > again. Do you have a transcript of any of the upgrades? It would be useful to know what when wrong here, since we do take care to make init reopen the control channel. See /var/lib/dpkg/info/sysvinit.postinst lines 9-44 in do_restart(). One question would be if all these systems were running in some type of container, since we determine the PID of init using PID="$(pidof /sbin/init || true)" Is this failing on your systems? If so, it would be very helpful to know why, and what we could do to make this more robust. Should probably be changed to "|| echo 1" as a fallback on failure. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#694379: initscripts: Symlinking /dev/shm to /run/shm makes Oracle Database XE unable to start. Bind mount makes it work.
On Mon, Dec 10, 2012 at 11:34:47PM +, Roger Leigh wrote: > On Mon, Dec 10, 2012 at 09:47:39PM +0000, Roger Leigh wrote: > > On Sun, Dec 09, 2012 at 05:24:50PM +0100, Jozsef Marton wrote: > > > Thank you, Roger, for your comments. > > > > > > You're right that the test Oracle XE applies is badly broken. See > > > details inline your comment below. > > > > > > This has not been reported to Oracle as Debian Linux is not a > > > supported platform for running their Database product. (I will make > > > a try reporting this.) > > > > > > Though I understand that dev/shm is an implementation detail, it was > > > user for ages and would using bind mount would simplify Debian > > > users' life when they intend to use Oracle Database. > > > > > > I'm attaching a patch[1] I have tested that makes this behaviour > > > configurable in /etc/default/tmpfs leaving symlink as the default > > > value. I hope that this can be intergated in Wheezy. > > > > Thanks very much for the patch. I'll look at merging this, or > > something very similar to it--there are some other details which > > also need taking care of. > > Preliminary patch is at > > http://anonscm.debian.org/gitweb/?p=users/rleigh/sysvinit.git;a=commitdiff;h=9be900ce3dc679f3f49b86b439b90f6937a159aa A fixed version of sysvinit has now been uploaded. Note that it's much simpler than the above patch. All you need to do is add an entry for /dev/shm in /etc/fstab as documented in fstab(5), i.e. tmpfs /dev/shm tmpfs nosuid,nodev,size=40%,mode=177700 and it will all just work. Note that /run/shm will then be linked to /dev/shm, so it won't preclude us switching the default to /run/shm down the line. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#695751: gdm: gdm3 update fails due to conflict with laptop-mode-tools
On Thu, Dec 13, 2012 at 09:15:12AM +0100, Adrin wrote: > This is the find output: > # find /etc -name '*vpnagentd_init*' > /etc/rc5.d/K25vpnagentd_init > /etc/rc5.d/S85vpnagentd_init > /etc/init.d/vpnagentd_init > /etc/rc4.d/K25vpnagentd_init > /etc/rc4.d/S85vpnagentd_init > /etc/rc2.d/K25vpnagentd_init > /etc/rc2.d/S85vpnagentd_init > /etc/rc3.d/K25vpnagentd_init > /etc/rc3.d/S85vpnagentd_init OK, I've solved the problem. If you adjust your symlinks like this: (sid)root@hufflepuff:/# find /etc -name '*vpnagentd_init' | sort | xargs ls -l -rwxr-xr-x 1 root root 1153 Dec 4 08:46 /etc/init.d/vpnagentd_init lrwxrwxrwx 1 root root 24 Dec 14 22:52 /etc/rc0.d/K01vpnagentd_init -> ../init.d/vpnagentd_init lrwxrwxrwx 1 root root 24 Dec 14 22:52 /etc/rc1.d/K01vpnagentd_init -> ../init.d/vpnagentd_init lrwxrwxrwx 1 root root 26 Dec 4 08:46 /etc/rc2.d/S21vpnagentd_init -> /etc/init.d/vpnagentd_init lrwxrwxrwx 1 root root 26 Dec 4 08:46 /etc/rc3.d/S21vpnagentd_init -> /etc/init.d/vpnagentd_init lrwxrwxrwx 1 root root 26 Dec 4 08:46 /etc/rc4.d/S21vpnagentd_init -> /etc/init.d/vpnagentd_init lrwxrwxrwx 1 root root 26 Dec 4 08:46 /etc/rc5.d/S21vpnagentd_init -> /etc/init.d/vpnagentd_init lrwxrwxrwx 1 root root 24 Dec 14 22:52 /etc/rc6.d/K01vpnagentd_init -> ../init.d/vpnagentd_init And then run insserv: (sid)root@hufflepuff:/# insserv insserv: warning: script 'K01vpnagentd_init' missing LSB tags and overrides insserv: warning: script 'vpnagentd_init' missing LSB tags and overrides It will then adjust the links and all will be well. Not entirely sure why this shows two warnings though. I think the cryptic errors you were getting were a result of "S85" being higher than the biggest runlevel "S21" in used by insserv. This then makes it get placed after $all and hence the dependency loop. That's my theory anyway--I haven't looked at the code yet. The stop number is adjusted to be first, and has also been removed from runlevels 2-5 and added to runlevels 0, 1 and 6. However, it does look like there's room for improvement here. If we haven't got an LSB header, why does the number get used at all? Isn't its presence in this runlevel sufficient? If so, we could just ignore the number and have insserv assign it one appropriately. Likewise for stop links. I hope this makes some degree of sense. I'm still not entirely sure about how the internals work here. I didn't notice issues like this testing upgrades, possibly due to there always being a script at S99. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#694379: initscripts: Symlinking /dev/shm to /run/shm makes Oracle Database XE unable to start. Bind mount makes it work.
On Mon, Dec 10, 2012 at 11:34:47PM +, Roger Leigh wrote: > tags 694379 + serious > thanks > > On Mon, Dec 10, 2012 at 09:47:39PM +, Roger Leigh wrote: > > On Sun, Dec 09, 2012 at 05:24:50PM +0100, Jozsef Marton wrote: > > > Thank you, Roger, for your comments. > > > > > > You're right that the test Oracle XE applies is badly broken. See > > > details inline your comment below. > > > > > > This has not been reported to Oracle as Debian Linux is not a > > > supported platform for running their Database product. (I will make > > > a try reporting this.) > > > > > > Though I understand that dev/shm is an implementation detail, it was > > > user for ages and would using bind mount would simplify Debian > > > users' life when they intend to use Oracle Database. > > > > > > I'm attaching a patch[1] I have tested that makes this behaviour > > > configurable in /etc/default/tmpfs leaving symlink as the default > > > value. I hope that this can be intergated in Wheezy. > > > > Thanks very much for the patch. I'll look at merging this, or > > something very similar to it--there are some other details which > > also need taking care of. > > Preliminary patch is at > > http://anonscm.debian.org/gitweb/?p=users/rleigh/sysvinit.git;a=commitdiff;h=9be900ce3dc679f3f49b86b439b90f6937a159aa > > This fits in with the existing script logic, and will simply mount the > tmpfs on /dev/shm rather than /run/shm if RAMSHM_ON_DEV_SHM=yes. Note > that this is currently not tested, so it's not ready for use yet. And > (note to me), needs to default RAMSHM=yes if RAMSHM_ON_DEV_SHM=yes since > there's no underlaying /run to fall back on. We don't use a bind mount > because with this approach it's firstly not needed, and also because > bind mounts don't play well in chroot environments. (Another note to > me: check chroot upgrade logic in case /run/shm is hardcoded in the > maintainer scripts.) With some further additions and testing, the current patch for this is here: http://anonscm.debian.org/gitweb/?p=users/rleigh/sysvinit.git;a=commitdiff_plain;h=f208974e295f187238d2ef6831ebc35d72b3c7de If you'd like to try this out, I'd be grateful for any feedback. If you would prefer prebuilt packages for testing, just let me know, and I'll make them available for download. Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#695751: gdm: gdm3 update fails due to conflict with laptop-mode-tools
On Thu, Dec 13, 2012 at 09:15:12AM +0100, Adrin wrote: > This is the find output: > # find /etc -name '*vpnagentd_init*' > /etc/rc5.d/K25vpnagentd_init > /etc/rc5.d/S85vpnagentd_init > /etc/init.d/vpnagentd_init > /etc/rc4.d/K25vpnagentd_init > /etc/rc4.d/S85vpnagentd_init > /etc/rc2.d/K25vpnagentd_init > /etc/rc2.d/S85vpnagentd_init > /etc/rc3.d/K25vpnagentd_init > /etc/rc3.d/S85vpnagentd_init > > And the attached is what you asked for. Thanks. With this, I can reproduce the issue in a chroot environment. I don't see this with just the script alone, so I can only assume this is a result of the symlinks you have in the rc.d directories. If I delete all the rc?.d/*vpnagentd_init links, insserv runs without error. Also, if I create a Snnvpnagentd_init link in rcS.d, it also works without error. But, if I create an S link in rc[2345].d, the error is then triggered. So this looks like the implicit $all dependency is only working in the context of rcS. Small note: You don't need the K links in rc[2345].d; restricting them to rc[016] is fine. This doesn't have any effect on the problem in question. One thing I'm not entirely clear on is how $all interacts with runlevels. Is there a $all at the end of every runlevel, or is this restricted to rcS? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#695751: gdm: gdm3 update fails due to conflict with laptop-mode-tools
On Wed, Dec 12, 2012 at 01:41:26PM +0100, Adrin wrote: > Hi, > > Thanks for the fast follow up. Two files are attached and this is the more > comprehensive report by adding set -x: I've tried to reproduce the failure on a clean wheezy install this evening using the /etc/init.d directory you provided. I'm afraid that I can't reproduce the failure at all. I just get a warning, and insserv completes without error. Possibly this is also dependent upon the links in the rcn.d directories. What does find /etc -name '*vpnagentd_init*' show? Would it be possible to have the entire content of your initscripts e.g. tar cfvz /tmp/initfiles.tar.gz /etc/rc?.d /etc/insserv* /etc/init.d so I can try to reproduce with the exact setup you have? Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#695751: gdm: gdm3 update fails due to conflict with laptop-mode-tools
On Wed, Dec 12, 2012 at 01:41:26PM +0100, Adrin wrote: > Hi, > > Thanks for the fast follow up. Two files are attached and this is the more > comprehensive report by adding set -x: Thanks for the files. The trigger for the problem is "vpnagentd_init", which lacks LSB headers. But there's nothing strictly wrong with this in and of itself. And there's nothing explicitly tying it to laptop-mode. /etc/init.d/laptop-mode contains: # Should-Start: $all # Required-Start:$remote_fs Could you change this to # Should-Start: # Required-Start:$remote_fs $all and then retry the "apt-get install -f" command? I think the reason this is causing problems is that "Should-Start: $all" isn't strict enough, which leads to the loop in the dependency graph; making it required should fix things (I hope). Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#687396: [buildd-tools-devel] Bug#687396: Bug#687396: Bug#687396: sbuild: building pyca fails silently
On Wed, Dec 05, 2012 at 02:25:45PM +, Roger Leigh wrote: > On Wed, Dec 05, 2012 at 03:17:11PM +0100, Roland Stigge wrote: > > On 12/05/2012 03:11 PM, Roland Stigge wrote: > > > But don't worry - it's just a minor change and at least fixes the issue > > > for the protocol. ;-) So others won't be disturbed by it during bug > > > squashing. > > > > So please consider sbuild 0.63.2-1.1 for wheezy (freeze exemption). > > (Maybe Roger will override the package which is now in the DELAYED queue.) > > I'd certainly want some careful testing first. Are there any corner > cases where this breaks anything? I'll review it later in the week > as I said earlier. And do note that this does not match the behaviour > on the buildds, so while it will fix things for local builds, it won't > work on the buildds until the patch is committed into git and merged > onto the buildd branch and then deployed. I just saw this uploaded; I thought you said this was in DELAYED/5 yesterday? Even small changes can do with some level of review and testing, which I said yesterday I would do this week. I don't think this warranted such a high severity, nor NMUing it as I was replying to your mail yesterday. Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#687396: [buildd-tools-devel] Bug#687396: Bug#687396: sbuild: building pyca fails silently
On Wed, Dec 05, 2012 at 03:17:11PM +0100, Roland Stigge wrote: > On 12/05/2012 03:11 PM, Roland Stigge wrote: > > But don't worry - it's just a minor change and at least fixes the issue > > for the protocol. ;-) So others won't be disturbed by it during bug > > squashing. > > So please consider sbuild 0.63.2-1.1 for wheezy (freeze exemption). > (Maybe Roger will override the package which is now in the DELAYED queue.) I'd certainly want some careful testing first. Are there any corner cases where this breaks anything? I'll review it later in the week as I said earlier. And do note that this does not match the behaviour on the buildds, so while it will fix things for local builds, it won't work on the buildds until the patch is committed into git and merged onto the buildd branch and then deployed. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#687396: [buildd-tools-devel] Bug#687396: sbuild: building pyca fails silently
On Wed, Dec 05, 2012 at 02:40:20PM +0100, Roland Stigge wrote: > Hi Andreas, > > On 12/05/2012 01:57 PM, Andreas Tille wrote: > > what about NMUing the package right now once you have found a proper > > patch? If there are any reasons that might prevent you from uploading > > just ping me about this. > > I just wanted to see if any buildd-tools developer wanted to upload. I've not yet had time to review and apply the patch you sent, but thanks for making it. Hopefully I'll have time later in the week. However, even if I fix and upload it now, it won't be deployed on the buildds immediately, so it won't resolve the problem you have with the -0 version right now. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#694928: asks for confirmation on config-file change on /etc/default/rcS, while file didn't change
On Sun, Dec 02, 2012 at 11:49:44PM +, Roger Leigh wrote: > On Sun, Dec 02, 2012 at 11:47:37PM +0000, Roger Leigh wrote: > > clone 694928 -1 > > reassign -1 initscripts > > thanks > > > > On Sun, Dec 02, 2012 at 12:23:07PM +0100, Martin Zobel-Helas wrote: > > > > Please find attached an example patch for flash-kernel to > > support old and new (rcS and fsck) locations for FSCKFIX > > as discussed on #debian-devel earlier. > > Hmm, actually attached now. Slight update to cope with commented-out lines (as provided by default). -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 >From 4db3a50a7bd6b11f3a4fa425e5e2c9b7cf1c9673 Mon Sep 17 00:00:00 2001 From: Roger Leigh Date: Sun, 2 Dec 2012 23:34:57 + Subject: [PATCH] debian: Update /etc/default/fsck in flash-kernel-installer postinst --- debian/changelog | 10 ++ debian/flash-kernel-installer.postinst |7 ++- 2 files changed, 16 insertions(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index 68c673b..526f1ec 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,13 @@ +flash-kernel (3.4) UNRELEASED; urgency=low + + [ Roger Leigh ] + * flash-kernel-installer postinst: Update FSCKFIX in +/etc/default/fsck as well as /etc/default/rcS for backward +compatibility. The purpose is to use /etc/default/fsck for +new installations. + + -- Roger Leigh Sun, 02 Dec 2012 23:33:24 + + flash-kernel (3.3) unstable; urgency=low * Replace XC-Package-Type by Package-Type diff --git a/debian/flash-kernel-installer.postinst b/debian/flash-kernel-installer.postinst index c07dee5..e9b88c7 100755 --- a/debian/flash-kernel-installer.postinst +++ b/debian/flash-kernel-installer.postinst @@ -35,7 +35,12 @@ db_progress INFO flash-kernel-installer/prepare # Stop fsck from prompting the user for input since most users don't # have a serial console. -sed -i "s/^FSCKFIX=no$/FSCKFIX=yes/" /target/etc/default/rcS || true +if [ -e /target/etc/default/rcS ]; then + sed -i -e "s/^FSCKFIX=no$/FSCKFIX=yes/" /target/etc/default/rcS || true +fi +if [ -e /target/etc/default/fsck ]; then + sed -i -e "s/^#FSCKFIX=no$/FSCKFIX=yes/" -e "s/^FSCKFIX=no$/FSCKFIX=yes/" /target/etc/default/fsck || true +fi if ! apt-install flash-kernel; then error "apt-install flash-kernel failed" -- 1.7.10.4
Bug#694928: asks for confirmation on config-file change on /etc/default/rcS, while file didn't change
On Sun, Dec 02, 2012 at 11:47:37PM +, Roger Leigh wrote: > clone 694928 -1 > reassign -1 initscripts > thanks > > On Sun, Dec 02, 2012 at 12:23:07PM +0100, Martin Zobel-Helas wrote: > > Please find attached an example patch for flash-kernel to > support old and new (rcS and fsck) locations for FSCKFIX > as discussed on #debian-devel earlier. Hmm, actually attached now. -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 >From 300eb0dcd6abc4ced0596f87a33d3165d46779e5 Mon Sep 17 00:00:00 2001 From: Roger Leigh Date: Sun, 2 Dec 2012 23:34:57 + Subject: [PATCH] debian: Update /etc/default/fsck in flash-kernel-installer postinst --- debian/changelog | 10 ++ debian/flash-kernel-installer.postinst |7 ++- 2 files changed, 16 insertions(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index 68c673b..526f1ec 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,13 @@ +flash-kernel (3.4) UNRELEASED; urgency=low + + [ Roger Leigh ] + * flash-kernel-installer postinst: Update FSCKFIX in +/etc/default/fsck as well as /etc/default/rcS for backward +compatibility. The purpose is to use /etc/default/fsck for +new installations. + + -- Roger Leigh Sun, 02 Dec 2012 23:33:24 + + flash-kernel (3.3) unstable; urgency=low * Replace XC-Package-Type by Package-Type diff --git a/debian/flash-kernel-installer.postinst b/debian/flash-kernel-installer.postinst index c07dee5..311615d 100755 --- a/debian/flash-kernel-installer.postinst +++ b/debian/flash-kernel-installer.postinst @@ -35,7 +35,12 @@ db_progress INFO flash-kernel-installer/prepare # Stop fsck from prompting the user for input since most users don't # have a serial console. -sed -i "s/^FSCKFIX=no$/FSCKFIX=yes/" /target/etc/default/rcS || true +if [ -e /target/etc/default/rcS ]; then + sed -i -e "s/^FSCKFIX=no$/FSCKFIX=yes/" /target/etc/default/rcS || true +fi +if [ -e /target/etc/default/fsck ]; then + sed -i -e "s/^FSCKFIX=no$/FSCKFIX=yes/" /target/etc/default/fsck || true +fi if ! apt-install flash-kernel; then error "apt-install flash-kernel failed" -- 1.7.10.4
Bug#694928: asks for confirmation on config-file change on /etc/default/rcS, while file didn't change
clone 694928 -1 reassign -1 initscripts thanks On Sun, Dec 02, 2012 at 12:23:07PM +0100, Martin Zobel-Helas wrote: Please find attached an example patch for flash-kernel to support old and new (rcS and fsck) locations for FSCKFIX as discussed on #debian-devel earlier. Please don't apply it just yet--we'll presumably need to get approval from the release team to change this in initscripts at the same time. I'll have a patch for initscripts shortly; might be a bit later in the week to allow for comprehensive testing. Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#694961: initscripts: Boot hangs cause of Init: job_process_handler ignored event 1 ....
reassign 694961 upstart thanks On Sun, Dec 02, 2012 at 08:14:00PM +0100, Peschae wrote: > Package: initscripts > Version: 2.88dsf-34 > Severity: critical > Justification: breaks the whole system > > Dear Maintainer, > > after an update, I got the error message Init: job_process_handler ignored > event 1 on three different system. > But I´m not really shure if the problem is in initscripts or an other package. > > One (this here) i386 , two amd64 - all Debian testing. One of the amd64 is > brand new after a Netinstall. Then I made > an update and got the error (boot stops). > i386: upstart 0.6.6-2 > amd64: upstart 0.6.6-2 > amd64 (brand new): sysvinit > > here´s the aptitude log of the update (brand new system): > [AKTUALISIERUNG] initscripts:amd64 2.88dsf-32 -> 2.88dsf-34 > [AKTUALISIERUNG] klibc-utils:amd64 2.0.1-3 -> 2.0.1-3.1 > [AKTUALISIERUNG] libc-bin:amd64 2.13-35 -> 2.13-37 > [AKTUALISIERUNG] libc6:amd64 2.13-35 -> 2.13-37 > [AKTUALISIERUNG] libgnutls26:amd64 2.12.20-1 -> 2.12.20-2 > [AKTUALISIERUNG] libklibc:amd64 2.0.1-3 -> 2.0.1-3.1 > [AKTUALISIERUNG] liblzma5:amd64 5.1.1alpha+20120614-1 -> 5.1.1alpha+20120614-2 > [AKTUALISIERUNG] libusb-0.1-4:amd64 2:0.1.12-20 -> 2:0.1.12-20+nmu1 > [AKTUALISIERUNG] locales:amd64 2.13-35 -> 2.13-37 > [AKTUALISIERUNG] multiarch-support:amd64 2.13-35 -> 2.13-37 > [AKTUALISIERUNG] sysv-rc:amd64 2.88dsf-32 -> 2.88dsf-34 > [AKTUALISIERUNG] sysvinit:amd64 2.88dsf-32 -> 2.88dsf-34 > [AKTUALISIERUNG] sysvinit-utils:amd64 2.88dsf-32 -> 2.88dsf-34 > [AKTUALISIERUNG] xz-utils:amd64 5.1.1alpha+20120614-1 -> 5.1.1alpha+20120614-2 > > My workaround is: update the systems to upstart upstart 1.6.x > > Please let me know if you need additonal information. I´ve also got an other > system (upstart 0.6.6-2) which I can "kill". Reassigning the bug to upstart. The actual error message (job_process_handler) is definitely upstart. If there's anything initscripts-related then I'll certainly look further into that, but I don't personally have the expertise to investigate the upstart side of things further. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#693371: insserv: Please update insserv.conf to ensure mountall-bootclean is run
Package: insserv Version: 1.14.0-4 Severity: serious Tags: patch Justification: Breaks boot See also: #677097 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677097 When we added mountall-bootclean to initscripts, I didn't realise at the time that the dependencies were insufficient, and $local_fs requires mountall-bootclean to be run, or it can be mis-ordered and delete /run. The attached patch fixes up insserv to add mountall-bootclean to $local_fs. I've included the change to both debian/patches and to insserv.conf so you can apply whatever you feel best. Flagged as serious since this does prevent systems from booting. I'm going to also make the change to sysvinit to add X-Start-Before: bootmish.sh to mountall_bootclean but it would be good to have it here as well to make it less easy to break your system. Thanks, Roger -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.32.33-kvm-i386-2028-dirty (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages insserv depends on: ii libc6 2.13-35 insserv recommends no packages. Versions of packages insserv suggests: pn bootchart2 -- no debconf information diff -urN insserv-1.14.0.original/debian/patches/11_debian_conf.patch insserv-1.14.0/debian/patches/11_debian_conf.patch --- insserv-1.14.0.original/debian/patches/11_debian_conf.patch 2012-11-15 20:28:53.639644555 + +++ insserv-1.14.0/debian/patches/11_debian_conf.patch 2012-11-15 20:32:27.459921674 + @@ -9,7 +9,7 @@ # All local filesystems are mounted (done during boot phase) # -$local_fs boot.localfs +boot.crypto -+$local_fs +mountall +mountoverflowtmp +umountfs ++$local_fs +mountall +mountall-bootclean +mountoverflowtmp +umountfs # # Low level networking (ethernet card) diff -urN insserv-1.14.0.original/insserv.conf insserv-1.14.0/insserv.conf --- insserv-1.14.0.original/insserv.conf 2012-11-15 20:28:53.639644555 + +++ insserv-1.14.0/insserv.conf 2012-11-15 20:30:57.778120460 + @@ -1,7 +1,7 @@ # # All local filesystems are mounted (done during boot phase) # -$local_fs +mountall +mountoverflowtmp +umountfs +$local_fs +mountall +mountall-bootclean +mountoverflowtmp +umountfs # # Low level networking (ethernet card)
Bug#677097: mountall-bootclean.sh nukes udev's data in /run
On Thu, Nov 08, 2012 at 12:44:09PM +0100, Jakub Wilk wrote: > * Roger Leigh , 2012-11-08, 00:22: > > > >Would it be possible to debug this in a bit more detail on your > >system? /lib/init/bootclean.sh's clean function must be failing > >all these checks: > > Thu Nov 8 12:17:30 2012: Cleaning up temporary files > Thu Nov 8 12:17:30 2012: BEFORE BOOTMISC: [ .tmpfs dhclient.eth0.pid initctl > initramfs lock mount network sendsigs.omit.d shm udev utmp ] > Thu Nov 8 12:17:30 2012: AFTER BOOTMISC: [ dhclient.eth0.pid initctl > initramfs lock mount network sendsigs.omit.d shm udev utmp ] > Thu Nov 8 12:17:31 2012: Setting up X socket directories... /tmp/.X11-unix > /tmp/.ICE-unix. > Thu Nov 8 12:17:31 2012: BEFORE MOUNTALL-BOOTCLEAN: [ dhclient.eth0.pid > initctl initramfs lock mount network sendsigs.omit.d shm udev utmp ] > Thu Nov 8 12:17:31 2012: Cleaning up temporary files... /tmp /lib/init/rw > /run /run/lock /run/shm. > Thu Nov 8 12:17:31 2012: AFTER MOUNTALL-BOOTCLEAN: [ .clean initramfs lock > mount network sendsigs.omit.d shm udev utmp ] > Thu Nov 8 12:17:31 2012: INIT: Entering runlevel: 2 > > (This is on a VM on which I had to impose a sleep to make the bug > trigger. However, the bug also triggers naturally on my development > machine, which I can't reboot right know, though I'm pretty sure the > cause is the same there.) > > As I understand it, bootmisc is supposed to be run _after_ > mountall-bootclean, though this order doesn't seem to be enforced in > any way. So it's looking like we may be just missing a dependency here, so the bug would be present all the time, but the parallelism is exposing it more frequently. Would be worth checking the /etc/init.d/depend files and running /usr/share/insserv/make-testsuite to see exactly where bootmisc is being placed in the depdendency graph. The intention is that this won't run until after mountall-bootclean. I /think/ that the $remote_fs is supposed to ensure this, but this might not be good enough. Maybe we need to add mountall_bootclean to $local_fs, or add X-Start-Before: bootmish.sh to mountall_bootclean. Could you possible try both of those, rerun insserv, and see if this prevents the problem from occuring? Thanks again, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#677097: mountall-bootclean.sh nukes udev's data in /run
On Wed, Nov 07, 2012 at 08:03:39PM +0100, Jakub Wilk wrote: > Control: reopen -1 Control: found -1 2.88dsf-32 > > * Jakub Wilk , 2012-06-11, 18:20: > >mountall-bootclean.sh removes files from /run, but these may > >include files created by init scripts earlier in the same boot > >process. I observed this because the script nuked files in > >/run/udev/, leaving my X server without any input devices. > > I can still reproduce this bug. That's a bit frustrating, I thought we had this nailed now. Would it be possible to debug this in a bit more detail on your system? /lib/init/bootclean.sh's clean function must be failing all these checks: # Does not exist [ -d "$dir" ] || return 1 # tmpfs does not require cleaning [ -f "$dir/.tmpfs" ] && return 0 # Can clean? checkflagfile "$dir" || return 0 # Already cleaned [ -f "${dir}/.clean" ] && return 0 # Can't clean yet? which find >/dev/null 2>&1 || return 1 Could you possibly put some print statements in there and find out if all these pass? If so, is the ".tmpfs" file missing? Or the ".clean" flag file? If that's the case, we really need to know why they aren't present, since they should have been created before this point. If the init scripts are being run in the wrong order, these could potentially be run after the files were deleted. Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#691376: [buildd-tools-devel] Bug#691376: schroot: session recovery mounts $device, not $mount-device, for LVM snapshots
tags 1.6.3-1 + patch pending thanks On Wed, Oct 24, 2012 at 10:23:27PM +0100, Roger Leigh wrote: Patch to address this issue. Note that this is not yet completely tested for all the other block-device-using chroot types. **Do not apply until tested.** commit 19293f7a7b0943997397ef30465cd11686990a9b Author: Roger Leigh Date: Wed Oct 24 23:25:10 2012 +0100 sbuild: Don't call set_mount_device indirectly from ctor See #691376. sbuild::chroot_block_device_base::set_device was called from the chroot_block_device_base ctor, and called sbuild::chroot_facet_mountable::set_mount_device for all chroot types except lvm-snapshot. However, dynamic_cast<> fails during construction, leading to the mount device being overwritten, and --recover-session mounting the source LV rather than the snapshot LV. This patch moves the call to set_mount_device to the session clone operation in sbuild::chroot_facet_session_clonable, which is where the equivalent operation is done for lvm-snapshot. This is done prior to lvm-snapshot to ensure that the snapshot is not overwritten here either. diff --git a/sbuild/sbuild-chroot-block-device-base.cc b/sbuild/sbuild-chroot-block-device-base.cc index 2f2f958..86f3af6 100644 --- a/sbuild/sbuild-chroot-block-device-base.cc +++ b/sbuild/sbuild-chroot-block-device-base.cc @@ -46,12 +46,8 @@ chroot_block_device_base::chroot_block_device_base (): chroot_block_device_base::chroot_block_device_base (const chroot_block_device_base& rhs): chroot(rhs), - device() + device(rhs.device) { - /// @todo Required to set mount_device. Remove once no longer - /// needed. - if (!rhs.device.empty()) -set_device(rhs.device); } chroot_block_device_base::~chroot_block_device_base () @@ -71,16 +67,6 @@ chroot_block_device_base::set_device (std::string const& device) throw error(device, DEVICE_ABS); this->device = device; - - /// @todo: This may not be appropriate for derived classes such as - /// lvm_snapshot, since re-setting the device could overwrite the - /// mount device. - chroot_facet_mountable::ptr pmnt -(get_facet()); -#ifdef SBUILD_FEATURE_LVMSNAP - if (!dynamic_cast(this)) -#endif -pmnt->set_mount_device(this->device); } std::string diff --git a/sbuild/sbuild-chroot-facet-session-clonable.cc b/sbuild/sbuild-chroot-facet-session-clonable.cc index 408e9ab..1d924ad 100644 --- a/sbuild/sbuild-chroot-facet-session-clonable.cc +++ b/sbuild/sbuild-chroot-facet-session-clonable.cc @@ -19,6 +19,7 @@ #include #include "sbuild-chroot.h" +#include "sbuild-chroot-facet-mountable.h" #include "sbuild-chroot-facet-session.h" #include "sbuild-chroot-facet-session-clonable.h" #include "sbuild-chroot-facet-source-clonable.h" @@ -138,6 +139,19 @@ chroot_facet_session_clonable::clone_session_setup (chroot::ptr& clone, << format("Mount Location: %1%") % clone->get_mount_location() << endl; + /* Block devices need the mount device name specifying. */ + /* Note that this will be overridden by LVM snapshot, below, so the + order here is important. */ + std::shared_ptr blockdevbase(std::dynamic_pointer_cast(clone)); + if (blockdevbase) +{ + chroot_facet_mountable::ptr pmnt + (clone->get_facet()); + if (pmnt) + pmnt->set_mount_device(blockdevbase->get_device()); +} + + #ifdef SBUILD_FEATURE_LVMSNAP /* LVM devices need the snapshot device name specifying. */ std::shared_ptr snapshot(std::dynamic_pointer_cast(clone)); -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#691376: schroot: session recovery mounts $device, not $mount-device, for LVM snapshots
Package: schroot Version: 1.6.3-1 Severity: serious Tags: security Justification: Security violation and potential for dataloss Originally reported here: https://bugs.launchpad.net/ubuntu/+source/schroot/+bug/1070008 Calling --recover-session on a session using an LVM snapshot, it remounts using the original LV rather than the snapshot LV. This is due to this check failing: sbuild::chroot_block_device_base::set_device(): /// @todo: This may not be appropriate for derived classes such as /// lvm_snapshot, since re-setting the device could overwrite the /// mount device. chroot_facet_mountable::ptr pmnt (get_facet()); #ifdef SBUILD_FEATURE_LVMSNAP if (!dynamic_cast(this)) #endif pmnt->set_mount_device(this->device); This is due to the use of dynamic_cast<> in this method. This is not in itself wrong, but because this method is called from the constructor, the dynamic_cast<> returns null due to the vptr not yet having any knowledge of the derived class--it will work fine once the base class is constructed. This was already commented in several places to refactor to clean this up, but the presence of this issue will require this to be done immediately. I've tagged this security due to the potential for a user to access the original source chroot. However, the scope is relatively limited since the filesystem permissions will prevent them from doing anything they should not (unless you granted them root access, in which case they already had the ability to do this). Regards, Roger -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.32.33-kvm-i386-2028-dirty (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages schroot depends on: ii libboost-filesystem1.49.0 1.49.0-3.1 ii libboost-iostreams1.49.01.49.0-3.1 ii libboost-program-options1.49.0 1.49.0-3.1 ii libboost-regex1.49.01.49.0-3.1 ii libboost-system1.49.0 1.49.0-3.1 ii libc6 2.13-35 ii libgcc1 1:4.7.1-7 ii liblockdev1 1.0.3-1.5 ii libpam0g1.1.3-7.1 ii libstdc++6 4.7.1-7 ii libuuid12.20.1-5.2 ii schroot-common 1.6.3-1 schroot recommends no packages. Versions of packages schroot suggests: pn aufs-modules | unionfs-modules pn btrfs-tools ii debootstrap 1.0.42 pn lvm2 pn qemu-user-static -- Configuration Files: /etc/schroot/schroot.conf changed [not included] -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#686148: [buildd-tools-devel] Bug#686148: schroot: Does not unmount /run/shm
severity 686148 serious tags 686148 + fixed-upstream pending thanks On Wed, Aug 29, 2012 at 09:42:16AM +0200, Daniel Dehennin wrote: > I noticed several “/run/shm” in my mount since a moment but did not > figure out where they came from. > tmpfs on /run/shm type tmpfs (rw,relatime) > > After quitting the schroot, the “/run/shm” is still here. Thanks for reporting this. I've made this RC severity due to this giving an end user the ability to mount over the host /run/shm, which could cause problems on the host system. They can't alter the content of the fstab, but if they have root access in the chroot, they could place symlinks to arbitrary places on the host. In git, I've updated schroot-mount to use realpath(3) to canonicalise the path, which will remove all symlinks. We then ensure that any links outside the chroot will be resolved inside before mounting. This does have a limitation: we call realpath(3) on the host, so complex nested symlinks may resolve differently. But anyone using complex sets of nested links as mountpoints is insane! And even in this case, they will all get mounted inside the chroot, so there's no danger of compromising the host. This will fix the problem you reported. This might also need backporting to 1.4 and squeeze. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#672959: [patch] Bug#672959: kfreebsd-*: panic: vm_fault_copy_wired
On Tue, Aug 21, 2012 at 10:47:57AM +0200, Axel Beckert wrote: > Hi, > > Petr Salinger wrote: > > >I'm beginning to think that startpar is malfunctioning in some way > > >(after checkroot.sh returns, but before it runs the next script). > > > > Thanks to Steven for excelent hint. > > Indeed. That fits perfectly with my observation that always the last > thing I saw before the crash was the ":" from the last line of > checkroot.sh. No trace of another init.d script being started. > > > The patch bellow fixes it for me. > > Please could also other people verify it. > > Will do this evening. Thanks Petr! Many thanks Petr for the patch, and everyone else for testing and investigating. I've put a test package here: http://people.debian.org/~rleigh/sysvinit/sysvinit_2.88dsf-33.dsc I'd be grateful if anyone could build this and double-check that this is correct, and fixes the bug. I'll upload this as soon as that's done. Thanks again, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#679409: lightdm: Fails to start on boot, invoke-rc.d lightdm start fails
On Sun, Aug 19, 2012 at 12:53:21PM -0700, Steve Langasek wrote: > On Sun, Aug 12, 2012 at 09:48:02AM +0100, Roger Leigh wrote: > > On Sun, Aug 12, 2012 at 03:37:52PM +1000, James Tocknell wrote: > > > I've patched startpar to special-case lightdm as for gdm/kdm, but this > > doesn't appear to have any effect here (but is probably generally a good > > thing to have). > > The change that was committed has nothing at all to do with this bug, and to > me it looks like an unnecessary divergence from startpar upstream; so I've > reverted those changes from the git repo. IMHO it's not something that's > worth carrying a delta from upstream over. But feel free to reinstate if > you disagree. My thinking here was that if startpar is special casing the priorities of display managers, shouldn't it be behaving the same for all the common ones? That said, I am not certain /why/ it's special casing them in the first place; certainly lightdm appears to function perfectly well without the patch. I don't have strong feelings either way here--personally I'd prefer them all removed if this is solely to hack in something better expressed through dependencies. > BTW, Roger, could you please run 'echo DEBCHANGE_RELEASE_HEURISTIC=changelog > >> ~/.devscripts' on your development machine? This is the only sensible > behavior to use with dch in a shared VCS; it's very frustrating to have to > check the archive or look at git tags each time to figure out whether the > changes I'm looking at on trunk are uploaded or not... I've done this, but isn't it the documented default behaviour? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#673676: [buildd-tools-devel] Bug#673676: sbuild-createchroot: broken due to debian-archive-keyring changes
On Thu, Aug 16, 2012 at 05:16:23PM +0200, Cyril Brulebois wrote: > Roger Leigh (04/07/2012): > > This was fixed in 4bc2072701ddd last week, and is pending upload. > > (Should already be tagged pending.) > > > > I have a few other bugs to fix in sbuild, but should be uploading it > > in the next week or so. > > “Next month”-ly-ping? This was done over the weekend. Hope this addresses all the outstanding issues. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#673676: [buildd-tools-devel] Bug#673676: sbuild-createchroot: broken due to debian-archive-keyring changes
On Thu, Aug 16, 2012 at 05:16:23PM +0200, Cyril Brulebois wrote: > Roger Leigh (04/07/2012): > > This was fixed in 4bc2072701ddd last week, and is pending upload. > > (Should already be tagged pending.) > > > > I have a few other bugs to fix in sbuild, but should be uploading it > > in the next week or so. > > “Next month”-ly-ping? Sorry, got caught up with other things. I'll upload it this weekend. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#672066: Still broken in unstable
r/include/Ice/LocalObjectF.h:15:0, from ./Printer.h:24, from Printer.cpp:21: /usr/include/Ice/Handle.h: In instantiation of ‘IceInternal::Handle::Handle(const IceInternal::Handle&) [with T = Ice::Object; IceInternal::Handle = IceInternal::Handle]’: Printer.cpp:241:12: required from here /usr/include/Ice/Handle.h:98:13: error: ‘upCast’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive] Printer.cpp:42:26: note: ‘IceProxy::Ice::Object* IceInternal::upCast(IceProxy::Demo::Printer*)’ declared here, later in the translation unit In file included from /usr/include/Ice/LocalObjectF.h:15:0, from ./Printer.h:24, from Printer.cpp:21: /usr/include/Ice/Handle.h: In instantiation of ‘IceInternal::Handle::~Handle() [with T = Demo::Printer]’: Printer.cpp:387:43: required from here /usr/include/Ice/Handle.h:106:13: error: ‘upCast’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive] Printer.cpp:42:26: note: ‘IceProxy::Ice::Object* IceInternal::upCast(IceProxy::Demo::Printer*)’ declared here, later in the translation unit In file included from /usr/include/Ice/LocalObjectF.h:15:0, from ./Printer.h:24, from Printer.cpp:21: /usr/include/Ice/Handle.h: In instantiation of ‘IceInternal::Handle& IceInternal::Handle::operator=(const IceInternal::Handle&) [with T = Demo::Printer; IceInternal::Handle = IceInternal::Handle]’: Printer.cpp:387:43: required from here /usr/include/Ice/Handle.h:178:17: error: ‘upCast’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive] Printer.cpp:42:26: note: ‘IceProxy::Ice::Object* IceInternal::upCast(IceProxy::Demo::Printer*)’ declared here, later in the translation unit In file included from /usr/include/Ice/LocalObjectF.h:15:0, from ./Printer.h:24, from Printer.cpp:21: /usr/include/Ice/Handle.h:186:17: error: ‘upCast’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive] Printer.cpp:42:26: note: ‘IceProxy::Ice::Object* IceInternal::upCast(IceProxy::Demo::Printer*)’ declared here, later in the translation unit In file included from /usr/include/Ice/LocalObjectF.h:15:0, from ./Printer.h:24, from Printer.cpp:21: /usr/include/Ice/Handle.h: In instantiation of ‘IceInternal::Handle::Handle(T*) [with T = Demo::Printer]’: /usr/include/Ice/Handle.h:198:47: required from ‘static IceInternal::Handle IceInternal::Handle::dynamicCast(const IceUtil::HandleBase&) [with Y = Ice::Object; T = Demo::Printer; IceInternal::Handle = IceInternal::Handle]’ Printer.cpp:387:43: required from here /usr/include/Ice/Handle.h:66:13: error: ‘upCast’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive] Printer.cpp:42:26: note: ‘IceProxy::Ice::Object* IceInternal::upCast(IceProxy::Demo::Printer*)’ declared here, later in the translation unit In file included from /usr/include/Ice/LocalObjectF.h:15:0, from ./Printer.h:24, from Printer.cpp:21: /usr/include/Ice/Handle.h: In instantiation of ‘IceInternal::Handle::Handle(const IceInternal::Handle&) [with T = Demo::Printer; IceInternal::Handle = IceInternal::Handle]’: /usr/include/Ice/Handle.h:198:47: required from ‘static IceInternal::Handle IceInternal::Handle::dynamicCast(const IceUtil::HandleBase&) [with Y = Ice::Object; T = Demo::Printer; IceInternal::Handle = IceInternal::Handle]’ Printer.cpp:387:43: required from here /usr/include/Ice/Handle.h:98:13: error: ‘upCast’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive] Printer.cpp:42:26: note: ‘IceProxy::Ice::Object* IceInternal::upCast(IceProxy::Demo::Printer*)’ declared here, later in the translation unit -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#679409: lightdm: Fails to start on boot, invoke-rc.d lightdm start fails
On Sun, Aug 12, 2012 at 03:37:52PM +1000, James Tocknell wrote: > I've tested the patch, and it doesn't fix the issue I'm having. I'm > using Upstart > as my init daemon, and lightdm still fails, with no useful output in > /var/log/boot. However, lightdm does start when I use sysvinit as the init > daemon, with the patch. Could this be a Upstart issue? I know lightdm has > some association with Ubuntu, and Upstart is Ubuntu's default init daemon, > could the issue be with the very different versions of Upstart in Ubuntu and > Debian? The problem could lie in the fix for the bug #660824, which was a > change between the version of sysvinit-utils that works for me and don't work > for me, as it's Upstart related. I'll have to ask Steve Langasek, who was responsible for that change. Steve, it appears that lightdm won't start using upstart with the recent sysvinit upstart bridge stuff. I'm not sure if this is an issue in sysvinit, startpar-upstart-inject, or upstart. I've patched startpar to special-case lightdm as for gdm/kdm, but this doesn't appear to have any effect here (but is probably generally a good thing to have). Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#679409: lightdm: Fails to start on boot, invoke-rc.d lightdm start fails
On Sat, Aug 11, 2012 at 05:26:29PM +0100, Roger Leigh wrote: > On Wed, Jul 11, 2012 at 02:06:52PM +1000, James Tocknell wrote: > > On Mon, Jul 2, 2012 at 6:04 PM, Yves-Alexis Perez wrote: > > > On lun., 2012-07-02 at 10:02 +0200, Petter Reinholdtsen wrote: > > >> [Yves-Alexis Perez] > > >> > James, in any case, I think providing /etc/init.d/.depend.* might > > >> > help solving this. > > >> > > >> Actually, it is better to provide the output from > > >> /usr/share/insserv/make-testsuite, which allow the boot sequence to be > > >> reproduced using dummy init.d scripts. > > >> > > >> > Please keep me on CC: so I'm informed of the development. It might > > >> > be interesting to provide /var/log/lightdm.log and > > >> > /var/log/lightdm-gtk-greeeter.log, although the fact it works with > > >> > startx might means it won't show anything. > > >> > > >> To debug this, try to disable concurrent booting (and keep dependency > > >> based boot sequencing), and see if it work better. Also, it would be > > >> useful to get the boot log (/var/log/boot.log) after enabling > > >> bootlogd. > > I've installed lightdm on my system, and I do see the occasional > failure to start. This would indicate some race in parallelisation > which would be indicative of a missing dependency. Please could you try sysvinit with the patch attached here? This special cases lightdm in startpar, since gdm/kdm/xdm are already special cased here. http://anonscm.debian.org/gitweb/?p=collab-maint/sysvinit;a=commitdiff;h=34ee13ba8d509183b568c70511289f7f7579502b If you're unable to build yourself, let me know and I'll prepare some packages. Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 >From 34ee13ba8d509183b568c70511289f7f7579502b Mon Sep 17 00:00:00 2001 From: Roger Leigh Date: Sat, 11 Aug 2012 22:16:00 +0100 Subject: [PATCH 1/2] startpar: Add patch to special case lightdm --- debian/patches/78_startpar_lightdm.patch | 15 +++ debian/patches/series|1 + 2 files changed, 16 insertions(+), 0 deletions(-) create mode 100644 debian/patches/78_startpar_lightdm.patch diff --git a/debian/patches/78_startpar_lightdm.patch b/debian/patches/78_startpar_lightdm.patch new file mode 100644 index 000..e110b8a --- /dev/null +++ b/debian/patches/78_startpar_lightdm.patch @@ -0,0 +1,15 @@ +Purpose: Add lightdm to list of special cased *dms +Fixes: Intermittent failure to start lightdm +Author: Roger Leigh +Status: Not yet submitted upstream +--- +--- a/startpar/makeboot.c 2012-08-11 21:58:53.0 +0100 b/startpar/makeboot.c 2012-08-11 22:00:57.0 +0100 +@@ -273,6 +273,7 @@ + if (! strcmp(node->name, "xdm") + || ! strncmp(node->name, "gdm", 3) + || ! strncmp(node->name, "kdm", 3) ++ || ! strncmp(node->name, "lightdm", 7) + || ! strcmp(node->name, "boot.udev") + || ! strcmp(node->name, "udev")) + importance = 100; diff --git a/debian/patches/series b/debian/patches/series index e4139b0..b70da91 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -16,6 +16,7 @@ 75_man_startpar_see_also.patch 76_startpar_ldflags.patch 77_startpar_skip_reason.patch +78_startpar_lightdm.patch 91_sulogin_lockedpw.dpatch 92_kfreebsd_ifdown.patch 93_run_initctl.patch -- 1.7.2.5
Bug#684607: [buildd-tools-devel] Bug#684607: Chroot setup failed: stage=setup-start
On Sat, Aug 11, 2012 at 08:23:28PM +0200, Christoph Egger wrote: > Nothing changed in config for almost a year, schroot fails to set up > a chroot now. Log attached. > D(2): run_parts: executing 50chrootname, setup-start, ok > I: Executing ‘50chrootname setup-start ok’ > I: 50chrootname: Setting chroot name to unstable-amd64-sbuild > D(2): run_parts: 50chrootname failed with status 1 > D(3): Chroot setup scripts, exec scripts or session failed OK, so it's the 50chrootname script failing here. The only change to that script in the last year has been the addition of a single line: d04e32dd etc/setup.d/50chrootname (Roger Leigh 2012-04-03 23:29:40 +0100 24) . "$SETUP_DATA_DIR/common-config" http://anonscm.debian.org/gitweb/?p=buildd-tools/schroot.git;a=commitdiff;h=d04e32dd3cc39ea641fc2848957292fe94751925 However, as you can see by looking at the diff, that line was added to all the other scripts as well, and you should have the script here: % ls /usr/share/schroot/setup common-config common-data common-functions Since you get the "Setting chroot name..." message, the only other line in the file which can fail is: echo "${CHROOT_NAME}" > "${CHROOT_PATH}/etc/debian_chroot" Which would imply that this failed. It doesn't give an error why--did your debug log also capture stderr? If not, a copy with stderr included would be useful here. All the variables like CHROOT_NAME and CHROOT_PATH look correct. SETUP_DATA_DIR is likewise correct for sourcing the shell scripts at the top. Is /etc/debian_chroot writable by the setup script? / and /etc must be writable by root. So it would be very useful to know - the stderr (e.g. run with script or 2>&1) - if you can check the filesystem permissions or anything else that might interfere with writing (e.g. free blocks/inodes) I'm not sure the grave severity is justified here. From what you've shown, this can only be a single line in the 50chrootname setup script failing. All the values set in the script are correct AFAICT, so it's most likely down to a filesystem issue or some other problem making that single echo statement fail. Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#679409: lightdm: Fails to start on boot, invoke-rc.d lightdm start fails
On Wed, Jul 11, 2012 at 02:06:52PM +1000, James Tocknell wrote: > On Mon, Jul 2, 2012 at 6:04 PM, Yves-Alexis Perez wrote: > > On lun., 2012-07-02 at 10:02 +0200, Petter Reinholdtsen wrote: > >> [Yves-Alexis Perez] > >> > James, in any case, I think providing /etc/init.d/.depend.* might > >> > help solving this. > >> > >> Actually, it is better to provide the output from > >> /usr/share/insserv/make-testsuite, which allow the boot sequence to be > >> reproduced using dummy init.d scripts. > >> > >> > Please keep me on CC: so I'm informed of the development. It might > >> > be interesting to provide /var/log/lightdm.log and > >> > /var/log/lightdm-gtk-greeeter.log, although the fact it works with > >> > startx might means it won't show anything. > >> > >> To debug this, try to disable concurrent booting (and keep dependency > >> based boot sequencing), and see if it work better. Also, it would be > >> useful to get the boot log (/var/log/boot.log) after enabling > >> bootlogd. lightdm uses the following dependencies: # Should-Start: console-screen kbd acpid dbus hal consolekit # Required-Start:$local_fs $remote_fs x11-common # Required-Stop: $local_fs $remote_fs gdm uses: # Should-Start: console-screen dbus network-manager # Required-Start:$local_fs $remote_fs # Required-Stop: $local_fs $remote_fs kdm uses: # Required-Start:$local_fs $remote_fs # Required-Stop: $local_fs $remote_fs # Should-Start: console-screen kbd acpid dbus hal krb5-kdc # Should-Stop: console-screen kbd While sysvinit has changed quite a few things since the last version which worked with lightdm, there's very little there to indicate anything which would affect lightdm. It's most likely that there's something wrong with the lightdm dependencies above. Please do see if there's something missing, or "should" rather than "required". Is the x11-common dependency needed? --why do gdm and kdm omit this? Are there any lightdm dependencies missing? I've installed lightdm on my system, and I do see the occasional failure to start. This would indicate some race in parallelisation which would be indicative of a missing dependency. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#672959: kfreebsd-*: panic: vm_fault_copy_wired
On Sun, Jul 22, 2012 at 02:06:11PM +0100, Roger Leigh wrote: > On Sat, Jul 21, 2012 at 11:47:24PM +0200, Carlos Alberto Lopez Perez wrote: > > On 21/07/12 23:32, Roger Leigh wrote: > > > Looking at the screenshot you attached, I can't see any obvious > > > reason for fsck to make the kernel panic. There's no indication > > > of odd scripts (other than geli) running in parallel here. This > > > really needs investigation from a kfreebsd person; I'm not > > > sufficiently knowledgeable to look into it myself. > > > > I guess this is reproducible by simply installing Debian/kFreeBSD AMD64 > > on a virtual machine and forcing and unclean shutdown (killing the qemu > > process when the virtual machine is running). > > I'm sure it is, but it needs someone with kfreebsd familiarity to > do this, and that's not me. I don't have the time or skills to fix > kfreebsd issues, but I can test, review and apply patches that any > kfreebsd people wish to provide. Hi debian-bsd people, This bug is still RC for wheezy. It really needs looking at by a kfreebsd expert, if someone could take a look at this. Given that this is only being experienced on kfreebsd, I would suggest starting with any kfreebsd-specific init scripts which could be running ahead of time if the dependencies aren't correct. Many thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683103: mkdir: cannot create directory `/run/shm': File exists
On Tue, Aug 07, 2012 at 09:18:39AM +0200, Vincent Danjean wrote: > I've just been hit by this bug in a schroot. > The host has initscripts 2.88dsf-28 installed. > When upgrading my sid schroot, I got the error: > mkdir: cannot create directory `/run/shm': File exists > dpkg: error processing initscripts (--configure): > > Looking at the situation on this system, I see: > atsina:/users/huron/danjean# mountpoint /dev > /dev is a mountpoint > atsina:/users/huron/danjean# mountpoint /dev/shm > mountpoint: /dev/shm: not a directory > atsina:/users/huron/danjean# ls -ld /dev/shm /run/shm > lrwxrwxrwx 1 root root 8 Jul 6 18:58 /dev/shm -> /run/shm > lrwxrwxrwx 1 root root 8 May 22 2011 /run/shm -> /dev/shm > > I do not know from where the circular symlink come from. > The schroot worked well (up-to-date) before I go to holidays, 3 weeks ago. I think vorlon's patch to improve the shm upgrade broke some particular cases. I've got a patch to fix it in progress. However, I do need to work out how to deal with all possible combinations of: /dev being a mountpoint /dev/shm being a mountpoint /run being a mountpoint /dev/shm being a symlink or directory /run/shm being a symlink or directory We need to take special care never to alter the bind mounted host environment, so as to not alter any state where a mountpoint is present. I should hopefully have time for this tonight. It's not such a combinatorial explosion as indicated above--if any mountpoints are present it restricts what we can do. So e.g. if /dev is a mountpoint and /dev/shm is a symlink, then /run/shm must be a directory since we can't alter the symlink. And vice versa if it's a directory, then /run/shm must be a symlink. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683103: mkdir: cannot create directory `/run/shm': File exists
On Sat, Jul 28, 2012 at 11:12:52PM +0100, Roger Leigh wrote: > On Sat, Jul 28, 2012 at 09:42:53PM +0200, Cyril Brulebois wrote: > > Package: initscripts > > Version: 2.88dsf-13.1+squeeze1 > > Severity: serious > > Justification: fails to upgrade > > > > Hi, > > > > during the sid chroot dist-upgrade on harris.debian.org, initscripts > > failed to upgrade due to: > > | Setting up initscripts (2.88dsf-29) ... > > | mkdir: cannot create directory `/run/shm': File exists > > | dpkg: error processing initscripts (--configure): > > | subprocess installed post-installation script returned error exit status > > 1 > > | Errors were encountered while processing: > > | initscripts > > | E: Sub-process /usr/bin/dpkg returned an error code (1) > > > > Not fun… > > Hmm, that's due to vorlon's recent change, I think. Is this inside > a chroot? If so, it's this logic failing: > > # Symlink /dev/shm from /run/shm > # Note that it's really /var/run/shm > if mountpoint -q /dev && mountpoint -q /dev/shm; then > compat_link /dev/shm /run/shm > else > [ -d /run/shm ] || mkdir -p /run/shm > mountpoint -q /dev || compat_link /run/shm /dev/shm > fi > > What is the output of > % ls -ld /dev /dev/shm /run /run/shm > on this system? Actually, just seen it myself, and I have: % ls -ld /dev /dev/shm /run /run/shm drwxr-xr-x 13 root root 3680 Jul 28 22:57 /dev lrwxrwxrwx 1 root root8 Jul 28 11:45 /dev/shm -> /run/shm drwxr-xr-x 21 root root 840 Jul 28 22:57 /run drwxrwxrwt 2 root root 40 Jul 28 11:45 /run/shm So that's all set up correctly. Unless my shell-fu is missing something tonight, I'm not sure what's causing the mkdir to be run here, given that the directory already exists. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683103: mkdir: cannot create directory `/run/shm': File exists
On Sat, Jul 28, 2012 at 09:42:53PM +0200, Cyril Brulebois wrote: > Package: initscripts > Version: 2.88dsf-13.1+squeeze1 > Severity: serious > Justification: fails to upgrade > > Hi, > > during the sid chroot dist-upgrade on harris.debian.org, initscripts > failed to upgrade due to: > | Setting up initscripts (2.88dsf-29) ... > | mkdir: cannot create directory `/run/shm': File exists > | dpkg: error processing initscripts (--configure): > | subprocess installed post-installation script returned error exit status 1 > | Errors were encountered while processing: > | initscripts > | E: Sub-process /usr/bin/dpkg returned an error code (1) > > Not fun… Hmm, that's due to vorlon's recent change, I think. Is this inside a chroot? If so, it's this logic failing: # Symlink /dev/shm from /run/shm # Note that it's really /var/run/shm if mountpoint -q /dev && mountpoint -q /dev/shm; then compat_link /dev/shm /run/shm else [ -d /run/shm ] || mkdir -p /run/shm mountpoint -q /dev || compat_link /run/shm /dev/shm fi What is the output of % ls -ld /dev /dev/shm /run /run/shm on this system? Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#672959: kfreebsd-*: panic: vm_fault_copy_wired
On Sat, Jul 21, 2012 at 11:47:24PM +0200, Carlos Alberto Lopez Perez wrote: > On 21/07/12 23:32, Roger Leigh wrote: > > Looking at the screenshot you attached, I can't see any obvious > > reason for fsck to make the kernel panic. There's no indication > > of odd scripts (other than geli) running in parallel here. This > > really needs investigation from a kfreebsd person; I'm not > > sufficiently knowledgeable to look into it myself. > > I guess this is reproducible by simply installing Debian/kFreeBSD AMD64 > on a virtual machine and forcing and unclean shutdown (killing the qemu > process when the virtual machine is running). I'm sure it is, but it needs someone with kfreebsd familiarity to do this, and that's not me. I don't have the time or skills to fix kfreebsd issues, but I can test, review and apply patches that any kfreebsd people wish to provide. Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#680861: aiccu: Breaks dist-upgrade if not correctly configured
On Fri, Jul 20, 2012 at 09:52:11AM +0200, Reinier Haasjes wrote: > On 7/5/2012 8:14 PM, Roger Leigh wrote: > > I have deliberately commented out some of the fields in aiccu.conf. > > This means that the service fails to start. > > However, this is not a reason to completely break > > apt-get upgrade|dist-upgrade. Please continue if "invoke-rc.d start" fails > > by using || true or a similar construct. > > This is not a aiccu-bug, it happens to other packages also. I borked the > sshd config and tried to upgrade: > > Personaly I think you shouldn't bork the config to not get the service > started but use something like: "update-rc.d disable aiccu" While this is true, aiccu causes problems due to its unique requirement that you must have a valid username/password etc. for your tunnel broker. ssh does not--by default it works without error, unless you take deliberate steps to break it. When I install aiccu, I might not yet have these details due to needing to sign up, or not having the details to hand. I don't think it's a reasonable expectation to require these. The other point is that if I don't have these details, then it's not worth starting up. There's a difference between a broken configuration and being unconfigured. If it's broken, then it's legitimate to fail on startup; if it's not yet been configured, then by all means print a warning, but please don't error out. > > Also, please don't ask debconf questions for the username and password, > > when these are trivially editable in the configuration file. It serves > > no purpose other than to annoy, because it interrupts upgrading by > > requiring interactive prompting. It's annoying because it's entirely > > unnecessary and wastes everyone's time. We have dpkg conffile > > handling to deal with configuration file updates; please don't add > > additional work on top of that. > > This will be handled in #680593. Thanks, that would be much appreciated. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#681876: [buildd-tools-devel] Bug#681876: Acknowledgement (dchroot: Bad upgrade path)
On Tue, Jul 17, 2012 at 03:35:37PM +0200, Kurt Roeckx wrote: > After actually trying this from a squeeze version, I end up with: > W: line 13 [i386-sid]: Deprecated key 'script-config' used > I: This option will be removed in the future; please update your configuration > W: line 10 [i386-sid]: Obsolete key 'priority' used These are expected: dchroot --config will create a configuration using the keys it knows about, which are deprecated in the new version. > I: This option has been removed, and no longer has any effect > E: Access not authorised > I: You do not have permission to access the schroot service. > I: This failure will be reported. This is, I think, due to the fact that dchroot (and dchroot-dsa) have different authentication/authorisation semantics than schroot. They override the authorisation logic used by schroot when using dchroot.conf (when using schroot.conf they use the schroot semantics); in 1.6 they always use the schroot.conf and hence the schroot semantics (the dchroot code having been removed). This is due to dchroot allowing all users to use the service by default, while schroot requires all users/groups allowed to use it to be specified in the configuration. The configuration that dchroot dumps is valid, but only when used with the dchroot authorisation/authentication semantics; it still requires the admin to manually edit to allow users to use the service. We can certainly dump the dchroot configuration to /etc/schroot/chroot.d/dchroot-XX in the preinst (so the old dchroot is used to dump). For the allowed users/groups, we can't currently represent dchroot behavour in the schroot.conf format (users/groups don't currently allow wildcards; I have a patch to allow regex matching, but this is not currently merged (it's on my wildcard-auth branch). So for the time being, we would have to document this and add to NEWS.Debian. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#680861: aiccu: Breaks dist-upgrade if not correctly configured
Package: aiccu Version: 20070115-15.1 Severity: serious Justification: Breaks upgrades Setting up aiccu (20070115-15.1) ... Files /usr/share/aiccu/conf-templates/aiccu.conf and /etc/aiccu.conf differ [FAIL] AICCU is not configured, edit /etc/aiccu.conf first ... failed! invoke-rc.d: initscript aiccu, action "start" failed. dpkg: error processing aiccu (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: aiccu E: Sub-process /usr/bin/dpkg returned an error code (1) I have deliberately commented out some of the fields in aiccu.conf. This means that the service fails to start. However, this is not a reason to completely break apt-get upgrade|dist-upgrade. Please continue if "invoke-rc.d start" fails by using || true or a similar construct. Also, please don't ask debconf questions for the username and password, when these are trivially editable in the configuration file. It serves no purpose other than to annoy, because it interrupts upgrading by requiring interactive prompting. It's annoying because it's entirely unnecessary and wastes everyone's time. We have dpkg conffile handling to deal with configuration file updates; please don't add additional work on top of that. Thanks, Roger -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (550, 'unstable'), (500, 'testing'), (400, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages aiccu depends on: ii debconf [debconf-2.0] 1.5.45 ii iproute20120521-3 ii iputils-ping 3:20101006-1+b1 ii iputils-tracepath 3:20101006-1+b1 ii libc6 2.13-34 ii libgnutls262.12.20-1 ii lsb-base 4.1+Debian7 ii ucf3.0025+nmu3 Versions of packages aiccu recommends: ii bind9-host 1:9.8.1.dfsg.P1-4.1 ii dnsutils1:9.8.1.dfsg.P1-4.1 ii ntp 1:4.2.6.p5+dfsg-2 aiccu suggests no packages. -- Configuration Files: /etc/aiccu.conf [Errno 13] Permission denied: u'/etc/aiccu.conf' -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#673676: [buildd-tools-devel] Bug#673676: sbuild-createchroot: broken due to debian-archive-keyring changes
On Wed, Jul 04, 2012 at 12:56:14PM +0200, Cyril Brulebois wrote: > found 673676 0.63.1-1 > severity 673676 serious > thanks > > Philipp Kern (20/05/2012): > > debian-archive-keyring does no longer include Debian archive keys in > > /etc/apt/trusted.gpg. sbuild-createchroot calls debootstrap > > specifying it explictly: > > > > I: Running debootstrap --arch=amd64 --variant=buildd --verbose > > --include=fakeroot,build-essential,debfoster --components=main > > --keyring=/etc/apt/trusted.gpg --resolve-deps sid /srv/chroots/sid-sbuild > > http://ftp.de.debian.org/debian/ > > > > debootstrap itself copes quite well without that setting. I'd suggest > > to only pass on --keyring if it got passed to the script itself. > > not being able to run sbuild-createchroot by default looks like a > serious bug in the sbuild package. Bumping severity accordingly. This was fixed in 4bc2072701ddd last week, and is pending upload. (Should already be tagged pending.) I have a few other bugs to fix in sbuild, but should be uploading it in the next week or so. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#679523: initscripts: 2.88dsf-28 version (unstable) creates issues with udev
On Mon, Jul 02, 2012 at 01:03:17PM +0200, Eloi COUTANT wrote: > Hi, > > Here is the result of the "ls -ld /run /var/run" command: > -- > lrwxrwxrwx 1 root root 8 oct. 25 2011 /run -> /var/run > drwxr-xr-x 21 root root 900 juil. 2 12:49 /var/run > -- Thanks. I fixed this issue in git yesterday, and it will be uploaded soon. In the interim, you may find fixed versions of the packages here: http://people.debian.org/~rleigh/sysvinit/ Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#671124: initscripts: Fails to update due to mountoverflowtmp
On Sun, Jun 24, 2012 at 06:39:25PM +0200, Petter Reinholdtsen wrote: > [Roger Leigh] > > Petter, maybe we should add that function back, doing just this single > > check? Since this affects all initscripts (despite it being very > > unusual to want to delete critical initscripts), we should probably > > do this for all scripts. > > The function was removed because it was not handling dependency based boot > sequencing, and I suspect it is better to work with the tools currently > available instead of trying to use the old function. How does the following look to you? (I only wanted to put the check for whether the script exists in the shell function, BTW, not to keep any of the old logic.) diff --git a/debian/bootlogd.postinst b/debian/bootlogd.postinst index 381fb69..d07cd8d 100644 --- a/debian/bootlogd.postinst +++ b/debian/bootlogd.postinst @@ -1,8 +1,14 @@ #!/bin/sh set -e -update-rc.d bootlogd start 05 S . >/dev/null || exit $? -update-rc.d stop-bootlogd-single start 99 S . >/dev/null || exit $? -update-rc.d stop-bootlogdstart 99 2 3 4 5 . >/dev/null || exit $? +if [ -x /etc/init.d/bootlogd ]; then +update-rc.d bootlogd start 05 S . >/dev/null || exit $? +fi +if [ -x /etc/init.d/stop-bootlogd-single ]; then +update-rc.d stop-bootlogd-single start 99 S . >/dev/null || exit $? +fi +if [ -x /etc/init.d/stop-bootlogd ]; then +update-rc.d stop-bootlogdstart 99 2 3 4 5 . >/dev/null || exit $? +fi #DEBHELPER# diff --git a/debian/initscripts.postinst b/debian/initscripts.postinst index 7235100..b6b319e 100755 --- a/debian/initscripts.postinst +++ b/debian/initscripts.postinst @@ -150,34 +150,83 @@ fi # # Links in runlevel S # +if [ -x /etc/init.d/mountkernfs.sh ]; then update-rc.d mountkernfs.sh start 02 S . >/dev/null || exit $? +fi +if [ -x /etc/init.d/hostname.sh ]; then update-rc.d hostname.shstart 02 S . >/dev/null || exit $? +fi +if [ -x /etc/init.d/mountdevsubfs.sh ]; then update-rc.d mountdevsubfs.sh start 04 S . >/dev/null || exit $? +fi +if [ -x /etc/init.d/checkroot.sh ]; then update-rc.d checkroot.sh start 10 S . >/dev/null || exit $? +fi +if [ -x /etc/init.d/mtab.sh ]; then update-rc.d mtab.shstart 12 S . >/dev/null || exit $? +fi +if [ -x /etc/init.d/checkroot-bootclean.sh ]; then update-rc.d checkroot-bootclean.sh start 13 S . >/dev/null || exit $? +fi +if [ -x /etc/init.d/checkfs.sh ]; then update-rc.d checkfs.sh start 30 S . >/dev/null || exit $? +fi +if [ -x /etc/init.d/mountall.sh ]; then update-rc.d mountall.shstart 35 S . >/dev/null || exit $? +fi +if [ -x /etc/init.d/mountall-bootclean.sh ]; then update-rc.d mountall-bootclean.sh start 36 S . >/dev/null || exit $? +fi +if [ -x /etc/init.d/mountnfs.sh ]; then update-rc.d mountnfs.shstart 45 S . >/dev/null || exit $? +fi +if [ -x /etc/init.d/mountnfs-bootclean.sh ]; then update-rc.d mountnfs-bootclean.sh start 46 S . >/dev/null || exit $? +fi +if [ -x /etc/init.d/bootmisc.sh ]; then update-rc.d bootmisc.shstart 55 S . >/dev/null || exit $? +fi +if [ -x /etc/init.d/urandom ]; then update-rc.d urandomstart 55 S . start 30 0 6 . >/dev/null || exit $? +fi + # # Links in runlevels other than S # +if [ -x /etc/init.d/halt ]; then update-rc.d halt start 90 0 . >/dev/null || exit $? +fi +if [ -x /etc/init.d/reboot ]; then update-rc.d reboot start 90 6 . >/dev/null || exit $? +fi +if [ -x /etc/init.d/umountroot ]; then update-rc.d umountroot start 60 0 6 . >/dev/null || exit $? +fi +if [ -x /etc/init.d/umountfs ]; then update-rc.d umountfs start 40 0 6 . >/dev/null || exit $? +fi +if [ -x /etc/init.d/umountnfs.sh ]; then update-rc.d umountnfs.sh start 31 0 6 . >/dev/null || exit $? +fi +if [ -x /etc/init.d/sendsigs ]; then update-rc.d sendsigs start 20 0 6 . >/dev/null || exit $? +fi +if [ -x /etc/init.d/killprocs ]; then update-rc.d killprocs start 30 1 . >/dev/null || exit $? +fi +if [ -x /etc/init.d/single ]; then update-rc.d single start 90 1 . >/dev/null || exit $? +fi +if [ -x /etc/init.d/motd ]; then update-rc.d motd start 70 1 2 3 4 5 . >/dev/null || exit $? +fi +if [ -x /etc/init.d/rc.local ]; then update-rc.d rc.local start 99 2 3 4 5 . >/dev/null || exit $? +fi +if [ -x /etc/init.d/rmnologin ]; then update-rc.d rmnologin start 99 2 3 4 5 . >/dev/null || exit $? +fi # # Remove scripts that were left behind by older glibc (<< 2.3.2.ds1-12) -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG
Bug#671124: initscripts: Fails to update due to mountoverflowtmp
On Sun, Jun 24, 2012 at 03:09:12AM +0200, Cyril Brulebois wrote: > severity 671124 serious > tag 671124 - moreinfo > thanks > > Roger Leigh (05/06/2012): > > I have not had any other reports of this, and I can't reproduce it > > myself. As I stated above, this file and maintainer scripts > > pertaining to it were not changed for several years, so in the > > absence of further information or being able to reproduce, I can't > > really do much more with this at the present. I'm downgrading the > > severity for the time being--if this is a reproducible bug, it's > > already in stable and testing. > > That's trivially reproducible. > > Install squeeze, rm /etc/init.d/mountoverflowtmp, replace squeeze with > wheezy in sources.list, apt-get update, apt-get dist-ugprade. > > Hint: the postinst's being set -e, and your calling update-rc.d > unconditionally on scripts that can go away (they're conffiles) is > probably a bad idea. Thanks. This begins to make sense, though it is not by any means a new bug (it's most likely been present since 4b9dd323 in 2009 which removed the updatercd shell function, which skipped running update-rc.d if the script wasn't present). Petter, maybe we should add that function back, doing just this single check? Since this affects all initscripts (despite it being very unusual to want to delete critical initscripts), we should probably do this for all scripts. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#669949: (no subject)
On Sat, Jun 09, 2012 at 07:34:14PM +0200, Luca wrote: > Hi Everyone, > I red the problem began on April. In my case that happened just two days > ago, even if I upgrade my sid on regular basis. > > I do not have a separate /var or /run partion, just the root one and /home. > > Removing symlink /run -> /var/run and creating a new /run DIRECTORY (not > symlink) works. > > I am wondering how many PCs will have this serious problem Did you create the /run symlink sometime in the past? Or was it created automatically? Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#676463: me too and more info
On Fri, Jun 08, 2012 at 02:16:58PM -0600, Gordon Haverland wrote: > I have the same packages triggering init script warnings. > > In addition, I get a warning from insserv files about K20scsi-idle > and scsi-idle missing LSB tags and overrides. Could you possibly attach a copy of each failing script? Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#676669: initscripts - Fails to install
tags 676669 + pending thanks On Fri, Jun 08, 2012 at 07:18:27PM +0200, Bastian Blank wrote: > The initscripts package fails to upgrade without error message: > The functions ram_size and swap_size in /lib/init/tmpfs.sh checks for the > existance of /proc/meminfo, but fails to handle errors. Adding "|| :" helps. Thanks, fixed in git. Out if interest, why was /proc/meminfo not available? -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#676560: mysql-5.5: Serious system breakage as a result of using /run
severity 676560 critical thanks (It breaks upgrading of the entire system.) On Thu, Jun 07, 2012 at 07:40:29PM +0100, Roger Leigh wrote: > You have two options: > 1) Revert to using /var/run > 2) Add a versioned dependency as described in the above reference > > This does not include working out how to undo the damage you have > caused, if this is safe or possible. You must additionally make sure that you do not provide the /run directory in your package, or create it. Both these actions will break squeeze upgrades. Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#669949: sysvinit: Break X11: no more mouse and keyboard
On Thu, Jun 07, 2012 at 10:45:44PM +0200, Jakub Moc wrote: > Definitely caused by /run -> /var/run symlink here. After getting rid > of that and creating /run dir in /, I have my keyboard, mouse and > sound back. Extremely weird bug, also only got this recently, been > running unstable for quite a while on LMDE. Thanks all for investigating. It looks like we need to cater for the directory and symlink being the wrong way around, and to rectify that if possible. Other than for chroots, where we don't have a choice, and no means to effectively upgrade to the correct configuration, this has never been an officially supported configuration. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#676560: mysql-5.5: Serious system breakage as a result of using /run
Package: mysql-5.5 Version: 5.5.23-2 Severity: serious Justification: Breaks /run transition > ql-5.5 (5.5.23-2) unstable; urgency=low > > * Changed /var/run to /run as required by Debian Policy 3.9.3 (9.1.1) No, it's not required by policy. /var/run continues to exist, and you should continue to use it. The new directory is available, but that does not mean you should use it blindly. Please **carefully** read http://wiki.debian.org/ReleaseGoals/RunDirectory You've broken the /run transition. You **can not use /run without a versioned initscripts dependency**. Without it, /run does not exist, and you certainly shouldn't be creating it yourself. You have two options: 1) Revert to using /var/run 2) Add a versioned dependency as described in the above reference This does not include working out how to undo the damage you have caused, if this is safe or possible. Regards, Roger -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (550, 'unstable'), (500, 'testing'), (400, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#676520: [sysv-rc] System unsuitable for dep-based boot cannot configure
On Thu, Jun 07, 2012 at 05:34:33PM +0300, David Baron wrote: > I have an older init scripted system which will not configure for dep-based > boot due to man missing lsb tags and overrides (what can I do about this?). >From NEWS.Debian: +sysv-rc (2.88dsf-23) experimental; urgency=low + + Dependency based boot ordering is now required. + + Most systems will already be using dependency based boot ordering. + This includes all squeeze and later releases, unless you have taken + deliberate action to disable it. Installations upgraded from etch, + lenny or earlier releases will have enabled dependency based booting + when upgrading to squeeze and later releases. However, it was + previously possible to opt out of migrating to dependency based + booting and retain static boot ordering. This is no longer the case. + + If your system is still using static boot ordering, migrating to + dependency based boot ordering will be performed when sysv-rc is + configured. If this is not possible for any reason, you will have to + correct the problem before upgrading can continue. It will not be + possible to complete the upgrade until insserv is configured. + + The most commonly encountered problem preventing migration is the + presence of obsolete init scripts from removed (but unpurged) + packages. If this is the case, you will be prompted with + instructions detailing how to purge these old packages. + + If you have custom init scripts, please ensure that these have the + correct dependency information in an LSB header so that they will be + run at the correct point in the boot sequence. + + -- Roger Leigh Wed, 18 Apr 2012 23:30:37 +0100 > Additonally, as per bug #676463, there are numerous complaints about init > scripts for removed applications and some that are not removed! These are, as said above, obsolete init scripts from removed (but not purged) conffiles. They lack LSB headers, and the packages need purging to remove them. > In the past, sysv-rc would configure for the old boot correctly and upgrades > went merrily on their way. Now, it gives an error return. > > Sysv-rc is left unconfigured and NO other apt operations are possible! This is intentional. Previously, you had the option to either enable dynamic dependency-based ordering, or stick with static legacy ordering. We now require dependency-based ordering, and static is no longer supported. So we can't continue until you've fixed the system by removing the broken scripts. We haven't really changed the logic of the scripts here--we've just removed the choice of retaining the legacy ordering. For the next upload, I need to see if we can just enable it unconditionally, irrespective of whether the broken scripts are present or not. If you can possibly mail me a copy of all the broken scripts it identified, I'll test that possibility. It will make the transition much smoother. Note that this only affects upgrades from older releases which lacked LSB init scripts. The reason for doing this is because the static ordering is bitrotting, and is no longer being actively tested since we are all now using dynamic ordering. Rather than have systems start to break as the ordering becomes progressively wrong, this will ensure all systems will use a single correct ordering. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#671124: initscripts: Fails to update due to mountoverflowtmp
severity 671124 important tags 671124 + moreinfo thanks On Tue, May 08, 2012 at 10:49:06PM +0100, Roger Leigh wrote: > On Wed, May 02, 2012 at 01:15:42AM +0200, Cyril Brulebois wrote: > > Preparing to replace initscripts 2.88dsf-22 (using > > .../initscripts_2.88dsf-22.1_amd64.deb) ... > > Unpacking replacement initscripts ... > > Processing triggers for man-db ... > > Setting up initscripts (2.88dsf-22.1) ... > > update-rc.d: error: unable to read /etc/init.d/mountoverflowtmp > > dpkg: error processing initscripts (--configure): > > subprocess installed post-installation script returned error exit status 1 > > This is quite odd, because there were no changes to mountoverflowtmp > between 2.88dsf-22 and 2.88dsf-22.1. It was an NMU of debconf > template translations only, and there were no changes to > mountoverflowtmp for a long time (years) prior to this. >[...] > I've not received any other reports of this problem to date, and > I can't yet reproduce the problem on my own systems--I never had > any problem with the 22.1 upgrade, and the -23 and -24 upgrades > from experimental have never caused any upgrade problems on my > test systems either. Hi, I have not had any other reports of this, and I can't reproduce it myself. As I stated above, this file and maintainer scripts pertaining to it were not changed for several years, so in the absence of further information or being able to reproduce, I can't really do much more with this at the present. I'm downgrading the severity for the time being--if this is a reproducible bug, it's already in stable and testing. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org