Niels, from the logs and output Víctor posted it seems it is a simple /dev/sda drive. However, it is possible that the drive that fails is not /dev/sda as the logs identify the drive by its hardware slot. The RAID lock lead sounds promising, it might explain the hang.
Víctor, could you please post the output of `lsblk --all --output-all` (in a text file as the lines will be very wide) so that we have a better idea of your HDD layout? Also post the relevant lines from the system log but also in a text file because in your first message they were truncated. We need to determine which drive exactly fails. Kind regards, Ondřej Grover On Sun, Apr 19, 2015 at 10:21 AM, Niels Thykier <[email protected]> wrote: > On 2015-04-19 02:43, Víctor Cana Benítez wrote: > > Dear maintainers, > > > > Hi, > > Thanks for following up. It is indeed an interesting find. > > > Finally I have found the problem to package hdparm in debian jessie. > > > > Resume: *the problem is the way that the package hdparm in debian > jessie's > > repository is compiled*. > > > > As Ondrej mentioned it mind be something different that just how it > compiled. Nevertheless, it certainly confirms that the problem is > entirely on the Debian side. > > I got two possible leads, Víctor do you have: > * a RAID setup? > * a block device named something like /dev/sdaa or /dev/hdaa? > - Minimum 4 /letters/ and starting with either "sd" or "hd". All > other letters can vary in the a-z range. > > If you have a RAID: > * Please provide the output of: > egrep -iq "resync|repair|recover|check" /proc/mdstat > cat /proc/rd/status > * Combined they should just say "OK" (or complain about missing > files). If not, your system is triggering the "RAID" resync code. > If this happens on every reboot, the issue is probably that it > takes your system is about a minute to resync them and Debians > init scripts forces you to wait for it to happen. > > > Well, to get to that conclusion, first I compared the sources of hdparm > from > > debian jessie and from ubuntu vivid. Unlike our colleague Niels, I > didn't find > > differences between both. Then, I downloaded the sources of hdparm from > debian > > jessie's repository, descompressed them, and typed in the terminal > "make" and > > finally "checkinstall". > > [...] > > This /sounds/ like you just downloaded the "hdparm_9.43.orig.tar.gz" > file and only used that. If so, a very likely alternative to your > conclusion would be a Debian specific change causes this issue (as > Ondrej suggested). > > The debian source also includes (in this case) a > "hdparm_9.43-2.diff.gz", which contains the debian packaging and > possibly some changes to the source. > > * Debian has *no* direct changes to the upstream code > * Ubuntu /has/ direct changes to the upstream source. However, these > are not applied upstream last I checked. Given a "vanilla" > upstream release "just works(tm)", lets whitelist all of these > changes as "safe" for now. > > This leaves an interdiff between Ubuntu (as "orig") and Debian (as > "new") of [excluding the changelog]: > > """ > 95hdparm-apm | 5 ++--- > control | 5 ++--- > hdparm.init | 5 +++++ > hdparm.udev | 4 ++-- > rules | 3 ++- > 5 files changed, 13 insertions(+), 9 deletions(-) > """ > (attached as hdparm-ubuntu-debian.interdiff) > > > Lets spread these changes into distinct changesets: > > * debian/hdparm.init => Debian has a *lock* in place for a RAID > "workaround". > > * debian/hdparm.udev => Change a rule to only match /dev/[sh]d[a-z] > instead of /dev/[sh]d[a-z]* > > * debian/95hdparm-apm => comments only / noise > > * debian/control => Add dependency on lsb-base (and some noise) > - Unlikely to be the problem as I doubt you uninstalled lsb-base > just to test this. > > * debian/rules => Change to if/how the service should be started. > - My take here is that this is Ubuntu specific due to their > (previous?) use of upstart > > > > > Thanks, > ~Niels > > >
