nfs-utils_2.6.3-4~exp1_sourceonly.changes ACCEPTED into experimental
Thank you for your contribution to Debian.
Accepted:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Mon, 20 Nov 2023 22:13:01 +0100
Source: nfs-utils
Architecture: source
Version: 1:2.6.3-4~exp1
Distribution: experimental
Urgency: medium
Maintainer: Debian kernel team
Changed-By: Salvatore Bonaccorso
Closes: 1051088
Changes:
nfs-utils (1:2.6.3-4~exp1) experimental; urgency=medium
.
* Remove extraneous words left behind by commit 522837f. (Closes: #1051088)
* Install systemd units to /usr/lib/systemd/system
- debian/rules: Drop explicit setting with path for Debian
--with=systemd=/lib/systemd/system and install the systemd units by
default in /usr/lib/systemd/system trough --with-systemd
- debian/nfs-common.install: Install systemd units from
/usr/lib/system/system
- debian/nfs-kernel-server.install: Install systemd units from
/usr/lib/system/system
- debian/*.links: Create symlinks for systemd units from and to
/usr/lib/systemd/system instead of /lib/systemd/system
* debian/rules: Don't force nfsdcltrack and mount helpers into /sbin
* nfs-common: Install {u,}mount.nfs{,4} into /usr/sbin
* nfs-common: lintian-overides: Adjust paths after installation to /usr/sbin
* nfs-kernel-server: Install nfsdcltrack to /usr/sbin
* debian/rules: Update chmod call to fix permissions of /usr/sbin/mount.nfs
* Install rpc.statd, sm-notify and showmount into /usr/sbin
- Install binaries to default locations in /usr/sbin
- Drop now oboslete patches to reference sm-notify from /sbin
- Drop now obsolete patches to change ExecStart to start sm-notify and
rpc.statd from /sbin
Checksums-Sha1:
ed8b216b238ae2c83d64ebfff42f2ad8dcf407c8 2574 nfs-utils_2.6.3-4~exp1.dsc
1dd64b1a9a882ced0f728cb0214ddb3c7de7bbc6 49888
nfs-utils_2.6.3-4~exp1.debian.tar.xz
Checksums-Sha256:
02ddb37b74f6d0d6d309d0b713f6a2ec87e20ac42372905a20e075e15b1c583e 2574
nfs-utils_2.6.3-4~exp1.dsc
4a5cbe446c45d9dacdb7f0b1f4074d018ad4f6c911a27436fffe8bc7be1c9306 49888
nfs-utils_2.6.3-4~exp1.debian.tar.xz
Files:
7911155743269458c2de9a22577930ea 2574 net optional nfs-utils_2.6.3-4~exp1.dsc
c2c56c5e6f6a11f086ebfd270c28a1d1 49888 net optional
nfs-utils_2.6.3-4~exp1.debian.tar.xz
-BEGIN PGP SIGNATURE-
iQKmBAEBCgCQFiEERkRAmAjBceBVMd3uBUy48xNDz0QFAmVbzO5fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDQ2
NDQ0MDk4MDhDMTcxRTA1NTMxRERFRTA1NENCOEYzMTM0M0NGNDQSHGNhcm5pbEBk
ZWJpYW4ub3JnAAoJEAVMuPMTQ89EO0oP/jlNo94pSJdxss82peSldi0QEhcqhnZ2
gsqiWx05geoy0gal6TRysAfl1jzKc1ytwgtpla9CIZ/V3eY+QAgh7dKXdehw45xx
/UF1ec4OTKbhpKN/O98YmeeEijKvdDWodBZp3v3f3RUIN4CozMQq16IRc0TFF/rg
IIWDDlwywjEvox1VEaYn/GkafqkzJyfNSo1nPm2yGb66T/MOO3NJ25Twc06QBHuA
Y3iSb21Tsm/ssWbuXZJdQ8E60SF1E47S4/aoUiHkkEA0jCnmHmnSXNd2R0hMWQKy
4C9X+e30XWJi3RBvZkIYZcJm2LwVIZH7ul7I0vIUMOvlMzeqCmmpz4iUxJJBzXBj
6QKcxZYuc/SQpf6pUgqY2nUs1XeZIAujh/fOQY1gVaK4p3j0lNZd9QTE46b7kvMF
I8PxYwWkhN2Xn0aO3R5HBu7sEYYZNl3ys1U5H1NBywKYRDfa+4c64k4iAm3KH+h+
x4axFA11v33The3Lv5jUa39ypbw/aUTrUpdRzpoCOCDFRVSl73T6BdPPv9cZF+1H
OPtWEkeFqV3FOikx7V5s0NsznM3Ea/4bgEl8lOif6d0I906F8lwNajsUIAw7znhz
9X11Rzx+sun4NYvsZwi3GffDMAXoQJ16NQhTXlObYg2kDWHzLBqC5LpbNAEQ/ErC
uB4TWFm6nZQ3
=rn9+
-END PGP SIGNATURE-
Processing of nfs-utils_2.6.3-4~exp1_sourceonly.changes
nfs-utils_2.6.3-4~exp1_sourceonly.changes uploaded successfully to localhost along with the files: nfs-utils_2.6.3-4~exp1.dsc nfs-utils_2.6.3-4~exp1.debian.tar.xz Greetings, Your Debian queue daemon (running on host usper.debian.org)
Bug#1051088: marked as done (nfs-common: Spurious additional words left behind in EXAMPLES section of nfs(5).)
Your message dated Mon, 20 Nov 2023 21:34:03 + with message-id and subject line Bug#1051088: fixed in nfs-utils 1:2.6.3-4~exp1 has caused the Debian Bug report #1051088, regarding nfs-common: Spurious additional words left behind in EXAMPLES section of nfs(5). to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1051088: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051088 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: nfs-common Version: 1:2.6.2-4 Severity: minor Tags: patch There is a spurious phrase "mount option" at the beginning of the EXAMPLES section. This patch fixes it: >From 0fbe8a874703124107e74f9a96a201ad3b89b60a Mon Sep 17 00:00:00 2001 From: James Youngman Date: Sat, 2 Sep 2023 12:45:18 +0100 Subject: [PATCH] Remove extraneous words left behind by commit 522837f. --- utils/mount/nfs.man | 1 - 1 file changed, 1 deletion(-) diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man index 7a410422..c9850f29 100644 --- a/utils/mount/nfs.man +++ b/utils/mount/nfs.man @@ -986,7 +986,6 @@ file. See .BR nfsmount.conf(5) for details. .SH EXAMPLES -mount option. To mount using NFS version 3, use the .B nfs -- 2.39.2 -- Package-specific info: -- rpcinfo -- program vers proto port service 104 tcp111 portmapper 103 tcp111 portmapper 102 tcp111 portmapper 104 udp111 portmapper 103 udp111 portmapper 102 udp111 portmapper -- /etc/default/nfs-common -- NEED_STATD= STATDOPTS= NEED_IDMAPD= NEED_GSSD= -- /etc/nfs.conf -- [general] pipefs-directory=/run/rpc_pipefs [nfsrahead] [exports] [exportfs] [gssd] [lockd] [exportd] [mountd] manage-gids=y [nfsdcld] [nfsdcltrack] [nfsd] [statd] [sm-notify] [svcgssd] -- /etc/nfs.conf.d/*.conf -- -- /etc/idmapd.conf -- [General] Verbosity = 0 [Mapping] Nobody-User = nobody Nobody-Group = nogroup -- /etc/fstab -- nas-fast:/home /nas/home nfs defaults,auto,nfsvers=4 0 0 nas-fast:/home/james/nas/home/james nfs defaults,auto,nfsvers=4 0 0 nas-fast:/home/maeve/nas/home/maeve nfs defaults,auto,nfsvers=4,sync 0 0 nas-fast:/home/sneezy /nas/home/sneezynfs defaults,auto,nfsvers=4,sync 0 0 ## On kernel version 4.16.0-0.bpo.2-amd64 we seem to get system crashes on some NFS I/O with nfs4. nas-fast:/nas/books /nas/books nfsdefaults,auto,nfsvers=4,sync 0 0 nas-fast:/nas/music /nas/music nfsdefaults,auto,nfsvers=4,sync 0 0 nas-fast:/nas/photo /nas/photo nfsdefaults,auto,nfsvers=4,sync 0 0 nas-fast:/nas/video /nas/video nfs4 defaults,proto=tcp,bg 0 0 nas-fast:/nas/video/Kids /nas/video/Kids nfs4 defaults,proto=tcp,bg 0 0 nas-fast:/nas/video/TV /nas/video/TV nfs4 defaults,proto=tcp,bg 0 0 nas-fast:/nas/video/TV/Comedy /nas/video/TV/Comedy nfs4 defaults,proto=tcp,bg 0 0 nas-fast:/nas/video/TV/Crime /nas/video/TV/Crime nfs4 defaults,proto=tcp,bg 0 0 nas-fast:/nas/video/TV/Documentary /nas/video/TV/Documentary nfs4 defaults,proto=tcp,bg 0 0 nas-fast:/nas/video/TV/Drama /nas/video/TV/Drama nfs4 defaults,proto=tcp,bg 0 0 nas-fast:/nas/video/TV/Tech /nas/video/TV/Tech nfs4 defaults,proto=tcp,bg 0 0 nas-v6:/nas/video/movies /nas/video/movies nfs4 defaults,proto=tcp,bg 0 0 nas:/var/lib/libvirt/images /var/lib/libvirt/images/jupiter nfs defaults,auto,ro 0 0 nas-fast:/nas/install-files /nas/install-files nfs defaults,proto=tcp,bg 0 0 nas-fast:/nas/preservation /nas/preservation nfs defaults,proto=tcp,bg 0 0 nas-fast:/nas/share /nas/share nfs defaults,proto=tcp,bg 0 0 nas-fast:/nas/video/TV/Historical_Drama /nas/video/TV/Historical_Drama nfs4 defaults,proto=tcp,bg 0 0 nas-fast:/nas/video/TV/Medical_Drama /nas/video/TV/Medical_Drama nfs4 defaults,proto=tcp,bg 0 0 nas-fast:/nas/video/TV/Romantic_Comedy /nas/video/TV/Romantic_Comedy nfs4 defaults,proto=tcp,bg 0 0 nas-fast:/nas/video/TV/SF_and_Fantasy /nas/video/TV/SF_and_Fantasy nfs4 defaults,proto=tcp,bg 0 0 -- /proc/mounts -- nas-fast:/nas/music /nas/music nfs4 rw,sync,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.10.1.2,local_lock=none,addr=10.10.1.1 0 0 nas-fast:/nas/preservation /nas/preservation nfs4 rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retra
Processed: limit source to nfs-utils, tagging 1051088
Processing commands for cont...@bugs.debian.org: > limit source nfs-utils Limiting to bugs with field 'source' containing at least one of 'nfs-utils' Limit currently set to 'source':'nfs-utils' > tags 1051088 + pending Bug #1051088 [nfs-common] nfs-common: Spurious additional words left behind in EXAMPLES section of nfs(5). Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 1051088: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051088 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1036644:
Apologies - had meant to report back on this thread as I found a workaround
(for my setup at least).
I found the solution here:
https://wiki.archlinux.org/title/Intel_graphics#Crash/freeze_on_low_power_Intel_CPUs
After setting enable_dc=0 in my kernel boot parameters I have no longer
experienced the issue on LTS 6.1.x kernel on my Intel NUC 8i3BEH running Arch
linux.
I also tried upgrading to kernel 6.4.x where the problem also seems to be
resolved.
Regards,
James.
On Fri, 18 Aug 2023 20:08:09 +0100 James Hutchinson
wrote:
> I am also affected by this, running Arch Linux on my Intel Nuc 8i3beh. I've
> seen these same random mce broadcast error kernel panics (only capturable
> via netconsole) ever since upgrading from the 5.15.x lts kernel series to
> the 6.1.x series - latest I've tried is 6.1.45 and currently back to the
> 5.15.x branch for stability.
>
> I update my Arch Linux installation on a rolling weekly basis so am right
> upto date for all packages including intel-microcode. As others have
> experienced, the problem seems more prominent (though not exclusively) when
> the machine is Idle.
>
> >>Maybe lowering "check_interval" or "monarch_timeout" in machinecheck will
> cause the bug to strike more often, so a git bisect could be possible!? Or
> raising those values may workaround the problem!?
>
> I had similar thoughts and stumbled upon
>
> /sys/kernel/debug/mce/fake_panic
>
> Writing 1 to here will cause a fake panic such that the mce event will be
> logged to dmesg but panic+reboot will not occur.
>
> Interestingly we then get a couple more messages that possibly suggest that
> the core lockup is somehow related to i915 as others suspect
>
> [5.848032] mce: CPUs not responding to MCE broadcast (may include false
> positives): 1,3
> [5.848032] mce: CPUs not responding to MCE broadcast (may include false
> positives): 1,3
> [5.848035] mce: [Hardware Error]: Fake kernel panic: Timeout: Not all
> CPUs entered broadcast exception handler
> [5.848039] Disabling lock debugging due to kernel taint
> [5.885355] mce: [Hardware Error]: Machine check events logged
> [5.888283] mce: [Hardware Error]: CPU 2: Machine Check Exception: 5
> Bank 4: ba0011000402
> [5.892145] mce: [Hardware Error]: RIP !INEXACT! 10:
> {fwtable_read32+0x7d/0x220 [i915]}
> [5.897167] mce: [Hardware Error]: TSC d44e32bae41d
> Might be interesting to see if the
> RIP !INEXACT! 10: {fwtable_read32+0x7d/0x220 [i915]}
> message occurs for others with fake_panic enabled.
>
> Unfortunately, fake_panic does not appear to be a workaround from my
> experience; since the cores reported in the mce event become locked up
> thereafter; such that any task scheduled onto those cores becomes locked-up
> - for example I ran the sensors command which hung and eventually.
>
> 77798.629123] watchdog: BUG: soft lockup - CPU#2 stuck for 21s!
> [sensors:1229265]
> [77798.631037] Modules linked in: coretemp drivetemp netconsole
> xt_conntrack ipt_REJECT nf_reject_ipv4 xt_connmark xt_mark iptable_mangle
> xt_comment xt_addrtype iptable_raw wireguard curve25519_x86_64
> libchacha20poly1305 chacha_x86_64 poly1305_x86_64 libcurve25519_generic
> libchacha ip6_udp_tunnel udp_tunnel rfcomm uinput xt_nat xt_tcpudp
> iptable_nat xt_MASQUERADE nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4
> libcrc32c iptable_filter veth ts2020 snd_sof_pci_intel_cnl
> snd_sof_intel_hda_common soundwire_intel soundwire_generic_allocation
> soundwire_cadence snd_sof_intel_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof
> snd_sof_utils soundwire_bus snd_soc_skl snd_soc_hdac_hda snd_hda_ext_core
> intel_rapl_msr intel_rapl_common snd_soc_sst_ipc intel_tcc_cooling
Bug#1054642: Failing ARP relay from external -> Linux bridge -> veth port --> NS veth port
Hi Daniel,
of course we can steadily move on, no problem. So now we move to VLAN level?
BR
Peter
-Original Message-
From: Daniel Gröber
Sent: sobota 18. novembra 2023 3:43
To: GASPAROVIC Peter OBS/MKT
Cc: 1054...@bugs.debian.org
Subject: Re: Bug#1054642: Failing ARP relay from external -> Linux bridge ->
veth port --> NS veth port
Hi Peter,
On Mon, Nov 13, 2023 at 09:40:46AM +, peter.gasparo...@orange.com wrote:
> In the meantime, I was stubborn to find a solution to what I need in
> order to progress and MACVLAN tech actually delivered it (private mode
> enough),
I used to love macvlan too but now I do L3 instead ;P
> something newer than VETH tech what I could read about, and it's just
> perfect avoiding bridge itself. So no problem to cooperate on this
> fix, I will be glad, just it can get lower priority on your side if
> you even attributed it some 😊
I'd be happy to still track this bug down but I need you to investigate the
behaviour in your environment. If you've torn down the lab already we can also
just call it quits.
If you do want to continue some questions are still pending, see quoted below.
> On Mon, Oct 30, 2023 at 07:25:38PM +, peter.gasparo...@orange.com wrote:
> > 1) As was reported, foreign external world MAC@ does not pass into
> > network namespace, just external border point "vlan199"
>
> How did you check this?
>
> > 2) now collecting data for you, honestly I don’t see external mac
> > address on "inet-br" object, so my previous statement was incorrect..
> > {ossibly I might mixed this up with another "labinet-br" (working in
> > its limited
> > scope) which is IP-defined, while "inet-br" in question is not.
> >
> > 3) so question is, if the MACs learnt via vlan199 are supposed to be
> > paired (displayed) with "inet-br" object and all way up into NS
>
> I want to make sure we're on the same page, how do you check if the MAC is
> reaching into the NS? I assume using `ip neigh`? I'd have a look at tcpdump
> this will tell you whether ARP is even reaching the NS or not.
>
> Something simple like
>
> $ tcpdump -enli $IFACE 'arp or icmp'
>
> optionally you can filter by MAC (`ether host` in pcap-filter speak):
>
> $ tcpdump -enli $IFACE ('arp or icmp) and ether host
> aa:00:00:00:00:01
>
> Oh and one last thing: please double and tripple check that a firewall isn't
> interfering.
--Daniel
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
