Since I installed 11.0, the startup time has greatly increased. I noticed that it lingers a very long time after some of the following messages (I wrote these down from the screen, if someone can point me where to find them, I’ll be happy to provide more):
Oops: 0000 #1] SMP
...
Pid: 923, comm: modprobe Tainted: P N(2.6.25.5-1.1.pae #1)
...
(various stuff with the word ‘usb’ in it, e.g.)
Call trace: ... usb_remote_probe
...
udevd-event[909]: run program: '/sbin/modprobe' abnormal exit
Then after maybe half a minute without any indication of activity, it picks up again and finishes the boot process.
There is an external hard drive connected via USB. Could this be the culprit? It would be rather inconvenient if I had to remove it each time I start the computer.
Possibly. Can you try switching the drive to another USB port, swapping ports with another USB device? Also, if this is on a USB hub, try removing the hub and connecting directly. Also, try connecting to a port that is directly mounted on the motherboard (on a desktop machine, on the rear I/O panel).
>
> I put the USB drive on the backside of the system, on the motherboard.
> This changed only a little: the last line is gone, there is now
>
>
> Code:
> --------------------
> sd4:0:0:0 Attached scsi generic sg4 type 0be’ abnormal exit
> --------------------
>
>
> Thanks, H.
>
>
The messages you are looking for may be found in /var/log/boot.msg
You could view that file, and cut-n-paste the text from the error messages to
the continuation.
Indeed if I unplug the external USB drive during boot, the problem does not occur. I guess it’s time to make a bug but it would be good to know what I should be posting there.
This seems to be the relevant part. Also some messages like
<4>Driver ‘sr’ needs updating - please use bus_type methods
but that doesn’t seem to have to do with it.
Further on, there is
System Boot Control: The system has been set up
Failed features: boot.udev
Skipped features: boot.cycle
System Boot Control: Running /etc/init.d/boot.local
done<notice>killproc: kill(719,3)
/var/log/boot.log is empty or cannot be accessed (not even as root).
What is the spec on the external? PATA or SATA? USB 1 or USB 2? Can you post back an fdisk on it? What filesystem(s)?
Boot with drive powered off. When you power it on, does it automatically mount? If so, post back result of doing a >mount in a terminal window. Also post back contents of /etc/fstab.
With the drive powered on, boot and immediately open a terminal window. Then do >dmesg to display the kernel boot messages and post that back here (if it helps, “dmesg > text” will send the display to a text file on disk).
Apparaat Opstart Begin Einde Blokken ID Systeem
/dev/sdc1 1 24321 195358401 c W95 FAT32 (LBA)
As you see, I have a Dutch Linux. I think you should be able to understand though, expecially if you do fdisk -l yourself, it has the same layout, right?
The drive does not have a power on/off button. It has no buttons, in fact. Just a led which shows that it’s connected, a USB port and an AC port. This makes it difficult to find any more information on it.
Yes, it does automatically mount. It does so if I unplug it and replug it as well. Once the system is running, everything seems to work fine. Also other USB sticks.
I’m afraid, though, that the phenomenon is not consistent: sometimes it starts up quicker (it did this time), and the error sometimes also occurs when the drive is not connected. I think because it remembers it from last time.
The hardware detection looks OK, no errors. The kernel detects the drive and assigns a drive-name and partition to it, sdc1.
Unfortunately, none of your logs show the mount attempt. You might try to get at that again, either in dmesg (since it’s apparently sdc1, you can just do “dmesg | grep sdc” to isolate those lines). Or the same from /var/log/messages, because a usb mount should be written to that log. Since an entry was written to fstab for the drive (you were right about that, that’s how it “remembered”), you might try doing a manual mount, i.e., without using fstab (which will be used by a mount command if there is a matching device). A simple way is to temporary comment out that line in fstab. Umount it if it is mounted. Then do “mount -t vfat /dev/sdc1 /media/USB-HDD” (if this folder is not already there permanently, create it). Then do “mount”. You’ll see the options with which the device was mounted. Check that you can access it properly. Then edit fstab again, uncommenting the line and changing the options column to whatever you saw when you did “mount”. This is just a quick way to check if perhaps the options automatically generated to fstab are somehow a problem.
Also, be sure you are connecting to a USB 2.0 port. It’s difficult to tell from dmesg if you have any USB 1.0 ports because the hub controller for 2.0 requires the 1.0 controller which it uses as a slave should a 1.0 device be plugged into a 2.0 port. Your device is powered thru the port, and if it’s on a 1.0 you could get intermittent behavior - which you’ve observed. I’d also try using various ports and be sure not to use a physical hub.
Power and the mount are the only two things I can think of to look at. Sorry I can’t offer more. Perhaps others will have some ideas.
/var/log/boot.msg:<5>sd 4:0:0:0: [sdc] Attached SCSI removable disk
/var/log/messages:Jun 26 23:38:20 linux-klgq smartd[12540]: Device: /dev/sdc, opened
/var/log/messages:Jun 26 23:38:20 linux-klgq smartd[12540]: Device: /dev/sdc, NO MEDIUM present; skip device
/var/log/messages:Jun 27 08:51:13 localhost smartd[4053]: Device: /dev/sdc, opened
/var/log/messages:Jun 27 08:51:13 localhost smartd[4053]: Device: /dev/sdc, NO MEDIUM present; skip device
/var/log/messages:Jun 29 10:54:37 localhost smartd[4011]: Device: /dev/sdc, opened
/var/log/messages:Jun 29 10:54:37 localhost smartd[4011]: Device: /dev/sdc, NO MEDIUM present; skip device
/var/log/messages:Jun 30 21:16:25 localhost smartd[4079]: Device: /dev/sdc, opened
/var/log/messages:Jun 30 21:16:25 localhost smartd[4079]: Device: /dev/sdc, Bad IEC (SMART) mode page, err=4, skip device
/var/log/messages:Jun 30 21:16:37 localhost hald: mounted /dev/sdc1 on behalf of uid 1001
/var/log/messages:Jun 30 21:52:52 localhost hald: unmounted /dev/sdc1 from ‘/media/AUDIOGOGEAR’ on behalf ofuid 1001
/var/log/messages:Jul 3 09:10:44 localhost smartd[3996]: Device: /dev/sdc, opened
/var/log/messages:Jul 3 09:10:44 localhost smartd[3996]: Device: /dev/sdc, IE (SMART) not enabled, skip device Try ‘smartctl -s on /dev/sdc’ to turn on SMART features
/var/log/messages:Jul 3 09:11:08 localhost hald: mounted /dev/sdc1 on behalf of uid 1000
/var/log/messages:Jul 3 09:26:46 localhost hald: unmounted /dev/sdc1 from ‘/media/USB-HDD’ on behalf of uid1000
/var/log/messages:Jul 3 22:31:37 localhost smartd[4053]: Device: /dev/sdc, opened
/var/log/messages:Jul 3 22:31:37 localhost smartd[4053]: Device: /dev/sdc, IE (SMART) not enabled, skip device Try ‘smartctl -s on /dev/sdc’ to turn on SMART features
/var/log/messages:Jul 3 22:31:53 localhost hald: mounted /dev/sdc1 on behalf of uid 1000
/var/log/messages:Jul 3 22:40:50 localhost hald: unmounted /dev/sdc1 from ‘/media/USB-HDD’ on behalf of uid1000
and similar like that. As you can see, sdc1 is also used for AUDIOGOGEAR, which is a 1G usb stick/mp3 player.
If I grep for sdg, I get similar things. Trying the recommended smartctl -s on /dev/sdg1 gives an error:
unable to fetch IEC (SMART) mode page [unsupported field in scsi command]
A mandatory SMART command failed: exiting. To continue, add one or more ‘-T permissive’ options.
I could not test this since there was no entry in fstab. There was in mtab, as I wrote in my previous post, but that one’s gone now (I started with the drive detached). Well, after plugging it in, it contains /dev/sdg1:
mounting it by hand with your command (s/sdc/sdg/) I get:
/dev/sdg1 /media/USB-HDD vfat rw 0 0
I tried sveral ports. I tried booting with the drive detached or attached. It stays unpredictable: sometimes the error occurs even when the drive is not connected, sometimes the converse. I’m starting to give up here.
This solved the issue, it seems, thank you very much! How am I going to know when I can remove this line again, or why? Is there a bug that needs reporting for the kernel?