PDC20271 on Slackware 8.1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I finally did it, but it wasn't easy at all. And I cheated, at that. :)
This is using the Promise binary ft.o or fasttrack.o (can't remember,
and I'm not at that machine now.)

I'm using a binary kernel from Red Hat 7.3. I also made the initrd from
a Redhat 7.3 install.

I thought it would be easier than it was. RH was installed (not by me)
with a separate /home partition. I had made a previous Slackware install
(not using the PDC20271) on this machine, and untarred it to /home. I
thought I could just copy the image=... block in lilo.conf, changing the
root= and label= parameters.

That didn't work, and I'm not sure why. Either something in the initrd
(I couldn't figure out how the new root device is defined in the initrd)
or something in the filesystem (is there a mount point for the real root
device?)

I tried mkinitrd with --fstab=/home/etc/fstab (which had been properly
edited for the proper partitions.) Same thing happened (on boot, kernel
panic due to "no init found".)

So I got tricky. I deleted the Slackware directories in /home, then
copied all the RH directories from / into /home. I edited the etc/fstab,
chroot'ed in /home, and mkinitrd. I configured LILO to boot /home as /
using the new initrd. Boot test, it worked.

>From the former /home install of RH I deleted most of the RH stuff from
its former / partition. I left some empty directories as mount points
(again, I'm not at the machine and can't remember.) Then I untarred the
Slackware in the old RH /.

This time using the original initrd I had no problem. Slack is happily
running on the RH kernel.

Can anyone here explain the workings of the initrd and pivot_root? Was I
just missing a mount point, or did I really have to make the different
initrd image? Yes, I can test that myself by trying to boot each root on
the other's initrd, but I hope someone can save me the trouble. :) I did
read and fail to understand Documentation/initrd.txt in the kernel
source.)

The next step will be to try again to build a kernel and use the
ataraid/pdcraid drivers. I tried several suggestions from this list's
archive, all to no avail. I could never get the controller recognized by
the kernel, whether Slackware's raid.s kernel or any of the custom ones
I built.

Is any of this worth the trouble? Would the kernel's software RAID on a
regular ATA-133 controller be just as good?

I will add that I am thoroughly disgusted by Promise. They work hard to
keep their driver source closed, which leads me to believe that they
have something to hide. *If it was any good they could just release it,
and SOMEONE ELSE would maintain it for them!!* I'll never buy their
trash again.

    Rob - /dev/rob0





[Index of Archives]     [Linux RAID]     [Linux Device Mapper]     [Linux IDE]     [Linux SCSI]     [Kernel]     [Linux Books]     [Linux Admin]     [GFS]     [RPM]     [Yosemite Campgrounds]     [AMD 64]

  Powered by Linux