I have a Dell Poweredge 700 Server, Bios A00, with a P4 cpu and Intel ICH5R SATA chipset. Attempted install was with the 2004.1 Universal CD. For some weird reason, I could not boot the system via the smp kernel; everything seemed fine, except the video was screwed up (only saw a set of vertical flashing stripes; I tried disabling the framebuffer, using the agpgart module, etc; no luck). So - I decide to boot with the regular "gentoo" kernel (2.4). No problems. Nice beautiful boot. I partitioned and installed the base system on my two 250 Gb SATA disk. No problems. I built and installed the "gentoo-sources" kernel. Then I reboot. My boot partition was the first 256M of the first disk, ext2. Problems. The stock kernel could not read the generated initrd properly; it kept complaining about media errors. Nothing I did would fix this. So, I decided to build and install a "gentoo-dev-sources" 2.6 era kernel, building the ATA_PIIX drivers as NON-modules (internal to the kernel). Everything works now... except the hard disks were renamed from the old /dev/hdX names to the new /dev/scsi/[etc] disks. This would REALLY confuse a newbie, the fact that SATA=SCSI for some drivers. Yech. I would like to find out why the live-cd "gentoo" kernel had no probs with the SATA disks under /dev/hdX emulation, but the built "gentoo-sources" kernel had problems. I validiated and fscked under both kernels: the former works, the latter does not. Incidentally, the Dell PE-700 does NOT allow you to set the SATA subsystem to legacy parallel mode, so that is NOT an option. Reproducible: Always Steps to Reproduce: See "details" Actual Results: Very difficult to get gentoo running, and very tricky to upgrade kernels... and I've been building kernels for years! Expected Results: Warning about the SATA craziniess in the docs. The 2.6.5-r1 gentoo-dev-sources kernel can NOT recognize the SATA disks unless the ATA_PIIX drivers are compiled into the kernel (not as a module).
not a livecd-issue - system already installed.
Pardon me if this comment is inapropriate, but I've dealt with this issue myself, and I feel that it wouldnt be that big an issue if there were better documentation. just thinking that this may be as much a documentation bug as a kernel bug.
Hm, not really a kernel bug at all...