When using chown as root, or tar to extract a tarball with original permissions, the machine often freezes. There is nothing in logs after reboot, and i can't see the screen (machine in a datacenter). Nevertheless, when trying to find the crash condition i once got a trace :
[root@Toushirou photos-perso-dc]# chown alice:adm alice
Message from syslogd@Toushirou at Feb 13 19:41:09 ...
kernel:[ 95.346548] ------------[ cut here ]------------
Message from syslogd@Toushirou at Feb 13 19:41:09 ...
kernel:[ 95.346675] invalid opcode: 0000 [#1] SMP
Message from syslogd@Toushirou at Feb 13 19:41:09 ...
kernel:[ 95.346791] last sysfs file: /sys/devices/platform/coretemp.1/temp1_crit_alarm
Message from syslogd@Toushirou at Feb 13 19:41:09 ...
kernel:[ 95.350139] Stack:
Message from syslogd@Toushirou at Feb 13 19:41:09 ...
kernel:[ 95.350454] Call Trace:
Message from syslogd@Toushirou at Feb 13 19:41:09 ...
kernel:[ 95.350454] Code: 00 48 89 ef e8 ab 3b fc ff 48 89 df 49 89 c5 e8 45 b7 1b 00 48 8b 85 00 01 00 00 48 8b 40 40 48 8b 80 88 00 00 00 48 85 c0 75 04 <0f> 0b eb fe 48 89 ef ff d0 4c 8b 30 66 ff 85 b0 00 00 00 4b 8d
Message from syslogd@Toushirou at Feb 13 19:41:09 ...
kernel:[ 95.353705] Kernel panic - not syncing: Fatal exception
After a few tests, it "seems" this problem only occurs on filesystems with POSIX ACLs activated. In the previous exemple, i was able to give rights to the user using setfacl, but using chown always froze the system.
Reverting to 2.6.30-8squeeze1 fixed the problem.
Please note the following data, collected using the linux-image reportbug script, may be uncomplete or partialy broken, as the script failed with exit code 256, but i continued filing the report anyway (i'd probably open another bugreport on this later).
Regards.
-- Package-specific info:
** Kernel log: boot messages should be attached
** Model information
sys_vendor: Supermicro
product_name: PDSMi
product_version: 0123456789
chassis_vendor: Supermicro
chassis_version: 0123456789
bios_vendor: Phoenix Technologies LTD
bios_version: 6.00
board_vendor: Supermicro
board_name: PDSMi+
board_version: PCB Version
Kernel: Linux 2.6.30-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages linux-image-2.6.32-2-amd64 depends on:
ii debconf [debconf-2.0] 1.5.28 Debian configuration management sy
ii initramfs-tools [linux-initr 0.93.4 tools for generating an initramfs
ii module-init-tools 3.12~pre1-1 tools for managing Linux kernel mo
Versions of packages linux-image-2.6.32-2-amd64 recommends:
ii firmware-linux-free 2.6.32-8 Binary firmware for various driver
Versions of packages linux-image-2.6.32-2-amd64 suggests:
pn grub | lilo <none> (no description available)
pn linux-doc-2.6.32 <none> (no description available)
Versions of packages linux-image-2.6.32-2-amd64 is related to:
pn firmware-bnx2 <none> (no description available)
pn firmware-bnx2x <none> (no description available)
pn firmware-ipw2x00 <none> (no description available)
pn firmware-ivtv <none> (no description available)
pn firmware-iwlwifi <none> (no description available)
pn firmware-linux <none> (no description available)
pn firmware-linux-nonfree <none> (no description available)
pn firmware-qlogic <none> (no description available)
pn firmware-ralink <none> (no description available)
--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
02-13-2010, 07:17 PM
Ben Hutchings
Bug#569722: sometimes crash with chown
On Sat, 2010-02-13 at 20:22 +0100, Marc Dequènes wrote:
> Package: linux-2.6
> Version: 2.6.32-8
Really?
> Severity: grave
>
> Coin,
>
> When using chown as root, or tar to extract a tarball with original permissions, the machine often freezes. There is nothing in logs after reboot, and i can't see the screen (machine in a datacenter). Nevertheless, when trying to find the crash condition i once got a trace :
>
> [root@Toushirou photos-perso-dc]# chown alice:adm alice
>
> Message from syslogd@Toushirou at Feb 13 19:41:09 ...
> kernel:[ 95.346548] ------------[ cut here ]------------
>
> Message from syslogd@Toushirou at Feb 13 19:41:09 ...
> kernel:[ 95.346675] invalid opcode: 0000 [#1] SMP
>
> Message from syslogd@Toushirou at Feb 13 19:41:09 ...
> kernel:[ 95.346791] last sysfs file: /sys/devices/platform/coretemp.1/temp1_crit_alarm
>
> Message from syslogd@Toushirou at Feb 13 19:41:09 ...
> kernel:[ 95.350139] Stack:
>
> Message from syslogd@Toushirou at Feb 13 19:41:09 ...
> kernel:[ 95.350454] Call Trace:
>
> Message from syslogd@Toushirou at Feb 13 19:41:09 ...
> kernel:[ 95.350454] Code: 00 48 89 ef e8 ab 3b fc ff 48 89 df 49 89 c5 e8 45 b7 1b 00 48 8b 85 00 01 00 00 48 8b 40 40 48 8b 80 88 00 00 00 48 85 c0 75 04 <0f> 0b eb fe 48 89 ef ff d0 4c 8b 30 66 ff 85 b0 00 00 00 4b 8d
[...]
This code appears to be part of dquot_transfer(). A bug in that
function was fixed in version 2.6.32-6.
Ben.
--
Ben Hutchings
Who are all these weirdos? - David Bowie, about L-Space IRC channel #afp