Bug#544592: linux-image-2.6.30-1-686: sometimes failed to boot

[Davide Prina <davide.prina@gmail.com>]

Ben Hutchings wrote:
> On Thu, 2009-09-03 at 22:17 +0200, Davide Prina wrote:
> > Ben Hutchings wrote:
> > > On Tue, 2009-09-01 at 20:44 +0200, Davide Prina wrote:

> > > > sometimes the boot fail: after grub I see: "Loading, please wait ...", 
> > > > but the hard disk is not used.
> > > > After a while busybox appear; here I can see that /proc/cmdline try to 
> > > > start something in directory /dev/disk/by-id, but this directory don't 
> > > > exists.

> > > The problem there appeared to be that your custom kernel included two
> > > different drivers that both supported your disk controller.

> > How can you found when a module is a duplication of another one?
>
> In general, grep for the device id string in modules.alias.
>
> > I have done the following steps:
> >
> > $ lspci
> > [...]
> > 00:11.0 Mass storage controller: Promise Technology, Inc. PDC20265 
> > (FastTrak100 Lite/Ultra100) (rev 02)
> > [...]
> >
> > $ cat /sys/bus/pci/devices/0000\:00\:11.0/vendor
> > 0x105a
> > $ cat /sys/bus/pci/devices/0000\:00\:11.0/device
> > 0x0d30
>
> You can find drivers that claim this device using:
>
>     grep pci:v0000105Ad00000D30 /lib/modules/$(uname -r)/modules.alias

If I use the 2.6.30-1-686 as $(uname -r) I have:

$ for i in $(grep pci: /lib/modules/$(uname -r)/modules.alias \
             | sed "s/^.*:v\([^v]*\)v.*$/pci:v\1/"); do \
   if [ $(grep $i /lib/modules/$(uname -r)/modules.alias | wc -l) \
        -gt 1 ]; then \
    echo "$i - $(grep $i /lib/modules/$(uname -r)/modules.alias | \
          wc -l)"; \
   fi; \
  done

pci:v000010ECd00008139s - 2
[...]

$ grep ci:v000010ECd00008139s /lib/modules/2.6.30-1-686/modules.alias
alias pci:v000010ECd00008139sv*sd*bc*sc*i* 8139cp
alias pci:v000010ECd00008139sv*sd*bc*sc*i* 8139too

in fact I have 8139too, in my custom Linux I have:
$ grep ci:v000010ECd00008139s /lib/modules/2.6.30-custom/modules.alias
alias pci:v000010ECd00008139sv*sd*bc*sc*i* 8139too

why this duplication in 2.6.30-1-686 do not generate problems?
Only some duplication type can generate problems?

> > but still have problems. I noted that good boots have greatly increased 
> > over bad boots (I have made few reboots and nearly all are good now).

this is a wrong information.
Bad boot persist. Probably I have had a long "good boot" series.

> > When I have a bad boot I have the message saying that it is impossible 
> > to remove the SCSI_WAIT_SCAN module (I have disable the "module 
> > unloading" option).
> [...]
>
> Reenable CONFIG_MODULE_UNLOAD and see if you can boot.

done.
It seem that now the boot is ok.
I don't know if I'm in a long "good boot" series or the problem is resolved.

But how enabling the "unloading module" will solve the boot problems?
I don't understand.

I read this DD announce "The future of the boot system in Debian"

http://lists.debian.org/debian-devel-announce/2009/09/msg00003.html

I think this can be the real problem I have encountered. Or not?

Very thanks for all your help

I will inform you next days if I have again "bad boots"

Ciao
Davide

--
Dizionari: http://linguistico.sourceforge.net/wiki
Strumenti per l'ufficio: http://it.openoffice.org
GNU/Linux User: 302090: http://counter.li.org
Non autorizzo la memorizzazione del mio indirizzo su outlook