[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#544592: marked as done (linux-image-2.6.30-1-686: sometimes failed to boot)

Your message dated Sat, 05 Sep 2009 20:38:24 +0100
with message-id <1252179504.3494.9.camel@localhost>
and subject line Re: Bug#544592: linux-image-2.6.30-1-686: sometimes failed to boot
has caused the Debian Bug report #544592,
regarding linux-image-2.6.30-1-686: sometimes failed to boot
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
544592: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544592
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: linux-image-2.6.30-1-686
Version: 2.6.30-6
Severity: important
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. 

Probably somethings crash of freeze and the boot fail.
To solve the problem I have to reboot X times (X >= 0) with Ctrl-Alt-Canc or AltGr-RSyst-b.
I think this problem is related to the bug #543209. I don't have anymore the disks remapped, but I cannot boot sometimes (I think that the remapped problem is migrated into the boot fail problem).
Please if you think this bug is not related to the linux-image package than reassign. I have reported the bug to this package because bug #543209 start when I installed Linux 2.6.30 the first time and this bug appear when I have upgrade to the new Linux 2.6.30 subversion
Please don't close the bug as the #543209 with no explanation, please help me to understand the problem. 

If you need more information let me know.

Ciao
Davide


-- Package-specific info:

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.30-customized
Locale: LANG=it_IT@euro, LC_CTYPE=it_IT@euro (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash

Versions of packages linux-image-2.6.30-1-686 depends on:
ii debconf [debconf-2.0] 1.5.27 Debian configuration management sy ii initramfs-tools [linux-initra 0.93.4 tools for generating an initramfs ii module-init-tools 3.10-3 tools for managing Linux kernel mo 

Versions of packages linux-image-2.6.30-1-686 recommends:
ii libc6-i686 2.9-25 GNU C Library: Shared libraries [i 

Versions of packages linux-image-2.6.30-1-686 suggests:
ii grub-pc [grub] 1.96+20090808-1 GRand Unified Bootloader, version 
pn  linux-doc-2.6.30         <none>          (no description available)

-- debconf information:
  linux-image-2.6.30-1-686/preinst/lilo-has-ramdisk:
  linux-image-2.6.30-1-686/postinst/create-kimage-link-2.6.30-1-686: true
linux-image-2.6.30-1-686/prerm/would-invalidate-boot-loader-2.6.30-1-686: true 
  linux-image-2.6.30-1-686/preinst/overwriting-modules-2.6.30-1-686: true
  linux-image-2.6.30-1-686/postinst/old-dir-initrd-link-2.6.30-1-686: true
  linux-image-2.6.30-1-686/preinst/failed-to-move-modules-2.6.30-1-686:
  linux-image-2.6.30-1-686/preinst/initrd-2.6.30-1-686:
  linux-image-2.6.30-1-686/prerm/removing-running-kernel-2.6.30-1-686: true
  linux-image-2.6.30-1-686/postinst/kimage-is-a-directory:
  linux-image-2.6.30-1-686/preinst/abort-overwrite-2.6.30-1-686:
  linux-image-2.6.30-1-686/preinst/bootloader-initrd-2.6.30-1-686: true
  linux-image-2.6.30-1-686/postinst/depmod-error-initrd-2.6.30-1-686: false
  shared/kernel-image/really-run-bootloader: true
  linux-image-2.6.30-1-686/postinst/old-initrd-link-2.6.30-1-686: true
  linux-image-2.6.30-1-686/postinst/depmod-error-2.6.30-1-686: false
  linux-image-2.6.30-1-686/postinst/old-system-map-link-2.6.30-1-686: true
  linux-image-2.6.30-1-686/preinst/lilo-initrd-2.6.30-1-686: true
  linux-image-2.6.30-1-686/postinst/bootloader-test-error-2.6.30-1-686:
  linux-image-2.6.30-1-686/preinst/abort-install-2.6.30-1-686:
  linux-image-2.6.30-1-686/postinst/bootloader-error-2.6.30-1-686:
  linux-image-2.6.30-1-686/preinst/elilo-initrd-2.6.30-1-686: true

--
Dizionari: http://linguistico.sourceforge.net/wiki
Perché microsoft continua a compiere azioni illegali?:
http://linguistico.sf.net/wiki/doku.php?id=traduzioni:ms_illegal
GNU/Linux User: 302090: http://counter.li.org
Non autorizzo la memorizzazione del mio indirizzo su outlook

--- End Message ---
--- Begin Message --- 
On Sat, 2009-09-05 at 19:58 +0200, Davide Prina wrote:
> 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?

Some devices cannot be distinguished by device id alone, and I think the
many variants of the RTL8139 are an example of this.  However, a driver
may reject a device that it does not handle, in which case the kernel
will try using the other driver.  I think 8139cp and 8139too do this.
There are other cases of overlapping device ids, for example between
rt2500usb and rt73usb.

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

The initramfs scripts wait for all drives to be scanned before selecting
the boot partition.  This is done by inserting and then removing the
scsi_wait_scan module.

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

This is not related.

Ben.

-- 
Ben Hutchings
Power corrupts.  Absolute power is kind of neat.
                           - John Lehman, Secretary of the US Navy 1981-1987

Attachment: signature.asc
Description: This is a digitally signed message part


--- End Message ---
Reply to: