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 2.6.17.13-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 2.6.13.17-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.