I'm currently running Linux version 2.6.18-6-amd64 (Debian
2.6.18.dfsg.1-18etch3) (dannf@debian.org) (gcc version 4.1.2 20061115
(prerelease) (Debian 4.1.1-21)) #1 SMP Thu Apr 24 03:57:46 UTC 2008
Up until now, things have been working fine with the two software raid5
arrays I've got running via mdadm. I had just replaced a failed disk in
the second array (/dev/md1) and decided to update the system with
"apt-get update" and "apt-get upgrade", which all proceeded normally
(including updating to the latest kernel image as seen above). After
the update, I restarted the box to finish the process, and upon getting
back into the system I noticed the first array was running in degraded
mode with a disk missing. Upon inspecting /proc/partitions i found that
/dev/sdm didn't have any partitions listed at all:
So I figured I'd check the drive in fdisk, which actually found the
partition to exist:
---
Disk /dev/sdm: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdm1 1 60789 488287611 fd Linux raid
autodetect
---
I tried switching out the SATA cable with a new one, which had no effect.
Moving the drive to a different port on the controller card didn't
affect it either.
A self-test via smartctl (from smartmontools) didn't turn anything up,
so I just decided to go back into fdisk and write the partition table to
disk. I didn't make any changes to the table. I just went in, printed
the list to make sure it was there, then wrote to disk. After doing
this, the partition appeared in /proc/partitions as seen here:
So with the partition back in working order I attempted to start the
array with sdm1 included, which kicked it out with a non-fresh error
code. Rather than taking the risk of corrupted data, I just re-added
the drive to the array and let it rebuild. Everything appeared to be
working fine after the rebuild, but upon restarting the box one more
time to see what would happen, the partition had once again vanished.
Going over the dmesg output, it's clear the system can see the partition:
---
SCSI device sdm: 976773168 512-byte hdwr sectors (500108 MB)
sdm: Write Protect is off
sdm: Mode Sense: 00 3a 00 00
SCSI device sdm: drive cache: write back
SCSI device sdm: 976773168 512-byte hdwr sectors (500108 MB)
sdm: Write Protect is off
sdm: Mode Sense: 00 3a 00 00
SCSI device sdm: drive cache: write back
sdm: sdm1
sd 12:0:0:0: Attached scsi disk sdm
---
Any ideas?
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
05-10-2008, 11:31 AM
martin f krafft
Vanishing RAID autodetect partition
also sprach ketonom@psiblade.net <ketonom@psiblade.net> [2008.05.09.2229 +0100]:
> Any ideas?
Not really, except you don't need a partition table... you could
just use /dev/sdm directly...
Also, if you're using a Debian kernel, you don't need to set 0xfd as
partition type.
--
.'`. martin f. krafft <madduck@debian.org>
: :' : 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
"anyone who is capable of getting themselves made president
should on no account be allowed to do the job"
-- douglas adams
05-10-2008, 09:00 PM
Vanishing RAID autodetect partition
The problem seems to have been fixed after I updated from etch to lenny.
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Vanishing RAID autodetect partition
