Problem booting 2.6.13 on RHEL 4

Problem booting 2.6.13 on RHEL 4

[Rajat Jain]

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

Re: Problem booting 2.6.13 on RHEL 4

[liyu@WAN]

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 majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>
>  
>

Re: Problem booting 2.6.13 on RHEL 4

[Bill Davidsen]

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 (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

RE: Problem booting 2.6.13 on RHEL 4

[Roger Heflin]

 

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org 
> [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Bill Davidsen
> Sent: Wednesday, September 14, 2005 11:21 AM
> To: liyu@WAN
> Cc: Linux-newbie@vger.kernel.org; linux-kernel@vger.kernel.org
> 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

Re: Problem booting 2.6.13 on RHEL 4

[Jason Baron]

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 

Re: Problem booting 2.6.13 on RHEL 4

[Rajat Jain]

>
> 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