Bug#463223: initramfs-tools: missing dependency on mktemp? Fails to configure without it
maximilian attems wrote: > severity 463223 normal > stop > > On Wed, Jan 30, 2008 at 12:27:37PM +0100, Lionel Elie Mamane wrote: >> Package: initramfs-tools >> Version: 0.91d >> Severity: serious >> Justification: Policy 3.5 >> >> On update/upgrade of a sid machine today, initramfs-tools failed to >> configure, because it tries to use mktemp, while it was not installed >> on that machine. > > apt-cache show mktemp | egrep '^(Essential|Priority)' > Essential: yes > Priority: required > > >> If it needs it, it must depend on it. > > your install is broken, fix it. Any reason why the bug was not closed? Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#470872: found 470872 in 2.6.22-6
# Automatically generated email from bts, devscripts version 2.10.19 # lebrun probably had 2.6.22-6 end of november found 470872 2.6.22-6 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343970: Intention to NMU apt-file
Hi
Attached the patch for the version I intend to upload. Please respond if
you don't want this NMU to happen, if you are working yourself on a
patch or if you think that the attached patch won't work.
Cheers
Luk
--
Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D
Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D
diff -Nru /tmp/WqwB0ysiLe/apt-file-2.0.6/debian/changelog
/tmp/j7thGpmPgO/apt-file-2.0.6/debian/changelog
--- /tmp/WqwB0ysiLe/apt-file-2.0.6/debian/changelog 2005-05-09
15:06:24.0 +0200
+++ /tmp/j7thGpmPgO/apt-file-2.0.6/debian/changelog 2006-01-12
16:52:55.0 +0100
@@ -1,3 +1,11 @@
+apt-file (2.0.6-0.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Depend on curl or wget to make package usable
+(Closes: #307833, #311329, #343970, #324153, #325102).
+
+ -- Luk Claes <[EMAIL PROTECTED]> Thu, 12 Jan 2006 16:46:10 +0100
+
apt-file (2.0.6) unstable; urgency=low
* Now ftp method works (Closes: #307971, #307973)
diff -Nru /tmp/WqwB0ysiLe/apt-file-2.0.6/debian/control
/tmp/j7thGpmPgO/apt-file-2.0.6/debian/control
--- /tmp/WqwB0ysiLe/apt-file-2.0.6/debian/control 2005-05-05
18:06:48.0 +0200
+++ /tmp/j7thGpmPgO/apt-file-2.0.6/debian/control 2006-01-12
16:46:01.0 +0100
@@ -7,8 +7,7 @@
Package: apt-file
Architecture: all
-Depends: ${perl:Depends}, gzip (>= 1.2.4), libconfigfile-perl, libapt-pkg-perl
-Recommends: curl, wget
+Depends: ${perl:Depends}, gzip (>= 1.2.4), libconfigfile-perl,
libapt-pkg-perl, curl | wget
Suggests: ssh
Description: APT package searching utility -- command-line interface
apt-file is a command line tool for searching packages for the APT
signature.asc
Description: OpenPGP digital signature
Bug#404503: Wrong characters typed using dead keys
tags 404503 +patch thanks Hi Attached an easy patch regarding this issue, improvements are very welcome as I know I can be quite dense... Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D Index: release-notes.en.sgml === RCS file: /cvs/debian-doc/ddp/manuals.sgml/release-notes/en/release-notes.en.sgml,v retrieving revision 1.175 diff -u -r1.175 release-notes.en.sgml --- release-notes.en.sgml 27 Mar 2007 12:08:33 - 1.175 +++ release-notes.en.sgml 27 Mar 2007 18:56:28 - @@ -1805,6 +1805,17 @@ ]]> + Wrong characters typed using dead keys + + Typing accented characters using dead keys doesn't work for non-latin1 + characters if one uses an utf8 locale. + + + An obvious temporary workaround is not using an 8-bit locale... + + + +]]> signature.asc Description: OpenPGP digital signature
Bug#387331: Uninstallable due to unmet dep on kernel-image-2.4.27-3-686-smp
Package: kernel-image-2.4-686-smp Severity: serious Version: 101sarge1 Hi Your package is not installable as it depends on kernel-image-2.4.27-3-686-smp which is not available in unstable anymore. Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Bug#400097: missing /dev/fb0 makes usplash fail
Steve Langasek wrote: > On Fri, Nov 24, 2006 at 10:56:13AM -0200, Otavio Salvador wrote: > >>>> It's not usplash trouble but initramfs problem. What version of your >>>> initramfs-tools package? I sent a patch that were include on last >>>> upload to solve it. > >>> the one in etch 0.85a >>> i noticed a more recent version in sid. So i have upgraded to that and >>> it seams to solve the problem. > >>> http://bjorn.haxx.se/debian/testing.pl?package=initramfs-tools >>> it could perhaps be hinted into etch ? it's long overdue the 5 day >>> waiting period. > >> I'm closing this bug then. > >> Please RM team, add a hint to initramfs-tools to enters etch since it >> has some nice and simple fixes like this one for FrameBuffer dealing. > > Apparently Luk did this without following up to the list. :) I did this before it was mentioned on the list as the maintainer had asked me already on IRC. .. Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Bug#440808: Upgrade dependency to the new kernel
David wrote: Package: linux-image-686 Version: 2.6.22+9 Severity: serious --- Please enter the report below this line. --- linux-image 2.6.22+9 has been removed from sid, so the dependency is broken. I guess you mean linux-image-2.6.22-1-686 has been removed and the dependency of linux-image-2.6-686 is now broken? Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [stable] kernel upload to p-u
dann frazier wrote: hey, I think we're nearly ready for a kernel upload to proposed-updates. Here's the current list of changes queued for a stable upload. Can you please consider fixing #317258 again? It's only about PCI ID mappings that got lost while splitting the megaraid and megaraid_mbox drivers. At one point this bug got fixed, but it was reverted later on, no idea why? A lot of the Debian machines at my work use these NetRAID cards and it's silly to have to keep repeating that it will be fixed in some undefined future while the fix is small and harmless... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [stable] kernel upload to p-u
Bastian Blank wrote: On Tue, Sep 11, 2007 at 11:20:35AM +0200, Luk Claes wrote: Can you please consider fixing #317258 again? It's only about PCI ID mappings that got lost while splitting the megaraid and megaraid_mbox drivers. At one point this bug got fixed, but it was reverted later on, no idea why? No part of this patch is in linux upstream. The relevant code sections was not changed since .12. Please fix it there if it is a problem. We don't carry any megaraid patches. Not anymore and no I'm not going to do your job as a maintainer by fixing it upstream... Any reason why you don't mention anything about not cooperating with upstream about this in the bugreport? Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [stable] kernel upload to p-u
Frederik Schueler wrote: Hello, Hi I think we should add patches to update the forcedeth and e1000 drivers to the latest version, too. Those are many changes, but also many new boxes require those new drivers: obviously most nvidia based athlon and opteron boards, and many xeon board (supermicro, tyan). What is the chance to get these drivers, backported from 2.6.22 or .23 into stable? I know we most fear regressions here, how extensive must the tests be to "get it in"? I would think the chance is rather big to include it in the etch and a half kernel... Up to now we were only talking about regressions... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#437344: seemingly random SATA disk lockup with ICH5: amazing way to ask for more info on the BTS
Mathieu Roy wrote: Package: linux-image-2.6.21-2-686 Version: 2.6.21-6 Severity: important stopped reading at that point, there is newer linux images in the archive install them directly from unstable. The version specified is the version in testing... Amazing. Tell me, are your trying to turn debian support/BTS into a joke? If one need to run the brand new latest über-unstable version of the kernel to have a chance to get his bug report *read*, why do even reportbug accept to submit bugs reports against older versions? I guess there is a misunderstanding. Probably he thought you were using an outdated version in unstable... I find really astonishing to get such reply to a bug report about a not so trivial bug in a not so trivial piece of software while running Debian GNU/Linux. Indeed, if you are not even polite enough to read more than 3 words in a bug report, clearly you do not need/deserve more help to improve Debian. Do not expect "more info" any time soon. Please calm down. I can understand your frustration, but please don't overreact to a possible misunderstanding. CCed to debian-devel because I'm wondering if this way of handling bug reports (not reading more than 3 words of the reports and then asking for more info and asking to install unstable software) is endorsed by debian developers nowadays. Well for packages with many changes and many users it's not always easy to debug every single problem. So sometimes it's a great help if bug submitters test if the problem still occurs in the latest version... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Meeting for etch and a half
dann frazier wrote: > (sorry for the nasty cross-posting) > > hey, > Now that 2.6.23 is out and the proposed timeframe for etch 1/2 is > just over two months away, its probably a good time to start making > some progress on an etch 1/2. Yes, I think it's a good time to start the discussion. > Perhaps we should start with an IRC meeting? I've created a wiki page > here with an initial stab at an agenda, starting with "Is it still a > good idea?": > http://wiki.debian.org/EtchAndAHalf > > If we have consensus is to proceed, then I'd like to see if we can > come up with a list of next steps. I'll be travelling Thur->Monday of > this week, so Wednesday is the only day I can do this week, but next > week is pretty open. If you're interested in attending, please mark > available times here: > http://www.doodle.ch/wa4r43rq55uif8rf People that are interested, please mark the times your available so the meeting can be scheduled... Dann: you don't seem to be listed? :-) Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [stable] firmware-nonfree update for etchnhalf
dann frazier wrote: > I'd like to propose the following update for stable. > > I've tested on an etch laptop w/ built-in intel 3945 wireless and a > server w/ a bnx2 nic under both etch and etchnhalf. Please upload. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny
Otavio Salvador wrote: > Martin Michlmayr <[EMAIL PROTECTED]> writes: > >> * Frans Pop <[EMAIL PROTECTED]> [2008-07-07 17:30]: >>> In fact, having 2.6.25 in testing would possibly make it easier for >>> the kernel team to do a final (?) 2.6.25 upload with latest stable >>> updates. >> FWIW, I fully agree. In the past, we never waited for all arches in >> d-i to move to a new kernel udebs before allowing the deb of that >> version to move to testing. In fact, not having 2.6.25 in testing now >> that some arches have updated d-i to 2.6.25 _hurts_ our testing >> efforts. Some Orion devices work perfectly fine in d-i now that we've >> moved to 2.6.25, but installations fail because no kernel is in >> testing... which means people cannot test it. > >> So, please migrate the 2.6.25 debs to testing. > > No objection in allowing 2.6.25 to go to testing but please hold on > about uploading 2.6.26 until RM team acks on it. hint added. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#490190: linux-modules-contrib-2.6: FTBFS on mipsel: This needs the I2C Bit Banging interface in your kernel
Package: linux-modules-contrib-2.6 Version: 2.6.25-2 Severity: serious Hi Your package FTBFS on mipsel with the following error. Build logs can be found on buildd.d.o as usual. CC [M] /build/buildd/linux-modules-contrib-2.6-2.6.25/debian/build/build_mipsel_none_r5k-cobalt_em8300/em8300_main.o /build/buildd/linux-modules-contrib-2.6-2.6.25/debian/build/build_mipsel_none_r5k-cobalt_em8300/em8300_main.c:68:2: error: #error "This needs the I2C Bit Banging Interface in your Kernel" /build/buildd/linux-modules-contrib-2.6-2.6.25/debian/build/build_mipsel_none_r5k-cobalt_em8300/em8300_main.c: In function 'em8300_io_mmap': /build/buildd/linux-modules-contrib-2.6-2.6.25/debian/build/build_mipsel_none_r5k-cobalt_em8300/em8300_main.c:352: warning: passing argument 1 of 'virt_to_phys' makes pointer from integer without a cast /build/buildd/linux-modules-contrib-2.6-2.6.25/debian/build/build_mipsel_none_r5k-cobalt_em8300/em8300_main.c: In function 'em8300_io_release': /build/buildd/linux-modules-contrib-2.6-2.6.25/debian/build/build_mipsel_none_r5k-cobalt_em8300/em8300_main.c:477: warning: passing argument 1 of 'virt_to_phys' makes pointer from integer without a cast make[4]: *** [/build/buildd/linux-modules-contrib-2.6-2.6.25/debian/build/build_mipsel_none_r5k-cobalt_em8300/em8300_main.o] Error 1 make[3]: *** [_module_/build/buildd/linux-modules-contrib-2.6-2.6.25/debian/build/build_mipsel_none_r5k-cobalt_em8300] Error 2 make[3]: Leaving directory `/usr/src/linux-headers-2.6.25-2-r5k-cobalt' make[2]: *** [debian/stamps/build_mipsel_none_r5k-cobalt_em8300] Error 2 make[2]: Leaving directory `/build/buildd/linux-modules-contrib-2.6-2.6.25' make[1]: *** [build_mipsel_none_r5k-cobalt_em8300] Error 2 make[1]: Leaving directory `/build/buildd/linux-modules-contrib-2.6-2.6.25' make: *** [debian/stamps/build-base] Error 2 dpkg-buildpackage: failure: debian/rules build gave error exit status 2 Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linux-modules-nonfree-2.6 binNMU
Daniel Baumann wrote: > Adeodato Simó wrote: >> Is it i386 only? > > since 'XS-Autobuild: yes' in control is not evaluated, yes. You do have to send a request to [EMAIL PROTECTED] to get that changed as was announced on d-d-a which made you put that field in the first place... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: user-mode-linux 2.6.25 [was Re: imminent 2.6.26 sid upload]
Mattia Dongili wrote: > [d-boot probably not interested in this subtopic] > > On Tue, Jul 22, 2008 at 11:48:20PM +0200, maximilian attems wrote: >> latest 2.6.25 stable release is in testing, we expect to keep it as backup >> plan for lenny. release team wishes to have unstable coverage of 2.6.26 >> before final ack on that release. > PS: once uml 2.6.25 is in testing I'll be able to upload 2.6.26 to stay > in sync with the current kernel sources. uml 2.6.25 has migrated to testing in the meantime btw. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#494120: binary firmware in drivers/media/dvb/frontends/tda10021.c
Robert Millan wrote:
On Thu, Aug 07, 2008 at 09:34:31AM -0700, Steve Langasek wrote:
drivers/media/dvb/frontends/tda10021.c (licensed under GPLv2+) contains a
small chunk of binary code:
static u8 tda10021_inittab[0x40]=
{
0x73, 0x6a, 0x23, 0x0a, 0x02, 0x37, 0x77, 0x1a,
0x37, 0x6a, 0x17, 0x8a, 0x1e, 0x86, 0x43, 0x40,
[...]
Since the licensing terms allow redistribution, shipping it is not illegal but
is a DFSG violation.
By "small chunk", you mean 64 bytes of data. That's not a program; that's
almost certainly register initialization values, which are data, and there
is no requirement in the DFSG that arbitrary bits of data (which are too
short and lacking in originality to be covered by copyright anyway) be
distributed in a textual source form.
Hi Steve
You might have a point here; the root of the problem seems to be the definition
of "source code", and the DFSG doesn't resolve this ambiguity. Some think
"source code" is the preferred form of modification for any form of data, some
think it only applies to certain types of data, etc. And then even "preferred"
doesn't mean the same to everyone!
Overall, it sounds like a gray area to me. Has this been discussed in -legal?
It may be a gray area, but normally we expect people to make sane
judgements...
Feel free to discuss this in -legal, though that doesn't change the fact
that we currently don't expect textual source for arbitrary bits of data.
You need to find yourself a more appropriate way to express your concerns
about such files
Well, I usually express that I found a bug (or in some -rare!- cases, that I
mistakenly think I found one) by filing it to the BTS.
Ah I expect noone is perfect, but you're close to be an exception?
than by unilaterally declaring them to be release-critical
bugs.
As usual, my assesment of severities is "best-effort". If a severity is
wrong, we can surely discuss it!
It was not only about the severity, but also about it being a bug...
Do you mind if I reopen with non-RC severity, untill my question above has
been clarified?
No, we don't want to wait till you clarify your question...
Cheers
Luk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Scheduling linux-2.6 2.6.26-3
Micah Anderson wrote: > Hi release team, > > I'm writing to request that a hint be added to allow util-vserver > 0.30.216~r2772-1 to enter testing. As discussed on debian-kernel, this > version of the util-vserver user-space utilities is necessary in order > to work with the kernel targetted for lenny, and so I am requesting a > release exception to sync these up: unblocked set age-days to 10 Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linux-2.6 upload planned
Otavio Salvador wrote: > dann frazier writes: > >> hey, >> I wanted to give -release & -boot a heads up that the kernel team is >> looking to do a linux-2.6 upload to sid tomorrow. As discussed on the >> d-i channel, delays in the d-i release have given us a short window to >> introduce a new build for inclusion in RC2. > >> Changes pending for this update include: >> - a few local DoS security issues >> - the hppa kernel fix that was causing crashes during ruby >> builds (doesn't fix the FTBFS - that may be a userspace issue) >> - reintroduces a driver for the ia64 rtc (regression) >> - several other fixes of >= important severity from Moritz's recent >> bug triage > > Please go ahead. unblocked Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Breaking X.Org on sparc (was: Bug#514418: [FIX]: ultra45 boot failing...)
Bastian Blank wrote: > Hi > > We introduced a workaround by reverting a removal in the kernel to allow > the current X.Org on sparc work. However this patch is not supportable > and breaks all newer machines quite badly. > > This means that we have to back it out again and the only question is if > we will do that for r0 or r1. I think it's best to delay that to r1. Can someone please provide a text for the release notes to describe the problem, TIA? Cheers Luk > - Forwarded message from Bastian Blank - > > Package: linux-2.6 > Version: 2.6.26-13 > Severity: grave > > I consider this RC. We'll break X.org either for r0 or r1. > > debian-sparc: Please provide someone who wants to take over sparc > architecture maintenance of the Linux packages. > > On Sat, Feb 07, 2009 at 10:45:31AM +, Jurij Smakov wrote: >> On Fri, Feb 06, 2009 at 11:11:44PM -0800, David Miller wrote: >>> The patch: >>> >>> debian/patches/bugfix/sparc/arch_pci_hostcontroller_workaround.patch >>> >>> causes ultra45 (and other PCI-Express based workstations) to >>> hard reset when the PCI bus is initially scanned by the kernel. >>> >>> Please revert this patch from the debian kernel in Lenny and >>> anywhere else it appears. >>> >>> The code in that patch creating dummy PCI root host controller nodes >>> is wrong and does nothing other than cause trouble. If it fixes some >>> problem with the X server for PCI devices on sparc64 that problem >>> needs to be fixed some other way. >>> >>> Thank you. >> I believe that we are just a few days from Lenny release, so uploading >> a new kernel and rebuilding debian-installer might not be an option >> at this point, unfortunately. The best we can probably do is include >> the fixed kernel in the point release, but that's up to kernel team >> to decide. > > - End forwarded message - > -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#517260: Do Debian Policy 3.5 not apply to unstable?!?
Jonas Smedegaard wrote: > Please reopen this bug. > > Debian Policy 3.5 mandates correct package dependencies. > > Debian Policy also applies to Debian unstable too. > > The "unstable" refer to the collection of packages - each individual > package released to "unstable" should itself be non-broken. It's not broken, it's common to have some things that are out of sync in unstable... Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#516746: open-iscsi: fails to use kernel IP configuration parameter
Hi Can you please upload a fix for this bug to stable, TIA? Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#529070: FTBFS on sparc: cannot stat `debian/build/build_sparc_none_sparc64/arch/sparc/boot/zImage': No such file or directory
Package: linux-2.6 Version: 2.6.29-4 Severity: serious Hi linux-2.6 fails to build on the sparc autobuilder (schroeder) with the following error: dh_installdirs 'boot' /usr/bin/make -f debian/rules.real COMPILER=gcc-4.3 ARCH=sparc LOCALVERSION=-sparc64 TYPE=plain ABINAME=-2 INITRD_CMD=update-initramfs\ mkinitrd.yaird KERNEL_HEADER_DIRS=sparc VERSION=2.6.29 FEATURESET=none SOURCEVERSION=2.6.29-4 LIBC_DEV_ARCH=sparc MODULES=True UPSTREAMVERSION=2.6.29 KERNEL_ARCH=sparc LOCALVERSION_HEADERS= KCONFIG=debian/config/config\ debian/config/sparc/config\ debian/config/sparc/config.sparc64 FLAVOUR=sparc64 LOCALVERSION_IMAGE=-sparc64 MAJOR=2.6 \ install-image_sparc_none_sparc64_plain_image \ DIR='debian/build/build_sparc_none_sparc64' PACKAGE_DIR='debian/linux-image-2.6.29-2-sparc64' INSTALL_DIR='debian/linux-image-2.6.29-2-sparc64/boot' REAL_VERSION='2.6.29-2-sparc64' failed to open configuration file `/home/buildd/.dpkg.cfg' for reading: Permission denied failed to open configuration file `/home/buildd/.dpkg.cfg' for reading: Permission denied failed to open configuration file `/home/buildd/.dpkg.cfg' for reading: Permission denied make[3]: Entering directory `/build/buildd/linux-2.6-2.6.29' install -m644 'debian/build/build_sparc_none_sparc64/arch/sparc/boot/zImage' debian/linux-image-2.6.29-2-sparc64/boot/vmlinuz-2.6.29-2-sparc64 install: cannot stat `debian/build/build_sparc_none_sparc64/arch/sparc/boot/zImage': No such file or directory make[3]: *** [install-image_sparc_none_sparc64_plain_image] Error 1 make[3]: Leaving directory `/build/buildd/linux-2.6-2.6.29' The full build log can be found at [1]. Cheers Luk [1] https://buildd.debian.org/fetch.cgi?pkg=linux-2.6&arch=sparc&ver=2.6.29-4&stamp=1241387254&file=log&as=raw -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Update of Linux 2.6.30?
Ben Hutchings wrote: > Although Linux 2.6.31 has been released, it has a number of known > regressions and I think we will wait for 2.6.31.1 before uploading to > unstable. Most of the kernel team will be meeting in Portland from > 22-26 September and I would expect the first upload to be done after > that. > > In the mean time, 2.6.30 has had more stable updates, and there are many > other bugs with patches available (the most important being #541307). I > propose that we should make another upload of 2.6.30, although this will > change the kernel ABI. Looks like a sane plan to me. Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Coordinating efforts to get a new kernel in testing?
Christian Perrier wrote: > During the last meeting of the D-I 'team' (ahem) which logs can be read > from http://wiki.debian.org/DebianInstaller/Meetings, the situation > of the kernel packages wrt testing transition was raised. > > Apparently, having a new kernel in testing (whether this is 2.6.30 or > whatever other funky new version appears soon is not really relevant) > is quite hairy. It needs quite some work to get reverse dependencies handled and getting it built on all architectures. Both of which are the main responsability of the kernel team... > Could this be prioritized by the involved teams (mostly kernel and > release, I'd guess) or are there already some plans for this to > happen? There are no plans to force anything in like some propose in such situations as there is no clear plan of the kernel team to get the remaining issues solved soon after it would be forced in. Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Coordinating efforts to get a new kernel in testing?
maximilian attems wrote: > On Sat, Jul 11, 2009 at 01:08:05PM +0200, Luk Claes wrote: >> It needs quite some work to get reverse dependencies handled and getting >> it built on all architectures. Both of which are the main responsability >> of the kernel team... > > it is mostly done, beside the strange cpio missing build dep, > that funnily surfaced now on i686. fixed in latest repo and > scheduled for upload latest on this upcoming week. > >>> Could this be prioritized by the involved teams (mostly kernel and >>> release, I'd guess) or are there already some plans for this to >>> happen? >> There are no plans to force anything in like some propose in such >> situations as there is no clear plan of the kernel team to get the >> remaining issues solved soon after it would be forced in. > > without force hints linux-2.6 goes nowhere. If you mean this in general then you are misinformed. If you mean atm, then you know the answer to your following question. > what are the remaining issues that you are concerned about? The ones that prevent linux-2.6 from migrating once it would be unblocked. Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [stable] Adding bnx2x driver in 5.0.3
Otavio Salvador wrote: > Hello dann, > > On Sun, Jul 26, 2009 at 4:04 PM, dann frazier wrote: >> The bnx2x driver was disabled in lenny due to its use of non-free >> firmware. I have put together a patch that would reenable this driver >> in lenny's 2.6.26 kernel, making use of the firmware split-out patch >> that has gone upstream in Linux 2.6.31-rc releases (and is currently >> in use in the linux-2.6 2.6.30 packages in sid). > > Really good news :-) > >> I'd like to see if we can enable the use of this driver in 5.0.3. >> As far as I can tell, the necessary steps would be: >> >> - Update the kernel (obviously) - planned for a p-u upload this week >> - Backport the necessary changes for firmware-nonfree from sid to add >> the firmware-bnx2x package AFAICS both above are done? >> - Update kernel-wedge/stable to include bnx2x if available (are there >> space issues here?) > > The space usage is neglitable and I think it can be done with a very > small risk of regressions. > > Be sure to use the kernel-wedge of lenny for building it since we've > changed kernel-wedge a lot during the 2.6.30 migration and it is not > suitable for the lenny usage. What's the status here? >> - Update d-i in 5.0.3 to incorporate this driver > > Yes, you got the picture right. > > I offer help if required. This can probably be done already when kernel-wedge is updated? Please don't delay when unnecessary, TIA. Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [stable] Adding bnx2x driver in 5.0.3
dann frazier wrote: > On Sat, Aug 08, 2009 at 03:18:53PM +0200, Luk Claes wrote: >> Otavio Salvador wrote: >>>> - Update kernel-wedge/stable to include bnx2x if available (are there >>>> space issues here?) >>> The space usage is neglitable and I think it can be done with a very >>> small risk of regressions. >>> >>> Be sure to use the kernel-wedge of lenny for building it since we've >>> changed kernel-wedge a lot during the 2.6.30 migration and it is not >>> suitable for the lenny usage. >> What's the status here? > > I can get this done tomorrow. Good. >>>> - Update d-i in 5.0.3 to incorporate this driver >>> Yes, you got the picture right. >>> >>> I offer help if required. >> This can probably be done already when kernel-wedge is updated? Please >> don't delay when unnecessary, TIA. > > Do we have an estimate for 5.0.3 yet? Reason I ask is that there is > typically always some kernel changes queued - security or > otherwise. I do understand wanting to have p-u in an always-releasable > state, but it can be a lot of throwaway work given that a security > update would force us to do a complete rebuild. If we have a target > date in mind I could work up a schedule (w/ buffer room) to make sure > that all the pieces are in place ahead of time. In the past we have almost always redone d-i after a kernel upload, though that should only be necessary when d-i related changes or an ABI bump is included... Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RL meeting
dann frazier wrote: > On Fri, Aug 07, 2009 at 11:30:18AM +0100, Steve McIntyre wrote: >> On Wed, Aug 05, 2009 at 05:24:00PM +0100, Steve McIntyre wrote: >>> On Wed, Jul 29, 2009 at 02:56:49PM +0200, Bastian Blank wrote: On Tue, Jul 28, 2009 at 09:54:08AM +0100, Steve McIntyre wrote: > In the kernel BoF from DebConf, people generally agreed that it would > be a good plan to organise a real-life meeting. I'm more than happy to > spend Debian funds to make that happen, if needed. Please make your participation clear to the "announcement" for the release plan change. This was not in any way communicated before with the directly affected and the infrastructure teams (security, d-i, kde, gnome and kernel) or the developers at all. If it is not necessary to discuss changes, then a RL meeting is wrongly used time. >>> I knew of discussions going on with the Ubuntu folks about the >>> possibility of freezing together, but the exact timing for the freeze >>> that was chosen was a surprise to me as well as you. Then again, that >>> decision is being revisited and I'm hoping that the kernel team will >>> be helping the release team in new discussions to re-plan. >>> >>> That sounds like a good thing to go on the agenda for a RL meeting, in >>> fact... Do you think it could be useful for me to join the RL meeting? Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Problems with kernel 2.6.26-2-686-bigmem
David Vanfleet wrote: > > Hi, I'm trying to get Debian (Lenny) to recognize 6 Gig of memory on a > Dell PE 2650 server. I installed the basic 5.02a Debian system with just > a minimal install then I installed the 2.6.26-2-686-bigmem kernel so it > will see all the memory. When I boot into the bigmem kernel it fails to > boot, the errors I get are: > >WARNING boot device may be renamed. Try root=/dev/hda3 >... >ALERT! /dev/sda3 does not exist Did you try with changing the root device for the bigmem kernel to /dev/hda3? If you use grub for booting you could do that by pressing 'e' (for edit on the line with the bigmem kernel) and afterwards pressing 'b' (for boot) while in the grub menu (to just try it) or updating /boot/grub/menu.lst (for the bigmem kernel) and running update-grub before rebooting into the bigmem kernel. Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Handling of linux-modules-*-2.6 during freeze
Bastian Blank wrote: > Hi folks > > linux-modules-*-2.6 also produces a source-availability problem, they > use source including binary packages from unstable to build binary > packages. In unstable this is usualy no problem as we ship the source in > at least one variant. For the packages in testing this can be a problem, > escpecially during freeze. > > This problem popped up now because virtualbox-ose got a new upstream > version in unstable which is not meant to be included in Lenny. As this is the problem, this is where it needs to be solved... > For a short-term fix I only see three solutions: > - Continue to upload to unstable, drop virtualbox modules. > - Upload to testing-proposed-updates. > - Let virtualbox-ose into Lenny. None of these look really good to me. Another solution would be a reupload of 1.6.2-dfsg-6 with a higher version than currently in unstable. Cc-ed the maintainers so they can comment. Please let them first the opportunity to react and explain how they see it. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: unblock request for firmware-nonfree_0.13
dann frazier wrote: > hey, > I've just uploaded firmware-nonfree 0.13. It resolves 2 RC bugs: > 494936 - bnx2 fails to load on bootup, succeeds on manul load > 500692 - FTBFS: depends on linux-support-2.6.25-2 > And one 'normal' one (that should be bumped to important, imo): > 494703 - iwl3945: Microcode SW Error detected unblocked Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Handling of linux-modules-*-2.6 during freeze
Otavio Salvador wrote: > Bastian Blank <[EMAIL PROTECTED]> writes: > >> On Sat, Oct 04, 2008 at 02:58:47PM +0200, Luk Claes wrote: >>> Bastian Blank wrote: >>>> For a short-term fix I only see three solutions: >>>> - Continue to upload to unstable, drop virtualbox modules. >>>> - Upload to testing-proposed-updates. >>>> - Let virtualbox-ose into Lenny. >>> None of these look really good to me. Another solution would be a >>> reupload of 1.6.2-dfsg-6 with a higher version than currently in unstable. >> This may produce another bunch of problems with the version generation >> in the linux-modules-* packages which I currently don't want to find >> out. It works now, and I'm glad that it works. What I don't want is to >> introduce another variable like epochs just for fun. > > In this case I think t-p-u is the best alternative and I agree that if > the version generation code doesn't this support up to now, this is > too late to add it. t-p-u is not the best alternative IMHO, we're not talking about some package (linux-modules-*2.6) we can easily take out of the release if it breaks without harming lots of users... Either we remove virtualbox-ose from the release or we accept the version in unstable AFAICS, though as I asked before, please let the maintainers comment... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#479709: release-notes: Please document kernel 2.6.25+/chrony issue
Hi Can you please provide a proposed text (license: GPL v2) about the issue mentioned in bug #479709 for inclusion in the release notes? Thanks already. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Handling of linux-modules-*-2.6 during freeze
Daniel Baumann wrote: > Luk Claes wrote: >> t-p-u is not the best alternative IMHO, we're not talking about some >> package (linux-modules-*2.6) we can easily take out of the release if it >> breaks without harming lots of users... > > ack. > >> Either we remove virtualbox-ose from the release or we accept the >> version in unstable AFAICS, though as I asked before, please let the >> maintainers comment... > > it was stupid to upload 1.6.6 to unstable, however, the the only sane > thing imho is, to unblock vbox and let that vesion into lenny. the > version should be fine. everything else is even more a hassle. Ok, unblocked. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock linux-2.6/2.6.26-8
Otavio Salvador wrote: > Bastian Blank <[EMAIL PROTECTED]> writes: > >> Hi folks > >> Please unblock linux-2.6/2.6.26-8. > > No objection from d-i POV. I'll wait it to be built on all > architectures and do a massupload. > > The just missed one is mipsel, I hope it gets done by tomorrow. unblocked, I fear that it will still take a couple of hours till that one is built. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#496410: redhat-cluster tmpfile fixes
Stefan Fritsch wrote: > Hi, > > please accept redhat-cluster 2.20080801-4+lenny1 which I have just > uploaded to testing-proposed-updates: > >* Fix several tmpfile race conditions, among them CVE-2008-4192 and > CVE-2008-4579. (Closes: #496410) approved cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Uploading linux-2.6
Ben Hutchings wrote: > There have been 2 upstream stable updates and one more (2.6.32.6) is due > early this week. As usual, these include some security fixes. > Therefore I propose to upload with the changes from 2.6.32.6 once that's > released. > > (Still no stable ABI, sorry.) If the ABI changed the package name will change, right? Will it become trunk2? Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Uploading linux-2.6
Philipp Kern wrote: > On Mon, Jan 25, 2010 at 11:48:04AM +0100, maximilian attems wrote: >> On Mon, 25 Jan 2010, Luk Claes wrote: >>> Ben Hutchings wrote: >>>> There have been 2 upstream stable updates and one more (2.6.32.6) is due >>>> early this week. As usual, these include some security fixes. >>>> Therefore I propose to upload with the changes from 2.6.32.6 once that's >>>> released. >>>> >>>> (Still no stable ABI, sorry.) >>> If the ABI changed the package name will change, right? Will it become >>> trunk2? >> no, trunk has no ABI guarantee. >> you can bet that each upload has a different one. >> once libata is used and the configs all set we can go for stable >> numbering. > > Sorry, but your package is in testing now. Please bump the ABI number in > whatever why you want, but you should. I guess this means that the next version is no candidate for the release unless it gets a stable ABI (versioning) and should block the kernel from migrating for the time being? Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Uploading linux-2.6
Julien Cristau wrote: > On Mon, Jan 25, 2010 at 18:56:47 +0100, Luk Claes wrote: > >> I guess this means that the next version is no candidate for the release >> unless it gets a stable ABI (versioning) and should block the kernel >> from migrating for the time being? >> > The 2.6.30 kernel and the current 2.6.32 one aren't candidates either, > so I'm not sure what difference blocking the next one makes. As always, what reaches testing is a candidate for stable when no better version comes along. Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#723602: Please remove me from uploaders
Package: nfs-utils Severity: wishlist Hi As I've lost interest in NFS packaging, please remove me from uploaders. Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130917193317.7604.353.report...@station.luk.local
Re: Bug#616690: RFH: nfs-utils -- NFS support files common to client and server
On 03/06/2011 06:11 PM, Ben Hutchings wrote: Hi Ben > I request assistance with maintaining the nfs-utils package. > > The package description is: > Use this package on any machine that uses NFS, either as client or > server. Programs included: lockd, statd, showmount, nfsstat, gssd > and idmapd. > > This is co-maintained by Anibal Monsalve Salazar and the kernel team > (mostly represented by me). Currently we are not keeping up with bug > reports and I don't think we have sufficiently broad experience with > NFS to deal effectively with them. I'm willing to help out. What bugs or area do you want me to prioritise on? Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d73c72c.2060...@debian.org
Re: Bug#616690: RFH: nfs-utils -- NFS support files common to client and server
On 03/06/2011 07:37 PM, Ben Hutchings wrote: > On Sun, 2011-03-06 at 18:41 +0100, Luk Claes wrote: >> On 03/06/2011 06:11 PM, Ben Hutchings wrote: >> I'm willing to help out. What bugs or area do you want me to prioritise on? > > I think the most urgent would be reported regressions from lenny to > squeeze. I had a look at the outstanding bugs. Unless there are kerberos or nfs4 related regressions, there don't seem to be real regressions reported. The issues that are reported quite a lot are problems related with the init scripts though. Do you mind if I try to come up with some init script changes that make sure depended on services are tested for availability and services don't hang unnecessary? I have the feeling that changes there would be welcomed most by our userbase as I can read quite some frustration in the bug reports. Cheers Luk PS: The reason so many bugs are reported related to initscripts very probably are a result from the different behaviour of the init system (running things in parallel) and hotplug system (background handling if possible) and/or cleaning up of other init scripts which cause faster execution of our init scripts. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d750dc9.7060...@debian.org
Bug#568856: heartbeat is unable to stop nfs-kernel-server
Hi > heartbeat is unable to stop nfs-kernel-server. The script returns 0 so heartbeat think that nfs is stopped, but when trying to unmount > a shared disk (drbd) with /var/lib/nfs symlinked into heartbeat gives up and reboots the server, it fails since nfsd is still locking files in that folder. Are you sure that nfs-common (statd) is also stopped when you try to unmount the shared disk? Can you give the output of lsof /var/lib/nfs before the unmount? Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d7bb238.3000...@debian.org
Bug#611464: nfs-common: still unchanged.
Hi > the client cannot find nfs > > so i do on the server: > > # /etc/init.d/nfs-kernel-server restart > Stopping NFS kernel daemon: mountd nfsd. > Unexporting directories for NFS kernel daemon > Exporting directories for NFS kernel daemon...exportfs: /etc/exports > Starting NFS kernel daemon: nfsd mountd. > > and here it works. the client can see it, and mount the NFS. Can you please give the output from 'grep -e nfs -e portmap -e rpcbind /var/log/dpkg.log' on the server? I guess it is related to the order the packages got upgraded. Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d7bb475.6030...@debian.org
Bug#615642: Cannot install nfs-kernel-server.
Hi > Setting up portmap (6.0.0-2) ... > Starting portmap daemon > Setting up nfs-common (1:1.2.2-4) ... > > Creating config file /etc/idmapd.conf with new version > > Creating config file /etc/default/nfs-common with new version > Starting NFS common utilities: statd. > Setting up nfs-kernel-server (1:1.2.2-4) ... > Starting NFS common utilities: statd. > Exporting directories for NFS kernel daemon > Starting NFS kernel daemon: nfsdrpc.nfsd: Setting version failed: errno 16 (Device or resource busy) > rpc.nfsd: writing fd to kernel failed: errno 13 (Permission denied) > rpc.nfsd: unable to set any sockets for nfsd > failed! > invoke-rc.d: initscript nfs-kernel-server, action "start" failed. > dpkg: error processing nfs-kernel-server (--configure): > subprocess installed post-installation script returned error exit status 1 > configured to not write apport reports > Errors were encountered while processing: > nfs-kernel-server > E: Sub-process /usr/bin/dpkg returned an error code (1) Is portmap really running (You can find out by running 'lsof -i :111')? Does restarting portmap help? Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d7bb6d4.6020...@debian.org
Bug#524157: Broken file locking with nfs-common
Hi > File locking does not work over NFS mounts when using the repositories > nfs-common. If nfs-common is built from source, the problem goes away. When you can reproduce this, can you have a look if statd and portmap (or rpcbind) are running? Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d7bb88a.40...@debian.org
Bug#446238: nfs-common: Locks when using nfs4 sec=krb5 and user ticket expires
Hi Can you still reproduce this problem or can this old bug be closed? Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d86384a.5070...@debian.org
Bug#617666: nfs-kernel-server: Periodic nfsd failure - single nfsd process with high CPU and no mounts working
> On 10/03/11 12:54, Debian Bug Tracking System wrote: > > I have some extra information about this problem - the syslog contains > some kernel error messages related to nfs and xfs (the filesystem of the > /export partition). I have attached the relevant log section... > > It could be this is a problem with xfs or even with our hardware raid > controller. I have rebooted the machine with /export unmounted and am > currently running xfs_repair over it to see if that picks up any problems. Hi I guess your xfs_repair finished by now? Did it shed some more light on the issue or should we look more closely into the nfs code? Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d86374f.5070...@debian.org
Bug#562821: nfs-common: Fails to map user id's via idmapd
Hi statd should be started on both the client and the server if you want locking to work correctly. Have you enabled idmapd in /etc/default/nfs-common? Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d86418b.1040...@debian.org
Bug#567546: NFS4: exports options are ignored for subdirs
Hi Can you still reproduce this with the version in squeeze/unstable? Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d86420e.40...@debian.org
Bug#568288: mount.nfs: mount(2): Invalid argument
Hi > Mounting an nfs file system suddenly stopped working with errors > like this: > -- > # mount.nfs exact:/ /mnt/exact -v > mount.nfs: timeout set for Wed Feb 3 16:09:00 2010 > mount.nfs: trying text-based options 'addr=192.168.0.5,vers=4,clientaddr=192.168.0.3' > mount.nfs: mount(2): Invalid argument > mount.nfs: an incorrect mount option was specified > -- > > Both systems (that on which the mount was issued and the server) > were running testing. They were, however using custom kernels, but these > had worked without problems until today. Only the server was set up for > nfs version 4 which seems to be the heart of the problem from the message > about the text based options above - see below as well. I guess it's an old kernel? > The problem was resolved by adding either -o nfsvers=2 or > -o nfsvers-3 to the mount command. > > Thus there seems to be some sort of problem negotiating the nfs version > between the client & server? And a totally misleading error message? The default changed to version 4, but that does not work with old kernels, so I guess that's the problem? That would also explain the error message. Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d864a2f@debian.org
Bug#572406: "users" Mount Option Broken
> The "users" option got broken with the latest release, despite working
> correctly in 1:1.0.10-6+etch.1 (old stable). Non-root users can mount
> filesystems listed in /etc/fstab that have "users" specified, but they
> will be unable to unmount the filesystem
> ("umount.nfs: You are not permitted to unmount ...").
>
> My first thought is someone confused the "user" (which would need to
> check who mounted the FS) and "users" option. Given bug report #501459,
> part of which sounds like a similar issue with cifs, I'm also wondering
> if the interface between `mount` and `mount.` got changed
> slightly.
Hi
Does adding a trailing slash in /etc/fstab fix the issue for you?
Cheers
Luk
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d864b4f.1070...@debian.org
Bug#590959: idmapd only working in one direction
> I tried to set up nfsv4 between two lenny-installations where users have > different UIDs. > > Server: User "xyz" has UID 1000 > Client: User "xyz" has UID 501 What did you believe that when user xyz writes to the mounted directory it would not end up as belonging to UID 501 on the server? Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d864dde.1090...@debian.org
Bug#568288: mount.nfs: mount(2): Invalid argument
On 03/20/2011 11:11 PM, ael wrote: > On Sun, Mar 20, 2011 at 07:40:47PM +0100, Luk Claes wrote: >> Hi >> >>> Mounting an nfs file system suddenly stopped working with errors >>> like this: >>> -- >>> # mount.nfs exact:/ /mnt/exact -v >>> mount.nfs: timeout set for Wed Feb 3 16:09:00 2010 >>> mount.nfs: trying text-based options >> 'addr=192.168.0.5,vers=4,clientaddr=192.168.0.3' >>> mount.nfs: mount(2): Invalid argument >>> mount.nfs: an incorrect mount option was specified >>> -- >>> >>> Both systems (that on which the mount was issued and the server) >>> were running testing. They were, however using custom kernels, but these >>> had worked without problems until today. Only the server was set up for >>> nfs version 4 which seems to be the heart of the problem from the message >>> about the text based options above - see below as well. >> >> I guess it's an old kernel? > > Actually, no. I either run the current Debian kernel, or the latest > from stable-git, compiled locally, of course. > > >>> The problem was resolved by adding either -o nfsvers=2 or >>> -o nfsvers-3 to the mount command. >>> >>> Thus there seems to be some sort of problem negotiating the nfs version >>> between the client & server? And a totally misleading error message? >> >> The default changed to version 4, but that does not work with old >> kernels, so I guess that's the problem? > > I don't think it can be: I was running kernel.org kernels, later then > Debian testing. I can't remember what version I was at when I reported > the bug: I confess that I had forgotten about the report. > Maybe I had something wrong in the kernel configs, but I doubt it. > As noted above, I only had version 4 configured in one of them: > might that have upset the negotiation/default somehow? It might if the export was not configured to be for NFSv4 (with an fsid=0 entry etc). Another possibility is a bug in an older version of the Debian package or using an older kernel at the other end AFAICS. Can you still reproduce this issue or are you fine with me closing this bug? Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d868080.2060...@debian.org
Bug#446238: nfs-common: Locks when using nfs4 sec=krb5 and user ticket expires
On 03/22/2011 03:46 PM, Pedro Celestino dos Reis Rodrigues wrote: > Hello > > > On Sunday 20 Mars 2011 17:24:26 Luk Claes wrote: >> Hi >> >> Can you still reproduce this problem or can this old bug be closed? >> >> Cheers >> >> Luk > > At this moment, I am no longer administrating the network that have the > triggering configuration. I only know that it is yet operational and that the > software version installed was not changed, so I can not give a prompt > answer. > The best I can do is to give a try to reproduce the problem in squeeze during > the weekend. Fair enough. I'll await your reply. Thanks already! Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d88e62c.5050...@debian.org
Bug#562737: closed by Luk Claes (Bug#562737: fixed in nfs-utils 1:1.2.2-5)
On 03/28/2011 09:41 PM, Bob Proulx wrote: > found 562737 1:1.2.3-1 > thanks > > Seen in an update today in an otherwise fully updated Sid machine: > > $ sudo apt-get install nfs-common > Reading package lists... Done > Building dependency tree > Reading state information... Done > The following extra packages will be installed: > libtirpc1 > The following NEW packages will be installed: > libtirpc1 > The following packages will be upgraded: > nfs-common > 1 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. > Need to get 349 kB of archives. > After this operation, 311 kB of additional disk space will be used. > Do you want to continue [Y/n]? > Get:1 http://ftp.us.debian.org/debian/ sid/main libtirpc1 amd64 0.2.1-1 > [84.2 kB] > Get:2 http://ftp.us.debian.org/debian/ sid/main nfs-common amd64 1:1.2.3-1 > [265 kB] > Fetched 349 kB in 2s (141 kB/s) > Selecting previously deselected package libtirpc1. > (Reading database ... 324385 files and directories currently installed.) > Unpacking libtirpc1 (from .../libtirpc1_0.2.1-1_amd64.deb) ... > Preparing to replace nfs-common 1:1.2.2-5 (using > .../nfs-common_1%3a1.2.3-1_amd64.deb) ... > Unpacking replacement nfs-common ... > Processing triggers for man-db ... > Setting up libtirpc1 (0.2.1-1) ... > Setting up nfs-common (1:1.2.3-1) ... > Installing new version of config file /etc/init.d/nfs-common ... > Stopping NFS common utilities: idmapd statd. > Starting NFS common utilities: statd failed! > > And restarting manually emits: > > # service nfs-common restart > Stopping NFS common utilities: idmapd statd. > Starting NFS common utilities: statd failed! Can you please add 'set -x' on the second line of /etc/init.d/nfs-common and give the output from 'service nfs-common restart' so we get an idea in what step it fails, TIA? Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d9103eb.5070...@debian.org
Bug#562737: closed by Luk Claes (Bug#562737: fixed in nfs-utils 1:1.2.2-5)
On 03/29/2011 12:13 AM, Bob Proulx wrote: > Luk Claes wrote: >>> # service nfs-common restart >>> Stopping NFS common utilities: idmapd statd. >>> Starting NFS common utilities: statd failed! >> >> Can you please add 'set -x' on the second line of /etc/init.d/nfs-common >> and give the output from 'service nfs-common restart' so we get an idea >> in what step it fails, TIA? > > It gets hidden by start-stop-daemon. > > + start-stop-daemon --start --oknodo --quiet --pidfile > /var/run/rpc.statd.pid --exec /sbin/rpc.statd -- > + RET=1 > > Attached is the full log trace from: > > # bash -x /etc/init.d/nfs-common start 2>/tmp/nfs-common.bash-x.out > Starting NFS common utilities: statd failed! > > Running just the rpc.statd manually gives the same result. > > # /sbin/rpc.statd > # echo $? > 1 > > The /var/log/syslog shows: > > Mar 28 16:01:45 hysteria rpc.statd[27554]: Version 1.2.3 starting > Mar 28 16:01:45 hysteria rpc.statd[27554]: failed to create RPC listeners, > exiting Can you please run rpc.statd with debugging: 'rpc.statd -Fd'? It might be related to IPv6 (with portmap, switching to rpcbind would help in that case), though the debug output should tell us for sure. > Note: I don't use nfs on this machine. There is no reason for nfs > statd to start on it. The /etc/default/nfs-common is unmodified from > the default package version. AFAIK nfs-common is getting installed by > default at system install time to handle possible use of nfs mounts in > /etc/fstab. I haven't made any local changes to enable nfs > subsequently. I don't have an /etc/exports file. But in the > /etc/init.d/nfs-common file the NEED_STATD defaults to yes. statd is also needed when you mount NFS shares to prevent locking issues. I don't think it's a wrong default. Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d91116e.2080...@debian.org
Bug#562737: closed by Luk Claes (Bug#562737: fixed in nfs-utils 1:1.2.2-5)
On 03/29/2011 01:33 AM, Bob Proulx wrote: > Luk Claes wrote: >> Can you please run rpc.statd with debugging: 'rpc.statd -Fd'? It might >> be related to IPv6 (with portmap, switching to rpcbind would help in >> that case), though the debug output should tell us for sure. > > Here is the output: > > # /sbin/rpc.statd -Fd > rpc.statd: Version 1.2.3 starting > rpc.statd: Flags: No-Daemon Log-STDERR TI-RPC > sm-notify: Version 1.2.3 starting > sm-notify: Already notifying clients; Exiting! > rpc.statd: Local NSM state number: 3 > rpc.statd: Failed to open /proc/sys/fs/nfs/nsm_local_state: No such file or > directory > rpc.statd: Failed to unregister program 100024, version 1 > rpc.statd: Effective UID, GID: 102, 0 > rpc.statd: Failed to register (statd, 1, udp) > rpc.statd: Failed to register (statd, 1, tcp) > rpc.statd: Failed to register (statd, 1, udp6) > rpc.statd: Failed to register (statd, 1, tcp6) > rpc.statd: failed to create RPC listeners, exiting Hmm, could you install rpcbind to see if this is portmap specific? Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d92bf2f.8010...@debian.org
Bug#562737: closed by Luk Claes (Bug#562737: fixed in nfs-utils 1:1.2.2-5)
On 03/30/2011 08:13 AM, Bob Proulx wrote: > Luk Claes wrote: >> Hmm, could you install rpcbind to see if this is portmap specific? Ok, so it seems to be portmap specific. It would be nice if you could try portmap from experimental (similar fix as rpcbind got for a related bug) to see if that fixes it. Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d92d2a2.1000...@debian.org
Bug#621471: libtirpc is incompatible with portmap
On 04/08/2011 04:24 AM, Ben Hutchings wrote: > libtirpc really does a terrible job of protocol fallback. > > When trying to connect to rpcbind/portmap, it iterates over the > protocols listed in /etc/netconfig (nice choice of name, oh yeah) and > tries to create a socket for each in turn. Then it selects the last > protocol for which that succeeded (yes, the last, not the first). > > Only then does it try to connect. So there is no fallback at all for > connection. > > I'm attaching a patch to fix connection fallback, but unfortunately it > is not sufficient to make svc_reg() with portmap. I think we should just drop portmap support altogether. Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d9e9edf.7020...@debian.org
Bug#621773: nfs-kernel-server will not start since upgrade to 1.2.3
> The upgrade to nfs-kernel-server and nfs-common completely broke NFS > (client and server) for me. > > I have tried switching from portmap to rpcbind - this change the errors but did not help. portmap unfortunately does not work with libtirpc which is the successor of the glibc sunrpc implementation. So switching from portmap to rpcbind is a good idea anyway. > dmesg contains lots of: > RPC: server localhost requires stronger authentication. then > svc: failed to register lockdv1 RPC service (errno 97) I guess you don't allow 127.0.0.1 in /etc/hosts.allow? It looks like rpcbind needs that. Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4da02914.9010...@debian.org
Bug#621027: Invalid shell option in start-statd
> updating to version 1.2.3 of nfs-common froze my system and made it > unbootable (the boot sequence blocked on statd). It still booted in rescue > mode, where I could downgrade nfs-common to 1.2.2 and the system works > again. > > I don't know if the problem is the same as the one reported here (didn't > see the report before downgrading so I didn't test removing '-p'), but if > so the severity should be critical. The problem is definitely not related as start-statd is not used in the init scripts. Do you have rpcbind installed? Do you still have issues with the latest upload (1:1.2.3-2)? Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4da029ef.3080...@debian.org
Bug#622146: nfs-common: compatibility between squeeze and sid broken
On 04/10/2011 06:10 PM, Rico Rommel wrote: > Am Sonntag, 10. April 2011, 17:57:11 schrieb Ben Hutchings: >> On Sun, 2011-04-10 at 17:48 +0200, Rico Rommel wrote: >>> Package: nfs-common >>> Version: 1:1.2.2-4 >>> Severity: normal >>> Tags: ipv6 >> >> [...] >> >> Why ipv6? >> >> Ben. > > I noticed, that nfs-common doesn't depend on librpcsecgss3 anymore and tried > a > rebuild using librpcsecgss3. > But librpcsecgss3 conflicts with the now used libtirpc1, which provides ipv6 > support to nfs. (as i understood) Does removing librpcsecgss3 solve the problem? Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4da1f260.6090...@debian.org
Bug#622146: nfs-common: compatibility between squeeze and sid broken
On 04/10/2011 08:45 PM, Rico Rommel wrote: > Am Sonntag, 10. April 2011, 20:09:36 schrieb Luk Claes: >> On 04/10/2011 06:10 PM, Rico Rommel wrote: >>> Am Sonntag, 10. April 2011, 17:57:11 schrieb Ben Hutchings: >>>> On Sun, 2011-04-10 at 17:48 +0200, Rico Rommel wrote: >>> I noticed, that nfs-common doesn't depend on librpcsecgss3 anymore and >>> tried a rebuild using librpcsecgss3. >>> But librpcsecgss3 conflicts with the now used libtirpc1, which provides >>> ipv6 support to nfs. (as i understood) >> >> Does removing librpcsecgss3 solve the problem? > > No, it doesn't make any difference. > librpcsecgss3 isn't used by nfs-common 1.2.3-2 What kernel version are you using on the clients? If you're not using sid's kernel, does upgrading to a recent kernel (and rebooting obviously) solve anything? If that also does not work, I guess we could prepare an upload containing support to limit the negotiated enctypes [1] to see if that helps. Cheers Luk [1] http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=d6c1b35c6b40243bfd6fba2591c9f8f2653078c0 Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4da32c3d.1060...@debian.org
Bug#621773: Add depends on rpcbind
On 04/13/2011 09:15 PM, Roman Mamedov wrote: > Hello, > > I just had the same issue, and was able to solve it simply by installing > rpcbind (and removing portmap). I think this package should add a dependency > on rpcbind (and possibly "breaks: portmap"?) starting from 1.2.3. It does, please update your system. Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4da60232.2050...@debian.org
Bug#620421: nfs-kernel-server: init script depends on non-existent ‘/dev/tcp/’
On 04/13/2011 10:12 PM, Andrew O. Shadoura wrote:
> Hello,
>
> On Wed, 13 Apr 2011 22:04:54 +0200
> Luk Claes wrote:
>
>>> I confirm the bug.
>>>
>>> # cat /dev/tcp/localhost/111
>>> -su: /dev/tcp/localhost/111: No such file or directory
>>
>> Unless you show that you:
>>
>> 1) have bash 4.1-3 or later installed ('apt-cache policy bash' for
>> instance) 2) are using bash as shell ('exec bash' for instance)
>> 3) sunrpc service is running ('lsof -i :111' for instance)
>> 4) still have this issue
>>
>> It's going to stay closed as only in that case it's supposed to work.
>
> If it's the only case, it should be specified explicitly. And, after
> all, why not use the utility that is supposed to be used, and not this
> hackish thing?
The only reason it was implemented this way is because bash is still
essential and so does not need a dependency.
> Also, there's no way to get a newer bash unless I install it by hand.
> This system isn't lenny any more, but nothing has upgraded it yet by
> means of dependencies.
Well, we only guarantee to support upgrades from stable to the next one.
Obviously we will try to not break things in unstable and testing.
Though it's not uncommon to make the assumption that users have at least
upgraded to stable before doing partial upgrades to unstable/testing
versions.
Anyway, using a really old packaged bash, a newly packaged bash or a
self compiled bash (even the version in lenny) should all work for this
/dev/tcp use. It can also be replaced by 'lsof -i :111' or something
netcat like, though for both these you need to make sure you have lsof
or netcat installed.
Cheers
Luk
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4da60786.1090...@debian.org
Bug#620421: nfs-kernel-server: init script depends on non-existent ‘/dev/tcp/’
On 04/13/2011 10:39 PM, Andrew O. Shadoura wrote: > Hello, > > On Wed, 13 Apr 2011 22:28:54 +0200 > Luk Claes wrote: > >>> If it's the only case, it should be specified explicitly. And, after >>> all, why not use the utility that is supposed to be used, and not >>> this hackish thing? > >> The only reason it was implemented this way is because bash is still >> essential and so does not need a dependency. > > So you prefer not to specify dependencies at all and break the install > than to specify the dependency explicitly? I don't grok this, sorry :( > >>> Also, there's no way to get a newer bash unless I install it by >>> hand. This system isn't lenny any more, but nothing has upgraded it >>> yet by means of dependencies. > >> Well, we only guarantee to support upgrades from stable to the next >> one. Obviously we will try to not break things in unstable and >> testing. Though it's not uncommon to make the assumption that users >> have at least upgraded to stable before doing partial upgrades to >> unstable/testing versions. > > This machine is (obviously) a server. I can't 'just upgrade' it to the > stable at once, so I do partial upgrades. Dist-upgrade is no go at this > moment. So in my attempt to get NFS over IPv6 working I got broken NFS > at all :( > >> Anyway, using a really old packaged bash, a newly packaged bash or a >> self compiled bash (even the version in lenny) should all work for >> this /dev/tcp use. > > It's bash 3.2-4 from lenny, it's not so old. And it doesn't > have /dev/tcp support. > >> It can also be replaced by 'lsof -i :111' or >> something netcat like, though for both these you need to make sure >> you have lsof or netcat installed. > > It could be replaced by rpcinfo (as suggested before) which is provided > by libc-bin, so no extra dependencies and no breakage. Why not? Why > such a resistance? I didn't see the suggestion to use rpcinfo. The one of libc-bin will probably be removed at some point, though we always will have the one of rpcbind. Committed, so will be in a new upload unless any objections are out. Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4da60f26.6080...@debian.org
Bug#620421: nfs-kernel-server: init script depends on non-existent ‘/dev/tcp/’
On 04/13/2011 11:32 PM, Ben Hutchings wrote: > On Wed, Apr 13, 2011 at 11:01:26PM +0200, Luk Claes wrote: >> On 04/13/2011 10:39 PM, Andrew O. Shadoura wrote: > [...] >>> It could be replaced by rpcinfo (as suggested before) which is provided >>> by libc-bin, so no extra dependencies and no breakage. Why not? Why >>> such a resistance? >> >> I didn't see the suggestion to use rpcinfo. The one of libc-bin will >> probably be removed at some point, though we always will have the one of >> rpcbind. >> >> Committed, so will be in a new upload unless any objections are out. > > Does glibc's rpcinfo actually work with rpcbind, then? It is > documented as only speaking the portmapper protocol, and we now > know libtirpc doesn't handle that. Yes, it does work. > Also, I think either method (/dev/tcp/localhost/111 or rpcinfo) > will not work for anyone who configures rpcbind to listen on IPv6 > only. Only rpcbind's rpcinfo would work in that case, true. Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4da61d3f.7060...@debian.org
Bug#623377: init: don't start in runlevel S *and* 2345
On 04/19/2011 08:40 PM, Michael Biebl wrote: > Hi, Hi > the initscripts of nfs-common, pormap and rpcbind all have the following in > their LSB header: > > # Default-Start: S 2 3 4 5 > # Default-Stop: 0 1 6 Indeed. > As a result, the init scripts are run *twice* when you boot your system. True. > More importantly though, this breaks systemd horribly, as this leads to a > depedency loop there. That's a clear design flow in systemd. > nfs-common, portmap and rpcbind are the only packages using such a strange > setup > in Default-Start. > > I can't really tell, if those packages are supposed to be started during early > boot (rcS) and be running in single-user mode or starting them in multi-user > is > sufficient. AFAICT it's kind of a workaround for the broken networking script that succeeds before devices are really available. Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dadebd0.4080...@debian.org
Bug#625603: bug script does not work
On 05/04/2011 03:44 PM, Martin Steigerwald wrote: > Please select tags: (one at a time) [none] > Gathering additional data, this may take a while... > rpcinfo: can't contact portmapper: rpcinfo: RPC: Authentication error; why = > Client credential too weak > The package bug script /usr/share/bug/nfs-common/script exited with an error > status (return code = 256). Do you still want to file a report? [y|N|q|?]? Any reason why you don't allow connections from unpriviledged ports on localhost to portmapper? This might very well be related to the other bug you filed... Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dc18aeb.1070...@debian.org
Bug#625826: nfs-common: missing manpage idmapd.conf
reassign 625826 libnfsidmap2 retitle 625826 missing manpage idmapd.conf forcemerge 585083 625826 thanks On 05/06/2011 11:20 AM, Sebastian Harl wrote: > Hi, > > the rpc.idmapd(8) manpage refers to the manpage idmapd.conf (SEE ALSO). > However, there is no such manpage (any more). According to upstream Git > commit 207cf7, the manpage was moved to libnfsidmap. > > It would be nice to have this manpage available again. Imho, the most > appropriate place would be the nfs-common package but since that depends > on libnfsidmap2, shipping it in the latter would be fine (and more > straight-forward) as well. So, please feel free to reassign as you seem > fit :-) There are already 2 bugs open about this, merging it with the others... They even 'affect' nfs-common, so it's strange that it does not show up when filing bugs? The idmapd.conf file is provided by libnfsidmap2, so it's only logical that the manpage is also provided by that same package AFAICT. Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dc4272e.4060...@debian.org
Bug#621773: Any sign of a fix??
On 05/07/2011 12:15 PM, Mike Ricketts wrote: > > This is still broken in the latest versions. Switching to rpcbind does > NOT make any difference. You are not using IPv6 and the suggestion of another user to add IPv6 addresses to /etc/hosts did not solve the issue? You are using NFS with Kerberos and have NEED_GSSD=yes in your configuration? You are using AD authentication and do not have libtirpc 0.2.2 (unfortunatley seems to not be packaged yet) installed? Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dc5356f.90...@debian.org
Bug#707589: nfs-kernel-server: NFSv3 is broken with libc-bin 2.17
Hi I will look at uploading a new package to unstable (and probably also stable for the NFSv4 and security issue if relevant) tomorrow unless Ben beats me to it. Cheers Luk On 05/09/2013 06:07 PM, Sven Joachim wrote: > Package: nfs-kernel-server > Version: 1:1.2.6-3 > Severity: important > > I have just spent half an hour trying to find out why my NFS mounts had > stopped working. It turns out that the init script tries to run > /usr/bin/rpcinfo: > > , > | $PREFIX/bin/rpcinfo -u localhost nfs 3 >/dev/null 2>&1 || > | RPCMOUNTDOPTS="$RPCMOUNTDOPTS --no-nfs-version 3" > ` > > Alas, libc-bin as of version 2.17-1 no longer ships /usr/bin/rpcinfo, > which seems to make sense given that rpcbind provides /usr/sbin/rpcinfo. > The net effect is that "--no-nfs-version 3" gets added to rpc.mountd's > options, breaking NFSv3 mounts. > > > -- System Information: > Debian Release: jessie/sid > APT prefers unstable > APT policy: (500, 'unstable'), (101, 'experimental') > Architecture: i386 (x86_64) > > Kernel: Linux 3.8.12-nouveau (SMP w/2 CPU cores) > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > Versions of packages nfs-kernel-server depends on: > ii libblkid1 2.20.1-5.3 > ii libc6 2.17-1 > ii libtirpc1 0.2.2-5 > ii libwrap07.6.q-24 > ii lsb-base4.1+Debian9 > ii nfs-common 1:1.2.6-3 > ii ucf 3.0025+nmu3 > > nfs-kernel-server recommends no packages. > > nfs-kernel-server suggests no packages. > > -- no debconf information > -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/518c122d.8040...@debian.org
Bug#659465: nfs-common: need to restart nfs-common at the end of init on the NFS server
Hi What's in your /etc/fstab and /etc/exports files before the init is run? The rpc.idmapd should start automatically when one of both contains anything. Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/518ca08b.8080...@debian.org
Bug#707960: rpc.gssd segfaults when mounting a nfsv4 volume
severity 707960 important thanks While a segfault is not tolerable you should still not file bugs as grave that do not break other packages. It's even not serious as the package is still functional for a lot of people that use it in another context than you do. Now to the bug in question: On 05/12/2013 01:06 PM, Marco d'Itri wrote: > (elided)://media/nfs nfs4noauto,soft,intr,sec=krb5p 0 0 > > [2262594.734234] rpc.gssd[2729]: segfault at 1 ip f74714ba sp > ff830170 error 4 in libgssglue.so.1.0.0[f746e000+8000] Does statd run? Does installing nfs-kernel-server by any chance fix the bug? > Reverting nfs-common to 1:1.2.6-3 fixes the issue. > > BTW: > > /usr/share/bug/nfs-common/script: 5: /usr/share/bug/nfs-common/script: > rpcinfo: not found Thanks, will be fixed in the next upload. Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/518f9b5a.8040...@zomers.be
Bug#705507: nfs-common: rpc.gssd crashes when performing nfs4 mount
On 05/11/2013 11:18 PM, Євгеній Мещеряков wrote: Hi > rpc.gssd now also crashes on amd64. Does this also happen when the package nfs-kernel-server is installed? Cheers Luk > Here is part of gdb log: > > Program received signal SIG37, Real-time event 37. > > Program received signal SIGSEGV, Segmentation fault. > 0x7f58a6214e95 in ?? () from /lib/x86_64-linux-gnu/libgssglue.so.1 > (gdb) bt > #0 0x7f58a6214e95 in ?? () from /lib/x86_64-linux-gnu/libgssglue.so.1 > #1 0x7f58a6215bc5 in gss_init_sec_context () from > /lib/x86_64-linux-gnu/libgssglue.so.1 > #2 0x7f58a733cfbd in ?? () from /lib/x86_64-linux-gnu/libtirpc.so.1 > #3 0x7f58a733d3c7 in authgss_create () from > /lib/x86_64-linux-gnu/libtirpc.so.1 > #4 0x7f58a733d4dc in authgss_create_default () from > /lib/x86_64-linux-gnu/libtirpc.so.1 > #5 0x004050f6 in ?? () > #6 0x00405caa in ?? () > #7 0x00406969 in ?? () > #8 0x00404abc in ?? () > #9 0x00403959 in ?? () > #10 0x7f58a6654a55 in __libc_start_main (main=0x4036a0, argc=1, > ubp_av=0x7fffbe42f968, init=, fini=, > rtld_fini=, stack_end=0x7fffbe42f958) at libc-start.c:260 > #11 0x004039c9 in ?? () -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/518fbd6e.8080...@zomers.be
Bug#707908: Missing source for nfsdcltrack.8
On 05/12/2013 04:54 AM, David Prévot wrote: > Hi, Hi David > The nfsdcltrack.8 man page is “Automatically generated by Pod::Man 2.25 > (Pod::Simple 3.16)” but the POD source is not provided, thus failing to > comply with the terms of its licence (GPL2+) and DFSG2. The POD source is not meant to be used anymore according to the original provider of the man page. So I sent a patch upstream to remove the auto generated comments and unneeded parts of the man page. Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/518fbd0e.9020...@zomers.be
Bug#708156: nfs-common: Please include /etc/request-key.d/id_resolver.conf
On 05/13/2013 05:33 PM, Norbert Veber wrote: > Hi, Hi > Thanks for packaging version 1.2.8 so promptly (re Bug#707258)! I intended to upload a newer upstream after wheezy's release anyway... > I have installed this version, but the request-key errors persist with > newer kernels (at least anything newer than 3.7). > > May 13 11:19:10 hostname request-key: Cannot find command to construct key > 213728982 > etc.. > > It turns out that an additonal config file needs to be provided. > > In RHEL they named this file /etc/request-key.d/id_resolver.conf, so > Debian can probably just use the same name. As per 'man nfsidmap' I > used the following line: > > $ cat /etc/request-key.d/id_resolver.conf > createid_resolver**/usr/sbin/nfsidmap -t 600 %k %d > > Once that file was created, the errors stop, and NFSv4 works properly > again. Thank you very much. Hopefully the segfaults some people got are also fixed now! New package uploading now... Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5191295b.8010...@debian.org
Bug#515754: acknowledged by developer (closing 515754)
On 11/08/2011 07:32 PM, Ben Harris wrote: > On Tue, 8 Nov 2011, Debian Bug Tracking System wrote: > >> This is an automatic notification regarding your Bug report >> #515754: nfs-common: Mounting with sec=krb5p fails with "access denied >> by server while mounting", >> which was filed against the nfs-common package. >> >> It has been marked as closed by one of the developers, namely >> Luk Claes . > > Thank you for the notification. I presume this means that there is no > bug in nfs-common, and that the inability to mount Kerberized > filesystems from my Solaris server is intended behaviour. Is this a bug > in Solaris that I should be chasing up with Oracle, or is it simply > expected that non-Debian NFS servers will no longer work with Debian > clients? It has nothing to do with Debian/Linux or not. It's unfortunately about making it harder to do less secure Kerberos based things which is mainly something that changed in the kerberos library, but only works when the NFS server knows how to use it. So I'm afraid as a NFS packager I won't be able to do anything about it as it's between the kerberos library and the server. You can probably work around it by having a permitted_enctypes in the server, so the kerberos library on the client does not try anything else AFAICS (more info in the following bugreport: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622146). Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4eb9b8dc.9020...@debian.org
Bug#648155: Acknowledgement (nfs-common: nfs mount hangs when kerberos ticket expires. Squeeze used to renew.)
On 11/09/2011 03:01 PM, John Hughes wrote: > This seems to be Ubuntu bug https://bugs.launchpad.net/ubuntu/+bug/794112 > > There it is suggested that updating nfs-utils could fix the problem. I > don't see how, and anyway, is there a more recent version than what's in > sid? Not really, there are some upstream commits, but they don't look related at all. Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ebac871.4060...@debian.org
Bug#622146: nfs-kernel-server: error Encryption type not permitted
On 11/14/2011 04:57 PM, Mc.Sim wrote: > Hello! Hi > I have Win2k8 R2 as a domain controller (as KDC for NFS). > There is an NFS client on Debian wheezy: hostname - debian: > I tried to uncomment > # default_tgs_enctypes = des3-hmac-sha1 > # default_tkt_enctypes = des3-hmac-sha1 > # permitted_enctypes = des3-hmac-sha1 > and comment: > default_tgs_enctypes = des-cbc-crc > default_tkt_enctypes = des-cbc-crc > permitted_enctypes = des-cbc-crc Why would that work without changing anything in your Kerberos keytabs? > but always when trying to connect to the server, > root@debian:~# mount -vvv -t nfs4 -o sec=krb5 archiv:/nfs /mnt2 > And get the error in log on server: > ARCHIV ~ # tailf /var/log/daemon.log > Nov 14 18:26:42 archiv rpc.svcgssd[4812]: ERROR: GSS-API: error in > handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS > failure. Minor code may provide more information) - Encryption type not > permitted > Nov 14 18:26:42 archiv rpc.svcgssd[4812]: ERROR: GSS-API: error in > handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS > failure. Minor code may provide more information) - Encryption type not > permitted > Nov 14 18:29:30 archiv rpc.svcgssd[4812]: ERROR: GSS-API: error in > handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS > failure. Minor code may provide more information) - Encryption type not > permitted > Nov 14 18:29:30 archiv rpc.svcgssd[4812]: ERROR: GSS-API: error in > handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS > failure. Minor code may provide more information) - Encryption type not > permitted > Nov 14 18:39:05 archiv rpc.svcgssd[4812]: ERROR: GSS-API: error in > handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS > failure. Minor code may provide more information) - Encryption type not > permitted > Nov 14 18:39:20 archiv rpc.svcgssd[4812]: ERROR: GSS-API: error in > handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS > failure. Minor code may provide more information) - Encryption type not > permitted Expected when des3-hmac-sha1 is not in keytab. > == > In this case, the second mount on the client only after a servise nfs-common > restart, because mount hangs and stops due to a timeout. > When I comment on all the settings on the server and client: > > # allow_weak_crypto = true > #default_tgs_enctypes = des-cbc-crc > #default_tkt_enctypes = des-cbc-crc > #permitted_enctypes = des-cbc-crc > # default_tgs_enctypes = des3-hmac-sha1 > # default_tkt_enctypes = des3-hmac-sha1 > # permitted_enctypes = des3-hmac-sha1 > # permitted_enctypes = des-cbc-crc > And I get message on server-log: > > Nov 14 18:50:23 archiv rpc.svcgssd[4812]: ERROR: GSS-API: error in > handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS > failure. Minor code may provide more information) - No supported encryption > types (config file error?) > Nov 14 18:50:23 archiv rpc.svcgssd[4812]: ERROR: GSS-API: error in > handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS > failure. Minor code may provide more information) - No supported encryption > types (config file error?) > > Help me, please for this problem. This will only work if you have other possibilities in the Kerberos keytab. > p.s. On the client (hostname debian) as an NFS server is installed and if I > run: > root@debian:~# grep -v ^# /etc/exports > /nfsgss/krb5(rw,sync,fsid=0,crossmnt,no_subtree_check) > root@debian:~# mount -v -t nfs4 -o sec=krb5 debian:/ /mnt > mount.nfs4: timeout set for Mon Nov 14 18:58:10 2011 > mount.nfs4: trying text-based options > 'sec=krb5,addr=10.0.0.50,clientaddr=10.0.0.50' > debian:/ on /mnt type nfs4 (rw,sec=krb5) > root@debian:~# mount | grep nfs > nfsd on /proc/fs/nfsd type nfsd (rw) > rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) > debian:/ on /mnt type nfs4 (rw,sec=krb5,addr=10.0.0.50,clientaddr=10.0.0.50) So it worked, I guess that's the initial scenario where you are using des-cbc-crc? I myself have little to no experience with Kerberos, but I would try klist to see what's in your keytabs (/etc/krb5.keytab) and related tools to add entries to the keytab when needed. This does not look like an NFS problem to me or am I mistaken? Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ec13589.6020...@debian.org
Bug#623377: init: don't start in runlevel S *and* 2345
On 11/25/2011 07:22 PM, Goswin von Brederlow wrote: > Note: libtirpc.so.1 is now in /lib/$(DEB_HOST_MULTIARCH)/ so the demaons > can start before /usr is mounted. Sure like now, though not everything is available at that time: kerberised access or NFSv4 idmapping for instance. So it still needs to rerun after /usr is available. Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ecfdfe9.6010...@debian.org
Bug#633034: nfs-utils: /run transition: Please switch to /run/sendsigs.omit.d
On 12/07/2011 04:14 PM, Roger Leigh wrote: > On Wed, Dec 07, 2011 at 02:55:55PM +, Roger Leigh wrote: >> On Wed, Dec 07, 2011 at 02:41:39PM +, Ben Hutchings wrote: >>> On Wed, 2011-12-07 at 09:52 +, Roger Leigh wrote: tags 633034 + patch thanks On Thu, Jul 07, 2011 at 11:33:01PM +0100, Roger Leigh wrote: > Source: nfs-utils > Version: 1:1.2.3-3 > Severity: important > > Your package is currently using/lib/init/rw/sendsigs.omit.d > which is now deprecated and pending removal. Please update your > package to use /run/sendsigs.omit.d with a versioned dependency > on initscripts, as detailed below. Patch against current git attached. >>> >>> I would be quite happy for you to do the NMU if you've tested the >>> result. Anibal, Luk, any objection to that? >> >> Thanks. It's currently untested, but I will do so right now. > > Correctly migrates and is correctly recreated on service restart. > Looks OK here. > > Note: I tested by applying the patch to current unstable nfs-utils; > I couldn't build from git directly for some reason. It's not this > patch. I tried git-buildpackage (fails packing with dpkg-source) > and dpkg-buildpackage (same error): > > ravenclaw% git reset --hard > HEAD is now at 54f72b6 debian: Migrate from /lib/init/rw to /run and close > #633034 > ravenclaw% dpkg-buildpackage -us -uc > dpkg-buildpackage: source package nfs-utils > dpkg-buildpackage: source version 1:1.2.5-2.1 > dpkg-buildpackage: source changed by Roger Leigh > dpkg-buildpackage: host architecture amd64 > dpkg-source --before-build nfs-utils > dpkg-source: info: using options from nfs-utils/debian/source/options: > --compression=bzip2 --compression-level=9 > fakeroot debian/rules clean > dh_testdir > dh_testroot > rm -f build-stamp > rm -rf /tmp/nfs-utils/debian/tmp > [ ! -f Makefile ] || /usr/bin/make distclean > dh_autoreconf_clean > dh_clean > dpkg-source: info: using options from nfs-utils/debian/source/options: > --compression=bzip2 --compression-level=9 > dpkg-source: info: using source format `3.0 (quilt)' > dpkg-source: info: building nfs-utils using existing > ./nfs-utils_1.2.5.orig.tar.bz2 > dpkg-source: warning: ignoring deletion of file utils/nfsidmap/Makefile.in > dpkg-source: warning: ignoring deletion of file utils/blkmapd/Makefile.in > dpkg-source: info: local changes detected, the modified files are: > nfs-utils/Makefile.in > nfs-utils/aclocal.m4 > nfs-utils/aclocal/kerberos5.m4 > nfs-utils/aclocal/libtool.m4 > nfs-utils/aclocal/ltversion.m4 > nfs-utils/config.log > nfs-utils/configure > nfs-utils/linux-nfs/Makefile.in > nfs-utils/ltmain.sh > nfs-utils/support/Makefile.in > nfs-utils/support/export/Makefile.in > nfs-utils/support/include/Makefile.in > nfs-utils/support/include/config.h.in > nfs-utils/support/include/nfs/Makefile.in > nfs-utils/support/include/rpcsvc/Makefile.in > nfs-utils/support/include/sys/Makefile.in > nfs-utils/support/include/sys/fs/Makefile.in > nfs-utils/support/misc/Makefile.in > nfs-utils/support/nfs/Makefile.in > nfs-utils/support/nsm/Makefile.in > nfs-utils/tests/Makefile.in > nfs-utils/tests/nsm_client/Makefile.in > nfs-utils/tools/Makefile.in > nfs-utils/tools/locktest/Makefile.in > nfs-utils/tools/mountstats/Makefile.in > nfs-utils/tools/nfs-iostat/Makefile.in > nfs-utils/tools/nlmtest/Makefile.in > nfs-utils/tools/rpcdebug/Makefile.in > nfs-utils/tools/rpcgen/Makefile.in > nfs-utils/utils/Makefile.in > nfs-utils/utils/blkmapd/device-process.c > nfs-utils/utils/exportfs/Makefile.in > nfs-utils/utils/exportfs/nfsd.man > nfs-utils/utils/gssd/Makefile.in > nfs-utils/utils/gssd/gss_util.c > nfs-utils/utils/gssd/gssd_proc.c > nfs-utils/utils/idmapd/Makefile.in > nfs-utils/utils/mount/Makefile.in > nfs-utils/utils/mount/fstab.c > nfs-utils/utils/mount/fstab.h > nfs-utils/utils/mount/mount.c > nfs-utils/utils/mount/mount.nfs.man > nfs-utils/utils/mountd/Makefile.in > nfs-utils/utils/nfsd/Makefile.in > nfs-utils/utils/nfsd/nfsd.man > nfs-utils/utils/nfsstat/Makefile.in > nfs-utils/utils/showmount/Makefile.in > nfs-utils/utils/statd/Makefile.in > nfs-utils/utils/statd/statd.c > dpkg-source: info: you can integrate the local changes with dpkg-source > --commit > dpkg-source: error: aborting due to unexpected upstream changes, see > /tmp/nfs-utils_1.2.5-2.1.diff.6o1obE > dpkg-buildpackage: error: dpkg-source -b nfs-utils gave error exit status 2 > > Plain "debian/rules build" failed with: > > checking for nfs4_set_debug in -lnfsidmap... (cached) yes > checking for nfs4_owner_to_uid in -lnfsidmap... (cached) yes > checking spkm3.h usability... no > checking spkm3.h presence... no > checking for spkm3.h... no > configure: WARNING: Could not locate SPKM3 header; will not have SPKM3 support > checking for Kerberos v5... configure: error: Kerberos v5 with GSS support > not found: consider --disable-gss or --with-krb5= > make: *** [build-
Bug#653630: /sbin/mount.nfs: Re: nfs-common: Only root can unmount, nautilus badly confused
On 01/22/2012 11:34 AM, Pavel Yakunin wrote: > Seems that I have the same issue with nfs. > > There is an entry in my fstab: > liveserv:/mnt/library//mnt/library nfs > noauto,user 0 0 > I mount the nfs share as user without any problem: > $mount /mnt/library > Then I try to umount: > $umount /mnt/library > umount: only root can unmount liveserv:/mnt/library/ from > /mnt/library > > Everything was working properly before the last dist-upgrade Jan 21 > 2012 (I did the previos one on Jan 9 2012). > Just after the upgrade I've got the error: "umount: /mnt/library > mount disagrees with the fstab". > Then I managed to get rid of this error by putting a trailing slash > to the fstab entry, but the error I mentioned above is still there. According to below snippet that automatically was attached to your bug report, the trailing slash is not in /etc/fstab? Anyway this bug was introduced by the conversion of /etc/mtab (putting Michael in Cc, maybe he has an idea how we should prevent this and similar issues from happening). > -- /etc/fstab -- > liveserv:/mnt/library/mnt/library nfs noauto,user > 0 0 > liveserv:/mnt/photo/ /mnt/photo nfs noauto,user 0 > 0 > liveserv:/mnt/backup/ /mnt/backup nfs noauto,user > 0 0 > lserv:/mnt/music/ /mnt/lserv-music nfs noauto,user > 0 0 > lserv:/mnt/archive/ /mnt/archive nfs noauto,user >0 0 > lserv:/home//mnt/lserv-home nfs noauto,user > 0 0 > liveserv:/mnt/mirror/ /mnt/mirror nfs noauto,user 0 0 > -- /proc/mounts -- > rpc_pipefs /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0 > liveserv:/mnt/library/ /mnt/library nfs > rw,relatime,vers=3,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.104,mountvers=3,mountport=46570,mountproto=udp,local_lock=none,addr=192.168.1.104 > 0 0 Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f1bf36a.90...@debian.org
Bug#653630: /sbin/mount.nfs: Re: nfs-common: Only root can unmount, nautilus badly confused
On 01/22/2012 01:53 PM, Roger Leigh wrote: > On Sun, Jan 22, 2012 at 12:34:39PM +, Roger Leigh wrote: >> On Sun, Jan 22, 2012 at 12:55:45PM +0100, Michael Biebl wrote: >>> On 22.01.2012 12:30, Luk Claes wrote: >>>>> -- /etc/fstab -- >>>>> liveserv:/mnt/library/mnt/library nfs noauto,user >>>>> 0 0 >>>>> -- /proc/mounts -- >>>>> liveserv:/mnt/library/ /mnt/library nfs >>>>> rw,relatime,vers=3,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.104,mountvers=3,mountport=46570,mountproto=udp,local_lock=none,addr=192.168.1.104 >>>>> 0 0 >>> >>> I am missing a bit of context here. Is the problem related to the "user" >>> option or regarding a trailing "/"? >>> >>> wrt /etc/mtab being a symlink to /proc/mounts: I assume mount.nfs is >>> built against libmount, seeing [1] as fixed? Do you get a file >>> /run/mount/utab when the nfs share is mounted? What does it contain? >> >> I'm afraid I can't help with the specifics immediately (I'll need >> to set up some NFS mounts), but some general comments about the >> recent changes: >> >> - if you mount a filesystem with the "user" option, the user who >> mounted it will be written to /run/mount/utab. While I've not >> tested this for NFS, it's certainly the case for all other mounts. > > A quick test with NFS4 showed that /run/mount/utab does not contain > anything, and additionally it looks like mount.nfs4 is /not/ linked > against libmount, which I thought (perhaps mistakenly, unless it's > a regression) was now using libmount. > > NFS certainly does support libmount, it's right there in the > configure script. Looks like it just needs adding to the Build-Deps > and enabling in debian/rules by configuring with > --enable-libmount-mount. I would highly recommend that the nfs-common > enable this as soon as possible! Hmm, apparently there was some confusion from my part: I did not expect to have to explicitly build depend on libmount-dev as libblkid-dev has a similar description I thought one would replace the other. I also did not expect I had to explicitly enable libmount via configure as configure has default --enable-mount=yes and --enable-libmount-mount same as --enable-mount. Apparently only when explicitly setting --enable-mount=yes, it would also be set for --enable-libmount-mount. Anyway, I have explicitly enabled it now (and added the build dependency). Pavel: Can you have a look if the new version from unstable fixes your problem (this bug)? Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f1c28d8.5040...@debian.org
Bug#653630: /sbin/mount.nfs: Re: nfs-common: Only root can unmount, nautilus badly confused
On 01/22/2012 09:32 PM, Pavel Yakunin wrote: > > >> >> Pavel: Can you have a look if the new version from unstable fixes your >> problem (this bug)? > Luk, did you push the new version in the sid repo? (or maybe I should > wait for a while? I used us.debian.org mirror). Apt tell me that nothing Yes, version 1:1.2.5-4. It was probably not pushed to the mirrors yet. Can you test if it fixes the bug, thanks already? Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f1c82e2.5090...@debian.org
Bug#625603: bug script does not work
>> Any reason why you don't allow connections from unpriviledged ports on >> localhost to portmapper? This might very well be related to the other >> bug you filed... > > No. I was not aware that I did, but you are right, I had NFS services without > LOCAL in /etc/hosts.allow. But now I changed it and even commented out the NFS > entries from /etc/hosts.allow completely and it still does not work. > > Now I just have: > > shambhala:/etc> tail -8 hosts.allow > ALL: LOCAL > sshd : ALL > #portmap: LOCAL 10.0.0.0/16 172.21.0.0/16 > #mountd : LOCAL 10.0.0.0/16 172.21.0.0/16 > #lockd : LOCAL 10.0.0.0/16 172.21.0.0/16 > #statd : LOCAL 10.0.0.0/16 172.21.0.0/16 > #rquotad: LOCAL 10.0.0.0/16 172.21.0.0/16 > > Any hints where else to look? So the bug script still does not work? Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dedf46e.6020...@debian.org
Bug#625601: mount.nfs complains about statd is not running while it is running
What does /usr/sbin/rpcinfo -p give as output? Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dedf599.5010...@debian.org
Bug#622146: nfs-common: compatibility between squeeze and sid broken
On 06/06/2011 05:37 PM, Alberto Gonzalez Iniesta wrote: > Adding the following line in the [libdefaults] section of /etc/krb5.conf > fixed the problem for me (tm), probably not the best solution, but > works: > permitted_enctypes = des-cbc-md5 It's probably better to set enable_weak_crypto=yes, does that work? > I also exported ONLY the DES-CBC-MD5:NORMAL key for my sid host: > kadmin.local: ktadd -k lib.keytab -e DES-CBC-MD5:NORMAL host/lib > (probably not needed, but just to stay on the ""safe"" side) Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dee594e.5030...@debian.org
Bug#622146: nfs-common: compatibility between squeeze and sid broken
On 06/07/2011 07:01 PM, Luk Claes wrote: > On 06/06/2011 05:37 PM, Alberto Gonzalez Iniesta wrote: >> Adding the following line in the [libdefaults] section of /etc/krb5.conf >> fixed the problem for me (tm), probably not the best solution, but >> works: >> permitted_enctypes = des-cbc-md5 > > It's probably better to set enable_weak_crypto=yes, does that work? 'allow_weak_crypto = true', that is. >> I also exported ONLY the DES-CBC-MD5:NORMAL key for my sid host: >> kadmin.local: ktadd -k lib.keytab -e DES-CBC-MD5:NORMAL host/lib >> (probably not needed, but just to stay on the ""safe"" side) Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dee5af0.3040...@debian.org
Re: Changes to Debian Installer release process
On 07/28/2011 01:18 PM, Otavio Salvador wrote: > I used some of Debcamp and Debconf time this year to discuss the > Debian Installer release process with some people and after talking > with many people it seems we agreed on the following changes on Debian > Installer release process and it would be interesting to receive > feedback on those to see if anyone see a problem we didn't notice yet. Great, lets make d-i as easy to handle as general packages (or at least almost ;-))! > * Official uploads to be built against unstable Sounds good. > * Linux kernel udebs to be built from linux source package Also looks good. > * Debian Installer daily builds to be done from source uploads > >The daily builds will use the archive source for building so every > time we do a change in unstable in a module that is included in initrd > it will trigger a binNMU in all architectures replicating what we have > in daily builds. When source changes in debian-installer source > package are done, a new source upload will be required. Do the daily builds only uncover issues from building the initrd? A.k.a. will changes in packages other than the one in the initrd only have an effect on the install via genuine downloading from the archive at the time of the install? > * Debian Installer experimental builds > >With Linux kernel udebs built from linux source we have the > possibility to get the installer built against the development kernel > that will be available on experimental and this is quite important to > us to be able to test all this before it is available in unstable to > avoid bad surprises for us and users. This will also be a handy tool > for us to play with not well tested or finished stuff without breaking > installer to end users. Sounds good! > * Use of britney to handle package and installer migration > >This is the end of the process and some details are yet unknown how > this is going to happen however but our goal is to make it happen > since it will alleviate a lot the amount of work to make Debian > Installer release to happen. Super! > It is important to notice that it is not a single-man effort but a > coordinate and shared effort of Debian Kernel, Debian Release and > Debian Installer teams to get all this done. Those changes are not > going to happen at once but in a progressive process and at the end > this is going to make the installer release process easier to > understand and handle. Right, lets go for it! Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e341d9a.1040...@debian.org
Bug#638448: nfs-common: add support for pNFS
On 08/19/2011 02:02 PM, Ben Hutchings wrote: > On Wed, 2011-08-17 at 20:17 +0200, Christoph Anton Mitterer wrote: >> alias nfs-layouttype4-1 nfs_layout_nfsv41_files >> alias nfs-layouttype4-2 nfs_layout_osd2_objects >> alias nfs-layouttype4-3 off > [...] > > No, the aliases should be *in the modules*, like I said before. If > there is any module setting which should be applied on all settings then > it belongs in the module. Putting it in a configuration file results in > an undocumented dependency and makes modprobe run slower. Changing the > module also means we have a patch we can send upstream and thus fix > every other distribution. Should this bug against nfs-common not be closed in that case or am I missing something? Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e4e9f9a.8070...@debian.org
Bug#639691: updating build-deps for nfs-utils to ease backporting to squeeze
On 08/30/2011 06:16 AM, Daniel Kahn Gillmor wrote: > I concur with Sean Finney that nfs-utils should Build-Depend on > libnfsidmap-dev >= 0.24 to ease backporting. > > I'm hoping to prepare nfs-utils 1.2.4 as a backport for squeeze, and > it'd be nice to modify the source package as minimally as possible. What features do you need/want from 1.2.4? Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e5c7466.4070...@debian.org
Bug#639691: updating build-deps for nfs-utils to ease backporting to squeeze
On 08/30/2011 06:30 PM, Daniel Kahn Gillmor wrote: > On 08/30/2011 01:25 AM, Luk Claes wrote: >> On 08/30/2011 06:16 AM, Daniel Kahn Gillmor wrote: >>> I concur with Sean Finney that nfs-utils should Build-Depend on >>> libnfsidmap-dev >= 0.24 to ease backporting. >>> >>> I'm hoping to prepare nfs-utils 1.2.4 as a backport for squeeze, and >>> it'd be nice to modify the source package as minimally as possible. >> >> What features do you need/want from 1.2.4? > > the version of nfs-utils in squeeze is only capable of using des-cbc-crc > kerberos tickets. This is a poor choice for network security. No one > setting up a modern system should be using plain DES for anything. > > from 1:1.2.3-1: > > - Try to use kernel function to determine supported Kerberos >enctypes (258f10f) (Closes: #474037) > > Taking advantage of this appears to require the kernel from > squeeze-backports as well, but i don't think that's an unreasonable > tradeoff (and i have verified that it works with 2.6.39-bpo.2, currently > in squeeze-backports). Fair enough, just was curious what feature(s) made you think about backporting. Good luck with the backport and please do share your experiences. Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e5d1448.4010...@debian.org
Bug#622146: nfs-common: compatibility between squeeze and sid broken
On 10/03/2011 07:20 PM, Philipp Kern wrote: > On Mon, Sep 05, 2011 at 12:46:13PM -0400, Sam Hartman wrote: >>> "Adam" == Adam D Barratt writes: >> Adam> The krb5 package was uploaded and I've (somewhat belatedly) >> Adam> marked it for acceptance at the next dinstall. What's the >> Adam> status of the nfs-utils upload? >> My guess is they were waiting for krb5. >> Remember they have to increase build-depends for the krb5 you just >> accepted. > > AFAICS this now missed the 6.0.3 point release. Upstream did some changes related to this which should fix it in unstable for the squeeze -> 2.6.35 kernel range. Kernels afterwards should not have the problem. It would be good if someone could confirm that it is really fixed in unstable now. Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e8a1530.9060...@debian.org
Bug#622146: nfs-common: compatibility between squeeze and sid broken
On 09/12/2011 08:24 PM, Adam D. Barratt wrote: > On Mon, 2011-09-05 at 12:46 -0400, Sam Hartman wrote: >>> "Adam" == Adam D Barratt writes: >> >> >> Adam> The krb5 package was uploaded and I've (somewhat belatedly) >> Adam> marked it for acceptance at the next dinstall. What's the >> Adam> status of the nfs-utils upload? >> >> My guess is they were waiting for krb5. >> Remember they have to increase build-depends for the krb5 you just >> accepted. > > If it requires a versioned build-dependency, then both packages could > just have been uploaded at the same time. Even if we accepted them both > from p-u-NEW together, the buildds would have put nfs-common in to the > "build-deps uninstallable" state until the necessary version of krb5 was > available. Anyway, uploaded now. Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ea7b134.60...@debian.org
Bug#682709: NFS4 krb5 mounts hang under nfs-utils 1.2.6-3
On 07/26/2012 05:18 PM, Nicolas Bourdaud wrote: > Since the bug does not seem to be as systematic as I originally thought, > I set the severity back to the one set by the bug reporter. Even if that was not the case, NFS is not only about NFS4 or use with krb5, so anything above important is wrong as long as these other use cases still work. Btw, there are quite some NFS4+krb5 bugs open as none of its maintainers use it that way, would you be willing to help out? Cheers Luk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50117732.3070...@debian.org
Bug#657802: nfs-kernel-server: NFSv4 kerberos mount stopped working after upgrade to 6.0.4 point release
On 01/31/2012 07:41 PM, Petter Reinholdtsen wrote:
> [Andreas B. Mundt]
>> For kerberized NFSv4 on squeeze 6.0.4 you need:
>>
>> [libdefaults]
>> permitted_enctypes = des-cbc-crc
>> allow_weak_crypto = true
>
> This setting broke Kerberos authentication using pam_sss. I found
> lines like this in the server kdc.log:
>
> Jan 31 15:26:42 tjener.intern krb5kdc[16339](info): AS_REQ (4 etypes
> {18 17 16 23}) 10.0.15.1: NEEDED_PREAUTH: pere@INTERN for
> krbtgt/INTERN@INTERN, Additional pre-authentication required
>
> I then looked up what the etypes meant, and found
> http://pig.made-it.com/kerberos-etypes.html > mapping IDs to
> names.
>
> By adding the names for 16-18,23 to krb5.conf on the KDC I was able to
> get pam_sss working again. The result looked like this:
>
> [libdefaults]
> permitted_enctypes = des-cbc-crc rc4-hmac des3-cbc-sha1-kd
> aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha1-96
> allow_weak_crypto = true
>
> I'm not sure which of these etypes should be listed, nor the other
> consequence of listing them like this, but thought it best to mention
> it here.
>
> Is this a good solution? Which of the etypes should one permit? Will
> any of them cause problems with NFSv4 or other systems?
permitted_enctypes lists the permitted enctypes so if you don't mention
one you want to use, it won't work. Though one should not put any in it
unless one wants to restrict the used enctypes.
The allow_weak_crypto = true alone should be enough to get the weak (cbc
ones) to work again AFAIK. Though unless one has old clients that don't
work with stronger encryption it's better to make sure there is a better
encryption method used for the nfs server AFAICT. I guess the
documentation on the wikipage (http://wiki.debian.org/NFS/Kerberos)
should be updated to not mention the cbc one anymore.
Russ: Which enctype is now preferred and could you please update the
above wikipage accordingly, TIA?
Cheers
Luk
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f2839c9.4030...@debian.org
