2005-09-14 04:08:08

by Rajat Jain

[permalink] [raw]
Subject: Problem booting 2.6.13 on RHEL 4

Hi list,

I am using RHEL4 distribution, and am trying to boot with vanilla
2.6.13 stock kernel. My system has two onboard Adaptec SCSI
controllers. I am booting using initrd, and passing the correct
"root=" option. The following message pops up while trying to boot
with 2.6.13:

Loading scsi_mod.ko module
Loading sd_mod.ko module
Loading scsi_transport_spi.ko module
SCSI subsystem initialized
Loading aic7xxx.ko module
Creating root device
umount /sys failed: 16
Mounting root filesystem
Mount: error 6 mounting ext3
Mount: error 2 mounting none
Switching to new root
switchroot: mount failed: 22
umount /initrd/dev failed: 2
Kernel panic - not syncing: Attempted to kill init!

When I boot the default kernel supplied with RHEL 4, it boots successfully:

Loading scsi_mod.ko module
SCSI subsystem initialized
Loading sd_mod.ko module
Loading scsi_transport_spi.ko module
Loading aic7xxx.ko module
ACPI: PCI interrupt 0000:05:09.0[A] -> GSI 18 (level, low) -> IRQ 201
ACPI: PCI interrupt 0000:05:09.1[B] -> GSI 19 (level, low) -> IRQ 169
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36
<Adaptec aic7899 Ultra160 SCSI adapter>
aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs

(scsi0:A:0): 160.000MB/s transfers (80.000MHz DT, offset 126, 16bit)
Vendor: HITACHI Model: DK32CJ-18MW Rev: JTN1
Type: Direct-Access ANSI SCSI revision: 03
scsi0:A:0:0: Tagged Queuing enabled. Depth 4
SCSI device sda: 35520512 512-byte hdwr sectors (18187 MB)
SCSI device sda: drive cache: write back
sda: sda1 sda2 sda3 sda4 < sda5 >
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36
<Adaptec aic7899 Ultra160 SCSI adapter>
aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs

Can some one please suggest me what could be the problem? I doubt if
there is any option I need to enable in the kernel configuration?

Any pointers are welcome,

TIA,

Rajat Jain


2005-09-14 08:14:04

by liyu

[permalink] [raw]
Subject: Re: Problem booting 2.6.13 on RHEL 4


It seem that kernel have no time to probe your disk, and do not
read parttion table.

I use kernel 2.6.12 and SATA disk on FC3, also failed to boot.
but after some experiment, I found if we place 'sleep 5'
statement between insmod commands in linuxrc or init, it will
boot up!

However, this idea is too HACK.

Maybe, I guest, kernel need some time to probe scsi disk?
but I can not explain that kernel say unresoluting symbol XXXXX
use this reason.



May be also, there have one problem in older mkinitrd. but
I looked its source (more roughly), it only include some scriptes.

Any more clear idea on it ??



Rajat Jain wrote:

>Hi list,
>
>I am using RHEL4 distribution, and am trying to boot with vanilla
>2.6.13 stock kernel. My system has two onboard Adaptec SCSI
>controllers. I am booting using initrd, and passing the correct
>"root=" option. The following message pops up while trying to boot
>with 2.6.13:
>
>Loading scsi_mod.ko module
>Loading sd_mod.ko module
>Loading scsi_transport_spi.ko module
>SCSI subsystem initialized
>Loading aic7xxx.ko module
>Creating root device
>umount /sys failed: 16
>Mounting root filesystem
>Mount: error 6 mounting ext3
>Mount: error 2 mounting none
>Switching to new root
>switchroot: mount failed: 22
>umount /initrd/dev failed: 2
>Kernel panic - not syncing: Attempted to kill init!
>
>When I boot the default kernel supplied with RHEL 4, it boots successfully:
>
>Loading scsi_mod.ko module
>SCSI subsystem initialized
>Loading sd_mod.ko module
>Loading scsi_transport_spi.ko module
>Loading aic7xxx.ko module
>ACPI: PCI interrupt 0000:05:09.0[A] -> GSI 18 (level, low) -> IRQ 201
>ACPI: PCI interrupt 0000:05:09.1[B] -> GSI 19 (level, low) -> IRQ 169
>scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36
> <Adaptec aic7899 Ultra160 SCSI adapter>
> aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
>
>(scsi0:A:0): 160.000MB/s transfers (80.000MHz DT, offset 126, 16bit)
> Vendor: HITACHI Model: DK32CJ-18MW Rev: JTN1
> Type: Direct-Access ANSI SCSI revision: 03
>scsi0:A:0:0: Tagged Queuing enabled. Depth 4
>SCSI device sda: 35520512 512-byte hdwr sectors (18187 MB)
>SCSI device sda: drive cache: write back
> sda: sda1 sda2 sda3 sda4 < sda5 >
>Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
>scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36
> <Adaptec aic7899 Ultra160 SCSI adapter>
> aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs
>
>Can some one please suggest me what could be the problem? I doubt if
>there is any option I need to enable in the kernel configuration?
>
>Any pointers are welcome,
>
>TIA,
>
>Rajat Jain
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
>

