J. Fahrner via Dng <dng@lists.dyne.org> wrote: > I don't see why this parameter is so important. When I read the description, > this is the delay for scanning usb devices after power up. But as you can see > in the logs, the device is responding and telling its characteristics. Only > mounting the filesystem fails.
As I've read the thread, the delay is between querying the USB bus for devices and trying to read from them. In your case, the device is been seen on the bus, but the mount fails - one possible cause of that is that the USB bridge device and/or disk are not ready in time, i.e. that the chippery and/or disk between them are not read to read data within 5s (if that's the default) of the devices being enumerated. So changing this parameter is to see if giving a longer time between enumerating the devices on the bus (at which point, the chippery and disk should initialise and spin up) and actually trying to read form the disk. If it does, great; if it doesn't then there's a different problem. > A smaller disk is no option, since this is my media server at home. It is > filled with 66%. I think the idea was simply to try a smaller disk and see if that works. It's all in an effort to narrow down the list of possible causes - e.g. if it still won't mount then it being a big disk isn't the problem; if it does mount then at least you know it's not the USB chippery in the drive case. At present, there are a lot of possible causes, which makes fixing the problem tricky. Simon _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
