Unable to install Debian SID on new laptop :-(
Apologies in advance for the length of this post. Those who
don't have a hearty appetite for sharing other's problems
should bail out now :-(.
A few weeks back, I bugged you all for the first time, while
preparing for where I am now. Back then, I was trying to
install a debian sid 2.6.4 kernel on an old Dell Inspiron
7000. That was a "test run" in preparation for buying a new
laptop. I was quite stuck, having never installed anything
other than Xandros (and Windows :-), which installs
correctly on nearly every machine imaginable!
Anyway, a number of you kind folks were able to help me over
the hump, and I have that laptop running nicely now (even
upgraded it to a 2.6.5 kernel the other day, downloaded from
kernels.org).
Last week I purchased a high-end Sager NP8890. 2 60GB
7200RPM drives, 2GB ram, 3.4ghz P4, 800mhz front-side bus,
16" 1600x1200 screen with 128MB DDR, etc.
I was going to do _exactly_ what I did on the Dell to get it
running, which was:
1) Boot from LindowsOS Live CD
2) use "debootstrap" to create a "chroot" environment on the
hard disk
3) chroot to there, and use apt-get, etc., to install a
kernel, etc.
4) Boot from the new drive.
Machine showed up early on Monday. Since I still don't have
things working, you should only know how much grief I have
gone through trying hundreds of things over the past 4 days,
and googling my brains out, before coming hat in hand (once
again) to this list... Please pity me :-)
OK, so I booted off of the Lindows CD. Unfortunately, while
output from dmesg shows that it recognized the two drives
(sort of), they weren't available in /dev/ to be mounted,
fdisk'ed, etc. They were invisible to Lindows, even though
the hardware probe showed that they were there.
They showed up as "hde" and "hdg". It turns out that this
machine has a RAID capable controller (though I purposely
configured the machine at purchase to have _no raid_, and
that was correctly done). The controller is a Promise
Ultra100 DMA.
I'm such a novice at this stuff that I am not sure if there
was anything that I could have done at that point to
"enable" Lindows to see the drive(s), but I quickly gave up
and decided to do what I had hoped to avoid doing, which was
to "install directly to the disk", and then "upgrade".
So, I popped in my Xandros Desktop 2.0 CD, and (thankfully!)
it recognized the drives and installed correctly. In fact,
everything "just worked", including sound, running X at
1600x1200, both drives, internet (the chip is Gigabit
capable :-). I was able to configure a PCMCIA wireless card
correctly as well.
So, you say I should be happy. Unfortunately, my original
goal was to put "sid" with a 2.6.4 kernel on the machine,
not to run XD. I thought I was home free, figuring that I
could run "debootstrap" on the second drive, chroot to it,
install it there, and worst case be able to "dd" it back to
the first drive!
debootstrap got reasonably far along each time, and then
always failed in one of two ways:
1) After checking, validating and extracting _all_ of the
packages apparently successfully, it would complain that the
"ln" command failed because "/bin/awk" already existed. I
checked, and sure enough, there was a link from awk->mawk. I
removed the link, and then it complained that libc6 wasn't
installed (or wasn't a "high enough" version), and nothing
that I did would change that. I knew from earlier
experiments (that I am sparing you!) that if I started
mucking too much on the XD disk, I'd get it to a point of
instability and have to reinstall (yes, I had to install XD
at least 3 or 4 times over the past few days, and now I can
only work in single user mode...).
Suffice it to say that debootstrap just ended up "not being
worth the effort"...
2) I (foolishly) thought that perhaps now that there was a
valid Linux distro (a close cousin of Lindows!) on the disk,
that Lindows Live would recognize the disk. So, I booted
from it again, but unfortunately, it was wishful thinking as
the drives were still invisible, even though the hde and hdg
lines were in dmesg.
3) I then decided to see if I could build a newer kernel,
boot from it, and then dist-upgrade to sid, etc. No matter
what I did, I couldn't get the "initrd" image to work. After
much hair pulling, it turns out that XD has a custom
mkinitrd in their own package, which doesn't take the
standard args, and so I had to start the dance of slowly
sucking in upgraded packages. Same turned out to be true for
lilo. So, at some point, I had a "Frankenstein" system with
parts XD and parts sid. Never got the new kernel to boot
though...
4) Next bright idea was to build a new kernel on the Dell
with make-kpkg, and install the package on the Sager. Toward
that end, I downloaded and built a 2.6.5 kernel from
kernels.org, and it had the Promise drivers in menuconfig.
Unfortunately, the Dell is slow, and it took 3 hours 20
minutes to build the kernel. Luckily, it built correctly. I
first installed it on the Dell, which is now happily running
2.6.5 :-). Bringing the package over to the Sager and
installing it yielded no joy. It seemed that the initrd was
the problem again, even though the identical initrd worked
on the Dell. So, the Sager obviously needed something in the
kernel or the initrd image that the Dell didn't.
5) I decided to "go for broke", break the XD install (hence
the ability only to use single user console mode now), and
do a dist-upgrade to sid, so that I could build the kernel
more reliably on the Sager. On one level alone it was a good
move. The same build that took 3.33 hours on the Dell takes
about 40 minutes on the Sager :-). I have built the kernel
at least 5 times, each time shoving more things directly
into the kernel away from modules (trying to get away from
initrd dependencies).
OK, all of the above was background (that I condensed hugely
from 4 days of pain...), to let you know how close I am, but
still no cigar!
When it boots now, I can see everything being probed and
apparently coming up correctly as well. The drives both get
recognized with exactly the same bios and port numbers that
XD sees them as, and I see messages that an EXT3 filesystem
journal is in a correct state (or something like that), and
one for ReiserFS as well (the first disk is ext3 and the
second reiser). XD defaults to Reiser, but on a subsequent
install I switched the primary drive to ext3 in case reiser
was causing my updated kernel problems (which it apparently
wasn't).
The last two messages are that RAMDISK installed the CramFS
correctly (and I see a "done." message unpacking XXXX
blocks), then the following error message:
Kernel Panic: VFS: Unable to mount root fs on hde2
Yes, hde2 is the correct root, and that's what XD correctly
boots from. I tried a variety of "root=" parameters in lilo,
including the full "/dev/ide/host2/bus0/target0/lun0/part2".
Nothing works.
After much googling, I settled on the logical conclusion
that the initrd image doesn't have the correct drivers to
read the hard drive. It's strange, because the kernel
clearly can, seeing the journals on both drives in both ext3
and reiserfs formats. my mkinitrd command is:
mkinitrd -o initrd.img-2.6.5 /lib/modules/2.6.5/
The conf files has "MODULES=most", and the initrd image is
over 3 megs, so their in there (I think :-), but I'm
confused anyway, since the kernel itself has them all
statically linked in. I also name ext3 reiser and jbd (just
because XD had it in their initrd) in the
/etc/mkinitrd/modules file, though like I said, I think they
are statically linked in...
I feel like I'm tantalizingly close, but also miles away. As
I type this, I'm downloading a Knoppix 3.3 iso image (which
was suggested the last time by at least one person on the
list), to see if I can boot that live and have the drive
recognized. Part of the problem (in my simpleton opinion) is
that XD is such a customized distro (a very nice one at
that!), that once I mix and match, all bets are off. If I
could do all of this off of a Live CD, then I can create a
pristine distribution on the drive itself (like debootstrap).
One of the big problems is that I can't do a line-by-line
comparison of the XD dmesg output and the bad 2.6.5 dmesg
output, because after the kernel panic, the machine has to
be hard-power-cycled, and of course, I can only see 25 lines
of output on the screen. Like I said previously, most of the
messages that scroll by seem 100% correct, and I can see the
one that fails...
P.S. I saw people with the same error message on the kernel
panic get responses like add a "mem=XXXM" to the boot line.
I did, and it didn't help.
At this point, I'm a little at my wits end. I would _hate_
to "give in" and just keep this as an XD machine. I am truly
impressed by XD, and for many people, it's likely a perfect
fit. I like to play with new things, which often don't work
on XD because they are an older release with a very custom
kernel, and they are oriented towards businesses, so
stability is more important than innovation. I can't easily
sync my treo 600 to XD, but it works out of the box with
2.6.4 sid. That's but one of many examples :-)
Any pointers will be greatly appreciated, even just a "wow,
I feel your pain" :-).
I would be delighted to post my ".config" file, and anything
else that I can get my hands on (other than the dmesg
output, unless anyone has any bright suggestions), but I
thought that might be overkill given the sheer length of
this post...
Thanks in advance!
Reply to: