Your message dated Sun, 30 Dec 2007 18:26:04 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Bug#458327: on reboot mdadm fails to mount all drives in a
raid5 array
has caused the attached Bug report 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 I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
Package: mdadm
Version: 2.6.3+200709292116+4450e59-3
Severity: important
This computer has, amongst others, two raid5 partitions.
The system is shut down via a "standard" command. When rebooted,
sdd1 and sdd2 are missing. The raid5 arrays get manually rebuilt
using the # mdadm --manage --re-add command.
On one occasion an abnormal shutdown occurred. On reboot both raid5
arrays were detected as degraded and were automatically rebuilt and
were reassembled correctly.
If, following a "normal" shutdown and reboot, an event were to occur
that caused a loss of data before the raid5 arrays were manually
restored, mdadm would be unable to recover the information from
either raid5 array. This is a bug.
-- Package-specific info:
--- mount output
/dev/md0 on / type ext3 (rw,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
procbususb on /proc/bus/usb type usbfs (rw)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
/dev/md2 on /home type ext3 (rw,errors=remount-ro)
/dev/md3 on /var type ext3 (rw,errors=remount-ro)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc
(rw,noexec,nosuid,nodev)
--- mdadm.conf
DEVICE /dev/sd[abcde]1
DEVICE /dev/sd[cde]2
DEVICE /dev/sd[ab]3
ARRAY /dev/md0 level=raid1 num-devices=2
UUID=a7ccc6ae:0b19165f:53868f85:2f9f5918
ARRAY /dev/md1 level=raid1 num-devices=2
UUID=04c38589:b3f84631:8c0b1476:c50c7236
ARRAY /dev/md2 level=raid5 num-devices=3 spares=1
UUID=5319b6ab:c6492e30:3cde2480:e3073515
ARRAY /dev/md2 devices=/dev/sdc1,/dev/sdd1,/dev/sde1
ARRAY /dev/md3 level=raid5 num-devices=3 spares=1
UUID=52db6426:52314f0e:3cde2480:e3073515
ARRAY /dev/md3 devices=/dev/sdc2,/dev/sdd2,/dev/sde2
MAILADDR root
--- /proc/mdstat:
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
[multipath]
md1 : active raid1 sdb3[1] sda3[0]
96320 blocks [2/2] [UU]
md2 : active raid5 sdd1[2] sde1[1] sdc1[0]
1171877248 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]
md3 : active raid5 sdd2[2] sde2[1] sdc2[0]
293266432 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]
md0 : active raid1 sdb1[1] sda1[0]
35158144 blocks [2/2] [UU]
unused devices: <none>
--- /proc/partitions:
major minor #blocks name
8 0 36151920 sda
8 1 35158221 sda1
8 2 891607 sda2
8 3 96390 sda3
8 16 36151920 sdb
8 17 35158221 sdb1
8 18 891607 sdb2
8 19 96390 sdb3
8 32 732574584 sdc
8 33 585938713 sdc1
8 34 146633287 sdc2
8 48 732574584 sdd
8 49 585938713 sdd1
8 50 146633287 sdd2
8 64 732574584 sde
8 65 585938713 sde1
8 66 146633287 sde2
9 0 35158144 md0
9 3 293266432 md3
9 2 1171877248 md2
9 1 96320 md1
--- initrd.img-2.6.22-ver.1.3:
--- /proc/modules:
dm_snapshot 19272 0 - Live 0xffffffff881f8000
dm_mirror 24192 0 - Live 0xffffffff881f1000
--- volume detail:
--- /proc/cmdline
root=/dev/md0 ro
--- grub:
kernel /boot/vmlinuz-2.6.22-ver.1.3 root=/dev/md0 ro
kernel /boot/vmlinuz-2.6.22-ver.1.3 root=/dev/md0 ro single
kernel /boot/vmlinuz-2.6.21 root=/dev/md0 ro
kernel /boot/vmlinuz-2.6.21 root=/dev/md0 ro single
kernel /boot/vmlinuz-2.6.18-4-amd64 root=/dev/md0 ro
kernel /boot/vmlinuz-2.6.18-4-amd64 root=/dev/md0 ro single
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.22-ver.1.3 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages mdadm depends on:
hi debconf [debconf-2.0] 1.5.17 Debian configuration management sy
ii libc6 2.7-4 GNU C Library: Shared libraries
hi lsb-base 3.1-24 Linux Standard Base 3.1 init scrip
hi makedev 2.3.1-84 creates device files in /dev
hi udev 0.114-2 /dev/ and hotplug management daemo
Versions of packages mdadm recommends:
hi exim4-daemon-light [mail-tra 4.68-2 lightweight Exim MTA (v4) daemon
hi module-init-tools 3.3-pre11-4 tools for managing Linux kernel mo
-- debconf information:
mdadm/autostart: true
mdadm/mail_to: root
mdadm/initrdstart_msg_errmd:
* mdadm/initrdstart: all
mdadm/initrdstart_msg_errconf:
mdadm/initrdstart_notinconf: false
mdadm/initrdstart_msg_errexist:
mdadm/initrdstart_msg_intro:
mdadm/autocheck: true
mdadm/initrdstart_msg_errblock:
mdadm/start_daemon: true
--- End Message ---
--- Begin Message ---
also sprach richard <[EMAIL PROTECTED]> [2007.12.30.1344 +0100]:
> If, following a "normal" shutdown and reboot, an event were to
> occur that caused a loss of data before the raid5 arrays were
> manually restored, mdadm would be unable to recover the
> information from either raid5 array. This is a bug.
No, this is what software RAID does. It provides run-time
redundancy, not a guard against data loss. Use backups for that.
If I am misunderstanding your report, maybe it would help if you
wrote what you expect instead of just claiming that this is a bug.
--
.''`. martin f. krafft <[EMAIL PROTECTED]>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
--- End Message ---
