Hello!
Kernel 2.4.20-62 from Suse
Two IBM DTLA 305040 with software raid 1
After (clean) shutdown or reboot, the root partition is not clean and
the reconstruction begins.
Kind regards
Armin Mohring
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
This used to happen to me too. I have a 3ware 7500 with 3 WD 120GB drives in RAID 5. It
stopped though. I just moved the server to its perm location thinking I will work on it
from there but it just stopped doing that.
Dhaval
Armin Mohring
> Hello!
>
> Kernel 2.4.20-62 from Suse
> Two IBM DTLA 305040 with software raid 1
> After (clean) shutdown or reboot, the root partition is not clean and
> the reconstruction begins.
>
> Kind regards
> Armin Mohring
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
I had the same problem with root-raid.
I migrated to 2.4.20 kernel from www.kernel.org and problem disappeared.
Seems like a bug in suse kernel to me.
Regards,
Mihail Daskalov
Here is my previous post to the mailing list:
I have SuSE 7.2 on a machine with 4 HDDs.
I have configured my root and boot to be on RAID1.
I installed the machine with he latest available kernel as a patch to SuSE 7.2 (ftp://ftp.suse.com/pub/suse/i386/update/7.2/kernel/2.4.18-2 0030324/k_de
flt-2.4.18-262.i386.rpm)
I had a problem with the IDE devices. Two blocks on two different disk were reported as bad and my raid5 was broken. Testing the IBM 120GB disks with the software provided by IBM/Hitachi revealed there were no problems in the disks.
Hoping that this was due to a problem with the IDE driver in the last kernel, I tried
ftp://ftp.suse.com/pub/people/mantel/next/RPM/kernel-source- 2.4.20.SuSE-
62.i586.rpm
I compiled it myself including md,raid1,raid5 in the kernel (not as
modules)
and there exists the following problem:
After every shutdown or reboot my /dev/md1 (rootfs) device needs recyncing. It's because it's not stopped cleanly on shutdown or reboot.
All other /dev/md? devices are stopped on shutdown, only this one is not. On the console I see messages like ....skip....
/dev/md0: switching to read-only mode
.....skip....
/dev/md2: switching to read-only mode
.....skip....
/dev/md3: switching to read-only mode
.....skip....
/dev/md4: switching to read-only mode
but I don't see that message for /dev/md0. Instead I see a message saying that /dev/md1 is still in use.
Anyone know why this happens on newer kernels? How can I fix the problem?
I didn't have this problem on k_deflt-2.4.18-262.i386.rpm . Does this version have any known problems with Intel 845 PESV motherboards?
Should I try a stock kernel from www.kernel.org ? Which one supports LVM?
Thanks in advance,
Mihail Daskalov
MDaskalov@technologica.biz
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-----Original Message-----
From: Armin Mohring [mailto:arminmohring@surfeu.de]
Sent: Thursday, June 05, 2003 9:12 AM
To: linux-raid@vger.kernel.org
Subject: Raid 1 after shutdown or reboot not clean
Hello!
Kernel 2.4.20-62 from Suse
Two IBM DTLA 305040 with software raid 1
After (clean) shutdown or reboot, the root partition is not clean and
the reconstruction begins.
Kind regards
Armin Mohring
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html