Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I am trying to check a mounted partition to see if the drive has errors:

[root@virtuality ~]# /sbin/badblocks -v /dev/sdb1
Segmentation fault

Uh oh. What does this mean? Why is badblocks segfaulting? Can I fix it?

(System is CentOS release 4.6, drive is an SATA drive)

EDIT: Using strace:

[root@virtuality ~]# strace /sbin/badblocks -v /dev/sdb1
...[snip]...
open("/dev/sdb1", O_RDONLY)             = 3
ioctl(3, BLKGETSIZE, 0x7fbffff878)      = 0
close(3)                                = 0
open("/dev/sdb1", O_RDONLY)             = 3
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
share|improve this question
    
I'm pretty sure that means it's hosed :( :( :( ... is this your new box that you just stood up or the old one? –  jcolebrand Jan 11 '11 at 23:41
1  
Try again with strace, what are the last few lines of the output? –  badp Jan 11 '11 at 23:43
    
Have you run a memory test lately? (E.g. from the boot menu in SystemRescueCD, in the Ubuntu livecd, etc.) –  Gilles Jan 12 '11 at 8:05
add comment

2 Answers

The last few lines of that strace tell a fairly boring tale: badblocks opens the drive device, gets its size, closes it, reopens it and then goes off to do some work, which fails in some way strace doesn't show. You'd have to use gdb or similar to dig deeper.

Your symptom may go away if you unmount the partition so badblocks has a stable thing to work on. Obviously this shouldn't be required just to do the read-only test you're attempting, but it wouldn't be the first time that some low-level uncommonly-used operation didn't work as it should.

Bonus: If you unmount the partition, you can use badblocks -n, which is far more effective at finding and fixing disk surface problems.

share|improve this answer
    
+1 for good advice, including running badblocks -n when the drive is unmounted. (A Virtual Machine has a backup vmkd on this drive so while it's not in use, it's also not easy to umount) Turns out this may have just been a silly mistake, running yum to update my system caused the problem to go away. –  Josh Jan 12 '11 at 13:23
    
Actually, the open() succeeded, as you can see from its return value of 3. The SIGSEGV happened somewhere in the badblocks code, not in a syscall. In general, you'll never get a SIGSEGV while a syscall is in progress; if anything, you'd get a kernel OOPS. –  Jander Jan 13 '11 at 9:43
    
Indeed. Removed the speculation based on unindicated nondeterminism. –  Warren Young Jan 13 '11 at 18:01
add comment
up vote 1 down vote accepted

Turned out this was a numbskull error, looks like my copy of badblocks may have just had a bug.

I ran yum update and after that, badblocks no longer segfaults.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.