[Desktop-packages] [Bug 1872950] Re: Nvidia 340.108 fails to install with kernels 5.5 onward
The problem in line 16 obviously is in "PATCH{7]" which has wrong
brackets.
Tho it needs to be fixed in /usr/src/nvidia-340-340.108/dkms.conf
instead which is the source for the mentioned file in the build tree.
If you already successfully installed the version where the patch didn't
apply, you will most probably need to remove and unbuild the module to
try the build again.
Something like:
dkms remove -m nvidia-340/340.108 -k all
dkms unbuild -m nvidia-340/340.108 -k all
dkms install -m nvidia-340/340.108 -k all
should do the trick. Not tested tho, just our of my memory
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nvidia-graphics-drivers-340 in Ubuntu.
https://bugs.launchpad.net/bugs/1872950
Title:
Nvidia 340.108 fails to install with kernels 5.5 onward
Status in nvidia-graphics-drivers-340 package in Ubuntu:
Fix Committed
Status in nvidia-graphics-drivers-340 source package in Groovy:
Fix Committed
Bug description:
SRU request:
[Impact]
* Installing the 340 driver will fail when running Linux 5.7 or
newer.
[Test Case]
* Install nvidia-340 from -proposed.
* Check that the modules was built and installed, using the
following command:
dkms status
[Regression Potential]
* The driver once built and installed could be not working and lead
to have the desktop not starting for example. Check that you get a
desktop loaded and decent performances
Hi developers,
thanks for your great work on porting legacy drivers to Ubuntu.
Anyway I have to complain in not seeing Nvidia 340.108 driver for
kernels 5.5 and 5.6 yet, leaving users stuck on kernel 5.4,
because Nvidia 340.108 fails to install with kernels 5.5 and 5.6.
Archlinux already has a driver for Kernel 5.6 via AUR
(https://aur.archlinux.org/packages/nvidia-340xx/) and Debian SID has
one for kernel 5.5.
So, the question is: when will we see a new version in repositories?
Bye and have a nice day.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-340/+bug/1872950/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1688018] Re: DNS server from vpn connection is not being used after network-manager upgrade to 1.2.6
This workaround is not bad indeed and saves me, too. But it has drawbacks that people need to know 1) In newer Ubuntu versions, "dnsmasq" is the default DNS option, so the config does not have this option to comment out. Instead you have to set "dns=default" there. 2) With this workaround, some applications need a restart to recognize the new DNS servers after you started VPN. Browsers are a prominent example of reading resolv.conf setup at start and then caching this until restart. 3) The VPN DNS servers are used then, but they are on top of the underlying DNS servers coming from your local DHCP. They are just added to the top of the list. As long as the VPN DNS servers are working, data security is intact. As soon as these stop working, your system might send DNS queries (that maybe should be confidential) to the underlying DNS server. Issues 2 and 3 are the most dangerous as they can compromise VPN confidentiality. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1688018 Title: DNS server from vpn connection is not being used after network-manager upgrade to 1.2.6 Status in network-manager package in Ubuntu: Triaged Status in network-manager source package in Xenial: In Progress Status in network-manager source package in Yakkety: Triaged Bug description: This was initially opened as #1671606 then later duped to #1639776. Discussion in #1639776 indicate that we need new bug for this so I am opening one ... Please don't mark this as duplicate to #1639776 or other similar bug report. We already lost several months and we are again at beginning ... TL;DR; -> network-manager-1.2.2-0ubuntu0.16.04.4 use DNS defined by VPN (correct). network-manager-1.2.6-0ubuntu0.16.04.1 use DNS from DHCP instead of one defined by VPN (wrong). DNS resolver should query only DNS servers defined by VPN while connection is active. = Test steps / result: - upgraded network-manager to 1.2.6-0ubuntu0.16.04.1 (dnsmasq-base-2.75-1ubuntu0.16.04.2) - restated my laptop to ensure clean start - connected to VPN using openconnect / network-manager-openconnect-gnome Observed results -> DNS queries are forwarded only to DNS servers defined by LAN connection (this is wrong / connection not working at all) - "killall dnsmasq" - dnsmasq get automatically restarted by system Observed results -> most of the the queries are forwarded to DNS servers defined by VPN, but lot of queries get forwarded to DNS servers defined by LAN connection (this is still wrong / DNS leaks, attacker can hijack connection even if VPN is enabled) - I downgraded back network-manager to 1.2.2-0ubuntu0.16.04.4 (dnsmasq-base stay same) - restated my laptop to ensure clean test - connected to same VPN using openconnect Observed results -> DNS queries are forwarded only to DNS servers defined by VPN connection. There are no leaks to LAN DNS server (this is correct behavior). = Paul Smith requested additional details in #1639776. Here are: * If you're using IPv4 vs. IPv6 -> IPv4 only. I have IPv6 set to ignore on all network definition (lan / wifi /vpn) * If you have checked or unchecked the "Use this connection only for resources on its network" -> unchecked on all nw definition * If you have this checked, try unchecking it and see if that makes a difference -> no change if I toggle this option. Behavior is same. * When you say "DNS lookups" please be clear about whether the hostnames being looked up are public (e.g., www.google.com or whatever), on your local LAN, or in the network accessed via the VPN. Does it make a difference which one you choose? -> No difference. * Are you using fully-qualified hostnames, or relying on the DNS domain search path? Does it make a difference if you do it differently? -> I normaly use FQDN due to nature of HTTPs cert validation. I don't see difference when I try same using hostname + domain search. = I am using openconnect (cisco) and openvpn. Test result are by using openconnect but I saw same behaviour also while using openvpn. = Thanks Lukas To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1688018/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1707352] Re: the change from libsane to libsane1 broke many (all?) 3rd party plug-ins for sane
The status for Artful is "fix committed". I think that's a mistake. With the committed sane version in artful-proposed, the iscan package does not install like described above, and when installed forcefully, it does not recognize the scanner. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to sane-backends in Ubuntu. https://bugs.launchpad.net/bugs/1707352 Title: the change from libsane to libsane1 broke many (all?) 3rd party plug- ins for sane Status in sane-backends package in Ubuntu: Fix Committed Status in sane-backends source package in Artful: Fix Committed Status in sane-backends package in Debian: New Bug description: Impact == The Debian maintainer renamed libsane to libsane1-experimental "to match with the soname". This apparently fixes a Lintian warning. Also the soname change might be justified by the new version breaking most 3rd party plug-ins even if the library version number doesn't any bigger change than any ordinary new version of the library: libsane 1.0.25 in zesty includes libsane.so.1.25 libsane1 1.0.27 in artful includes libsane.so.1.27 The breaking of all plug-ins might be an upstream bug - which is allowed in an experimental package, but is unfortunate as in Ubuntu this package went mainstream; The library rename is an additional factor that makes it impossible to install any scanner drivers for libsane that are distributed as a .deb unless the driver distributors recompiles against Ubuntu 17.10+. It is to note that depending on the manufacturer for many old scanners there won't be new versions of the plug-ins that are recompiled like this; Adding a Provides: libsane to the library might therefore make some plug-ins work, perhaps. Test Case = Visit http://support.epson.net/linux/en/iscan_c.html Download the amd64 deb .tar.gz Unzip it. Install the iscan .deb from the core folder. It won't install before this SRU because it Depends: libsane Regression Potential The fix here was proposed to the Debian maintainer in July but there's been virtually zero response on it. In the meantime the workaround that was proposed initially has started to result in automatically uninstalling gtk - which makes the system basically useless. It doesn't seem like adding the Provides will make things any worse for third-party drivers but it has a goodme chance of making things better for some. Impossibility of workarounds Just installing an old version of libsane is impossible as it uninstalls libgtk (which depends on libsane1 which conflicts with libsane) making the system basically useless. Original Bug Report === I don't know if that can be prevented in the long run. But both brscan (for my brother scanner) and iscan (for my epson scanners) have been broken by the change from libsane to libsane1. For iscan I have unpackaged the debian package, changed the dependency it contains from libsane to libsane1 and installed the changed package. But even then my epson scanners no more work leaving me without any scanner => Reporting a bug. ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: libsane1 1.0.27-1~experimental1ubuntu2 Uname: Linux 4.13.0-041300rc2-lowlatency x86_64 ApportVersion: 2.20.6-0ubuntu4 Architecture: amd64 Date: Sat Jul 29 08:38:15 2017 EcryptfsInUse: Yes SourcePackage: sane-backends UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sane-backends/+bug/1707352/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1539513] Re: networkmanager segfaults with 3.2.21-1ubuntu1
For having temporary wired network to make the downgrade suggested in #8, you could do: ifconfig eth0 up && dhcpcd eth0 & Wireless of course is more tricky. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to libnl3 in Ubuntu. https://bugs.launchpad.net/bugs/1539513 Title: networkmanager segfaults with 3.2.21-1ubuntu1 Status in libnl3 package in Ubuntu: Confirmed Bug description: Description:Ubuntu 14.04.3 LTS Release:14.04 After upgrading to 3.2.21-1ubuntu1 network-manager 0.9.8.8-0ubuntu7.2 segfaults: [ 21.367977] init: network-manager main process (1000) killed by SEGV signal [ 21.367989] init: network-manager main process ended, respawning [ 21.424932] init: network-manager main process (1060) killed by SEGV signal [ 21.424943] init: network-manager main process ended, respawning [ 21.451519] init: network-manager main process (1066) killed by SEGV signal [...] xxx@yyy:/tmp/bla# gdb /usr/sbin/NetworkManager CoreDump [...] Reading symbols from /usr/sbin/NetworkManager...(no debugging symbols found)...done. [New LWP 3550] [New LWP 3551] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `NetworkManager'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00469fee in nm_netlink_monitor_attach () To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1539513/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1024955] Re: Changing volume while parec records monitor causes sound to studder
still present in Pulseaudio 4.0 on Ubuntu 13.10
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1024955
Title:
Changing volume while parec records monitor causes sound to studder
Status in “pulseaudio” package in Ubuntu:
Confirmed
Bug description:
Changing volume while parec records monitor causes recorded sound to
stutter (synonyms: lag, jump, skips). The output sound does not
studder or lag, only the file of the recording suffers from the volume
modification. This was tested on audio coming from Firefox/Flash as
well as VLC. Both applications produce the same result.
How to reproduce:
1) Use the following script which finds the monitor pseudo-device and records
its output to a file using sox.
#!/bin/bash
#This script requires sox, if not installed, run sudo apt-get install sox
command first.
# Get PA sink monitor name:
MONITOR=$(pactl list | grep -A2 '^Source #' | grep 'Name: .*\.monitor$' |
awk '{print $NF}' | tail -n1)
# Record monitor output
echo Recording from $MONITOR
echo Press Ctrl-C or close window to stop recording
parec -d $MONITOR | sox -t raw -r 44100 -sLb 16 -c 2 - ~/output.wav
2) While it is recording, play with the volume controls (top panel
volume/speaker icon) to bring the volume all the way down, and then
all the way up using your mouses scroll wheel or touchpads scroll
functionality.
Result: recorded sound stutter or lags
Expected: monitor device is not linked to output volume therefore
sound should be recorded without interference from regular system use.
Question: Trying to find the cause of the interference is beyond me.
Could this issue be related to sox? If so, could someone recommend or
test this script with a different program?
ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: pulseaudio-utils 1:1.1-0ubuntu15.1
ProcVersionSignature: Ubuntu 3.2.0-26.41-generic-pae 3.2.19
Uname: Linux 3.2.0-26-generic-pae i686
NonfreeKernelModules: wl
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
AplayDevices:
List of PLAYBACK Hardware Devices
card 0: Intel [HDA Intel], device 0: ALC268 Analog [ALC268 Analog]
Subdevices: 0/1
Subdevice #0: subdevice #0
ApportVersion: 2.0.1-0ubuntu8
Architecture: i386
ArecordDevices:
List of CAPTURE Hardware Devices
card 0: Intel [HDA Intel], device 0: ALC268 Analog [ALC268 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
AudioDevicesInUse:
USERPID ACCESS COMMAND
/dev/snd/controlC0: komputes 1936 F pulseaudio
komputes 3871 F pulseaudio
/dev/snd/pcmC0D0p: komputes 3871 F...m pulseaudio
Card0.Amixer.info:
Card hw:0 'Intel'/'HDA Intel at 0xf054 irq 44'
Mixer name : 'Realtek ALC268'
Components : 'HDA:10ec0268,102802b0,00100101'
Controls : 17
Simple ctrls : 10
Date: Sun Jul 15 08:30:10 2012
InstallationMedia: Ubuntu 12.04 LTS Precise Pangolin - Release i386
(20120423.2)
ProcEnviron:
TERM=xterm
PATH=(custom, user)
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: pulseaudio
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/09/2010
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A07
dmi.board.name: CN0J14
dmi.board.vendor: Dell Inc.
dmi.board.version: A07
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.chassis.version: A07
dmi.modalias:
dmi:bvnDellInc.:bvrA07:bd04/09/2010:svnDellInc.:pnInspiron910:pvrA07:rvnDellInc.:rnCN0J14:rvrA07:cvnDellInc.:ct8:cvrA07:
dmi.product.name: Inspiron 910
dmi.product.version: A07
dmi.sys.vendor: Dell Inc.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1024955/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1024955] Re: Changing volume while parec records monitor causes sound to studder
Hello Raymond. I do not really understand what your message means to us
or what we should do in your opinion. Either the grammar on this
sentence is wrong, or my english is worse than I thought. Nevertheless
thank you for pointing out stream volumes and sink volume. Because of
that I was to add:
If you have 3 streams connected to one sink, and then one stream changes
volume, then the whole sink is rewinded. I am rather sure, that it's
this rewind that breaks the audio stream you can record from the
sink.monitor source.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1024955
Title:
Changing volume while parec records monitor causes sound to studder
Status in “pulseaudio” package in Ubuntu:
Incomplete
Bug description:
Changing volume while parec records monitor causes recorded sound to
stutter (synonyms: lag, jump, skips). The output sound does not
studder or lag, only the file of the recording suffers from the volume
modification. This was tested on audio coming from Firefox/Flash as
well as VLC. Both applications produce the same result.
How to reproduce:
1) Use the following script which finds the monitor pseudo-device and records
its output to a file using sox.
#!/bin/bash
#This script requires sox, if not installed, run sudo apt-get install sox
command first.
# Get PA sink monitor name:
MONITOR=$(pactl list | grep -A2 '^Source #' | grep 'Name: .*\.monitor$' |
awk '{print $NF}' | tail -n1)
# Record monitor output
echo Recording from $MONITOR
echo Press Ctrl-C or close window to stop recording
parec -d $MONITOR | sox -t raw -r 44100 -sLb 16 -c 2 - ~/output.wav
2) While it is recording, play with the volume controls (top panel
volume/speaker icon) to bring the volume all the way down, and then
all the way up using your mouses scroll wheel or touchpads scroll
functionality.
Result: recorded sound stutter or lags
Expected: monitor device is not linked to output volume therefore
sound should be recorded without interference from regular system use.
Question: Trying to find the cause of the interference is beyond me.
Could this issue be related to sox? If so, could someone recommend or
test this script with a different program?
ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: pulseaudio-utils 1:1.1-0ubuntu15.1
ProcVersionSignature: Ubuntu 3.2.0-26.41-generic-pae 3.2.19
Uname: Linux 3.2.0-26-generic-pae i686
NonfreeKernelModules: wl
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
AplayDevices:
List of PLAYBACK Hardware Devices
card 0: Intel [HDA Intel], device 0: ALC268 Analog [ALC268 Analog]
Subdevices: 0/1
Subdevice #0: subdevice #0
ApportVersion: 2.0.1-0ubuntu8
Architecture: i386
ArecordDevices:
List of CAPTURE Hardware Devices
card 0: Intel [HDA Intel], device 0: ALC268 Analog [ALC268 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
AudioDevicesInUse:
USERPID ACCESS COMMAND
/dev/snd/controlC0: komputes 1936 F pulseaudio
komputes 3871 F pulseaudio
/dev/snd/pcmC0D0p: komputes 3871 F...m pulseaudio
Card0.Amixer.info:
Card hw:0 'Intel'/'HDA Intel at 0xf054 irq 44'
Mixer name : 'Realtek ALC268'
Components : 'HDA:10ec0268,102802b0,00100101'
Controls : 17
Simple ctrls : 10
Date: Sun Jul 15 08:30:10 2012
InstallationMedia: Ubuntu 12.04 LTS Precise Pangolin - Release i386
(20120423.2)
ProcEnviron:
TERM=xterm
PATH=(custom, user)
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: pulseaudio
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/09/2010
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A07
dmi.board.name: CN0J14
dmi.board.vendor: Dell Inc.
dmi.board.version: A07
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.chassis.version: A07
dmi.modalias:
dmi:bvnDellInc.:bvrA07:bd04/09/2010:svnDellInc.:pnInspiron910:pvrA07:rvnDellInc.:rnCN0J14:rvrA07:cvnDellInc.:ct8:cvrA07:
dmi.product.name: Inspiron 910
dmi.product.version: A07
dmi.sys.vendor: Dell Inc.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1024955/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1244619]
In case you did not click the launchpad link above, here my me too: As of today, Ubuntu Saucy is still shipping Thunderbird 24.0.0. But the extentions are of course updated nevertheless. That left me with a Thunderbird 24.0.0 and Lightning 2.6.1 which shows exactly the same issue as running TB 24.0.1 with Lightning 2.6.0. Manually installing TB 24.0.1 to my ~/opt/ fixed the problem, but it took me ages to puzzle that out. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to thunderbird in Ubuntu. https://bugs.launchpad.net/bugs/1244619 Title: Thunderbird must be upgraded to Thunderbird 24.0.1 for lightning 2.6.1 Status in Lightning extension: Confirmed Status in “lightning-extension” package in Ubuntu: Confirmed Status in “thunderbird” package in Ubuntu: Confirmed Status in “thunderbird” package in Gentoo Linux: Fix Released Status in “thunderbird” package in openSUSE: Confirmed Bug description: Since the upgrade of Lightning 2.6.0 to Lightning 2.6.1, this extension need Thunderbird 24.0.1 but Ubuntu only give Thunderbird 24.0.0 https://blog.mozilla.org/calendar/2013/10/dont-upgrade-to-thunderbird-24-0-1-yet/ Update 4: Lightning 2.6.1 is now public. On Linux, it is compatible ONLY with Thunderbird 24.0.1, so go ahead and upgrade now. A lot of people don't use the Ubuntu package for Lightning but those of Mozilla. Ubuntu should give an upgrade to Thunderbird 24.0.1 and Lightning 2.6.1 Step: 1) Silent update of Lightning 2.6.0 to Lightning 2.6.1 on Thunderbird 24.0.0 2) Open your calendar and see nothing (see screencast) A work form it's to downgrade to Lightning 2.6 until waiting Ubuntu upgrade to Thunderbird 24.0.1. You could find it here: https://addons.mozilla.org/fr/thunderbird/addon/lightning/versions/?page=1#version-2.6 ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: thunderbird 1:24.0+build1-0ubuntu0.12.04.1 ProcVersionSignature: Ubuntu 3.8.0-32.47~precise1-generic 3.8.13.10 Uname: Linux 3.8.0-32-generic x86_64 ApportVersion: 2.0.1-0ubuntu17.6 Architecture: amd64 BuildID: 20130913160939 Date: Fri Oct 25 12:30:44 2013 InstallationMedia: Ubuntu 12.04 Precise - Build amd64 LIVE Binary 20120425-15:28 MarkForUpload: True SourcePackage: thunderbird UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/lightning-extension/+bug/1244619/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 963106] Re: NetworkManager causes orphaned inodes
I fixed it for me in upstart, modifying /etc/init/network-manager.conf.
Patch attached.
** Patch added: umount-fix.patch
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/963106/+attachment/3468459/+files/umount-fix.patch
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/963106
Title:
NetworkManager causes orphaned inodes
Status in “network-manager” package in Ubuntu:
Fix Released
Status in “network-manager” source package in Precise:
Fix Released
Bug description:
[Impact]
On shutdown, dhclient isn't getting reaped by NetworkManager, despite being
kept running through sendsigs so as not to disrupt remote filesystems (and
their unmounting at shutdown). dhclient may be keeping open files for its lease
files, which causes issues when unmounting /var/lib, which contains those lease
files.
[Development Fix]
Remove support for connection assumption, which is meant to bring
NetworkManager up to speed with connections that may have already be up during
a restart of the daemon. Since we don't actually restart the daemon
automatically (and instead suggest a restart of the system after upgrade) and
the advantage is minimal compared to the impact on users of this interacting
with the shutdown sequence, patch connection assumption out of the NM code and
just always take down dhclient when NM stops.
[Stable Fix]
See above Development fix.
[Test Case]
1) Shut down coputer.
2) In the shutdown process, perhaps as a post-stop script in
/etc/init/network-manager, track down open files for the dhclient pid (which
should be available from /run/sendsigs.omit.d/network-manager.dhclient{6,}.pid)
[Regression Potential]
Minimal, only affects bringing NetworkManager up on a restart of the daemon
(sudo restart network-manager or /etc/init.d/network-manager restart), which
improves on the speed of this operation and avoid resetting the connection if
it's already up.
-
During system shutdown, NetworkManager neither kills dhclient nor does
it remove the dhclient pid file from the directory
/var/run/sendsigs.omit.d. As a result, dhclient continues to hold the
pid file open for write and when /etc/init.d/umountroot tries to
remount the root filesystem read-only, the remount fails. The
message:
mount: / is busy
is seen in the console, and the filesystem must be recovered at boot
time:
[8.946427] EXT4-fs (sda1): INFO: recovery required on readonly filesystem
[8.947057] EXT4-fs (sda1): write access will be enabled during recovery
[ 11.234075] EXT4-fs (sda1): recovery complete
If shared libraries used by dhclient are updated before the reboot,
orphaned inodes associated with the .so files are created. For
example, doing sudo apt-get install --reinstall libc6 and then
rebooting leads to:
[8.356521] EXT4-fs (sda1): INFO: recovery required on readonly filesystem
[8.356521] EXT4-fs (sda1): write access will be enabled during recovery
[8.716544] EXT4-fs (sda1): orphan cleanup on readonly fs
[8.716544] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced
inode 313749
[8.724544] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced
inode 313733
[8.724544] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced
inode 313725
[8.724544] EXT4-fs (sda1): 3 orphan inodes deleted
[8.728544] EXT4-fs (sda1): recovery complete
This is network-manager 0.9.3.995+git201203152001.04b2a74-0ubuntu1
running under 12.04. I don't believe any actual data loss will occur
as a result of this bug, but it's likely to produce much user anxiety.
Also see Bug 952315, which misidentifies the cause of the problems as
upstart.
ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: network-manager 0.9.3.995+git201203152001.04b2a74-0ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-20.32-generic 3.2.12
Uname: Linux 3.2.0-20-generic i686
ApportVersion: 1.95-0ubuntu1
Architecture: i386
CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211
not found.
Date: Fri Mar 23 07:42:20 2012
InstallationMedia: Ubuntu 11.10 Oneiric Ocelot - Release i386 (20111011)
IwConfig:
lono wireless extensions.
eth0 no wireless extensions.
NetworkManager.state:
[main]
NetworkingEnabled=true
WirelessEnabled=true
WWANEnabled=true
WimaxEnabled=true
ProcEnviron:
TERM=xterm
LANG=en_US.UTF-8
SHELL=/bin/bash
RfKill:
SourcePackage: network-manager
UpgradeStatus: Upgraded to precise on 2012-03-02 (20 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/963106/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More
[Desktop-packages] [Bug 963106] Re: NetworkManager causes orphaned inodes
For some reason, the main issue of this report now hit me. Root cannot
be unmounted, because dhclient and dnsmasq is still running at this
point (verified by running lsof in umountroot).
The order of my init scripts is still fine now, I have S35networking,
S40umountfs and S60umountroot, so this is not the cause anymore.
Also when stopping networking manually, dhclient and dnsmasq are both
still running.
I took the time to update to 12.10 (quantal), but still no change to
this issue for me. My workaround is a killall dnsmasq dhclient; sleep
2 in umountroot, but obviously, this doesn't even count as dirty hack,
this is even more ugly.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/963106
Title:
NetworkManager causes orphaned inodes
Status in “network-manager” package in Ubuntu:
Fix Released
Status in “network-manager” source package in Precise:
Fix Released
Bug description:
[Impact]
On shutdown, dhclient isn't getting reaped by NetworkManager, despite being
kept running through sendsigs so as not to disrupt remote filesystems (and
their unmounting at shutdown). dhclient may be keeping open files for its lease
files, which causes issues when unmounting /var/lib, which contains those lease
files.
[Development Fix]
Remove support for connection assumption, which is meant to bring
NetworkManager up to speed with connections that may have already be up during
a restart of the daemon. Since we don't actually restart the daemon
automatically (and instead suggest a restart of the system after upgrade) and
the advantage is minimal compared to the impact on users of this interacting
with the shutdown sequence, patch connection assumption out of the NM code and
just always take down dhclient when NM stops.
[Stable Fix]
See above Development fix.
[Test Case]
1) Shut down coputer.
2) In the shutdown process, perhaps as a post-stop script in
/etc/init/network-manager, track down open files for the dhclient pid (which
should be available from /run/sendsigs.omit.d/network-manager.dhclient{6,}.pid)
[Regression Potential]
Minimal, only affects bringing NetworkManager up on a restart of the daemon
(sudo restart network-manager or /etc/init.d/network-manager restart), which
improves on the speed of this operation and avoid resetting the connection if
it's already up.
-
During system shutdown, NetworkManager neither kills dhclient nor does
it remove the dhclient pid file from the directory
/var/run/sendsigs.omit.d. As a result, dhclient continues to hold the
pid file open for write and when /etc/init.d/umountroot tries to
remount the root filesystem read-only, the remount fails. The
message:
mount: / is busy
is seen in the console, and the filesystem must be recovered at boot
time:
[8.946427] EXT4-fs (sda1): INFO: recovery required on readonly filesystem
[8.947057] EXT4-fs (sda1): write access will be enabled during recovery
[ 11.234075] EXT4-fs (sda1): recovery complete
If shared libraries used by dhclient are updated before the reboot,
orphaned inodes associated with the .so files are created. For
example, doing sudo apt-get install --reinstall libc6 and then
rebooting leads to:
[8.356521] EXT4-fs (sda1): INFO: recovery required on readonly filesystem
[8.356521] EXT4-fs (sda1): write access will be enabled during recovery
[8.716544] EXT4-fs (sda1): orphan cleanup on readonly fs
[8.716544] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced
inode 313749
[8.724544] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced
inode 313733
[8.724544] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced
inode 313725
[8.724544] EXT4-fs (sda1): 3 orphan inodes deleted
[8.728544] EXT4-fs (sda1): recovery complete
This is network-manager 0.9.3.995+git201203152001.04b2a74-0ubuntu1
running under 12.04. I don't believe any actual data loss will occur
as a result of this bug, but it's likely to produce much user anxiety.
Also see Bug 952315, which misidentifies the cause of the problems as
upstart.
ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: network-manager 0.9.3.995+git201203152001.04b2a74-0ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-20.32-generic 3.2.12
Uname: Linux 3.2.0-20-generic i686
ApportVersion: 1.95-0ubuntu1
Architecture: i386
CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211
not found.
Date: Fri Mar 23 07:42:20 2012
InstallationMedia: Ubuntu 11.10 Oneiric Ocelot - Release i386 (20111011)
IwConfig:
lono wireless extensions.
eth0 no wireless extensions.
NetworkManager.state:
[main]
NetworkingEnabled=true
WirelessEnabled=true
WWANEnabled=true
WimaxEnabled=true
ProcEnviron:
TERM=xterm
LANG=en_US.UTF-8
SHELL=/bin/bash
[Desktop-packages] [Bug 963106] Re: NetworkManager causes orphaned inodes
I fear I cannot verify this fix :(
I'm still suffering from this problem, using:
network-manager/precise uptodate 0.9.4.0-0ubuntu4
All the networkmanager stuff wants to terminate AFTER the umountroot
script. I used halt to shutdown the sytem without poweroff and made a
screenshot to show you (see attached umountroot_fail.jpg).
Please help, as I really fear for my file system... :-S
** Attachment added: screenshot of nm stuff terminating after umount
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/963106/+attachment/3141347/+files/umountroot_fail.jpg
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/963106
Title:
NetworkManager causes orphaned inodes
Status in “network-manager” package in Ubuntu:
Fix Released
Status in “network-manager” source package in Precise:
Fix Released
Bug description:
[Impact]
On shutdown, dhclient isn't getting reaped by NetworkManager, despite being
kept running through sendsigs so as not to disrupt remote filesystems (and
their unmounting at shutdown). dhclient may be keeping open files for its lease
files, which causes issues when unmounting /var/lib, which contains those lease
files.
[Development Fix]
Remove support for connection assumption, which is meant to bring
NetworkManager up to speed with connections that may have already be up during
a restart of the daemon. Since we don't actually restart the daemon
automatically (and instead suggest a restart of the system after upgrade) and
the advantage is minimal compared to the impact on users of this interacting
with the shutdown sequence, patch connection assumption out of the NM code and
just always take down dhclient when NM stops.
[Stable Fix]
See above Development fix.
[Test Case]
1) Shut down coputer.
2) In the shutdown process, perhaps as a post-stop script in
/etc/init/network-manager, track down open files for the dhclient pid (which
should be available from /run/sendsigs.omit.d/network-manager.dhclient{6,}.pid)
[Regression Potential]
Minimal, only affects bringing NetworkManager up on a restart of the daemon
(sudo restart network-manager or /etc/init.d/network-manager restart), which
improves on the speed of this operation and avoid resetting the connection if
it's already up.
-
During system shutdown, NetworkManager neither kills dhclient nor does
it remove the dhclient pid file from the directory
/var/run/sendsigs.omit.d. As a result, dhclient continues to hold the
pid file open for write and when /etc/init.d/umountroot tries to
remount the root filesystem read-only, the remount fails. The
message:
mount: / is busy
is seen in the console, and the filesystem must be recovered at boot
time:
[8.946427] EXT4-fs (sda1): INFO: recovery required on readonly filesystem
[8.947057] EXT4-fs (sda1): write access will be enabled during recovery
[ 11.234075] EXT4-fs (sda1): recovery complete
If shared libraries used by dhclient are updated before the reboot,
orphaned inodes associated with the .so files are created. For
example, doing sudo apt-get install --reinstall libc6 and then
rebooting leads to:
[8.356521] EXT4-fs (sda1): INFO: recovery required on readonly filesystem
[8.356521] EXT4-fs (sda1): write access will be enabled during recovery
[8.716544] EXT4-fs (sda1): orphan cleanup on readonly fs
[8.716544] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced
inode 313749
[8.724544] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced
inode 313733
[8.724544] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced
inode 313725
[8.724544] EXT4-fs (sda1): 3 orphan inodes deleted
[8.728544] EXT4-fs (sda1): recovery complete
This is network-manager 0.9.3.995+git201203152001.04b2a74-0ubuntu1
running under 12.04. I don't believe any actual data loss will occur
as a result of this bug, but it's likely to produce much user anxiety.
Also see Bug 952315, which misidentifies the cause of the problems as
upstart.
ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: network-manager 0.9.3.995+git201203152001.04b2a74-0ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-20.32-generic 3.2.12
Uname: Linux 3.2.0-20-generic i686
ApportVersion: 1.95-0ubuntu1
Architecture: i386
CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211
not found.
Date: Fri Mar 23 07:42:20 2012
InstallationMedia: Ubuntu 11.10 Oneiric Ocelot - Release i386 (20111011)
IwConfig:
lono wireless extensions.
eth0 no wireless extensions.
NetworkManager.state:
[main]
NetworkingEnabled=true
WirelessEnabled=true
WWANEnabled=true
WimaxEnabled=true
ProcEnviron:
TERM=xterm
LANG=en_US.UTF-8
SHELL=/bin/bash
RfKill:
SourcePackage: network-manager
UpgradeStatus: Upgraded
[Desktop-packages] [Bug 963106] Re: NetworkManager causes orphaned inodes
Additionally I let umountroot make a ps -ef and a lsof -nP just before
trying to remount readonly. The output is attached, too (see
safe.root.debug.txt)
** Attachment added: ps -ef and a lsof -nP just before trying to remount
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/963106/+attachment/3141349/+files/safe.root.debug.txt
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/963106
Title:
NetworkManager causes orphaned inodes
Status in “network-manager” package in Ubuntu:
Fix Released
Status in “network-manager” source package in Precise:
Fix Released
Bug description:
[Impact]
On shutdown, dhclient isn't getting reaped by NetworkManager, despite being
kept running through sendsigs so as not to disrupt remote filesystems (and
their unmounting at shutdown). dhclient may be keeping open files for its lease
files, which causes issues when unmounting /var/lib, which contains those lease
files.
[Development Fix]
Remove support for connection assumption, which is meant to bring
NetworkManager up to speed with connections that may have already be up during
a restart of the daemon. Since we don't actually restart the daemon
automatically (and instead suggest a restart of the system after upgrade) and
the advantage is minimal compared to the impact on users of this interacting
with the shutdown sequence, patch connection assumption out of the NM code and
just always take down dhclient when NM stops.
[Stable Fix]
See above Development fix.
[Test Case]
1) Shut down coputer.
2) In the shutdown process, perhaps as a post-stop script in
/etc/init/network-manager, track down open files for the dhclient pid (which
should be available from /run/sendsigs.omit.d/network-manager.dhclient{6,}.pid)
[Regression Potential]
Minimal, only affects bringing NetworkManager up on a restart of the daemon
(sudo restart network-manager or /etc/init.d/network-manager restart), which
improves on the speed of this operation and avoid resetting the connection if
it's already up.
-
During system shutdown, NetworkManager neither kills dhclient nor does
it remove the dhclient pid file from the directory
/var/run/sendsigs.omit.d. As a result, dhclient continues to hold the
pid file open for write and when /etc/init.d/umountroot tries to
remount the root filesystem read-only, the remount fails. The
message:
mount: / is busy
is seen in the console, and the filesystem must be recovered at boot
time:
[8.946427] EXT4-fs (sda1): INFO: recovery required on readonly filesystem
[8.947057] EXT4-fs (sda1): write access will be enabled during recovery
[ 11.234075] EXT4-fs (sda1): recovery complete
If shared libraries used by dhclient are updated before the reboot,
orphaned inodes associated with the .so files are created. For
example, doing sudo apt-get install --reinstall libc6 and then
rebooting leads to:
[8.356521] EXT4-fs (sda1): INFO: recovery required on readonly filesystem
[8.356521] EXT4-fs (sda1): write access will be enabled during recovery
[8.716544] EXT4-fs (sda1): orphan cleanup on readonly fs
[8.716544] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced
inode 313749
[8.724544] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced
inode 313733
[8.724544] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced
inode 313725
[8.724544] EXT4-fs (sda1): 3 orphan inodes deleted
[8.728544] EXT4-fs (sda1): recovery complete
This is network-manager 0.9.3.995+git201203152001.04b2a74-0ubuntu1
running under 12.04. I don't believe any actual data loss will occur
as a result of this bug, but it's likely to produce much user anxiety.
Also see Bug 952315, which misidentifies the cause of the problems as
upstart.
ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: network-manager 0.9.3.995+git201203152001.04b2a74-0ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-20.32-generic 3.2.12
Uname: Linux 3.2.0-20-generic i686
ApportVersion: 1.95-0ubuntu1
Architecture: i386
CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211
not found.
Date: Fri Mar 23 07:42:20 2012
InstallationMedia: Ubuntu 11.10 Oneiric Ocelot - Release i386 (20111011)
IwConfig:
lono wireless extensions.
eth0 no wireless extensions.
NetworkManager.state:
[main]
NetworkingEnabled=true
WirelessEnabled=true
WWANEnabled=true
WimaxEnabled=true
ProcEnviron:
TERM=xterm
LANG=en_US.UTF-8
SHELL=/bin/bash
RfKill:
SourcePackage: network-manager
UpgradeStatus: Upgraded to precise on 2012-03-02 (20 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/963106/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
[Desktop-packages] [Bug 963106] Re: NetworkManager causes orphaned inodes
Thank you so much Mathieu, that was a stunning catch. Something
obviously shuffled my rc links around O.o
I once (months ago) had the problem that vmware player was changing the
position of halt but seemingly it changed a lot more :(
Anyway: Obviously my problem is not this bug and I'm now sure this bug
really is solved. I will now fix my script links... If anybody has an
idea how I can easily reset them to their defaults, I would be very
pleased. Using update-rc.d -f scriptname remove and then ...
defaults did not work, as it sets everything to 20 only.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/963106
Title:
NetworkManager causes orphaned inodes
Status in “network-manager” package in Ubuntu:
Fix Released
Status in “network-manager” source package in Precise:
Fix Released
Bug description:
[Impact]
On shutdown, dhclient isn't getting reaped by NetworkManager, despite being
kept running through sendsigs so as not to disrupt remote filesystems (and
their unmounting at shutdown). dhclient may be keeping open files for its lease
files, which causes issues when unmounting /var/lib, which contains those lease
files.
[Development Fix]
Remove support for connection assumption, which is meant to bring
NetworkManager up to speed with connections that may have already be up during
a restart of the daemon. Since we don't actually restart the daemon
automatically (and instead suggest a restart of the system after upgrade) and
the advantage is minimal compared to the impact on users of this interacting
with the shutdown sequence, patch connection assumption out of the NM code and
just always take down dhclient when NM stops.
[Stable Fix]
See above Development fix.
[Test Case]
1) Shut down coputer.
2) In the shutdown process, perhaps as a post-stop script in
/etc/init/network-manager, track down open files for the dhclient pid (which
should be available from /run/sendsigs.omit.d/network-manager.dhclient{6,}.pid)
[Regression Potential]
Minimal, only affects bringing NetworkManager up on a restart of the daemon
(sudo restart network-manager or /etc/init.d/network-manager restart), which
improves on the speed of this operation and avoid resetting the connection if
it's already up.
-
During system shutdown, NetworkManager neither kills dhclient nor does
it remove the dhclient pid file from the directory
/var/run/sendsigs.omit.d. As a result, dhclient continues to hold the
pid file open for write and when /etc/init.d/umountroot tries to
remount the root filesystem read-only, the remount fails. The
message:
mount: / is busy
is seen in the console, and the filesystem must be recovered at boot
time:
[8.946427] EXT4-fs (sda1): INFO: recovery required on readonly filesystem
[8.947057] EXT4-fs (sda1): write access will be enabled during recovery
[ 11.234075] EXT4-fs (sda1): recovery complete
If shared libraries used by dhclient are updated before the reboot,
orphaned inodes associated with the .so files are created. For
example, doing sudo apt-get install --reinstall libc6 and then
rebooting leads to:
[8.356521] EXT4-fs (sda1): INFO: recovery required on readonly filesystem
[8.356521] EXT4-fs (sda1): write access will be enabled during recovery
[8.716544] EXT4-fs (sda1): orphan cleanup on readonly fs
[8.716544] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced
inode 313749
[8.724544] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced
inode 313733
[8.724544] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced
inode 313725
[8.724544] EXT4-fs (sda1): 3 orphan inodes deleted
[8.728544] EXT4-fs (sda1): recovery complete
This is network-manager 0.9.3.995+git201203152001.04b2a74-0ubuntu1
running under 12.04. I don't believe any actual data loss will occur
as a result of this bug, but it's likely to produce much user anxiety.
Also see Bug 952315, which misidentifies the cause of the problems as
upstart.
ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: network-manager 0.9.3.995+git201203152001.04b2a74-0ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-20.32-generic 3.2.12
Uname: Linux 3.2.0-20-generic i686
ApportVersion: 1.95-0ubuntu1
Architecture: i386
CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211
not found.
Date: Fri Mar 23 07:42:20 2012
InstallationMedia: Ubuntu 11.10 Oneiric Ocelot - Release i386 (20111011)
IwConfig:
lono wireless extensions.
eth0 no wireless extensions.
NetworkManager.state:
[main]
NetworkingEnabled=true
WirelessEnabled=true
WWANEnabled=true
WimaxEnabled=true
ProcEnviron:
TERM=xterm
LANG=en_US.UTF-8
SHELL=/bin/bash
RfKill:
SourcePackage: network-manager
UpgradeStatus: Upgraded to precise on
[Desktop-packages] [Bug 963106] Re: NetworkManager causes orphaned inodes
Thank you very much. Sadly it turned out that most of the sequence
numbers are totally wrong. It's a wonder that still everything worked
flawlessly except this unmounting...
I searched for a way to set all sequence numbers to their distribution
default, but I failed to find such a way.
I now have a file list from another correct precise installation and I'm
fixing all the links manually using update-rc.d just as you described.
After I have fixed the vast majority, I will reboot and report back, if
this fixed the initial problem, but this really will take some time...
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/963106
Title:
NetworkManager causes orphaned inodes
Status in “network-manager” package in Ubuntu:
Fix Released
Status in “network-manager” source package in Precise:
Fix Released
Bug description:
[Impact]
On shutdown, dhclient isn't getting reaped by NetworkManager, despite being
kept running through sendsigs so as not to disrupt remote filesystems (and
their unmounting at shutdown). dhclient may be keeping open files for its lease
files, which causes issues when unmounting /var/lib, which contains those lease
files.
[Development Fix]
Remove support for connection assumption, which is meant to bring
NetworkManager up to speed with connections that may have already be up during
a restart of the daemon. Since we don't actually restart the daemon
automatically (and instead suggest a restart of the system after upgrade) and
the advantage is minimal compared to the impact on users of this interacting
with the shutdown sequence, patch connection assumption out of the NM code and
just always take down dhclient when NM stops.
[Stable Fix]
See above Development fix.
[Test Case]
1) Shut down coputer.
2) In the shutdown process, perhaps as a post-stop script in
/etc/init/network-manager, track down open files for the dhclient pid (which
should be available from /run/sendsigs.omit.d/network-manager.dhclient{6,}.pid)
[Regression Potential]
Minimal, only affects bringing NetworkManager up on a restart of the daemon
(sudo restart network-manager or /etc/init.d/network-manager restart), which
improves on the speed of this operation and avoid resetting the connection if
it's already up.
-
During system shutdown, NetworkManager neither kills dhclient nor does
it remove the dhclient pid file from the directory
/var/run/sendsigs.omit.d. As a result, dhclient continues to hold the
pid file open for write and when /etc/init.d/umountroot tries to
remount the root filesystem read-only, the remount fails. The
message:
mount: / is busy
is seen in the console, and the filesystem must be recovered at boot
time:
[8.946427] EXT4-fs (sda1): INFO: recovery required on readonly filesystem
[8.947057] EXT4-fs (sda1): write access will be enabled during recovery
[ 11.234075] EXT4-fs (sda1): recovery complete
If shared libraries used by dhclient are updated before the reboot,
orphaned inodes associated with the .so files are created. For
example, doing sudo apt-get install --reinstall libc6 and then
rebooting leads to:
[8.356521] EXT4-fs (sda1): INFO: recovery required on readonly filesystem
[8.356521] EXT4-fs (sda1): write access will be enabled during recovery
[8.716544] EXT4-fs (sda1): orphan cleanup on readonly fs
[8.716544] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced
inode 313749
[8.724544] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced
inode 313733
[8.724544] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced
inode 313725
[8.724544] EXT4-fs (sda1): 3 orphan inodes deleted
[8.728544] EXT4-fs (sda1): recovery complete
This is network-manager 0.9.3.995+git201203152001.04b2a74-0ubuntu1
running under 12.04. I don't believe any actual data loss will occur
as a result of this bug, but it's likely to produce much user anxiety.
Also see Bug 952315, which misidentifies the cause of the problems as
upstart.
ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: network-manager 0.9.3.995+git201203152001.04b2a74-0ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-20.32-generic 3.2.12
Uname: Linux 3.2.0-20-generic i686
ApportVersion: 1.95-0ubuntu1
Architecture: i386
CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211
not found.
Date: Fri Mar 23 07:42:20 2012
InstallationMedia: Ubuntu 11.10 Oneiric Ocelot - Release i386 (20111011)
IwConfig:
lono wireless extensions.
eth0 no wireless extensions.
NetworkManager.state:
[main]
NetworkingEnabled=true
WirelessEnabled=true
WWANEnabled=true
WimaxEnabled=true
ProcEnviron:
TERM=xterm
LANG=en_US.UTF-8
SHELL=/bin/bash
RfKill:
SourcePackage: network-manager
UpgradeStatus: Upgraded to
[Desktop-packages] [Bug 963106] Re: NetworkManager causes orphaned inodes
After fixing all my init script symlinks, this problem is gone. Thank
you all so much for your help.
Some background information for others who might have my problem:
Cause:
Installing Vmware Player broke all rc script links. I guess that happened
already when still running ubuntu 11.10. See here:
http://communities.vmware.com/message/1846324
Solution:
For every service with broken symlink I:
- deleted it using: update-rc.d -f servicename remove
- searched for the related package using: dpkg -S /etc/init.d/servicename
- reconfigured this package using: dpkg-reconfigure packagename
reconfiguration ran the postinstall script and recreated the now missing
symlinks with correct sequence numbers
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/963106
Title:
NetworkManager causes orphaned inodes
Status in “network-manager” package in Ubuntu:
Fix Released
Status in “network-manager” source package in Precise:
Fix Released
Bug description:
[Impact]
On shutdown, dhclient isn't getting reaped by NetworkManager, despite being
kept running through sendsigs so as not to disrupt remote filesystems (and
their unmounting at shutdown). dhclient may be keeping open files for its lease
files, which causes issues when unmounting /var/lib, which contains those lease
files.
[Development Fix]
Remove support for connection assumption, which is meant to bring
NetworkManager up to speed with connections that may have already be up during
a restart of the daemon. Since we don't actually restart the daemon
automatically (and instead suggest a restart of the system after upgrade) and
the advantage is minimal compared to the impact on users of this interacting
with the shutdown sequence, patch connection assumption out of the NM code and
just always take down dhclient when NM stops.
[Stable Fix]
See above Development fix.
[Test Case]
1) Shut down coputer.
2) In the shutdown process, perhaps as a post-stop script in
/etc/init/network-manager, track down open files for the dhclient pid (which
should be available from /run/sendsigs.omit.d/network-manager.dhclient{6,}.pid)
[Regression Potential]
Minimal, only affects bringing NetworkManager up on a restart of the daemon
(sudo restart network-manager or /etc/init.d/network-manager restart), which
improves on the speed of this operation and avoid resetting the connection if
it's already up.
-
During system shutdown, NetworkManager neither kills dhclient nor does
it remove the dhclient pid file from the directory
/var/run/sendsigs.omit.d. As a result, dhclient continues to hold the
pid file open for write and when /etc/init.d/umountroot tries to
remount the root filesystem read-only, the remount fails. The
message:
mount: / is busy
is seen in the console, and the filesystem must be recovered at boot
time:
[8.946427] EXT4-fs (sda1): INFO: recovery required on readonly filesystem
[8.947057] EXT4-fs (sda1): write access will be enabled during recovery
[ 11.234075] EXT4-fs (sda1): recovery complete
If shared libraries used by dhclient are updated before the reboot,
orphaned inodes associated with the .so files are created. For
example, doing sudo apt-get install --reinstall libc6 and then
rebooting leads to:
[8.356521] EXT4-fs (sda1): INFO: recovery required on readonly filesystem
[8.356521] EXT4-fs (sda1): write access will be enabled during recovery
[8.716544] EXT4-fs (sda1): orphan cleanup on readonly fs
[8.716544] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced
inode 313749
[8.724544] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced
inode 313733
[8.724544] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced
inode 313725
[8.724544] EXT4-fs (sda1): 3 orphan inodes deleted
[8.728544] EXT4-fs (sda1): recovery complete
This is network-manager 0.9.3.995+git201203152001.04b2a74-0ubuntu1
running under 12.04. I don't believe any actual data loss will occur
as a result of this bug, but it's likely to produce much user anxiety.
Also see Bug 952315, which misidentifies the cause of the problems as
upstart.
ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: network-manager 0.9.3.995+git201203152001.04b2a74-0ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-20.32-generic 3.2.12
Uname: Linux 3.2.0-20-generic i686
ApportVersion: 1.95-0ubuntu1
Architecture: i386
CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211
not found.
Date: Fri Mar 23 07:42:20 2012
InstallationMedia: Ubuntu 11.10 Oneiric Ocelot - Release i386 (20111011)
IwConfig:
lono wireless extensions.
eth0 no wireless extensions.
NetworkManager.state:
[main]
NetworkingEnabled=true
WirelessEnabled=true
WWANEnabled=true
WimaxEnabled=true
