After shutdown I notice that both the USB hub and the external USB drive remain active (lights on): the next time I try to boot the system hang after grub and I have to do a hard reboot. After that the system boots fine, until the next shutdown/boot cycle.
Ideas on how to troubleshoot/resolve the issue?
EDIT: The USB hard drive is powered by an adapter, while the hub is self powered; it's a dual-boot machine, with Windows XP on another partition and with Win there's no such a problem.
EDIT #2: It's a PC, and the USB devices remain active after the PC's shtudown: I mean, when the pc is completely off, not standby, not hibernated and not suspended. After that the CPU, PSU, GPU and the various fans are completely quiet.
EDIT #3: The problem occurs also if a SD card is in the reader at boot time.
Also, I re-read again before posting, and I think I mis-interpereted your question. By after shutdown, do you mean after the PC shuts down, or the process of shutting down, before the PC turns itself off?
I am assuming you have a PC, not a laptop. When you shut down your PC, there s still some power flowing through the SMPS (also called the PSU). Thats the reason you can see the hub lit. As for the HDD, it might be connected to the same spike-strip/board as the PSU. After you shut-down the PC, turn off the wall socket too, and see if that works.
It's not possible.
Here's why: Because your drive is set to run as long as it has power. There is no way to change that, it's hardware level.
So, the only way to make it stop that is to unplug it.
Apologies if that wasn't what you wanted to hear, but it's the truth as far as I've been able to figure out.
This may be silly ...any chance it's a grub issue?
if it's a really really really OLD version of grub, maybe. look in /boot/grub/grub.cfg
Do you see UUIDs being used? stuff like:
or do you see something like
if it's the former, nevermind ignore this post ;)
if it's the latter, then well you might want to edit those /dev/sdXY pointers to UUIDs, because the USB device might be taking over that device name (which is possible with today's BIOSes)