IDS000 wrote:
Like many, I too have had my share of RAID volumes being created and mounting perfectly after creation only to findthat the Volume will not mount at boot and failing to any number of error levels.
Often the user is presented with a shell repair mode and running repairs like fsck could be the worst thing you can do. Often the problem is the superblock creation time...here's the kicker...
If the RAID was created whilst a system is up and running, that system date/time is taken from your prevailing clock. Most of us set up a NTP Network Service to auto sync with time servers all over the world.
IF, at boot, your PC's CMOS date/time is behind the date/time of the PC's session clock, you will be flooded with huge numbers of reasons why the volume wont mount...
The real reason is that the Superblock will be written to the date/time of your PC session clock and now at boot, with your CMOS clock retarded! You will be flooded with various error levels as to why the volume wont mount and some reasons are really fancifully and as a consequence to an Invalid Superblock
The number of error levels that could possibly appear at boot as to why the volume wont mount could be just about any reason. Before you start entertaining using any repair mode, or any maintenance mode where / is mounted rw, just make sure your CMOS clock is accurate.
This might just fix your never ending issues with creating ANY RAID Volume that wont mount at boot
Hope this helps a few guys/girls -Scott - .AU
Why would this have an effect on RAID-ed filesystems but not on non-RAID filesystems? They both have superblocks, and as far as I know, there is no additional "RAID superblock", just the same old superblock in the filesystem which we have been living with since 1970's versions of Unix. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org