Time for Slackware 12.0
Yesterday I had to install Linux on a Intel Core 2 Duo machine with
SATA disks. So, I figured I need both SMP and SATA support. My
trustworthy Slackware 10.2 seemed out of the question, or shall I
rather say: out of date. So I went for 11.0 as I didn’t have
12.0 DVD at hand and this was supposed to be a quick installation.
Well, it turned into a 9-hour marathon, ending in me giving up on SMP
at the end (until I try with Slackware 12.0).
Slackware 11.0 comes with 15 or so kernels. All but two of those are 2.4 kernels. Non of those 2.4 kernels supports the SATA controller in that machine. So, I had huge26 and test26 to test. The huge one should work on any machine? Couldn’t boot this one (Asus/Intel965, JMicron SATA controller). Pluging SATA disk into Intel ICH8 rather than JMicron fixed that and I was able to boot with test26.s. Unfortunately, after booting, there was no way for it to see the DVD ROM that was connected to PATA IDE. Going back to Bios and trying both compatibility and enhanced modes didn’t help at all - most of experiments with BIOS settings ended up in not being able to boot with any kernel. BTW, each time we changed a single setting in BIOS we rebooted and tried all of: sata.i, bare.i, test26.s, huge26.s and the only one that would sometimes work in test26.s. I’m inclined to say that sata.i kernel in Slackware 11.0 is next to useless.
In the end, we managed to find an USB DVD reader and decided to copy the DVD image to hard disk (as we had to return the USB DVD reader, we couldn’t affort to play and try to install from it). Now, we learned some more interesting things. For example, I ran fdisk and created 3 partitions. Formatted one of them as xfs (default option in Slack11) and ran:
dd if=/dev/sdb of=slack11dvd.iso
All was going nice until slack11dvd.iso reached 2GB file size. Now, it
was my first time using XFS and even though I know I read people having
huge files on it, I just figured that something might be wrong and
reformatted the partition to ext3 and start over. No luck, at 2GB mark we
got the same error. Ok, at this point I concluded that dd on Slackware
11.0 installation disk does not support files larger than 2GB. So I
mounted the DVD and used ‘cp -a’ to copy it over.
Next, I started ‘setup’ and go to the point to select media. Tried with ‘directory on local disk’ option (can’t recall the exact wording) and it gave me various errors before I gave up on it and selected the ‘pre-mounted CD or DVD’ or whatever it is called exactly. In the end I had just deleted the /var/log/mount (or something like that) directory where the installer expected to find the directory structure and symlinked that to that DVD copy I made with ‘cp -a’ earlier. It’s so cool that Slackware’s installer is a shell script and you can use ‘vi’ to peek inside and find easy ways to trick it into doing what you want it to do. Another cool thing is that Slackware gives you usable consoles while installing (available via alt+Fn combinations). Finally the Slackware installed.
Rebooting is a whole new story. As I was scared to choose kernel from CD during install (didn’t know if it was going to try searching the CD device again), I told it to just go with vmlinuz. It couldn’t boot, so I booted from DVD, went in, replaced default kernel with test26.s, run lilo and rebooted again. Now we now had a running Slackware 11.0 with SATA support. Great? Not yet.
Of course, test26.s kernel doesn’t have SMP support some one of our CPUs was simply just lying there dead doing nothing at all. Looking at various precompiled kernel options, I found 126.96.36.199-smp. Tried it - of course - no SATA support. At this point, some 4 hours have already passed, and I was looking at a choice: add SATA support to SMP kernel, or add SMP support to SATA kernel. The former seamed feasible, the latter impossible. Ok, I just figured that I need to add some modules for SATA stuff into kernel core and be done with it. But that would require to compile the entire kernel and I wasn’t really in a mood for that. Then I figured that we have to use initrd anyway, so why not just load sata drivers in it. Seemed like a best idea of the day. BTW, by now I learned the mkinitrd line by heart:
mkinitrd -c -k 188.8.131.52-smp -m jbd:ext3 -r /dev/sda1
This is the default line. To add more modules, simply add their names
(filenames of .ko files) to the list in -m option. So I added sata_mv as I
mistakenly thought that SATA controller was involved.
Ran mkinitrd, lilo, rebooted… kernel panic.
Booted from DVD again…this time reading all the output of boot process (and later analyzing dmesg). It’s nice that test26.s successfully loads almost all SATA stuff (not modules - it’s built in) without errors - so it’s really hard to determine which of those is really used. lsmod cannot help at this time. If you knows how to get ‘lsmod’ for stuff that is compiled into the kernel PLEASE LET ME KNOW.
So, I started adding stuff to the -m line of mkinitrd. Some of the modules I recognized instantly, for others I used ‘grep’ in /lib/modules to find out. I the end I had about 12 modules, output of loading process was quite similar to the one of test26.s but still it wasn’t able to see the SATA disk, and still wasn’t able to boot. The only module making problems was ipr (some IBM’s SATA controller I believe), but I wasn’t able to determine why it cannot load. Looking at modules.dep it didn’t seem that it has some dependent modules that I need to preload before it.
I also had problem with my network card not being supported by test26.s, which is (if someone wonders) kernel 2.6.18. But that’s a minor issue as the card is supported in 2.6.20, and one RTL8139 is doing the job in the meantime.
The current state is that we’re running with SATA disk and one CPU and PCI Ethernet card. I’m looking forward to Slackware 12.0 and 2.6.21 kernel which should solve this.