2005-09-14 16:22:00

by Bill Davidsen

[permalink] [raw]
Subject: Re: Problem booting 2.6.13 on RHEL 4

liyu@WAN wrote:
>
> It seem that kernel have no time to probe your disk, and do not
> read parttion table.
>
> I use kernel 2.6.12 and SATA disk on FC3, also failed to boot.
> but after some experiment, I found if we place 'sleep 5'
> statement between insmod commands in linuxrc or init, it will
> boot up!
>
> However, this idea is too HACK.

It would have been nice, back in the 2.5.46 timeframe when modules were
complete reinvented, to have provided a hook by which modprobe could
have waited until insertion init was complete.

The sleep is a hack indeed, as is the slightly more reliable solution to
tail the log and look for init messages to appear. Perhaps look for the
devices in /proc/scsi/scsi or something?

There doesn't seem to be a "right way" for this, particularly if you
have both warm and cold boots, which may differ by minutes depending on
disk spin-up already being done.

--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me

2005-09-14 16:45:43

by Roger Heflin

[permalink] [raw]
Subject: RE: Problem booting 2.6.13 on RHEL 4



> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Bill Davidsen
> Sent: Wednesday, September 14, 2005 11:21 AM
> To: liyu@WAN
> Cc: [email protected]; [email protected]
> Subject: Re: Problem booting 2.6.13 on RHEL 4
>
> liyu@WAN wrote:
> >
> > It seem that kernel have no time to probe your disk, and do
> not read
> > parttion table.
> >
> > I use kernel 2.6.12 and SATA disk on FC3, also failed to boot.
> > but after some experiment, I found if we place 'sleep 5'
> > statement between insmod commands in linuxrc or init, it
> will boot up!
> >
> > However, this idea is too HACK.
>
> It would have been nice, back in the 2.5.46 timeframe when
> modules were complete reinvented, to have provided a hook by
> which modprobe could have waited until insertion init was complete.
>
> The sleep is a hack indeed, as is the slightly more reliable
> solution to tail the log and look for init messages to
> appear. Perhaps look for the devices in /proc/scsi/scsi or something?
>
> There doesn't seem to be a "right way" for this, particularly
> if you have both warm and cold boots, which may differ by
> minutes depending on disk spin-up already being done.
>

I have seen this.

On one machine with 2 scsi adaptors 10 seconds was enough, on a different
machine with 6 channels it had to be over 45 seconds to get things to be
found reliabily, and I don't know if that is always going to be reliable.

It would have been nice if there were at least an option on modprobe so
that it could be set to not return after init on the critical modules,
ie mostly disk modules, but I have seen failures on other parts because
the modprobe is not quite finished and ready for the next step after
it returns.

Any better way to deal with this?

Roger

2005-09-15 15:25:30

by Jason Baron

[permalink] [raw]
Subject: Re: Problem booting 2.6.13 on RHEL 4


On Wed, 14 Sep 2005, Rajat Jain wrote:

> Hi list,
>
> I am using RHEL4 distribution, and am trying to boot with vanilla
> 2.6.13 stock kernel. My system has two onboard Adaptec SCSI
> controllers. I am booting using initrd, and passing the correct
> "root=" option. The following message pops up while trying to boot
> with 2.6.13:
>

it might be worth trying an updated 'mkinitrd'. The one currently in rhel4
can currently do parallel 'insmod's, which might be causing this issue.
See bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145660
for more detail. This is fixed in U2, which isn't quite shipping yet, but
in the meantime, I think you can get the updated package from the U2 beta
channel.

thanks,

-Jason

2005-09-28 09:18:28

by Rajat Jain

[permalink] [raw]
Subject: Re: Problem booting 2.6.13 on RHEL 4

>
> On Wed, 14 Sep 2005, Rajat Jain wrote:
>
> > Hi list,
> >
> > I am using RHEL4 distribution, and am trying to boot with vanilla
> > 2.6.13 stock kernel. My system has two onboard Adaptec SCSI
> > controllers. I am booting using initrd, and passing the correct
> > "root=" option. The following message pops up while trying to boot
> > with 2.6.13:
> >
>
> it might be worth trying an updated 'mkinitrd'. The one currently in rhel4
> can currently do parallel 'insmod's, which might be causing this issue.
> See bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145660
> for more detail. This is fixed in U2, which isn't quite shipping yet, but
> in the meantime, I think you can get the updated package from the U2 beta
> channel.

Hi Jason,

Thanks a TON! I was truggling with mkinitrd and nash for the past 3
weeks, and finally a *very* odd combination of mkinitrd and nash
solved the problem. But thanks for your inputs, they've been really
helpful.

Rajat