Your message dated Mon, 3 Jun 2013 19:03:10 +0200
with message-id <20130603170310.GC5319@pisco.westfalen.local>
and subject line Closing
has caused the Debian Bug report #523039,
regarding /boot/vmlinuz-2.6.26-1-686: umount -f /net/tesla/foo & umount -l -f
/net/tesla/foo breaks the whole VFS
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.)
--
523039: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=523039
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: linux-image-2.6.26-1-686
Version: 2.6.26-13lenny2
Severity: normal
File: /boot/vmlinuz-2.6.26-1-686
I'm not sure how reproducible this is. I use the automounter to
automount /net/tesla/whatever, and so on. I think I got NFS confused
by changing the exports on tesla without unmounting from llama first.
Anyway, I was in one of those nfs-is-stuck-and-I-need-to-umount
situations.
I ran
sudo umount -f /net/tesla/usr &
sudo umount -f /net/tesla/home &
sudo umount -f /net/tesla/var/tmp &
At least one of these mounts shouldn't have had any open files, but I
wasn't able to check for sure because lsof blocks on broken NFS mounts.
When none of those umounts exitted for several minutes, I ran
sudo umount -l -f /net/tesla/var/tmp &
sudo umount -l -f /net/tesla/usr &
Within seconds of doing that, _local_ file access started to break.
Anything I tried to run hung. e.g. ls didn't return. (I was CDed
to a directory in /mnt/large, an ext3 filesystem on a local disk.)
The machine wasn't totally locked, though. I was able to fg a vi
process, and have it prompt that a file on disk was newer, and then
exit cleanly (and this was over SSH). So user-space (and apparently
even the VFS) wasn't entirely screwed, but there were major problems.
I eventually had to alt+sysrq s, u, b to reboot.
Does umount -l need to check if there's already a umount attempt
going on? The only thing out of the ordinary that I did was
umount -l -f while a umount -f was stuck on the same filesystem.
Machine hardware: PIII 500MHz, 440BX chipset, 512MB. tulip NICs.
This HW has been stable for ~10 years. :)
-- Package-specific info:
** Version:
Linux version 2.6.26-1-686 (Debian 2.6.26-13lenny2) (da...@debian.org) (gcc
version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Fri Mar 13
18:08:45 UTC 2009
** Command line:
root=/dev/md0 lapic ro
** Not tainted
** Loaded modules:
Module Size Used by
autofs4 16420 1
nfsd 186704 17
auth_rpcgss 33952 1 nfsd
exportfs 3904 1 nfsd
nfs 213896 5
lockd 54248 2 nfsd,nfs
nfs_acl 2912 2 nfsd,nfs
sunrpc 162144 26 nfsd,auth_rpcgss,nfs,lockd,nfs_acl
ipt_REJECT 2784 1
xt_tcpudp 2816 16
xt_state 2016 1
nf_nat_irc 2080 0
nf_conntrack_irc 5124 1 nf_nat_irc
nf_conntrack_ftp 6852 0
ipt_MASQUERADE 2592 1
iptable_nat 4680 1
nf_nat 15576 3 nf_nat_irc,ipt_MASQUERADE,iptable_nat
nf_conntrack_ipv4 12268 4 iptable_nat,nf_nat
nf_conntrack 55508 8
xt_state,nf_nat_irc,nf_conntrack_irc,nf_conntrack_ftp,ipt_MASQUERADE,iptable_nat,nf_nat,nf_conntrack_ipv4
iptable_filter 2624 1
ip_tables 10160 2 iptable_nat,iptable_filter
x_tables 13284 6
ipt_REJECT,xt_tcpudp,xt_state,ipt_MASQUERADE,iptable_nat,ip_tables
dm_snapshot 14340 0
dm_mirror 15104 0
dm_log 8452 1 dm_mirror
dm_mod 46184 3 dm_snapshot,dm_mirror,dm_log
ipv6 235300 26
button 6096 0
serio_raw 4740 0
snd_pcm 62596 0
psmouse 32336 0
i2c_piix4 7216 0
snd_timer 17800 1 snd_pcm
i2c_core 19828 1 i2c_piix4
snd 45604 2 snd_pcm,snd_timer
soundcore 6368 1 snd
shpchp 25528 0
pci_hotplug 23460 1 shpchp
snd_page_alloc 7816 1 snd_pcm
intel_agp 22332 1
agpgart 28776 1 intel_agp
pcspkr 2432 0
evdev 8000 0
ext3 105512 4
jbd 39444 1 ext3
mbcache 7108 1 ext3
raid1 18016 3
md_mod 67036 4 raid1
usbhid 35904 1
hid 33184 1 usbhid
ff_memless 4392 1 usbhid
ide_disk 10496 10
ata_generic 4676 0
libata 140384 1 ata_generic
scsi_mod 129356 1 libata
dock 8304 1 libata
uhci_hcd 18672 0
piix 6568 0 [permanent]
ide_pci_generic 3908 0 [permanent]
tulip 44064 0
usbcore 118160 4 usbhid,uhci_hcd
ide_core 96168 3 ide_disk,piix,ide_pci_generic
thermal 15228 0
processor 32576 2 thermal
fan 4164 0
thermal_sys 10856 3 thermal,processor,fan
-- System Information:
Debian Release: 5.0
APT prefers stable
APT policy: (990, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages linux-image-2.6.26-1-686 depends on:
ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy
ii initramfs-tools [linux-initra 0.92o tools for generating an initramfs
ii module-init-tools 3.4-1 tools for managing Linux kernel mo
Versions of packages linux-image-2.6.26-1-686 recommends:
ii libc6-i686 2.7-18 GNU C Library: Shared libraries [i
Versions of packages linux-image-2.6.26-1-686 suggests:
ii grub 0.97-47lenny2 GRand Unified Bootloader (Legacy v
pn linux-doc-2.6.26 <none> (no description available)
--- End Message ---
--- Begin Message ---
Hi,
your bug has been filed against the "linux-2.6" source package and was filed for
a kernel older than the recently released Debian 7.0 / Wheezy with a severity
less than important.
We don't have the ressources to reproduce the complete backlog of all older
kernel
bugs, so we're closing this bug for now. If you can reproduce the bug with
Debian Wheezy
or a more recent kernel from testing or unstable, please reopen the bug by
sending
a mail to cont...@bugs.debian.org with the following three commands included in
the
mail:
reopen BUGNUMBER
reassign BUGNUMBER src:linux
thanks
Cheers,
Moritz
--- End Message ---