Well, I got it to boot. Now that it's up, I can see what the problem was/is. There are no disk device files in /dev.
I created the appropriate nodes and things went much better. The problem was that CONFIG_SYSFS_DEPRECATED_V2 was on I just closed up the chassis and it will ship in the morning. Thank you for your help! Mike. On Friday 15 October 2010 3:02:27 pm Florian Philipp wrote: > Am 15.10.2010 21:23, schrieb Mike Diehl: > > On Friday 15 October 2010 11:40:34 am Florian Philipp wrote: > >> Am 15.10.2010 19:29, schrieb Mike Diehl: > >>> Hi all. > >>> > >>> I've never had this much trouble with a server before, but I've been > >>> pulling my hair out. > >>> > >>> The install seemed to go well, but when I rebooted it from it's own > >>> hard drive, it fails. fsck claims that it can't open /dev/sda3 or > >>> that the superblock doesn't describe a valid ext2 filesystem. > >> > >> *All* of the drivers could be too much. There is a generic driver which > >> can prevent the "right" driver from taking over. In that case you end up > >> with a /dev/hda node and no DMA. Try to deactivate "Generic ATA support" > >> = CONFIG_ATA_GENERIC and "generic/default IDE chipset support" = > >> CONFIG_IDE_GENERIC. > >> I think it is the second option that causes that problem. However, you > >> won't need the first option, either. > > > > I tried this, first without success. I then ran through all combinations > > of sda3, sdb3, hda3, hdb3 in /etc/fstab. This didn't work. > > > >> Instead of your brute-force "yes to all" approach, newer kernels also > >> support `make localyesconfig` which takes all modules currently used in > >> the running kernel and compiles them into the new kernel. It is very > >> helpful when you already have a good but generic kernel like the one on > >> your live CD. > > > > I tried this, next. At least now, I believe I have a viable kernel. But > > it still didn't work. > > > >> If even that doesn't help, it might be possible that the device > >> numbering has changed and your hard disk is detected as /dev/sdb or so. > >> Try mounting it by UUID (google for it, please). > > > > I tried this. Only now, fsck.ext2 tells me that it can't resolve the > > UUID. > > > > Here is the new fstab: > > /dev/sda1 /boot ext2 noauto,noatime 1 2 > > > > UUID=ba7511dd-a5f9-48d8-8102-cf71c08a0c7b / ext2 noatime > > 0 1 > > > > /dev/sda2 none swap sw 0 0 > > /dev/cdrom /mnt/cdrom auto noauto,ro 0 > > 0 > > > > At this point, I'm going to move the drive to a different port on the > > SATA chain; shouldn't change anything, but I'm running out of ideas. > > I'll also check the BIOS for anything stupid-obvious. > > > > So, I guess I'm still stuck! > > Hmm, sounds like a serious problem. I suggest you try to get into an > early stage during boot and try to move forward from there. Try to add > '1' to the parameters in order to get into single-user mode. You can > also try 'init=/bin/bash'. > > There are lots of other options you can try. For a long time, 'noapic' > (not 'noapci') was my first candidate for odd boot issues. Take a look > at /usr/sr/linux/Documentation/kernel-parameters.txt for more options. > > Also, which kernel sources are you using and which live CD (with which > kernel version)? Is there a specific reason why you use ext2 for root? > What kind of system do you run, anyway? And, just by chance, you are not > using an extremely large (>1TB) drive which might happen to have 4kB > blocks instead of 512 B? > > Regards, > Florian Philipp -- Take care and have fun, Mike Diehl.
