Re: [opensuse] boot after installation problem
- From: Ken Schneider <suse-list3@xxxxxxxxxxxxx>
- Date: Thu, 07 Feb 2008 08:04:45 -0500
Ian Marlier pecked at the keyboard and wrote:
On 2/6/08 11:58 PM, "Fred A. Miller" <fmiller@xxxxxxxxxxxxx> wrote:
Lew Wolfgang wrote:
Hi Folks,I don't have an answer for you nor could I find anything except that
I'm having a problem installing 10.3 x86_64 on a box with
many raid disk controllers and disks. It has two disks
mounted in the back that are supposed to be the system
disks, configured as a raid1 mirror. Alas, this disk
shows up after all the other disks, in this particular
case as /dev/sde instead of /dev/sda.
A full install goes well until the first boot. The boot
fails saying it can't find /dev/sde3 (the root partition).
It eventually drops into a limited sh shell running out
of ram.
This box worked ok when the system disk appeared as /dev/sdc.
I wonder if there is some bug about booting from disks too
far removed from /dev/sda?
I've got a call in to the manufacturer to see if there's
a way to have the system disks show up as /dev/sda, but
no word from them yet.
Anyone seen this behavior? The controllers are 3-Ware,
the disks SATA, if that matters.
apparently the company has been bought out by a non-Linux friend company
(AMCC) and there are performance complaints now showing up. Here's a
reference: http://lxer.com/module/forums/t/26605/
I'm running several dozen servers with 3ware cards, all of them running
opensuse 10.1 to opensuse 10.3. The kernel modules for those cards have
been updated consistently for their latest hardware, backwards compatibility
for new cards has always worked, and they've made a point to keep all of
their management tools (3dm2) up to date on Linux as well as Windows and
other platforms.
As far as vendors in the Linux world go, they're about as close to the top
of the heap as anyone. Whatever Sander Marechal's complaints, they don't
have any relation to my real-world experience.
That said: I've had problems like yours in the past.
At root, it has to do with something seemingly ridiculous: alphabetical
order. When the installation system is probing for hardware, it does so by
loading each kernel module and seeing whether any new hardware appears. (Or
something else, the effect of which is identical to this.) Because the
3ware modules are loaded very early -- 3w-9xxx.so is, after all, very early
in alphabetical order -- 3ware disks almost always show up as /dev/sda.
However, this order does not hold when the initrd for the installed system
is created. There's an explicit order that's created in that case.
Within the initrd filesystem, at the root level, there's a file called
"init". It's basically a shell script, and is created dynamically when the
initrd is created at the end of the installation process. It includes a
section that loads the various modules. Somehow the 3w_9xxx kernel module
always ends up being loaded after others, especially the modules for onboard
SATA controllers.
The only fix that I've found is to rebuild the initrd. Fortunately, it's
pretty easy:
- Boot from a rescue disk;
- chroot to the installed system;
- edit /etc/sysconfig/kernel; for the parameter "INITRD_MODULES", make sure
that "3w_9xxx" is listed before any other scsi/sata/ata/etc modules.
- do "mkinitrd"
I do almost all of my installs via autoyast, and have had this problem off
and on with builds from suse 9.1 through 10.3. At one time, I actually had
a chroot-script (run after the installation of the system but before the
first reboot, chrooted within the installed system) that would do this. For
opensuse 10.2 I found that I didn't need it, but I'm about to start to set
up the 10.3 autobuild for these servers, so who knows...
In my case, my machines almost all have Silicon Image controllers onboard,
in addition to the 3ware cards. So the chroot script was something
basically like this (I'll see if I can dig the exact script out of the
subversion repository where I keep my autoyast configs tomorrow):
#!/bin/sh
## Alter the INITRD_MODULES line appropriately
sed -i s/sata_sil 3w_9xxx/3w_9xxx sata_sil/g" /etc/sysconfig/kernel
## Rebuild initrd
mkinitrd
exit 0
FWIW, my personal opinion is that the bug lies in initrd/mkinitrd/the initrd
creation process, and not the card; that is, the process of creating the
initrd should be smarter about disk detection order, and force a load of the
module needed for the disk on which the bootloader is installed before any
others.
Have you filed a bug report with this info? Sounds very similar to
problems many people are having, install order of disks is different
then boot order of disks.
--
Ken Schneider
SuSe since Version 5.2, June 1998
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx
- References:
- Re: [opensuse] boot after installation problem
- From: Ian Marlier
- Re: [opensuse] boot after installation problem
- Prev by Date: [opensuse] A bug in KDE when using ext3 in a USB disk?
- Next by Date: Re: [opensuse] route question
- Previous by thread: Re: [opensuse] boot after installation problem
- Next by thread: Re: [opensuse] boot after installation problem
- Index(es):
Relevant Pages
|
