Re: Raid, fsck, superblock could not be found
hi ya rds
On Mon, 11 Apr 2005, rds wrote:
> --- Alvin Oga <aoga@mail.Linux-Consulting.com> wrote:
> > > # cat /boot/grub/device.map
> > > (hd0) /dev/sda
> > > (hd1) /dev/sdb
> > > (hd2) /dev/sdc
> > i'm not sure about that .. but lets assume its right
> Not sure about that myself. Tried also putting only "(hd0) /dev/md1" but it did
> not appear to make any difference.
last variable to experiment with later
make sure you keep it straight
or whatever it happens to be
> > > ## default grub root device
> > > ## e.g. groot=(hd0,0)
> > > # groot=(hd0,0)
> > whacky ... root should be "/dev/md0" not the default of an individual
> > sata disk
> You mean /dev/md1? /dev/md1 is mounted as /boot according to my /etc/fstab.
i donno what supposed to be what .... /boot vs /
as long as you're straight with which one is which
> Tried also "# groot=/dev/md1" but did not see any difference.
you need to remove "#" so that its not commented out and using
the program defaults of (hd0,0) which to me is questionable what
it should be
> /initrd.img-2.6.8-2-686-sata-raid contains "most" modules + sata_nv + raid0 +
> raid1 + raid5, nothing more.
that's just the modules ..
what about the commands executed from inside initrd
it supposed to be modprobe'ing all the modules in the initrd, which is
the whole point of including the modules in the initrd
it should also post porcess the modules with mdadm to assemble
the raid stuff in this case
- i suspect if you are using a generic initrd, that it will
not build your software raid with mdadm for you
so you have to add the explict mdadm -assemble ...
commands into the initrd and rebuild the initrd
( uncompress it, do the change .. compress it again )
> But it does seem to be able assemble and fsck the "/" partition which is a
> raid5 array *BEFORE*(!) it tries to fsck /dev/md1. Why can't it handle /dev/md1
> the same way as it just did for /dev/md2??
some magic pixie dust is missing ... i do not know your setup or config
files nor do i want to fix it all .... just willing to say what to look
> fsck.ext: Invalid argument while trying to open /dev/md1
and i bet /dev/md1 does not exist
> So, as you can see, first it fsck'ed "/" (on raid5, /dev/md2) and found it to
> be clean. Why can't it do the same for /dev/md1 LATER? I'm puzzled.
not quite, that is not the normal boot process sequence ....
probably an erroneous error message or some assumptions
in the boot script does not work for your environment
/boot is needed to boot first ... than it will fsck / and other partitions
note though that /boot can be on any media
( floppy, compact flash, cd, network ... )
if /boot and / are raid devices, that mdadm is needed PRIOR to
booting ( in /linuxrc for initrd's or before fsck is called )