I'm trying to set up a Fedora 10 box with bootable RAID 1. I've followed Falko Timme's excellent HowTo on doing the same with FC 8 and I'm hoping that Fedora hasn't changed so much that it is no longer applicable. Everything goes pretty much as expected during the setup. I started with an installation on one disk, and a second unformatted disk. After the 'grub' setup is complete, I reboot for the first time and hold my breath. The machine reboots (into runlevel 3, as I set it up) and shows a login prompt. I enter my username, the password prompt appears, I enter the password. Then a brief flash of a couple lines that seem to say something about "last login was ...", and then I get the login prompt again. Same thing happens. I try loggin in as another user, same results. If I enter an incorrect password, I get the message "unable to authenticate user, as I would expect. Googling and searching this forum does not seem to produce any information relevant ... does anyone have any idea what's up or how I can get around it? Thanks ... Rich Leitner
I could imagine that something went wrong with /etc/passwd or /etc/shadow when they got copied to the RAID device. I'd boot into the "normal" system again and do the copy process again. Look out for any error messages.
Indeed, the entire process went without a hitch until the "cp -dpRx / /mnt/md2", when I had two error messages about copying. I wish I had written them down verbatim, but the first was something like: Copying /rich/something/something/cups/0/certs: Operation not supported I assumed this might have to do with 'cups' printing and I could safely ignore it. The second was a bit more cryptic and had to do with "/.gvfs". I've been googling like mad about gvfs and learning a bit, though I don't know exactly what might have gone wrong here. The message was "permission denied", so I'm guessing this might be the one. Anyway, as far a booting back into the normal system, I'm not sure I can! It won't let me sign in. However, I think if I disconnect the 'sdb' hard drive, the 'sda' hard drive should still be in its original state and should let me sign in. I'm not at the machine now, but I'll try it when I can. Thanks Falko, and thanks for taking the time to provide such a terrific guide! Rich
It was as I expected ... I cannot log in even after disconnecting one of the HDDs. I have tried reinstalling the entire OS via the DVD. I thought this would essentially destroy the remnants of the old stuff, but apparently this is not the case. Am I missing something obvious? How can I essentially "erase" (not just delete) the remnants of my previous attempts? I actually removed the HDD and put in a new spare I had laying around ... this gave me a clean slate until I ran into problems again. Now I'm out of 'clean' HDDs so another method is needed. Thanks again for any help ...
Yes, this is what I did the very first time: I installed Fedora 10 on the first drive, left the second drive alone (though it was installed on the board). Didn't format it, partition it or anything. But after trying and failing, it seems the partitioning on the second HDD remains, even after "deleting" it in the Fedora Installer. I understand that 'deleting' does not mean 'wiping', and this seems to cause problems with the next attempt. Currently, I'm using a disk utility to "wipe" the second HDD, then I will reinstall Fedora 10 and try again. I'll be more diligent about documenting the error messages I get. This machine is essentially a "laboratory" for me to learn, so I'm willing to spend as much time as necessary not only to get it working, but to understand what I am doing. Thanks again, and I'll post my results ...
Okay, here are my results so far: I followed the HowTo guide verbatim. This time I got almost no errors. The one time errors were shown was when I was setting up the RAMdisk. Specifically, mkinitrd /boot/initrd-`uname -r`.img `uname -r` threw some errors related to I/O on device "fd0". Now, it is my understanding that most linux setups assume that one has a floppy disk attached. My machine does NOT have a floppy, and a bit of googling shows that this error is fairly common during some operations. Accordingly, I ignored these errors. If this is not correct, please let me know! Another point: I completed the entire operation in "runlevel 1". Previously, I had tried it in runlevel 5 (at first) and runlevel 3 (later). In each case, the copy operation produced the two errors I mentioned in my previous post. Booting to runlevel 1 did NOT produce these errors. Excuse me if this was obvious to some users of the guide: this is an area where my experience is limited, and if I was supposed to do this right off, I missed it. At any rate, besides the aforementioned "fd0" errors, the entire operation completed without a hitch. I watched as the array was built and it took awhile since I'm using a pair of SATA 500GB HDDs. I then finished all the steps to the second reboot. Booting into runlevel 1, "cat /proc/mdstat" showed exactly like I expected (and what was shown in the HowTo). At this point, I changed the default boot level back to runlevel 5. After getting to the graphical log in screen, I attempted to sign in using my username and password. Results: Same as before; the screen blanks momentarily, then returns to the graphical log in. Entering my username and an INCORRECT password produces the expected "Cannot authenticate user" response. This leads me to believe that the "copy" operations were successful, including the password files. Let me know if you disagree; I can't think of why it knows when my password is wrong, but won't 'log' me on when it is right. Some gnome script, perhaps? (Edit: booting or switching into runlevel 3 has the same problem, so I guess it's not Gnome. A message flashes on screen about "last login ..." but it is gone before I can read the two lines that show). I can boot into runlevel 1 again by entering the grub menu, so I can still possibly correct any of my errors. Okay, I'm pretty much at the end of where my limited experience can take me, but I really want to get it working. Any help would be appreciated!
Sqitching to a certain runlevel is not required. I did this setup on a server (runlevel 3) and had no problems. Did you disable SELinux?
I had disabled SELinux on a previous unsuccessful try, but I am virtually certain that I did NOT disable for this latest one. Could this be the problem? What about the respawning of the terminal login? There are some messages, but they flash too fast to read. Are these logged somewhere if they are errors? I looked in /var/log but didn't find anything. If I could determine what these messages are (if there are one or more errors) than perhaps I will not have to start again from scratch! Thanks ...
Thanks Falko! I changed the /etc/selinux/config to read "disabled" and rebooted. Now I can sign in on both runlevel 3 and runlevel 5. I think my machine is now FULLY configured for RAID, but I haven't done the testing for a failed disk yet. I may wait a bit and have a beer first ... I don't want to ruin the moment! Any advice on why SELinux nixed my log on would be appreciated. I guess I should also put a book about SELinux on my reading list! Rich
