Re: Software-RAID Issues on RH7.2
From: Ricky Boone (whiplash_at_planetfurry.com)
Date: 07/24/03
- Previous message: R P Herrold: "Re: rh-l] building RPMs from SRPMs as non-root user"
- In reply to: Leonard den Ottolander: "Re: Software-RAID Issues on RH7.2"
- Next in thread: Peter Kiem: "Re: Software-RAID Issues on RH7.2"
- Reply: Peter Kiem: "Re: Software-RAID Issues on RH7.2"
- Reply: Leonard den Ottolander: "Re: Software-RAID Issues on RH7.2"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: redhat-list@redhat.com Date: 23 Jul 2003 23:02:50 -0400
On Wed, 2003-07-23 at 10:20, Leonard den Ottolander wrote:
> I am sorry nobody else jumps in. Problem with waiting such a long time
> with your replies is it makes that I already forgot what the precise
> problem was, what you have already tried to solve it, and what I did
> recommend you to try.
I understand the problem there. Since this server is not technically
work-related, it usually gets put on the far-back burner, for various
periods of time. :(
> > BTW: I've tried the following:
> >
> > # mkinitrd --preload raid1 --with=raid1 raid1-initrd.img 2.4.20-18.7
> >
> > ... and no luck. It booted just fine, just no difference and no RAID.
>
> I think we already concluded before that the ramdisk probably is not
> the problem.
The last recommendation I noticed was to try and create a custom ramdisk
to force it to load the raid1 module.
> Since you are using root raid and can't access the machine physically
> I think you have a serious problem. Instead of debugging the situation
> you could try recreating the array (you should test if this works
> without losing your data on another machine first, and to make sure you
> know the procedure), but the fact that your root fs is on raid makes
> this very difficult if you are unable to handle the machine. You could
> try to setup a rescue system on a spare partition, reboot to that (use
> the -f flag for shutdown to make sure you do not end up in a filesystem
> check), boot to this rescue partition, fix things from there and boot
> back to your original system. This is possible but very tricky if you
> can't handle the machine.
*chuckle* Difficult is an understatement. ;) Makes me really wish I
could host it from home... ;)
I'm probably still looking at this the wrong way, but previous kernel
upgrade(s) work just fine. For example, the software needed 2.4.9
initially, but RH7.2 came with 2.4.7. I upgraded the kernel rpms the
same way I've tried now, and it worked. What could have changed between
2.4.9 and 2.4.20 in this respect? :|
I've recreated the situation on a VMware virtual machine I set up. The
only difference is that I have no control over the type of hard-drives
are "emulated", per se, as it only allows SCSI. The real machine has
IDE drives. Same problem. Upgrade from 2.4.7 -> 2.4.9, just fine.
Upgrade to 2.4.9 -> 2.4.20, no RAID.
Argh. :\ I really wish I had hardware RAID support... bleh.
-- Ricky Boone <whiplash@planetfurry.com> Planetfurry.com -- redhat-list mailing list unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
- Previous message: R P Herrold: "Re: rh-l] building RPMs from SRPMs as non-root user"
- In reply to: Leonard den Ottolander: "Re: Software-RAID Issues on RH7.2"
- Next in thread: Peter Kiem: "Re: Software-RAID Issues on RH7.2"
- Reply: Peter Kiem: "Re: Software-RAID Issues on RH7.2"
- Reply: Leonard den Ottolander: "Re: Software-RAID Issues on RH7.2"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|